O Modelo SEI/CMM e o Processo de Desenvolvimento de Software

por Átila Belloquim

Publicado em Março de 1997 na Developers Magazine. Este artigo está apresentado aqui tal como foi enviado ao editor, podendo, devido ao processo de revisão da revista, estar ligeiramente diferente de sua versão publicada.
Copyright por Átila Belloquim. Este documento pode ser reproduzido no todo ou em parte, desde que citada a fonte.

Existe muita discussão e controvérsia em torno da eficácia das Metodologias de Desenvolvimento de Sistemas (MDS). Embora, na teoria, todo mundo concorde que as MDS são úteis e mesmo necessárias, na prática são pouquíssimas as empresas que as adotam. Porquê esta incongruência? É comum escutar nas empresas seguinte argumento: "Já tentamos implantar metodologia aqui há dez anos e não deu certo. Logo, metodologias não funcionam, e não vamos perder tempo e dinheiro com esta bobagem...". Este argumento estaria perfeito, se não fosse pelo fato de que muitas empresas usam MDS há muitos anos, com absoluto sucesso! O quê está errado, então? A verdade é que Metodologias são muito difíceis de implantar, e uma implantação mal feita pode mesmo ser desastrosa e "queimar" a idéia por muitos anos na empresa. Um dos principais problemas com a implantação de metodologias é que elas não podem ser tiradas de um contexto maior. Em outras palavras, metodologia só não basta. Tentar implantar uma MDS sem ter o ambiente bem preparado é como jogar sementes em um campo que não foi arado e adubado. Querer que dê certo é desejar uma colheita sem irrigar o campo. Se a semente não germina, a culpa não é dela! E o que a empresa deve fazer para "arar" e "irrigar" o campo antes da semeadura? O campo estará "arado" se a empresa se empenhar em adquirir Capacitação Tecnológica, que é o conjunto de conhecimentos e habilidades possuídos pela empresa e seus funcionários que facilitam a absorção de novos conhecimentos e habilidades. É bastante conhecido o fenômeno de que as pessoas tendem a aprender tanto mais rápido quanto mais conhecimentos já possuem. O mesmo vale para a empresa como um todo. Assim, é muito mais fácil implantar MDS em uma empresa em que os analistas conhecem e usam técnicas como Modelagem de Dados e Análise Essencial, e praticam algum tipo de planejamento e controle em projetos, do que numa empresa em que o desenvolvimento é totalmente empírico e sem nenhum controle. Para "irrigar" o campo, a empresa deve estar ciente de que as MDS não podem ser consideradas como uma coisa estática. A MDS deve ser continuamente revisada e melhorada, conforme surgem novas tecnologias e deficiências são encontradas. Em outras palavras, MDS não basta. A empresa deve estar preparada para recebê-la e deve inseri-la dentro de um contexto maior que inclua, por exemplo, revisões periódicas na própria Metodologia. Este "contexto maior" é conhecido como Processo de Software. Processo de Software

