Resumo Livro RUP Made Easy

Study Guide IBM Rational Unified Process – RUP 2003 Esse resumo gratuito foi criado com base no Livro The Rational Unified

Process Made Easy de Per Kroll and Philippe Kruchten e não se propõe a substituir o mesmo em parte ou em sua totalidade, sendo assim,

apenas um guia de referência rápida. Recomenda-se também a leitura do livro devido a sua excelente abordagem sobre RUP. Qualquer

revisão ou sugestão entre em contato com [email protected]. www.fernandodantas.com.br 21/2/2008

Study Guide – IBM Rational Unified Process – RUP 2003 www.fernandodantas.com.br

2

CERTIFICAÇÕES RELACIONADAS: IBM Rational Unified Process 000-639

Conteúdo

PART I ............................................................................................................................................................ 5

CHAPTER 1: INTRODUCING THE RATIONAL UNIFIED PROCESS ........................................................................ 5

O QUE É O RUP? ........................................................................................................................................ 5

RUP E O DESENVOLVIMENTO ITERATIVO ................................................................................................... 5

THE RUP - A WELL-DEFINED SOFTWARE ENGINEERING PROCESS ............................................................... 6

THE RUP - A CUSTOMIZABLE PROCESS PRODUCT ....................................................................................... 8

CHAPTER 2: THE SPIRIT OF THE RUP: GUIDELINES FOR SUCCESS .................................................................. 10

ATAQUE OS RISCOS O MAIS CEDO POSSÍVEL ............................................................................................ 10

ENTREGUE VALOR AO CLIENTE................................................................................................................. 10

FOQUE NO SOFTWARE EXECUTÁVEL ........................................................................................................ 11

ACOMODE MUDANÇAS AO PROJETO O QUANTO ANTES .......................................................................... 11

BASELINE AN EXECUTABLE ARCHITECTURE EARLY ON .............................................................................. 11

CONSTRUA SEU SISTEMA COM COMPONENTS ......................................................................................... 11

TRABALHE COMO UM ÚNICO TIME .......................................................................................................... 11

FAÇA DA QUALIDADE UMA FILOSOFIA DE VIDA, NAO UM PÓS-PROCESSO; .............................................. 12

CHAPTER 3. COMPARING PROCESSES: THE RUP, AGILE METHODS, AND HEAVYWEIGHT GOVERNMENT ...... 13

COMPARANDO PROCESSOS ..................................................................................................................... 13

HIGH CEREMONY STRIVING FOR HIGHER PREDICTABILITY ........................................................................ 14

SEI CMMI: PROCESS ASSESSMENT FRAMEWORK ...................................................................................... 14

RUP: PROCESSO ITERATIVO COM NÍVEL DE CERIMÔNIA ADAPTÁVEL ....................................................... 15

QUÃO ITERATIVO VOCÊ QUER SER? ......................................................................................................... 15

QUANTA CERIMÔNIA VOCÊ QUER? .......................................................................................................... 16

CHAPTER 4. THE RUP FOR A TEAM OF ONE: PROJECT DEIMOS ..................................................................... 17

PART II: CICLO DE VIDA DE UM PROJETO RUP .............................................................................................. 17

CHAPTER 5: AS QUATRO FASES DO RUP ....................................................................................................... 17

ERRO COMUM ......................................................................................................................................... 17

PRINCIPAIS MILESTONES .......................................................................................................................... 17

SEM WORKFLOWS FIXOS ......................................................................................................................... 18

SEM ARTEFATOS CONGELADOS ............................................................................................................... 18


3

CHAPTER 6: FASE INCEPTION ....................................................................................................................... 19

OBJETIVOS DA FASE INCEPTION ............................................................................................................... 19

INCEPTION E ITERAÇÕES .......................................................................................................................... 19

OBJETIVO 01: ENTENDER O QUE CONSTRUIR ........................................................................................... 19

OBJETIVO 02: INDENTIFICAR AS PRINCIPAIS FUNCIONALIDADES DO SISTEMA .......................................... 20

OBJETIVO 03: DETERMINAR UMA POSSÍVEL SOLUÇÃO ............................................................................. 20

OBJETIVO 04: ENTENDER O CUSTO, CRONOGRAMA E RISCOS DO PROJETO ............................................. 20

OBJETIVO 05: DEFINIR PROCESSOS E FERRAMENTAS................................................................................ 20

CHAPTER 7: FASE ELABORAÇÃO ................................................................................................................... 21

OBJETIVOS DA FASE ................................................................................................................................. 21

ELABORAÇÃO E ITERAÇÕES ...................................................................................................................... 21

PRIMEIRA ITERAÇÃO ................................................................................................................................ 21

SEGUNDA ITERAÇÃO ................................................................................................................................ 21

OBJECTIVE 1: GET A MORE DETAILED UNDERSTANDING OF THE REQUIREMENTS .................................... 22

OBJECTIVE 2: DESIGN, IMPLEMENT, VALIDATE, AND BASELINE THE ARCHITECTURE ................................ 22

USE CASOS DE USO SIGNIFICANTES PARA DEFINIR A ARQUITETURA......................................................... 22

DESENHE CASOS DE USO CRÍTICOS........................................................................................................... 22

TESTE OS CENÁRIOS CRÍTICOS .................................................................................................................. 23

OBJECTIVE 3: MITIGATE ESSENTIAL RISKS, AND PRODUCE ACCURATE SCHEDULE AND COST ESTIMATES .. 23

CHAPTER 8: FASE CONSTRUÇÃO .................................................................................................................. 24

OBJECTIVES OF THE CONSTRUCTION PHASE............................................................................................. 24

CONSTRUCTION AND ITS ITERATIONS ...................................................................................................... 24

OBJECTIVE 1: MINIMIZE DEVELOPMENT COSTS AND ACHIEVE SOME DEGREE OF PARALLELISM ............... 25

CONFIGURATION MANAGEMENT SYSTEM ............................................................................................... 26

ENFORCE THE ARCHITECTURE .................................................................................................................. 26

ENSURE CONTINUAL PROGRESS ............................................................................................................... 26

OBJECTIVE 2: ITERATIVELY DEVELOP A COMPLETE PRODUCT THAT IS READY TO TRANSITION TO ITS USER

COMMUNITY ........................................................................................................................................... 26

DESCRIBE THE REMAINING USE CASES AND OTHER REQUIREMENTS ........................................................ 26

DESIGN THE DATABASE ............................................................................................................................ 27

IMPLEMENT AND UNIT-TEST CODE .......................................................................................................... 27

EARLY DEPLOYMENTS AND FEEDBACK LOOPS .......................................................................................... 27

CHAPTER 9: FASE TRANSIÇÃO ...................................................................................................................... 28

OBJECTIVES OF THE TRANSITION PHASE .................................................................................................. 28


4

TRANSITION AND ITERATIONS.................................................................................................................. 28

TRANSITION AND DEVELOPMENT CYCLES ................................................................................................ 29

