Modelos de Desenvolvimento de Projetos

MODELO CASCATA

O modelo cascata ou clássico também pode ser conhecido como “top-down”,

tendo sido criado na década de 1970 por Royce, sendo o modelo mais aceito até a
metade da década de 1980. Esse modelo é oriundo de outros modelos de atividades
de engenharia com a finalidade de determinar a ordem no desenvolvimento de
grandes produtos de software. Comparado com os outros modelos de criação de
software, o cascata se caracteriza por ser mais rígido e menos administrativo.

O modelo espiral fornece um grande potencial para que possamos ter rápido
desenvolvimento de versão cada vez mais completas. Um modelo espiral possui
diversas atividades definidas pela engenharia de software, onde cada uma dessas
atividades representa um segmento do caminho espiral.

Um dos motivos que fazem o modelo cascata ser muito bem sucedido e famoso
é o fato de ser orientado para documentação. Porém, é importante ressaltar que a
documentação compreende mais do que o arquivo de texto, abrangendo
representações gráficas ou até mesmo simulação. Este modelo inclui processos,
métodos e ferramentas para o desenvolvimento de softwares. Há três abordagens de
modelos de processo de criação de software, que são a cascata pura, incremental e
evolucionária.

Sua principal característica é a divisão das tarefas em etapas predeterminadas,

que são executadas de forma sequencial. Isso quer dizer que é preciso finalizar todas
as tarefas de uma etapa para que seja possível passar para a seguinte. Ao cumprir
todas as etapas, o resultado será um produto de software funcional, pronto para ser
entregue ao cliente. Uma das vantagens do modelo cascata é de que uma tarefa só
avança para a outra quando há a validação dos produtos financeira da tarefa atual.
Este modelo permite que o idealizador participe de forma ativa do desenvolvimento
do projeto do software. A versão também diminui o impacto do entendimento
adquirido no decorrer de um projeto, visto que se um processo não pode ser
retrocedido para alterar os modelos e finalizações das tarefas anteriores,
consequentemente, as ideias sobre o sistema não terão proveito.

Com o objetivo de resolver o problema de reversão e para permitir a alteração

de tarefas, foi desenvolvido um novo processo que se baseia no clássico em cascata,
sendo chamado de cascata revisto, que tem como diferença prever a possibilidade de,
a partir de qualquer tarefa do ciclo viabilizar o retorno da tarefa anterior, permitindo
alterações funcionais ou técnicas que tenham surgido no meio do processo.

O modelo cascata é dividido em cinco etapas: levantamento de requisitos, projeto,

implementação, realização de testes e manutenção do sistema.

● Levantamento de requisitos: Na primeira etapa é feito o levantamento de

requisitos com o cliente, para entender suas expectativas e definir quais
funcionalidades devem ser implementadas no sistema. É preciso que isso seja
feito com cuidado para que o objetivo do software seja atingido, já que isso vai
nortear todas as etapas seguintes.
● Projeto: O projeto de elaboração do sistema é composto por vários processos
que se centralizam em quatro atributos diferentes do sistema, sendo: a
estrutura de dados, a arquitetura do software, caracterização das interfaces e
detalhes procedimentais.
● Implementação: A etapa de implementação é quando os programas são
criados. Caso o projeto tenha um nível de detalhamento mais avançado, a
etapa de codificação pode ser implementada de maneira automática. Nessa
etapa, os programadores codificam o software de acordo com os requisitos e as
especificações do projeto. A duração dessa fase depende da quantidade de
pessoas no time e também da complexidade e quantidade de funcionalidades
do sistema.
● Teste: Após o fim da etapa de codificação, inicia-se a fase da realização de teste
do sistema. Este processo de teste é focado em dois pontos principais, que são
as lógicas internas do software e as suas funcionalidades externas. Esta etapa é
importante porque evidencia se os erros de comportamento do software foram
solucionados e assegura que as entradas definidas produzam resultados
eficientes e que estão de acordo com os requisitos determinados
anteriormente.
● Manutenção: A fase da manutenção se baseia na correção de erros que não
detectados durante os testes, em melhorias funcionais e de preferência com os
demais tipos de suporte. Esta etapa faz parte do ciclo de vida do produto de
software e não pertence apenas ao seu desenvolvimento. As melhorias e
alterações para correções do software podem ser classificadas como parte do
processo de desenvolvimento. Após os testes e a correção de erros, o sistema é
implantado para que o cliente veja o resultado final. Caso seja necessária
alguma mudança, o software deve passar por uma manutenção, que pode ser
feita com a reaplicação do modelo em cascata.
 O modelo cascata é o paradigma mais antigo da engenharia de software. Porém,
