rup apostila v12

185
RUP Rational Unified Process RUP Set/2005

Upload: lvaldeir

Post on 08-Aug-2015

378 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: RUP Apostila v12

RUPRational Unified Process

RUPSet/2005

Page 2: RUP Apostila v12

Apostila desenvolvida especialmente para a Target Informática Ltda.Sua cópia ou reprodução é expressamente proibida.

Ago/2005

Page 3: RUP Apostila v12

RUP

Sumário

1. Visão Geral...............................................................................1-1Objetivos................................................................................................................................1-2Visão Geral............................................................................................................................1-3Conceitos Chave..................................................................................................................1-4

Processo de Desenvolvimento de Software.......................................................................1-4Roles (Papéis)....................................................................................................................1-5Activity (Atividade)...........................................................................................................1-5Steps (Tarefas)...................................................................................................................1-6Work Guidelines (Guias de Trabalho)..............................................................................1-7Artefato (Artifact)..............................................................................................................1-7Template (Modelo)............................................................................................................1-9Report (Relatório)..............................................................................................................1-9Artifact Guidelines and Checkpoints (Guias de Artefatos e Pontos de Verificação)......1-10Workflows (Disciplinas).................................................................................................1-10Core Workflows (Workflows Principais)........................................................................1-11Workflow Details (Detalhes de Workflows)...................................................................1-13Outros Conceitos.............................................................................................................1-14Tool Mentor.....................................................................................................................1-14Conceitos.........................................................................................................................1-15

A Essência dos Processos..............................................................................................1-16Introdução........................................................................................................................1-16Definir uma Visão...........................................................................................................1-16Usar uma Arquitetura......................................................................................................1-16Planejamento e Controle..................................................................................................1-17Gerenciar pelo Planejamento...........................................................................................1-17Riscos – Identificar e Mitigar..........................................................................................1-18Issues (Questões) – Definir Responsáveis e Controlar....................................................1-18Business Case (Caso de Negócio) – Examinar o Caso de Negócio................................1-18Evaluation (Avaliação) – Avaliar regularmente os resultados........................................1-18Implementar e Testar Iterativamente...............................................................................1-19Controlar Mudanças........................................................................................................1-19Entregar um Produto Utilizável.......................................................................................1-19Adaptar o Processo..........................................................................................................1-19Conclusão........................................................................................................................1-20

Melhores Práticas..............................................................................................................1-21Desenvolver em Iterações................................................................................................1-21Gerenciar Requisitos.......................................................................................................1-24Usar Arquitetura de Componentes..................................................................................1-26Modelar Visualmente (UML)..........................................................................................1-27Verificar Qualidade.........................................................................................................1-28Controlar Mudanças........................................................................................................1-31

Exercícios.............................................................................................................................1-33

2. Fases.......................................................................................2-1Objetivos................................................................................................................................2-2Fases........................................................................................................................................2-3

Planejamento das Fases.....................................................................................................2-3Inception (Concepção)......................................................................................................2-5

T@rgetTrust Treinamento e Tecnologia I

Page 4: RUP Apostila v12

Visão Geral

Objetivos............................................................................................................................2-5Atividades Essenciais........................................................................................................2-5Milestone: Lifecycle Objectives........................................................................................2-6Artefatos............................................................................................................................2-6

Elaboration (Elaboração)..................................................................................................2-8Objetivos............................................................................................................................2-8Atividades Essenciais........................................................................................................2-8Milestone: Lifecycle Architecture.....................................................................................2-9Artefatos..........................................................................................................................2-10

Construction (Construção).............................................................................................2-12Objetivos..........................................................................................................................2-12Atividades Essenciais......................................................................................................2-12Milestone: Initial Operational Capability........................................................................2-13Artefatos..........................................................................................................................2-13

Transition (Transição).....................................................................................................2-15Objetivos..........................................................................................................................2-15Atividades Essenciais......................................................................................................2-16Milestone: Product Release.............................................................................................2-16Artefatos..........................................................................................................................2-16

Exercícios.............................................................................................................................2-18

3. Core Workflows........................................................................3-1Objetivos................................................................................................................................3-2Análise de Negócio.............................................................................................................3-3

Proposta.............................................................................................................................3-3Relacionamento com outros workflows............................................................................3-4Atividades..........................................................................................................................3-4Artefatos............................................................................................................................3-5

Requisitos..............................................................................................................................3-6Proposta.............................................................................................................................3-6Relacionamento com outros workflows............................................................................3-8Atividades..........................................................................................................................3-9Artefatos............................................................................................................................3-9

Análise e Projeto................................................................................................................3-10Proposta...........................................................................................................................3-10Relacionamento com outros workflows..........................................................................3-10Atividades........................................................................................................................3-11Artefatos..........................................................................................................................3-11

Implementação..................................................................................................................3-12Proposta...........................................................................................................................3-12Relacionamento com outros workflows..........................................................................3-13Atividades........................................................................................................................3-13Artefatos..........................................................................................................................3-13

Teste......................................................................................................................................3-14Proposta...........................................................................................................................3-14Relacionamento com outros workflows..........................................................................3-15Atividades........................................................................................................................3-16Artefatos..........................................................................................................................3-16

Deployment (Entrega).....................................................................................................3-17Proposta...........................................................................................................................3-17Relacionamento com outros workflows..........................................................................3-18

T@rgetTrust Treinamento e Tecnologia II

Page 5: RUP Apostila v12

Visão Geral

Atividades........................................................................................................................3-19Artefatos..........................................................................................................................3-19

Gerenciamento de Configuração e Mudanças.......................................................3-20Introdução........................................................................................................................3-20Proposta...........................................................................................................................3-21Relacionamento com outros core workflows..................................................................3-22Atividades........................................................................................................................3-23Artefatos..........................................................................................................................3-23

Gerenciamento de Projeto.............................................................................................3-24Introdução........................................................................................................................3-24Proposta...........................................................................................................................3-24Relacionamento com outros workflows..........................................................................3-25Atividades........................................................................................................................3-25Artefatos..........................................................................................................................3-26

Ambiente (Environment)................................................................................................3-27Proposta...........................................................................................................................3-27Relacionamento com outros workflows..........................................................................3-27Atividades........................................................................................................................3-28Artefatos..........................................................................................................................3-29

Exercícios.............................................................................................................................3-30

4. Papéis e Atividades...................................................................4-1Objetivos................................................................................................................................4-2Analistas.................................................................................................................................4-3

Analista de Processos de Negócio.....................................................................................4-3Projetista de Negócio.........................................................................................................4-4Revisor de Modelo de Negócio.........................................................................................4-5Revisor de Requisitos........................................................................................................4-6Analista de Sistemas..........................................................................................................4-6Especificador de Requisitos..............................................................................................4-8Projetista de Interface com o Usuário...............................................................................4-8

Desenvolvedores...............................................................................................................4-10Arquiteto de Software......................................................................................................4-10Revisor de Arquitetura....................................................................................................4-12Projetista de Cápsulas (Capsule Designer)......................................................................4-12Revisor de Código...........................................................................................................4-13Projetista de Banco de Dados..........................................................................................4-13Revisor de Projeto...........................................................................................................4-14Projetista..........................................................................................................................4-14Implementador.................................................................................................................4-15Integrador........................................................................................................................4-16

Testadores...........................................................................................................................4-19Testador...........................................................................................................................4-19Projetista de Testes..........................................................................................................4-19

Gerentes...............................................................................................................................4-21Gerente de Controle de Mudanças..................................................................................4-21Gerente de Configuração.................................................................................................4-22Gerente de Deployment...................................................................................................4-23Engenheiro de Processos.................................................................................................4-24Gerente de Projeto...........................................................................................................4-25Revisor de Projeto...........................................................................................................4-29

T@rgetTrust Treinamento e Tecnologia III

Page 6: RUP Apostila v12

Visão Geral

Exercícios.............................................................................................................................4-31

5. Artefatos..................................................................................5-1Objetivos................................................................................................................................5-2Modelagem de Negócio....................................................................................................5-3

Ator de Negócio................................................................................................................5-3Documento de Arquitetura de Negócio.............................................................................5-3Entidade de Negócio..........................................................................................................5-3Glossário de Negócio........................................................................................................5-4Modelo de Objetos de Negócio.........................................................................................5-4Regras de Negócio.............................................................................................................5-4Caso de Uso de Negócio....................................................................................................5-4Modelo de Casos de Uso de Negócio................................................................................5-4Realização de Caso de Uso de Negócio............................................................................5-4Visão do Negócio..............................................................................................................5-5Trabalhador do Negócio....................................................................................................5-5Unidade Organizacional....................................................................................................5-5Especificação de Negócio Suplementar............................................................................5-5Avaliação da Organização Alvo........................................................................................5-5

Requisitos..............................................................................................................................5-6Ator....................................................................................................................................5-6Classes Limite...................................................................................................................5-6Glossário............................................................................................................................5-6Atributos de Requisitos.....................................................................................................5-6Plano de Gerência dos Requisitos.....................................................................................5-7Solicitações dos Envolvidos..............................................................................................5-7Especificação de Requisitos de Software..........................................................................5-7Especificações Suplementares...........................................................................................5-7Caso de Uso.......................................................................................................................5-7Modelo de Casos de Uso...................................................................................................5-8Pacote de Casos de Uso.....................................................................................................5-8Descrição de Caso de Uso.................................................................................................5-8Protótipo de Interface com o Usuário................................................................................5-8Visão..................................................................................................................................5-8

Análise e Projeto..................................................................................................................5-9Classe de Análise...............................................................................................................5-9Modelo de Análise.............................................................................................................5-9Cápsula (Capsule)..............................................................................................................5-9Modelo de Dados.............................................................................................................5-10Modelo de Deployment...................................................................................................5-10Classe de Projeto.............................................................................................................5-10Modelo de Projeto...........................................................................................................5-10Pacote de Projeto.............................................................................................................5-10Subsistema de Projeto......................................................................................................5-10Evento..............................................................................................................................5-11Interface...........................................................................................................................5-11Protocolo..........................................................................................................................5-11Arquitetura de Referência................................................................................................5-11Sinal.................................................................................................................................5-11Documento de Arquitetura de Software..........................................................................5-11Realização de Caso de Uso..............................................................................................5-12

T@rgetTrust Treinamento e Tecnologia IV

Page 7: RUP Apostila v12

Visão Geral

Prova de Conceito Arquitetural.......................................................................................5-12Implementação..................................................................................................................5-13

Build................................................................................................................................5-13Componente.....................................................................................................................5-13Modelo de Implementação..............................................................................................5-13Subsistema de Implementação........................................................................................5-13Plano de Integração.........................................................................................................5-14

Teste......................................................................................................................................5-15Caso de Teste...................................................................................................................5-15Classe de Teste................................................................................................................5-15Componente de Teste......................................................................................................5-16Resumo de Avaliação de Testes......................................................................................5-16Modelo de Teste..............................................................................................................5-16Pacote de Teste................................................................................................................5-16Plano de Teste..................................................................................................................5-16Procedimento de Teste....................................................................................................5-16Resultados de Teste.........................................................................................................5-17Script de Teste.................................................................................................................5-17Subsistema de Teste........................................................................................................5-17Documento de Análise de Carga de Trabalho.................................................................5-17

Deployment.........................................................................................................................5-18Lista de Materiais............................................................................................................5-18Plano de Deployment......................................................................................................5-18Material de Suporte ao Usuário Final..............................................................................5-18Artefatos de Instalação....................................................................................................5-19Unidade de Deployment..................................................................................................5-19Produto............................................................................................................................5-19Arte do Produto...............................................................................................................5-19Notas de Versão...............................................................................................................5-19Material de Treinamento.................................................................................................5-19

Gerenciamento de Configuração e Mudanças.......................................................5-20Requisição de Mudança...................................................................................................5-20Evidências de Auditoria de Configuração.......................................................................5-20Plano de Gerência de Configuração................................................................................5-20Repositório de Projeto.....................................................................................................5-21Espaço de Trabalho (Workspace)....................................................................................5-21

Gerenciamento de Projeto.............................................................................................5-22Caso de Negócio..............................................................................................................5-22Avaliação de Iteração......................................................................................................5-22Plano de Iteraçao.............................................................................................................5-22Plano de Métricas............................................................................................................5-23Plano de Resolução de Problemas...................................................................................5-23Plano de Aceite do Produto.............................................................................................5-23Métricas do Projeto..........................................................................................................5-23Plano de Garantia de Qualidade......................................................................................5-23Registros de Revisão.......................................................................................................5-24Lista de Riscos.................................................................................................................5-24Plano de Gerenciamento de Riscos.................................................................................5-24Plano de Desenvolvimento de Software..........................................................................5-24Avaliação de Status.........................................................................................................5-24Ordem de Trabalho..........................................................................................................5-24

T@rgetTrust Treinamento e Tecnologia V

Page 8: RUP Apostila v12

Visão Geral

Ambiente..............................................................................................................................5-25Guidelines para Modelagem de Negócio........................................................................5-25Guidelines para Projeto...................................................................................................5-25Caso de Desenvolvimento...............................................................................................5-26Avaliação da Organização de Desenvolvimento.............................................................5-26Guia de Estilo de Manual................................................................................................5-26Templates Específicos do Projeto...................................................................................5-26Guidelines de Programação.............................................................................................5-26Guidelines de Teste.........................................................................................................5-26Ferramentas.....................................................................................................................5-26Guidelines de Ferramentas..............................................................................................5-27Infraestrutura de Desenvolvimento.................................................................................5-27Guidelines de Modelagem de Casos de Uso...................................................................5-27Guidelines de Interface de Usuário.................................................................................5-27

Exercícios.............................................................................................................................5-28

T@rgetTrust Treinamento e Tecnologia VI

Page 9: RUP Apostila v12

RUP

T@rgetTrust Treinamento e Tecnologia 1

Page 10: RUP Apostila v12

RUP

1.1. Visão GeralVisão Geral

T@rgetTrust Treinamento e Tecnologia 1

Page 11: RUP Apostila v12

Visão Geral

Objetivos

Entender o que é um Processo de Desenvolvimento de Software

Conhecer a estrutura geral do RUP

Conhecer os conceitos chave do RUP

T@rgetTrust Treinamento e Tecnologia 2

Page 12: RUP Apostila v12

Visão Geral

Visão 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 organização desenvolvedora. Sua meta é assegurar a producão de software de alta qualidade, que atenda as necessidades de seus usuários finais dentro de cronogramas e orçamentos previsíveis.

A figura 1-1 mostra a visão total da arquitetura do Rational Unified Process.

O RUP tem duas dimensões:

- 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 dimensão representa o aspecto dinâmico do processo, expresso em termos de fases, iterações e milestones.

A segunda dimensão representa o aspecto estático do processo, descrito em termos de componentes de processo, atividades, workflows, artefatos e papéis.

O gráfico mostra como a ênfase varia ao longo do tempo. Por exemplo, nas iterações iniciais mais tempo é gasto em requisitos, enquanto que nas iterações finais, mais tempo é gasto em implementação.

T@rgetTrust Treinamento e Tecnologia 3

Page 13: RUP Apostila v12

Visão Geral

Conceitos Chave

Figura 1-2: Conceitos básicos no RUP

Processo de Desenvolvimento de Software

Um processo é um conjunto de passos parcialmente ordenados para alcançar 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 negócios, o processo de desenvolvimento de software é um processo de negócio. O Rational Unified Process (RUP) é um processo de negócio genérico para engenharia de software orientado a objetos. Ele descreve uma família de processos de engenharia de software relacionados compartilhando uma estrutura comum, uma arquitetura de processo comum. Ele provê uma abordagem disciplinada para alocação de tarefas e responsabilidades em uma organização desenvolvedora. Seu objetivo é assegurar a produção de software de alta qualidade que vá ao encontro das necessidades dos seus usuários, dentro de cronogramas e orçamentos previsíveis. O RUP captura as melhores práticas utilizadas em desenvolvimento de software moderno de forma que possa ser adaptado para atender a vários tipos de projetos e organizações.

T@rgetTrust Treinamento e Tecnologia 4

Page 14: RUP Apostila v12

Visão Geral

Quando um sistema de software é desenvolvido do zero, o desenvolvimento é o processo de criação 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 adaptação do sistema a requisitos novos ou modificados. Isso é aplicável através 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 (Papéis)

O conceito central no processo é o de Papel (Role). Um papel define o comportamento e as responsabilidades de um indivíduo, ou de um conjunto de indivíduos trabalhando juntos como um time, dentro do contexto de uma organização desenvolvedora de software.

Note que papéis são diferentes de indivíduos, ao invés disso, papéis descrevem como indivíduos devem se comportar no negócio e as responsabilidades de um indivíduo. Membros individuais de uma organização desenvolvedora de software irão usar chapéus diferentes, ou executar papéis diferentes. O mapeamento de indivíduo para papel, feito pelo gerente de projeto enquanto está planejando e alocando o pessoal para o projeto, possibilita que indivíduos possam atuar com vários papéis diferentes, ou que um papel seja executado por vários indivíduos.

T@rgetTrust Treinamento e Tecnologia 5

Page 15: RUP Apostila v12

Visão Geral

Activity (Atividade)

Figura 1-4: Um papel com suas atividaes

Papéis têm 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 indivíduo exercendo um papel pode ser solicitado a executar. A atividade tem um propósito claro, geralmente expresso em termos de criação ou alteração de alguns artefatos, como um modelo, uma classe ou um plano. Cada atividade é associada a um papel específico. A granularidade de uma atividade varia de algumas horas a alguns dias, usualmente envolve um papel e afeta um ou um pequeno número 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 várias vezes para o mesmo artefato, especialmente quando vamos de uma iteração para outra, refinando e expandindo o sistema, pelo mesmo papel, mas não necessariamente o mesmo indivíduo.

Steps (Tarefas)

Atividades são quebradas em tarefas. As tarefas recaem em três categorias principais:

Tarefas de estudo: quando o indivíduo executando o papel entende a natureza da tarefa, reúne e examina os artefatos de entrada e formula a saída.T@rgetTrust Treinamento e Tecnologia 6

Page 16: RUP Apostila v12

Visão Geral

Tarefas de execução: quando o indivíduo executando o papel cria ou altera algum artefato.

Tarefas de revisão: quando o indivíduo executando o papel inspeciona o resultado de acordo com algum critério.

Nem todas as tarefas são 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 decompõe 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 questionário do modelo de casos de uso

7. Avaliar os resultados

A parte de encontrar [tarefas 1 a 3] requer algum estudo; a parte de execução [tarefas 4 a 6] envolve capturar o resultado no modelo de casos de uso; a parte de revisão [tarefa 7] é quando o indivíduo 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 técnicas e conselhos práticos que são úteis para o papel executor da atividade.

Artefato (Artifact)

