SlideShare uma empresa Scribd logo
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
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
CARACTERÍSTICAS baseado em  componentes  que realizam  interfaces usa  UML aspectos: * dirigido por  Use-Cases *  centrado em  arquitetura * iterativo  e  incremental os 4 Ps: pessoal, projeto, produto  e  processo
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
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
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ó
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
Dirigido a  Use-Cases Porque USE-CASES?? Capturar os requisitos : o  Diagrama Use-Case   mostra  quais  atores  usam quais  use-cases Use-Cases Arquitetura do sistema dirige influi Dirigir o processo : para realizar os  use-cases  são definidos  classificadores  (classes, subsistemas, interfaces) e relacionamentos (colaborações) entre estes Elaborar a arquitetura, determinar iterações, determinação dos manuais de usuário
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
Dirigido a  Use-Cases Dirigir o processo : 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
Centrado  na arquitetura DECISÕES SOBRE: a organização do sistema como um todo os elementos estruturais, interfaces e seu comportamento composição de elementos estruturais e comportamentais   em subsistemas  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.
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
Centrado na arquitetura PRODUTO Use-Case Arquitetura Sequência para o  arquiteto: Criar uma visão preliminar da arquitetura Analisar os  use-cases  chave  (5-10%) e especificar um  subsistema para cada um Pela especificação dos subsistemas aparecem mais detalhes da    arquitetura e novos  use-cases Repetir o passo acima, até terminar o sistema função forma
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 Um grupo de  use-cases  que estendem usabilidade Fatores de risco mais  importantes MINI- PROJETO Cada iteração gera um  incremento PORQUE ITERATIVO E INCREMENTAL atenuar riscos obter arquitetura robusta facilitar alterações táticas ou contínuas conseguir aprendizado mais cedo
Iterativo e incremental Fases
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. identificar os  riscos fixar subconjunto chave -> arquitetura candidata estimativas iniciais (custos, esforços, alocações e qualidade  do produto) iniciar caso gerencial ( business case )
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 identificar e reduzir  riscos  de construção especificar maioria dos  use-cases fixar a arquitetura em proporções executáveis preparar o  plano de projeto  (para a próxima fase) estimar e justificar o orçamento finalizar o  business case iterações garantindo viabilidade em forma executável ->  incrementos eliminar problemas e erros não identificados previamente
O  P ROCESSO  U NIFICADO
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.
Modelos Requisitos ARTEFATOS Análise Projeto Implementação Testes ARTÍFICES PASSOS e  ATIVIDADES produz produzido-por composto-por
Obtenção dos Requisitos ARTEFATOS Modelo  Use-Case   ator  Use-Case   descrição da arquitetura
Obtenção dos Requisitos ARTÍFICES Analista de sistemas arquiteto  Especificador de  Use-Case   projetista de interfaces
Obtenção dos Requisitos PASSOS listar potenciais requisitos  entender o contexto do sistema  capturar requisitos funcionais  capturar requisitos não-funcionais
Obtenção dos Requisitos - Passos listar potenciais requisitos  Desenvolver uma  lista de características  obtidas de clientes, usuários, analistas e desenvolvedores CARACTERÍSTICA: nome breve descrição ou definição conjunto de valores Estado (proposto, aprovado, incorporado, validado) estimativa de custos prioridade (crítica, importante ou secundária) riscos (crítico, significante, ordinário)
Obtenção dos Requisitos - Passos entender o contexto do sistema  criar um  modelo do domínio objetos de negócio (pedidos, contas, contratos,..) objetos do mundo real (veículos, máquinas, trajetos,..) eventos básicos (chegada de um pedido, partida de um    transporte, ..) usar diagramas UML, em particular diagramas de classe
Obtenção dos Requisitos - Passos capturar requisitos funcionais  ARTÍFICE ARTEFATO Analista de Sistemas Especificador de  Use-Cases Projetista de Interfaces Arquiteto Modelo  use-case atores glossários Protótipos de interfaces Use-cases Arquitetura responsável
Obtenção dos Requisitos - Passos capturar requisitos funcionais  ATIVIDADES E SUBPASSOS A1) encontrar os atores e  use-cases encontrar os atores encontrar e descrever cada  use-case descrever o Modelo  Use-Case  como um todo A2) Priorizar  Use-Cases  (visão arquitetural)
Obtenção dos Requisitos - Passos capturar requisitos funcionais  ATIVIDADES E SUBPASSOS A3) Detalhar cada  Use-Case estruturar a descrição do  use-case (construir um diagrama de estados e analisar cada caminho)  formalizar a descrição do  use-case (usar diagramas de estado, diagramas de atividade ou diagramas  de interação)  descrever o Modelo  Use-Case  como um todo
Obtenção dos Requisitos - Passos capturar requisitos funcionais  ATIVIDADES E SUBPASSOS A4) Prototipar as interfaces com o usuário projeto lógico da interface do usuário projeto físico da interface do usuário e protótipo
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! QUESTÕES para determinar os elementos de interação : quais informações o ator fornece ao sistema? quais informações o ator necessita do sistema? com quais elementos de interação o ator trabalha? quais ações o ator pode acionar e quais decisões tomar? Quais classes de domínio ou entidades de negócio estão envolvidos   com elementos de interação?
Obtenção dos Requisitos PROJETO FÍSICO : combinar elementos de interação para formar interfaces que atendam a atores determinar elementos adicionais (folders, janelas, controles, etc.) desenvolver um protótipo para cada interface
Obtenção dos Requisitos capturar requisitos funcionais  ATIVIDADES E SUBPASSOS A5) Estruturar o modelo  Use-Case identificar funcionalidades comuns (generalizações,  <<estende>>) identificar funcionalidades adicionais ou opcionais identificar outros relacionamentos entre  use-cases   (<<inclui>>, inverso de <<estende>>)
Obtenção dos Requisitos capturar requisitos não-funcionais  ATIVIDADES usabilidade requisitos de interfaces   metáfora, frequência de uso, .. documentação confiabilidade tolerância a falhas.
Obtenção dos Requisitos capturar requisitos não-funcionais  ATIVIDADES performance tempos de resposta volumes de transações requisitos físicos equipamentos, material, espaços, configurações de rede, software
Análise
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
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
Análise - artefatos 3. REALIZAÇÃO DE UM  USE-CASE Diagramas de classe Diagramas de colaboração 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
Análise - artefatos 3. REALIZAÇÃO DE UM  USE-CASE  (cont.) requisitos especiais fluxo de eventos 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 Candidatos a subsistemas do projeto é um conjunto de ações coerentes, indivisíveis para uso em vários  use-cases 5. DESCRIÇÃO DA ARQUITETURA
Análise  arquiteto  Especificador de  Use-Case   Especificador de componentes  ARTÍFICES responsável pela integridade global do modelo de análise   (corretude, consistência e legibilidade),    tanto pela sua funcionalidade quanto pela arquitetura responsável que a realização de um  use-case  corresponde   a sua especificação responsável pelas classe de análise e pelos pacotes
Análise PASSOS Análise arquitetural  Análise de cada  Use-Case   Análise de cada classe  Análise de cada pacote
Análise - passos Análise arquitetural  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)
Análise - passos Análise arquitetural  ATIVIDADES E SUBPASSOS A1) Identificar pacotes de análise  Encontrar  pacotes coesos e fracamente acoplados Identificar funcionalidades comuns entre pacotes   (pacotes genéricos) Identificar pacotes de serviço   (serviços opcionais, classes relacionadas funcionalmente) Dependências entre pacotes
Análise - passos Análise arquitetural (cont.)  A2) Identificar classes de entidades óbvias   Obtidas a partir das classe do domínio A3) Identificar requisitos especiais comuns Persistência Distribuição e concorrência aspectos de segurança tolerância a falhas gerência de transações
Análise - passos Análise de cada  Use-Case   encontrar as classe de análise para realizar o  use-case distribuir o comportamento do  use-case  entre as classes identificar requisitos especiais 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)
Análise - passos Análise de cada  Use-Case   A1) Identificar classes de análise  encontrar classes de entidades para armazenar as informações    do  use-case para cada ator humano, determinar uma classe de fronteira    central (representa a janela principal) determinar as classe de fronteira que interagem com as classes    de entidade determinar, pelo menos, uma classe de controle que coordena o    use-case CONSTRUIR UM DIAGRAMA DE CLASSES
Análise - passos Análise de cada  Use-Case  (cont.)  A2) Descrever interações entre objetos construir um  diagrama de colaboração toda classe de análise deve participar de algum diagrama de    colaboração dar maior ênfase às conexões e condições do que à sequência às conexões de mensagens podem corresponder associações do   diagrama de objetos ou  não considerar as relações entre  use-cases  no diagrama A3) Determinar requisitos especiais
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 Análise de cada  Use-Case  (cont.)
Análise - passos Análise de cada classe  identificar as responsabilidades de cada classe, baseado em sua função    na realização de  use-cases definir os atributos e relacionamentos capturar requisitos especiais para cada classe 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)
Análise - passos Análise de cada classe  A3) Identificar associações e agregações A2) Definir os atributos tipos de atributos são conceituais classes com muitos atributos podem ser divididas atributos de classes de fronteira são campos em interfaces classes de controle geralmente não tem atributos A1) Identificar responsabilidades  Determinar os papéis de cada classe nos diferentes  use-cases A4) Identificar generalizações A5) Determinar requisitos especiais
Análise - passos Análise de cada pacote  Rever as dependências entre pacotes de acordo com associações   estáticas ou dinâmicas entre as classes, criadas nos passos    anteriores Garantir que cada pacote preenche sua função Rever as questões de  acoplamento fraco  e  coesão
Projeto  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. . Criar informações suficientes para a implementação, descre-   vendo  subsistemas, interfaces e classes. Estar apto a dividir a tarefa de implementação  em equipes Determinar mais cedo as interfaces entre os subsistemas Criar um modelo que possibilite uma implementação   que preencha as estruturas definidas sem altera-las  OBJETIVOS
Projeto
Projeto - artefatos 1. MODELO DE  PROJETO É uma hierarquia de  subsistemas  contendo   classe de projeto ,  projetos de  use-cases  e  interfaces 2. CLASSE DE  PROJETO na linguagem de programação da implementação visibilidade dos atributos  (ex. publico, protegido, privado) generalizações    herança;  associações e agregações    atributos métodos em pseudo-código
Projeto - artefatos 3. REALIZAÇÃO DO  USE-CASE Diagrama de classes Diagrama de interações (diagramas de sequência) Fluxo de eventos (textual) Requisitos de implementação
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)
Projeto - artífices Arquiteto  Especificador de  use-cases   Especificador de componentes  MODELO DO PROJETO ARQUITETURA MODELO DE DISTRIBUIÇÃO REALIZAÇÃO DE  USE CASE CLASSE DE  PROJETO SUBSISTEMA INTERFACE
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
Projeto - passos Projeto da arquitetura A1) Identificar nós e configurações de rede  determinar os nós envolvidos e suas características determinar os tipos de conexões entre os nós verificar necessidades de processamentos redundantes,    backups , etc.
Projeto - passos Projeto da arquitetura (cont.) A2) Identificar subsistemas e suas interfaces subsistemas da aplicação identificar  middleware    ( SO, SGBD, software de comunicação, pacotes GUI, distribuição, etc.) definir dependências entre os subsistemas identificar as interfaces entre os subsistemas Pacote (análise) Subsistema novo Software existente Não serve como subsistema É integrado com sistemas existentes
Projeto - passos Projeto da arquitetura (cont.) A3) Identificar classes de projeto significativas a partir das classes de análise classes ativas   ( requisitos de concorrência, performance, inicialização, distribuição,   prevenção de deadlocks)   A4) outros requisitos de projeto   ( persistência, transparência de distribuição, segurança, recuperação   de erros, gerência de transações)
Projeto - passos Projeto de um  use-case A1) Identificar classes de projeto participantes estudar as classes de análise identificar classes que realizam os requisitos especiais da análise definir as classes de projeto e passar para o projetista de componentes OBJETIVO: identificar classes de projeto distribuir o comportamento entre os objetos definir requisitos das operações requisitos de implementação do  use-case
Projeto - passos Projeto de um  use-case  (cont.) A2) Descrever a interação entre objetos o  use-case  é acionado por uma mensagem de um ator a um objeto traçar um ou vários  diagramas de sequência utilize nomes e textos (fluxo de eventos) para descrever as sequências considere as associações entre  use-cases  no diagrama de sequência
Projeto - passos Projeto de um  use-case  (cont.) A3) Identificar subsistemas e interfaces identificar os subsistemas obtidos a partir de pacotes deste  use-case verifique se há classes de projeto especiais e seus subsistemas A4) Descrever a interação entre subsistemas a partir dos  caminhos  no diagrama se sequência determinar a interação determinar qual interfaces é utilizada por qual mensagem
Projeto - passos Projeto de uma classe A1) Definir uma classe de projeto a partir de classes de fronteira : depende da linguagem classes de entidades persistentes podem produzir tabelas relacionais  classes de controle podem gerar várias classes de projeto (distribuição) ou serem encapsuladas em classes de entidades ASPECTOS: atributos operações e sua realização relacionamentos estados dependências interfaces requisitos de implementação
Projeto - passos Projeto de uma classe (cont.) A2) Definir operações realizar as responsabilidades da classe requisitos especiais (e.g. acesso ao banco de dados) atender às necessidades das interfaces da classe A3) Definir atributos considerar os atributos da análise os tipos dos atributos são determinados pela linguagem de programação valores de atributos usados por vários objetos devem ser transformados em objetos
Projeto - passos Projeto de uma classe (cont.) A4) Identificar associações e agregações dependendo da linguagem, transformá-los em relacionamentos tentar transformar cardinalidades, papéis, etc. em atributos ou    em novas classes para realizar a associação analise a navegabilidade pelas associações A5) Identificar generalizações A6) Descrever métodos realização de operações por pseudo-código, diagramas de atividades, linguagem natural,.. A7) Descrever estados diagrama de estados
Projeto - passos Projeto de um subsistema A1) Rever as dependências entre subsistemas A2) Rever as interfaces A3) Rever o conteúdo
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
Implementação - artefatos 1. MODELO DA IMPLEMENTAÇÃO É uma hierarquia de  subsistemas de implementação contendo   componentes  e  interfaces 2. COMPONENTE <<executable>> (programa executável) <<file>> (arquivo contendo código fonte ou dados) <<library>> (biblioteca estática ou dinâmica)  <<table>> (tabela do banco de dados) <<document>> (um documento) É UM PACOTE CONTENDO ELEMENTOS DO PROJETO Estereótipos:
Implementação - artefatos 2. COMPONENTE - exemplos <<executable>> ProcessaBoletim.java <<table>> Resumo BOLETIM __________ __________ RESUMO __________ __________ <<table>> Contrato realiza realiza gera gera
Implementação - artefatos 3. SUBSISTEMAS DE IMPLEMENTAÇÃO um  package  em Java um  project  em Visual Basic um  diretório  de C++ CORRESPONDÊNCIA 1-1 COM SUBSISTEMAS DE PROJETO 4. INTERFACES Implementam as interfaces do projeto
Implementação - artefatos 5. ARQUITETURA (visão da implementação) 6. PLANO DE INTEGRAÇÃO Decomposição em subsistemas, compostos de interfaces   e componentes   Componentes chave Primeira versão executável testes localizados de integração para facilitar a detecção de    erros versão final
Implementação - artífices Arquiteto  Integrador do sistema  Engenheiro de componentes  MODELO DA IMPLEMENTAÇÃO DESCRIÇÃO DA ARQUITETURA MODELO DE DISTRIBUIÇÃO PLANO DE INTEGRAÇÃO COMPONENTE SUBSISTEMA DE  IMPLEMENTAÇÃO INTERFACE
Implementação - artífices
Implementação PASSOS Implementação arquitetural  Integrar sistemas  Implementar subsistema  Testar componentes  Implementar uma classe
Projeto - passos Integrar sistemas Implementar uma classe Implementar um subsistema Implementação arquitetural ARQUITETO ENGENHEIRO DE  COMPONENTES INTEGRADOR  DE SISTEMAS Teste de unidade
Implementação - passos Implementação arquitetural  identificar componentes significativos Integrar sistemas  determinar sequência de construção integrar construções   (compilar e linkar novos componentes)
Implementação - passos Implementar subsistema garantir conteúdo do subsistema Implementar uma classe  implementar métodos determinar operações/métodos auxiliares
Teste OBJETIVOS Planejar os testes em cada iteração, tanto os      testes de integração  quanto os  testes de sistema preparar casos de teste, criar procedimentos de teste e procedimentos executáveis Realizar os testes e analisar os resultados
Teste - artefatos 1. MODELO DE TESTE Planejar os testes em cada iteração, tanto os    os  testes de integração  quanto os  testes de sistema preparar casos de teste, criar procedimentos de teste e procedimentos executáveis Realizar os testes e analisar os resultados 2. CASO DE TESTE
Fases X Etapas  Fases
As quatro Fases Fase de Concepção estabelece o  business case  (prioridade de negócio) Delimitar o  escopo do sistema Determinar  arquitetura  candidata (elementos novos, arriscados) Identificar  riscos críticos Identificar potenciais  usuários  ou  clientes  do sistema Passos
As quatro Fases Fase de Elaboração determina uma arquitetura estável Determinar linha base da  arquitetura  cobrindo funcionalidades  significantes Identificar  riscos críticos  que podem derrubar planos, orçamentos, e prazos Determinar níveis de  qualidade  (confiabilidade, tempos de resposta) Definir use-cases que cobrem ca. de 80% da funcionalidade do  sistema Determinar limites de pessoal, custos, prazos. Passos
As quatro Fases Fase de Construção determina capacidades operacionais iniciais Estender o modelo de  use-cases   para toda a aplicação Finalizar a  análise, projeto, implementação  e  testes Checar  integridade da arquitetura  (com possíveis alterações) Monitorar  ricos críticos Passos
As quatro Fases Fase de transição transforma versão  beta  em um sistema operacional Preparar atividades de transição Avisar clientes sobre mudanças no ambiente (hardware, software, distribuição, ..) Preparar  documentação  final Carregar o novo sistema Corrigir possíveis  defeitos  detectados no beta-teste Passos
Iterativo e incremental Uma ITERAÇÃO genérica é composta pelas 5 etapas: Requisitos, Análise, Projeto, Implementação e Testes Após cada iteração ou cada fase: planejar a próxima iteração à luz da experiência anterior modificar o processo, adaptar  ferramentas, treinamento, etc.
Iterativo e incremental requisitos análise projeto Implement. testes planejamento consolidação ITERAÇÃO
Iterativo e incremental Planejando as ITERAÇÕES Planejando as FASES tempos por fase milestones iterações por fase plano do projeto cronograma conteúdo:   -  quais use-cases serão realizados   -  iterações anteriores e posteriores
Riscos Possíveis riscos: Gerenciar uma lista de riscos: descrição prioridade  (crítico, signifcante, rotineiro) impacto responsabilidades contingência  (o que fazer?) relacionados a um produto não conseguir a arquitetura não realizar os requisitos

