5 EngSoftware CicloVida Cascata

Ciclos de Vida de Software
O conceito de Ciclo de Vida de Software um

paradigma da Eng.Software.

Existem vrios modelos de ciclo de vida de software,
alguns cobrindo apenas da concepo ao
desenvolvimento, enquanto outros cobrem
concepo, desenvolvimento, implantao e
manuteno.
Modelo Clssico (Cascata)
Modelo didtico que divide o ciclo de vida de 5 a 12
fases (cf. o autor).
Criado por Winston W. Royce (1970) e aperfeioado
por Barry Boehm (1976).
Adequao:
Projetos grandes (cobre todas as fases), quando os
requisitos esto claramente definidos no incio do
desenvolvimento, com complexidade baixa e riscos
tcnicos e de projeto bem entendidos.

Definio de Requisitos:
Requisito: (adj.) O que se requisitou ou requereu.
Condio necessria para obteno de certo
objetivo. Quesito.
Foco:
No usurio e no processo (voz do cliente e voz do
processo).
Tarefas:
Extrair os requisitos, especificar cada um deles,
redigir uma Definio de Requisitos e valida-los junto
ao usurio.
Atravs de consulta ao usurio e observao do
processo (existem outras possibilidades, por exemplo
analisar os documentos em uso no sistema
convencional), extrair os servios e as metas a serem
atingidas, bem como as restries serem respeitadas.
Qual a qualidade desejada para o sistema em termos
de funcionalidade, desempenho, flexibilidade de uso,
etc.
Especificar quais os requisitos e no como eles
devero ser obtidos (detalhes de implementao).
Esse refinamento ser feito na fase de anlise e/ou
projeto.
Diferena entre:
Informar clientes classificados em ordem alfabtica
crescente.
Informar clientes classificados em ordem alfabtica
crescente (Tabela TC_Cliente, campo TC_Nome.
Montar viso para a tabela ordenada).
Praticamente todo requisito identificado precisa de
uma especificao.

Especificar: (v.t.d.) Indicar espcie de; explicar
detalhadamente; Descrio rigorosa e minuciosa das
caractersticas que um material, uma obra ou um
servio devero apresentar.
Por exemplo:
Requisito:
O sistema deve aceitar multi-empresas.
Especificao:
Cada empresa tem CNPJ, endereo e Diretoria prpria.
Os clientes so cadastrados para a Holding e no por
empresa. Atualmente existem 4 empresas, mas esse
nmero poder chegar a 10 unidades.
Gerar um Documento de Especificao, redigido em
linguagem inteligvel para o usurio.
Finalidade:
1. O usurio dever analisar e confirmar se a descrio
est correta e se atende suas necessidades e
expectativa.
2. Ser usados pelos desenvolvedores, durante o
processo de construo do produto.
3. Quando o produto for entregue, ser usado pelo
usurio para valida-lo (ver se est conforme os
requisitos).
Caractersticas do Documento de Especificao:
1. Linguagem de domnio do usurio;
2. Preciso;
3. Completo;
4. Consistente;
5. Sem redundncias;
6. Sem ambigidades.
Por exemplo:
O sistema deve ser preciso. (qual o significado de
preciso nesse contexto ?)
(Doc.de Especificao):
Requisitos Funcionais:
O que o produtos de software deve fazer
(funcionalidade).
Requisitos No Funcionais:
1. Confiabilidade Disponibilidade
Integridade
Segurana
(Doc.de Especificao):
Requisitos No Funcionais (cont.):
2. Acurcia dos resultados (exatido).
3. Desempenho
4. Problemas da interface homem-mquina
5. Restries fsicas e operacionais
6. Portabilidade
7. Etc.
Aplicar os 5 Princpios da Engenharia de Software,
especialmente: Abstrao, Decomposio e
Generalizao.
Abstrao: Fixar-se nos aspectos importantes,
ignorando os detalhes.
Decomposio: Dividir em partes para lidar com a
complexidade.
Generalizao: Buscar caractersticas comuns
relegando as caractersticas especficas ( uma forma
de abstrao).
No usamos: Formalidade e Flexibilizao.
Anlise de Requisitos:
Foco:
Nos objetivos, restries e alternativas.
Ferramentas:
Metodologias/tcnicas de modelagem e anlise,
ferramentas (editores grficos, CASEs etc).
Anlise de Requisitos:
Obter uma compreenso completa dos requisitos de
software, atravs de:
Definio detalhada do domnio das informaes e do
domnio da funcionalidade requerida para o software.

