Aula02 Modelos Processo Software

Prévia do material em texto

Modelos de Processo de Modelos de Processo de 
SoftwareSoftware
Profa. Ellen Francine
(francine@icmc.usp.br)
Processo de Software
 Fases Genéricas
MANUTENÇÃOMANUTENÇÃO
Entendimento 
Modificação 
Revalidação
CONSTRUÇÃOCONSTRUÇÃO
SOFTWARE PRODUTOSOFTWARE PRODUTO
Projeto 
Codificação 
Teste
DEFINIÇÃODEFINIÇÃO
Análise de Sistema
Planejamento do Projeto
 Análise de Requisitos
• Gerenciamento de 
Configuração 
• Acompanhamento 
e Controle do 
Projeto
• Aplicação de 
Métricas
• Gerenciamento de 
Risco
• Gerenciamento de 
Reusabilidade
• Atividades de SQA
• Documentação
Modelos de Processo de SoftwareModelos de Processo de SoftwareModelos de Processo de SoftwareModelos de Processo de Software
Um Processo de Software 
com Qualidade
PROCESSO DE PROCESSO DE 
SOFTWARESOFTWARE
eficiente
controlado
definido
medido
gerenciado
Modelos de Processo de Software
 Existem vários modelos de processo de 
software.
– Paradigmas de Engenharia de SoftwareParadigmas de Engenharia de Software.
Genéricos, abstrações do processo.
– Usados para explicar diferentes abordagens 
para o desenvolvimento de software.
Tentativa de colocar ordem em uma 
atividade inerentemente caótica.
Tópicos da Aula
 Modelos de Processo de Software
– Cascata
– Prototipação
– RAD
– Evolutivos
 Incremental
Espiral
Componentes
– Métodos Formais
– Técnicas de Quarta Geração
– …
O Modelo Cascata
 Modelo mais antigo e mais amplamente 
utilizado da Engenharia de Software.
– Paradigma do Ciclo de Vida ClássicoParadigma do Ciclo de Vida Clássico.
– Modelo Seqüencial LinearModelo Seqüencial Linear.
 Sugere uma abordagem sistemática 
seqüencial para o desenvolvimento de 
software.
– Tem início em nível de sistema e avança ao longo 
da análise, projeto, codificação, teste e 
manutenção.
O Modelo Cascata
 Modelado em função do ciclo 
convencional de engenharia.
– O resultado de uma fase constitui-se na 
entrada de outra.
Engenharia 
de Sistemas
Análise de 
Requisitos 
Projeto 
Codificação 
Testes 
Manutenção
O Modelo Cascata
Engenharia 
de Sistemas
Análise de 
Requisitos 
Projeto 
Codificação 
Testes 
Manutenção
 Engenharia de SistemasEngenharia de Sistemas
– Estabelecimento de requisitos para todos os todos os 
elementos do sistemaelementos do sistema e atribuição de um 
subconjunto desses requisitos para o software.
 Visão essencial quando o software deve fazer interface 
com outros elementos (hardware, pessoas, banco de 
dados, etc.).
– Coleta de requisitos em nível do sistemasistema, com uma 
pequena quantidade de projetoprojeto e análiseanálise de alto 
nível. 
O Modelo Cascata
Engenharia 
de Sistemas
Análise de 
Requisitos 
Projeto 
Codificação 
Testes 
Manutenção
 Análise de Requisitos de SoftwareAnálise de Requisitos de Software
– O processo de coleta dos requisitos é
intensificado e concentrado especificamente no 
software.
– Para entender a natureza do programa a ser 
construído:
Deve-se compreender o domínio da informaçãodomínio da informação do 
software, a funçãofunção, o desempenhodesempenho e a interfaceinterface exigidos.
– Os requisitos (do sistema e do software) são 
documentadosdocumentados e revistosrevistos com o cliente.
O Modelo Cascata
Engenharia 
de Sistemas
Análise de 
Requisitos 
Projeto 
Codificação 
Testes 
Manutenção
 ProjetoProjeto
– Tradução dos requisitos do software para
um conjunto de representaçõesrepresentações que podem ser 
avaliadas quanto à qualidade, antes que a
codificação se inicie.
– Concentra-se em quatro atributos distintos do 
programa: estrutura de dadosestrutura de dados, arquitetura doarquitetura do
softwaresoftware, representações da interfacerepresentações da interface e detalhes detalhes 
procedimentaisprocedimentais. 
– Assim como os requisitos, o projeto deve ser 
documentado e torna-se parte da configuração de 
software.
O Modelo Cascata
Engenharia 
de Sistemas
Análise de 
Requisitos 
Projeto 
Codificação 
Testes 
Manutenção
 Codificação (Geração de Código)Codificação (Geração de Código)
– Tradução das representações do projeto para uma 
linguagem de programação, resultando em 
instruções executáveis pelo computador.
 Se o projeto for executado detalhadamente, a codificação 
pode ser executada mecanicamente.
O Modelo Cascata
Engenharia 
de Sistemas
Análise de 
Requisitos 
Projeto 
Codificação 
Testes 
Manutenção
 TestesTestes
