Programa do Módulo 2. Processo Unificado: Visão Geral



Documentos relacionados
O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

Processo de Desenvolvimento Unificado

Para cada fase consideramos. Tempo para um projeto típico Tempo para um projeto Complexo. Arquitetura do Processo Unificado. A meta a ser atingida

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

Visão Geral do RUP Rational Unified Process. Jorge Fernandes UFRN Junho de 2002

O modelo unificado de processo. O Rational Unified Process, RUP.

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

Projeto de Sistemas I

RUP. Evolução. Principais Características do RUP. Principais Características do RUP RUP

Processos de Desenvolvimento de Software. Prof. Hélio Engholm Jr

Metodologia e Gerenciamento do Projeto na Fábrica de Software

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

O Processo Unificado

Introdução ao RUP Rational Unified Process. por Denize Terra Pimenta Outubro/2004

Processo Unificado (RUP)

3. Fase de Planejamento dos Ciclos de Construção do Software

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

Capítulo 2. Processos de Software Pearson Prentice Hall. Todos os direitos reservados. slide 1

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

ENGENHARIA DE SOFTWARE I

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS

Feature-Driven Development

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto

Processos de Software

Processos de Desenvolvimento de Software

Felipe Denis M. de Oliveira. Fonte: Alice e Carlos Rodrigo (Internet)

Introdução ao OpenUP (Open Unified Process)

Concepção e Elaboração

Ciclo de Vida Clássico ou Convencional CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS. Ciclo de Vida Clássico ou Convencional. Enfoque Incremental

Professor: Curso: Disciplina:

Introdução ao Processo Unificado (PU)

A Disciplina Gerência de Projetos

Engenharia de Software

Engenharia de Software I

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

Especialização em Engenharia de Software e Banco de Dados

Metodologia e Gerenciamento do Projeto na Fábrica de Software v.2

Unified Process. Sueleni Mendez Batista. Orientadora: Dra. Elisa Hatsue Moriya Huzita

PROJETO DE FÁBRICA DE SOFTWARE

RUP Rational Unified Process

UML - Unified Modeling Language

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite (81 )

Gerenciamento de Projetos Modulo III Grupo de Processos

Engenharia de Software I

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

DESENVOLVIMENTO DE SISTEMAS

Princípios da Engenharia de Software Aula 02. Prof.: Franklin M. Correia

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA

Pós Graduação Engenharia de Software

Processos de gerenciamento de projetos em um projeto

Modelagem OO com UML. Vítor E. Silva Souza ~ vitorsouza

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0

ISO/IEC 12207: Gerência de Configuração

Engenharia de Software II

Qualidade de Software. Profa. Cátia dos Reis Machado

Guia de utilização da notação BPMN

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

Engenharia de Software II

Desenvolvimento Iterativo. Unified Process (UP) Esta abordagem ao desenvolvimento

Uma Abordagem usando PU

CHECK - LIST - ISO 9001:2000

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga

MASTER IN PROJECT MANAGEMENT

Curso: Engenharia de Software com Ênfase em Padrões de Software (UECE Universidade Estadual do Ceará) RUP

Histórico da Orientação a Objetos Ciclo de vida de Desenvolvimento de SW

Análise e Projeto Orientados a Objetos Aula IV Requisitos. Prof.: Bruno E. G. Gomes IFRN

Engenharia de Requisitos

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como:

Engenharia de Software II: Definindo Projeto III. Prof. Msc Ricardo Britto DIE-UFPI

Engenharia de Software II

O Processo Unificado: Captura de requisitos

Gerência de Projetos

Testes de Software. Testes de Software. Teste de Validação. Teste de Defeito. Modelo de Entrada e Saída. Modelo de Entrada e Saída

Apresentar os conceitos básicos da metodologia de desenvolvimento Processo Unificado, utilizando como aporte o Processo Unificado Rational RUP

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software.

PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE 1. VISÃO GERAL 1.1. PROCESSOS EM GERAL

Fundamentos em Teste de Software. Vinicius V. Pessoni

Engenharia de Software II

Project and Portfolio Management [PPM] Sustainable value creation.

A Linguagem de Modelagem Unificada (UML)

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial

As principais características da abordagem de um banco de dados versus a abordagem de processamento de arquivos são as seguintes:

Gerenciamento de projetos.

Gerenciamento de Projetos Modulo III Grupo de Processos

Prova de Conhecimento para Consultores de Implementação MPS.BR INSTRUÇÕES

Ideal para que tipo de empresa (equipe): pequena, média, grande? Em software onde os requisitos não são conhecidos é recomendado o uso do XP? Por quê?

Gerenciamento da Integração (PMBoK 5ª ed.)

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS

Transcrição:

9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo: Conjunto de atividades executadas para transformar um conjunto de requisitos do cliente em um Sistema de Software [SCO02]. Processo Unificado PU tem suas origens no trabalho que Ivar Jacobson desenvolveu na Ericsson no final da década de 1960 Em 1987 Jacobson fundou a Objectory AB e iniciou com seus associados o desenvolvimento do Objectory (processo e produto) A Rational comprou a Objectory AB e apareceu o ROP (Rational Objectory Process) Em 1998 o ROP torna-se o RUP, Rational Unified Process, ou Processo Unificado da Rational. O Processo Unificado é uma estrutura genérica de processo que pode ser adaptada a necessidades particulares, através da adição ou supressão de atividades O RUP é uma versão especializada do Processo Unificado. O Processo Unificado é baseado em três princípios chave: Dirigido por Casos de Uso Centrado na Arquitetura Iterativo e Incremental Todo o material sobre o RUP é fortemente baseado no Capítulo 1 da referência [SCO02].

Processo Unificado Visão Geral: Dirigido por Casos de Uso PU: Dirigido por Casos de Uso 9.3 Casos de Uso constituem uma seqüência de ações executadas por um ou mais atores ou pelo próprio sistema e que produzem um ou mais resultados de valor para um ou mais atores. Casos de Uso constituem a força condutora do desenvolvimento no processo unificado Eles são utilizados para dirigir o desenvolvimento, desde a fase de análise de requisitos até a fase de aceitação do código. Casos de Uso são adequados na captura dos requisitos, nas tarefas da análise, projeto e implementação por diversas razões: São expressos na perspectiva dos usuários do sistema (descrição nos termos do usuário) em língua natural e apresentam portanto uma maior facilidade de compreensão dos requisitos do sistema do que os documentos de requisitos típicos; Oferecem um alto grau de rastreamento dos requisitos nos modelos que resultam do seu desenvolvimento posterior [SCO02]; Oferecem um meio simples de decompor os requisitos em pedaços que permitem alocação de trabalho a sub-equipes e também facilitam a gerência do projeto [SCO02]. Processo Unificado Visão Geral: Centrado na Arquitetura PU: Centrado na Arquitetura I 9.4 No Processo Unificado a Arquitetura é definida como o alicerce fundamental sobre o qual ele se erguerá Ela deve ser uma das preocupações principais da equipe de projeto devendo, juntamente com os casos de uso, orientar a exploração de todos os aspectos do sistema. A Arquitetura pode ser vista como A expressão de uma visão comum que todos os membros de um equipe devem compartilhar a fim de que o sistema resultante seja adequadamente robusto, flexível, expansível e de custo viável [SCO02]. Dentro do Processo Unificado a Arquitetura é especificada em termos de visões de cinco modelos obtidos a partir de Cinco Workflows (Requisitos, Análise, Projeto, Implementação e Teste) Essas visões juntas formam a Descrição da Arquitetura do Sistema.