OBJECTIVE 1: BETA TEST TO VALIDATE THAT USER EXPECTATIONS ARE MET ............................................ 29

PART III: ADOPTING THE RUP ....................................................................................................................... 31

CHAPTER 11: ADOPTING RUP ....................................................................................................................... 31

ADOPTING THE RUP IN A LARGE ORGANIZATION ..................................................................................... 31

CHAPTER 12: CONFIGURING, INSTANTIATING, AND CUSTOMIZING RUP ...................................................... 33

KEY CONCEPTS ......................................................................................................................................... 33

COARSE-GRAIN AND FINE-GRAIN PLANS: PROJECT PLANS AND ITERATION PLANS ................................... 33

BUILDING A PROJECT PLAN ...................................................................................................................... 35

ITERATION PLANNING .............................................................................................................................. 37

ESTIMATING ............................................................................................................................................ 37

OPTIMIZING THE PROJECT PLAN .............................................................................................................. 37


5

PART I

CHAPTER 1: INTRODUCING THE RATIONAL UNIFIED PROCESS

O QUE É O RUP? Em sua essência, o RUP é um conjunto de práticas coletadas de engenharia de software que são

continuamente aprimoradas, com regularidade, para refletirem alterações nas práticas do segmento de

mercado. Há três elementos centrais que definem o RUP:

- A software development approach that is iterative, architecture-centric and use-case driven;

- A well-defined and structured software engineering process;

- A process product providing a customizable process framework;

RUP E O DESENVOLVIMENTO ITERATIVO Muitas equipes ainda utilizam o processo chamado waterfall onde cada fase(requisitos, análise & desenho,

implementação, testes) deve ser completamente concluída antes de iniciar a próxima. Esse tipo de processo

faz com que membros importantes da equipe fiquem ociosos ou fora do projeto por muito tempo e também

retém os testes para o fim do projeto quando problemas tendem a ser difíceis e caros de se resolver.

RUP utiliza um processo Iterativo(repetitivo) que é uma seqüência de passos incrementais. Nesse processo

as seguintes características são marcantes:

- Cada iteração inclui algumas ou todas as disciplinas;

- Cada iteração deve ter um conjunto bem definido de objetivos e produz uma parte funcional do

sistema;

- Cada iteração sucessiva é construída sob o trabalho da iteração anterior;

- As primeiras iterações têm uma grande ênfase em requisitos e análise & desenho;

- Iterações posteriores têm uma grande ênfase em implementação e testes;


6

O processo iterativo tem provado-se melhor do que o processo waterfall pelos seguintes motivos:

- Ele acomoda melhor e mais cedo as mudanças de requisitos;

- Integra melhor a equipe do projeto pois todos atuam em conjunto:

Deixar a integração para o fim do projeto resulta e retrabalho o que algumas vezes chega a consumir

40% do tempo total do projeto.

- Riscos são geralmente descobertos e resolvidos durante o início da integração:

Desde as primeiras iterações exercita-se vários aspectos do projeto como: ferramentas, circulação

do software e skill dos membros da equipe.

- Gerencialmente é possível mudar a tática ou mudar o projeto já que em pouco tempo um release

executável é liberado;

- A reutilização é facilitada quando partes inicias são desenhada e implementadas;

- Defeitos podem ser encontrados e corrigidos sob inúmeras iterações;

- Faz um melhor uso das pessoas envolvidas no projeto;

Como muitas pessoas ficam muito tempo sem por as mãos no projeto no processo waterfall elas

sentem-se menos responsáveis pelo produto final o que também causa muitos erros e mal-

entendidos;

- Os membros da equipe aprendem ao longo do caminho;

Membros da equipe têm mais oportunidades de aprender com os próprios erros realizando ajustes

entre uma iteração e outra;

- O processo de desenvolvimento é evoluído e refinado ao longo do caminho;

THE RUP - A WELL-DEFINED SOFTWARE ENGINEERING PROCESS O próprio RUP foi desenhado com técnicas similares às utilizadas em Desenho de Softwares. Particularmente falando, RUP foi desenhado em SPEM(Software Process Engineering Metamodel), um padrão de

modelagem de processo baseado em UML. A arquitetura do RUP apresenta duas estrutura, ou

dimensões, como também são chamadas.


7

Estrutura Dinâmica: A dimensão horizontal representa a estrutura dinâmica ou o tempo dos processos. Ela expressa o processo em termos de ciclo, fase(Inception, Elaboration, Construction, and Transition), iteração e milestones. Estrutura Estática:

A dimensão vertical representa a estrutura estática do processo. Ela descreve como elementos do processo(atividades, disciplinas, artefatos e papéis) são logicamente agrupados em disciplinas principais de processo ou workflows.

Um processo descreve quem faz o que, como e quando conforme os elementos de modelagem abaixo:

Papéis(roles) -> Quem


8

Representa o chapéu que um individuo usa pondendo o mesmo ter diferentes papéis durante o

projeto. Geralmente confunde-se papéis como sendo um indivíduo ou posição fixa no projeto mas

para o RUP papel simplesmente define que individuo deve realizar o trabalho.

Atividades -> O que

Unidade de trabalho que um individuo em um papel pode ser questionado a executar. Geralmente

cria ou atualiza algum artefato.

Artefatos -> Como

São elementos tangíveis de um projeto. Pode assumir várias formas como: modelo, documento,

código fonte ou executável.

Workflow -> Quando

Uma forma de descrever seqüência significantes de atividades que produzem algum resultado de

valor(artefato) e que mostram interações entre papéis.

Disciplinas

Um agrupamento lógico de papéis, atividades, artefatos e outros elementos. Existem 9 disciplinas no RUP

sendo que essa lista não é definitiva e qualquer empresa pode estender o RUP e suas disciplinas.

THE RUP - A CUSTOMIZABLE PROCESS PRODUCT Cada projeto e organização têm necessidades únicas e requerem um processo que seja adaptado a sua

situação específica. Para atender esse requisito o RUP apresenta um completo framework de processo

composto por várias partes integradas:

- Best Practices:

Conjunto de melhores práticas produzidas pela IBM e exposta através de fases, papéis, atividades,

artefatos e workflows.

- Process delivery tools:

O RUP é apresentando em forma de WebSite interativo facilitando a integração com equipe de

desenvolvimento e ferramentas Rational.

- Configuration tools

Através do RMC (Rational Method Composer) é possível customizar o RUP e publicar variações de

processos diferentes.

- Community/Marketplace

Através do site DeveloperWorks é possível trocar experiências com experts e ter acesso as últimas

informações em termos de artefatos, artigos ou conteúdo adicional do RUP.

- Ferramenta de Autoria de Método

Rational Process Workbench é uma ferramenta que permite capturar suas próprias melhores

práticas no formato RUP.


9


10

CHAPTER 2: THE SPIRIT OF THE RUP: GUIDELINES FOR SUCCESS

Os princípios abaixo foram coletados de inúmeros projetos de sucesso:

