Engenharia de software I Unid II

Prévia do material em texto

45
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Unidade II
3 PROCESSO DE SOftwaRE
3.1 Conceitos preliminares 
Weber et al. ([s.d.]), no artigo escrito para apresentar os resultados alcançados e as lições aprendidas 
com a implantação do modelo MPS.BR de melhoria do processo de software brasileiro, afirmam:
Hoje, todos (no governo, academia e indústria) reconhecem a importância 
da melhoria dos processos de software para a competitividade, qualidade 
e produtividade sistêmica do setor de software brasileiro; mas poucos têm 
ideia da magnitude, complexidade e duração do esforço quando se trata de 
superar este desafio em um país com as dimensões e características do Brasil 
(WEBER et al, [s.d.]). 
Para tratar especificamente dos processos de software, é muito importante localizá-los no contexto 
da engenharia de software. 
Como já foi visto, a engenharia de software estuda e propõe soluções que abrangem todo o ciclo 
de vida de um produto de software. Para isso, deve incluir diversas facetas que se apresentam nesse 
contexto.
A figura a seguir apresenta uma visão holística, em forma de pilares, do desenvolvimento de software, 
que abrange todos os aspectos envolvidos nos modelos de engenharia de software.
Pr
oc
es
so
s
M
ét
od
os
/T
éc
ni
ca
s
Ciclo de vida de software (visão da ES)
Fe
rr
am
en
ta
s
Qu
al
id
ad
e
Ge
re
nc
ia
m
en
to
Figura 4 – Visão holística do ciclo de vida do software
Os pilares verticais apresentados na figura representam os principais aspectos envolvidos com o 
desenvolvimento e a manutenção de software, obtidos a partir de livros, materiais didáticos e modelos 
da engenharia de software e definidos conforme a seguir. 
46
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade II
•	 Processos	de	software:
— são o estudo, os conhecimentos adquiridos e as práticas que apoiam as atividades envolvidas 
com o desenvolvimento e a manutenção de software durante toda a vida de um determinado 
produto de software;
— precisam ser descritos, normatizados e divulgados para todas as pessoas da organização 
envolvidas com software;
— têm como resultado do processo de software o produto de software, constituído de códigos 
programados que formam um sistema de informação, que é considerado o elemento central, já 
que realiza estruturas complexas e flexíveis que fornecem funções, utilidade e valor ao sistema;
— incorporam as pessoas, os documentos e as regras de execução de suas atividades, inclusive, 
determinando as responsabilidades na sua execução.
•	 Métodos	e	técnicas:
— as atividades de um processo de software envolvem conhecimento na sua execução, disciplina 
e padrões predefinidos;
— para isso, a engenharia de software propõe um conjunto de técnicas e métodos para que os 
desenvolvedores consigam executar suas tarefas com o máximo de produtividade e qualidade.
•	 Ferramentas:
— ao longo de quarenta anos, e ainda em evolução, têm surgido ferramentas de automação que 
dão suporte às atividades do processo de software; 
— ferramentas para desenho, descrições, testes de software e, principalmente, para os trabalhos 
colaborativos entre as equipes de desenvolvimento.
•	 Qualidade:
— com a pressão cada vez maior pela qualidade nos produtos de software, a engenharia de 
software vem propondo e desenvolvendo diversos modelos para a garantia da qualidade, tanto 
no nível dos processos quanto no dos produtos desenvolvidos e mantidos dentro das áreas de 
software das organizações.
•	 Gerenciamento:
— são todas as propostas para a gestão da área de software e para os projetos de software. A 
grande procura é pelo aumento da eficiência no uso dos recursos e na eficácia na produção de 
sistemas de informação;
47
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
— atualmente a gestão ou o gerenciamento de software vem atuando, também, no nível de 
governança, criando modelos e aplicando práticas próprias ou oriundas de outras áreas da 
engenharia que têm sucesso registrado e provado nos últimos tempos;
— diversos aspectos do gerenciamento são abrangidos por esse pilar: gerência de equipe, gerência 
de projetos, gerência da qualidade, governança de TI etc. 
Esses pilares se inter-relacionam e trabalham juntos (ou de forma paralela) na busca das melhores 
práticas nos processos de software, como mostra a figura 5.
Métodos e técnicas
Qualidade de
software
Gerenciamento Ferramentas
Processo de 
desenvolvimento
Figura 5 – Relação dos pilares de sustentação da engenharia de software
 Lembrete
Dominar o ciclo de vida de software significa conhecer todos os pilares 
e suas funcionalidades. A complexidade está em trabalhar ao mesmo tempo 
nos projetos executando os diversos papéis que permeiam esse modelo.
Um aspecto importante a ser considerado é que o desenvolvimento de software envolve empresas 
de todos os tamanhos e quantidades de recursos disponibilizados. 
Os modelos brasileiros têm, ao longo do tempo, dado especial atenção às pequenas empresas de 
software, em virtude da seguinte constatação: as pequenas empresas de desenvolvimento de software 
possuem poucos recursos financeiros para investir na utilização das melhores práticas do mercado; 
diante disso, perdem competitividade no mercado nacional e no internacional, e deixam de atender a 
padrões de qualidade.
Uma das alternativas que o mercado vem implementando é o uso de métodos ágeis que foram 
desenvolvidos exatamente para atender aos pequenos projetos e para pequenas equipes de 
desenvolvimento. Esses métodos procuram deixar os processos de software mais simples, menos 
burocráticos, porém não menos organizados, com o intuito de se construir softwares de forma mais 
48
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade II
rápida e com grande qualidade. A garantia de que as empresas praticam processos com qualidade tem 
advindo dos processos de certificação, tanto nacionais como internacionais.
 Saiba mais
Existem diversas certificações, tanto para empresas quanto para 
profissionais de software, tais como: certificação em teste de software do 
Instituto IBQTS; certificações das normas ISO para as empresas da ABNT em 
processos de qualidade de software, como o CMMI-DEV, do SEI americano, 
e o modelo nacional de melhoria de processos MPS.BR etc.
Todas essas organizações possuem portais disponibilizados na internet, 
que podem ser acessados para busca de maiores detalhes a respeito: 
<http://www.abnt.org.br>. 
<http: www.ibqts.com.br>. 
<http://www.sei.cmu.edu/>. 
<http://www.softex.br/mpsbr/>.
3.2 Etapas do processo de software
Como acontece com todo produto industrial, o software tem um ciclo de vida que possui os seguintes 
elementos ou fases:
•	 é	concebido	a	partir	da	percepção	das	necessidades	de	uma	área	da	organização	ou	de	clientes-
usuários, partindo de uma realidade;
•	 é	desenvolvido,	transformando-se	em	um	conjunto	de	itens	entregáveis	ao	cliente	ou	ao	usuário	
final;
•	 entra	 em	 operação,	 sendo	 utilizado	 dentro	 de	 algum	 processo	 de	 negócio,	 por	 um	 tempo	
indeterminado, e podendo sofrer evoluções ao longo do tempo;
•	 é	retirado	de	operação,	ao	final	de	sua	vida	considerada	útil.
O esquema a seguir mostra uma visão do ciclo de vida de um produto de software que segue os 
mesmos princípios do ciclo de vida de qualquerproduto da manufatura ou industrial.
49
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Criação
Evolução
Decadência
Figura 6 – Visão do ciclo de vida de produtos de software 
No ciclo criação ocorre o desenvolvimento de uma aplicação ou de um sistema de informação. 
Existem diversas metodologias e modelos para representar esse ciclo inicial de software. Este possui um 
tempo predeterminado para ocorrer e é dependente do planejamento do software a ser construído.
No ciclo evolução ocorre a alteração de um produto de software existente. Inclui melhorias, 
novas funcionalidades ou necessidades de adaptação para novas tecnologias. Não existe um tempo 
predeterminado para acontecer evolução em um produto de software, e isso vai depender do tipo de 
sistema, das funcionalidades às quais ele atende e/ou de eventos aleatórios que acontecem ao longo do 
ciclo de vida do produto.
O ciclo decadência ocorre quando o produto de software atingiu um ponto em que não existem mais 
possibilidades para sua evolução. Ele entra em decadência por diversos motivos, tais como: obsolescência 
da tecnologia, mudanças de regras de negócio, mudanças radicais nas regras dos órgão públicos etc. 
O ciclo de vida do software apresentado na figura pode, ainda, ser dividido em diversas etapas 
detalhadas, e cada modelo existente, norma certificadora e/ou autor do mercado apresenta uma visão 
diferenciada dessas divisões.
O quadro 3 apresenta visão típica da estrutura do ciclo de vida de um processo de software, mas que 
não necessariamente seria apresentada por outros autores ou modelos existentes.
Quadro 3 – Visão do ciclo de vida de um produto de software
Percepção das necessidades do cliente ou usuário final (requisitos do software)
Desenvolvimento
Concepção (análise do software – modelagem)
Elaboração (definição da arquitetura do software)
Construção
Desenho inicial
Implementação
Desenho detalhado
Codificação
Teste de unidade
Testes de integração
Transição (entregas parciais e testes de homologação pelo cliente/
usuário final)
Operação (utilização do software pelo cliente-usuário)
Manutenção (melhorias do software e acertos de defeitos)
Retirada (troca ou cancelamento do produto de software)
50
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade II
Algumas considerações devem ser feitas sobre o processo de desenvolvimento de um produto de 
software:
•	 o	 desenvolvimento	 de	 software deve ser feito por profissionais treinados e capacitados em 
engenharia de software e deve ocorrer dentro do conceito de projetos;
•	 todo	projeto	de	software deve ter uma data de início e uma de fim, uma equipe alocada e outros 
recursos de apoio, tais como arquitetos de sistemas, analistas de negócio, administradores de 
banco de dados, testadores etc.;
•	 o	cronograma	do	projeto	deve	ser	feito	a	partir	de	métricas	de	estimativas	e	representa	a	execução	
de um processo de software;
•	 todo	processo	bem-definido	tem	subdivisões	que	permitem	avaliar	o	andamento	de	um	projeto	e	
corrigir seus rumos quando ocorrerem problemas;
•	 todas	 as	 etapas	 e	 atividades	 do	 processo	 de	 software devem ser terminadas por meio de marcos 
predefinidos. Esses marcos são pontos de controle que representam estados significativos do projeto;
•	 geralmente	 os	marcos	 são	 associados	 a	 resultados	 concretos,	 como	 documentos,	modelos	 ou	
porções do produto, que fazem parte do conjunto prometido ao cliente ou têm apenas utilização 
interna ao projeto;
•	 o	próprio	produto	final,	o	software propriamente dito, é um resultado associado ao marco de 
conclusão do projeto.
 Saiba mais
