Processo Unificado de Desenvolvimento de Software

Processo Unificado de Processo Unificado de Desenvolvimento de Desenvolvimento de

SoftwareSoftwareG. Booch, Ivar Jacobson, James Rumbaugh

Rational Software Corporation

UNIVERSIDADE FEDERAL DA PARAÍBADEPARTAMENTO 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

PESSOASPESSOAS financiam, escolhem, desenvolvem, gerenciam, testam, usam e são beneficiadas por produtos

PROJETOSPROJETOS 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

faseiteração

P4 = Pessoa, Projeto, Produto, Processo

PRODUTOPRODUTO 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)

PROCESSOPROCESSO define quem faz o que, quando e como

PUPU é um processo. Considera fatores organizacionais, do domínio, ciclo de vida e técnicos

Modelos

REQUISITOSREQUISITOS - 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ÁLISEANÁLISE classes e responsabilidades

PROJETOPROJETO classes de projeto, subsistemas, interfaces

IMPLEMENTAÇÃOIMPLEMENTAÇÃO código fonte (DLLs, JavaBeams, ActiveX)

TESTETESTE casos de teste (baseado nos use-cases)

DISTRIBUIÇÃODISTRIBUIÇÃ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


Porque USE-CASES??

Capturar os requisitos: o Diagrama Use-Case mostra quais atores usam quais use-cases

Use-Cases Arquitetura do sistemadirige

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


Classe defronteira

Classe decontrole

Classe deentidades

ModeloUSE-CASE

ModeloANÁLISE

Modelo PROJETO

Classe

Modelo IMPLEMENT

<executável>

<arquivo>

<arquivo>

relacionamento


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 arquivosque 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.


Use-Cases

Plataforma de software

Disponibilidade de blocosreusáveis

Sistemas existentes

Hardware existente

Requisitos não-funcionais(performance, segurança)

Arquitetura

influem


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 subsistemapara cada um

Pela especificação dos subsistemas aparecem mais detalhes da arquitetura e novos use-casesRepetir 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


Concepção Elaboração Construção Transição

Requisitos

Análise

Projeto

ImplementaçãoTestes

Iter.#1

Iter.#2

_ _ _ _ _ Iter.#n-1

Iter.#n

Fases


Cada fase termina com um MARCO (milestone):

INICIOINICIO: 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)


ELABORAÇÃOELABORAÇÃO: use-cases especificados e esqueleto da arquitetura definido

CONSTRUÇÃOCONSTRUÇÃO: software feito

TRANSIÇÃOTRANSIÇÃ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 O

PPROCESSO ROCESSO

UUNIFICADONIFICADO

EXEMPLODesenvolver 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çõesdo 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

RequisitosARTEFATOS

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


ARTÍFICES

Analista de sistemas

arquiteto

Especificador de Use-Case

projetista de interfaces


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)


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



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



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)




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




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


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?


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




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>>)



ATIVIDADES

usabilidade

requisitos de interfaces metáfora, frequência de uso, ..

documentação

confiabilidade

tolerância a falhas.



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

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

Os requisitos externos são transformados em um modelo interno preciso e completo para desenvolver o projeto do sistema

Análise - artefatos

2. CLASSE DE ANÁLISE

Classe defronteira

Classe decontrole

Classe deentidades

EXEMPLO

Interface deregistro

processarresumo do dia

Boletim decontrole

1. MODELO DA ANÁLISE


3. REALIZAÇÃO DE UM USE-CASE

Diagramas de classe

Diagramas de colaboração

Resultadodo dia

Processarresumo

boletim de controle

VENDEDOR

partida

Resumo do dia

SUPERVISOR

mostraresumos

1.registra partida

3. registra retorno2. abre boletim

3. completa boletim

5. dados boletim

6. Registra resumo

8. analisa resumo

9. comentários

7. mostra resumo

10. resumocomentado

RELOGIO

4. 8 horas


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 usoem 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



MODELOUSE-CASE

REQUISITOS ADICIONAIS

MODELODO DOMÍNIO

DESCRIÇÃOARQUITETURA(mod. Requisitos)

ARQUITETO

DESCRIÇÃOARQUITETURA

(mod. Análise)

CLASSE DE ANÁLISE

(esboço)

PACOTEANÁLISE

(esboço)

Análise - passos



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

MODELOUSE-CASE

REQUISITOS ADICIONAIS

MODELODO DOMÍNIO

DESCRIÇÃOARQUITETURA

(mod Análise)

ESPECIFICADORDE USE-CASES

CLASSE DE ANÁLISE

(esboço)

REALIZAÇÃODE UM USE-CASE

(diagramas de classese 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

Resultadodo dia

Processarresumo

boletim de controleVENDEDOR

partida

Resumo do dia

mostraresumos

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. resumocomentado

5. 8 horas

Análise - passos

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 classeREALIZAÇÃO

DE UM USE-CASE(diagramas de classes

e de colaboração)

ESPECIFICADORDE 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 interfacesclasses 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

MODELO DE ANÁLISE MODELO DE PROJETO

conceitual físico

Genérico (c.r. projeto) específico

3 tipos de classes Depende da implementação

Menos formal Mais formal

Mais rápido (1/5 do projeto Mais demorado (5 x análise)Poucos níveis Muitos níveisMenos dinamica Mais dinâmica, foco na

sequenciaNão se mantém no ciclo Se manté em todo ciclo

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 deum use-case

Projeto de uma classe

Projeto deum subsistema

Projeto daarquitetura

ARQUITETOESPECIFICADORDE COMPONENTES

ESPECIFICADORDE 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


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:


2. COMPONENTE - exemplos

<<executable>>ProcessaBoletim.java

<<table>>Resumo

BOLETIM____________________

RESUMO____________________ <<table>>

Contrato

realiza

realiza

geragera


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


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

Integrarsistemas

Implementaruma classe

Implementarum subsistemaImplementação

arquitetural

ARQUITETOENGENHEIRO DE COMPONENTES

INTEGRADOR DE SISTEMAS

Teste deunidade

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

Concepção Elaboração Construção Transição

Requisitos

Análise

Projeto

ImplementaçãoTestes

Iter.#1

Iter.#2

_ _ _ _ _ Iter.#n-1

Iter.#n

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


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.


requisitos análise projeto Implement. testes

planejamento consolidação

ITERAÇÃO


Planejando asITERAÇÕ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 umalista 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

Processo Unificado de Desenvolvimento de Software

Technology

Transcript of Processo Unificado de Desenvolvimento de Software