ATAQUE OS RISCOS O MAIS CEDO POSSÍVEL Um dos benefícios do processo interativo é que ele permite que você identifique e enderece os principais riscos do projeto com antecedência.

Uma estratégia simples é relacionar os principais riscos(entre 3 e 5 geralmente) conforme abaixo:

- Risk 1: You are concerned, based on past experience, that Department X will not understand what

requirements you plan to deliver, and as a result will request changes after beta software is delivered.

- Risk 2: You do not understand how you can integrate with legacy system Y.

- Risk 3: You have no experience in developing on the Microsoft .NET platform or in using Rational Rose.

Identificada a lista de erros faça uma segunda lista com as possíveis soluções:

- Risk 1: As the use cases related to Department X are developed, complement them with a user-

interface (UI) prototype. Set up a meeting with Department X, and walk them through each use case,

using the UI prototype as a storyboard. Get a formal sign-off on the requirements. Throughout the

project, keep Department X in the loop on progress, and provide them with early prototypes and alpha

releases.

- Risk 2: Have a "tiger team" with one or two skilled developers build an actual prototype that shows how

to integrate with legacy system.

ENTREGUE VALOR AO CLIENTE Use cases make it easy to document functional user requirements and to help all stakeholders understand

the capabilities that are to be delivered. More essentially, use cases allow you to work closely to the

requirements when doing design, implementation, and testing, thereby ensuring that you not only

document, but also deliver, the user requirements. Combined with iterative development, they help ensure

that you deliver customer value.


11

FOQUE NO SOFTWARE EXECUTÁVEL Documentação é importante mas deve ser vista como produto secundário. Código compilado e executando

tem maior valor do que documentos. Um dos erros mais comuns dos usuários do RUP é produzir artefatos

apenas porque o RUP descreve como fazê-los.

ACOMODE MUDANÇAS AO PROJETO O QUANTO ANTES A maioria dos softwares atuais é muito complexo para permite a coleta de requisitos exatos que não

requeiram mudanças. Dessa forma, se não ocorrem mudanças você estará entregando uma solução

defeituosa ou sem valor de negócio e é exatamente por isso que mudanças devem ser estimuladas.

Porém, mudanças tardias podem ter sérias conseqüências em custo. Existem 4 grupos de mudanças e seus

respectivos custos de acordo com o ciclo do projeto:

- Cost of change to the business solution

- Cost of change to the architecture

- Cost of change to the design and implementation

- Cost of change to the scope

BASELINE AN EXECUTABLE ARCHITECTURE EARLY ON Muitos riscos de projetos, especialmente para novas arquiteturas, podem ser mitigados desenhando,

implementando e testando-se uma arquitetura executável o quanto antes dentro do projeto. A arquitetura

provê uma esqueleto do sistema compreendendo de 10 a 20% de toda a quantidade de código a ser

produzido.

CONSTRUA SEU SISTEMA COM COMPONENTS Isso facilita mudanças e reduz o tempo.

TRABALHE COMO UM ÚNICO TIME O trabalho iterativo enfatiza a importância de uma boa comunicação na equipe e o espírito onde cada

membro sente-se responsável pelo produto. Organizações funcionais tendem a criar grupos de Analistas,


12

Desenvolvedores, Testes, etc. O maior problema dessa abordagem é que a comunicação entre os grupos

torna-se ineficiente. Já em Organizações matriciais um único individuo pode estar alocado em várias

projetos ao mesmo tempo.

FAÇA DA QUALIDADE UMA FILOSOFIA DE VIDA, NAO UM PÓS-PROCESSO; Um dos maiores benefícios do processo Iterativo é que ele permite a realização de testes muito mais cedo

do que no processo em cascata. Dessa forma não é surpresa o fato de que muitos projetos que adotam o

RUP tem como primeiro resultado a evolução da qualidade final do produto.


13

CHAPTER 3. COMPARING PROCESSES: THE RUP, AGILE METHODS, AND

HEAVYWEIGHT GOVERNMENT

COMPARANDO PROCESSOS Um processo pode ser comparado dividindo-o em dois eixos conforme abaixo:

Nível de Cerimônia: refere-se a quantidade de formalismo na produção de documentos e artefatos;

Iterativo: refere-se ao fato do processo ser iterativo ou waterfall;

Algumas metodologias Ágeis como XP, Scrum, e Adaptive Development fazem sacrifícios em termos

de cerimônia e rigor em prol da flexibilidade e habilidade de adaptar-se para envolver o ambiente de

negócio. Elas concentram-se em produzir o software funcional ao invés de criar documentações

extensivas. Em oposição a um modelo rígido de desenvolvimento um dos principais princípios do

desenvolvimento ágil é respond to changes that occur during the process.


14

HIGH CEREMONY STRIVING FOR HIGHER PREDICTABILITY Paralelamente ao movimento Ágil existe uma forte tendencia em direção a frameworks baseados em alta

cerimônia como SEI CMM, SEI CMMI, e ISO/IEC e processos como DOD-STD e MIL-STD. Characteristics of a

high-ceremony project include the following:

- Todo o planejamento é cuidadosamente documentado;

- Muitos artefatos relacionados a gerenciamento, requisitos, desenho e teste são produzidos;

- Todos os artefatos são detalhados, documentados e colocados em um controle de versões;

- Rastreabilidade entre artefatos de requisitos, desenho e teste são estabelecidas e mantidas;

- Aprovação do CCB - Change Control Board é requerida para mudanças;

- Resultados de inspeção são cuidadosamente gravados e rastreados.

Processos baseados em alta cerimônia são apropriados para sistemas complexos, com grandes equipes e

distribuídos. Se o tempo de entrega é uma necessidade primária esse tipo de processo pode levar a uma

menor qualidade porque não haverá tempo suficiente para fazer o trabalho correto descrito pelo processo.

SEI CMMI: PROCESS ASSESSMENT FRAMEWORK Ao contrário do CMM que estimula um processo waterfall o CMMI visa acomodar as novas práticas iterativas

e conforme figura abaixo ilustra sua localização como um processo formal e iterativo.


15

RUP: PROCESSO ITERATIVO COM NÍVEL DE CERIMÔNIA ADAPTÁVEL RUP é um framework customizável que permite produzir uma variedade de processos ou configurações.

Essas configurações podem favorecer tanto um menor quanto uma maior cerimônia.

QUÃO ITERATIVO VOCÊ QUER SER? Existe um concenso na industria de software sobre os benefícios do processo iterative mas o que impede

uma organização de utilizar um alto nível de iteração?

Conhecimento: pode ser difícil para equipes inexperientes adotar um alto nível de iteração sem

nenhuma mentoria;


16

Processos: desenvolvimento iterativo introduz um grande conjunto de novos desafios,

especialmente para gerentes e arquitetos. Dessa forma, deve existir um processo que guie o

desenvolvimento introduzindo boas práticas;

Ferramentas: é extremamente difícil realizar desenvolvimento iterativo sem ferramentas para