Atividades têm artefatos de entrada e saída. Um artefato é um produto de um trabalho do processo: papéis usam artefatos para executar atividades e produzem artefatos enquanto estão executando atividades. Artefatos são de responsabilidade de um papel único e promovem a idéia que cada parte de informação no processo deve ser de responsabilidade de uma pessoa específica. Apesar de que uma pessoa ser “dona” do artefato, muitas pessoas podem usar o artefato, até memo podendo alterá-lo se houver permissão para isso.

T@rgetTrust Treinamento e Tecnologia 7

Page 17: RUP Apostila v12

Visão Geral

Figura 1-5: Artefatos principais do processo e o fluxo de informações entre eles

O diagrama acima mostra como o fluxo de informação ao longo do projeto, através dos artefatos; as setas mostram como mudanças em um artefato se propagam aos outros seguindo as setas. Para maior clareza, muitos artefatos são omitidos (por exemplo, muitos artefatos no modelo do projeto são omitidos, sendo representado pelo artefato: Design Model).

Para simplificar a organização, os artefatos são 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

T@rgetTrust Treinamento e Tecnologia 8

Page 18: RUP Apostila v12

Visão Geral

Artefatos podem assumir várias formas e tipos:

Um modelo (model), como Modelo de Casos de Uso ou Modelo de Projeto, que contêm 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 Negócio ou um Documento de Arquitetura de Software.

Códigos fonte e executáveis (componentes)

Executáveis

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) são o subconjunto de artefatos que vai para as mãos dos clientes e usuários finais.

Artefatos são muito indicados para serem controlados por um sistema de controle de versionamento e gerenciamento de configuração. Isto muitas vezes só é atingido versionando-se o artefato “container”, quando não é possível fazê-lo para os artefatos elementares artefatos, chamados “contained”. Por exemplo, você pode controlar a versão de todo o modelo do projeto, ou de um pacote, mas não para as classes individuais que eles contém.

Artefatos tipicamente NÃO são documentos. Muitos processos têm foco excessivo em documentos e particularmente e documentos em papel. O RUP desencoraja sistematicamente a produção de documentos em papel. A abordagem mais eficiente e prática para gerenciar artefatos de projetos é manter os artefatos dentro de uma ferramenta apropriada, usada para criar e gerenciar um artefato. Quando necessário você pode gerar documentos (snapshots) a partir dessas ferramentas, de uma forma “just-in-time”. Você poderá também considerar a possibilidade de entregar artefatos às partes interessadas dentro da própria ferramenta, ao invés de em papel. Esta abordagem assegura que a informação está sempre atualizada e baseada no trabalho atual do projeto e que não irá requerer esforço adicional para produzi-la.

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 informação descritiva.

T@rgetTrust Treinamento e Tecnologia 9

Page 19: RUP Apostila v12

Visão Geral

Template (Modelo)

Templates são modelos, ou protótipos, de artefatos. Associados com a descrição do artefato está um ou mais templates que podem ser usados para criar o artefato correspondente. Templates são ligagos a ferramenta que será utilizada.

Por exemplo:

Templates do Microsoft Word podem ser usados para artefatos que são documentos e para relatórios.

Templates do Rational SoDA para Microsoft Word ou para FrameMaker podem extrair informações de ferramentas como Rational Rose, Rational RequisitePro ou Rational TeamTest.

Templates do Microsoft FrontPage para vários elementos do processo.

Templates do Microsoft Project para o planejamento do projeto.

De acordo com as guias de trabalho, as organizações podem querer customizar os templates antes de usá-los adicionando o logo da companhia, identificação do projeto ou informações especificas do tipo de projeto.

Figura 1-7: Diferentes tipos de templates do RUP

Report (Relatório)

Modelos e elementos dos modelos podem ter relatórios associados. Um relatório extrai informações de um modelo ou de elementos do modelo em uma ferramenta. Por exemplo, um relatório apresenta um artefato ou um conjunto de artefatos para uma revisão. Diferente dos artefatos normais, os relatórios não estão sujeitos ao controle de versão.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 Verificação)

Artefatos têm, tipicamente, guias de trabalho associadas e checkpoints (pontos de verificação) que contém informaçãoes sobre como desenvolver, avaliar e utilizar os artefatos. Muito do conteúdo do Processo está contido nas guias dos artefatos. As descrições das atividades tentam capturar a essência do que é feito, enquanto as guias dos artefatos capturam a essência de como fazer o trabalho. Os checkpoints provêm uma referência rápida para auxiliar na avaliação da qualidade do artefato.

T@rgetTrust Treinamento e Tecnologia 10

Page 20: RUP Apostila v12

Visão Geral

Ambos, guias e checkpoints são úteis em vários 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 enumeracão de todos os papéis, artefatos e atividades não constitui um processo. Precisamos de uma forma para descrever seqüências significativas de atividades que produzem algum resultado avaliável e também mostrar as interações entre os papéis. Um workflow é ma seqüência de atividades que produzem um resultdado de valor observável.

Em termos de UML, um workflow pode ser expresso como um diagrama de seqüência, um diagrama de colaboração 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.

T@rgetTrust Treinamento e Tecnologia 11

Page 21: RUP Apostila v12

Visão Geral

Figura 1-9: Um diagrama de atividades, mostrando detalhes e transições

Uma das grandes dificuldades na descrição 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 coleção de atividades relacionadas que tem relação com uma das maiores “áreas de conhecimento” dentro de todo o projeto. O agrupamento de atividades em core workflows é, principalmente, um auxílio para o entendimento do projeto de uma perspectiva de cascata “tradicional” – tipicamente, por exemplo, é mais comum realizar certas atividades ligadas a requisitos em coordenação com atividades de análise e projeto. Separar estas atividades em core workflows torna as atividades mais fáceis de serem compreendidas, mas mais difíceis de serem colocadas em cronograma (schedule).

T@rgetTrust Treinamento e Tecnologia 12

Page 22: RUP Apostila v12

Visão Geral

Figura 1-10: Core workflows

Como outros workflows, um core workflow é uma seqüência semi-ordenada de atividades que são realizadas para atingir um resultado. A natureza “semi-ordenada” dos core workflows enfatiza que eles não representam exatamente o “trabalho real” em um cronograma, por eles não podem configurar as atividades opcionais ou a natureza iterativa dos projetos reais. Mas, eles ainda possuem valor como forma de entender o processo pela decomposição em “áreas de conhecimento” menores.

Cada “área de conhecimento” ou core workflow tem associado a ele um ou mais modelos (models) que são por sua vez compostos de artefatos associados. Os artefatos mais importantes são os modelos que cada core workflow gera: modelo de casos de uso, modelo de projeto, modelo de implementação 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 também está presente. Este diagrama mostra todos os artefatos e papéis envolvidos no workflow.

T@rgetTrust Treinamento e Tecnologia 13

Page 23: RUP Apostila v12

Visão Geral

Figura 1-12: Exemplo de diagrama de overview de artefatos, do workflow de modelagem de negócios

É interessante notar que a organização “centrada em workflows” dos artefatos é, algumas vezes, mas não sempre, um pouco diferente da organização dos conjuntos de artefatos. A razão para isto é simples: alguns artefatos são usados de forma cruzada nos workflows, um agrupamento estritamente “centrado em workflows” torna mais difícil 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ê também encontrará diagramas de workflow detalhados, que mostram grupos de atividades que freqüentemente são executados “como um todo”. Estes diagramas mostram papéis envolvidos, artefatos de entrada e saída e atividades executadas. Os diagramas de detalhamento de workflow estão lá pelas seguintes razões:

As atividades de um workflow não são executadas em seqüência, nem feitos todos de uma vez. O diagrama detalhado mostra como você freqüentemente irá trabalhar em workshops ou reuniões 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 vários diagramas de detalhamento de workflow para um core workflow.

Torna-se muito complexo mostrar artefatos de entrada e saída 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 não são completamente independentes entre si. Por exemplo, integração ocorre nos workflows de implementação e

T@rgetTrust Treinamento e Tecnologia 14

Page 24: RUP Apostila v12

Visão 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 negócio

Outros Conceitos

Tool Mentor

Atividades, tarefas e guias associados provêm o caminho geral para o praticante. Para ir um passo a frente, “tool mentors” são um outro caminho mostrando como executar as tarefas usando uma ferramenta de software específica. Tool mentors estão disponíveis no RUP, ligando suas atividades com ferramentas como Rational Rose, Rational RequisitePro, Rational ClearCase, Rational ClearQuest, Rational Suíte TestStudio. Os “tool mentors” encapsulam quase completamente as dependências do processo no conjunto de ferramentas, mantendo as atividades livres dos detalhes das ferramentas. Uma organização pode extender o conceito de “tool mentor” para prover caminhos para outras ferramentas.

T@rgetTrust Treinamento e Tecnologia 15

Page 25: RUP Apostila v12

Visão Geral

Figura 1-14: Exemplos de "tool mentors"

Conceitos

Alguns dos conceitos chave do processo, como iteração, fase, risco, testes de performance e assim por diante, são introduzidos em partes separadas do processo, geralmente anexados ao core workflow mais apropriado.

Figura 1-15: Exemplo de conceitos anexados ao workflow

T@rgetTrust Treinamento e Tecnologia 16

Page 26: RUP Apostila v12

Visão Geral

A Essência dos Processos

Introdução

