Você está na página 1de 157

RUP

Rational Unified Process

RUP
Set/2005

Apostila desenvolvida especialmente para a Target Informtica Ltda. Sua cpia ou reproduo expressamente proibida. Ago/2005

RUP

Sumrio
1. Viso Geral.................................................................................1 Objetivos.......................................................................................................................................2 Viso Geral...................................................................................................................................3 Conceitos Chave...........................................................................................................................4 Processo de Desenvolvimento de Software..........................................................................4 Roles (Papis).......................................................................................................................5 Activity (Atividade)..............................................................................................................6 Steps (Tarefas)......................................................................................................................6 Work Guidelines (Guias de Trabalho)..................................................................................7 Artefato (Artifact).................................................................................................................7 Template (Modelo).............................................................................................................10 Report (Relatrio)...............................................................................................................10 Artifact Guidelines and Checkpoints (Guias de Artefatos e Pontos de Verificao).........10 Workflows (Disciplinas).....................................................................................................11 Core Workflows (Workflows Principais)...........................................................................12 Workflow Details (Detalhes de Workflows)......................................................................14 Outros Conceitos.................................................................................................................15 Tool Mentor........................................................................................................................15 Conceitos............................................................................................................................16 A Essncia dos Processos...........................................................................................................17 Introduo...........................................................................................................................17 Definir uma Viso...............................................................................................................17 Usar uma Arquitetura..........................................................................................................18 Planejamento e Controle.....................................................................................................18 Gerenciar pelo Planejamento..............................................................................................18 Riscos Identificar e Mitigar.............................................................................................19 Issues (Questes) Definir Responsveis e Controlar.......................................................19 Business Case (Caso de Negcio) Examinar o Caso de Negcio....................................19 Evaluation (Avaliao) Avaliar regularmente os resultados...........................................20 Implementar e Testar Iterativamente..................................................................................20 Controlar Mudanas............................................................................................................20 Entregar um Produto Utilizvel..........................................................................................20 Adaptar o Processo.............................................................................................................21 Concluso............................................................................................................................21 Melhores Prticas........................................................................................................................22 Desenvolver em Iteraes...................................................................................................22 Gerenciar Requisitos...........................................................................................................25 Usar Arquitetura de Componentes......................................................................................27 Modelar Visualmente (UML).............................................................................................29 Verificar Qualidade.............................................................................................................29 Controlar Mudanas............................................................................................................32 Exerccios....................................................................................................................................34 2. Fases..........................................................................................1 Objetivos.......................................................................................................................................2 Fases..............................................................................................................................................3 Planejamento das Fases........................................................................................................3 Inception (Concepo)..................................................................................................................5
T@rgetTrust Treinamento e Tecnologia I

Viso Geral

Objetivos...............................................................................................................................5 Atividades Essenciais...........................................................................................................5 Milestone: Lifecycle Objectives...........................................................................................6 Artefatos................................................................................................................................6 Elaboration (Elaborao)..............................................................................................................8 Objetivos...............................................................................................................................8 Atividades Essenciais...........................................................................................................8 Milestone: Lifecycle Architecture........................................................................................9 Artefatos..............................................................................................................................10 Construction (Construo)..........................................................................................................12 Objetivos.............................................................................................................................12 Atividades Essenciais.........................................................................................................12 Milestone: Initial Operational Capability...........................................................................13 Artefatos..............................................................................................................................13 Transition (Transio).................................................................................................................15 Objetivos.............................................................................................................................15 Atividades Essenciais.........................................................................................................16 Milestone: Product Release ...............................................................................................16 Artefatos..............................................................................................................................17 Exerccios....................................................................................................................................18 3. Core Workflows...........................................................................1 Objetivos.......................................................................................................................................2 Anlise de Negcio.......................................................................................................................3 Proposta................................................................................................................................3 Relacionamento com outros workflows...............................................................................4 Atividades.............................................................................................................................4 Artefatos................................................................................................................................5 Requisitos......................................................................................................................................6 Proposta................................................................................................................................6 Relacionamento com outros workflows...............................................................................8 Atividades.............................................................................................................................9 Artefatos................................................................................................................................9 Anlise e Projeto.........................................................................................................................10 Proposta..............................................................................................................................10 Relacionamento com outros workflows.............................................................................10 Atividades...........................................................................................................................11 Artefatos..............................................................................................................................11 Implementao............................................................................................................................12 Proposta..............................................................................................................................12 Relacionamento com outros workflows.............................................................................13 Atividades...........................................................................................................................13 Artefatos..............................................................................................................................13 Teste............................................................................................................................................14 Proposta..............................................................................................................................14 Relacionamento com outros workflows.............................................................................15 Atividades...........................................................................................................................16 Artefatos..............................................................................................................................16 Deployment (Entrega).................................................................................................................17 Proposta..............................................................................................................................17 Relacionamento com outros workflows.............................................................................18
T@rgetTrust Treinamento e Tecnologia II

Viso Geral

Atividades...........................................................................................................................19 Artefatos..............................................................................................................................19 Gerenciamento de Configurao e Mudanas............................................................................20 Introduo...........................................................................................................................20 Proposta..............................................................................................................................21 Relacionamento com outros core workflows......................................................................22 Atividades...........................................................................................................................23 Artefatos..............................................................................................................................23 Gerenciamento de Projeto...........................................................................................................24 Introduo...........................................................................................................................24 Proposta..............................................................................................................................24 Relacionamento com outros workflows.............................................................................25 Atividades...........................................................................................................................25 Artefatos..............................................................................................................................26 Ambiente (Environment)............................................................................................................27 Proposta..............................................................................................................................27 Relacionamento com outros workflows.............................................................................27 Atividades...........................................................................................................................28 Artefatos..............................................................................................................................29 Exerccios....................................................................................................................................30 4. Papis e Atividades.....................................................................1 Objetivos.......................................................................................................................................2 Analistas........................................................................................................................................3 Analista de Processos de Negcio........................................................................................3 Projetista de Negcio............................................................................................................4 Revisor de Modelo de Negcio............................................................................................5 Revisor de Requisitos...........................................................................................................6 Analista de Sistemas.............................................................................................................6 Especificador de Requisitos..................................................................................................8 Projetista de Interface com o Usurio...................................................................................9 Desenvolvedores.........................................................................................................................10 Arquiteto de Software.........................................................................................................10 Revisor de Arquitetura........................................................................................................12 Projetista de Cpsulas (Capsule Designer).........................................................................12 Revisor de Cdigo..............................................................................................................13 Projetista de Banco de Dados.............................................................................................13 Revisor de Projeto...............................................................................................................14 Projetista.............................................................................................................................14 Implementador....................................................................................................................16 Integrador............................................................................................................................17 Testadores...................................................................................................................................19 Testador..............................................................................................................................19 Projetista de Testes.............................................................................................................19 Gerentes......................................................................................................................................21 Gerente de Controle de Mudanas......................................................................................21 Gerente de Configurao....................................................................................................22 Gerente de Deployment......................................................................................................23 Engenheiro de Processos....................................................................................................24 Gerente de Projeto..............................................................................................................25 Revisor de Projeto...............................................................................................................29
T@rgetTrust Treinamento e Tecnologia III

Viso Geral

Exerccios....................................................................................................................................31 5. Artefatos....................................................................................1 Objetivos.......................................................................................................................................2 Modelagem de Negcio................................................................................................................3 Ator de Negcio....................................................................................................................3 Documento de Arquitetura de Negcio................................................................................3 Entidade de Negcio.............................................................................................................3 Glossrio de Negcio............................................................................................................4 Modelo de Objetos de Negcio............................................................................................4 Regras de Negcio................................................................................................................4 Caso de Uso de Negcio.......................................................................................................4 Modelo de Casos de Uso de Negcio...................................................................................4 Realizao de Caso de Uso de Negcio................................................................................4 Viso do Negcio..................................................................................................................5 Trabalhador do Negcio.......................................................................................................5 Unidade Organizacional.......................................................................................................5 Especificao de Negcio Suplementar................................................................................5 Avaliao da Organizao Alvo...........................................................................................5 Requisitos......................................................................................................................................6 Ator.......................................................................................................................................6 Classes Limite.......................................................................................................................6 Glossrio...............................................................................................................................6 Atributos de Requisitos.........................................................................................................7 Plano de Gerncia dos Requisitos.........................................................................................7 Solicitaes dos Envolvidos.................................................................................................7 Especificao de Requisitos de Software.............................................................................7 Especificaes Suplementares..............................................................................................7 Caso de Uso..........................................................................................................................8 Modelo de Casos de Uso......................................................................................................8 Pacote de Casos de Uso........................................................................................................8 Descrio de Caso de Uso....................................................................................................8 Prottipo de Interface com o Usurio...................................................................................8 Viso.....................................................................................................................................8 Anlise e Projeto.........................................................................................................................10 Classe de Anlise................................................................................................................10 Modelo de Anlise..............................................................................................................10 Cpsula (Capsule)...............................................................................................................10 Modelo de Dados................................................................................................................11 Modelo de Deployment......................................................................................................11 Classe de Projeto.................................................................................................................11 Modelo de Projeto...............................................................................................................11 Pacote de Projeto................................................................................................................11 Subsistema de Projeto.........................................................................................................11 Evento.................................................................................................................................12 Interface..............................................................................................................................12 Protocolo.............................................................................................................................12 Arquitetura de Referncia...................................................................................................12 Sinal....................................................................................................................................12 Documento de Arquitetura de Software.............................................................................12 Realizao de Caso de Uso.................................................................................................13
T@rgetTrust Treinamento e Tecnologia IV

Viso Geral

Prova de Conceito Arquitetural..........................................................................................13 Implementao............................................................................................................................14 Build....................................................................................................................................14 Componente........................................................................................................................14 Modelo de Implementao..................................................................................................14 Subsistema de Implementao............................................................................................14 Plano de Integrao.............................................................................................................15 Teste............................................................................................................................................16 Caso de Teste......................................................................................................................16 Classe de Teste....................................................................................................................16 Componente de Teste..........................................................................................................17 Resumo de Avaliao de Testes.........................................................................................17 Modelo de Teste..................................................................................................................17 Pacote de Teste...................................................................................................................17 Plano de Teste.....................................................................................................................17 Procedimento de Teste........................................................................................................18 Resultados de Teste............................................................................................................18 Script de Teste....................................................................................................................18 Subsistema de Teste............................................................................................................18 Documento de Anlise de Carga de Trabalho....................................................................18 Deployment.................................................................................................................................19 Lista de Materiais................................................................................................................19 Plano de Deployment..........................................................................................................19 Material de Suporte ao Usurio Final.................................................................................19 Artefatos de Instalao........................................................................................................20 Unidade de Deployment.....................................................................................................20 Produto................................................................................................................................20 Arte do Produto...................................................................................................................20 Notas de Verso..................................................................................................................20 Material de Treinamento.....................................................................................................20 Gerenciamento de Configurao e Mudanas............................................................................21 Requisio de Mudana......................................................................................................21 Evidncias de Auditoria de Configurao..........................................................................21 Plano de Gerncia de Configurao....................................................................................21 Repositrio de Projeto........................................................................................................22 Espao de Trabalho (Workspace).......................................................................................22 Gerenciamento de Projeto...........................................................................................................23 Caso de Negcio.................................................................................................................23 Avaliao de Iterao..........................................................................................................23 Plano de Iteraao.................................................................................................................24 Plano de Mtricas................................................................................................................24 Plano de Resoluo de Problemas......................................................................................24 Plano de Aceite do Produto................................................................................................24 Mtricas do Projeto.............................................................................................................24 Plano de Garantia de Qualidade..........................................................................................24 Registros de Reviso...........................................................................................................25 Lista de Riscos....................................................................................................................25 Plano de Gerenciamento de Riscos.....................................................................................25 Plano de Desenvolvimento de Software.............................................................................25 Avaliao de Status.............................................................................................................25 Ordem de Trabalho.............................................................................................................26
T@rgetTrust Treinamento e Tecnologia V

Viso Geral

Ambiente.....................................................................................................................................27 Guidelines para Modelagem de Negcio............................................................................27 Guidelines para Projeto.......................................................................................................27 Caso de Desenvolvimento..................................................................................................28 Avaliao da Organizao de Desenvolvimento ...............................................................28 Guia de Estilo de Manual....................................................................................................28 Templates Especficos do Projeto.......................................................................................28 Guidelines de Programao................................................................................................28 Guidelines de Teste.............................................................................................................28 Ferramentas.........................................................................................................................29 Guidelines de Ferramentas..................................................................................................29 Infraestrutura de Desenvolvimento.....................................................................................29 Guidelines de Modelagem de Casos de Uso.......................................................................29 Guidelines de Interface de Usurio.....................................................................................29 Exerccios....................................................................................................................................30

T@rgetTrust Treinamento e Tecnologia

VI

1. Viso Geral

Viso Geral

Objetivos
Entender o que um Processo de Desenvolvimento de Software Conhecer a estrutura geral do RUP Conhecer os conceitos chave do RUP

Viso Geral

Viso Geral

Figura 1-1: Fases e Workflows

O Rational Unified Process RUP um processo de engenharia de software. Ele prov uma abordagem disciplinada para alocar tarefas e responsabilidades em uma organizao desenvolvedora. Sua meta assegurar a produco de software de alta qualidade, que atenda as necessidades de seus usurios finais dentro de cronogramas e oramentos previsveis. A figura 1-1 mostra a viso total da arquitetura do Rational Unified Process. O RUP tem duas dimenses: - o eixo horizontal representa tempo e mostra no seu decorrer os aspectos do ciclo de vida do processo - o eixo vertical representa os principais workflows do processo, os quais agrupam atividades logicamente conforme sua natureza. A primeira dimenso representa o aspecto dinmico do processo, expresso em termos de fases, iteraes e milestones. A segunda dimenso representa o aspecto esttico do processo, descrito em termos de componentes de processo, atividades, workflows, artefatos e papis. O grfico mostra como a nfase varia ao longo do tempo. Por exemplo, nas iteraes iniciais mais tempo gasto em requisitos, enquanto que nas iteraes finais, mais tempo gasto em implementao.

Viso Geral

Conceitos Chave

Figura 1-2: Conceitos bsicos no RUP

Processo de Desenvolvimento de Software


Um processo um conjunto de passos parcialmente ordenados para alcanar uma meta. Em Engenharia de Software, a meta construir um produto de software ou melhorar um existente. Em Engenharia de Processos, a meta desenvolver ou melhorar um Processo. Em termos de modelagem de negcios, o processo de desenvolvimento de software um processo de negcio. O Rational Unified Process (RUP) um processo de negcio genrico para engenharia de software orientado a objetos. Ele descreve uma famlia de processos de engenharia de software relacionados compartilhando uma estrutura comum, uma arquitetura de processo comum. Ele prov uma abordagem disciplinada para alocao de tarefas e responsabilidades em uma organizao desenvolvedora. Seu objetivo assegurar a produo de software de alta qualidade que v ao encontro das necessidades dos seus usurios, dentro de cronogramas e oramentos previsveis. O RUP captura as melhores prticas utilizadas em desenvolvimento de software moderno de forma que possa ser adaptado para atender a vrios tipos de projetos e organizaes.

Viso Geral

Quando um sistema de software desenvolvido do zero, o desenvolvimento o processo de criao de um sistema a partir de requisitos. Mas, uma vez que o sistema toma forma (ou, em termos de RUP, uma vez que o sistema passou pelo ciclo inicial de desenvolvimento), qualquer desenvolvimento a partir da o processo de adaptao do sistema a requisitos novos ou modificados. Isso aplicvel atravs de todo o ciclo de vida do sistema.

Figura 1-3: O processo de engenharia de software o processo de desenvolvimento de um sistema a partir de requisitos, sejam eles novos (ciclo de desenvolvimento inicial) ou modificados (ciclo evolutivo).

Roles (Papis)
O conceito central no processo o de Papel (Role). Um papel define o comportamento e as responsabilidades de um indivduo, ou de um conjunto de indivduos trabalhando juntos como um time, dentro do contexto de uma organizao desenvolvedora de software. Note que papis so diferentes de indivduos, ao invs disso, papis descrevem como indivduos devem se comportar no negcio e as responsabilidades de um indivduo. Membros individuais de uma organizao desenvolvedora de software iro usar chapus diferentes, ou executar papis diferentes. O mapeamento de indivduo para papel, feito pelo gerente de projeto enquanto est planejando e alocando o pessoal para o projeto, possibilita que indivduos possam atuar com vrios papis diferentes, ou que um papel seja executado por vrios indivduos.

Viso Geral

Activity (Atividade)

Figura 1-4: Um papel com suas atividaes

Papis tm atividades que definem o trabalho que eles devem executar. Uma atividade algo que um papel faz que produz um resultado significativo para o contexto do projeto. Uma atividade uma unidade de trabalho que um indivduo exercendo um papel pode ser solicitado a executar. A atividade tem um propsito claro, geralmente expresso em termos de criao ou alterao de alguns artefatos, como um modelo, uma classe ou um plano. Cada atividade associada a um papel especfico. A granularidade de uma atividade varia de algumas horas a alguns dias, usualmente envolve um papel e afeta um ou um pequeno nmero de artefatos. Uma atividade deve ser usada como um elemento de planejamento e progresso. Se for muito pequena, ser negligenciada, se for muito grande, o progresso teria de ser medido em termos de partes de uma atividade. Atividades podem se repetir vrias vezes para o mesmo artefato, especialmente quando vamos de uma iterao para outra, refinando e expandindo o sistema, pelo mesmo papel, mas no necessariamente o mesmo indivduo.

Steps (Tarefas)
Atividades so quebradas em tarefas. As tarefas recaem em trs categorias principais: Tarefas de estudo: quando o indivduo executando o papel entende a natureza da tarefa, rene e examina os artefatos de entrada e formula a sada.

Viso Geral

Tarefas de execuo: quando o indivduo executando o papel cria ou altera algum artefato. Tarefas de reviso: quando o indivduo executando o papel inspeciona o resultado de acordo com algum critrio. Nem todas as tarefas so necessariamente executadas cada vez que a atividade iniciada, desta forma elas podem ser descritas na forma de fluxos alternativos. Exemplos de tarefas: A atividade: Encontrar casos de uso e atores se decompe nas seguintes tarefas: 1. Encontrar atores 2. Encontrar casos de uso 3. Descrever como os atores e casos de uso interagem 4. Empacotar casos de uso e atores 5. Apresentar o modelo de caso de uso em diagramas de use-case 6. Desenvolver um questionrio do modelo de casos de uso 7. Avaliar os resultados A parte de encontrar [tarefas 1 a 3] requer algum estudo; a parte de execuo [tarefas 4 a 6] envolve capturar o resultado no modelo de casos de uso; a parte de reviso [tarefa 7] quando o indivduo executor o papel avalia o resultado para assegurar a completude, robustez, inteligibilidade ou outras qualidades.

Work Guidelines (Guias de Trabalho)


Atividades podem ter guias de trabalho associadas, as quais apresentam tcnicas e conselhos prticos que so teis para o papel executor da atividade.

Artefato (Artifact)
Atividades tm artefatos de entrada e sada. Um artefato um produto de um trabalho do processo: papis usam artefatos para executar atividades e produzem artefatos enquanto esto executando atividades. Artefatos so de responsabilidade de um papel nico e promovem a idia que cada parte de informao no processo deve ser de responsabilidade de uma pessoa especfica. Apesar de que uma pessoa ser dona do artefato, muitas pessoas podem usar o artefato, at memo podendo alter-lo se houver permisso para isso.

Viso Geral

Figura 1-5: Artefatos principais do processo e o fluxo de informaes entre eles

O diagrama acima mostra como o fluxo de informao ao longo do projeto, atravs dos artefatos; as setas mostram como mudanas em um artefato se propagam aos outros seguindo as setas. Para maior clareza, muitos artefatos so omitidos (por exemplo, muitos artefatos no modelo do projeto so omitidos, sendo representado pelo artefato: Design Model). Para simplificar a organizao, os artefatos so organizados em "information sets", ou conjuntos de artefatos. Um conjunto de artefatos set um grupo de artefatos relacionados que tendem a ser usados para uma finalidade similar.

Figura 1-6: Conjuntos de artefatos

Viso Geral

Artefatos podem assumir vrias formas e tipos: Um modelo (model), como Modelo de Casos de Uso ou Modelo de Projeto, que contm outros artefatos. Um elemento de um modelo, ou seja, um elemento dentro de um modelo, como uma classe de projeto, um Caso de Uso ou um projeto de sub-sistema. Um documento, como um Caso de Negcio ou um Documento de Arquitetura de Software. Cdigos fonte e executveis (componentes) Executveis

