Prévia do material em texto

Modelo Cascata 
O modelo cascata é utilizado principalmente quando os requisitos de um 
determinado problema são bem compreendidos. Uma forma de utilizar o 
modelo cascata é quando precisamos fazer adaptações ou aperfeiçoamentos 
em um sistema já existente. Por exemplo, quando temos um sistema já pronto 
e precisamos fazer uma adaptação porque alguma lei governamental foi 
alterada ou criada. 
Também podemos utilizar o modelo cascata quando um software necessita de 
uma nova funcionalidade e os requisitos estão bem definidos e são estáveis. 
O modelo cascata também é chamado de ciclo de vida clássico ou tradicional. 
Este modelo sugere uma abordagem sequencial e sistemática para o 
desenvolvimento de software. Dessa forma, começamos com o levantamento 
de requisitos ou necessidades junto ao cliente, depois vamos para a fase de 
planejamento onde definimos estimativas, cronograma e acompanhamento, 
após isso partimos para a modelagem onde fazemos a análise e projeto, 
seguindo da construção onde codificamos e testamos, passamos para a 
implantação ou emprego onde efetuamos a entrega, suporte e feedback do 
software concluído. 
Basicamente na etapa de levantamentos de requisitos ou necessidades 
estabelecemos junto aos clientes os requisitos do produto desejado pelo cliente 
que consiste dos serviços que devem ser fornecidos, limitações e objetivos do 
software. Esta etapa também consiste da documentação e o estudo de 
viabilidade do projeto para determinarmos o processo de início de 
desenvolvimento do projeto do sistema. Na etapa de planejamento temos a 
definição de estimativas, cronograma e acompanhamento baseando-se nos 
requisitos e na determinação das tarefas que, por sua vez, são determinadas 
pelos requisitos. A etapa de modelagem é uma prévia da próxima etapa de 
construção, nesta etapa define-se a estrutura de dados, arquitetura do 
software, interfaces, etc. A etapa de construção abrange a implementação, 
onde os programas são efetivamente criados e também os testes que é onde 
se testam as lógicas internas do software e as funcionalidades externas. As 
funcionalidades internas normalmente são realizadas com o uso de testes 
unitários e as fases externas podem ser realizadas por testadores e pelo 
próprio cliente. Por fim, a etapa de emprego ou implantação abrange e entrega 
efetiva do software no cliente que é onde instalamos o software no servidor ou 
na máquina do cliente junto com outros utilitários como banco de dados ou 
outros itens dependendo do software sendo construído. O suporte é onde 
tiramos dúvidas dos clientes e a manutenção consiste na correção de erros que 
não foram previamente detectados. 
A Figura 1 demonstra as etapas discutidas acima. 
 
Figura 1. Ilustrando o Modelo cascata. 
O modelo cascata também possui algumas variações como o "modelo v". Este 
modelo pode ser visto na Figura 2. 
 
Figura 2. Ilustrando o Modelo V. 
Este modelo descreve a relação entre ações da garantia da qualidade 
(representado no lado direito da figura) e as ações associadas à comunicação, 
modelagem e atividades de construção. O modelo é seguido de cima para 
baixo a partir do lado esquerdo e depois parte de baixo para cima no lado 
direito quando o código estiver finalizado no lado esquerdo, ou seja, quando 
possuirmos um software executável efetivamente subimos no modelo. Não 
existe diferença entre o modelo V e o modelo tradicional. O modelo V apenas 
enfatiza uma forma para visualizar como a verificação e as ações de validação 
são aplicadas ao trabalho de engenharia que são realizadas no lado esquerdo. 
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 a incerteza natural que 
existem no início 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. Estudos mostram que o 
estado de bloqueio tende a prevalecer no início e no final de um processo 
sequencial linear. Um exemplo clássico disso é a brincadeira das moedas. 
Imagine que temos 5 moedas de 10 centavos na mão esquerda e faremos uma 
rodinha com 5 pessoas sendo que existe uma cadeira ao lado de cada pessoa 
para que possamos colocar as moedas já lançadas. Cada pessoa deve pegar 
uma moeda da mão esquerda com a sua mão direita e atirar essa moeda para 
cima e deixar a moeda cair na mesma mão direita, após isso colocamos a 
moeda na cadeira ao lado. Após lançarmos todas as moedas e colocarmos na 
cadeira ao lado o próximo colega deve pegar essas cinco moedas deixadas na 
cadeira pelo colega anterior e novamente lançar as moedas, repetindo os 
mesmo procedimentos do colega anterior. Agora vamos recomeçar a 
brincadeira e o colega deve lançar as moedas novamente, porém quando 
tivermos duas moedas na cadeira o próximo colega deverá começar a lançar 
as moedas, sem precisar esperar que as cinco moedas estejam disponível. 
Calcule o tempo gasto nas duas brincadeiras. Veremos que há uma boa 
diferença quando não precisamos esperar até que cada um realize toda a 
atividade para que possamos começar o trabalho. Temos um grande ganho de 
produtividade. 
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. 
Com isso, neste artigo vimos o que são processos e quais são seus principais 
conceitos e princípios. Também vimos sobre os modelos prescritivos e o 
modelo cascata. O modelo cascata é útil em determinados tipos de projeto e 
não adequado em outros quando temos muitas mudanças e ambientes 
imprevisíveis. 
Modelo Incremental 
Alguns projetos de software definem requisitos iniciais de software 
razoavelmente bem definidos. Pode ser necessário o rápido fornecimento de 
um determinado conjunto funcional aos usuários, para que após esse 
fornecimento, possamos melhorar e expandir suas funcionalidades em versões 
de software posteriores. Nesses casos, podemos optar por um modelo de 
processo que desenvolve software de uma forma incremental. 
O modelo de processo incremental combina elementos dos fluxos de 
processos tanto lineares quanto paralelos. A Figura 1 demonstra o modelo 
incremental: 
 
