Requisitos. Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( )

Transcrição

1 Qualidade de Software Aula 8 (Versão ) 01) Requisitos Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( )

2 Revisando Qual o foco da garantia da qualidade do processo? 2. O que significa CMMI e qual o seu objetivo? 3. Qual a diferença do CMMI para o CMMI-DEV? 4. Quais os tipos de representações existentes no CMMI-DEV? Qual das representações é mais utilizada no mercado? 5. O que significa nível de capacidade e qual o seu objetivo para o CMMI-DEV? 6. O que significa nível de maturidade e qual o seu objetivo para o CMMI-DEV? 7. O que significa nível de maturidade 1? 8. O que significa nível de maturidade 2?

3 Por que rever requisitos? Dos projetos de software que falham (aproximadamente 66% dos projetos), 65% falham por questões relativas aos requisitos!!!

4 Revisando 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

5 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

6 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, 2005

7 Como o CMMI-DEV trata a questão dos Requisitos? - Nível 2 Gerenciamento de Requisitos (REQM) - Nível 3 Desenvolvimento de Requisitos (RD)

8 Gerenciamento de Requisitos segundo o CMMI-DEV O objetivo da área de processo Gestão de Requisitos (REQM) é fornecer subsídios para gerenciar os requisitos dos produtos e componentes de produto do projeto e identificar inconsistências entre esses requisitos e os planos e produtos de trabalho do projeto.

9 Relação de metas e práticas específicas - REQM

10 Relação de metas e práticas específicas - REQM SG 1 Gerenciar Requisitos SP 1.1 Obter Entendimento dos Requisitos SP 1.2 Obter Comprometimento com os Requisitos SP 1.3 Gerenciar Mudanças nos Requisitos SP 1.4 Manter Rastreabilidade Bidirecional dos Requisitos SP 1.5 Identificar Inconsistências entre Produtos de Trabalho, Planos de Projeto e Requisitos

11 Engenharia de Requisitos Engenharia de Requisitos Desenvolvimento de Requisitos Gerenciamento de Requisitos Elicitação Análise Especificação Validação * Costa, 2007: Sub-Componentes do domínio da Engenharia de Requisitos

12 Desenvolvimento 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)

13 Desenvolvimento de Requisitos 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

14 Desenvolvimento de Requisitos 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

15 Desenvolvimento de Requisitos Especificação * Sommerville, 2005

16 Desenvolvimento de Requisitos Validação Vamos confirmar o que o foi pedido pelo cliente... - Prototipação - Revisões formais

17 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

18 Só isso? RUP Rational Unified Process

19 Controlar mudanças do software Necessidade de um controle disciplinado: Equipes distantes, projetos de integração, stakeholders com visões diferentes. Fluxos repetíveis para gerenciar mudanças em todos os artefatos. Conceito de baseline (linha base). Rastreabilidade. Estatísticas em torno de mudanças. Ferramentas.

20 Sobre as mudanças de software... Caminhar sobre a água e desenvolver software a partir de uma especificação de requisitos é fácil, desde que ambos estejam congelados. [BERARD]

21 Sim! Os requisitos mudam! E devemos agradecer sempre por eles mudarem! - Novas necessidades - Novas leis - Mudanças tecnológicas Só temos que nos prevenir de mudanças de requisitos que causem a falha do projeto!

22 Controle de mudanças do software A maioria das modificações no software é justificada. Não condene modificações. Em vez disso, certifique-se de que dispõe de mecanismos para cuidar delas. [PRESSMAN]

23 Conceito de baseline Vamos tirar uma foto do que foi acordado... - A partir daí, qualquer mudança deverá ser avaliada para detecção de impactos em: - Custo - Prazo - Qualidade

24 Atividade Criar um ou mais processos que permitam a uma empresa atender às práticas específicas da área de processo REQM. Não se esqueçam que um processo deve descrever: - O que tem de ser feito? - Em que ordem isso deve ser feito? - Quem deve fazê-lo? - Como isso deve ser feito?

25 Obrigado!