I Teorico 2

Processo
Inserir Título
de Software
Aqui
Inserir Título Aqui
Conceitos Gerais de Processo de Software
Responsável pelo Conteúdo:

Prof. Me. Afonso Maria Luiz Rodrigues
Revisão Textual:
Prof. Me. Claudio Brites
Fonte: iStock/Getty Images

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.
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!
UNIDADE
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
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
7
UNIDADE
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
• 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
Document and requirements
test the system
Code the Design the

program program
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
9
UNIDADE
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
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
11
UNIDADE
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
Business Staff
Facilitator Breaks down Them/Us
BetterUnderstand IT Issues
Participants Barriers
and Project Management
Business Staff
Levers of Control
Technical Staff
Scripted Sessions
Workshops Create Project Ownership,
Timeboxed Commitment and Buy-In
Join Application
Brainstorming
Development Developed
Quickly Defines Requirements
(JAD) Final Project Work Product is
Inspected
Resolve Conflicts
Also See “Workshop Breakdown Approved
Identifies Best Practices Structure (WBS)
Helps Forming, Storming

and Nothing of Project Team What, Why, When, Where and How
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
13
UNIDADE
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.
Team #3
Team #2 Business
Team #1 Modelling
Business
Business Modelling
Data
Modelling Modelling
Data
Modelling Process
Modelling
Data
Modelling
Process Application
Generation
Modelling
Process Testing &

Modelling Turnover
Application
Generation
Application
Generation Testing &
Turnover
Testing &
Turnover
60-90 days
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
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
15
UNIDADE
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 requisitos durante 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
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
17
UNIDADE
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.
Análise Validar
de Requisitos
Projeto do Verificar
Sistema
Design do
Sistema
Codificação
Prototipagem Teste de Unidade

e Integração
Testes do
Sistema
Teste de
Aceitação Operação e
Manutençã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
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
19
UNIDADE
pode visualizar na figura a seguir.
Design de teste
Análise de de aceitação Teste de
Requisitos aceitação
Projeto de teste
Projeto de do sistema Testes do
Sistema Sistema
Design de teste
Design de de integração Teste de
Arquitetura Integração
Design de teste
Design do de unidade Testes
Módulo Unitários
Codificaçã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
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
Progress
Determine Through Evaluate Alternatives;
Objectives, Steps
Identify, Resolve Risks
Alternatives,
Constraints Risk Analysis
Risk Analysis
Risk Analysis
Operational
R Proto- Prototype
Prototype 3
Commitment A type 1 Prototype 2
Review
Partition Simulations Models
Rqts. Plan
Concept of Benchmarks
Life Cycle
Plan Operation Software
Develop, Verify Rqts. Detailed
Next-Level Software Design
Process Plans Development Requirements
Plan Validation Product
Design
Code
Integration Design Validation
and Test Plan Unit
Evaluate Process and Verification Test
Alternatives;
Identify, Resolve Determine Integration
Process Risks Process Acceptance and Test
Objectives, Implemen- Test
Alternatives, tation
Constraints
Plan Develop, Verify
Next Phases Next-Level Product Boehm (1988)
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
21
UNIDADE
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).
Product 2
Pr
Pro
oduct
du
ct 1
Cross-product
Requirements Requirements
Collaboration
ct A
Pro
Product B
du
du
Pro
ct C
Figura 9 – Processo de desenvolvimento de software
22
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.
Design &
Requirements
Testing Implemention (Build 1)

Development
Design & (Build 2)
Testing Implemention
Development
Design & Implemention (Build 3)
Development Testing
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
23
UNIDADE
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 ...Iteration N

Analyze Analyze Analyze
Analyze Design Design
Analyze Implement Implement
Analyze Test Test
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
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 Construction Transition
Lifecycle Lifecycle Initial Product

Objective Architecture Operational Release
Capability
Commit Commit Product Customer