Não deixe de ler:
PEZZÉ, M.; YOUNG, M. Teste e análise de software: processos, princípios 
e técnicas. Porto Alegre: Bookman, 2008.
Nesse livro, os autores fazem um estudo profundo com relação ao 
processo de teste de software e às diversas técnicas que permitem a 
melhoria de sua qualidade.
PRADO, J. C. S. Gerenciando a qualidade de software com base em 
requisitos. Rio de Janeiro, [s.d.]. Disponível em: <http://www-di.inf.puc-rio.
br/~julio/Slct-pub/Livro-qualidade.pdf>. Acesso em: 31 mar. 2014. 
Nesse ensaio, o autor discute a obtenção da qualidade no 
desenvolvimento de software. O autor faz uma análise do capítulo 17 do 
livro Qualidade de Software, de Rocha, Maldonado e Weber (2001), que dá 
uma visão simples e clara sobre os problemas e as alternativas na busca da 
qualidade em software.
51
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Fechando o entendimento de processo de software, a próxima figura apresenta todos os aspectos 
envolvidos com o ciclo de vida de software.
Processo de 
construção de 
software Artefatos Nível abstração
Processo de 
gestão de 
software
Controle 
do 
sistema
Produtos
Alto
Médio
Baixo
Pessoas, 
organização, 
cultura
Notação/linguagens
Ferramentas (automação)
Processo de qualidade
Construção
Construção
Figura 7 – Visão holística do processo de software
O subprocesso de construção é apresentado em camadas que indicam o nível de entendimento e 
abstração com relação aos domínios da tecnologia envolvida no processo. Quanto mais se desce nos 
níveis de conhecimento específico das tecnologias, mais os desenvolvedores deverão ter entendimento, 
e quanto mais alto nos níveis, maior será a necessidade de conhecimento do negócio.
3.3 Processo Pessoal de Software (PSP)
Para um entendimento dos processos de software apresentados a seguir, é interessante observar 
como o Software Engineering Institute (SEI) os organiza. Essa visão é apresentada na figura a seguir. 
Modelo CMMI voltado para a 
capacitação organizacional
Modelo PSP voltado para a 
capacitação de indivíduos 
Modelo TSP voltado para a 
capacitação de equipes ou 
times de desenvolvimento de 
software
Organização
Time 1 Time 2
Figura 8 – Visão dos processos como entendido pelo SEI
52
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade II
De acordo com Maldonado e Fabbri (2001):
•	 seguindo	um	modelo	de	gerenciamento	de	processos	de	software, as organizações têm alcançado 
melhorias significativas nos seus processos e modos de trabalho, e muitas perceberam que, para 
obter índices melhores, dependem do talento individual de seus funcionários;
•	 como	um	grande	modelo	de	qualidade	tipo	ISO	15504	ou	Capability Maturity Model Integration 
(CMMI) poderia ser aplicado no trabalho individual ou em pequenas equipes de projeto, em que 
os profissionais de software pudessem, individualmente, aplicar princípios do nível máximo de 
capacidade e maturidade almejados?
•	 surge,	então)	a	proposta	do	Personal Software Process – PSP (2009), de propriedade do Instituto 
de Engenharia de Software (SEI – Software Engineering Institute), como recurso para melhoria e 
otimização do processo individual de trabalho.
O modelo PSP (2009) sugere práticas e métodos para que o próprio indivíduo consiga identificar e 
corrigir seus pontos fracos. É uma sugestão para organizar e disciplinar os processos individuais e não 
diminui nem restringe a capacidade criativa dos indivíduos.
O modelo foi originalmente derivado do modelo de qualidade Capability Maturity Model (CMM), e 
o autor desse processo é o mesmo, Whatts Humphrey, que adaptou 12 das 18 áreas-chave de processo 
CMM (Key Process Area – KPA) da época ao trabalho individualde profissionais de software. Aplica 
conceitos importantes de engenharia de software em nível individual para desenvolver softwares, e não 
apenas para codificar programas.
O modelo PSP (2014) faz uso de um conjunto de sete etapas sequenciais e progressivas, cada uma 
com um conjunto de roteiros, formulários e gabaritos associados. É apoiado por um livro-texto e um 
curso introdutório oferecido por esse mesmo livro (exercícios de programação e relatórios), principal 
veículo de aprendizado.
De acordo com Humphrey, autor do PSP, à medida que os profissionais de desenvolvimento de software 
aprendem a avaliar seus trabalhos, a analisar essas medidas e a definir e atingir metas de melhoria, passam a 
enxergar os benefícios de usar o processo definido e são motivados constantemente a isso.
 Observação
De acordo com o SEI (2014), a qualidade de um software é governada 
pelo indivíduo que o desenvolve (rotinas ou componentes) e exige 
conhecimento, disciplina e comprometimento.
O modelo PSP tem os seguintes objetivos básicos:
•	 demonstrar	os	princípios	do	processo	individual;
•	 determinar	a	situação	do	processo	atual	de	software individual;
53
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
•	 elaborar	um	processo	de	planejamento	para	desenvolvimento	de	software;
•	 medir	o	tamanho	do	software, como parte do processo de planejamento;
•	 fazer	uma	estimativa	antecipada	do	tamanho	do	software;
•	 fazer	uma	estimativa	do	cronograma	e	dos	recursos	necessários	para	o	software;
•	 realizar	medições	apropriadas	do	processo	individual;
•	 fazer	revisões	significativas	de	projeto	e	código;
•	 executar	gerenciamento	da	qualidade	do	software;
•	 executar	projeto	de	software de modo mais formal;
•	 verificar	o	projeto	usando	métodos	como	máquinas	de	estados	finitos	e	rastreamento	de	programa;
•	 aumentar	a	escala	de	PSP	para	problemas	maiores;
•	 ajudar	a	elaborar	planos	mais	precisos;
•	 determinar	as	etapas	necessárias	para	melhorar	a	qualidade	do	produto;
•	 estabelecer	um	padrão	de	referência	para	se	medir	as	melhorias	do	processo	pessoal;	
•	 determinar	o	impacto	das	mudanças	sobre	a	eficiência	profissional.
A figura a seguir apresenta a estrutura visual do modelo PSP (2009).
Processo cíclico
Qualidade pessoal
Planejamento pessoal
Medição pessoal
PSP3
Desenvolvimento cíclico
PSP 2
Revisões de código
Revisões de projeto
PSP1
Estimativa de tamanho
Relatório de teste
PSP 0
Processo atual
Registro de tempos e defeitos
PSP 2.1
Gabaritos de projeto
PSP 1.1
Planejamento de tarefa
Planejamento deescalonamento
PSP 0.1
Padrão de codificação
Medição de tamanho
Proposta de melhoramento do processo
Figura 9 – A evolução do processo PSP (2009)
54
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade II
O PSP 0 representa o processo de construir software que permanece o mesmo. Os profissionais de 
software aprendem a aplicar os formulários e roteiros do PSP aos seus trabalhos pessoais, medindo 
tempo e defeitos de desenvolvimento, defeitos estes injetados ou removidos.
O PSP 0.1 adiciona um padrão de codificação, medição de tamanho e formulário de proposta de 
melhoramento do processo (PMP). Os profissionais de software registram no PMP os problemas, os tópicos 
importantes para discussão e argumentação e as ideias a serem usadas futuramente, aperfeiçoando, 
assim, os seus processos pessoais.
O PSP 1 introduz o Proxy-Based Estimating Method (Método PROBE) para estimar tamanhos e 
tempos de desenvolvimento para novos programas, com base nos próprios dados individuais, utilizando 
regressão linear para calcular parâmetros de estimativa e gerar intervalos de confiança para indicar a 
qualidade dessa estimativa de tamanhos e tempos.
Já no PSP 1.1, adicionam-se o escalonamento e o planejamento de tarefas.
O PSP 2 introduz o gerenciamento de defeitos. Com esses dados reunidos previamente, os profissionais 
de software constroem e usam listas de verificação para revisão de projeto e código (checklists).
O PSP 2.1 introduz as técnicas de especificação de projeto e análise em acréscimo à prevenção de 
defeitos, análise e comparação de processos. Os profissionais de software aprendem a avaliar e melhorar 
a eficiência individual.
No PSP 3, os profissionais de software combinam múltiplos PSP 2.1, de uma forma cíclica, para 
construir módulos com milhares de linhas de código (Kilo Lines of Code – KLOC). Exploram os métodos 
de verificação de projeto, assim como os princípios e métodos de definição de processo.
 Lembrete
