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

07/09/2014 Your name here (insert->page number) 2

Introdução

● 1. Introdução

● 2. Ciclo de Vida

– 2.1 O que é Ciclo de vida do Software

– 2.2 Cascata

– 2.3 Prototipação

– 2.4 Espiral

– 2.5 Incremental

– 2.6 Rad

– 2.7 Modelo em V

● 3.Referencias

07/09/2014 Your 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.1 O que é 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.2 Cascata

O 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.3 Prototipação

O 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.4 Espiral

No 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.4 Espiral

Vantagens 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.5 Incremental

O 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.5 Incremental

2.6 RAD

Este 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.7 Modelo em V

O 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.Referência

• SOMMERVILLE, Ian, Engenharia Software. Addison Wesley. 8ª ed • PRESSMAN, Roger, Engenharia Software, McGraw-Hill. 6ª ed