SEI/CMM: O Caminho Para o Nível 2

Por Átila Belloquim

Publicado em Julho 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.

A partir do artigo publicado na edição de março da DevMag, a respeito do modelo SEI/CMM de melhoria do nível de maturidade de software, tive a oportunidade de observar que, felizmente, o assunto da qualidade de software têm encontrado eco. Cada vez mais encontramos profissionais da área, em todos os níveis, que começam a preocupar-se com esta questão tão complexa e delicada. Após anos de promessas não cumpridas de solucionar-se os problemas de tecnologia através de mais tecnologia, parece que começa a haver um movimento de compreensão de que os problemas de desenvolvimento de software não são tecnológicos, mas gerenciais e organizacionais. Não é à toa que a DevMag dedicou seu último número, em sua chamada de capa, para o assunto.

Assim, dando prosseguimento ao artigo citado, discutirei agora, em maior nível de detalhe, o Nível 2 do CMM, chamado de Repetível. Mais do que qualquer outro nível de maturidade, o nível repetível têm interesse especial, pois além do fato da grande maioria das empresas estar no nível 1 (Inicial), o caminho para o nível 2 é talvez o mais difícil de ser percorrido, pois trata-se de colocar o trem em movimento, enquanto a passagem para os níveis seguintes pode se beneficiar do "embalo" gerado pelos esforços de melhoria para se alcançar o nível 2. Segundo os últimos números publicados pela SEI (Software Engineering Institute), 67% das empresas que se submeteram a avaliações conduzidas por avaliadores credenciados pela SEI foram classificadas no nível 1. Sabendo-se que estas empresas submeteram-se a estas avaliações e, portanto, manifestam algum tipo de preocupação com a qualidade, pode-se inferir que, se as empresas que "não estão nem aí" com a qualidade (que não devem ser poucas) fossem incluídas na amostra, a proporção de empresas no nível inicial seria muito maior. Provavelmente, chagaríamos à conclusão de que virtualmente todas as empresas se encontram aí (eu, pessoalmente, chutaria algo em torno de 95 a 98%). Talvez isso explique porque nossos micros travam tanto... Iniciando o Processo de Melhoria.

O início do caminho para o nível dois parte de um grande esforço para chamar a atenção para os problemas de software internamente. A partir de uma avaliação formal ou informal, em que se encontram os principais pontos fracos no processo de desenvolvimento, é necessário fazer com que todos dentro da empresa comprem a idéia da melhoria, de cima a baixo. Isto inclui a alta administração (diretoria), profissionais de informática (gerentes, analistas programadores, AD, DBA, produção, suporte etc. etc. etc.) e usuários (gerência e pessoal operacional).

Isto implica na necessidade de se constituir uma disciplina de comprometimento. Todos os envolvidos devem acostumar-se a assumir compromissos com seriedade. Isto significa, entre outras coisas, não prometer o que não se pode cumprir, e, por outro lado, cumprir o que se prometeu.

Isto é especialmente importante em relação ao tratamento de prazos. Segundo Watts Hunphrey, "Com poucas exceções, estimativas iniciais de recursos e cronogramas são inaceitáveis. Isto não ocorre por que os programadores são incompetentes, mas porque os usuários geralmente querem mais do que o que podem pagar. Quando alguém quer construir uma casa e as primeiras estimativas estão além de suas possibilidades, não há sentido em pôr a culpa no construtor. (...) Após algumas experiências, os usuários normalmente reconhecem que construir software leva tempo. Poucos usuários, porém, têm este background (...). Este conflito natural existe desde os primeiros dias da programação de computadores, e aqueles que reduziram suas estimativas sob pressão invariavelmente estavam errados. A história demonstra que até mesmo estimativas iniciais "infladas" são geralmente otimistas (...)". Assim, "as negociações de planejamento são o teste crítico do time gerencial. Este time deve tratar o plano inicial como um ponto de partida e, quando o prazo ou o custo tiverem de ser reduzidos, o escopo do trabalho deve ser igualmente cortado" (Managing the Software Process, Addison-Wesley, 1989). É evidente que a promessa de prazos fora da realidade é a principal causa de problemas de qualidade e insatisfação dos usuários. Mas não é o único problema. Assim, uma vez que se obtenha forte compromisso gerencial para as mudanças, pode-se iniciar a caminhada rumo ao nível 2. O foco do nível 2 é o estabelecimento de procedimento básicos de Gerenciamento de Projetos. A falta de planejamento é a primeira coisa a ser atacada, sem a qual qualquer outro esforço de melhoria é baldado. Uma equipe que desenvolve seu trabalho aleatoriamente não poderá se beneficiar de técnicas de inspeção, metodologias de desenvolvimento ou métricas.

