Exibir código-fonte para EL064X - Aula 05

= Algumas perguntas =
<br>

== 01) A crise do software ainda existe (existiu)? == 
Gesmar
* Sim.
* Índice de sucesso em projetos
** 68% dos projetos nunca foram colocados em produção ou foram cancelados
** 45% acima do custo estimado
** 63% acima do prazo esperado
** 67% das funcionalidades é que são entregues
* Presente
** Silos = Bug Ping Pong
* Impacto
** Desenvolvedores sentem-se desmotivados
** Testadores não são respeitados
** Impacto negativo no negócio
<br>

== 02) Por que se errou tanto e se continua errando na construção de softwares? == 
Tiago, Matheus e João Paulo
* Entendimento distorcido de cada stakeholder
** O desenvolvimento de software tem várias etapas (passagem de bastão)
** Deve ter uma comunicação eficaz
** Pode-se usar ferramentas para ajudar no conhecimento completo
** As estimativas para definições de prazo e custo ainda são inadequados
* Motivos:
** Má prospecção dos requisitos
** Levantamento inadequado dos riscos
** Previsão de tempo de projeto subestimado
** Planejamento rápido e sem detalhes
** Não acompanhamento do avanço da tecnologia
** Alto volume de tecnologia disponĩvel
* Consequências dos erros?
** Mais de 30% dos projetos são cancelados antes de serem finalizados
** Mais de 70% dos projetos falham nas entregas das funcionalidades esperadas
** Os custos extrapolam mais de 180% dos valores originalmente previstos
** Os prazo excedem em mais de 200%, os cronogramas originais
* Onde melhorar?
** No planejamento
** Na comunicação
** Na aplicação e escolha das metodologias e tecnologias
* O que os erros podem causar?
** Insatisfação do contratante
** Equipe desmotivada
** Custo final extrapolado
** Quebra de contrato e demissão em massa
<br>

== 03) O uso de um processo formal de desenvolvimento traz ganhos de produtividade para uma equipe? == 
Júlio e Júlio

Antes de tentarmos responder esta pergunta, vamos relembrar o que é Processo Formal.

* Planejamento é definido como:
** quais atividades;
** quem deve realiza-las;
** como realizar;
** por que realizar;
** quando realizar e finalizar;
** quanto deve custar.
* Este planejamento resulta em:
** realizar estimativas;
** elaborar estrutura de divisão de trabalho;
** definir equipe e recursos;
** alocar pessoas e atividades;
** elaborar cronograma;
** elaborar orçamento.
*Além disso, deve-se fazer:
** análise de riscos;
** revisões periódicas.
* Já Modelos indicam quais são as atividades e as relações entre elas. Alguns exemplos são:
** em cascata;
** incremental;
** evolucionário;
** desenvolvimento ágil.

Reunindo os conceitos de planejamentos e modelos anteriores, definimos Processo Formal de software como o Planejamento associado a um Modelo de Processo.



Pontos positivos do Processo Formal:
* o desenvolvedor sabe o que fazer;
* a data para início e fim são definidas;
* é possível dimensionar o tamanho;
* é possível dimensionar a quantidade de artefatos;
* é possível dimensionar o esforço necessário;
* é possível ter noção quanto custa;
* é possivel perceber se há recursos para o desenvolvimento;
* facilita gerenciamento de equipe, produção, prazos, custos;
* a possibilidade da utilização de métricas para estimações.

Pontos negativos:
* a difícil escolha do modelo apropriado para cada especificidade. Exemplos: Processo Unificado Rational, Processo Unificado, Programação Extrema, etc.

Portanto, a eficiência no ganho de produtividade ao utilizarmos Processo Formal de Desenvolvimento depende da escolha certa do modelo.

<br>

