I Workshop Paraense de Tecnologia de Software. Gerência de Requisitos Carla Alessandra Lima Reis (UFPA)

Transcrição

1 I Workshop Paraense de Tecnologia de Software Gerência de Requisitos Carla Alessandra Lima Reis (UFPA)

2 Roteiro Introdução/Motivação Visão geral da Engenharia de Requisitos Gerência de Requisitos Rastreabilidade GRE no MPS.BR Exemplos de Ferramentas Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 2

3 Introdução/Motivação para GRE 3

4 Objetivo da Gerência de Requisitos O objetivo da Gerência de Requisitos é garantir que os todos os requisitos aprovados sejam adequadamente transformados em artefatos, assim como garantir que cada artefato produzido tenha tido sua origem em requisitos aprovados. Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 4

5 Níveis de Maturidade MPS.BR A Em Otimização (sem processo específico) B C D E F Parcialmente Definido Gerenciado Gerenciado Quantitativamente Largamente Definido Definido Gerência de Projetos - GPR (evolução) Gerência de Decisões - GDE Desenvolvimento para Reutilização - DRU Gerência de Riscos - GRI Desenvolvimento de Requisitos - DRE Projeto e Construção do Produto - PCP Integração do Produto - ITP Verificação - VER / Validação - VAL Avaliação e Melhoria do Processo Organizacional - AMP Definição do Processo Organizacional - DFP Gerência de Reutilização - GRU Gerência de Recursos Humanos - GRH Gerência de Projetos - GPR (evolução) Medição - MED / Gerência de Configuração - GCO Aquisição - AQU / Garantia da Qualidade - GQA Gerência de Portfólio de Projetos - GPP G Parcialmente Gerenciado Gerência de Requisitos - GRE Gerência de Projetos - GPR Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 5 5

6 Quanto custa corrigir problemas em software? 6

7 Custo de correção 7

8 Custos gerados por problemas em requisitos Segundo Boehm e Papaccio (apud Pfleeger, 2004), o custo relativo para o conserto de um problema de requisitos em cada fase de desenvolvimento de sistema é: $1 na fase de análise de requisitos $5 na fase de projeto do sistema $10 na fase de codificação $20 na fase de teste de unidade $200 após a entrega do sistema [Conte 2007] Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 8

9 Custo de correção [Breitman, 2007] 9

10 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Situação típica Carla A. Lima Reis,

11 Visão Geral da Engenharia de Requisitos 11

12 Requisitos Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar, para atingir os seus objetivos. [Pfleeger (2004)] Um requisito é descrito como uma propriedade que o software deve exibir para resolver algum problema no mundo real. [SWEBOK (2004),] Rede Paraense [Conte 2007] de Pesquisa em Tecnologias de Informação e Comunicações 12

13 Requisitos não são apenas Software! Subsystem 1 System Subsystem 2 Assembly a Assembly b Assembly c Subsystem 3 Hardware Device x Software Program y (Alexander, 2001) Sistemas podem ser compostos de subsistemas de vários tipos Carla A. Lima Reis, [Conte 2007]

14 Importância dos Requisitos Estudo feito pelo Standish Group em 1995 (Pfleeger, 2004) 350 companhias e projetos de software Resultados: 31% dos projetos cancelados antes de estarem completos Em pequenas companhias, somente 16% dos projetos foram entregues no prazo e no orçamento inicialmente estabelecidos Em grandes companhias, apenas 9% atenderam esses critérios Rede Paraense [Conte 2007] de Pesquisa em Tecnologias de Informação e Comunicações 14

15 Causas para os projetos falhos Standish Group Fatores de Projetos Críticos % Resp. 1. Requisitos Incompletos 13.1% 2. Falta de Envolvimento do Usuário 12.4% 3. Falta de Recursos 10,6% 4. Expectativas Irreais 9,9% 5. Falta de Apoio Executivo 9,3% 6. Mudança de Requisitos e Especificações 8,7% 7. Falta de Planejamento 8,1% 8. Sistema não mais necessário 7,5% Carla A. Lima Reis, 2007 Requisitos estão envolvidos na maioria 15 das causas!

16 16 Soa familiar?

17 Engenharia de Requisitos É o processo de: Descobrir, Analisar, Documentar e Verificar...as funções e restrições do sistema Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Sommerville (2003) 17

