Baixar para ler offline
Carregado porPatrícia Melo
Ciclo de vida processo
O documento discute os processos de engenharia de requisitos, incluindo a obtenção e análise de requisitos, ciclos de vida de desenvolvimento de software e modelos como cascata, evolucionário, formal e incremental. Ele também descreve as atividades de engenharia de requisitos como elicitação, especificação e gerenciamento de mudanças.
Mais conteúdo relacionado
Ciclo de vida processo
- 1. O processo deEngenharia de Requisitos
- 2. 2. Obtenção eAnálise dos Requisitos Avaliar os problemas na situação atual Principal foco para o novo sistema: O QUE e não COMO: – qual o fluxo e o conteúdo de informação – quais as funções do sistema – quais dados o sistema produz e consome – qual o comportamento do sistema – quais as características de interface com outros subsistemas – quais são as restrições do projeto
- 3. A Gerência doProcesso de Desenvolvimento
- 4. Ciclo de Vida Qualo propósito de estabelecer um Ciclo de Vida para o Software? – Definir que atividades devem ser executadas em um projeto de desenvolvimento de sistemas – Introduzir consistência entre vários projetos de desenvolvimento de sistemas de uma mesma organização – Prover pontos de controle para prever, gerenciar e controlar o desenvolvimento de sistemas
- 5. Ciclo de Vida Cascata Evolucionário Formal Orientadoa Reuso Espiral Incremental
- 6. Cascata Ciclo de VidaClássico Prevê um processo de desenvolvimento com etapas seqüenciais Base: engenharia convencional O resultado de cada fase envolve a elaboração de um ou mais documentos que são aprovados
- 7.
- 8. Cascata Problemas: – Para grandesprojetos o tempo que decorre desde a especificação até sua implantação é grande – O Ambiente Externo evolui e é diferente daquele que deu origem a sua especificação – Na prática os estágios se sobrepõem – O processo de software envolve interações
- 9. Evolucionário Base – Desenvolver umaimplementação inicial – Expor o resultado ao comentário do usuário – Aprimoramento por meio de muitas versões – Até que o sistema tenha sido totalmente desenvolvido Dois tipos: – Exploratório – Protótipos descartáveis
- 10. Evolucionário Exploratório – Trabalhar como cliente – O desenvolvimento inicia com as partes do sistema que são compreendidas – O sistema evolui com as novas características propostas pelo cliente Protótipos descartáveis – O protótipo experimenta os requisitos não compreendidos – Neste caso o objetivo é a Especificação de Requisitos – Falaremos de protótipos mais adiante
- 11.
- 12. Evolucionário Produz sistemas queatendem as necessidades imediatas do cliente Problemas – O processo não é visível • Não se produzem documentos que reflitam as versões do sistema – Freqüentemente são mal estruturados • Software sem estrutura • Modificações cada vez mais custosas – Ferramentas e técnicas especiais • Possibilitam rápido desenvolvimento • Poucas pessoas podem ter a habilitação necessária para usá-las
- 13. Evolucionário Definição de Requisitose Refinamento Projeto Rápido Constru- ção do Protótipo Avaliação do Usuário Refinamento do protótipo Produto Final Início Fim
- 14. Formal Base: a transformaçãomatemática formal de uma especificação de sistema em um programa executável – A especificação de requisitos é redefinida com uma linguagem formal Especificação de Requisitos Especificação Formal Transformação Formal Testes
- 15. Formal Transformação formal – Váriasetapas – Representação mais detalhada, matematicamente correta Adequada a sistemas críticos – Permite verificação automática de consistência – Model checking • utiliza máquinas de estado para verificar onde uma determinada propriedade é satisfeita sob todas as condições – Prova de teoremas • axiomas do comportamento do sistema são empregados para derivar uma prova de que o sistema vai se comportar de uma determinada forma
- 16. Orientado a Reuso Amplabase de componentes reusáveis Infra-estrutura de integração Etapas: – De posse da Especificação de Requisitos, buscam-se componentes para implementá-la – Negociação – requisitos são modificados para que se possa usar os componentes Redução do esforço de desenvolvimento
- 17. Iteração de processo Existea necessidade de utilizar diferentes abordagens para diferentes partes do sistema Partes do processo são repetidas enquanto os requisitos evoluem Modelos Híbridos – Apóiam a iteração do processo – Desenvolvimento Espiral – Desenvolvimento Incremental
- 18. Modelo Espiral O processode desenvolvimento se move sobre uma espiral evolucionária – Melhores características do • Ciclo de vida clássico • Evolucionário – Prototipação • Acrescenta Análise de Riscos As fases são executadas de forma iterativa As fases de análise e projeto não são monolíticas e distintas
- 19.
- 20. Modelo Espiral Planejamento – objetivos,alternativas e restrições Análise de Riscos – Análise de alternativas e identificação/resolução de riscos – Prototipação pode ser usada – Simulações e outros modelos podem ser usados para definir melhor o problema Desenvolvimento e Validação – Desenvolvimento do produto no “nível seguinte” Avaliação feita pelo Cliente Volta ao Planejamento
- 21. Enfoque Incremental Uma variaçãodo modelo cascata onde a partir da fase de especificação de requisitos são feitos incrementos sucessivos. Estratégia para minimizar riscos, obtendo- se resultados de médio e curto prazo sem se descuidar do objetivo final
- 22.
- 23. Desenvolvimento Incremental O Processode Desenvolvimento RUP está em conformidade com o Desenvolvimento Incremental.
- 24. Desenvolvimento Incremental Em vezde entregar o sistema como um todo, o desenvolvimento e a entrega são divididos em partes, com cada incremento entregando parte da funcionalidade requerida Requisitos dos usuários são priorizados e os requisitos de mais alta prioridade são incluídos nas iterações iniciais Uma vez que o desenvolvimento de um incremento é iniciado, os requisitos são "congelados“, embora possam continuar a evoluir para incrementos posteriores
- 25. Desenvolvimento Iterativo eIncremental (RUP)
- 26.
- 27. Engenharia de Requisitos Compreendera natureza do software a ser desenvolvido é realmente muito complexo Conseqüentemente é difícil estabelecer o que o sistema deve fazer Estabelecer o que o sistema deve fazer descrevendo suas funções e restrições é conseguir determinar todos os seus requisitos O Processo de: 1. Descobrir 2. Analisar 3. Documentar 4. Verificar É chamado de Engenharia de Requisitos
- 28.
- 29. Engenharia de Requisitos Oprocesso de estabelecer as funções que um cliente requer de um sistema e as restrições sob as quais ele deve funcionar e ser desenvolvido Os requisitos são descrições das funções e restrições que são geradas durante o processo de engenharia de requisitos
- 30. Atividades de Engenhariade Requisitos – Recursos Humanos
- 31. Organização e Responsabilidade- Papéis Analista de Negócios Negocia junto com os clientes e os demais envolvidos a lista dos requisitos iniciais e suas ampliações, priorizando-os e quando necessário agrupando-os em pacotes a serem desenvolvidos em iterações. É responsável por explicitar as regras de negócio e o glossário associado ao negócio. Analista de Requisitos Elicita os requisitos de produto e registrá-os de forma adequada. Garante a rastreabilidade dos requisitos de negócio e requisitos de produto ao longo do projeto. Cliente Aprova a versão final do escopo da aplicação, descrito na Especificação de Requisitos de software Inspetor Inspeciona a Especificação de Requisitos de Software com relação ao formato. Testador Aplica o Plano de Testes e assegura que os requisitos implementados estão de acordo com o requisitado pelo cliente.
- 32. Explicitar odomínio do problema Identificar possibilidade de reuso de solução Identificar pessoas e áreas impactadas Elicitar e classificar os requisitos de negócio Envolver a área de serviços e definir alternativas de solução Analisar e validar os requisitos Necessidades Analista de Negócios Regras de Negócio Glossário Documento de Visão Elicitação dos Requisitos de Negócio
- 33. Especificação e Modelagemde Requisitos Elicitar Requisitos de Produto Especificar casos de uso e validá-los Especificar requisitos não funcionais Analisar e validar os requisitos Requisitos p/ Inspeção Plano e Casos de Teste Casos de Uso e Esp. Suplementar Regras de Negócio Glossário Documento de Visão Analista de Requisitos
- 34. Verificação e Validaçãodos Requisitos Verificar conflitos de requisitos Verificar consistência de requisitos Verificar completude de requisitos Verificar existência de requisitos ambíguos Analista de Requisitos Requisitos p/ Inspeção Plano e Casos de Teste Casos de Uso e Esp. Suplementar Garantir a rastreabilidade dos requisitos Validar requisitos com o cliente Inspetor Especificação de Requisitos Atualizada Resultado dos Casos de Teste
- 35. Rastreabilidade e Gestãode Mudanças Avaliar o impacto nos requisitos Validar com o cliente Notificar os envolvidos Atualizar as especificações de requisitos Garantir a rastreabilidade nos requisitos Necessidade Documento de Visão Atualizado Solic. Mudança Analista de Requisitos Analista de Negócios Especificação de Requisitos Atualizada
- 36.
- 37. Explicitar odomínio do problema Identificar possibilidade de reuso de solução Identificar pessoas e áreas impactadas Elicitar e classificar os requisitos de negócio Envolver a área de serviços e definir alternativas de solução Analisar e validar os requisitos Necessidades Analista de Negócios Regras de Negócio Glossário Documento de Visão Elicitação dos Requisitos de Negócio
- 38. Elicitação de Requisitos Atividadesque envolvem a descoberta de requisitos de um sistema: – identificação das fontes de informação – técnicas de elicitação (coleta de fatos) – comunicação (estabelecer uma linguagem comum) Envolve pessoal objetivando descobrir: – o domínio de aplicação – serviços que devem ser fornecidos – restrições
- 39. Elicitação de Requisitos Podeenvolver diferentes tipos de pessoas em uma organização (stakeholders): – usuários – gerentes – desenvolvedores – especialistas de domínio – sindicatos,... A equipe de desenvolvimento e clientes trabalham em conjunto visando identificar: – detalhes do domínio da aplicação – serviços que o sistema deve oferecer – desempenho – restrições de hardware, ...
- 40. Elicitação de Requisitos Problemas: –Em geral, stakeholders não sabem o que querem de fato • dificuldade de expressão • pedidos não realistas – Stakeholders expressam requisitos em sua própria terminologia • conhecimento implícito – Stakeholders distintos podem ter requisitos conflitantes – Fatores políticos podem influenciar os requisitos do sistema – Ambientes econômicos e de negócios são dinâmicos • requisitos mudam durante o processo de análise • novos requisitos podem surgir (novos stakeholders)
- 41. Elicitação de Requisitos Atividadesdo Processo: – Compreensão do domínio – Coleta de requisitos – Classificação – Resolução de conflitos – Definição de Prioridades – Verificação de requisitos
- 42. Compreensão do Domínio Osanalistas devem desenvolver sua compreensão do domínio da aplicação – se estiver desenvolvendo um sistema de supermercado deverá descobrir como este funciona – utilizar técnicas para descobrir este funcionamento – aprender a linguagem do usuário • elaborar um Glossário
- 43. Coleta de Requisitos Interagircom stakeholders para descobrir os requisitos A coleta de requisitos é feita através de técnicas Os requisitos são simplesmente documentados à medida que são coletados – resulta em documento preliminar (draft)
- 44. Classificação dos Requisitos Consistebasicamente em agrupar os diversos requisitos coletados em categorias bem-definidas Classificação: – Funcional Ex.: Deve ser possível consultar o preço de uma mercadoria – Não Funcional Ex.: A consulta deve retornar uma resposta em no máximo 5s – Inversos Ex.: O sistema não fará controle de estoque.
- 45. Resolução de Conflitos Énormal que ocorram requisitos conflitantes Por exemplo – R-23: O sistema deve ... – R-45: O sistema não deve ... Cliente é o responsável por resolver conflitos e ambigüidades
- 46. Atribuição de Prioridade Algunsrequisitos são mais urgentes que outros É essencial determinar a prioridade dos requisitos junto ao cliente Requisitos de maior prioridade são considerados em primeiro lugar
- 47. Prioridade Requisitos podem seragrupados em classes, por exemplo: – Essenciais – Importantes – Desejáveis Em princípio, o sistema deve abranger todos os requisitos de essenciais para desejáveis
- 48. Exemplo de Prioridade Aconsulta ao extrato bancário deve retornar dados do movimento até o dia anterior – Prioridade: Essencial A consulta ao extrato bancário deve visualizar dados segundo padrão X – Prioridade: Importante A consulta ao extrato bancário deve usar cores vermelhas para saldos negativos – Prioridade: Desejável
- 49. Verificação de Requisitos Osrequisitos são verificados – Completos? – Consistentes? – Em concordância com o que os stakeholders desejam?