Livro-Texto Unidade II - ENGENHARIA DE SOFTWARE I

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 qualquer produto da manufaturaou 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 individual de profissionais de software. Aplica 
conceitosimportantes 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 engenhariasã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 planejamento
Processos definidos
Dados de proocesso
TSP
Construção de times
Comprometimento
Possessão do plano
Possessão da qualidade
Papéis do time
Planos agressivosDetalhamento 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 
desenvolvimento e 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.
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 acabarcom 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 obtido o 
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 seexecutam 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. Umtrabalhador 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 monitorar e 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çãoou 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
— Mito: é um conjunto de práticas e princípios ortodoxos.
– Não existem princípios e práticas ortodoxas no cleanroom. Os programadores ajustam de 
modo que sirva para o projeto específico no qual estão trabalhando, no entanto os princípios 
fundamentais mantêm-se os mesmos, seja qual for o projeto.
— Mito: o cleanroom irá substituir as técnicas SE 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