– Concentram-se nos aspectos lógicos internosaspectos lógicos internos do 
software, garantindo que todas as instruções 
tenham sido testadas.
– Concentram-se nos aspectos funcionais externosaspectos funcionais externos a 
fim de descobrir erros e garantir que as entradas 
definidas produzam resultados reais que estejam 
em conformidade com os resultados esperados.
O Modelo Cascata
 Modelado em função do ciclo 
convencional de engenharia.
– O resultado de uma fase constitui-se na 
entrada de outra.
Engenharia 
de Sistemas
Análise de 
Requisitos 
Projeto 
Codificação 
Testes 
Manutenção
 ManutençãoManutenção
– Provavelmente o software deverá sofrer mudanças 
depois que for entregue ao cliente.
– Causas das mudanças:
ErrosErros.
Adaptação do software para acomodaracomodar mudanças
em seu ambiente externo.
Exigência do cliente para melhoramentosmelhoramentos funcionais e de 
desempenho.
– Reaplica cada uma das fases precedentes a um 
programa existente.
Modelo Cascata: Problemas
 Projetos reais raramente seguem o fluxo seqüencial 
que o modelo propõe.
 Modificações podem causar confusão à medida que o 
projeto prossegue.
 É difícil para o cliente estabelecer explicitamente 
todos os requisitos logo no início do projeto.
 Dificuldade do modelo em acomodar a incerteza natural 
que existe no começo do projeto.
Modelo Cascata: Problemas
 O cliente deve ter paciência. Uma versão 
executável do software só fica disponível em uma 
etapa avançada do desenvolvimento.
 Um erro grosseiro pode ser desastroso, se não for 
detectado até que o programa executável seja revisto.
Embora o Embora o Modelo CascataModelo Cascata tenha tenha 
fragilidades, ele é fragilidades, ele é 
significativamente melhor do que significativamente melhor do que 
uma abordagem casual ao uma abordagem casual ao 
desenvolvimento de software.desenvolvimento de software. 
Embora o Embora o Modelo CascataModelo Cascata tenha tenha 
fragilidades, ele é fragilidades, ele é 
significativamente melhor do que significativamente melhor do que 
uma abordagem casual ao uma abordagem casual ao 
desenvolvimento de software.desenvolvimento de software. 
O Modelo Cascata
 ContribuiçõesContribuições importantes do modelo ao 
processo de desenvolvimento de software:
– Produz um padrãopadrão no qual os métodos para 
análise, projeto, codificação, testes e manutenção 
podem ser situados.
– Impõe disciplinadisciplina, planejamentoplanejamento e gerenciamentogerenciamento.
– A implementação do produto deve ser postergadapostergada 
até que os objetivos tenham sido completamente 
entendidos.
O Modelo de Prototipação
 Possibilita que o desenvolvedor crie um 
modelo (protótipoprotótipo) do software que deve ser 
construído.
O objetivo é entender os requisitos do requisitos do 
usuáriousuário e, assim, obter uma melhor definição 
dos requisitos do sistema.
– Apropriado para quando o cliente não definiu 
detalhadamente os requisitos.
O Modelo de Prototipação
Obter Requisitos Obter Requisitos 
Elaborar Projeto RápidoElaborar Projeto Rápido
ConstruirProtótipoConstruir Protótipo
Avaliar ProtótipoAvaliar Protótipo
Refinar ProtótipoRefinar Protótipo
O Modelo de Prototipação
Obter Requisitos Obter Requisitos 
Elaborar Projeto RápidoElaborar Projeto Rápido
Construir ProtótipoConstruir Protótipo
Avaliar ProtótipoAvaliar Protótipo
Refinar ProtótipoRefinar Protótipo
 Obtenção dos RequisitosObtenção dos Requisitos
– Desenvolvedor e cliente:
 Definem os objetivos gerais do software.
Identificam quais requisitos são conhecidos.
Identificam as áreas que necessitam de 
definições adicionais. 
O Modelo de Prototipação
Obter Requisitos Obter Requisitos 
Elaborar Projeto RápidoElaborar Projeto Rápido
Construir ProtótipoConstruir Protótipo
Avaliar ProtótipoAvaliar Protótipo
Refinar ProtótipoRefinar Protótipo
 Projeto RápidoProjeto Rápido
– Representação dos aspectos do software 
que são visíveis ao usuário.
Abordagens de entrada.
Formatos de saída.
O Modelo de Prototipação
Obter Requisitos Obter Requisitos 
Elaborar Projeto RápidoElaborar Projeto Rápido
Construir ProtótipoConstruir Protótipo
Avaliar ProtótipoAvaliar Protótipo
Refinar ProtótipoRefinar Protótipo
 Construção do ProtótipoConstrução do Protótipo
– Implementação rápida do protótipo. 
O Modelo de Prototipação
Obter Requisitos Obter Requisitos 
Elaborar Projeto RápidoElaborar Projeto Rápido
Construir ProtótipoConstruir Protótipo
Avaliar ProtótipoAvaliar Protótipo
Refinar ProtótipoRefinar Protótipo
 Avaliação do ProtótipoAvaliação do Protótipo