Figura 1. Ilustração do Modelo Incremental. 
Podemos notar pela figura acima que o modelode processo incremental aplica 
sequências lineares (como no modelo cascata) de forma escalonada, à medida 
que o tempo for avançando. Cada uma das sequencias lineares gera um 
incremento do software. Esses incrementos são entregáveis e prontos para o 
cliente. Um exemplo de um processo incremental é um software de e-mail que 
inicialmente contém funções apenas para enviar e-mails à destinatários e ler e-
mails recebidos. Em um segundo incremento o software poderia adicionar 
funções de revisão ortográfica e gerenciamento de e-mails recebidos. No 
terceiro incremento o software poderia adicionar um controle de spam. E assim 
sucessivamente. 
No primeiro incremento de um produto que utiliza o modelo incremental temos 
apenas o essencial do produto, ou seja, os requisitos básicos que devem ser 
atendidos para o software entrar em operação. Portanto, no primeiro 
incremento muitos recursos complementares ainda não são entregues para os 
clientes. Após o término do primeiro incremento o cliente utiliza e avalia esse 
incremento fornecendo posteriormente um resultado ou feedback. Com base 
nesse resultado fornecido pelo cliente o próximo incremento é planejado 
considerando a modificação do primeiro incremento, caso seja necessário, de 
acordo com o feedback do cliente. Após a liberação de cada incremento é 
realizado esse mesmo processo até que o produto esteja completo. 
O modelo de processo incremental entrega um produto operacional a cada 
incremento, ou seja, um produto sem erros e pronto para o usuário utilizar. 
Mesmo que os primeiros incrementos sejam partes do produto, essas partes 
são operacionais e funcionam sem as outras. Portanto, os incrementos 
possuem totais condições de atender ao usuário. 
De forma geral, os primeiros incrementos podem ser implementados com um 
número reduzidos de pessoas. Nos próximos incrementos um pessoal adicional 
poderá ser acrescido de forma a implementar o incremento seguinte. Também 
podemos administrar alguns riscos através de um planejamento baseado nos 
incrementos. Por exemplo, se uma determinada versão de um software utilitário 
fornecido por terceiros que será integrado ao nosso projeto estiver disponível 
apenas numa data mais posterior, poderíamos deixar para desenvolver um 
determinado complemento do software que use essa versão mais atual numa 
data posterior quando esse utilitário já estiver disponível para uso. 
 
Modelo Espiral 
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. 
Modelo RAD 
O Rapid Application Development (RAD) é um modelo de processo 
de software incremental que enfatiza um ciclo de desenvolvimento curto. O 
Modelo RAD é uma adaptação, de alta velocidade, do modelo em cascata, 
no qual a agilidade é conseguida com o uso de uma abordagem de 
construção baseada em componentes. 
Porém o processo RAD necessita que os requisitos sejam bem 
compreendidos e o objetivo do projeto seja restrito, para garantir o sucesso 
do projeto. 
A figura 1 ilustra o Modelo RAD. As etapas do Modelo RAD apresentam as 
seguintes definições: 
• comunicação: trabalha para entender os problemas do negócio e as 
características de informação que o software precisa acomodar; 
• planejamento: o planejamento é essencial, porque várias equipes de 
software trabalham em paralelo em diferentes funções do sistema; 
• modelagem: abrange três das principais fases: modelagem do negócio, 
modelagem dos dados e modelagem dos processos. Também estabelece 
representações de projeto que servem como base para a atividade de 
construção do RAD; 
• construção: enfatiza o uso de componentes de software preexistentes e 
a aplicação da geração automática de código; 
• implantação: estabelece a base para iterações subsequentes, se 
necessárias. 
 
