MODELOS DE PROCESSOS DE SOFTWARE 1

Prévia do material em texto

Modelos de Processos 
de Software
Material Teórico
Responsável pelo Conteúdo:
Prof. Me. Artur Marques
Revisão Textual:
Prof. Me. Luciano Vieira Francisco
Processos de Software Tradicionais (Parte A)
• Princípios;
• Modelos, Métodos e Metodologias.
• Conhecer e diferenciar processos de software tradicionais quanto à sua aplicação em 
projetos de software.
OBJETIVO DE APRENDIZADO
Processos de Software
Tradicionais (Parte A)
Orientações de estudo
Para que o conteúdo desta Disciplina seja bem 
aproveitado e haja maior aplicabilidade na sua 
formação acadêmica e atuação profissional, siga 
algumas recomendações básicas: 
Assim:
Organize seus estudos de maneira que passem a fazer parte 
da sua rotina. Por exemplo, você poderá determinar um dia e 
horário fixos como seu “momento do estudo”;
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
alimentação saudável pode proporcionar melhor aproveitamento do estudo;
No material de cada Unidade, há leituras indicadas e, entre elas, artigos científicos, livros, vídeos 
e sites para aprofundar os conhecimentos adquiridos ao longo da Unidade. Além disso, você tam-
bém encontrará sugestões de conteúdo extra no item Material Complementar, que ampliarão sua 
interpretação e auxiliarão no pleno entendimento dos temas abordados;
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discus-
são, pois irão auxiliar a verificar o quanto você absorveu de conhecimento, além de propiciar o 
contato com seus colegas e tutores, o que se apresenta como rico espaço de troca de ideias e 
de aprendizagem.
Organize seus estudos de maneira que passem a fazer parte 
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Determine um 
horário fixo 
para estudar.
Aproveite as 
indicações 
de Material 
Complementar.
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
Não se esqueça 
de se alimentar 
e de se manter 
hidratado.
Aproveite as 
Conserve seu 
material e local de 
estudos sempre 
organizados.
Procure manter 
contato com seus 
colegas e tutores 
para trocar ideias! 
Isso amplia a 
aprendizagem.
Seja original! 
Nunca plagie 
trabalhos.
UNIDADE Processos de Software Tradicionais (Parte A)
Princípios
Modelos e métodos de engenharia de software são os responsáveis em dar 
corpo e estrutura à engenharia de software! O seu objetivo é tornar as atividades 
sistemáticas, repetíveis e, finalmente, orientadas ao sucesso e, com isso, atingir um 
encerramento satisfatório e o mais próximo possível dos objetivos para o sucesso.
O uso de modelos fornece uma abordagem para a solução de problemas em 
geral, todavia, para softwares tem se tornado um padrão; por consequência, traz 
uma notação e procedimentos para a análise e melhoria desses modelos. 
É sabido que os métodos fornecem uma abordagem para a especificação sis-
temática, design, construção, teste e verificação do software do item final e dos 
produtos associados de trabalho. 
Esses modelos e métodos de engenharia de software variam em escopo, desde 
uma única fase do ciclo de vida do software até a cobertura do ciclo de vida completo.
À medida que o tamanho e a complexidade do projeto de software aumentam, 
a importância de seguir um processo definido aumenta proporcionalmente.
Um processo de software organiza e prescreve as atividades necessárias para 
escrever o software, portanto, são descritivas. Esses processos podem ser prescri-
tivos ou empíricos: por exemplo, métodos ágeis são bem empíricos, isso significa 
que quando você está produzindo o software este não pode ser totalmente automa-
tizado, além do que, não existe um algoritmo preciso que você possa seguir e que 
garanta um sistema completo, correto e funcional. Todavia, existem procedimentos 
e diretrizes de processo que você pode seguir dado que garantirão alta probabilida-
de de sucesso.
A base de um processo de software bem-sucedido é transformar requisitos em 
software, simples assim! Claro, isso simplifica demais o processo, mas ilustra al-
gumas sutilezas, mesmo porque os requisitos que alimentam o processo em seu 
início são ideias nas mentes de um ou mais indivíduos – clientes, analistas de ne-
gócios, usuários etc. Afinal, a primeira coisa que devemos fazer é extrair e formar 
essas ideias em uma declaração dos requisitos; depois, a saída de um processo de 
desenvolvimento é mais do que apenas software – sim, inclui manuais do usuário, 
documentação do programa e casos de teste.
A esta altura você já deve ter percebido que não há um processo de software, dado 
que aquilo que seguimos como profissionais ou empresas é adaptado ao projeto espe-
cífico desenvolvido, à cultura da organização e às habilidades das pessoas envolvidas.
Neste momento devemos prestar atenção, pois alguns tópicos necessitam estar 
muito bem definidos em sua mente e os conceitos solidamente ancorados, mesmo 
que revisemos alguns dos referidos conceitos, vamos lá:
8
9
• Ciclo de vida do software: estamos tratando das fases de alto nível que um 
projeto de software passa ao longo do tempo – análise, design, codificação, 
testes, documentação, implementação etc;
• Modelo de ciclo de vida (SDLC): t rata-se de uma abstração que serve para 
agrupar processos de software com características compartilhadas. Alguns dos 
critérios utilizados para distinguir os modelos de processo de software são, por 
exemplo, o tempo entre fases, critérios de entrada e saída entre fases e os ar-
tefatos criados durante cada etapa, ou seja, características de comportamento 
de alto nível;
• Método: é uma técnica ou processo para gerar um resultado. Um método 
geralmente inclui uma notação para expressar resultados; além disso, aplica-se 
também a uma parte do ciclo de vida do software. Para facilitar, um método 
descreve a forma de se fazer algo, tal como abordar um problema, por exemplo;
• Metodologia: trata-se de uma coleção de métodos que se aplicam a todas as 
fases do ciclo de vida do software (SDLC) e são unificados por uma filosofia. 
A distinção entre método e metodologia é a mais difícil de definir com precisão. 
A confusão existe porque método e metodologia definem extremos opostos de 
um espectro e é difícil julgar técnicas no meio do espectro. Veja um exemplo:
Método
Programação
Estruturada Metodologia
Programação
Extrema
Técnica de
Modelagem
a Objeto
Método
de Booch
Design
orientado
a objeto
• Técnica ou Processo
• Inclui notações para expressar resultados
• Se relaciona com fases do SDLC
• Coleção de métodos
• Filoso­a Uni­cada
• Se relaciona com todas
 as fases do SDLC