– Cliente e desenvolvedor avaliam o 
protótipo. 
O Modelo de Prototipação
Obter Requisitos Obter Requisitos 
Elaborar Projeto RápidoElaborar Projeto Rápido
Construir ProtótipoConstruir Protótipo
Avaliar ProtótipoAvaliar Protótipo
Refinar ProtótipoRefinar Protótipo
 Refinamento do ProtótipoRefinamento do Protótipo
– Cliente e desenvolvedor refinam os 
requisitos do software a ser desenvolvido. 
O Modelo de Prototipação
Obter Requisitos Obter Requisitos 
Elaborar Projeto RápidoElaborar Projeto Rápido
Construir ProtótipoConstruir Protótipo
Avaliar ProtótipoAvaliar Protótipo
Refinar ProtótipoRefinar Protótipo
CONSTRUÇÃO CONSTRUÇÃO 
DO PRODUTODO PRODUTO
 Construção do ProdutoConstrução do Produto
– Identificados os requisitos, o protótipo deve 
ser descartadodescartado e a versão de produção deve 
ser construída considerando os critérios de critérios de 
qualidadequalidade. 
Prototipação: Problemas
O cliente não sabe que o software que ele vê 
nãonão considerou, durante o desenvolvimento:
– Qualidade global.
– Manutenibilidade a longo prazo.
O desenvolvedor freqüentemente faz uma 
implementação comprometidaimplementação comprometida.
– Utilizando o que está disponível com o objetivo de 
produzir rapidamente um protótipo.
O Modelo de Prototipação
 Ainda que possam ocorrer problemas, a 
prototipação é um ciclo de vida eficiente.
 Definir as regras do jogo logo no começo.Definir as regras do jogo logo no começo.
– O cliente e o desenvolvedor devem concordar que 
o protótipo será construído para servir como um 
mecanismo para definição dos requisitosmecanismo para definição dos requisitos.
Deve ser descartadodescartado (ao menos em parte).
O software real é submetido à engenharia visando à 
qualidadequalidade e à manutenibilidademanutenibilidade.
O Modelo RAD
RAD (Rapid Application Development)
é um modelo seqüencial linear que enfatiza 
um ciclociclo de desenvolvimento extremamente 
curtocurto.
 Trata-se de uma adaptação de “alta 
velocidade” do modelo seqüencial linearmodelo seqüencial linear.
O Modelo RAD
 A abordagem engloba as seguintes 
fases:
1. Modelagem do Negócio
2. Modelagem dos Dados
3. Modelagem do Processo
4. Geração da Aplicação
5. Teste e Modificação
O Modelo RAD
Modelagem do 
Negócio
Modelagem dos 
Dados
Modelagem do 
Processo
Geração da 
Aplicação
Teste e
Modificação
Equipe #1 Modelagem do Negócio
Modelagem dos 
Dados
Modelagem do 
Processo
Geração da 
Aplicação
Teste e 
Modificação
Equipe #2 Modelagem 
do Negócio
Modelagem 
dos Dados
Modelagem 
do Processo
Geração da 
Aplicação
Teste e 
Modificação
Equipe #3
60 a 90 dias
O Modelo RAD
1- Modelagem do Negócio
O fluxo de informação entre as funções de funções de 
negócionegócio é modelado de modo que responda as 
seguintes questões: 
– Que informação direciona o processo de negócio? 
– Que informação é gerada? 
– Quem a gera?
– Para onde vai a informação?
– Quem a processa?
O Modelo RAD
2- Modelagem dos Dados
 O fluxo de informação definido como parte da fase de 
modelagem dos negócios é refinado em um conjunto 
de objetos de dadosobjetos de dados necessários para apoiar os 
negócios.
 As característicascaracterísticas (atributos) de cada objeto são 
identificadas e o relacionamentorelacionamento entre esses objetos é 
definido.
O Modelo RAD
A abordagem RAD engloba as 
seguintes fases:
– Modelagem do Negócio
– Modelagem dos Dados
– Modelagem do Processo
– Geração da Aplicação
– Teste e Modificação
3- Modelagem do Processo
 Os objetos de dados definidos na fase de modelagem 
dos dados são transformados para obter o fluxo de 
informação necessário para implementar uma função 
de negócio.
 As descrições de processamento são criadas 
adicionando, modificando, excluindo ou recuperando 
objetos de dados.
O Modelo RAD
4- Geração da Aplicação
 RAD assume o uso de técnicas de 4ª geração 
(ferramentas automatizadas para facilitar a construção 
do software).
– Delphi, Visual Basic, Asp.net, etc.
 O processo RAD trabalha para reutilizar componentes 
de programa existentes (quando possível) ou criar 
componentes reutilizáveis.
O Modelo RAD
5- Teste e Modificação
 Como o processo RAD enfatiza a reutilização, 
muitos dos componentes do programa já foram 
testados.
– Isso reduz o tempo de teste global. 
– Entretanto… os novos componentes devem ser testados e 
todas as interfaces devem ser exaustivamente exercitadas. 
O Modelo RAD
 Se uma aplicação de negócio puder ser 
modularizadamodularizada, de modo que possibilite que 
cada função principal seja completada em 
um curto prazocurto prazo (por ex: 30 a 90 dias), ela é 
candidata ao RAD.
– Cada função principal pode ser tratada por uma 
equipe RAD distinta e depois integrada para 
formar o todo.
Modelo RAD: Problemas
 Para projetos grandes (mas escaláveis), RAD 
