Ciclo de vida de Software

Faculdade JK de Tecnlologia

Departamento de Tecnologia da Informação

TADS – Processo de Desenvolvimento de Software (PDS)

Professor George Henrique R. E. Mendonça

Eduardo Inez Cesario,Nivaldo Santos, Marcelo

17/09/14

17/09/20

14Your name here (insert->page number) 2

1.Introdução● 1. Introdução

– 2. O que é Ciclo de vida do Software

– 2.1 Cascata

– 2.2 Prototipação

– 2.3 Espiral

– 2.4 Incremental

– 2.5 Rad

– 2.6 Modelo em V

● 3.Referencias

17/09/20

14Your name here (insert->page number) 3

1. Introdução

Qualificar um produto é muito bom para que tenhamos

certeza de que há seriedade e preocupação com a satisfação

em tê-lo, mas, qualificar o processo de produção é mais

importante para obter um produto melhor. Ambas as

qualificações da produção e do produto são largamente

utilizados na produção de muitos produtos, inclusive no

desenvolvimento de softwares. Hoje, temos normas da ISO

9003 que certificam o processo de produção de software

bem como o software pronto. Tais normas exigem cada vez

mais qualidade no gerenciamento do projeto e tais

exigências são convertidas em benefícios para os usuários e

desenvolvedores.

● Todo desenvolvimento de um software é caracterizado

por fases que quando colocados em sequência obtêm-se um

Ciclo de Vida do Sistema e é este ciclo de vida que deve ter

qualidade.

2. Oque é Ciclo de vida de Software?

Todo o ser humano tem fases ou etapas de sua vida, ate que

venha morrer. Assim também é a vida de um Software, saber

quais foram os processos que ele teve que passar ate esta

totalmente pronto.

Passando por alguns modelos de implementação como:

• Cascata

• Espiral

• Rad

• Modelo em V

• Incremetal

• Prototipagem

Em resumo ,ciclo de vida são as etapas pelo qual o

software passa antes de esta pronto.

2.1 CascataO modelo Cascata é um modelo de engenharia

projetado para ser aplicado no desenvolvimento do

software. A ideia principal que o dirige é que as

diferentes etapas de desenvolvimento seguem uma

sequência:

a saída da primeira etapa “fluí” para a segunda etapa

e a saída da segunda etapa “fluí” para a terceira e assim

por diante. As atividades a executar são agrupadas em

tarefas, executadas sequencialmente, de forma que uma

tarefa só poderá ter início quando a anterior tiver

terminado.

2.2 PrototipaçãoO ciclo de vida denominado Prototipação aborda basicamente uma visão evolutiva

do desenvolvimento de software, afetando o processo como um todo. Esta abordagem

envolve a produção de versões iniciais - protótipos (análogo a maquetes para a

arquitetura) - de um sistema futuro com o qual pode-se realizar verificações e

experimentações para se avaliar algumas de suas qualidades antes que o sistema venha

realmente a ser construído.

IMPORTANTE: O protótipo criado mostra apenas o sistema em âmbito visual, feita

em html ou outra linguagem visual, Apenas para a visualização por parte do cliente. Não é

implementado o código para a resolução das situações que ele enfrentará no seu

cotidiano.

PRINCIPAL BENEFÍCIO: Impede que após todo o projeto criado, o cliente fique

insatisfeito, pois o mesmo participou "teoricamente" da criação desse projeto.

DESVANTAGEM: A documentação...

A documentação torna-se mais difícil, pois depois da análise de requisitos, parte-se de

imediato para a implementação do projeto, não sendo feita uma análise de risco e

viabilidade do projeto.

POR QUE A ESCOLHA DESTE CICLO...

Nós achamos que com esse ciclo de vida, a participação do cliente na criação de cada fase

do projeto, evita chances de erro e principalmente de insatisfação após ele (projeto)

criado.

2.3 EspiralNo 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

2.3 EspiralVantagens

Por ser incremental podem ser adicionadas novas funcionalidades em cada nova

versão;

Praticamente não existe distinção entre desenvolvimento e pós-entrega;

Maior controle sobre os riscos do projeto, tornando o processo de construção de um