Figura 1 – Quadro de abordagens de desenvolvimento, posicionando à
esquerda as que estão como método e à direita as que tendem a metodologias
Fonte: Adaptada de IEEE 730.1, 2001, p. 2
• Processo de software: t ratamos aqui da série ou sequência de etapas que 
uma pessoa ou organização segue para produzir um sistema de software. Um 
processo de software não é abstrato, sendo utilizado por um indivíduo ou uma 
organização em um projeto específico. É uma série detalhada de etapas que 
um indivíduo, uma equipe ou empresa segue durante a produção de um siste-
ma de software. Os processos de software são detalhados. Em seu desenvolvi-
mento, um processo de software é uma instância específica de uma descrição 
mais abstrata do processo, portanto, envolve, em última forma, uma ou mais 
tarefas/atividades. Os processos de software devem ser selecionados e adap-
tados à cultura da organização, às experiências e aos talentos dos indivíduos 
envolvidos e aos requisitos exclusivos do projeto.
9
UNIDADE Processos de Software Tradicionais (Parte A)
Um bom processo de software é repetível, previsível, apreensível, mensurável, 
improvável. Essas características permitem que o processo seja reutilizado e apri-
morado ao longo do tempo. A previsibilidade é importante porque muitas organi-
zações valorizam a previsibilidade acima daeficiência máxima. 
Para facilitar o raciocínio sobre processos de software, é útil criar categorias 
abstratas ou agrupamentos específicos de processos de software. Essas categorias 
são criadas abstraindo detalhes específicos de processos individuais. As categorias 
de processos de software são chamadas de modelos de ciclo de vida de desen-
volvimento de software.
• Estrutura do processo: necessita ser adaptável, a natureza do desenvolvi-
mento de software torna improvável que exista um processo prescritivo que 
seja melhor para todos os projetos em todos os ambientes. Em vez disso, a 
maioria dos indivíduos e organizações adaptará um processo recomendado 
para as suas necessidades particulares. Por exemplo, o Processo Unificado da 
Rational (RUP), adquirido pela IBM – apesar de no Brasil utilizarmos Scrum 
e outras ferramentas associadas ao gerenciamento de projetos –, atualmente 
é a estrutura de processo de desenvolvimento de software mais conhecida e 
amplamente utilizada;
• Ciclo de vida de desenvolvimento de software (SDLC): é a sequência de 
fases pelas quais um projeto de desenvolvimento de software passa, por exem-
plo, requisitos, análise, design, implementação, teste etc.; mas poderíamos uti-
lizar iniciação, elaboração, construção e transição, de modo que nomear a fase 
não é algo “engessado” – o que importa são as formas com que produzimos 
os artefatos de cada fase.
Significa que no começo o objetivo é entender o problema. Isso pode exigir 
inicialmente a compreensão do ambiente no qual o problema está inserido; depois, 
os requisitos de uma solução são identificados, os quais são estudados em maior 
profundidade e detalhamento, tal como a preparação para o desenvolvimento de 
uma solução que os atenda. Pode haver muitos requisitos, mas a solução deve ter 
uma arquitetura geral, esta que fornece a estrutura organizacional para o design 
detalhado de soluções individuais; depois, o foco muda para a construção ou imple-
mentação dos projetos de solução. Todo o trabalho deve ser testado e, por fim, o 
sistema pode ser integrado para que o usuário o utilize. Quando em produção, al-
terações futuras e melhorias são consideradas na manutenção enquanto o software 
estiver cumprindo a sua designação.
Modelos de ciclo de vida de desenvolvimento de software: as categorias de 
processos de software são chamadas de modelos de ciclo de vida de desenvol-
vimento de software. Um modelo de processo de software descreve uma coleção 
abstrata de processos de software que compartilham características comuns – ge-
ralmente nos critérios de especificação, tempo, entrada e saída para as fases do 
ciclo de vida do software.
10
11
Modelos de processos possuem algumas propriedades, sendo as características 
que os distinguem e incluem:
• Completude: o grau em que todos os requisitos foram implementados e veri-
ficados dentro do modelo;
• C onsistência: o grau em que o modelo não contém requisitos, asserções, res-
trições, descrições, funções ou componentes conflitantes;
• Correção: o grau em que o modelo atende aos seus requisitos e às especifica-
ções de projeto, estando livre de defeitos.
Afinal, os modelos são construídos para representar objetos do mundo real e 
os seus comportamentos para responder a perguntas específicas sobre como o 
software deve operar. Quando analisados e descobertos erros, a sua correção é 
comumente verificada através de nova simulação ou revisão, até que estejamos 
satisfeitos com o resultado.
Modelos e Métodos em
Engenharia de Software
Modelos
Tipos 
de Modelos
Análise
de Modelos
Métodos de
Engenharia
Princípios de
Modelagem
Propriedades e
Expressões de
Modelos
Sintaxe,
Semântica e
Pragmática
Pré-condições,
Pós-condições e
Invariantes
Modelagem
Informacional
Análise de
Completude
Análise de
Consistência
Análise de
Correção
Rastreabilidade
Análise de
Interação
Métodos
Heurísticos
Métodos
Formais
Métodos de
Prototipação
Métodos 
Ágeis
Modelagem
Comportamental
Modelagem
Estrutural
Figura 2 – Detalhamento dos tópicos para os modelos e métodos de engenharia de software
Modelos, Métodos e Metodologias
Já que pretendemos entender de onde vieram as coisas para podermos utilizá-las 
a contento, a Figura 1 demonstra uma proposta taxinômica para modelos e méto-
dos que, como vimos, possuem os seus processos; começaremos, então, do mais 
simples, abordando os métodos até irmos aos considerados ágeis e lean. 
11
UNIDADE Processos de Software Tradicionais (Parte A)
Desenvolvimento Code-and-Fix
Sem dúvida, é o primeiro; mas não se engane, não se trata de um modelo, 
mas de algo empírico, em tentativa e erro. Portanto, provavelmente é o “modelo 
mais simplista”, embora o mais utilizado de todos, principalmente se você contar 
os milhões de softwares criados em universidades, cursos técnicos, empresas de 
garagem, trabalhos de conclusão de curso ou experimentos científicos de toda a 
natureza ao longo de todo o Planeta.
Um processo seguindo o modelo “code + fix” – código e correção – começa 
com apenas uma análise de requisitos suficiente para iniciar a codificar. Quan-
do algo está funcionando, é retrabalhado até atender a todos os requisitos do proje-
to, o que pode exigir ciclos repetidos de análise, design e codificação de requisitos.
Apesar de simplista, esse “modelo” pode ser uma escolha lógica para alguns 
programas. Se você estiver construindo um programa para o seu uso pessoal, 
lembrando que neste caso você é a única fonte geradora de requisitos, é um pro-
grama pequeno, simples e que não se planeja ampliá-lo no futuro – perceba que em 
nenhum momento foi citada a palavra sistema quando explicado o “code + fix”.
Claro que há problemas, os quais comumente ocorrem quando tentamos aplicá-lo 
a um projeto que não atende aos critérios já mencionados. O motivo parece óbvio, 
tratando-se do volume de retrabalho e possível destruição da própria solução para fa-
zer uma que funcione. O “modelo” code + fix foi preponderante na década de 1970. 
Modelo Waterfall – Cascata ou Cachoeira
No final da década de 1960, os avanços no hardware criaram uma demanda 
por programas cada vez maiores, portanto, não dava mais para fazer via “code + 
fix” ou estilos informais “ad hoc” de programação e que funcionavam para peque-
nos programas, mas que não operavam a contento quando aplicados a programas 
maiores. A solução oferecida foi um modelo de desenvolvimento mais formal, com 
fases bem separadas de análise, design e teste e com documentação sólida.
Esse modelo é uma abordagem sequencial e linear do ciclo de vida de desen-
volvimento de software SDLC, de uso comum ainda na engenharia de software 
e no desenvolvimento de produtos. Tornou-se tão popular que o seu esquema foi 
largamente empregado no ambiente de gerenciamento de projetos, institutos famo-
sos como o PMI – Instituto de Gerenciamento de Projetos –, por exemplo, somente 
há cinco anos reconheceu e publicou o gerenciamento de projetos ágeis a despeito 
do excelente PMBOK – corpo de conhecimentos em gerenciamento de projetos 
que segue uma estrutura baseada no modelo em cascata. Esse modelo enfatiza 
uma lógica de progressão de etapas, fazendo-nos lembrar da direção que a água 
corre sobre a beira de um penhasco, sendo que as metas ou os marcos distintos 
são definidos para cada fase do desenvolvimento e não podem ser revisados após 
a conclusão da qual. 
12
13
 Como fato histórico, vale notar que o termo cascata foi cunhado por Winston 