Processo Unificado Visão Geral: Centrado na Arquitetura PU: Centrado na Arquitetura II 9.5 Razões chave pelas quais a Arquitetura é tão importante para o Processo Unificado: Entender a Visão Global: a descrição da arquitetura é o eixo central que leva a um melhor entendimento da Visão Global do sistema em construção; Organizar o Esforço de Desenvolvimento: como a arquitetura define corretamente porções discretas do sistema, e a interface entre elas, facilita o esforço de desenvolvimento e o trabalho em equipes; Facilitar as Possibilidades de Reuso: uma arquitetura bem definida favorece a identificação de possibilidades de reuso de componentes presentes no sistema em construção; Facilitar a Evolução do Sistema: uma arquitetura sólida oferece um conjunto de pontos de referência essenciais sobre os quais o trabalho de desenvolvimento futuro poderá se apoiar [SCO02]; Dirigir os Casos de Uso: a arquitetura guia a seleção e exploração dos casos de uso, pois decisões sobre a implementação do sistema têm forte influência na escolha dos casos de uso na fase de projeto, pois se pode focar aqueles que agregarão valor a arquitetura. Processo Unificado Visão Geral: Iterativo e Incremental PU: Iterativo e Incremental I 9.6 O Processo Unificado tem como característica ser Iterativo e Incremental: Iterativo: uma iteração é um mini-projeto que resulta em uma versão do sistema que pode ser liberada interna ou externamente Incremental: um incremento nas características das versões do sistema liberadas é obtido em cada iteração. Vantagens do desenvolvimento iterativo e incremental: Progresso lógico para uma arquitetura robusta: as iterações seguidas conduzem a definição incremental de uma arquitetura robusta para o sistema Problemas graves podem ser eliminados nas fases iniciais da modelagem; Manipulação das mudanças contínuas dos requisitos: como em cada iteração é construído um protótipo funcional que implementa uma funcionalidade específica do sistema (um ou mais casos de uso) se pode negociar progressivamente os requisitos;

Processo Unificado Visão Geral: Iterativo e Incremental PU: Iterativo e Incremental II 9.7 Vantagens do desenvolvimento iterativo e incremental continuação...: Flexibilidade na mudança do plano de iterações: como cada iteração é um mini-projeto e como ao final de cada iteração se deve reavaliar os riscos, os planos de iterações podem ser redefinidos em função de problemas e/ou soluções encontrados; Integração contínua: a cada iteração se estará integrando uma nova funcionalidade ao sistema Isto permite que se avalie efetivamente o progresso obtido e até que se possa descartar, sem grandes problemas, os resultados obtidos em uma iteração; Entendimento Precoce: como o sistema é construído incrementalmente a compreensão pode ser feita passo-a-passo e alternativas podem ser analisadas sem grandes riscos (erros impactam somente a iteração); Foco contínuo sobre riscos: talvez a principal vantagem do PU As iterações devem ser planejadas buscando concentrar os esforços iniciais nos riscos mais críticos ao projeto. Deve-se minimizar os riscos, no maior grau possível, durante cada iteração, de modo que cada uma delas tenha menos riscos e que estes sejam de menor importância que em iterações anteriores [SCO02]. Processo Unificado PU: Iterativo e Incremental III 9.8 Cada fase do Processo Unificado (Concepção, Elaboração, Construção e Transição) está dividida em iterações que produzem cada uma dela um mini-projeto. Uma iteração típica cruza todos os Cinco Workflows (Requisitos, Análise, Projeto, Implementação e Teste) em maior ou menor grau Cada iteração resulta em um Incremento que é uma versão do sistema que contenha funcionalidade adicionada ou melhorada em relação a uma versão elaborada em uma iteração anterior.