Mais conteúdo relacionado

Mais procurados

Exemplos de User Stories
Exemplos de User StoriesExemplos de User Stories
Exemplos de User Stories
Manoel Pimentel Medeiros
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1
Elaine Cecília Gatto
 
Manual de portugol
Manual de portugolManual de portugol
Manual de portugol
Gabriel Faustino
 
Padrões de Projeto
Padrões de ProjetoPadrões de Projeto
Padrões de Projeto
Vagner Santana
 
Aula 2 arquitecturas de sgbd, utilizadores, perfis
Aula 2   arquitecturas de sgbd, utilizadores, perfisAula 2   arquitecturas de sgbd, utilizadores, perfis
Aula 2 arquitecturas de sgbd, utilizadores, perfis
Hélio Martins
 
Documentação de Processos de Negócio
Documentação de Processos de NegócioDocumentação de Processos de Negócio
Documentação de Processos de Negócio
Rildo (@rildosan) Santos
 
CVS - Slides Parte 1 - Introdução
CVS - Slides Parte 1 - IntroduçãoCVS - Slides Parte 1 - Introdução
CVS - Slides Parte 1 - Introdução
Marden Neubert
 
Normas e Padrões para a Qualidade de Software
Normas e Padrões para a Qualidade de SoftwareNormas e Padrões para a Qualidade de Software
Normas e Padrões para a Qualidade de Software
Danilo Sousa
 