A chave para atingir o delicado equilíbrio entre entregar software de qualidade e entregar rápido (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 específicas de seu projeto. Isto deve ser feito aderindo as melhores práticas que têm sido provadas através da indústria para auxiliar os projetos de desenvolvimento de software a terem sucesso.

A seguir descrevemos o essencial para um processo de software eficiente.

Definir uma Visão

Em particular, desenvolver uma Visão clara é chave para desenvolver um produto que vá ao encontro das “reais necessidades” dos envolvidos.

A Visão captura a “essência” do workflow de Requisitos.

A Visão provê uma base de alto nível, algumas vezes contratual, para requisitos técnicos mais detalhados. A Visão captura restrições de requisitos e projeto em alto nível, dando ao leitor um entendimento do sistema a ser desenvolvido. Ela provê entrada para o processo de aprovação do projeto e é, portanto, intimamente relacionada ao Caso de Negócio (Business Case). Ela comunica os “o quês e os porquês” fundamentais relativos ao projeto e é um marcador que validará todas as decisões futuras.

O conteúdo da Visão deve responder as seguintes questões, que podem ser quebradas em artefatos separados, mais detalhados, conforme a necessidade:

Quais são os termos utilizados? (Glossário)

Qual problema estamos tentando resolver? (Problem Statement)

Quem são os envolvidos? Quem são os usuários? Quais são suas necessidades?

Quais são as funcionalidades do produto?

Quais são os requisitos não funcionais?

Quais são as restrições de projeto?

A Visão é a essência do workflow de Requisitos e da “best practice”: Gerenciar Requisitos.

T@rgetTrust Treinamento e Tecnologia 17

Page 27: RUP Apostila v12

Visão Geral

Usar uma Arquitetura

No RUP, a arquitetura de um sistema de software (em um dado momento) é a organização ou a estrutura dos componentes significativos do sistema interagindo através de interfaces com componentes compostos de outros componentes e interfaces sucessivamente menores. Quais são as peças principais? Como elas se integram? Existe um framework no qual o restante do software pode ser adicionado?

Para falar de forma razoável sobre arquitetura de software, você deve primeiramente definir uma representação arquitetural, uma forma de descrever os aspectos importantes da arquitetura. Esta descrição é capturada no Documento de Arquitetura de Software, que apresenta a arquitetura em múltiplas visões.

Cada visão arquitetural endereça algum conjunto específico de assunto, especificamente aos envolvidos no processo de desenvolvimento: usuários finais, projetistas, gerentes, engenheiros de sistemas, operadores e assim por diante. Isso serve como meio de comunicação entre o arquiteto de software e os membros do time do projeto com respeito das decisões arquiteturais significativas que são tomadas no projeto.

Definir arquitetura, refinar arquitetura, analizar o comportamento e o projeto de componentes do sistema é a “essência” do workflow de Análise 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 iteração e fase – são a “essência” do workflow de Gerênciamento do Projeto.

Gerenciar pelo Planejamento

“O produto é somente tão bom quanto o plano para o produto”.

O Plano de Desenvolvimento de Software (PDS) reúne toda a informação requerida para gerenciar o projeto. Ele deve incluir um número 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 endereça áreas como: Organização do Projeto, Cronograma (Plano de Projeto, Plano de Iterações, Recursos, Ferramentas), Plano de Gerencia de Requisitos, Plano de Gerência de Configuração, Plano de Resolução de Problemas, Plano de QA, Plano de Testes, Casos de Teste, Plano de Avaliação e Plano de Aceitação de Produto. Para um projeto pequeno, não é necessário manter artefatos separados para cada área. Elas podem ser endereçadas como uma simples seção, ou até mesmo um parágrafo, no PDS.

Em um projeto simples, pode-s incluir uma ou duas sentenças para cada. Por exemplo, um Plano de Gerência de Configuração pode simplesmente dizer: “No final de cada dia, o conteúdo do diretório do projeto será “zipado”, copiado T@rgetTrust Treinamento e Tecnologia 18

Page 28: RUP Apostila v12

Visão Geral

em um disquete com etiqueta e data, marcado com um número de versão e colocado no armário do arquivo central”.

O formato do PDS em si não é tão importante como a atividade e o sentido que se tem ao produzí-lo. Não 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 intenção 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 iterações são organizadas.

Issues (Questões) – Definir Responsáveis e Controlar

Comunicação contínua e aberta, com dados objetivos derivados diretamente das atividades em progresso e a evolução das configurações do produto são importantes em qualquer projeto. Avaliações regulares de status provêm mecanismos para endereçar, comunicar e resolver questões de gerenciamento, questões técnicas e riscos de projeto. Além de identificar as “issues”, cada uma deve ser associada a uma data, com uma pessoa responsável pela resolução. Elas devem ser regularmente acompanhadas e atualizadas quando necessário.

Business Case (Caso de Negócio) – Examinar o Caso de Negócio

O “Business Case” provê a informação necessária, do ponto de vista de negócio, para determinar se o projeto vale o investimento.

A proposta principal do “Business Case” é desenvolver um plano econômico para realização da Visão 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 restrições econômicas. Produz ainda, informação para os tomadores de decisões econômicas no projeto e é usado para determinar se o projeto deve seguir em frente.

A descrição não deve se aprofundar no problema específico, mas sim, criar um argumento convincente de por que o produo é necessário. Deve ser breve, portanto, fácil o suficiente para todos os membros do projeto entenderem e lembrarem. Em marcos críticos do projeto, o “Business Case” é re-examinado para verificar se as estimativas de retorno e custo ainda estão precisas e se o projeto deve ser continuado.

T@rgetTrust Treinamento e Tecnologia 19

Page 29: RUP Apostila v12

Visão Geral

Evaluation (Avaliação) – Avaliar regularmente os resultados

A Avaliação da Iteração captura os resultados de uma iteração, o grau atingido de acordo com os critérios de avaliação, as lições aprendias e as alterações no processo a serem implementadas.

A Avaliação da Iteração é um artefato essencial da abordagem iterativa. Dependendo do escopo e risco do projeto e da natureza da iteração, ela pode variar de um simples registro de demonstração a um registro de revisão 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 construção, teste e avaliação de versões executáveis do produto visando eliminar problemas e resolver riscos e questões tão cedo quanto possível.

Construir e testar componentes do sistema de forma incremental é a “essência” dos workflows de Implementação e Teste e da “best practice”: Desenvolver Iterativamente.

Controlar Mudanças

Assim que o primeiro protótipo é colocado para os usuários (e freqüentemente até antes disso) mudanças serão solicitadas. (Uma daquelas certezas da vida!). Para controlar essas mudanças e gerenciar efetivamente o escopo do projeto e expectativas dos envolvidos, é importante que todas as mudanças em qualquer artefato seja proposta através de “Change Requests” (Requisição de Mudança) e gerenciadas com um processo consistente.

“Change Request” são usados para documentar e acompanhar defeitos, requsições de melhorias e qualquer outro tipo de requisição de mudança do produto. O benefício dos “Change Requests” é que eles possibilitam o registro das decisões, e, devido ao processo de avaliação de impacto, asseguram que os impactos da mudança potencial são entendidos por todos os membros do time do projeto. Os “Change Requests” são essenciais para gerenciamento do escopo do projeto, bem como a avaliação do impacto das mudanças propostas.

Gerenciar e controlar o escopo do projeto, assim que as mudanças ocorrem ao longo do ciclo de vida do projeto, mantendo o objetivo de considerar e atingir todas as necessidades dos envolvidos, na máxima estensão possível – esta é a “essência” do workflow de Gerenciamente de Configuração e mudanças e da “best practice”: Controlar Mudanças.

Entregar um Produto Utilizável

A proposta de um processo é produzir um produto utilizável. Todos os aspectos do processo devem ser ajustados tendo esse objetivo em mente. O T@rgetTrust Treinamento e Tecnologia 20

Page 30: RUP Apostila v12

Visão Geral

produto é, tipicamente, mais do que apenas software. No mínimo, deve haver um Guia de Usuário, talvez implementado em forma help online. Você pode também incluir um Guia de Instalação e “Release Notes” (Notas de Versão). Dependento da complexidade do produto, material de treinamento pode ser também necessário, 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 não seja seguido cegamente – o processo e as ferramentas devem ser configurados para ir ao encontro das necessidades da organização e do projeto. Esta á a “essência” do workflow de Environment (Ambiente).

Conclusão

As “essências” acima provêm uma forma de avaliação rápida em um processo e a identificação de áreas onde melhorias serão mais benéficas. É importante explorar o que aconteceria se alguma dessas essências for ignorada. Por exemplo:

Sem Visão? Você pode perder o trilho de onde você está indo e pode ser facilmente distraído por desvios.

Sem plano? Você não vai conseguir acompanhar o progresso.

Sem lista de riscos? Você pode estar focando nas questões erradas agora e daqui a 5 meses algo inesperado pode explodir.

Sem lista de “issues” (questões/pendências)? Sem responsabilidades, obstáculos ao sucesso podem permanecer indefinidamente.

Sem “business case” (caso de negócio)? Você arrisca perder tempo e dinheiro no projeto, ele pode ser cancelado ou ir à bancarrota.

Sem arquitetura? Você pode não conseguir lidar com questões de comunicação, sincronização e acesso a dados quando elas surgirem, problemas com escalabilidade e performance.

Sem produto (protótipo)? Apenas acumular papel não assegura a você ou ao cliente que o produto terá sucesso – e aumenta o risco de aumento de orçamento e cronograma.

Sem avaliação? Não enfie a cabeça na areia. É importante encarar a verdade. O quão perto você realmente está do seu deadline? Para suas metas em qualidade ou orçamento?

Sem “change requests” (requisições de mudança)? Como você mantém o acompanhamento disso?

Sem suporte ao usuário? O que acontece quando um usuário tem uma pergunta ou não sabe como usar o produto? O quanto é fácil obter ajuda?

Essas “essências” também provêm uma introdução para cada um dos “core workflows” do RUP e muitas de suas “best practices”.T@rgetTrust Treinamento e Tecnologia 21

Page 31: RUP Apostila v12

Visão Geral

Melhores Práticas

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

Desenvolver em Iterações

Para mitigar os riscos, desenvolver incrementalmente de forma iterativa. Cada iteração resulta em uma “release” executável.

O que é Desenvolvimento Iterativo?

Um projeto usando desenvolvimento iterativo tem um ciclo de vida que consite de várias iterações. Uma iteração consiste em uma seqüência de atividades em modelagem de negócio, requisitos, análise e projeto, implementação, teste e deployment, em várias proporções dependendo de onde dentro do ciclo de desenvolvimento a iteração está. Iterações nas fases de Inception e Elaboration focam em atividades de gerenciamento, requisitos e projeto. Iterações na fase de Construction focam em atividades de projeto, T@rgetTrust Treinamento e Tecnologia 22

Page 32: RUP Apostila v12

Visão Geral

implementação e teste. Iterações 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 têm 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 não são 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 iteração baseado em uma lista de riscos chave. Uma vez que a iteração produz um executável testado, você pode verificar se mitigou os riscos alvo ou não.

Benefícios de uma Abordagem Iterativa

T@rgetTrust Treinamento e Tecnologia 23

Page 33: RUP Apostila v12

Visão Geral

Uma abordagem iterativa é geralmente superior a uma abordagem linear ou cascata por muitas razões diferentes.

Tolerância à mudança de requisitos. A realidade é que normalmente requisitos vão mudar. Mudanças 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 são integrados progressivamente – integração não é um “big bang” no fim. A abordagem iterativa é quase como integração contínua. O que costumava ser uma fase longa, incerta e problemática, tomando até 40% do esforço total no fim de um projeto, é agora dividida em seis a nove integrações menores que começam com poucos elementos.

Riscos são mitigados mais cedo, porque na integração é geralmente o único momento onde os riscos são descobertos ou endereçados. No desenrolar das primeiras iterações, 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 não serem riscos na verdade e riscos novos e imprevistos podem emergir.

Possibilita a organização aprender e melhorar. Os membros do time podem aprender ao longo do caminho e as várias competências e especialidades são totalmente empregadas durante todo o ciclo de vida. Testadores começam a testar mais cedo, redatores técnicos escrevem antes e assim por diante. Em um desenvolvimento não-iterativo, o mesmo pessoal estaria esperando para começar seu trabalho, fazer seus planos e afiar suas habilidades. Necessidades de treinamento ou necessidade de apoio adicional (talvez externo) aparecem cedo durante as revisões de avaliação.

Facilita o reuso, porque é mais fácil identificar partes comuns enquanto estão projetadas ou implementadas parcialmente, ao invés de identificar tudo que é comum de antemão. Identificar e desenvolver partes reutilizáveis é difícil. Revisões de projeto nas primeiras iterações possibilitam ao arquiteto de software identificar reusos potenciais e desenvolver e amadurecer código comum nas iterações subseqüentes.

Resulta em um produto mais robusto, porque você está corrigindo erros nas várias iterações. Falhas são detectadas mesmo nas primeiras iterações quando o produto se move além da Inception. Gargalos de performance são descobertos a tempo de ainda serem endereçados, ao invés de na véspera da entega.

Tolerância a mudanças táticas no produto. Por exemplo, para competir com produtos existentes. Você pode decidir lançar um produto com funcionalidade reduzida para conter o movimento de

T@rgetTrust Treinamento e Tecnologia 24

Page 34: RUP Apostila v12

Visão 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 avaliação no fim de uma iteração não apenas olha para o status do projeto pela perspectiva do produto e cronograma, mas analisa também o que poderia ser mudado na organização e no processo em si para fazer melhor na próxima iteração.

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 integração. Então tudo cai aos pedaços. Com a abordagem iterativa, é muito difícil 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. Iterações são planejadas em número, duração e objetivo. As tarefas e responsabilidades dos participantes são definidas. Medidas objetivas de progresso são capturadas. Algum retrabalho vai ser necessário de uma iteração para a outra, mas isto é, também, cuidadosamente contralado.

Gerenciar Requisitos

O que é Gerenciamento de Requisitos?

Gerenciamento de requisitos é uma abordagem sistemática para encontrar, documentar, organizar e acompanhar as mudanças de requisitos de um sistema.

Definimos um requisito como:

Uma condição ou capacidade com a qual o sistema tem que ter conformidade.

Nossa definição formal de Gerenciamento de Requisitos é: uma abordagem sistemática 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 mudanças de requisitos do sistema

As chaves para o Gerenciamento de Requisitos efetivo incluem a manutenção de sentenças claras para os requisitos, em conjunto com atributos aplicáveis 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 não são sempre óbvios e podem vir de várias fontes.

Requisitos não são sempre fáceis de expressar em palavras claras.

Existem muitos tipos diferentes de requisitos em diferentes níveis de detalhamento.

T@rgetTrust Treinamento e Tecnologia 25

Page 35: RUP Apostila v12

Visão Geral

O número de requisitos pode se tornar impossível de gerenciar se não houver controle.

Requisitos são relacionados uns com os outros e também com outros deliverables do processo de engenharia de software.

Requisitos têm propriedades únicas ou valores próprios. Por exemplo, eles não são nem igualmente importantes nem igualmente fáceis de alcançar.

Existem muitas partes interessadas, o que significa que requisitos precisam ser gerenciados por grupos de pessoas multi-funcionais.

Requisitos mudam.

Então, que habilidades você precisa desenvolver em sua organização para apoiar no gerenciamento dessas dificuldades? Nós aprendemos que as seguintes habilidades são as mais importantes:

Análise do problema

Endenter as necessidades dos envolvidos

Definir o sistema

Gerenciar o escopo do projeto

Refinar a definição do sistema

Gerenciar a mudança de requisitos

Desenvolvimento orientado por Casos de Uso

Casos de uso (Use Cases) são o método recomendado para a organização de seus requisitos. Ao invés de uma lista de requisitos, você organiza-os de forma que eles contem uma história de como alguém pode usar o sistema. Isto melhora na completude e consistência e você vai obter um entendimento melhor da importância de um requisito na perspectiva do usuário.

No RUP, casos de uso definem o comportamento realizado pelo sistema. Casos de uso não fazem parte de orientação a objetos “tradicional”, mas sua importância tem se tornado mais e mais aparente. Isto é ainda mais enfatizado pelo fato de que os Casos de Uso são 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 são a base para todos o processo de desenvolvimento.

Casos de Uso tomam parte em vários dos “core workflows” do processo.

O conceito de casos de uso pode ser usado para representar processos de negócio, como definido no workflow de modelagem de negócio. Nós chamamos essa variação de Caso de Uso de Negócio (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 usuário. Desta forma, os casos de uso constituem um conceito importante e

T@rgetTrust Treinamento e Tecnologia 26

Page 36: RUP Apostila v12

Visão Geral

fundamental que deve ser aceitável tanto pelo cliente como pelos desenvolvedores do sistema.

Na análise e projeto os casos de uso são “realizados” no modelo de projeto (design model). Você cria realizações 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 implementação, o modelo de projeto serve como especificação. A implementação será nos termos das classes de projeto e os casos de uso são a base para o modelo de projeto.

Durante os testes, os casos de uso constituem a base para identificação dos casos de teste (test cases) e os procedimentos de teste. Ou seja, o sistema é verificado pela execução de cada caso de uso.

No workflow de Gerenciamento de Projeto, os casos de uso são base para o planejamento do desenvolvimento iterativo.

No workflow de Deployment (Entrega), eles são as fundações para o que será descrito nos manuais do usuário. Casos de uso também podem ser usados para definir diferenciação de distribuições. 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 são grupos coesos de código, em forma de fonte ou executável, com interfaces bem definidas e comportamento que provê forte encapsulamento de seu conteúdo e são, portanto, substituíveis. Arquiteturas baseadas em torno de componentes tendem a reduzir o tamanho efetivo e a complexidade da solução, sendo então mais robustas e resilientes.

Ênfase na Arquitetura

Casos de uso conduzem o RUP de ponta a ponto em todo o ciclo de vida, mas as atividades de projeto são centradas em torno da noção da arquitetura T@rgetTrust Treinamento e Tecnologia 27

Page 37: RUP Apostila v12

Visão Geral

do sistema e, para sistemas intensivos de software, na arquitetura de software. O foco principal nas primeiras iterações do processo – principalmente na fase de elaboração – é produzir e validar uma arquitetura de software. No início do ciclo do desenvolvimento o sistema toma forma de um protótipo arquitetural executável que evolui gradualmente para se tornar o sistema final nas últimas iterações. Por arquitetura executável, entendemos uma implementação parcial do sistema, construída para demonstrar funções e propriedades do sistema selecionadas, em particular, aquelas que satisfazem requisitos não 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 construção sobre uma fundação sólida, sem medo de desmoronamento.

Arquitetura é importande por várias razões:

Permite obter ganho e retenção 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 não trivial, um módulo, um pacote ou um subsistema, o qual cumpre uma função clara, tem limites claros e pode ser integrado em uma arquitetura bem definida. É a realização física de uma abstração 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 vão interagir.

Conceitos como pacotes, subsistemas e camadas são usados durante a Análise e Projeto para organizar componentes e especificar interfaces.

O teste é organizado primeiramente em torno dos componentes, então gradualmente em torno de conjuntos maiores de componentes integrados.

T@rgetTrust Treinamento e Tecnologia 28

Page 38: RUP Apostila v12

Visão Geral

Modelar Visualmente (UML)

Modelagem visual aumenta o nível de abstração

O que é Modelagem Visual?

Modelagem Visão é o uso de notações gráficas e textuais, semanticamente ricas, para capturar o projeto do software. Uma notação, como UML, permite que o nível de abstração cresça, enquanto mantém uma sintaxe e semântica rigorosas. Desta forma, melhora a comunicação no time do projeto (enquanto o projeto é formado e revisado), permitindo ao leitor o entendimento lógico do projeto e a produção de uma base livre de ambigüidades para a implementação.

Por que fazer Modelagem?

O modelo é uma visão simplificado de um sistema. Ele mosta o essencial do sistema de uma perspectiva particular e esconte detalhes não essenciais. Modelos podem ajudar a:

Ajudar no entendimento de sistemas complexos

Explorar e comparar alternativas de projeto a um custo mais baixo

Formar uma fundação para a implementação

Capturar os requisitos precisamente

Comunicar decisões livres de ambiguidades

T@rgetTrust Treinamento e Tecnologia 29

Page 39: RUP Apostila v12

Visão Geral

Verificar Qualidade

Problemas de software são 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 Verificação de Qualidade ao longo do ciclo de vida?

É importante que a qualidade de todos os artefatos seja avaliada em vários pontos do ciclo de vida do projeto enquanto eles amadurecem. Artefatos devem ser avaliados quando as atividades que os produzem se completam e na conclusão de cada iteração. Em particular, quando software executável é produzido, ele deve ser sujeito a demonstração e teste dos cenários importantes em cada iteração, produzindo entendimento mais tangível das decisões de projeto e eliminação 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 serviços. Ainda assim, quando se pergunta: “O que é Qualidade?”, todos tem opiniões diferentes. As respostas mais comuns incluem:

“Qualidade... Não estou muito certo de como descreve-la, mas eu saberei quando eu a vir.”

ou

“... atingir aos requisitos.”

Talvez a referência a qualidade mais freqüente, especificamente relacionada a software, é a observação a respeito de sua ausência:

“Como podem lançar software como esse, com qualidade tão baixa!?”

Estas respostas comuns são expressivas, mas carecem de espaço maior para exame mais rigorose de qualidade e de melhoria em sua execução. Todos estes comentários ilustram a necessidade de definir qualidade em uma maneira pela qual ela pode ser medida e alcançada.

Qualidade, entretanto, não é uma característica singular ou um atributo. É multi-dimensional e pode ser adquirida por um produto ou um processo. A

T@rgetTrust Treinamento e Tecnologia 30

Page 40: RUP Apostila v12

Visão Geral

qualidade do produto é concentrada em construir o produto certo, enquanto que a qualidade do processo foca em construir o produto corretamente.

Definição de qualidade

A definição 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.

Qualidade 1.a. Uma característica inerente ou distintiva; uma propriedade. b. A personal trait, especially a character trait. b. Um traço pessoal, especialmente um traço de caráter. 2. Caráter essencial; natureza. 3.a. Superioridade no gênero. b. Marca ou grau de excelência.

Como demonstrado pela definição, qualidade não está em uma dimensão única, mas em muitas. Para usar a definição e aplicá-la em desenvolvimento de software, ela deve ser refinada. Portanto, para a propostas do RUP, qualidade é definida como:

“A característica identificada pelo seguinte:

satisfaz ou excede o conjunto de requisitos acordados, e

avalidado usando medidas e critérios acordados, e

produzido usando um processo acordado.”

Obter qualidade não é simplesmente “preencher requisitos” ou produzir um produto que vá ao encontro das necessidades e expectativas do usuário. Qualidade também inclui identificar as medidas e os critérios para demonstrar o atingimento da qualidade e a implementação 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 (métricas) de aceitação de qualidade

Identificar medidas apropriadas para serem usadas na avaliação e julgamento da qualidade

Identificar e endereçar apropriadamente questões que afetam a qualidade o quanto mais cedo e tão efetivamente quanto possível

T@rgetTrust Treinamento e Tecnologia 31

Page 41: RUP Apostila v12

Visão Geral

O gerenciamento de qualidade é implementado ao longo de todos os workflows, fases e iterações 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 esforços gastos em cada workflow para gerenciar qualidade são destacados abaixo:

Gerenciamente de qualidade no workflow de Requisitos inclui analisar o conjunto de artefatos de requisitos pela consistência (entre os artefatos modelo e outros artefatos), clareza (comunica a informação de forma clara para os envolvidos e para os outros papeis) e precisão (nível apropriado de detalhamento e precisão).

No workflow de Análise e Projeto, gerenciar qualidade inclui avaliar o conjunto de artefatos de projeto, incluindo a consistência do modelo de projeto, sua tradução a partir dos artefatos de requisitos e sua tradução para os artefatos de implementação.

No workflow de implementação, gerenciar qualidade inclui avaliar os artefatos de implementação e avaliar o código fonte e os artefatos executáveis contra os apropriados artefatos de requisitos, projeto e teste.

O workflow de teste é altamente focado no sentido de gerenciamento de qualidade, a maioria dos esforços gastos nesse workflow endereça as propostas de gerenciamento de qualidade identificadas acima.

No workflow de Ambiente (Environment), como no de teste, inclui muitos esforços endereçando as propostas de gerência 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 implementação e de entrega contra os artefatos de requisitos, projeto e teste apropriados e necessários para entregar o produto ao cliente.

O workflow de Gerenciamento de Projeto inclui uma visão geral de muitos esforços para gerenciar qualidade, incluindo revisões e auditorias requeridas para avaliar a implementação, aderência e o progresso do processo de desenvolvimento.

T@rgetTrust Treinamento e Tecnologia 32

Page 42: RUP Apostila v12

Visão Geral

Controlar Mudanças

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 múltiplos desenvolvedores organizados em times diferentes, possivelmente em lugares diferentes, trabalhando juntos em múltiplas iterações, releases, produtos e plataformas. Na ausência de controle disciplinado, o processo de desenvolvimento rapidamente degenera para o caos. No RUP o workflow de Gerenciamente de Configuração e Mudanças é devotado a descrever como você enfrentará esse desafio.

Coordenar as atividades e os artefatos dos desenvolvedores e times envolve estabelecer procedimentos repetíveis para gerenciar mudanças no software e em outros artefatos de desenvolvimento. Esta coordenação possibilita a melhor alocação de recursos baseada nas prioridades e riscos do projeto e gerencia ativamente o trabalho destar mudanças ao longo das iterações. Em conjunto com o desenvolvimento do software iterativamente isto praticamente deixa você continuamente monitorando mudanças para que possa ativamente descobrir e então reagir a problemas. Workflow: Gerenciar Requisições de Mudança.

Coordenar iterações e releases envolve estabelecer e lançar uma baseline testada ao completar cada iteração. Manter a rastreabilidade em todos os elementes de cada release e em todos os elementos ao longo de releases múltiplas e paralelas é essencial para avaliar e gerenciar ativamente o impacto das mudanças. Workflow: Gerenciar Baselines e Releases.

Controlar mudanças no software oferece um número de soluções para as causas raiz dos problemas em desenvolvimento de software:

O workflow de mudança de requisitos é definido e repetível.

“Change requests” (Requisições de Mudança) facilitam a clareza das comunicações

Workspaces separados reduzem a interferência entre os membros do time trabalhando em paralelo

Estatísticas de mudanças provêm boas métricas para avaliar objetivamente o status do projeto.

T@rgetTrust Treinamento e Tecnologia 33

Page 43: RUP Apostila v12

Visão Geral

Os workspaces contêm todos os artefatos, facilitando a consistência.

A propagação das mudanças é avaliável e controlada.

Mudanças podem ser mantidas em um sistema robusto e customizável

T@rgetTrust Treinamento e Tecnologia 34

Page 44: RUP Apostila v12

Visão Geral

Exercícios

T@rgetTrust Treinamento e Tecnologia 35

Page 45: RUP Apostila v12

Visão Geral

Espaço para anotações

T@rgetTrust Treinamento e Tecnologia 36

Page 46: RUP Apostila v12

RUP

2.2. FasesFases

T@rgetTrust Treinamento e Tecnologia 1

Page 47: RUP Apostila v12

Fases

Objetivos

Conhecer as fases do RUP

Conhecer os objetivos e milestones de cada fase

T@rgetTrust Treinamento e Tecnologia 2

Page 48: RUP Apostila v12

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 seqüenciais, cada uma é concluída por um milestone (marco) principal. Cada fase é essencialmente um intervalo de tempo entro dois milestones principais. A cada final de fase, uma avaliação é executada (Atividade: Revisão de Marco de Ciclo de Vida) para determinar se os objetivos da fase foram atingidos. Um julgamento satisfatório possibilita que o projeto passe para a próxima fase.

Planejamento das Fases

As fases não são idênticas nem em termos de cronograma nem em duração. Apesar de poder variar consideravelmente dependendo do projeto, um ciclo de desenvolvimento inicial típico em um projeto de tamanho médio pode seguir a seguinte distribuição entre esforço e duração (tempo):

Inception Elaboration Construction Transition

Esforço ~5 % 20 % 65 % 10%

Duração 10 % 30 % 50 % 10%

Que pode ser colocado graficamente como:

T@rgetTrust Treinamento e Tecnologia 3

Page 49: RUP Apostila v12

Fases

Para um ciclo de evolução, as fases de inception e elaboration serão consideravelmente menores. Ferramentas que podem automatizar alguma parte do esforço de Construção podem mudar essa visão, fazendo com que a fase de construction possa ser muito menor do que as fases de inception e elaboration juntas.

Uma passada através das quatro fases compõe um ciclo de desenvolvimento. Cada passada produz uma geração de um software. A menos que o produto “morra”, ele ira evoluir para sua próxima geração repetindo a mesma seqüência de fases de inception, elaboration, construction e transition, mas desta vez com ênfase diferente nas várias fases. Esses ciclos subseqüentes são chamados de ciclos de evolução. A medida que o produto vai através de vários ciclos, novas gerações são produzidas.

Ciclos de evolução podem ser disparados por melhorias sugeridas pelo usuário, por mudanças no contexto do usuário, mudanças na tecnologia, reação a competição e assim por diante. Ciclos de evolução tipicamente têm fases de Inception e Elaboration mais curtas, uma vez que a definição básica do produto e da arquitetura foi determinada pelos ciclos de desenvolvimento anteriores. Exceções para essa regra são ciclos de evolução nos quais ocorre redefinição significativa do produto ou da arquitetura.

T@rgetTrust Treinamento e Tecnologia 4

Page 50: RUP Apostila v12

Fases

Inception (Concepção)

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 significância primordial para esforços em novos desenvolvimentos, nos quais existem riscos significativos de negócio e requisitos que devem ser endereçados 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 é viável (possível) de se fazer.

Os objetivos primordiaisda fase de inception incluem:

Estabelecer o escopo e as condições de limite para o projeto de software, incluindo uma visão operacional, critérios de aceitação e o que se entende que o produto deve ser e o que não deve.

Discriminar os casos de uso críticos do sistema, os cenários primordias de operação que irão conduzir as principais decisões de projeto.

Evidenciar e talvez demonstrar, ao menos uma arquitetura candidata para alguns dos cenários 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 restrições mais importantes a uma extensão tal que possa derivar os critérios de aceitação para o produto final.

Planejar e preparar um “business case” (caso de negócio). Avaliar alternativas para gerenciamento de riscos, pessoal, planejamento do projeto e decisões de custo/cronograma/rentabilidade.

Sintetizar a arquitetura candidata, avaliar as decisões de projeto (design) e em construir/comprar/reusar, para que custo, cronograma e recursos possam ser estimados. A meta aqui é demonstrar a factibilidade através 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 protótipo que explora o que pode ser considerado como sendo área de alto risco. O esforço de prototipação durante a inception deve ser limitado a

T@rgetTrust Treinamento e Tecnologia 5

Page 51: RUP Apostila v12

Fases

adquirir confiança que a solução é possível – a solução é realizada durante a elaboração e a construção.

Preparar o ambiente de trabalho para o projeto, avaliar o projeto e a organização, 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.

Critérios de Avaliação:

Envolvimento dos interessados (stakeholders) na definição 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 estão apropriados.

Todos os riscos foram identificados e existe uma estratégia de mitigação para cada um.

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

Artefatos

Artefatos Essenciais (em ordem de importância)

Estado no milestone

Visão Os requisitos centrais do projeto, funcionalidades chave e restrições principais estão documentados.

Business Case Definido e aprovado.

Lista de Riscos Riscos iniciais do projeto identificados.

Plano de Desenvolvimento de Software

Fases iniciais, suas durações 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 necessários para ir até a fase de elaboration. Estimativas dos recursos requeridos para todo o projeto, nesse ponto, devem ser vistas como “grosseiras”, um chute. Esta estimativa é

T@rgetTrust Treinamento e Tecnologia 6

Page 52: RUP Apostila v12

Fases

atualizada em cada fase e em cada iteração e se torna mais precisa a cada iteração.

Dependendo das necessidades do projeto, um ou mais dos artefatos de Planejamento incluídos podem ser opcionalmente completados. Adicionalmente, os artefatos “Guidelines” estão tipicamente, pelo menos em forma de “draft”.

Plano de Iteração

Plano de Iteração para a primeira iteração da fase de Elaboration deve estar completo e revisado.

Plano de aceitação do produto

Revisado e com data de referência (baseline); será refinado em iterações subseqüentes ao se descobrirem requisitos adicionais.

Caso de Desenvolvimento

Adaptações e extensões ao RUP, documentadas e revisadas.

Templates específicos para o projeto

Os templates dos documentos usados para desenvolver os artefatos documentais.

“Guidelines” para a Modelagem de Casos de Uso

Com data de referência (baseline).

Ferramentas Todas as ferramentas de suporte ao projeto estão selecionadas. As ferramentas necessárias para o trabalha na Inception estão instaladas.

Glossário Termos importantes definidos; glossário revisado.

Modelo de Casos de Uso (Atores, Casos de Uso).

Atores e Casos de Uso importantes identificados e a seqüência de eventos desenhada em linhas gerais para os casos de uso mais críticos.

Artefatos Opcionais

Estado no milestone

Modelo de Domínio (também conhecido como Modelo de Objetos de Negõcio).

Os conceitos chave que estão sendo usados no sistema, documentados e revisados. Usado como uma extensão ao Glossário nos casos onde há relacionamentos específicos entre conceitos cuja captura é essencial.

Protótipos Um ou mais protótipos de prova de conceito, para auxiliar a Visão e o Business Case e para endereçar os riscos mais específicos.

T@rgetTrust Treinamento e Tecnologia 7

Page 53: RUP Apostila v12

Fases

Elaboration (Elaboração)

Objetivos

A meta da fase de elaboração é definir uma base para a arquitetura do sistema de forma a produzir uma fundação estável para o esforço maior de projeto e implentação que ocorrerá na fase de construction. A arquitetura evolui da consideração dos requisitos mais significativos (aqueles que têm grande impacto na arquitetura do sistema) e da avaliação dos riscos. A estabilidade da arquitetura é validada através de um ou mais protótipos arquiteturais.

Os objetivos primordiais da fase de elaboration incluem:

Assegurar que a arquitetura, requisitos e planos são estáveis o suficiente, e os riscos suficientemente mitigados para possibilitar a previsibilidade na determinação do custo e cronograma para completar o desenvolvimento. Para muitos projetos, passar esse milestone também corresponde a uma transição de uma operação leve e rápida, de baixo risco, para uma operação de alto custo e alto risco com uma inércia organizacional substancial.

Endereçar todos os riscos arquiteturais significativos do projeto

Estabelecer uma base para a arquitetura derivada do endereçamento dos cenários arquiteturais significativos, os quais tipicamente expõem os maiores riscos técnicos do projeto.

Produzir um protótipo evolucionário de componentes com qualidade de produção, bem como possivelmente um ou mais protótipos exploratórios, não economize protótipos para mitigar riscos específicos, como:

o Decisões de projeto e requisitos

o Reuso de componentes

o Factibilidade do produto ou demonstrações para investidores, clientes e usuários finais

Demonstrar que a arquitetura base vai suportar os requisitos do sistema a um custo razoável em um tempo razoável

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 rápida e prática.

T@rgetTrust Treinamento e Tecnologia 8

Page 54: RUP Apostila v12

Fases

Refinar a Visão, baseado nas informações novas obtidas durante a fase, estabelecendo um entendimento sólido dos casos de uso mais críticos que conduzem as decisões arquiteturais e de planejamento.

Criar e estabelecer planos de iteração detalhados para a fase de construção.

Refinar o caso de desenvolvimento e montar o ambiente de desenvolvimento, incluindo o processo, ferramentas e suporte automatizado requerido para suportar o time de construção.

Refinar a arquitetura e selecionar componentes. Os componentes potenciais estão validados e as decisões de construir/comprar/reusar estão suficientemente definidas para determinar o custo e cronograma da fase de construction com confiança. Os componentes arquiteturais selecionados estão integrados e validados contra os cenários primordiais. As lições aprendidas nestas atividades podem bem resultar em um re-projeto da arquitetura, levando em consideração projetos alternativos ou reconsideração dos requisitos.

Milestone: Lifecycle Architecture

O milestone “Lifecycle Architecture” estabelece uma referência gerenciável para a arquitetura do sistema e torna possível 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 resolução dos riscos principais.

Criérios de Avaliação

A Visão do produto e os requisitos estão estáveis

A arquitetura está estável

Os protótipos executáveis demonstram que os elementos de maior risco foram endereçados e foram resolvidos com credibilidade

Os planos de iteração para a fase de construction estão em detalhamento e fidelidade suficiente para permitir o prosseguimento do trabalho

Os planos das iterações para a fase de construction estão baseados por estimativas confiáveis

Todos os envolvidos concordam que a visão 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 são aceitáveis de acordo com o plano de gastos.

T@rgetTrust Treinamento e Tecnologia 9

Page 55: RUP Apostila v12

Fases

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

Artefatos

Artefatos Essenciais (em ordem de importância)

Estado no milestone

Protótipos Um ou mais protótipos arquiteturais executáveis foram criados para explorar funcionalidades críticas e cenários arquiteturalmente significativos.

Lista de Riscos Atualizada e revisada. Novos riscos são propensos a ser de natureza arquitetural, primordialmente relacionadas a manipulação de requisitos não funcionais.

Caso de Desenvolvimento

Refinado com base na experiência inicial do projeto. O ambiente de trabalho para o desenvolvimento, inclusive o processo, ferramentas e suporte automatizado requerido para auxiliar o time de construção é instalado e colocado em operação.

Templates específicos do projeto

Os templates do documento usados para desenvolver os artefatos documentais.

Ferramentas As ferramentas usadas para o trabalho na Elaboração são instaladas.

Documento de Arquitetura de Software

Criado e estabelecido, incluindo descrições detalhadas para os casos de uso arquiteturalmente significativos (use-case view), identificação dos mecanismos chave e dos elementos chave de projeto (logical view), mais a definição do “process view” e da “deployment view” (do Modelo de Deployment) se o sistema é distribuído ou deve lidar com questões de concorrencia.

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

Definido e estabelecido. A realização dos casos de uso para os cenários significativos arquiteturalmente estão definidos o o comportamento requerido está alocado para os elementos apropriados do projeto. Componentes estão identificados e as decisões construir/comprar/reusar estão suficientemente entendidas para determinação do custo e cronograma da fase de construction com confiança. Os componentes arquiteturais selecionados estão integrados e avaliados contra os cenários primoriais. As lições aprendidas a partir destas atividades podem resultar em uma redefinição da arquitetura, levando em consideração designs alternativos ou reconsideração dos requisitos.

Modelo de Definido e estabelecido. Os elementos principais do modelo T@rgetTrust Treinamento e Tecnologia 10

Page 56: RUP Apostila v12

Fases

Dados de dados (entidades, relacionamentos e tabelas importantes) estão definidos e revisados.

Modelo de Implementação (e todos os artefatos que o constituem, inclusive os componentes)

Estrutura inicial criada e os componentes principais identificados e prototipados.

Visão Refinada, baseada nas novas informações obtidas durante a fase, estabelecendo um entendimento sólido dos casos de uso mais críticos que conduzem as decisões arquiteturais e de planejamento.

Plano de Desenvolvimento de Software

Atualizado e expandido para cobrir as fases de Construction e Transition.

Guidelines, como guias de projeto e guias de programação.

As “guidelines” usadas para auxiliar o trabalho.

Plano de Iteração

Plano de iteração para a fase de construction completo e revisado.

Modelo de Casos de Uso (Ators, Casos de Uso)

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 descrições de casos de uso (captura de requisitos) está desenvolvida.

Especificações suplementares

Requisitos suplementares capturando os requisitos não funcionais estão documentados e revisados.

Artefatos Opcionais

Estado no milestone

Business Case Atualizado se as investigações arquiteturais descobriram questões que mudam as premissas fundamentais do projeto.

Modelo de Análise

Deve ser desenvolvido como um artefato formal; frequentemente mantido de forma não formal, evoluindo então para uma versão preliminar do Modelo de Projeto.

Materiais de Treinamento

Manuais de usuário e outros materiais de treinamento. Rascunhos preliminares, baseados nos casos de uso. Pode ser necessário se o sistema tem aspectos importantes em interface de usuário.

T@rgetTrust Treinamento e Tecnologia 11

Page 57: RUP Apostila v12

Fases

Construction (Construção)

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 operações para otimizar custos, cronogramas e qualidade. Neste sentido a disciplina de gerenciamento passa por uma transição de desenvolvimento de propriedade intelectual durante a inception e elaboration, para o desenvolvimento de produtos entregáveis durante a construction e a transition.

Os objetivos primordiais da fase de construction incluem:

Minimizar os custos do desenvolvimento pela otimização dos recursos e eliminação de elementos dispensáveis e retrabalhos desnecessárias.

Atingir qualidade adequada de forma rápida e prática

Atingir verões utilizáveis (alpha, beta, and other test releases) de forma rápida e prática.

Completar a análise, projeto, desenvolvimento e teste de todas as funcionalidades requeridas.

Desenvolver de forma iterativa e incremental um produto completo que estará pronto para a transição para a comunidade de usuários. Isto implica em descrever os casos de uso restantes e outros requisitos, detalhar o projeto (design), completar a implementação e testar o software.

Decidir se o software, as locações e os usuários estão todos prontos para a aplicação 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 sincronização dos workflows. Uma arquitetura robusta é essencial quando se deseja atingir um nível significativo de paralelismo.

Atividades Essenciais

Gerenciamento de recursos, controle e otimização do processo.

Completar o desenvolvimento dos componentes e testar contra os critérios de avaliação definidos

T@rgetTrust Treinamento e Tecnologia 12

Page 58: RUP Apostila v12

Fases

Avaliação das releases do produto contra os critérios de aceitação da Visão

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 Transição. Todas as funcionalidades foram desenvolvidas e todos os testes alfa (se houverem) foram completados. Em adição ao software, um manual de usuário foi desenvolvido e existe uma descrição da release atual.

Critérios de Avaliação

Os critérios de avaliação para a fase de construiction envolvem as respostas para as seguintes questões:

A release do produto está estável e madura o suficiente para ser colocada em uso na comunidade de usuários?

Os envolvidos estão todos prontos para a transição para a comunidade de usuários?

Os recursos gastos até o momento em relação aos gastos planejados ainda são aceitáveis?

A transição pode ter de ser adiada para o próximo release se o projeto falhar em alcançar esse milestone.

Artefatos

Artefatos Essenciais (em ordem de importância)

Estado no milestone

“O sistema” O sistema executável em si, pronto para começar os testes beta.

Plano de Distribuição (Deployment)

Versão inicial desenvolvida, revisada e estabelecida.

Modelo de Implementação (e todos os artefatos que o contituem, inclusive os componentes)

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

Modelo de Testes (e todos

Testes projetados e desenvolvidos para validar as releases executáveis criadas durante a fase de construction

T@rgetTrust Treinamento e Tecnologia 13

Page 59: RUP Apostila v12

Fases

os artefatos que o constituem)

Material de Treinamento

Manuais de usuário e outros materiais de treinamento. Rascunhos preliminares baseados em casos de uso. Podem ser necessários se os sistema tem aspectos importantes na interface com o usuário.

Plano de Iteração

Plano de iteração para a fase de transition completo e revisado.

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

Atualizado com novos elementos de projeto identificados durante a complementação de todos os requisitos.

Caso de Desenvolvimento

Refinado baseado na experiência anterior do projeto. O ambiente de trabalho, incluindo o pocesso, ferramentas e suporte automatizado requerido para auxiliar o time de transição está pronto para uso.

Templates específicos do projeto

Os templates de documentos usados para desenvolver os artefatos documentais.

Ferramentas As ferramentas usadas para auxiliar o trabalho na Construction são instaladas.

Modelo de Dados

Atualizado com os elementos necessários para suportar a implementação da persistência (tabelas, índices, mapeamento objeto-relacional, etc.)

Artefatos Opcionais

Estado no milestone

Especificações suplementares

Atualizado com novos requisitos (se houver) descobertos durante a fase de construction.

Modelo de Casos de Uso (Atores, Casos de Uso)

Atualizado com novos casos de uso (se houver) descobertos durante a fase de construction.

T@rgetTrust Treinamento e Tecnologia 14

Page 60: RUP Apostila v12

Fases

Transition (Transição)

Objetivos

O foco da fase de Transition é assegurar que o software está disponível para seus usuários finais. A fase de Transition pode se extender por várias iterações, inclui o teste do produto em preparação para a liberação e ajustes menores baseados em feedback dos usuários. Neste ponto do ciclo de vida, o retorno do usuário deve focar principalmente no ajuste fino do produto, configuração, instalação e questões de usabilidade, todas as principais questões 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 posição de ser encerrado. Em alguns casos, o final do ciclo corrente pode coincidir com o início de um outro ciclo de vida para o mesmo produto, levando a próxima geração ou versão do produto. Para outros projetos, o final da Transition pode coincidir com a entrega completo dos artefatos a terceiros que serão agora responsáveis pela operação, manutenção 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 substituição de um sistema de controle de tráfego aéreo de um país pode extremamente complicado.

As atividades executadas durante uma iteração na Fase de Transition dependem da meta a alcançar. Por exemplo, quando corrigindo bugs, implementação e teste são usualmente suficientes. Se, entretanto, novas features tem de ser adicionadas, a iteração é similar a uma iteração da fase de construction, requerindo análise e projeto e etc.

A Fase de Transition entra quando uma versão está madura o suficiente para ser colocada em uso no domínio de usuário final. Isto usualmente requer que algum subconjunto utilizável do sistema esteja completo e com nível aceitável de qualidade e com documentação de usuário de forma tal que a transição para o usuário produza resultados positivos para todas as partes.

Os objetivos primordiais da Fase de Transition são:

Beta testing para validação do novo sistema contra as expectativas dos usuários

Beta testing e operação em paralelo relativa ao um sistema legado que está se substituindo

Conversão dos bancos de dados operacionais

Treinamento dos usuários e equipe de manutenção

Lançamento do produto no mercado, distribuição e força de vendas.

T@rgetTrust Treinamento e Tecnologia 15

Page 61: RUP Apostila v12

Fases

Engenharia específica de distribuição/entrega como cutover (troca de sistemas), empacotamento comercial e produção, lançamento de vendas e treinamento de pessoal de campo.

Atividades de ajuste como correção de bugs, melhorias de performance e usabilidade.

Avaliação da versão de distribuição contra a Visão completa e os critérios de aceitação do produto.

Conseguir a auto-suficiencia dos usuários no uso sistema

Conseguir a concordância dos envolvidos de que a versão de distribuição está completa

Conseguir a concordância dos envolvidos de que a versão de distribuição está consistente de acordo com os critérios de avaliação da Visão

Atividades Essenciais

Executar os planos de entrega/distribuição

Finalizar o material de suporte ao usuário final

Testar o produto entregavel no ambiente de desenvolvimento

Criar uma release do produto

Obter feedback dos usuários

Ajuste fino do produto baseado no feedback

Tornar o produto disponível para os usuários 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 próximo ciclo. O milestone “Product Release” é o resultado obtido ao completar com sucesso a Atividade: Revisão de Aceitação do Projeto.

Critérios de Avaliação

Os critérios de avaliação primordiais para a fase de transition envolve as respostas para as seguintes questões:

O usuário está satisfeito?

Os recursos gastos até o momento em relação aos gastos planejados são aceitáveis?

Ao chegar no milestone “Product Release”, o produto está em produção e o ciclo de manutenção pós release começa. Isto pode envolver o início de um novo ciclo, ou algumas releases de manutenção adicionais.

T@rgetTrust Treinamento e Tecnologia 16

Page 62: RUP Apostila v12

Fases

Artefatos

Artefatos Essenciais (em ordem de importância)

Estado no milestone

A construção do produto (Product Build)

Completa e de acordo com os requisitos do produto. O produto final deve ser utilizável pelo cliente.

Notas de Release

Completas

Artefatos de Instalação

Completos

Material de Treinamento

Completo para assegurar que o cliente possa tornar-se auto suficiente no uso e na manutenção do produto.

End-User Support Material

Completo para assegurar que o cliente possa tornar-se auto suficiente no uso e na manutenção do produto.

Artefatos Opcionais

Estado no milestone

Test Model The test model may be provided in the situation where the customer wants to runs on-site testing.

'Shrinkwrap' Product Packaging

In the case of creating a shrinkwrap product, the contractor will need the necessary packaging artifacts to help retail the product.

T@rgetTrust Treinamento e Tecnologia 17

Page 63: RUP Apostila v12

Fases

Exercícios

T@rgetTrust Treinamento e Tecnologia 18

Page 64: RUP Apostila v12

Fases

Espaço para anotações

T@rgetTrust Treinamento e Tecnologia 19

Page 65: RUP Apostila v12

RUP

3.3. Core WorkflowsCore Workflows

T@rgetTrust Treinamento e Tecnologia 1

Page 66: RUP Apostila v12

Core Workflows

Objetivos

Conhecer os principais workflows do RUP

Relacionar os workflows a suas atividades e artefatos

T@rgetTrust Treinamento e Tecnologia 2

Page 67: RUP Apostila v12

Core Workflows

Análise de Negócio

Proposta

A proposta da modelagem de negócio é:

Entender a estrutura e a dinâmica da organização na qual o sistema será colocado em uso (a organização alvo).

Endender os problemas atuais da organização alvo e identificar melhorias potenciais

Assegurar que os clientes, usuários finais e desenvolvedores tem um entendimento comum da organização alvo.

T@rgetTrust Treinamento e Tecnologia 3

Page 68: RUP Apostila v12

Core Workflows

Deduzir os requisitos do sistema necessários para suportar a organização alvo.

Para atingir a esses objetivos, o workflow de modelagem de negócios descreve como desenvolver uma visão da nova organização alvo e, baseado nessa visão, definir o processo, papéis e responsabilidades da organização em um modelo de casos de uso de negócio e um modelo de objetos de negócio.

Complementar a esses modelos, os seguintes artefatos são desenvolvidos:

Especificações de negócio suplementares

Glossário

Relacionamento com outros workflows

O workflow de modelagem de negócios é relacionado com outros workflows, conforme segue:

O workflow de Requisitos usa os modelos de negócio como entrada importante para o entendimento dos requisitos do sistema.

O workflow de Análise e Projeto usa as entidades de negócio como entrada para identificar as classes de entidade no modelo de projeto

O workflow de Ambiente desenvolve e mantém os artefatos de suporte, como as Guidelines de Modelagem de Negócio.

Atividades

T@rgetTrust Treinamento e Tecnologia 4

Page 69: RUP Apostila v12

Core Workflows

Artefatos

T@rgetTrust Treinamento e Tecnologia 5

Page 70: RUP Apostila v12

Core Workflows

Requisitos

Proposta

A proposta do workflow de Requisitos é:

Estabelecer e manter a concordância 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 extensão do sistema.

Produzir uma base para o planejamento do conteúdo técnico das iterações.

Produzir uma base para a estimativa de custos e de tempo para o desenvolvimento do sistema.

Definir a interface do usuário para o sistema, focando nas necessidades e objetivos dos usuários.

T@rgetTrust Treinamento e Tecnologia 6

Page 71: RUP Apostila v12

Core Workflows

Para atingir essas metas, é importante, antes de tudo, entender a definição e o escopo do problema que estamos tentando resolver com o sistema. Os Papéis de Negócio, o Modelo de Casos de Uso de Negócio e o Modelo de Objetos de Negócio desenvolvidos durante a Modelagem de Negócio servirão como entradas valiosas para esse esforço. Os envolvidos (stakeholders) são identificados e as Solicitações dos Envolvidos são elencadas, reunidas e analisadas.

Um documento de Visão, um modelo de casos de uso, casos de uso e Especificações Suplementares são desenvolvidas para descrever o sistema totalmente – o que o sistema irá fazer – em um esforço que vê todos os envolvidos, incluindo clientes e usuários potenciais, como fontes importantes de informação (em adição aos requisitos do sistema).

Requisições dos Envolvidos são ativamente elencadas e reunidas das fontes existente para obter uma “lista de desejos” de que os diferentes envolvidos no projeto (clientes, usuários, líderes de produto) esperam ou desejam que o sistema inclua, juntamente com a informação de como cada requisição está sendo considerada pelo projeto.

O documento de Visão prove uma visão completa do sistema de software em desenvolvimento e auxilia no contrato entre a autoridade financiadora e a organização desenvolvedora. Todo o projeto precisa de uma fonte para capturar as espectativas entre os envolvidos. O documento de visão é escrito a partir da perspectiva do cliente, focando nas funcionalidades essenciais do sistema e nos níveis de qualidade aceitáveis. A Visão deve incluir uma descrição de que funcionalidades serão incluídas, bem como aquelas que foram consideradas, mas não serão incluídas. Deve também especificar capacidade operacional (volumes, tempos de resposta, precisão), perfis de usuário (quem usará o sistema) e interfaces de interoperabilidade com entidades fora dos limites do sistema, quando aplicável. O documento de Visão provê a base contratual para os requisitos visíveis aos envolvidos.

O modelo de casos de uso deve servir como um meio de comunicação e pode server como um contrato entre o cliente, os usuários e os desenvolvedores do sistema sobre as funcionalidades do sistema, o que possibilitará:

Aos clientes e usuários, 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 ligação ao longo do ciclo de vida do software; o mesmo modelo de casos de uso é usado na análise, projeto, implementação e teste do sistema.

As Especificações Suplementares são importantes complementos ao modelo de casos de uso, porque juntos eles capturam todos os requisitos do software (funcionais e não-funcionais) que precisam ser descritos para servir como uma especificação completa dos requisitos do software.

T@rgetTrust Treinamento e Tecnologia 7

Page 72: RUP Apostila v12

Core Workflows

Uma definição completa dos requisitos do software descritos nos casos de uso e nas Especificações Suplementares pode ser empacotada em conjunto para definir a Especificação 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 informação e controle que serão coletados e usados para medições, relatórios e controle de mudanças nos requisitos do produto.

Complementando os artefatos mencionados acima, os seguintes são também desenvolvidos:

Glossário

Descrições de casos de uso

Protótipo de interface com o usuário

O glossário é importante porque define uma terminologia comum que é usada consistentemente ao longo do projeto ou pela organização.

A Descrição de Casos de Uso e o Protótipo de Inteface com o Usuário são resultados da modelagem da interface do usuário e prototipação, que é feita em paralelo com as outras atividades de requisitos. Estes artefatos produzem mecanismos de feedback importantes nas iterações seguintes para a descoberta de requisitos desconhecidos ou não claros.

Relacionamento com outros workflows

O workflow de Requisitos está relacionado a outros workflows do processo.

O workflow de Modelagem de Negócio provê Regras de Negócio, um Modelo de Casos de Uso de Negócio e um modelo de Objetos de Negócio, incluindo um Modelo de Domínio e o contexto organizacional para o sistema.

O workflow de Análise e Projeto obtém suas primeiras entradas (o modelo de casos de uso e o Glossário) a partir do workflow de Requisitos. Falhas no modelo de casos de uso podem ser descobertas durante a Análise e Projeto; requisições de mudança são então geradas e aplicadas ao modelo de casos de uso.

O workflow de Teste testa o sistema para verificar o código contra o Modelo de Casos de Uso. Casos de Uso e Especificações Suplementares provêm entrada para os requisitos usados no planejamento e projeto dos testes.

O workflow de Configuração e Mudança provê os mecanismos de controle de mudança para os requisitos. O mecanismo para propor uma mudança é submeter uma Requisição de Mudança, que é revisada pelo Comitê de Controle de Mudanças.

O workflow de Gerenciamento de Projeto planeja o projeto e cada iteração (descrita no Plano de Iteração). O modelo de casos de uso

T@rgetTrust Treinamento e Tecnologia 8

Page 73: RUP Apostila v12

Core Workflows

e o Plano de Gerenciamento de Requisitos são entradas importantes para as atividades de planejamento das iterações.

O workflow de Ambiente (Environment) desenvolve e mantém os artefatos de suporte que são 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 Usuário.

Atividades

Artefatos

T@rgetTrust Treinamento e Tecnologia 9

Page 74: RUP Apostila v12

Core Workflows

Análise e Projeto

Proposta

A proposta da Análise 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 implementação, projetando para a melhor performance.

Relacionamento com outros workflows

O workflow de Análise e Projeto é relacionado a outros workflows, como segue:

O workflow de Modelagem de Negócio provê um contexto organizacional para o sistema.

O workflow de Requisitos provê as primeiras entradas para Análise e Projeto.

T@rgetTrust Treinamento e Tecnologia 10

Page 75: RUP Apostila v12

Core Workflows

O workflow de Teste testa o sistema projetado durante a Análise e o Projeto.

O workflow de Ambiente desenvolve e mantem os artefatos de suporte que são usados durante a Análise e Projeto.

O workflow de Gerenciamento de Projeto planeja o projeto e cada iteração (descritas no Plano de Iteração).

Atividades

Artefatos

T@rgetTrust Treinamento e Tecnologia 11

Page 76: RUP Apostila v12

Core Workflows

Implementação

Proposta

A proposta da implementação é:

Definir a organização do código, em termos da implementação de subsistemas organizados em layers (camadas),

Implementar classes e objetos em termos de componentes (códigos fonte, binários, executáveis e outros),

Testar os componentes desenvolvidos como unidades, e

Integrar os resultados produzidos pelos implementadores individuais (ou times) em um sistema executável.

O workflow de Implementação limita seu escopo a como as classes individualmente devem ser testadas (unit testing). Testes de sistema e testes de integração são descritos no workflow de Teste.

T@rgetTrust Treinamento e Tecnologia 12

Page 77: RUP Apostila v12

Core Workflows

Relacionamento com outros workflows

Implementação é relacionada a outros workflows:

O workflow de Requisitos descreve, no modelo de casos de uso, como capturar os requisitos que a implementação deve satisfazer.

O workflow de Análise e Projeto descreve como desenvolver o modelo de projeto. O modelo de projeto representa o plano para a implementação e é a entrada primordial para o workflow de Implementação.

O workflow de Teste descreve como serão feitos os testes de integração dos builds durante a integração do sistema. Ele também descreve como testar o sistema para verificar se todos os requisitos são satisfeitos, e ainda como os defeitos são detectados e submetidos.

O workflow de Ambiente descreve como desenvolver e manter artefatos de suporte que são usados durante a implementação, como a descrição do processo, os guidelines de projeto e os guidelines de programação.

O workflow de Deployment descreve como usar o modelo de implementação para produzir e entregar o código ao cliente final.

O workflow de Gerenciamento de Projeto descreve como planejar melhor o projeto. Aspectos importantes do processo de planejamento são o plano de iteração, o gerenciamento de mudanças e os sistemas de rastreamento de defeitos.

Atividades

Artefatos

T@rgetTrust Treinamento e Tecnologia 13

Page 78: RUP Apostila v12

Core Workflows

Teste

Proposta

As propostas deste workflow são:

Verificar a interação entre os objetos.

Verificar a integração apropriade de todos os componentes do software.

Verificar se todos os requisitos foram corretamente implementados.

Identificar e assegurar que os defeitos encontrados serão endereçados antes do software ser colocado em uso.

Em muitas organizações, o teste de software responde de 30% a 50% dos custos de desenvolvimento de software. Ainda assim muitas pessoas acreditam que o software não é bem testado antes de ser entregue. Esta

T@rgetTrust Treinamento e Tecnologia 14

Page 79: RUP Apostila v12

Core Workflows

contraição é baseada em dois fatos claros. Primeiro, testar software é extremamente difícil. As maneiras diferentes de que um dado programa pode se comportar não são quantificáveis. Segundo, o teste é feito usualmente sem uma metodologia clara e sem automatização e sem ferramenta de suporte. Apesar da complexidade do software tornar o teste completo uma meta impossível, uma metodologia bem concebida aliada ao uso de ferramentas avançadas, podem melhorar enormemente a produtividade e a eficiência no teste de software.

Para sistemas de segurança crítica, onde uma falha pode causar danos a pessoas (como controle de tráfego aéreo, controle de mísseis ou sistemas médicos), software de alta qualidade é essencial para o sucesso do sistema produzido. Para um sistema de informações gerenciais típico, esta situação não é tão 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, vão reduzir significativamente o custo de completar e manter o software. Também reduzirão grandemente os riscos ou obrigações associadas ao colocar em uso software de baixa qualidade, assim como baixa produtividade dos usuários, entrada de dados e erros de cálculo e comportamento funcional inaceitável. Nos dias atuais, muitos sistemas MIS são de sistemas de “missão crítica”, ou seja, as companhias não podem desempenhar satisfatóriamente suas funções e experimentam grandes prejuízos quando uma falha ocorre. Por exemplo: bancos ou companhias de transporte. Sistema de Missão-crítica devem ser testados usando as mesmas abordagens rigorosas usadas por sistemas de segurança crítica.

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 identificação dos testes a executar.

O workflow de Análise e Projeto descreve como desenvolver um projeto, este é uma outra das entradas principais para identificar quais testes serão executados.

O workflow de Implementação produz os builds do modelo de implementação que são testados pelo workflow de Teste. Dentro de uma iteração existem vários builds sendo testados, primeiro quando o sistema é integrado e no fim para testar todo o sistema.

O workflow de Ambiente desenvolve e mantém os artefatos de suporte que são usados durante o teste, como as Guidelines de Teste.

O workflow de Gerenciamento de Projeto planeja o projeto e cada iteração (descrito no Plano da Iteração)

T@rgetTrust Treinamento e Tecnologia 15

Page 80: RUP Apostila v12

Core Workflows

Atividades

Artefatos

T@rgetTrust Treinamento e Tecnologia 16

Page 81: RUP Apostila v12

Core Workflows

Deployment (Entrega)

Proposta

O workflow de Deployment (Entrega) descreve as atividades associadas em assegurar que o produto de software esteja disponível para seus usários finais.

T@rgetTrust Treinamento e Tecnologia 17

Page 82: RUP Apostila v12

Core Workflows

O workflow de Deployment descreve três modos de “deployment” de produto:

Instalação customizada

Oferta do produto “empacotado”

Acesso ao software pela internet

Em cada instância, 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 colocação em uso.

Relacionamento com outros workflows

O workflow de “Deployment” é relacionado com outros workflows, conforme segue:

O workflow de Requisitos produz a Especificação de Requisitos do Software que consiste do modelo de casos de uso e dos requisitos não funcionais. Em conjunto com o Protótipo de Interface com o Usuário, a Especificação de Requisitos do Software é uma das entradas chave para o desenvolvimento dos Materiais de Suporte ao Usuário Final e aos Materiais de Treinamneto.

Teste é uma parte indispensável do “deployment” e os artefatos essenciais do workflow de Teste são: o Modelo de Testes, os Resultados dos Testes e as atividades de gerenciamento, execução e avaliação dos testes.

O Gerenciamento de Configuração e Mudanças é referenciado para prover o build estabelecido e a release do produto e os mecanismos para lidar com as Requisições de Mudança que são geradas como resultado dos beta-testes e dos testes de aceitação.

No workflow de Gerenciamento de Projeto, as atividades para desenvolver um Plano de Iteração e um Plano de Desenvolvimento de Software irão influenciar no desenvolvimento do Plano de Entrega (Deployment Plan). Ainda, o trabalho para produzir o Plano de Aceitação do Produto tem de ser coordenado da mesma forma como você gerencia os testes de aceitação no workflow de Deployment.

O workflow de Ambiente provê suporte ao ambiente de testes.

T@rgetTrust Treinamento e Tecnologia 18

Page 83: RUP Apostila v12

Core Workflows

Atividades

Artefatos

T@rgetTrust Treinamento e Tecnologia 19

Page 84: RUP Apostila v12

Core Workflows

Gerenciamento de Configuração e Mudanças

Introdução

Parafraseando o SEI CMM (Software Engineering Institute's Capability Maturity Model), Gerenciamento de Configuração e Mudança controlam alterações e mantém a integridade dos artefatos do projeto.

T@rgetTrust Treinamento e Tecnologia 20

Page 85: RUP Apostila v12

Core Workflows

Gerenciamento de Configuração e de Requisições de Mudança (CM e CRM) envolve:

Identificar items de configuração,

Restringir mudanças a esses items

Auditar mudanças feitas a esses items, e

Definir e gerenciar as configurações destes items.

Os métodos, processos e ferramentas usadas para prover gerenciamento de configuração e mudanças para uma organização é chamado de Sistema de CM da organização.

O Sistema de Gerenciamento de Configuração e Requisições de Mudança de uma organização (Sistema de CM) tem as informações chave sobre os processos de desenvolvimento de produtos, promoções, distribuição e manutenção e retém a base ativa de artefatos potencialmente reutilizáveis resultantes da execução 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 confusões e assegura que os artefatos resultantes não são conflitantes devido a alguns dos seguintes tipos de problemas:T@rgetTrust Treinamento e Tecnologia 21

Page 86: RUP Apostila v12

Core Workflows

Atualizações simultâneas

Notificações limitadas

Múltiplas versões

Um Sistema de CM é útil para gerenciar variações múltiplas de sistemas de software evolutivos, acompanhando que versões são usadas em determinado “build” do software, realizando build de programas individuais ou de releases inteiras de acordo com as especificações de versão definidas pelo usuário e reforçando políticas específicas de desenvolvimento.

Alguns dos benefícios diretos produzidos por um Sistema de CM são:

Suporta os métodos de desenvolvimento,

Manutém da integridade do produto,

Assegura completude e correção do produto configurado,

Provê um ambiente estável dentro do qual se desenvolve o produto,

Restringe mudanças aos artefatos baseado nas políticas 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 verão particular (e quando, e porque), que versões de que fontes foram para um build particular e outras informações relevantes.

Relacionamento com outros core workflows

O Sistema de CM de uma organização é usado ao longo de todo o ciclo de vida do produto, da início até a colocação em uso. Como um repositório de ativos de uma organização, o Sistema de CM contém versões atuais e históricos dos arquivos fontes, de artefatos de equisitos, projeto e implentação que definem uma versão particular de um sistema ou de um componente.

A Estrutura de Diretórios do Produto, representada no Sistema de CM, contém todos os artefatos requeridos para implementar o produto. Desta forma, o workflow de Gerenciamento de Configuração e Mudanças (CCM) é relacionado com todos os outros workflows do processo e serve como repositório para seus conjuntos resultantes de artefatos.

T@rgetTrust Treinamento e Tecnologia 22

Page 87: RUP Apostila v12

Core Workflows

Atividades

Artefatos

T@rgetTrust Treinamento e Tecnologia 23

Page 88: RUP Apostila v12

Core Workflows

Gerenciamento de Projeto

Introdução

Gerenciamento de Projeto de Software é a arte de balancear objetivos conflitantes, gerenciar risco e superar restrições para entregar com sucesso um produto que vá ao encontro das necessidades tanto dos clientes (os que pagam a conta) como dos usuários. O fato de tão poucos projetos serem sucessos indiscutíveis é comentário suficiente sobre a dificuldade da tarefa.

Proposta

A proposta do Gerenciamento de Projeto é:

Prover os princípios básicos para gerenciamento de projetos de software intensivo

T@rgetTrust Treinamento e Tecnologia 24

Page 89: RUP Apostila v12

Core Workflows

Prover guias práticos para planejamento, controle de pessoa, execução e monitoramento de projetos.

Prover os princípios básicos para o gerenciamento de riscos

Entretanto, este workflow do RUP não tenciona cobrir todos os aspectos do gerencimento de projetos. Por exemplo, ele não cobre questões como:

Gerenciamento de pessoal: contratação, treinamento e “coaching”.

Gerenciamento de orçamento: definição, alocação, 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 iteração particular

Monitoramento do progresso de um projeto iterativo e métricas

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 são utilizados como parte do trabalho do projeto.

Atividades

T@rgetTrust Treinamento e Tecnologia 25

Page 90: RUP Apostila v12

Core Workflows

Artefatos

T@rgetTrust Treinamento e Tecnologia 26

Page 91: RUP Apostila v12

Core Workflows

Ambiente (Environment)

Proposta

O workflow de Environment (Ambiente) foca nas atividades necessárias 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 organização desenvolvedora de software com um ambiente de desenvolvimento de software completo – ambos, processos e ferramentas – que irão 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.

T@rgetTrust Treinamento e Tecnologia 27

Page 92: RUP Apostila v12

Core Workflows

Atividades

T@rgetTrust Treinamento e Tecnologia 28

Page 93: RUP Apostila v12

Core Workflows

Artefatos

T@rgetTrust Treinamento e Tecnologia 29

Page 94: RUP Apostila v12

Core Workflows

Exercícios

T@rgetTrust Treinamento e Tecnologia 30

Page 95: RUP Apostila v12

Core Workflows

Espaço para anotações

T@rgetTrust Treinamento e Tecnologia 31

Page 96: RUP Apostila v12

RUP

4.4. Papéis e AtividadesPapéis e Atividades

T@rgetTrust Treinamento e Tecnologia 1

Page 97: RUP Apostila v12

Papéis e Atividades

Objetivos

Conhecer os papéis do RUP

Conhecer as atividades associadas a cada papel

T@rgetTrust Treinamento e Tecnologia 2

Page 98: RUP Apostila v12

Papéis e Atividades

Analistas

O conjunto de papéis de análise inclui os papéis envolvidos primordialmente em elencar e investigar requisitos.

Analista de Processos de Negócio

O Analista de Processos de Negócio lidera e coordena a modelagem de casos de uso de negócio enfatizando os pontos essenciais e delimitando a organização que está sendo modelada. Por exemplo, estabelecendo quais são os atores de negócio e os casos de uso de negócio e como eles interagem.

Atividades

Desenvolver os Guidelines para a Modelagem de Negócio

o Desenvolver os Guidelines para a Modelagem de Negócio

Avaliar a Organização Alvo

o Descrever o “status” da organização na qual a aplicação será colocada em uso, em termos de seus processos correntes, ferramentas, compentências pessoais, atitudes pessoais, clientes, competidores, tendências técnicas, problemas e áreas de melhoria.

o Motivar por que a organização alvo deve ser melhorada.

o Identificar envolvidos (stakeholders) para o esforço de modelagem de negócio.

Capturar um Vocabulário de Negócios Comum

T@rgetTrust Treinamento e Tecnologia 3

Page 99: RUP Apostila v12

Papéis e Atividades

o Definir um vocabulário comum que possa ser usado em todas as descrições textuais do negócio, especialmente em descrições de casos de uso de negócio.

Definir e Ajustar Metas

o Definir os limites para o esforço de modelagem de negócio.

o Desenvolver uma visão de futuro para a organização alvo

o Obter concordância quanto as melhorias potenciais e as novas metas para a organização alvo.

o Descrever os objetivos primordiais para a organização alvo.

Definir a Arquitetura do Negócio

o Definir a arquitetura para o negócio.

o Definir os padrões de negocio, mecanismos chave e convenções de modelagem para o negócio.

Manter Regras de Negócio

o Determinar quais regras de negócio considerar no projeto.

o Dar definições detalhadas as regras de negócio.

Encontrar os Atores e os Casos de Uso de Negócio

o Destacar os pontos essenciais dos processos de negócio.

o Definir os limites do negócio a ser modelado.

o Definir quem e o quê vai interagir com o negócio.

o Criar diagramas do modelo de casos de uso de negócio.

o Desenvolver uma visão geral do modelo de casos de uso de negócio.

Estruturar o Modelo de Casos de Uso de Negócio

o Extrair o comportamento nos casos de uso de negócio que podem ser considerados como casos de uso de negócio abstratos. Exemplos deste comportamento são comportamentos comuns, comportamentos opcionais e comportamento que será desenvolvido em iterações posteriores.

o Encontrar atores de negócio abstratos que definem papéis que são compartilhados por vários atores de negócio.

Projetista de Negócio

O papel de Projetista de Negócio detalha a especificação de parte da organização descrevendo o fluxo de um ou mais casos de uso de negócio. Este papel especifica os trabalhadores do negócio e as entidades de negócio necessárias para a realização de um caso de uso de negócio e distribui o comportamento dos casos de uso de negócio. O Projetista de Negócio define

T@rgetTrust Treinamento e Tecnologia 4

Page 100: RUP Apostila v12

Papéis e Atividades

as responsabilidades, operações, atributos e relacionamentos de um ou vários trabalhadores e entidades do negócio.

Atividades

Detalhar um Caso de Uso de Negócio

o Descrever o workflow do caso de uso de negócio em detalhes.

o Descrever o workflow do caso de uso de negócio de forma que o cliente, usuário e envolvidos possam entende-lo.

Encontrar Trabalhadores e Entidades do Negócio

o Identificar todos os “papéis” e “coisas” no negócio

o Descrever como as realizações dos casos de uso de negócio são executadas pelos trabalhadores e entidadoes do negócio.

Detalhar um Trabalhador de Negócio

o Detalhar as responsabilidades de um trabalhador do negócio.

Detalhar uma Entidade de Negócio

o Detalhar a definição de uma entidade de negócio.

Definir os Requisitos de Automação

o Entender como novas tecnologias podem ser usadas para tornar a organização alvo mais eficiente.

o Determinar o nível de automação na organização alvo.

o Derivar os requisitos de sistema a partir dos artefatos de modelagem de negócio.

Revisor de Modelo de Negócio

O Revisor do Modelo de Negócio participal nas revisões formais do modelo de caso de usos de negócio e o modelo de objetos de negócio.

T@rgetTrust Treinamento e Tecnologia 5

Page 101: RUP Apostila v12

Papéis e Atividades

Atividades

Revisar o Modelo de Casos de Uso de Negócio

o Verificar formalmente que os resultados da modelagem de casos de uso de negócio estão de acordo com a visão de negócio dos stakeholders.

Revisar o Modelo de Objetos de Negócio

o Verificar formalmente que os resultados da modelagem dos objetos de negócio estão de acordo com a visão de negócio dos stakeholders.

Revisor de Requisitos

O Revisor de Requisitos planeja e conduz a revisão formal do modelo de casos de uso.

Atividades:

Revisar Requisitos

o Verificar formalmente que os resultados dos Requisitos estão de acordo com a visão 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.

T@rgetTrust Treinamento e Tecnologia 6

Page 102: RUP Apostila v12

Papéis e Atividades

Atividades:

Desenvolver o Plano de Gerenciamento de Requisitos

o Desenvolver um plano para documentar os requisitos, atributos e padrões 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 Vocabulário Comum

o Definir um vocabulário comum que pode ser usado em todoas as descrições textuais do sistema, especialmente nas descrições dos casos de uso.

Esclarecer as Requisições dos Envolvidos

o Entender quem são os envolvidos no projeto

o Coletar as requisições que o sistema precisa satisfazer

o Priorizar as requisições dos envolvidos

Desenvolver a Visão

o Obter concordância 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.

T@rgetTrust Treinamento e Tecnologia 7

Page 103: RUP Apostila v12

Papéis e Atividades

o Criar diagramas do modelo de casos de uso.

o Desenvolver uma visão 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 serão desenvolvidos em iterações posteriores.

o Encontrar novos atores abstratos que definem papéis que são compartilhados por vários atores.

Gerenciar Dependências

o Usar atributos e rastreabilidade dos requisitos do projeto para auxiliar no gerenciamento do escopo do projeto e gerenciamento de mudanças em requisitos.

Especificador de Requisitos

O papel de Especificador de Requisitos detalha a especificação 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 também ser responsável por um pacote de casos de uso e pela manutenção da integridade deste pacote. É recomendado que o Especificador de requisitos responsável por um pacote de casos de uso seja também responsável 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 usuários possam entendê-lo.

Detalhar os Requisitos de Software

T@rgetTrust Treinamento e Tecnologia 8

Page 104: RUP Apostila v12

Papéis 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 Usuário

O Projetista de Interface com o Usuário lidera e coordena a prototipação e projeto da interface do usuário:

Capturanto requisitos na interface do usuário, incluindo requisitdos de usabilidade.

Construindo protótipos de interface de usuário.

Envolvendo outros stakeholders de interface de usuário, como usuários finais em revisões de usabilidade e sessões de teste de uso.

Revisando e produzindo feedback apropriado na implementação final da interface de usuário, criada pelos outros desenvolvedores, ou seja, projetistas e implementadores.

Atividades

Modelar a Interface de Usuário

o Construir um modelo de interface de usuário que auxilia e possibilita a melhoria em sua usabilidade

Prototipar a Interface do Usuário

o Criar um protótipo da interface do usuário

Desenvolver os guidelenes para Interface de Usuário

o Desenvolver os guidelenes para Interface de Usuário

T@rgetTrust Treinamento e Tecnologia 9

Page 105: RUP Apostila v12

Papéis e Atividades

Desenvolvedores

O conjunto de papéis de Desenvolvedores organiza os papéis envolvidos primordialmente em projetar e desenvolver o software.

Arquiteto de Software

O papel Arquiteto de Software lidera e coordena as atividades e artefatos técnicos ao longo do projeto. O Arquiteto de Software estabelece a estrutura geral para cada visão arquitetural: a decomposição das views, o agrupamento dos elementos e as interfaces entre os grupos principais. Desta forma, em contraste aos outros papéis, a visão do Arquiteto de Software é mais abrangente do que aprofundada.

Atividades

Priorizar os Casos de Uso

o Definir entradas para a seleção do conjunto de cenários e casos de uso que serão analisados na iteração corrente.

o Definir o conjunto de cenários e casos de uso que representam as funcionalidades mais significativas.

o Definir o conjunto de cenários e casos de uso que tem cobertura arquitetural substancial (que irão exercitar muitos elementos arquiteturais) ou que estressam ou ilustram algum ponto específico ou delicado da arquitetura.

Análise da Arquitetura

T@rgetTrust Treinamento e Tecnologia 10

Page 106: RUP Apostila v12

Papéis e Atividades

o Definir uma arquitetura candidata para o sistema, baseada na experiência em sistemas similares ou em domínios de problemas similares.

o Definir os padrões arquiteturais, mecanismos chave e convenções de modelagem para o sistema.

o Definir a estratégia para reuso

o Produzir entrada para o processo de planejamento

Identificar os Mecanismos de Projeto

o Refinar os mecanismos de análise em mecanismos de projeto baseado nas restrições impostas pelo ambiente de implementação.

Identificar os Elementos de Projeto

o Analisar interações das classes de análise para identificar os elementos do modelo de projeto

Incorporar Elementos de Projeto Existentes

o Analisar interações das classes de análise para encontrar interfaces, classes de projeto e subsistemas de projeto.

o Refinar a arquitetura, incorporanto reuso onde for possível.

o Identificar soluções padrão 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 Distribuição

o Descrever como a funcionalidade do sistema é distribuída pelos nós físicos. Necessário apenas para sistemas distribuídos.

Descrever a Arquitetura de Execução

o Analisar os requisitos de concorrência, identificar processos, identificar mecanismos de comunicação inter-processo, alocar recursos de coordenação inter-processo, identificar os ciclos de vida dos processos e distribuir os elementos do modelo entre os processos.

Estruturar o Modelo de Implementação

o Estabelecer a estrutura na qual a implementação vai residir.

o Estabelecer responsabilidades para Subsistemas de Implementação e seu elementos.

Desenvolver as Guidelines de Projeto

o Desenvolver as Guidelines de Projeto

Desenvolver as Guidelines de Programação

o Desenvolver as Guidelines de ProgramaçãoT@rgetTrust Treinamento e Tecnologia 11

Page 107: RUP Apostila v12

Papéis e Atividades

Construir uma Prova de Conceito Arquitetural

o Sintetizar pelo menos uma solução (que pode ser simplesmente conceitual) que satisfaça os requisitos arquiteturais críticos.

Avaliar a Viabilidade da Prova de Conceito Arquitetural

o Avaliar a Prova de Conceito Arquitetural sintetizada para determinar se os requisitos arquiteturais críticos são factíveis e podem ser satisfeitos (por essa ou outra solução).

Revisor de Arquitetura

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

Atividades

Revisar a Arquitetura

o Descobrir riscos desconhecidos ou percebidos ao cronograma ou orçamento.

o Detectar falhas no projeto arquitetural. Falhas arquiteturais são conhecidas como difíceis 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 avaliação deve examinar alguns aspectos frequentemente negligenciados nas áreas de operação, administração e manutençã. Como o sistema é instalado? Atualizado? Como será feita a transição a partir dos bancos de dados atuais?

o Avaliar uma ou mais qualidades arquiteturais específicas: performance, confiabilidade, modificabilidade, segurança.

o Identificar oportunidades de reuso.

Projetista de Cápsulas (Capsule Designer)

O papel de Projetista de Cápsulas foca em assegurar que o sistema possa responder a eventos temporais, de acordo com os requisitos de concorrência. O veículo primoridial para resolver estes problemas é o Artefato: Cápsula.

T@rgetTrust Treinamento e Tecnologia 12

Page 108: RUP Apostila v12

Papéis e Atividades

Atividades

Projetar Cápsulas

o Elaborar e refinar as descrições de cápsulas.

Revisor de Código

O papel do Revisor de Código é assegurar a qualidade do código fonte e planejar e conduzir as revisões de códigos fonte. O Revisor de Código é também responsável por dar feedback de qualquer retrabalho que possa resultar das atividades de revisão.

Revisar Código

o Verificar os códigos 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 parâmetros de storage e outras contruções específicas de banco de dados necessárias para o armazenamento, recuperação e exclusão dos objetos persistentes. Esta informação é mantida no artefato: Modelo de Dados.

Atividades

Projeto de Banco de Dados

T@rgetTrust Treinamento e Tecnologia 13

Page 109: RUP Apostila v12

Papéis e Atividades

o Assegurar que os dados persistentes são 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 revisões 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 implementação.

o Assegurar que o modelo de projeto é consistente com as guidelines gerais do projeto.

o Assegurar que as guidelines de projeto satisfazem seus objetivos.

Projetista

O papel do Projetista é definir as responsabilidades, operações, atributos e relacionamentos das classes e determinar como elas serão ajustadas ao ambiente de implementação. Adicionalmente, o Projetista pode ser responsável por pacotes de projeto, ou subsistemas de projeto, incluindo as classes contidas nesses pacotes e subsistemas.

T@rgetTrust Treinamento e Tecnologia 14

Page 110: RUP Apostila v12

Papéis e Atividades

Atividades

Projeto de Classes

o Assegurar que a classe prove o comportamento que a realização do caso de uso requer.

o Assegurar que informação suficiente é provida para a implemtação da classe sem ambigüidades.

o Lidar com os requisitos não 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 colaboração das classes contidas.

o Documentar a estrutura interna do subsistema.

o Definir realizações entre a interface do subsistema e as classes contidas nele.

o Determinar as dependências com outros subsistemas.

Análise 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 realizações do caso de uso.

o Identificar responsabilidades, atributos e associações das classes.

o Observar o uso dos mecanismos arquiteturais.

Projeto de Casos de Uso

o Refinar as realizações dos casos de uso em termos de interações.

T@rgetTrust Treinamento e Tecnologia 15

Page 111: RUP Apostila v12

Papéis e Atividades

o Refinar os requisitos sobre as operações das classes de projeto.

o Refinar os requisitos sobre as operações dos subsistemas e/ou suas interfaces.

o Refinar os requisitos sobre as operações das cápsulas.

Projetar Testes de Pacotes e Classes

o Projetar funcionalidades específicas de teste.

Implementador

O papel Implementador é responsável por desenvolver e testar componentes, de acordo com os padrões de projeto adotados, para integração em subsistemas maiores. Quando componentes de teste, como drivers ou stubs, precisam ser criados para suportar teste, o implementador também é responsável por desenvolver e testar os componentes de teste e os subsistemas correspondentes.

Atividades

Implementar Componentes

o Produzir código fonte de acordo com o modelo de projeto.

Consertar Defeitos

o Consertar defeitos

Executor Testes de Unidade

o Verificar a especificação de uma unidade.

o Verificar a estrutura interna de uma unidade.

Implementar Componentes e Subsistemas de Teste

o Implementar funcionalidades específicas de teste

Desenvolver Artefatos de Instalação

T@rgetTrust Treinamento e Tecnologia 16

Page 112: RUP Apostila v12

Papéis e Atividades

o Produzir todo o software requerido para instalar e desinstalar o produto de forma rápida, fácil e segura sem afetar outras aplicações ou características do sistema.

Integrador

Implementadores entregam seus componentes testados em um espaço de trabalho para integração, esses componentes serão combinados pelos Integradores para produzir um “build”. Um Integrador é também responsável por planejar a integração, que terá lugar nos nívels de sistema e subsistemas, onde cada um tem um espaço de integração separado.

Atividades

Planejar a Integração de Subsistemas

o Planejar a ordem na qual os componentes contidos em um subsistema de implementação devem ser integrados.

Criar os Workspaces de Integração

o O workspace de Integração é similar aos workspaces privados dos implementadores, onde os indivíduos podem desenvolver e mudar código. O workspace de Integração é 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 são capturados e arquivados, em dados pontos no tempo, como base para o desenvolvimento posterior do produto.

Planejar a Integração do Sistema

o Planejar a integração do sistema

Integrar Subsistemas

T@rgetTrust Treinamento e Tecnologia 17

Page 113: RUP Apostila v12

Papéis e Atividades

o Integrar os componentes em um subsistema de implementação e então entregar o subsistema para a Integração de Sistema.

Integrar o Sistema

o Integrar os subsistemas de implementação em um build.

Promover Baselines

o A proposta desta atividade é assegurar que baselines (componentes testados individualmento de vários implementadores e times de desenvolvimento combinados para funcionar como produto) estão rotuladas (tagged) para refletir o nível do software em maturidade, estabilidade e qualidade que foi atingido.

Verificar Mudanças no Build

o A proposta de ter um processo padrão e documentado de controle de mudanças é assegurar que mudanças são feitas em um projeto de forma consistente e os stakeholders apropriados são informados do estado do produto, mudanças feitas e o impacto em custo e cronograma dessas mudanças.

T@rgetTrust Treinamento e Tecnologia 18

Page 114: RUP Apostila v12

Papéis e Atividades

Testadores

O conjunto de Testadores organiza os papéis envolvidos primordialmente no teste de software.

Testador

O testador é responsável por:

Preparar e executar testes

Avaliar a execução dos testes

Recuperação 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 é responsável pelo planejamento, projeto, implentação e avaliação do teste, incluindo:

Geração do plano de teste e do modelo de testes

Implementação dos procedimentos de teste

Avaliação da cobertura, dos resultdados e da eficácia dos testes

Geração do resumo dos testes de avaliação

T@rgetTrust Treinamento e Tecnologia 19

Page 115: RUP Apostila v12

Papéis e Atividades

Atividades

Planejar Testes

o Coletar e organizar a informação de planejamento de testes

o Criar o plano de testes.

Projetar Testes

o Identificar um conjunto de testes verificáveis para cada build.

o Identificar procedimentos de teste que mostram como os casos de teste serão realizados.

Implementar Testes

o Criar ou gerar scripts de testes reutilizáveis

o Manter a rastreabilidade dos artefatos de implementação 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 requisições de mudança

o Calcular e entregar as medições dos testes.

o Gerar o resumo dos testes de avaliação.

Desenvolver os Guidelines de Teste

o Desenvolver os Guidelines de Teste

T@rgetTrust Treinamento e Tecnologia 20

Page 116: RUP Apostila v12

Papéis e Atividades

Gerentes

O conjunto de Gerentes organiza os papéis envolvidos primordialmente em gerenciamento e configuração do processo de engenharia de software.

Gerente de Controle de Mudanças

O papel de Gerente de Controle de Mudanças supervisiona o processo de controle de mudanças. Este papel é geralmente realizado por um Comitê de Controle de Configuração (ou Mudança) e consiste de representantes de todas as partes interessadas, incluindo clientes, desenvolvedores e usuários. 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 Mudanças é também responsável por definir o Processo de Gerenciamento de Requisições de Mudança, que é documentado no Plano de Gerencia de Configuração (CM Plan).

Atividades

Estabelecer o Processo de Controle de Mudanças

Revisar Requisições de Mudança

o A proposta de ter processos de controle de mudanças padronizados e documentados é assegurar que as mudanças são feitas em um projeto de forma consistente e que os stakeholders apropriados são informados do estado do produto, mudanças e o impacto destas no custo e no cronograma.

Confirmar Requisições de Mudanças Duplicadas ou Rejeitadas

o Um administrador designado pelo Comitê deve ser alocado para confirmar requisições de mudança duplicadas ou inválidas.

T@rgetTrust Treinamento e Tecnologia 21

Page 117: RUP Apostila v12

Papéis e Atividades

Gerente de Configuração

O Gerente de Configuração provê toda a infraestrutura e ambiente de Gerencia de Configuração (CM) para o time de desenvolvimento do produto. A função 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 disponíveis para inclusão na unidade de deploy quando necessário. O Gerente de configuração também deve assegurar que o ambiente de CM facilite a revisão do produto e as atividades de mudança e rastreabilidade de defeitos. O Gerente de Configuração também é responsável por escrever o Plano de CM e reportar estatísticas de progresso baseadas em requisições de mudanças.

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 Configuração

o A proposta desta atividade é estabelecer um ambiente onde o produto possa ser desenvolvido e construído. 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 alocação de recursos de máquina (servidores e espaço em disco) e instalação das ferramentas de gerenciamento de configuração.

o Preparar o ambiente de desenvolvimento envolve criação de repositórios, preparar a estrutura de diretórios do produto e importar arquivos existentes. O ambiente inicial serve como base para o trabalho de desenvolvimento posterior.

Realizar Auditoria de Configuração

T@rgetTrust Treinamento e Tecnologia 22

Page 118: RUP Apostila v12

Papéis e Atividades

o Determinar que uma baseline contém 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 coleção de componentes executável), documentos (material de suporte ao usuário final e notas de versão) e artefatos de instalação. A proposta desta atividade é criar uma unidade de deployment que é suficientemente completa para ser obtida, instalada e possa rodar.

Relatar Status de Configuração

o Suportar as atividades de Relato de Status de Configuração que são baseadas em registros formalizados e relatórios de status de mudanças propostas e status de implementação de mudanças propostas.

o Facilitar a revisão do produto através do acompanhamento de defeitos e atividades de relatórios.

o Assegurar que os dados são distribuídos e relatados para acompanhamento de progresso.

Escrever o Plando de Gerenciamento de Configuração (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 transição do produto para a comunidade usuária.

Desenvolver o Plano de DeploymentT@rgetTrust Treinamento e Tecnologia 23

Page 119: RUP Apostila v12

Papéis e Atividades

o O plano de Deployment documenta como e quando o produto deve ser disponibilizado para a comunidade usuária.

Definir a Lista de Materiais

o Criar uma lista completa de artefatos que compõe um build/pdoruto. A lista inclui itens de configuração do software, documentos e scripts de instalação. No caso de produtos empacotados a Lista de Matérias precisa identificar as peças de arte final e os itens do pacote que compõe o produto final.

Controlar os Testes de Aceitação

o Assegurar que o produto desenvolvido satisfaz os critérios de aceitação tanto nos sites de desenvolvimento quanto em produção

Controlar os Testes Beta

o Um testes Beta é um teste de “pré-release” no qual uma amostragem do público 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 próxima release. O Gerente de Deployment precisa gerenciar o programa de beta testes do produto para assegurar que ambas as propostas serão seguidas.

Escrever as Notas de Versão

o Descrever as principais mudanças e funcionalidades novas na verão. As Notas de Versão devem também descrever os problemas conhecidos e limitações ou “workarounds” para o uso do produto.

Prover Acesso ao Site de Download

o Assegurar que o produto está disponível para compra e download na internet.

Liberar para a Manufatura

o Produção em massa da versão empacotada do produto.

Verificar o Produto Manufaturado

o Assegurar que o produto manufatorado está completo e utilizável. 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 é responsável pelo processo de desenvolvimento de software em si. Isto inclui a configuração do processo

T@rgetTrust Treinamento e Tecnologia 24

Page 120: RUP Apostila v12

Papéis e Atividades

antes do início do projeto e a melhoria contínua do processo durante os esforços de desenvolvimento.

Atividades

Avaliar a Organização

o Descrever o estado atual da organização de software em temos de seus processos correntes, ferramentas, competências pessoais, atitudes pessoais, clientes, competidores, tendências técnicas, problemas e áreas de melhoria.

Desenvolver Templates Específicos para o Projeto

o Desenvolver os templates para os documentos e relatórios 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 específico da organização.

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 interações com clientes e usuários e, de forma geral, manter o time do projeto focado nos objetivos corretos. O Gerente do Projeto também estabelece um conjunto de práticas que asseguram a integridade e qualidade dos artefatos do projeto.

T@rgetTrust Treinamento e Tecnologia 25

Page 121: RUP Apostila v12

Papéis e Atividades

Atividades

Desenvolver o Caso de Negócio

o Desenvolver a justificativa econômica para o produto.

Identificar e Avaliar Riscos

o Identificar, analisar e priorizar riscos para o projeto e determinar estratégias 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 critérios para medida de sucesso do projeto.

Definir os Processos de Monitoramento e Controle

o Definir as informações e os processos que serão usados para monitorar e controlar o progresso do projeto, qualidade e riscos.

T@rgetTrust Treinamento e Tecnologia 26

Page 122: RUP Apostila v12

Papéis e Atividades

Planejar Fases e Iterações

o Estimar o escopo, esforço 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 iterações dentro das fases do projeto e identificar os objetivos para cada uma das iterações.

o Desenvolver o cronograma e orçamento para o projeto.

o Desenvolver um plano de recursos para o projeto.

o Definir as atividades para a execução ordenada e completa do projeto.

Desenvolver um Plano de Métricas

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 Organização e o Pessoal do Projeto

o Definir uma uma estrutura organizacional para o projeto

o Baseado nas estimativas de esforço, definir os requisitos de “staff” – em termos de número, tipos e níveis de experiência – para a próxima iteração (com menos incertezas) e para iterações subseqüentes, com mais incertezas, para possibilitar o início 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 conteúdo para a publicação de um documento de Plano de Desenvolvimento de Software.

Desenvolver o Plano de Aceitação do Produto

o Criar um procedimento escrito em concordância 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 aceitação do produto serão resolvidos.

Desenvolver um Plano de Gerenciamento de Riscos

o Criar um plano documentado para identificar, analisar e priorizar riscos.

o Identificar as estratégias de gerenciamento de risco para os riscos mais significativos do projeto.

Desenvolver um Plano de Resolução de ProblemasT@rgetTrust Treinamento e Tecnologia 27

Page 123: RUP Apostila v12

Papéis e Atividades

o Criar um plano documentado provendo um procedimento definido para gerenciar e resolver problemas experimentados durante o projeto.

Desenvolver o Plano de Iteração

o Desenvolver um plano “fine-grained” para uma iteração, consistindo de:

Uma WBS (Work Breakdown Structure) detalhada das atividades e da associação de responsabilidades

Os “milestones” e “deliverables” dentro da iteração

Os critérios de avaliação para a iteração

Alocar Pessoal

o Comprometer os recursos humanos para o projeto

o Mapear os recursos disponíveis quanto as habilidades necessárias para o projeto.

o Agrupar os recursos disponíveis em times relativamente independentes, mas colaborativos.

Iniciar a Iteração

o Alocar pessoal e outros recursos para os pacotes de trabalho identificados para a iteração atual

Avaliar a Iteração

o Determinar o sucesso ou fracasso da iteração

o Capturar as lições 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 Revisão do Milestone.

Prepara para o Fechamento do Projeto

o Completar as formalidades associadas com a aceitação do projeto e fechamento, realocação de pessoal e transferência 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 mudanças aprovadas (defeitos, melhorias) ao produto e processo que aparecem durante uma iteração.

Relatar Status

o Prover atualizações regulares sobre o status do projeto para revisão pelas Autoridades de Revisão do Projeto (PRA).

T@rgetTrust Treinamento e Tecnologia 28

Page 124: RUP Apostila v12

Papéis e Atividades

o Escalar questões que vão além da autoridade do gerente de projeto para resolução pela PRA.

Lidar com Exceções e Problemas

o Iniciar ações corretivas apropriadas para problemas e exceções 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 é responsável pela avaliação dos artefatos de planejamento do projeto e pela avaliação dos artefatos nos pontos de revisão principais dentro do ciclo de vida do projeto. Estas são eventos de revisão 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

Revisão de Aprovação do Projeto

o Determinar, do ponto de vista de negócio, se o projeto vale o investimento.

Revisão do Planejamento do Projeto

o Aprovar o Plano de Desenvolvimento de Software Inicial

o Revisar e aprovar mudanças no Plano de Desenvolvimento de Software

Revisão do Plano de Iteração

o Aprovar o plano de trabalho proposto para a iteração atual.

Revisão do Projeto com a Autoridade de Revisão do Projeto (PRA)

o Revisar o progresso feito no projeto em conjunto com a PRA.

Revisão dos Critérios de Avaliação da Iteração

o Aprovar os critérios que serão usados para determinar se o trabalho completado durante a iteração atinge os objetivos.

Revisão de Aceitação da Iteração

T@rgetTrust Treinamento e Tecnologia 29

Page 125: RUP Apostila v12

Papéis e Atividades

o Aceitar formalmente o trabalho de uma iteração como completo.

Revisão do Lifecycle Milestone

o Revisar o estado do projeto no final de cada fase e determinar se o projeto deve prosseguir para a próxima fase.

Revisão de Aceitação do Projeto

Project Acceptance Review

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

T@rgetTrust Treinamento e Tecnologia 30

Page 126: RUP Apostila v12

Papéis e Atividades

Exercícios

T@rgetTrust Treinamento e Tecnologia 31

Page 127: RUP Apostila v12

Papéis e Atividades

Espaço para anotações

T@rgetTrust Treinamento e Tecnologia 32

Page 128: RUP Apostila v12

RUP

5.5. ArtefatosArtefatos

T@rgetTrust Treinamento e Tecnologia 1

Page 129: RUP Apostila v12

Artefatos

Objetivos

Apresentar uma visão geral dos artefatos do RUP

T@rgetTrust Treinamento e Tecnologia 2

Page 130: RUP Apostila v12

Artefatos

Modelagem de Negócio

O conjunto de Modelagem de Negócio apresenta os artefatos que capturam e representam o contexto de negócio do sistema. Os artefatos de Modelagem de Negócio servem como entrada e referência para os requisitos do sistema.

Ator de Negócio

Um Ator de Negócio representa um papel exercido na relação de negócio por alguém ou algo no ambiente de negócio.

Documento de Arquitetura de Negócio

O Documento de Arquitetura de Negócio provê uma visão geral compreensiva do negócio, usando diferentes visões arquiteturais para destacar diferentes aspectos do negócio.

Entidade de Negócio

Uma Entidade de Negócio é uma classe passiva, ou seja, ela não inicia interações por si só. Uma Entidade de Negócio pode participar em várias realizações de caso de uso diferentes e geralmente sobrevivem por uma única T@rgetTrust Treinamento e Tecnologia 3

Page 131: RUP Apostila v12

Artefatos

interação. Na modelagem de negócio, as entidades de negócio representam objetos que os trabalhadores do negócio acessam, inspecionam, manipulam, produzem e assim por diante. Objetos de entidade de negócio provêm a base de compartilhamento entre os trabalhadores do negócio participando em diferentes realizações de casos de uso de negócio.

Glossário de Negócio

O Glossário de Negócio define os termos importantes usados na parte de modelagem de negócio do projeto.

Modelo de Objetos de Negócio

O Modelo de Objetos de Negócio é um modelo de objetos descrevendo a realização dos casos de uso de negócio.

Regras de Negócio

Regras de Negócio são declarações de políticas ou condições que devem ser satisfeitas.

Caso de Uso de Negócio

Um Caso de Uso de Negócio (Classe) define um conjunto de instancias de casos de uso de negócio, onde cada instancia é uma seqüência de ações executadas que resultam em resultados observáveis para um Ator de Negócio em particular.

Modelo de Casos de Uso de Negócio

O Modelo de Casos de Uso de Negócio é um modelo das funções de negócio desejadas. O Modelo de Casos de Uso de Negócio é usado como entrada essencial para identificar papéis e “deliverables” da organização.

T@rgetTrust Treinamento e Tecnologia 4

Page 132: RUP Apostila v12

Artefatos

Realização de Caso de Uso de Negócio

Uma Realização de Caso de Uso de Negócio descreve como um caso de uso de negócio em particular é realizado dentro do modelo de objetos de negócio, em termos de colaboração de objetos (instancias de trabalhadores do negócio e entidades do negócio).

Visão do Negócio

A Visão do Negócio define o conjunto de metas e objetivos a serem alcançadas pelo esforço de modelagem de negócio.

Trabalhador do Negócio

Um trabalhador do negócio é uma classe que representa uma abstração de uma pessoa que age no sistema. Um trabalhador do negócio interage com outros trabalhadores de negócio e manipula entidades de negócio enquanto participa em realizações de casos de uso de negócio.

Unidade Organizacional

Uma unidade organizacional é uma coleção de trabalhadores do negócio, entidades de negócio, relacionamentos, realizações de casos de uso de negócio, diagramas e outras unidades organizacionais. É usada para estruturar o modelo de objetos de negócio pela sua divisão em partes menores.

Especificação de Negócio Suplementar

Este documento apresenta as definições necessárias de negócio que não estão incluídas no modelo de casos de uso de negócio nem no modelo de objetos de negócio.

Avaliação da Organização Alvo

A avaliação da Organização Alvo descreve o status corrente da organização na qual o sistema será colocado em uso. A descrição em termos de processos atuais, ferramentas, competências pessoais, atitudes pessoais, clientes, competidores, tendências técnicas, problemas e áreas de melhoria.T@rgetTrust Treinamento e Tecnologia 5

Page 133: RUP Apostila v12

Artefatos

Requisitos

O conjunto de artefatos de Requisitos captura e apresenta a informação usada na definição das capacidades requeridas para o sistema.

Ator

Um ator define um conjunto coerente de papéis que os usuários 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 interação entre um ou mais atores e o sistema.

Glossário

O Glossário define termos importantes usados no projeto.

T@rgetTrust Treinamento e Tecnologia 6

Page 134: RUP Apostila v12

Artefatos

Atributos de Requisitos

Este artefato contém um repositório de requisitos do projeto, atributos e dependências que devem ser acompanhadas na perspectiva de gerenciamento de requisitos.

Plano de Gerência dos Requisitos

Descreve a documentação dos requisitos, os tipos de requisitos e seus respectivos atributos, especificando as informações e mecanismos de controle que devem ser coletados e usados para medição, relatórios e controle de mudanças aos requisitos do produto.

Solicitações dos Envolvidos

Este artefato contém qualquer tipo de requisição que um envolvido (cliente, usuário final, pessoal do marketing e assim por diante) pode ter para o sistema a ser desenvolvido. Deve também conter referências para recursos externos com os quais o sistema deve ser compatível.

Especificação de Requisitos de Software

A Espeficicação de Requisitos de Software captura os requisitos completos de software para o sistema ou para uma porção 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 Especificações Suplementares aplicáveis.

Especificações Suplementares

As Especificações Suplementares capturam os requisitos do sistema que não foram completamente capturadas pelos casos de uso e o modelo de casos de uso. Tais requisitos incluem:

Requisitos legais, regulamentos e normas aplicáveis.

Atributos de qualidade do sistema a ser construído, incluindo requisitos de usabilidade, confiabilidade, performance e estabilidade.

Outros requisitos como sistemas operacionais e ambientes, requisitos de compatibilidade e restrições de projeto.

T@rgetTrust Treinamento e Tecnologia 7

Page 135: RUP Apostila v12

Artefatos

Caso de Uso

Um caso de uso define um conjunto de instancias de casos de uso, onde cada instancia é uma seqüência de ações que um sistema executa que produz resultados observáveis para um ator em particular.

Modelo de Casos de Uso

O Modelo de Casos de Uso é um modelo das funções 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 análise, projeto e teste.

Pacote de Casos de Uso

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

Descrição de Caso de Uso

Uma Descrição de Caso de Uso é uma descrição lógica e conceitual de como um caso de uso é executado pela interface com o usuário, incluindo a interação requerida entre os atores e o sistema.

Protótipo de Interface com o Usuário

Um Protótipo de Interface com o Usuário mostra a interface do sistema. Pode ser mostrada como:

Desenhos em papel ou figuras;

Bitmaps feitos por ferramentas de desenho;

Um protótipo executável interativo;

Visão

A Visão define as visões dos envolvidos do produto a ser desenvolvido, especificadas em termos das necessidades chaves e das T@rgetTrust Treinamento e Tecnologia 8

Page 136: RUP Apostila v12

Artefatos

“features” necessárias. Contém os pontos essenciais dos requisitos e provê uma base contratual para requisitos técnicos mais detalhados.

T@rgetTrust Treinamento e Tecnologia 9

Page 137: RUP Apostila v12

Artefatos

Análise e Projeto

O conjunto de artefatos de Análise e Projeto captura e apresenta informações relacionadas a solução de problemas colocados no conjunto de Requisitos.

Classe de Análise

Classes de Análise representam um modelo conceitual preliminar para “coisas no sistema que tem responsabilidades e comportamento”.

Modelo de Análise

Um modelo de objetos descrevendo a realização dos casos de uso e que serve como uma abstração do artefato: Modelo de Projeto. O Modelo de Análise contém o resultado da análise dos casos de uso, instancias do artefato: Classe de Análise. O Modelo de Análise é um artefato opcional.

Cápsula (Capsule)

Uma cápsula é um “design pattern” específico que representa uma “thread” encapsulada de controle do sistema.

T@rgetTrust Treinamento e Tecnologia 10

Page 138: RUP Apostila v12

Artefatos

Modelo de Dados

O Modelo de Dados é um subconjunto do modelo de implementação que descreve o a representação lógica e física dos dados persistentes do sistema. Ele também inclui comportamentos definidos na base de dados, como stored procedures, triggers, constraints, etc.

Modelo de Deployment

O Modelo de Deployment mostra a configuração do processamento nos nós em “run-time”, os links de comunicação entre eles e os componentes e objetos que neles residem.

Classe de Projeto

Uma classe é uma descrição de um conjunto de objetos que compartilha as mesmas responsabilidades, relacionamentos, operações, atributos e semântica.

Modelo de Projeto

O Modelo de Projeto descreve a realização dos casos de uso e serve como uma abstração do modelo de implementação e do código fonte. O Modelo de Projeto é usado como entrada essencial para as atividades de implementação e teste.

Pacote de Projeto

Um pacote de projeto é uma coleção de classes, relacionamentos, realizações de casos de uso e de outros pacotes. É usado para estruturar o modelo de projeto pela divisão em partes menores.

Subsistema de Projeto

Um elemento do modelo que tem a semântica de um pacote (pode conter outros elementos do modelo) e de uma classe (tem comportamento). O comportamento do subsistema é provido pelas classes e

T@rgetTrust Treinamento e Tecnologia 11

Page 139: RUP Apostila v12

Artefatos

outros subsistemas que ele contém. Um subsistema realiza uma ou mais interfaces, que definem o comportamento que ele pode exercer.

Evento

A especificação de uma ocorrência no espaço tempo. De forma menos formal, é a ocorrência de algo ao qual o sistema deve responder.

Interface

Um elemento do modelo que define um conjunto de comportamentos (um conjunto de operações) 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 substituídos um pelo outro no sistema. Cada interface deve prover um conjunto único e bem definido de operações.

Protocolo

Uma especificação comum para um conjunto de artefatos: portas de Cápsulas.

Arquitetura de Referência

Uma Arquitetura de Referência é, em essência, um padrão arquitetural pré-definido, parcialmente ou completamente instanciado, projetado e aprovado para uso em negócios e contextos técnicos particulares, em conjunto com artefatos de suporte para possibilitar seu uso. Frequentemente, esses artefatos são capturados de projetos anteriores.

Sinal

Um sinal é uma entidade de comunicação assíncrona que pode causar uma transição de estados na máquina de estados de um objeto que o recebe.

T@rgetTrust Treinamento e Tecnologia 12

Page 140: RUP Apostila v12

Artefatos

Documento de Arquitetura de Software

O Documento de Arquitetura de Software provê uma visão geral compreensiva da arquitetura do sistema, usando diferentes visões arquiteturais para destacar diferentes aspectos do sistema.

Realização de Caso de Uso

Uma Realização de Caso de Uso descreve como um caso de uso particular é realizado dentro do modelo de projeto em termos de colaboração de objetos.

Prova de Conceito Arquitetural

A Prova de Conceito Arquitetural é uma solução – que pode ser simplesmente conceitual – para os requisitos arquiteturalmente significativos que foram identificados na fase de Inception.

T@rgetTrust Treinamento e Tecnologia 13

Page 141: RUP Apostila v12

Artefatos

Implementação

O conjunto de artefatos de Implementação captura e apresenta a realização da solução apresentada no conjunto de Análise e Projeto.

Build

Um build inclui um ou mais componentes (frequentemente executáveis), cada um construído de outros componentes, geralmente através de um processo de compilação e link de código fonte.

Componente

Um componente representa uma peça de código de software (fonte, binário ou executável) ou um arquivo contendo informação (por exemplo, um arquivo de “startup” ou um arquivo “readme”). Um componente pode também ser um agregado de outros componentes, por exemplo, uma aplicação consiste de vários executáveis.

Modelo de Implementação

O Modelo de Implementação é uma coleção de componentes e de subsistemas de implementação que os contém. Componentes incluem “deliverables”, como executáveis e componentes a partir dos quais os “deliverables” são produzidos, como arquivos de códigos fonte.

Subsistema de Implementação

Um Subsistema de Implementação é uma coleção de componentes e de outros subsistemas de implementação e é usado para estruturar o modelo de implementação pela sua divisão em partes menores.

T@rgetTrust Treinamento e Tecnologia 14

Page 142: RUP Apostila v12

Artefatos

Plano de Integração

O Plano de Integração do build provê o planejamente detalhado para a atividade de integração dentro de uma iteração.

T@rgetTrust Treinamento e Tecnologia 15

Page 143: RUP Apostila v12

Artefatos

Teste

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

Caso de Teste

Um Caso de Teste é um conjunto de: entradas, condições de execução e resultados esperados, desenvolvidos para um objetivo particular, como exercitar um caminho de execução particular de um programa ou para verificar a conformidade com um requisito específico.

Classe de Teste

Uma classe estereotipada no modelo de projeto.

T@rgetTrust Treinamento e Tecnologia 16

Page 144: RUP Apostila v12

Artefatos

Componente de Teste

Um componente estereotipado no modelo de implementação.

Resumo de Avaliação de Testes

O Resumo de Avaliação de Testes organiza e apresenta os resultados e medições chaves dos testes para revisão e avaliação. Adicionalmente, o Resumo de Avaliação de Testes contém uma avaliação, feita pelos testadores e projetistas de testes, destas informações e recomendações para os esforços futuros.

Modelo de Teste

O Modelo de Teste é uma representação do que será testado e de como será testado. É uma visão dos modelos de projeto e implementação, destacando os testes em si, bem como os aspectos dos alvos do teste que são relefantes para os esforços de teste. Ele inclui a coleção dos casos de teste, procedimentos de teste, scripts de teste e resultados esperados junto com as descrições de seus relacionamentos.

Pacote de Teste

Um pacote estereotipado no modelo de projeto.

Plano de Teste

O Plano de Teste contém informação sobre a proposta e metas dos testes dentro do projeto. Adicionalmento, o Plano de Testes identifica as estratégias a serem usadas para implementar e executar testes e os recursos necessários.

T@rgetTrust Treinamento e Tecnologia 17

Page 145: RUP Apostila v12

Artefatos

Procedimento de Teste

Um Procedimento de Teste é um conjunto detalhado de instruções 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 contém um repositório dos dados capturados durante a execução dos testes e é usado no calculo das medições chave dos testes.

Script de Teste

Scripts de Teste são instruções de computador que automatizam a execução 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 automação de teste, programadas usando uma linguagem de programação ou uma combinação de gravação, geração e programação.

Subsistema de Teste

Um tipo de subsistema de implementação, do modelo de implementação, contendo componentes relacionados aos testes.

Documento de Análise de Carga de Trabalho

Um Documento de Análise de Carga de Trabalho identifica as variáveis e define os valores a serem utilizados nos diferentes testes de performance usados para simular e/ou emular as características dos atores, usuários finais, funções de negócio, carga e volume de transações.

T@rgetTrust Treinamento e Tecnologia 18

Page 146: RUP Apostila v12

Artefatos

Deployment

O conjunto de artefatos de Deployment captura e apresenta informações relacionadas a transição do sistema apresentada no conjunto de Implementação para o ambiente de produção.

Lista de Materiais

A Lista de Materiais lista as partes que constituem uma determinada versão do produto e a localização onde podem ser encontradas. Ela descreve as mudanças feitas na versão e referencia como o produto deve ser instalado.

Plano de Deployment

O Plano de Deployment descreve o conjunto de tarefas necessárias para instalar e testar o produto desenvolvido de forma que ele possa ser transmitido de forma eficiente para a comunidade usuária.

Material de Suporte ao Usuário Final

Material que auxilia o usuário final no aprendizado, utilização, operação e manutenção do produto.

T@rgetTrust Treinamento e Tecnologia 19

Page 147: RUP Apostila v12

Artefatos

Artefatos de Instalação

Aretefatos de Instalação referem-se ao software e instruções documentadas necessárias para a instalação do produto.

Unidade de Deployment

Uma Unidade de Deployment consite de um build (uma coleção executável de componentes), documentos (material de suporte ao usuário final e notas de versão) e artefatos de instalação. Uma Unidade de Deployment é geralmente associada a um nó único dentro da rede de computadores ou periféricos.

Produto

O empacotamente de um produto com apelo de marketing o diferencia de uma unidade de deployment. Um produto pode conter múltiplas unidades de deployment e pode estar acessível através de download, empacotado ou em algum formato de armazenamento em mídia digital.

Arte do Produto

A Arte do Produto inclui o texto (especificações) e trabalho de arte que será usado como “marca” do produto. A Arte do Produto pode aparecer no pacote físico ou em um web site.

Notas de Versão

Notas de Versão identificam mudanças e problemas conhecidos em uma versão de build ou unidade de deployment que tenha sido colocada disponível para uso.

Material de Treinamento

Materiais de Treinamento referem-se aos materiais que são usadas em programas de treinamento ou cursos para auxiliar os usuários finais no uso, operação e/ou manutenção do produto

T@rgetTrust Treinamento e Tecnologia 20

Page 148: RUP Apostila v12

Artefatos

Gerenciamento de Configuração e Mudanças

O conjunto de artefatos de Gerenciamento de Configuração e Mudanças captura e apresenta as informações relacionadas ao workflow de Gerenciamento de Configuração e Mudanças.

Requisição de Mudança

Mudanças aos artefatos de desenvolvimento são propostas através de Requisições de Mudança (CR – Change Requests). Requisições de mudança são usadas para documentar e rastrear defeitos, requisições de melhoria e outros tipos de requisições de mudança no produto. O benefício das Requisições de Mudança é que eles provêm registro das decisões e, devido ao seu processo de avaliação, asseguram que os impactos das mudanças são entendidos por todo o projeto.

Evidências de Auditoria de Configuração

As Evidências de Auditoria de Configuração identificam uma baseline, artefatos faltantes e requisitos não testados ou com falha.

Plano de Gerência de Configuração

O Plano de Gerencia de Configuração (CM Plan) descreve todas as atividades de Gerência e Controle de Mudanças (CCM Plan) que serão executadas durante o ciclo de vida do produto ou do projeto. Ele detalha o

T@rgetTrust Treinamento e Tecnologia 21

Page 149: RUP Apostila v12

Artefatos

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

Repositório de Projeto

O Repositório do Projeto armazena todas as versões dos arquivos e diretórios do projeto. Também armazena todos os dados e meta-dados derivados ou associados aos arquivos e diretórios.

Espaço de Trabalho (Workspace)

Os workspaces possibilitam o acesso a artefatos e recursos necessários 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 mudanças aos artefatos sem que essas mudanças tornem-se visíveis imediatamente aos outros.

O workspace de integração é um espaço compartilhado e acessível a todos os membros do time do projeto. O produto total é construído e estabelecido (baselined) no workspace de integração.

T@rgetTrust Treinamento e Tecnologia 22

Page 150: RUP Apostila v12

Artefatos

Gerenciamento de Projeto

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

Caso de Negócio

O Caso de Negócio provê a informação necessária, do ponto de vista de negócio, para determinar se o projeto vale o investimento.

Para um produto de software comercial, o Caso de Negócio 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 são verificadas novamente ao final da fase de elaboration quando o escopo e o planejamento estão definidos com mais precisão.

Avaliação de Iteração

A Avaliação da Iteração captura o resultado de uma iteração, o grau ao qual os critérios de avaliação foram atingidos, lições aprendidas e mudanças a serem feitas.

T@rgetTrust Treinamento e Tecnologia 23

Page 151: RUP Apostila v12

Artefatos

Plano de Iteraçao

Um conjunto de atividades e tarefas seqüenciadas no tempo, com recursos associados, contendo dependências entre tarefas, para a iteração; um plano “fine-grained”.

Plano de Métricas

Define as metas para as medições, métricas associadas e as métricas primitivas que serão obtidas no projeto para monitorar seu progresso.

Plano de Resolução de Problemas

O Plano de Resolução 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 critérios de aceitação. Ele detalha estes critérios de aceitação e identifica as tarefas de aceitação do produto (incluindo identificação dos casos de teste que precisam ser desenvolvidos) que serão levadas adiante, terão as responsabilidades associadas e os recursos necessários. Em projetos de menor escala, este plano pode ser embutido dentro do Plano de Desenvolvimento de Software.

Métricas do Projeto

O artefato de Métricas do Projeto é o repositório ativo de dados de métricas do projeto. Ele contém as medidas mais atuais sobre projeto, recursos, processos e produto em nível primitivo e derivado.

Plano de Garantia de Qualidade

O Plano de Garantia de Qualidade é um artefato que provê uma visão clare de como a qualidade do produto, artefatos e processo serão

T@rgetTrust Treinamento e Tecnologia 24

Page 152: RUP Apostila v12

Artefatos

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

Registros de Revisão

Um Registro de Revisão é criado para capturar os resultados da revisão de um artefato do projeto.

Lista de Riscos

Uma lista de riscos conhecidos e abertos para o projeto, ordenada em ordem decrescente de importância associada a ações específicas de mitigação ou contingência.

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 serão levadas adiante, responsabilidades associadas e recursos adicionais necessários 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 reúne toda a informação necessária para gerenciar o projeto. Ele contém artefatos desenvolvidos durante a fase de Inception e é mantido ao longo do projeto.

Avaliação de Status

Um dos objetivos do processo é assegurar que as expectativas de todas as partes estão sincronizadas e consistentes. A avaliação de status periódica provê um mecanismo para gerenciar as expectativas de todos ao longo do ciclo de vida do projeto.

T@rgetTrust Treinamento e Tecnologia 25

Page 153: RUP Apostila v12

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 responsável. Ela se torna um contrato interno entre o Gerente do Projeto e os responsáveis pela execução.

T@rgetTrust Treinamento e Tecnologia 26

Page 154: RUP Apostila v12

Artefatos

Ambiente

O conjunto de artefatos de Ambiente representa os artefatos que são usados como guia ao longo do desenvolvimento do sistema para assegurar a consistência de todos os artefatos produzidos.

Guidelines para Modelagem de Negócio

Descreve as guidelines para modelagem do negócio.

Guidelines para Projeto

Descreve as guidelines para projeto e implementação.

T@rgetTrust Treinamento e Tecnologia 27

Page 155: RUP Apostila v12

Artefatos

Caso de Desenvolvimento

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

Avaliação da Organização de Desenvolvimento

A Avaliação da Organização de Desenvolvimento descreve o status atual da organização de software em termos de processos atuais, ferramentas, competências pessoais, atitudes pessoais, competidores, tendências técnicas, problemas e áreas de melhoria.

Guia de Estilo de Manual

Descreve como os manuais de suporte usuário final devem ser escritos.

Templates Específicos do Projeto

Templates para os artefatos documentais e relatórios usados no projeto. Pode também haver templates para modelos e elementos de modelo, como o modelo de projeto.

Guidelines de Programação

Descreve as convenções a serem usadas no trabalho com a linguagem de programação.

Guidelines de Teste

Descreve as guidelines de teste.

T@rgetTrust Treinamento e Tecnologia 28

Page 156: RUP Apostila v12

Artefatos

Ferramentas

As ferramentas para suportar o esforço de desenvolvimento de software.

Guidelines de Ferramentas

Descreve como utilizar uma ou várias 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 também inclui o hardware e o software usado para interconectar os computadores e usuários.

Guidelines de Modelagem de Casos de Uso

Descreve as guidelines para modelagem de casos de uso.

Guidelines de Interface de Usuário

Guidelines específicas do projeto sobre como criar a interface com o usuário.

T@rgetTrust Treinamento e Tecnologia 29

Page 157: RUP Apostila v12

Artefatos

Exercícios

T@rgetTrust Treinamento e Tecnologia 30

Page 158: RUP Apostila v12

Artefatos

Espaço para anotações

T@rgetTrust Treinamento e Tecnologia 31

Page 159: RUP Apostila v12

RUP

T@rgetTrust Treinamento e Tecnologia 1