Logomarca IETEC

Buscar no TecHoje

Preencha o campo abaixo para realizar sua busca

Uma Análise sobre a Importância da Utilização do CMM e MPS-BR na Garantia da Qualidade do Produto

Renata Diniz Viana

Analista de sistemas formada em Ciência da Computação na Universidade FUMEC. Atua como analista de sistemas no BDMG.

rdinizviana@gmail.com

2. Introdução

Desenvolver software de qualidade assegurada, com elevada produtividade, dentro do prazo estabelecido e sem necessitar de mais recursos do que os alocados tem sido o grande desafio de Engenharia de Software.
Freqüentemente surgem defensores de soluções miraculosas apresentadas sob a forma de ferramentas, métodos outra tecnologia qualquer. Sabe-se que, infelizmente, tais soluções não existem.
Segundo os idealizadores do CMM, 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. Um processo, em nível mais macro cruza horizontalmente várias funções da organização.


3. Referencial Teórico
3.1 Qualidade de software
Qualidade de programas não é somente uma questão de correção ou confiabilidade. Sem dúvida estas propriedades são fundamentais, porém existem muitos exemplos de programas confiáveis e que, no entanto, não são vistos pelo usuário como possuidores de elevada qualidade. 
Qualidade de programas tem que ser projetada (definição de um padrão) e depois verificada (comparação com o padrão, controle de qualidade). Precisamos pois de um instrumento para a especificação e o controle de qualidade (Staa, 1987).
De uma forma genérica, podemos dizer que um software de boa qualidade produz resultados úteis e confiáveis na oportunidade certa; é ameno ao uso; é mensurável e pode ser auditado; é corrigível, modificável, e de fácil evolução; opera em máquinas e em ambientes reais; foi desenvolvido de forma econômica e no prazo estipulado; e opera com economia de recursos. Qualidade de software é, pois, um conceito muito mais amplo do que software correto e bem documentado, requerendo para ser conseguida, métodos e técnicas de desenvolvimento específicas. (Staa, 1987).
Para Alexandre Bartié, (2002) qualidade de software é um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos.
Segundo o professor Marcos Roberto Rodrigues (2001), qualidade não é um fator de vantagem no mercado, mas é uma necessidade para a garantia da competitividade. 
Algumas iniciativas vêem surgindo visando a melhoria da qualidade de software como CMM, ISO, MSP-BR no Brasil.

3.2 CMM

O CMM – Capability Maturity Model para software é um conjunto de processos desenvolvido pela SEI – Software Engineering Institute (www.sei.cmu.edu) em 1986. 
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. (Fagundes, 1996).
Segundo Ana Cristina Melo (2003), O CMM 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.  Entende-se por aprimoramento contínuo, um processo em que se observa a forma de trabalhar, identificam-se problemas inerentes a esta forma, eliminam-se estes problemas, passa-se a trabalhar na nova modalidade, voltando a observar.
Para que o CMM obtenha sucesso, é necessário que se tenha o apoio da direção da empresa, além de um bom domínio de conhecimento, habilitação técnica, e participação e esforço de todos os envolvidos. (Ana Cristina Melo, 2003).

Descreve uma estrutura de trabalho que possui todos os elementos necessários para tornar um processo de desenvolvimento de software mais eficiente e controlado. O CMM baseia-se em um modelo evolutivo de maturidade, no qual as organizações partem de uma total falta de controle e gerenciamento dos processos (imaturidade organizacional) para gradativamente adquirir novas competências, incrementando seu nível de eficiência e maturidade em relação aos diversos processos críticos envolvidos em um desenvolvimento de software. (BARTIÉ, 2002).


3.2.1 Níveis de Maturidade