O PSP, diferentemente do CMMI, que atua no nível de ambiente 
organizacional (áreas de processos), equipa os profissionais para fazerem 
tal trabalho de alta qualidade e para participarem ativamente no 
melhoramento do processo de software da organização.
No paradigma do PSP, cada desenvolvedor estabelece metas pessoais, define os métodos que usará, 
mede seu trabalho, analisa seus resultados e os ajusta para se aproximar das metas. O PSP tem sido 
usado com sucesso em atividades pessoais estruturadas, tais como escrever um livro e desenvolver um 
autotreinamento.
De acordo com o PSP (2009) é muito útil, caso seja empregado em conjunto com o modelo de 
qualidade CMMI. Tem mostrado resultados significativos:
•	 aumento	de	30%	na	produtividade;
55
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
•	 precisão	em	estimativas	aumentada	para	+/-	10%;
•	 injeção	de	erros/defeitos	no	desenvolvimento	reduzido	em	60%;	
•	 erros/defeitos,	encontrados	no	teste	de	unidade,	reduzidos	em	75%.
 Observação
Como conclusão, pode-se dizer que o PSP é um processo definido para 
ajudar o desenvolvedor a fazer melhor o seu trabalho, bem como a ajustá-
lo e estendê-lo para atender às suas necessidades futuras. 
 Saiba mais
O modelo PSP é de propriedade do Instituto de Engenharia de Software 
ou Software Engineering Institute (SEI). 
Para saber mais, acesse o site, disponível em:<http://www.sei.cmu.edu>.
3.4 Processo para equipe de software (tSP) 
O Team Software Process (TSP) (2010), de acordo com o SEI, significa um guia ou framework para:
•	 planejar	e	gerenciar	um	projeto	em	equipe;
•	 processos	definidos;
•	 papéis	distribuídos;
•	 princípios	de	teamwork e teambuilding;
•	 baseado	no	PSP;
•	 construído	a	partir	de	métodos	comprovados	de	engenharia	e	trabalho	em	equipe.
Uma equipe é um grupo de pessoas que deve estar comprometido com um objetivo comum e dispor 
de um quadro de trabalho comum; é composta de, no mínimo, duas pessoas, e cada uma tem um papel 
específico atribuído. A conclusão da missão requer alguma forma de dependência entre os membros do 
grupo.
56
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade II
Para serem eficazes, as equipes devem estar devidamente qualificadas e ser capazes de funcionar 
como unidades coesas. Equipes eficazes têm certas características comuns:
•	 os	membros	são	qualificados;
•	 o	objetivo	da	equipe	é	importante,	definido,	visível	e	realista;
•	 os	recursos	são	suficientes	para	o	trabalho;	
•	 os	membros	estão	motivados	e	empenhados	a	cumprir	o	objetivo	da	equipe;
•	 os	membros	cooperam	uns	com	os	outros	e	se	apoiam;
•	 os	membros	são	disciplinados	em	seu	trabalho.
Outra característica das equipes eficazes é sua capacidade de inovar. A inovação é mais do 
que pensar somente em ideias brilhantes,já que exige criatividade e muito trabalho. Praticamente 
todas as tarefas de engenharia são parte de um esforço inovador, e equipes inovadoras devem 
ter pessoas qualificadas e capazes, além de muito motivadas. Elas devem ser criativas, flexíveis e 
disciplinadas.
Equipes ou times devem se esforçar para cumprir prazos apertados, enquanto se ajustam às novas 
necessidades. Devem também manter os custos e os horários sob controle, mantendo a gerência 
informada de seu progresso; são compostas por pessoas que podem sentir falta de confiança no projeto. 
Quando os engenheiros não se sentem seguros e respeitados, muitas vezes, sentem-se hostilizados e 
manipulados. 
Para estabelecer essas condições, são dez as orientações do TSP (2010), no modelo do SEI:
•	 os	membros	da	equipe	estabelecem	metas	comuns	e	definem	os	papéis	dos	membros;
•	 a	equipe	desenvolve	uma	estratégia;
•	 os	membros	da	equipe	definem	um	processo	comum	para	o	seu	trabalho;
•	 todos	os	membros	participam	na	elaboração	do	plano,	e	cada	um	sabe	o	seu	papel;
•	 a	equipe	negocia	o	plano	com	a	gerência;
•	 os	membros	fazem	o	trabalho	da	maneira	que	planejaram;
•	 a	equipe	se	comunica	livremente	e	com	frequência;
•	 forma	um	grupo	coeso:	os	participantes	cooperam,	e	todos	estão	empenhados	em	atingir	a	meta;
57
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
•	 os	engenheiros	conhecem	sua	situação,	buscam	o	feedback sobre seu trabalho e têm uma liderança 
que sustenta a sua motivação;
•	 essas	 condições	 não	 são	 óbvias:	 o	 TSP	 fornece	 orientação	 explícita	 do	 que	 as	 organizações	
necessitam para construir equipes de engenharia eficazes.
De acordo com o modelo TSP, cada papel nesse processo é considerado como uma espécie de gerente 
e será responsável por uma lista de tarefas. O gerente de desenvolvimento decide o número de iterações 
que a equipe precisa executar na construção do software e desenvolve uma estratégia para fabricar 
o produto; o gerente de planejamento acompanha as iterações planejadas, para auxiliar a equipe na 
estimativa e no balanceamento de carga; o gerente de qualidade produz artefatos como o plano de 
gerência de configuração e os testes de aceitação.
O gerente de processo deve ter respostas para a maioria das questões sobre o processo. É responsável 
pela alocação de recursos, pela execução de reuniões e pela gerência de riscos, tendo, no entanto, 
responsabilidade menor nos demais processos. Ele precisa da participação de diversos atores na 
organização: os gerentes, os desenvolvedores, os usuários e os clientes.
O desenvolvimento de software é colaborativo, no sentido de que o trabalho deve ser alinhado e 
sintonizado. O objetivo é capacitar a equipe para que se gerencie, distribuindo entre si as responsabilidades 
pelas atividades gerenciais e de apoio; deve ocorrer em ciclos incrementais, de forma que mitigue os 
riscos de cada um dos ciclos (launch). Para tanto, antes de se lançar no desenvolvimento, a equipe deve 
traçar suas estratégias, conhecendo suas forças, disponibilidades e fraquezas, e só depois disso elaborar 
o planejamento e a execução de desenvolvimento.
A missão do framework TSP é ser simples e baseado nos fundamentos do PSP, para:
•	 utilizar	o	modelo	de	ciclo	de	vida	incremental	(ciclos);
•	 estabelecer	medidas-padrão	para	qualidade	e	performance;
•	 prover	métricas	precisas	para	equipes	e	desenvolvedores;
•	 usar	avaliações	de	papéis	e	de	equipe;
•	 requerer	disciplina	de	processo;
•	 prover	orientações	para	solução	de	problemas	com	equipes.
58
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade II
A figura a seguir apresenta uma visão holística dos princípios do modelo TSP.
Arcabouço 
(framework) 
de medição 
integrada
Personal 
Software 
Process 
(PSP)
Gerência da 
qualidade
Coaching
(tutorial)
Equipes 
autogerenciáveis
Fatores - 
princípios 
do TSP
Figura 10 – Visão holística dos princípios do TSP 
Os princípios-base do TSP são:
•	 estabelecimento	de	objetivos	e	papéis	comuns;
•	 definição	de	um	processo	comum	de	trabalho;
•	 envolvimento	de	todos	na	produção	do	plano;
•	 negociação	do	plano	entre	o	time	e	a	gerência;	
•	 revisão	e	aceite	final	pela	gerência;
•	 comunicação	livre	e	frequente;
•	 exigência	de	que	a	pessoa	tenha	sido	previamente	treinada	em	PSP;
•	 possibilidade	de	formar	a	base	para	a	adoção	do	CMMI.
Com relação aos indicadores, o TSP apresenta um conjunto necessário para a avaliação dos produtos 
desenvolvidos pelas equipes de projeto. Os indicadores apresentados pelo modelo são:
•	 precisão	de	estimativas;
•	 intervalos	de	previsibilidade	(tamanho,	esforço	e	defeitos);
•	 distribuição	de	esforço	e	defeitos	nas	fases;
•	 remoção	de	defeitos	nas	fases;
•	 produtividade;
59
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
•	 porcentagem	de	reúso;
•	 índice	de	desempenho;	
•	 valor	agregado	(earned value);
•	 densidade	de	defeitos	total	e	por	fase;
•	 eficácia	dos	filtros	de	defeitos;
•	 custo	da	qualidade;
•	 perfis	de	qualidade;
•	 índice	de	perfis	de	qualidade;
•	 taxas	de	revisão;
•	 rendimento	do	processo;
•	 rendimento	das	fases.
Com relação ao processo TSP (2010), o SEI afirma que: 
•	 é	baseado	na	melhoria	de	processos	de	uma	equipe	de	desenvolvimento,	usando	a	noção	de	time	
(grupo de pessoas) com o mesmo objetivo;
•	 provê	um	conjunto	de	scripts de processos, formulários, métodos, métricas;
•	 esses	 elementos	 guiam	 os	 desenvolvedores	 a	 criarem	 equipes	 eficazes	 e	 estabelecer	 metas	 e	
planos para a equipe acompanhar e reportar o trabalho.
Para o TSP, o desenvolvimento de software está dividido em oito fases, que estão definidas como:
•	 lançamento	da	equipe	do	projeto;
•	 desenvolvimento	da	estratégia;
•	 desenvolvimento	do	plano;
•	 definição	dos	requisitos;
•	 design de alto nível;
•	 implementação;
•	 testes	de	integração	e	de	sistema;
•	 post mortem.
60
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade II
Oferece, ainda, métodos prontos para serem utilizados de forma que não precisem ser reinventados 
ou descobertos e possam, portanto, ser reutilizados, diminuindo, assim, o tempo do projeto.
O TSP baseia-se no PSP, utilizando as medidas de tamanho, tempo e defeito, e, ainda, adiciona a data 
de término das tarefas. 
Para todas as medidas e projeções, os dados são coletados individualmente e, ainda, são analisados 
semanalmente pela equipe, para que esta possa ter ideia do andamento do projeto em relação ao seu 
plano.
Com relação à estrutura do modelo TSP, tem-se:
•	 que	o	primeiro	requisito	para	aplicações	do	TSP	é	que	cada	membro	da	equipe	tenha	sido	treinado	
no PSP;
•	 que	este	é	o	primeiro	passo	para	montar	uma	equipe	de	trabalho	no	TSP;
•	 o	 TSP	adiciona	 elementos	necessários	para	que	 se	possa	 realizar	 o	 trabalho	 em	equipe,	 como	
mostrará a próxima figura; 
•	 todos	os	membros	da	equipe	devem	trabalhar	para	executar	uma	determinada	tarefa,	que,	no	TSP,	
são denominadas de lançamentos do time. 
A figura que segue apresenta a estrutura do TSP, a partir da proposta do autor Koscianski e Soares 
(2007).
Times integrados
Disciplinas de engenharia Disciplinas de times Disciplinas de administração
PSP
Aquisição de habilidades
Planos pessoais
Medidas de qualidade
Valores aprendidos
Métodos de planejamentoProcessos definidos
Dados de proocesso
TSP
Construção de times
Comprometimento
Possessão do plano
Possessão da qualidade
Papéis do time
Planos agressivos
Detalhamento do plano
Objetivos do projeto
Recursos do time
TSP
Trabalho de times
Prioridade da qualidade
Revisão da qualidade
Respeito dos processos
Gerência de mudanças
Custo da qualidade
Comunicação
Revisão de status
Figura 11 – Estrutura do TSP da SEI 
61
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Como mostra a figura, é necessário que o pessoal tenha formação no PSP antes de dar início à 
implantação do modelo TSP. Os engenheiros de software devem ser treinados nas habilidades do PSP 
antes que possam participar das equipes ou times do TSP.
Equipes TSP são relançadas periodicamente, pois o processo segue uma estratégia de desenvolvimento 
iterativo e evolutivo. Os relançamentos periódicos são necessários para que cada fase ou ciclo possam 
ser planejados com base nos conhecimentos adquiridos no ciclo anterior. O relançamento também é 
necessário para atualizar os planos dos engenheiros em detalhes, os quais, normalmente, são necessários 
apenas por alguns meses. 
No lançamento TSP, as equipes fazem um plano global e outro detalhado, por cerca de três a quatro 
meses. Após os membros (todos ou a maioria) da equipe terem completado a fase do projeto ou ciclo, 
é feita uma revisão do plano global e, se necessário, um novo plano detalhado para cobrir os próximos 
três ou quatro meses. Eles são guiados a fazer isso pelo processo de relançamento do TSP.
O lançamento da equipe compreende a fase inicial do processo TSP, na qual são discutidos 
vários temas, durante os quatro dias de duração dessa fase. Segundo Koscianski e Soares (2007), 
o processo de lançamento é composto por uma série de atividades de planejamento do trabalho 
a ser realizado. 
Após o lançamento da equipe, é preciso que esta desenvolva uma estratégia de trabalho. Essa etapa 
tem como principal objetivo minimizar o risco de o desenvolvimento exceder o tempo programado para 
a conclusão do projeto. Para o modelo, definiram-se os seguintes passos:
•	 no	primeiro	ciclo	de	desenvolvimento,	deve-se	fabricar	um	produto	executável	com	as	funções	
mínimas do produto final;
•	 esse	produto,	resultante	do	primeiro	ciclo,	deve	ser	uma	base	para	o	restante	do	produto,	para	que	
possa facilmente ser estendida;
•	 em	todos	os	ciclos,	gerar	um	produto	com	alta	qualidade,	permitindo	que	este	possa	ser	facilmente	
testado;
•	 ter	uma	arquitetura	modular,	para	que	membros	da	equipe	possam	trabalhar	independentemente.
Com relação ao desenvolvimento do plano, o modelo indica que o planejamento ajuda os engenheiros 
da equipe a trabalharem de maneira mais eficiente, com mais produtividade e sem desperdício de tempo. 
Além disso, algumas atividades poderão ser esquecidas, se não forem planejadas. Portanto, planejar um 
projeto não é uma tarefa muito fácil, pois projetos grandes e complexos consomem muitas horas de 
planejamento.
Com a utilização do TSP, é possível analisar a sobrecarga de tarefas de alguns membros da equipe, 
enquanto outros estão mais “folgados”. Isso faz aqueles que não estão sobrecarregados terem, em alguns 
casos, de esperar pela conclusão do trabalho daqueles sobrecarregados, atrasando, assim, o grupo. Para 
62
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade II
resolver esse problema, o TSP propõe que, nessa fase de planejamento, seja feito um balanceamento de 
trabalho entre os membros da equipe. 
Já na fase de implementação, está definida a etapa de construção das partes do produto, e, 
consequentemente, o produto em sua totalidade. O desenvolvimento de cada parte projetada na fase 
anterior será, preferencialmente, realizado por quem a projetou. Porém, mesmo que o engenheiro seja 
o mais indicado para programá-la, isso pode ser diferente, pois a estratégia que será adotada não é 
imposta pelo TSP.
 Observação
