Você está na página 1de 17

Phillip Kruchten Rational Unified

Process Made Easy. Addison Wesley


www.ibm.com (RMC)
www.wthreex.com/rup

Introduo
Fernando Pedrosa fpedrosa@gmail.com

Fernando Pedrosa Lopes

Segundo Kruchten:
Necessidades do usurio mal
compreendidas
Falta de habilidade para tratar
mudanas de requisitos
Descoberta tardia de problemas srios
Baixa qualidade de software
Problemas com papis e
responsabilidades
Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Criado por Booch, Jacobson e


Rumbaugh, e implementado pela
Rational
Em seu livro, os amigos se referem a
ele como Unified Process. RUP o
nome comercial dado pela Rational
Em 2003 a IBM compra a Rational. RUP
continua sendo, at hoje, o principal
framework de processos no qual as
metodologias se baseiam

Fernando Pedrosa Lopes

uma plataforma de processos

Adaptvel
Deve ser configurada para selecionar os
elementos apropriados s necessidades da
organizao

Iterativo e Incremental
O ciclo de vida do produto dividido em
iteraes, cada uma entregando
incrementos (partes acabadas) do software

Guiado por casos de uso


Os casos de uso conectam todas as fases e
vises, sendo utilizados por todos os
stakeholders

Fornece atividades, artefatos e guias


ligados
s ferramentas IBM/Rational
linguagem UML

Fernando Pedrosa Lopes

Centrado na arquitetura
Envolve aspectos estticos e dinmicos
Evolui a partir das necessidades do produto

Fernando Pedrosa Lopes

Orientado a Objetos

(CAIXA - CESPE 2010)


[45] No se utilizam diagramas de caso de uso em projetos
desenvolvidos de acordo com o RUP (rational unified process).

Componentes so construdos atravs de


Objetos e estes colaboram entre si para
realizar os casos de uso

(CEHAP CESPE 2009)


[27A] O RUP foi projetado em conjunto com a UML e os processos
de negcios so modelados usando casos de uso que,
posteriormente, sero desenvolvidos para modelar os requisitos
de sistema.

Planejado por riscos


Os riscos so analisados continuamente e
os de maior criticidade so tratados
prioritariamente

Fernando Pedrosa Lopes

(TCU CESPE 2010)


[109] O processo unificado de software centrado na arquitetura
e orientado por casos de uso, o que sugere um fluxo de processo
iterativo e incremental.
7

Fernando Pedrosa Lopes

Eixo
dinmico

(PETROBRAS - CESGRANRIO 2008)


[48] Um princpio fundamental do Processo Unificado
(A) ser centrado em arquitetura.
(B) empregar times auto-dirigidos e auto-organizados.
(C) o desenvolvimento em cascata.
(D) a programao em pares.
(E) a propriedade coletiva do cdigo fonte.

Eixo
esttico

(BASA CESPE 2010)


[80] A metodologia RUP, que consiste no desenvolvimento
interativo com foco na reduo dos riscos do projeto, agrega um
valor real organizao que necessita manter padres relativos
s comunicaes externas e comunicao com a equipe de
desenvolvimento.
Fernando Pedrosa Lopes

O RUP tem duas dimenses


A primeira dimenso representa o
aspecto dinmico do processo

A segunda dimenso representa o


aspecto esttico do processo

(EMBASA CESPE 2009)


[70] A primeira dimenso do RUP representa o aspecto dinmico
do processo quando ele aprovado e expressa em termos de
fases, iteraes e marcos.

Eixo vertical
Expresso em termos de componentes,
disciplinas, atividades, artefatos, papis
Fernando Pedrosa Lopes

10

(SECONT/ES - CESPE 2010)


[76] O processo unificado estruturado em duas dimenses. A
dimenso horizontal representa o aspecto dinmico do
processo, onde esto representadas suas fases, s quais esto
associados marcos que determinam sua finalizao. Na outra
dimenso esto representadas as disciplinas, que agrupam
logicamente as atividades. possvel haver disciplina que no
esteja presente em todas as fases.

Eixo horizontal
Expresso em termos de fases, marcos e
iteraes

Fernando Pedrosa Lopes

11

Fernando Pedrosa Lopes

12

Processo de Desenvolvimento
Conjunto de mtodos e prticas bem
definidas

Com responsveis
Entradas/Sadas
Ordem de precedncia