exige recursos humanosrecursos humanos suficientes para 
criar um número adequado de equipes.
 Exige que desenvolvedores e clientes 
estejam comprometidos com atividades atividades 
continuamente rápidascontinuamente rápidas, necessárias para 
obter um sistema completosistema completo em um período período 
muito curtomuito curto.
Modelo RAD: Problemas
 Nem todos os tipos de aplicação são 
apropriadas para o RAD. 
– Deve ser possível a modularização efetivamodularização efetiva 
da aplicação..
 Se o sistema não puder ser adequadamente 
modularizado, a construção dos componentes 
será problemática.
Modelo RAD: Problemas
Quando riscos técnicosriscos técnicos forem 
elevados, o RAD não é adequado. 
– A nova aplicação faz uso intenso de novas novas 
tecnologiastecnologias..
– O novo software exige um alto grau de 
interoperabilidadeinteroperabilidade com programas 
existentes.
Modelos Evolucionários 
(Evolutivos)
Existem situações em que a 
engenharia de software necessita de 
um modelo de processo que possa 
acomodar um produto que evolui com o evolui com o 
tempotempo.
Modelos Evolucionários 
(Evolutivos)
Requisitos de produtoproduto e de negócionegócio mudam 
conforme o desenvolvimento prossegue.
Requisitosbásicos são bem conhecidos, mas 
os detalhesdetalhes ainda devem ser definidos.
 Prazos reduzidosPrazos reduzidos de mercado tornam 
impossível a conclusão de um produto 
completo.
– Uma versão reduzidaversão reduzida pode ser elaborada face à 
competitividade ou às pressões do negócio.
 Modelo CascataModelo Cascata: desenvolvimento retilíneo.
– O sistema completo estará pronto depois que a 
seqüência linear for concluída.
 PrototipaçãoPrototipação: entendimento dos requisitos.
– Em geral, não é projetado para ajudar um sistema 
em produção.
Modelos Evolucionários 
(Evolutivos)
A natureza evolutiva do software A natureza evolutiva do software 
não é considerada.não é considerada. 
A natureza evolutiva do software A natureza evolutiva do software 
não é considerada.não é considerada. 
Modelos evolutivos são iterativositerativos.
– Possibilitam o desenvolvimento de versõesversões 
cada vez mais completas do software.
Modelo Incremental
Modelo Espiral
Modelo de Desenvolvimento Concorrente
Modelos Evolucionários 
(Evolutivos)
O Modelo Incremental
O Modelo Incremental combina:
– Elementos do Modelo Cascata (aplicado 
repetidamente).
– A filosofia iterativa da Prototipação.
O Modelo Incremental
 Objetivo: trabalhar junto ao cliente para 
descobrir seus requisitos, de maneira 
incremental, até que o produto final seja 
obtido.
– A evolução acontece quando novas 
características são adicionadasadicionadas à medida que 
são sugeridas pelo cliente.
O Modelo Incremental
Clientes identificam, em um esboço, as 
funções a serem fornecidas pelo 
sistema.
– Funções maismais e menosmenos importantes.
Definem-se estágios de entregaestágios de entrega.
– Cada estágio fornece um subconjuntosubconjunto das 
funcionalidades do sistema. 
IncrementoIncremento.
O Modelo Incremental
Os incrementosincrementos são elaborados 
utilizando-se o processo de 
desenvolvimento mais apropriado.
 Incrementos concluídos são entreguesentregues 
ao cliente e colocados em operaçãooperação.
Versões IdiáriasVersões Idiárias
Versões 
Intermediárias
O Modelo Incremental
Versão
Inicial
Versão
Inicial
Versões 
Intermediárias
Versão
Final
Versão
Final
Descrição 
geral
Descrição 
geral
Engenh
aria de 
Sistema
s
Engenh
aria de 
Sistema
s
Análise 
de 
Requisit
os 
Análise 
de 
Requisit
os 
Projeto Projeto 
Codifica
ção 
Codifica
ção 
Testes Testes 
O Modelo Incremental
 A versão inicial é frequentemente o núcleonúcleo do 
produto (a parte mais importante).
 A funcionalidade do sistema melhoramelhora a cada 
novo estágio que é entregue.
– Os incrementos são versões simplificadasversões simplificadas do 
produto final.
 Oferecem capacidadescapacidades que servem ao usuário.
Constituem uma plataforma para avaliaçãoavaliação.
O Modelo Incremental
 Importante quando é difícil estabelecer a 
priori uma especificação detalhadaespecificação detalhada dos 
requisitos.
Útil quando não há mão-de-obra mão-de-obra disponíveldisponível 
para uma implementação completa, dentro 
do prazo de entrega estabelecido.
Os incrementos podem ser planejados de 
modo que os riscos técnicosriscos técnicos possam ser 
gerenciadosgerenciados.
Modelo Incremental: Problemas
 Incrementos devem ser relativamente 
pequenospequenos e produzir alguma 
funcionalidadefuncionalidade para o sistema.
– Difícil mapear os requisitos do cliente 
dentro de incrementos de tamanho correto.
 Difícil identificar facilidades comunsfacilidades comuns, 