O CMM possui níveis de maturidade que estabelecem um conjunto coerente de metas que, quando satisfeitas em seu conjunto, melhoram a capacitação da organização e fazem com que desenvolvam software de forma mais organizada, cada vez com menos problemas de qualidade e menos erros de estimativa de prazo e de necessidade de recursos.
Nível de maturidade é um estágio evolutivo bem definido em busca de um processo de software maduro. Cada nível de maturidade fornece uma gama de fundamentos para a melhoria contínua do processo. Cada nível compreende um conjunto de objetivos de processos que, quando satisfeitos, estabilizam um componente importante do processo de software. Alcançando cada nível da estrutura de maturidade, estabelece-se diferentes componentes no processo de software, resultando em um crescimento na capacidade de processo da organização. (Villas-Boas e Gonçalves, 2001).
O CMM é dividido em cinco níveis de maturidade conforme a figura abaixo:


Figura 1: Níveis de maturidade do CMM
Fonte: FAGUNDES, 2005.

Definição dos níveis de maturidade do CMM:
Nível 1 – Inicial: Processo imprevisível e quase sem controle.  Não há controle de requisitos e o cliente só os avalia na entrega do produto. O sucesso depende da disponibilidade de um excepcional gerente, bem como de uma equipe de desenvolvedores eficientes.  Cronogramas, orçamentos, funcionalidades e qualidade de produtos são geralmente imprevisíveis. Estar no nível 1 não significa que uma organização não possa produzir um produto software.  O que ocorre é que a capacitação não é da organização e sim das pessoas, se um produto é entregue com sucesso. (Ana Cristina Melo, 2003).
Nível 2 – Repetitivo: Desenvolvimentos bem sucedidos podem ser repetidos. Os projetos nas organizações de nível 2 possuem controles básicos de gestão de software. Os compromissos realistas do projeto são baseados em resultados observados em projetos anteriores e nos requisitos do projeto atual. Os gerentes de software do projeto acompanham custos, cronogramas e funcionalidades do software; os problemas com compromissos são identificados quando surgem. Os requisitos e os produtos de trabalho de software desenvolvidos para satisfazê-los são armazenados de forma criteriosa e a integridade dos mesmos é controlada. Os padrões do projeto de software são definidos e a organização garante que eles sejam seguidos fielmente. Existindo subcontratados, o projeto de software trabalha em conjunto com os mesmos, visando fortalecer a relação cliente-fornecedor. (Villas-Boas e Gonçalves, 2001).
Nível 3 – Definido: Após atingir o estágio de repetir as práticas de desenvolvimento com sucesso, as organizações de desenvolvimento de aplicações devem identificar as melhores práticas dos melhores projetos. Subseqüentemente, esses procedimentos são integrados aos padrões de desenvolvimento para toda a organização. Conseqüentemente, uma forte cultura é desenvolvida no nível 3 com a utilização de processos comuns que cobrem os mais importantes elementos do desenvolvimento de aplicações. Uma vez todos os projetos utilizando as melhores práticas e compartilhando lições de aprendizagem, existe o amadurecimento da organização. (Fagundes, 1996).
Nível 4 – Gerenciado: Tendo atingindo o estágio 3 com a utilização de processos comuns nos projetos de desenvolvimento de software, as organizações estão capacitadas a gerar estatísticas que possam caracterizar o desempenho de seus processos. Essas estatísticas provêem informações para se entender a capacidade de desenvolvimento baseado nos processos e as causas das variações de desempenho. Gerenciando o desempenho dos processos de desenvolvimento estatisticamente, uma organização pode prever e controlar os resultados dos projetos. O gerenciamento da quantidade produzida permite um grande envolvimento dos times de projeto e melhorar a previsão dos resultados pelo gerenciamento de projetos. (Fagundes, 1996).
Nível 5 – Em Otimização: Melhorias contínuas podem ser desenvolvidas através das lições de aprendizagem de cada projeto através de ações pró-ativas durante a avaliação de novos métodos de desenvolvimento, novos processos ou tecnologias. Uma organização com um nível de maturidade 5 estabelece uma infra-estrutura para suportar continuas mudanças no gerenciamento dos processos de desenvolvimento. (Fagundes, 1996).

3.3 MPS-BR