Arquitetura de Computadores: Conceitos básicos
Arquitetura de Computadores: Conceitos básicosArquitetura de Computadores: Conceitos básicos
Arquitetura de Computadores: Conceitos básicos
Alex Camargo
 
Exemplo de Plano de testes
Exemplo de Plano de testes Exemplo de Plano de testes
Exemplo de Plano de testes
Leandro Rodrigues
 
Porque você deveria usar CDI nos seus projetos Java! - JavaOne LA 2012 - Sérg...
Porque você deveria usar CDI nos seus projetos Java! - JavaOne LA 2012 - Sérg...Porque você deveria usar CDI nos seus projetos Java! - JavaOne LA 2012 - Sérg...
Porque você deveria usar CDI nos seus projetos Java! - JavaOne LA 2012 - Sérg...
Caelum
 
Introdução à Gerência de configuração de Software
Introdução à Gerência de configuração de SoftwareIntrodução à Gerência de configuração de Software
Introdução à Gerência de configuração de Software
Lucas Amaral
 
Visão por Processos
Visão por ProcessosVisão por Processos
Visão por Processos
Q2 Management
 
Caderno de exercícios excel 2010
Caderno de exercícios excel 2010Caderno de exercícios excel 2010
Caderno de exercícios excel 2010
Luiz Alexandre Araujo Tobase
 