Note que artefato um termo usado no RUP. Outros processos usam termos como work product, work unit e assim por diante, para designar a mesma coisa. Deliverables (ou aquilo que ser entregue) so o subconjunto de artefatos que vai para as mos dos clientes e usurios finais. Artefatos so muito indicados para serem controlados por um sistema de controle de versionamento e gerenciamento de configurao. Isto muitas vezes s atingido versionando-se o artefato container, quando no possvel faz-lo para os artefatos elementares artefatos, chamados contained. Por exemplo, voc pode controlar a verso de todo o modelo do projeto, ou de um pacote, mas no para as classes individuais que eles contm. Artefatos tipicamente NO so documentos. Muitos processos tm foco excessivo em documentos e particularmente e documentos em papel. O RUP desencoraja sistematicamente a produo de documentos em papel. A abordagem mais eficiente e prtica para gerenciar artefatos de projetos manter os artefatos dentro de uma ferramenta apropriada, usada para criar e gerenciar um artefato. Quando necessrio voc pode gerar documentos (snapshots) a partir dessas ferramentas, de uma forma just-in-time. Voc poder tambm considerar a possibilidade de entregar artefatos s partes interessadas dentro da prpria ferramenta, ao invs de em papel. Esta abordagem assegura que a informao est sempre atualizada e baseada no trabalho atual do projeto e que no ir requerer esforo adicional para produzila. Exemplos de artefatos: Um modelo de projeto no Rational Rose. Um plano de projeto no Microsoft Project. Um bug registrado no Rational ClearQuest. Uma base de dados de requisitos do projeto no Rational RequisitePro.

Entretando, ainda existem artefatos que tem de ser documentos de texto, como no caso de entradas externas ao projeto ou em alguns casos onde sisplesmente melhor apresentar uma informao descritiva.

Viso Geral

Template (Modelo)
Templates so modelos, ou prottipos, de artefatos. Associados com a descrio do artefato est um ou mais templates que podem ser usados para criar o artefato correspondente. Templates so ligagos a ferramenta que ser utilizada. Por exemplo: Templates do Microsoft Word podem ser usados para artefatos que so documentos e para relatrios. Templates do Rational SoDA para Microsoft Word ou para FrameMaker podem extrair informaes de ferramentas como Rational Rose, Rational RequisitePro ou Rational TeamTest. Templates do Microsoft FrontPage para vrios elementos do processo. Templates do Microsoft Project para o planejamento do projeto.

De acordo com as guias de trabalho, as organizaes podem querer customizar os templates antes de us-los adicionando o logo da companhia, identificao do projeto ou informaes especificas do tipo de projeto.

Figura 1-7: Diferentes tipos de templates do RUP

Report (Relatrio)
Modelos e elementos dos modelos podem ter relatrios associados. Um relatrio extrai informaes de um modelo ou de elementos do modelo em uma ferramenta. Por exemplo, um relatrio apresenta um artefato ou um conjunto de artefatos para uma reviso. Diferente dos artefatos normais, os relatrios no esto sujeitos ao controle de verso.Eles podem ser reproduzidos em qualquer tempo voltando-se para os artefatos que os geraram.

Artifact Guidelines and Checkpoints (Guias de Artefatos e Pontos de Verificao)


Artefatos tm, tipicamente, guias de trabalho associadas e checkpoints (pontos de verificao) que contm informaoes sobre como desenvolver, avaliar e utilizar os artefatos. Muito do contedo do Processo est contido nas guias dos artefatos. As descries das atividades tentam capturar a essncia do que feito, enquanto as guias dos artefatos capturam a essncia de como fazer o trabalho. Os checkpoints provm uma referncia rpida para auxiliar na avaliao da qualidade do artefato.

Viso Geral

Ambos, guias e checkpoints so teis em vrios contextos: eles ajudam a decidir o que fazer, ajudam a fazer e ajudam a decidir se o trabalho est bem feito depois de completo.

Figura 1-8: Um artefato com seus guias e checkpooints

Workflows (Disciplinas)
Uma mera enumeraco de todos os papis, artefatos e atividades no constitui um processo. Precisamos de uma forma para descrever seqncias significativas de atividades que produzem algum resultado avalivel e tambm mostrar as interaes entre os papis. Um workflow ma seqncia de atividades que produzem um resultdado de valor observvel. Em termos de UML, um workflow pode ser expresso como um diagrama de seqncia, um diagrama de colaborao ou um diagrama de atividades. No RUP utilizamos a forma de diagramas de atividades. Para cada workflow principal um diagrama de atividades mostrado. O diagrama mostra um workflow, expresso em termo de seus detalhes.

Viso Geral

Figura 1-9: Um diagrama de atividades, mostrando detalhes e transies

Uma das grandes dificuldades na descrio do processo que existem muitas formas para organizar o conjunto de atividades dentro dos workflows. O RUP organizado usando:

Core workflows (workflows principais) Workflow details (workflows auxiliares)

Core Workflows (Workflows Principais)


Um core workflow uma coleo de atividades relacionadas que tem relao com uma das maiores reas de conhecimento dentro de todo o projeto. O agrupamento de atividades em core workflows , principalmente, um auxlio para o entendimento do projeto de uma perspectiva de cascata tradicional tipicamente, por exemplo, mais comum realizar certas atividades ligadas a requisitos em coordenao com atividades de anlise e projeto. Separar estas atividades em core workflows torna as atividades mais fceis de serem compreendidas, mas mais difceis de serem colocadas em cronograma (schedule).

Viso Geral

Figura 1-10: Core workflows

Como outros workflows, um core workflow uma seqncia semiordenada de atividades que so realizadas para atingir um resultado. A natureza semi-ordenada dos core workflows enfatiza que eles no representam exatamente o trabalho real em um cronograma, por eles no podem configurar as atividades opcionais ou a natureza iterativa dos projetos reais. Mas, eles ainda possuem valor como forma de entender o processo pela decomposio em reas de conhecimento menores. Cada rea de conhecimento ou core workflow tem associado a ele um ou mais modelos (models) que so por sua vez compostos de artefatos associados. Os artefatos mais importantes so os modelos que cada core workflow gera: modelo de casos de uso, modelo de projeto, modelo de implementao e modelo de testes.

Figura 1-11: Cada core workflow associado a um conjunto particular de modelos

Para cada core workflow, um overview das atividades apresentado. O overview de atividades mostra todas as atividades no workflow em junto com o papel que executa a atividade. Um overview de artefatos tambm est presente. Este diagrama mostra todos os artefatos e papis envolvidos no workflow.

Viso Geral

Figura 1-12: Exemplo de diagrama de overview de artefatos, do workflow de modelagem de negcios

interessante notar que a organizao centrada em workflows dos artefatos , algumas vezes, mas no sempre, um pouco diferente da organizao dos conjuntos de artefatos. A razo para isto simples: alguns artefatos so usados de forma cruzada nos workflows, um agrupamento estritamente centrado em workflows torna mais difcil representar um processo integrado. Se voc est usando apenas uma parte do processo, entretanto, o overview centrado em workflows pode ser mais til.

Workflow Details (Detalhes de Workflows)


Para a maioria dos core workflows, voc tambm encontrar diagramas de workflow detalhados, que mostram grupos de atividades que freqentemente so executados como um todo. Estes diagramas mostram papis envolvidos, artefatos de entrada e sada e atividades executadas. Os diagramas de detalhamento de workflow esto l pelas seguintes razes: As atividades de um workflow no so executadas em seqncia, nem feitos todos de uma vez. O diagrama detalhado mostra como voc freqentemente ir trabalhar em workshops ou reunies de equipe enquanto executando um workflow. Voc tipicamente trabalha em paralelo, em mais de uma atividade e olha para mais de um artefato enquanto faz isso. Existem vrios diagramas de detalhamento de workflow para um core workflow. Torna-se muito complexo mostrar artefatos de entrada e sada para todas as ativiades de um core workflow em um diagrama. O diagrama detalhado de workflow possibilita mostrar atividades e artefatos juntos, para uma parte de um workflow cada vez. Os core workflows no so completamente independentes entre si. Por exemplo, integrao ocorre nos workflows de implementao e

Viso Geral

de teste e, na realidade, voc nunca faz realmente um sem o outro. O diagrama detalhado de workflow pode mostrar um grupo de ativiades e artefatos no workflow, junto com suas atividades intimamente relacionadas com outro workflow.

Figura 1-13: Exemplo de diagrama de detalhamento do workflow de modelagem de negcio

Outros Conceitos Tool Mentor


Atividades, tarefas e guias associados provm o caminho geral para o praticante. Para ir um passo a frente, tool mentors so um outro caminho mostrando como executar as tarefas usando uma ferramenta de software especfica. Tool mentors esto disponveis no RUP, ligando suas atividades com ferramentas como Rational Rose, Rational RequisitePro, Rational ClearCase, Rational ClearQuest, Rational Sute TestStudio. Os tool mentors encapsulam quase completamente as dependncias do processo no conjunto de ferramentas, mantendo as atividades livres dos detalhes das ferramentas. Uma organizao pode extender o conceito de tool mentor para prover caminhos para outras ferramentas.

Viso Geral

Figura 1-14: Exemplos de "tool mentors"

Conceitos
Alguns dos conceitos chave do processo, como iterao, fase, risco, testes de performance e assim por diante, so introduzidos em partes separadas do processo, geralmente anexados ao core workflow mais apropriado.

Figura 1-15: Exemplo de conceitos anexados ao workflow

Viso Geral

A Essncia dos Processos


Introduo
A chave para atingir o delicado equilbrio entre entregar software de qualidade e entregar rpido (o paradoxo do e-software!) entender os elementos essenciais do processo e seguir certas linhas guias para ajustar o processo para servir melhor as necessidades especficas de seu projeto. Isto deve ser feito aderindo as melhores prticas que tm sido provadas atravs da indstria para auxiliar os projetos de desenvolvimento de software a terem sucesso. A seguir descrevemos o essencial para um processo de software eficiente.

Definir uma Viso


Em particular, desenvolver uma Viso clara chave para desenvolver um produto que v ao encontro das reais necessidades dos envolvidos. A Viso captura a essncia do workflow de Requisitos. A Viso prov uma base de alto nvel, algumas vezes contratual, para requisitos tcnicos mais detalhados. A Viso captura restries de requisitos e projeto em alto nvel, dando ao leitor um entendimento do sistema a ser desenvolvido. Ela prov entrada para o processo de aprovao do projeto e , portanto, intimamente relacionada ao Caso de Negcio (Business Case). Ela comunica os o qus e os porqus fundamentais relativos ao projeto e um marcador que validar todas as decises futuras. O contedo da Viso deve responder as seguintes questes, que podem ser quebradas em artefatos separados, mais detalhados, conforme a necessidade: Quais so os termos utilizados? (Glossrio) Qual problema estamos tentando resolver? (Problem Statement) Quem so os envolvidos? Quem so os usurios? Quais so suas necessidades? Quais so as funcionalidades do produto? Quais so os requisitos no funcionais? Quais so as restries de projeto?

A Viso a essncia do workflow de Requisitos e da best practice: Gerenciar Requisitos.

Viso Geral

Usar uma Arquitetura


No RUP, a arquitetura de um sistema de software (em um dado momento) a organizao ou a estrutura dos componentes significativos do sistema interagindo atravs de interfaces com componentes compostos de outros componentes e interfaces sucessivamente menores. Quais so as peas principais? Como elas se integram? Existe um framework no qual o restante do software pode ser adicionado? Para falar de forma razovel sobre arquitetura de software, voc deve primeiramente definir uma representao arquitetural, uma forma de descrever os aspectos importantes da arquitetura. Esta descrio capturada no Documento de Arquitetura de Software, que apresenta a arquitetura em mltiplas vises. Cada viso arquitetural enderea algum conjunto especfico de assunto, especificamente aos envolvidos no processo de desenvolvimento: usurios finais, projetistas, gerentes, engenheiros de sistemas, operadores e assim por diante. Isso serve como meio de comunicao entre o arquiteto de software e os membros do time do projeto com respeito das decises arquiteturais significativas que so tomadas no projeto. Definir arquitetura, refinar arquitetura, analizar o comportamento e o projeto de componentes do sistema a essncia do workflow de Anlise e Projeto e da best practice: Usar Arquitetura de Componentes.

Planejamento e Controle
Conceber um novo projeto, avaliar escopo e risco. Monitorar e controlar o projeto. Planejar e avaliar cada iterao e fase so a essncia do workflow de Gernciamento do Projeto.

Gerenciar pelo Planejamento


O produto somente to bom quanto o plano para o produto. O Plano de Desenvolvimento de Software (PDS) rene toda a informao requerida para gerenciar o projeto. Ele deve incluir um nmero de artefatos desenvolvidos durante a fase de Inception e mantido ao longo do projeto. O PDS usado para planejar o cronograma do projeto e a necessidade de recursos e para acompanhar o progresso de acordo com o cronograma. Ele enderea reas como: Organizao do Projeto, Cronograma (Plano de Projeto, Plano de Iteraes, Recursos, Ferramentas), Plano de Gerencia de Requisitos, Plano de Gerncia de Configurao, Plano de Resoluo de Problemas, Plano de QA, Plano de Testes, Casos de Teste, Plano de Avaliao e Plano de Aceitao de Produto. Para um projeto pequeno, no necessrio manter artefatos separados para cada rea. Elas podem ser endereadas como uma simples seo, ou at mesmo um pargrafo, no PDS. Em um projeto simples, pode-s incluir uma ou duas sentenas para cada. Por exemplo, um Plano de Gerncia de Configurao pode simplesmente dizer: No final de cada dia, o contedo do diretrio do projeto ser zipado, copiado

Viso Geral

em um disquete com etiqueta e data, marcado com um nmero de verso e colocado no armrio do arquivo central. O formato do PDS em si no to importante como a atividade e o sentido que se tem ao produz-lo. No importa como ele se parece ou que ferramenta voc usa para constru-lo. Como Dwight D. Eisenhower disse: The plan is nothing; the planning is everything.

Riscos Identificar e Mitigar


essencial identificar e atacar os maiores items de risco o quanto mais cedo no projeto. A inteno da lista de riscos capturar os riscos ao sucesso do projeto. Ela identifica, em ordem decrescente de prioridade, os eventos que podem levar a resultados negativos. Para cada risco, deve haver um plano para mitig-lo. Isso servir como ponto focal para planejar as atividades do projeto e a base em torno da qual as iteraes so organizadas.

Issues (Questes) Definir Responsveis e Controlar


Comunicao contnua e aberta, com dados objetivos derivados diretamente das atividades em progresso e a evoluo das configuraes do produto so importantes em qualquer projeto. Avaliaes regulares de status provm mecanismos para enderear, comunicar e resolver questes de gerenciamento, questes tcnicas e riscos de projeto. Alm de identificar as issues, cada uma deve ser associada a uma data, com uma pessoa responsvel pela resoluo. Elas devem ser regularmente acompanhadas e atualizadas quando necessrio.

Business Case (Caso de Negcio) Examinar o Caso de Negcio


O Business Case prov a informao necessria, do ponto de vista de negcio, para determinar se o projeto vale o investimento. A proposta principal do Business Case desenvolver um plano econmico para realizao da Viso do projeto. Uma vez desenvolvido, o Business Case usado para fazer um julgamento preciso do Retorno do Investimento (ROI) proporcionado pelo projeto. Isso produz a justificativa para o projeto e estabelece as restries econmicas. Produz ainda, informao para os tomadores de decises econmicas no projeto e usado para determinar se o projeto deve seguir em frente. A descrio no deve se aprofundar no problema especfico, mas sim, criar um argumento convincente de por que o produo necessrio. Deve ser breve, portanto, fcil o suficiente para todos os membros do projeto entenderem e lembrarem. Em marcos crticos do projeto, o Business Case re-examinado para verificar se as estimativas de retorno e custo ainda esto precisas e se o projeto deve ser continuado.

Viso Geral

Evaluation (Avaliao) Avaliar regularmente os resultados


A Avaliao da Iterao captura os resultados de uma iterao, o grau atingido de acordo com os critrios de avaliao, as lies aprendias e as alteraes no processo a serem implementadas. A Avaliao da Iterao um artefato essencial da abordagem iterativa. Dependendo do escopo e risco do projeto e da natureza da iterao, ela pode variar de um simples registro de demonstrao a um registro de reviso de teste formal completo. A chave focar nos problemas do processo, bem como nos problemas do produto.

Implementar e Testar Iterativamente


O RUP uma abordagem iterativa de construo, teste e avaliao de verses executveis do produto visando eliminar problemas e resolver riscos e questes to cedo quanto possvel. Construir e testar componentes do sistema de forma incremental a essncia dos workflows de Implementao e Teste e da best practice: Desenvolver Iterativamente.

Controlar Mudanas
Assim que o primeiro prottipo colocado para os usurios (e freqentemente at antes disso) mudanas sero solicitadas. (Uma daquelas certezas da vida!). Para controlar essas mudanas e gerenciar efetivamente o escopo do projeto e expectativas dos envolvidos, importante que todas as mudanas em qualquer artefato seja proposta atravs de Change Requests (Requisio de Mudana) e gerenciadas com um processo consistente. Change Request so usados para documentar e acompanhar defeitos, requsies de melhorias e qualquer outro tipo de requisio de mudana do produto. O benefcio dos Change Requests que eles possibilitam o registro das decises, e, devido ao processo de avaliao de impacto, asseguram que os impactos da mudana potencial so entendidos por todos os membros do time do projeto. Os Change Requests so essenciais para gerenciamento do escopo do projeto, bem como a avaliao do impacto das mudanas propostas. Gerenciar e controlar o escopo do projeto, assim que as mudanas ocorrem ao longo do ciclo de vida do projeto, mantendo o objetivo de considerar e atingir todas as necessidades dos envolvidos, na mxima estenso possvel esta a essncia do workflow de Gerenciamente de Configurao e mudanas e da best practice: Controlar Mudanas.

Entregar um Produto Utilizvel


A proposta de um processo produzir um produto utilizvel. Todos os aspectos do processo devem ser ajustados tendo esse objetivo em mente. O

Viso Geral

produto , tipicamente, mais do que apenas software. No mnimo, deve haver um Guia de Usurio, talvez implementado em forma help online. Voc pode tambm incluir um Guia de Instalao e Release Notes (Notas de Verso). Dependento da complexidade do produto, material de treinamento pode ser tambm necessrio, bem como uma lista de materiais contidos no pacote do produto. Estas atividades associadas formam o workflow de Deployment (Entrega).

Adaptar o Processo
essencial que o processo no seja seguido cegamente o processo e as ferramentas devem ser configurados para ir ao encontro das necessidades da organizao e do projeto. Esta a essncia do workflow de Environment (Ambiente).

Concluso
As essncias acima provm uma forma de avaliao rpida em um processo e a identificao de reas onde melhorias sero mais benficas. importante explorar o que aconteceria se alguma dessas essncias for ignorada. Por exemplo: Sem Viso? Voc pode perder o trilho de onde voc est indo e pode ser facilmente distrado por desvios. Sem plano? Voc no vai conseguir acompanhar o progresso. Sem lista de riscos? Voc pode estar focando nas questes erradas agora e daqui a 5 meses algo inesperado pode explodir. Sem lista de issues (questes/pendncias)? Sem responsabilidades, obstculos ao sucesso podem permanecer indefinidamente. Sem business case (caso de negcio)? Voc arrisca perder tempo e dinheiro no projeto, ele pode ser cancelado ou ir bancarrota. Sem arquitetura? Voc pode no conseguir lidar com questes de comunicao, sincronizao e acesso a dados quando elas surgirem, problemas com escalabilidade e performance. Sem produto (prottipo)? Apenas acumular papel no assegura a voc ou ao cliente que o produto ter sucesso e aumenta o risco de aumento de oramento e cronograma. Sem avaliao? No enfie a cabea na areia. importante encarar a verdade. O quo perto voc realmente est do seu deadline? Para suas metas em qualidade ou oramento? Sem change requests (requisies de mudana)? Como voc mantm o acompanhamento disso? Sem suporte ao usurio? O que acontece quando um usurio tem uma pergunta ou no sabe como usar o produto? O quanto fcil obter ajuda? Essas essncias tambm provm uma introduo para cada um dos core workflows do RUP e muitas de suas best practices.

Viso Geral

Melhores Prticas