== 04) Comprar não é melhor que fazer? == 
Clarissa e Hudson
* Deve-se avaliar o foco, o negócio e a estratégia
* Comprando
** Menor custo
** Menor tempo de entrega
** Não customizado
* Fazendo
** Customizado
** Maior qualidade
** Maior custo e tempo de entrega
* Para fazer:
** Necessita conhecimento, muito conhecimento
** Demanda tempo e boa organização
** Menor custoo, se bem feito
** Personalizado
* Para comprar:
** Linha de montagem profissional
** Equipe para manutenção
** Vários níveis de customização
** Alto custo
** Demanda tempo
* Avalie:
** Os custos
** Os riscos
** O tempo
** A necessidade
** A comodidade
<br>

== 05) O desenvolvimento ágil, ajuda ou atrapalha? == 
Alexandre<br>
[[Arquivo:EL064X - Desenvolvimento Ágil.pdf]]

== 06) As revisões por pares são mais eficientes que testes funcionais? ==
Luiz Cláudio
<br>
* Manifesto Ágil
** Indivíduos e interações são mais importantes que processos e ferramentas
** Software funcionando é mais importante do que documentação completa e detalhada
** Colaboração com o cliente é mais importante do que negociação de contratos
** Adaptação a mudanças é mais importante do que seguir o plano inicial
<br>

* Princípios:
** Objetivo: satisfazer o cliente entregando, rapidamente e com freqüência, sistemas com algum valor
** Entregar versões funcionais em prazos curtos
** Estar preparado para requisitos mutantes
** Pessoal de negócios e desenvolvedores juntos
** Troca de informações através de conversas diretas
<br>

* Principais métodos ágeis:
** Programação eXtrema (XP)
** Crystal (uma família de métodos)
** Scrum
** Lean
** Feature-driven Development
** e outros
<br>

* Modelo Tradicional de Desenvolvimento de Software
** A. Levantamento de Requisitos
** B. Análise de Requisitos
** C. Desenho da Arquitetura
** D. Implementação
** E. Testes
** G. Produção / Manutenção
<br>

* Princípios básicos do XP
** Feedback rápido
** Simplicidade é o melhor negócio
** Mudanças incrementais
** Embrace change => não valorize o medo
** Alta qualidade do código
<br>

* Programação em pares:
** Erro de um detectado imediatamente pelo outro (grande economia de tempo)
** Maior diversidade de idéias, técnicas, algoritmos
** Enquanto um escreve, o outro pensa em contra-exemplos, problemas de eficiência, etc
** Vergonha de escrever código feio (gambiarras) na frente do seu par
** Pareamento de acordo com especialidades.Exemplos:
*** Sistema Multimídia Orientado a Objetos
*** Aplicação Web com alto nível de segurança
<br>

 Pois é! Pessoal, não tem nada a ver!
 Uma coisa é programação em pares, outra coisa é Revisão em pares

* Uma equipe de Peer Review é composta por três a cinco componentes e suas inspeções são usualmente baseadas em uma estrutura compreensiva, incluindo:
** Desenvolvimento de checklists de inspeção para cada tipo de documento de projeto, como linguagem de codificação e ferramentas, que serão atualizados periodicamente.
** Desenvolvimento de tabelas de freqüência de erros comuns, baseados em casos passados de erros.
** Treinamento de profissionais competentes nos processo de inspeção, um processo que possibilita a formação de lideres de inspeção, ou moderadores e membros da equipe de inspeção.
** Análises periódicas da eficiência de inspeções realizadas, para avaliar a metodologia de inspeção.
<br>

* Três peças de um quebra-cabeça: chamado de “software verdadeiramente e suficientemente confiável”. Se um módulo de software for submetido:
** a quantidades enormes de testes bem sucedidos
** aprovado em revisão por pares e 
** tiver alta testabilidade
*** então o quebra-cabeça está resolvido, e a alta confiabilidade foi alcançada.
** Testabilidade de software
<br>

* T. Capers Jones - Estimating Software Costs - 1998
** “quando revisões técnicas são combinadas com as práticas de testes o número de defeitos encontrados e corrigidos podem superar os índices de 90% dos defeitos existentes.”
<br>

* Sommerville  - Engenharia de Software - 2007
** "... as inspeções são comprovadamente mais eficientes para descobrir defeitos do que os testes, pois mais de 60% dos erros em um programa podem ser detectados por inspeções informais de programa."
<br>

