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.

MPS.BR – Mitos e Verdades a Respeito de um Modelo de Maturidade

Ultimamente modelos de maturidade de software, como o MPS.BR (a denominação correta do modelo é MR_MPS, mas o nome do programa que lhe deu origem – MPS.BR – tem sido mais comumente utilizado para designá-lo) e o CMMI (Capability Maturity Model Integration) estão sendo questionados e criticados. Infelizmente, muitas dessas críticas são absolutamente equivocadas. Abaixo, alguns mitos sobre modelos de maturidade de software:

1º Mito – Modelos de Maturidade só se preocupam com processos. A competência das pessoas é desconsiderada.

Os modelos de maturidade de software valorizam bastante os processos. Mas esse fato, porém, não implica dizer que a competência das pessoas envolvidas nos processos é dispensada. Tanto no MPS.BR quanto no CMMI, há também resultados, práticas e objetos específicos que, para o sucesso do software, necessitam, sim, da competência e do conhecimento das pessoas que executarão as atividades.

2º Mito – Modelos de maturidade estão ressuscitando o taylorismo. Um grupo de pessoas completamente alheias à realidade de quem “põe a mão na massa” cria um bando de processos democráticos.

Qualquer iniciativa de melhoria de processo de software está condenada ao fracasso se os executores das atividades que estão sendo descritas no processo são alijados das discussões. Portanto, não há cabimento em se associar este tipo de comportamento ao modelo A, B ou C.

3º Mito – Scrum ou XP são preferíveis ao CMMI/MPS.BR porque usam uma abordagem iterativa e não cascata.

Não há definição de uso de um ciclo de vida de projeto específico nos modelos de maturidade. O que é necessário para que haja aderência aos modelos é a definição de qual ciclo de vida será utilizado para cada um dos projetos. Pode ser cascata, iterativo ou qualquer outro.

4º Mito – Dezoito meses é o tempo necessário para se avaliar com um sucesso uma empresa no nível G do MPS.BR.

Não há um tempo determinado para se implementar os processos de um nível. Esse tempo varia muito de empresa para empresa, pois depende de alguns fatores como, por exemplo, investimento direto no projeto de melhoria de processos. A instituição mantenedora do modelo, a Softex, tem apoiado financeiramente empresas que apresentem certos requisitos a cobrirem parte dos seus custos de consultoria. Entre eles está o compromisso de se realizar uma avaliação após 12 meses e não 18. Mas isto não quer dizer que o tempo seja este ou aquele. Este compromisso existe apenas para empresas que participam de algum grupo que recebe este apoio financeiro.

5º Mito – O MPS.BR é burocrático demais. Se eu for gerar todos os documentos que são solicitados pelo modelo, não tenho tempo para fazer o mais importante: software de qualidade.

O MPS.BR não obriga a geração de nenhum documento específico. O modelo apenas exige que algumas formalizações sejam realizadas. E isso não é mera burocracia. É importante, pois a obtenção de compromissos por parte de clientes e fornecedores, por exemplo, é muito mais segura se for formalizada. Seria muito difícil as pessoas lembrarem todas as mudanças feitas no projeto e que foram acordadas apenas oralmente.

O MPS.BR e o CMMI, apesar de este último ter mais reconhecimento internacional, estão sendo tratados de forma indistinta porque eles são completamente compatíveis. Há apenas algumas diferenças: Há alguns processos e, portanto, requisitos adicionais ao MPS.BR ligados às áreas de gestão do conhecimento e gerência de reuso; O MPS.BR apresenta maior flexibilidade na exclusão de processos a serem considerados na avaliação.

Agora serão citados e comentados alguns resultados esperados de alguns processos do modelo. A nível de esclarecimento, as siglas no início de cada resultado são abreviações dos nomes dos processos aos quais eles pertencem e o número representa a posição do resultado dentro do processo. Nos exemplos abaixo são citados resultados dos processos Gerência de Projetos (GPR), Gerência de Requisitos (GRE) e Medição (MED).