18 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Atividades da Engenharia de Requisitos A Engenharia de Requisitos consiste de dois grupos de atividades relacionadas: Desenvolvimento de Requisitos (Elicitação, Análise, Modelagem e Validação) Gerência de Requisitos (Identificação, Configuração, Priorização, Rastreabilidade) Carla A. Lima Reis,

19 Atividades da Engenharia de Requisitos Elicitação, Análise, Modelagem e Validação Novos requisitos elicitados Versões aceitas, rastreabilidade, progresso Gerência de Requisitos O Desenvolvimento de Requisitos cria e interpreta os requisitos A Gerência de Requisitos organiza e mantém registro dos mesmos Carla A. Lima Reis, [Conte 2007]

20 Classificação de Requisitos 20

21 Classificação de Requisitos Requisitos Funcionais Requisitos diretamente ligados a funcionalidade do software, descrevem as funções que o software deve executar Um requisito funcional descreve uma interação entre o sistema e seu ambiente Exemplo: O sistema deve prover um formulário um relatório com os resultados dos testes clínicos de um paciente Rede Paraense [Conte 2007] de Pesquisa em Tecnologias de Informação e Comunicações 21

22 Classificação de Requisitos Requisitos Não-Funcionais São requisitos que expressam condições que o software deve atender ou qualidades específicas que o software deve ter Em vez de informar o que o sistema fará, os requisitos não-funcionais colocam restrições no sistema Exemplo: As consultas ao sistema devem ser respondidas em menos de três segundos Rede Paraense [Conte 2007] de Pesquisa em Tecnologias de Informação e Comunicações 22

23 Gerência de Requisitos 23

24 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Desafio Atual no Processo de Requisitos Gerência de Requisitos O que se deve gerenciar? É possível gerenciar efetivamente requisitos? Qual o ganho com o gerenciamento? Carla A. Lima Rei/ Rodrigo Reis,

25 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Gerência de Requisitos Principais Objetivos da Gerência de Requisitos: Gerenciar mudanças nos requisitos acordados Gerenciar os relacionamentos entre os requisitos Gerenciar as dependências entre os documentos de requisitos e outros documentos produzidos Carla A. Lima Rei/ Rodrigo Reis,

26 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 26

27 Mudança de Paradigma Formalização (Hazan, 2004): Antes do Processo de Gerência de Requisitos Quem definiu isso? Vou tentar me lembrar... Depois do Processo de Gerência de Requisitos Quem definiu isso? Foi a área de negócio XYZ no dia 10 de janeiro segundo consta aqui nessa ata... Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 27

28 Mudança de Paradigma Gerenciamento (Hazan, 2004): Antes do Processo de Gerência de Requisitos Como o usuário pode estar insatisfeito com a mudança de prazo se estamos fazendo tudo que ele quer? Depois do Processo de Gerência de Requisitos Informe ao usuário que os novos requisitos acarretarão um desvio de 20% no prazo e 5% no custo Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 28

29 Rastreabilidade de Requisitos Um requisito é rastreável se for possível identificar: Quem solicitou o requisito Porque o requisito existe Quais os requisitos relacionados Como os requisitos se relacionam a outras informações Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 29

30 Rastreabilidade Seu objetivo é criar vínculos (links) entre os requisitos e outros itens do sistema A rastreabilidade é importante para auxiliar a avaliar o impacto de mudanças nos requisitos ( forward para o projeto) E também para demonstrar a completa satisfação dos requisitos ( backward do projeto/design) Rastreabilidade pode ter outros usos e propósitos: Apoiar verificação Criar vínculos a documentos de referência Criar vínculos entre termos e suas definições Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 30

31 Rastreabilidade backward/forward forward p/ avaliar o impacto de mudança Requisitos do Usuário Especificações do Sistema Projeto do Sistema backward p/a rastrear a origem de um componente Links lógicos podem ser seguidos em qualquer direção 31

32 Ferramentas de Apoio à Gerência dos Requisitos Ferramentas de Gerência de Requisitos devem oferecer facilidades para: Identificação e Armazenamento dos Requisitos; Gerenciamento de mudanças, que ajudem a garantir que as mudanças solicitadas foram avaliadas e tratadas corretamente; Rastreabilidade, que auxiliem a encontrar dependências entre os requisitos. Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 32