* Brown Winsor - 2010: Estatísticas
** Encontrar e corrigir um problema de software após a entrega é 100-1000 vezes mais caro do que encontrá-lo e corrigi-lo durante a fase de requisitos e projeto.
** Cerca de 40-50% do esforço em projetos de software atual é gasto em retrabalho que pode ser evitado
** Cerca de 80% do retrabalho evitável vem de 20% dos defeitos.
** Cerca de 80% dos defeitos vêm de 20% dos módulos e cerca de metade dos módulos estão livre de defeitos.
** Cerca de 90% do tempo de inatividade vem, no máximo, 10% dos defeitos.
** Revisões pelos pares podem pegar 60% dos defeitos. 
<br>

[[Arquivo:ESOF-IDealxReal.png]]
Figura: Ana Liddy Cenni de Castro Magalhães
<br>

* O teste:
** Testes de unidade: escrito pelos programadores
** Testes funcionais: escrito pelos clientes
<br>

* A grande questão?
** Revisões pelos pares são mais eficazes do que os testes funcionais para falhas de omissão e especificação incorreta 
** Teste funcional é mais eficaz do que revisões por falhas relativas a aproximações numéricas e controle de fluxo

== 07) POO é melhor que PP? == 
Renato, Luciene e Leonardo

* [[Arquivo:EL064X - POOxPP.pdf]]

'''TIOBE Programming Community Index'''

O TIOBE Programming Community Index é um indicador da popularidade de linguagens de programação.  O índice é atualizado uma vez por mês. 

'''Linguagens de Programação mais usadas - top 20'''
Link: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html 

[[Arquivo:pesquisa_languages.png]]

'''Ranking das linguagens de programação mais usadas (mai.10)'''
O índice pode ser utilizado para verificar se suas habilidades ainda estão atualizadas ou para se tomar uma decisão estratégica de aprender um novo ambiente que esta crescendo.

   1. C (18,18%) 
   2. Java (17,95%) 
   3. C++ (10,37%) 
   4. PHP (9,07%) 
   5. (Visual) Basic (5,65%) 
   6. C# (4,77%) 
   7. Python (4,09%) 
   8. Perl (3,28%) 
   9. Delphi (2,56%) 
  10. Objective-C (2,36%) 
  11. Ruby (2,09%) 
  12. JavaScript (2,08%) 
  13. PL/SQL (0,85%) 
  14. SAS (0,73%) 
  15. Pascal (0,72%) 
  16. Lisp/Scheme/Clojure (0,65%) 
  17. ABAP (0,65%) 
  18. Go (0,64%) 
  19. MATLAB (0,61%) 
  20. Lua (0,49%) 

Link: http://www.blogcmmi.com.br/geral/ranking-das-linguagens-de-programacao-mais-usadas-mai-10



'''Linguagens de programação mais utilizadas em 2010'''

De acordo com o gráfico mostrado no link (http://imasters.com.br/artigo/19935/linguagens/linguagens-de-programacao-mais-utilizadas-em-2010), houve um crescimento de 52% tanto do Java, quanto do C#, desde abril de 2009. Porém o Java continua muito acima. Empregos relacionados a Visual Basic tiveram um crescimento de 112% e de Ruby, 78%, considerando também início em abril de 2009.

'''Compare and Contrast Structured programming vs Object Oriented programming.''' 

One organizes code by comprehensiveness while the other organizes code by the data affected.
Structured programming consists of breaking big problems into smaller problems, then further breaking those into still smaller problems, and so on, until a level of such simplicity is reached that the implementation is obvious to the programmer expected to do the coding.  Object-oriented programming consists of grouping code with the data on which it operates so that this "object" can function independently of the rest of the software system.  Structured programming and object-oriented programming are not mutually exclusive.  You can structure the code in an object, and you can use objects to implement the modules of code in a structured program. 

Fonte: http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

== 08) Uma empresa CMM Nível n+1 produz melhor software que uma empresa CMM Nível n? == 
Will
<br>