Você está na página 1de 6

Modelos de Ciclo de vida

n Projetos são empreendimentos únicos e portanto

Engenharia de Software envolvem um grau de incerteza.


n Organizações dividem projetos em fases de forma a
Aula 02 – Ciclo de Vida garantir um melhor controle e encadeamento com as
operações correntes da empresa.
Fernando Prass n O conjunto das fases de um projeto é conhecido como
fprass@gmail.com ciclo de vida do projeto.
www.fp2.com.br/fernando
1/36 2/36

Seqüência das fases Ciclo de Vida do Software

n A seqüência de fases normalmente envolve alguma


forma de transferência de informação. Exemplo: de Projeto e
Requisitos
requisitos para projeto ou de projeto para construção. Desenv.
Fases
n Produtos das fases precedentes são usualmente (macro-etapas) Implantação/
aprovados antes do início da fase seguinte. Manutenção
n “Fast tracking”: fases correndo em paralelo com um
risco tolerável.

3/36 4/36

03 Macro-Etapas Modelos de Ciclo de vida


n Requisitos: “O que” deve ser desenvolvido e “Como” os
n Modelos de ciclos de vida definem:
processos e dados são utilizados.
Analista + Cliente/Usuário ¨ que parte do trabalho técnico que deve ser

n Projeto e Desenvolvimento: feita em cada fase

Analista + Programador => Cliente/Usuário ¨ quem deve estar envolvido em cada fase
n Implantação: Resistência ¨ como deve ser feito o trabalho em cada fase
n Manutenção: Vida útil (correção, adaptação,
incorpora ção de melhoramento funcional)
5/36 6/36

1
Modelo Cascata Modelo Cascata - Características
= Requer uma abordagem sistemática
n Uma etapa termina antes da próxima começar
Engenharia de seqü encial ao desenvolvimento
Sistemas de software. n Cliente afastado da fase de implementação
Anáá lise de
An
Requisitos (funcionalidade do sistema separada do projeto);
Projeto “o que – como fazer”
Codificaçção
Codifica n Foi e ainda tem sido usado para indicar as atividades de
Testes projeto em vários contextos
Manutençç ão
Manuten

7/36 8/36

Modelo Cascata Modelo Cascata


Um exemplo do uso deste modelo (Departamento n Ajuda os desenvolvedores a descrever o que
de defesa dos EUA) precisam fazer (útil);
• Gerentes de projeto podiam utilizar o modelo para estimar n Ajuda a explicar o processo de desenvolvimento
quanto faltava para o término do projeto. aos clientes (simples e fácil);
• Marcos e Produtos estavam associados a cada atividade do
n Explicita os produtos intermediários para
processo.
começar próximo estágio;
Teste de Módulos Cópia n Seu enfoque está nos documentos e artefatos
teste Unidades e Codificados do Código
Integração testados Gerado (requisitos, projetos, códigos);
integrados
9/36 10/36

Modelo Cascata Modelo Cascata


n Maior problema: não reflete efetivamente como o n Usuários e Desenvolvedores não irão conhecer
código é desenvolvido todos os requisitos em uma única etapa (todos os
n Freqüentemente usado na solução de problemas fatores que influenciarão no resultado desejado)
nunca resolvidos antes ou para soluções que
n Usar muito do tempo gasto na compreensão dos
precisam ser atualizadas para refletir alguma
itens e processos afetados pelo sistema e seu
mudança nos neg ócios
software;

11/36 12/36

2
Modelo Cascata - Dicas Modelo Cascata - Desvantagens
n Controlar o processo real de desenvolvimento; n Não mostra detalhes de como cada fase

n Não passar muitas vezes de uma etapa para a transforma um artefato em outro, por exemplo:

outra e ficar voltando para a anterior Como transformar os requisitos em projeto;

sucessivamente enquanto se esforçam para n Não trata sobre as mudanças nos produtos e
adquirir conhecimento sobre o problema e como atividades que provavelmente ocorrerão durante
chegar a solução proposta. o desenvolvimento.

13/36 14/36

Modelo Cascata - Desvantagens


Modelo Cascata: Desenvolver é...
n Exemplos:
n Tentar um pouco de várias alternativas;
n quando os requisitos são modificados durante
n Desenvolver a avaliar projetos;
a programação, as mudanças subseqüentes no
n Avaliar a viabilidade dos requisitos, contrastando
projeto e no código não são indicadas.
diversos projetos, aprendendo com as falhas para
n Não informa nada sobre as atividades de “ida e
chegar a uma solução satisfatória.
volta” que levam a cria ção do produto final.

15/36 16/36

Modelo Cascata: Resumo


Modelo Incremental
n Clássico è Mais antigo;
n Seqüencial; Requisitos
n Gerenciamento Simples;
n Incompatível com Realidade Atual; Projeto Projeto

n Problema è Requisitos (uma única etapa); Cod. Mód. Cod. Mód.


n Retornos ???;
Integraçào Integraçào
n Testes (final do processo);
n Erros Sutis – atraso no cronograma. Aceite Aceite

17/36 18/36