O RUP mostra como voc pode aplicar as melhores prticas de engenharia de software e como voc pode usar ferramentas para automatizar se processo de engenharia de software.

Desenvolver em Iteraes

Para mitigar os riscos, desenvolver incrementalmente de forma iterativa. Cada iterao resulta em uma release executvel. O que Desenvolvimento Iterativo? Um projeto usando desenvolvimento iterativo tem um ciclo de vida que consite de vrias iteraes. Uma iterao consiste em uma seqncia de atividades em modelagem de negcio, requisitos, anlise e projeto, implementao, teste e deployment, em vrias propores dependendo de onde dentro do ciclo de desenvolvimento a iterao est. Iteraes nas fases de Inception e Elaboration focam em atividades de gerenciamento, requisitos e projeto. Iteraes na fase de Construction focam em atividades de projeto,

Viso Geral

implementao e teste. Iteraes na fase de Transition focam em teste e deployment (entrega). Por que Desenvolver Iterativamente? Um projeto inicial ser provavelmente falho com respeito aos requisitos chave. Descobertas posteriores de defeitos de projeto resultam em aumento de custos e, em alguns casos, at mesmo em cancelamento do projeto. Todos os projetos tm riscos envolvidos. Quanto mais cedo no ciclo de vida voc puder verificar que evitou um risco, mais precisamente voc pode fazer seu planejamento. Muitos riscos no so descobertos at que voc tente integrar o sistema. Voc nunca conseguir prever todo o risco independente do quanto experiente seu time de desenvolvimento seja.

Em um ciclo de waterfall (cascata), voc s pode verificar se est livre de um risco muito tarde no ciclo de vida do projeto.

Em um ciclo iterativo, voc seleciona qual incremento desenvolver em uma iterao baseado em uma lista de riscos chave. Uma vez que a iterao produz um executvel testado, voc pode verificar se mitigou os riscos alvo ou no. Benefcios de uma Abordagem Iterativa

Viso Geral

Uma abordagem iterativa geralmente superior a uma abordagem linear ou cascata por muitas razes diferentes.

Tolerncia mudana de requisitos. A realidade que normalmente requisitos vo mudar. Mudanas de requisitos e aparecimento de novos requisitos tem sido sempre a fonte primordial de problemas em projetos, levando a entregas com atraso, cronogramas perdidos, clientes insatisfeitos e desenvolvedores frustrados. Elementos so integrados progressivamente integrao no um big bang no fim. A abordagem iterativa quase como integrao contnua. O que costumava ser uma fase longa, incerta e problemtica, tomando at 40% do esforo total no fim de um projeto, agora dividida em seis a nove integraes menores que comeam com poucos elementos. Riscos so mitigados mais cedo, porque na integrao geralmente o nico momento onde os riscos so descobertos ou endereados. No desenrolar das primeiras iteraes, voc vai ao longo de todos os core process workflows, exercitando muitos dos aspectos do projeto: ferramentas, software de prateleira, habilidades do pessoal e assim por diante. Alguns dos riscos percebidos podem provar no serem riscos na verdade e riscos novos e imprevistos podem emergir. Possibilita a organizao aprender e melhorar. Os membros do time podem aprender ao longo do caminho e as vrias competncias e especialidades so totalmente empregadas durante todo o ciclo de vida. Testadores comeam a testar mais cedo, redatores tcnicos escrevem antes e assim por diante. Em um desenvolvimento no-iterativo, o mesmo pessoal estaria esperando para comear seu trabalho, fazer seus planos e afiar suas habilidades. Necessidades de treinamento ou necessidade de apoio adicional (talvez externo) aparecem cedo durante as revises de avaliao. Facilita o reuso, porque mais fcil identificar partes comuns enquanto esto projetadas ou implementadas parcialmente, ao invs de identificar tudo que comum de antemo. Identificar e desenvolver partes reutilizveis difcil. Revises de projeto nas primeiras iteraes possibilitam ao arquiteto de software identificar reusos potenciais e desenvolver e amadurecer cdigo comum nas iteraes subseqentes. Resulta em um produto mais robusto, porque voc est corrigindo erros nas vrias iteraes. Falhas so detectadas mesmo nas primeiras iteraes quando o produto se move alm da Inception. Gargalos de performance so descobertos a tempo de ainda serem endereados, ao invs de na vspera da entega. Tolerncia a mudanas tticas no produto. Por exemplo, para competir com produtos existentes. Voc pode decidir lanar um produto com funcionalidade reduzida para conter o movimento de

Viso Geral

um competidor ou voc pode adotar um outro fabricante para uma determinada tecnologia.

O processo em si pode ser melhorado e refinado ao longo do caminho. A avaliao no fim de uma iterao no apenas olha para o status do projeto pela perspectiva do produto e cronograma, mas analisa tambm o que poderia ser mudado na organizao e no processo em si para fazer melhor na prxima iterao.

Um cliente uma vez disse: Com a abordagem de cascata, tudo parece bem at quase o fim do projeto, algumas vezes at o meio da integrao. Ento tudo cai aos pedaos. Com a abordagem iterativa, muito difcil esconder a verdade por muito tempo. Gerentes de Projeto frequentemente resistem a abordagem iterativa, vendo ela como um tipo de caminhada sem fim. No RUP, a abordagem iterativa muito controlada. Iteraes so planejadas em nmero, durao e objetivo. As tarefas e responsabilidades dos participantes so definidas. Medidas objetivas de progresso so capturadas. Algum retrabalho vai ser necessrio de uma iterao para a outra, mas isto , tambm, cuidadosamente contralado.

Gerenciar Requisitos
O que Gerenciamento de Requisitos? Gerenciamento de requisitos uma abordagem sistemtica para encontrar, documentar, organizar e acompanhar as mudanas de requisitos de um sistema. Definimos um requisito como:

Uma condio ou capacidade com a qual o sistema tem que ter conformidade.

Nossa definio formal de Gerenciamento de Requisitos : uma abordagem sistemtica para:

Elencar, organizar e documentar os requisitos de um sistema, e Estabelecer e manter os acordos entre o cliente e o time do projeto para as mudanas de requisitos do sistema

As chaves para o Gerenciamento de Requisitos efetivo incluem a manuteno de sentenas claras para os requisitos, em conjunto com atributos aplicveis e rastreabilidade para outros requisitos e outros artefatos do projeto. Coletar requisitos pode soar como um tarefa simples. Em projetos reais, entretanto, voc pode cair em dificuldades porque: Requisitos no so sempre bvios e podem vir de vrias fontes. Requisitos no so sempre fceis de expressar em palavras claras. Existem muitos tipos diferentes de requisitos em diferentes nveis de detalhamento.

Viso Geral

O nmero de requisitos pode se tornar impossvel de gerenciar se no houver controle. Requisitos so relacionados uns com os outros e tambm com outros deliverables do processo de engenharia de software. Requisitos tm propriedades nicas ou valores prprios. Por exemplo, eles no so nem igualmente importantes nem igualmente fceis de alcanar. Existem muitas partes interessadas, o que significa que requisitos precisam ser gerenciados por grupos de pessoas multi-funcionais. Requisitos mudam.

Ento, que habilidades voc precisa desenvolver em sua organizao para apoiar no gerenciamento dessas dificuldades? Ns aprendemos que as seguintes habilidades so as mais importantes: Anlise do problema Endenter as necessidades dos envolvidos Definir o sistema Gerenciar o escopo do projeto Refinar a definio do sistema Gerenciar a mudana de requisitos

Desenvolvimento orientado por Casos de Uso Casos de uso (Use Cases) so o mtodo recomendado para a organizao de seus requisitos. Ao invs de uma lista de requisitos, voc organiza-os de forma que eles contem uma histria de como algum pode usar o sistema. Isto melhora na completude e consistncia e voc vai obter um entendimento melhor da importncia de um requisito na perspectiva do usurio. No RUP, casos de uso definem o comportamento realizado pelo sistema. Casos de uso no fazem parte de orientao a objetos tradicional, mas sua importncia tem se tornado mais e mais aparente. Isto ainda mais enfatizado pelo fato de que os Casos de Uso so parte da UML Unified Modeling Language. O RUP emprega uma abordagem orientada por casos de uso. O que significa que os Casos de Uso definidos para um sistema so a base para todos o processo de desenvolvimento. Casos de Uso tomam parte em vrios dos core workflows do processo. O conceito de casos de uso pode ser usado para representar processos de negcio, como definido no workflow de modelagem de negcio. Ns chamamos essa variao de Caso de Uso de Negcio (Business Use Case). O modelo de caso de uso um resultado do worflow de Requisitos. Nesse processo inicial voc precisa dos casos de uso para modelar o que o sistema deve fazer do ponto de vista do usurio. Desta

Viso Geral

forma, os casos de uso constituem um conceito importante e fundamental que deve ser aceitvel tanto pelo cliente como pelos desenvolvedores do sistema.

Na anlise e projeto os casos de uso so realizados no modelo de projeto (design model). Voc cria realizaes de casos de uso que descrevem como o caso de uso executado em termos de objetos interagindo no modelo de projeto. Este modelo descreve, em termos de objetos de projeto, as diferentes partes do sistema implementado e como as partes devem interagir para executar os casos de uso. Durante a implementao, o modelo de projeto serve como especificao. A implementao ser nos termos das classes de projeto e os casos de uso so a base para o modelo de projeto. Durante os testes, os casos de uso constituem a base para identificao dos casos de teste (test cases) e os procedimentos de teste. Ou seja, o sistema verificado pela execuo de cada caso de uso. No workflow de Gerenciamento de Projeto, os casos de uso so base para o planejamento do desenvolvimento iterativo. No workflow de Deployment (Entrega), eles so as fundaes para o que ser descrito nos manuais do usurio. Casos de uso tambm podem ser usados para definir diferenciao de distribuies. Por exemplo, um cliente pode obter o sistema configurado com um mix particular de casos de uso.

Usar Arquitetura de Componentes

Arquitetura baseada em componentes em camadas O que Arquitetura de Componentes? Componentes so grupos coesos de cdigo, em forma de fonte ou executvel, com interfaces bem definidas e comportamento que prov forte encapsulamento de seu contedo e so, portanto, substituveis. Arquiteturas baseadas em torno de componentes tendem a reduzir o tamanho efetivo e a complexidade da soluo, sendo ento mais robustas e resilientes. nfase na Arquitetura

Viso Geral

Casos de uso conduzem o RUP de ponta a ponto em todo o ciclo de vida, mas as atividades de projeto so centradas em torno da noo da arquitetura do sistema e, para sistemas intensivos de software, na arquitetura de software. O foco principal nas primeiras iteraes do processo principalmente na fase de elaborao produzir e validar uma arquitetura de software. No incio do ciclo do desenvolvimento o sistema toma forma de um prottipo arquitetural executvel que evolui gradualmente para se tornar o sistema final nas ltimas iteraes. Por arquitetura executvel, entendemos uma implementao parcial do sistema, construda para demonstrar funes e propriedades do sistema selecionadas, em particular, aquelas que satisfazem requisitos no funcionais. Isso feito visando mitigar riscos relacionados a performance, throughput, capacidade, confiabilidade e outras ilities, de forma que a capacidade funcional completa do sistema possa ser adicionada na fase de construo sobre uma fundao slida, sem medo de desmoronamento. Arquitetura importande por vrias razes: Permite obter ganho e reteno do controle intelectual sobre o projeto, gerenciar sua complexidade e manter a integridade do sistema. uma base efetiva para o reuso em larga escala. Prov uma base para o gerenciamento do projeto.

Desenvolvimento Baseado em Componentes (CBD) Um componente de software pode ser definido como uma parte de software no trivial, um mdulo, um pacote ou um subsistema, o qual cumpre uma funo clara, tem limites claros e pode ser integrado em uma arquitetura bem definida. a realizao fsica de uma abstrao do seu projeto. O RUP auxilia desenvolvimento baseado em componentes, das seguintes formas: A abordagem iterativa permite que voc identifique componentes progressivamente e decida qual vai desenvolver, qual vai reusar e qual vai comprar. O foco na arquitetura do software permite que voc articule a estrutura os componentes e a forma como eles se integram incluindo os mecanismos fundamentais e os patterns pelos quais eles vo interagir. Conceitos como pacotes, subsistemas e camadas so usados durante a Anlise e Projeto para organizar componentes e especificar interfaces. O teste organizado primeiramente em torno dos componentes, ento gradualmente em torno de conjuntos maiores de componentes integrados.

Viso Geral

Modelar Visualmente (UML)

Modelagem visual aumenta o nvel de abstrao O que Modelagem Visual? Modelagem Viso o uso de notaes grficas e textuais, semanticamente ricas, para capturar o projeto do software. Uma notao, como UML, permite que o nvel de abstrao cresa, enquanto mantm uma sintaxe e semntica rigorosas. Desta forma, melhora a comunicao no time do projeto (enquanto o projeto formado e revisado), permitindo ao leitor o entendimento lgico do projeto e a produo de uma base livre de ambigidades para a implementao. Por que fazer Modelagem? O modelo uma viso simplificado de um sistema. Ele mosta o essencial do sistema de uma perspectiva particular e esconte detalhes no essenciais. Modelos podem ajudar a:

Ajudar no entendimento de sistemas complexos Explorar e comparar alternativas de projeto a um custo mais baixo Formar uma fundao para a implementao Capturar os requisitos precisamente Comunicar decises livres de ambiguidades

Verificar Qualidade

Viso Geral

