conteúdo ciclo de vida do software.

1. Ciclo de vidade Software
FaculdadeJK de Tecnlologia
Departamentode Tecnologiada Informação
TADS–Processode Desenvolvimento de Software (PDS)
ProfessorGeorge Henrique R. E. Mendonça
Eduardo Inez Cesario,NivaldoSantos, Marcelo
17/09/14

2. 17/09/20
14
Your name here (insert->page number) 2
1.Introdução
●1. Introdução
–2. O que é Ciclo de vidado Software
–2.1 Cascata
–2.2 Prototipação
–2.3 Espiral
–2.4 Incremental
–2.5 Rad
–2.6 Modelo emV
●3.Referencias

3. 17/09/20
14
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.

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

5. 2.1 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.

6. 2.2 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 htmlou 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.

7. 2.3 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 replanejandoo processo

8. 2.3 Espiral
VantagensPor 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.

9. 2.4 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.

10. 2.4 Incremental

11. 2.5 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.

12. 2.6 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.

13. 3.Referencia
• SOMMERVILLE, Ian, Engenharia Software. AddisonWesley. 8ª ed
• PRESSMAN, Roger, Engenharia Software, McGraw-Hill. 6ª ed