resources for resources for mature & acceptance
colaboration construction customer or end-of-life
ready
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;
• Desenvolvimento iterativo;
• 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
25
UNIDADE
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
RAD – prós e contras
https://goo.gl/iyLKlX
Sequência de eventos no processo Waterfall
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
Processo de desenvolvimento de software Espiral
Modelo Espiral – prós e contras
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
Modelo RUP – prós e contras
https://goo.gl/BKgYrU
27
27
UNIDADE
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

I Teorico 2

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

I Teorico 2

Enviado por

Direitos autorais:

Formatos disponíveis

Processo

Responsável pelo Conteúdo:

Fonte: iStock/Getty Images

O SDLC é como um guia que utilizaremos para consulta durante a execução de um

Como se trata de um processo, o SDLC possui fases:

Code the Design the

Figura 1 – Gráfico contendo as 5 fases do ciclo de vida de desenvolvimento de software

A importância do SDLC está na oferta de que o software será concluído dentro do

A partir da definição do SDLC, podemos partir para as perspectivas de abordagem

A abordagem top-down, entre outras coisas, favorecia um design mais elegante de

Tabela 1 – Top-down – prós e contras

Essa abordagem permite testes iniciais e detalhados, já que todos os submódulos

Tabela 2 – Bottom-up – prós e contras

JAD (Joint Application Development)

O foco de JAD é a equipe e, portanto, o mote é consenso. É justamente esse

Helps Forming, Storming

Figura 2 – Mapa mental do funcionamento do processo JAD

Um bom projeto candidato ao uso de JAD deve ao menos conter as seguintes

Prós e contras de usarmos JAD:

Tabela 3 – JAD – prós e contras

RAD (Rapid Aplication Development)

Process Testing &

O modelo RAD, de James Martin, aproveita muitas coisas do processo ESPIRAL de

Possui alguns princípios fundamentais como:

Tabela 4 – RAD – prós e contras

Usamos RAD quando nossa demanda de desenvolvimento de software permite

Possui como componentes as seguintes fases:

Existe, obviamente, um engessamento aqui, que, devido à pouca participação dos

Figura 4 - Sequência de eventos no processo Waterfall

Todavia, como em todo processo, há vantagens e desvantagens que você precisa

Tabela 5 – Prós e contras do Waterfall

Apesar de estar perdendo a força para os processos ágeis de desenvolvimento, o

Conforme Rising (2009), sashimi é às vezes referenciado como o “processo em

Rising (2009) explica: “Por exemplo, desde as fases de concepção e implementação

Sashimi é apropriado para projetos de médio porte para os quais a comunicação

Waterfall com prototipagem

Normalmente, isso segue algumas regras:

Prototipagem Teste de Unidade

Figura 6 – O modelo waterfall com prototipagem

Conforme Raccoon (1995),

O SDLC, ciclo de vida do Chaos, define as frases do ciclo de vida do desenvolvimento

Para colocar um pouco de luz sobre o caos no desenvolvimento de softwares nessa

O relacionamento do modelo do caos com a teoria do caos é a ideia de que as questões

pode visualizar na figura a seguir.

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

O que há a favor e contra esse processo:

Tabela 6 – Modelo V – prós e contras

Figura 8 – Processo de desenvolvimento de software Espiral

Onde podemos usar o modelo Espiral e ele se torna especialmente útil:

Tabela 7 – Modelo Espiral – prós e contras

Wheel and Spoke Model

Figura 9 – Processo de desenvolvimento de software

Basicamente, um ciclo de desenvolvimento abrange as fases de requisitos, design,

Testing Implemention (Build 1)

Figura 10 – Processo de desenvolvimento de software Incremental

Tabela 8 – Modelo Incremental – prós e contras

De maneira geral, o processo iterativo se apresenta da seguinte forma:

Iteration 1 Iteration 2 Iteration 3 ...Iteration N

Analyze Design Design

Analyze Implement Implement

Analyze Test Test

Figura 11 – Processo de desenvolvimento de software Iterativo