automatizar: testes, configurações, gerência de mudanças entre outros.

QUANTA CERIMÔNIA VOCÊ QUER? Baixa cerimônia significa produzir menos documentação como, por exemplo, não rastrear mudanças em

requisitos, design e casos de uso. Dessa forma, muito tempo seria economizado e mudanças teriam um

custo reduzido o que pode ser importante para empresas que tem um grande restrição de data ou atuam

em mercados em constante mudança.

Por outro lado, alta cerimônia pode ser deseja em desenvolvimentos de larga escala, distribuídos,

tecnicamente complexos ou onde a relação com stakeholder é complexa. Em muitos casos um bom nível de

automatização permite extrair o benefício de ambas as abordagens.


17

CHAPTER 4. THE RUP FOR A TEAM OF ONE: PROJECT DEIMOS Este capítulo apresentar um passo-a-passo de um projeto de uma semana que utiliza as práticas do RUP. Por

ser apenas um exemplo não foi relacionado neste resumo.

PART II: CICLO DE VIDA DE UM PROJETO RUP

CHAPTER 5: AS QUATRO FASES DO RUP O ciclo de desenvolvimento do RUP passa por quarto fases: Inception, Elaboration, Construction, e

Transition. Esse ciclo de vida encerra-se com a entrega completa do software.

ERRO COMUM Embora as 4 fases sejam seqüenciais lembre-se que ciclo de vida do RUP é iterativo e baseado em

riscos(risk-driven). Dessa forma, as fases do RUP não devem ser tratadas como um processo em cascata

onde a primeira deve ser completamente encerradas antes de se começar a próxima.

PRINCIPAIS MILESTONES O propósito de uma fase no RUP não é dividir atividades por tipo(análise, implementação, etc). Isso já é

obtido através do conceito de disciplina. O real objetivo de uma fase é fazer apenas o suficiente de uma

atividade para atingir os objetivos da fase ao mesmo tempo que atinge os milestones que a concluem. O que

você precisa atingir em cada fase normalmente é guiado pelos riscos que a mesma representa conforme

abaixo:

Inception: o foco é o tratamento de riscos relacionados ao business case, ou seja, o projeto

compensa financeiramente?

Elaboration: foca principalmente nos riscos técnicos examinando a arquitetura e revendo o escopo

ao passo que o requisito torna-se mais claro;

Construction: volta-se para os riscos lógicos do projeto. É nessa fase que a equipe atinge seu maior

número de recursos.

Transition: trata o risco associado com a entrega do produto ao usuário final.


18

SEM WORKFLOWS FIXOS A única coisa que se mantém constante ao longo de todos os projetos do RUP são os milestones

apresentados anteriormente. O que você deve alcançar ao fim de cada fase deve ser de preocupação de

cada membro do time. Isso significa que não existe no RUP uma receita ou um conjunto de atividades pre-

definidas que deve ser sempre executada em cada fase. O RUP oferece uma paleta de possibilidade, mas o

contexto do seu projeto é quem irá determinar o que você irá usar durante a fase para alcançar seus

objetivos.

Uma das piores práticas é quando a equipe tenta executar todo o RUP desenvolvendo seus artefatos e

executando suas atividades sem nenhuma customização que o adapte ao real contexto do projeto a ser

aplicado.

SEM ARTEFATOS CONGELADOS Seja para simplificar o gerenciamento ou dar a sensação de conclusão é comum querermos completar um

artefato de uma única vez dentro de uma fase ou iteração e congelá-lo após sua assinatura. Porém, o

objetivo de uma fase não é descrito com foco em concluir artefatos mas sim elevá-los a um nível maior de

maturidade. Dessa forma, artefatos devem ser atualizados, revisados e corrigidos conforme o entendimento

do projeto evolui. Um bom exemplo pode ser o próprio documento de Visão que é escrito na fase de

Iniciação mas pode e deve ser modificado em fases posteriores conforme a visão fica mais clara.

Também deve-se considerar que nem todos artefatos necessitam ser construídos. Alguns como Casos de

Uso, por exemplo, podem ser feitos sempre por serem mais importantes mas outros que venham a ser

constantemente semelhantes podem ser apenas brevemente descritos.


19

CHAPTER 6: FASE INCEPTION Devido a complexidade é comum para novos seguidores do RUP perderem a exata perspectiva do que estão

tentando alcançar. Porém, uma regra simples pode ser seguida: Tenha um claro entendimento sobre os

objetivos das 4 fases do RUP e imagine o que esses objetivos concretos significam para o seu contexto.

OBJETIVOS DA FASE INCEPTION Essa fase foca na compreensão do escopo e objetivos do projeto obtendo informações suficientes para

confirmar que você deve seguir ou até mesmo abortar o projeto. Os 5 principais objetivos são:

1) Understand what to build: Determine the vision, the scope of the system, and its boundaries,

that is, what is inside the system and what is outside. Identify who wants this system and what it

is worth to them.

2) Identify key system functionality: Decide which use cases (which ways of using the system) are

most critical.

3) Determine at least one possible solution: Identify at least one candidate architecture.

4) Understand the costs, schedule, and risks associated with the project.

5) Decide what process to follow and what tools to use.

INCEPTION E ITERAÇÕES A maioria dos projetos tem apenas uma iteração para essa fase. Porém, alguns projetos podem ter mais de

uma iteração o que geralmente ocorre em projetos maiores onde a primeira iteração foca no “o que” -

objetivos 1, 2 e 3 acima - enquanto a outra foca no “como” - objetivos 4 e 5 acima.

OBJETIVO 01: ENTENDER O QUE CONSTRUIR Todos os stakeholders devem concordar com uma visão comum do que o sistema se propõe a realizar. Para

assegurar um entendimento comum você precisa:

Produzir um documento de visão:

O documento de visão deve estar concluído e estável até o fim da fase de Iniciação mas pode

continuar sendo refinado ao longo do projeto. Ele claramente deve apresente aos stakeholders:

- os benefícios e oportunidades que a aplicação irá prover;

- os problemas que serão resolvidos pela aplicação;

- quem serão os principais usuários do sistema;

- principais features do sistema;

- principais requisitos não funcionais(banco de dados, SO, escalabilidade, etc);

Gerar uma breve descrição do sistema:

Fornecer uma descrição do escopo do sistema sem muitos detalhes através da identificação de seus

atores e casos de uso.

Detalhar os principais Atores e Use Cases

Refinar o detalhamento dos principais casos de uso do sistema (aproximadamente 20% deles). Em

paralelo as descrições você poderá também gerar protótipos de interface com usuário que

permitirão a validação os fluxos de eventos com os stakeholders.


20

OBJETIVO 02: INDENTIFICAR AS PRINCIPAIS FUNCIONALIDADES DO SISTEMA É importante identificar quais são os casos de uso essenciais do sistema e também os que são

arquiteturalmente significantes para que um maior tempo seja dedicado aos mesmos. Tipicamente um