O desenvolvedor deve definir as estruturas de dados,
conhecendo cada uma delas (tipo, tamanho, volume,
consistncias, inter-relao, se disponvel em bases de
dados, forma de coleta etc).
Tambm deve definir detalhes da funcionalidade
(detalhes de como o sistema deve se comportar, tanto
em funcionalidade como em performance, segurana
etc.)
Projeto de Software:
Foco:
Nos dados, componentes de software e no produto
final de software.
Ferramentas:
Metodologias/tcnicas de modelagem e anlise,
ferramentas (editores grficos, ferramentas CASE etc).
Representao das funes do sistema, em uma forma
que possa ser transformada em programas
executveis.
Decompor o produto de software desejado em partes
(programas, mdulos, componentes etc).
Recompor, pensando no produto final (monoltico)
Criar documento de especificao de cada parte do
produto:
O que ela deve fazer (entradas, comportamento,
sadas).
Definir a relao entre componentes
Relao entre componentes:
Forte coeso (interna)
Fraco acoplamento (externo)
Projeto Preliminar:
Transformao dos requisitos numa arquitetura de
dados e de funcionalidade.
Projeto Detalhado:
Refinamento das representaes estruturais, obtendo-
se assim representaes detalhada dos algoritmos
(nos casos em que for necessrio) e dos dados.
Detalhe: O ciclo de vida clssico tem um foco
acentuado no produto de software e no o processo,
portanto est faltando um projeto operacional,
visando detalhes do processo de construo (esforos,
responsabilidades, milestones, etc).
Codificao:
Foco:
Nos algoritmos e nas linguagens de programao
(sintaxe, limitaes, funcionalidade disponvel,
Ferramentas:
Linguagens de programao, geradores de cdigo
fonte, CASE de amplo espectro etc.
Teste:
Foco:
Nas especificaes e nas sadas do produto de
software.
Ferramentas:
Tcnicas de testagem, procedimentos da Qualidade,
ferramentas de testagem.
Testar contra especificaes de requisitos
Testar contra padres da instalao
Nomenclatura de campos, tabelas
Padres de interfaces
Padres de qualidade
Unitrio (cada unidade de software)
De Integrao do sistema (todos os omponentes, a
partir de uma estratgia de aglutinao progressiva).
De integrao entre sistemas (sistema gerado com
outros sistemas com os quais haver troca de
informaes).
Elementos necessrios:
Padres da instalao e Def. Requisitos
Ferramentas de teste
Plano de teste
Critrios de teste
Critrios de completude (quando parar ?)
Gerenciamento dos casos de teste
Recomendao IEEE (Computer Dictionary). No usar
o termo bug; usar:
Defeito (Fault)
Instruo ou definio incorreta.
Falha (Failure)
Resultados incorretos
Erro (Mistake)
Falha resultante de ao humana
Testes especiais:
Performance
Segurana
Stress etc
Teste na rea de produo:
Teste inicial (alfa)
Beta teste
(Operao e) Manuteno:
Foco:
Depende do tipo de manuteno (algoritmo, usurio,
processo, tecnologia etc)
Ferramentas:
Linguagens de programao, ferramentas CASE etc . A
rigor deveria ser o mesmo foco e as mesmas
ferramentas da fase de Definio de Requisitos (volta
s origens).
Fase mais longa do ciclo.
Tipos de manuteno:
Corrigir erros remanescentes
Adaptar a novas situaes e necessidades
Preparar para futuras alteraes
Implantao:
Transferir da rea de desenvolvimento para a rea de
produo.
Preparar rea de rede (grupo, usurios, diretrios,
direitos)
Converso de arquivos ou
Gerao dos arquivos (caso Biblioteca)
Treinamento dos usurios
Integrar tecnologias
Falhas do modelo:
Todo modelo tem suas limitaes (abstrao, esttico,
foco (viso) do modelo, etc.

1) Imagina o processo como sendo seqencial e
progressivo, onde cada fase estanque, mesmo com as
setas indicando retorno a fases anteriores,cada fase
vista isoladamente. Tenta manter a linearidade para
manter o processo previsvel e de fcil gerenciamento.
2) A fase de Anlise s se inicia aps obteno dos
requisitos, que devem ser:
Completos
Corretos
No ambguos
No redundantes
Sem detalhes de implementao
Quando isso possvel ?
3) No estimula o desenvolvimento conjunto. O
trabalho com o usurio est restrito fase de Definio
de Requisitos.

4) A entrega do produto s ocorre depois de
terminado. Quando o usurio tem a chance de ver se o
produto atende suas necessidades e expectativa, ele j
est pronto.
5) No prev um Estudo de Viabilidade, que deveria
iniciar ao trmino da Definio de Requisitos e, no
mximo prolongar-se at o incio da Anlise.

Sua finalidade evitar que recursos sejam gastos na
tentativa de solucionar o problema de maneira errada,
alm de verificar se a soluo vivel do ponto de vista
econmico (investimos poucos recursos para termos
certeza de que o projeto vivel, evitando perder
muitos recursos)
O Estudo de Viabilidade dever avaliar:
Se o problema passvel de soluo via software
As possveis solues (desenvolver, comprar)
Estudo de custos x benefcios
Deve conter:
Definio do problema
Possveis solues (inclusive alternativas)
Benefcio de cada uma delas
Recursos necessrios, custo e prazo de cada uma delas
O Estudo de Viabilidade dever avaliar:
Se o problema passvel de soluo via software
As possveis solues (desenvolver, comprar)
Estudo de custos x benefcios
No Estudo de Viabilidades investimos poucos recursos
para termos certeza de que o projeto vivel, evitando
perder muitos recursos.
6) No menciona o Gerenciamento do Processo de
Software, que ocorre simultaneamente a construo do
produto e altamente influenciado pela complexidade
deste ltimo.
7) No permite Engenharia Reversa (reconstruo
de sistema legados).
Gerenciar o processo:
Objetivo: Controlar o processo.
1. Adaptar o modelo de gerenciamento do processo ao
tipo de ciclo de vida e tipo de produto.
2. Definir Polticas (autorizao de acessos, perodos
de backup, responsabilidades, documentao
obrigatria etc).
3. Obter recursos
4. Gerenciar recursos
5. Corrigir desvios do projeto e monitorar prazos e
custos.
Na prtica:
Presses sobre o tempo
Receber ordens para fazer (mandatrio)
DSI fazendo poltica de boa vizinhana
Diretoria fazendo poltica de boa vizinhana
O desenvolvimento j estava previsto em P.D.I.
Referncias
Modelos de Ciclos de Vida de Software .1 Modelo em
Cascata. Prof. Cristiano R R Portella

5 EngSoftware CicloVida Cascata

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

5 EngSoftware CicloVida Cascata

Enviado por

Direitos autorais:

Formatos disponíveis

Ciclos de Vida de Software

O conceito de Ciclo de Vida de Software um

Você também pode gostar