O SEI (2014) relatou que, antes do TSP, a empresa Teradyne tinha, 
nos testes de integração, testes do sistema, testes de campos e testes em 
clientes, em média, vinte defeitos por KLOC (mil linhas de código).
O projeto TSP, primeiro, reduziu estes níveis para um defeito por 
KLOC (mil linhas de código). Uma vez que o custo médio é de 12 horas de 
engenharia para encontrar e corrigir cada defeito, a Teradyne economizou 
228 horas de engenharia para cada KLOC de programa desenvolvido.
4 MODELOS DE CICLO DE VIDa DE SOftwaRE
4.1 Introdução a ciclo de vida de software
De acordo com Gordon e Gordon (2006), o ciclo de vida do desenvolvimento de sistemas (Systems 
Development Life Cycle – SDLC), conhecido também como ciclo de vida do software, refere-se aos 
estágios de concepção, projeto, criação e implementação de um Sistema de Informação (SI). Um 
desdobramento possível para SDLC é mostrado na figura a seguir. 
Levantamento das 
necessidades
Desenvolvimento
Manutenção
Implementação
Análise das alternativas
Projeto
Figura 12 – Ciclo de vida do desenvolvimento de software (SDLC)
Analisando-se as atividades propostas para o ciclo SDLC, com base em Gordon e Gordon (2006), 
tem-se o exposto a seguir. 
63
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
•	 Levantamento	de	necessidades:
— essa atividade compreende diversas tarefas para o entendimento e o levantamento das 
necessidades da área de negócio, dos clientes ou dos usuários que precisam de um software de 
automação de suas atividades;
— tem como resultados mais importantes a lista de requisitos do sistema a ser construído, as 
informações que serão tratadas e armazenadas e, se necessário, um protótipo das interfaces 
entre os usuários e o sistema de software.
•	 Análise	de	alternativas:
— essa atividade consiste na identificação e na avaliação de alternativas sistêmicas que melhor 
atendam aos requisitos do software a ser construído;
— seria interessante, para que essa atividade fosse padronizada e a organização possuísse uma 
arquitetura de referência, que a base fosse para todas as soluções de tecnologia de todos os 
sistemas da empresa.
•	 Projeto:
— trata da construção das especificações detalhadas para o projeto selecionado;
— essas especificações incluem projeto das interfaces, banco de dados, características físicas 
do sistema, tais como número, tipos e localizações das estações de trabalho, hardware de 
processamento, cabeamento e os dispositivos de rede; deve especificar os procedimentos para 
testar o sistema completo antes da instalação.
•	 Desenvolvimento:
— inclui o desenvolvimento ou a aquisição do software, a provável aquisição do hardware e o 
teste do novo sistema. 
•	 Implementação:
— ocorre após o sistema ter passado satisfatoriamente por testes de aceitação. O sistema é 
transferido do ambiente de desenvolvimento para o ambiente de produção;
— o sistema antigo (se existir) deve migrar para o novo. 
•	 Manutenção:
— refere-se a todas as atividades relacionadas a um sistema depois que ele é implementado, 
devendo incluir atividades como a correção de software que não funcione corretamente, a 
adição de novos recursos aos sistemas em resposta às novas demandas dos usuários etc.
64
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade II
 Observação