Inclui:
Ferramentas, Tecnologias, Pessoas, Padres e
guias

Quem? O qu? Como? Quando?

Fernando Pedrosa Lopes

Modelos, Padres
e Guias

13

Fernando Pedrosa Lopes

14

Qualidade de software
Maior produtividade
Maior previsibilidade
Maior controle sobre custos e prazos

Equipes Treinadas

Ferramentas

Linguagem Padro

Fernando Pedrosa Lopes

15

Fases e Iteraes
Disciplinas/Fluxo de Atividades
Atividades/Tarefas
Artefatos/Produtos de Trabalho
Papis

Fernando Pedrosa Lopes

17

Fernando Pedrosa Lopes

16

Concepo

Elaborao

Construo

Transio

Estabelecer
o escopo, e
estimar
custos e
riscos

Assegurar
que os
principais
riscos foram
diminudos
e definir
uma
arquitetura
executvel

Desenvolver
de modo
iterativo e
incremental
um produto
completo
para a
Transio

Disponibilizar
o Software
para seus
usurios
finais

Fernando Pedrosa Lopes

18

Cada fase termina com um Marco

Fernando Pedrosa Lopes

Cada passagem pela sequncia


de disciplinas do projeto se
chama iterao

19

Fernando Pedrosa Lopes

20

(SERPRO CESPE 2010)


[72] O framework de processo RUP (rational unified process)
organiza o ciclo de vida de um produto de software desde o
incio de sua concepo at a sua aposentadoria, na seguinte
sequncia de etapas: concepo, elaborao, construo e
transio

Cada fase pode ser dividida em


iteraes

(CEHAP CESPE 2009)


[27 C] Ao contrrio do modelo em cascata, no qual as fases
coincidem com as atividades do processo, o RUP compreende
as fases de concepo, elaborao, construo e transio.

Fernando Pedrosa Lopes

21

(MPE/RR CESPE 2008)


[80] No Processo Unificado, a vida de um sistema dividida em
ciclos; cada ciclo, por sua vez, dividido em fases e, entre as
fases, tem-se a fase Construo, na qual as atividades visam
capturar requisitos ainda no capturados na fase anterior e
produzir uma arquitetura executvel, a ser usada na fase
Elaborao.

Fernando Pedrosa Lopes

22

(ANATEL - CESPE 2006)


[86] O ciclo apresentado na figura, que compreende uma
execuo seqenciada das atividades de modelagem de
negcios, requisitos, anlise e desenho, implementao, testes,
avaliao etc., forma o denominado ciclo de vida de software
no modelo RUP.

[81] O Processo Unificado iterativo e incremental. Ao final de


cada iterao, a qual um miniprojeto, os modelos que
representam o sistema encontram-se em um determinado
estado, denominado baseline. As atividades de cada fase de um
ciclo de vida podem ser distribudas entre vrias iteraes.

Fernando Pedrosa Lopes

23

Fernando Pedrosa Lopes

24

So um conjunto de atividades
(fluxo de trabalho) relacionadas a
uma rea de interesse do
projeto
Ajudam a compreender o projeto
a partir de uma perspectiva em
cascata

Algumas disciplinas esto


associadas a conjuntos
especficos de modelos

Fernando Pedrosa Lopes

25

Cada disciplina
possui um fluxo
de trabalho (ex:
Anlise e Design)

Fernando Pedrosa Lopes

Disciplinas bsicas
M odelagem de
Negcios

Requisitos
A nlise e projeto
I mplementao
Testes
I mplantao

26

Disciplinas de suporte
G erenciamento de Projeto
G erenc. de configurao e
mudanas

A mbiente

MRAITIGGA
Fernando Pedrosa Lopes

27

Definem o comportamento e as
responsabilidades no processo
Karina

Programador

Fbio
ris
Lus
Jorge

Testador

No representam pessoas!

Fernando Pedrosa Lopes

28

Unidade de trabalho
desempenhada por um papel
Inseridas no contexto de uma
Disciplina
Compostas de:

Finalidade
Passos
Entradas e sadas
Papel responsvel
Guias e padres
Fernando Pedrosa Lopes

30

So o resultado de um processo
de trabalho
Utilizados como entradas e/ou
sadas na execuo das
atividades
Podem ser:

Papis executam Atividades que


geram Artefatos

Modelos
Documentos
Cdigo fonte
Executveis, etc
Fernando Pedrosa Lopes

31