Processo Unificado PU: Iterativo e Incremental IV 9.9 Com o enfoque iterativo e incremental o processo de desenvolvimento é iniciado com a avaliação dos riscos relevantes (inclusive os ligados aos requisitos), práticas, tecnologias e políticas e assegurando que o escopo do projeto seja definido para a satisfação de todos os interessados [SCO02]. Riscos Iniciais Escopo Inicial do Projeto Definir iterações que abordem os maiores riscos Rever o Plano do Projeto Original Custo Listas Alcance/Conteúdo Cada iteração resulta em uma versão executável Iteração N Planejar a Iteração N Custo Listas Desenvolver a Iteração N Coletar custos e métricas de qualidade Avaliar a Iteração N Risco Eliminado Revisar os riscos redefinir as prioridades para os riscos Processo Unificado PU: Iterativo e Incremental V 9.10 Na seqüência do processo se deve [SCO02]: 1. Definir a primeira iteração focando os riscos maiores e mais críticos, ou seja, deve-se inicialmente procurar resolver os maiores problemas Deve-se abordar inicialmente as coisas mais difíceis; Definir iterações Riscos/Escopo Rever o Plano do Projeto Original Iteração N 2. Delinear um plano para a iteração em um nível apropriado de detalhe; Revisar os riscos Planejar /Desenvolver Iteração N 3. Executar as atividades apropriadas, ou seja, aquelas associadas aos workflows de Requisitos, Análise, Projeto Implementação e Teste; Avaliar a Iteração N 4. Fazer uma análise ao término da iteração sobre o resultado obtido com o incremento; Risco Eliminado 5. Descartar os riscos que foram adequadamente eliminados no incremento. Na seqüência atualizar a lista de riscos; 6. Revisar o plano completo do projeto em resposta ao sucesso ou fracasso relativo da iteração; 7. Prosseguir com a próxima iteração.

Processo Unificado Processo Unificado 9.11 Matricial: Fases x Worflows Workflows Processo Unificado As Quatro Fases 9.12 A vida de um sistema de software pode ser descrita por uma séria de ciclos, onde cada ciclo termina com a liberação de uma versão do sistema para os clientes No Processo Unificado cada ciclo contém quatro fases (que podem ser realizadas em uma ou mais iterações), sendo que cada fase indica o tempo decorrido entre dois marcos principais [SCO02]. Ao final de uma fase os gerentes tomam decisões sobre se prosseguem ou não com o desenvolvimento Caso decidam prosseguir, devem avaliar as necessidades em relação ao escopo, orçamento e cronograma do projeto [SCO02]. 1. Concepção 2. Elaboração 3. Construção 4. Transição Iteração 1 Objetivos do Ciclo de Vida Iteração 2 Iteração x Capacidade Ope racional Inicial Iteração x+1 Iteração y Arquitetura do Ciclo de Vida Iteração y+1 Iteração z Liberação do Produto Marcos Principais [SCO02]

Processo Unificado As Quatro Fases 1. Concepção 9.13 Esta fase tem como objetivo principal estabelecer a viabilidade do sistema a ser construído, tendo como principais tarefas [SCO02]: Definir o escopo do sistema; Esboçar uma Arquitetura Candidata composta pelas versões iniciais dos seis diferentes modelos (Casos de Uso, Análise, Projeto, Implementação, Instalação e Teste); Identificar os riscos críticos e determinar quando e como o projeto os abordará; Iniciar uma análise econômica para o projeto. O principal marco associado a esta fase é denominado Objetivos do Ciclo de Vida e os sinais de que o projeto o atingiu são [SCO02]: Principais envolvidos concordam sobre o escopo proposto para o sistema; A arquitetura candidata equaciona claramente um conjunto de requisitos críticos de alto nível; A análise econômica do projeto é sólida o bastante para justificar a continuação do desenvolvimento. Processo Unificado As Quatro Fases 2. Elaboração 9.14 Esta fase tem como principal objetivo definir as bases nas quais a construção do novo sistema é viável em relação aos diversos tipos de restrições (financeira, de cronograma, etc.) definidas Tem como principais tarefas [SCO02]: Capturar a maioria dos requisitos funcionais válidos restantes; Expandir a arquitetura candidata em uma Base Arquitetônica que contenha versões expandidas dos seis modelos inicializados durante a fase de concepção; Abordar riscos significativos de forma contínua; Finalizar a análise econômica do projeto e preparar um plano que contenha detalhes suficientes para orientar a próxima fase. O principal marco associado a esta fase é denominado Arquitetura do Ciclo de Vida e os sinais de que o projeto o atingiu são [SCO02]: A maioria dos requisitos funcionais do sistema foi capturada nos casos de uso; A base arquitetônica constitui um sistema enxuto e pequeno que servirá como alicerce sólido para o desenvolvimento progressivo do projeto; A análise econômica foi aprovada e há um plano de projeto que descreve como a fase de Construção irá ser desenvolvida.