As diversas atividades de melhoria de software devem ser conduzidas por um grupo especialmente constituído para isto, normalmente chamado de SEPG (Software Engineering Process Group - Grupo de Processos de Engenharia de Software). A existência de um grupo especificamente encarregado destas tarefas é fundamental para garantir os projetos de melhoria. Obviamente, não são os desenvolvedores já pressionados que disporão de tempo para estas atividades. Em termos de sua implementação, cada nível do CMM é composto de um certo número de Áreas-Chave de Processo (KPAs - Key Process Areas). Estas áreas descrevem as questões que devem ser abordadas e resolvidas para se alcançar aquele nível. Assim, por exemplo, uma organização pode dominar uma KPA do nível três sem contudo estar sequer no nível dois em outras KPAs. Em geral, considera-se que uma organização está em determinado nível caso todas as KPAs definidas para aquele nível sejam cumpridas. Cada KPA, portanto, identifica um conjunto de atividades que, tomadas em conjunto, permitem alcançar uma série de objetivos importantes para se obter uma melhoria de processo. As KPAs do nível 2 são seis e estão listadas a seguir:

Passemos portanto a discutir resumidamente cada uma destas KPAs.

Gerenciamento de Requisitos

O propósito do Gerenciamento de Requisitos é estabelecer um entendimento comum entre o usuário e a equipe de projeto a respeito dos requerimentos que serão atendidos pelo projeto. Além disso, são estabelecidos procedimentos para a mudança dos requisitos, garantindo que os planos, cronogramas e recursos alocados estejam sempre coerentes com os requisitos.

Não é novidade para ninguém que nada é mais deletério para o prazo e qualidade de um projeto do que requisitos que mudam constantemente. A pior situação, porém, é quando estas mudanças (algumas vezes realmente necessárias, mas nem sempre) são aceitas pela equipe sem que prazos e recursos sejam revistos.

Para cumprir esta KPA, a organização deve, em primeiro lugar, instituir procedimentos para a documentação dos requisitos. Estes requisitos devem também ser revisados por diversas áreas envolvidas (para verificar sua viabilidade) e ter sua qualidade controlada. Observe-se que a documentação dos requisitos e sua revisão devem ser feitas antes da elaboração do plano do projeto. Embora isto pareça óbvio, é impressionante ver a quantidade de gerentes de projeto que se comprometem com prazos antes de saber o que terão de fazer!

Em seguida, a organização precisa instituir procedimentos para a alteração dos requisitos. Isto significa que os requisitos não podem ser alterados "por telefone". A existência de um procedimento formal para alteração de requisitos têm dois benefícios: garante que os planos serão revistos para acomodar as alterações (isto é, renegociação de prazos e recursos) e funciona como um freio para alterações desnecessárias ou postergáveis (normalmente, a maioria), instituindo uma disciplina de controle de prioridades. Afinal, é impossível desenvolver software decente se os requisitos não forem "congelados" por algum tempo.

Planejamento de Projetos

O propósito desta KPA é garantir que, a cada projeto, sejam elaborados planos razoáveis para o desenvolvimento. Isto envolve a realização de estimativas e o estabelecimento de compromissos. Também se incluem aqui atividades de gerenciamento de riscos e alocação de recursos. Para cumprir esta KPA, a empresa deve instituir políticas e procedimentos padronizados para o planejamento de projetos. Estes procedimentos devem incluir, entre outras coisas, a necessidade de envolver todas as áreas interessadas (técnicas e usuárias) no processo de planejamento. Esta KPA também pressupõe que a empresa tenha definido um ciclo de vida de sistemas para ser usado no planejamento. Estimativas, planejamento de projetos e gerenciamento de riscos são atividades suficientemente grandes para fugir do escopo deste artigo e serão tratadas em pormenores em ocasiões futuras. No entanto, gostaria de enfatizar que a existência de procedimentos padronizados para estas atividades tem enorme valor, evitando que os gerentes de projetos se sintam perdidos e acabem cometendo falhas graves de planejamento por falta de experiência.

Acompanhamento e Supervisão de Projetos