projeto de 20 casos de uso apresenta 3 ou 4 siginificantes.

OBJETIVO 03: DETERMINAR UMA POSSÍVEL SOLUÇÃO Como o objetivo da fase de Iniciação é determinar se faz sentido continuar com o projeto você precisa ter

certeza de que pelo menos uma arquitetura aplica-se ao sistema permitindo sua construção. Nesse

momento poderá ser necessário implementar parte da arquitetura para assegurar-se que os riscos são

aceitáveis.

OBJETIVO 04: ENTENDER O CUSTO, CRONOGRAMA E RISCOS DO PROJETO Compreender o que desenvolver é importante mas determinar os custos e prazos é crucial. Geralmente o

Business Case documenta o valor econômico de um produto expressando termos quantitativos como seu

ROI(Returno n Invenstiment).

OBJETIVO 05: DEFINIR PROCESSOS E FERRAMENTAS É importante que toda a equipe compartilhe uma visão de como o produto será desenvolvimento, ou seja,

qual processo será seguido. Dessa forma, você deve definir qual IDE, ferramenta de gerenciamento de

requisitos, modelagem visual, Configuration and Change Management, etc deverão ser utilizadas.


21

CHAPTER 7: FASE ELABORAÇÃO Essa é a fase na qual a diferenças com a abordagem cascata fica mais evidente em relação ao modelo

iterativo ficando claro as vantagens deste segundo.

OBJETIVOS DA FASE O objetivo da fase de Elaboração é definir e consolidar uma arquitetura do sistema provendo um base

estável para as atividades de desenho e implementação. Nessa fase você endereça riscos associados com:

- Requisitos (você está construindo a aplicação correta?);

- Arquitetura (você está construindo a solução correta?);

- Custo e Cronograma (você realmente está no caminho)?

- Processo e Ferramentas (você tem o processo e ferramenta corretos para fazer o trabalho?).

ELABORAÇÃO E ITERAÇÕES Muitos riscos são mitigados quando uma Arquitetura Executável é produzida, ou seja, um subconjunto

compilável dos principais aspectos do sistema para fins de teste e validação da arquitetura. Se um sistema

de mesma característica já foi construído no passado pode-se atingir esse objetivo em uma única iteração.

Porém, se você não possuir conhecimento no domínio do sistema ou seja uma nova tecnologia esse objetivo

poderá requerer 02 ou 03 iterações para ser atingido e assim mitigar o risco.

PRIMEIRA ITERAÇÃO - Design, implement, and test a small number of critical scenarios to identify what type of architecture

and architectural mechanism you need. Do this as early as possible to mitigate the most crucial risks.

- Identify, implement, and test a small, initial set of architectural mechanisms.

- Do a preliminary logical database design.

- Detail the flow of events of roughly half of the use cases you intend to detail in Elaboration, in order

of decreasing priority.

- Test enough to validate that your architectural risks are mitigated. Do you, for example, have the

right level of performance?

SEGUNDA ITERAÇÃO - Corrija o que nao saiu correto da primeira iteração;

- Implemente os demais cenários relevantes para a arquitetura ;

- Identifique e implemente aspectos técnicos como concorrência, threads, processos, performance,

distribuição;


22

- Implemente uma versão preliminar do banco;

- Detalhes os casos de uso que precisam ser especificados;

- Teste, valide e refine a arquitetura até o ponto que possa ser considerada uma baseline, ou seja,

uma versão estável da arquitetura.

OBJECTIVE 1: GET A MORE DETAILED UNDERSTANDING OF THE REQUIREMENTS By the end of Elaboration, you will want to complete the description of a majority of use cases. Some use

cases may be so simple, or so similar to other use cases but operating on other data, that you can

comfortably postpone them until Construction, or even never formally describe them. Detailing them will

not address any major risks. You should also produce a user-interface prototype for major use cases, if

necessary, to make stakeholders understand what functionality the use case provides. Walk through and test

each use case with a user, using the user-interface prototype to clarify what the user experience will be and

what information is displayed and entered.

You should also continuously update the glossary. In some cases, you may want to Express graphically how

different glossary items relate to each other. You do this by expressing the most important glossary items as

"domain objects" in a small domain model (see Workflow Detail: Develop a Domain Model, in the RUP, for

more information).

At the end of Elaboration, you will have detailed a vast majority of the requirements (probably about 80

percent).

OBJECTIVE 2: DESIGN, IMPLEMENT, VALIDATE, AND BASELINE THE

ARCHITECTURE Architecture key design choices that must be made:

- The most important building blocks of the system, and their interfaces, as well as the decision to

build, buy, or reuse some of these building blocks

- A description of how these building blocks will interact at runtime to implement the most important

scenarios you have identified

- An implementation and testing of a prototype of this architecture to validate that it does work, that

the major technical risks are resolved, and that it has the proper quality attributes: performance,

scalability, and cost.

USE CASOS DE USO SIGNIFICANTES PARA DEFINIR A ARQUITETURA Durante a fase de Iniciação você identificou casos de uso, talvez 20 a 30% como críticos para o sistema. Eles

provavelmente também são significantes para a definição da arquitetura. Também é necessário identificar

certos elementos nos requisitos como os não funcionais que são difíceis, desconhecidos ou apresentam

risco.

DESENHE CASOS DE USO CRÍTICOS O desenho de um caso de uso é chamada realização de caso de uso. Ele descreve como um caso de uso

particular é realizado dentro do modelo de desenho em termos de colaboração de objetos. Voce pode


23

dividir esse trabalho em uma seção de Análise & Design. A seguir os 5 passos mais importantes ao realizar

um caso de uso:

1- Faça um esboço preliminar dos objetos envolvidos na colaboração.

2- Especifique a responsabilidade de cada classe de análise para entender como as classes juntas

podem prover funcionalidades para o caso de uso;

3- Detalhe as classes de análise;

4- Especifique a ordem e como as classes irão comunicar-se para fornecer as funcionalidades do

caso de uso;

5- Transforme as classes de Análise em Classes de Desenho informando seus métodos e atributos.

Casos de uso simples com sequencia limitada tipicamente não requerem todos os passos especialmente o

passo 4.

O próximo passo é agrupar as classes em pacotes de acordo com seu subsistema.

TESTE OS CENÁRIOS CRÍTICOS A melhor de verificar se os riscos de arquitetura foram mitigados é realizando testes sob a arquitetura

executável gerada. Voce precisa verificar:

- Os cenários mais críticos foram implementados e fornecem a devida funcionalidade esperada?

- A arquitetura atende os requisitos de performance esperados?

- A arquitetura suporta a carga de usuários simultanes esperada?

- As interfaces com sistemas externos funcionam corretamente?

- Os principais requisitos não funcionais foram testados?

OBJECTIVE 3: MITIGATE ESSENTIAL RISKS, AND PRODUCE ACCURATE SCHEDULE