Fernando Pedrosa Lopes

32

Cada disciplina tem uma viso geral dos


artefatos relacionados (ex: Requisitos)

Cada disciplina
tem uma viso
geral de
atividades
executadas
Ex:
Disciplina de
Requisitos

Fernando Pedrosa Lopes

33

(MPE/RR - CESPE 2008)


[79] No Processo Unificado, atividades so organizadas em
fluxos de atividades. Algumas atividades produzem artefatos,
que podem ser de engenharia ou gerenciais. Entre os artefatos
criados, h modelos que visam especificar o sistema a partir de
certos pontos de vista e nveis de abstrao.

34

[32-D] Um papel uma definio abstrata de um conjunto de


atividades executadas e dos respectivos artefatos. Exemplos de
papis no RUP so: analistas, desenvolvedores e testadores.
Explicitamente, papis de gerentes no fazem parte dos papis
possveis no RUP.
[32-E] As disciplinas de engenharia do RUP so: modelagem de
negcios; requisitos; anlise e projeto; implementao; teste;
qualidade; e implantao.

(TRE/MT CESPE 2010)


[32-C] As disciplinas de suporte (apoio) do RUP so:
gerenciamento de classes; gerenciamento de produto; e
ambiente.

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

35

Fernando Pedrosa Lopes

36

Fernando Pedrosa Lopes

37

Desenvolvimento Iterativo lida com


mudanas

Fernando Pedrosa Lopes

Diminui riscos

Os riscos so reduzidos mais cedo, pois


os elementos so integrados
progressivamente

A melhoria e o refinamento do produto


so facilitados, tornando-o mais robusto

39

Fernando Pedrosa Lopes

40

Com a abordagem em cascata, tudo


parece bem at quase no final do
projeto; s vezes, at a metade da
integrao. A, tudo desmorona. Com a
abordagem iterativa, muito difcil
esconder a verdade durante muito
tempo cliente da Rational

Incorporam um conjunto quase


seqencial de atividades:

Fernando Pedrosa Lopes

Aumenta o reuso
Identificar partes comuns quando esto
parcialmente projetadas ou
implementadas mais fcil que
identificar todas as semelhanas no
incio

Busca melhor qualidade

Fernando Pedrosa Lopes

Aprende e melhora
As organizaes podem aprender a
partir dessa abordagem e melhorar seus
processos

As tticas e os requisitos variveis so


acomodados

38

41

Fernando Pedrosa Lopes

42

(TRE/MT - CESPE 2010)


[44-A] Uma das principais caractersticas do RUP o uso da
iterao, que, por meio de refinamentos sucessivos, melhora o
entendimento do problema.

Jogue fora um pouco do trabalho


durante o caminho, para no ter
que jogar todo o trabalho fora ao
final. Grady Booch

Fernando Pedrosa Lopes

[44-C] Pelo fato de o RUP ser muito complexo, seu foco evita a
reduo dos riscos do projeto. Essa fase tratada diretamente
na UML.

43

Fernando Pedrosa Lopes

44

Um requisito uma condio ou uma


restrio com a qual o sistema dever
estar em conformidade
O gerenciamento de requisitos uma
abordagem sistemtica para:
Localizar,
Documentar,
Organizar e Controlar os requisitos
variveis em um sistema.

Fernando Pedrosa Lopes

45

Nem sempre os requisitos so


bvios e podem vir de vrias fontes.

H vrias partes interessadas


O nmero de requisitos pode se
tornar impossvel de gerenciar se
eles no forem controlados

Os requisitos so alterados

Requisitos relacionam-se entre si,


mas deve haver consistncia nos
relacionamentos
Cada requisito diferente, eles no
so igualmente importantes ou
fceis de entender

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

47

Fernando Pedrosa Lopes

46

48

Analise o problema

Entenda o problema por trs do


problema

Entenda a necessidade das partes


interessadas
Todos querem algo. Determine qual a
melhor fonte

Estabelea um vocabulrio comum

Utilize tcnicas de elicitao de


requisitos

Proponha solues em alto nvel

Faa acordos, balanceie prioridades

Fernando Pedrosa Lopes

49

Defina o sistema

Fernando Pedrosa Lopes

50

Gerencie requisitos variveis

Defina o que sistema deve fazer, em


termos gerais, utilizando linguagem
natural e grfica

Garanta que os requisitos tenham uma


estrutura que os tornem facilmente
atualizveis