Não há modelo de SDLC uniformemente aceito. Alguns combinam 
desenvolvimentoe implementação em uma única etapa. Outros combinam 
o levantamento e a análise das necessidades, também, em uma única etapa. 
Alguns modelos dividem o projeto em lógico e físico.
4.2 Os principais modelos de ciclo de vida de software
4.2.1 O modelo codifica-remenda
O modelo codifica-remenda significa um processo de ciclo de vida de software mais caótico. 
Partindo apenas de uma especificação ou simplesmente de uma reunião de trabalho, os desenvolvedores 
começam imediatamente a codificar, remendando, à medida que os erros vão sendo descobertos. Não 
existe nenhum processo definido e nenhum é seguido.
Esse modelo, provavelmente e infelizmente, seja o ciclo de vida mais usado na atualidade. Para 
alguns desenvolvedores, ele é atraente porque não exige nenhuma sofisticação técnica ou gerencial. 
Todavia, é considerado um modelo de alto risco, impossível de ser gerenciado e que não permite assumir 
compromissos confiáveis.
Esse modelo persistiu durante algumas décadas, e, como não existia separação de papéis, todos 
faziam um pouco de tudo. Às vezes, uma única pessoa analisava, codificava e testava um sistema inteiro. 
Na busca de eliminar os problemas causados pelo método codifica-remenda, foram sendo criadas 
as metodologias conhecidas hoje como tradicionais, sendo a mais conhecida a chamada cascata, que é, 
também, referida como o modelo clássico de desenvolvimento de software.
4.2.2 O modelo cascata (waterfall)
O modelo clássico ou cascata, que também é conhecido por abordagem top-down, surgiu na década 
de 1970. Até meados da década de 1980, foi o único modelo com aceitação geral; derivado de modelos 
de atividade de engenharia com o fim de estabelecer ordem no desenvolvimento de grandes produtos 
de software. Comparado com outros modelos, este é mais rígido e menos administrativo. Um dos mais 
importantes, é referência para muitos outros, servindo de base para projetos modernos. A versão original 
desse modelo foi melhorada e retocada ao longo do tempo, e este continua a ser muito utilizado hoje 
em dia.
Grande parte do sucesso do modelo cascata está no fato de ser orientado para a documentação. 
No entanto, esta abrange mais do que arquivo e texto: incluindo representações gráficas e mesmo 
simulações. Uma abordagem que incorpora processos, métodos e ferramentas deve ser utilizada pelos 
criadores de software.
Janete
Highlight
Janete
Highlight
Janete
Highlight
Janete
Highlight
65
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
O paradigma do ciclo de vida clássico demanda uma abordagem sistemática e sequencial para o 
desenvolvimento de software. Começa no nível do sistema e progride, através da análise, do design, da 
codificação, do teste e da manutenção, como apresentado na figura a seguir.
Engenharia de 
sistemas
Análise
Design
Codificação
Testes
Manutenção
Figura 13 – Visão do ciclo clássico ou cascata de desenvolvimento de software 
Problemas encontrados no ciclo clássico de desenvolvimento de software são fartamente 
documentados pelos autores consagrados da engenharia de software:
•	 os	projetos	reais	raramente	seguem	o	fluxo	sequencial	que	o	modelo	propõe;	ocorrem	interações,	
bem como voltas a níveis anteriores, provocando problemas na aplicação do paradigma;
•	 frequentemente	os	usuários	têm	dificuldade	de	estabelecer	explicitamente	todos	os	requisitos	do	
software, acompanhada das incertezas naturais que existem no início de muitos projetos;
•	 uma	 versão	 do	 software somente estará disponível quando todo o sistema for definido e 
desenvolvido; qualquer alteração pode ocasionar um desastre no desenvolvimento do sistema; 
isso requer paciência dos usuários.
 Observação
Esses problemas são reais, porém o paradigma do ciclo clássico de 
software tem um definitivo e importante lugar na engenharia de software: 
proporciona um modelo real para a colocação e uso dos métodos para 
analisar, projetar, codificar, testar e manter softwares.
4.2.3 O modelo incremental
De acordo com Pressman (2006), Sommerville (2007), Paula Filho (2003) e outros autores, o modelo 
incremental seria a aplicação do modelo cascata por diversas vezes em um mesmo projeto. Isso ocorre 
ao se dividir o desenvolvimento de um sistema complexo em pequenas partes, o que pode ocorrer de 
forma sequencial, parte a parte ou em paralelo, com equipes diferentes desenvolvendo partes diferentes.
66
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade II
Para apresentar o modelo, é utilizada uma visão do ciclo de vida em cascata considerada por Peres, 
Laskoski e Radaelli (2014), mostrada na próxima figura.
Comunicação
Planejamento
Modelagem
Construção
Implantação
Figura 14 – Modelo em cascata 
As fases desse modelo, de acordo com Peres, Lakosky e Radaelli (2014, p. 2) significam:
•	 comunicação:	consiste	de	atividades	para	o	levantamento	dos	requisitos	do	sistema	e	envolve	a	
comunicação entre os desenvolvedores e o cliente;
•	 planejamento:	consiste	de	atividades	para	o	estabelecimento	de	um	plano	de	desenvolvimento	
do sistema ou projeto de software. Descreve, também, as técnicas a serem conduzidas, os riscos 
prováveis, os recursos que serão necessários, os produtos de trabalho a serem produzidos e um 
cronograma;
•	 modelagem:	 composta	 de	 atividades	 que	 incluem	 a	 criação	 de	 modelos	 que	 permitem	 ao	
desenvolvedor e ao cliente entender melhor os requisitos do software e o projeto que vai satisfazer 
a esses requisitos;
•	 construção:	essa	fase	combina	a	geração	de	código	e	os	testes	necessários	para	revelar	erros	no	
código implementado;
•	 implantação:	o	software é entregue ao cliente, que avalia o produto e fornece feedback com base 
na avaliação.
Se essas fases se repetirem e pequenos pedaços do software forem sendo liberados ou agrupados 
para serem entregues ao cliente, teremos o que se chama de modelo incremental, mostrado na figura 
a seguir. 
67
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Comunicação
Comunicação
Comunicação
Planejamento
Planejamento
Planejamento
Modelagem
Modelagem
Modelagem
Construção
Construção
Construção
Implantação
Implantação
Implantação
Incremento 1
Incremento 2
Incremento n
Entrega do 1º incremento 
Núcleo do produto
Fu
nc
io
na
lid
ad
es
 e
 c
ar
ac
te
rís
tic
as
 d
o 
so
ft
w
ar
e
Entrega do 2º 
incremento
Entrega do n 
incremento
Figura 15 – Modelo incremental
Vantagens apontadas pelos autores para o modelo incremental em relação ao modelo em cascata 
puro:
•	 entregas	parciais	facilitam	a	identificação	e	a	correção	de	erros	entre	os	componentes	do	software;
•	 necessidades	não	especificadas	nas	fases	iniciais	podem	ser	desenvolvidas	nos	incrementos;
•	 cada	iteração	produz	um	conjunto	de	itens	utilizáveis	(se	possível);
•	 os	feedbacks de iterações anteriores podem ser usados nos próximos incrementos;
•	 os	incrementos	podem	ser	desenvolvidos	por	menos	profissionais;
•	 a	entrega	dos	incrementos	permite	o	cumprimento	do	prazo	especificado.
Como todo modelo conceitual, porém, o modelo incremental apresenta algumas desvantagens: 
•	 o	número	de	iterações	não	pode	ser	definido	no	início	do	processo,	o	que	pode	não	ser	aceito	pelo	
cliente;
•	 o	fim	do	processo	também	não	pode	ser	previamente	definido;
68
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -2
5/
04
/2
01
4
Unidade II
•	 o	gerenciamento	e	a	manutenção	do	sistema	completo	podem	se	tornar	complexos,	principalmente,	
se ocorrem durante o desenvolvimento dos incrementos;
•	 o	gerenciamento	do	custo	do	projeto	é	mais	complexo,	em	razão	do	número	de	 iterações	que	
pode acabar com a verba disponível. 
4.2.4 O modelo Rapid Application Development (RAD)
Na busca de produtividade e qualidade no processo de desenvolvimento de sistemas, especialistas e 
autores da engenharia de software, baseados nos problemas do ciclo clássico (cascata), na evolução das 
técnicas estruturadas, no impacto das linguagens de programação orientadas a objetos e no surgimento 
dos conceitos de qualidade, no final da década de 1980 e início da década de 1990, propuseram um 
novo paradigma denominado de Rapid Application Development (RAD).
A metodologia RAD propõe um conjunto de elementos que criaram um novo paradigma incluindo 
a prototipação interativa, o desenvolvimento espiral e o uso intensivo de ferramentas de automação do 
desenvolvimento (CASE), com uso de linguagens de quarta geração, orientação a objetos e modelos-
padrão de desenvolvimento, como a Unified Modeling Language (UML).
O RAD foi originalmente utilizado por James Martin, em seu livro RAD, publicado em 1991.
De acordo com Ramos (2009), tem-se sobre o modelo RAD:
•	 é	sequencial	linear	e	enfatiza	um	ciclo	de	desenvolvimento	extremamente	curto;
•	 o	 desenvolvimento	 rápido	 é	 obtido	 usando	 uma	 abordagem	 de	 construção	 baseada	 em	
componentes;
•	 os	requisitos	devem	ser	entendidos	corretamente,	e	o	alcance	do	projeto	deve	ser	restrito;
•	 é	usado	principalmente	para	aplicações	de	sistemas	de	informação;
•	 cada	função	principal	pode	ser	direcionada	para	uma	equipe	RAD	separada	e,	então,	integrada	
para formar o todo.
A próxima figura mostra uma visão gráfica do modelo RAD proposta por Ramos (2009).
69
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Modelagem
do negócio
Modelagem
do negócio
Modelagem
do negócio
Modelagem
dos dados
Modelagem
dos dados
Modelagem
dos dados
Modelagem
do processo
Modelagem
do processo
Modelagem
do processo
Geração de 
aplicação
Geração de 
aplicação
Geração de 
aplicação
Teste e 
modificação
Teste e 
modificação
Teste e 
modificação
Equipe nº1
60 a 90 dias
Equipe nº2 Equipe nº3
Figura 16 – O modelo RAD 
Alguns autores consideram que nem todos os tipos de aplicação são apropriados para o modelo 
RAD. Para que este seja aplicado corretamente, as seguintes considerações devem ser levadas em 
conta:
•	 a	aplicação	deve	permitir	uma	efetiva	modularização,	com	ciclos	curtos	de	desenvolvimento;
•	 se	 a	 aplicação	 exigir	 alto	 desempenho	 e	 se	 este	 for	 obtido	 sintonizando	 as	 interfaces	 dos	
componentes, a abordagem RAD poderá não funcionar a contento;
•	 a	prototipação	interativa	e	viva,	aliada	ao	desenvolvimento	incremental	e	não	linear,	são	aspectos	
extremamente positivos para atingir os objetivos do desenvolvimento rápido;
•	 a	adoção	da	orientação	a	objetos	ou	o	uso	de	linguagens	de	quarta	geração	é	também	um	fator	
altamente positivo, principalmente, na aplicação de reúso de código;
•	 o	 modelo	 RAD	 propõe-se	 a	 ser	 um	 método	 leve,	 flexível	 e	 adaptável	 às	 novas	 tecnologias	
emergentes que considerem o RAD um processo organizado, gerenciado e padronizado.
 Saiba mais