AND COST ESTIMATES During Elaboration you mitigate the vast majority of technical risks. Toward the end of Elaboration, you have

more accurate information allowing us to update our

project plan and cost estimate.

- You have detailed the requirements so you understand what system you are building. You update

the Vision accordingly.

- You have implemented a executable architecture of the system, which means that you have solved

many of the most difficult problems;

- You have mitigated the vast majority of risks. This radically reduces the gap between lower- and

upper-range estimates for schedule and cost.

- You understand how effectively you are working with the people, the tools, and the technology at

hand.


24

CHAPTER 8: FASE CONSTRUÇÃO Durante a fase de construção é dado total foco em detalhar o design, implementar e testar para liberar-lo por completo. De fato a fase de construção é a que consome maior tempo, em geral 65% do esforço de todo o projeto e 50% de todo o tempo previsto são dedicados a ela. Apesar de a maioria dos riscos terem sido tratados na fase de Elaboração novos riscos serão descobertos e devem continuar sendo tratados. Porém, esses novos riscos não devem comprometer a arquitetura e caso isso aconteça um bom trabalho não foi feito durante a fase de Elaboração. Especialmente para grandes projetos assegurar a integridade da arquitetura, o desenvolvimento paralelo, a gerencia de configuração e mudanças assim como os testes automatizados podem assegurar o sucesso dessa fase.

OBJECTIVES OF THE CONSTRUCTION PHASE - Minimize development costs and achieve some degree of parallelism;

- Iteratively develop a complete product that is ready to transition to its user community.

CONSTRUCTION AND ITS ITERATIONS In most cases Construction has usually two to four iterations. Iteration planning is largely driven by the parts of use cases that should be implemented. You want to implement the use cases that are most essential to customers, as well as those associated with the most technical risk. Start with only partial implementation of use cases (that is, implement only some of the scenarios within the use case) to drive out quickly as much risk as possible and to get a reasonable implementation before detailing the use cases. Plano de progresso por iteração.


25

OBJECTIVE 1: MINIMIZE DEVELOPMENT COSTS AND ACHIEVE SOME DEGREE OF

PARALLELISM If you have created a baselined, robust executable architecture you can develop a more cost-effective software than would otherwise be the case. This is possible since you can reuse architectural mechanisms; you can work in parallel by organizing around the architecture. One of the many benefits of a robust architecture is that it clearly divides the system responsibilities into well-defined subsystems. Individuals can focus primarily on their assigned subsystem(s). Organizing around the architecture prevents people from stepping on each other's feet.


26

CONFIGURATION MANAGEMENT SYSTEM Here, we describe why you need a CM system and how it benefits you during Construction. As a project progresses, it becomes increasingly complex to track all versions of the many files being created and changed. Especially during iterative development, you are continually creating new versions of files, and you need help with, among others, the following tasks:

- Iterative development means frequent builds. You need to track which version goes into each build.

Sometimes it is the latest version, sometimes an earlier version because the work on a new version

has not been completed.

- Iterative development means that you will try out different solutions to see if you can improve upon

what you have. You need to merge successful solutions into your mainstream development paths.

- As a project grows, it is essential to be able to hide changes made by one team from other teams so

they will not be negatively impacted by code that is not yet working properly.

- For larger projects, you may also want to control who is allowed to make certain types of changes.

- When you notice that you have introduced a defect, you want to be able to go back in time to understand when the defect was introduced.

ENFORCE THE ARCHITECTURE To benefit fully from the work done with the architecture, you need to actively enforce the architecture. You now need to prevent each developer from arbitrarily reinventing solutions for these problems. This can be done through training on the architecture and architectural mechanisms available, coupled with design reviews that include the architects and developers.

You also need to ensure that interfaces of subsystems are not arbitrarily changed and that any changes are properly communicated to other teams to minimize impact on them. This communication can be done through a Configuration Management system, where you, among others, put interfaces under CM.

ENSURE CONTINUAL PROGRESS The following guidelines are proven recipes for success:

- Create one team, with one mission. You want to avoid functionally oriented teams; - Set clear, achievable goals for developers. The developers should agree that the expected

deliverables are achievable. - Continually demonstrate and test code. Measure progress primarily by looking at what code is

compiled and tested. Do not be satisfied with statements such as "we are 90 percent done." Continual demonstration and testing of executable code is the only way to ensure progress.

- Force continuous integration. If possible, do daily builds. For large projects, or projects with poor or nonexistent CM systems.

OBJECTIVE 2: ITERATIVELY DEVELOP A COMPLETE PRODUCT THAT IS READY TO

TRANSITION TO ITS USER COMMUNITY

DESCRIBE THE REMAINING USE CASES AND OTHER REQUIREMENTS As you implement and test a use case, you often need to revisit at least some of the detailed requirements, and in many cases, you may even want to rethink the entire use case as you come up with better solutions.


27

In some systems there are many similar use cases, having the same general sort of functionality, but for different entities or different actors, with different user interfaces. These types of use cases are often left to be detailed in Construction, along with partially detailed use cases.

DESIGN THE DATABASE During Elaboration, you made a first-draft implementation of the database. In the Construction phase, additional columns may be added to tables, views may be created to support query and reporting requirements but major restructuring of tables should not occur.

IMPLEMENT AND UNIT-TEST CODE Developers need to test their implementations continuously to verify that they behave as expected. To test component(s), you may need to design and implement test drivers and test stubs that emulate other components that will interact with the component(s). To increase quality, continuously integrate and test your system. To minimize testing costs, you need to automate regression testing.

EARLY DEPLOYMENTS AND FEEDBACK LOOPS It is crucial to get early feedback on whether the application is useful and provides desired behavior, by exposing it to actual users. For example, maybe it is performing according to requirements, but the requirements do not quite make sense. This is especially important when developing unprecedented applications or applications in unfamiliar domains, where it is difficult to assess what the real requirements are. Future users of the system often do not want to, or have the ability to, spend time on early versions of the application. Based on your needs for feedback and the availability of customers to provide it, you should choose the right approach for getting feedback, which provides value both to the development team and to the future users of the system. These approaches include:

- Bringing a few users to your development environment and demonstrating key capabilities. - Bringing a few users to your development environment and having them use the product for some

time. - Installing the software at a test site and sitting with the users as they are using the software. - For hosted applications, providing some users with early access. You probably need to guide the user

through the application, which may not be stable or intuitive to use at this stage. - Typical results of successful early deployments and feedback loops include verification of whether

requirements are right or need to be modified, feedback on usability and performance, and identification of insufficient capabilities.

- Testing in a development environment that is not equivalent to the target (production) environment may produce misleading results. Organizations that focus on tight quality control may need to invest in a separate environment that is equivalent to that of the target environment. This simulated environment enables frequent test builds and more accurate test results.


28

CHAPTER 9: FASE TRANSIÇÃO The focus of the Transition phase is to ensure that the software fully addresses the needs of its users. The

Transition phase normally spans one or two iterations that include testing the product in preparation for