W. Royce, em 1970. Apesar de estar em lenta descontinuidade em projetos de 
software, ainda é preponderante em projetos para aplicações de design industrial.
De�nição de
requisitos
Projeto de sistemas
e de software
Implementação e
teste de unidades
Integração e teste
de sistemas
Operação e
Manutenção
Figura 3 – Modelo em cascata
Fonte: S OMMERVILLE, 2011, p. 30
Importante!
Em um modelo em cascata, cada fase deve ser concluída completamente antes que a 
próxima fase possa começar. Esse tipo de modelo de desenvolvimento de software é ba-
sicamente usadopara o projeto, que é pequeno e não há requisitos incertos. No final de 
cada fase, é realizada uma revisão para determinar se o projeto está no caminho certo e 
se deve ou não continuar ou descartar o projeto (SOMMERVILLE, 2011, p. 30).
Trocando ideias...
Nesse modelo, o teste de software é iniciado somente após a conclusão do de-
senvolvimento. No modelo em cascata, as fases não se sobrepõem. Idealmente, 
nunca haveria a necessidade de retroceder no ciclo de vida – isto é, retornar a uma 
fase anterior para corrigir um problema que foi descoberto em uma etapa posterior.
O modelo em cascata é uma daquelas ideias que soam bem na teoria, mas 
falham na prática; todavia, é atraente por ser parecido com a engenharia e, à 
época – início da década de 1970 –, havia um desejo de tornar o desenvolvimen-
to de software mais como uma disciplina de engenharia. Uma das razões pelas 
quais o modelo em cascata falha na prática é a dificuldade em concluir as etapas 
sequencialmente, sem retroceder, de modo que o tempo provou ser cada vez mais 
necessário retroceder, razão pela qual a comunidade começou a pensar em outras 
formas de realizar essa missão. 
Uma das sugestões foi construir um protótipo antes de se comprometer com 
um design final, ou envolver o cliente no início e nos estágios-chave do ciclo de 
vida – isso não lhe lembra um processo ágil? Ademais, no modelo em cascata não 
13
UNIDADE Processos de Software Tradicionais (Parte A)
há retorno! As atividades sugeridas que vieram com o modelo em cascata foram 
projetadas para limitar qualquer retrocesso a, no máximo, uma fase.
Riscos não são considerados dentro de um processo formal, no mínimo apesar 
de serem percebidos, os problemas tendem a aparecer primeiro durante a imple-
mentação e o teste com o modelo em cascata, isto porque é a primeira vez que as 
ideias são colocadas em prática e os usuários avaliarão e... – bem, você já sabe o 
que acontece.
Analisaremos rapidamente o que ocorre em cada fase desse modelo neste exem-
plo fictício de um novo sistema de informação para um banco:
Coleta e análise de requisitos: nesta fase, os requisitos são reunidos pelo 
analista de negócios e analisados pela equipe. Os requisitos são docu-
mentados durante esta fase e os esclarecimentos podem ser solicitados. 
Os analistas de negócios documentam o requisito com base em sua 
discussão com o cliente. Analisar os requisitos revelou que a equipe do 
projeto precisa de respostas para as seguintes perguntas que não foram 
abordadas no documento de requisitos:
• O novo aplicativo bancário será usado em mais de um país?
• Temos que suportar vários idiomas?
• Quantos usuários devem usar o aplicativo?
[...]
Projeto de sistema: o arquiteto e os membros seniores da equipe traba-
lham na arquitetura de software, no design de alto e baixo nível do proje-
to. É decidido que o aplicativo bancário precisa ter recursos redundantes 
de “backup e failover” (cópia de segurança, redundância e contingência), 
para que o sistema esteja sempre acessível. O arquiteto cria os diagramas 
de arquitetura e os documentos de design de alto/baixo nível.
Implementação: a equipe de desenvolvimento trabalha na codificação do 
projeto. Pegam os documentos/artefatos de design e garantem que sua 
solução siga o design finalizado pelo arquiteto. 
Como é um aplicativo bancário e a segurança era uma alta prioridade nos 
requisitos do aplicativo, implementam várias verificações de segurança, 
recursos de log de auditoria no aplicativo.
Eles também realizam várias outras atividades, como um desenvolvedor sê-
nior, revisando o código de outros desenvolvedores para verificar se há algum 
problema. Alguns desenvolvedores realizam análises estáticas do código.
Testando: a equipe específica testa o aplicativo completo e identifica 
quaisquer defeitos, que são corrigidos pelos desenvolvedores e a equipe 
de avaliação testa as correções para garantir que os defeitos sejam cor-
rigidos. Realizam também testes de regressão do aplicativo para verifi-
car se novos defeitos foram introduzidos. Testadores com conhecimento 
14
15
do domínio bancário também foram contratados para o projeto, para 
que pudessem testar o aplicativo com base na perspectiva do domínio. 
As equipes de teste de segurança foram designadas para testar a seguran-
ça do aplicativo bancário.
Desdobramento, desenvolvimento: a equipe cria e instala o aplicativo nos 
servidores que foram adquiridos para o qual. Algumas das atividades de 
alto nível incluem a instalação do sistema operacional nos servidores, a 
instalação de patches de segurança, a proteção dos servidores, a insta-
lação de servidores web e de aplicativos, a instalação do banco de dados 
etc. Eles também coordenam com as equipes administrativas de rede e de 
Tecnologia da Informação (TI) etc., para finalmente colocar o aplicativo 
em funcionamento nos servidores de produção.
Manutenção: durante a fase de manutenção, a equipe garante que o apli-
cativo esteja funcionando sem problemas nos servidores e sem nenhum 
tempo de inatividade. Os problemas relatados após a entrada em operação 
são corrigidos pela equipe e testados pela equipe de teste. (TRYQA, 2019)
Mesmo após a publicação do Manifesto ágil, por volta de 2001, esse modelo 
continuou sendo usado por muitas organizações até por volta de 2010. Atualmente, 
a maioria dos projetos segue a metodologia ágil, alguma forma de modelo iterativo 
ou um dos outros padrões, dependendo dos requisitos específicos do projeto – lem-
brando que quanto mais incertos os requisitos, mais tendentes ao “agilismo”. 
Fazendo um resumo para sabermos quando utilizar esse modelo, temos o seguinte:
• Utilizado apenas quando os requisitos são muito bem conhecidos, claros e fixos;
• A definição do produto é estável;
• A tecnologia é entendida;
• Não há requisitos ambíguos;
• Recursos amplos com a experiência necessária estão facilmente disponíveis;
• O projeto é de curta duração.
Modelo Spiral – Espiral
O modelo em espiral a primora os modelos que o precederam – code + fix e 
waterfall – porque é um padrão orientado a riscos – e não orientado a documentos 
ou códigos. Foi criado por Boehm, em 1988.
Esse modelo lida com os riscos no início do ciclo de vida do software – e não 
quando de sua entrega, muito menos “ad hoc”. Portanto, quando há mais tem-
po para lidar com os problemas que os riscos podem causar e antes que haja 
quantidade significativa de trabalho concluído que possa ser afetado. O modelo é 
suficientemente genérico para acomodar outros padrões de desenvolvimento de 
software, por exemplo, em que o próprio modelo em cascata seja utilizado durante 
as iterações.
15
UNIDADE Processos de Software Tradicionais (Parte A)
Uma das características únicas do modelo em espiral é que as fases não são 
predeterminadas; na verdade, são determinadas após a análise de risco, de tal 
maneira que se a análise de risco revelar um alto índice de o usuário não aceitar a 
GUI – interface do usuário – a próxima etapa poderá ser uma fase de prototipagem.
Figura 4 – Modelo em espiral
Fonte: Adaptada de BOEHM, 1988
Importante!
Um loop ao redor do círculo representa uma fase do processo. Cada fase possui 4 partes: 
i) Determine as alternativas e restrições dos objetivos; ii) Avalie alternativas, avalie riscos, 
resolva riscos; iii) Desenvolva e valide. Qualquer modelo de desenvolvimento pode ser 
usado durante esta etapa; e iv) Planeje a próxima fase. (BOEHM, 1988) 
Trocando ideias...
16
17
De certa forma, o modelo em espiral foi uma “ponte” para o desenvolvimento 
iterativo, afinal, permite ou acomoda o modelo em cascata do desenvolvimento de 
software, mas ao mesmo tempo permite tendências iterativas que à época – quan-
do voltamos para os idos de 1988 – eram muito diferentes da prática comum e 
vistas com desconfiança pelas organizações conservadoras.
Vejamos quando utilizar o modelo em espiral:
• A avaliação de custos e riscos é importante;
• Para projetos de médio a alto risco;
• O compromisso de longo prazodo projeto torna-se imprudente devido a pos-
síveis mudanças nas prioridades econômicas;
• Os usuários não têm certeza de suas necessidades;
• Os requisitos são complexos;
• Desenvolvimento de uma nova linha de produtos ou softwares;
• Mudanças significativas são esperadas durante o percurso do desenvolvimento.
Modelo Incremental
É uma forma de se desenvolver softwares em que os requisitos são divididos em 
vários módulos independentes do ciclo de desenvolvimento de software utilizado. 
O desenvolvimento incremental é realizado em etapas do projeto de análise, imple-
mentação, teste/verificação, manutenção. 
Primeiro, um sistema de trabalho simples é implementado contendo apenas al-
guns recursos básicos para ser entregue ao cliente. Depois disso, muitas iterações/
versões sucessivas são implementadas e entregues ao cliente até que o sistema 
desejado seja realizado.
Cada iteração passa pelas fases de requisitos, design, codificação e teste, e cada 
versão subsequente do sistema adiciona função à versão anterior até que toda a fun-
cionalidade projetada tenha sido implementada. O sistema é colocado em produção 
quando o primeiro incremento é entregue. O primeiro incremento geralmente é um 
produto principal onde os requisitos básicos são abordados e os recursos adicionais 
são incluídos nos próximos incrementos. Depois que o produto principal é analisa-
do pelo cliente, há desenvolvimento do plano para o próximo incremento.
A abordagem incremental utiliza um número definido de etapas e o desenvolvi-
mento vai do início ao fim em um caminho linear de progressão.
É feito nas etapas de projeto, implementação, teste/verificação, manutenção. 
Podem ser divididos em suas etapas, mas a maioria dos modelos incrementais 
segue o mesmo padrão. O modelo em cascata é uma abordagem tradicional de 
desenvolvimento incremental.
17
UNIDADE Processos de Software Tradicionais (Parte A)
De�nir escopo
dos requisitos
Priorizar
requisitos
(incrementos)
Projetar
Arquitetura
Desenvolver
incremento
Integrar
incremento
Versões Versão Final
Veri�car e
Validar incremento
Validar
software
Figura 5 – Exemplo de modelo incremental
Fonte: GHAHRAI, 2018
Importante!
O modelo preconiza o incremento, ou seja, entregar um pouco mais a cada vez até que 
o produto de software seja finalizado. O produto de software é definido como acabado 
quando atende a todos os seus requisitos. Este modelo combina os elementos do modelo 
em cascata com a filosofia iterativa de prototipagem. O produto é decomposto em vários 
componentes, cada um dos quais é projetado e construído separadamente (denominado 
como compilações). Cada componente é entregue ao cliente quando está completo. Isso 
permite a utilização parcial do produto e evita um longo tempo de desenvolvimento. 
Existem alguns problemas com este modelo. Um é que cada nova construção deve ser 
integrada às construções anteriores e a quaisquer sistemas existentes. A tarefa de de-
compor o produto em compilações também não é trivial. Se houver poucas compilações 
e cada uma se degenerar, isso se transformará no modelo build-and-fix (construir e con-
sertar) (GHAHRAI, 2018, p. 1-2).
Trocando ideias...
Temos as seguintes vantagens ao utilizar um modelo incremental:
• Gera software de trabalho rapidamente e no início do ciclo de vida do software;
• Mais flexível – menos dispendioso para alterar o escopo e os requisitos;
• Mais fácil de testar e depurar durante uma iteração menor;
• Mais fácil de gerenciar riscos porque as peças arriscadas são identificadas e 
manipuladas durante a sua iteração;
• Cada iteração é um marco facilmente gerenciado.
Por fim, lembre-se: a abordagem incremental utiliza um número definido de eta-
pas e o desenvolvimento vai do início ao fim em um caminho linear de progressão. 
O desenvolvimento incremental é realizado nas etapas de projeto, implementação, 
teste/verificação, manutenção. Podem ser divididos em subetapas, mas a maioria 
dos modelos incrementais segue o mesmo padrão.
18
19
Modelo de Prototipagem
É definido como um modelo de desenvolvimento de software no qual um protó-
tipo é construído, testado e retrabalhado quando necessário até que um protótipo 
aceitável seja alcançado. C ria também uma base para produzir o sistema final. 
Funciona melhor em cenários em que os requisitos do projeto não são conhecidos. 
É um método iterativo, de tentativa e erro – empírico –, que ocorre entre o desen-
volvedor e o cliente.
Requisito Design Rápido Avaliação peloUsuário
Implementação
e Manutenção
Construção
Protótipo
Re�no do
Protótipo
Figura 6 – Fases do modelo de prototipagem
O modelo de prototipagem possui, a partir de seu SDLC, vários tipos que co-
nheceremos a seguir.
• Protótipo de lançamento rápido: o descarte rápido é baseado no requisito 
preliminar. É rapidamente desenvolvido para mostrar como o requisito será 
visualmente. O feedback do cliente ajuda a gerar alterações no requisito, e o 
protótipo é criado novamente até que o requisito seja atingido. Nesse método, 
um protótipo desenvolvido será descartado e não fará parte do protótipo final-
mente aceito. Essa técnica é útil para explorar ideias e obter feedback instan-
tâneo para os requisitos do cliente;
• Prototipagem evolutiva: o protótipo desenvolvido é aprimorado de forma in-
cremental com base no feedback do cliente até que seja finalmente aceito. Isso 
ajuda a economizar tempo e esforço porque desenvolver um protótipo do zero 
para cada iteração do processo pode, às vezes, ser frustrante. É útil para um 
projeto que utiliza uma nova tecnologia que não é bem compreendida. É uti-
lizado também para um projeto complexo em que todas as funcionalidades 
devem ser verificadas uma vez. É útil quando o requisito não é estável ou não 
é entendido claramente no estágio inicial;
• Prototipagem incremental: o produto é fracionado em diferentes pequenos 
protótipos e que são desenvolvidos individualmente. Eventualmente, os dife-
rentes protótipos são mesclados em um único produto. Esse método é útil para 
reduzir o tempo de feedback entre o usuário e a equipe de desenvolvimento 
de aplicativos;
• Prototipagem extrema: é empregada principalmente para o desenvolvimento 
na web. É composta por três fases sequenciais:
19
UNIDADE Processos de Software Tradicionais (Parte A)
 » Protótipo básico, com toda a página no formato HyperText Markup Language 
