Processo Unificado de Desenvolvimento de Software

Apresentação em tema: "Processo Unificado de Desenvolvimento de Software"— Transcrição da apresentação:

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 ciclo Sistema-i fase Sistema-i+1 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 descrevem o sistema a ser desenvolvido, sob um certo ponto-de-vista, e seu ambiente, ou seja, os atores REQUISITOS - funcionais e não-funcionais ANÁLISE classes e responsabilidades PROJETO classes de projeto, subsistemas, interfaces DISTRIBUIÇÃO nós físicos e os componentes em cada nó IMPLEMENTAÇÃO código fonte (DLLs, JavaBeams, ActiveX) TESTE casos de teste (baseado nos use-cases)

7 Dirigido a Use-Cases Cada use-case representa uma sequência de ações que produzem um resultado de utilidade para um ator 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

8 Dirigido a Use-Cases Porque USE-CASES??
Capturar os requisitos: o Diagrama Use-Case mostra quais atores usam quais use-cases 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 dirige Use-Cases Arquitetura do sistema influi

9 Dirigido a Use-Cases Modelo Modelo Modelo Modelo ANÁLISE PROJETO
IMPLEMENT Classe de fronteira Classe <executável> relacionamento Classe de controle <arquivo> Classe de entidades <arquivo>

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 influem Plataforma de software Disponibilidade de blocos reusáveis Arquitetura Sistemas existentes Hardware existente Requisitos não-funcionais (performance, segurança)

13 Centrado na arquitetura
Use-Case função PRODUTO forma 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

14 4 FASES CONCEPÇÃO ELABORAÇÃO CONSTRUÇÃO TRANSIÇÃO

15 Iterativo e incremental
Projetos grandes são divididos em mini-projetos Cada mini-projeto é uma iteração 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 Um grupo de use-cases que estendem usabilidade MINI- PROJETO Fatores de risco mais importantes

16 Iterativo e incremental
Fases

17 Iterativo e incremental
Cada fase termina com um MARCO (milestone): Um CICLO é uma sequência das 4 fases. Um projeto pode necessitar de vários ciclos. INICIO: o que o sistema fará? Como poderia ser a arquitetura? Prazos e custos? 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 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 CONSTRUÇÃO: software feito iterações garantindo viabilidade em forma executável -> incrementos TRANSIÇÃO: beta-teste feito por poucos usuários. Treinamento, documentação eliminar problemas e erros não identificados previamente

19 O PROCESSO UNIFICADO

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 Análise Projeto Implementação Testes ARTEFATOS
produz ARTEFATOS Análise produzido-por ARTÍFICES Projeto composto-por PASSOS e ATIVIDADES Implementação Testes

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 ARTEFATO ARTÍFICE responsável Modelo use-case atores glossários Analista de Sistemas Especificador de Use-Cases Use-cases Projetista de Interfaces Protótipos de interfaces Arquiteto Arquitetura

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

36 Análise

37 Análise Os requisitos externos são transformados em um modelo interno
preciso e completo para desenvolver o projeto do sistema MODELO USE-CASE MODELO DA ANÁLISE linguagem do usuário Linguagem do desenvolvedor Visão externa do sistema Visão interna do sistema Estruturado por use-cases Estruturado por classes Captura a funcionalidade do sistema Descreve como realizar a funcionalidade Usado para o contrato com o cliente Usado para o desenvolvedor entender o sistema Pode conter redundâncias, inconsistências, etc. Deve ser preciso e inambíguo

38 Análise - artefatos 1. MODELO DA ANÁLISE 2. CLASSE DE ANÁLISE EXEMPLO
fronteira Interface de registro 2. CLASSE DE ANÁLISE Classe de controle processar resumo do dia Boletim de controle Classe de entidades

39 Análise - artefatos Diagramas de classe 3. REALIZAÇÃO DE UM USE-CASE
Diagramas de colaboração 3. REALIZAÇÃO DE UM USE-CASE RELOGIO Processar resumo 4. 8 horas partida VENDEDOR 6. Registra resumo 1.registra partida 5. dados boletim Resumo do dia 2. abre boletim 3. registra retorno 7. mostra resumo 10. resumo comentado 3. completa boletim boletim de controle 8. analisa resumo 9. comentários Resultado do dia mostra resumos SUPERVISOR

40 Análise - artefatos 3. REALIZAÇÃO DE UM USE-CASE (cont.)
fluxo de eventos Descrição textual do diagrama de colaboração requisitos especiais Descrição textual de requisitos não-funcionais 4. PACOTES DE ANÁLISE Devem ter coesão e fraco acoplamento Candidatos a subsistemas do projeto PACOTE DE SERVIÇOS é um conjunto de ações coerentes, indivisíveis para uso em vários use-cases 5. DESCRIÇÃO DA ARQUITETURA