mesmo sendo bastante antigo e ainda utilizado na indústria esse processo recebe
muitas críticas que gerou questionamentos sobre a sua eficácia até mesmo pelos seus
maiores defensores.

Os principais problemas encontrados no modelo cascata são:

● Os projetos de software reais construídos e evoluídos na indústria de software

raramente seguem o fluxo sequencial que o modelo prega. Apesar de que esse
modelo em forma sequencial possa conter iterações, onde poderíamos passar
diversas vezes pelas mesmas atividades, ele o faz indiretamente. Como
resultado tem-se que mudanças podem provocar bastante confusão na medida
em que a equipe de projeto prossegue.
● É muito raro e difícil para o cliente saber e estabelecer explicitamente todas as
suas necessidades. O modelo cascata é muito fortemente baseado nisso e tem
dificuldade para adequar à incerteza natural que existem no inicio dos projetos.
● O cliente precisa ter muita paciência, o que raramente acontece. Uma versão
operacional (pronta para ser executada no cliente) não estará disponível até
estarmos próximo ao final do projeto. Se tivermos um erro grave nas etapas
iniciais, como uma especificação mal compreendida e mal especificada,
podemos ter um resultado desastroso.
● Outro grande problema que temos com os projetos que usam modelos cascata
é o bloqueio que existe em alguns membros da equipe que precisam esperar
que os outros completem as suas tarefas para que eles possam dar sequência
ao trabalho. O tempo gasto nessa espera pode exceder o tempo gasto em
trabalho produtivo que levaria à conclusão do projeto.

Atualmente também temos um ritmo bastante acelerado no desenvolvimento

de software e estamos cada vez mais sujeitos a uma cadeia de mudanças que são
intermináveis que surgem desde necessidades do negócio, necessidades dos clientes
até exigências impostas por leis governamentais. O modelo cascata é inapropriado
para este trabalho. Como dito anteriormente o modelo cascata é útil apenas em
situações onde os requisitos são fixos e o trabalho deve ser todo finalizado de forma
linear.

MODELO ESPIRAL
 Criado por Barry Boehm em 1988, o Modelo em Espiral é uma melhoria do
Modelo Incremental e possui esse nome por causa de sua representação, onde cada
volta no espiral percorre todas as fases do processo de software. As voltas devem ser
repetidas quantas vezes forem necessárias até que o software possa ser
completamente entregue. É um processo evolucionário, ou seja, adequado para
softwares que precisam passar por inúmeras evoluções na medida em que o
desenvolvimento acontece.

O objetivo do modelo espiral é prover um metamodelo que pode acomodar

diversos processos específicos. Isto significa que podemos encaixar nele as principais
características dos modelos vistos anteriormente, adaptando-os a necessidades
específicas de desenvolvedores ou às particularidades do software a ser desenvolvido.
Este modelo prevê prototipação, desenvolvimento evolutivo e cíclico, e as principais
atividades do modelo cascata.

Sua principal inovação é guiar o processo de desenvolvimento gerado a partir

deste metamodelo com base em análise de riscos e planejamento que é realizado
durante toda a evolução do desenvolvimento. Riscos são circunstâncias adversas que
podem surgir durante o desenvolvimento de software impedindo o processo ou
diminuindo a qualidade do produto. São exemplos de riscos: pessoas que abandonam
a equipe de desenvolvimento, ferramentas que não podem ser utilizadas, falha em
equipamentos usados no desenvolvimento ou que serão utilizados no produto final,
etc. A identificação e o gerenciamento de riscos é hoje uma atividade importantíssima
no desenvolvimento de software devido à imaturidade da área e à falta de
conhecimento, técnicas e ferramentas adequadas.

O modelo espiral descreve um fluxo de atividades cíclico e evolutivo constituído

de quatro estágios.

● No estágio 1 devem ser determinados objetivos, soluções alternativas e