Processo Unificado As Quatro Fases 3. Construção 9.15 Esta fase tem como principal objetivo construir um sistema capaz de operar bem em ambientes beta de clientes, tendo como principal tarefa a construção do sistema de modo iterativo e incremental para que se possa comprovar que a viabilidade do sistema está sempre evidente em uma forma executável [SCO02]: O principal marco associado a esta fase é denominado Capacidade Operacional Inicial e o sinal de que o projeto o atingiu é dado pelo fato de um conjunto de clientes ter em mãos um sistema que seja operacional Este sistema pode ser mais ou menos completo [SCO02]. Processo Unificado As Quatro Fases 4. Transição 9.16 Esta fase tem como principal objetivo entregar um sistema completamente funcional aos clientes. Nesta fase se deve identificar e corrigir todos os problemas descobertos no sistema a ser entregue. O principal marco associado a esta fase é denominado Liberação do Produto [SCO02].

Processo Unificado 9.17 Workflow: Artefatos, Trabalhadores e Atividades Um Workflow é um sistema que permite a automatização de um fluxo de informação em uma empresa, por exemplo, transmitindo automaticamente documentos entre pessoas (http://fr.wikipedia.org/wiki/workflow). No Processo Unificado, um workflow é definido como Um conjunto de atividades que vários trabalhadores do projeto executam [SCO02]. No Processo Unificado workflows têm os seguintes elementos-chave [SCO02]: Artefatos: qualquer porção significativa de informação interna ou a ser fornecida a interessados externos que desempenhem um papel no desenvolvimento do sistema Modelos, plano de projeto, etc.; Trabalhadores: um papel que um indivíduo pode desempenhar no projeto. Trabalhadores produzem artefatos e uma pessoa pode atuar como mais de um tipo de trabalhador. Trabalhadores são diferentes de atores: os primeiros participam do desenvolvimento do sistema enquanto os atores estão envolvidos na utilização do sistema Analista, programador, etc.; Atividades: uma tarefa que um trabalhador executa a fim de produzir um artefato Construir um modelo, implementar uma classe, etc. Processo Unificado Os Cinco Workflows 9.18 No Processo Unificado, cinco workflows atravessam o conjunto das quatro fases apresentadas: 1. Requisitos; 2. Análise; 3. Projeto; 4. Implementação; 5. Teste.

Processo Unificado Os Cinco Workflows 9.19 No Processo Unificado, cinco workflows atravessam o conjunto das quatro fases apresentadas: 1. Requisitos; 2. Análise; 3. Projeto; 4. Implementação; 5. Teste. Cada workflow agrega um série de atividades que devem ser realizadas por diferentes membros do projeto. [IBM03] Processo Unificado Os Cinco Workflows 1. Workflow de Requisitos As atividades envolvidas neste workflow têm como principal objetivo a construção de um Modelo de Casos de Uso que capture os requisitos funcionais do sistema sendo definido. Este modelo, que serve de alicerce para todo o desenvolvimento, auxilia os envolvidos no projeto a chegar a um acordo sobre as capacidades do sistema e as condições que ele deve satisfazer. Modelo de Projeto Especificado por Implementado por Modelo de Análise Modelo de Casos de Uso Realizado por Distribuído por Verificado por Modelo de Instalação 9.20 Modelo de Implementação Modelo de Teste [SCO02]

Processo Unificado Os Cinco Workflows Workflow de Requisitos 9.21 Workflow de Requisitos: Elementos Chave Artefatos: Modelo de Domínio (captura as entidades e conceitos importantes do mundo real que pertencem ao espaço do problema), Modelo de Negócio (Dois modelos, Caso de Uso de Negócio e Objetos de Negócio), Glossário, Ator, Casos de Uso, Protótipo de Interface com Usuário e Modelo de Casos de Uso. Trabalhadores: Analista de Sistemas, Especificador de Caso de Uso, Projetista de Interface com o Usuário e Arquiteto. Atividades: Construir o Modelo de Domínio, Construir o Modelo de Negócio, Descobrir Atores e Casos de Uso, Prototipar a Interface com o Usuário, Atribuir prioridades aos Casos de Uso, Detalhar um Caso de Uso e Estruturar o Modelo de Casos de Uso. [SCO02] Processo Unificado Os Cinco Workflows 2. Workflow de Análise 9.22 As atividades envolvidas neste workflow tem como principal objetivo a construção do Modelo de Análise que deve auxiliar os desenvolvedores a refinar e estruturar os requisitos funcionais capturados nos modelos de caso de uso. Este modelo deve ser composto de Casos de Uso Realização que sejam mais apropriados ao trabalho que deve ser executado nas atividades dos workflows de projeto e implementação.

Processo Unificado Os Cinco Workflows Workflow de Análise Workflow de Análise: Elementos Chave 9.23 Artefatos: Classes de Análise (classe somente com atributos), Realização de Análise de Casos de Uso (descrito como um Diagrama de Colaboração), Pacote de Análise (composto de classes de análise e realizações de análise) e Modelo de Análise (pacote de pacotes de análise) Trabalhadores: Arquiteto, Engenheiro de Casos de Uso e Engenheiro de Componentes. Atividades: Efetuar Análise Arquitetônica (criar um esboço do modelo de análise e da arquitetura como um todo), Analisar um Caso de Uso (construir uma realização para um caso de uso), Analisar uma Classe (expandir a definição de uma classe de análise participante de um caso de uso) e Analisar um Pacote (construir um pacote de análise altamente coeso). [SCO02] Processo Unificado Os Cinco Workflows 3. Workflow de Projeto 9.24 As atividades envolvidas neste workflow tem como principal objetivo a construção do Modelo de Projeto que irá descrever as realizações físicas dos casos de uso a partir dos modelos de caso de uso e do modelo de análise. O modelo criado neste workflow serve como uma abstração do Modelo de Implementação. Além do modelo de projeto este workflow aborda também o Modelo de Instalação que define a organização física do sistema em termos de recursos computacionais.

Processo Unificado Os Cinco Workflows Workflow de Projeto Workflow de Projeto: Elementos Chave 9.25 Artefatos: Classes de Projeto (classe com atributos e operações e detalhes como visibilidade), Realização de Projeto de Caso de Uso (definir um caso de uso através de Diagramas de Seqüência), Interface (coleção de operações que representam serviços oferecidos por classes, subsistemas ou componentes), Subsistemas de Projeto (pacote UML contendo classes de projeto, interfaces de classes/subsistemas e realizações de projeto de caso de uso), Modelo de Projeto (um dos pacotes de projeto), Descrição da Arquitetura Visão do Modelo de Projeto, Modelo de Instalação (Diagrama de Instalação UML) e Descrição da Arquitetura Visão do Modelo de Instalação. Trabalhadores: Arquiteto, Engenheiro de Casos de Uso e Engenheiro de Componentes. Atividades: Efetuar Projeto Arquitetônico (criação dos modelos de instalação e de projeto), Projetar um Caso de Uso (construção de uma realização de projeto de caso de uso para um caso de uso), Projetar uma Classe (expansão da definição de uma classe de projeto com detalhes como lista de parâmetros e tipos de retorno) e Projetar um Subsistema (projeto do subsistema de projeto esboçado durante o projeto arquitetônico) [SCO02] Processo Unificado Os Cinco Workflows 4. Workflow de Implementação 9.26 As atividades envolvidas neste workflow têm como principal objetivo a construção do Modelo de Implementação que serve como uma descrição de como os elementos deste modelo (arquivos fonte, bibliotecas, componentes) são empacotados como componentes de software.

Processo Unificado Os Cinco Workflows Workflow de Implementação Workflow de Implementação: Elementos Chave Artefatos: Componente (parte física e substituível de um sistema que está em conformidade com um conjunto de interfaces e o realiza), Interface, Subsistema de Implementação (pacote UML com componentes e interfaces conectadas a componentes e ao próprio sistema), Modelo de Implementação (pacote UML com pacotes de implementação), Descrição da Arquitetura Visão do Modelo de Implementação e Plano de Integração de Construções (descrição das construções que ocorrerão na interação com descrição da funcionalidade a ser implementada em termos de caso de uso e partes do modelo de implementação afetadas pela construção e termos de componentes e subsistemas). Trabalhadores: Arquiteto, Engenheiro de Componentes e Integrador de Sistemas. Atividades: Efetuar Implementação Arquitetônica (identificação dos componentes significativos da arquitetura e mapeamento dos componentes executáveis aos nós de processamento), Implementar uma Classe (geração do código), Efetuar Teste de Unidade (produzir código executável a partir de um componente e efetuar testes sobre este código independentemente de outros componentes), Implementar um Subsistema (construir um subsistema de implementação esboçado durante a implementação arquitetônica) e Integrar o Sistema (criar ou expandir o plano de integração de construções para refletir o conteúdo da próxima interação e integrar as várias peças da construção antes do teste de integração). 9.27 [SCO02] Processo Unificado Os Cinco Workflows 9.28 5. Workflow de Teste As atividades envolvidas neste workflow tem como principal objetivo a construção do Modelo de Teste que descreve como os testes de integração e de sistema irão ser aplicados aos componentes definidos no modelo de implementação. O modelo de teste irá descrever também como os testes de integração, de sistema e de unidade serão realizados. Muitas vezes os modelos de teste são derivados diretamente dos casos de uso Testes de caixa-preta são realizados utilizando a descrição textual dos casos de uso e testes de caixa-branca são realizados utilizando os casos de uso realização.

Processo Unificado Os Cinco Workflows Workflow de Teste Workflow de Teste: Elementos Chave Artefatos: Caso de Teste (especificação da maneira pela qual se deve testar uma parte do sistema, usando testes caixa-preta a partir de casos de uso e testes caixa-branca para casos de uso realização), Procedimento de Teste (como exercitar um ou mais casos de teste como um todo ou em partes), Componente de Teste (código que automatiza todo ou partes do procedimento de teste), Modelo de Teste (pacote UML com casos, procedimentos e componentes de teste para o sistema), Plano de Teste (descrição dos recursos, cronograma e da estratégia de aplicação dos testes), Defeito (problema a ser tratado) e Avaliação de Teste. Trabalhadores: Engenheiro de Teste, Engenheiro de Componentes, Testador de Integração e Testador de Sistema. Atividades: Planejar Teste (desenvolvimento de um plano deteste para uma iteração), Projetar Teste (projetar os vários níveis de teste e os procedimentos a serem seguidos na condução dos testes), Implementar Teste (criação de componentes de teste), Efetuar Teste de Integração, Efetuar Teste de Sistema (testar cada construção d sistema), Avaliar Teste (avaliar os resultados em comparação aos objetivos descritos no plano de teste). 9.29 [SCO02] Processo Unificado Rational Unified Process 9.30