Modelos Tradicionais de
Desenvolvimento
Engenharia de SoftwareProcesso de Software - Recapitulando
• Metodologia para as atividades, ações e tarefas necessárias para desenvolver
software de alta qualidade.
• Serve como uma série de passos previsíveis, ou um roteiro, que ajudará na
criação de um produto ou sistema de alta qualidade e dentro do prazo estabelecido entre as partes.
• Um processo de software pode ser diferente dependendo da organização ou
Processo de Software - Recapitulando
• Esse processo conta com a ajuda de toda a equipe de desenvolvimento,
equipe de testes, gerentes, entre outros, além também dos próprios
solicitantes do software que devem colaborar com a definição, construção e
teste do software.
• A grande importância de um processo se dá pela estabilidade, controle e
organização que ele estabelece para uma atividade que, sem controle,
Modelos Prescritivos (Tradicionais)
• Um modelo de processo prescritivo foi originalmente concebido para trazer
ordem ao caos que existia na área de desenvolvimento de software.
• Durante todos esses anos que os modelos prescritivos têm sido estudados e
utilizados conclui-se que esses modelos tradicionais proporcionaram uma grande contribuição quanto a sua estrutura utilizável e, além disso, eles
forneceram um roteiro razoavelmente eficaz para as equipes que desenvolvem software.
• No entanto, esse modelo mostrou que o trabalho de engenharia de software e
Modelos Prescritivos (Tradicionais)
Esse modelo é denominado prescritivo, pois esses modelos prescrevem um
conjunto de elementos de processo como atividades específicas do método,
ações de engenharia de software, tarefas, produtos, garantia da qualidade, controles e mudanças para cada projeto.
Cada modelo de processo também define um fluxo de processo, ou seja, como os elementos do processo estão inter-relacionados.
Engenharia de Software
Modelo Cascata (
Waterfall )
O modelo foi proposto por W. W. Royce em 1970 e é também conhecido como abordagem "top-down".
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.
Modelo Cascata
O modelo cascata tem esse nome as etapas do processo de desenvolvimento são estruturadas em uma forma de cascata onde a saída de uma é a entrada para a
próxima.
A idéia do modelo cascata é organizar o processo de desenvolvimento de
software de modo que ao finalizar uma etapa, a próxima flui naturalmente. (Uma etapa depende da outra).
Modelo Cascata - Quando Usar?
• 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
Modelo Cascata - Quando Usar?
O modelo Cascata aplica-se bem em situações em que o software a ser desenvolvido é simples, os requisitos são bem conhecidos assim como a tecnologia de programação.
Devemos utilizar os modelos cascata quando o projeto é algo bem definido e não irá sofrer mudanças nos seus requisitos ao longo do desenvolvimento.
Modelo Cascata
Análise e Especificação de Requisitos
• Estabelecer os serviços que devem fornecer, limitações e objetivos do
software.
• Definir requisitos de forma útil para todas as etapas.
• Documentação e o estudo da facilidade e da viabilidade do projeto com o fim
Análise e Especificação de Requisitos
• 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.
Projeto (Planejamento) do Software
• Se centraliza em quatro atributos: estrutura de dados, arquitetura do
software, detalhes procederias e caracterização das interfaces.
• É a prévia da codificação onde os requisitos são representados de forma a
facilitar esse processo.
• Nessa etapa ocorre 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.
Implementação
• Nessa etapa 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.
Integração e Teste do Sistema
• Na 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.
• Na parte de teste do software asseguram que os resultados reais conhecida
Manutenção
Essa etapa consiste em:
• Correção de erros que não foram detectados previamente. • Melhorias funcionais.
Modelo 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.
Modelo Cascata - Vantagens
• Torna o processo de desenvolvimento estruturado (abordagem disciplinada e
dirigida a documentação)
• Tem uma ordem sequencial de fases. Cada fase cai em cascata na próxima
Modelo Cascata - Desvantagens
• Não fornece feedback entre as fases e não permite a atualização ou redefinição das
fases anteriores;
• Não suporta modificações nos requisitos;
• Não prevê a manutenção (alteração e adição de novos conteúdos) do software;
• Não permite a reutilização;
• É excessivamente sincronizado;
• Se ocorrer um atraso todo o processo é afetado; • Faz aparecer/entregar o software muito tarde.
Problemas segundo Pressman
• Os projetos reais raramente seguem o fluxo seqüencial que o modelo
propõe. Alguma iteração sempre ocorre e traz problemas na aplicação do paradigma
• Muitas vezes é difícil para o cliente declarar todas as exigências explicitamente. O
ciclo de vida clássico exige isso e tem dificuldade de acomodar a incerteza natural que existe no começo de muitos projetos.
• O cliente deve ter paciência. Uma versão de trabalho dos programas não
estará disponível até um ponto tardio do cronograma do projeto. Um erro crasso, se não for detectado até que o programa de trabalho seja revisto, pode ser desastroso.
Problemas do Modelo Cascata
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.
Finalizando - Modelo Cascata
Atualmente 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 tipo de 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.
Engenharia de Software
Modelo Prototipação
Um protótipo é uma visão inicial de um sistema de software, onde possibilita demonstrar conceitos, experimentar opções de projeto, e em geral para conhecer o problema e suas possíveis soluções.
Em suma, a prototipação é o processo que possibilita que o programador de software crie um modelo que será construído.
A Prototipação é um ciclo de vida eficiente quando as regras entre cliente e desenvolvedor são definidas no início do processo e há concordância em que o protótipo, por ser um protótipo, deve ser descartado (PRESSMAN, 1995).
Prototipo - Por que Usar?
A definição de todos os requisitos necessários ao sistema pelo cliente ou usuário geralmente é uma tarefa muito difícil.
É quase impossível prever como o sistema irá afetar o funcionamento das práticas de trabalho, como será a interação com outros sistemas e que operações dos usuários devem ser automatizadas.
Mas para poder testar os requisitos de uma forma mais eficiente, seria necessária a utilização de um protótipo do sistema.
Prototipo - O que é?
Um protótipo é uma versão inicial de um sistema de software, que é utilizada para mostrar conceitos, experimentar opções de projeto e, em geral, para conhecer mais sobre os problemas e suas possíveis soluções. O desenvolvimento rápido de um protótipo é essencial para que os custos sejam controlados e os usuários possam fazer experiências com o protótipo no início do processo de software.
Prototipo - Objetivos e Possibilidades
O objetivo da prototipação é entender os requisitos do usuário e, assim, obter uma melhor definição dos requisitos do sistema.
Possibilita que o desenvolvedor crie um modelo (protótipo) do software que deve ser construído.
Prototipo - Quando Usar?
Em muitos casos o cliente define somente um conjunto de objetivos gerais para o Sistema (Software), mas não foi capaz de gerar requisitos definidos, de entrada , processamento e saída, para o sistema (software).
Desenvolvedor não tem certeza da eficiência de um algoritmo, ou como ele pode se comportar em um determinado Sistema Operacional, ou durante a comunicação com alguma interface, periféricos/componentes.
Prototipo - Atividades Principais
Um protótipo de software apóia duas atividades do processo de engenharia de requisitos:
Levantamento de requisitos - Os protótipos de sistema permitem que os
usuários realizem experiências para ver como o sistema apóia seu trabalho. Eles obtêm novas idéias para os requisitos e podem identificar pontos positivos e negativos do software. Eles podem, então, propor novos requisitos de sistema.
Prototipo - Atividades Principais
Validação de requisitos - O protótipo pode revelar erros e omissões nos
requisitos propostos. Uma função descrita em uma especificação pode parecer útil e bem-definida. Contudo, quando essa função é utilizada com outras, os usuários muitas vezes acham que sua visão inicial era incorreta e incompleta. A especificação de sistema pode então ser modificada para refletir sua compreensão alterada dos requisitos.
Prototipo - Modelo
Prototipo - Obter Requisitos
Nesta etapa, desenvolvedor e cliente definem os objetivos gerais do software, identificam quais requisitos são conhecidos e as áreas que necessitam de
Prototipo - Projeto Rápido
Representação dos aspectos do software que são visíveis ao usuário (abordagens de entrada e formatos de saída).
Prototipo - Construção do Protótipo
Prototipo - Avaliação do Protótipo
Prototipo - Refinamento do Protótipo
Desenvolvedores refinam os requisitos do software a ser desenvolvido, baseado nas sugestões e comentários do cliente.
Prototipo - Construção do Produto Final
Identificado os requisitos, o protótipo deve ser descartado e a versão de produção deve ser construída considerando os critérios de qualidade de um produto final.
Prototipo - Tipos
O protótipo pode ser oferecido ao cliente em diversas formas:
• Protótipo em papel
• Modelo executável em PC retratando a interface homem-máquina capacitando o
cliente a compreender a forma de interação com o software
• Protótipo do trabalho que implemente um subconjunto dos requisitos indicados • Programa existente (pacote) que permita representar todas ou parte das funções
Prototipo - Modelos
Existem modelos de prototipação, que serão abordados a seguir:
• Prototipação Evolucionária • Prototipação Incremental
Prototipação Evolucionária
Inicia um sistema relativamente simples, implantando os requisitos mais importantes e o sistema é ampliado e alterado a medida que novos requisitos são descobertos.
Vantagens
• Rápido fornecimento do sistema;
• Compromisso do usuário com o sistema
Desvantagens / Problemas
• Problemas de gerenciamento (Custos,
Documentação);
Prototipação Incremental
Os componentes do sistema são desenvolvidos de maneira incremental. Uma vez validado e entregues não são modificados, exceto se for descoberto erros.
Vantagens
• Fácil gerenciamento dos padrões de
processos;
Prototipação Descartável
Essa abordagem amplia o processo de análise dos requisitos, com intenção de reduzir os custos no ciclo de vida do software, ou seja, esclarece os requisitos e fornece informações para que os riscos de processos sejam avaliados. Então, ela ajuda a desenvolver os requisitos do sistema.
Prototipo - Vantagens
• Modelo de desenvolvimento interessante para alguns sistemas de grande porte que
representem um certo grau de dificuldade para exprimir rigorosamente os requisitos.
• É possível demonstrar a realizabilidade através da construção de um protótipo do
sistema.
• É possível obter uma versão, mesmo simplificada do que será o sistema, com um
pequeno investimento inicial.
• A experiência adquirida no desenvolvimento do protótipo vai ser de extrema
utilidade nas etapas posteriores do desenvolvimento do sistema real, permitindo reduzir o seu custo e resultando num sistema melhor concebido.
Prototipo - Desvantagens
• O cliente vê a versão em funcionamento e exige alguns acertos para colocar
logo em uso;
• A codificação utilizada para apresentar o protótipo pode no final não ser a
definitiva;
Prototipo - Problemas
• Quando informamos que o produto precisa ser reconstruído, o cliente exige
que alguns acertos sejam aplicados para tornar o protótipo um produto; muito freqüentemente, a gerência de desenvolvimento de software cede.
• O desenvolvedor muitas vezes faz concessões de implementação a fim de
colocar um protótipo em funcionamento rapidamente. Depois de algum tempo, o desenvolvedor pode familiarizar-se com essas opções e esquecer-se de todas as razões pelas quais elas são inadequadas - a opção menos ideal se tornou então parte integrante do sistema.
Finalizando - Prototipação
• Ainda que possam ocorrer problemas, a prototipação é um ciclo de vida
eficiente.
• A chave é definir as regras do jogo logo no começo.
• O cliente e o desenvolvedor devem ambos concordar que o protótipo seja
Engenharia de Software
Modelo Espiral
Segundo Pressman, este modelo foi desenvolvido pela Engenharia de Software para abranger as melhores características do modelo tradicional e da prototipação, acrescentando ao mesmo tempo, um novo elemento - a
Modelo Espiral
O modelo espiral usa a prototipação como um mecanismo de redução de riscos e mantém uma abordagem de passos sistemáticos sugerida pelo ciclo de vida clássico e ainda incorpora uma estrutura iterativa que reflete mais realisticamente o mundo real.
Modelo Espiral
• O modelo espiral acopla a natureza iterativa da prototipação com os aspectos
controlados e sistemáticos do modelo cascata.
• O modelo espiral é dividido em uma série de atividades de trabalho ou
regiões de tarefa.
Modelo Espiral
O modelo espiral define quatro importantes atividades:
• Planejamento: determinação dos objetivos, alternativas e restrições do
projeto;
• Análise de riscos: análise das alternativas e identificação/resolução de riscos; • Engenharia: desenvolvimento do produto no “nivel seguinte”;
Modelo Espiral
Esta concepção tende a criar um roteiro de atividades e etapas para que se alcance uma maturidade do processo evolutivo de desenvolvimento de sistemas complexos e obter, ao final, um produto em sua forma mais completa possível.
Modelo Espiral
• Cada ciclo na espiral representa uma fase do processo de software.
• Com cada iteração ao redor da espiral (iniciando-se ao centro e avançando
para fora), versões progressivamente mais completas do software são construídas.
• O ciclo mais interno está concentrado nas possibilidades do sistema.
• O próximo ciclo está concentrado na definição dos requisitos do sistema. • O ciclo seguinte está concentrado no projeto do sistema.
Modelo Espiral
• Não existem fases fixas no modelo.
• As fases mostradas na figura anterior são meramente um exemplo. • A gerência decide como estruturar o projeto em fases.
Modelo Espiral
CADA LOOP DA ESPIRAL É DIVIDIDO EM 4 SETORES Estabelecimento de Objetivos Planejamento Avaliação e Redução de Riscos Desenvolvimento e Validação
Modelo Espiral
Estabelecimento de Objetivos
São definidos objetivos específicos para a fase de projeto são identificadas restrições sobre o processo e o produto é projetado um plano de gerenciamento detalhado são identificados riscos do projeto dependendo dos riscos, estratégias alternativas podem ser planejadas.
Modelo Espiral
Avaliação e Redução de Riscos
• Para cada um dos riscos identificados, uma analise detalhada é executada. • Passos são tomados para reduzir o risco.
Modelo Espiral
Desenvolvimento e Validação
Depois da avaliação de riscos, um modelo de desenvolvimento é escolhido para o sistema.
Modelo Espiral
Planejamento
O projeto é revisto e é tomada uma decisão de continuidade se é decidido continuar, são projetados planos para a próxima fase do projeto (próximo “loop” )
Modelo Espiral - Problemas
• O modelo em espiral, por suas características de avaliação e planejamento baseadas em
risco, exige que se tenha gerentes e técnicos experientes.
• As tarefas gerenciais para acompanhamento e controle do projeto tornam-se mais
difíceis, uma vez que o modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado.
• É necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem
Modelo Espiral - Resumo
• Engloba as melhores características do ciclo da vida clássico (modelo
tradicional) e da prototipação, adicionando um novo elemento: a Análise de
Risco).
• Segue a abordagem de passos sistemáticos do Ciclo de vida clássico
incorporando-os numa estrutura iterativa que reflete mais realisticamente o mundo real.
• Usa a Prototipação em todas as etapas da evolução do produto, como
Modelo Espiral - Resumo
• Modelo tradicional, com a abordagem mais realística para o
desenvolvimento de software em grande escala.
• Usa uma abordagem que capacita o desenvolvedor e o cliente a entender e
reagir aos riscos em cada etapa evolutiva
• Pode ser difícil convencer os clientes que uma abordagem “evolutiva” é
Modelo Espiral - Resumo
❖ Exige considerável experiência na determinação de riscos e depende dessa
experiência para obter sucesso.
❖ O modelo é relativamente novo e não tem sido amplamente usado.
Demorará muitos anos até que a eficácia desse modelo possa ser determinada com certeza absoluta.