Problemas de software so de 100 a 1000 vezes mais caros para encontrar e consertar depois da entrega. Verificar e gerenciar qualidade ao longo do ciclo de vida do projeto essencial para atingir os objetivos certos no tempo certo. O que quer dizer Verificao de Qualidade ao longo do ciclo de vida? importante que a qualidade de todos os artefatos seja avaliada em vrios pontos do ciclo de vida do projeto enquanto eles amadurecem. Artefatos devem ser avaliados quando as atividades que os produzem se completam e na concluso de cada iterao. Em particular, quando software executvel produzido, ele deve ser sujeito a demonstrao e teste dos cenrios importantes em cada iterao, produzindo entendimento mais tangvel das decises de projeto e eliminao de defeitos arquiteturais mais cedo. Isto contrasta com uma abordagem mais tradicional, que deixa o teste do software integrado para o final do ciclo de vida do projeto. O que Qualidade? Qualidade algo que todos buscamos em nossos produtos, processos e servios. Ainda assim, quando se pergunta: O que Qualidade?, todos tem opinies diferentes. As respostas mais comuns incluem: Qualidade... No estou muito certo de como descreve-la, mas eu saberei quando eu a vir. ou ... atingir aos requisitos. Talvez a referncia a qualidade mais freqente, especificamente relacionada a software, a observao a respeito de sua ausncia: Como podem lanar software como esse, com qualidade to baixa!? Estas respostas comuns so expressivas, mas carecem de espao maior para exame mais rigorose de qualidade e de melhoria em sua execuo. Todos estes comentrios ilustram a necessidade de definir qualidade em uma maneira pela qual ela pode ser medida e alcanada. Qualidade, entretanto, no uma caracterstica singular ou um atributo. multi-dimensional e pode ser adquirida por um produto ou um processo. A qualidade do produto concentrada em construir o produto certo, enquanto que a qualidade do processo foca em construir o produto corretamente. Definio de qualidade A definio de qualidade, retirada do The American Heritage Dictionary of the English Language, 3rd Edition, Houghton Mifflin Co., 1992, 1996, : Quality (kwol'i-te) n., pl. -ties. Abbr. qlty. 1.a. An inherent or distinguishing characteristic; a property. b. A personal trait, especially a character trait. 2. Essential character; nature. 3.a. Superiority of kind. b. Degree or grade of excellence.

Viso Geral

Qualidade 1.a. Uma caracterstica inerente ou distintiva; uma propriedade. b. A personal trait, especially a character trait. b. Um trao pessoal, especialmente um trao de carter. 2. Carter essencial; natureza. 3.a. Superioridade no gnero. b. Marca ou grau de excelncia. Como demonstrado pela definio, qualidade no est em uma dimenso nica, mas em muitas. Para usar a definio e aplic-la em desenvolvimento de software, ela deve ser refinada. Portanto, para a propostas do RUP, qualidade definida como: A caracterstica identificada pelo seguinte: satisfaz ou excede o conjunto de requisitos acordados, e avalidado usando medidas e critrios acordados, e produzido usando um processo acordado. Obter qualidade no simplesmente preencher requisitos ou produzir um produto que v ao encontro das necessidades e expectativas do usurio. Qualidade tambm inclui identificar as medidas e os critrios para demonstrar o atingimento da qualidade e a implementao de um processo que assegure que o produto que seja criado por esse processo atinja o grau de qualidade desejado e possa ser repetido e gerenciado. Gerenciando Qualidade no RUP Gerenciamento de qualidade feito com as seguintes propostas:

Identificar indicadores apropriados (mtricas) de aceitao de qualidade Identificar medidas apropriadas para serem usadas na avaliao e julgamento da qualidade Identificar e enderear apropriadamente questes que afetam a qualidade o quanto mais cedo e to efetivamente quanto possvel

O gerenciamento de qualidade implementado ao longo de todos os workflows, fases e iteraes no RUP. Em geral, gerenciar qualidade ao longo do ciclo de vida significa implementar, medir e avaliar ambos, a qualidade do processo e a qualidade do produto. Alguns dos esforos gastos em cada workflow para gerenciar qualidade so destacados abaixo: Gerenciamente de qualidade no workflow de Requisitos inclui analisar o conjunto de artefatos de requisitos pela consistncia (entre os artefatos modelo e outros artefatos), clareza (comunica a informao de forma clara para os envolvidos e para os outros papeis) e preciso (nvel apropriado de detalhamento e preciso). No workflow de Anlise e Projeto, gerenciar qualidade inclui avaliar o conjunto de artefatos de projeto, incluindo a consistncia do modelo de projeto, sua traduo a partir dos artefatos de requisitos e sua traduo para os artefatos de implementao.

Viso Geral

No workflow de implementao, gerenciar qualidade inclui avaliar os artefatos de implementao e avaliar o cdigo fonte e os artefatos executveis contra os apropriados artefatos de requisitos, projeto e teste. O workflow de teste altamente focado no sentido de gerenciamento de qualidade, a maioria dos esforos gastos nesse workflow enderea as propostas de gerenciamento de qualidade identificadas acima. No workflow de Ambiente (Environment), como no de teste, inclui muitos esforos endereando as propostas de gerncia de qualidade. Aqui voc encontra o guia de como melhor configurar seu processo para atingir suas necessidades. Gerenciar qualidade no workflow de Entrega (Deployment) inclui avaliar os artefatos de implementao e de entrega contra os artefatos de requisitos, projeto e teste apropriados e necessrios para entregar o produto ao cliente. O workflow de Gerenciamento de Projeto inclui uma viso geral de muitos esforos para gerenciar qualidade, incluindo revises e auditorias requeridas para avaliar a implementao, aderncia e o progresso do processo de desenvolvimento.

Controlar Mudanas

Controlling changes is more than just check-in and check-out of files. It includes management of workspaces, parallel development, integration, as well as builds. O desafio chave quando voc est desenvolvendo sistemas de software intensivos que voc precisa cooperar com mltiplos desenvolvedores organizados em times diferentes, possivelmente em lugares diferentes, trabalhando juntos em mltiplas iteraes, releases, produtos e plataformas. Na ausncia de controle disciplinado, o processo de desenvolvimento rapidamente degenera para o caos. No RUP o workflow de Gerenciamente de Configurao e Mudanas devotado a descrever como voc enfrentar esse desafio. Coordenar as atividades e os artefatos dos desenvolvedores e times envolve estabelecer procedimentos repetveis para gerenciar mudanas no

Viso Geral

software e em outros artefatos de desenvolvimento. Esta coordenao possibilita a melhor alocao de recursos baseada nas prioridades e riscos do projeto e gerencia ativamente o trabalho destar mudanas ao longo das iteraes. Em conjunto com o desenvolvimento do software iterativamente isto praticamente deixa voc continuamente monitorando mudanas para que possa ativamente descobrir e ento reagir a problemas. Workflow: Gerenciar Requisies de Mudana. Coordenar iteraes e releases envolve estabelecer e lanar uma baseline testada ao completar cada iterao. Manter a rastreabilidade em todos os elementes de cada release e em todos os elementos ao longo de releases mltiplas e paralelas essencial para avaliar e gerenciar ativamente o impacto das mudanas. Workflow: Gerenciar Baselines e Releases. Controlar mudanas no software oferece um nmero de solues para as causas raiz dos problemas em desenvolvimento de software:

O workflow de mudana de requisitos definido e repetvel. Change requests (Requisies de Mudana) facilitam a clareza das comunicaes Workspaces separados reduzem a interferncia entre os membros do time trabalhando em paralelo Estatsticas de mudanas provm boas mtricas para avaliar objetivamente o status do projeto. Os workspaces contm todos os artefatos, facilitando a consistncia. A propagao das mudanas avalivel e controlada. Mudanas podem ser mantidas em um sistema robusto e customizvel

Viso Geral

Exerccios

Viso Geral

Espao para anotaes

2. Fases

Fases

Objetivos
Conhecer as fases do RUP Conhecer os objetivos e milestones de cada fase

Fases

Fases

As fases e os milestones de um projeto Pela perspectiva de gerenciamento, o ciclo de vida de software do RUP decomposto no tempo em quatro fases seqenciais, cada uma concluda por um milestone (marco) principal. Cada fase essencialmente um intervalo de tempo entro dois milestones principais. A cada final de fase, uma avaliao executada (Atividade: Reviso de Marco de Ciclo de Vida) para determinar se os objetivos da fase foram atingidos. Um julgamento satisfatrio possibilita que o projeto passe para a prxima fase.

Planejamento das Fases


As fases no so idnticas nem em termos de cronograma nem em durao. Apesar de poder variar consideravelmente dependendo do projeto, um ciclo de desenvolvimento inicial tpico em um projeto de tamanho mdio pode seguir a seguinte distribuio entre esforo e durao (tempo): Inception Esforo Durao ~5 % 10 % Elaboration 20 % 30 % Construction 65 % 50 % Transition 10% 10%

Que pode ser colocado graficamente como:

Fases

Para um ciclo de evoluo, as fases de inception e elaboration sero consideravelmente menores. Ferramentas que podem automatizar alguma parte do esforo de Construo podem mudar essa viso, fazendo com que a fase de construction possa ser muito menor do que as fases de inception e elaboration juntas. Uma passada atravs das quatro fases compe um ciclo de desenvolvimento. Cada passada produz uma gerao de um software. A menos que o produto morra, ele ira evoluir para sua prxima gerao repetindo a mesma seqncia de fases de inception, elaboration, construction e transition, mas desta vez com nfase diferente nas vrias fases. Esses ciclos subseqentes so chamados de ciclos de evoluo. A medida que o produto vai atravs de vrios ciclos, novas geraes so produzidas.

Ciclos de evoluo podem ser disparados por melhorias sugeridas pelo usurio, por mudanas no contexto do usurio, mudanas na tecnologia, reao a competio e assim por diante. Ciclos de evoluo tipicamente tm fases de Inception e Elaboration mais curtas, uma vez que a definio bsica do produto e da arquitetura foi determinada pelos ciclos de desenvolvimento anteriores. Excees para essa regra so ciclos de evoluo nos quais ocorre redefinio significativa do produto ou da arquitetura.

Fases

Inception (Concepo)
Objetivos
A meta mais importante da fase de inception obter o envolvimento de todos os interessados sobre os objetivos do ciclo de vida do projeto. A fase de inception tem significncia primordial para esforos em novos desenvolvimentos, nos quais existem riscos significativos de negcio e requisitos que devem ser endereados antes que o projeto possa prosseguir. Para projetos focados em melhorias em um sistema existente, a fase de inception mais breve, mas ainda focada em assegurar que o projeto vale a pena ser feito (retorno) e que vivel (possvel) de se fazer. Os objetivos primordiaisda fase de inception incluem:

Estabelecer o escopo e as condies de limite para o projeto de software, incluindo uma viso operacional, critrios de aceitao e o que se entende que o produto deve ser e o que no deve. Discriminar os casos de uso crticos do sistema, os cenrios primordias de operao que iro conduzir as principais decises de projeto. Evidenciar e talvez demonstrar, ao menos uma arquitetura candidata para alguns dos cenrios primordiais. Estimar o custo e o cronograma geral para todo o projeto (e estimativas mais detalhadas para a fase de elaboration que vir em seguida) Estimar os riscos potenciais (as fontes de imprevisibilidade) Preparar o ambiente de trabalho que ir dar suporte para o projeto

Atividades Essenciais
Formular o escopo do projeto. Isto envolve capturar o contexto e os requisitos e restries mais importantes a uma extenso tal que possa derivar os critrios de aceitao para o produto final. Planejar e preparar um business case (caso de negcio). Avaliar alternativas para gerenciamento de riscos, pessoal, planejamento do projeto e decises de custo/cronograma/rentabilidade. Sintetizar a arquitetura candidata, avaliar as decises de projeto (design) e em construir/comprar/reusar, para que custo, cronograma e recursos possam ser estimados. A meta aqui demonstrar a factibilidade atravs de algum tipo de prova de conceito (proof of concept). Isto pode tomar a forma de um modelo que simula o que requerido ou um prottipo que explora o que pode ser considerado como sendo rea de alto risco. O

Fases

esforo de prototipao durante a inception deve ser limitado a adquirir confiana que a soluo possvel a soluo realizada durante a elaborao e a construo. Preparar o ambiente de trabalho para o projeto, avaliar o projeto e a organizao, selecionar ferramentas, decidir que partes do processo devem ser melhoradas.

Milestone: Lifecycle Objectives


O milestone Lifecycle Objectives avalia basicamente a viabilidade do projeto. Ao final da fase de inception est o primeiro dos milestones principais do projeto. Neste ponto, voc examina os objetivos para o ciclo de vida do projeto e decide se deve prosseguir com o projeto ou cancela-lo. Critrios de Avaliao:

Envolvimento dos interessados (stakeholders) na definio do escopo e nas estimativas de custo e cronograma Acordo de que o conjunto correto de requisitos foi capturado e que h um entendimento geral destes requisitos Acordo de que as estimativas de custo e cronograma, prioridades, riscos e processo de desenvolvimento esto apropriados. Todos os riscos foram identificados e existe uma estratgia de mitigao para cada um.

O projeto pode ser abortado ou consideravelmente re-pensado se ele falhar em alcanar este milestone.

Artefatos
Artefatos Essenciais (em ordem de importncia) Viso Business Case Lista de Riscos Plano de Desenvolviment o de Software Estado no milestone

Os requisitos centrais do projeto, funcionalidades chave e restries principais esto documentados. Definido e aprovado. Riscos iniciais do projeto identificados. Fases iniciais, suas duraes e objetivos identificados. Estimativas de recursos (especificamente tempo, pessoal e os custos do ambiente de desenvolvimento em particular) no PDS devem estar consistentes com o Business Case. A estimativa de recursos pode, ou incluir todo o projeto at a entrega, ou apenas estimar os recursos necessrios para ir at a fase de elaboration. Estimativas dos recursos requeridos para todo o projeto, nesse ponto, devem ser

Fases

vistas como grosseiras, um chute. Esta estimativa atualizada em cada fase e em cada iterao e se torna mais precisa a cada iterao. Dependendo das necessidades do projeto, um ou mais dos artefatos de Planejamento includos podem ser opcionalmente completados. Adicionalmente, os artefatos Guidelines esto tipicamente, pelo menos em forma de draft. Plano de Iterao Plano de aceitao do produto Caso de Desenvolviment o Templates especficos para o projeto Guidelines para a Modelagem de Casos de Uso Ferramentas Plano de Iterao para a primeira iterao da fase de Elaboration deve estar completo e revisado. Revisado e com data de referncia (baseline); ser refinado em iteraes subseqentes ao se descobrirem requisitos adicionais. Adaptaes e extenses ao RUP, documentadas e revisadas. Os templates dos documentos usados para desenvolver os artefatos documentais. Com data de referncia (baseline).

Todas as ferramentas de suporte ao projeto esto selecionadas. As ferramentas necessrias para o trabalha na Inception esto instaladas. Termos importantes definidos; glossrio revisado. Atores e Casos de Uso importantes identificados e a seqncia de eventos desenhada em linhas gerais para os casos de uso mais crticos. Estado no milestone Os conceitos chave que esto sendo usados no sistema, documentados e revisados. Usado como uma extenso ao Glossrio nos casos onde h relacionamentos especficos entre conceitos cuja captura essencial.

Glossrio Modelo de Casos de Uso (Atores, Casos de Uso). Artefatos Opcionais Modelo de Domnio (tambm conhecido como Modelo de Objetos de Negcio). Prottipos

Um ou mais prottipos de prova de conceito, para auxiliar a Viso e o Business Case e para enderear os riscos mais especficos.

Fases

Elaboration (Elaborao)
Objetivos
A meta da fase de elaborao definir uma base para a arquitetura do sistema de forma a produzir uma fundao estvel para o esforo maior de projeto e implentao que ocorrer na fase de construction. A arquitetura evolui da considerao dos requisitos mais significativos (aqueles que tm grande impacto na arquitetura do sistema) e da avaliao dos riscos. A estabilidade da arquitetura validada atravs de um ou mais prottipos arquiteturais. Os objetivos primordiais da fase de elaboration incluem:

Assegurar que a arquitetura, requisitos e planos so estveis o suficiente, e os riscos suficientemente mitigados para possibilitar a previsibilidade na determinao do custo e cronograma para completar o desenvolvimento. Para muitos projetos, passar esse milestone tambm corresponde a uma transio de uma operao leve e rpida, de baixo risco, para uma operao de alto custo e alto risco com uma inrcia organizacional substancial. Enderear todos os riscos arquiteturais significativos do projeto Estabelecer uma base para a arquitetura derivada do endereamento dos cenrios arquiteturais significativos, os quais tipicamente expem os maiores riscos tcnicos do projeto. Produzir um prottipo evolucionrio de componentes com qualidade de produo, bem como possivelmente um ou mais prottipos exploratrios, no economize prottipos para mitigar riscos especficos, como: o Decises de projeto e requisitos o Reuso de componentes o Factibilidade do produto ou demonstraes para investidores, clientes e usurios finais

Demonstrar que a arquitetura base vai suportar os requisitos do sistema a um custo razovel em um tempo razovel Estabelecer um ambiente de suporte

Visando atingir esses objetivos, igualmente importante montar e configurar o ambiente de trabalho e suporte para o projeto. Isto inclui criar um caso de desenvolvimento, templates, guias e disponibilizar as ferramentas.

Atividades Essenciais

Definir, validar e estabelecer uma arquitetura rpida e prtica.

Fases

Refinar a Viso, baseado nas informaes novas obtidas durante a fase, estabelecendo um entendimento slido dos casos de uso mais crticos que conduzem as decises arquiteturais e de planejamento. Criar e estabelecer planos de iterao detalhados para a fase de construo. Refinar o caso de desenvolvimento e montar o ambiente de desenvolvimento, incluindo o processo, ferramentas e suporte automatizado requerido para suportar o time de construo. Refinar a arquitetura e selecionar componentes. Os componentes potenciais esto validados e as decises de construir/comprar/reusar esto suficientemente definidas para determinar o custo e cronograma da fase de construction com confiana. Os componentes arquiteturais selecionados esto integrados e validados contra os cenrios primordiais. As lies aprendidas nestas atividades podem bem resultar em um reprojeto da arquitetura, levando em considerao projetos alternativos ou reconsiderao dos requisitos.

Milestone: Lifecycle Architecture


O milestone Lifecycle Architecture estabelece uma referncia gerencivel para a arquitetura do sistema e torna possvel ao time de projeto ganhar em escala durante a fase de Construction. O final da fase de elaboration marca o segundo milestone importante do projeto, o milestone Lifecycle Arquitecture. Neste ponto, voc examina o detalhamento dos objetivos de sistema e do escopo, a escolha da arquitetura e a resoluo dos riscos principais. Cririos de Avaliao A Viso do produto e os requisitos esto estveis A arquitetura est estvel Os prottipos executveis demonstram que os elementos de maior risco foram endereados e foram resolvidos com credibilidade Os planos de iterao para a fase de construction esto em detalhamento e fidelidade suficiente para permitir o prosseguimento do trabalho Os planos das iteraes para a fase de construction esto baseados por estimativas confiveis Todos os envolvidos concordam que a viso corrente pode ser atingida se o plano corrente for executado para desenvolver o sistema completo, de acordo com contexto da arquitetura corrente. Os recursos gastos at o momento so aceitveis de acordo com o plano de gastos.

Fases

O projeto pode ser abortado ou consideravelmente re-pensado se ele falha em alcanar esse milestone.

Artefatos
Artefatos Essenciais (em ordem de importncia) Prottipos Estado no milestone

Um ou mais prottipos arquiteturais executveis foram criados para explorar funcionalidades crticas e cenrios arquiteturalmente significativos. Atualizada e revisada. Novos riscos so propensos a ser de natureza arquitetural, primordialmente relacionadas a manipulao de requisitos no funcionais. Refinado com base na experincia inicial do projeto. O ambiente de trabalho para o desenvolvimento, inclusive o processo, ferramentas e suporte automatizado requerido para auxiliar o time de construo instalado e colocado em operao. Os templates do documento usados para desenvolver os artefatos documentais. As ferramentas usadas para o trabalho na Elaborao so instaladas. Criado e estabelecido, incluindo descries detalhadas para os casos de uso arquiteturalmente significativos (use-case view), identificao dos mecanismos chave e dos elementos chave de projeto (logical view), mais a definio do process view e da deployment view (do Modelo de Deployment) se o sistema distribudo ou deve lidar com questes de concorrencia. Definido e estabelecido. A realizao dos casos de uso para os cenrios significativos arquiteturalmente esto definidos o o comportamento requerido est alocado para os elementos apropriados do projeto. Componentes esto identificados e as decises construir/comprar/reusar esto suficientemente entendidas para determinao do custo e cronograma da fase de construction com confiana. Os componentes arquiteturais selecionados esto integrados e avaliados contra os cenrios primoriais. As lies aprendidas a partir destas atividades podem resultar em uma redefinio da arquitetura, levando em considerao designs alternativos ou reconsiderao dos requisitos. Definido e estabelecido. Os elementos principais do modelo

Lista de Riscos

Caso de Desenvolviment o

Templates especficos do projeto Ferramentas Documento de Arquitetura de Software

Modelo de Projeto (e todos os artefatos que o constituem)

Modelo de

Fases

Dados Modelo de Implementao (e todos os artefatos que o constituem, inclusive os componentes) Viso

de dados (entidades, relacionamentos e tabelas importantes) esto definidos e revisados. Estrutura inicial criada e os componentes principais identificados e prototipados.

Refinada, baseada nas novas informaes obtidas durante a fase, estabelecendo um entendimento slido dos casos de uso mais crticos que conduzem as decises arquiteturais e de planejamento. Atualizado e expandido para cobrir as fases de Construction e Transition.

Plano de Desenvolviment o de Software

Guidelines, As guidelines usadas para auxiliar o trabalho. como guias de projeto e guias de programao. Plano de Iterao Modelo de Casos de Uso (Ators, Casos de Uso) Plano de iterao para a fase de construction completo e revisado. O modelo de casos de uso (aproximandamente 80% completo) todos os casos de uso foram identificados no mapeamento do modelo de casos de uso, todos os atores foram identificados e a maioria das descries de casos de uso (captura de requisitos) est desenvolvida. Requisitos suplementares capturando os requisitos no funcionais esto documentados e revisados. Estado no milestone Atualizado se as investigaes arquiteturais descobriram questes que mudam as premissas fundamentais do projeto. Deve ser desenvolvido como um artefato formal; frequentemente mantido de forma no formal, evoluindo ento para uma verso preliminar do Modelo de Projeto. Manuais de usurio e outros materiais de treinamento. Rascunhos preliminares, baseados nos casos de uso. Pode ser necessrio se o sistema tem aspectos importantes em interface de usurio.

Especificaes suplementares Artefatos Opcionais Business Case

Modelo de Anlise Materiais de Treinamento

Fases

Construction (Construo)
Objetivos
A meta na fase de construction esclarecer os requisitos restantes e completar o desenvolvimento do sistema baseado na arquitetura estabelecida. A fase de construction de alguma forma um processo de manufatura, onde a nfase colocada no gerenciamento de recursos e controle das operaes para otimizar custos, cronogramas e qualidade. Neste sentido a disciplina de gerenciamento passa por uma transio de desenvolvimento de propriedade intelectual durante a inception e elaboration, para o desenvolvimento de produtos entregveis durante a construction e a transition. Os objetivos primordiais da fase de construction incluem: Minimizar os custos do desenvolvimento pela otimizao dos recursos e eliminao de elementos dispensveis e retrabalhos desnecessrias. Atingir qualidade adequada de forma rpida e prtica Atingir veres utilizveis (alpha, beta, and other test releases) de forma rpida e prtica. Completar a anlise, projeto, desenvolvimento e teste de todas as funcionalidades requeridas. Desenvolver de forma iterativa e incremental um produto completo que estar pronto para a transio para a comunidade de usurios. Isto implica em descrever os casos de uso restantes e outros requisitos, detalhar o projeto (design), completar a implementao e testar o software. Decidir se o software, as locaes e os usurios esto todos prontos para a aplicao ser posta em uso. Atingir algum grau de paralelismo no trabalho dos times de desenvolvimento. Mesmo em projeto pequenos, geralmente existem componentes que podem ser desenvolvidos independentemente, permitindo paralelismo natural entre os times. Este paralelisto pode acelerar as atividades de desenvolvimento de forma significativa, mas incrementa a complexidade no gerenciamento dos recursos e na sincronizao dos workflows. Uma arquitetura robusta essencial quando se deseja atingir um nvel significativo de paralelismo.

Atividades Essenciais

Gerenciamento de recursos, controle e otimizao do processo. Completar o desenvolvimento dos componentes e testar contra os critrios de avaliao definidos

Fases

Avaliao das releases do produto contra os critrios de aceitao da Viso

Milestone: Initial Operational Capability


O milestone Initial Operational Capability determines se o produto est pronto para ser colocado em uso em um ambiente de beta-teste. Ao atingir este milestone, o produto est pronto para ser passado para o Time de Transio. Todas as funcionalidades foram desenvolvidas e todos os testes alfa (se houverem) foram completados. Em adio ao software, um manual de usurio foi desenvolvido e existe uma descrio da release atual. Critrios de Avaliao Os critrios de avaliao para a fase de construiction envolvem as respostas para as seguintes questes: A release do produto est estvel e madura o suficiente para ser colocada em uso na comunidade de usurios? Os envolvidos esto todos prontos para a transio para a comunidade de usurios? Os recursos gastos at o momento em relao aos gastos planejados ainda so aceitveis?

A transio pode ter de ser adiada para o prximo release se o projeto falhar em alcanar esse milestone.

Artefatos
Artefatos Essenciais (em ordem de importncia) O sistema Plano de Distribuio (Deployment) Modelo de Implementao (e todos os artefatos que o contituem, inclusive os componentes) Modelo de Testes (e todos Estado no milestone

O sistema executvel em si, pronto para comear os testes beta. Verso inicial desenvolvida, revisada e estabelecida.

Expandido a partir do que foi criado durante a fase de elaborao, todos os componentes criados ao final da fase de construction.

Testes projetados e desenvolvidos para validar as releases executveis criadas durante a fase de construction

Fases

os artefatos que o constituem) Material de Treinamento Manuais de usurio e outros materiais de treinamento. Rascunhos preliminares baseados em casos de uso. Podem ser necessrios se os sistema tem aspectos importantes na interface com o usurio. Plano de iterao para a fase de transition completo e revisado. Atualizado com novos elementos de projeto identificados durante a complementao de todos os requisitos.

Plano de Iterao Modelo de Projeto (e todos os artefatos que o constituem) Caso de Desenvolviment o Templates especficos do projeto Ferramentas Modelo de Dados Artefatos Opcionais Especificaes suplementares Modelo de Casos de Uso (Atores, Casos de Uso)

Refinado baseado na experincia anterior do projeto. O ambiente de trabalho, incluindo o pocesso, ferramentas e suporte automatizado requerido para auxiliar o time de transio est pronto para uso. Os templates de documentos usados para desenvolver os artefatos documentais. As ferramentas usadas para auxiliar o trabalho na Construction so instaladas. Atualizado com os elementos necessrios para suportar a implementao da persistncia (tabelas, ndices, mapeamento objeto-relacional, etc.) Estado no milestone Atualizado com novos requisitos (se houver) descobertos durante a fase de construction. Atualizado com novos casos de uso (se houver) descobertos durante a fase de construction.

Fases

Transition (Transio)
Objetivos
O foco da fase de Transition assegurar que o software est disponvel para seus usurios finais. A fase de Transition pode se extender por vrias iteraes, inclui o teste do produto em preparao para a liberao e ajustes menores baseados em feedback dos usurios. Neste ponto do ciclo de vida, o retorno do usurio deve focar principalmente no ajuste fino do produto, configurao, instalao e questes de usabilidade, todas as principais questes estruturais j foram trabalhadas muito antes no ciclo do projeto. Ao final da fse de Transition os objetivos do ciclo de vida devem ser atingidos e o projeto deve estar em posio de ser encerrado. Em alguns casos, o final do ciclo corrente pode coincidir com o incio de um outro ciclo de vida para o mesmo produto, levando a prxima gerao ou verso do produto. Para outros projetos, o final da Transition pode coincidir com a entrega completo dos artefatos a terceiros que sero agora responsveis pela operao, manuteno e melhorias no sistema entregue. A fase de Transition pode variar bastante, pode ser muito simples ou at extremamente complexa, dependendo do tipo do produto. Uma nova release de um produto de desktop existente pode ser muito simples, enquanto que a substituio de um sistema de controle de trfego areo de um pas pode extremamente complicado. As atividades executadas durante uma iterao na Fase de Transition dependem da meta a alcanar. Por exemplo, quando corrigindo bugs, implementao e teste so usualmente suficientes. Se, entretanto, novas features tem de ser adicionadas, a iterao similar a uma iterao da fase de construction, requerindo anlise e projeto e etc. A Fase de Transition entra quando uma verso est madura o suficiente para ser colocada em uso no domnio de usurio final. Isto usualmente requer que algum subconjunto utilizvel do sistema esteja completo e com nvel aceitvel de qualidade e com documentao de usurio de forma tal que a transio para o usurio produza resultados positivos para todas as partes. Os objetivos primordiais da Fase de Transition so: Beta testing para validao do novo sistema contra as expectativas dos usurios Beta testing e operao em paralelo relativa ao um sistema legado que est se substituindo Converso dos bancos de dados operacionais Treinamento dos usurios e equipe de manuteno Lanamento do produto no mercado, distribuio e fora de vendas.

Fases

Engenharia especfica de distribuio/entrega como cutover (troca de sistemas), empacotamento comercial e produo, lanamento de vendas e treinamento de pessoal de campo. Atividades de ajuste como correo de bugs, melhorias de performance e usabilidade. Avaliao da verso de distribuio contra a Viso completa e os critrios de aceitao do produto. Conseguir a auto-suficiencia dos usurios no uso sistema Conseguir a concordncia dos envolvidos de que a verso de distribuio est completa Conseguir a concordncia dos envolvidos de que a verso de distribuio est consistente de acordo com os critrios de avaliao da Viso

Atividades Essenciais
Executar os planos de entrega/distribuio Finalizar o material de suporte ao usurio final Testar o produto entregavel no ambiente de desenvolvimento Criar uma release do produto Obter feedback dos usurios Ajuste fino do produto baseado no feedback Tornar o produto disponvel para os usurios finais

Milestone: Product Release


O final da fase de transition marca o quarto milestone importante do projeto, o milestone Product Release. Neste ponto, voc decide se os objetivos foram atingidos e se voc deve iniciar um outro ciclo de desenvolvimento. Em alguns casos este milestone pode coincidir com o fim da fase de inception para o prximo ciclo. O milestone Product Release o resultado obtido ao completar com sucesso a Atividade: Reviso de Aceitao do Projeto. Critrios de Avaliao Os critrios de avaliao primordiais para a fase de transition envolve as respostas para as seguintes questes:

O usurio est satisfeito? Os recursos gastos at o momento em relao aos gastos planejados so aceitveis?

Ao chegar no milestone Product Release, o produto est em produo e o ciclo de manuteno ps release comea. Isto pode envolver o incio de um novo ciclo, ou algumas releases de manuteno adicionais.

Fases

Artefatos

Artefatos Essenciais (em ordem de importncia) A construo do produto (Product Build) Notas de Release Artefatos de Instalao Material de Treinamento End-User Support Material Artefatos Opcionais Test Model 'Shrinkwrap' Product Packaging

Estado no milestone

Completa e de acordo com os requisitos do produto. O produto final deve ser utilizvel pelo cliente. Completas Completos Completo para assegurar que o cliente possa tornar-se auto suficiente no uso e na manuteno do produto. Completo para assegurar que o cliente possa tornar-se auto suficiente no uso e na manuteno do produto. Estado no milestone The test model may be provided in the situation where the customer wants to runs on-site testing. In the case of creating a shrinkwrap product, the contractor will need the necessary packaging artifacts to help retail the product.

Fases

Exerccios

Fases

Espao para anotaes

3. Core Workflows

Core Workflows

Objetivos
Conhecer os principais workflows do RUP Relacionar os workflows a suas atividades e artefatos

Core Workflows

Anlise de Negcio

Proposta
A proposta da modelagem de negcio : Entender a estrutura e a dinmica da organizao na qual o sistema ser colocado em uso (a organizao alvo). Endender os problemas atuais da organizao alvo e identificar melhorias potenciais Assegurar que os clientes, usurios finais e desenvolvedores tem um entendimento comum da organizao alvo.

Core Workflows

Deduzir os requisitos do sistema necessrios para suportar a organizao alvo.

Para atingir a esses objetivos, o workflow de modelagem de negcios descreve como desenvolver uma viso da nova organizao alvo e, baseado nessa viso, definir o processo, papis e responsabilidades da organizao em um modelo de casos de uso de negcio e um modelo de objetos de negcio. Complementar a esses modelos, os seguintes artefatos so desenvolvidos: Especificaes de negcio suplementares Glossrio

Relacionamento com outros workflows


O workflow de modelagem de negcios relacionado com outros workflows, conforme segue: O workflow de Requisitos usa os modelos de negcio como entrada importante para o entendimento dos requisitos do sistema. O workflow de Anlise e Projeto usa as entidades de negcio como entrada para identificar as classes de entidade no modelo de projeto O workflow de Ambiente desenvolve e mantm os artefatos de suporte, como as Guidelines de Modelagem de Negcio.

Atividades

Core Workflows

Artefatos

Core Workflows

Requisitos

Proposta
A proposta do workflow de Requisitos :

Estabelecer e manter a concordncia com os clientes e outros envolvidos sobre o que o sistema deve fazer. Prover aos desenvolvedores do sistema um melhor entendimento sobre os requisitos do sistema. Definir os limites de extenso do sistema. Produzir uma base para o planejamento do contedo tcnico das iteraes. Produzir uma base para a estimativa de custos e de tempo para o desenvolvimento do sistema. Definir a interface do usurio para o sistema, focando nas necessidades e objetivos dos usurios.

Core Workflows

Para atingir essas metas, importante, antes de tudo, entender a definio e o escopo do problema que estamos tentando resolver com o sistema. Os Papis de Negcio, o Modelo de Casos de Uso de Negcio e o Modelo de Objetos de Negcio desenvolvidos durante a Modelagem de Negcio serviro como entradas valiosas para esse esforo. Os envolvidos (stakeholders) so identificados e as Solicitaes dos Envolvidos so elencadas, reunidas e analisadas. Um documento de Viso, um modelo de casos de uso, casos de uso e Especificaes Suplementares so desenvolvidas para descrever o sistema totalmente o que o sistema ir fazer em um esforo que v todos os envolvidos, incluindo clientes e usurios potenciais, como fontes importantes de informao (em adio aos requisitos do sistema). Requisies dos Envolvidos so ativamente elencadas e reunidas das fontes existente para obter uma lista de desejos de que os diferentes envolvidos no projeto (clientes, usurios, lderes de produto) esperam ou desejam que o sistema inclua, juntamente com a informao de como cada requisio est sendo considerada pelo projeto. O documento de Viso prove uma viso completa do sistema de software em desenvolvimento e auxilia no contrato entre a autoridade financiadora e a organizao desenvolvedora. Todo o projeto precisa de uma fonte para capturar as espectativas entre os envolvidos. O documento de viso escrito a partir da perspectiva do cliente, focando nas funcionalidades essenciais do sistema e nos nveis de qualidade aceitveis. A Viso deve incluir uma descrio de que funcionalidades sero includas, bem como aquelas que foram consideradas, mas no sero includas. Deve tambm especificar capacidade operacional (volumes, tempos de resposta, preciso), perfis de usurio (quem usar o sistema) e interfaces de interoperabilidade com entidades fora dos limites do sistema, quando aplicvel. O documento de Viso prov a base contratual para os requisitos visveis aos envolvidos. O modelo de casos de uso deve servir como um meio de comunicao e pode server como um contrato entre o cliente, os usurios e os desenvolvedores do sistema sobre as funcionalidades do sistema, o que possibilitar:

Aos clientes e usurios, validar que o sistema se tornar o que eles esperam. Aos desenvolvedores do sistema, desenvolver o que esperado.

O modelo de casos de uso consiste de casos de uso e atores. Cada caso de uso no modelo descrito em detalhes, mostrando passo a passo como o sistema interage com os atores e o que o sistema faz no caso de uso. Casos de uso funcionam como um fio de ligao ao longo do ciclo de vida do software; o mesmo modelo de casos de uso usado na anlise, projeto, implementao e teste do sistema. As Especificaes Suplementares so importantes complementos ao modelo de casos de uso, porque juntos eles capturam todos os requisitos do software (funcionais e no-funcionais) que precisam ser descritos para servir como uma especificao completa dos requisitos do software.

Core Workflows

Uma definio completa dos requisitos do software descritos nos casos de uso e nas Especificaes Suplementares pode ser empacotada em conjunto para definir a Especificao de Requisitos de Software (SRS Software Requirements Specification) para uma feature particular ou outros agrupamentos de subsistemas. Um Plano de Gerencia de Requisitos especifica os mecanismos de informao e controle que sero coletados e usados para medies, relatrios e controle de mudanas nos requisitos do produto. Complementando os artefatos mencionados acima, os seguintes so tambm desenvolvidos:

Glossrio Descries de casos de uso Prottipo de interface com o usurio

O glossrio importante porque define uma terminologia comum que usada consistentemente ao longo do projeto ou pela organizao. A Descrio de Casos de Uso e o Prottipo de Inteface com o Usurio so resultados da modelagem da interface do usurio e prototipao, que feita em paralelo com as outras atividades de requisitos. Estes artefatos produzem mecanismos de feedback importantes nas iteraes seguintes para a descoberta de requisitos desconhecidos ou no claros.

Relacionamento com outros workflows


O workflow de Requisitos est relacionado a outros workflows do processo. O workflow de Modelagem de Negcio prov Regras de Negcio, um Modelo de Casos de Uso de Negcio e um modelo de Objetos de Negcio, incluindo um Modelo de Domnio e o contexto organizacional para o sistema. O workflow de Anlise e Projeto obtm suas primeiras entradas (o modelo de casos de uso e o Glossrio) a partir do workflow de Requisitos. Falhas no modelo de casos de uso podem ser descobertas durante a Anlise e Projeto; requisies de mudana so ento geradas e aplicadas ao modelo de casos de uso. O workflow de Teste testa o sistema para verificar o cdigo contra o Modelo de Casos de Uso. Casos de Uso e Especificaes Suplementares provm entrada para os requisitos usados no planejamento e projeto dos testes. O workflow de Configurao e Mudana prov os mecanismos de controle de mudana para os requisitos. O mecanismo para propor uma mudana submeter uma Requisio de Mudana, que revisada pelo Comit de Controle de Mudanas. O workflow de Gerenciamento de Projeto planeja o projeto e cada iterao (descrita no Plano de Iterao). O modelo de casos de uso

Core Workflows

e o Plano de Gerenciamento de Requisitos so entradas importantes para as atividades de planejamento das iteraes. O workflow de Ambiente (Environment) desenvolve e mantm os artefatos de suporte que so usados durante o gerenciamento dos requisitos e a modelagem dos casos de uso, como as Guidelines para a Modelagem de Casos de Uso e as Guidelines para a Inteface de Usurio.

Atividades

Artefatos

Core Workflows

Anlise e Projeto

Proposta
A proposta da Anlise e Projeto : Transformar os requisitos em um projeto do que o sistema deve ser. Evoluir uma arquitetura robusta para o sistema. Adaptar o projeto para casar com o ambiente de implementao, projetando para a melhor performance.

Relacionamento com outros workflows


O workflow de Anlise e Projeto relacionado a outros workflows, como segue: O workflow de Modelagem de Negcio prov um contexto organizacional para o sistema. O workflow de Requisitos prov as primeiras entradas para Anlise e Projeto.

Core Workflows

O workflow de Teste testa o sistema projetado durante a Anlise e o Projeto. O workflow de Ambiente desenvolve e mantem os artefatos de suporte que so usados durante a Anlise e Projeto. O workflow de Gerenciamento de Projeto planeja o projeto e cada iterao (descritas no Plano de Iterao).

Atividades

Artefatos

Core Workflows

Implementao

Proposta
A proposta da implementao : Definir a organizao do cdigo, em termos da implementao de subsistemas organizados em layers (camadas), Implementar classes e objetos em termos de componentes (cdigos fonte, binrios, executveis e outros), Testar os componentes desenvolvidos como unidades, e Integrar os resultados produzidos pelos implementadores individuais (ou times) em um sistema executvel.

O workflow de Implementao limita seu escopo a como as classes individualmente devem ser testadas (unit testing). Testes de sistema e testes de integrao so descritos no workflow de Teste.

Core Workflows

Relacionamento com outros workflows


Implementao relacionada a outros workflows: O workflow de Requisitos descreve, no modelo de casos de uso, como capturar os requisitos que a implementao deve satisfazer. O workflow de Anlise e Projeto descreve como desenvolver o modelo de projeto. O modelo de projeto representa o plano para a implementao e a entrada primordial para o workflow de Implementao. O workflow de Teste descreve como sero feitos os testes de integrao dos builds durante a integrao do sistema. Ele tambm descreve como testar o sistema para verificar se todos os requisitos so satisfeitos, e ainda como os defeitos so detectados e submetidos. O workflow de Ambiente descreve como desenvolver e manter artefatos de suporte que so usados durante a implementao, como a descrio do processo, os guidelines de projeto e os guidelines de programao. O workflow de Deployment descreve como usar o modelo de implementao para produzir e entregar o cdigo ao cliente final. O workflow de Gerenciamento de Projeto descreve como planejar melhor o projeto. Aspectos importantes do processo de planejamento so o plano de iterao, o gerenciamento de mudanas e os sistemas de rastreamento de defeitos.

Atividades

Artefatos

Core Workflows

Teste

Proposta
As propostas deste workflow so: Verificar a interao entre os objetos. Verificar a integrao apropriade de todos os componentes do software. Verificar se todos os requisitos foram corretamente implementados. Identificar e assegurar que os defeitos encontrados sero endereados antes do software ser colocado em uso.

Em muitas organizaes, o teste de software responde de 30% a 50% dos custos de desenvolvimento de software. Ainda assim muitas pessoas acreditam que o software no bem testado antes de ser entregue. Esta

Core Workflows

contraio baseada em dois fatos claros. Primeiro, testar software extremamente difcil. As maneiras diferentes de que um dado programa pode se comportar no so quantificveis. Segundo, o teste feito usualmente sem uma metodologia clara e sem automatizao e sem ferramenta de suporte. Apesar da complexidade do software tornar o teste completo uma meta impossvel, uma metodologia bem concebida aliada ao uso de ferramentas avanadas, podem melhorar enormemente a produtividade e a eficincia no teste de software. Para sistemas de segurana crtica, onde uma falha pode causar danos a pessoas (como controle de trfego areo, controle de msseis ou sistemas mdicos), software de alta qualidade essencial para o sucesso do sistema produzido. Para um sistema de informaes gerenciais tpico, esta situao no to dolorosa, mas o impacto de um defeito ainda assim pode sair bastante caro. Testes bem executados, iniciando bem cedo no ciclo de vida do software, vo reduzir significativamente o custo de completar e manter o software. Tambm reduziro grandemente os riscos ou obrigaes associadas ao colocar em uso software de baixa qualidade, assim como baixa produtividade dos usurios, entrada de dados e erros de clculo e comportamento funcional inaceitvel. Nos dias atuais, muitos sistemas MIS so de sistemas de misso crtica, ou seja, as companhias no podem desempenhar satisfatriamente suas funes e experimentam grandes prejuzos quando uma falha ocorre. Por exemplo: bancos ou companhias de transporte. Sistema de Misso-crtica devem ser testados usando as mesmas abordagens rigorosas usadas por sistemas de segurana crtica.

Relacionamento com outros workflows


O workflow de teste relacionado a outros core workflows do processo: O workflow de Requisitos captura os requisitos no modelo de casos de uso, que uma das entradas primordiais para identificao dos testes a executar. O workflow de Anlise e Projeto descreve como desenvolver um projeto, este uma outra das entradas principais para identificar quais testes sero executados. O workflow de Implementao produz os builds do modelo de implementao que so testados pelo workflow de Teste. Dentro de uma iterao existem vrios builds sendo testados, primeiro quando o sistema integrado e no fim para testar todo o sistema. O workflow de Ambiente desenvolve e mantm os artefatos de suporte que so usados durante o teste, como as Guidelines de Teste. O workflow de Gerenciamento de Projeto planeja o projeto e cada iterao (descrito no Plano da Iterao)

Core Workflows

Atividades

Artefatos

Core Workflows

Deployment (Entrega)

Proposta
O workflow de Deployment (Entrega) descreve as atividades associadas em assegurar que o produto de software esteja disponvel para seus usrios finais.

Core Workflows

O workflow de Deployment descreve trs modos de deployment de produto:


Instalao customizada Oferta do produto empacotado Acesso ao software pela internet

Em cada instncia, existe uma nfase em testar o produto no local de desenvolvimento, seguido de beta-teste antes de o produto ser finalmente liberado para o cliente. Apesar das atividades de deployment terem seu pico na fase de Transition, algumas das atividades ocorrem em fases iniciais para planejar e prepara para a colocao em uso.

Relacionamento com outros workflows


O workflow de Deployment relacionado com outros workflows, conforme segue: O workflow de Requisitos produz a Especificao de Requisitos do Software que consiste do modelo de casos de uso e dos requisitos no funcionais. Em conjunto com o Prottipo de Interface com o Usurio, a Especificao de Requisitos do Software uma das entradas chave para o desenvolvimento dos Materiais de Suporte ao Usurio Final e aos Materiais de Treinamneto. Teste uma parte indispensvel do deployment e os artefatos essenciais do workflow de Teste so: o Modelo de Testes, os Resultados dos Testes e as atividades de gerenciamento, execuo e avaliao dos testes. O Gerenciamento de Configurao e Mudanas referenciado para prover o build estabelecido e a release do produto e os mecanismos para lidar com as Requisies de Mudana que so geradas como resultado dos beta-testes e dos testes de aceitao. No workflow de Gerenciamento de Projeto, as atividades para desenvolver um Plano de Iterao e um Plano de Desenvolvimento de Software iro influenciar no desenvolvimento do Plano de Entrega (Deployment Plan). Ainda, o trabalho para produzir o Plano de Aceitao do Produto tem de ser coordenado da mesma forma como voc gerencia os testes de aceitao no workflow de Deployment. O workflow de Ambiente prov suporte ao ambiente de testes.

Core Workflows

Atividades

Artefatos

Core Workflows

Gerenciamento de Configurao e Mudanas

Introduo
Parafraseando o SEI CMM (Software Engineering Institute's Capability Maturity Model), Gerenciamento de Configurao e Mudana controlam alteraes e mantm a integridade dos artefatos do projeto.

Core Workflows

Gerenciamento de Configurao e de Requisies de Mudana (CM e CRM) envolve: Identificar items de configurao, Restringir mudanas a esses items Auditar mudanas feitas a esses items, e Definir e gerenciar as configuraes destes items.

Os mtodos, processos e ferramentas usadas para prover gerenciamento de configurao e mudanas para uma organizao chamado de Sistema de CM da organizao. O Sistema de Gerenciamento de Configurao e Requisies de Mudana de uma organizao (Sistema de CM) tem as informaes chave sobre os processos de desenvolvimento de produtos, promoes, distribuio e manuteno e retm a base ativa de artefatos potencialmente reutilizveis resultantes da execuo destes processos. O Sistema de CM uma parte essencial e integral do sistema de desenvolvimento como um todo.

Proposta
Um Sistema de CM essencial para controlar os numerosos artefatos produzidos por muitas pessoas que trabalham em um projeto comum. O controle ajuda a evitar custosas confuses e assegura que os artefatos resultantes no so conflitantes devido a alguns dos seguintes tipos de problemas:

Core Workflows

Atualizaes simultneas Notificaes limitadas Mltiplas verses

Um Sistema de CM til para gerenciar variaes mltiplas de sistemas de software evolutivos, acompanhando que verses so usadas em determinado build do software, realizando build de programas individuais ou de releases inteiras de acordo com as especificaes de verso definidas pelo usurio e reforando polticas especficas de desenvolvimento. Alguns dos benefcios diretos produzidos por um Sistema de CM so: Suporta os mtodos de desenvolvimento, Manutm da integridade do produto, Assegura completude e correo do produto configurado, Prov um ambiente estvel dentro do qual se desenvolve o produto, Restringe mudanas aos artefatos baseado nas polticas do projeto, e Prove uma trilha de auditoria sobre por que, quando e por quem algum artefato foi mudado.

Adicionalmente, um Sistema de CM armazena dados detalhados sobre responsabilidades sobre o processo de desenvolvimento em si: quem criou uma vero particular (e quando, e porque), que verses de que fontes foram para um build particular e outras informaes relevantes.

Relacionamento com outros core workflows


O Sistema de CM de uma organizao usado ao longo de todo o ciclo de vida do produto, da incio at a colocao em uso. Como um repositrio de ativos de uma organizao, o Sistema de CM contm verses atuais e histricos dos arquivos fontes, de artefatos de equisitos, projeto e implentao que definem uma verso particular de um sistema ou de um componente. A Estrutura de Diretrios do Produto, representada no Sistema de CM, contm todos os artefatos requeridos para implementar o produto. Desta forma, o workflow de Gerenciamento de Configurao e Mudanas (CCM) relacionado com todos os outros workflows do processo e serve como repositrio para seus conjuntos resultantes de artefatos.

Core Workflows

Atividades

Artefatos

Core Workflows

Gerenciamento de Projeto

Introduo
Gerenciamento de Projeto de Software a arte de balancear objetivos conflitantes, gerenciar risco e superar restries para entregar com sucesso um produto que v ao encontro das necessidades tanto dos clientes (os que pagam a conta) como dos usurios. O fato de to poucos projetos serem sucessos indiscutveis comentrio suficiente sobre a dificuldade da tarefa.

Proposta
A proposta do Gerenciamento de Projeto : Prover os princpios bsicos para gerenciamento de projetos de software intensivo

Core Workflows

Prover guias prticos para planejamento, controle de pessoa, execuo e monitoramento de projetos. Prover os princpios bsicos para o gerenciamento de riscos

Entretanto, este workflow do RUP no tenciona cobrir todos os aspectos do gerencimento de projetos. Por exemplo, ele no cobre questes como:

Gerenciamento de pessoal: contratao, treinamento e coaching. Gerenciamento de oramento: definio, alocao, etc. Gerenciamento de contratos, com fornecedores e clientes.

Este workflow foca principalmento nos aspectos importantes de um processo de desenvolvimento iterativo: Gerenciamento de riscos Planejamento de um projeto iterativo, ao longo do ciclo de vida e para uma iterao particular Monitoramento do progresso de um projeto iterativo e mtricas

Relacionamento com outros workflows


O workflow de Gerenciamento de Projeto prov a base sobre a qual o projeto criado e gerenciado. Desta forma, todos os outros workflows so utilizados como parte do trabalho do projeto.

Atividades

Core Workflows

Artefatos

Core Workflows

Ambiente (Environment)

Proposta
O workflow de Environment (Ambiente) foca nas atividades necessrias para configurar o processo para um projeto. Ele descreve as atividades requeridas para desenvolver as guidelines de suporte de um projeto. A proposta das atividades de ambiente prover a organizao desenvolvedora de software com um ambiente de desenvolvimento de software completo ambos, processos e ferramentas que iro dar suporte ao time de desenvolvimento.

Relacionamento com outros workflows


O workflow de Ambiente prove ambiente de suporte para o projeto. Fazendo isso, suporta a todos os outros workflows.

Core Workflows

Atividades

Core Workflows

Artefatos

Core Workflows

Exerccios

Core Workflows

Espao para anotaes

4. Papis e Atividades

Papis e Atividades

Objetivos
Conhecer os papis do RUP Conhecer as atividades associadas a cada papel

Papis e Atividades

Analistas
O conjunto de papis de anlise inclui os papis envolvidos primordialmente em elencar e investigar requisitos.

Analista de Processos de Negcio


O Analista de Processos de Negcio lidera e coordena a modelagem de casos de uso de negcio enfatizando os pontos essenciais e delimitando a organizao que est sendo modelada. Por exemplo, estabelecendo quais so os atores de negcio e os casos de uso de negcio e como eles interagem.

Atividades Desenvolver os Guidelines para a Modelagem de Negcio


o

Desenvolver os Guidelines para a Modelagem de Negcio

Avaliar a Organizao Alvo o Descrever o status da organizao na qual a aplicao ser colocada em uso, em termos de seus processos correntes, ferramentas, compentncias pessoais, atitudes pessoais, clientes, competidores, tendncias tcnicas, problemas e reas de melhoria. o Motivar por que a organizao alvo deve ser melhorada. o Identificar envolvidos (stakeholders) para o esforo de modelagem de negcio.

Capturar um Vocabulrio de Negcios Comum

Papis e Atividades

o Definir um vocabulrio comum que possa ser usado em todas as descries textuais do negcio, especialmente em descries de casos de uso de negcio. Definir e Ajustar Metas o Definir os limites para o esforo de modelagem de negcio. o Desenvolver uma viso de futuro para a organizao alvo o Obter concordncia quanto as melhorias potenciais e as novas metas para a organizao alvo. o Descrever os objetivos primordiais para a organizao alvo.

Definir a Arquitetura do Negcio o Definir a arquitetura para o negcio. o Definir os padres de negocio, mecanismos chave e convenes de modelagem para o negcio.

Manter Regras de Negcio o Determinar quais regras de negcio considerar no projeto. o Dar definies detalhadas as regras de negcio.

Encontrar os Atores e os Casos de Uso de Negcio o Destacar os pontos essenciais dos processos de negcio.
o o

Definir os limites do negcio a ser modelado. Definir quem e o qu vai interagir com o negcio. Desenvolver uma viso geral do modelo de casos de uso de negcio. Extrair o comportamento nos casos de uso de negcio que podem ser considerados como casos de uso de negcio abstratos. Exemplos deste comportamento so comportamentos comuns, comportamentos opcionais e comportamento que ser desenvolvido em iteraes posteriores.

o Criar diagramas do modelo de casos de uso de negcio.


o

Estruturar o Modelo de Casos de Uso de Negcio


o

o Encontrar atores de negcio abstratos que definem papis que so compartilhados por vrios atores de negcio.

Projetista de Negcio
O papel de Projetista de Negcio detalha a especificao de parte da organizao descrevendo o fluxo de um ou mais casos de uso de negcio. Este papel especifica os trabalhadores do negcio e as entidades de negcio necessrias para a realizao de um caso de uso de negcio e distribui o comportamento dos casos de uso de negcio. O Projetista de Negcio define

Papis e Atividades

as responsabilidades, operaes, atributos e relacionamentos de um ou vrios trabalhadores e entidades do negcio.

Atividades Detalhar um Caso de Uso de Negcio o Descrever o workflow do caso de uso de negcio em detalhes. o Descrever o workflow do caso de uso de negcio de forma que o cliente, usurio e envolvidos possam entende-lo. Encontrar Trabalhadores e Entidades do Negcio
o o

Identificar todos os papis e coisas no negcio Descrever como as realizaes dos casos de uso de negcio so executadas pelos trabalhadores e entidadoes do negcio.

Detalhar um Trabalhador de Negcio o Detalhar as responsabilidades de um trabalhador do negcio. Detalhar uma Entidade de Negcio o Detalhar a definio de uma entidade de negcio. Definir os Requisitos de Automao o Entender como novas tecnologias podem ser usadas para tornar a organizao alvo mais eficiente. o Determinar o nvel de automao na organizao alvo. o Derivar os requisitos de sistema a partir dos artefatos de modelagem de negcio.

Revisor de Modelo de Negcio


O Revisor do Modelo de Negcio participal nas revises formais do modelo de caso de usos de negcio e o modelo de objetos de negcio.

Papis e Atividades

Atividades Revisar o Modelo de Casos de Uso de Negcio o Verificar formalmente que os resultados da modelagem de casos de uso de negcio esto de acordo com a viso de negcio dos stakeholders. Revisar o Modelo de Objetos de Negcio o Verificar formalmente que os resultados da modelagem dos objetos de negcio esto de acordo com a viso de negcio dos stakeholders.

Revisor de Requisitos
O Revisor de Requisitos planeja e conduz a reviso formal do modelo de casos de uso.

Atividades: Revisar Requisitos o Verificar formalmente que os resultados dos Requisitos esto de acordo com a viso do cliente sobre o sistema.

Analista de Sistemas
O papel de Analista de Sistemas lidera e coordena a captura dos requisitos e a modelagem de casos, encontrando os pontos essenciais das funcionalidades do sistema e delimitando o sistema. Por exemplo, estabelecendo que atores e que casos de uso existem e como eles interagem.

Papis e Atividades

Atividades: Desenvolver o Plano de Gerenciamento de Requisitos


o

Desenvolver um plano para documentar os requisitos, atributos e padres para rastreabilidade e gerenciamento dos requisitos do produto.

Desenvolver Guidelines para a Modelagem de Casos de Uso o Desenvolver guidelines para modelagem de casos de uso Capturar um Vocabulrio Comum o Definir um vocabulrio comum que pode ser usado em todoas as descries textuais do sistema, especialmente nas descries dos casos de uso.

Esclarecer as Requisies dos Envolvidos o Entender quem so os envolvidos no projeto


o

Coletar as requisies que o sistema precisa satisfazer

o Priorizar as requisies dos envolvidos Desenvolver a Viso o Obter concordncia sobre quais problemas precisam ser resolvidos. o Identificar os envolvidos no sistema. o Definir os limites do sistema. o Descrever as funcionalidades primordiais do sistema. Encontrar Atores e Casos de Uso o Encontrar os pontos essenciais das funcionalidades do sistema.
o

Definir que o que ser feito pelo sistema e o que ser feito fora do sistema.

o Definir quem e o que vai interagir com o sistema. o Dividir o modelo em pacotes com atores e casos de uso.

Papis e Atividades

o Criar diagramas do modelo de casos de uso. o Desenvolver uma viso geral do modelo de casos de uso. Estruturar o Modelo de Casos de Uso o Extrair o comportamento nos casos de uso que precisam ser considerados como abstratos. Por exemplo, comportamentos comuns, comportamentos opcionais, comportamentos excepcionais e comportamentos que sero desenvolvidos em iteraes posteriores. o Encontrar novos atores abstratos que definem papis que so compartilhados por vrios atores. Gerenciar Dependncias
o

Usar atributos e rastreabilidade dos requisitos do projeto para auxiliar no gerenciamento do escopo do projeto e gerenciamento de mudanas em requisitos.

Especificador de Requisitos
O papel de Especificador de Requisitos detalha a especificao de uma parte do sistema descrevendo os aspectos principais dos Requisitos de um ou mais casos de uso e de outros requisitos de suporte do software. O Especificador de Requisitos pode tambm ser responsvel por um pacote de casos de uso e pela manuteno da integridade deste pacote. recomendado que o Especificador de requisitos responsvel por um pacote de casos de uso seja tambm responsvel pelos casos de uso e atores nele contidos.

Atividades Detalhar um Caso de Uso o Descrever o fluxo de eventos de um caso de uso em detalhes.
o

Descrever o fluxo de eventos de um caso de uso de forma que o cliente e os usurios possam entend-lo.

Detalhar os Requisitos de Software

Papis e Atividades

o Coletar, detalhar e organizar o conjunto (pacote) de artefatos que descrevem completamento os requisitos de software do sistema ou subsistema.

Projetista de Interface com o Usurio


O Projetista de Interface com o Usurio lidera e coordena a prototipao e projeto da interface do usurio: Capturanto requisitos na interface do usurio, incluindo requisitdos de usabilidade. Construindo prottipos de interface de usurio. Envolvendo outros stakeholders de interface de usurio, como usurios finais em revises de usabilidade e sesses de teste de uso. Revisando e produzindo feedback apropriado na implementao final da interface de usurio, criada pelos outros desenvolvedores, ou seja, projetistas e implementadores.

Atividades Modelar a Interface de Usurio o Construir um modelo de interface de usurio que auxilia e possibilita a melhoria em sua usabilidade Prototipar a Interface do Usurio o Criar um prottipo da interface do usurio Desenvolver os guidelenes para Interface de Usurio o Desenvolver os guidelenes para Interface de Usurio

Papis e Atividades

Desenvolvedores
O conjunto de papis de Desenvolvedores organiza os papis envolvidos primordialmente em projetar e desenvolver o software.

Arquiteto de Software
O papel Arquiteto de Software lidera e coordena as atividades e artefatos tcnicos ao longo do projeto. O Arquiteto de Software estabelece a estrutura geral para cada viso arquitetural: a decomposio das views, o agrupamento dos elementos e as interfaces entre os grupos principais. Desta forma, em contraste aos outros papis, a viso do Arquiteto de Software mais abrangente do que aprofundada.

Atividades Priorizar os Casos de Uso


o

Definir entradas para a seleo do conjunto de cenrios e casos de uso que sero analisados na iterao corrente.

o Definir o conjunto de cenrios e casos de uso que representam as funcionalidades mais significativas. o Definir o conjunto de cenrios e casos de uso que tem cobertura arquitetural substancial (que iro exercitar muitos elementos arquiteturais) ou que estressam ou ilustram algum ponto especfico ou delicado da arquitetura. Anlise da Arquitetura

Papis e Atividades

o Definir uma arquitetura candidata para o sistema, baseada na experincia em sistemas similares ou em domnios de problemas similares. o Definir os padres arquiteturais, mecanismos chave e convenes de modelagem para o sistema. o Definir a estratgia para reuso o Produzir entrada para o processo de planejamento Identificar os Mecanismos de Projeto o Refinar os mecanismos de anlise em mecanismos de projeto baseado nas restries impostas pelo ambiente de implementao. Identificar os Elementos de Projeto o Analisar interaes das classes de anlise para identificar os elementos do modelo de projeto Incorporar Elementos de Projeto Existentes o Analisar interaes das classes de anlise para encontrar interfaces, classes de projeto e subsistemas de projeto. o Refinar a arquitetura, incorporanto reuso onde for possvel. o Identificar solues padro para os problemas de projeto mais comumente encontrados o Incluir os elementos do modelo de projeto arquiteturalmente significativos no Documento de Arquitetura de Software. Descrever a Distribuio o Descrever como a funcionalidade do sistema distribuda pelos ns fsicos. Necessrio apenas para sistemas distribudos. Descrever a Arquitetura de Execuo o Analisar os requisitos de concorrncia, identificar processos, identificar mecanismos de comunicao inter-processo, alocar recursos de coordenao inter-processo, identificar os ciclos de vida dos processos e distribuir os elementos do modelo entre os processos. Estruturar o Modelo de Implementao o Estabelecer a estrutura na qual a implementao vai residir. o Estabelecer responsabilidades para Subsistemas de Implementao e seu elementos. Desenvolver as Guidelines de Projeto o Desenvolver as Guidelines de Projeto Desenvolver as Guidelines de Programao

Papis e Atividades

o Desenvolver as Guidelines de Programao Construir uma Prova de Conceito Arquitetural o Sintetizar pelo menos uma soluo (que pode ser simplesmente conceitual) que satisfaa os requisitos arquiteturais crticos. Avaliar a Viabilidade da Prova de Conceito Arquitetural o Avaliar a Prova de Conceito Arquitetural sintetizada para determinar se os requisitos arquiteturais crticos so factveis e podem ser satisfeitos (por essa ou outra soluo).

Revisor de Arquitetura
O papel de Revisor de Arquitetura planeja e conduz as revises formais da arquitetura do software de forma geral.

Atividades Revisar a Arquitetura o Descobrir riscos desconhecidos ou percebidos ao cronograma ou oramento. o Detectar falhas no projeto arquitetural. Falhas arquiteturais so conhecidas como difceis de serem consertadas, causando danos no longo prazo.
o

Detectar potenciais desencontros entre os requisitos e a arquitetura: over-design, requisitos irreais ou requisitos faltantes. Em particular, a avaliao deve examinar alguns aspectos frequentemente negligenciados nas reas de operao, administrao e manuten. Como o sistema instalado? Atualizado? Como ser feita a transio a partir dos bancos de dados atuais?

o Avaliar uma ou mais qualidades arquiteturais especficas: performance, confiabilidade, modificabilidade, segurana. o Identificar oportunidades de reuso.

Projetista de Cpsulas (Capsule Designer)


O papel de Projetista de Cpsulas foca em assegurar que o sistema possa responder a eventos temporais, de acordo com os requisitos de concorrncia. O veculo primoridial para resolver estes problemas o Artefato: Cpsula.

Papis e Atividades

Atividades Projetar Cpsulas


o

Elaborar e refinar as descries de cpsulas.

Revisor de Cdigo
O papel do Revisor de Cdigo assegurar a qualidade do cdigo fonte e planejar e conduzir as revises de cdigos fonte. O Revisor de Cdigo tambm responsvel por dar feedback de qualquer retrabalho que possa resultar das atividades de reviso.

Revisar Cdigo o Verificar os cdigos fonte.

Projetista de Banco de Dados


O papel do Projetista de Banco de Dados de definir as tabelas, ndices, views, constraints, triggers, stored procedures, tablespaces ou parmetros de storage e outras contrues especficas de banco de dados necessrias para o armazenamento, recuperao e excluso dos objetos persistentes. Esta informao mantida no artefato: Modelo de Dados.

Atividades Projeto de Banco de Dados

Papis e Atividades

o Assegurar que os dados persistentes so armazenados de forma consistente e eficiente. o Definir comportamento que deve ser implementado no banco de dados.

Revisor de Projeto
O papel do Revisor de Projeto planejar e conduzir as revises formais do artefato: Modelo de Projeto.

Atividades Revisar o Projeto o Verificar se o modelo de projeto satisfaz plenamente os requisitos do sistema e se serve como boa base para a implementao.
o o

Assegurar que o modelo de projeto consistente com as guidelines gerais do projeto. Assegurar que as guidelines de projeto satisfazem seus objetivos.

Projetista
O papel do Projetista definir as responsabilidades, operaes, atributos e relacionamentos das classes e determinar como elas sero ajustadas ao ambiente de implementao. Adicionalmente, o Projetista pode ser responsvel por pacotes de projeto, ou subsistemas de projeto, incluindo as classes contidas nesses pacotes e subsistemas.

Papis e Atividades

Atividades Projeto de Classes o Assegurar que a classe prove o comportamento que a realizao do caso de uso requer. o Assegurar que informao suficiente provida para a implemtao da classe sem ambigidades. o Lidar com os requisitos no funcionais relacionados classe. o Incorporar os mecanismos de projeto usados pela classe. Projeto de Subsistemas o Definir os comportamentos especificados na interface do subsistema em termos da colaborao das classes contidas. o Documentar a estrutura interna do subsistema. o Definir realizaes entre a interface do subsistema e as classes contidas nele. o Determinar as dependncias com outros subsistemas. Anlise de Casos de Uso o Identificar as classes que executam o fluxo de eventos de um caso de uso. o Distrubuir o comportamento do caso de uso para essas classes, usando as realizaes do caso de uso. o Identificar responsabilidades, atributos e associaes das classes. o Observar o uso dos mecanismos arquiteturais. Projeto de Casos de Uso

Papis e Atividades

o Refinar as realizaes dos casos de uso em termos de interaes. o Refinar os requisitos sobre as operaes das classes de projeto. o Refinar os requisitos sobre as operaes dos subsistemas e/ou suas interfaces. o Refinar os requisitos sobre as operaes das cpsulas.

Projetar Testes de Pacotes e Classes o Projetar funcionalidades especficas de teste.

Implementador
O papel Implementador responsvel por desenvolver e testar componentes, de acordo com os padres de projeto adotados, para integrao em subsistemas maiores. Quando componentes de teste, como drivers ou stubs, precisam ser criados para suportar teste, o implementador tambm responsvel por desenvolver e testar os componentes de teste e os subsistemas correspondentes.

Atividades Implementar Componentes o Produzir cdigo fonte de acordo com o modelo de projeto. Consertar Defeitos
o

Consertar defeitos

Executor Testes de Unidade o Verificar a especificao de uma unidade. o Verificar a estrutura interna de uma unidade.

Implementar Componentes e Subsistemas de Teste o Implementar funcionalidades especficas de teste Desenvolver Artefatos de Instalao

Papis e Atividades

o Produzir todo o software requerido para instalar e desinstalar o produto de forma rpida, fcil e segura sem afetar outras aplicaes ou caractersticas do sistema.

Integrador
Implementadores entregam seus componentes testados em um espao de trabalho para integrao, esses componentes sero combinados pelos Integradores para produzir um build. Um Integrador tambm responsvel por planejar a integrao, que ter lugar nos nvels de sistema e subsistemas, onde cada um tem um espao de integrao separado.

Atividades Planejar a Integrao de Subsistemas o Planejar a ordem na qual os componentes contidos em um subsistema de implementao devem ser integrados.

Criar os Workspaces de Integrao


o

O workspace de Integrao similar aos workspaces privados dos implementadores, onde os indivduos podem desenvolver e mudar cdigo. O workspace de Integrao onde os integradores tabalham para demonstrar que os componentes desenvolvidos e testados separadamente podem de fato funcionar juntos como um produto.

Criar Baselines o Assegurar que todos os artefatos desenvolvidos so capturados e arquivados, em dados pontos no tempo, como base para o desenvolvimento posterior do produto.

Planejar a Integrao do Sistema o Planejar a integrao do sistema Integrar Subsistemas

Papis e Atividades

o Integrar os componentes em um subsistema de implementao e ento entregar o subsistema para a Integrao de Sistema. Integrar o Sistema o Integrar os subsistemas de implementao em um build. Promover Baselines
o

A proposta desta atividade assegurar que baselines (componentes testados individualmento de vrios implementadores e times de desenvolvimento combinados para funcionar como produto) esto rotuladas (tagged) para refletir o nvel do software em maturidade, estabilidade e qualidade que foi atingido.

Verificar Mudanas no Build o A proposta de ter um processo padro e documentado de controle de mudanas assegurar que mudanas so feitas em um projeto de forma consistente e os stakeholders apropriados so informados do estado do produto, mudanas feitas e o impacto em custo e cronograma dessas mudanas.

Papis e Atividades

Testadores
O conjunto de Testadores organiza os papis envolvidos primordialmente no teste de software.

Testador
O testador responsvel por: Preparar e executar testes Avaliar a execuo dos testes Recuperao de erros

Atividades Executar Testes o Executar testes e capturar os resultados dos testes.

Projetista de Testes
O Projetista de Testes o papel principal em teste e responsvel pelo planejamento, projeto, implentao e avaliao do teste, incluindo:

Gerao do plano de teste e do modelo de testes Implementao dos procedimentos de teste Avaliao da cobertura, dos resultdados e da eficcia dos testes Gerao do resumo dos testes de avaliao

Papis e Atividades

Atividades Planejar Testes o Coletar e organizar a informao de planejamento de testes o Criar o plano de testes. Projetar Testes o Identificar um conjunto de testes verificveis para cada build. o Identificar procedimentos de teste que mostram como os casos de teste sero realizados. Implementar Testes o Criar ou gerar scripts de testes reutilizveis o Manter a rastreabilidade dos artefatos de implementao de teste com os casos de teste associados e os requisitos dos casos de uso para teste. Avaliar Testes
o

Avaliar os resultados dos testes e criar requisies de mudana

o Calcular e entregar as medies dos testes. o Gerar o resumo dos testes de avaliao. Desenvolver os Guidelines de Teste o Desenvolver os Guidelines de Teste

Papis e Atividades

Gerentes
O conjunto de Gerentes organiza os papis envolvidos primordialmente em gerenciamento e configurao do processo de engenharia de software.

Gerente de Controle de Mudanas


O papel de Gerente de Controle de Mudanas supervisiona o processo de controle de mudanas. Este papel geralmente realizado por um Comit de Controle de Configurao (ou Mudana) e consiste de representantes de todas as partes interessadas, incluindo clientes, desenvolvedores e usurios. Em um projeto pequeno, um membro do time, como o gerente do projeto ou o arquiteto de software pode desempenhar este papel. O Gerende de Controle de Mudanas tambm responsvel por definir o Processo de Gerenciamento de Requisies de Mudana, que documentado no Plano de Gerencia de Configurao (CM Plan).

Atividades Estabelecer o Processo de Controle de Mudanas Revisar Requisies de Mudana o A proposta de ter processos de controle de mudanas padronizados e documentados assegurar que as mudanas so feitas em um projeto de forma consistente e que os stakeholders apropriados so informados do estado do produto, mudanas e o impacto destas no custo e no cronograma. Confirmar Requisies de Mudanas Duplicadas ou Rejeitadas o Um administrador designado pelo Comit deve ser alocado para confirmar requisies de mudana duplicadas ou invlidas.

Papis e Atividades

Gerente de Configurao
O Gerente de Configurao prov toda a infraestrutura e ambiente de Gerencia de Configurao (CM) para o time de desenvolvimento do produto. A funo do CM suportar o atividade de desenvolvimento do produto de forma que os desenvolvedores e integradores tenham workspaces apropriados para construir e testar seu trabalho e de forma que todos os artefatos estejam disponveis para incluso na unidade de deploy quando necessrio. O Gerente de configurao tambm deve assegurar que o ambiente de CM facilite a reviso do produto e as atividades de mudana e rastreabilidade de defeitos. O Gerente de Configurao tambm responsvel por escrever o Plano de CM e reportar estatsticas de progresso baseadas em requisies de mudanas.

Atividades Establish Configuration Management (CM) Policies o CM policies are used to monitor and safeguard project assets, and to enforce software development practices. Project policies should improve communication amongst the team members and minimize problems encountered when integrating their work. Preparar o Ambiente de Gerencia de Configurao o A proposta desta atividade estabelecer um ambiente onde o produto possa ser desenvolvido e construdo. Isto feito em duas etapas, primeiro preparando o ambiente de hardware e depois estabelecendo o ambiente de desenvolvimento. o Preparar o ambiente de CM envolve alocao de recursos de mquina (servidores e espao em disco) e instalao das ferramentas de gerenciamento de configurao. o Preparar o ambiente de desenvolvimento envolve criao de repositrios, preparar a estrutura de diretrios do produto e importar arquivos existentes. O ambiente inicial serve como base para o trabalho de desenvolvimento posterior. Realizar Auditoria de Configurao

Papis e Atividades

o Determinar que uma baseline contm todos os artefatos requeridos o Determinar que uma baseline satisfaz os requisitos. Criar Unidade de Deployment o Uma unidade de deployment consiste de um build (uma coleo de componentes executvel), documentos (material de suporte ao usurio final e notas de verso) e artefatos de instalao. A proposta desta atividade criar uma unidade de deployment que suficientemente completa para ser obtida, instalada e possa rodar.

Relatar Status de Configurao


o

Suportar as atividades de Relato de Status de Configurao que so baseadas em registros formalizados e relatrios de status de mudanas propostas e status de implementao de mudanas propostas. Facilitar a reviso do produto atravs do acompanhamento de defeitos e atividades de relatrios.

o Assegurar que os dados so distribudos e relatados para acompanhamento de progresso. Escrever o Plando de Gerenciamento de Configurao (CM Plan) o Descrever todas as atividades relacionadas a CM que devem ser realizadas durante o curso do ciclo de vida do produt/projeto. o Documentar como as atividades de CM relacionadas ao produto devem ser planejadas, implementadas, controladas e organizadas.

Gerente de Deployment
O papel de Gerente de Deployment planeja e documenta a transio do produto para a comunidade usuria.

Desenvolver o Plano de Deployment

Papis e Atividades

o O plano de Deployment documenta como e quando o produto deve ser disponibilizado para a comunidade usuria. Definir a Lista de Materiais o Criar uma lista completa de artefatos que compe um build/pdoruto. A lista inclui itens de configurao do software, documentos e scripts de instalao. No caso de produtos empacotados a Lista de Matrias precisa identificar as peas de arte final e os itens do pacote que compe o produto final. Controlar os Testes de Aceitao o Assegurar que o produto desenvolvido satisfaz os critrios de aceitao tanto nos sites de desenvolvimento quanto em produo Controlar os Testes Beta
o

Um testes Beta um teste de pr-release no qual uma amostragem do pblico alvo testa o produto. O beta-teste serve a duas propostas. Primeiramente ele d ao produto um teste em um mundo real controlado e depois, ele fornece um preview para a prxima release. O Gerente de Deployment precisa gerenciar o programa de beta testes do produto para assegurar que ambas as propostas sero seguidas. Descrever as principais mudanas e funcionalidades novas na vero. As Notas de Verso devem tambm descrever os problemas conhecidos e limitaes ou workarounds para o uso do produto.

Escrever as Notas de Verso


o

Prover Acesso ao Site de Download o Assegurar que o produto est disponvel para compra e download na internet.

Liberar para a Manufatura o Produo em massa da verso empacotada do produto. Verificar o Produto Manufaturado o Assegurar que o produto manufatorado est completo e utilizvel. Esta atividade por vezes referida como first article inspection. Server como atividade de controle de qualidade para assegurar que o produto vendido tem todos os atributos e artefatos requeridos.

Engenheiro de Processos
O papel de Engenheiro de Processos responsvel pelo processo de desenvolvimento de software em si. Isto inclui a configurao do processo

Papis e Atividades

antes do incio do projeto e a melhoria contnua do processo durante os esforos de desenvolvimento.

Atividades Avaliar a Organizao


o

Descrever o estado atual da organizao de software em temos de seus processos correntes, ferramentas, competncias pessoais, atitudes pessoais, clientes, competidores, tendncias tcnicas, problemas e reas de melhoria.

Desenvolver Templates Especficos para o Projeto o Desenvolver os templates para os documentos e relatrios usados no projeto

Desenvolver o Caso de Desenvolvimento o Desenvolver o Caso de Desenvolvimento que descreve o processo de desenvolvimento de software para um projeto. o Relacionar o Caso de Desenvolvimento ao processo de produto especfico da organizao.

Disparar o Caso de Desenvolvimento o Fazer os membros do projeto utilizarem o Caso de Desenvolvimento em conjunto com as ferramentas de suporte.

Gerente de Projeto
O papel do Gerente de Projeto alocar recursos, formar prioridades, coordenar interaes com clientes e usurios e, de forma geral, manter o time do projeto focado nos objetivos corretos. O Gerente do Projeto tambm estabelece um conjunto de prticas que asseguram a integridade e qualidade dos artefatos do projeto.

Papis e Atividades

Atividades Desenvolver o Caso de Negcio o Desenvolver a justificativa econmica para o produto. Identificar e Avaliar Riscos o Identificar, analisar e priorizar riscos para o projeto e determinar estratgias apropriadas para o gerenciamento dos riscos. o Atualizar a Lista de Riscos para refletir o status atual do projeto. Iniciar o Projeto o Recrutar o time que ira planejar o projeto e definir os critrios para medida de sucesso do projeto. Definir os Processos de Monitoramento e Controle o Definir as informaes e os processos que sero usados para monitorar e controlar o progresso do projeto, qualidade e riscos.

Papis e Atividades

Planejar Fases e Iteraes


o

Estimar o escopo, esforo e custo para todo o projeto.

o Desenvolver um plano coarse-grained para o projeto, focando nos milestones principais e nas entregas chave dentro do ciclo de vida do produto. o Definir um conjunto de iteraes dentro das fases do projeto e identificar os objetivos para cada uma das iteraes. o Desenvolver o cronograma e oramento para o projeto. o Desenvolver um plano de recursos para o projeto. o Definir as atividades para a execuo ordenada e completa do projeto. Desenvolver um Plano de Mtricas o Definir metas de gerenciamento em termos de qualidade, progresso e melhoria. o Determinar o que precisa ser medido periodicamente para dar suporte a essas metas. Definir a Organizao e o Pessoal do Projeto
o

Definir uma uma estrutura organizacional para o projeto

o Baseado nas estimativas de esforo, definir os requisitos de staff em termos de nmero, tipos e nveis de experincia para a prxima iterao (com menos incertezas) e para iteraes subseqentes, com mais incertezas, para possibilitar o incio do recrutamento do pessoal, se isso for um risco. Compilar o Plano de Desenvolvimento de Software o Coordenar o desenvolvimento de todos os planos associados e contedo para a publicao de um documento de Plano de Desenvolvimento de Software. Desenvolver o Plano de Aceitao do Produto o Criar um procedimento escrito em concordncia com o cliente e o time do projeto para determinar a aceitabilidade dos deliverables do projeto.
o

Definir um processo acordado sobre como problemas identificados durante a aceitao do produto sero resolvidos.

Desenvolver um Plano de Gerenciamento de Riscos o Criar um plano documentado para identificar, analisar e priorizar riscos.
o

Identificar as estratgias de gerenciamento de risco para os riscos mais significativos do projeto.

Papis e Atividades

Desenvolver um Plano de Resoluo de Problemas o Criar um plano documentado provendo um procedimento definido para gerenciar e resolver problemas experimentados durante o projeto.

Desenvolver o Plano de Iterao o Desenvolver um plano fine-grained para uma iterao, consistindo de: Uma WBS (Work Breakdown Structure) detalhada das atividades e da associao de responsabilidades Os milestones e deliverables dentro da iterao Os critrios de avaliao para a iterao

Alocar Pessoal o Comprometer os recursos humanos para o projeto o Mapear os recursos disponveis quanto as habilidades necessrias para o projeto.
o

Agrupar os recursos disponveis em times relativamente independentes, mas colaborativos.

Iniciar a Iterao o Alocar pessoal e outros recursos para os pacotes de trabalho identificados para a iterao atual

Avaliar a Iterao o Determinar o sucesso ou fracasso da iterao o Capturar as lies aprendidas para modificar o projeto ou melhorar o processo

Prepara para o Fechamento da Fase o Preparar o projeto para o final de uma fase e preparar o material para a Reviso do Milestone.

Prepara para o Fechamento do Projeto o Completar as formalidades associadas com a aceitao do projeto e fechamento, realocao de pessoal e transferncia de outros recursos do projeto.

Monitorar o Status do Projeto o Capturar o status corrente do projeto o Avaliar o status contra o planejamento

Agendar e Alocar Trabalho o Acomodar mudanas aprovadas (defeitos, melhorias) ao produto e processo que aparecem durante uma iterao.

Relatar Status

Papis e Atividades o o

Prover atualizaes regulares sobre o status do projeto para reviso pelas Autoridades de Reviso do Projeto (PRA). Escalar questes que vo alm da autoridade do gerente de projeto para resoluo pela PRA.

Lidar com Excees e Problemas o Iniciar aes corretivas apropriadas para problemas e excees que surgem no projeto

Desenvolver o Plano de Garantia de Qualidade o Criar um plano documentado para a garantia de qualidade das atividades no projeto.

Revisor de Projeto
O papel de Revisor de Projeto responsvel pela avaliao dos artefatos de planejamento do projeto e pela avaliao dos artefatos nos pontos de reviso principais dentro do ciclo de vida do projeto. Estas so eventos de reviso significativos porque eles marcam pontos nos quais o projeto pode ser cancelado caso o planejamento esteja inadequado ou se o progresso est inaceitavelmente pobre.

Atividades

Reviso de Aprovao do Projeto


o

Determinar, do ponto de vista de negcio, se o projeto vale o investimento. Aprovar o Plano de Desenvolvimento de Software Inicial Revisar e aprovar mudanas no Plano de Desenvolvimento de Software Aprovar o plano de trabalho proposto para a iterao atual. Revisar o progresso feito no projeto em conjunto com a PRA.

Reviso do Planejamento do Projeto


o o

Reviso do Plano de Iterao


o

Reviso do Projeto com a Autoridade de Reviso do Projeto (PRA)


o

Reviso dos Critrios de Avaliao da Iterao

Papis e Atividades o

Aprovar os critrios que sero usados para determinar se o trabalho completado durante a iterao atinge os objetivos. Aceitar formalmente o trabalho de uma iterao como completo. Revisar o estado do projeto no final de cada fase e determinar se o projeto deve prosseguir para a prxima fase.

Reviso de Aceitao da Iterao


o

Reviso do Lifecycle Milestone


o

Reviso de Aceitao do Projeto Project Acceptance Review


o

Para o cliente revisar formalmente e aceitar os deliverables do projeto.

Papis e Atividades

Exerccios

Papis e Atividades

Espao para anotaes

5. Artefatos

Artefatos

Objetivos
Apresentar uma viso geral dos artefatos do RUP

Artefatos

Modelagem de Negcio
O conjunto de Modelagem de Negcio apresenta os artefatos que capturam e representam o contexto de negcio do sistema. Os artefatos de Modelagem de Negcio servem como entrada e referncia para os requisitos do sistema.

Ator de Negcio
Um Ator de Negcio representa um papel exercido na relao de negcio por algum ou algo no ambiente de negcio.

Documento de Arquitetura de Negcio


O Documento de Arquitetura de Negcio prov uma viso geral compreensiva do negcio, usando diferentes vises arquiteturais para destacar diferentes aspectos do negcio.

Entidade de Negcio
Uma Entidade de Negcio uma classe passiva, ou seja, ela no inicia interaes por si s. Uma Entidade de Negcio pode participar em vrias realizaes de caso de uso diferentes e geralmente sobrevivem por uma nica

Artefatos

interao. Na modelagem de negcio, as entidades de negcio representam objetos que os trabalhadores do negcio acessam, inspecionam, manipulam, produzem e assim por diante. Objetos de entidade de negcio provm a base de compartilhamento entre os trabalhadores do negcio participando em diferentes realizaes de casos de uso de negcio.

Glossrio de Negcio
O Glossrio de Negcio define os termos importantes usados na parte de modelagem de negcio do projeto.

Modelo de Objetos de Negcio

O Modelo de Objetos de Negcio um modelo de objetos descrevendo a realizao dos casos de uso de negcio.

Regras de Negcio
Regras de Negcio so declaraes de polticas ou condies que devem ser satisfeitas.

Caso de Uso de Negcio


Um Caso de Uso de Negcio (Classe) define um conjunto de instancias de casos de uso de negcio, onde cada instancia uma seqncia de aes executadas que resultam em resultados observveis para um Ator de Negcio em particular.

Modelo de Casos de Uso de Negcio


O Modelo de Casos de Uso de Negcio um modelo das funes de negcio desejadas. O Modelo de Casos de Uso de Negcio usado como entrada essencial para identificar papis e deliverables da organizao.

Realizao de Caso de Uso de Negcio

Artefatos

Uma Realizao de Caso de Uso de Negcio descreve como um caso de uso de negcio em particular realizado dentro do modelo de objetos de negcio, em termos de colaborao de objetos (instancias de trabalhadores do negcio e entidades do negcio).

Viso do Negcio
A Viso do Negcio define o conjunto de metas e objetivos a serem alcanadas pelo esforo de modelagem de negcio.

Trabalhador do Negcio
Um trabalhador do negcio uma classe que representa uma abstrao de uma pessoa que age no sistema. Um trabalhador do negcio interage com outros trabalhadores de negcio e manipula entidades de negcio enquanto participa em realizaes de casos de uso de negcio.

Unidade Organizacional
Uma unidade organizacional uma coleo de trabalhadores do negcio, entidades de negcio, relacionamentos, realizaes de casos de uso de negcio, diagramas e outras unidades organizacionais. usada para estruturar o modelo de objetos de negcio pela sua diviso em partes menores.

Especificao de Negcio Suplementar


Este documento apresenta as definies necessrias de negcio que no esto includas no modelo de casos de uso de negcio nem no modelo de objetos de negcio.

Avaliao da Organizao Alvo


A avaliao da Organizao Alvo descreve o status corrente da organizao na qual o sistema ser colocado em uso. A descrio em termos de processos atuais, ferramentas, competncias pessoais, atitudes pessoais, clientes, competidores, tendncias tcnicas, problemas e reas de melhoria.

Artefatos

Requisitos
O conjunto de artefatos de Requisitos captura e apresenta a informao usada na definio das capacidades requeridas para o sistema.

Ator
Um ator define um conjunto coerente de papis que os usurios do sistema podem exercer quando interagindo com ele. Uma instancia de ator pode ser exercida tanto por uma pessoa como por um sistema externo.

Classes Limite
Uma classe limite modela a interao entre um ou mais atores e o sistema.

Glossrio
O Glossrio define termos importantes usados no projeto.

Artefatos

Atributos de Requisitos
Este artefato contm um repositrio de requisitos do projeto, atributos e dependncias que devem ser acompanhadas na perspectiva de gerenciamento de requisitos.

Plano de Gerncia dos Requisitos


Descreve a documentao dos requisitos, os tipos de requisitos e seus respectivos atributos, especificando as informaes e mecanismos de controle que devem ser coletados e usados para medio, relatrios e controle de mudanas aos requisitos do produto.

Solicitaes dos Envolvidos


Este artefato contm qualquer tipo de requisio que um envolvido (cliente, usurio final, pessoal do marketing e assim por diante) pode ter para o sistema a ser desenvolvido. Deve tambm conter referncias para recursos externos com os quais o sistema deve ser compatvel.

Especificao de Requisitos de Software


A Espeficicao de Requisitos de Software captura os requisitos completos de software para o sistema ou para uma poro do sistema. Usando modelagem de casos de uso, este artefato consiste de um pacote contendo casos de uso do modelo de casos de uso e Especificaes Suplementares aplicveis.

Especificaes Suplementares
As Especificaes Suplementares capturam os requisitos do sistema que no foram completamente capturadas pelos casos de uso e o modelo de casos de uso. Tais requisitos incluem: Requisitos legais, regulamentos e normas aplicveis. Atributos de qualidade do sistema a ser construdo, incluindo requisitos de usabilidade, confiabilidade, performance e estabilidade. Outros requisitos como sistemas operacionais e ambientes, requisitos de compatibilidade e restries de projeto.

Artefatos

Caso de Uso
Um caso de uso define um conjunto de instancias de casos de uso, onde cada instancia uma seqncia de aes que um sistema executa que produz resultados observveis para um ator em particular.

Modelo de Casos de Uso


O Modelo de Casos de Uso um modelo das funes desejadas para o sistema e o seu ambiente, serve como contrato entre o cliente e os desenvolvedores. O modelo de casos de uso usado como entrada essencial para atividades de anlise, projeto e teste.

Pacote de Casos de Uso


Um Pacote de Casos de Uso uma coleo de casos de uso, atores, relacionamentos, diagramas e outros pacotes, usado para estruturar o modelo de casos de uso divindindo-o em partes menores.

Descrio de Caso de Uso


Uma Descrio de Caso de Uso uma descrio lgica e conceitual de como um caso de uso executado pela interface com o usurio, incluindo a interao requerida entre os atores e o sistema.

Prottipo de Interface com o Usurio


Um Prottipo de Interface com o Usurio mostra a interface do sistema. Pode ser mostrada como: Desenhos em papel ou figuras; Bitmaps feitos por ferramentas de desenho; Um prottipo executvel interativo;

Viso
A Viso define as vises dos envolvidos do produto a ser desenvolvido, especificadas em termos das necessidades chaves e das

Artefatos

features necessrias. Contm os pontos essenciais dos requisitos e prov uma base contratual para requisitos tcnicos mais detalhados.

Artefatos

Anlise e Projeto
O conjunto de artefatos de Anlise e Projeto captura e apresenta informaes relacionadas a soluo de problemas colocados no conjunto de Requisitos.

Classe de Anlise
Classes de Anlise representam um modelo conceitual preliminar para coisas no sistema que tem responsabilidades e comportamento.

Modelo de Anlise

Um modelo de objetos descrevendo a realizao dos casos de uso e que serve como uma abstrao do artefato: Modelo de Projeto. O Modelo de Anlise contm o resultado da anlise dos casos de uso, instancias do artefato: Classe de Anlise. O Modelo de Anlise um artefato opcional.

Cpsula (Capsule)
Uma cpsula um design pattern especfico que representa uma thread encapsulada de controle do sistema.

Artefatos

Modelo de Dados
O Modelo de Dados um subconjunto do modelo de implementao que descreve o a representao lgica e fsica dos dados persistentes do sistema. Ele tambm inclui comportamentos definidos na base de dados, como stored procedures, triggers, constraints, etc.

Modelo de Deployment

O Modelo de Deployment mostra a configurao do processamento nos ns em run-time, os links de comunicao entre eles e os componentes e objetos que neles residem.

Classe de Projeto
Uma classe uma descrio de um conjunto de objetos que compartilha as mesmas responsabilidades, relacionamentos, operaes, atributos e semntica.

Modelo de Projeto

O Modelo de Projeto descreve a realizao dos casos de uso e serve como uma abstrao do modelo de implementao e do cdigo fonte. O Modelo de Projeto usado como entrada essencial para as atividades de implementao e teste.

Pacote de Projeto
Um pacote de projeto uma coleo de classes, relacionamentos, realizaes de casos de uso e de outros pacotes. usado para estruturar o modelo de projeto pela diviso em partes menores.

Subsistema de Projeto
Um elemento do modelo que tem a semntica de um pacote (pode conter outros elementos do modelo) e de uma classe (tem comportamento). O comportamento do subsistema provido pelas classes e outros subsistemas que ele contm. Um subsistema realiza uma ou mais interfaces, que definem o comportamento que ele pode exercer.

Artefatos

Evento
A especificao de uma ocorrncia no espao tempo. De forma menos formal, a ocorrncia de algo ao qual o sistema deve responder.

Interface
Um elemento do modelo que define um conjunto de comportamentos (um conjunto de operaes) oferecidos por um elemento classificador do modelo (especificamente uma classe, subsistema ou componente). Um classificador pode realizar uma ou mais interfaces. Uma interface pode ser realizada por um ou mais classificadores. Classificadores que realizam a mesma interface podem ser substitudos um pelo outro no sistema. Cada interface deve prover um conjunto nico e bem definido de operaes.

Protocolo
Uma especificao comum para um conjunto de artefatos: portas de Cpsulas.

Arquitetura de Referncia
Uma Arquitetura de Referncia , em essncia, um padro arquitetural pr-definido, parcialmente ou completamente instanciado, projetado e aprovado para uso em negcios e contextos tcnicos particulares, em conjunto com artefatos de suporte para possibilitar seu uso. Frequentemente, esses artefatos so capturados de projetos anteriores.

Sinal
Um sinal uma entidade de comunicao assncrona que pode causar uma transio de estados na mquina de estados de um objeto que o recebe.

Documento de Arquitetura de Software


O Documento de Arquitetura de Software prov uma viso geral compreensiva da arquitetura do sistema, usando diferentes vises arquiteturais para destacar diferentes aspectos do sistema.

Artefatos

Realizao de Caso de Uso


Uma Realizao de Caso de Uso descreve como um caso de uso particular realizado dentro do modelo de projeto em termos de colaborao de objetos.

Prova de Conceito Arquitetural


A Prova de Conceito Arquitetural uma soluo que pode ser simplesmente conceitual para os requisitos arquiteturalmente significativos que foram identificados na fase de Inception.

Artefatos

Implementao
O conjunto de artefatos de Implementao captura e apresenta a realizao da soluo apresentada no conjunto de Anlise e Projeto.

Build
Um build inclui um ou mais componentes (frequentemente executveis), cada um construdo de outros componentes, geralmente atravs de um processo de compilao e link de cdigo fonte.

Componente
Um componente representa uma pea de cdigo de software (fonte, binrio ou executvel) ou um arquivo contendo informao (por exemplo, um arquivo de startup ou um arquivo readme). Um componente pode tambm ser um agregado de outros componentes, por exemplo, uma aplicao consiste de vrios executveis.

Modelo de Implementao

O Modelo de Implementao uma coleo de componentes e de subsistemas de implementao que os contm. Componentes incluem deliverables, como executveis e componentes a partir dos quais os deliverables so produzidos, como arquivos de cdigos fonte.

Subsistema de Implementao
Um Subsistema de Implementao uma coleo de componentes e de outros subsistemas de implementao e usado para estruturar o modelo de implementao pela sua diviso em partes menores.

Artefatos

Plano de Integrao
O Plano de Integrao do build prov o planejamente detalhado para a atividade de integrao dentro de uma iterao.

Artefatos

Teste
O conjunto de artefatos de Teste captura e apresenta as informaes relacionadas aos testes executados para assegurar a qualidade do produto.

Caso de Teste
Um Caso de Teste um conjunto de: entradas, condies de execuo e resultados esperados, desenvolvidos para um objetivo particular, como exercitar um caminho de execuo particular de um programa ou para verificar a conformidade com um requisito especfico.

Classe de Teste
Uma classe estereotipada no modelo de projeto.

Artefatos

Componente de Teste
Um componente estereotipado no modelo de implementao.

Resumo de Avaliao de Testes

O Resumo de Avaliao de Testes organiza e apresenta os resultados e medies chaves dos testes para reviso e avaliao. Adicionalmente, o Resumo de Avaliao de Testes contm uma avaliao, feita pelos testadores e projetistas de testes, destas informaes e recomendaes para os esforos futuros.

Modelo de Teste

O Modelo de Teste uma representao do que ser testado e de como ser testado. uma viso dos modelos de projeto e implementao, destacando os testes em si, bem como os aspectos dos alvos do teste que so relefantes para os esforos de teste. Ele inclui a coleo dos casos de teste, procedimentos de teste, scripts de teste e resultados esperados junto com as descries de seus relacionamentos.

Pacote de Teste
Um pacote estereotipado no modelo de projeto.

Plano de Teste
O Plano de Teste contm informao sobre a proposta e metas dos testes dentro do projeto. Adicionalmento, o Plano de Testes identifica as estratgias a serem usadas para implementar e executar testes e os recursos necessrios.

Artefatos

Procedimento de Teste

Um Procedimento de Teste um conjunto detalhado de instrues para preparar, executar e avaliar os resultados para um dado caso de teste (ou um conjunto de casos de teste).

Resultados de Teste
Este artefato contm um repositrio dos dados capturados durante a execuo dos testes e usado no calculo das medies chave dos testes.

Script de Teste

Scripts de Teste so instrues de computador que automatizam a execuo de um Procedimento de Teste (um de uma parte de um Procedimento de Teste). Os Scripts de Teste podem ser criados (gravados) ou gerados automaticamente usando ferramentas de automao de teste, programadas usando uma linguagem de programao ou uma combinao de gravao, gerao e programao.

Subsistema de Teste
Um tipo de subsistema de implementao, do modelo de implementao, contendo componentes relacionados aos testes.

Documento de Anlise de Carga de Trabalho

Um Documento de Anlise de Carga de Trabalho identifica as variveis e define os valores a serem utilizados nos diferentes testes de performance usados para simular e/ou emular as caractersticas dos atores, usurios finais, funes de negcio, carga e volume de transaes.

Artefatos

Deployment
O conjunto de artefatos de Deployment captura e apresenta informaes relacionadas a transio do sistema apresentada no conjunto de Implementao para o ambiente de produo.

Lista de Materiais
A Lista de Materiais lista as partes que constituem uma determinada verso do produto e a localizao onde podem ser encontradas. Ela descreve as mudanas feitas na verso e referencia como o produto deve ser instalado.

Plano de Deployment
O Plano de Deployment descreve o conjunto de tarefas necessrias para instalar e testar o produto desenvolvido de forma que ele possa ser transmitido de forma eficiente para a comunidade usuria.

Material de Suporte ao Usurio Final


Material que auxilia o usurio final no aprendizado, utilizao, operao e manuteno do produto.

Artefatos

Artefatos de Instalao
Aretefatos de Instalao referem-se ao software e instrues documentadas necessrias para a instalao do produto.

Unidade de Deployment
Uma Unidade de Deployment consite de um build (uma coleo executvel de componentes), documentos (material de suporte ao usurio final e notas de verso) e artefatos de instalao. Uma Unidade de Deployment geralmente associada a um n nico dentro da rede de computadores ou perifricos.

Produto
O empacotamente de um produto com apelo de marketing o diferencia de uma unidade de deployment. Um produto pode conter mltiplas unidades de deployment e pode estar acessvel atravs de download, empacotado ou em algum formato de armazenamento em mdia digital.

Arte do Produto
A Arte do Produto inclui o texto (especificaes) e trabalho de arte que ser usado como marca do produto. A Arte do Produto pode aparecer no pacote fsico ou em um web site.

Notas de Verso
Notas de Verso identificam mudanas e problemas conhecidos em uma verso de build ou unidade de deployment que tenha sido colocada disponvel para uso.

Material de Treinamento
Materiais de Treinamento referem-se aos materiais que so usadas em programas de treinamento ou cursos para auxiliar os usurios finais no uso, operao e/ou manuteno do produto

Artefatos

Gerenciamento de Configurao e Mudanas


O conjunto de artefatos de Gerenciamento de Configurao e Mudanas captura e apresenta as informaes relacionadas ao workflow de Gerenciamento de Configurao e Mudanas.

Requisio de Mudana
Mudanas aos artefatos de desenvolvimento so propostas atravs de Requisies de Mudana (CR Change Requests). Requisies de mudana so usadas para documentar e rastrear defeitos, requisies de melhoria e outros tipos de requisies de mudana no produto. O benefcio das Requisies de Mudana que eles provm registro das decises e, devido ao seu processo de avaliao, asseguram que os impactos das mudanas so entendidos por todo o projeto.

Evidncias de Auditoria de Configurao


As Evidncias de Auditoria de Configurao identificam uma baseline, artefatos faltantes e requisitos no testados ou com falha.

Plano de Gerncia de Configurao


O Plano de Gerencia de Configurao (CM Plan) descreve todas as atividades de Gerncia e Controle de Mudanas (CCM Plan) que sero executadas durante o ciclo de vida do produto ou do projeto. Ele detalha o

Artefatos

cronograma das atividades, as matriz de responsabilidades e os recursos necessrios, incluindo pessoal, ferramentas e recursos computacionais.

Repositrio de Projeto
O Repositrio do Projeto armazena todas as verses dos arquivos e diretrios do projeto. Tambm armazena todos os dados e meta-dados derivados ou associados aos arquivos e diretrios.

Espao de Trabalho (Workspace)

Os workspaces possibilitam o acesso a artefatos e recursos necessrios para desenvolver e montar um produto deliverable. Existem dois tipos de workspaces: O workspace de desenvolvimento uma rea privada de desenvolvimento na qual um membro do time pode fazer mudanas aos artefatos sem que essas mudanas tornem-se visveis imediatamente aos outros. O workspace de integrao um espao compartilhado e acessvel a todos os membros do time do projeto. O produto total construdo e estabelecido (baselined) no workspace de integrao.

Artefatos

Gerenciamento de Projeto
O conjunto de artefatos de Gerenciamento de Projeto captura os artefatos associados com o planejamento e execuo do projeto e do processo.

Caso de Negcio
O Caso de Negcio prov a informao necessria, do ponto de vista de negcio, para determinar se o projeto vale o investimento. Para um produto de software comercial, o Caso de Negcio deve incluir um conjunto de premissas sobre o projeto e a ordem de magnitude do retorno do investimento (ROI) se essas premissas forem verdadeiras. Por exemplo, o ROI ser de cinco se completo em um ano, dois se completo em dois anos e negativo depois disso. Essas premissas so verificadas novamente ao final da fase de elaboration quando o escopo e o planejamento esto definidos com mais preciso.

Avaliao de Iterao
A Avaliao da Iterao captura o resultado de uma iterao, o grau ao qual os critrios de avaliao foram atingidos, lies aprendidas e mudanas a serem feitas.

Artefatos

Plano de Iteraao
Um conjunto de atividades e tarefas seqenciadas no tempo, com recursos associados, contendo dependncias entre tarefas, para a iterao; um plano fine-grained.

Plano de Mtricas
Define as metas para as medies, mtricas associadas e as mtricas primitivas que sero obtidas no projeto para monitorar seu progresso.

Plano de Resoluo de Problemas


O Plano de Resoluo de Problemas descreve o processo usado para relatar, analisar e resolver problemas que ocorrem durante o projeto.

Plano de Aceite do Produto


O Plano de Aceite do Produto descreve como o cliente vai avaliar os artefatos de entrega de um projeto para determinar se eles atingem um conjunto predefinido de critrios de aceitao. Ele detalha estes critrios de aceitao e identifica as tarefas de aceitao do produto (incluindo identificao dos casos de teste que precisam ser desenvolvidos) que sero levadas adiante, tero as responsabilidades associadas e os recursos necessrios. Em projetos de menor escala, este plano pode ser embutido dentro do Plano de Desenvolvimento de Software.

Mtricas do Projeto

O artefato de Mtricas do Projeto o repositrio ativo de dados de mtricas do projeto. Ele contm as medidas mais atuais sobre projeto, recursos, processos e produto em nvel primitivo e derivado.

Plano de Garantia de Qualidade


O Plano de Garantia de Qualidade um artefato que prov uma viso clare de como a qualidade do produto, artefatos e processo sero

Artefatos

asseguradas. Ele contem o Plano de Reviso e Auditoria e referencia outros artefatos desenvolvidos durante a fase de Inception. mantido ao longo do projeto.

Registros de Reviso
Um Registro de Reviso criado para capturar os resultados da reviso de um artefato do projeto.

Lista de Riscos
Uma lista de riscos conhecidos e abertos para o projeto, ordenada em ordem decrescente de importncia associada a aes especficas de mitigao ou contingncia.

Plano de Gerenciamento de Riscos


O Plano de Gerenciamento de Riscos detalha como gerenciar os riscos associados a um projeto. Ele detalha as tarefas de gerenciamento de risco que sero levadas adiante, responsabilidades associadas e recursos adicionais necessrios para a atividade de gerenciamento de risco. Em projetos de menor escala, este plano pode ser embutido no Plano de Desenvolvimento de Software.

Plano de Desenvolvimento de Software


O Plano de Desenvolvimento de Software um artefato compreensivo e composto, que rene toda a informao necessria para gerenciar o projeto. Ele contm artefatos desenvolvidos durante a fase de Inception e mantido ao longo do projeto.

Avaliao de Status
Um dos objetivos do processo assegurar que as expectativas de todas as partes esto sincronizadas e consistentes. A avaliao de status peridica prov um mecanismo para gerenciar as expectativas de todos ao longo do ciclo de vida do projeto.

Artefatos

Ordem de Trabalho
A Ordem de Trabalho a forma com que o Gerente do Projeto comunica o que deve ser feito e quando, para o pessoal responsvel. Ela se torna um contrato interno entre o Gerente do Projeto e os responsveis pela execuo.

Artefatos

Ambiente
O conjunto de artefatos de Ambiente representa os artefatos que so usados como guia ao longo do desenvolvimento do sistema para assegurar a consistncia de todos os artefatos produzidos.

Guidelines para Modelagem de Negcio


Descreve as guidelines para modelagem do negcio.

Guidelines para Projeto


Descreve as guidelines para projeto e implementao.

Artefatos

Caso de Desenvolvimento
O Caso de Desenvolvimento descreve o processo de desenvolvimento a seguir que foi escolhido pelo seu projeto.

Avaliao da Organizao de Desenvolvimento


A Avaliao da Organizao de Desenvolvimento descreve o status atual da organizao de software em termos de processos atuais, ferramentas, competncias pessoais, atitudes pessoais, competidores, tendncias tcnicas, problemas e reas de melhoria.

Guia de Estilo de Manual


Descreve como os manuais de suporte usurio final devem ser escritos.

Templates Especficos do Projeto


Templates para os artefatos documentais e relatrios usados no projeto. Pode tambm haver templates para modelos e elementos de modelo, como o modelo de projeto.

Guidelines de Programao
Descreve as convenes a serem usadas no trabalho com a linguagem de programao.

Guidelines de Teste
Descreve as guidelines de teste.

Artefatos

Ferramentas

As ferramentas para suportar o esforo de desenvolvimento de software.

Guidelines de Ferramentas
Descreve como utilizar uma ou vrias ferramentas.

Infraestrutura de Desenvolvimento

A infraestrutura de desenvolvimento inclui o hardware e o software, como computadores e sistemas operacionais, sobre os quais as ferramentas rodam. A Infraestrutura de Desenvolvimento tambm inclui o hardware e o software usado para interconectar os computadores e usurios.

Guidelines de Modelagem de Casos de Uso


Descreve as guidelines para modelagem de casos de uso.

Guidelines de Interface de Usurio


Guidelines especficas do projeto sobre como criar a interface com o usurio.

Artefatos

Exerccios

Artefatos

Espao para anotaes

T@rgetTrust Treinamento e Tecnologia