Consulte o material do autor Ricardo Argenton Ramos, da Univasf, que 
detalha os modelos apresentados nesta unidade.
RAMOS, R. A. Processos de desenvolvimento de software. Univasf, 
Juazeiro, 2009. Disponível em: <http://www.univasf.edu.br/~ricardo.
aramos/disciplinas/ESI2009_2/Aula02.pdf>. Acesso em: 13 fev. 2014.
70
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade II
4.2.5 Os modelos evolucionários
Os modelos evolucionários ou modelos evolutivos, como o próprio nome sugere, são os explicitamente 
projetados para acomodar um produto de software que evolui com o tempo. A cada iteração, os modelos 
evolucionários ou evolutivos têm por objetivo produzir uma versão melhor e mais completa do software.
Dois modelos se encaixam nessa definição: o de prototipagem e o espiral.
4.2.5.1 O modelo de prototipagem
A prototipação é uma ferramenta que pode ser usada em qualquer um dos modelos apresentados 
até agora. Essa técnica auxilia o engenheiro de software e o cliente a entenderem melhor o que deve ser 
construído quando os requisitos estão confusos. Um protótipo é uma espécie de versão preliminar do 
software. Pode ser um software ou um plano no papel e concentra-se na representação dos aspectos do 
software que são visíveis para o cliente.
O objetivo é entender os requisitos do usuário e, assim, obter melhor definição dos requisitos do 
sistema. Possibilita que o analista crie um modelo (protótipo) do software que será construído. Esse 
protótipo é apropriado para quando o cliente não tiver definido detalhadamente os requisitos, mas 
tiver prazo curto para o desenvolvimento. O protótipo dá maior assertividade ao projeto com relação às 
necessidades do cliente ou usuário.
A figura a seguir dá uma visão do funcionamento do modelo de prototipagem.
Obter requisitos
Elaborar projeto rápido
Avaliar protótipo
Construir protótipo
Refinamento do protótipo
Figura 17 – Modelo de processo de prototipagem
A função da atividade obter requisitos é permitir que desenvolvedor e cliente definam os objetivos 
gerais do software, identifiquem quais requisitos são conhecidos e as áreas que necessitam de definições 
adicionais; elaborar projeto rápido é aquela em que se faz a representação dos aspectos do software 
que são visíveis ao usuário por meio de abordagens de entrada e formatos de saída; a atividade construir 
71
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
protótipo é a implementação rápida do projeto; avaliar protótipo é quando o desenvolvedor e o cliente 
avaliam o protótipo; e a atividade refinamento do protótipo é o momento em que o desenvolvedor 
refina os requisitos do software a ser desenvolvido na tecnologia final.
Percebe-se claramente que a intenção desse modelo é apoiar o entendimento do software a ser 
construído e que o resultado da prototipagem não pode ser considerado a aplicação final que será 
colocada em produção ou operação. Quando todos os requisitos estiverem identificados e detalhados, e 
as interfaces, totalmente definidas, o protótipo deverá ser descartado, e a versão de produção, construída, 
considerando os critérios de qualidade.
4.2.5.2 O modelo espiral
O modelo espiral foi proposto por Barry Boehm, em 1986, e tem como objetivo acoplar a natureza 
iterativa da prototipação aos aspectos controlados e sistemáticos do modelo em cascata; é dividido 
em uma série de atividades de trabalho ou regiões de tarefas e combina as características positivas da 
gerência de baselines (conjunto de documentos associados ao processo).
A seguir, a figura apresenta o modelo de Boehm, de 1986, com quatro regiões de tarefas.
Definir objetivos
(planejamento)
Avaliar e planejar 
próxima fase Desenvolvimento 
engenharia
Analisar riscos
Figura 18 – O modelo espiral adaptado de Barry Boehm
O modelo espiral é uma evolução dos modelos clássicos e da prototipagem. Valoriza os pontos 
positivos desses modelos, desprezando os considerados negativos. Organiza o desenvolvimento como 
um processo iterativo em que vários conjuntos com quatro fases se sucedem, até que seja obtidoo 
sistema ou software final.
Um novo ciclo se inicia (primeira fase) com a determinação de objetivos, alternativas e restrições, em 
que ocorre o comprometimento dos interessados e o estabelecimento de uma estratégia para alcançar 
os objetivos. Na segunda fase, a avaliação de alternativas, bem como a identificação e a solução de 
riscos se executam numa análise de riscos. Na terceira fase, ocorre o desenvolvimento do produto de 
72
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade II
software. Nesse quadrante, outros modelos podem ser empregados, inclusive, o modelo cascata. Na 
quarta e última fase, o produto é avaliado e prepara-se para iniciar um novo ciclo.
4.2.6 Os modelos especializados
Um modelo de processo especializado leva em conta muitas das características de um ou mais 
modelos tradicionais, tais como o modelo em cascata, o espiral, o evolucionário, entre outros. Todavia, 
existe a necessidade de aplicação, em produtos de softwares muito específicos, de uma abordagem mais 
especializada de engenharia de software, ou, quando definida, de uma forma mais restritiva. Os autores 
organizam esses modelos especializados em modelo de desenvolvimento, baseado em componentes, 
e modelo de métodos formais. 
Com relação ao modelo de desenvolvimento baseado em componentes, tem-se:
•	 o	modelo	baseado	em	componentes	tem	como	ênfase	criar	sistemas	de	software que envolvam 
a composição de componentes, permitindo que sejam adicionadas, adaptadas, removidas 
e substituídas partes do sistema sem que seja necessária sua completa substituição; é a 
implementação do conceito da reusabilidade no desenvolvimento de software, tão comum em 
outras engenharias;
•	 esse	tipo	de	desenvolvimento	auxilia	a	manutenção	dos	sistemas,	visto	que	foca	a	integração	de	
novos componentes já prontos ou, então, a atualização dos já existentes;
•	 dessa	 forma,	 essa	 abordagem	 enfatiza	 a	 criação	 ou	 a	 adaptação	 de	 componentes	 para	 que	
sejam utilizados em diversos sistemas; com isso, temos como resultado a reutilização, que busca 
flexibilizar o desenvolvimento;
•	 um	tipo	de	desenvolvimento	que	utiliza	essa	filosofia	é	o	formado	pelos	componentes	de	software 
comercial de prateleira, ou Commercial Off-The-Shelf (COTS), componentes desenvolvidos por 
vendedores que os oferecem como produtos e disponibilizam as suas funcionalidades juntamente 
com interfaces bem-definidas que permitem que esses componentes sejam integrados ao software 
a ser desenvolvido;
•	 nesse	caso,	a	equipe	de	desenvolvimento	do	sistema	ou	da	aplicação	conhece	pouco	ou	nada	
sobre o funcionamento interno de um componente, porém é fornecida uma interface externa 
bem-definida com a qual se deve trabalhar;
•	 esses	componentes	podem	ser	comprados,	e	a	sua	principal	desvantagem,	na	maioria	dos	casos,	é	
que não há código-fonte disponível; assim, a definição de como usar o componente é dada pelo 
fabricante e deve ser documentada, além de ser oferecido suporte na instalação e no uso desses 
componentes;
•	 o	que	se	procura	em	um	componente	é	algo	quase	independente	e	uma	parte	substituível	de	um	
sistema que tem função bastante clara; os componentes possuem interface e, também, empregam 
73
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
regras de herança oriundas da tecnologia de objetos;
•	 o	 modelo	 de	 desenvolvimento	 baseado	 em	 componentes	 possui	 uma	 abordagem	 iterativa	 e	
evolucionária; a essência é desenvolver aplicações comerciais ou científicas a partir de componentes 
de software pré-empacotados;
•	 uma	característica	 importante	nesse	modelo	 é	que	as	 atividades	de	modelagem	e	 construção	
começam com a identificação de possíveis candidatos a componentes, que podem ser projetados 
como módulos de software convencionais, como classes ou pacotes;
•	 de	 acordo	 com	Medeiros,	 E.	 (2004),	 o	modelo	 de	 desenvolvimento	 baseado	 em	 componentes	
possui as seguintes etapas: diversos produtos baseados em componentes existentes no mercado 
são pesquisados e avaliados; os itens de integração de componentes são considerados; projeta-
se uma arquitetura de software para acomodar os componentes; integram-se os componentes à 
arquitetura; e realizam-se todos os testes para assegurar a funcionalidade adequada; todas essas 
etapas são independentes da tecnologia utilizada para criar os componentes.
 Saiba mais
