Você está na página 1de 23

Ciclos de vida do Software

Conceitos Iniciais
Para que serve
O ciclo de vida a estrutura contendo processos, atividades e tarefas
envolvidas no desenvolvimento, operao e manuteno de um produto de
software, abrangendo a vida do sistema, desde a definio de seus requisitos at o
trmino de seu uso.

Em que situao o tema til


O modelo de ciclo de vida a primeira escolha a ser feita no processo de
software. A partir desta escolha definir-se- desde a maneira mais adequada de
obter as necessidades do cliente, at quando e como o cliente receber sua
primeira verso operacional do sistema.

Processo de Software
Processo de software o conjunto de atividades que constituem o
desenvolvimento de um sistema computacional. Estas atividades so agrupadas em
fases, como: definio de requisitos, anlise, projeto, desenvolvimento, teste e
implantao.

Em cada fase so definidas, alm das suas atividades, as funes e


responsabilidades de cada membro da equipe, e como produto resultante, os
artefatos.

O que diferencia um processo de software do outro a ordem em que


as fases vo ocorrer, o tempo e a nfase dados a cada fase, as atividades
presentes, e os produtos entregues.

Com o crescimento do mercado de software, houve uma tendncia a


repetirem-se os passos e as prticas que deram certo. A etapa seguinte foi a
formalizao em modelos de ciclo de vida. Em outras palavras, os modelos de
ciclo de vida so o esqueleto, ou as estruturas pr-definidas nas quais
encaixamos as fases do processo.
De acordo com a NBR ISO/IEC 12207:1998, o ciclo de vida a Estrutura
contendo processos, atividades e tarefas envolvidas no desenvolvimento, operao
e manuteno de um produto de software, abrangendo a vida do sistema, desde a
definio de seus requisitos at o trmino de seu uso.

O modelo de ciclo de vida a primeira escolha a ser feita no processo de


software. A partir desta escolha definir-se- desde a maneira mais adequada de
obter as necessidades do cliente, at quando e como o cliente receber sua
primeira verso operacional do sistema.

No existe um modelo ideal. O perfil e complexidade do negcio do cliente, o


tempo disponvel, o custo, a equipe, o ambiente operacional so fatores que
influenciaro diretamente na escolha do ciclo de vida de software a ser adotado.

Da mesma forma, tambm difcil uma empresa adotar um nico ciclo de


vida. Na maior parte dos casos, v-se a presena de mais de um ciclo de vida no
processo.

Os ciclos de vida se comportam de maneira sequencial (fases seguem


determinada ordem) e/ou incremental (diviso de escopo) e/ou iterativa
(retroalimentao de fases) e/ou evolutiva (software aprimorado).

Neste contexto, neste artigo apresentaremos alguns modelos de ciclo de


vida, quais sejam:
Cascata
Modelo em V
Incremental
Evolutivo
RAD
Prototipagem
Espiral
Modelo de Ciclo de Vida Associado ao RUP


Modelo em Cascata
Formalizado por Royce em 1970, o modelo mais antigo. Suas atividades
fundamentais so:
anlise e definio de requisitos;
projeto;
implementao;
teste;
integrao.

O modelo em cascata tem o grande mrito de ser o primeiro a impor o


planejamento e o gerenciamento ao processo de software, que antes era casual. O
nome "cascata" foi atribudo em razo da sequncia das fases, onde cada fase s
comea quando a anterior termina; e da transmisso do resultado da fase anterior
como entrada para a fase atual (o fim de cada fase resulta em um documento
aprovado).

Nesse modelo, portanto, dada muita nfase s fases de anlise e projeto


antes de partir para a programao, a fim de que o objetivo do software esteja bem
definido e que sejam evitados retrabalhos, conforme podemos observar na Figura
1.

Figura 1. O modelo em cascata


Devido sua simplicidade, o modelo em cascata fcil de ser entendido pelo
cliente. um modelo que supe um incio e fim claro e determinado, assim como
uma estimativa precisa de custo logo no incio, fatores importantes na conquista do
cliente.

O problema se d depois, quando o cliente, aps esperar at o fim do


processo para receber a primeira verso do sistema, pode no concordar com
ela.

Apesar de cada fase terminar com uma documentao aprovada, certamente