41 Análise ARTÍFICES arquiteto Especificador de Use-Case
responsável pela integridade global do modelo de análise (corretude, consistência e legibilidade), tanto pela sua funcionalidade quanto pela arquitetura Especificador de Use-Case responsável que a realização de um use-case corresponde a sua especificação Especificador de componentes 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 PACOTE ARQUITETO ANÁLISE MODELO
(esboço) ARQUITETO MODELO USE-CASE REQUISITOS ADICIONAIS CLASSE DE ANÁLISE (esboço) Análise arquitetural MODELO DO DOMÍNIO DESCRIÇÃO ARQUITETURA (mod. Requisitos) DESCRIÇÃO ARQUITETURA (mod. Análise)

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 ESPECIFICADOR DE USE-CASES MODELO USE-CASE REALIZAÇÃO DE UM USE-CASE (diagramas de classes e de colaboração) REQUISITOS ADICIONAIS Análise de um Use-Case MODELO DO DOMÍNIO CLASSE DE ANÁLISE (esboço) DESCRIÇÃO ARQUITETURA (mod Análise)

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 Análise de cada Use-Case (cont.) RELÓGIO boletim
de controle 5. 8 horas Processar resumo VENDEDOR 6. dados boletim partida 7. Registra resumo 2. abre boletim 1.registra partida Resumo do dia 3. registra retorno 8. mostra resumo 11. resumo comentado 4. completa boletim 9. analisa resumo 10. comentários Resultado do dia mostra resumos SUPERVISOR

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 ESPECIFICADOR DE COMPONENTES CLASSE DE ANÁLISE (esboço) Análise de uma classe CLASSE DE ANÁLISE (completa) REALIZAÇÃO DE UM USE-CASE (diagramas de classes e de colaboração)

51 Análise - passos Análise de cada classe
A1) Identificar responsabilidades Determinar os papéis de cada classe nos diferentes use-cases 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 A3) Identificar associações e agregações A4) Identificar generalizações A5) Determinar requisitos especiais

52 Análise - passos Análise de cada pacote
Rever as questões de acoplamento fraco e coesão Garantir que cada pacote preenche sua função Rever as dependências entre pacotes de acordo com associações estáticas ou dinâmicas entre as classes, criadas nos passos anteriores

53 Projeto OBJETIVOS 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

54 Projeto

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 4. SUBSISTEMA DE PROJETO (pacotes de análise, componentes, produtos de software, sistemas existentes) - SUBSISTEMAS DE SERVIÇO 5. INTERFACE (separa funcionalidade de implementação) 6. ARQUITETURA (VISÃO DO PROJETO) (1. Subsistemas, interfaces e dependências Classes chave, classes ativas Realização de use-cases centrais ao sistema 7. MODELO DE DISTRIBUIÇÃO (Diagrama de nós e conexões) 8. ARQUITETURA (VISÃO DO MODELO DE DISTRIBUIÇÃO)

58 Projeto - artífices Arquiteto Especificador de use-cases
MODELO DO PROJETO Arquiteto MODELO DE DISTRIBUIÇÃO ARQUITETURA Especificador de use-cases REALIZAÇÃO DE USE CASE CLASSE DE PROJETO Especificador de componentes SUBSISTEMA INTERFACE

59 Projeto - passos ESPECIFICADOR DE USE-CASES ESPECIFICADOR
DE COMPONENTES ARQUITETO Projeto da arquitetura Projeto de uma classe Projeto de um use-case Projeto de um subsistema

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 Subsistema novo Software existente Pacote (análise) 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
OBJETIVO: identificar classes de projeto distribuir o comportamento entre os objetos definir requisitos das operações requisitos de implementação do 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

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
atributos operações e sua realização relacionamentos estados dependências interfaces requisitos de implementação ASPECTOS: 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

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 É UM PACOTE CONTENDO ELEMENTOS DO PROJETO Estereótipos: <<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)

72 Implementação - artefatos
2. COMPONENTE - exemplos <<executable>> ProcessaBoletim.java BOLETIM __________ realiza gera gera <<table>> Resumo realiza RESUMO __________ <<table>> Contrato

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) Decomposição em subsistemas, compostos de interfaces e componentes Componentes chave 6. PLANO DE INTEGRAÇÃO 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
MODELO DA IMPLEMENTAÇÃO MODELO DE DISTRIBUIÇÃO Arquiteto DESCRIÇÃO DA ARQUITETURA COMPONENTE Engenheiro de componentes SUBSISTEMA DE IMPLEMENTAÇÃO INTERFACE Integrador do sistema PLANO DE INTEGRAÇÃO

76 Implementação - artífices

77 Implementação PASSOS Implementação arquitetural Integrar sistemas
Implementar subsistema Implementar uma classe Testar componentes

78 Projeto - passos ENGENHEIRO DE INTEGRADOR COMPONENTES DE SISTEMAS
ARQUITETO Implementar um subsistema Implementação arquitetural Teste de unidade Integrar sistemas Implementar uma classe

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) Passos Delimitar o escopo do sistema Determinar arquitetura candidata (elementos novos, arriscados) Identificar riscos críticos Identificar potenciais usuários ou clientes do sistema

85 As quatro Fases Fase de Elaboração determina uma arquitetura estável
Passos 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.

86 As quatro Fases Fase de Construção
determina capacidades operacionais iniciais Passos 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

87 As quatro Fases Fase de transição
transforma versão beta em um sistema operacional Passos 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

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
ITERAÇÃO planejamento consolidação requisitos análise projeto Implement. testes

90 Iterativo e incremental
tempos por fase milestones iterações por fase plano do projeto Planejando as FASES Planejando as ITERAÇÕES cronograma conteúdo: - quais use-cases serão realizados iterações anteriores e posteriores

91 Riscos descrição Gerenciar uma
prioridade (crítico, signifcante, rotineiro) impacto responsabilidades contingência (o que fazer?) Gerenciar uma lista de riscos: Possíveis riscos: relacionados a um produto não conseguir a arquitetura não realizar os requisitos