01 RUP - Conceitos - Folhetos

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
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
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
Centrado na arquitetura
Envolve aspectos estticos e dinmicos
Evolui a partir das necessidades do produto
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
(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
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.
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
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
11
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?
Modelos, Padres
e Guias
13
14
Qualidade de software
Maior produtividade
Maior previsibilidade
Maior controle sobre custos e prazos
Equipes Treinadas
Ferramentas
Linguagem Padro
15
Fases e Iteraes
Disciplinas/Fluxo de Atividades
Atividades/Tarefas
Artefatos/Produtos de Trabalho
Papis
17
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
18
Cada fase termina com um Marco
Cada passagem pela sequncia

de disciplinas do projeto se
chama iterao
19
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.
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.
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.
23
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
25
Cada disciplina
possui um fluxo
de trabalho (ex:
Anlise e Design)
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
27
Definem o comportamento e as
responsabilidades no processo
Karina
Programador
Fbio
ris
Lus
Jorge
Testador
No representam pessoas!
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
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
31
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
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.
35
36
37
Desenvolvimento Iterativo lida com

mudanas
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
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:
Aumenta o reuso
Identificar partes comuns quando esto
parcialmente projetadas ou
implementadas mais fcil que
identificar todas as semelhanas no
incio
Busca melhor qualidade
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
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
[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
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.
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
47
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
49
Defina o sistema
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!
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!

53
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
Testadores
E outras partes interessadas...
Por isso se diz que o RUP guiado por

Casos de Uso
55
56
57
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.
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
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
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, ...
<<Segurana>>
Autorizar
Autenticar
...
61
Impresso
Gerao de
planilhas
...
Log
Monitoramento
...
Aonde eles
esto
localizados?
<<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
64
65
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
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
67
68
69
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
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)
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
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
73
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.
75
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)
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
Processo
Melhores prticas
O que fazer
Como fazer
Responsabilidades
Ferramenta
Produtividade
79
80
81
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.
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
83
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
85
86
87
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.
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.
Uma entidade que satisfaz algum

propsito para o usurio final e que
pode ser unicamente identificada
89
Esto sob a Gesto da Configurao

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
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.
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.
93
94
95
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.
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
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
[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
99
101
98
100
17

01 RUP - Conceitos - Folhetos

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

01 RUP - Conceitos - Folhetos

Enviado por

Direitos autorais:

Formatos disponíveis

Phillip Kruchten Rational Unified

Process Made Easy. Addison Wesley

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Criado por Booch, Jacobson e

Fernando Pedrosa Lopes

uma plataforma de processos

Guiado por casos de uso

Fornece atividades, artefatos e guias

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

(CAIXA - CESPE 2010)

Componentes so construdos atravs de

(CEHAP CESPE 2009)

Planejado por riscos

Fernando Pedrosa Lopes

(TCU CESPE 2010)

Fernando Pedrosa Lopes

(PETROBRAS - CESGRANRIO 2008)

(BASA CESPE 2010)

O RUP tem duas dimenses

A segunda dimenso representa o

(EMBASA CESPE 2009)

(SECONT/ES - CESPE 2010)

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Quem? O qu? Como? Quando?

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Cada fase termina com um Marco

Fernando Pedrosa Lopes

Cada passagem pela sequncia

Fernando Pedrosa Lopes

(SERPRO CESPE 2010)

Cada fase pode ser dividida em

(CEHAP CESPE 2009)

Fernando Pedrosa Lopes

(MPE/RR CESPE 2008)

Fernando Pedrosa Lopes

(ANATEL - CESPE 2006)

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

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Algumas disciplinas esto

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Papis executam Atividades que

Fernando Pedrosa Lopes

Cada disciplina tem uma viso geral dos

Fernando Pedrosa Lopes

(MPE/RR - CESPE 2008)

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

(TRE/MT CESPE 2010)

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Desenvolvimento Iterativo lida com

Fernando Pedrosa Lopes