haver lacunas devido a requisitos mal descritos pelo cliente, mal entendido pelo
analista ou por mudana de cenrio na organizao que exija adaptao de
requisitos. O modelo em cascata no prev reviso de fases.

Assim, o risco muito alto, principalmente para sistemas complexos, de


grande porte, afinal o modelo em cascata pressupe uma realidade esttica e bem
conhecida, comparado a uma linha de produo fabril. Mas a rotina do negcio do
cliente no reflete isso. Manipulao de usurios com diferentes habilidades,
ambientes operacionais distintos, tecnologia em crescente evoluo, necessidade
de integrao com outros sistemas (em plataformas antigas ou mais novas),
mudanas organizacionais, at mudanas na legislao do municpio/estado/pas,
pedem um modelo mais flexvel.

Por outro lado, o modelo em cascata adequa-se bem como um "sub-modelo"


para outros modelos. Por exemplo, no modelo "cascata com realimentao"
permite-se que, a cada descoberta da fase posterior, haja uma correo da fase
anterior.


Modelo em V
Neste modelo, do Ministrio de Defesa da Alemanha, do ano de 1992, o modelo em
cascata colocado em forma de "V".

Do lado esquerdo do V ficam da anlise de requisitos at o projeto, a


codificao fica no vrtice e os testes, desenvolvimento, implantao e manuteno,
direita, conforme Figura 2.

Figura 2. O modelo em V

A caracterstica principal desse modelo, que o diferencia do modelo em


cascata, a nfase dada verificao e validao: cada fase do lado esquerdo
gera um plano de teste a ser executado no lado direito.

Mais tarde, o cdigo fonte ser testado, do mais baixo nvel ao nvel
sistmico para confirmar os resultados, seguindo os respectivos planos de teste: o
teste de unidade valida o projeto do programa, o teste de sistema valida o projeto de
sistema e o teste de aceitao do cliente valida a anlise de requisitos.

Da mesma forma que o modelo em cascata, o cliente s recebe a primeira


verso do software no final do ciclo, mas apresenta menos risco, devido ao
planejamento prvio dos testes nas fases de anlise e projeto.

Ciclos de Vida Incremental


Neste modelo, de Mills em 1980, os requisitos do cliente so obtidos, e, de acordo
com a funcionalidade, so agrupados em mdulos. Aps este agrupamento, a
equipe, junto ao cliente, define a prioridade em que cada mdulo ser desenvolvido,
escolha baseada na importncia daquela funcionalidade ao negcio do cliente.

Cada mdulo passar por todas as fases "cascata" de projeto, conforme se


observa na Figura 3, e ser entregue ao cliente um software operacional. Assim, o
cliente receber parte do produto final em menos tempo.

Figura 3. Ciclo de vida Incremental

Como o cliente j trabalhar no primeiro incremento ou mdulo, muito


importante que haja uma especial ateno na integrao dos incrementos, o que
exige muito planejamento, afinal no aceitvel que o cliente se depare com muitos
erros de software a cada incremento, tampouco, que a cada incremento ele precise
se readaptar a grandes mudanas. Uma ateno especial deve ser dada ao
agrupamento dos requisitos e qualidade no desenvolvimento das funes comuns
a todo o sistema, que inevitavelmente devero ser entregues no primeiro
incremento.
Desta forma, alm de atender as necessidades mais crticas do cliente mais
cedo, as partes mais importantes sero, tambm, as partes mais testadas no
ambiente real. Ser mais difcil gastar recursos em conceitos errados, ou que um
mau entendimento dos requisitos alcance uma escala difcil de ser ajustada, visto
que durante todo o projeto haver o feedback do cliente (a opinio do cliente
realimenta o sistema).

Esse ciclo de vida no exige uma equipe muito grande, pois a modularizao
diminui o escopo de cada incremento, e no h um paralelismo nas atividades.
Haver, por outro lado, uma dificuldade em manter a documentao de cada fase
atualizada devido s melhorias no sistema e aos ajustes de requisitos solicitados
pelos clientes.
Modelo Evolutivo
Neste modelo, os requisitos so adquiridos em paralelo evoluo do sistema.

O modelo evolutivo parte do princpio que o cliente no expe todos os