Uma das metas do MPS-BR visa definir e aprimorar um modelo de melhoria e avaliação de processo de software, visando preferencialmente as micro, pequenas e médias empresas, de forma a atender as suas necessidades de negócio e ser reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software. O MPS.BR também estabelece um processo e um método de avaliação, o qual dá sustentação e garante que o MPS-BR seja empregado de forma coerente com as suas definições. (Softex, 2006).

3.3.1 Níveis de Maturidade
Os níveis de maturidade estabelecem patamares de evolução de processos, caracterizando estágios de melhoria da implementação de processos na organização. O nível de maturidade em que se encontra uma organização permite prever o seu desempenho futuro ao executar um ou mais processos. O MPS-BR define sete níveis de maturidade: A (Em Otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). A escala de maturidade se inicia no nível G e progride até o nível A. Para cada um destes sete níveis de maturidade é atribuído um perfil de processos que indicam onde a organização deve colocar o esforço de melhoria. O progresso e o alcance de um determinado nível de maturidade MPS se obtêm quando são atendidos os propósitos e todos os resultados esperados dos respectivos processos e dos atributos de processo estabelecidos para aquele nível. (Softex, 2006).



Tabela 1 - Níveis de maturidade doMPS-BR.

4. Pesquisa
A metodologia utilizada neste trabalho foi constituída apenas de pesquisa teórica baseada na análise de textos retirados de levantamento bibliográfico de livros, sites de internet com artigos sobre CMM e MPS-BR, revistas, periódicos e pressupostos teóricos apresentados.

4.1 Fatores que dificultam a implantação do CMM

Podemos citar alguns fatores que podem dificultar a implantação do CMM dentre eles:
Falta de recursos financeiros;
Falta de mão de obra especializada;
Resistência a mudanças culturais (problemas com a institucionalização);
Prioridade para o “manter”, pouco foco no “empreender”;
Gestores despreparados, muitas vezes com bagagem defasada;
CMMI não está alinhado às exigências dos clientes;
Gestores despreparados, muitas vezes com bagagem defasada;
Divergência com os interesses dos acionistas;
Resistência a mudanças culturais (problemas com a institucionalização);

4.2 CMM X MPS-BR

Apesar dos dois modelos de desenvolvimento terem sido criados com o mesmo propósito, o foco de atuação dos modelos são diferentes um do outro.
Enquanto o MPS BR é um modelo criado em função das médias e pequenas empresas, o CMM tem um foco global mais voltado para as empresas de maior porte.
Enquanto o CMM é reconhecido internacionalmente e tornou-se uma referencia no mercado, o MPS-BR é mais adequado à realidade brasileira. Foi criado com o objetivo de ser um modelo de processo mais rápido de ser adquirido e mais acessível que outros modelos como o CMM, porém a certificação MSP-BR não competitiva o suficiente para tornar a empresa competitiva internacionalmente. Nesse caso, o MPS-BR torna-se uma boa opção para ser uma preparação para a certificação CMM.
Contudo apesar dessas diferenças é possível afirmar que na realidade brasileira os modelos são complementares. As médias e pequenas empresas
adotam o MPS BR com o objetivo de conseguir alcançar uma padronização e qualidade no processo com mais velocidade e de baixo custo. Uma vez alcançada essa padronização a empresa já se encontra qualificada para tentar obter a certificação CMM.




Figura 2 – Comparação entre os níveis de maturidade do MPS.BR e o CMM.

Fonte: http://www.camilaoliveira.net/Arquivos/Comparando%20CMMi%20x%20MPS.pdf

 

1.1 Algumas empresas brasileiras certificadas

 

Segue abaixo alguns exemplos de empresas brasileiras certificadas no CMM:

·         Nível 2:

o   MSA Informática – MG (2002)

o   Inatel – MG (2003)

o   General Motors – SP (2005)

o   ATT/PS Informática – MG (2009)

o   Avansys Tecnologia – BA (2009)

·         Nível 3:

o   DBA Engenharia de Sistemas – RJ (2001)

o   Politec – SP (2005)

o   Spress Informática S/A – MG (2007)

·         Nível 4:

o   Ci&T – SP (2006)

o   EDS – RJ (2003)

·         Nível 5:

o   Accenture – SP (2005)

o   Unisys – MG (2005)

o   IBM – RJ (2005)

Segue abaixo alguns exemplos de empresas brasileira certificadas em MPS-BR:

·         Nível G:

o   CADSOFT – MG

o   EMPRO – SP

o   INFOCARD – ES

o   PRODABEL – MG

o   QUANTUM – MG

·         Nível F:

o   AZ Informática –MS

o   BANCO DO BRASIL – DF

o   CASA DE SOFTWARE – MG

·         Nível E:

o   COPPE/UFRJ – RJ

o   INFORMAL INFORMÁTICA – RJ

o   IVIA – CE

·         Nível D:

o   Não existe nenhuma empresa certifica nível D.

·         Nível C:

o   POWERLOGIC – MG

o   SYNAPSIS – RJ e CE

o   BRQ – PR

·         Nível B:

o   Não existe nenhuma empresa certifica nível B.

·         Nível A:

o   CPM BRAXIS/UNITECH – BA

o   POLITEC – DF

o   STEFANINI – SP

 

 

 

 

Informações retiradas do site http://www.blogcmmi.com.br, atualizadas em 07de agosto de 2010. Acesso em 11/09/2010.

 

2.    Conclusão

A partir do estudo abordado, pode-se concluir a importância de utilização de um processo de software bem definido nas organizações. Todas as decisões tomadas durante o desenvolvimento de software comprometem a qualidade final do produto, sendo esse, resultado final de todas as decisões e realizações ocorridas durante o ciclo de desenvolvimento. Portanto, quando existe a necessidade de se produzir software de alta qualidade é necessário um investimento em todos os pontos existentes no processo.

Com base nessas necessidades, o CMM, surge como uma proposta capaz de viabilizar a produção de softwares de qualidade. Propõe elementos necessários para tornar o processo de desenvolvimento de software mais eficiente e controlado de forma gradativa. Com isso, torna-se mais fácil a produção de software de qualidade quando se adota os procedimentos propostos pelo CMM. Ainda é pouco utilizado no Brasil, devido à sua complexidade de implementação e ao alto custo, porém muitas empresas brasileiras, principalmente de grande porte, já estão aderindo ao CMM no Brasil.

Outra opção para as empresas se certificarem em um processo de desenvolvimento de software é o MPS-BR. É uma opção mais rápida e mais barata, indicada principalmente para empresas de médio e pequeno porte. Uma vez conseguido a certificação MPS-BR a empresa fica mais perto da certificação CMM.

Dessa forma, para manter essa qualidade dos softwares, as organizações precisam se adequar aos padrões exigidos pelo mercado tornando-se competitivas e o mercado atual está cada vez mais exigente com relação à qualidade dos softwares produzidos. Esse fato é conseqüência de um aumento na complexidade do software e um crescimento significativo na dependência de processos automatizados em todos os tipos de organizações.

 

3.    Referência Bibliográfica

BARTIÉ, Alexandre. Garantia da qualidade de software. Rio de Janeiro: Campus, 2002.

 

FAGUNDES, Eduardo Mayer. Capability Maturity Model for Software. Disponível em: .

           

MELO, Ana Cristina. Engenharia de software: CMM. Belo Horizonte: 2003. (Texto não publicado).

 

RODRIGUES, Marcos Roberto. Qualidade de Software. Belo Horizonte: 2001. (Texto não publicado).

 

SOFTEX, MPS.BR - Melhoria de Processo do Software Brasileiro. Guia Geral. Disponível em .

 

STAA, Arndt Von. Engenharia de Programas. Rio de Janeiro: Livros Técnicos e Científicos Editora LTDA, 1987.

 

VILLAS-BOAS, André; GONÇALVES, José Marcos. Modelo de Maturidade de Capabilidade de Software (CMM). Campinas, 2001. (Texto não publicado).

 

 

Indique este artigo a um amigo

Indique o artigo