exigidas por todos os incrementos. 
Programação Extrema
(eXtreme Programming)
 EvoluçãoEvolução da abordagem incremental.
 (Kent Beck, 1999)
– Voltada para equipes de até 20 pessoas, 
engajadas no desenvolvimento de 
software cujos requisitos são vagosvagos ou se 
encontram em constante mudançaconstante mudança.
Programação Extrema
(eXtreme Programming)
– Desenvolvimento e entrega de incrementosincrementos de 
funcionalidade muito pequenos.
– EnvolvimentoEnvolvimento do cliente no processo.
– Constante melhoriamelhoria de código.
– Programação em paresem pares.
– 40 horas de trabalho.
– RefactoringRefactoring 
 Abordagem disciplinada para tornar o código de um 
software mais claro e de fácil manutenção, minimizando 
a probabilidade de inclusão de erros.
– Test firstTest first, code latercode later.
O Modelo Espiral
 O Modelo Espiral combina:
– A natureza iterativaiterativa da Prototipação.
– Os aspectos controladoscontrolados e sistemáticossistemáticos do 
Modelo Cascata.
 Fornece potencial para o desenvolvimento 
rápido de versões incrementaisversões incrementais do software.
Dividido em um certo número de atividades 
ou regiões de tarefaregiões de tarefa.
– Existem, tipicamente, de 3 a 6 regiões de tarefa.
O Modelo Espiral
 
Revisão
Determinar objetivos, 
alternativas e
restrições
Planejar próxima fase
Avaliar alternativas
Identificar,
resolver riscos
Desenvolver,
verificar produto no 
próximo nível
Plano de requisitos
Plano de ciclo de vida
Plano de
desenvolvimento
Integração
e plano de teste
Análise
de risco
Análise
de risco
Análise
de risco
Análise
de risco
Protó
tipo 1
Protótipo
2
Protótipo
3
Protótipo
Operacional
Simulação, modelos, benchmarks
Conceito de
operação
Validação de
requisito
Requisitos
de SW
Projeto
V & V
Projeto
do produto Projeto
detalhado
Código
Teste de
unidade
Teste de
integração
Teste de
aceitaçãoOperação
Cada Cada looploop na espiral na espiral 
representa umarepresenta uma fasefase do do 
processo de software.processo de software.
O Modelo Espiral
 
Revisão
Plano de requisitos
Plano de ciclo de vida
Análise
de risco
Protó
tipo 1
Conceito de
operação
O O looploop mais interno está mais interno está 
relacionado àrelacionado à viabilidadeviabilidade 
do sistema.do sistema.
O Modelo Espiral
 
Plano de
desenvolvimento
Análise
de risco
Protótipo
2
Simulação, modelos, benchmarks
Validação de
requisito
Requisitos
de SW
O próximo O próximo looploop está está 
concentrado na definição concentrado na definição 
dosdos requisitosrequisitos do do 
sistema.sistema.
O Modelo Espiral
 
Integração
e plano de teste
Análise
de risco
Protótipo
3
Simulação, modelos, benchmarks
Projeto
V & V
Projeto
do produto
O O looploop seguinte está seguinte está 
concentrado noconcentrado no projetoprojeto 
do sistema.do sistema.
O Modelo Espiral
 Análise
de risco
Protótipo
Operacional
Simulação, modelos, benchmarks
Projeto
detalhado
Código
Teste de
unidade
Teste de
integração
Teste de
aceitaçãoOperação
O O looploop ainda mais ainda mais 
externo está externo está 
concentrado naconcentrado na 
construçãoconstrução do sistema.do sistema.
O Modelo Espiral
 
Revisão
Determinar objetivos, 
alternativas e
restrições
Planejar próxima fase
Avaliar alternativas
Identificar,
resolver riscos
Desenvolver,
verificar produto no 
próximo nível
Plano de requisitos
Plano de ciclo de vida
Plano de
desenvolvimento
Integração
e plano de teste
Análise
de risco
Análise
de risco
Análise
de risco
Análise
de risco
Protó
tipo 1
Protótipo
2
Protótipo
3
Protótipo
Operacional
Simulação, modelos, benchmarks
Conceito de
operação
Validação de
requisito
Requisitos
de SW
Projeto
V & V
Projeto
do produto Projeto
detalhado
Código
Teste de
unidade
Teste de
integração
Teste de
aceitaçãoOperação
Definição dos Definição dos 
ObjetivosObjetivos 
Definição dos Definição dosObjetivosObjetivos 
Avaliação e Avaliação e 
Redução de RiscosRedução de Riscos 
Avaliação e Avaliação e 
Redução de RiscosRedução de Riscos 
PlanejamentoPlanejamentoPlanejamentoPlanejamento Desenvolvimento e Desenvolvimento e ValidaçãoValidação
Desenvolvimento e Desenvolvimento e 
ValidaçãoValidação
O Modelo Espiral
 