Muito se tem falado em Processo de Software, mas pouco se sabe a respeito. Quando se fala em Processo de Software, muita gente que já ouviu falar no assunto lembra logo da sigla SEI/CMM. Nem poderia ser diferente, já que o SEI/CMM é o modelo hoje mais respeitado de gerenciamento do Processo de Software. Para quem ainda não sabe, SEI é o Software Engineering Institute, uma instituição vinculada à Carnegie-Mellon University. Este instituto foi fundado com o objetivo de pesquisar os problemas recorrentes encontrados nas tarefas de Engenharia de Software e propor soluções que permitam resolver estes problemas. A idéia é criar uma infra-estrutura que permita a quem escreve software fazer um bom trabalho, isto é, criar software melhor, mais rápido, mais barato e com menos "bugs", e que ainda por cima seja mais fácil de dar manutenção e estender a funcionalidade. Se isto está cheirando a mais uma nova metodologia, não se engane! O mérito da SEI está justamente em perceber que métodos sozinhos não resolvem problema nenhum. A promessa de qualidade e produtividade já estava embutida na Análise, Projeto e Programação Estruturadas. Todo mundo hoje usa as técnicas estruturadas (com maior ou menor competência, é claro), mas mesmo profissionais tarimbados têm dificuldades em ver esta Terra Prometida quando estão em projeto atrasado, com orçamento cortado e com o chefe no cangote querendo saber por quê ainda não está pronto. Isto sem contar com as toneladas de manutenções atrasadas pedidas pelos usuários. A Orientação a Objetos tem, sem dúvida, muitas vantagens técnicas e metodológicas sobre os métodos estruturados. Mas quem já está na estrada há tempos pode, com razão, torcer o nariz diante deste novo mapa para o Eldorado, desconfiando que, na verdade, as técnicas OO, por melhores que sejam, não vão fazer os prazos e orçamentos ficarem maiores. Ao contrário, como tanto o chefe quanto o usuário também ouviram as promessas, é provável que os prazos fiquem ainda mais curtos e os orçamentos ainda menores... A questão é que os problemas de prazo e orçamento têm muito pouco a ver com a tecnologia que está sendo empregada. São questões relativas ao Processo de desenvolvimento e, por isso, estão muito acima do que as Metodologias, seja em que técnicas estejam baseadas, podem e pretendem resolver. Portanto, o que a SEI propõe é um modelo muito mais amplo do que uma simples Metodologia. É um modelo que procura dar às organizações de desenvolvimento um processo de produção de software que funcione. Na verdade, a Metodologia é um dos componentes do processo (um dos mais importantes, aliás), mas o que se procura é resolver os problemas que as MDS não alcançam. Então, o quê quer dizer CMM? O CMM é o Capability Maturity Model, algo difícil de traduzir, mas que poderia ser talvez o "Modelo de Maturidade de Capacitação". Este modelo permite avaliar uma organização de desenvolvimento (uma Software-House ou um Departamento de Desenvolvimento de Sistemas de um Banco, por exemplo) e classificá-la em um entre cinco níveis crescentes de maturidade. O termo "capacitação" diz respeito tanto à habilidade para tocar com competência o desenvolvimento quanto à capacidade de incorporar novas tecnologias ou desenvolver novos tipos de sistemas sem bagunçar o que já existe. Uma organização, evidentemente, está tanto mais "madura" quanto menor for o caos de seu processo de desenvolvimento. Com base na classificação, o CMM propõe o que deve ser feito para que a organização consiga atingir o próximo nível. Além disso, indica como se deve atuar para evitar a regressão a um nível mais baixo (algo muito mais comum do que se imagina). A idéia básica que permeia todo o modelo é a de Gerência de Processos, ao invés da tradicional Gerência de Projetos. A Gerência de Projetos, como diz o próprio nome, tem como foco um único projeto, com início e fim, um cronograma e um orçamento. É exercida por um único gerente (para um projeto) e todos os gerentes de projetos exercem atividades iguais. A Gerência do Processo de Software, por sua vez, abrange todos os projetos em execução ao mesmo tempo e ainda uma série de outras atividades, como Gerenciamento de Mudanças, de Configuração e atividades de Controle de Qualidade. Trata-se de uma tarefa da organização de desenvolvimento como um todo e exige diferentes gerentes com especialidades distintas. Assim, o CMM propõe meios e técnicas concretas em áreas antes deixadas à intuição dos gerentes. Em uma empresa que tem MDS, os analistas e desenvolvedores sabem o que têm que fazer e como. O gerente do projeto já está mais abandonado. Poucos gerentes recebem treinamento específico em gerência de projetos. As Metodologias dizem ao gerente o que os seus subordinados devem fazer, mas não diz o que ele mesmo deve fazer! As Metodologias, por outro lado, são estáticas. Quando uma empresa compra no mercado, de uma empresa de consultoria, uma Metodologia (ou mesmo quando a desenvolve em casa), aceita-se tacitamente na transação a hipótese de que a MDS não precisará ser nunca mudada. Acredita-se que ela manter-se-á sempre útil e atualizada. Na prática, o que se vê são empresas que adotaram Metodologias em tempos de mainframe e que, na hora de migrar para tecnologia Cliente-Servidor, perceberam que a sua MDS não era adequada para o desenvolvimento de sistemas na nova tecnologia. O que fizeram elas então? Adivinhou: abandonaram a Metodologia e voltaram a construir sistemas de forma empírica e caótica. Dentro do modelo SEI/CMM, um dos conceitos mais importantes é o do SEPG (Software Engineering Process Group). Este é um grupo de pessoas (presumivelmente uma equipe com um gerente, respondendo para o Diretor de Desenvolvimento) encarregado especialmente de avaliar continuamente a maturidade da organização e conduzir os projetos de melhorias. Assim, a responsabilidade por manter a MDS sempre atualizada e relevante é deste grupo. O que está por trás disto é a idéia (que deveria ser óbvia, mas não é) de que a MDS sofre de entropia como qualquer outra coisa, isto é, se alguém não se preocupar com sua manutenção, ela não terá como melhorar-se sozinha! Os Cinco Níveis