release and making minor adjustments based on user feedback.

OBJECTIVES OF THE TRANSITION PHASE The Transition phase has the following objectives:

- Validate that user expectations are met. This typically requires some tuning activities such as bug fixing and making enhancements for performance and usability.

- Train users and maintainers to achieve user self-reliability. “Train the Trainer” - Prepare deployment site and convert operational databases. - Prepare for launch-packaging, production, and marketing rollout - Achieve stakeholder concurrence that deployment baselines are complete and consistent with the

evaluation criteria of the vision. - Improve future project performance through lessons learned. You should also determine whether

any work can be reused for other projects.

TRANSITION AND ITERATIONS Most projects have a reasonably simple Transition, working on fixing bugs; the primary focus is

implementation and testing. Occasionally, new features may have to be added, and the iteration is then

similar to a Construction phase iteration in that it requires some work on requirements, analysis and design,

and so on.


29

TRANSITION AND DEVELOPMENT CYCLES For some projects, the end of the current lifecycle may coincide with the start of another lifecycle, leading to the next generation of the same product. For other projects, the end of Transition may coincide with a complete delivery of the artifacts to a third party, who may be responsible for operations, maintenance, and enhancements of the delivered system. One pass through the four RUP phases (Inception, Elaboration, Construction, and Transition) is a Development Cycle. The subsequent cycles are called Evolution Cycles.

OBJECTIVE 1: BETA TEST TO VALIDATE THAT USER EXPECTATIONS ARE MET As you implement change requests, it is essential to have in place a good Configuration Management process as well as comprehensive regression testing. At this stage, builds with incorrect file versions or missing files are common sources of defects. Good CM practices and tools radically reduce these types of errors, and comprehensive regression testing rapidly identifies any introduced defects. Transition Testing As defects are fixed and beta feedback is incorporated, successive builds are tested using a standard test cycle:

- Validate build stability. Execute a subset of tests to validate that the build is stable enough to start detailed test and evaluation.

- Test and evaluate. Implement, execute, and evaluate tests. - Achieve your test objectives, or, in RUP parlance, achieve an acceptable mission. Evaluate test

results against testing objectives and perform additional testing as necessary. - Improve test assets. Improve test artifacts as needed to support the next cycle of testing.

Metrics for Understanding When Transition Will Be Complete It is not always obvious when you can end Transition. To help determine when Transition will be complete, you can analyze defect metrics and test metrics. This analysis can help you answer questions such as, "When will the quality be good enough?", "How many more defects can we expect to find?", and "When will we have tested all functionality?" Through trend analysis of this figure, you can estimate that 20 open defects will be reached around March 9, and another week would be needed to come down to below 5 defects.


30

Test Metrics Another important set of metrics of great value is test metrics, such as test completion. If, for example, only 60 percent of planned tests are completed, you should expect to find many more defects once testing is completed. You can predict how many new defects can be expected by determining how many defects are typically found per test case and multiplying that by the number of test cases yet to be executed and analyzed. This can be expressed with the formula: DRemaining = DAverage x ( TCTotal - TCExecuted) Where DRemaining = number of defects yet to be found DAverage = average number of defects found per test case TCTotal = total number of test cases TCExecuted = number of test cases executed so far You do not want to deliver a system that has not been properly tested. By analyzing the trend of completed and successful test cases, you can predict when you will have completed the test effort, yet another data point allowing you to decide when it is appropriate to end Transition.


31

PART III: ADOPTING THE RUP

CHAPTER 11: ADOPTING RUP The reason for introducing the RUP and supporting tools into your organization is to obtain business benefits measured in improved project results. To be worth the investment, process improvement through effective use of the RUP and associated technologies must ultimately lead to higher quality systems, lower cost, or shorter time to market. Time spent on process improvement easily becomes overhead unless these objectives are clear in everyone's mind. A common mistake is to roll out too "heavyweight" a version of the RUP, where you have too many artifacts that need to be produced by the project team. Whenever possible, you should minimize the number of artifacts to be produced, without compromising on quality. The following five steps will help you when introducing the RUP product in the beginning of your project: Assess. Assess what issues your team has been facing in the past, what impact they have on your business, and which issues are of the highest business priority to address for the future. Plan. Plan the rollout activities, such as customization of the process, training and mentoring and purchase of required tools. Configure and customize. Do necessary configuration and customization of the process, tool environments, and training material. Execute. Deploy the process and tools in your project, train and mentor project members, and run your project. Evaluate. Evaluate project performance and compare it to expectations as expressed in the business case.

ADOPTING THE RUP IN A LARGE ORGANIZATION When looking at your organization's problems, you may feel the strong desire to fix everything at once, especially since many of these problems occur simultaneously. Organizations, just like individuals, can accommodate only a limited amount of change, and different organizations are better prepared for change than others. To understand the organizational capacity for change, we recommend that you interview people in the organization to understand their attitudes and willingness to change.

Problems Encountered Business Impact Possible Solutions

Product builds have missing files or old versions of files.

Quality is reduced. Introduce a Configuration and Change Management system

Development is based on old files.

Time is spent on rediscovering old defects.

Rational ClearCase and Rational ClearQuest.

Developers in each other's way, preventing parallel development.

Longer lead-time, resulting in longer time-to-market.

Introduce a Configuration and Change Management system providing private workspaces and diff & merge capabilities

Rational ClearCase and Rational ClearQuest.


32

Iterative development introduces increased testing burden on regression testing.

Test costs increase or defects are found late, making them more costly to fix.

Automate testing. Example: Rational Suite TextStudio.

Unclear which requirements are current, and when they were changed.

Investment in development are done toward obsolete requirements , increasing development costs and decreasing customer satisfaction.

Manage requirements using a requirements management tool. Example: Rational RequisitePro.

Unclear which change requests should be implemented, and which should not. Changes that should be implemented are not implemented, and vice versa.

Reduced quality and increased development costs.

Introduce a change and defect tracking system. Rational ClearQuest.

The process improvement program consists of a combination of the following types of projects:

- Process and tool enhancement projects (PTEPs), which aim to produce new baselined versions of processes and supporting tool environments used for internal deployments. They provide the right infrastructure to facilitate the introduction of the process and tools. Just as a RUP project is divided, we divide the PTEP into four phases, in which each phase has the same name and business objectives as a software development project using the RUP.

- Pilot projects, which are software development projects with the added objective to investigate the organization's ability to adopt a certain process and tool environment and verify that the process and tool environment is sound.

- Software development projects which use the processes and supporting tool environments.


33

CHAPTER 12: CONFIGURING, INSTANTIATING, AND CUSTOMIZING RUP Traditional planning of engineering projects is far too often organized from the top down and around a

product breakdown, a style of planning that was inherited from the manufacturing and construction

industries. Although at some point the plan needs to acknowledge the artifacts and the product structure,

this is often done too early in the software development, at a point when little is known about the product.

KEY CONCEPTS Let's start by revisiting a few key concepts.

Cycle

