Modelos de Processo de Software

Modelo Sequencial Linear

O modelo seqüencial linear é um modelo de desenvolvimento de software que começa no nível de sistema e progride, de maneira seqüencial, através da análise, projeto, codificação, teste e manutenção. Modelado segundo um ciclo convencional de engenharia, o modelo seqüencial linear abrange as seguintes atividades:

Modelagem e engenharia do sistema/informação: O software sempre pertence a um sistema (ou negócio) maior. Em razão disso, o trabalho começa estabelecendo-se requisitos para todos os elementos do sistema e depois alocando-se alguns subconjuntos desses requisitos para o software. Esses requisitos atenderam tanto às necessidades a nível de sistema (engenharia e análise de sistemas) como às necessidades a nível estratégico e a nível da área de negócios (engenharia da informação).

Análise de requisitos de software: Nesse momento, há a definição dos requisitos do software. Ou seja, há uma preocupação com o software agora. Em como ele será construído, qual a sua função, desempenho, etc. Os requisitos do sistema e do software serão documentados e revistos com o cliente.

Projeto: O projeto de software é um processo de múltiplos passos que definirá a estrutura dos dados, a arquitetura do software, as representações da interface e detalhes procedimentais (algorítmicos). Isto é, são definidos os requisitos para uma representação do software, que pode ser avaliada quanto à qualidade antes que a codificação tenha início. O projeto também é documentado, tornando-se parte da configuração do software.

Geração de código: Aqui o projeto será traduzido para a linguagem de máquina.

Teste: Nesse processo testam-se todos os comandos do software e se conduz testes para descobrir erros e garantir que entradas definidas produzirão resultados reais e coerentes.

Manutenção: Depois de liberado para o cliente, o software passará por modificações seja para corrigir erros encontrados, para implantar melhoras funcionais ou de desempenho, ou para adaptar-se a mudanças no seu ambiente externo.

O modelo seqüencial linear é o mais antigo e é o paradigma para engenharia de software mais amplamente usado. Porém, algumas vezes em que esse modelo é aplicado, alguns problemas são encontrados:

1- Projetos reais raramente seguem o fluxo seqüencial que o modelo propõe. Fazer modificações podem causar confusão à medida que a equipe de projeto prosegue.

2- É difícil para o cliente estabelecer todos os requisitos explicitamente e o modelo seqüencial linear exige isso, além de ter dificuldade em acomodar a incerteza natural que existe no começo de vários projetos.

3- Nenhuma versão executável do programa fica disponível até o projeto terminar. O que é desvantajoso quando, por exemplo, um erro que seria simples, por ser detectado só no final, pode ter causado alguns desastres no programa.

4- Nesse modelo, alguns projetos podem passar por “estados bloqueios”, nos quais alguns membros da equipe de projeto precisam esperar que outros membros completem as tarefas pendentes.

Apesar desses pontos fracos, é melhor se desenvolver um software onde os processos são situados do que quando se tem uma abordagem aleatória.

Modelo de prototipagem

Nesse modelo de processo de software constrói-se um protótipo, um modelo executável de como será um software. Esse protótipo é construído de maneira rápida, não há preocupação com a sua qualidade, por exemplo. Dessa forma, esse protótipo deveria ser, em tese, descartado.

O paradigma de prototipagem começa com a definição de requisitos. O cliente e o desenvolvedor se encontram e definem os objetivos gerais do software, identificam as necessidades conhecidas e delineiam áreas que necessitam de mais definições. Um “projeto rápido” é então realizado. Esse projeto parte de um protótipo que é avaliado pelo cliente e usado para refinar os requisitos do software. O protótipo vai sendo ajustado para satisfazer às necessidades do usuário e orientar o desenvolvedor.

Os problemas desse modelo são:

1- O cliente vê o projeto executável e pede para o desenvolvedor fazer alguns ajustes e transformar o protótipo num produto executável, ignorando que aspectos como qualidade não foram considerados nesse modelo. Em geral, a gerência de desenvolvimento de software concorda.

2- Objetivando fazer um protótipo executável rapidamente, o desenvolvedor faz muitas concessões na implementação, como uma linguagem inapropriada por exemplo. Com o tempo, o desenvolvedor pode se familiarizar com essas escolhas, esquecendo de suas verdadeiras razões, e integrá-las ao sistema.

Mas se for acordado entre desenvolvedor e cliente que um protótipo será construído apenas como mecanismo para definição dos requisitos, a prototipagem pode ser bastante efetiva.

Modelo RAD

O desenvolvimento rápido de aplicação (rapid application development, RAD) é um modelo de processo de desenvolvimento de software incremental que enfatiza um ciclo de vida extremamente curto. O modelo RAD é uma adaptação muito mais rápida do modelo seqüencial linear. Rapidez essa conseguida a partir do uso da construção baseada em componentes. É usado principalmente para aplicações de sistemas de informação e quando os requisitos são bem compreendidos e o objetivo do projeto é restrito. Tem as seguintes fases:

Modelagem do negócio: O fluxo de informação entre as funções dos negócios é modelado. Devem responder às seguintes questões: que informação dirige o processo do negócio? Que informação é gerada? Quem a gera? Para onde vai a informação? Quem a processa?

Modelagem dos dados: O fluxo de informação definido na modelagem dos negócios será agora refinado num conjunto de objetos de dados. As características (atributos) de cada objeto são identificadas e as relações entre eles, estabelecidas.

Modelagem do processo: Os objetos de dados serão transformados para se obter o fluxo de informação necessário para implementar uma função do negócio. São criadas descrições do processamento para manipular esses objetos.

Geração da aplicação: São utilizadas ferramentas automatizadas para facilitar a construção do software. Estas ferramentas permitirão o reuso de componentes de programas já existentes (quando possível) ou a criação de componentes reusáveis.

Teste e entrega: Devido ao reuso muitos componentes do programa já foram testados, o que reduz o tempo total de teste. Entretanto todo o resto deve ser testado.

As restrições de tempo impostas num projeto RAD podem ser medidas. É interessante usar o modelo RAD quando cada função principal da aplicação possa ser completada em menos de três meses. Cada função principal pode ser desenvolvida por uma equipe RAD diferente e depois integrada para formar um todo.

As desvantagens desse modelo se encontram nos fatos de:

· Mesmo que o projeto seja mensurável, se ele for grande o RAD exigirá recursos humanos suficientes para criar um número adequado de equipes RAD.

· O RAD requer um comprometimento entre desenvolvedores e clientes para que as atividades possam ser realizadas rapidamente e o sistema seja concluído em um tempo abreviado.

· Nem todos os tipos de aplicação são apropriados para o RAD como, por exemplo, se o sistema não puder ser adequadamente modularizado ou exigir ajustes nas interfaces dos componentes do sistema.

· Quando os riscos técnicos forem elevados o RAD não é adequado.

Modelos de Processos de Software Evolucionários

Os modelos evolucionários são utilizados quando os sistemas que serão desenvolvidos evoluirão com certo período de tempo. Eles são interativos e caracterizados de forma a permitir aos engenheiros de software desenvolver versões cada vez mais completas do software.

Os tipos de modelo evolucionário são: modelo incremental, modelo espiral, modelo espiral ganha-ganha e modelo de desenvolvimento concorrente.

O Modelo Incremental

Esse modelo combina aspectos do modelo seqüencial linear com a filosofia interativa da prototipagem.

Seqüencias lineares são aplicadas e, ao final, elas produzem um incremento. Este é uma versão já operacional, diferentemente do protótipo, do produto mas que não possui ainda todas as funcionalidades. Esse processo é repetido várias vezes, em cada uma delas se aplicando mais funcionalidades ao software (o primeiro incremento tem as características básicas do programa), até que o produto completo seja produzido.

É bastante vantajoso quando o prazo para a construção do software é pequeno ou não há pessoas suficientes para terminar o programa dentro do prazo ou quando o software completamente terminado necessitará, por exemplo, de um hardware novo que demorará a chegar: se produz alguns incrementos e manda para o cliente, depois finaliza-se o produto e o entrega totalmente pronto ao cliente.

Modelo espiral

Combina a natureza iterativa da prototipagem com os aspectos controlados e sistemáticos do modelo seqüencial linear. Fornece potencial para o desenvolvimento rápido de versões incrementais do software, onde os primeiros incrementos podem ser modelos de papel ou protótipos, mas já nas últimas iterações são produzidas versões incrementais cada vez mais completas.

Um modelo espiral é dividido em regiões de tarefas. Tipicamente, há de três a seis regiões de tarefas:

· Comunicação com o cliente – tarefas necessárias para estabelecer uma comunicação efetiva entre desenvolvedor e cliente.

· Planejamento – tarefas que definirão informações como recursos e prazos.

· Análise de risco – tarefas que analisarão os riscos técnicos e gerenciais.

· Engenharia – tarefas necessárias para construir representações da aplicação.

· Construção e liberação – tarefas necessárias para construir, testar, instalar e fornecer apoio ao usuário.

· Avaliação pelo cliente – tarefas necessárias para obter realimentação do cliente.

Cada uma das regiões é formada por um conjunto de tarefas que são adaptados às características do projeto a ser desenvolvido. Em todos os projetos, porém, são aplicadas as atividades guarda-chuva.

À medida que esse processo evolucionário é iniciado, a equipe de engenharia de software move-se em volta do espiral, no sentido horário, a partir do centro. Cada região de tarefas pode ter quantas passagens forem necessárias para a construção do software. Pode-se também, fazer passagens subseqüentes pela espiral para se desenvolver um protótipo e só depois versões realmente operacionais do software.

É vantajoso porque esse modelo não termina quando o software é entregue. Ao longo da vida do software ele pode retornar à espiral, mas não do início, do ponto de entrada adequado para o que se pretende fazer. O projeto pode também ser utilizado antes de completar toda a espiral, já que se pode fazer versões do software que irão sendo melhoradas quando for completando a espiral, o que permite, entre outras coisas, testes e correções antes do projeto, em sua totalidade, ser finalizado.

O modelo espiral exige a consideração direta dos riscos técnicos em todos os estágios. Isso acaba sendo um problema, pois é necessária uma competência considerável das equipes.

Outro problema desse modelo é que pode ser difícil convencer os clientes que a abordagem evolucionária é controlável.

O modelo espiral ganha-ganha

Como os clientes e os desenvolvedores têm uma relação “ganha-ganha”, onde o cliente faz concessões para que o software seja mais barato e produzido em menos tempo e o desenvolvedor aceita, já que assim ele trabalhará com orçamentos e prazos possíveis de ser cumpridos, o modelo espiral ganha-ganha define um conjunto de atividades de negociação no começo de cada passagem, em torno da espiral. Assim, ao invés de uma única atividade de comunicação com o cliente, as seguintes atividades são definidas:

1. Identificação dos principais “interessados” do sistema e do subsistema.

2. Determinação das “condições de lucro” do interessado.

3. Negociação das condições de ganho do interessado para reconciliá-las no âmbito das negociações ganha-ganha para todos os envolvidos (incluindo a equipe de projeto do software).

Esse modelo introduz marcos de processo, chamados pontos de ancoragem, que ajudam a estabelecer quando um ciclo é completado em torno da espiral e fornecem marcos de decisão antes do projeto prosseguir. São três: objetivos de ciclo de vida (define um conjunto de objetivos para cada atividade principal de engenharia de software), arquitetura do ciclo de vida (estabelece objetivos que precisam ser satisfeitos à medida que a arquitetura do sistema e do software é definida) e capacidade operacional inicial(representa um conjunto de objetivos associado com a preparação do software para instalação/distribuição, preparação do local antes da instalação e assistência requerida por todas as partes que irão usar ou dar suporte ao software).

Modelo de desenvolvimento concorrente

Um modelo de processo concorrente é conduzido por necessidades do usuário, decisões da gerência e resultados de re revisão. É representado como uma série de grandes atividades técnicas, tarefas e seus estados associados.

Todas as atividades existem concorrentemente, mas estão em diferentes estados. Por exemplo: Enquanto o desenvolvedor se comunica com o cliente, a atividade de análise está no estado “aguardando modificações”, quando essa comunicação termina, ela evolui para a fase “em desenvolvimento”. Assim, o modelo de processo concorrente define uma série de eventos que vão disparar transições de estado para estado, para cada uma das atividades de engenharia de software.

O modelo de processo concorrente é aplicável a todos os tipos de desenvolvimento de software e fornece um panorama preciso do estado atual de um projeto. Não segue uma seqüência de eventos, define uma rede de atividades, que transitarão de um estado a outro.

Desenvolvimento baseado em componentes

O modelo de desenvolvimento baseado em componentes compõe aplicações a partir de componentes de software previamente preparados: as classes. Esse modelo permite a criação de classes que encapsulam tanto os dados quanto os algoritmos usados para manipulá-los. Essas classes são armazenadas em uma biblioteca ou repositório de classes e podem ser reusáveis ao longo de diferentes aplicações e arquiteturas de sistemas baseados em computador.

A atividade de engenharia começa com a identificação das classes adequadas. Isso é conseguido pelo exame dos dados a serem manipulados pela aplicação e dos algoritmos a serem aplicados para efetuar manipulação. Os dados e os algoritmos correspondentes são empacotados em uma classe. Uma vez identificadas as classes adequadas, verifica-se se elas já existem na biblioteca. Se já existirem, elas serão extraídas e reusadas. Caso contrário, o desenvolvedor utilizará métodos orientados a objetos para criá-las. Então, é composta a primeira iteração da aplicação a ser construída, usando classes extraídas e criadas. O fluxo de processo volta então para a espiral e vai, em última análise, reingressar na iteração de montagem de componentes durante as passagens subseqüentes pela atividade de engenharia.

Por se utilizar o reuso, o modelo de desenvolvimento baseado em componentes apresenta uma redução de 70% no prazo do ciclo de desenvolvimento; uma redução de 84% no custo do projeto e um índice de produtividade relativamente alto. Mas ainda há algumas dúvidas a respeito das vantagens do reuso de componentes.

Modelo de métodos formais

Métodos formais permitem ao engenheiro de software especificar, desenvolver e verificar um sistema baseado em computador, pela aplicação de uma rigorosa notação matemática.

Esse modelo oferece a promessa de software livre de defeito, pois problemas como ambigüidade, inconclusão, e inconsistência que seriam difíceis de resolver através das revisões comuns, podem ser descobertos e corrigidos mais facilmente com aplicação de análise matemática. Além disso, métodos formais servem como base para a verificação do programa e assim permitem que o engenheiro de software descubra e corrija erros que poderiam passar despercebidos.

Mas nem tudo é perfeito, as desvantagens desse modelo são:

1. Atualmente esse modelo é muito lento e caro.

2. Como poucos desenvolvedores de software têm o preparo necessário para aplicar métodos formais, torna-se necessário um treinamento extensivo.

3. É difícil usar tais modelos como meio de comunicação com a maioria dos clientes.