Processo de Software I_Teorico

Prévia do material em texto

Inserir Título Aqui 
Inserir Título Aqui
Processo de Software
Conceitos Gerais de Processo de Software
Responsável pelo Conteúdo:
Prof. Me. Afonso Maria Luiz Rodrigues
Revisão Textual:
Prof. Me. Claudio Brites
Nesta unidade, trabalharemos os seguintes tópicos:
• Introdução;
• Top-down;
• Bottom-up;
• JAD (Joint Application Development);
• RAD (Rapid Aplication Development);
• Waterfall;
• Sashimi;
• Chaos Model;
• V-Model;
• Espiral;
• Wheel and Spoke Model;
• Incremental;
• Iterativo;
• Processo Unificado – RUP.
Fonte: iStock/Getty Im
ages
Objetivos
• Conceituar e descrever padrões e modelos básicos de processos;
• Perceber os pontos fortes e fracos de cada processo;
• Revisar os modelos de processos de software.
Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o 
último momento o acesso ao estudo, o que implicará o não aprofundamento no material 
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.
Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você 
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns 
dias e determinar como o seu “momento do estudo”.
No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões 
de materiais complementares, elementos didáticos que ampliarão sua interpretação e 
auxiliarão o pleno entendimento dos temas abordados.
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de 
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de 
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de 
troca de ideias e aprendizagem. Bons Estudos!
Conceitos Gerais de Processo de Software
UNIDADE 
Conceitos Gerais de Processo de Software
Contextualização
Falar ou escrever sobre processo de desenvolvimento de software é tão apaixonante 
e desafiador como prever o tempo para uma estação toda. Livros e mais livros, cursos e 
vídeos, fóruns e blogs são escritos diariamente de forma incessante em todo o mundo, e 
o motivo disso tudo é muito simples: os negócios das organizações!
Não são os softwares, afirmar isso seria uma grande mentira, pois, apesar dos 
processos de desenvolvimento de software terem sua origem na necessidade de 
otimizar o tempo dos programadores, arquitetos de sistemas e analistas de forma geral, 
softwares contam com um tempo de desenvolvimento inerente à época do princípio 
do desenvolvimento dos grandes sistemas comerciais, baseados em grande porte, e que 
permitiam um conhecimento tanto do negócio quanto do problema estável.
Com o avanço dos negócios, da economia, tanto as crises quanto as oportunidades 
de negócios no mundo todo começaram a ocorrer com maior frequência, e de maneira 
muito veloz. Isso impactava profundamente nas corporações e nos negócios no mundo 
todo, e um dos grandes culpados disso acontecer cada vez mais rápido, e com maior 
frequência, foram os avanços nas telecomunicações.
Isso a ponto de, em determinado momento no século XX – no início dos anos 1970 
–, haver uma crise generalizada no desenvolvimento de softwares, que levou a área de 
tecnologia da informação a repensar a forma com que escrevia seus softwares.
Percebeu-se que a forma com que se produzia artefatos, funcionalidades e sistemas 
inteiros não era nem eficiente e nem eficaz, já que, devido à velocidade com que as 
coisas aconteciam no mundo todo, essas impactavam os negócios negativamente, pois 
simplesmente a área de desenvolvimento não estava preparada para tantas mudanças de 
escopo e de requisitos, principalmente quando isso ocorria durante a fase de codificação. 
Projetos inteiros, incluindo tempo e dinheiro, eram jogados fora, eram perdidos no mar 
de solicitações de mudanças e das não-conformidades.
Principalmente por esses motivos associados, urge a necessidade de colocar esses 
softwares cada vez mais cedo no ar, complicando em muito a vida dos analistas e 
programadores. Fora o fato – comum de fato – de que um sistema podia demorar anos 
para ser entregue e a única fase de conversa que havia com os especialistas do negócio, 
clientes e, às vezes, os usuários finais do software era no início de sua produção – ou 
seja, na coleta de requisitos e no final na fase de testes. Portanto, a possibilidade de haver 
defasagem entre o que foi projetado com os requisitos da época e o que seria entregue 
contra os requisitos futuros e necessidades de negócios era gritantemente diferente.
A forma de diminuir esse gap foi verificar o que poderia ser feito para controlar 
ou tentar eliminar esse impacto. Mesmo nos dias atuais, os programadores, analistas 
e gerentes de projeto sofrem horrores com os desafios cada vez mais crescentes por 
velocidade de entrega, precisão, qualidade, custo baixo e assertividade.
6
7
Com o tempo, os pesquisadores da área, normalmente trabalhando, ou que trabalha-
ram em grandes empresas, perceberam que o desenvolvimento de software segue ciclos 
regulares, com etapas muito bem definidas, e começaram a regulamentar, na forma de 
processos e procedimentos, essas fases e seus conteúdos. Criaram boas práticas, viram 
que boa parte desses itens era repetível, testaram, publicaram seus artigos, escreveram 
livros e evoluíram até termos hoje mais de 100 processos diferentes de se fazer software, 
para cada tipo de finalidade e indústria.
Sim, o processo de desenvolvimento de softwares para um banco pode ser bem di-
ferente de como seria para um comércio que, por sua vez, é diferente do que seria para 
os militares.
Mais do que nunca, você, analista e programador, deve estar antenado a essas 
metodologias e processos, pois o mercado de trabalho está cada vez mais dinâmico, 
exigente e buscando o salvador da pátria; embora saibamos que isso não existe.
Portanto, você deve estar preparado para essa dinâmica e suas novas regras de 
jogo nesse tabuleiro chamado mercado. Fazer a diferença conhecendo e sabendo usar 
os processos de desenvolvimento mais adequados para cada situação e software que 
a empresa, onde você atua ou atuará, irá precisar para se diferenciar no mercado e 
continuar existindo – e você fará essa diferença!
7
UNIDADE 
Conceitos Gerais de Processo de Software
Introdução
Para iniciar nossa jornada no mundo dos processos de desenvolvimento de software, 
devemos retomar o SDLC (System Development Life Cycle – o Ciclo de Vida do 
Desenvolvimento de Sistemas).
O SDLC é como um guia que utilizaremos para consulta durante a execução de um 
projeto de software e nele está o começo, meio e fim de todas as coisas e atividades 
inerentes. São um conjunto de fases ordenadas e, dessa forma, os marcos do software 
podem ser estabelecidos e seguidos – e o melhor: tanto os executores dos processos de 
desenvolvimento quanto os gerentes de projeto, preocupados com a entrega do produto 
de software, podem acompanhar e ter o controle necessário para cumprir escopo, 
prazo e orçamento.
Isso mesmo, o SDLC é um processo para criar modelos e metodologias que permi-
tem você desenvolver softwares com qualidade, atendendo às mudanças do negócio.
Você já deve ter ouvido falar ou deve até mesmo conhecer vários tipos de SDLC, pois 
eles são chamados de:
• Waterfall;
• Espiral;
• Iterativo;
• Incremental;
• Prototipagem;
• RUP;
• XT;
• SCRUM.
Esses são os mais comuns, existem muitos outros e aqui nós vamos relembrar de 
alguns e ser apresentados a outros. A ideia é que você possa ampliar seus horizontes e 
perceber a quantidade de opções que tem para usar em seu dia a dia.
Como se trata de um processo, o SDLC possui fases:
• Pesquisa e análise: estudo de viabilidade, análise de custo/benefício, quais os 
limites do sistema, os riscos envolvidos, a equipe que trabalhará no projeto, se vale 
a pena desenvolver dentro ou fora, coleta de requisitos, reuniões com as partes 
interessadas, brainstormings, gente de negócio, modelagens bpm/n, regras de 
negócios, funcionalidades etc.;
• Design:é a fase de criação de layouts, arquitetura da informação, distribuição dos 
elementos na tela, interfaces humano-computador etc.;
• Testes: planejamento, criação dos casos de testes, testes unitários, testes de regres-
são e integração, entre outros; pode envolver os usuários finais ou fábricas de testes;
• Implementação: disponibilizar para ambientes produtivos o sistema todo;
8
9
• Suporte e evolução: foco em pegar os problemas que possam ter acontecido, 
mantendo o cuidado de monitorá-los atentamente no início, visando manter a 
estabilidade e corrigir prontamente se ocorrerem bugs ou flutuações inesperadas 
no desempenho, entre outras coisas. Nessa fase, podem ser percebidas mudanças 
necessárias e também testes adicionais quando se implementam essas mudanças 
ou correções. Isso se repete até decidirem que o sistema não pode evoluir mais e, 
portanto, deve ser substituído por outro.
Operate and
maintain the 
system
Analyse user
requirements
Design the 
program
Code the 
program
Document and 
test the system
Figura 1 – Gráfico contendo as 5 fases do ciclo de vida de desenvolvimento de software
Não importa quantos subitens existam num SDLC, essas 5 fases sempre se manterão.
A importância do SDLC está na oferta de que o software será concluído dentro do 
prazo e custo estabelecidos.
Sim, claro que haverá flutuações, mas essas também estarão dentro de margens 
aceitáveis. Além disso, seguindo o processo estabelecido, a entrega do software deverá 
funcionar dentro da tecnologia usada para o projeto. Se pararmos para pensar, isso re-
presenta, entre outras coisas, em economia de custos e de tempo, que, quando colocado 
no mercado, gerará vantagens competitivas importantes para as organizações.
Além de tudo isso, um dos grandes problemas enfrentados por equipes que precisam 
manter sistemas de informação no ar, quando acontece de todos os membros do time 
de desenvolvimento do projeto terem partido da empresa ou por demissão ou por irem 
para outras empresas, é a perda da memória do projeto, porque não houve cuidado no 
desenvolvimento de documentação tanto do projeto quanto do software, principalmente 
desse último. O SDLC regulamenta isso e coloca tal ação como item essencial e, por si 
só, já aumenta as chances de sobrevida do sistema enormemente.
9
UNIDADE 
Conceitos Gerais de Processo de Software
A partir da definição do SDLC, podemos partir para as perspectivas de abordagem 
de problemas para o desenvolvimento de softwares, e elas são bem conhecidas e 
servem para praticamente qualquer problema. São elas a top-down e a bottom-up – em 
português, uma abordagem de cima para baixo e a outra, de baixo para cima.
Top-down
Permite a decomposição de um problema, no nosso caso, em partes menores, 
utilizando a técnica de decomposição, ou seja, do todo para as partes. Do sistema maior, 
resultado desejado para as partes menores em subsistemas, funcionalidades, módulos, 
rotinas etc. Conforme Santos (2005, p. 16-17), 
[...] a primeira etapa é o levantamento de requisitos, seguido pela es-
pecificação, onde é criada uma descrição detalhada do que queremos. 
Na especificação, descrevemos como o sistema se comporta, e não 
como ele é construído. O detalhamento interno do sistema começa 
a aparecer quando desenvolvemos a arquitetura, a qual resulta na es-
trutura do sistema em termos de grandes componentes. Identificamos 
nesses componentes abstratos os módulos de software e os componen-
tes específicos de hardware, componentes ainda não implementados 
são desenvolvidos como parte do projeto. Com base nestes compo-
nentes, podemos finalmente construir o sistema completo. No fim do 
projeto está integração e testes dos componentes de hardware e dos 
componentes de software, fase em que grande parte dos bugs são des-
cobertos. Para isso, temos que trabalhar fortemente no planejamento e 
numa compreensão plena do sistema que será desenvolvido. Somente 
depois podemos sair escrevendo código.
Essa abordagem foi desenvolvida pelo pessoal da IBM, pelos pesquisadores Niklaus 
Wirth e Harlan Mills, por volta do início dos anos 1970. A própria engenharia de 
software utilizou esse tipo de abordagem de forma a produzir seus artefatos e processos.
A abordagem top-down, entre outras coisas, favorecia um design mais elegante de 
aplicações. Ela também foi apropriada pelo pessoal de desenvolvimento de código con-
forme o excerto a seguir:
Na programação estruturada, ao desenvolvermos um algoritmo, temos 
como objeto um produto final – o programa. Todavia, para termos 
essa transição, passamos por várias fases, no sentido cima para baixo, 
onde cada fase é documentada, e principalmente obtida por “refina-
mento” da fase anterior, até chegarmos a um nível de detalhamento 
que permita implementar o algoritmo diretamente na linguagem de 
programação. Este é o desenvolvimento top-down (CPT, 20[--]).
10
11
Conforme a própria IBM, podemos fazer uma lista de vantagens e desvantagens 
dessa abordagem:
Tabela 1 – Top-down – prós e contras
A FAVOR
• Sua organização realiza um uso focado de recursos do aplicativo gerenciado:
• A primeira implementação se torna uma vitrine para a solução de gerenciamento de identidade;
• Quando as fases são concluídas para o aplicativo gerenciado, você programou uma implementação 
mais profunda e madura da solução de gerenciamento de identidade;
• Os recursos de operação e manutenção não são inicialmente impactados tão severamente quanto 
com a abordagem de baixo para cima.
CONTRA
• A solução fornece uma cobertura limitada nas primeiras fases;
• Uma porcentagem mínima de contas de usuário é gerenciada nas primeiras fases;
• Você pode ter que desenvolver adaptadores personalizados em uma fase inicial;
• O suporte e o negócio em geral não perceberão o benefício da solução tão rapidamente;
• O custo de implementação provavelmente será maior.
Fonte: https://goo.gl/gieaKJ
Bottom-up
Todas as rotinas de nível inferior são escritas primeiro e, em seguida, ligadas entre 
si para formar um sistema completo. A programação orientada a objetos segue essa 
abordagem – onde definimos os objetos primeiro e depois usamos padrões de design 
para conectá-los e formar uma solução completa.
Essa abordagem, entre outras coisas, nos dá implantação em fases iniciais facilitada, 
já que você está iniciando construções pequenas e funcionais, porém específicas, e há, 
com certeza, um retorno mais rápido de investimento em comparação com a abordagem 
top-down por motivos óbvios de dispêndio de tempo no planejamento (já que as fases e 
o problema vão sendo quebrados em partes cada vez menores até podermos codificar).
Dessa forma, bottom-up pode, de partida, criar um impacto maior para a organização.
Essa abordagem permite testes iniciais e detalhados, já que todos os submódulos 
são implementados de forma independente. Outro benefício dessa abordagem é que 
qualquer novo produto pode reutilizar os submódulos já implementados. 
Mas isso pode levar a complicações, ao mesmo tempo em que integra os produtos 
de software completos, pois podem estar envolvidas equipes de desenvolvimento 
inteiramente diferentes e que só estão interessadas em seus próprios módulos, não no 
produto completo.
11
UNIDADE 
Conceitos Gerais de Processo de Software
Da mesma maneira que a abordagem anterior, ela também tem seus prós e contras, 
a saber:
Tabela 2 – Bottom-up – prós e contras
A FAVOR
• Consciência dos usuários e empresas sobre o produto;
• Os benefícios são realizados nas fases iniciais;
• Você pode substituir muitos processos manuais com automação precoce;
• Sua organização amplia habilidades de gerenciamento de identidade e 
compreensão durante a primeira fase;
• Substituição facilitada de processos manuais.
CONTRA
• A estrutura organizacional estabelecida pode ter que ser alterada em uma fase 
posterior de implantação;
• Devido às mudanças imediatas nos proprietários do repositório e na população 
de usuários, o lançamento terá um impacto maior e exigirá maior cooperação;• Essa estratégia é impulsionada pela infraestrutura existente, em vez de ser 
pelos processos de negócios;
• Dependência de processos comerciais já existentes;
• Difícil gerenciar o progresso do software.
Fonte: https://goo.gl/gieaKJ
JAD (Joint Application Development)
JAD é um processo que acelera o design de software e utiliza como componente 
importante o cliente e dinâmicas de elicitação de requisitos para descrever a visão do 
negócio e desenvolver uma solução com esses atores envolvidos.
Foi uma grande novidade na época porque os requisitos eram elicitados por meio de 
reuniões e entrevistas com cada usuário, ou seja, um a um. Isso nunca gerava consenso 
de requisitos e também de objetivos, coisa que o JAD resolveu colocando praticamente 
todos os envolvidos em dinâmicas, ou na mesma página e na mesma sala.
O foco de JAD é a equipe e, portanto, o mote é consenso. É justamente esse 
consenso que permite a documentação dos requisitos de forma rica e de aceitação geral, 
tendo em vista que foi participativa e justa.
Mais uma vez aqui há o dedo da IBM, um de seus pesquisadores, Chuck Morris, já 
no final da década de 1970, elaborou uma método para juntar todos os requisitos em 
sistemas de informação com uso em diferentes bases territoriais, ou seja, extremamente 
distribuídos. Isso foi importante porque JAD ajuda muito na análise e design de software. 
12
13
Participants
Facilitator
Business Sta�
Technical Sta�
Scripted Sessions
Timeboxed
Brainstorming
Helps Forming, Storming 
and Nothing of Project Team What, Why, When, Where and How
Final Project Work Product is
Create Project Ownership, 
Commitment and Buy-In
Breaks down Them/Us
Barriers
Developed
Inspected
Approved
Business Sta�
BetterUnderstand IT Issues 
and Project Management 
Levers of Control
Also See “Workshop Breakdown 
Structure (WBS)
Workshops
Join Application
Development
(JAD)
Resolve Con�icts
Identi�es Best Practices
Quickly De�nes Requirements
Figura 2 – Mapa mental do funcionamento do processo JAD
Um bom projeto candidato ao uso de JAD deve ao menos conter as seguintes 
características:
• Ser fundamental para a continuidade e o resultado da empresa;
• Projetos de desenvolvimento de software nunca feito antes;
• Possuir muitos usuários ou grupos de usuários com papeis que cruzem outros de-
partamentos e áreas, ou seja, as famosas áreas cinzentas;
• Possuir pessoas dispostas a compartilhar e participar;
• Ser problemático, produz desentendimentos entre os atores; e possuir baixa inte-
gração com outros sistemas da empresa.
Prós e contras de usarmos JAD:
Tabela 3 – JAD – prós e contras
A FAVOR
• Acelera o design;
• Melhora a qualidade;
• Promove o trabalho em equipe com o cliente;
• Cria um design da perspectiva do cliente;
• Reduz os custos de desenvolvimento e manutenção;
• As decisões são presentes;
• A maioria dos erros é detectada nas etapas de análise e design;
• Os problemas são resolvidos rapidamente;
• Os pressupostos são documentados e compreendidos.
CONTRA
• Toma uma quantidade excessiva de tempo para o planejamento e agendamento;
• Requer investimento significativo de tempo e esforço;
• Solicita especialistas altamente treinados, o que é difícil de encontrar.
Fonte: https://goo.gl/eRBtaS
13
UNIDADE 
Conceitos Gerais de Processo de Software
RAD (Rapid Aplication Development)
RAD, em linha gerais, apareceu por volta de 1980 e foi um dos primeiros modelos 
funcionais a colocar em cheque os processos tradicionais de desenvolvimento, como o 
waterfall. Por ser mais flexível, permite a mudança, aproveitando-se por exemplo de 
prototipagem. É um modelo incremental, durante o SDLC os componentes podem ser 
desenvolvidos em paralelo, depois são integrados e estão prontos para uso.
60-90 days
Team #1
Business 
Modelling
Data
 Modelling