33 Recursos para Gerência dos Requisitos - Site: ReqManager (TABA) Analyst Pro (Goda Software, Inc.) CaliberRM (Borland) Catalyze (SteelTrace) Cradle (3SL - Structured Software Systems Ltd) Doors (Telelogic AB) Objectiver (Cediti) RDT (Igatech) Reconcile (Compuware Corporation) Requisite Pro (IBM Rational Software) 33

34 Exemplo de Ferramenta para Rastreabilidade Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Impacto de requisitos no projeto (em outro documento) é encontrado por vínculos (links) 34

35 Matriz de Rastreabilidade Tabela utilizada para documentar os relacionamentos entre os requisitos Normalmente criam-se diferentes níveis de requisitos em uma matriz de rastreabilidade: Requisitos do Cliente, Requisitos do Sistema, Módulos de Código, Casos de Teste... Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 35

36 Matriz de Rastreabilidade (Hazan, 2004) Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 36

37 Matriz de Rastreabilidade (Hazan, 2004) Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 37

38 Matriz de Rastreabilidade (Hazan, 2004) Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 38

39 Política de Rastreabilidade de Requisitos Ao adotar um processo de Gerenciamento de Requisitos, a organização precisa definir sua Política de Rastreabilidade de Requisitos que deve incluir: A informação de rastreabilidade que será mantida; As técnicas e ferramentas que serão utilizadas; Processo de coleta das informações de rastreabilidade: quem e quando Processo de atualização das informações de rastreabilidade, após alterações Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 39

40 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Rastreabilidade dos Requisitos Estabelecimento da Rastreabilidade Bidirecional Um mecanismo que permita rastrear a dependência entre os requisitos, os planos do projeto e os produtos de trabalho deve ser estabelecido, para: Facilitar a avaliação do impacto das mudanças de requisitos que possam ocorrer, por exemplo, nas estimativas do escopo, nos produtos de trabalho ou nas tarefas do projeto. A rastreabilidade bidirecional deve ser tanto horizontal quanto vertical

41 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Rastreabilidade dos Requisitos Itens que devem ser rastreáveis A rastreabilidade só é efetiva para a avaliação do impacto das mudanças se existe rastreabilidade bidirecional entre os itens com impacto no produto: Requisitos Produtos de trabalho Planos do projeto Códigos de unidade ou módulos do software Casos de Teste

42 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Gerência de Mudanças e de Inconsistências Procedimentos da Gerência de Mudanças Durante o projeto, os requisitos podem mudar por uma série de motivos: Requisitos adicionais podem ser incorporados no projeto e/ou Mudanças podem ser feitas nos requisitos já existentes. As necessidades de mudanças devem ser registradas e um histórico das decisões acerca dos requisitos deve estar disponível Estas decisões são tomadas através da realização de análises de impacto da mudança no projeto e pode incluir aspectos como: influência em outros requisitos, expectativa dos interessados, esforço, cronograma, riscos e custo.

43 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Gerência de Mudanças e de Inconsistências Identificação de Inconsistências entre requisitos e outros produtos de trabalho A consistência entre os requisitos e os produtos de trabalho do projeto deve ser constantemente avaliada e os problemas identificados devem ser corrigidos. As inconsistências identificadas devem ser registradas, e ações corretivas executadas a fim de resolver as inconsistências. As ações para correções das inconsistências devem ser acompanhadas até que sejam resolvidas.

44 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Gerência de Mudanças e de Inconsistências Identificação de Inconsistências entre requisitos e outros produtos de trabalho (cont.) Quando há mudanças nos requisitos: Devem ser identificados os impactos da mudança com a utilização do instrumento de rastreabilidade dos requisitos Deve-se examinar se os demais artefatos estão consistentes com as alterações realizadas como, por exemplo: verificar se a planilha de estimativas está contemplando todos os requisitos e mudanças; verificar se as mudanças dos requisitos foram incorporadas ao escopo do projeto

45 GRE no MPS.BR 45

46 Resultados esperados de GRE Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 46

47 Capacidade do processo Capacidade do Processo A capacidade do processo é representada por um conjunto de atributos de processo descrito em termos de resultados esperados. A capacidade do processo expressa o grau de refinamento e institucionalização com que o processo é executado na organização Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 47

48 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 48

49 Capacidade do Processo Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 49

50 Capacidade do Processo Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 50

51 Capacidade do Processo Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 51

52 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 52

53 Capacidade do Processo Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 53

54 Capacidade do Processo Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 54

55 Capacidade do Processo Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 55

56 Capacidade do Processo Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 56

57 Capacidade do Processo Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 57