Gerência de Requisitos
Gerência de RequisitosGerência de Requisitos
Gerência de Requisitos
Mauricio Volkweis Astiazara
 
Tipos de Licença de Softwares
Tipos de Licença de SoftwaresTipos de Licença de Softwares
Tipos de Licença de Softwares
Lucas Castejon
 
Excel basico
Excel basicoExcel basico
Excel basico
Carlos Melo
 
Aula 1 Excel básico
Aula 1   Excel básicoAula 1   Excel básico
Aula 1 Excel básico
Saulo Said
 
Governança de TI - Aula 6 - intro cobit
Governança de TI - Aula 6 - intro cobitGovernança de TI - Aula 6 - intro cobit
Governança de TI - Aula 6 - intro cobit
CEULJI/ULBRA Centro Universitário Luterano de Ji-Paraná
 
SEAC: Um Simulador Online para Ensino de Arquitetura de Computadores
SEAC: Um Simulador Online para Ensino de Arquitetura de ComputadoresSEAC: Um Simulador Online para Ensino de Arquitetura de Computadores
SEAC: Um Simulador Online para Ensino de Arquitetura de Computadores
Eduardo de Lucena Falcão
 

Mais procurados (20)

Exemplos de User Stories
Exemplos de User StoriesExemplos de User Stories
Exemplos de User Stories
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1
 
Manual de portugol
Manual de portugolManual de portugol
Manual de portugol
 
Padrões de Projeto
Padrões de ProjetoPadrões de Projeto
Padrões de Projeto
 
Aula 2 arquitecturas de sgbd, utilizadores, perfis
Aula 2   arquitecturas de sgbd, utilizadores, perfisAula 2   arquitecturas de sgbd, utilizadores, perfis
Aula 2 arquitecturas de sgbd, utilizadores, perfis
 
Documentação de Processos de Negócio
Documentação de Processos de NegócioDocumentação de Processos de Negócio
Documentação de Processos de Negócio
 
CVS - Slides Parte 1 - Introdução
CVS - Slides Parte 1 - IntroduçãoCVS - Slides Parte 1 - Introdução
CVS - Slides Parte 1 - Introdução
 
Normas e Padrões para a Qualidade de Software
Normas e Padrões para a Qualidade de SoftwareNormas e Padrões para a Qualidade de Software
Normas e Padrões para a Qualidade de Software
 
Arquitetura de Computadores: Conceitos básicos
Arquitetura de Computadores: Conceitos básicosArquitetura de Computadores: Conceitos básicos
Arquitetura de Computadores: Conceitos básicos
 
Exemplo de Plano de testes
Exemplo de Plano de testes Exemplo de Plano de testes
Exemplo de Plano de testes
 
Porque você deveria usar CDI nos seus projetos Java! - JavaOne LA 2012 - Sérg...
Porque você deveria usar CDI nos seus projetos Java! - JavaOne LA 2012 - Sérg...Porque você deveria usar CDI nos seus projetos Java! - JavaOne LA 2012 - Sérg...
Porque você deveria usar CDI nos seus projetos Java! - JavaOne LA 2012 - Sérg...
 
Introdução à Gerência de configuração de Software
Introdução à Gerência de configuração de SoftwareIntrodução à Gerência de configuração de Software
Introdução à Gerência de configuração de Software
 
Visão por Processos
Visão por ProcessosVisão por Processos
Visão por Processos
 
Caderno de exercícios excel 2010
Caderno de exercícios excel 2010Caderno de exercícios excel 2010
Caderno de exercícios excel 2010
 
Gerência de Requisitos
Gerência de RequisitosGerência de Requisitos
Gerência de Requisitos
 
Tipos de Licença de Softwares
Tipos de Licença de SoftwaresTipos de Licença de Softwares
Tipos de Licença de Softwares
 
Excel basico
Excel basicoExcel basico
Excel basico
 
Aula 1 Excel básico
Aula 1   Excel básicoAula 1   Excel básico
Aula 1 Excel básico
 
Governança de TI - Aula 6 - intro cobit
Governança de TI - Aula 6 - intro cobitGovernança de TI - Aula 6 - intro cobit
Governança de TI - Aula 6 - intro cobit
 
SEAC: Um Simulador Online para Ensino de Arquitetura de Computadores
SEAC: Um Simulador Online para Ensino de Arquitetura de ComputadoresSEAC: Um Simulador Online para Ensino de Arquitetura de Computadores
SEAC: Um Simulador Online para Ensino de Arquitetura de Computadores
 

Semelhante a Processo Unificado de Desenvolvimento de Software

Processo Unificado(RUP)
Processo Unificado(RUP)Processo Unificado(RUP)
Processo Unificado(RUP)
elliando dias
 
347842.ppt
347842.ppt347842.ppt
347842.ppt
PedrinaBrasil2
 
Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
Carlos Henrique Martins da Silva
 
Saam & arquiteturas_iu_halan
Saam & arquiteturas_iu_halanSaam & arquiteturas_iu_halan
Saam & arquiteturas_iu_halan
Halan Ridolphi
 
Visao geraldorup 20slides
Visao geraldorup 20slidesVisao geraldorup 20slides
Visao geraldorup 20slides
horaciosila
 
Iconix.metodo.trabajo.universidad.porto.ppt
Iconix.metodo.trabajo.universidad.porto.pptIconix.metodo.trabajo.universidad.porto.ppt
Iconix.metodo.trabajo.universidad.porto.ppt
roygarcia271
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
Roni Reis
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
Milfont Consulting
 
Apresentação RUP
Apresentação RUPApresentação RUP
Apresentação RUP
Fernando Nogueira
 
Visao Geral Rup
Visao Geral RupVisao Geral Rup
Visao Geral Rup
renancristiano
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
eros.viggiano
 
Introdução a engenharia de software aula 01
Introdução a engenharia de software   aula 01Introdução a engenharia de software   aula 01
Introdução a engenharia de software aula 01
Franklin Matos Correia
 
Gestão de Projectos de SW OO Métricas Estimações e Planificações
Gestão de Projectos de SW OO Métricas Estimações e PlanificaçõesGestão de Projectos de SW OO Métricas Estimações e Planificações
Gestão de Projectos de SW OO Métricas Estimações e Planificações
Rogerio P C do Nascimento
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
Fábio Nogueira de Lucena
 
O papel do Arquiteto de Soluções na RPA.
O papel do Arquiteto de Soluções na RPA.O papel do Arquiteto de Soluções na RPA.
O papel do Arquiteto de Soluções na RPA.
Sergio Marmilicz
 