requisitos, ou os requisitos no so to bem conhecidos, ou os requisitos ainda
esto sofrendo mudanas. Desta forma, a anlise feita em cima dos requisitos
conseguidos at ento, e a primeira verso entregue ao cliente. O cliente usa o
software no seu ambiente operacional, e como feedback, esclarece o que no foi
bem entendido e d mais informaes sobre o que precisa e sobre o que deseja (ou
seja, mais requisitos).

A partir deste feedback, nova anlise, projeto e desenvolvimento so


realizados, e uma segunda verso do software entregue ao cliente que,
novamente, retorna com mais feedbacks. Assim, o software vai evoluindo, se
tornando mais completo, at atender todas as necessidades do cliente dentro do
escopo estabelecido. Obtm-se assim a verso final, pelo menos at novos
requisitos aparecerem (ver Figura 4).

Figura 4. Ciclo de vida Evolutivo

A participao constante do cliente uma grande vantagem desse modelo, o


que diminui o risco de m interpretao de requisitos dos modelos que s oferecem
a primeira verso do software no final do processo. Da mesma forma, o software j
atende algumas necessidades do cliente muito mais cedo no processo.

No dada muita nfase documentao, pois a gerao de verses torna


este trabalho muito rduo. Alm disso, como a anlise de requisitos e
desenvolvimento esto sempre acontecendo, a preocupao em documentar todo o
processo pode fazer com que haja atrasos na entrega.

H uma alta necessidade de gerenciamento nesse tipo de modelo, pois a


falta de documentao adequada, o escopo de requisitos no determinado, o
software crescendo e estando ao mesmo tempo em produo podem ter
consequncias negativas. Seguem alguns exemplos:
o sistema nunca terminar, pois o cliente sempre pede uma alterao;
o sistema no ter uma estrutura robusta a falhas nem propcia a uma
fcil manuteno, pelas constantes alteraes;
o cliente mudar de ideia radicalmente entre uma verso e outra ou
revelar um requisito que exija uma verso bem diferente da anterior,
fazendo com que toda a base (de dados ou de programao) precise
ser revista.

Os problemas podem implicar em um grande nus financeiro e de tempo.

muito importante que o cliente esteja ciente do que se trata este ciclo de
vida e que sejam esclarecidos os limites de escopo e de tempo, para que no haja
frustraes de expectativas.


RAD Rapid Application Development
Este modelo formalizado por James Martin em 1991, como uma evoluo da
prototipagem rpida, destaca-se pelo desenvolvimento rpido da aplicao. O ciclo
de vida extremamente comprimido, de forma a encontrarem-se exemplos, na
literatura, de durao de 60 e 90 dias. ideal para clientes buscando lanar
solues pioneiras no mercado.

um ciclo de vida incremental, iterativo, onde prefervel que os requisitos


tenham escopo restrito. A diferena principal do ciclo anterior o forte paralelismo
das atividades, requerendo, assim, mdulos bastante independentes. Aqui os
incrementos so desenvolvidos ao mesmo tempo, por equipes diferentes.

Alm do paralelismo, a conquista do baixo tempo se d graas compresso


da fase de requisitos e da fase de implantao. Isso significa que, na obteno dos
requisitos, costumam-se optar por metodologias mais dinmicas e rpidas, como
workshops ao invs de entrevistas. Permite-se tambm um desenvolvimento inicial
no nvel mais alto de abstrao dos requisitos visto o envolvimento maior do usurio
e visibilidade mais cedo dos prottipos (ver Figura 5).

Figura 5. Ciclo de vida RAD

As fbricas de software que resolvem por adotar este modelo devem ter uma
estrutura prvia diferencial de pessoas e ferramentas, tais como:

Pessoas:
Profissionais experientes (funcional e gerncia);
Profissionais de rpida adaptao;
Equipes de colaborao mtua;
Maior quantidade de pessoas;

Gerenciamento:
Empresas pouco burocrticas que encorajem a eliminao de
obstculos;
Alto controle do tempo;

Uso de Ferramentas:
CASE;
Muita diagramao;
Prvia biblioteca de componentes reutilizveis (APIs, wizards,
templates,...);
Fcil manuteno (ex.: linguagens de programao que
suportem Orientao a Objetos, tratamento de exceo,
ponteiros);
Adoo de ferramentas maduras, pois no h tempo de
atualizar verses e tratar erros inesperados;

Os sistemas desenvolvidos no ciclo RAD tendem a ter uma padronizao de