Gerencie o escopo do sistema

Rastreie os requisitos

O que est dentro? O que est fora?


Estabelea prioridades!

Fernando Pedrosa Lopes

51

O RUP recomenda a utilizao de


Casos de Uso como mtodo para a
organizao dos requisitos
funcionais

Em vez de fazer uma lista de


requisitos, organize-os na viso de
como o usurio poder utilizar o
sistema

52

Um caso de uso define um conjunto


de cenrios
Cada cenrio descreve o
comportamento do sistema em
termos de sequncias de aes
Um caso de uso deve produzir um
resultado de valor observvel para
um ator
Atores so as entidades que interagem
com o sistema

Utilize Casos de Uso!


Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

53

Fernando Pedrosa Lopes

54

Clientes

Para entenderem o comportamento do


sistema e aprovar o fluxo de eventos

Utilizam os casos de uso como base para


gerar casos de teste

Arquitetos de Software

Para identificar caractersticas da


arquitetura

Gerentes
Para planejar e acompanhar o progresso do
projeto

Analistas, Projetistas, Desenvolvedores

Para entender o comportamento do sistema


e refin-lo

Fernando Pedrosa Lopes

Testadores

E outras partes interessadas...

Por isso se diz que o RUP guiado por


Casos de Uso

55

Fernando Pedrosa Lopes

56

57

Fernando Pedrosa Lopes

58

(EMBASA CESPE 2010)


[72] No RUP, os manuais dos sistemas e as rotinas de teste so
definidos a partir dos casos de uso. Entretanto, os elementos
da arquitetura e a estratgia de implantao do sistema, por se
relacionarem com a infraestrutura e no com os requisitos
funcionais, no so definidos com base nos casos de uso.

Fernando Pedrosa Lopes

Segundo a IEEE:

Arquitetura de Software inclui:

O conceito de mais alto nvel de


um sistema em seu ambiente

A arquitetura de um sistema a sua


organizao ou estrutura de
componentes significativos que
interagem atravs de interfaces

Fernando Pedrosa Lopes

59

As decises significativas sobre a


organizao de um sistema
A seleo de elementos
estruturadores e suas interfaces
A especificao do comportamento
dos elementos do sistema e como
eles colaboram entre si

Fernando Pedrosa Lopes

60

10

No se preocupa apenas com


estrutura e comportamento, mas
tambm com:

Grupos coesos de cdigo fonte ou


executvel com interfaces e
comportamentos bem definidos

Funcionalidade

Fornecem forte encapsulamento de


contedo

Desempenho
Segurana

Substituveis

Reuso

Exemplos: mdulos, pacotes,


subsistemas, componentes OTS

Manutenibilidade
Decises tecnolgicas e econmicas, ...
Fernando Pedrosa Lopes

<<Segurana>>

Autorizar
Autenticar
...

61

Impresso
Gerao de
planilhas
...

Log
Monitoramento
...

Aonde eles
esto
localizados?

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

<<Relatrios>>

Como estes
componentes
colaboram
entre si?

<<Servios>>

Quais so suas
interfaces?

O que so?

62

Permite reuso em grande escala


Permite gerenciar a complexidade
do projeto e manter a integridade
do sistema
Identifica, isola, projeta,
desenvolve e testa pedaos bem
formados do sistema
Possibilita usar componentes de
prateleira (off the shelf)

63

Fernando Pedrosa Lopes

64

65

Fernando Pedrosa Lopes

66

No RUP a arquitetura representada


por uma srie de vises de
arquitetura diferentes
Em sua essncia, as Vises so
fragmentos que ilustram os
elementos significativos em termos
de arquitetura
conhecido como o modelo de
viso 4+1
Fernando Pedrosa Lopes

11

Contm Casos de Uso e cenrios


que abrangem comportamentos
significativos em termos de
arquitetura, classes ou riscos
tcnicos
uma viso obrigatria do
documento de arquitetura de
software

Fernando Pedrosa Lopes

67

Fernando Pedrosa Lopes

68

69

Fernando Pedrosa Lopes

70

Contm as classes de projeto mais


importantes e sua organizao em
pacotes e subsistemas, e a
organizao desses pacotes em
camadas
uma viso obrigatria do
documento de arquitetura de
software

Fernando Pedrosa Lopes

Contm uma viso geral do Modelo de


Implementao e sua organizao em
termos de mdulos em pacotes e
camadas

