EL064X - Aula 05

Algumas perguntas

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

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

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.

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

05) O desenvolvimento ágil, ajuda ou atrapalha?

Alexandre e Deus

06) As revisões por pares são mais eficientes que testes funcionais?

Luiz Cláudio

• 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

• 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
• Principais métodos ágeis:
  • Programação eXtrema (XP)
  • Crystal (uma família de métodos)
  • Scrum
  • Lean
  • Feature-driven Development
  • e outros

• 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

• 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

• 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

• 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

• 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.”

• 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."

Figura: Ana Liddy Cenni de Castro Magalhães

• O teste:
  • Testes de unidade: escrito pelos programadores
  • Testes funcionais: escrito pelos clientes

07) POO é melhor que PP?

Renato, Luciene e Leonardo

• Arquivo:EL064X - POOxPP.pdf

08) Uma empresa CMM Nível n+1 produz melhor software que uma empresa CMM Nível n?

Will