telas muito forte, devido a bibliotecas reutilizveis e templates, porm tendem a
perder em desempenho do sistema e na anlise de risco (atividades estas que
demandam tempo em qualquer projeto). Assim, prefervel seu uso para softwares
de distribuio pequena.


Prototipagem
Prototipagem a construo de um exemplar do que foi entendido dos requisitos
capturados do cliente. Pode ser considerado um ciclo de vida ou pode ser usado
como ferramenta em outros ciclos de vida.

Um prottipo em engenharia de software pode ser o desenho de uma tela,


um software contendo algumas funcionalidades do sistema. So considerados
operacionais (quando j podem ser utilizados pelo cliente no ambiente real, ou seja,
em produo), ou no operacionais (no esto aptos para serem utilizados em
produo). Os prottipos podem ser descartados, ou reaproveitados para evolurem
at a verso final.

No ciclo de vida de prototipagem, no exigido um conhecimento


aprofundado dos requisitos num primeiro momento. Isso bastante til quando os
requisitos no so totalmente conhecidos, so muitos complexos ou confusos.
Desta forma, se o cliente no sabe expressar o que deseja (o que ocorre bastante
quando no um sistema legado), a melhor maneira de evitar que se perca tempo e
recursos com uma m interpretao a construo de modelos, ou seja, de
prottipos do que o software faria.

Assim, o cliente experimentar, na prtica, como o sistema ou parte dele


funcionar. A partir desse primeiro contato, o cliente esclarece o que no foi bem
interpretado, aprofunda alguns conceitos e at descobre um pouco mais sobre o
que realmente precisa. A partir deste feedback, novos requisitos so colhidos e o
projeto ganha maior profundidade. Outro prottipo gerado e apresentado ao
cliente, que retorna com mais feedbacks. Ou seja, o cliente participa ativamente do
incio ao fim do processo (ver Figura 6).

Figura 6. O modelo e prototipagem (Pressman, adaptado)


A gerao de prottipos pode ser facilitada por ferramentas geradoras de
telas, de relatrios, poupando esforo de programao e diminuindo o tempo de
entrega.

Cada prottipo tem uma finalidade diferente. Um prottipo pode servir para
esclarecer dvidas sobre uma rotina, demonstrar a aparncia das telas, contedo de
tabelas, formato de relatrios. Os prottipos podem tambm ser utilizados para
apresentar opes ao cliente para que ele escolha a que mais lhe agrade, como
opes de navegao, de fluxo de telas, entre outras.

Por isso, muito importante explicar previamente ao cliente que prottipos


so apenas modelos para melhorar a comunicao. Caso contrrio, pode causar
uma frustrao por no funcionar corretamente, ter funes limitadas, ter resposta
lenta, ou a aparncia ruim. Certamente um prottipo construdo para esclarecer uma
rotina provavelmente ter uma cara feia; para demonstrar a aparncia das telas,
no ter funcionalidade; para apresentar o formato dos relatrios, os dados no
sero coerentes.

O cliente far comparaes entre o sistema final e o que foi prometido


atravs do prottipo e pode ficar insatisfeito. Por exemplo, geralmente o prottipo
no acessa rede ou banco de dados, pois as informaes so desenhadas com a
tela, fazendo com que tudo fique muito rpido. J no ambiente operacional haver
uma degradao de desempenho e o cliente pode se decepcionar.

Faz parte de um bom gerenciamento no modelo de prototipagem planejar-se


quais e que funes dos prottipos no operacionais sero reaproveitadas na
verso operacional, para que sua confeco siga as boas prticas de engenharia de
software. Os prottipos no operacionais so construdos com pouca qualidade em
prol da velocidade. Ou seja, no h preocupao na programao, em refinar o
cdigo, em usar comentrios, em aproveitar eficientemente os recursos de hardware
e software, na manuteno, no reuso de componentes e na integrao com outras
funes ou sistemas. Com certeza ser um problema se a equipe sucumbir
presso do cliente, cada vez mais ansioso para ver a verso final daquele trabalho,
e transformar revelia, prottipos no operacionais em operacionais.

O gerente tambm deve se preocupar com o escopo do projeto versus a


quantidade de prottipos, para que no se perca muito tempo nesse processo,
tampouco se transforme num processo de tentativa e erro.

No uma tarefa fcil documentar o modelo de ciclo de vida baseado na