Figura 1: Modelo RAD. 
Fonte: PRESSMAN (2010). 
Entre as desvantagens do Modelo RAD, considera-se: 
• para projetos grandes, mas passíveis de sofrer aumento, o RAD exige 
recursos humanos suficientes para criar um número adequado de equipes; 
• se desenvolvedores e clientes não estiverem comprometidos com as 
atividades os projetos RAD falharão; 
• se o sistema não puder ser adequadamente modularizado, a construção 
dos componentes será problemática; 
• se for necessário ajustes nas interfaces dos componentes do sistema, a 
http://jkolb.com.br/wp-content/uploads/2013/12/rad.png
abordagem RAD pode não funcionar; 
• o RAD pode não ser adequado quando os riscos técnicos são altos. 
Modelo RUP 
Rational Unified Process (RUP) é um processo de engenharia de software que 
fornece uma abordagem disciplinada para assumir tarefas e responsabilidades 
dentro de uma organização de desenvolvimento, cujo objetivo é assegurar a 
produção de software de alta qualidade dentro de prazos e orçamentos 
previsíveis (Kruchten 2003, pág. 14). Derivado dos trabalhos sobre UML e 
do Processo Unificado de Desenvolvimento de Software, ele traz elementos de 
todos os modelos genéricos de processo, apoia a iteração e ilustra boas 
práticas de especificação e projeto (Sommervillie 2007, pág. 54). Ele captura 
seis das melhores práticas no desenvolvimento de software de forma 
satisfatória para uma grande faixa de projetos e organizações (Krutchten 2003, 
pág. 14). As melhores práticas abordadas são as seguintes (Sommerville 2007, 
pág. 56): 
1. Desenvolver o software iterativamente: planejar os incrementos de 
software com base nas prioridades do cliente e desenvolver e entregar o mais 
cedo possívelàs características de sistema de maior prioridade no processo de 
desenvolvimento. 
2. Gerenciar Requisitos: documentar explicitamente os requisitos do cliente e 
manter acompanhamento das mudanças desses requisitos. Analisar o impacto 
das mudanças no sistema antes de aceitá-las. 
3. Usar arquiteturas baseadas em componentes: Estruturar a arquitetura do 
sistema com componentes, reduzindo a quantidade de software a ser 
desenvolvido e, consequentemente, reduzir custos e riscos. 
4. Modelar software visualmente: usar modelos gráficos de UML para 
apresentar as visões estática e dinâmica do software. 
5. Verificar a qualidade do software: garantir que o software atenda aos 
padrões de qualidade da organização. 
6. Controlar as mudanças do software: gerenciar as mudanças do software, 
usando um sistema de gerenciamento de mudanças, procedimentos e 
ferramentas de gerenciamento de configuração. 
O RUP é um modelo constituído por quatro fases do processo de software, 
relacionadas mais estritamente aos negócios do que a assuntos técnicos 
(Sommerville 2007, pág. 54). As quatro fases do RUP são descritas abaixo: 
1. Concepção: o objetivo desta fase é estabelecer um business case[2] para o 
sistema. Devem ser identificadas todas as entidades externas (pessoas e 
sistemas) que irão interagir com o sistema em desenvolvimento e definir essas 
http://www.tiespecialistas.com.br/tag/rup/?utm_source=site_tag&utm_medium=site&utm_content=09-05-2013&utm_campaign=TAG
http://www.tiespecialistas.com.br/tag/rup/?utm_source=site_tag&utm_medium=site&utm_content=09-05-2013&utm_campaign=TAG
http://www.tiespecialistas.com.br/tag/uml/?utm_source=site_tag&utm_medium=site&utm_content=09-05-2013&utm_campaign=TAG
http://www.tiespecialistas.com.br/categoria/ti_corporativa/gestao-de-processos-ti_corporativa/?utm_source=site_tag&utm_medium=site&utm_content=09-05-2013&utm_campaign=TAG
http://www.tiespecialistas.com.br/tag/desenvolvimento-de-software/?utm_source=site_tag&utm_medium=site&utm_content=09-05-2013&utm_campaign=TAG
http://www.tiespecialistas.com.br/tag/melhores-praticas/?utm_source=site_tag&utm_medium=site&utm_content=09-05-2013&utm_campaign=TAG
http://www.tiespecialistas.com.br/tag/software/?utm_source=site_tag&utm_medium=site&utm_content=09-05-2013&utm_campaign=TAG
http://www.tiespecialistas.com.br/tag/requisitos/?utm_source=site_tag&utm_medium=site&utm_content=09-05-2013&utm_campaign=TAG
http://www.tiespecialistas.com.br/tag/qualidade/?utm_source=site_tag&utm_medium=site&utm_content=09-05-2013&utm_campaign=TAG
https://www.tiespecialistas.com.br/2011/02/rup-primeiros-passos/#_ftn2
interações. Essas informações são utilizadas para avaliar a contribuição do 
novo sistema para o negócio. 
2. Elaboração: os objetivos desta fase são desenvolver um entendimento do 
domínio do problema, estabelecer um framework[3] de arquitetura para o 
sistema, desenvolver o plano de projeto e identificar seus principais riscos. Ao 
final desta fase deve-se ter um modelo de requisitos para o sistema (os casos 
de uso da UML são especificados), uma descrição de arquitetura e um plano 
de desenvolvimento do software. 
3. Construção: está fase está essencialmente relacionada ao projeto, 
programação e teste do sistema. As partes do sistema são desenvolvidas 
paralelamente e integradas durante esta fase. Ao final deve-se ter um sistema 
de software em funcionamento e a documentação associada pronta para ser 
liberada para os usuários. 
4. Transição: nesta fase, faz-se a transferência do sistema da comunidade de 
desenvolvimento para a comunidade de usuários, com a entrada do sistema 
em funcionamento no ambiente real. Esta é uma atividade ignorada na maioria 
dos modelos de processo de software, pois é onerosa e às vezes problemática. 
Ao final desta fase, deve-se ter um sistema de software documentado, 
funcionando corretamente em seu ambiente operacional. 
Cada uma das fases descritas acima pode ser realizada de forma iterativa, com 
os resultados desenvolvidos incrementalmente. 
As atividades que ocorrem durante o processo de desenvolvimento são 
chamadas de workflows. Existem seis workflows principais, exibidos na Tabela 
1. 
Workflow 
 