A development cycle is the period of time that elapses from the very start of the project until product

release. We often distinguish initial development cycles from evolution cycles or maintenance cycles. An

initial development cycle, leading to the very first release of a system, is often referred to as a "green-field"

development. An evolution cycle is referred as “brown-filed” development.

This figure indicates an average breakdown for an initial development cycle.

Phases The phases are important, not because of what is executed or because of their length, but because of what is achieved at the major milestone that concludes them. Iteration Inside each phase there may be one or more iterations. Software is developed in each iteration, which is concluded by a minor milestone, including a release (internal or external) that is a point for assessing the project progress. The software product grows incrementally as you iterate over the activities. Build Inside each iteration, the various developers or teams may produce software builds. Often the last build of the iteration is part of the iteration's release. Time-Boxing Time-boxing is a top-down technique that tries to confine the achievement of a specific goal within a small time interval. It is not about setting impossible or irrational goals and delivering anything of poor quality within the time-box. It is a tool used to balance scope and schedule but also to force convergence and to limit analysis-paralysis or gold plating.

COARSE-GRAIN AND FINE-GRAIN PLANS: PROJECT PLANS AND ITERATION PLANS Because the iterative process is highly dynamic and adaptive and is meant to accommodate changes to goals and tactics, there is no purpose in spending an inordinate amount of time producing detailed plans that extend beyond the current project horizon. Such plans are difficult to maintain, rapidly become obsolete, and are typically ignored by the performing organization after a few weeks.


34

In an iterative process, two kinds of plans are recommended:

- A coarse-grained plan. The project plan, which focuses on phases and iterations, their objectives, and the overall staffing level

- A series of fine-grained plans. The iteration plans, one per iteration, which bring RUP activities and individual resources into perspective

The Project Plan Top management and external stakeholders are rarely interested in the details of who is doing what and when. They are interested in the final product. The project plan is a coarse-grained plan. The project plan includes the following:

- Dates of the major milestones: o Lifecycle Objective (LCO) Milestone. End of Inception, project well scoped and funded o Lifecycle Architecture (LCA) Milestone. End of Elaboration, architecture complete,

requirements baseline set o Initial Operational Capability (IOC) Milestone. End of Construction, first beta release o Product Release (PR) Milestone. End of Transition and of the development cycle

- Staffing profile. What resources are required over time. - Dates of minor milestones. End of iterations; include primary objectives, if known.

The project plan (usually one to two pages) is produced very early in the Inception phase and updated as often as necessary. The Iteration Plan An iteration plan is a fine-grained, time-boxed plan; there is one plan per iteration. A project usually has two iteration plans "active" at any time:

- The current iteration plan (for the current iteration), which is used to track progress - The next iteration plan (for the upcoming iteration), which is built toward the second half of the

current iteration and is ready at the end of the current iteration While the team is executing the current iteration plan, the project manager is writing the plan for the next iteration. The iteration plan is built using traditional planning techniques and tools (Gantt charts and so on) to define the tasks and help allocate them to individuals and teams. You can picture the iteration plan as a window moving through the project plan (or phase plan), acting as a magnifier.


35

BUILDING A PROJECT PLAN To build a project plan you will need an initial estimate of the overall size of the project. Most projects will not function efficiently if staffed with a constant number of people.

Once you have planted the dates of the major milestones on the calendar, the next questions to address are how many iterations and how long. Many avid fans of iterative development think of an iteration as lasting around two to five weeks. This may be fine for most small- to medium-sized projects. Iterations need not all be the same length: Their length will vary according to their objectives. Typically, Elaboration iterations will be longer than Construction iterations. Determining the Number of Iterations For a more substantial project, in its initial development cycle, the norm would be

- Inception: 1 iteration, possibly producing a prototype. - Elaboration: 2 iterations, one to develop an initial architectural prototype and one to finalize the

architectural baseline.


36

- Construction: 2 iterations, one to expose a partial system and one to mature it for beta testing. - Transition: 1 iteration, to go from beta to full product release.

For a large project, with many unknown factors, new technologies, and the like, there may be a case for additional iterations:

- Inception: An additional iteration to allow for more prototyping (so 2 iterations in all). - Elaboration: An additional iteration to allow different technologies to be explored, or to phase in the

introduction of architectural solutions, bringing this phase to 3 iterations. - Construction: An additional iteration because of the sheer size of the product, also 3 iterations. - Transition: An additional iteration to allow for operational feedback halfway through.

table can be used as a starting point when deciding how many iterations to have.

Iteration Length As a first approximation, obtain the iteration length by dividing the length of the phase by the number of iterations. Then also take into account major holidays, planned vacations, or plant closures to adjust the project plan to a realistic time frame. Iteration Objectives Once you have an idea of the number of iterations in your coarse-grained plan, you need to define the contents of each iteration. It is even a good idea to find a name or title to qualify the release you have at the end of each iteration, and to help people gain a better focus on the next target.

Example: Names of Iterations for a Private Telephone Switch Iteration 1: Local station-to-station call Iteration 2: Add external calls and subscriber management Iteration 3: Add voice mail and conference calls…And so on

Again, do not put too much effort into this. You will revise these several times throughout the cycle. Planning is iterative and adaptive. Staffing the Project The next step is to allocate the right level of resources to the project alongside the lifecycle. Figure 12.4 shows a typical staffing profile.


37

ITERATION PLANNING The development of an iteration plan has four steps:

- Determine the iteration scope. Determine the intent—what you want to accomplish in the iteration. - Define iteration evaluation criteria. Define how to objectively evaluate the accomplishments at the

end of the iteration; specify which artifacts will be worked on. - Define iteration activities. Establish what needs to be done and on which artifacts. - Assign responsibilities. Allocate resources to execute the activities.

Inception and Elaboration Use a top-down approach, with rough estimates derived from other projects, as a basis for your planning assumptions—you probably did this for the project plan. Construction and Transition You can proceed with a bottom-up, artifact-based planning, using the elements of the design, such as class, component, subsystem, use case, test case, and so on, as well as any measures from previous iterations to estimate the effort.

ESTIMATING By far the best tool a project manager can use to estimate a project, a phase, an iteration, or a simple activity is historical data. The most basic approach is to record effort, duration, or size estimates as well as estimate processes and assumptions, and then record the actual results from each estimated activity. For the project plan, early in Inception, it is best to calibrate the new project relative to another one for which you already know the total effort.

OPTIMIZING THE PROJECT PLAN Beyond the basic recipe just described for planning an iterative project, the bold project manager can attempt to optimize the project plan. A certain amount of overlap can occur between one iteration and the next, and this is probably healthy to keep everyone busy. The planning of the next iteration should not wait until you come to a complete stop. Don't lose sight of the fact that to reap the benefits from iterative development, you need the lessons


38

learned from iteration N to do a better job in iteration N+1—too much overlap will defeat this built-in mechanism for refining requirements, goals, and process.

Documents

Resumo Livro RUP Made Easy