Processo Unificado de Desenvolvimento de Software G. Booch, Ivar Jacobson, James Rumbaugh Rational Software Corporation UN...
PRECURSORES Object Modeling Technique - OMT  de  J. Rumbaugh,  M. Blaha, W. Premerlani, F. Eddy e W. Lorensen (TMO - Técni...
CARACTERÍSTICAS <ul><li>baseado em  componentes  que realizam  interfaces </li></ul><ul><li>usa  UML </li></ul><ul><li>asp...
P4 = Pessoa, Projeto, Produto, Processo PESSOAS  financiam, escolhem, desenvolvem, gerenciam,  testam, usam e são benefici...
P4 = Pessoa, Projeto, Produto, Processo PRODUTO  código fonte, código de máquina, subsistemas, classes, diagramas: interaç...
Modelos REQUISITOS   -  funcionais e não-funcionais descrevem o sistema a ser desenvolvido,  sob um certo  ponto-de-vista,...
Dirigido a  Use-Cases Um  ator  é uma pessoa ou outro sistema Cada  use-case  é um requisito funcional do sistema Modelo  ...
Dirigido a  Use-Cases Porque USE-CASES?? <ul><li>Capturar os requisitos : o  Diagrama Use-Case   mostra  quais  atores  us...
Dirigido a  Use-Cases Classe de fronteira Classe de controle Classe de entidades Modelo USE-CASE Modelo ANÁLISE Modelo  PR...
Dirigido a  Use-Cases <ul><li>Dirigir o processo : </li></ul>ANÁLISE : definir as  CLASSES DE ANÁLISE para realizar um  us...
Centrado  na arquitetura <ul><li>DECISÕES SOBRE: </li></ul><ul><li>a organização do sistema como um todo </li></ul><ul><li...
Centrado  na arquitetura Use-Cases Plataforma de software Disponibilidade de blocos reusáveis Sistemas existentes Hardware...
Centrado na arquitetura PRODUTO Use-Case Arquitetura Sequência para o  arquiteto: <ul><li>Criar uma visão preliminar da ar...
4 FASES CONCEPÇÃO CONSTRUÇÃO ELABORAÇÃO TRANSIÇÃO
Iterativo e incremental Projetos grandes são divididos em  mini-projetos   Cada mini-projeto é uma  iteração <ul><li>Um gr...
Iterativo e incremental Fases
Iterativo e incremental Cada  fase  termina com um MARCO (milestone): INICIO :  o que o sistema fará? Como poderia ser a a...
Iterativo e incremental ELABORAÇÃO :  use-cases  especificados e esqueleto da arquitetura definido CONSTRUÇÃO : software f...
O  P ROCESSO  U NIFICADO
EXEMPLO Desenvolver um sistema de controle de vendedores ambulantes de um empresa. A empresa dividiu cada cidade em que at...
Modelos Requisitos ARTEFATOS Análise Projeto Implementação Testes ARTÍFICES PASSOS e  ATIVIDADES produz produzido-por comp...
Obtenção dos Requisitos ARTEFATOS <ul><li>Modelo  Use-Case   </li></ul><ul><li>ator  </li></ul><ul><li>Use-Case   </li></u...
Obtenção dos Requisitos ARTÍFICES <ul><li>Analista de sistemas </li></ul><ul><li>arquiteto  </li></ul><ul><li>Especificado...
Obtenção dos Requisitos PASSOS <ul><li>listar potenciais requisitos  </li></ul><ul><li>entender o contexto do sistema  </l...
Obtenção dos Requisitos - Passos <ul><li>listar potenciais requisitos  </li></ul>Desenvolver uma  lista de características...
Obtenção dos Requisitos - Passos <ul><li>entender o contexto do sistema  </li></ul><ul><li>criar um  modelo do domínio </l...
Obtenção dos Requisitos - Passos <ul><li>capturar requisitos funcionais  </li></ul>ARTÍFICE ARTEFATO Analista de Sistemas ...
Obtenção dos Requisitos - Passos <ul><li>capturar requisitos funcionais  </li></ul><ul><li>ATIVIDADES E SUBPASSOS </li></u...
Obtenção dos Requisitos - Passos <ul><li>capturar requisitos funcionais  </li></ul><ul><li>ATIVIDADES E SUBPASSOS </li></u...
Obtenção dos Requisitos - Passos <ul><li>capturar requisitos funcionais  </li></ul><ul><li>ATIVIDADES E SUBPASSOS </li></u...
Obtenção dos Requisitos PROJETO LÓGICO : para cada ator, ver todos  use-cases  nos  quais está envolvido e especificar os ...
Obtenção dos Requisitos PROJETO FÍSICO : <ul><li>combinar elementos de interação para formar interfaces que atendam a ator...
Obtenção dos Requisitos <ul><li>capturar requisitos funcionais  </li></ul><ul><li>ATIVIDADES E SUBPASSOS </li></ul><ul><li...
Obtenção dos Requisitos <ul><li>capturar requisitos não-funcionais  </li></ul><ul><li>ATIVIDADES </li></ul><ul><li>usabili...
Obtenção dos Requisitos <ul><li>capturar requisitos não-funcionais  </li></ul><ul><li>ATIVIDADES </li></ul><ul><li>perform...
Análise
Análise Os  requisitos externos  são transformados em um  modelo interno preciso e completo para desenvolver o projeto do ...
Análise - artefatos 2. CLASSE DE ANÁLISE Classe de fronteira Classe de controle Classe de entidades EXEMPLO Interface de r...
Análise - artefatos 3. REALIZAÇÃO DE UM  USE-CASE <ul><li>Diagramas de classe </li></ul><ul><li>Diagramas de colaboração <...
Análise - artefatos 3. REALIZAÇÃO DE UM  USE-CASE  (cont.) <ul><li>requisitos especiais </li></ul><ul><li>fluxo de eventos...
Análise  <ul><li>arquiteto  </li></ul><ul><li>Especificador de  Use-Case   </li></ul><ul><li>Especificador de componentes ...
Análise PASSOS <ul><li>Análise arquitetural  </li></ul><ul><li>Análise de cada  Use-Case   </li></ul><ul><li>Análise de ca...
Análise - passos <ul><li>Análise arquitetural  </li></ul>Análise  arquitetural MODELO USE-CASE REQUISITOS  ADICIONAIS MODE...
Análise - passos <ul><li>Análise arquitetural  </li></ul><ul><li>ATIVIDADES E SUBPASSOS </li></ul><ul><li>A1) Identificar ...
Análise - passos <ul><li>Análise arquitetural (cont.)  </li></ul>A2) Identificar classes de entidades óbvias   Obtidas a p...
Análise - passos <ul><li>Análise de cada  Use-Case   </li></ul><ul><li>encontrar as classe de análise para realizar o  use...
Análise - passos <ul><li>Análise de cada  Use-Case   </li></ul><ul><li>A1) Identificar classes de análise  </li></ul><ul><...
Análise - passos <ul><li>Análise de cada  Use-Case  (cont.)  </li></ul><ul><li>A2) Descrever interações entre objetos </li...
Análise - passos Resultado do dia Processar resumo boletim  de controle VENDEDOR partida Resumo do dia mostra resumos 1.re...
Análise - passos <ul><li>Análise de cada classe  </li></ul><ul><li>identificar as responsabilidades de cada classe, basead...
Análise - passos <ul><li>Análise de cada classe  </li></ul><ul><li>A3) Identificar associações e agregações </li></ul><ul>...
Análise - passos <ul><li>Análise de cada pacote  </li></ul><ul><ul><li>Rever as dependências entre pacotes de acordo com a...
Projeto  <ul><li>adquirir uma compreensão de aspectos de requisitos   não funcionais e restrições sobre  linguagens de pro...
Projeto
Projeto - artefatos 1. MODELO DE  PROJETO É uma hierarquia de  subsistemas  contendo   classe de projeto ,  projetos de  u...
Projeto - artefatos 3. REALIZAÇÃO DO  USE-CASE <ul><li>Diagrama de classes </li></ul><ul><li>Diagrama de interações (diagr...
Projeto - artefatos 7. MODELO DE DISTRIBUIÇÃO   (Diagrama de nós e conexões) 5. INTERFACE ( separa funcionalidade de imple...
Projeto - artífices <ul><li>Arquiteto  </li></ul><ul><li>Especificador de  use-cases   </li></ul><ul><li>Especificador de ...
Projeto - passos Projeto de um  use-case Projeto de  uma classe Projeto de um subsistema Projeto da arquitetura ARQUITETO ...
Projeto - passos <ul><li>Projeto da arquitetura </li></ul><ul><li>A1) Identificar nós e configurações de rede  </li></ul><...
Projeto - passos <ul><li>Projeto da arquitetura (cont.) </li></ul><ul><li>A2) Identificar subsistemas e suas interfaces </...
Projeto - passos <ul><li>Projeto da arquitetura (cont.) </li></ul><ul><li>A3) Identificar classes de projeto significativa...
Projeto - passos <ul><li>Projeto de um  use-case </li></ul><ul><li>A1) Identificar classes de projeto participantes </li><...
Projeto - passos <ul><li>Projeto de um  use-case  (cont.) </li></ul><ul><li>A2) Descrever a interação entre objetos </li><...
Projeto - passos <ul><li>Projeto de um  use-case  (cont.) </li></ul><ul><li>A3) Identificar subsistemas e interfaces </li>...
Projeto - passos <ul><li>Projeto de uma classe </li></ul><ul><li>A1) Definir uma classe de projeto </li></ul><ul><ul><li>a...
Projeto - passos <ul><li>Projeto de uma classe (cont.) </li></ul><ul><li>A2) Definir operações </li></ul><ul><ul><li>reali...
Projeto - passos <ul><li>Projeto de uma classe (cont.) </li></ul><ul><li>A4) Identificar associações e agregações </li></u...
Projeto - passos <ul><li>Projeto de um subsistema </li></ul><ul><li>A1) Rever as dependências entre subsistemas </li></ul>...
Implementação - artefatos 1. MODELO DA IMPLEMENTAÇÃO 2. COMPONENTE 3. SUBSISTEMA DE IMPLEMENTAÇÃO 4. INTERFACE 5. ARQUITET...
Implementação - artefatos 1. MODELO DA IMPLEMENTAÇÃO É uma hierarquia de  subsistemas de implementação contendo   componen...
Implementação - artefatos 2. COMPONENTE - exemplos <<executable>> ProcessaBoletim.java <<table>> Resumo BOLETIM __________...
Implementação - artefatos 3. SUBSISTEMAS DE IMPLEMENTAÇÃO <ul><li>um  package  em Java </li></ul><ul><li>um  project  em V...
Implementação - artefatos 5. ARQUITETURA (visão da implementação) 6. PLANO DE INTEGRAÇÃO <ul><li>Decomposição em subsistem...
Implementação - artífices <ul><li>Arquiteto  </li></ul><ul><li>Integrador do sistema  </li></ul><ul><li>Engenheiro de comp...
Implementação - artífices
Implementação PASSOS <ul><li>Implementação arquitetural  </li></ul><ul><li>Integrar sistemas  </li></ul><ul><li>Implementa...
Projeto - passos Integrar sistemas Implementar uma classe Implementar um subsistema Implementação arquitetural ARQUITETO E...
Implementação - passos <ul><li>Implementação arquitetural  </li></ul><ul><li>identificar componentes significativos </li><...
Implementação - passos <ul><li>Implementar subsistema </li></ul><ul><li>garantir conteúdo do subsistema </li></ul><ul><li>...
Teste OBJETIVOS <ul><li>Planejar os testes em cada iteração, tanto os      testes de integração  quanto os  testes de sist...
Teste - artefatos 1. MODELO DE TESTE <ul><li>Planejar os testes em cada iteração, tanto os    os  testes de integração  qu...
Fases X Etapas  Fases
As quatro Fases <ul><li>Fase de Concepção </li></ul><ul><li>estabelece o  business case  (prioridade de negócio) </li></ul...
As quatro Fases <ul><li>Fase de Elaboração </li></ul><ul><li>determina uma arquitetura estável </li></ul><ul><li>Determina...
As quatro Fases <ul><li>Fase de Construção </li></ul><ul><li>determina capacidades operacionais iniciais </li></ul><ul><li...
As quatro Fases <ul><li>Fase de transição </li></ul><ul><li>transforma versão  beta  em um sistema operacional </li></ul><...
Iterativo e incremental <ul><li>Uma ITERAÇÃO genérica é composta pelas 5 etapas: Requisitos, Análise, Projeto, Implementaç...
Iterativo e incremental requisitos análise projeto Implement. testes planejamento consolidação ITERAÇÃO
Iterativo e incremental Planejando as ITERAÇÕES Planejando as FASES <ul><li>tempos por fase </li></ul><ul><li>milestones <...
Riscos Possíveis riscos: Gerenciar uma lista de riscos: <ul><li>descrição </li></ul><ul><li>prioridade  (crítico, signifca...
Próximos SlideShares
Carregando em…5
×

Processo Unificado de Desenvolvimento de Software

3.794 visualizações

Publicada em

Publicada em: Tecnologia, Negócios
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
3.794
No SlideShare
0
A partir de incorporações
0
Número de incorporações
30
Ações
Compartilhamentos
0
Downloads
263
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Processo Unificado de Desenvolvimento de Software

  1. 1. Processo Unificado de Desenvolvimento de Software G. Booch, Ivar Jacobson, James Rumbaugh Rational Software Corporation UNIVERSIDADE FEDERAL DA PARAÍBA DEPARTAMENTO DE SISTEMAS E COMPUTAÇÃO © Ulrich Schiel
  2. 2. PRECURSORES Object Modeling Technique - OMT de J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy e W. Lorensen (TMO - Técnica de Modelagem de Objetos), 1991 Objectology - A Use-Case Driven Approach de I. Jacobson, M. Ericsson e A. Jacobson, 1992 Object Oriented Analysis and Design - OOA & OOD de G. Booch, 1994
  3. 3. CARACTERÍSTICAS <ul><li>baseado em componentes que realizam interfaces </li></ul><ul><li>usa UML </li></ul><ul><li>aspectos: * dirigido por Use-Cases * centrado em arquitetura * iterativo e incremental </li></ul><ul><li>os 4 Ps: pessoal, projeto, produto e processo </li></ul>
  4. 4. P4 = Pessoa, Projeto, Produto, Processo PESSOAS financiam, escolhem, desenvolvem, gerenciam, testam, usam e são beneficiadas por produtos PROJETOS sofrem alterações. Determinam os tipos de pessoas que irão trabalhar no projeto e os artefatos que serão usados Sistema-i Sistema-i+1 ciclo fase iteração
  5. 5. P4 = Pessoa, Projeto, Produto, Processo PRODUTO código fonte, código de máquina, subsistemas, classes, diagramas: interação, de estados e outros artefatos ARTEFATO é qualquer tipo de informação criada por uma pessoa (diagramas UML, textos, modelos de interfaces) PROCESSO define quem faz o que, quando e como PU é um processo. Considera fatores organizacionais , do domínio , ciclo de vida e técnicos
  6. 6. Modelos REQUISITOS - funcionais e não-funcionais descrevem o sistema a ser desenvolvido, sob um certo ponto-de-vista, e seu ambiente, ou seja, os atores ANÁLISE classes e responsabilidades PROJETO classes de projeto, subsistemas, interfaces IMPLEMENTAÇÃO código fonte (DLLs, JavaBeams, ActiveX) TESTE casos de teste (baseado nos use-cases ) DISTRIBUIÇÃO nós físicos e os componentes em cada nó
  7. 7. Dirigido a Use-Cases Um ator é uma pessoa ou outro sistema Cada use-case é um requisito funcional do sistema Modelo Use-Case =  use-cases = funcionalidade do sistema Os Use-Cases acompanham todo o processo de desenvolvimento: Especificação de Requisitos, Análise, Projeto, Implementação e Testes Cada use-case representa uma sequência de ações que produzem um resultado de utilidade para um ator
  8. 8. Dirigido a Use-Cases Porque USE-CASES?? <ul><li>Capturar os requisitos : o Diagrama Use-Case mostra quais atores usam quais use-cases </li></ul>Use-Cases Arquitetura do sistema dirige influi <ul><li>Dirigir o processo : para realizar os use-cases são definidos classificadores (classes, subsistemas, interfaces) e relacionamentos (colaborações) entre estes </li></ul><ul><li>Elaborar a arquitetura, determinar iterações, determinação dos manuais de usuário </li></ul>
  9. 9. Dirigido a Use-Cases Classe de fronteira Classe de controle Classe de entidades Modelo USE-CASE Modelo ANÁLISE Modelo PROJETO Classe Modelo IMPLEMENT <executável> <arquivo> <arquivo> relacionamento
  10. 10. Dirigido a Use-Cases <ul><li>Dirigir o processo : </li></ul>ANÁLISE : definir as CLASSES DE ANÁLISE para realizar um use-case (classes limite, classes de controle e classes de entidades) PROJETO : ENTRADA: modelo de análise, pacote de construção de interfaces, SGBD, sistemas existentes. SAIDA: classificadores (classes, subsistemas, interfaces), relacionamentos e colaborações IMPLEMENTAÇÃO :criação de programas executáveis e arquivos que realizam os use-cases TESTE : casos de teste e procedimentos de teste. Testar entradas, resultados e condições
  11. 11. Centrado na arquitetura <ul><li>DECISÕES SOBRE: </li></ul><ul><li>a organização do sistema como um todo </li></ul><ul><li>os elementos estruturais, interfaces e seu comportamento </li></ul><ul><li>composição de elementos estruturais e comportamentais em subsistemas </li></ul>A ARQUITETURA descreve as partes essenciais do sistema, importantes para todos desenvolvedores Menos de 10% das classes são relevantes para a arquitetura Descrição de REQUISITOS ADICIONAIS: segurança, distribuição, concorrência, plataformas, etc.
  12. 12. Centrado na arquitetura Use-Cases Plataforma de software Disponibilidade de blocos reusáveis Sistemas existentes Hardware existente Requisitos não-funcionais (performance, segurança) Arquitetura influem
  13. 13. Centrado na arquitetura PRODUTO Use-Case Arquitetura Sequência para o arquiteto: <ul><li>Criar uma visão preliminar da arquitetura </li></ul><ul><li>Analisar os use-cases chave (5-10%) e especificar um subsistema para cada um </li></ul><ul><li>Pela especificação dos subsistemas aparecem mais detalhes da arquitetura e novos use-cases </li></ul><ul><li>Repetir o passo acima, até terminar o sistema </li></ul>função forma
  14. 14. 4 FASES CONCEPÇÃO CONSTRUÇÃO ELABORAÇÃO TRANSIÇÃO
  15. 15. Iterativo e incremental Projetos grandes são divididos em mini-projetos Cada mini-projeto é uma iteração <ul><li>Um grupo de use-cases que estendem usabilidade </li></ul>Fatores de risco mais importantes MINI- PROJETO Cada iteração gera um incremento <ul><li>PORQUE ITERATIVO E INCREMENTAL </li></ul><ul><li>atenuar riscos </li></ul><ul><li>obter arquitetura robusta </li></ul><ul><li>facilitar alterações táticas ou contínuas </li></ul><ul><li>conseguir aprendizado mais cedo </li></ul>
  16. 16. Iterativo e incremental Fases
  17. 17. Iterativo e incremental Cada fase termina com um MARCO (milestone): INICIO : o que o sistema fará? Como poderia ser a arquitetura? Prazos e custos? Um CICLO é uma sequência das 4 fases. Um projeto pode necessitar de vários ciclos. <ul><li>identificar os riscos </li></ul><ul><li>fixar subconjunto chave -> arquitetura candidata </li></ul><ul><li>estimativas iniciais (custos, esforços, alocações e qualidade do produto) </li></ul><ul><li>iniciar caso gerencial ( business case ) </li></ul>
  18. 18. Iterativo e incremental ELABORAÇÃO : use-cases especificados e esqueleto da arquitetura definido CONSTRUÇÃO : software feito TRANSIÇÃO : beta-teste feito por poucos usuários. Treinamento, documentação <ul><li>identificar e reduzir riscos de construção </li></ul><ul><li>especificar maioria dos use-cases </li></ul><ul><li>fixar a arquitetura em proporções executáveis </li></ul><ul><li>preparar o plano de projeto (para a próxima fase) </li></ul><ul><li>estimar e justificar o orçamento </li></ul><ul><li>finalizar o business case </li></ul><ul><li>iterações garantindo viabilidade em forma executável -> incrementos </li></ul><ul><li>eliminar problemas e erros não identificados previamente </li></ul>
  19. 19. O P ROCESSO U NIFICADO
  20. 20. EXEMPLO Desenvolver um sistema de controle de vendedores ambulantes de um empresa. A empresa dividiu cada cidade em que atua em regiões. Cada região é controlada por um supervisor ao qual está subordinado um certo número de vendedores. A empresa possui diversos pontos distribuídos na cidade. Todo dia os vendedores passam pela empresa, de manhã, e registram, em um boletim de controle, a hora da partida, o roteiro de visitas planejado e o número de contratos de vendas que levaram. Ao final da tarde, cada vendedor passa por um pontos, e registra o resultado das atividades do dia, ou seja, os contratos de venda fechados. Até as 20 horas, todos vendedores devem ter registrados suas produções do dia. Cada ponto da empresa, processa a esta hora, um resumo das atividades registradas e o remete para a central da empresa. No outro dia o supervisor analisa os boletins recebidos e passa-os, com alguns comentários, ao controle geral de vendas da empresa. O supervisor, além de controlar a produção dos vendedores, registra o recebimento de novos vendedores e a liberação deles para o departamento pessoal que, por sua vez, controla a contratação, alocação, relocação e demissão de vendedores e supervisores.
  21. 21. Modelos Requisitos ARTEFATOS Análise Projeto Implementação Testes ARTÍFICES PASSOS e ATIVIDADES produz produzido-por composto-por
  22. 22. Obtenção dos Requisitos ARTEFATOS <ul><li>Modelo Use-Case </li></ul><ul><li>ator </li></ul><ul><li>Use-Case </li></ul><ul><li>descrição da arquitetura </li></ul>
  23. 23. Obtenção dos Requisitos ARTÍFICES <ul><li>Analista de sistemas </li></ul><ul><li>arquiteto </li></ul><ul><li>Especificador de Use-Case </li></ul><ul><li>projetista de interfaces </li></ul>
  24. 24. Obtenção dos Requisitos PASSOS <ul><li>listar potenciais requisitos </li></ul><ul><li>entender o contexto do sistema </li></ul><ul><li>capturar requisitos funcionais </li></ul><ul><li>capturar requisitos não-funcionais </li></ul>
  25. 25. Obtenção dos Requisitos - Passos <ul><li>listar potenciais requisitos </li></ul>Desenvolver uma lista de características obtidas de clientes, usuários, analistas e desenvolvedores <ul><li>CARACTERÍSTICA: </li></ul><ul><li>nome </li></ul><ul><li>breve descrição ou definição </li></ul><ul><li>conjunto de valores </li></ul><ul><ul><li>Estado (proposto, aprovado, incorporado, validado) </li></ul></ul><ul><ul><li>estimativa de custos </li></ul></ul><ul><ul><li>prioridade (crítica, importante ou secundária) </li></ul></ul><ul><ul><li>riscos (crítico, significante, ordinário) </li></ul></ul>
  26. 26. Obtenção dos Requisitos - Passos <ul><li>entender o contexto do sistema </li></ul><ul><li>criar um modelo do domínio </li></ul><ul><ul><li>objetos de negócio (pedidos, contas, contratos,..) </li></ul></ul><ul><ul><li>objetos do mundo real (veículos, máquinas, trajetos,..) </li></ul></ul><ul><ul><li>eventos básicos (chegada de um pedido, partida de um transporte, ..) </li></ul></ul><ul><li>usar diagramas UML, em particular diagramas de classe </li></ul>
  27. 27. Obtenção dos Requisitos - Passos <ul><li>capturar requisitos funcionais </li></ul>ARTÍFICE ARTEFATO Analista de Sistemas Especificador de Use-Cases Projetista de Interfaces Arquiteto <ul><li>Modelo use-case </li></ul><ul><li>atores </li></ul><ul><li>glossários </li></ul>Protótipos de interfaces Use-cases Arquitetura responsável
  28. 28. Obtenção dos Requisitos - Passos <ul><li>capturar requisitos funcionais </li></ul><ul><li>ATIVIDADES E SUBPASSOS </li></ul><ul><li>A1) encontrar os atores e use-cases </li></ul><ul><ul><li>encontrar os atores </li></ul></ul><ul><ul><li>encontrar e descrever cada use-case </li></ul></ul><ul><ul><li>descrever o Modelo Use-Case como um todo </li></ul></ul><ul><li>A2) Priorizar Use-Cases (visão arquitetural) </li></ul>
  29. 29. Obtenção dos Requisitos - Passos <ul><li>capturar requisitos funcionais </li></ul><ul><li>ATIVIDADES E SUBPASSOS </li></ul><ul><li>A3) Detalhar cada Use-Case </li></ul><ul><ul><li>estruturar a descrição do use-case (construir um diagrama de estados e analisar cada caminho) </li></ul></ul><ul><ul><li>formalizar a descrição do use-case (usar diagramas de estado, diagramas de atividade ou diagramas de interação) </li></ul></ul><ul><ul><li>descrever o Modelo Use-Case como um todo </li></ul></ul>
  30. 30. Obtenção dos Requisitos - Passos <ul><li>capturar requisitos funcionais </li></ul><ul><li>ATIVIDADES E SUBPASSOS </li></ul><ul><li>A4) Prototipar as interfaces com o usuário </li></ul><ul><ul><li>projeto lógico da interface do usuário </li></ul></ul><ul><ul><li>projeto físico da interface do usuário e protótipo </li></ul></ul>
  31. 31. Obtenção dos Requisitos PROJETO LÓGICO : para cada ator, ver todos use-cases nos quais está envolvido e especificar os elementos de interação (ícones, listas, campos, figuras, etc.) N.B. a mesma interface (formulário) pode aparecer em diversos use-cases para diversos atores! <ul><li>QUESTÕES para determinar os elementos de interação : </li></ul><ul><li>quais informações o ator fornece ao sistema? </li></ul><ul><li>quais informações o ator necessita do sistema? </li></ul><ul><li>com quais elementos de interação o ator trabalha? </li></ul><ul><li>quais ações o ator pode acionar e quais decisões tomar? </li></ul><ul><li>Quais classes de domínio ou entidades de negócio estão envolvidos com elementos de interação? </li></ul>
  32. 32. Obtenção dos Requisitos PROJETO FÍSICO : <ul><li>combinar elementos de interação para formar interfaces que atendam a atores </li></ul><ul><li>determinar elementos adicionais (folders, janelas, controles, etc.) </li></ul><ul><li>desenvolver um protótipo para cada interface </li></ul>
  33. 33. Obtenção dos Requisitos <ul><li>capturar requisitos funcionais </li></ul><ul><li>ATIVIDADES E SUBPASSOS </li></ul><ul><li>A5) Estruturar o modelo Use-Case </li></ul><ul><ul><li>identificar funcionalidades comuns (generalizações, <<estende>>) </li></ul></ul><ul><ul><li>identificar funcionalidades adicionais ou opcionais </li></ul></ul><ul><ul><li>identificar outros relacionamentos entre use-cases (<<inclui>>, inverso de <<estende>>) </li></ul></ul>
  34. 34. Obtenção dos Requisitos <ul><li>capturar requisitos não-funcionais </li></ul><ul><li>ATIVIDADES </li></ul><ul><li>usabilidade </li></ul><ul><ul><li>requisitos de interfaces metáfora, frequência de uso, .. </li></ul></ul><ul><ul><li>documentação </li></ul></ul><ul><li>confiabilidade </li></ul><ul><ul><li>tolerância a falhas. </li></ul></ul>
  35. 35. Obtenção dos Requisitos <ul><li>capturar requisitos não-funcionais </li></ul><ul><li>ATIVIDADES </li></ul><ul><li>performance </li></ul><ul><ul><li>tempos de resposta </li></ul></ul><ul><ul><li>volumes de transações </li></ul></ul><ul><li>requisitos físicos </li></ul><ul><ul><li>equipamentos, material, espaços, configurações de rede, </li></ul></ul><ul><ul><li>software </li></ul></ul>
  36. 36. Análise
  37. 37. Análise Os requisitos externos são transformados em um modelo interno preciso e completo para desenvolver o projeto do sistema Deve ser preciso e inambíguo Pode conter redundâncias, inconsistências, etc. Usado para o desenvolvedor entender o sistema Usado para o contrato com o cliente Descreve como realizar a funcionalidade Captura a funcionalidade do sistema Estruturado por classes Estruturado por use-cases Visão interna do sistema Visão externa do sistema Linguagem do desenvolvedor linguagem do usuário MODELO DA ANÁLISE MODELO USE-CASE
  38. 38. Análise - artefatos 2. CLASSE DE ANÁLISE Classe de fronteira Classe de controle Classe de entidades EXEMPLO Interface de registro processar resumo do dia Boletim de controle 1. MODELO DA ANÁLISE
  39. 39. Análise - artefatos 3. REALIZAÇÃO DE UM USE-CASE <ul><li>Diagramas de classe </li></ul><ul><li>Diagramas de colaboração </li></ul>Resultado do dia Processar resumo boletim de controle VENDEDOR partida Resumo do dia SUPERVISOR mostra resumos 1.registra partida 3. registra retorno 2. abre boletim 3. completa boletim 5. dados boletim 6. Registra resumo 8. analisa resumo 9. comentários 7. mostra resumo 10. resumo comentado RELOGIO 4. 8 horas
  40. 40. Análise - artefatos 3. REALIZAÇÃO DE UM USE-CASE (cont.) <ul><li>requisitos especiais </li></ul><ul><li>fluxo de eventos </li></ul>Descrição textual de requisitos não-funcionais Descrição textual do diagrama de colaboração 4. PACOTES DE ANÁLISE PACOTE DE SERVIÇOS Devem ter coesão e fraco acoplamento <ul><li>Candidatos a subsistemas do projeto </li></ul>é um conjunto de ações coerentes, indivisíveis para uso em vários use-cases 5. DESCRIÇÃO DA ARQUITETURA
  41. 41. Análise <ul><li>arquiteto </li></ul><ul><li>Especificador de Use-Case </li></ul><ul><li>Especificador de componentes </li></ul>ARTÍFICES <ul><li>responsável pela integridade global do modelo de análise (corretude, consistência e legibilidade), tanto pela sua funcionalidade quanto pela arquitetura </li></ul><ul><li>responsável que a realização de um use-case corresponde a sua especificação </li></ul><ul><li>responsável pelas classe de análise e pelos pacotes </li></ul>
  42. 42. Análise PASSOS <ul><li>Análise arquitetural </li></ul><ul><li>Análise de cada Use-Case </li></ul><ul><li>Análise de cada classe </li></ul><ul><li>Análise de cada pacote </li></ul>
  43. 43. Análise - passos <ul><li>Análise arquitetural </li></ul>Análise arquitetural MODELO USE-CASE REQUISITOS ADICIONAIS MODELO DO DOMÍNIO DESCRIÇÃO ARQUITETURA (mod. Requisitos) ARQUITETO DESCRIÇÃO ARQUITETURA (mod. Análise) CLASSE DE ANÁLISE (esboço) PACOTE ANÁLISE (esboço)
  44. 44. Análise - passos <ul><li>Análise arquitetural </li></ul><ul><li>ATIVIDADES E SUBPASSOS </li></ul><ul><li>A1) Identificar pacotes de análise </li></ul><ul><ul><li>Encontrar pacotes coesos e fracamente acoplados </li></ul></ul><ul><ul><li>Identificar funcionalidades comuns entre pacotes (pacotes genéricos) </li></ul></ul><ul><ul><li>Identificar pacotes de serviço (serviços opcionais, classes relacionadas funcionalmente) </li></ul></ul><ul><ul><li>Dependências entre pacotes </li></ul></ul>
  45. 45. Análise - passos <ul><li>Análise arquitetural (cont.) </li></ul>A2) Identificar classes de entidades óbvias Obtidas a partir das classe do domínio <ul><li>A3) Identificar requisitos especiais comuns </li></ul><ul><ul><li>Persistência </li></ul></ul><ul><ul><li>Distribuição e concorrência </li></ul></ul><ul><ul><li>aspectos de segurança </li></ul></ul><ul><ul><li>tolerância a falhas </li></ul></ul><ul><ul><li>gerência de transações </li></ul></ul>
  46. 46. Análise - passos <ul><li>Análise de cada Use-Case </li></ul><ul><li>encontrar as classe de análise para realizar o use-case </li></ul><ul><li>distribuir o comportamento do use-case entre as classes </li></ul><ul><li>identificar requisitos especiais </li></ul>Análise de um Use-Case MODELO USE-CASE REQUISITOS ADICIONAIS MODELO DO DOMÍNIO DESCRIÇÃO ARQUITETURA (mod Análise) ESPECIFICADOR DE USE-CASES CLASSE DE ANÁLISE (esboço) REALIZAÇÃO DE UM USE-CASE (diagramas de classes e de colaboração)
  47. 47. Análise - passos <ul><li>Análise de cada Use-Case </li></ul><ul><li>A1) Identificar classes de análise </li></ul><ul><ul><li>encontrar classes de entidades para armazenar as informações do use-case </li></ul></ul><ul><ul><li>para cada ator humano, determinar uma classe de fronteira central (representa a janela principal) </li></ul></ul><ul><ul><li>determinar as classe de fronteira que interagem com as classes de entidade </li></ul></ul><ul><ul><li>determinar, pelo menos, uma classe de controle que coordena o use-case </li></ul></ul>CONSTRUIR UM DIAGRAMA DE CLASSES
  48. 48. Análise - passos <ul><li>Análise de cada Use-Case (cont.) </li></ul><ul><li>A2) Descrever interações entre objetos </li></ul><ul><ul><li>construir um diagrama de colaboração </li></ul></ul><ul><ul><li>toda classe de análise deve participar de algum diagrama de colaboração </li></ul></ul><ul><ul><li>dar maior ênfase às conexões e condições do que à sequência </li></ul></ul><ul><ul><li>às conexões de mensagens podem corresponder associações do diagrama de objetos ou não </li></ul></ul><ul><ul><li>considerar as relações entre use-cases no diagrama </li></ul></ul><ul><li>A3) Determinar requisitos especiais </li></ul>
  49. 49. Análise - passos Resultado do dia Processar resumo boletim de controle VENDEDOR partida Resumo do dia mostra resumos 1.registra partida 3. registra retorno 2. abre boletim 4. completa boletim 6 . dados boletim 7 . Registra resumo 9 . analisa resumo 10 . comentários 8 . mostra resumo 11 . resumo comentado 5 . 8 horas RELÓGIO SUPERVISOR <ul><li>Análise de cada Use-Case (cont.) </li></ul>
  50. 50. Análise - passos <ul><li>Análise de cada classe </li></ul><ul><li>identificar as responsabilidades de cada classe, baseado em sua função na realização de use-cases </li></ul><ul><li>definir os atributos e relacionamentos </li></ul><ul><li>capturar requisitos especiais para cada classe </li></ul>Análise de uma classe REALIZAÇÃO DE UM USE-CASE (diagramas de classes e de colaboração) ESPECIFICADOR DE COMPONENTES CLASSE DE ANÁLISE (completa) CLASSE DE ANÁLISE (esboço)
  51. 51. Análise - passos <ul><li>Análise de cada classe </li></ul><ul><li>A3) Identificar associações e agregações </li></ul><ul><li>A2) Definir os atributos </li></ul><ul><ul><li>tipos de atributos são conceituais </li></ul></ul><ul><ul><li>classes com muitos atributos podem ser divididas </li></ul></ul><ul><ul><li>atributos de classes de fronteira são campos em interfaces </li></ul></ul><ul><ul><li>classes de controle geralmente não tem atributos </li></ul></ul><ul><li>A1) Identificar responsabilidades </li></ul><ul><ul><li>Determinar os papéis de cada classe nos diferentes use-cases </li></ul></ul><ul><li>A4) Identificar generalizações </li></ul><ul><li>A5) Determinar requisitos especiais </li></ul>
  52. 52. Análise - passos <ul><li>Análise de cada pacote </li></ul><ul><ul><li>Rever as dependências entre pacotes de acordo com associações estáticas ou dinâmicas entre as classes, criadas nos passos anteriores </li></ul></ul><ul><ul><li>Garantir que cada pacote preenche sua função </li></ul></ul><ul><ul><li>Rever as questões de acoplamento fraco e coesão </li></ul></ul>
  53. 53. Projeto <ul><li>adquirir uma compreensão de aspectos de requisitos não funcionais e restrições sobre linguagens de programação, sistemas operacionais, SGBDs, aspectos de distribuição , etc. . </li></ul><ul><li>Criar informações suficientes para a implementação, descre- vendo subsistemas, interfaces e classes. </li></ul><ul><li>Estar apto a dividir a tarefa de implementação em equipes </li></ul><ul><li>Determinar mais cedo as interfaces entre os subsistemas </li></ul><ul><li>Criar um modelo que possibilite uma implementação que preencha as estruturas definidas sem altera-las </li></ul>OBJETIVOS
  54. 54. Projeto
  55. 55. Projeto - artefatos 1. MODELO DE PROJETO É uma hierarquia de subsistemas contendo classe de projeto , projetos de use-cases e interfaces 2. CLASSE DE PROJETO <ul><li>na linguagem de programação da implementação </li></ul><ul><li>visibilidade dos atributos (ex. publico, protegido, privado) </li></ul><ul><li>generalizações  herança; </li></ul><ul><li>associações e agregações  atributos </li></ul><ul><li>métodos em pseudo-código </li></ul>
  56. 56. Projeto - artefatos 3. REALIZAÇÃO DO USE-CASE <ul><li>Diagrama de classes </li></ul><ul><li>Diagrama de interações (diagramas de sequência) </li></ul><ul><li>Fluxo de eventos (textual) </li></ul><ul><li>Requisitos de implementação </li></ul>
  57. 57. Projeto - artefatos 7. MODELO DE DISTRIBUIÇÃO (Diagrama de nós e conexões) 5. INTERFACE ( separa funcionalidade de implementação) 6. ARQUITETURA (VISÃO DO PROJETO) (1. Subsistemas, interfaces e dependências 2. Classes chave, classes ativas 3. Realização de use-cases centrais ao sistema 4. SUBSISTEMA DE PROJETO (pacotes de análise, componentes, produtos de software, sistemas existentes) - SUBSISTEMAS DE SERVIÇO 8. ARQUITETURA (VISÃO DO MODELO DE DISTRIBUIÇÃO)
  58. 58. Projeto - artífices <ul><li>Arquiteto </li></ul><ul><li>Especificador de use-cases </li></ul><ul><li>Especificador de componentes </li></ul>MODELO DO PROJETO ARQUITETURA MODELO DE DISTRIBUIÇÃO REALIZAÇÃO DE USE CASE CLASSE DE PROJETO SUBSISTEMA INTERFACE
  59. 59. Projeto - passos Projeto de um use-case Projeto de uma classe Projeto de um subsistema Projeto da arquitetura ARQUITETO ESPECIFICADOR DE COMPONENTES ESPECIFICADOR DE USE-CASES
  60. 60. Projeto - passos <ul><li>Projeto da arquitetura </li></ul><ul><li>A1) Identificar nós e configurações de rede </li></ul><ul><ul><li>determinar os nós envolvidos e suas características </li></ul></ul><ul><ul><li>determinar os tipos de conexões entre os nós </li></ul></ul><ul><ul><li>verificar necessidades de processamentos redundantes, backups , etc. </li></ul></ul>
  61. 61. Projeto - passos <ul><li>Projeto da arquitetura (cont.) </li></ul><ul><li>A2) Identificar subsistemas e suas interfaces </li></ul><ul><ul><li>subsistemas da aplicação </li></ul></ul><ul><ul><li>identificar middleware ( SO, SGBD, software de comunicação, pacotes GUI, distribuição, etc.) </li></ul></ul><ul><ul><li>definir dependências entre os subsistemas </li></ul></ul><ul><ul><li>identificar as interfaces entre os subsistemas </li></ul></ul>Pacote (análise) Subsistema novo Software existente Não serve como subsistema É integrado com sistemas existentes
  62. 62. Projeto - passos <ul><li>Projeto da arquitetura (cont.) </li></ul><ul><li>A3) Identificar classes de projeto significativas </li></ul><ul><ul><li>a partir das classes de análise </li></ul></ul><ul><ul><li>classes ativas ( requisitos de concorrência, performance, inicialização, distribuição, prevenção de deadlocks) </li></ul></ul><ul><li>A4) outros requisitos de projeto ( persistência, transparência de distribuição, segurança, recuperação de erros, gerência de transações) </li></ul>
  63. 63. Projeto - passos <ul><li>Projeto de um use-case </li></ul><ul><li>A1) Identificar classes de projeto participantes </li></ul><ul><ul><li>estudar as classes de análise </li></ul></ul><ul><ul><li>identificar classes que realizam os requisitos especiais da análise </li></ul></ul><ul><ul><li>definir as classes de projeto e passar para o projetista de componentes </li></ul></ul><ul><li>OBJETIVO: </li></ul><ul><li>identificar classes de projeto </li></ul><ul><li>distribuir o comportamento entre os objetos </li></ul><ul><li>definir requisitos das operações </li></ul><ul><li>requisitos de implementação do use-case </li></ul>
  64. 64. Projeto - passos <ul><li>Projeto de um use-case (cont.) </li></ul><ul><li>A2) Descrever a interação entre objetos </li></ul><ul><ul><li>o use-case é acionado por uma mensagem de um ator a um objeto </li></ul></ul><ul><ul><li>traçar um ou vários diagramas de sequência </li></ul></ul><ul><ul><li>utilize nomes e textos (fluxo de eventos) para descrever as sequências </li></ul></ul><ul><ul><li>considere as associações entre use-cases no diagrama de sequência </li></ul></ul>
  65. 65. Projeto - passos <ul><li>Projeto de um use-case (cont.) </li></ul><ul><li>A3) Identificar subsistemas e interfaces </li></ul><ul><ul><li>identificar os subsistemas obtidos a partir de pacotes deste use-case </li></ul></ul><ul><ul><li>verifique se há classes de projeto especiais e seus subsistemas </li></ul></ul><ul><li>A4) Descrever a interação entre subsistemas </li></ul><ul><ul><li>a partir dos caminhos no diagrama se sequência determinar a interação </li></ul></ul><ul><ul><li>determinar qual interfaces é utilizada por qual mensagem </li></ul></ul>
  66. 66. Projeto - passos <ul><li>Projeto de uma classe </li></ul><ul><li>A1) Definir uma classe de projeto </li></ul><ul><ul><li>a partir de classes de fronteira : depende da linguagem </li></ul></ul><ul><ul><li>classes de entidades persistentes podem produzir tabelas relacionais </li></ul></ul><ul><ul><li>classes de controle podem gerar várias classes de projeto (distribuição) ou serem encapsuladas em classes de entidades </li></ul></ul>ASPECTOS: <ul><li>atributos </li></ul><ul><li>operações e sua realização </li></ul><ul><li>relacionamentos </li></ul><ul><li>estados </li></ul><ul><li>dependências </li></ul><ul><li>interfaces </li></ul><ul><li>requisitos de implementação </li></ul>
  67. 67. Projeto - passos <ul><li>Projeto de uma classe (cont.) </li></ul><ul><li>A2) Definir operações </li></ul><ul><ul><li>realizar as responsabilidades da classe </li></ul></ul><ul><ul><li>requisitos especiais (e.g. acesso ao banco de dados) </li></ul></ul><ul><ul><li>atender às necessidades das interfaces da classe </li></ul></ul><ul><li>A3) Definir atributos </li></ul><ul><ul><li>considerar os atributos da análise </li></ul></ul><ul><ul><li>os tipos dos atributos são determinados pela linguagem de programação </li></ul></ul><ul><ul><li>valores de atributos usados por vários objetos devem ser transformados em objetos </li></ul></ul>
  68. 68. Projeto - passos <ul><li>Projeto de uma classe (cont.) </li></ul><ul><li>A4) Identificar associações e agregações </li></ul><ul><ul><li>dependendo da linguagem, transformá-los em relacionamentos </li></ul></ul><ul><ul><li>tentar transformar cardinalidades, papéis, etc. em atributos ou em novas classes para realizar a associação </li></ul></ul><ul><ul><li>analise a navegabilidade pelas associações </li></ul></ul>A5) Identificar generalizações <ul><li>A6) Descrever métodos </li></ul><ul><ul><li>realização de operações por pseudo-código, diagramas de atividades, linguagem natural,.. </li></ul></ul><ul><li>A7) Descrever estados </li></ul><ul><ul><li>diagrama de estados </li></ul></ul>
  69. 69. Projeto - passos <ul><li>Projeto de um subsistema </li></ul><ul><li>A1) Rever as dependências entre subsistemas </li></ul><ul><li>A2) Rever as interfaces </li></ul>A3) Rever o conteúdo
  70. 70. Implementação - artefatos 1. MODELO DA IMPLEMENTAÇÃO 2. COMPONENTE 3. SUBSISTEMA DE IMPLEMENTAÇÃO 4. INTERFACE 5. ARQUITETURA (visão da implementação) 6. PLANO DE INTEGRAÇÃO
  71. 71. Implementação - artefatos 1. MODELO DA IMPLEMENTAÇÃO É uma hierarquia de subsistemas de implementação contendo componentes e interfaces 2. COMPONENTE <ul><li><<executable>> (programa executável) </li></ul><ul><li><<file>> (arquivo contendo código fonte ou dados) </li></ul><ul><li><<library>> (biblioteca estática ou dinâmica) </li></ul><ul><li><<table>> (tabela do banco de dados) </li></ul><ul><li><<document>> (um documento) </li></ul>É UM PACOTE CONTENDO ELEMENTOS DO PROJETO Estereótipos:
  72. 72. Implementação - artefatos 2. COMPONENTE - exemplos <<executable>> ProcessaBoletim.java <<table>> Resumo BOLETIM __________ __________ RESUMO __________ __________ <<table>> Contrato realiza realiza gera gera
  73. 73. Implementação - artefatos 3. SUBSISTEMAS DE IMPLEMENTAÇÃO <ul><li>um package em Java </li></ul><ul><li>um project em Visual Basic </li></ul><ul><li>um diretório de C++ </li></ul>CORRESPONDÊNCIA 1-1 COM SUBSISTEMAS DE PROJETO 4. INTERFACES Implementam as interfaces do projeto
  74. 74. Implementação - artefatos 5. ARQUITETURA (visão da implementação) 6. PLANO DE INTEGRAÇÃO <ul><li>Decomposição em subsistemas, compostos de interfaces e componentes </li></ul><ul><li>Componentes chave </li></ul><ul><li>Primeira versão executável </li></ul><ul><li>testes localizados de integração para facilitar a detecção de erros </li></ul><ul><li>versão final </li></ul>
  75. 75. Implementação - artífices <ul><li>Arquiteto </li></ul><ul><li>Integrador do sistema </li></ul><ul><li>Engenheiro de componentes </li></ul>MODELO DA IMPLEMENTAÇÃO DESCRIÇÃO DA ARQUITETURA MODELO DE DISTRIBUIÇÃO PLANO DE INTEGRAÇÃO COMPONENTE SUBSISTEMA DE IMPLEMENTAÇÃO INTERFACE
  76. 76. Implementação - artífices
  77. 77. Implementação PASSOS <ul><li>Implementação arquitetural </li></ul><ul><li>Integrar sistemas </li></ul><ul><li>Implementar subsistema </li></ul><ul><li>Testar componentes </li></ul><ul><li>Implementar uma classe </li></ul>
  78. 78. Projeto - passos Integrar sistemas Implementar uma classe Implementar um subsistema Implementação arquitetural ARQUITETO ENGENHEIRO DE COMPONENTES INTEGRADOR DE SISTEMAS Teste de unidade
  79. 79. Implementação - passos <ul><li>Implementação arquitetural </li></ul><ul><li>identificar componentes significativos </li></ul><ul><li>Integrar sistemas </li></ul><ul><li>determinar sequência de construção </li></ul><ul><li>integrar construções (compilar e linkar novos componentes) </li></ul>
  80. 80. Implementação - passos <ul><li>Implementar subsistema </li></ul><ul><li>garantir conteúdo do subsistema </li></ul><ul><li>Implementar uma classe </li></ul><ul><li>implementar métodos </li></ul><ul><li>determinar operações/métodos auxiliares </li></ul>
  81. 81. Teste OBJETIVOS <ul><li>Planejar os testes em cada iteração, tanto os testes de integração quanto os testes de sistema </li></ul><ul><li>preparar casos de teste, criar procedimentos de teste e procedimentos executáveis </li></ul><ul><li>Realizar os testes e analisar os resultados </li></ul>
  82. 82. Teste - artefatos 1. MODELO DE TESTE <ul><li>Planejar os testes em cada iteração, tanto os os testes de integração quanto os testes de sistema </li></ul><ul><li>preparar casos de teste, criar procedimentos de teste e procedimentos executáveis </li></ul><ul><li>Realizar os testes e analisar os resultados </li></ul>2. CASO DE TESTE
  83. 83. Fases X Etapas Fases
  84. 84. As quatro Fases <ul><li>Fase de Concepção </li></ul><ul><li>estabelece o business case (prioridade de negócio) </li></ul><ul><li>Delimitar o escopo do sistema </li></ul><ul><li>Determinar arquitetura candidata (elementos novos, arriscados) </li></ul><ul><li>Identificar riscos críticos </li></ul><ul><li>Identificar potenciais usuários ou clientes do sistema </li></ul>Passos
  85. 85. As quatro Fases <ul><li>Fase de Elaboração </li></ul><ul><li>determina uma arquitetura estável </li></ul><ul><li>Determinar linha base da arquitetura cobrindo funcionalidades significantes </li></ul><ul><li>Identificar riscos críticos que podem derrubar planos, orçamentos, e prazos </li></ul><ul><li>Determinar níveis de qualidade (confiabilidade, tempos de resposta) </li></ul><ul><li>Definir use-cases que cobrem ca. de 80% da funcionalidade do sistema </li></ul><ul><li>Determinar limites de pessoal, custos, prazos. </li></ul>Passos
  86. 86. As quatro Fases <ul><li>Fase de Construção </li></ul><ul><li>determina capacidades operacionais iniciais </li></ul><ul><li>Estender o modelo de use-cases para toda a aplicação </li></ul><ul><li>Finalizar a análise, projeto, implementação e testes </li></ul><ul><li>Checar integridade da arquitetura (com possíveis alterações) </li></ul><ul><li>Monitorar ricos críticos </li></ul>Passos
  87. 87. As quatro Fases <ul><li>Fase de transição </li></ul><ul><li>transforma versão beta em um sistema operacional </li></ul><ul><li>Preparar atividades de transição </li></ul><ul><li>Avisar clientes sobre mudanças no ambiente (hardware, software, distribuição, ..) </li></ul><ul><li>Preparar documentação final </li></ul><ul><li>Carregar o novo sistema </li></ul><ul><li>Corrigir possíveis defeitos detectados no beta-teste </li></ul>Passos
  88. 88. Iterativo e incremental <ul><li>Uma ITERAÇÃO genérica é composta pelas 5 etapas: Requisitos, Análise, Projeto, Implementação e Testes </li></ul>Após cada iteração ou cada fase: <ul><li>planejar a próxima iteração à luz da experiência anterior </li></ul><ul><li>modificar o processo, adaptar ferramentas, treinamento, etc. </li></ul>
  89. 89. Iterativo e incremental requisitos análise projeto Implement. testes planejamento consolidação ITERAÇÃO
  90. 90. Iterativo e incremental Planejando as ITERAÇÕES Planejando as FASES <ul><li>tempos por fase </li></ul><ul><li>milestones </li></ul><ul><li>iterações por fase </li></ul><ul><li>plano do projeto </li></ul><ul><li>cronograma </li></ul><ul><li>conteúdo: - quais use-cases serão realizados - iterações anteriores e posteriores </li></ul>
  91. 91. Riscos Possíveis riscos: Gerenciar uma lista de riscos: <ul><li>descrição </li></ul><ul><li>prioridade (crítico, signifcante, rotineiro) </li></ul><ul><li>impacto </li></ul><ul><li>responsabilidades </li></ul><ul><li>contingência (o que fazer?) </li></ul><ul><li>relacionados a um produto </li></ul><ul><li>não conseguir a arquitetura </li></ul><ul><li>não realizar os requisitos </li></ul>

×