Modelos de Ciclo de Vida - José Malcher Jr.

Modelo de Maturidade de Software – Modelos de Ciclo de Vida

Ciclo de vida de software

Por que precisamos utilizar um modelo de ciclo de vida para desenvolver software?

Porque ele define a estrutura e a filosofia utilizadas obrigatoriamente em um processo de desenvolvimento de software. Um modelo de ciclo de vida define também as diferentes fases na existência deste produto, além de determinar também os princípios e diretrizes que guiarão a realização destas fases. Precisamos entender também que a adoção de um ciclo de vida não é suficiente para guiar e controlar um projeto de software na prática.

As seguintes características devem ser levadas em consideração durante a vida de um produto de software:

Organização das atividades do processo;
Recursos humanos, hardware e software;
Procedimentos de operação;
Políticas de desenvolvimento e restrições;
Tipos de software.

Ou seja, precisamos conhecer bem a equipe de desenvolvimento e entender quais são as suas habilidades e quais as ferramentas disponíveis na organização, dentre outras características.

Com essas informações, podemos definir o melhor ciclo de vida a ser utilizado no desenvolvimento de um software, pois não existe um melhor ciclo de vida a ser utilizado. Precisamos conhecer bem as características do projeto a ser desenvolvido para escolher ciclo de vida mais adequado para esse projeto.

Um ciclo de vida possui algumas características básicas que são comuns a todos os modelos, tais como:

Descrever as principais fases do desenvolvimento;
Definir as principais atividades a serem realizadas durante cada uma das fases;
Especificar os produtos de cada uma das fases, além dos insumos necessários para o início delas;
Fornecer um framework sobre o qual as atividades necessárias podem ser mapeadas.

Principais modelos de ciclo de vida de software

Existem vários modelos de ciclo de vida disponíveis no mercado; entretanto, vamos discutir os principais modelos utilizados nas organizações, que são: cascata, V, incremental, evolutivo, iterativo e incremental.

Vejamos cada um deles a seguir.

Modelo cascata

Modelo mais antigo e o mais amplamente usado na engenharia de software, modelado em função do ciclo da engenharia convencional. Também conhecido como modelo clássico ou sequencial linear.

Ele requer uma abordagem sistemática e sequencial ao desenvolvimento de software, sendo adequado em situações nas quais os requisitos são bem entendidos, e o gerente do projeto confia na capacidade da equipe de desenvolver utilizando o processo.

A ideia da cascata nasceu das etapas que possuem este formato, sendo executadas sequencialmente e podendo retornar a uma etapa anterior. Entretanto, o retorno a uma etapa anterior deve ser muito bem analisado quanto à sua viabilidade financeira e técnica.

Esse modelo apresenta as seguintes vantagens:

A fase única de requisitos leva à especificação antes do projeto e ao projeto antes da codificação;
O uso de revisões ao fim de cada fase permite o envolvimento do usuário;
O modelo permite que se imponha um controle de configuração;
Cada passo serve como uma base aprovada e documentada para o passo seguinte.

E possui as seguintes desvantagens:

O fluxo sequencial que o modelo propõe geralmente não é seguido em projetos reais;
Requisitos devem ser estabelecidos de maneira completa, correta e clara no início de um projeto;
Difícil avaliar o progresso verdadeiro do projeto durante as primeiras fases;
Uma versão executável do software só fica disponível numa etapa avançada do desenvolvimento;
Ao final do projeto, é necessário um grande esforço de integração e testes.

Modelo V

Assim como o modelo cascata, o modelo V é sequencial; isto significa que cada fase precisa ser completada antes que a próxima se inicie. Os testes são muito mais enfatizados nesse modelo do que no modelo cascata. Os procedimentos de teste são desenvolvidos desde cedo no ciclo de vida, antes da implementação.

Esse modelo apresenta as seguintes vantagens:

Menor custo e menos tempo são necessários para a entrega da primeira versão;
Riscos associados ao desenvolvimento de incrementos são menores devido ao seu tamanho reduzido;
Número de mudanças nos requisitos pode diminuir devido ao curto tempo de desenvolvimento da primeira versão.

E possui as seguintes desvantagens:

Se os requisitos não são tão estáveis ou completos quanto se esperava, alguns incrementos podem ser retirados de uso e retrabalhados;
O gerenciamento de custo, cronograma e configuração são mais complexos.

Modelo incremental

Neste modelo, as necessidades do usuário são segmentadas em uma série incremental de produtos. O processo se repete até que um produto completo seja produzido, e a segmentação das necessidades é realizada antes do desenvolvimento da primeira versão. A ideia desse modelo condiz com o propósito de aumentar pouco a pouco o software.

O modelo incremental deve ser adotado quando os requisitos são conhecidos no início do desenvolvimento e há a necessidade de entrega de um produto funcional em pouco tempo. Deve notar que, a cada incremento, é produzida uma versão operacional do software.

Esse modelo apresenta as seguintes vantagens:

Menor custo e menos tempo são necessários para a entrega da primeira versão;
Riscos associados ao desenvolvimento de incrementos são menores devido ao seu tamanho reduzido;
Número de mudanças nos requisitos pode diminuir devido ao curto tempo de desenvolvimento da primeira versão.

E possui as seguintes desvantagens:

Se os requisitos não são tão estáveis ou completos quanto se esperava, alguns incrementos podem ser retirados de uso e retrabalhados;
O gerenciamento de custo, cronograma e configuração são mais complexos.

Modelo evolutivo

Neste modelo, as versões parciais são desenvolvidas para atender aos requisitos conhecidos inicialmente. A primeira versão é usada para refinar os requisitos para uma segunda versão e, a partir do conhecimento sobre os requisitos obtido com o uso, continua-se o desenvolvimento, evoluindo o produto.

Esse modelo apresenta as seguintes vantagens:

É adequado quando os requisitos não podem ser completamente especificados no início do desenvolvimento;
O uso do sistema pode aumentar o conhecimento sobre o produto e, consequentemente, melhorar os requisitos.

E possui as seguintes desvantagens:

Necessária uma forte gerência de custo, cronograma e configuração;
Usuários podem não entender a natureza da abordagem e se decepcionarem quando os resultados não são satisfatórios.

Modelo iterativo e incremental

O fundamento deste modelo é dividir o desenvolvimento do software em pequenos ciclos, considerando um pequeno conjunto de necessidades do cliente final para que estes ciclos sejam executados.

Os ciclos dizem respeito a pequenos modelos cascatas que são executados para contemplar as necessidades do usuário. Dessa forma, precisamos dividir as necessidades dos clientes finais em partes e definir um grau de importância para cada uma delas.

Modelos de ciclo de vida mais utilizados

Nesta parte do curso, discutiremos mais alguns modelos de ciclo de vida que são muito utilizados no mercado, que são: RAD (Rapid Application Development), prototipação, espiral e RUP (Rational Unified Process).

Entenda cada um deles a seguir!

Modelo RAD

O modelo RAD (Rapid Application Development) é sequencial linear que enfatiza o desenvolvimento rápido de um software. Essa “alta velocidade” é conseguida através de uma abordagem de construção baseada em várias equipes que trabalham paralelamente enquanto o produto é dividido em módulos. Geralmente, um projeto de software que utiliza RAD tem duração de 60 a 90 dias.

Ele pode ser utilizado quando os requisitos são bem definidos e estão estabilizados, o escopo do sistema é restrito, e a aplicação pode ser modularizada.

Necessita de recursos humanos capacitados e comprometidos, suficientes para todas as equipes. A equipe deve utilizar componentes no desenvolvimento do software.

Esse modelo apresenta as seguintes vantagens:

O ciclo de desenvolvimento é extremamente curto;
Maior distribuição de tarefas entre as equipes.

E possui as seguintes desvantagens:

Requer recursos humanos suficientes para criar um número adequado de equipes em projetos grandes e escaláveis;
Requer um comprometimento entre desenvolvedores e clientes;
Não é apropriado quando os riscos são grandes;
Não é apropriado quando o sistema precisa interagir com outros sistemas.

Prototipação

Um protótipo é uma versão preliminar do produto final, o software. É uma técnica que deve ser utilizada para explorar (elicitar) as necessidades do cliente final, principalmente quando eles são vagos ou indefinidos. Os usuários podem fazer experiências com o protótipo, conhecendo mais sobre o software que será disponibilizado futuramente.