produto complexo mais seguro.

Desvantagens:

Modelo destina-se exclusivamente a desenvolvimento de software interno;

A abordagem deste modelo exige grande experiência na avaliação dos riscos.

Pode ser difícil convencer grandes clientes de que a abordagem evolutiva é

controlável.

Uso

O modelo espiral é mais adequado para sistemas complexos e que exijam um alto nível

de interações com os usuários, a fim de possibilitar a abordagem de todos os problemas

desse sistema.

Usado com mais frequência em grandes projetos.

2.4 IncrementalO modelo de ciclo de vida incremental e iterativo foi proposto como uma

resposta aos problemas encontrados no modelo em cascata. Um processo de

desenvolvimento segundo essa abordagem divide o desenvolvimento de um produto de

software em ciclos. Em cada ciclo de desenvolvimento, podem ser identificadas as fases

de análise, projeto, implementação e testes. Essa característica contrasta com a

abordagem clássica, na qual as fases de análise, projeto, implementação e testes são

realizadas uma única vez.

Cada um dos ciclos considera um subconjunto de requisitos. Os requisitos são

desenvolvidos uma vez que sejam alocados a um ciclo de desenvolvimento. No próximo

ciclo, um outro subconjunto dos requisitos é considerado para ser desenvolvido, o que

produz um novo incremento do sistema que contém extensões e refinamentos sobre o

incremento anterior.

Assim, o desenvolvimento evolui em versões, através da construção incremental

e iterativa de novas funcionalidades até que o sistema completo esteja construído. Note

que apenas uma parte dos requisitos é considerada em cada ciclo de desenvolvimento. Na

verdade, um modelo de ciclo de vida iterativo e incremental pode ser visto como uma

generalização da abordagem em cascata: o software é desenvolvimento em incrementos e

cada incremento é desenvolvido em cascata.

A abordagem incremental e iterativa somente é possível se existir um mecanismo

para dividir os requisitos do sistema em partes, para que cada parte seja alocada a um

ciclo de desenvolvimento. Essa alocação é realizada em função do grau de importância

atribuído a cada requisito.

2.4 Incremental

2.5 RADEste modelo formalizado por James Martin em 1991, como uma

evolução da “prototipagem rápida”, destaca-se pelo desenvolvimento rápido

da aplicação. O ciclo de vida é extremamente

comprimido, de forma a encontrarem-se exemplos, na literatura, de duração

de 60 e 90 dias. É ideal para clientes buscando lançar soluções pioneiras no

mercado.

É um ciclo de vida incremental, iterativo, onde é preferível que os

requisitos tenham escopo restrito. A diferença principal do ciclo anterior é o

forte paralelismo das atividades, requerendo, assim, módulos bastante

independentes. Aqui os incrementos são desenvolvidos ao mesmo tempo, por

equipes diferentes.

Além do paralelismo, a conquista do baixo tempo se dá graças à

compressão da fase de requisitos e da fase de implantação. Isso significa que,

na obtenção dos requisitos, costumam-se optar por metodologias mais

dinâmicas e rápidas, como workshops ao invés de entrevistas. Permite-se

também um desenvolvimento inicial no nível mais alto de abstração dos

requisitos visto o envolvimento maior do usuário e visibilidade mais cedo dos

protótipos.

2.6 Modelo em VO Modelo V é um modelo conceitual de gestão de projeto visto como

melhoria ao problema de reatividade do modelo em cascata. Ele permite, em caso de

anomalia, delimitar um retorno às etapas precedentes. As fases das partes acima

devem devolver as informações sobre elas, camada a camada, quando os padrões são

detectados, a fim de melhorar o programa.

O Modelo V virou um padrão da indústria de software depois de 1980 e, após

o surgimento da Engenharia de Sistemas, tornou-se um conceito padrão em todos os

domínios da indústria. O mundo do software tinha feito poucos avanços em termos de

maturidade, em achar na bibliografia corrente as referências que poderiam se aplicar

ao sistema.

3.Referencia• SOMMERVILLE, Ian, Engenharia Software. Addison Wesley. 8ª ed

• PRESSMAN, Roger, Engenharia Software, McGraw-Hill. 6ª ed