prototipagem devido aos requisitos no serem totalmente conhecidos no primeiro
momento e a consequente quantidade de mudanas ocorridas.


Modelo Espiral
O modelo proposto por Boehm em 1988 trata de uma abordagem cclica das fases
do processo, onde a cada volta ou iterao temos verses evolucionrias do
sistema.

Este um modelo guiado por risco, suporta sistemas complexos e/ou de


grande porte, onde falhas no so tolerveis. Para isso, a cada iterao h uma
atividade dedicada anlise de riscos e apoiada atravs de gerao de prottipos,
no necessariamente operacionais (desenhos de tela, por exemplo) para que haja
um envolvimento constante do cliente nas decises.

Cada iterao ou volta dedicada a uma fase do processo de vida de um


software (viabilidade do projeto, definio de requisitos, desenvolvimento e teste,...).
Ao mesmo tempo, cada volta seccionada em 4 setores, da seguinte forma:

1 Iterao: Viabilidade do projeto:


1.1. Definio de objetivos;
1.2. Avaliao e reduo de riscos;
1.3. Desenvolvimento e validao;
1.4. Planejamento da prxima fase;
2 Iterao: Definio de requisitos do sistema:
2.1. Definio dos objetivos;
2.2. Avaliao e reduo de riscos;
2.3. Desenvolvimento e validao;
2.4. Planejamento da prxima fase;
3 Iterao: Projeto do sistema:
3.1.
3.2.
3.3.
3.4. ...
4 Iterao: Desenvolvimento e teste de unidade
4.1.
4.2.
...
5 Iterao: Implantao
...
Ou, na representao grfica deste modelo conforme Figura 7.
Figura 7. Modelo Espiral

Os quatro setores so explicados da seguinte forma:

1. Na Definio de Objetivos, desempenhos, funcionalidade, entre outros


objetivos, so levantados. Visando alcanar esses objetivos so listadas alternativas
e restries, e cria-se um plano gerencial detalhado.

2. Na Anlise de Riscos, as alternativas, restries e riscos anteriormente


levantados so avaliados. Neste setor (porm no apenas neste) prottipos so
utilizados para ajudar na anlise de riscos.

3. No Desenvolvimento e Validao um modelo apropriado para o


desenvolvimento do sistema escolhido, de acordo com o risco analisado no setor
anterior (cascata, interativo,...).

4. No Planejamento da Prxima fase ocorre a reviso do projeto e a deciso


de partir para a prxima fase.

Ou seja, cada volta ou iterao do processo vista por quatro ngulos.

No final da Viabilidade do Projeto teremos como resultado a Concepo das


Operaes; da Definio de Requisitos o produto sero os requisitos; no final do
Desenvolvimento e Testes o projeto criado e os testes habilitados. Pode-se parar
por a, pode-se incluir mais fases, pode a espiral ficar adormecida at uma nova
alterao do sistema se requisitada, e desta forma estender at o fim de vida do
sistema.

Neste modelo, apenas o incio definido. A evoluo e amadurecimento dos


requisitos demandam tempo ajustvel (assim como custo). Isto torna o sistema
difcil de ser vender ao cliente e exige um alto nvel de gerenciamento em todo o
processo.


Modelo de Ciclo de Vida Associado ao RUP
Derivado da UML e do Processo Unificado de Desenvolvimento de Software, o
RUP, Rational Unified Process, um modelo de processo iterativo e incremental,
dividido em fases, orientado a casos de uso. Possui framework (esqueleto) de
processo e manuais que guiam na utilizao das melhores prticas de especificao
de projeto (Vdeo Aula sobre Ciclo de Vida de Software, parte 3, revista Engenharia
de Software Magazine).

O objetivo do RUP produzir software com qualidade (melhores prticas de


engenharia de software) que satisfaa as necessidades dos clientes dentro de um
prazo e oramento estabelecidos.

Este modelo foi desenvolvido pela Rational Software Corporation e adquirido


pela IBM, que o define da seguinte maneira: IBM Rational Unified Process, ou
RUP, uma plataforma de processo de desenvolvimento de software configurvel
que oferece melhores prticas comprovadas e uma arquitetura configurvel. (ver
Figura 8)

Figura 8. Conceitos chaves do RUP