Planejar o projeto não basta. É preciso garantir, ao longo de sua execução, que os planos estão sendo cumpridos. O propósito desta KPA é dar visibilidade sobre o progresso real do projeto em relação ao planejado, permitindo a tomada de ações corretivas quando a realidade estiver se afastando muito do que foi inicialmente planejado. Para cumprir esta KPA, a organização deve instituir procedimentos para garantir que o progresso do projeto é continuamente comparado com o planejado, em termos de prazos, custos e qualidade. Além disso, os procedimentos devem estabelecer "gatilhos" a serem disparados quando houver muita distância, indicando as ações corretivas a serem tomadas em cada caso, incluindo alterações nos compromissos assumidos. A evidência, por exemplo, de que um prazo não será cumprido deve levar à renegociação de prazo, recursos, escopo ou nível de qualidade previamente acordados. Esta KPA, naturalmente, inclui o acompanhamento dos fatores de risco identificados nas atividades de gerenciamento de riscos incluídas na KPA de Planejamento de Projetos. Outro ponto importante coberto por esta KPA é o estabelecimento da obrigatoriedade da existência de pontos de revisão formal ao longo do projeto. Isto significa que, em determinados momentos do desenvolvimento, os produtos gerados até então são revisados formalmente pelas áreas envolvidas, como forma de garantia que o projeto está andando conforme deveria.

Quando ocorrem alterações nos planos por conta de ações corretivas tomadas, é fundamental que os planos originais sejam mantidos. Isto permitirá futuramente que os erros de estimativas sejam conhecidos e, portanto, reduzidos. Sabendo-se onde se errou, pela comparação entre planejado e real, futuros projetos poderão ser estimados com mais precisão. Quando isto não é feito, a impressão que se tem é que o projeto está sempre em dia (já que os planos foram refeitos...). Naturalmente, todo mundo sabe, por exemplo, que o projeto atrasou. Porém, ao fim de inúmeras alterações nos planos, ninguém mais sabe quanto atrasou, o que atrasou e por quê!

Gerenciamento de Subcontratação

Cada vez mais são usados recursos externos (outsourcing) para colaborar no desenvolvimento do software. O propósito desta KPA é garantir a seleção e gerenciamento eficaz destes recursos terceirizados. Para cumprir esta KPA, a organização deve estabelecer procedimentos para garantir que a seleção de subcontratados se faz de forma apropriada, que as atividades a serem desenvolvidas pelos terceiros estejam bem definidas e planejadas, que o contrato entre a empresa e os terceiros é adequado e que a comunicação entre empresa e terceiros é adequada. Além disso, devem ser estabelecidos procedimentos especificando como se fará a comunicação (por exemplo, documentos de trabalho a serem trocados) e, naturalmente, procedimentos para revisão e controle de qualidade dos produtos gerados pelos terceiros.

Novamente, o estabelecimento e gerenciamento de contratos de terceirização de desenvolvimento de software é um assunto muito maior do que o que se pode cobrir neste espaço, ficando outros detalhes para outra ocasião. A idéia, porém, que deve ficar, é que a existência de padrões para o trabalho conjunto com os terceiros é crítica para o sucesso dos projetos, uma vez que, por maior que seja a qualidade do trabalho da empresa, se os subcontratados não tiverem qualidade o projeto será nivelado por baixo e terá certamente qualidade deficiente e altos riscos.

Garantia de Qualidade de Software

O propósito desta KPA é prover visibilidade sobre a qualidade tanto dos processos utilizados pela equipe de projeto quanto dos produtos gerados. Isto inclui revisões formais e informais dos produtos e auditorias dos processos. Tipicamente, em empresas com recursos suficientes, existe um grupo especialmente dedicado a estas tarefas. Quando este recursos estão ausentes, pode-se executar as atividades desta KPA através de comitês de pessoas selecionadas nas áreas envolvidas, dedicando parte de seu tempo.

É importante observar que esta KPA diz respeito tanto a produtos quanto a processos. Além disso, as revisões de qualidade se dão em todas as fases do desenvolvimento. Isto deve ser dito pois existe uma idéia corrente que faz acreditar que controle de qualidade de software resume-se à existência de procedimentos de teste de programas e sistemas. Nada mais falso. Sabendo-se que testes muito bem feitos (coisa muito rara, aliás) são capazes de remover em média apenas 60% dos defeitos de um programa, e que o custo da remoção de defeitos após a codificação é absurdamente maior do que se forem detectados e removidos em fases anteriores, fica evidente que a qualidade dos produtos do projeto deve ser acompanhada desde o início do desenvolvimento. Quantas semanas já não gastamos reescrevendo partes inteiras de sistemas, depois de prontas e testadas, apenas porque descobrimos, no momento do teste de aceitação pelo usuário, que havia sérios erros na própria especificação funcional do sistema? Certamente, se houvesse um procedimento de revisão da especificação, ao final da análise, a correção do problema seria infinitamente mais barata. Quanto à revisão dos processos, deve-se dizer que não basta revisar produtos. Na maioria das vezes, produtos sem qualidade são resultado de processos sem qualidade. Não basta descobrir que um programa tem um monte de bugs. É necessário descobrir por quê estes bugs existem. Geralmente, a razão será algo como o não uso dos padrões definidos de programação, documentação de programação insuficiente, comunicação inadequada entre analistas e programadores etc.

