Organizações de software em todo o mundo empregam perto de 7 milhões de técnicos e geram anualmente uma receita de mais de 600 bilhões de dólares, com taxa de crescimento anual de mais de 25% nos últimos três anos. Metade desta receita é gerada por pacotes de software de uso geral, como os ERPs e a outra metade com o desenvolvimento de produtos específicos para clientes. A indústria de software é vista atualmente como um dos segmentos mais promissores, com um enorme potencial futuro.

Se considerarmos o desenvolvimento de software como um projeto, então, o foco desta indústria está na execução de projetos. Assumindo que, em média, cada projeto consome 7 pessoas/ano de esforço, então, a indústria de software, com seus 7 milhões de técnicos, executam algo em torno de 1 milhão de projetos por ano. Logo, desenvolver projetos de software eficientes é de fundamental importância para a indústria de software como um todo.

Os processos usados para desenvolver um projeto de software têm a maior importância na qualidade do software produzido e na produtividade alcançada pelo projeto. Por conseqüência, existe uma necessidade de evoluir os processos usados em uma organização para desenvolver projetos de software [Jalote 99].

Um projeto de desenvolvimento de software visa a construção de um produto de software que satisfaça as necessidades do cliente e seja desenvolvido e entregue dentro do custo e prazo especificado. Em outras palavras, as três principais características de um projeto são: custo, planejamento e qualidade, onde qualidade representa quão bom o produto é e satisfaz o cliente.

Um projeto é um sucesso quando atinge ou excede as expectativas destas três características - custo, planejamento e qualidade. Porém, a indústria de software pode citar muitos exemplos de projetos que fracassaram. A situação vem melhorando com o passar dos anos mas ainda temos muitos projetos fracassando em termos de cronograma, custo e qualidade. Uma pesquisa utilizando dados de projetos [Putnam 97] mostra que 1/3 destes projetos tem custo e cronograma além de 125% da estimativa inicial. Exemplos de projetos que saíram do controle têm sido documentados [Glass 98].

As possíveis razões para falhas de projeto incluem estimativas impróprias, falta de gerenciamento de requisitos, fraco gerenciamento de projeto, gerenciamento de risco impróprio, pobres soluções de engenharia. Muitas destas razões podem ser combinadas em uma categoria chamada "falha do processo". Um projeto de software falha, muitas vezes, porque o processo seguido não é apropriado. As maiores razões para o descontrole são: objetivos pouco claros, planejamento ruim, utilização de novas tecnologias, falta de uma metodologia de gerenciamento do projeto e pessoal insuficiente [Glass 98]. Todas estas razões podem ser consideradas falha do processo. Para um projeto ter sucesso, um parâmetro chave é o conjunto de processos utilizados. Se processos apropriados são utilizados, as chances do projeto ter sucesso é extremamente alta.

Alta produtividade pode gerar redução de custo e minimizar o tempo do projeto. Qualidade e produtividade são as metas de toda a organização, porém, ainda existe um objetivo mais primordial das organizações. É a previsibilidade. Não é suficiente que um projeto tenha alta qualidade e produtividade. A organização também quer prever qual será a qualidade e produtividade atingida. Se você não consegue ter previsibilidade, é porque você não consegue realizar estimativas apropriadas e isto é o mesmo que caminhar no escuro. Você nunca sabe se está indo no caminho certo.

Como o processo tem o maior efeito sobre qualidade e produtividade, um modo de melhorar este par está na melhoria do processo usado pela organização. Este é o foco deste artigo. Mostrar como o CMM propõe às organizações focarem seus processos.

Área chave de processo do nível 3 do modelo CMM, chamado definido. Neste nível de maturidade é estabelecido um processo padrão da organização para desenvolvimento de projetos de software que inclui processos de gerenciamento e de engenharia de software. A partir deste processo padrão, adaptações necessárias a cada projeto são realizadas, derivando o processo de software definido que cada projeto, de forma individual, irá utilizar. Este processo definido, nada mais é do que processos de gerência de projeto e de engenharia de software, selecionados do processo padrão, para atender as características individuais dos projetos. Um processo é chamado definido quando possui entradas, padrões e procedimentos, mecanismos de verificação, saídas e critérios de aceitação, e é baseado em um entendimento comum das atividades, papéis e responsabilidades dos envolvidos no projeto de desenvolvimento de software. A capacitação deixa de ser uma habilidade das pessoas e passa a ser uma habilidade da organização [Fiorini 98].