Descreveremos agora, resumidamente, as principais características da organização em cada um dos cinco níveis do CMM e as ações necessárias para passar ao próximo nível. No nível 1, chamado de Inicial, o desenvolvimento é caótico. Não existem procedimentos padronizados, estimativas de custos e planos de projeto. Cada qual desenvolve como quer, não existe documentação e não há mecanismos de controle que permitam ao gerente saber o que está acontecendo, identificar problemas e riscos e agir de acordo. Como conseqüência, os desvios não são corrigidos e ocorrem os problemas que todos conhecemos muito bem: prazos não cumpridos, orçamentos estourados, software sem qualidade e usuários insatisfeitos. Na verdade, raramente existe um cronograma ou um orçamento. Infelizmente, estima-se que mais de três quartos das empresas norte-americanas encontram-se neste nível, e não há razões para acreditar que a situação seja melhor no Brasil. Para passar ao nível 2, a organização deve instituir controles básicos de projeto, incluindo o Gerenciamento de Projetos (técnicas para planejar e estimar o esforço em projetos, e controlar o progresso), Controle Gerencial (verificação pela Gerência do progresso do projeto em momentos pré-determinados, incluindo a qualidade dos produtos), a instituição de um Grupo de Controle de Qualidade e de procedimentos básicos de Controle de Mudanças (para garantir que mudanças no projeto e manutenções solicitadas não destruam o que já foi feito, garantindo um mínimo de estabilidade no desenvolvimento; nada é mais deletério para um projeto do que requerimentos que mudam constantemente e sem controle). Chegando ao nível 2, chamado Repetível, a organização está em condições de ter maior controle sobre seus projetos, e pode-se esperar que as estimativas sejam mais precisas (já que se desenvolve uma base histórica intuitiva) e a qualidade do software produzido seja maior. No entanto, caso a empresa enfrente o desafio de atacar projetos de características distintas das que está acostumada (usando uma nova tecnologia, por exemplo), esta informação será irrelevante, e a empresa poderá regredir ao nível 1. Para passar ao nível 3, Definido, é necessário introduzir uma Metodologia de Desenvolvimento formal, com um ciclo de vida definido, acompanhada de métodos, técnicas e ferramentas apropriadas, como inspeções e técnicas abrangentes de teste. É o momento também de estabelecer o SEPG, isto é, o time encarregado exclusivamente da melhoria contínua do processo de software. Ao chegar a este nível, a empresa terá um fundamento claro para desenvolver sistemas e também para melhorar o próprio processo, especialmente quando surgirem crises. No nível 3, entretanto, os controles ainda são basicamente qualitativos, não havendo meios de quantificar a qualidade dos produtos e a eficiência do processo. Assim, a empresa deve estabelecer métricas de forma a medir características específicas dos produtos. A forma de coletar, armazenar e analisar estes dados é definida e, com base nesta informação, pode-se sugerir melhorias específicas nos produtos. Neste ponto, a empresa estará no nível 4, ou Gerenciado, Para subir do nível Gerenciado para o último nível, o Otimizador, deve-se estabelecer meios para a coleta automática de métricas e para a utilização da informação coletada de forma a prevenir problemas. Enquanto no nível 4 as métricas têm seu foco no produto (o software sendo desenvolvido), no nível 5 são coletadas e utilizadas informações sobre o processo em si. A idéia é analisar as causas do problemas e atacá-las para evitar que volvem a ocorrer. Enquanto os dados coletados no nível 4 podem informar, por exemplo, quantos erros existem em um programa, a preocupação no nível 5 é melhorar o processo para evitar que tais erros aconteçam no próximo projeto. Conclusão

O modelo CMM é extremamente útil para uma organização de desenvolvimento poder avaliar a si mesma e estabelecer prioridades para melhorar seu processo de desenvolvimento e, conseqüentemente, aumentar a qualidade do software que desenvolve. Os benefícios do uso de uma Metodologia de Desenvolvimento são maximizados quando a empresa tem sua MDS "encaixada" no contexto mais amplo do Processo de Software. O esforço por aumentar sua Capacitação Tecnológica, através do treinamento e incentivo aos desenvolvedores, fará com que a transição entre os vários níveis se dê mais rápida e suavemente. Estima-se que menos de 10% das empresas norte-americanas estejam no nível 3. Para os níveis 4 e 5 juntos, a estimativa é de menos de 1% das organizações de desenvolvimento em todo o mundo! Percebe-se, portanto, que ainda está muito longe o dia em que o desenvolvimento de software será uma tarefa realmente parecida com a engenharia, no sentido de ser mais uma técnica que uma arte. Este artigo procurou discutir os conceitos básicos do Processo de Software. Em artigos futuros na DevMag, apresentaremos com maior profundidade alguns destes tópicos. Sugestões sobre assuntos específicos são bem-vindas.

Átila Belloquim é especialista em Metodologias de Desenvolvimento de Sistemas, Mestrando em Administração de Empresas pela USP e Conferencista em eventos de informática. Atualmente é Gerente de Serviços de Treinamento da Choose Technologies e Membro da Coordenação do SPIN Brasil (Grupo de Usuários SEI/CMM). Pode ser contactado em choose@choose.com.br ou através da redação de DevMag.


volta