3
Modelo Incremental Modelo Incremental RAD
n Variante do Modelo Cascata (Rapid Application Development)
n Decomposição da Fase de Projeto Modelagem
do Neg ócio
Modelagem
do Neg ócio

n Atividades em Paralelo Modelagem Modelagem


dos Dados dos Dados
n Desenvolvimento em fases Modelagem Modelagem
de Processos de Processos
n Entrega do sistema em partes Geraç ão do Geraç ão do
Aplicativo Aplicativo
n Permissão para que o usuário utilize alguns
Testes Testes
recursos enquanto outros estão sendo
desenvolvidos
60-90 dias 60-90 dias
19/36 20/36

Modelo Incremental RAD Modelo Incremental RAD


1. Modelagem do negócio: definição das atividades a
serem executadas e seus requisitos de informação n Pontos positivos
2. Modelagem dos dados – Definição dos objetos de n uso de componentes
dados que suportam o negócio n redução do tempo
3. Modelagem do tratamento da informação – Descrição
dos processos de manipulação dos objetos de dados
n Pontos negativos
4. Gera ção da aplicação – usando técnicas de geração n tamanho da equipe
de código e bibliotecas de componentes n necessidade de comprometimento
n não adequada a projetos de risco
5. Testes – Tempo de testes reduzido devido ao uso de
componentes
21/36 22/36

Modelo por Prototipação Modelo por Prototipação


n Pode ser usado tanto como um modelo específico
a ser seguido (base de um processo efetivo),
Ouvir o Desenho e
Cliente Construção quanto como um sub-processo de outro modelo;
n Construído rapidamente para que questões sejam
entendidas ou esclarecidas;
Avaliação n Possibilita examinar antecipadamente os
do Cliente
requisitos.
Prototipação é uma boa opção para a definição de requisitos
23/36 24/36

4
Modelo por Prototipação Modelo por Prototipação
n Reduz os riscos e as incertezas do
desenvolvimento. Exemplo: n Pontos positivos
¨ grande interação com o usuário
n começa com um conjunto simples de requisitos
¨ qualidade da definição da interface
n os usuários fazem experimentações e decidem o
que querem
n os requisitos são revisados, alterados, n Pontos negativos
detalhados, documentados e o sistema passa a ¨ expectativa do usuário
ser codificado
¨ compromissos com a tecnologia
n novamente as alternativas são discutidas e
assim por diante até a entrega do software
25/36 26/36

Modelo Espiral Modelo Espiral


D ete rmine ob j ect iv es Avaliaç ão de
Ev a luate alt e rn at ive s
a ltern ativ es a nd id en ti fy , reso lv e ri sk s Planejamento Alternativas e Riscos
co ns train ts R isk
a na lys is
R isk
ana lys is
Ri sk
an aly sis O pe ra-
Prot oty p e 3 ti o na l
Prot o typ e 2 p ro t oyp e
Risk
Pro t o-
R EV IEW analysis
ty p e 1 3 2 1 0
Re qu ire me nt s pl an Simu lati o ns, mo de ls, b en ch ma rks
Li fe-c ycl e p lan C on cep t o f
O pe ra ti on S/W
req ui remen ts Prod u ct
de si g n De tai le d
De ve lop men t Re qu ire me nt d esi gn
pl an v ali d at io n C od e
De si g n U ni t t est
Int egra ti on
a nd t est p la n V& V Int egr ati on Engenharia
Plan ne xt p h ase
A ccep ta nc e te st Avaliaç ão do Cliente Desenvolvimento
Serv i ce t est D ev elo p, v e rify
n ext -l e vel p rod u ct de Software
Boehm (1988)
27/36 28/36

Modelo Espiral Modelo Espiral


n Cada volta ao longo da espiral gera:
n Inicia com Requisitos e um Projeto inicial
¨ um protótipo

¨ versão mais sofisticada;


para o desenvolvimento (incluindo um
orçamento, restrições e alternativas para o
n Permite ao desenvolvedor:
¨ utilizar
a prototipação em qualquer estágio de pessoal, o projeto e o ambiente de
evolução do produto desenvolvimento);
¨ manter a sistemática sugerida pelo ciclo de vida
n Combina as atividades de desenvolvimento
clássico.
com gerenciamento de risco;
29/36 30/36

5
Modelo Espiral Modelo Espiral
n Especificação e Detalhamento de
n Avaliar riscos e criação de protótipos Requisitos (o completo quanto possível)
alternativos antes de ser produzido um n 1ª iteração – o produto é a concepção
documento de “concepção das operações”; das operações;
n 2ª iteração - os requisitos;
n O objetivo é descrever em alto nível como o
n 3ª iteração - o desenvolvimento do
sistema deverá funcionar. sistema produz o projeto;
n 4ª iteração - habilita os testes.
31/36 32/36

Modelo Espiral
n Em cada iteração, a análise de riscos pondera
diferentes alternativas em face dos requisitos e
das restrições.
n A prototipação verifica a viabilidade e a
adequação, antes que haja a decisão por alguma
alternativa.
n Quando riscos são identificados, o gerenciamento
do projeto decide como eliminar ou minimizar
cada risco.
33/36