A idéia básica da definição do processo da organização é desenvolver um conjunto de padrões tanto de atividades de gerência quanto de engenharia de software que possam ser utilizados por todos os projetos de software da organização, porém, flexíveis o bastante para possibilitar a sua adaptação às particularidades de cada projeto.

Cada elemento deste conjunto de padrões, o CMM chama de ativos do processo, os quais fazem parte da estrutura conceitual do processo de desenvolvimento de software, ilustrado pela figura 1.

Estes ativos do processo incluem:

• Arquitetura do Processo de Software: é uma descrição do processo de software padrão da organização, os elementos que o compõe e o inter-relacionamento entre estes elementos.

• Elemento do Processo de Software: é um componente do processo padrão e descreve um conjunto de atividades com forte relacionamento. Podem ser considerados como elementos o processo de estimativa de software, revisão, design, codificação, documentação...

• Ciclo de Vida do Software: deve prever os possíveis ciclos de vida utilizados pelos projetos da organização. O CMM cita o cascata, cascata estendido, espiral e outros [Sei 94]

• Diretrizes e Critérios para adaptação: asseguram a existência de uma base comum para todos os projetos de software e descrevem o que pode ou não ser adaptado do processo padrão para o processo definido

• Base de dados dos processos de software da organização: é uma base de dados utilizada para disponibilizar informações sobre os processos de software e os produtos (artefatos ou produtos intermediários) de software produzidos, tais como os dados de medições, estimativas, custo, número de defeitos, ...

• Biblioteca de documentação de processos de software: utilizada para armazenar documentos relacionados ao processo de software padrão da organização e permitir o compartilhamento destas informações por toda a organização. Pode conter exemplos de documentos, projetos de sucesso, padrões, procedimentos, planos,...

obs: sobre os dois últimos itens que tratam de disponibilização de informações, uma característica fundamental para o sucesso deste compartilhamento é a organização das informações. Se esta organização estiver inadequada, é provável que estas informações sejam muito pouco consultadas, e isto, implicará no insucesso da implantação do processo padrão.

Figura 1 - Estrutura conceitual do processo de software utilizado pelo CMM.

• Decomposição do processo de desenvolvimento de software em elementos fundamentais, de tal forma que estejam bem descritos e possam ser seguidos. Cada um destes elementos é composto de atividades bem definidas e inter-relacionadas.

• Descrição do relacionamento entre os elementos do processo, apontando a ordem de execução dos elementos,

• interface e a interdependência.

A partir da definição do processo padrão da organização, este é utilizado a cada novo projeto, para a geração do processo definido do projeto que é adaptado para abranger as características específicas do projeto. O plano de desenvolvimento de software deve ser feito a partir do processo definido do projeto e deverá descrever as atividades que serão executadas, implementadas e controladas. Esta adaptação do processo padrão até o plano de desenvolvimento de software ocorre de acordo com a figura 2.

As práticas básicas de estimativa, planejamento e acompanhamento de um projeto de software são baseadas em um processo que acumulou as melhores práticas de todos os projetos que foram adaptados do processo padrão, conduzindo cada novo projeto a uma chance maior de sucesso.

[Jalote 99] JALOTE, Pankaj. CMM in practice: processes for executing software projects at Infosys. USA: Addison Wesley, 1999.

[Glass 98] GLASS, R. L. Software runaways, lessons learned from massive software project failures. USA: Prentice Hall, 1998.

[Putnam 97] PUTNAM, L. H.; MYERSM, W. Industrial strength software - effective management using measurement. USA: IEEE Computer Society Press, 1997.

[Sei 94] PAULK, Mark. The capability maturity model - guidelines for improving the software process. USA: Addison Wesley, 1994.

[Fiorini 98] FIORINI, Soeli. Engenharia de software com CMM. Rio de Janeiro: Brasport Livros e Multimídia, 1998.

Figura 2 - Adaptação do processo.