Revisão
Determinar objetivos, 
alternativas e
restrições
Planejar próxima fase
Avaliar alternativas
Identificar,
resolver riscos
Desenvolver,
verificar produto no 
próximo nível
Plano de requisitos
Plano de ciclo de vida
Plano de
desenvolvimento
Integração
e plano de teste
Análise
de risco
Análise
de risco
Análise
de risco
Análise
de risco
Protó
tipo 1
Protótipo
2
Protótipo
3
Protótipo
Operacional
Simulação, modelos, benchmarks
Conceito de
operação
Validação de
requisito
Requisitos
de SW
Projeto
V & V
Projeto
do produto Projeto
detalhado
Código
Teste de
unidade
Teste de
integração
Teste de
aceitaçãoOperação
Definição dos Definição dos 
ObjetivosObjetivos 
Definição dos Definição dos 
ObjetivosObjetivos 
– São definidos os objetivos específicosobjetivos específicos para cada 
fase do projeto.
– São identificadas restriçõesrestrições sobre o processo e o 
produto.
– É projetado um plano de gerenciamentoplano de gerenciamento detalhado.
– São identificados os riscos do projetoriscos do projeto e planejadas 
estratégias alternativasestratégias alternativas. 
O Modelo Espiral
 
Revisão
Determinar objetivos, 
alternativas e
restrições
Planejar próxima fase
Avaliar alternativas
Identificar,
resolver riscos
Desenvolver,
verificar produto no 
próximo nível
Plano de requisitos
Plano de ciclo de vida
Plano de
desenvolvimento
Integração
e plano de teste
Análise
de risco
Análise
de risco
Análise
de risco
Análise
de risco
Protó
tipo 1
Protótipo
2
Protótipo
3
Protótipo
Operacional
Simulação, modelos, benchmarks
Conceito de
operação
Validação de
requisito
Requisitos
de SW
Projeto
V & V
Projeto
do produto Projeto
detalhado
Código
Teste de
unidade
Teste de
integração
Teste de
aceitaçãoOperação
Avaliação e Avaliação e 
Redução de RiscosRedução de Riscos 
Avaliação e Avaliação e 
Redução de RiscosRedução de Riscos 
– É realizada uma análise detalhadaanálise detalhada para 
cada um dos riscos identificados.
– São tomadas providênciasprovidências para reduzir os 
riscos.
O Modelo Espiral
 
Revisão
Determinar objetivos, 
alternativas e
restrições
Planejar próxima fase
Avaliar alternativas
Identificar,
resolver riscos
Desenvolver,
verificar produto no 
próximo nível
Plano de requisitos
Plano de ciclo de vida
Plano de
desenvolvimento
Integração
e plano de teste
Análise
de risco
Análise
de risco
Análise
de risco
Análise
de risco
Protó
tipo 1
Protótipo
2
Protótipo
3
Protótipo
Operacional
Simulação, modelos, benchmarks
Conceito de
operação
Validação de
requisito
Requisitos
de SW
Projeto
V & V
Projeto
do produto Projeto
detalhado
Código
Teste de
unidade
Teste de
integração
Teste de
aceitaçãoOperação
Desenvolvimento e Desenvolvimento e 
ValidaçãoValidação
Desenvolvimento e Desenvolvimento e 
ValidaçãoValidação
– Depois da avaliação dos riscos, é 
escolhido um modelo de modelo de 
desenvolvimentodesenvolvimento para o sistema.
O Modelo Espiral
 
Revisão
Determinar objetivos, 
alternativas e
restrições
Planejar próxima fase
Avaliar alternativas
Identificar,
resolver riscos
Desenvolver,
verificar produto no 
próximo nível
Plano de requisitos
Plano de ciclo de vida
Plano de
desenvolvimento
Integração
e plano de teste
Análise
de risco
Análise
de risco
Análise
de risco
Análise
de risco
Protó
tipo 1
Protótipo
2
Protótipo
3
Protótipo
Operacional
Simulação, modelos, benchmarks
Conceito de
operação
Validação de
requisito
Requisitos
de SW
Projeto
V & V
Projeto
do produto Projeto
detalhado
Código
Teste de
unidade
Teste de
integração
Teste de
aceitaçãoOperação
PlanejamentoPlanejamentoPlanejamentoPlanejamento
– O projeto é revistorevisto e é tomada uma decisão 
sobre continuar com o próximo loop.
– Se a decisão for continuar, são traçados os 
planosplanos para a próxima fase do projeto.
O Modelo Espiral
 
Revisão
Determinar objetivos, 
alternativas e
restrições
Planejar próxima fase
Avaliar alternativas
Identificar,
resolver riscos
Desenvolver,
verificar produto no 
próximo nível
Plano de requisitos
Plano de ciclo de vida
Plano de
desenvolvimento
Integração
e plano de teste
Análise
de risco
Análise
de risco
Análise
de risco
Análise
de risco
Protó
tipo 1
Protótipo
2
Protótipo
3
Protótipo
Operacional
Simulação, modelos, benchmarks
Conceito de
operação
Validação de
requisito
Requisitos
de SW
Projeto
V & V
Projeto
do produto Projeto
detalhado
Código
Teste de
unidade
Teste de
integração
Teste de
aceitaçãoOperação
– Não existem fases fixasfases fixas no 
modelo.
– A gerênciagerência decide como 
estruturar o projeto em fases. 
O Modelo Espiral
 Engloba as melhores características do 