Data
 Modelling
Process
 Modelling
Process
 Modelling
Application
Generation
Testing &
Turnover
Testing &
Turnover
Application
Generation
Process
 Modelling
Application
Generation
Testing &
Turnover
Data
 Modelling
Business 
Modelling
Business 
Modelling
Team #2
Team #3
Figura 3 – Fases do processo de desenvolvimento RAD
O modelo RAD, de James Martin, aproveita muitas coisas do processo ESPIRAL de 
Boehm – quanto aos riscos e ao elemento cíclico. Esse método tem o mérito de ser o 
precursor dos métodos ágeis.
Possui alguns princípios fundamentais como:
• Gerar satisfação no cliente por entregas antecipadas e contínuas com valor agregado;
• A mudança e seus consequentes requisitos são aceitos e acolhidos, mesmo que as 
etapas de desenvolvimento estejam já bem avançadas;
• O software pronto para uso é entregue com frequência em semanas ao invés de anos;
• Os princípios do RAD se concentram na funcionalidade e na satisfação do usuário;
• Leva em consideração o poder do feedback dos usuários finais;
• O software em produção é a principal medida de progresso.
14
15
Vamos ver quais as vantagens e desvantagens do RAD:
Tabela 4 – RAD – prós e contras
A FAVOR
• Sinergia inerente aos requisitos do próprio meio;
• Progresso mensurável;
• Gerar rapidamente o código produtivo;
• Compartimentalização dos componentes do sistema;
• Rápido, constante feedback do Usuário;
• Integração de sistemas precoce.
CONTRA
• Requer sistemas modulares;
• Dificuldade em projetos de grande escala;
• Exige interação frequente com usuários;
• Depende de desenvolvedores especializados.
Fonte: https://goo.gl/iyLKlX
Usamos RAD quando nossa demanda de desenvolvimento de software permite 
modularização e o tempo de desenvolvimento é curto, como, por exemplo, até 4 meses 
corridos. Além disso, o time deve conhecer profundamente o negócio para ser efetivo 
no desenvolvimento, isso quer dizer também que você precisa possuir em sua equipe 
profissionais experientes em design de solução.
Waterfall
Esse processo foi o primeiro a ser desenvolvido para o desenvolvimento de softwares. 
Foi criado em 1970 pelo Dr. Winston Royce e ganhou notoriedade porque estabeleceu 
um caminho rigoroso, um processo com começo, meio e fim, para se criar software. 
Possui como componentes as seguintes fases:
• Determinação de Requisitos;
• Design;
• Implementação;
• Verificação; e
• Manutenção.
Cada um desses componentes só pode seguir para o próximo se ele estiver encerrado. 
Portanto, só se avança para o design se a etapa anterior de requisitos estiver encerrada. 
Não há concomitância e nem paralelismo.
Existe, obviamente, um engessamento aqui, que, devido à pouca participação dos 
usuários finais nas outras fases do projeto, pode gerar forte desatualização e distan-
ciamento do propósito do software, já que esses usuários ou clientes somente verão o 
resultado quando o software estiver pronto.
15
UNIDADE 
Conceitos Gerais de Processo de Software
Waterfall-Model
Project Planning
Requirements
Analysis
Design
Coding
Testing
Deployment
Figura 4 - Sequência de eventos no processo Waterfall
Todavia, como em todo processo, há vantagens e desvantagens que você precisa 
conhecer:
Tabela 5 – Prós e contras do Waterfall
A FAVOR
• Os erros de design são capturados antes de qualquer software estar escrito economizando tempo durante 
a fase de implementação;
• Excelente documentação técnica é parte dos produtos e é mais fácil para os novos programadores se 
atualizarem durante a fase de manutenção;
• A abordagem é muito estruturada e é mais fácil medir o progresso por referência a marcos 
claramente definidos;
• O custo total do projeto pode ser estimado com precisão após os requisitos terem sido definidos;
• O teste é mais fácil, pois pode ser feito por referência aos cenários definidos na especificação funcional.
CONTRA
• Os clientes geralmente terão dificuldade em indicar seus requisitos no nível abstrato de uma especificação 
funcional e só apreciarão o que é necessário quando o aplicativo for entregue;
• Torna-se muito difícil e cara a reengenharia da aplicação;
• O modelo não atende à possibilidade de mudanças de requisitosdurante o ciclo de desenvolvimento;
• Um projeto geralmente pode levar muito mais tempo para entregar do que quando desenvolvido com 
uma metodologia iterativa, como o método de desenvolvimento ágil.
Fonte: https://goo.gl/eBr8lr
Apesar de estar perdendo a força para os processos ágeis de desenvolvimento, o 
processo waterfall ainda pode ser empregado com sucesso em projetos maiores e em 
empresas que exigem em seus projetos estágios rigorosos de cumprimento de escopo e 
requisitos, bem como prazos mais extensos.
16
17
Sashimi
O processo sashimi é uma forma de organizar o processo waterfall inserindo 
superposição entre as fases. Foi criado por Peter DeGrace e a novidade da sobreposição 
de fases faz com que os requisitos não se concluam até que a arquitetura esteja evoluída, 
e assim por diante.
Requisitos
Arquitetura
Design do Módulo
Implementação
Teste do Sistema
Operação e
Manutenção
Figura 5 – O modelo sashimi
Conforme Rising (2009), sashimi é às vezes referenciado como o “processo em 
cascata com sobreposição de fases” ou “processo em cascata com feedback”. Ou seja, 
desde que há a sobreposição de fases no modelo do processo sashimi, informações do 
problema podem ser postas em execução durante fases que, normalmente, no modelo 
cascata puro, precisariam estar terminadas antes de irem para a próxima.
Rising (2009) explica: “Por exemplo, desde as fases de concepção e implementação 
se sobrepõem no modelo de sashimi, problemas de execução podem ser descobertos 
durante a fase de concepção e implementação do processo de desenvolvimento”.
Sashimi é apropriado para projetos de médio porte para os quais a comunicação 
entre fases pode ser tratada de forma improvisada.
Waterfall com prototipagem
O processo waterfall tradicional é muito rígido e tem servido cada vez menos aos 
projetos de software do tempo em que vivemos; dessa forma, foram criados alguns 
processos híbridos como, por exemplo, colocar a prototipagem para dar maior 
flexibilidade ao waterfall – lembrando que a prototipagem é usada quando o cliente não 
é muito claro sobre os requisitos do projeto.
17
UNIDADE 
Conceitos Gerais de Processo de Software
Normalmente, isso segue algumas regras:
• Um primeiro protótipo do projeto é apresentado pela primeira vez ao cliente.
• Esses protótipos são refinados e o requisito final é congelar de antemão.
• Uma comunicação estreita entre empresa e cliente é a chave para o sucesso do 
modelo de protótipo.
• É um processo que usa diferentes testes e erros antes do protótipo ser finalizado.
Validar
Veri�car
Análise
de Requisitos
Projeto do
Sistema
Design do
Sistema
Testes do
Sistema
Teste de
Aceitação Operação e 
Manutenção
Codi�cação
Prototipagem Teste de Unidade 
e Integração
Figura 6 – O modelo waterfall com prototipagem
Chaos Model
A principal regra na estratégia do caos é sempre resolver a questão mais importante pri-
meiro. Portanto, nesse processo, há uma declaração muito forte de que um projeto de de-
senvolvimento de software é claramente não linear e trata-se aqui de sistemas complexos.
Conforme Raccoon (1995),
O processo de desenvolvimento de software CHAOS combina um 
loop linear de resolução de problemas para sugerir que um projeto 
consiste de múltiplos níveis inter-relacionados de resolução de proble-
mas. O comportamento de um sistema complexo emerge do compor-
tamento combinado dos blocos de construção menores.
18
19
De acordo com o excerto do mesmo artigo, Raccon (1995) elucida que o modelo 
Chaos define uma estrutura caótica dentro dos processos de software. São muitos níveis 
de resolução de problemas em um projeto:
• Nos níveis mais altos, o desenvolvedor escreve e mantém todo o programa;
• Nos níveis superiores, os desenvolvedores escrevem e mantêm os componentes;
• Nos níveis mais baixos, os desenvolvedores escrevem e mantêm objetos e funções. 
Os desenvolvedores decidem qual função ou objeto criar, criam o objeto e, em se-
guida, testam e integram a função no software;
• Nos níveis inferiores, os desenvolvedores escrevem e mantêm linhas de código 
individuais. Os desenvolvedores primeiro decidem qual linha de código escrever ou 
editar e, a seguir, mudam a fonte usando um editor. Então eles veem se o código 
parece correto e elegante o suficiente para manter.
O SDLC, ciclo de vida do Chaos, define as frases do ciclo de vida do desenvolvimento 
de software em termos de fractais que mostram que todas as fases do ciclo de vida 
ocorrem em outras fases também, ou seja, o maior padrão se replica no menor padrão, 
e assim por diante.
Para colocar um pouco de luz sobre o caos no desenvolvimento de softwares nessa 
nova abordagem, com os atores estando inseridos dentro de um ambiente complexo, 
significa em software que os resultados serão totais, completa e absolutamente 
imprevisíveis.
Nem tanto, contudo, mas o processo ChaoS tenta unificar os melhores processos 
de desenvolvimento com as melhores técnicas de gerenciamento de projetos, formando 
idealmente uma estratégia geral superior.
O relacionamento do modelo do caos com a teoria do caos é a ideia de que as questões 
arquitetônicas em larga escala não podem ser estabilizadas sem também estabilizarem-se 
os problemas “menores” no software. Dessa forma, usando esse processo, resolver um 
problema é levá-lo a um ponto de estabilidade.
V-Model
Em linhas gerais, o modelo V nada mais é do que verificar e validar todos os artefatos 
em todas as fases. Da mesma forma que um modelo estilo Waterfall, o modelo V é 
sequencial, como num SDLC tradicional, para a execução de processos.
Cada fase deve ser concluída antes da próxima fase começar. O teste do produto está 
prevista em paralelo com uma fase de desenvolvimento correspondente, como você 
19
UNIDADE 
Conceitos Gerais de Processo de Software
pode visualizar na figura a seguir.
Análise de 
Requisitos
Projeto de 
Sistema
Design de 
Arquitetura
Design do 
Módulo
Codi�cação
Design de teste 
de aceitação
Projeto de teste 
do sistema
Teste de 
aceitação
Testes do
Sistema
Teste de
Integração
Testes 
Unitários
Design de teste 
de unidade
Design de teste 
de integração
Figura 7 – Processo de desenvolvimento de software V-Model
O modelo V é uma extensão do modelo waterfall e é baseado na associação de uma 
fase de teste para cada estágio de desenvolvimento correspondente. Isso significa que, 
para cada fase única no ciclo de desenvolvimento, há uma fase de teste diretamente 
associada. Este é um modelo altamente disciplinado e a próxima fase só começa após a 
conclusão da fase anterior.
O que há a favor e contra esse processo:
Tabela 6 – Modelo V – prós e contras
A FAVOR
• Este é um modelo altamente disciplinado e as fases são completadas uma por vez;
• Funciona bem para projetos menores onde os requisitos são muito bem compreendidos;
• Simples e fácil de entender e usar;
• Fácil de gerenciar devido à rigidez do modelo. Cada fase possui entregas específicas e um processo de revisão.
CONTRA
• Alto risco e incerteza;
• Não é um bom modelo para projetos complexos e orientados a objetos;
• Modelo pobre para projetos longos e em andamento;
• Não é adequado para os projetos onde os requisitos estão em um risco moderado a alto de mudar;
• Uma vez que um aplicativo está na fase de teste, é difícil voltar e mudar uma funcionalidade;
• Nenhum software de trabalho é produzido até o final do ciclo de vida.
Fonte: https://goo.gl/TRp6Bm
20
21
Espiral
Esse processo combina a ideia de desenvolvimento iterativo com os aspectos siste-
máticos e controlados do modelo waterfall, com ênfase elevada na análise de riscos. 
Permite versões incrementais do produto ou refinamento incremental através de cada 
iteração ao redor da espiral até o final do desenvolvimento e entrega do software. Veja 
a figura a seguir:
Cumulative Cost
Evaluate Alternatives;
Identify, Resolve Risks
Determine
Objectives,
Alternatives,
Constraints
Plan
Next Phases
Develop, Verify
Next-Level Product Boehm (1988)
Progress
Through
Steps
RiskAnalysis
Operational
Prototype
Benchmarks
Simulations Models
Prototype 2
Software 
Rqts.
Requirements
Validation
Concept of
Operation
Proto-
type 1
Prototype 3
Detailed
DesignSoftware
Product
Design
Design Validation
and Veri�cation
Code
Unit
Test
Determine
Process
Objectives,
Alternatives,
Constraints
Evaluate Process
Alternatives;
Identify, Resolve
Process Risks
Develop, Verify
Next-Level
Process Plans
Review
Commitment
Partition
Integration
and TestAcceptance 
TestImplemen-
tation
Risk Analysis
Risk Analysis
R
A
Rqts. Plan
Life Cycle
Plan
Development 
Plan
Integration 
and Test Plan
Figura 8 – Processo de desenvolvimento de software Espiral
Onde podemos usar o modelo Espiral e ele se torna especialmente útil:
• Em caso de restrição orçamentária, portanto, saber os riscos é importante para não 
estourar orçamento;
• Projetos de longo termo, com potencial de ter mudanças que impactam em valores;
• Problemas de incerteza nos requisitos, o que geralmente é o caso;
• Falta de clareza em requisitos;
• Quando apesar dos requisitos, grandes mudanças são esperadas durante o ciclo de 
desenvolvimento.
21
UNIDADE 
Conceitos Gerais de Processo de Software
Tabela 7 – Modelo Espiral – prós e contras
A FAVOR
• A alteração dos requisitos pode ser acomodada sem maiores problemas;
• Permite o uso extensivo de protótipos;
• Os requisitos podem ser capturados com mais precisão;
• Usuários veem o sistema mais cedo, e ver uma tela ou uma sequência funcional é 
muito importante para eles;
• O desenvolvimento pode ser dividido em partes menores e isso ajuda a melhorar 
o gerenciamento de riscos.
CONTRA
• A gestão é mais complexa;
• O final do projeto pode não ser conhecido no curto prazo;
• Não é adequado para projetos de pequeno ou baixo risco e pode ser caro para 
pequenos projetos;
• O processo é complexo, isso significa que gente experiente deve estar envolvida;
• Os ciclos da espiral podem continuar indefinidamente;
• Um grande número de estágios intermediários requer documentação excessiva.
Fonte: https://goo.gl/TRp6Bm
Wheel and Spoke Model
O processo wheel and spoke – “roda e raio”, se você preferir – tem como inspiração 
o processo espiral projetado trabalhar com equipes menores inicialmente. Trata-se de 
uma abordagem bottom-up que retém a maior parte dos elementos do modelo em 
espiral porque ocorre através de iterações múltiplas.
É um processo que pode ser melhor utilizado em um ambiente onde vários projetos 
possuem arquitetura comum ou conjunto de recursos que podem ser abstraídos em uma 
API (Interface de programação de aplicativos).
Cross-product
Collaboration Requirements
Product C
Product B
Pro
du
ct 
A
Product 3
Product 2
Product 1
Requirements
Figura 9 – Processo de desenvolvimento de software
22
23
Incremental
No modelo incremental, os requisitos são fracionados em várias partes. Essas partes 
passarão por desenvolvimento em sequência e ciclo após ciclo serão encerradas, como 
se fosse uma sequência waterfall – ou seja, uma cachoeira termina e começa outra, e 
assim vai até o final; cada ciclo pode representar um modulo do software entregue.
Basicamente, um ciclo de desenvolvimento abrange as fases de requisitos, design, 
implementação e teste e, dessa forma, vários ciclos são produzidos até que o software 
total seja entregue.
(Build 1)
(Build 2)
(Build 3)
Design &
Development Testing
Testing
Testing
Implemention
Implemention
Implemention
Design &
Development
Design &
DevelopmentRe
qu
ire
m
en
ts
Figura 10 – Processo de desenvolvimento de software Incremental
Esse processo como qualquer outro SDLC possui pontos forte e pontos fracos. Va-
mos conhecer alguns:
Tabela 8 – Modelo Incremental – prós e contras
A FAVOR
• Gera software de trabalho rápido e cedo durante o SDLC;
• Mais flexível e mais econômico quando precisamos realizar mudanças 
no escopo ou nos requisitos;
• É mais fácil testar e depurar durante um incremento;
• Reduz os custos iniciais de entrega;
• Mais fácil de gerenciar o risco porque as peças de risco são identificadas 
no incremento.
CONTRA
• Precisa de bom planejamento e design, portanto, de gente experiente;
• Precisa de uma definição clara e completa de todo o sistema antes que 
ele possa ser dividido e construído de forma incremental;
• O custo total acaba sendo maior que do waterfall.
Fonte: https://goo.gl/4tdb1i
Dessa forma, o processo incremental pode ser usado para desenvolver softwares cujos 
requisitos são claros e definidos e os detalhes finais podem ser inseridos tardiamente; 
mas o princípio é usar gente que conheça bem o negócio para ajudar os analistas a 
coletarem os dados de forma mais precisa. Uma coisa é certa: precisa ser um time com 
experiência para lidar com fatores como riscos, coisas novas ou novas abordagens de 
desenvolvimento em softwares que entregarão alto valor aos usuários.
23
UNIDADE 
Conceitos Gerais de Processo de Software
Iterativo
O processo iterativo não está centrado em obter logo de início uma especificação 
completa de requisitos, mas sim atuando em pequenas partes, conhecendo em peque-
nas partes, revisitando e revisando sempre, complementando com novos requisitos e 
produzindo sempre uma nova versão do software a cada iteração.
Tenha em mente que, nesse processo, cada iteração entrega um produto de software 
completo, um sistema completo, que é melhorado a cada iteração.
De maneira geral, o processo iterativo se apresenta da seguinte forma:
Iteration 1 Iteration 2 Iteration 3
Analyze
Analyze
Analyze
Analyze
Analyze
Design
Implement
Test
Analyze
Design
Implement
Test
...Iteration N
Figura 11 – Processo de desenvolvimento de software Iterativo
Algumas de suas vantagens e desvantagens são:
Tabela 9 – Modelo Iterativo – prós e contras
A FAVOR
• Podemos criar apenas um projeto de alto nível antes de começar a construir o 
produto e definir a solução de design para todo o produto;
• Projetar e construir uma versão do arcabouço do sistema;
• Evoluir o design baseado no que foi construído;
• Enquanto construímos, melhoramos o produto passo a passo;
• Rastreiam-se defeitos nos estágios iniciais;
• Obtemos feedback confiável dos usuários;
• Dedicamos menos tempo à documentação e mais tempo para a construção.
CONTRA
• Mais recursos podem ser necessários;
• Embora o custo de mudança seja menor, não é adequado mudar os requisitos;
• É necessária mais atenção de gerenciamento;
• Definir incrementos pode exigir a definição do sistema completo.
Fonte: https://goo.gl/xUdQ6h
Processo Unificado – RUP
É um processo de engenharia de Software desenvolvido originalmente por uma 
empresa chamada Rational, que foi comprada pela IBM. Sua execução gera melhoria 
24
25
continua, incrementa a produtividade da equipe, cria e dá manutenção em modelos 
eficientes para tratar as diversas categorias de projeto de software, implementa direta-
mente o uso consciente de UML (Unified Modeling Language), o que gera eficiência 
e eficácia na tradução de requisitos em artefatos, bem como a entrega de softwares de 
alta qualidade em conformidade com o que o cliente realmente deseja.
Tem embarcado em seu framework:
• Desenvolvimento Iterativo;
• Gestão de requisitos;
• Modelagem visual de sistemas utilizando UML por exemplo;
• Gestão da qualidade;
• Gestão do controle de mudanças.
GO / NO GO
Inception Elaboration Transition
Lifecycle
Objective
Commit
resources for 
colaboration
Commit
resources for 
construction
Customer
acceptance
or end-of-life
Product 
mature & 
customer 
ready
Lifecycle
Architecture
Product
Release
Initial
Operational
Capability
Construction
Figura 12 – Processo de desenvolvimento de software RUP
Os aspectos favoráveis e desfavoráveis são:
Tabela 10 – Modelo RUP – prós e contras
A FAVOR
• Feedback regular de e para as partes interessadas;
• Uso eficiente dos recursos;
• Entregar exatamente o que o cliente quer;
• Problemas são descobertos no início do seu desenvolvimento;
• Desenvolvimentoiterativo;
• Melhoria da gestão do risco.
CONTRA
• O processo pode ser muito complexo para implementar;
• Desenvolvimento pode sair do controle;
• É um processo pesado;
• É mandatório o uso de um especialista para adotar totalmente este processo.
Fonte: https://goo.gl/BKgYrU
25
UNIDADE 
Conceitos Gerais de Processo de Software
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Livros
The Chaos Model and the Chaos Life Cycle
LBS RACCOON. The Chaos Model and the Chaos Life Cycle. Software Engineering 
Notes, v. 20, n. 1, p. 55-66, jan. 1995. ACM Press.
 Leitura