Arquitetura de sistemas web
Arquitetura de sistemas webArquitetura de sistemas web
Arquitetura de sistemas web
Opakus - Soluções Inteligentes
 
Aula1 eng software
Aula1 eng softwareAula1 eng software
Aula1 eng software
Portal_do_estudante_ADS
 
Aula 03 - IBM Rational Unified Process- METODOLOGIA ÁGIL
Aula 03 - IBM Rational Unified Process- METODOLOGIA ÁGILAula 03 - IBM Rational Unified Process- METODOLOGIA ÁGIL
Aula 03 - IBM Rational Unified Process- METODOLOGIA ÁGIL
CarlosHenriqueRamalh2
 
Apresentação fdd
Apresentação fddApresentação fdd
Apresentação fdd
Marlon Ribeiro
 
FDD
FDDFDD

Semelhante a Processo Unificado de Desenvolvimento de Software (20)

Processo Unificado(RUP)
Processo Unificado(RUP)Processo Unificado(RUP)
Processo Unificado(RUP)
 
347842.ppt
347842.ppt347842.ppt
347842.ppt
 
Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
 
Saam & arquiteturas_iu_halan
Saam & arquiteturas_iu_halanSaam & arquiteturas_iu_halan
Saam & arquiteturas_iu_halan
 
Visao geraldorup 20slides
Visao geraldorup 20slidesVisao geraldorup 20slides
Visao geraldorup 20slides
 
Iconix.metodo.trabajo.universidad.porto.ppt
Iconix.metodo.trabajo.universidad.porto.pptIconix.metodo.trabajo.universidad.porto.ppt
Iconix.metodo.trabajo.universidad.porto.ppt
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
 
Apresentação RUP
Apresentação RUPApresentação RUP
Apresentação RUP
 
Visao Geral Rup
Visao Geral RupVisao Geral Rup
Visao Geral Rup
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Introdução a engenharia de software aula 01
Introdução a engenharia de software   aula 01Introdução a engenharia de software   aula 01
Introdução a engenharia de software aula 01
 
Gestão de Projectos de SW OO Métricas Estimações e Planificações
Gestão de Projectos de SW OO Métricas Estimações e PlanificaçõesGestão de Projectos de SW OO Métricas Estimações e Planificações
Gestão de Projectos de SW OO Métricas Estimações e Planificações
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
O papel do Arquiteto de Soluções na RPA.
O papel do Arquiteto de Soluções na RPA.O papel do Arquiteto de Soluções na RPA.
O papel do Arquiteto de Soluções na RPA.
 
Arquitetura de sistemas web
Arquitetura de sistemas webArquitetura de sistemas web
Arquitetura de sistemas web
 
Aula1 eng software
Aula1 eng softwareAula1 eng software
Aula1 eng software
 
Aula 03 - IBM Rational Unified Process- METODOLOGIA ÁGIL
Aula 03 - IBM Rational Unified Process- METODOLOGIA ÁGILAula 03 - IBM Rational Unified Process- METODOLOGIA ÁGIL
Aula 03 - IBM Rational Unified Process- METODOLOGIA ÁGIL
 
Apresentação fdd
Apresentação fddApresentação fdd
Apresentação fdd
 
FDD
FDDFDD
FDD
 

Mais de elliando dias

Clojurescript slides
Clojurescript slidesClojurescript slides
Clojurescript slides
elliando dias
 
Why you should be excited about ClojureScript
Why you should be excited about ClojureScriptWhy you should be excited about ClojureScript
Why you should be excited about ClojureScript
elliando dias
 
Functional Programming with Immutable Data Structures
Functional Programming with Immutable Data StructuresFunctional Programming with Immutable Data Structures
Functional Programming with Immutable Data Structures
elliando dias
 
Nomenclatura e peças de container
Nomenclatura  e peças de containerNomenclatura  e peças de container
Nomenclatura e peças de container
elliando dias
 
Geometria Projetiva
Geometria ProjetivaGeometria Projetiva
Geometria Projetiva
elliando dias
 
Polyglot and Poly-paradigm Programming for Better Agility
Polyglot and Poly-paradigm Programming for Better AgilityPolyglot and Poly-paradigm Programming for Better Agility
Polyglot and Poly-paradigm Programming for Better Agility
elliando dias
 
Javascript Libraries
Javascript LibrariesJavascript Libraries
Javascript Libraries
elliando dias
 
How to Make an Eight Bit Computer and Save the World!
How to Make an Eight Bit Computer and Save the World!How to Make an Eight Bit Computer and Save the World!
How to Make an Eight Bit Computer and Save the World!
elliando dias
 
Ragel talk
Ragel talkRagel talk
Ragel talk
elliando dias
 
A Practical Guide to Connecting Hardware to the Web
A Practical Guide to Connecting Hardware to the WebA Practical Guide to Connecting Hardware to the Web
A Practical Guide to Connecting Hardware to the Web
elliando dias
 
Introdução ao Arduino
Introdução ao ArduinoIntrodução ao Arduino
Introdução ao Arduino
elliando dias
 
Minicurso arduino
Minicurso arduinoMinicurso arduino
Minicurso arduino
elliando dias
 
Incanter Data Sorcery
Incanter Data SorceryIncanter Data Sorcery
Incanter Data Sorcery
elliando dias
 
Rango
RangoRango
Fab.in.a.box - Fab Academy: Machine Design
Fab.in.a.box - Fab Academy: Machine DesignFab.in.a.box - Fab Academy: Machine Design
Fab.in.a.box - Fab Academy: Machine Design
elliando dias
 
The Digital Revolution: Machines that makes
The Digital Revolution: Machines that makesThe Digital Revolution: Machines that makes
The Digital Revolution: Machines that makes
elliando dias
 
Hadoop + Clojure
Hadoop + ClojureHadoop + Clojure
Hadoop + Clojure
elliando dias
 
Hadoop - Simple. Scalable.
Hadoop - Simple. Scalable.Hadoop - Simple. Scalable.
Hadoop - Simple. Scalable.
elliando dias
 
Hadoop and Hive Development at Facebook
Hadoop and Hive Development at FacebookHadoop and Hive Development at Facebook
Hadoop and Hive Development at Facebook
elliando dias
 
Multi-core Parallelization in Clojure - a Case Study
Multi-core Parallelization in Clojure - a Case StudyMulti-core Parallelization in Clojure - a Case Study
Multi-core Parallelization in Clojure - a Case Study
elliando dias
 

Mais de elliando dias (20)

Clojurescript slides
Clojurescript slidesClojurescript slides
Clojurescript slides
 
Why you should be excited about ClojureScript
Why you should be excited about ClojureScriptWhy you should be excited about ClojureScript
Why you should be excited about ClojureScript
 
Functional Programming with Immutable Data Structures
Functional Programming with Immutable Data StructuresFunctional Programming with Immutable Data Structures
Functional Programming with Immutable Data Structures
 
Nomenclatura e peças de container
Nomenclatura  e peças de containerNomenclatura  e peças de container
Nomenclatura e peças de container
 
Geometria Projetiva
Geometria ProjetivaGeometria Projetiva
Geometria Projetiva
 