Modelo Cascata e da Prototipação, 
adicionando um novo elemento: a Análise de Análise de 
RiscosRiscos.
– RiscoRisco: algo que pode dar errado.
– Segue a abordagem de passos sistemáticos do 
Modelo Cascata, incorporando-os numa estrutura estrutura 
iterativaiterativa.
– Usa a Prototipação em qualquer etapa da evolução 
do produto, como mecanismo de reduçãoredução de 
riscos.
Modelo Espiral
 É, atualmente, a abordagem mais realística 
para o desenvolvimento de sistemas e 
software de grande portegrande porte.
 Exige a consideração direta dos riscos riscos 
técnicostécnicos em todos os estágios do projeto.
– Se aplicado adequadamente, pode reduzir os 
riscos antes que os mesmos fiquem 
problemáticos.
Modelo Espiral: Problemas
 Pode ser difícil convencerconvencer os clientes que 
uma abordagem evolutiva é controlável.
 Exige considerável experiênciaexperiência na 
determinação de riscos e depende dessa 
experiência para ter sucesso.
O Modelo de Montagem
de Componentes
 Incorpora características de tecnologias tecnologias 
orientadas a objetoorientadas a objeto no Modelo EspiralModelo Espiral. 
 É de natureza evolutiva demandando uma 
abordagem iterativa para a criação do software.
O modelo compõe aplicações a partir de 
componentes de software “empacotados”.
– Quando projetadas e implementadas apropriadamente, 
as classes são reutilizáveisreutilizáveis em diferentes aplicações e 
arquiteturas de sistema.
O Modelo de Montagem
de Componentes
 Planejamento
Análise de Riscos
Engenharia,
Construção e Liberação
Avaliação do Cliente
Comunicação 
com Cliente
Planejamento
Avaliação do Cliente
Comunicação 
com Cliente
Identificar 
componentes 
candidatos
Procurar 
componentes 
na biblioteca
Extrair 
componentes, 
se disponíveis
Construir os 
componentes 
não disponíveis
Colocar os 
novos 
componentes na 
biblioteca
Construir a na 
iteração do 
sistema
O Modelo de Montagem
de Componentes
 O modelo de montagem de componentes 
conduz ao reusoreuso do software.
 A reusabilidade pode fornecer uma série de 
benefícios:
– Redução no tempo de desenvolvimento.
– Redução no custo do projeto.
– Aumento no índice de produtividade.
 Tais benefícios dependem da robustez da bibliotecarobustez da biblioteca de 
componentes.
O Modelo de Métodos Formais
 Especificar, desenvolvere verificar um sistema pela aplicação 
de uma rigorosa notação matemáticarigorosa notação matemática. 
– Abrange um conjunto de atividades que levam à especificação especificação 
matemática formal matemática formal do software.
– Tem como base a transformação matemática formaltransformação matemática formal de uma 
especificação de sistema em um programa executável.
O Modelo de Métodos Formais
O Modelo de Métodos Formais
 No projeto...
– Base para a verificação do programaverificação do programa, 
permitindo que se descubram erros que 
poderiam passar despercebidos.
No desenvolvimento...
– AmbigüidadeAmbigüidade, não completitudenão completitude e 
inconsistênciainconsistência podem ser mais facilmente 
descobertas pela análise matemática.
O Modelo de Métodos Formais
 Abordagem particularmente adequada ao 
desenvolvimento de sistemas com rigorosas 
exigências de segurançasegurança, confiabilidadeconfiabilidade e 
garantiagarantia.
– Eletrônica de aeronaves.
– Controle de tráfego aéreo.
– Dispositivos médicos.
– Telecomunicações.
Modelo de Métodos Formais: 
Problemas
 Preocupações quanto à aplicabilidade em 
ambientes comerciais:
– O desenvolvimento é lentolento e dispendiosodispendioso.
– Requer treinamento extensivotreinamento extensivo.
– Difícil utilizar os modelos como um mecanismo de 
comunicaçãocomunicação.
Clientes despreparados tecnicamente.
Cleanroom (Sala Limpa)
 ExemploExemplo mais conhecido do processo de 
desenvolvimento formal.
– Desenvolvimento incrementalincremental do software.
– Cada estágio é desenvolvido e sua correção é 
demonstrada utilizando-se uma abordagem abordagem 
formalformal.
– O teste de sistema visa a medir a confiabilidadeconfiabilidade 
do sistema.
Conduzido como um experimento estatístico.
Técnicas de Quarta Geração
 Engloba um conjunto de ferramentas 
de software possibilitando que:
– O sistema seja especificado em uma 
linguagem de alto nívellinguagem de alto nível. 
– O código-fonte seja gerado 
automaticamenteautomaticamente a partir dessas 
especificações.
Técnicas de Quarta Geração
 Ferramentas de Apoio
– Linguagens não-procedimentais para:
Consulta de banco de dados (SQL).
Geração de relatórios (PostScript).
Manipulação de dados (XML).
 Interação e definição de telas (Delphi, Visual Basic).
 Geração de código.