O RUP possui quatro fases de negcio. O nome de cada fase revela o que
ser entregue por ela (ver Figura 9):
Concepo: define o escopo do projeto, ou business case; onde
julgado se o projeto deve ir adiante ou ser cancelado.
Elaborao: elabora modelo de requisitos, arquitetura do sistema,
plano de desenvolvimento para o software e identificar os riscos.
Construo: constri o software e a documentao associada.
Transio: finaliza produto, define-se plano de entrega e entrega a
verso operacional documentada para o cliente.

Figura 9. RUP

A iterao no RUP tem por objetivo minimizar os riscos. Como pode ser visto
na Figura 9, a iterao pode acontecer dentro de cada fase, gerando incrementos,
ou em todo o processo. Por exemplo, dentro da concepo, a iterao pode ocorrer
at que todos os requisitos sejam perfeitamente entendidos. O plano de iteraes
identificar quais e quantas iteraes so necessrias durante o processo.

Em geral, essas fases demandam esforo e programao diferentes. Para


um projeto de mdio porte, de acordo com o fabricante ser seguida a distribuio
apresentada na Tabela 1.

Tabela 1. Distribuio prevista de esforo e programao para um ciclo de desenvolvimento


inicial tpico de um projeto de mdio tamanho.
Concepo Elaborao Construo Transio

Esforo ~5% 20% 65% 10%

Programao 10% 30% 50% 10%

O RUP usa templates que descrevem o que esperado no resultado de cada


fase ou cada iterao (IBM, 2004), identificando as competncias e
responsabilidades (arquiteto, analista, testador,...), as atividades e os artefatos.

Para descrever as atividades (codificao de uma classe, integrao de


sistemas,...) o RUP faz o uso de manuais (guidelines), que descrevem tcnicas e
heursticas; e de Mentores de Ferramentas, que explicam o uso da ferramenta
para executar a atividade. Os artefatos de cada fase (documentos, modelos,
cdigos, etc.) so criados, juntamente com templates e exemplos, para melhor
entendimento da equipe e do cliente (ver Figura 10).

Figura 10. Os principais artefatos do Rational Unified Process e o fluxo de informaes


existente entre eles.

Os templates tambm ajudam no gerenciamento, pois definem o que precisa


ser executado. Servem tambm como guia para que as boas prticas de
especificao de projeto no sejam esquecidas no processo de desenvolvimento
daquele software.

Assim, toda a preocupao dada pelo RUP em disciplinar o processo atravs


de frameworks, guias, templates, faz com que haja uma melhor alocao de
pessoas na equipe, padronizao do sistema, viso concreta do andamento do
projeto.

A escolha do RUP deve ser feita por empresas de software com prvia
experincia, pois a definio de framework, templates, guias, mtodos, entre outros,
demandam tempo e exigem aderncia s boas prticas de processo de software.
Consideraes Finais
Finalizando este artigo sobre os modelos de ciclo de vida de software, segue uma
tabela comparativa das principais caractersticas que devem ser observadas antes
de escolher o ciclo ou os ciclos de vida a serem adotados (ver Tabela 2).

Vale ressaltar que, conforme j mencionado anteriormente, no existe um


modelo ideal e na maioria dos softwares desenvolvidos so utilizados mais de um
modelo de ciclo de vida.

Modelo Foco Requisitos 1 verso para Gerenciamen Sistemas


cliente to (1 = mais (tamanho
simples) complexid
ade
mximo)

Cascata Documento e Bem Fim do ciclo 1 Simples


artefato conhecido/co
ngelado

V Planejamento Bem Fim do ciclo 2 Simples


de testes conhecido /
congelado

Incremental Incrementos Maior Prottipos 3 Mdio


Operacionais Abstrao / Operacionais
Tratado em
mdulo

Evolutivo Evoluo dos Pouco Prottipos 4 Mdio


requisitos conhecidos Operacionais

RAD Rapidez Escopo Prottipos 4 Mdio


restrito / Operacionais
Maior
abstrao /
Tratado em
mdulos

Prototipagem Dvidas nos Abstratos Prottipos no 5 Mdio


requisitos operacionais

Espiral Anlise de Maior Prottipos 5 Complexos


risco abstrao / operacionais ou
evoludos no operacionais
com o tempo

RUP Frameworks e Maior Prottipos 5 Complexos


boas prticas abstrao / operacionais ou
evoludos no operacionais
com o tempo

Você também pode gostar