Metodologia de Desenvolvimento de Sistemas – JAD e RAD
https://goo.gl/7YQRZC
Jim Rising – Sashimi Waterfall Software Development Process
https://goo.gl/DtvwXv
Steve Johnston – Software CHAOS
https://goo.gl/EXhT7P
Rational Unified Process – Best Practices for Software Development Teams
https://goo.gl/UeJcAi
Fases do ciclo de vida de desenvolvimento de software
https://goo.gl/0xFa7z
Estudo comparativo de metodologias de desenvolvimento de sistemas embutidos
SANTOS, Danilo Moura.
https://goo.gl/33N7SE
CPT
https://goo.gl/Tj12TY
Top-down – prós e contras
https://goo.gl/gieaKJ
Bottom-up – prós e contras
https://goo.gl/gieaKJ
Mapa mental do funcionamento do processo JAD
https://goo.gl/GAqW7V
JAD – prós e contras
https://goo.gl/eRBtaS
Fases do processo de desenvolvimento RAD
https://goo.gl/3wf2fe
26
27
RAD – prós e contras
https://goo.gl/iyLKlX
Sequência de eventos no processo Waterfall
https://goo.gl/GAqW7V
Prós e contras do Waterfall
https://goo.gl/eBr8lr
O modelo sashimi
https://goo.gl/EnfeVK
O modelo waterfall com prototipagem
https://goo.gl/images/akxYud
Processo de desenvolvimento de software V-Model
https://goo.gl/TRp6Bm
Modelo V – prós e contras
https://goo.gl/TRp6Bm
Processo de desenvolvimento de software Espiral
https://goo.gl/TRp6Bm
Modelo Espiral – prós e contras
https://goo.gl/TRp6Bm
Processo de desenvolvimento de software
https://goo.gl/aH4Ntq
Processo de desenvolvimento de software Incremental
https://goo.gl/JmhCSQ
Modelo Incremental – prós e contras
https://goo.gl/4tdb1i
Processo de desenvolvimento de software Iterativo
https://goo.gl/8MDZsp
Modelo Iterativo – prós e contras
https://goo.gl/xUdQ6h
Processo de desenvolvimento de software RUP
https://goo.gl/GAqW7V
Modelo RUP – prós e contras
https://goo.gl/BKgYrU
27
UNIDADE 
Conceitos Gerais de Processo de Software
Referências
CENTRO DE PRODUÇÕES TÉCNIAS (CPT). Lógica de programação: top-down, 
modularização, estruturas de controle, confiabilidade, manutenibilidade e Portugol. 20[--]. 
Disponível em: <https://www.cpt.com.br/cursos-informatica-desenvolvimentodesoftwares/
artigos/logica-de-programacao-top-down-modularizacao-estruturas-de-controle-
confiabilidade-manutenibilidade-e-portugol>. Acesso em: 08 jan. 2018.
FOGGETTI, C. (Org.). Gestão ágil de projetos. São Paulo, Pearson, 2015. (e-book)
PAGE-JONES, M. Fundamentos do desenho orientado a objetos com
UML. São Paulo: Makron Books, 2001. (e-book)
PFLEEGER, S. L. Engenharia de software – teoria e prática. 2. ed. São Paulo: Pearson/
Prentice Hall, 2004. (e-book)
PRESSMAN, R. S. Engenharia de software. 7. ed. Rio de Janeiro: McGraw-Hill do 
Brasil, 2011. (e-book)
SANTOS, D. M. Estudo comparativo de metodologias de desenvolvimento de 
sistemas embutidos. 2005. Disponível em: <https://projetos.inf.ufsc.br/arquivos_
projetos/projeto_433/monografia_top.pdf>. Acesso em: 08 jan. 2018.
SCHACH, S. R. Engenharia de software: os paradigmas clássicos & orientado a 
objetos. 7. ed. São Paulo: Bookman, 2009.
SHORE, J.; WARDEN, S. A arte do desenvolvimento ágil. Rio de Janeiro: Alta 
Books 2008.
SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson, 2001. (e-book)
WAZLAWICK, R. S. Análise e design orientados a objetos para sistemas de infor-
mação: modelagem com UML, OCL e IFML. 3. ed. Rio de Janeiro: Campus, 2015.
28