58 Capacidade do Processo Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 58

59 Capacidade do Processo Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 59

60 Artefatos de GRE 60

61 Exemplos de artefatos Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 61

62 Exemplos de artefatos Parte de uma solicitação de mudança Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 62

63 Matriz de Rastreabilidade Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações 63

64 Ferramentas para Gerência de requisitos 64

65 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Gerência de Requisitos no TABA Ferramenta para Apoio à Gerência de Requisitos ReqManager Vídeo disponível em Carla A. Lima Rei/ Rodrigo Reis,

66 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Ferramenta GatherSpace Carla A. Lima Rei/ Rodrigo Reis,

67 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Ferramenta GatherSpace Carla A. Lima Rei/ Rodrigo Reis,

68 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Ferramenta GatherSpace Rastreabilidade Carla A. Lima Rei/ Rodrigo Reis,

69 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Ferramenta RTH (free) Rastreabilidade Testes de requisitos Registro de defeitos relatórios Carla A. Lima Rei/ Rodrigo Reis,

70 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Requisite Pro (Rational) Carla A. Lima Rei/ Rodrigo Reis,

71 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Caliber Analyst Borland Carla A. Lima Rei/ Rodrigo Reis,

72 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Caliber diagrama de rastreabilidade Carla A. Lima Rei/ Rodrigo Reis,

73 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações DOORS ( cfm) Carla A. Lima Rei/ Rodrigo Reis,

74 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações DOORS Carla A. Lima Rei/ Rodrigo Reis,

75 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações DOORS Carla A. Lima Rei/ Rodrigo Reis,

76 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações DOORS Carla A. Lima Rei/ Rodrigo Reis,

77 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Enterprise Architect ( Carla A. Lima Rei/ Rodrigo Reis,

78 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Bibliografia indicada Parte I Pfleeger, Shari Lawrence. Engenharia de Software: Teoria e Prática. 2ª edição 2004, Pressman, R.S. Engenharia de Software. 6ª edição. McGraw-Hill, ( COCKBURN, A. Escrevendo Casos de Uso Eficazes: Um Guia Pratico para Desenvolvedores de Software. Bookman, 2005, X Paula Filho, Wilson de Pádua. Engenharia de Software: Fundamentos, Métodos e Padrões. 2ª edição Sommerville, Ian. Software Engineering. (7th Edition). Addison-Wesley Publishing Co, 2006, ( Nuseibeh, Easterbrook Requirements Engineering - a roadmap -. ( Neil A. Maiden and Cornelius Ncube. Acquiring COTS Software Selection Requirements. IEEE Software, 15(2):46-56, Mar Goguen, Joseph - Requirements Engineering as the reconciliation of social and technical issues - in Requirements Engineering: Social and Technical Issues edited by Joseph Goguen and Marina Jirotka - Academic Press Requrements Engineering in the health care domain - L. Cysneiros - RE03- IEEE Joint International Requirements Engineering Conference - Essen, Alemanha, pp Carla A. Lima Reis,

79 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Bibliografia indicada/referências Alexander I., Robertson, S., Understanding Project Sociology by Modeling Stakeholders, IEEE Software, Jan Feb 2004 Hazan, C., Implantação de um Processo de Gestão dos Requisitos seguindo o CMMI, VI Simpósio Internacional de Melhoria de Processo de Software, São Paulo, Nov Pfleeger, S. Engenharia de Software Teoria e Prática, 2ª Edição, Prentice Hall, 2004 SWEBOK 2004 disponível em Leite, J.C.S.P., Entrevistas, em Livro Vivo : Engenharia de Requisitos, Breitman, K. Requisitos. Minicurso Requisitos XXII Simpósio Brasileiro de Engenharia de Sofware 2007 João Pessoa Conte, T. Gerência de Requisitos. Mini-Curso. COPPE-UFRJ, 2007 Vasconcelos, A. Visão geral sobre a engenharia de software. UFPE. Carla A. Lima Reis,

80 Rede Paraense de Pesquisa em Tecnologias de Informação e Comunicações Referências na web Laboratório de Engenharia de Requisitos da UFPE ( Livro Vivo sobre Engenharia de Requisitos, Prof. Julio Leite ( Cenários e Léxicos (Sl.les.inf.puc-rio.br/cel) Artigos do Workshop de Engenharia de Requisitos (wer.inf.pucrio.br/werpapers/) Carla A. Lima Reis,