restrições.
● No estágio 2, devem ser analisados os riscos das decisões do estágio anterior.
Durante este estágio podem ser construídos protótipos ou realizar-se
simulações do software.
● O estágio 3 consiste nas atividades da fase de desenvolvimento, incluindo
design, especificação, codificação e verificação. A principal característica é que
a cada especificação que vai surgindo a cada ciclo - especificação de requisitos,
do software, da arquitetura, da interface de usuário e dos algoritmos e dados -
deve ser feita a verificação apropriadamente.
 ● O estágio 4 compreende a revisão das etapas anteriores e o planejamento da
próxima fase. Neste planejamento, dependendo dos resultados obtidos nos
estágios anteriores - decisões, análise de riscos e verificação, pode-se optar por
seguir o desenvolvimento num modelo Cascata (linear), Evolutivo ou
Transformação. Por exemplo, se já no primeiro ciclo, os requisitos forem
completamente especificados e validados pode-se optar por seguir o modelo
Cascata. Caso contrário, pode-se optar pela construção de novos protótipos,
incrementando-o, avaliando novos riscos e replanejando o processo.

Vantagens:

● Mais versátil para testar e lidar com mudanças;

● Como o modelo exige a consideração dos riscos técnicos em todos os estágios

de evolução, se for aplicado adequadamente, reduzirá os riscos antes que se
tornem problemáticos;

● As estimativas se tornam mais realistas e o tempo de implementação é

reduzido;

● Não faz distinção entre desenvolvimento e manutenção.

Desvantagens:

● Segundo PRESSMAN (2006), pode ser difícil convencer os clientes que o

processo de evolução é controlável, pois ele exige competência considerável na
avaliação dos riscos e depende dessa competência para ser bem sucedido;

● Se um risco importante não for descoberto e gerenciado corretamente,

fatalmente ocorrerão problemas;

● A avaliação dos riscos exige um analista com experiência;

● Aplica-se melhor a sistemas de grande porte;

● Erros na avaliação de riscos podem impactar o projeto.

MODELO ITERATIVO

Como processo de desenvolvimento iterativo, podemos entender a atividade

em que a criação de um software é realizada por meio de progressos sucessivos.
Assim, é comum que o sistema seja apresentado ainda incompleto ou com algumas
partes deficitárias. O objetivo é que o refinamento do produto aconteça por etapas até
que o resultado pretendido seja alcançado.

Assim, o método iterativo é frequentemente comparado ao trabalho de um

escultor: primeiramente, ele seleciona uma pedra do tamanho adequado para o seu
trabalho; na sequência, ele começa a esculpir a peça de um modo geral, quando já é
possível ter uma ideia de qual será o seu desfecho; na última etapa, ocorre o
refinamento de detalhes, resultando em uma arte que cumpre com o seu propósito.
A criação de um processo de desenvolvimento iterativo e incremental está nas
bases das metodologias ágeis, como a Scrum. A ideia é que a criação de um software
seja pautada por vários ciclos curtos, em que funcionalidades são introduzidas,
feedbacks coletados e requisitos revistos.

Assim, é possível atingir um maior nível de satisfação do cliente e garantir que o

resultado final esteja dentro do esperado. Se no modelo em cascata a evolução é feita
como um processo contínuo e sequenciado, no desenvolvimento iterativo, a empresa
diminui tarefas e repete etapas sempre que for necessário.

Pretende-se, com isso, reduzir o número de falhas na solução entregue ao

usuário, criando um ambiente de trabalho que seja mais prático e capaz de fazer
mudanças em todas as etapas de desenvolvimento.

O processo iterativo pode ser útil durante o ciclo de vida de um projeto.

Durante as fases de um processo iterativo, as metas e requisitos servirão como ponto
de partida do projeto. Em seguida, a equipe irá realizar testes, prototipagem e
iterações para alcançar o melhor resultado possível. Etapas:

1. Planejamento e requisitos

Durante esta etapa do processo iterativo, o planejamento do projeto será definido e

alinhado aos objetivos gerais do projeto. Este é o estágio onde os principais requisitos
devem ser delineados, isto é, o que precisa acontecer para que o projeto tenha êxito.
Sem esta etapa, você corre o risco de realizar iterações mas não atingir as metas.