Para cumprir esta KPA, a empresa deve instituir um grupo de garantia de qualidade (ou ao menos um comitê), procedimentos que garantam que as atividades necessárias de garantia de qualidade são planejadas, executadas e revisadas. Estes procedimentos devem incluir medidas objetivas de verificação de qualidade, e também padrões de qualidade que possam ser usados como medida de comparação com os produtos e processos efetivamente utilizados.

A cada projeto, portanto, são desenvolvidos planos de garantia de qualidade, dentro do planejamento geral do projeto. Este planos incluem pontos e procedimentos de verificação, tais como revisões de documentos, inspeções de código e, naturalmente, testes. O cumprimento destes planos permite a identificação de desvios de qualidade e, conseqüentemente, a adoção de ações corretivas o mais cedo possível.

Gerenciamento de Configuração

O propósito desta KPA é garantir a integridade dos produtos gerados durante o ciclo de vida do projeto.

Uma das maiores dores de cabeça em projetos complexos é gerenciar a configuração do software, incluindo aí o controle de versões. Em um determinado momento, um mesmo programa pode ter três ou mais versões. Além disso, pode haver confusão entre códigos-fonte e executáveis. Pergunte-se a si mesmo: que garantias você tem de que os programas rodando em produção em sua empresa hoje foram gerados realmente pelo fonte que está guardado em produção? Será que eles estão na mesma versão? Numa manutenção de grande porte, você sabe distinguir uma versão "quente" de uma antiga? Você tem certeza de que não existem dois programadores alterando o mesmo programa ao mesmo tempo, sem saber um do outro?

Existem casos ainda mais cabeludos. Considere a seguinte situação muito corriqueira: O usuário solicita uma grande alteração em um programa. Não há pressa, e a manutenção é alocada para o programador X, que começa as alterações que deverão ser implantadas, digamos, em três semanas. No final da segunda semana, o programador sai para um treinamento de Qualidade de Software de dois dias. Sua manutenção está em ordem, a maior parte das alterações já foram feitas e testadas.

Enquanto o programador X está em seu curso, o tal programa explode em produção, devido à ocorrência de uma condição rara não testada quando o programa foi escrito pela primeira vez. O programador Y recebe a incumbência de consertar o programa e recolocá-lo no ar em meia hora, já que o programa é crítico e está prejudicando o atendimento aos clientes da empresa. Com toda a sua competência, Y corrige o problema e todos ficam felizes e aliviados, indo contentes para seu merecido fim de semana. Naturalmente, ninguém se lembrou de deixar um bilhete para X contando-lhe o que aconteceu. Aliás, ninguém mesmo se lembrou de que X estava alterando este programa.

Na segunda feira, X volta ao trabalho ávido para experimentar as novas técnicas de teste que aprendeu no curso. Termina sua manutenção e coloca o programa em produção na sexta-feira... queimando o conserto que Y fizera! Um mês depois, a rara condição volta a ocorrer, o programa aborta novamente e todo mundo se convence de que isto só pode ser obra do Demo!!!

Bem, Gerenciamento de Configuração é a KPA que evita que estes casos escabrosos ocorram. Para cumprir esta KPA, a organização deve instituir procedimentos que garantam que as atividades de Gerenciamento de Configuração são planejadas, executadas e verificadas. Procedimentos de Controle de Mudanças são estabelecidos, garantindo que alterações em produtos (documentos, dados de teste, programas) são feitas de forma consistente e sob o conhecimento e aprovação de todos os envolvidos. O uso de software de Controle de Configuração (Librarians) pode facilitar bastante a execução destas atividades. Também é necessária a criação de um grupo (ou comitê) responsável pelas atividades de gerenciamento de configuração. Toda manutenção passa a ser considerada como a implantação de uma nova versão ou release do software.

Conclusão

É fácil entender por quê tão poucas organizações estão no nível 2. Qualquer um que tenha alguma experiência na área sabe que a maioria das atividades acima ou são realizadas de forma aleatória, ou, na maioria das vezes, não são executadas de forma alguma. No entanto, são todas atividades necessárias para que exista um mínimo de ordem no desenvolvimento de software, e será difícil defender a tese de que é possível desenvolver software com qualidade na ausência de qualquer uma das atividades descritas. Fica claro, portanto, que, em vez de burocracia sem sentido, padrões e processos bem definidos e usados podem fazer muito pela qualidade dos processos de desenvolvimento de uma empresa, aumentando a qualidade dos produtos e reduzindo prazos e custos por conta de muito menos retrabalho, que seria necessário como decorrência de um ambiente caótico.

Á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