1. Desenvolver o software iterativamente. Um pouco de reflexão: Acabou aí? 31/08/2010

Transcrição

1 Engenharia de Software Aula 5 (Versão ) Melhores práticas para desenvolvimento de software Desenvolver de forma iterativa e gerenciar requisitos Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( ) Revisando O que você sabe sobre o modelo espiral? 2. O que você sabe sobre o modelo incremental? Melhores Práticas em Desenvolvimento de Software Desenvolvimento iterativo Gerenciamento de requisitos Utilização de arquiteturas baseadas em componentes Modelagem visual do software Controle de mudanças do software Verificação contínua da qualidade do software 1

2 1. Desenvolver o software iterativamente Cada iteração resulta em um lançamento executável (release). Facilidade de encontrar problemas mais cedo. Usuário mais participativo. Equipe é forçada a pensar nos pontos mais críticos. Lições aprendidas podem ser melhoradas dentro do próprio projeto. Facilidade de verificação do status do projeto. Equipe de teste tem trabalho mais uniforme. Um pouco de reflexão: Acabou aí? 2

3 Tem mais? Mas na verdade... Isto é comum? SIM!!! Em 1995, um relatório elaborado pelo Grupo Standish*, chamado CHAOS, alertou que apenas 16,2% dos projetos eram encerrados com sucesso. O mesmo estudo em 2004 apresentou uma melhoria no índice, passando para 34%. Na verdade, fala-se em crise do software desde 1968! * Acessado através de 3

4 Isto é comum? Segundo Capers Jones and Bill Curtis: - 25% dos projetos de software falham ou são abandonados; - 15% dos defeitos permanecem no produto entregue ao cliente; - 30% a 44% do tempo está sendo utilizado para retrabalho nas companhias (tempo não produtivo); - 50% dos prazos são atendidos pelas companhias. Segundo Professor Dr. Ivanir Costa: - 65% dos erros ocorrem na fase de requisitos - 8% dos erros ocorrem na fase da codificação* * Testes caixas pretas só conseguem verificar estes erros A questão é... Por quê? Para Jack Ganssle: Let's face it: any idiot can write code. Estudo do Grupo Standish*: Falta de Envolvimento do Usuário Falta de Gerenciamento Falta de necessidades claras * Acessado através de A questão é... Por quê? Segundo Humphrey*: - Cronogramas fora da realidade - Equipe inapropriada - Mudanças de Necessidades - Trabalho com baixa qualidade - Crenças em mágica * Maio de Acessado através de 4

5 Agora imaginem... Um idiota programando + Lista de necessidades confusas ou inexistentes + Necessidades sendo modificadas a toda hora CAOS Relatório do Grupo Standish CHAOS As coisas pioraram % dos projetos de software com sucesso; - 44% atrasados, acima do custo, e/ou com menos funcionalidades; - 24% cancelados ou nunca usados. Existe algo a ser feito? 5

6 Engenharia de Requisitos A Engenharia de Requisitos ajuda os engenheiros de software a compreender melhor o problema que eles vão trabalhar para resolver. Ela inclui o conjunto de tarefas que elevam a um entendimento de qual será o impacto do software sobre o negócio, do que o cliente quer e de como os usuários finais vão interagir com o software * Pressman, 2006 Engenharia de Requisitos O que é um requisito? Os requisitos para um sistema de software estabelecem o que o sistema deve fazer e definem restrições sobre sua operação e implementação * Sommerville, 2005 Engenharia de Requisitos Tipos de requisitos - Requisitos do usuário - Funções que o sistema deve ter, visualizados de uma maneira simples - Requisitos do sistema - Domínio: Leis, normas ou até mesmo uma restrição funcional obtidos a partir das necessidades específicas do sistema. - Funcionais: Funcionalidades ou os serviços que se espera que o sistema forneça. - Não-funcionais: Não dizem respeito diretamente às funções específicas do sistema. Definem atributos como confiabilidade e restrições. * Sommerville,

7 Engenharia de Requisitos Engenharia de Requisitos Gerenciamento de Requisitos Elicitação Análise Especificação Validação * Costa, 2007: Sub-Componentes do domínio da Engenharia de Requisitos Elicitação Vamos tentar extrair as necessidades do cliente... - Introspecção (Imaginação) - Questionários - Entrevistas - Etnografia (Observação) - JAD (Joint Application Development) Análise Vamos pensar sobre tudo que foi levantado e, de alguma maneira, vamos documentar estas necessidades na forma de sistema... - JAD (Joint Application Development) - Use cases - Prototipação 7

8 Especificação Vamos criar um contrato com o nosso cliente... - O objetivo é gerar um documento que possa ser lido por diversos stakeholders: - Clientes - Gerentes - Engenheiros de Desenvolvimento - Engenheiros de Teste - Engenheiros de Implantação Especificação * Sommerville, 2005 Validação Vamos confirmar o que o foi pedido pelo cliente... - Prototipação - Revisões formais 8

9 Desenvolvimento de Requisitos Re-avalia Elicitação Análise Especificação Validação esclarece Corrige e fecha lacunas Reescreve * Costa, 2007: Desenvolvimento de requisitos em um processo iterativo Só isso? RUP Rational Unified Process 2. Gerenciar requisitos Identificar os verdadeiros requisitos do sistema é um processo contínuo. Compreensão do usuário sobre os requisitos do sistema também muda. Se faz necessária a utilização de uma abordagem disciplinada. Facilitação da comunicação. Possibilidade de filtrar, localizar e priorizar requisitos. Permite a detecção de problemas mais cedo. 9

10 Para pensar... Um restaurante conhecido na cidade XYZ possui atualmente três instalações e contatou a sua empresa com o objetivo de solucionar um problema que eles estão sofrendo quanto ao atendimento dos clientes. O restaurante tem sofrido uma série de reclamações a respeito da demora no atendimento e do excessivo número de pedidos errados. Outro fator importante de ser comentado é a necessidade por parte do dono do restaurante de avaliar com mais precisão informações sobre os pedidos, estoque e organização dos empregados. O restaurante gostaria que fosse realizada uma avaliação do problema, indicando a possível solução, bem como o custo e prazo para execução do projeto. Equipes de 3 a 5 pessoas Obrigado! 10