Detalha os pacotes e mdulos da Viso


Lgica (detalhes fsicos)

uma viso opcional do documento de


arquitetura de software

uma viso opcional do documento


de arquitetura de software
S precisa ser usada se o sistema tiver
alto grau de paralelismo

Deve ser usada apenas se a implementao


no for derivada diretamente do modelo de
projeto (isto , h detalhes adicionais)
Fernando Pedrosa Lopes

Contm a descrio das tarefas


(processos e threads) envolvidas,
suas interaes e configuraes e a
alocao dos objetos e classes de
projeto em tarefas

71

Fernando Pedrosa Lopes

72

12

Caixa Eletrnico

Contm a descrio dos vrios ns


fsicos do sistema e a alocao de
tarefas atribudas a eles
uma viso opcional do documento
de arquitetura de software
S precisar ser usada se o sistema
estiver distribudo em vrios ns fsicos

Fernando Pedrosa Lopes

73

Fernando Pedrosa Lopes

74

(TRE/BA - CESPE 2010)


[62] Na engenharia de software baseada em componentes, na
qual se supe que partes do sistema j existam, o processo de
desenvolvimento concentra-se mais na integrao dessas
partes que no seu desenvolvimento a partir do incio. Essa
abordagem baseada em reso para o desenvolvimento de
sistemas de software.
(SAD/PE - CESPE 2010)
[35-D] desejvel que o valor da coeso e o do acoplamento,
duas importantes propriedades da arquitetura de um software,
sejam maximizados durante a engenharia de software.

Fernando Pedrosa Lopes

75

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

77

76

Fazer uso de notao de design


grfica e visual para capturar o
projeto do software
Permitir que o nvel de abstrao
seja aumentado
Capturar requisitos com preciso
Melhorar a comunicao da equipe
(acabando com a ambiguidade)

Fernando Pedrosa Lopes

78

13

UML Unified Modeling Language

UML
Melhoria da comunicao
Elevao da abstrao

Notao padro para modelagem de


Software
Oferece mltiplas perspectivas de um
problema
Mantm projeto e implementao
consistentes

Fernando Pedrosa Lopes

Processo
Melhores prticas
O que fazer
Como fazer
Responsabilidades

Ferramenta
Produtividade

79

Fernando Pedrosa Lopes

80

81

Fernando Pedrosa Lopes

82

(TCU - CESPE 2010)


[108] UML (unified modeling language) uma tecnologia
concorrente com o processo unificado, no que diz respeito ao
apoio prtica de engenharia de software orientada a objetos.
(TJ/CE - CESPE 2008)
[90] O modelo de ciclo de vida prescrito pela metodologia RUP
iterativo, incremental, direcionado por riscos, adota as reas
de processos de gerncia de processos prescritas pelo modelo
CMMI e baseado em modelagem visual com UML e
ferramentas CASE.

Fernando Pedrosa Lopes

Para as finalidades do RUP,


definida como:

Controle da Qualidade
Tem foco no produto, e em encontrar
defeitos especficos

...a caracterstica de ter demonstrado a

realizao da criao de um produto que


atende ou excede os requisitos
acordados, conforme avaliado por
medidas e critrios acordados, e que
criado em um processo acordado

Preza pelos resultados do seu trabalho

Garantia da Qualidade
Tem foco nos processos e como eles
esto sendo executados
Garante que voc est fazendo as
coisas de maneira correta

Fernando Pedrosa Lopes

83

Fernando Pedrosa Lopes

84

14

Qualidade multidimensional

Andamento: progresso do projeto

Variao: diferena entre planejado


e executado

O custo sobe exponencialmente...


Verificar a qualidade durante o ciclo
de vida essencial!

Confiabilidade: robustez
Funcionalidade: casos de uso
implementados

Desempenho: tempo de execuo


em diversas situaes reais
Fernando Pedrosa Lopes

85

Fernando Pedrosa Lopes

86

87

Fernando Pedrosa Lopes

88

(TRE/BA - CESPE 2010)


[53] Uma falha comum em projetos de sistemas
computacionais no assegurar a qualidade do software.
Normalmente, essa questo discutida aps o trmino dos
projetos, ou a qualidade fica sob a responsabilidade de equipe
diferente da equipe de desenvolvimento. O RUP, proposto pela
IBM, um processo que prov uma soluo disciplinada sobre
como assinalar tarefas e responsabilidades dentro de uma
organizao de desenvolvimento de software, porm, no
auxilia no controle do planejamento e verificao da qualidade.