Descrição 
Modelagem de Negócios 
Os processos de negócio são modelados usando 
casos de uso de negócios. 
Requisitos 
Os agentes que interagem com o sistema são 
identificados e os casos de uso são desenvolvidos 
para modelar os requisitos do sistema. 
Análise e Projeto 
Um modelo de projeto é criado e documentado 
usando modelos de arquitetura, modelos de 
componente, modelos de objetos e modelos de 
sequência. 
Implementação 
Os componentes de sistema são implementados e 
estruturados em subsistemas de implementação. 
A geração automática de código com base os 
modelos de projeto ajuda a acelerar esse 
processo. 
https://www.tiespecialistas.com.br/2011/02/rup-primeiros-passos/#_ftn3
http://www.tiespecialistas.com.br/tag/riscos/?utm_source=site_tag&utm_medium=site&utm_content=09-05-2013&utm_campaign=TAG
Teste 
O teste é um processo iterativo realizado em 
conjunto com a implementação. O teste de 
sistema segue o término da implementação. 
Implantação 
Uma versão do produto é criada, distribuída aos 
usuários e instalada no local de trabalho. 
Gerenciamento de 
Configuração e Mudança 
Este workflow de apoio gerencia mudanças no 
sistema. 
Gerenciamento de 
Projetos 
Este workflow de apoio gerencia o 
desenvolvimento do sistema. 
Ambiente 
Este workflow está relacionado à disponibilização 
de ferramentas apropriadas de software para a 
equipe de desenvolvimento. 
Tabela 1: Workflows no Rational Unified Process (Sommerville 2007, pág. 55) 
Embora o RUP não seja um processo adequado a todos os tipos 
de desenvolvimento de software, ele representa uma nova geração de 
processos genéricos. A mais importante inovação é a separação de fases e 
workflows, e o reconhecimento de que a implantação de software no ambiente 
do usuário é parte do processo. As fases são dinâmicas e tem objetivos. 
Os workflows são estáticos e constituem atividades técnicas que não estão 
associadas a uma única fase, mas podem ser utilizados ao longo do 
desenvolvimento para atingir os objetivos de cada fase 
 
http://www.tiespecialistas.com.br/tag/desenvolvimento-de-software/?utm_source=site_tag&utm_medium=site&utm_content=09-05-2013&utm_campaign=TAG
http://www.tiespecialistas.com.br/tag/workflow/?utm_source=site_tag&utm_medium=site&utm_content=09-05-2013&utm_campaign=TAG