Alguns leitores mandaram comentários sobre o artigo "Crise na Indústria de Software" de Maio de 2000 – volume 97, em que menciono o CMM como um modelo a ser seguido, mas não como a tábua de salvação de todos os problemas. Por este motivo, decidi escrever sobre o modelo CMM e mostrar meu posicionamento sobre o assunto.
Desenvolver software de qualidade assegurada, com elevada produtividade, dentro do prazo estabelecido e sem necessitar de mais recursos que os alocados, tem sido o grande desafio da Engenharia de Software. Segundo os idealizadores do CMM, a principal causa dos problemas é a falta de um processo de desenvolvimento de software claramente definido e efetivo. Conhecer os processos significa conhecer como os produtos e serviços são planejados, produzidos e entregues. Cabe ressaltar que, a partir da definição do processo, é possível definir-se medições e coletar dados de execução. Isto dá visibilidade aos gerentes e técnicos sobre o andamento dos projetos, possibilitando ações para controlar as variações do projeto e dos processos por ele utilizados. O CMM enfatiza a documentação dos processos, seguindo a premissa de que, para realizar alguma melhoria no processo é preciso primeiro conhecê-lo e entendê-lo, e que a qualidade de um produto é reflexo da qualidade e gerenciamento do processo utilizado em seu desenvolvimento.
O CMM – Capability Maturity Model for Software -, ou Modelo de Maturidade da Capacitação para Software, propõe um caminho gradual que leva as organizações a se aprimorarem continuamente na busca da sua própria solução dos problemas inerentes ao desenvolvimento sistemático de software. Este caminho gradual se apresenta no CMM através de 5 níveis de maturidade que inicia no nível 1, em que a improvisação rege o processo de desenvolvimento até o nível 5 cujo foco é a melhoria sistemática do processo. Cada nível possui áreas-chaves de processo, que visam atingir uma meta de melhoria do processo através de um conjunto de atividades realizadas para este fim (práticas chave).
É o que pode ser visto na figura abaixo [paulk 95]:
Figura 1.5 - Áreas - Chaves de Processo - ACPs - do CMM
[Paulk 95]
Na verdade, o CMM é uma estrutura que descreve os principais elementos de um processo de desenvolvimento de software [Fio 98], ou seja, descreve o que é necessário implementar mas não explicita como fazê-lo. Uma das ênfases do CMM é a definição do processo de software da organização, ou seja, aquilo que é realizado está documentado e de acordo com o processo padrão da organização. Este conceito de processo padrão da organização é a padronização na organização dos processos de gerenciamento de projeto e de engenharia de software. A ênfase na descrição de processo padrão se dá a partir do nível 3 do CMM. Este processo padrão da organização define todos os processos básicos e comuns aos projetos de software da organização. Todos os projetos, são adaptados do processo padrão da organização, para definir os processos que serão utilizados em cada projeto. Este conjunto de processos selecionados do processo padrão da organização para a execução de um projeto é conhecido como processo definido do projeto. A partir do momento em que uma organização estabelece o seu processo padrão de desenvolvimento de software, esta passa a desenvolver projetos de forma homogênea, facilitando o entendimento dos projetos por parte de todos os envolvidos. Este é um passo decisivo para uma organização, do ponto de vista dos modelos de qualidade. A partir deste ponto, deixa-se de trabalhar de forma amadora tomando seu lugar o enfoque profissional. Entre os principais ganhos de se estabelecer um processo padrão da organização, considero:
Entendimento comum dos envolvidos (técnicos e não técnicos), do processo e das atividades necessárias a realizar e dos papéis e responsabilidades de cada um no projeto;
Cada novo projeto é a consolidação do aprendizado anterior, pois as atividades a executar serão basicamente as mesmas;
Uma flexibilidade maior na movimentação de técnicos durante a execução do projeto devido a capacitação do processo ser da organização e não uma habilidade das pessoas. É claro que tirar uma pessoa de um projeto em andamento é sempre difícil, pelo conhecimento do negócio que a mesma adquiriu. Porém, sem um processo definido e documentado, a remoção, bem como a inserção de um técnico no projeto, é praticamente impossível. Geralmente, esta é a primeira idéia de coordenadores e gerentes quando sinais de atraso se tornam evidentes em um projeto, que, muitas vezes, não pode ser colocada em prática, pelo fato do processo não estar definido e documentado;
Uma evolução natural do processo padrão da organização, que pode sofrer melhorias a cada avaliação dos projetos realizados, já que todo projeto tem seu processo de execução definido a partir do processo padrão. É a grande vantagem de se ter na organização uma estrutura comum de trabalho. Neste caso, todos utilizam e contribuem na melhoria do processo ao passo que o trabalho isolado, em que cada um faz o que quer, contribui minimamente para a melhoria da capacitação de desenvolvimento da organização.
Como podemos ver, as idéias do modelo CMM bem como do SPICE, seguem a mesma filosofia e são muito boas, como também são as propostas das metodologias estruturadas da década de 70 e as metodologias orientadas a objeto da década de 80, que apontam:
Passos seqüenciais e lógicos a seguir;
Documentação dos produtos;
Revisões,...
O problema é que a teoria é muito diferente da prática das organizações. Muita coisa boa vem sendo feita desde a década de 70 buscando melhoria do processo de desenvolvimento, porém, pouca coisa vem sendo praticada. Uma pesquisa buscando identificar o nível de capacitação das organizações dentro do modelo CMM foi realizada pelo SEI – Software Engineering Institute – um centro de pesquisa e desenvolvimento criado em 1984 pelo Departamento de Defesa americano, responsável por aprimorar práticas de engenharia de software e idealizador do modelo CMM. De acordo com a pesquisa [SEI 97] que avaliou 533 organizações de 1992 a 1996, foi revelado que 61,5% destas organizações ainda desenvolvem software de forma amadora e se encontram no nível 1 do modelo, enquanto que apenas 13,5% possuem um processo padrão de desenvolvimento. Sobre organizações brasileiras, o relatório brasileiro de 1995 [Weber 97] , baseado na avaliação de 445 empresas, mostra que apenas 2,7% das empresas conheciam e estavam adotando o CMM.
Talvez este problema sobre teoria e prática repouse sobre algumas destas bases:
É verdade que nos sentimos um pouco artistas e o artista é um criador. Talvez devêssemos nos sentir mais engenheiros que artistas. Continuaríamos com um título pomposo, porém, o enfoque do nosso trabalho passaria a ser o de aprimorar e seguir métodos;
Ferramentas adequadas são fundamentais para a realização de um bom trabalho, bem como, máquinas que suportem tais ferramentas;
Se o processo padrão da organização é elaborado a partir das melhores práticas da organização, é evidente que este trabalho de elaboração deve ser um trabalho conjunto dos pesquisadores e dos desenvolvedores da organização. Quanto mais distante o relacionamento deste par, mais difícil a internalização (a prática) do processo padrão;
Treinamento do pessoal técnico é fundamental para o entendimento comum. Se você acha que treinamento é um peso e que compromete o atendimento ao cliente, talvez você esteja indo na contramão da melhoria da qualidade e produtividade. Treinamento não é só importante, mas fundamental;
Por fim, vale a pena lembrar que toda organização que se considera apta para enfrentar a competição do terceiro milênio deve trabalhar com alta qualidade e produtividade. E qualidade e produtividade de uma organização depende de três fatores: processos, tecnologia e pessoas. É o chamado triângulo da qualidade [SEI 96] mostrado abaixo:
Qualquer destes fatores que esteja inadequado, certamente irá comprometer a Qualidade e a Produtividade da organização, ou seja, se você busca aumento de qualidade e produtividade da sua organização, pessoal desmotivado, tecnologia inadequada ou processos desorganizados devem ser tratados com muito cuidado e o mais rapidamente possível.
Por fim, gostaria de terminar este artigo tecendo minhas considerações sobre implantação de modelos de qualidade:
É um processo lento e gradual;
Necessidade de investimentos e apoio do nível estratégico da organização;
É necessário um trabalho de auditoria intenso, principalmente no início;
Treinamento e Disciplina do quadro técnico.
Não é um trabalho fácil a implantação destes modelos. Porém, o retorno do investimento vem com a diminuição gradativa principalmente dos custos de manutenção dos produtos de software.
REFERÊNCIAS BIBLIOGRÁFICAS
[Paulk 95] PAULK, M. C. The Capability Maturity Model: guidelines for improving the software process. U.S.A: Addison Wesley, 1995. (SEI Series).
[SEI 96] SOFTWARE ENGINEERING INSTITUTE. CMM based appraisal for internal process improvement (CBA IPI) - Team Training Material. U.S.A: Addison Wesley, 1996.
[SEI 97] SOFTWARE ENGINEERING INSTITUTE. Process maturity profile of the software community - year end update. U.S.A: Addison Wesley, 1997.
[Weber 97] WEBER, K. C.; LUCA, J. C. M. Qualidade e produtividade em software. 2. ed. Rio de Janeiro: Makron Books, 1997.
[Fio 98] FIORINI, Soeli. Engenharia de software com CMM. Rio de Janeiro: Brasport Livros e Multimídia, 1998.
