CMMI, um dos Principais Modelos da Qualidade e o MPS.Br, Modelo Adaptado à Realidade Brasileira
Há algum tempo atrás a produção de software era algo feito sem nenhum processo definido, com nenhum controle sobre possíveis manutenções ou agregação de módulos aos mesmos. Com isto os sistemas antigos tinham um ciclo de vida muito curto e de custo bem alto.
À medida que a complexidade dos projetos aumentava novas tecnologias foram surgindo, e uma necessidade de mudança nos processos de produção foi percebida por empresas que tinham custos altíssimos no desenvolvimento de softwares com um comportamento completamente ad-hoc em sua produção.
Então a computação foi em busca de um modelo que pudesse trazer uma unidade ao processo de desenvolvimento de sistemas. Então foi na Engenharia que se espelhou uma primeira tentativa de uniformidade.
A engenharia de software foi evoluindo e começou a criar conceitos importantes como divisão de software, arquitetura top-down e botton-up, diagramas, modelagens entre tantos outros que nos levaram ao estado atual.
Com esses novos padrões um software deixou de ser uma caixa preta, para ser um conjunto de partes encaixáveis a fim de construir um sistema reutilizável, mais fácil de manter.
Algumas dessas modificações criaram também a oportunidade de mensurar alguns atributos de maneira mais exata e segura. Também se iniciou a possibilidade de prever o tamanho do software antes de sua construção.
Mas, apesar de todas as indicações de que a engenharia de software estava a evoluir, novos fatores surgiam para comprovar a complexidade de produzir software. A complexidades dos sistemas aumentavam muito, a natureza dos negócios se diversificavam bastante e novas tecnologias apareciam modificando completamente definições obtidas anteriormente.
Somado a estes fatores, sempre existiam projetos mal construídos por equipes despreparadas, o que tornava a produção de software bem diferente da produção da engenharia comum. Enquanto os sistemas se tornavam maiores e a natureza dos negócios se multiplicava a engenharia de software também se tornava mais completa e novas tecnologias como UML (Unified Model Language) e RUP (Rational Unified Process) foram criadas.
Os modelos para a avaliação de contextualização podem ser baseados em vários modelos de referência como, por exemplo, do CMM/CMMI-SE/SW [SEI 2005], do modelo exemplar da ISSO 9001 (incluindo 9000-3) [ABNT 2001], ISSO 9001/IEC 15504 ou SPICE [ISO 2003-2005] ou do MR-MPS/ MPS.BR [SOFTEX 2005].
2. A Gestão de Competências e os Modelos da Qualidade
Os modelos de qualidade têm sido criados para ser um guia destinado a melhorar os processos organizacionais e a habilidade deste em gerenciar o desenvolvimento, aquisição e manutenção dos produtos e serviços. Apesar de cada um dos modelos apresentar uma visão própria, eles são unânimes em destacar a importância de preparar o pessoal para o trabalho e gerenciar capacitação, habilidades e programas de treinamento.
Existe uma norma da ISO muito genérica que pode ser aplicada a vários setores, ela tem por nome ISO-9001, e podemos encontrá-la hoje em diversos estabelecimentos. De prestadores de serviços a empresas fabricantes de hardwares poderiam tirar esta certificação.
Esta norma tem algumas regras que se aplicavam no processo de funcionamento da instituição. Mas como vemos o domínio de aplicação dela é muito genérico, e pouco eficiente na prática de aplicações específicas.
Em resposta a isso foi criado pelo SEI (Software Engeneering Institute) o CMM (Capability Mature Model) que verifica o nível de maturidade da empresa em relação ao seu processo. Esse modelo foi baseado em tecnologias de Engenharia de Software como o RUP. Assim era um domínio específico da computação que tinha um suporte a avaliação de uma empresa de desenvolvimento de sistemas.
Este mesmo modelo evoluiu em conjunto com as novas tecnologias surgidas na computação, e se adequava as necessidades criadas por esta evolução. Assim surgiu o CMMI (Capability Mature Model Integration) que abrangia um conjunto ainda maior de requisitos.
Mas estes processos são cobrados em dólares, a realidade nacional é que a grande maioria das empresas é formada por empresas de pequeno e médio porte. Então se percebeu que o CMMI com seus custos em dólares fica impraticável no Brasil aumentando ainda mais o abismo entre empresas grandes e com recursos e empresas emergentes.
Até que a SOFTEX (Sociedade para Promoção da Excelência do Software Brasileiro), um comitê criado para melhoria do software nacional, resolveu tomar uma medida que adequada a realidade brasileira. Com isso baseado no SCAMPI, SPICE e no próprio CMMI, nascia o MPS-Br (Melhoria do Processo de Software Brasileiro).
Esta abordagem além de conter as melhores práticas de cada uma das metodologias de avaliação citadas, tem uma melhor adaptação a realidade nacional, que são pequenas e médias empresas que querem buscar qualificação a um custo acessível de valor reconhecido.
2.1. O Modelo CMM CMMI
O CMMI (Capability Maturity Model Integration) evoluiu e integrou diversos modelos de maturidade anteriormente desenvolvidos (SW-CMM, SE-CMM, IPD-CMM) [SEI 2005b], consolidando um framework que é consistente com a norma ISO/IEC 15504 ou SPICE (Software Process Improvement and Capability dEtermination).
O CMMI possui uma arquitetura basicamente composta pela definição de um conjunto de áreas de processo, organizadas em duas representações diferentes: um modelo por estágio, semelhante ao SW-CMM e um modelo contínuo, semelhante à ISO/IEC 15504. Seu objetivo é representar metas e recomendações genéricas para orientar a melhoria de processos em geral, não existindo soluções prontas para serem institucionalizadas. Na busca por melhorias relevantes, cabe a cada organização entender e interpretar as recomendações em relação ao contexto, objetivo e estratégia de negócio.
A gestão de competências também é apontada como um objetivo das organizações que buscam a melhoria seguindo os modelos de maturidade. Na perspectiva do SW-CMM, a área-chave de processo "Programa de Treinamento" (TP - Nível 3) tem como objetivo "desenvolver os perfis e conhecimentos dos indivíduos de forma que eles possam exercer seus papéis, eficiente e eficazmente" [SEI 2005b]. No modelo CMMI por estágio, a área de processo "Treinamento Organizacional" (OT – Nível 3) possui o mesmo objetivo e orienta a organização a: identificar as necessidades de treinamento, tanto técnicos (para atuação específica em projetos) quanto operacionais (para atuação em processos organizacionais do dia-a-dia); disponibilizar treinamentos; desenvolver mecanismos que assegurem sua efetividade [SEI 2005a].
2.2 O Modelo MPS.BR MR-MPS
O objetivo do MPS.BR está sintetizado no próprio nome: Melhoria de Processo do Software Brasileiro, envolve universidades, grupos de pesquisas e empresas, sob coordenação da SOFTEX. Para isto o MPS.BR está desenvolvendo uma serie de atividades cobrindo deste a elaboração de modelos (MRMPS), elaboração de métodos de avaliação (MA-MPS), elaboração de guia de aquisição, desenvolvimento e aplicação de diversos cursos para capacitação, credenciamento de pessoas e instituições como implementadoras e avaliadoras, ações de disseminação para incentivo a utilização pelas empresas, e outras.Uma das orientações do MPS.BR é entender e consolidar diversas boas experiências, nacionais e internacionais, em melhoria de processo de software e estimular a sua maior disseminação possível no Brasil e pelo menos em outros países da América Latina.
O modelo MR-MPS em sua versão 1.0 [Softex 2005] define 23 processos baseados em processos selecionados da ISO/IEC 12207 Amd.2 e ISO/IEC 15504-5 e nas áreas de processo do CMMI-SE/SW. Sete perfis de capacidade de processo, expressos em termos de processos e de cinco atributos de processo (AP1.1, AP2.1 e 2.2, AP3.1 e 3.2), são definidos como sete níveis de maturidade. Cada nível, introduz alguns processos, mantendo todos os processos dos níveis inferiores e eventualmente, acrescenta novos atributos de processo a todos os processos. Por exemplo, para uma unidade organizacional atender ao nível F de maturidade, ela deve satisfazer os atributos de processo AP1.1, 2.1 e 2.2 para os seguintes seis processos: Gerência de Projeto (GPR), Gerência de Requisitos (GRE), Gerência de Configuração (GCO), Medição (MED), Garantia da Qualidade (GQA) e Aquisição (AQU). Quatro dos sete níveis de maturidade correspondem respectivamente aos quatro níveis de maturidade (2 a 5) do CMMI-SE/SW na representação estagiada.
3. Comparações dos Modelos
No contexto de micro e pequenas empresas de software, alguns métodos de avaliação para melhoria de processo estão sendo desenvolvidos, incluindo, por exemplo, QuickLocus [Kohan, 2003], RAPID [Rout 2000], MARES/15504MPE [Anacleto, et. Al 2005], MA-MPS [SOFTEX 2005]. Basicamente todos estes métodos enfocam em avaliações para orientar a melhoria usando vários modelos de referência, incluindo CMMI-SE/SW, ISO/IEC 15504 ou MR-MPS. Entretanto, a maioria destas abordagens usa um conjunto pré-definido de processos a serem avaliados, como exemplo o RAPID (limitado a um conjunto de 8 processos) ou MA-MPS predefinido pelos níveis de maturidade.
Uma outra abordagem freqüentemente aplicada no contexto de micro e pequenas empresas no início de uma iniciativa de melhoria é a realização de miniavaliações ou como, por exemplo, no contexto do CMMI a realização de avaliações classe C. Neste contexto, vários métodos foram também desenvolvidos principalmente por empresas de consultoria, mas que não são disponíveis publicamente.
No comparativo de atendimento dos modelos da qualidade:
• CMMI: Processo de Apoio Nível 3: “Treinamento Organizacional” com o propósito de desenvolver as habilidades e conhecimentos das pessoas, de forma que elas possam desempenhar seus papéis de maneira efetiva e eficiente.
• MPS.BR: Processo de Apoio Nível E: “Treinamento” com o propósito de prover a organização e os projetos com profissionais que possuam os conhecimentos e as habilidades necessárias para executar suas funções de forma efetiva.
6. Conclusão
Podemos observar que devido a complexidade dos projetos se tornar imensa e o surgimento de várias tecnologias uma necessidade de mudança nos processos de produção era necessária. Então a computação foi em busca de um modelo de engenharias de software a fim de formalizar uma unidade ao processo de desenvolvimento de sistemas.
Neste trabalho vimos como ocorreu o surgimento dos modelos para formar unidade ao processo de desenvolvimento de sistemas, aprendeu-se um pouco mais sobre um dos principais modelos internacionais (CMMI) comparado ao modelo adaptado a realizade brasileiro (MPS.BR)
Referências
WANGENHEIM, Gresse von, PICKLER, Kênia Karim, THIRY, Marcello, ZOUCAS, Alessandra Casses e SALVIANO, Clenio Figueiredo (2005) “Aplicando Avaliações de Contextualização em Processos de Software Alinhados ao CMMI-SE/SW”. Disponível em: http://www.simpros.com.br/upload/A01_1_artigo14900.pdf, acessado em novembro.
JÚNIOR, Andrade de Santana (2005) “Mapeamento do modelo de Melhoria do Processo de Software Brasileiro (MPS-Br) para empresas que utilizam metodologia Extreme Programming (XP) como metodologia de desenvolvimento”. Dsiponivel em: http://www.cin.ufpe.br/~tg/2005-2/casj-proposta.doc, acessado em novembro.
DE PETRI1, Flávia, RODRIGUEIRO, Juliana, MAPELLI, Luiz, OLIVEIRA, Vera Lúcia e SALVIANO , Clênio F. (2005) “Uma Experiência de Capacitação e Início de Melhoria de Processo de Software com o Método PRO2PI-WORK”. Dsiponível em: http://www.cin.ufpe.br/~tg/2005-2/casj-proposta.doc, acessado em novembro.
SALVIANO, Clênio F. e TSUKUMO, Alfredo (2005) “Introdução aos Modelos de Capacidade de Processo do CMMI, MPS-BR, ISO/IEC 15504 e outros”. Dsiponível em: http://www.simpros.com.br/upload/T1_tutorial.pdf, acessado em novembro.
Autor: Elias Lopes
Artigos Relacionados
A Essencialidade Da Engenharia De Software
Mda
Evolução De Software Usando Genexus
Estratégia De Testes
Quando Aplicar A Reengenharia De Software
Engenharia De Componentes
Engenharia De Software