– Capacidade gráfica de alto nível.
– Capacidade de disposição em planilhas.
– Geração automática de HTML e linguagens 
similares para criação de páginas Web. 
Técnicas de Quarta Geração
Obtenção dos 
Requisitos
Estratégia de 
“Projeto” 
Implementação 
usando 4GL 
Testes 
Técnicas de Quarta Geração
Obtenção dos 
Requisitos
Estratégia de 
“Projeto” 
Implementação 
usando 4GL 
Testes 
 Obtenção dos RequisitosObtenção dos Requisitos
– O cliente descreve os requisitos os quais são 
traduzidos para um protótipo operacionalprotótipo operacional.
O cliente pode estar inseguro quanto aos requisitos.
O cliente pode ser incapaz de especificar as informações 
de um modo que uma ferramenta 4GL possa ser utilizada.
As 4GLs atuais não são suficientemente sofisticadas para 
acomodar a verdadeira linguagem natural.
Obtenção dos 
Requisitos
Estratégia de 
“Projeto” 
Implementação 
usando 4GL 
Testes 
Técnicas de Quarta Geração
 Estratégia de “Projeto”Estratégia de “Projeto”
– Pequenas Aplicações
É possível mover-se do passo de Obtenção dos 
Requisitos para o passo de Implementação usando uma 
linguagem de quarta geração.
– Grandes Projetos
É necessário desenvolver uma estratégia de projetoestratégia de projeto.
De outro modo ocorrerão os mesmos problemas 
encontrados quando se usa abordagem convencional 
(baixa qualidade). 
Obtenção dos 
Requisitos
Estratégia de 
“Projeto” 
Implementação 
usando 4GL 
Testes 
Técnicas de Quarta Geração
 Implementação usando 4GLImplementação usando 4GL
– Os resultados desejados são representados de 
modo que haja geração automática de código.
– Deve existir uma estrutura de dados com 
informações relevantes e que seja acessível pela 
4GL.
Obtenção dos 
Requisitos
Estratégia de 
“Projeto” 
Implementação 
usando 4GL 
Testes 
Técnicas de Quarta Geração
 TestesTestes
– O desenvolvedor deve efetuar testes e desenvolver 
uma documentaçãodocumentação significativa.
– O software desenvolvido deve ser construído de 
maneira que a manutençãomanutenção possa ser efetuada 
prontamente.
Técnicas de Quarta Geração
 Proponentes
– Redução dramática no tempotempo de desenvolvimento 
do software.
Aumento de produtividadeprodutividade.
Oponentes
– As 4GL atuais não são mais fáceis de usar do que 
as linguagens de programação.
– O código-fonte produzido é ineficiente.
– A manutenibilidademanutenibilidade de sistemas usando técnicas 
4GT ainda é questionável.
Metodologias Ágeis
 SCRUMSCRUM
 Crystal/Clear
 FDDFDD (Feature Driven Development)
– Desenvolvimento Orientado a Funcionalidades
 DSDM DSDM (Dynamic Systems Development 
Method)
– Método Dinâmico de Desenvolvimento de Sistemas
 ASD ASD (Adaptive Software Development)
– Desenvolvimento Adaptável de Software
Metodologias Ágeis
 XPXP (eXtreme Programming)
Pragmatic ProgrammingPragmatic Programming
Open Source Software DevelopmentOpen Source Software Development
RUPRUP (Rational Unified Process)
Concluindo...
 Cascata, Prototipação, Evolutivos, Formais, Ágeis, ...
 Para escolha de um modelo de processo de softwaremodelo de processo de software:
– Natureza do projeto e da aplicação.
– Métodos e ferramentas a serem usados.
– Controles e produtos que precisam ser entregues.
 Não são mutuamente exclusivos e freqüentemente são usados em 
conjunto. 
	Slide 1
	Slide 2
	Slide 3
	Slide 4
	Slide 5
	Slide 6
	Slide 7
	Slide 8
	Slide 9
	Slide 10
	Slide 11
	Slide 12
	Slide 13
	Slide 14
	Slide 15
	Slide 16
	Slide 17
	Slide 18
	Slide 19
	Slide 20
	Slide 21
	Slide 22
	Slide 23
	Slide 24
	Slide 25
	Slide 26
	Slide 27
	Slide 28
	Slide 29
	Slide 30
	Slide 31
	Slide 32
	Slide 33
	Slide 34
	Slide 35
	Slide 36
	Slide 37
	Slide 38
	Slide 39
	Slide 40
	Slide 41
	Slide 42
	Slide 43
	Slide 44
	Slide 45
	Slide 46
	Slide 47
	Slide 48
	Slide 49
	Slide 50
	Slide 51
	Slide 52
	Slide 53
	Slide 54
	Slide 55
	Slide 56
	Slide 57
	Slide 58
	Slide 59
	Slide 60
	Slide 61
	Slide 62
	Slide 63
	Slide 64
	Slide 65
	Slide 66
	Slide 67
	Slide 68
	Slide 69
	Slide 70
	Slide 71
	Slide 72
	Slide 73
	Slide 74
	Slide 75
	Slide 76
	Slide 77
	Slide 78
	Slide 79
	Slide 80
	Slide 81
	Slide 82
	Slide 83
	Slide 84
	Slide 85
	Slide 86
	Slide 87