Polyglot and Poly-paradigm Programming for Better Agility
Polyglot and Poly-paradigm Programming for Better AgilityPolyglot and Poly-paradigm Programming for Better Agility
Polyglot and Poly-paradigm Programming for Better Agility
 
Javascript Libraries
Javascript LibrariesJavascript Libraries
Javascript Libraries
 
How to Make an Eight Bit Computer and Save the World!
How to Make an Eight Bit Computer and Save the World!How to Make an Eight Bit Computer and Save the World!
How to Make an Eight Bit Computer and Save the World!
 
Ragel talk
Ragel talkRagel talk
Ragel talk
 
A Practical Guide to Connecting Hardware to the Web
A Practical Guide to Connecting Hardware to the WebA Practical Guide to Connecting Hardware to the Web
A Practical Guide to Connecting Hardware to the Web
 
Introdução ao Arduino
Introdução ao ArduinoIntrodução ao Arduino
Introdução ao Arduino
 
Minicurso arduino
Minicurso arduinoMinicurso arduino
Minicurso arduino
 
Incanter Data Sorcery
Incanter Data SorceryIncanter Data Sorcery
Incanter Data Sorcery
 
Rango
RangoRango
Rango
 
Fab.in.a.box - Fab Academy: Machine Design
Fab.in.a.box - Fab Academy: Machine DesignFab.in.a.box - Fab Academy: Machine Design
Fab.in.a.box - Fab Academy: Machine Design
 
The Digital Revolution: Machines that makes
The Digital Revolution: Machines that makesThe Digital Revolution: Machines that makes
The Digital Revolution: Machines that makes
 
Hadoop + Clojure
Hadoop + ClojureHadoop + Clojure
Hadoop + Clojure
 
Hadoop - Simple. Scalable.
Hadoop - Simple. Scalable.Hadoop - Simple. Scalable.
Hadoop - Simple. Scalable.
 
Hadoop and Hive Development at Facebook
Hadoop and Hive Development at FacebookHadoop and Hive Development at Facebook
Hadoop and Hive Development at Facebook
 
Multi-core Parallelization in Clojure - a Case Study
Multi-core Parallelization in Clojure - a Case StudyMulti-core Parallelization in Clojure - a Case Study
Multi-core Parallelization in Clojure - a Case Study
 