Fernando Pedrosa Lopes

Vrios desenvolvedores

Diferentes equipes

Diferentes locais

Vrias iteraes, releases, produtos,


plataformas

Podem ser
Arquivos-fonte, Executveis, DLLs, etc.
Planos, especificaes, modelos, etc.

Na ausncia de controle disciplinado,


o processo de desenvolvimento
rapidamente se transforma no caos!

Casos de teste, manuais, documentao


de apoio, etc.

Fernando Pedrosa Lopes

Uma entidade que satisfaz algum


propsito para o usurio final e que
pode ser unicamente identificada

89

Esto sob a Gesto da Configurao


Fernando Pedrosa Lopes

90

15

No RUP, abrange as atividades de:

Gerncia de Mudanas o processo


de avaliar, coordenar e decidir sobre
a realizao de mudanas propostas
a itens de configurao (ICs)
Apenas mudanas aprovadas so
implementadas nos ICs e nos
dados e documentos relacionados

Coordenao de atividades e artefatos


Procedimentos repetveis para gerenciar
mudanas sobre os artefatos

Coordenao de iteraes e releases


Mantm o controle sobre os releases ao final
de cada iterao (baselines)

Controle de mudanas no software


Mantm uma estrutura bem definida para
gerenciar mudanas no software

Fernando Pedrosa Lopes

91

(TRE/MT - CESPE 2010)


[32-B] O RUP promove o uso de seis melhores prticas:
desenvolva iterativamente; gerencie requisitos; use arquiteturas
de componentes; modele visualmente (UML); verifique
qualidade de software continuamente; e gerencie mudanas.

Fernando Pedrosa Lopes

92

(BNDES - CESGRANRIO 2009)


[51] A gerncia de desenvolvimento de sistemas de uma
empresa est reformulando seu processo de software. Para
isso, deseja criar uma metodologia de desenvolvimento
baseada no Processo Unificado. A respeito desse processo,
INCORRETO afirmar que o(a)
(A) desenvolvimento iterativo, incremental e orientado por
casos de uso.
(B) caso de uso mais crtico deve ser atacado,
preferencialmente, no final.
(C) fase de transio envolve treinamento de usurios e
assistncia no uso do produto.

Fernando Pedrosa Lopes

93

Fernando Pedrosa Lopes

94

95

Fernando Pedrosa Lopes

96

(D) arquitetura se desenvolve a partir das vises do usurio


expressas em casos de uso.
(E) arquitetura, na fase de construo, estvel, ainda que
possa ser evoluda.

Fernando Pedrosa Lopes

16

Casos de Uso
Aps levantados os
principais requisitos
(fase de Iniciao),
por onde devo
comear?

UC001

UC004

UC002

UC005

feita uma matriz,


que estabelece uma
relao entre a
importncia dos
requisitos e o quo
arriscados eles so

UC003

UC006

Casos de Uso
arriscados
UC007

UC010

UC008

UC011

UC009

UC012

Fernando Pedrosa Lopes

Segundo o RUP, as funcionalidades mais


arriscadas e importantes devem ser
implementadas primeiro

Importncia

UC002

UC003

UC004

UC005

UC006

UC007

10

10

UC008

UC009

UC010

UC011

UC012

10

97

Fernando Pedrosa Lopes

[1] - [45] E, [27A] C, [109] C, [48] A, [80] C (E)

[2] - [76] C, [70] C

[3] - [72] E, [27 C] C, [80] E, [81] C, [86] E

Elas devem ser estabilizadas j nas iteraes da


fase de Elaborao

[4] - [79] C, [32-C] E, [32-D] E, [32-E] E

Ao final da fase de Iniciao, j existe o


planejamento (de alto nvel) do projeto feito

[5] - [44-A] C, [44-C] E

[6] - [72] E

[7] - [62] C, [35-D] E

[8] - [108] E, [90] E

[9] - [53] E

[10] - [32-B] C, [51] B

O detalhamento das funcionalidades feito apenas


para aquelas que sero feitas na prxima iterao

Risco
UC001

Este ciclo de re-planejamento se d ao longo


das iteraes, at o produto estar completo
Fernando Pedrosa Lopes

99

Fernando Pedrosa Lopes

101

Fernando Pedrosa Lopes

98

100

17