É uma versão inicial de um software que pode ser utilizado para determinar a viabilidade técnica, de custo e de cronograma de um projeto.

Deve haver uma forte interação com o usuário para que as suas necessidades sejam rapidamente projetadas e implementadas na construção e validação do protótipo, de acordo com etapas descritas na figura seguinte.

Ele possui as seguintes vantagens:

Um protótipo deve ser submetido a uma avaliação, geralmente feita pelo cliente;
O fato de o cliente poder interagir com um protótipo ajuda a cristalizar suas necessidades funcionais e de desempenho;
Os desenvolvedores podem implementar os requisitos baseado no feedback do usuário.

E apresenta os seguintes riscos na sua utilização:

Clientes imaginam que a maior parte do trabalho já foi feita;
Protótipo pode crescer de maneira não planejada, tornando-se um incremento funcional;
Protótipo pode ter um desempenho melhor do que um incremento funcional, pois não implementa toda a funcionalidade, causando frustração aos clientes quando o sistema completo é entregue.

Modelo espiral

Esse modelo possui as melhores características do ciclo de vida clássico e da prototipação, acrescentando um elemento muito importante: a análise de risco.

Além disso, assume que o desenvolvimento acontece em ciclos e possui as seguintes fases: planejamento, análise de riscos, engenharia e avaliação. Um software passa repetidamente por essas fases em iterações (chamadas espirais nesse modelo). A cada passagem na espiral, é realizada a análise de risco para avaliar a continuidade ou não do desenvolvimento do software.

Esse modelo apresenta as seguintes vantagens:

Muita análise de riscos;
Bom para o projeto grandes e críticos;
Software é produzido cedo no ciclo de vida.

E possui as seguintes desvantagens:

Pode ser custoso;
Análise de riscos requer experiência;
Análise de riscos requer experiência;
Não se aplica bem a projetos menores.

Rational Unified Process (RUP)

O RUP (Rational Unified Process) é um processo proprietário de engenharia de software desenvolvido pela Rational Software, atualmente subsidiária da IBM, e possui um framework de processo que pode ser adaptado e estendido.

Ele usa o paradigma orientado a objetos, juntamente com a notação UML (Unified Modeling Language) para a documentação do software.

Esse modelo está organizado em disciplinas, nas quais são distribuídas tarefas e responsabilidades para que sejam gerados produtos de software de cada uma destas tarefas, conhecidas como artefatos de software.

O ciclo de vida é dividido em fases sequenciais, as quais, por sua vez, são divididas em iterações, que são planejadas em número, duração e objetivos, como pode ser observado na figura.

As etapas do modelo são descritas abaixo:

Concepção:

Entender os requisitos gerais e determinar o escopo do esforço de desenvolvimento.

Elaboração:

Planejar as atividades e recursos necessários e especificar as características e projeto da arquitetura.

Construção:

Construir o produto e evoluir a visão, arquitetura e planos até que o material esteja pronto para entrega.

Transição:

Garantir que o sistema tenha o nível correto de qualidade para atingir os objetivos, além de realizar correções, treinamento de usuários, ajustes e adição de elementos que estavam faltando. Posteriormente, o produto final é produzido e entregue.

Esse modelo possui as seguintes vantagens:

Permite e encoraja o feedback do usuário, elicitando os requisitos reais do sistema;
Inconsistências entre requisitos, projeto e implementação podem ser detectados rapidamente;
Divisão da carga de trabalho por todo o ciclo de vida;
Compartilhamento de lições aprendidas, melhorando continuamente o processo;
Evidências concretas do andamento do projeto podem ser oferecidas durante todo o ciclo de vida.

Referências

PRESSMAN, Roger S. Engenharia de Software: Uma Abordagem Profissional. 7ª Edição. São Paulo: McGraw-Hill Brasil, 2011.

SOMMERVILLE, Ian. Engenharia de Software. 9ª Edição. São Paulo: Pearson (Livros Universitários), 2011.

PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prática. 2ª Edição. São Paulo: Pearson (Livros Universitários), 2003.

Lista de Exercícios de Modelo de Maturidade de Software – Lista 3

Deixe um comentário Cancelar resposta

Este site utiliza o Akismet para reduzir spam. Saiba como seus dados em comentários são processados.