Processo Unificado de Desenvolvimento de Software

  • 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. 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. CARACTERÍSTICAS baseado em componentes que realizam interfaces usa UML aspectos: * dirigido por Use-Cases * centrado em arquitetura * iterativo e incremental os 4 Ps: pessoal, projeto, produto e processo
  • 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. 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. 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. 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. Dirigido a Use-Cases Porque USE-CASES?? Capturar os requisitos : o Diagrama Use-Case mostra quais atores usam quais use-cases Use-Cases Arquitetura do sistema dirige influi Dirigir o processo : para realizar os use-cases são definidos classificadores (classes, subsistemas, interfaces) e relacionamentos (colaborações) entre estes Elaborar a arquitetura, determinar iterações, determinação dos manuais de usuário
  • 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. Dirigido a Use-Cases Dirigir o processo : 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. Centrado na arquitetura DECISÕES SOBRE: a organização do sistema como um todo os elementos estruturais, interfaces e seu comportamento composição de elementos estruturais e comportamentais em subsistemas 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. 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. Centrado na arquitetura PRODUTO Use-Case Arquitetura Sequência para o arquiteto: Criar uma visão preliminar da arquitetura Analisar os use-cases chave (5-10%) e especificar um subsistema para cada um Pela especificação dos subsistemas aparecem mais detalhes da arquitetura e novos use-cases Repetir o passo acima, até terminar o sistema função forma
  • 14. 4 FASES CONCEPÇÃO CONSTRUÇÃO ELABORAÇÃO TRANSIÇÃO
  • 15. Iterativo e incremental Projetos grandes são divididos em mini-projetos Cada mini-projeto é uma iteração Um grupo de use-cases que estendem usabilidade Fatores de risco mais importantes MINI- PROJETO Cada iteração gera um incremento PORQUE ITERATIVO E INCREMENTAL atenuar riscos obter arquitetura robusta facilitar alterações táticas ou contínuas conseguir aprendizado mais cedo
  • 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. identificar os riscos fixar subconjunto chave -> arquitetura candidata estimativas iniciais (custos, esforços, alocações e qualidade do produto) iniciar caso gerencial ( business case )
  • 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 identificar e reduzir riscos de construção especificar maioria dos use-cases fixar a arquitetura em proporções executáveis preparar o plano de projeto (para a próxima fase) estimar e justificar o orçamento finalizar o business case iterações garantindo viabilidade em forma executável -> incrementos eliminar problemas e erros não identificados previamente
  • 19. O P ROCESSO U NIFICADO
  • 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. Modelos Requisitos ARTEFATOS Análise Projeto Implementação Testes ARTÍFICES PASSOS e ATIVIDADES produz produzido-por composto-por
  • 22. Obtenção dos Requisitos ARTEFATOS Modelo Use-Case ator Use-Case descrição da arquitetura
  • 23. Obtenção dos Requisitos ARTÍFICES Analista de sistemas arquiteto Especificador de Use-Case projetista de interfaces
  • 24. Obtenção dos Requisitos PASSOS listar potenciais requisitos entender o contexto do sistema capturar requisitos funcionais capturar requisitos não-funcionais
  • 25. Obtenção dos Requisitos - Passos listar potenciais requisitos Desenvolver uma lista de características obtidas de clientes, usuários, analistas e desenvolvedores CARACTERÍSTICA: nome breve descrição ou definição conjunto de valores Estado (proposto, aprovado, incorporado, validado) estimativa de custos prioridade (crítica, importante ou secundária) riscos (crítico, significante, ordinário)
  • 26. Obtenção dos Requisitos - Passos entender o contexto do sistema criar um modelo do domínio objetos de negócio (pedidos, contas, contratos,..) objetos do mundo real (veículos, máquinas, trajetos,..) eventos básicos (chegada de um pedido, partida de um transporte, ..) usar diagramas UML, em particular diagramas de classe
  • 27. Obtenção dos Requisitos - Passos capturar requisitos funcionais ARTÍFICE ARTEFATO Analista de Sistemas Especificador de Use-Cases Projetista de Interfaces Arquiteto Modelo use-case atores glossários Protótipos de interfaces Use-cases Arquitetura responsável
  • 28. Obtenção dos Requisitos - Passos capturar requisitos funcionais ATIVIDADES E SUBPASSOS A1) encontrar os atores e use-cases encontrar os atores encontrar e descrever cada use-case descrever o Modelo Use-Case como um todo A2) Priorizar Use-Cases (visão arquitetural)
  • 29. Obtenção dos Requisitos - Passos capturar requisitos funcionais ATIVIDADES E SUBPASSOS A3) Detalhar cada Use-Case estruturar a descrição do use-case (construir um diagrama de estados e analisar cada caminho) formalizar a descrição do use-case (usar diagramas de estado, diagramas de atividade ou diagramas de interação) descrever o Modelo Use-Case como um todo
  • 30. Obtenção dos Requisitos - Passos capturar requisitos funcionais ATIVIDADES E SUBPASSOS A4) Prototipar as interfaces com o usuário projeto lógico da interface do usuário projeto físico da interface do usuário e protótipo
  • 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! QUESTÕES para determinar os elementos de interação : quais informações o ator fornece ao sistema? quais informações o ator necessita do sistema? com quais elementos de interação o ator trabalha? quais ações o ator pode acionar e quais decisões tomar? Quais classes de domínio ou entidades de negócio estão envolvidos com elementos de interação?
  • 32. Obtenção dos Requisitos PROJETO FÍSICO : combinar elementos de interação para formar interfaces que atendam a atores determinar elementos adicionais (folders, janelas, controles, etc.) desenvolver um protótipo para cada interface
  • 33. Obtenção dos Requisitos capturar requisitos funcionais ATIVIDADES E SUBPASSOS A5) Estruturar o modelo Use-Case identificar funcionalidades comuns (generalizações, <<estende>>) identificar funcionalidades adicionais ou opcionais identificar outros relacionamentos entre use-cases (<<inclui>>, inverso de <<estende>>)
  • 34. Obtenção dos Requisitos capturar requisitos não-funcionais ATIVIDADES usabilidade requisitos de interfaces metáfora, frequência de uso, .. documentação confiabilidade tolerância a falhas.
  • 35. Obtenção dos Requisitos capturar requisitos não-funcionais ATIVIDADES performance tempos de resposta volumes de transações requisitos físicos equipamentos, material, espaços, configurações de rede, software
  • 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. 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. Análise - artefatos 3. REALIZAÇÃO DE UM USE-CASE Diagramas de classe Diagramas de colaboração 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. Análise - artefatos 3. REALIZAÇÃO DE UM USE-CASE (cont.) requisitos especiais fluxo de eventos 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 Candidatos a subsistemas do projeto é um conjunto de ações coerentes, indivisíveis para uso em vários use-cases 5. DESCRIÇÃO DA ARQUITETURA
  • 41. Análise arquiteto Especificador de Use-Case Especificador de componentes ARTÍFICES responsável pela integridade global do modelo de análise (corretude, consistência e legibilidade), tanto pela sua funcionalidade quanto pela arquitetura responsável que a realização de um use-case corresponde a sua especificação responsável pelas classe de análise e pelos pacotes
  • 42. Análise PASSOS Análise arquitetural Análise de cada Use-Case Análise de cada classe Análise de cada pacote
  • 43. Análise - passos Análise arquitetural 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. Análise - passos Análise arquitetural ATIVIDADES E SUBPASSOS A1) Identificar pacotes de análise Encontrar pacotes coesos e fracamente acoplados Identificar funcionalidades comuns entre pacotes (pacotes genéricos) Identificar pacotes de serviço (serviços opcionais, classes relacionadas funcionalmente) Dependências entre pacotes
  • 45. Análise - passos Análise arquitetural (cont.) A2) Identificar classes de entidades óbvias Obtidas a partir das classe do domínio A3) Identificar requisitos especiais comuns Persistência Distribuição e concorrência aspectos de segurança tolerância a falhas gerência de transações
  • 46. Análise - passos Análise de cada Use-Case encontrar as classe de análise para realizar o use-case distribuir o comportamento do use-case entre as classes identificar requisitos especiais 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. Análise - passos Análise de cada Use-Case A1) Identificar classes de análise encontrar classes de entidades para armazenar as informações do use-case para cada ator humano, determinar uma classe de fronteira central (representa a janela principal) determinar as classe de fronteira que interagem com as classes de entidade determinar, pelo menos, uma classe de controle que coordena o use-case CONSTRUIR UM DIAGRAMA DE CLASSES
  • 48. Análise - passos Análise de cada Use-Case (cont.) A2) Descrever interações entre objetos construir um diagrama de colaboração toda classe de análise deve participar de algum diagrama de colaboração dar maior ênfase às conexões e condições do que à sequência às conexões de mensagens podem corresponder associações do diagrama de objetos ou não considerar as relações entre use-cases no diagrama A3) Determinar requisitos especiais
  • 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 Análise de cada Use-Case (cont.)
  • 50. Análise - passos Análise de cada classe identificar as responsabilidades de cada classe, baseado em sua função na realização de use-cases definir os atributos e relacionamentos capturar requisitos especiais para cada classe 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. Análise - passos Análise de cada classe A3) Identificar associações e agregações A2) Definir os atributos tipos de atributos são conceituais classes com muitos atributos podem ser divididas atributos de classes de fronteira são campos em interfaces classes de controle geralmente não tem atributos A1) Identificar responsabilidades Determinar os papéis de cada classe nos diferentes use-cases A4) Identificar generalizações A5) Determinar requisitos especiais
  • 52. Análise - passos Análise de cada pacote Rever as dependências entre pacotes de acordo com associações estáticas ou dinâmicas entre as classes, criadas nos passos anteriores Garantir que cada pacote preenche sua função Rever as questões de acoplamento fraco e coesão
  • 53. Projeto 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. . Criar informações suficientes para a implementação, descre- vendo subsistemas, interfaces e classes. Estar apto a dividir a tarefa de implementação em equipes Determinar mais cedo as interfaces entre os subsistemas Criar um modelo que possibilite uma implementação que preencha as estruturas definidas sem altera-las OBJETIVOS
  • 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 na linguagem de programação da implementação visibilidade dos atributos (ex. publico, protegido, privado) generalizações  herança; associações e agregações  atributos métodos em pseudo-código
  • 56. Projeto - artefatos 3. REALIZAÇÃO DO USE-CASE Diagrama de classes Diagrama de interações (diagramas de sequência) Fluxo de eventos (textual) Requisitos de implementação
  • 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. Projeto - artífices Arquiteto Especificador de use-cases Especificador de componentes MODELO DO PROJETO ARQUITETURA MODELO DE DISTRIBUIÇÃO REALIZAÇÃO DE USE CASE CLASSE DE PROJETO SUBSISTEMA INTERFACE
  • 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. Projeto - passos Projeto da arquitetura A1) Identificar nós e configurações de rede determinar os nós envolvidos e suas características determinar os tipos de conexões entre os nós verificar necessidades de processamentos redundantes, backups , etc.
  • 61. Projeto - passos Projeto da arquitetura (cont.) A2) Identificar subsistemas e suas interfaces subsistemas da aplicação identificar middleware ( SO, SGBD, software de comunicação, pacotes GUI, distribuição, etc.) definir dependências entre os subsistemas identificar as interfaces entre os subsistemas Pacote (análise) Subsistema novo Software existente Não serve como subsistema É integrado com sistemas existentes
  • 62. Projeto - passos Projeto da arquitetura (cont.) A3) Identificar classes de projeto significativas a partir das classes de análise classes ativas ( requisitos de concorrência, performance, inicialização, distribuição, prevenção de deadlocks) A4) outros requisitos de projeto ( persistência, transparência de distribuição, segurança, recuperação de erros, gerência de transações)
  • 63. Projeto - passos Projeto de um use-case A1) Identificar classes de projeto participantes estudar as classes de análise identificar classes que realizam os requisitos especiais da análise definir as classes de projeto e passar para o projetista de componentes OBJETIVO: identificar classes de projeto distribuir o comportamento entre os objetos definir requisitos das operações requisitos de implementação do use-case
  • 64. Projeto - passos Projeto de um use-case (cont.) A2) Descrever a interação entre objetos o use-case é acionado por uma mensagem de um ator a um objeto traçar um ou vários diagramas de sequência utilize nomes e textos (fluxo de eventos) para descrever as sequências considere as associações entre use-cases no diagrama de sequência
  • 65. Projeto - passos Projeto de um use-case (cont.) A3) Identificar subsistemas e interfaces identificar os subsistemas obtidos a partir de pacotes deste use-case verifique se há classes de projeto especiais e seus subsistemas A4) Descrever a interação entre subsistemas a partir dos caminhos no diagrama se sequência determinar a interação determinar qual interfaces é utilizada por qual mensagem
  • 66. Projeto - passos Projeto de uma classe A1) Definir uma classe de projeto a partir de classes de fronteira : depende da linguagem classes de entidades persistentes podem produzir tabelas relacionais classes de controle podem gerar várias classes de projeto (distribuição) ou serem encapsuladas em classes de entidades ASPECTOS: atributos operações e sua realização relacionamentos estados dependências interfaces requisitos de implementação
  • 67. Projeto - passos Projeto de uma classe (cont.) A2) Definir operações realizar as responsabilidades da classe requisitos especiais (e.g. acesso ao banco de dados) atender às necessidades das interfaces da classe A3) Definir atributos considerar os atributos da análise os tipos dos atributos são determinados pela linguagem de programação valores de atributos usados por vários objetos devem ser transformados em objetos
  • 68. Projeto - passos Projeto de uma classe (cont.) A4) Identificar associações e agregações dependendo da linguagem, transformá-los em relacionamentos tentar transformar cardinalidades, papéis, etc. em atributos ou em novas classes para realizar a associação analise a navegabilidade pelas associações A5) Identificar generalizações A6) Descrever métodos realização de operações por pseudo-código, diagramas de atividades, linguagem natural,.. A7) Descrever estados diagrama de estados
  • 69. Projeto - passos Projeto de um subsistema A1) Rever as dependências entre subsistemas A2) Rever as interfaces A3) Rever o conteúdo
  • 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. Implementação - artefatos 1. MODELO DA IMPLEMENTAÇÃO É uma hierarquia de subsistemas de implementação contendo componentes e interfaces 2. COMPONENTE <<executable>> (programa executável) <<file>> (arquivo contendo código fonte ou dados) <<library>> (biblioteca estática ou dinâmica) <<table>> (tabela do banco de dados) <<document>> (um documento) É UM PACOTE CONTENDO ELEMENTOS DO PROJETO Estereótipos:
  • 72. Implementação - artefatos 2. COMPONENTE - exemplos <<executable>> ProcessaBoletim.java <<table>> Resumo BOLETIM __________ __________ RESUMO __________ __________ <<table>> Contrato realiza realiza gera gera
  • 73. Implementação - artefatos 3. SUBSISTEMAS DE IMPLEMENTAÇÃO um package em Java um project em Visual Basic um diretório de C++ CORRESPONDÊNCIA 1-1 COM SUBSISTEMAS DE PROJETO 4. INTERFACES Implementam as interfaces do projeto
  • 74. Implementação - artefatos 5. ARQUITETURA (visão da implementação) 6. PLANO DE INTEGRAÇÃO Decomposição em subsistemas, compostos de interfaces e componentes Componentes chave Primeira versão executável testes localizados de integração para facilitar a detecção de erros versão final
  • 75. Implementação - artífices Arquiteto Integrador do sistema Engenheiro de componentes MODELO DA IMPLEMENTAÇÃO DESCRIÇÃO DA ARQUITETURA MODELO DE DISTRIBUIÇÃO PLANO DE INTEGRAÇÃO COMPONENTE SUBSISTEMA DE IMPLEMENTAÇÃO INTERFACE
  • 77. Implementação PASSOS Implementação arquitetural Integrar sistemas Implementar subsistema Testar componentes Implementar uma classe
  • 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. Implementação - passos Implementação arquitetural identificar componentes significativos Integrar sistemas determinar sequência de construção integrar construções (compilar e linkar novos componentes)
  • 80. Implementação - passos Implementar subsistema garantir conteúdo do subsistema Implementar uma classe implementar métodos determinar operações/métodos auxiliares
  • 81. Teste OBJETIVOS Planejar os testes em cada iteração, tanto os testes de integração quanto os testes de sistema preparar casos de teste, criar procedimentos de teste e procedimentos executáveis Realizar os testes e analisar os resultados
  • 82. Teste - artefatos 1. MODELO DE TESTE Planejar os testes em cada iteração, tanto os os testes de integração quanto os testes de sistema preparar casos de teste, criar procedimentos de teste e procedimentos executáveis Realizar os testes e analisar os resultados 2. CASO DE TESTE
  • 83. Fases X Etapas Fases
  • 84. As quatro Fases Fase de Concepção estabelece o business case (prioridade de negócio) Delimitar o escopo do sistema Determinar arquitetura candidata (elementos novos, arriscados) Identificar riscos críticos Identificar potenciais usuários ou clientes do sistema Passos
  • 85. As quatro Fases Fase de Elaboração determina uma arquitetura estável Determinar linha base da arquitetura cobrindo funcionalidades significantes Identificar riscos críticos que podem derrubar planos, orçamentos, e prazos Determinar níveis de qualidade (confiabilidade, tempos de resposta) Definir use-cases que cobrem ca. de 80% da funcionalidade do sistema Determinar limites de pessoal, custos, prazos. Passos
  • 86. As quatro Fases Fase de Construção determina capacidades operacionais iniciais Estender o modelo de use-cases para toda a aplicação Finalizar a análise, projeto, implementação e testes Checar integridade da arquitetura (com possíveis alterações) Monitorar ricos críticos Passos
  • 87. As quatro Fases Fase de transição transforma versão beta em um sistema operacional Preparar atividades de transição Avisar clientes sobre mudanças no ambiente (hardware, software, distribuição, ..) Preparar documentação final Carregar o novo sistema Corrigir possíveis defeitos detectados no beta-teste Passos
  • 88. Iterativo e incremental Uma ITERAÇÃO genérica é composta pelas 5 etapas: Requisitos, Análise, Projeto, Implementação e Testes Após cada iteração ou cada fase: planejar a próxima iteração à luz da experiência anterior modificar o processo, adaptar ferramentas, treinamento, etc.
  • 89. Iterativo e incremental requisitos análise projeto Implement. testes planejamento consolidação ITERAÇÃO
  • 90. Iterativo e incremental Planejando as ITERAÇÕES Planejando as FASES tempos por fase milestones iterações por fase plano do projeto cronograma conteúdo: - quais use-cases serão realizados - iterações anteriores e posteriores
  • 91. Riscos Possíveis riscos: Gerenciar uma lista de riscos: descrição prioridade (crítico, signifcante, rotineiro) impacto responsabilidades contingência (o que fazer?) relacionados a um produto não conseguir a arquitetura não realizar os requisitos