2. Análise e design
Durante esta etapa, você e a equipe irão se concentrar nas necessidades do negócio e
nos requisitos técnicos do projeto. Se a etapa 1 foi o processo de delineamento das
metas, a etapa 2 é aquela onde um design é criado por meio de um debate criativo,
com o objetivo de ajudá-los a atingir essas metas.

3. Implementação

Durante a terceira etapa, a equipe irá criar a primeira iteração do entregável do

projeto. Esta iteração será retroalimentada pela sua análise e design, com objetivo de
alcançar o objetivo principal do projeto. O nível de detalhe e o tempo gasto nesta
iteração dependem de cada projeto.

4. Testes

Após realizar a iteração, ela será testada do modo que fizer mais sentido para o
projeto. Se você está trabalhando na melhoria de uma página da Web, por exemplo,
pode ser útil realizar um teste A/B para compará-la à página atual. Se você está
criando um novo produto ou recurso, considere a realização de testes de
funcionalidade com um grupo de clientes em potencial.

Além dos testes, você também deve manter contato com os outros participantes do
projeto e pedir-lhes que avaliem a iteração e enviem comentários.

5. Avaliação e revisão

Após os testes, a equipe deverá avaliar o sucesso da iteração e alinhá-la a qualquer

aspecto que precisa ser alterado. Caso algo deva ser alterado, é possível reiniciar o
processo iterativo voltando à etapa 2 para criar a próxima iteração. O planejamento e
as metas iniciais devem permanecer os mesmos em todas as iterações. Então é só
continuar o desenvolvimento com base na iteração anterior até obter um entregável
satisfatório.

Caso você reinicie o processo iterativo, certifique-se de que todos continuem alinhados
às metas do projeto. O processo iterativo pode levar semanas ou meses, dependendo
do número de iterações realizadas. Concentrar a iteração nos objetivos do projeto
sempre que o processo iterativo for reiniciado pode ajudar a assegurar que você não
perca o rumo traçado.

O modelo iterativo não é adequado para todas as equipes ou projetos. A seguir,

descrevemos as principais vantagens e desvantagens do processo iterativo para a sua
equipe.

Vantagens:
● Aumento da eficiência. Ao empregar a tentativa e erro, o processo iterativo
frequentemente ajuda a atingir o resultado desejado com maior rapidez do que
num processo não iterativo.
 ● Aumento da colaboração. Em vez de trabalhar com planos e especificações
predefinidos que também exigem muito tempo para serem criados, a equipe
estará trabalhando em conjunto de forma ativa.
● Aumento da capacidade de adaptação: Ao aprender coisas novas durante as
fases de implementação e testes, é possível melhorar a iteração para atingir as
metas, mesmo que isso signifique fazer algo que era inesperado no início do
processo iterativo.
● Melhor relação de custo vs. Eficácia: Se for necessário alterar o escopo do
projeto, serão perdidos somente um mínimo de tempo e esforço despendidos
no processo.
● Capacidade de trabalho em paralelo: Ao contrário das metodologias não
iterativas, como o método de cascata, as iterações não dependem
necessariamente do trabalho que vem antes delas. Os membros da equipe
podem trabalhar paralelamente em diversos elementos do projeto, o que pode
encurtar o cronograma total.
● Menor risco de projeto: No processo iterativo, os riscos são identificados e
trabalhados durante cada iteração. Em vez de solucionar grandes riscos no
início e no final do projeto, você estará trabalhando de forma contínua para a
solução de riscos de baixo nível.
● Feedback de usuários mais confiável: Com uma iteração com a qual os
usuários possam interagir ou ver, eles poderão fornecer comentários
incrementais sobre o que funciona bem ou não.

Desvantagens:

● Aumento do risco de desvio do escopo: A natureza de tentativa e erro do

processo iterativo pode desviar o desenvolvimento do projeto de maneira
inesperada e que extrapola o escopo original do projeto.
● Planejamento e requisitos rígidos: O primeiro passo do processo iterativo é a
definição dos requisitos do projeto. A alteração destes requisitos durante o
processo iterativo pode atrapalhar o fluxo do trabalho e resultar em iterações
que não se adequam ao propósito do projeto.
● Cronogramas vagos: A criação, teste e revisão das iterações pelos membros da
equipe, até que se atinja uma solução satisfatória, não permite uma definição
clara do cronograma iterativo. Além disso, os testes para os diversos
incrementos podem variar em duração, o que também impacta o cronograma
geral do processo iterativo.