Amazing

O que me motivou a escrever essa nota foi uma mensagem do Professor Erney Plessmann Camargo, aos pesquisadores do CNPq relatando sobre sua gestão na presidência do órgão. Em função do seguinte trecho da mensagem do Professor:
“A partir de Junho, a circulação de
pedidos em papel praticamente desaparecerá do CNPq. Nosso corpo técnico
terá, assim, mais liberdade e tempo para se dedicar a questões
substantivas e de mérito, parcialmente liberado da burocracia documental.
O programa, como sempre, ainda não está isento de defeitos e “bugs”.” ,
resolvi escrever-lhe uma carta.

Em minha carta disse sobre a maturidade da Engenharia de software e também solicitei ao Professor sua anuência para que eu pudesse tornar público essa minha observação. Através de seu chefe de gabinete, Carlos Pittaluga., o Prof. concordou e pediu que eu fizesse saber que:
“Nesse particular, solicitou o Sr. Presidente que deixasse
expresso o fato do novo software ter sido inteiramente desenvolvido pelos funcionários do CNPq, e que não recorremos a nenhuma empresa desenvolvedora de software. No momento, e a exemplo do que ocorreu com outros programas por nós desenvolvidos, estamos solicitando a colaboração dos pesquisadores, cujas observações, críticas e sugestões
sempre são úteis e que, ao longo do tempo, vêm permitindo o constante aperfeiçoamento de nossos sistemas”.

O “como sempre” utilizado pelo presidente do CNPq é o reflexo de como o processo de produção de software é visto por muitos executivos. São muitos os exemplos de falhas no processo de produção de software.

Costumo dizer que a sociedade, aos poucos, desperta para a importância da qualidade de software, e um dos primeiros avisos foi o movimento Y2K, ou o problema do ano 2000. Poucos produtos de software oferecem garantia de funcionamento, se duvidar dê uma olhada nos contratos dos software de prateleira que normalmente usamos. Se por um lado isso é um fato, é verdade também que a comunidade de engenharia de software tem trabalhado na formação e divulgação de boas práticas de software.

Um dos melhores exemplos é o trabalho do SEI, Software Engineering Institute, uma organização estatal em associação com a Universidade Carnegie Mellon nos Estados Unidos. O SEI é fruto de um movimento que se iniciou na década de 80 nos Estados Unidos em contraposição ao esforço do Japão na construção da Quinta Geração com a criação do MCC(Microelectronics and Computer Technology Corporation).

Coube ao SEI trazer para a Engenharia de Software o conceito de Maturidade. Este conceito é aplicado tanto a indivíduos como a organizações. Em particular, modelos de maturidade ou de estágios foram bastante utilizados em Sistemas de Informação, sendo o modelo de Nolan um dos pioneiros. Veja um estudo de Álvaro Rocha da Universidade Fernando Pessoa sobre modelos de maturidade organizacional e uma apresentação da PMI-Rio sobre o padrão OPM3 para maturidade em gerência de projetos.

O modelo de maturidade proposto pelo SEI é o CMM (Capability Maturity Model) . É interessante notar o que escreveu o líder desse projeto, Bill Curtis, sobre o sucesso da transferência de tecnologia que foi o CMM. O modelo CMM, hoje atualizado com a versão CMM-I, é um modelo de maturidade onde o conhecimento específico de engenharia de software é base para a avaliação. Os níveis indicam de que maneira a organização produtora de software é madura em relação ao uso de MTF´s (métodos, técnicas, e ferramentas) de Engenharia de Software.

O modelo CMM usa tanto a perspectiva de processo, como são feitas as tarefas, como a perspectiva de documentos, ou seja o tipo de documentos produzidos pela organização. A SEI juntou e continua aperfeiçoando um conjunto de boas práticas que ajudam a caracterizar o nível de maturidade. A cada nível, são cinco os níveis, um conjunto de áreas chave de competência são definidos. A visão de qualidade do CMM é mais voltada para as práticas internas do processo.

Veja abaixo como no meu pre-livro de Engenharia de Requisitos eu classifico os cinco estágios:

Empresas de software podem ser certificadas por consultoras ligadas a SEI que aplicam um processo de avaliação padrão. O custo da implantação das práticas CMM é um investimento alto e o custo da certificação também é alto. Mais detalhes sobre o CMM/CMM-I podem ser encontrados nos elos apontados abaixo.

• Página da Wikipedia (Português)
• Livro “Engenharia de Software com CMM“, de Fiorini, von Staa e Baptista
• Página do curso de Alexandre Vasconcelos na UFPE
• Páginas do SEI: CMM e CMM-I

Algumas organizações brasileiras produtoras de software têm certificação pelo modelo do SEI. Veja aqui um recente relatório do Ministério de Ciência e Tecnologia sobre o assunto. Como o custo para certificação CMM é alto e seu processo é voltado principalmente para organizações americanas, o Brasil, através de um processo de redução sociológica, elaborou normas que medem a maturidade de organizações produtoras de software. Mais detalhes sobre Mps Br podem ser encontrados aqui.

Vale ressaltar que existem outros modelos de avaliação/certificação de qualidade do processo de produção. Dentre esses modelos os que são mais frequentemente utilizados, principalmente por empresas Européias, são os modelo ISO (International Standards Organization). Os modelos derivados da ISO são fundamentalmente orientados a processos e apresentam uma visão sob a ótica do consumidor diferentemente daquela do CMM original. Hoje, os novos modelos da SEI como os da ISO já refletem os impactos do uso de ambas as formas de certificação.

Veja mais detalhes sobre as normas ISO aplicadas a software nos elos abaixo:

• Sítio oficial das normas ISO/IEC.
• Wikipedia em Espanhol.
• Artigo do BateByte.

…………

Leia sobre Sistemas de Informação.

Veja a página do autor.

This entry was posted on agosto 12, 2007 at 2:06 am and is filed under cmm, engenharia de software, falhas, Mps Br, processo de software, software engineering. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.