Veja material interessante sobre os modelos especializados de 
software, com exemplo de uso do modelo de desenvolvimento baseado em 
componentes com a tecnologia Enterprise Java Beans (EJB).
MEDEIROS, H. Modelos de desenvolvimento especializados. [s.d.]. 
Disponível em: <http://www.devmedia.com.br/modelos-de-processo-
especializado-conceitos-e-principios/29898>. Acesso em: 13 fev. 2014. 
Com relação ao modelo de métodos formais, tem-se:
•	 o	modelo	de	métodos	formais	possui	um	conjunto	de	atividades	que	conduzem	a	uma	especificação	
matemática formal do software e possibilita a especificação, o desenvolvimento e a verificação de 
um sistema baseado em computador por meio da aplicação de uma rigorosa notação matemática;
•	 os	métodos	formais	oferecem	três	diferentes	níveis	de	atividades:
— nível 0: em que o software é descrito por meio de uma especificação formal que será usada 
como base para a implementação do sistema; esse nível é opcional e deve ser de custo-benefício 
menor;
— nível 1: em que o desenvolvimento e a verificação formal são utilizados para produzir um 
software de maneira mais formal; esse nível é mais apropriado para sistemas de alta integridade 
que necessitem de segurança ou confiança;
74
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade II
— nível 2: em que provadores de teoremas ou simuladores podem ser utilizados, a fim de conduzir 
testes completos das propriedades de um sistema, de forma mais automatizada; esse nível é 
mais apropriado em sistemas nos quais o custo provocado por erros é extremamente alto.
•	 a	vantagem	dos	métodos	formais	durante	o	desenvolvimento	é	que	eles	oferecem	a	eliminação	
de diversos problemas encontrados em outros modelos, como a ambiguidade, a incompletude e a 
inconsistência;
•	 todos	 esses	 problemas	 podem	 ser	 descobertos	 e	 corrigidos	 mais	 facilmente	 com	 a	 aplicação	
da análise matemática; os métodos formais, quando utilizados durante o projeto, servem para 
verificar a programação, possibilitando, assim, a descoberta e a correção de erros que poderiam 
passar despercebidos;
•	 em	razão	da	sua	característica,	os	modelos	de	métodos	formais	são	mais	utilizados	quando	se	
desenvolvem softwares que possuem fator crítico de segurança, ou quando a empresa pode sofrer 
pesados problemas econômicos caso ocorram erros no software;
•	 alguns	exemplos	de	software em que os métodos formais são aplicados são os sistemas de controle 
de aeronaves, engenharia aeroespacial e equipamentos médicos.
4.2.7 O Unified Process (UP) 
O Processo Unificado (PU) ou Unified Process (UP) é um processo configurável de engenharia de 
software e um guia de como usar efetivamente a UML.
A UML é uma linguagem unificada de modelagem de sistemas, abrangendo desde as funcionalidades 
até as soluções de implementação de códigos orientadas a objetos.
O UP foi desenvolvido na década de 1990 pela empresa Rational, que hoje pertence à IBM. 
É caracterizado como um arcabouço (framework) que pode ser personalizado de acordo com as 
necessidades específicas e os recursos disponíveis para cada projeto.
Todo UP deve descrever quem (papel) está fazendo o que(artefatos das atividades), como 
(execução das atividades) e quando (no tempo, representa a disciplina no processo). Artefato é 
qualquer documento ou modelo que precisa ser construído nas atividades do processo. Dentro do 
processo unificado, aparece a figura do trabalhador ou ator, que é alguém que desempenha um 
papel e é responsável pela realização de atividades para produzir ou modificar um artefato. Um 
trabalhador pode ser um analista de negócio, um analista de sistema, um programador, um testador 
etc. Atividade, no UP, representa uma tarefa a ser realizada por um trabalhador ou ator, a fim de 
produzir ou modificar um artefato. Como exemplos, podemos citar os requisitos do sistema, o plano 
do projeto, os códigos, os casos de testes etc.
O UP apresenta, também, o conceito de disciplinas, que descrevem as sequências das atividades 
que produzem algum resultado significativo e mostram as interações dos participantes. As atividades 
75
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
das disciplinas são realizadas a qualquer momento durante o ciclo de desenvolvimento, que, no UP, é 
denominado de fase do UP. Como exemplo de uma sequência de atividades, temos: requisitos, análise, 
projeto, implementação e teste.
O modelo unificado UP apresenta os seguintes princípios básicos: desenvolvimento iterativo; baseado 
em casos de uso; e centrado em arquitetura.
Com relação ao desenvolvimento iterativo, tem-se:
•	 o	desenvolvimento	de	um	software é dividido em vários ciclos de iteração, cada qual produzindo 
um pedaço do sistema testado, integrado e executável;
•	 em	cada	ciclo	ocorrem	as	atividades	de	análise	de	requisitos,	projeto,	implementação	e	teste,	bem	
como a integração dos artefatos produzidos com os artefatos já existentes.
A figura a seguir mostra o funcionamento do modelo unificado em ciclos e incremental.
Requisitos Requisitos
Projetos Projetos
Implementação e 
testes
Implementação e 
testes
Integração e testes 
de sistema
Vinte dias, 
por exemplo
O sistema cresce 
incrementalmente
As iterações são 
de tamanho fixo 
ou limitadas pelo 
tempo
Integração e testes 
de sistema
Tempo
Ciclo 1 Ciclo N
Figura 19 – Desenvolvimento iterativo e incremental do modelo UP
Com relação ao princípio baseado em casos de uso, tem-se:
•	 um	caso	de	uso	ou	use case da UML é uma sequência de ações executadas por um ou mais 
atores e pelo próprio sistema, que produz um ou mais resultados de valor para um ou mais 
atores;
•	 o	modelo	unificado	UP	é	dirigido	por	casos	de	uso,	pois	os	utiliza	para	dirigir	todo	o	trabalho	de	
desenvolvimento, desde a captação inicial e a negociação dos requisitos até a aceitação do código 
(testes). 
•	 os	 casos	de	uso	 são	 centrais	 ao	processo	UP	e	a	outros	métodos	 iterativos,	 pois	os	 requisitos	
funcionais são registrados, preferencialmente, por meio deles; ajudam a planejar as iterações, 
podem conduzir o projeto, e o teste é baseado neles.
76
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade II
Com relação ao princípio centrado na arquitetura, tem-se:
•	 arquitetura	é	a	organização	fundamental	do	sistema	em	sua	totalidade;	inclui	elementos	estáticos,	
dinâmicos, o modo pelo qual trabalham juntos e o estilo arquitetônico total que guia a organização 
do sistema;
•	 a	arquitetura	também	se	refere	a	questões	como	desempenho,	escalabilidade,	reúso	e	restrições	
econômicas e tecnológicas; no UP, a arquitetura do sistema em construção é o alicerce fundamental 
sobre o qual ele se erguerá;
•	 deve	ser	uma	das	preocupações	da	equipe	de	projeto;
•	 a	arquitetura,	juntamente	com	os	casos	de	uso,	deve	orientar	a	exploração	de	todos	os	aspectos	
do sistema;
•	 a	arquitetura	é	 importante	porque	ajuda	a	entender	a	visão	global	e	a	organizar	o	esforço	de	
desenvolvimento, facilita as possibilidades de reúso, facilita a evolução do sistema e guia a seleção 
e a exploração dos casos de uso.
O processo unificado é apresentado em quatro fases, como mostra a figura a seguir.
Concepção Elaboração Construção Transição
Fases do processo 
unificado
Entrega do 
produto para a 
produção
Figura 20 – As quatro fases do modelo unificado 
Na fase de concepção se estabelece a viabilidade de implantação do software/sistema a ser 
desenvolvido, define-se o escopo do sistema, estimam-se os custos e o cronograma, identificam-se os 
potenciais riscos que devem ser gerenciados ao longo do projeto e se faz o esboço da arquitetura, que 
servirá como alicerce para sua construção.
Na fase de elaboração se desenvolve a visão detalhada do sistema, contendo a definição 
dos requisitos funcionais, o detalhamento da arquitetura criada na fase de concepção e o 
gerenciamento dos riscos.
Na construção, o sistema é efetivamente desenvolvido e já pode ser colocado em produção, mesmo 
que seja em ambiente de teste.
77
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Na fase de transição, o sistema é entregue ao cliente para uso em produção; testes detalhados são 
realizados, e um ou mais incrementos são implantados; erros ou defeitos são corrigidos, caso apareçam 
nesse momento.
Com relação às disciplinas que determinam as atividades de trabalho, são realizadas a qualquer 
momento no ciclo de desenvolvimento do UP e entrecortam todas as fases do processo unificado, 
podendo ter maior participação em uma fase e menor influência em outras, mas ocorrendo em qualquer 
uma delas.
A próxima figura mostra uma visão da organização das disciplinas no modelo UP. O gráfico também 
é chamado de Gráfico das Baleias, em razão do seu formato peculiar.
Concepção
Análise
Análise
Implementação
Testes
Requisitos
Elaboração Construção Transição
Iter.
nº 1
Iter.
nº 1
Iter.
nº 2
Iter.
nº 2
Figura 21 – Visão da distribuição das disciplinas no UP nas fases
O processo unificado propõe que as disciplinas ocorram em paralelo nas fases e que podem ocorrer 
a qualquer momento. Isso significa que diversas atividades ou trabalhos são realizados de forma 
simultânea, dependendo do momento em que estão ocorrendo e de acordo com o plano do projeto. 
Cada disciplina pode gerar um ou mais artefatos, que são documentos produzidos, modelos, diagramas, 
especificações, códigos, planos de testes etc.
4.2.8 O Rational Unified Process (RUP)
O RUP é uma instância do Processo Unificado desenvolvido pela empresa Rational e hoje mantido 
pela IBM. Trata-se de um processo configurável de engenharia de software e serve como um guia de 
como se deve usar a linguagem de modelos UML no ciclo de desenvolvimento de software.
Os objetivos do RUP são:
•	 assegurar	uma	produção	de	 alta	 qualidade	de	 software, que realiza a necessidade do usuário 
seguindo os prazos e o orçamento;
78
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade II
•	 com	o	advento	do	Capability Maturity Model/Capability Maturity Model Integration (CMM/CMMI), 
as organizações focalizam a qualidade em primeiro plano, e o RUP pode ser bastante útil quando 
se quer atingir níveis maiores.
O RUP, como processo de desenvolvimento de software, tem quatro regras básicas, semelhantes ao 
processo unificado UP:
•	 servir	de	guia;	
•	 especificar	quais	artefatos	devem	ser	desenvolvidos	e	quando	devem	ser	desenvolvidos;
•	 dirigir	as	tarefas	individuais	e	do	time	em	sua	totalidade;	
•	 oferecer	critérios	para	monitorare	medir	os	produtos	e	atividades	do	projeto.
O RUP, semelhante ao processo unificado UP, apresenta os seguintes princípios:
•	 é	dirigido	por	casos	de	uso	(use cases);
•	 é	baseado	em	componentes;
•	 é	centrado	em	arquitetura;
•	 é	iterativo	e	incremental	(modelo	espiral);
•	 é	framework genérico de um processo de desenvolvimento.
Esse processo também apresenta as quatro fases semelhantes às do processo unificado: concepção 
ou iniciação, elaboração, construção e transição. As disciplinas, dentro das fases, são orientadas por 
modelos desenvolvidos com o uso da UML, como mostra a próxima figura.
Requisitos
Modelo de negócio, lista de requisitos, casos de uso, 
modelo de domínio, protótipo preliminar
Modelo de classes, diagrama de atividades, diagrama de 
estados, e casos de testes
Deployment, diagrama de componentes, diagramas de 
sequência e modelagem visual
Design
Implementação
Análise
Testes
Modelo de
use case
Modelo de
análise
Modelo 
design
Modelo de
implementação
Modelo de
teste
Figura 22 – O uso dos modelos da UML nas disciplinas do RUP
79
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
As disciplinas no RUP são atividades conduzidas em todas as fases de um ciclo, variando de 
intensidade conforme a fase. Dão origem aos artefatos do projeto. Em cada fase são desenvolvidas 
várias atividades do processo:
•	 modelagem	de	negócio;
•	 levantamento	de	requisitos;
•	 análise	e	design;
•	 implementação;
•	 testes	(entre	outras).
 Saiba mais