GPR 1. O escopo do trabalho para o projeto é definido;

É interessante se definir o escopo de um projeto. Mesmo que ele venha a mudar necessário algum nível de definição inicial deste escopo: para que a mudança seja possível é preciso saber o que se quer mudar.

GPR 6. Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados;

Como em um projeto sempre há um grau de novidade é fundamental que ocorra, em algum nível, o gerenciamento dos riscos, já que se os mesmos não forem devidamente tratados, a probabilidade de que algum deles ocorra e prejudique algum aspecto do projeto é muito grande. O MPS.BR deve identificar esses riscos, classificá-los em relação à sua probabilidade e impacto e priorizá-los em função destas características. A priorização é importante para que aquilo que é mais importante tenha um cuidado maior do que aquilo que potencialmente pode trazer menos danos ao projeto.

GPR 7. Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo;

É neste ponto em que as pessoas envolvidas no modelo são mais valorizadas. É de extrema importância que a alocação dos recursos humanos aos projetos não se dê por questões como disponibilidade, por exemplo. Cada papel ou função dentro de um projeto requer uma série de conhecimentos e habilidades e o não-atendimento destes “pré-requisitos” normalmente traz consigo uma série de problemas. Se um funcionário irá desempenhar determinada função, mas não tem capacitação para isso, deve-se pelo menos oferecer-lhe um treinamento. O que o modelo quer evitar é que uma pessoa com um déficit de conhecimento importante vá adquirindo este conhecimento de qualquer forma, o que prejudicaria a qualidade do software.

GPR 13. O progresso do projeto é monitorado com relação ao estabelecido no Plano de Projeto e os resultados são documentados;

Fazer um planejamento para o projeto é altamente recomendável. É necessário, porém, que seja exercido certo controle sobre esse planejamento, um monitoramento constante que avalie se o plano está de fato sendo concretizado ou se necessita de alguma ação de correção de rota. Muito dificilmente um plano não sofrerá mudanças, mas ele, junto ao monitoramento é importante para que essas mudanças não sejam feitas de forma desordenada. É interessante planejar de forma progressiva, isto é, detalhar o que está próximo do momento atual e planejar as etapas mais avançadas de forma mais genérica dado que é impossível detalhar o que não se conhece. A parte da documentação é importante, pois ajuda a orientar o que deve ser feito naquele projeto e, futuramente, poderá servirá como base para, por exemplo, se estimar um tempo de construção de um conjunto de requisitos de outros projetos semelhantes.

GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos;

Espera-se que os requisitos do projeto sejam entendidos, definidos e que tal definição tenha a participação de uma pessoa (ou mais pessoas) chamada fornecedor de requisitos, que foi eleita por outros stakeholders do projeto para ser aquele que diz o que o software deve fazer para quem irá desenvolvê-lo. Esses requisitos devem ser documentados para que seja possível entender o que se deve ser feito e se manter um monitoramento sobre eles, até mesmo quando eles sofrerão mudanças, já que é preciso saber e se ter um controle do que está sendo mudado.

MED 2. Um conjunto adequado de medidas, orientado pelos objetivos de medição, é identificado e/ou definido, priorizado, documentado, revisado e atualizado.

A empresa precisa se conhecer objetivamente para alcançar o sucesso. E medidas, bem entendidas, definidas, coletadas e analisadas são a base para este autoconhecimento. Devemos medir aquilo que é melhor para a empresa e tirar o melhor proveito destas medições. É importante que o processo operacional de medição esteja completamente alinhado com aquilo que a empresa precisa para melhorar sua gestão.

Enfim, modelos de maturidade não são garantia de sucesso absoluto para nenhuma empresa. São um guia de referência para a aplicação de boas práticas dentro das empresas que desenvolvem software, um caminho a ser seguido por empresas que desejam melhorar seu desempenho operacional de forma consistente ao longo do tempo.