(HTML);
 » Simulação do processo de dados utilizando uma camada de serviços no pro-
tótipo;
 » Implementação e integração de serviços ao protótipo final.
A prototipagem oferece um esboço – um “fake”, se preferir – em pequena escala 
do produto e é empregado para obter feedback do cliente. 
Retorno do
Cliente
Desenvolvimento/
Re�no do Protótipo
Teste do
Protótipo 
pelo Cliente
Figura 7 – Ciclo geral da prototipagem
Fonte: Geeks for Geeks, 2018
Importante!
Esse modelo é usado quando os clientes não conhecem previamente os requisitos exatos 
do projeto. Neste modelo, um protótipo do produto final é primeiro desenvolvido, testa-
do e refinado de acordo com o feedback do cliente repetidamente até que seja alcançado 
um protótipo final aceitável que forme a base para o desenvolvimento do produto final 
(GEEKS FOR GEEKS, 2018).
Trocando ideias...
Como boas práticas de prototipagem você deve observar os seguintes precei-
tos fundamentais:
• Utilizar a prototipagem quando os requisitos não estiverem claros;
• Executar a prototipagem de forma planejada e controlada;
• Fazer reuniões regulares, pois são vitais para manter o projeto no prazo e custo;
• Os usuários e designers devem estar cientes dos problemas e das armadilhas 
da prototipagem – um protótipo não é um software de produção;
20
21
• É necessária a aprovação do primeiro protótipo; somente depois permite-se 
que a equipe avance para a etapa seguinte;
• Você deve selecionar o tamanho da etapa – duração – apropriado para cada versão.
Modelo RAD – Desenvolvimento Rápido de Aplicativos
RAD é uma metodologia de desenvolvimento de software. Diferentementedo 
método cascata/waterfall. Enfatiza o software de trabalho e feedback do usuário 
sobre o planejamento rigoroso e registro de requisitos. Portanto, esse modelo é 
menos conversa, mais ação e teste como pontos fortes. Embora não enfatize o 
planejamento rigoroso, existem ainda algumas etapas ou fases pelas quais cada 
projeto de desenvolvimento passa ao utilizar RAD, vejamos:
• Descoberta de requisitos do projeto a ser realizado no limite de seu orçamento 
e tempo;
• Prototipagem em ciclo de melhoria até atingir o objetivo do(s) requisito(s);
• O feedback dos usuários deve ser constante;
• Reconstrução focada na melhoria, nos ajustes e nas descobertas, buscando 
atender ao requisito do cliente;
• Testar maciçamente até que o sistema funcione tal como espera-se nos requisitos.
Ademais, RAD não funciona para todos os projetos e, como qualquer metodolo-
gia organizacional, não deve ser utilizado indiscriminadamente; contudo, funciona 
bem em alguns casos específicos, como quando você precisa fazer algo rapida-
mente, ou seja, com prazo apertado; ou quando houver um conjunto de usuários 
disponíveis para realizar os testes maciços que você precisa.
Além disso, você pode usar RAD também quando o seu orçamento de projeto é 
suficientemente robusto, afinal, para fazer as coisas rápidas e certas você precisa de 
mão de obra sênior e atualmente isso, além de raro, é muito caro – mas com toda 
a certeza valerá cada centavo.
O desenvolvimento de cada módulo envolve as várias etapas básicas, tal como 
no modelo em cascata, ou seja, análise, projeto, codificação e teste etc. Outra ca-
racterística marcante desse modelo é um curto período, ou seja, o prazo de entrega 
– caixa de tempo ou marco, pois não estamos, neste caso, em hipótese alguma 
tratando de sprint – geralmente é de 60 a 90 dias.
21
UNIDADE Processos de Software Tradicionais (Parte A)
Teste e entrega
do Produto Final
Integração de todos
os Módulos
Desenvolver
Módulo n
Time nTime 2Time 1
Análise
Design
Código
Arte
Desenvolver
Módulo 2
Modularização
de Requisitos
Elicitação
de Requisitos
Desenvolver
Módulo 1
Figura 8 – Modelo RAD, fluxo operacional
Fonte: Geeks for Geeks, 2018
Possui 4 fases básicas, planejamento de requisitos: envolve o uso de várias técnicas usadas 
na obtenção de requisitos, como brainstorming, análise de tarefas, análise de formulários, 
cenários de usuário, Fast (Técnica de Desenvolvimento de Aplicativo Facilitado) etc. Ele tam-
bém consiste em todo o plano estruturado que descreve os dados críticos, métodos para 
obtê-lo e processá-lo para formar o modelo refinado final. Descrição do usuário: essa fase 
consiste em receber feedback do usuário e criar o protótipo usando ferramentas de desenvol-
vedor. Em outras palavras, inclui reexame e validação dos dados coletados na primeira fase. 
Os atributos do conjunto de dados também são identificados e elucidados nesta fase. Cons-
trução: nesta fase, o refinamento do protótipo e entrega ocorre. Inclui o uso real de podero-
sas ferramentas automatizadas para transformar modelos de processo e dados no produto 
final de trabalho. Todas as modificações e aprimoramentos necessários também são feitos 
nesta fase. Cutover: todas as interfaces entre os módulos independentes desenvolvidos por 
equipes separadas devem ser testadas corretamente. O uso de ferramentas e subpartes po-
derosamente automatizadas facilita o teste. Isso é seguido pelo teste de aceitação do usuário 
(GEEKS FOR GEEKS, 2018).
Ex
pl
or
Portanto, se você possui um grupo de usuários que podem fornecer feedback 
consistente e confiável sobre os protótipos criados, o desenvolvimento rápido 
de aplicativos é um ótimo modelo a seguir. Modernamente, o RAD evoluiu e se 
adaptou, concentrando-se na coleta dos requisitos do cliente por meio de oficinas ou 
grupos focais, teste precoce dos protótipos pelo cliente utilizando o conceito iterativo 
baseado no TDD – desenvolvimento baseado em teste como um caminho possível –, 
reutilização dos protótipos existentes – reuso de componentes –, integração contínua 
e entrega rápida. Ou seja, acabou virando um tipo de ágil, mas originalmente nunca 
pretendeu sê-lo.
22
23
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Vídeos
Prototipação
https://youtu.be/L81RtZzzGkI
Engenharia de Software – Modelo em Espiral de Boehm 
https://youtu.be/GCrxnZZCcYU
Engenharia de Software – Desenvolvimento Incremental
https://youtu.be/oN3gZ5uogR0
Métodos Ágeis ou Método em Cascata?
https://youtu.be/AF383vAbV2U
23
UNIDADE Processos de Software Tradicionais (Parte A)
Referências
BOEHM, B. W. A spiral model of software development and enhancement. 
1988. Disponível em: <https://csse.usc.edu/TECHRPTS/1988/usccse88-500/
usccse88-500.pdf>. Acesso em: 24 set. 2019.
GEEKS FOR GEEKS. Software engineering prototyping model. 2018. 
Disponível em: <https://www.geeksforgeeks.org/software-engineering-prototyping-
model>. Acesso em: 25 set. 2019.
GHAHRAI, A. Modelo incremental. 2018. Disponível em: <https://www.testin-
gexcellence.com/incremental-model>. Acesso em: 25 set. 2019.
IEEE STANDARDS ASSOCIATION. IEEE 730.1-2001 – guia IEEE para planeja-
mento de garantia de qualidade de software. [S.l.], 2001.
PETERS, J. F.; WITOLD, P. Engenharia de software. 3. ed. São Paulo: Campus, 2001.
SEBOK – guide to the system engineering body of knowledge. 2011. Disponível 
em: <https://www.sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_
of_Knowledge_(SEBoK)>. Acesso em: 24 set. 2019.
SOMMERVILLE, I. Engenharia de software. 9. ed. EUA: Addison Wesley, 2011.
SOUZA, R. F. Requisitos não funcionais. 2017. Disponível em: <https://github.
com/Desenho-2-2017/Ecom_merci/wiki/Requisitos-n%C3%A3o-Funcionais>. 
Acesso em: 24 set. 2019.
TRYQA. O que é o modelo waterfall – exemplos. 2019. Disponível em: <http://
tryqa.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it>. 
Acesso em: 24 set. 2019.
WAZLAWICK, R. S. Análise e projeto orientado a objetos para sistemas de 
informação – modelando com UML, OCL e IFML. EUA: Elsevier, 2014.
24