O artigo a seguir mostra como o processo RUP captura as seis 
melhores práticas do desenvolvimento moderno de software: desenvolver 
softwares interativamente; gerenciar requisitos; arquitetura baseada em 
componentes; modelagem visual de software; verificação da qualidade; e 
controle de mudanças para software.
BLEAKLEY, G.; COLLYER, K.; SCOULER, J. Best practices for software 
development teams. IBM, 17 sept. 2013. Disponível em: <http://www.
ibm.com/developerworks/rational/library/systems-software-lifecycle-
development/systems-software-lifecycle-development-pdf.pdf>. Acesso 
em: 31 mar. 2014. 
4.2.9 O processo Praxis
É um processo de desenvolvimento de software, para uso educacional, com o objetivo de dar 
suporte ao treinamento em engenharia de software e à implantação de processos em organizações que 
desenvolvem, mantêm ou contratam softwares; é baseado na experiência do professor Wilson de Pádua 
Paula Filho, assim como em alguns dos mais importantes paradigmas da área (PAULA FILHO, 2003):
•	 o	modelo	CMMI	de	maturidade	em	processos	de	software;
•	 a	notação	orientada	a	objetos	da	linguagem	de	modelos	UML;
•	 o	processo	unificado	(unified process);
•	 os	padrões	do	Institute Eletric Eletronic Engineering (IEEE) para a engenharia de software.
80
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade II
O processo Praxis é desenhado para dar suporte a projetos realizados individualmente ou por 
pequenas equipes, com duração de seis meses a um ano. Com isso se pretende que ele seja utilizável 
para projetos de fim de curso de graduação e congêneres, ou similares de aplicação de disciplinas de 
engenharia de software. Abrange tanto métodos técnicos, como requisitos, análise, desenho, testes e 
implementação, quanto métodos gerenciais, como gestão de requisitos, gestão de projetos, garantia da 
qualidade e gestão de configuração. Propõe um ciclo de vida composto por fases que produzem um 
conjunto precisamente definido de artefatos (documentos e modelos). Para construir cada um desses 
artefatos, o usuário do processo (estudante ou engenheiro de software) precisa exercitar um conjunto 
de práticas recomendáveis da engenharia de software. Na construção desses artefatos, o usuário do 
processo é guiado por padrões e auxiliado pelos modelos de documentos e pelos exemplos constantes 
do material de apoio.
 Saiba mais
Toda a estrutura do processo Praxis encontra-se definida no livro: 
PAULA FILHO, W. P. Engenharia de software: fundamentos, métodos e 
padrões. São Paulo: LTC, 2003.
Leia uma breve apresentação em: 
PAULA FILHO, W. P. Processo Praxis 3.0. Disponível em: <http://
homepages.dcc.ufmg.br/~wilson/praxis/>. Acesso em: 31 mar. 2014. 
4.2.10 O processo cleanroom (sala limpa)
Esse processo é considerado como uma aplicação prática de matemática e da estatística para produzir 
software de alta qualidade. Também considera o conceito de hardware cleanroom. Aplica fortemente 
prevenção de erros versus remoção de erros, o design correto com certificação por teste e apresenta as 
metas: processo de desenvolvimento gerenciável mais prevenção de erros.
Com relação ao gerenciamento dos projetos, o processo considera:
•	 controle	sobre	o	processo	–	progresso	evidente	mais	garantia	de	integridade	dos	artefatos;
•	 trabalho	em	equipe	com	processos	de	engenharia	bem-definidos;	
•	 gerenciamento	 de	 complexidade,	 redução	 de	 riscos,	 eliminação	 do	 refazer	 e	 atendimento	 dos	
requisitos do negócio dentro de prazos e orçamentos estabelecidos;
•	 controle	depende	da	tecnologia	empregada	pelos	times	(tecnologia	e	processos	adequados);
81
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
•	 métodos	 para	 especificação	 e	 projeto	 precisos,	 verificação	 de	 correção,	 teste	 e	 medidas	 de	
qualidade e confiabilidade;
•	 completude	e	consistência	matemática	que	leva	à	verificação	de	correção.
De acordo com Linger e Trammell (1996), o cleanroom combina métodos formais de requisitos e 
desenho com uso no teste estatístico para produzir software com quase nenhum ou nenhum defeito.
Passos para aplicação do processo cleanroom:
•	 análise	de	requisitos:	produzindo	e	revendo	especificações	informais;
•	 desenho	de	alto	nível:	convertendo	o	requisito	em	máquinas	de	estado	e	funções;
•	 desenho	detalhado:	refinamento	das	funções;
•	 codificação	por	incremento:	desenvolver	código	e	verificá-lo	usando	métodos	informais;	compilar	
código ou efetuar teste às unidades é proibido;
•	 pré-teste	por	incremento:	geração	de	casos	de	teste;
•	 teste	 estatístico	 por	 incremento:	 o	 código	 é	 compilado,	 linkado e testado; os resultados são 
validados.
Linger e Trammell (1996) apontam, ainda, as razões para que uma organização adote a abordagem 
do cleanroom quando, com o mesmo trabalho, poderia usar sua estratégia tradicional de engenharia de 
software:
•	 os	métodos	tradicionais	de	desenvolvimento	de	software já são tão usuais nas organizações em 
que o processo de descobrir defeitos nas aplicações é considerado como fato normal;
•	 a	 organização	 que	 pretende	 adotar	 o	 cleanroom tem de estar preparada para uma mudança 
radical; adotar uma filosofia “sem erros na cultura da empresa”;
•	 uma	vez	que	o	principal	objetivo	do	cleanroom é prevenir erros, o produto final é praticamente 
sem erros, com um certificado de fiabilidade científica;
•	 isso	faz	baixar	o	preço	de	produção	e	manutenção	de	um	produto	feito	em	grande	escala;
•	 os	autores	apontam,	ainda,	os	mitos	e	as	realidades	em	torno	do	processo	cleanroom:
— mito: o cleanroom irá substituir as técnicas de engenharia de software existentes. 
– Não. O cleanroom utiliza muitas das práticas existentes e, ao contrário do que dizem as 
críticas, não vai substituir todas as técnicas tradicionais.
82
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade II