A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Metodologia de Desenvolvimento de Software – RUP 2. Requisitos

Apresentações semelhantes


Apresentação em tema: "Metodologia de Desenvolvimento de Software – RUP 2. Requisitos"— Transcrição da apresentação:

1 Metodologia de Desenvolvimento de Software – RUP 2. Requisitos
Márcio Aurélio Ribeiro Moreira

2 Requisitos = f( comunicação )

3 Objetivos da disciplina de requisitos
Estabelecer e manter concordância com os clientes e outros investidores sobre o que o sistema deve fazer. Oferecer aos desenvolvedores do sistema uma compreensão melhor dos requisitos do sistema. Definir os limites do sistema (ou delimitar o sistema). Fornecer uma base para planejar o conteúdo técnico das iterações. Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema. Definir uma interface de usuário para o sistema, focando nas necessidades e metas dos usuários.

4 Fluxo de trabalho de requisitos

5 Objetivos das atividades
Problema Análise do problema: Essa atividade estabelece o acordo sobre o problema a ser resolvido e propõe uma solução de alto nível. Compreender as necessidades dos envolvidos (lista de funcionalidades): Essa atividade busca entender o que os envolvidos desejam a partir da solução proposta e define os recursos principais para a solução. Definir o sistema: Essa atividade destaca os requisitos chave e busca aceitação no escopo do sistema. Gerenciar o escopo do sistema: Essa atividade assegura que os requisitos do sistema estejam limpos e estabelece um conjunto gerenciável de trabalhos de requisitos para iteração. Refinar a definição do sistema: Essa atividade detalha os requisitos a serem desenvolvidos no ciclo atual de desenvolvimento. Gerenciar requisitos variáveis: Essa atividade gerencia as alterações nos requisitos e avalia seus impactos. Soluções Funcionalidades Requisitos Requisitos Software

6 A: Analisar o problema

7 A: Compreender as necessidades dos envolvidos

8 A: Definir o sistema

9 A: Gerenciar o escopo do sistema

10 A: Refinar a definição do sistema

11 A: Gerenciar requisitos variáveis

12 Essência da coleta de requisitos
Modelo de Casos de Uso Esboço Seqüencial Processo Pedido dos Envolvidos Lista de Features Plano Gestão de Requisitos Como vamos colher, analisar e manter os requisitos? Detalhar o Sistema Casos de Uso Modelo de Domínio e/ou Arquitetura do Software Estrutura de: mercado, processos, pessoas, etc. Estruturar o Software Requisitos do Software Regras de Negócio Glossário de Negócio

13 P: Plano de gestão de requisitos
Organização, Responsabilidades e Interfaces Ferramentas, Ambiente e Infra-estrutura Identificação: Rastreabilidade: Planilha de rastreabilidade Atributos de Casos de Uso: Status: Proposto, Aprovado e Validado Prioridade: Baixo, Médio e Alto Risco Técnico: Baixo, Médio e Alto Atributos de Casos de Teste Produtos de Trabalho Tipo de Requisito Descrição Visão Requisitos do Produto Recursos do produto, restrições e outros requisitos do produto. Modelo de Caso de Uso Caso de Uso Casos de Uso, documentados no Rational Rose

14 P: Esboço seqüencial Exemplo 1: Exemplo 2: Exemplo 3: SLR
Service Level Requirements Requisitos de Níveis de Serviços Spec Sheets Service Specification Sheets Planilhas de Especificações Técnicas SLA Service Level Agreement Acordo de Nível de Serviço OLA Operational Level Agreement Acordo de Nível Operacional UC Underpinning Contract Contratos de Suporte (apoio)

15 P: Pedido dos envolvidos
Lista de funcionalidades: Lista de Features ou Diagrama de requisitos Realização das Features:

16 P: Caso de Uso

17 Distribuição (Implantação)
Visões arquiteturais Usabilidade: Casos de Uso importantes para estruturação do sistema Lógica: Subsistemas, pacotes e classes relevantes para o sistema Processo: Visão do processo de negócio Parte relevante se tiver simultaneidade Implementação & Dados: Módulos, pacotes, camadas arquiteturais e entidades Distribuição (Implantação): Máquinas (nós de rede) onde o software deve ser instalado Visões arquiteturais: Ref.: KRU95, JAC98 e RUP08 Obrigatoriedade das visões: Processo Usabilidade Lógica Implementação & Dados Distribuição (Implantação) Visão Obrigatória Razão Usabilidade Sim Define a arquitetura Lógica Define a estrutura Processo Não Use se tiver simultaneidade Implementação Dados Use se a implementação ou a persistência não forem projetadas Distribuição Use se o software for distribuído

18 P: Documento de arquitetura
Usabilidade Lógica

19 P: Documento de arquitetura
Processos Implementação (módulos)

20 P: Documento de arquitetura
Implementação (processos) Distribuição (Implantação)

21 Referências Sigla Referência JAC98
Ivar Jacobson, Grady Booch, and James Rumbaugh. The Unified Software Development Process Addison Wesley Longman. KRO03 Per Kroll e Philippe Kruchten The Rational Unified Process Made Easy, A Practitioners Guide to the RUP. Addison Wesley Longman. KRU95 Philippe Kruchten 1995, "The 4+1 view model of architecture," IEEE Software. 12(6), 1995. KRU98 P. Kruchten; The Rational Unified Process: An Introduction, Object Technology Series, Addison-Wesley, 1998. MAR05 Márcio Moreira. Resumo do livro Unified Process. Márcio. Uberlândia (MG) MAR06 Márcio Moreira. Engenharia de Software - RUP . Uniube - Universidade de Uberaba - Uberlândia (MG) PRE95 PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books RUP08 IBM Rational. RUP – Rational Unified Process – 7.5 – For Large and Small Projects IBM Rational. SUM07 Sommerville, Ian. Engenharia de Software. 8ª Ed. Pearson / Prentice Hall


Carregar ppt "Metodologia de Desenvolvimento de Software – RUP 2. Requisitos"

Apresentações semelhantes


Anúncios Google