O ciclo de vida de um "software (em inglês software lifecycle), designa todas as etapas do desenvolvimento de um software, da sua concepção ao seu desaparecimento. O objectivo de tal segmentação é definir balizas intermédias que permitem a validação do desenvolvimento do software, isto é, a conformidade do software com as necessidades exprimidas, e a verificação do processo de desenvolvimento, quer dizer, a adequação dos métodos aplicados.
A origem desta discriminação provém da constatação que os erros têm um custo ainda mais elevado quando são detectados tardiamente no processo de realização. O ciclo de vida permite detectar os erros o mais depressa possível e assim dominar a qualidade do software, os prazos da sua realização e os custos associados.
Geralmente, o ciclo de vida do software compreende, no mínimo, as actividades seguintes:
Definição dos objectivos, consistindo em definir a finalidade do projecto e a sua inscrição numa estratégia global.
Análise das necessidades e viabilidade, quer dizer a expressão, a recolha e a formalização das necessidades do requerente (o cliente) e do conjunto dos constrangimentos.
Concepção geral. Trata-se da elaboração das especificações da arquitectura geral do software.
Concepção detalhada, que consiste em definir precisamente cada subconjunto do software.
Codificação (Aplicação ou programação), quer dizer a tradução numa linguagem de programação das funcionalidades definidas aquando das fases de concepção.
Testes unitário, que permitem verificar individualmente que cada subconjunto do "software" é aplicado em conformidade com as especificações.
Integração, cujo objectivo é assegurar a intercomunicação dos diferentes elementos (módulos) do software. É objecto de testes de integração consignados num documento.
Qualificação (ou receita), isto é, a verificação da conformidade do software às especificações iniciais.
Documentação, destinada a produzir as informações necessárias para a utilização do software e para desenvolvimentos ulteriores.
Produção,
Manutenção, compreendendo todas as acções correctivas (manutenção correctiva) e evolutivas (manutenção evolutiva) no software.
MODELO CASCATA
O modelo clássico ou cascata, que também é conhecido por abordagem “top-down”, foi proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação geral. Esse modelo foi derivado de modelos de atividade de engenharia com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software. Comparado com outros modelos de desenvolvimento de software, este é mais rígido e menos administrativo.
O modelo cascata é um dos mais importantes modelos, e é referência para muitos outros modelos, servindo de base para muitos projetos modernos. A versão original deste modelo foi melhorada e retocada ao longo do tempo e continua sendo muito utilizado hoje em dia.
Grande parte do sucesso do modelo cascata está no facto dele ser orientado para documentação. No entanto deve salientar-se que a documentação abrange mais do que arquivo de texto, abrange representações gráficas ou mesmo simulação.
Uma abordagem incorporando processos, métodos e ferramentas deve ser utilizada pelos criadores de software. Esta abordagem é muitas vezes designada de Abordagem do Processo de Desenvolvimento. Existem três abordagens de modelos de processo de desenvolvimento de software. Elas tentem colocar ordem numa atividade inerentemente caótica.
MODELO INCREMENTAL
Barry Boehm sugeriu, tendo em vista as limitações da abordagem tradicional, que o desenvolvimento de sistemas de informação poderia ser administrado numa série de incrementos. Assim, poderia haver uma série de ciclos de vida tradicionais para cada incremento.
O Modelo Incremental foi desenvolvido através da combinação entre os modelos linear e prototipação. O desenvolvimento é dividido em etapas, denominadas “incrementos”, que produzirão incrementalmente o sistema, até a sua versão final.
Em cada incremento é realizado todo o ciclo do desenvolvimento de software, do planejamento aos testes do sistema já em funcionamento. Cada etapa produz um sistema totalmente funcional, apesar de ainda não cobrir todos os requisitos.
O Modelo Incremental apresenta diversas vantagens para o desenvolvimento de um software, especialmente se os requisitos não estão claros inicialmente. Por exemplo: quando o Modelo Incremental é utilizado, o primeiro incremento é normalmente constituído do núcleo do sistema. Isto é, os requisitos básicos são implementados, e os detalhes suprimidos. Esse produto será entregue para uma avaliação, que poderá detectar, inicialmente, problemas que poderiam ser de dimensões muito maiores se detectados somente na entrega do produto final.
Outra vantagem para o desenvolvedor é que, em contato com o sistema, o cliente esclarece seus requisitos e suas prioridades para os próximos incrementos, além de contar com os serviços da versão já produzida.
MODELO ESPIRAL
Este modelo baseia-se em quatro principais atividades:
- Determinação dos objetivos, alternativas e restrições;
- Análise de risco e prototipação;
- Validação e verificação;
- Planejamento da fase seguinte.
Problemas do Modelo espiral:
- O modelo em espiral, por suas características de avaliação e planejamento baseadas em risco, exige que se tenha gerentes e técnicos experientes.
- As tarefas gerenciais para acompanhamento e controle do projeto tornam-se mais difíceis, uma vez que o modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado. É necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.
MODELO DE PROTOTIPAGEM
Baseado no desenvolvimento de um protótipo com base no conhecimento dos requisitos iniciais para o sistema. O desenvolvimento é feito obedecendo à realização das diferentes etapas de análise de requisitos, o projeto, a codificação e os testes. Não necessariamente estas etapas devem ser realizadas de modo muito explícito ou formal
A definição de todos os requisitos necessários ao sistema pelo cliente ou usuário geralmente é uma tarefa muito difícil. É quase impossível prever como o sistema irá afetar o funcionamento das práticas de trabalho, como será a interação com outros sistemas e que operações dos usuários devem ser automatizadas. Mas para poder testar os requisitos de uma forma mais eficiente, seria necessária a utilização de um protótipo do sistema.
Um protótipo é uma versão inicial de um sistema de software, que é utilizada para mostrar conceitos, experimentar opções de projeto e, em geral, para conhecer mais sobre os problemas e suas possíveis soluções. O desenvolvimento rápido de um protótipo é essencial para que os custos sejam controlados e os usuários possam fazer experiências com o protótipo no início do processo de software.
Vantagens da prototipação:
- modelo de desenvolvimento interessante para alguns sistemas de grande porte que representem um certo grau de dificuldade para exprimir rigorosamente os requisitos
- é possível demonstrar a realizabilidade através da construção de um protótipo do sistema
- é possível obter uma versão, mesmo simplificada do que será o sistema, com um pequeno investimento inicial
- A experiência adquirida no desenvolvimento do protótipo vai ser de extrema utilidade nas etapas posteriores do desenvolvimento do sistema real, permitindo reduzir o seu custo e resultando num sistema melhor concebido
- Quando informamos que o produto precisa ser reconstruído, o cliente exige que alguns acertos sejam aplicados para tornar o protótipo um produto; muito freqüentemente, a gerência de desenvolvimento de software cede.
- O desenvolvedor muitas vezes faz concessões de implementação a fim de colocar um protótipo em funcionamento rapidamente. Depois de algum tempo, o desenvolvedor pode familiarizar-se com essas opções e esquecer-se de todas as razões pelas quais elas são inadequadas - a opção menos ideal se tornou então parte integrante do sistema.
Nenhum comentário:
Postar um comentário