______________________
*elvis.fs@gmail.com. Programador de Computador. Prefeitura Municipal de Governador Valadares. Bacharel em Ciência da Computação. Universidade Vale do Rio Doce
** profamarta@gmail.com. Mestre em Administração e Planejamento de Sistemas de Informação. PUCCAMP. Especialista em Informática em Educação. UFLA. Sócia-Gerente ZAP Consultoria e Treinamentos.
*** helder@ipplus.com.br. Mestre em Ciências e Técnicas Nucleares. UFMG. Coordenador do curso de Gestão de Tecnologia da Informação. SENAC/MG.
VANTAGENS DA APLICAÇÃO DO PROGRAMA DE MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO MPS.BR NOS AMBIENTES DE
DESENVOLVIMENTO DE SOFTWARE
Elvis Ferreira da Silva* Msc. Marta Alves de Souza** Msc. Helder Rodrigues da Costa***
RESUMO
O presente trabalho objetiva identificar as principais vantagens obtidas na implementação de práticas de gerenciamento de processos no desenvolvimento de softwares, sendo conduzido por meio do estudo do modelo de melhoria de processos MPS.BR, que engloba um conjunto de práticas para gestão de processos de software e é especialmente voltado às micro, pequenas e médias empresas. A abordagem inicia-se a partir da analise dos problemas que ameaçam o sucesso dos projetos de software, através da revisão bibliográfica dos principais autores da área e segue com a pesquisa nas publicações disponíveis no sítio da Softex, instituição responsável pela gestão do modelo MPS.BR. Identificou-se que a adoção dos processos descritos no MPS.BR permite a organização obter maior previsibilidade, com definição de cronogramas confiáveis e melhor análise dos custos do produto de software.
Palavras chave: Software, Desenvolvimento de Software, Processo, Processos de Software,
Modelo. MPS.BR
1 INTRODUÇÃO
O avanço da tecnologia, sobretudo a partir do início do século XXI, vem automatizando os mais variados processos nos diversos segmentos da sociedade: a simples tarefa de fotografar, que antes era composta de vários processos, hoje se resume a um clique na máquina fotográfica e a sua transferência para o computador, e em poucos segundos a fotografia pode ser enviada para qualquer lugar do planeta, isso sem falar nos complexos sistemas de controle empresariais e industriais. O uso de equipamentos eletrônicos que empregam softwares está cada vez mais presente no dia a dia das pessoas.
Nesse contexto, a importância de se produzir softwares com qualidade e que atendam às necessidades e aos prazos estabelecidos é cada vez mais evidente, sendo um fator primordial para a sobrevivência das empresas no mercado.
Com objetivo de profissionalizar o processo de produção de softwares, diversas parcerias entre instituições governamentais, universidades e empresas contribuíram para definição de modelos que reúnem melhores práticas de desenvolvimento. A adoção de modelos permite maior gerenciamento dos processos, garantindo a entrega dentro dos prazos previstos e qualidade final do produto de software.
Neste contexto, quais as vantagens obtidas na implementação do Modelo de Melhoria de Processos de Software MPS.BR?
Desta forma, o objetivo deste estudo é detalhar o modelo MPS.BR (Melhoria de Processo de Melhoria de Software Brasileiro), identificar as vantagens obtidas através da sua implementação nos ambientes de desenvolvimento de software.
2 REFERENCIAL TEÓRICO
2.1 O que é software?
Segundo Pressman (1995), um software é um conjunto de instruções que, quando executadas, produzem a função e o desempenho desejados, além disso, faz parte da definição do software toda a documentação que descreve a sua operação e uso.
A utilização do software nos diversos equipamentos eletroeletrônicos tem se tornado comum, sendo que a maioria dos processos pode ser automatizada através de aplicações desenvolvidas por computador.
2.2 Crise do software
Há várias décadas, diversos problemas relacionados ao software preocupam os profissionais que administram o desenvolvimento de aplicações: por ser produto de uma atividade puramente intelectual, existe dificuldade em mensurar seu tamanho, dificultando a definição de cronogramas e comprometendo a entrega do produto no prazo acordado, além disso, problemas na comunicação entre desenvolvedores e clientes comumente fazem com que o produto não atenda às necessidades dos usuários.
De acordo com Pressman (1995), os problemas não se limitam a software que não funciona adequadamente. Ao contrário, os problemas estão associados à forma como software é desenvolvido, como é mantido o volume crescente de software existente e como acompanhar a crescente demanda.
Segundo Pressman (1995), entre as características dos problemas que afligem o desenvolvimento de software estão a imprecisão das estimativas de prazo e de custo, a falta de
qualidade do produto final e a produtividade dos profissionais da área, que não tem acompanhado a demanda por seus serviços.
A qualidade de software frequentemente é suspeita. Só recentemente começou-se a entender a importância dos testes de software sistemáticos e tecnicamente completos. Somente agora estão surgindo conceitos quantitativos sólidos de confiabilidade e garantia de qualidade de software. (PRESSMAN, 1995, p. 22).
2.3 O que é processo?
De acordo com Oliveira (2006), tudo o que é realizado é feito por meio de um processo produtivo. A construção de um software ou até mesmo o ato de tomar um banho possui, essencialmente, os mesmos conceitos envolvidos: um produtor, um cliente, um sistema de produção, que é constituído pelo conjunto de operações mais os recursos produtivos e os bens e serviços produzidos, e um ambiente (Sociedade, Governo, concorrentes etc).
Um processo é um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos, práticas e transformações, usado para atingir uma meta. Esta meta geralmente está associada a um ou mais resultados concretos finais, que são os produtos da execução do processo. (PAULA FILHO, 2000, p. 23)
Segundo Paula Filho (2000), o processo de software engloba um conjunto de atividades, métodos, práticas e transformações, usado para desenvolver e manter produtos de software, que inclui os artefatos associados, como documentos e modelos.
Paula Filho (2000) afirma que no âmbito da engenharia de software os processos podem ser definidos para atividades como desenvolvimento, manutenção, aquisição e contratação de software. O processo de desenvolvimento possui atividades como análise e determinação de requisitos, desenho, implementação e testes. Em organizações com baixa maturidade de capacitação em software, os processos geralmente são informais, existindo apenas na cabeça de seus praticantes. Por outro lado, um processo definido tem documentação que detalha todos os seus aspectos importantes: o que é feito, quando, por quem, as coisas que usa e as coisas que produz.
2.4 Qualidade de Software
Segundo Pressman (2002 apud Oliveira, 2006), no campo da Engenharia de Software tem-se duas abordagens para medir a qualidade: a qualidade do processo, que abrange características referentes ao processo de software como o esforço humano despendido, tempo gasto, cumprimento de cronograma, etc. e a qualidade do produto, que diz respeito a atributos desejáveis para o artefato de software, tais como facilidade de uso, rapidez de processamento, funcionalidade, confiabilidade, eficiência, manutenabilidade, portabilidade, entre outros.
Para Paulk et al (1994 apud OLIVEIRA, 2006), uma suposição básica da gestão de qualidade é que a qualidade do processo influencia diretamente a qualidade do produto. De acordo com Paula Filho (2001 apud OLIVEIRA, 2006), há outros determinantes da qualidade do produto como a capacidade do pessoal e a tecnologia usada no processo; não obstante, o investimento na qualidade do processo pode trazer retorno em prazos mais curtos.
Paula Filho (2000) entende como qualidade de um produto o seu grau de conformidade com os respectivos requisitos. Neste sentido, por exemplo, um carro popular pode ser de boa qualidade, e um carro de luxo pode ser de má qualidade. Sendo que a comparação com os respectivos requisitos decide a qualidade de cada produto.
2.5 Melhoria de Processos de Software
As mudanças que estão ocorrendo nos ambientes de negócios têm motivado as empresas a modificar estruturas organizacionais e processos produtivos, saindo da visão tradicional baseada em áreas funcionais em direção a redes de processos centrados no cliente. A competitividade depende, cada vez mais, do estabelecimento de conexões nestas redes, criando elos essenciais nas cadeias produtivas. Alcançar competitividade pela qualidade, para as empresas de software, implica tanto na melhoria da qualidade dos produtos de software e serviços correlatos, como dos processos de produção e distribuição de software. (GUIA GERAL 2009, p. 6)
Paula Filho (2000) afirma que programas de melhoria de processos devem ser justificáveis através de análises de retorno do investimento, que procuram medir, para cada unidade monetária investida, quantas unidades monetárias retornam em determinado prazo, através da redução de custos ou do aumento da renda. Dentre as práticas da Engenharia de Software, devem ser priorizadas as práticas com melhor retorno de investimento.
De acordo com Jones, McConnell (1994, 1996 apud Paula Filho, 2000), os dados seguintes, sustentam algumas das práticas mais prioritárias para melhoria dos processos:
• Captar um requisito correto é 50 a 200 vezes mais barato que corrigí-lo durante a implementação ou em operação. Portanto, a engenharia e a gestão dos requisitos estão entre as práticas de maior retorno de investimento.
• Fazer um desenho correto é 10 vezes mais barato que corrigi-lo durante os testes de aceitação. Portanto, o desenho tem forte impacto nos custos dos projetos, embora menos que a engenharia de requisitos.
• Refazer defeitos de requisitos, desenho e código consome 40% a 50% do custo total dos projetos. Portanto, a garantia da qualidade se paga rapidamente, na medida em que diminui a necessidade de refazer.
• Cada hora gasta em prevenção de defeitos representa de 3 a 10 horas menos de correção de defeitos. Dentre as atividades de qualidade, as atividades ligadas à prevenção de defeitos são mais eficazes que aquelas que focalizam a correção.
2.5.1 ISO/IEC 12207:2008
Segundo a SOFTEX (2009), a Norma Internacional ISO/IEC 12207 foi criada através de um esforço conjunto da ISO (International Organization for Standardization) e do IEC (International Electrotechnical Commission). Sendo publicada sua versão brasileira no ano de 1998, acrescida das iniciais NBR.
De acordo com a SOFTEX (2009), nos anos 2002 e 2004, com objetivo de representar a evolução da Engenharia de Software e a melhorar a compatibilidade com a norma ISO/IEC 15504, foram feitas atualizações, que criaram novos processos, além de expandir o escopo de alguns existentes. A norma ISO/IEC 12207:2008 foi publicada também como padrão IEEE (IEEE Std 12207:2008) e estabelece uma arquitetura comum para o ciclo de vida de processos de software. Contêm processos, atividades e tarefas a serem aplicadas durante o fornecimento, aquisição, desenvolvimento, operação, manutenção e descarte de produtos de software, bem como partes de software de um sistema. Sendo também aplicada na aquisição de serviços.
2.5.2 ISO/IEC 15504
Segundo a SOFTEX (2009), a ISO, através de um estudo sobre a necessidade de se avaliar processos de software, concluiu que era necessária a elaboração de uma norma que fosse aplicável à melhoria de processos e à determinação da capacidade. Este padrão deveria considerar os métodos e normas já existentes, como o SW-CMM® (Software Capability Maturity Model) e a ISO 9001, além disso, deveria abranger todos os processos de software e ser construído pelos especialistas que já desenvolviam e trabalhavam com os métodos e normas existentes à época. Em janeiro de 1993 iniciou-se o projeto SPICE (Software Process Improvement and Capability dEtermination) que tinha o objetivo inicial de produzir um relatório técnico originando a norma ISO/IEC 15504.
De acordo com a SOFTEX (2009), o objetivo da norma ISO/IEC 15504 é promover a melhoria de processos e a determinação da capacidade de processos de uma unidade organizacional. Caso o objetivo de uma organização seja a melhoria de processos, pode-se realizar uma avaliação que definirá um perfil dos processos sendo este usado para a elaboração de um plano de melhorias. A análise dos resultados identifica os pontos fortes, os pontos fracos e os riscos inerentes aos processos. No segundo caso, a organização tem o objetivo de avaliar um fornecedor em potencial, obtendo o seu perfil de capacidade, permitindo a contratante estimar o risco associado à contratação daquele fornecedor.
2.5.3 CMMI-DEV®
Segundo a SOFTEX (2009), a pedido do Departamento de Defesa dos Estados Unidos foi desenvolvido pelo SEI (Software Engineering Institute) o modelo de melhoria SW-CMM® (Software Capability Maturity Model). A partir de 1991, foram desenvolvidas versões do modelo CMM para as disciplinas de Engenharia de Sistemas, Engenharia de Software, Aquisição de Software, Gerência e Desenvolvimento da Força de Trabalho, Desenvolvimento Integrado do Processo e do Produto. O uso de múltiplos modelos tornou-se um problema, surgindo então o CMMI, que é o resultado da evolução do SW-CMM®, SECM® (System Engineering Capability Model) e IPD-CMM® (Integrated Product Development Capability Maturity Model). Além disso, o CMMI foi desenvolvido para ser consistente e compatível com a ISO/IEC 15504. Em 2006 foi publicada a versão 1.2 do CMMI®, o CMMI-DEV® (CMMI for Development).
2.5.4 MPS-BR (Programa de Melhoria de Processo de Software Brasileiro)
De acordo com a SOFTEX (2009), o modelo MPS é um programa criado em Dezembro de 2003, coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX) e conta com apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP), do Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) e do Banco Interamericano de Desenvolvimento (BID). Ele baseia-se nos conceitos de maturidade e capacidade de processo para a avaliação e melhoria da qualidade e produtividade de produtos de software e serviços relacionados. Sendo adequado ao perfil de empresas com diferentes tamanhos e características, públicas e privadas, especialmente as micro, pequenas e médias empresas.
Segundo a SOFTEX (2009), o MPS.BR estabelece um modelo de processos de software (MR-MPS), um processo (Aquisição) e um método de avaliação de processos (MA-MPS). Além disso, estabelece um modelo de negócio para apoiar a sua adoção pelas empresas brasileiras desenvolvedoras de software. Sua compatibilidade com as normas internacionais ISO/IEC 12207 e ISO/IEC 15504, e sua conformidade com o modelo CMMI-DEV, que são padrões de qualidade aceitos internacionalmente o coloca em consonância com as principais abordagens internacionais para definição, avaliação e melhoria de processos de software.
De acordo com a SOFTEX (2009), o MPS.BR conta com duas estruturas de apoio para o desenvolvimento de suas atividades, o Fórum de Credenciamento e Controle (FCC) e a Equipe Técnica do Modelo (ETM). Através delas, obtém a participação de representantes de universidades, instituições governamentais, centros de pesquisa e de organizações privadas,
que contribuem com suas visões.
O FCC emite parecer que subsidia as decisões da SOFTEX sobre o credenciamento ou descredenciamento das Instituições Implementadoras e Instituições Avaliadoras.
Compete à ETM apoiar a SOFTEX sobre os aspectos técnicos, permitindo a criação e aprimoramento contínuo do MR-MPS, MA-MPS e seus guias específicos, além de capacitar pessoas por meio de cursos, provas e workshops.
Neste contexto, segundo a SOFTEX (2009), o modelo MPS possui três componentes: Modelo de Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS).
O modelo MPS está descrito por meio de documentos em formato de guias:
• Guia Geral: contém a descrição geral do modelo MPS e detalha o Modelo de Referência (MR-MPS), seus componentes e as definições comuns necessárias para seu entendimento e aplicação;
• Guia de Aquisição: descreve um processo de aquisição de software e serviços correlatos. É descrito como forma de apoiar as instituições que queiram adquirir produtos de software e serviços apoiando-se no MR-MPS;
• Guia de Avaliação: descreve o processo e o método de avaliação MA-MPS, os requisitos para avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras (IA);
• Guia de Implementação: série de dez documentos que fornecem orientações para implementar nas organizações os níveis de maturidade descritos no Modelo de Referência MR-MPS.
Figura 1: Componentes do modelo MPS Fonte: (GUIA GERAL 2009 p. 13)
O Guia de Implementação está subdividido em 10 partes, contemplando, respectivamente, os seguintes níveis de maturidade:
• Parte 1: Nível G (Parcialmente Gerenciado) • Parte 2: Nível F (Gerenciado)
• Parte 3: Nível E (Parcialmente Definido) • Parte 4: Nível D (Largamente Definido) • Parte 5: Nível C (Definido)
• Parte 6: Nível B (Gerenciado Quantitativamente) • Parte 7: Nível A (Em Otimização)
• Parte 8: Níveis G a A (Implementação do MR-MPS em organizações que adquirem software);
• Parte 9: Níveis G a A (Implementação do MR-MPS em organizações do tipo Fábrica de Software);
• Parte 10: Níveis G a A (Implementação do MR-MPS em organizações do tipo Fábrica de Teste).
De acordo com a SOFTEX (2009), os níveis de maturidade definem 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. 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 são
obtidos quando são atendidos os propósitos e todos os resultados esperados dos respectivos processos e os resultados esperados dos atributos de processo estabelecidos para aquele nível. A seguir são descritos, de acordo com a SOFTEX (2009), os atributos dos processos do modelo de referência MR-MPS:
• O processo é executado (AP 1.1) – mede o quanto o processo atinge o seu propósito. • O processo é gerenciado (AP 2.1) - mede o quanto a execução do processo é
gerenciada.
• Os produtos de trabalho do processo são gerenciados (AP 2.2) – mede o quanto os produtos de trabalho produzidos pelo processo são gerenciados apropriadamente. • O processo é definido (AP 3.1) – mede o quanto um processo padrão é mantido para
apoiar a implementação do processo definido.
• O processo está implementado (AP 3.2) – mede o quanto o processo padrão é efetivamente implementado como um processo definido para atingir seus resultados. • O processo é medido (AP 4.1) mede o quanto os resultados de medição são usados para assegurar que a execução do processo atinge os seus objetivos de desempenho e apóia o alcance dos objetivos de negócio definidos.
• O processo é controlado (AP 4.2) mede o quanto o processo é controlado estatisticamente para produzir um processo estável, capaz e previsível dentro de limites estabelecidos.
• O processo é objeto de melhorias e inovações (AP 5.1) mede o quanto as mudanças no processo são identificadas a partir da análise de defeitos, problemas, causas comuns de variação do desempenho e da investigação de enfoques inovadores para a definição e implementação do processo.
• O processo é otimizado continuamente (AP 5.2) mede o quanto as mudanças na definição, gerência e desempenho do processo têm impacto efetivo para o alcance dos objetivos relevantes de melhoria do processo.
O quadro 1 apresenta os níveis de maturidade do modelo de referência com os respectivos processos e atributos dos processos requeridos.
Fonte: (GUIA GERAL 2009 p. 22)
Segundo a SOFTEX (2009), alguns processos podem ser total ou parcialmente excluídos do escopo de uma avaliação por não serem pertinentes ao negócio da unidade organizacional que está sendo avaliada.
3 METODOLOGIA
A pesquisa qualitativa, de acordo com Godoy (1995), envolve a obtenção de dados descritivos sobre pessoas, lugares e processos interativos pelo contato direto do pesquisador com a situação estudada, procurando compreender os fenômenos segundo a perspectiva dos sujeitos, ou seja, dos participantes da situação em estudo.
Segundo Gil (1999) um trabalho é de natureza exploratória quando envolve várias bibliografias com a finalidade básica de desenvolver, esclarecer e modificar conceitos e idéias para a formulação de abordagens posteriores.
Desta forma, este estudo foi realizado através de pesquisa exploratória e revisão bibliográfica no Guia Geral do modelo MPS.BR, edição 2009, disponibilizado no sitio da SOFTEX, instituição responsável pela avaliação e certificação MPS.BR, visando proporcionar um maior conhecimento acerca do assunto e identificar as vantagens obtidas através da implementação do MPS.BR nos ambientes de desenvolvimento de software.
O guia Geral contém a descrição geral do Modelo MPS e detalha o Modelo de Referência (MR-MPS) e as definições comuns necessárias para seu entendimento e aplicação. Foram revisadas ainda publicações relacionadas ao tema de engenharia e qualidade de software, compreendidas entre os anos de 1995 e 2006.
A aplicação do programa MPS.BR permite a implementação de práticas reconhecidas internacionalmente e a certificação das empresas a um custo razoável, dentro da realidade brasileira.
4 CONSIDERAÇÕES FINAIS
A importância de se normatizar os processos é cada vez mais evidente: definir, documentar e padronizar a forma de trabalho permite aos gestores maior domínio da organização. Aliada a isso, a adoção de modelos de processos com práticas reconhecidas internacionalmente permite às empresas se posicionarem no mercado globalizado, garantindo sua participação em processos de seleção onde há exigência de certificações de qualidade.
A aplicação do programa MPS.BR permite a definição, padronização e monitoração dos processos de desenvolvimento de software.
Este modelo aumenta a produtividade, permitindo melhor visualização dos processos e a definição de cronogramas confiáveis com melhor análise dos custos do produto.É gerado uma base histórica com subsídios para a melhoria do processo. Sua divisão em níveis de maturidade possibilita a adoção de forma gradativa, facilitando sua implementação com custo adequado.
É importante destacar que o MPS.BR é um modelo criado no Brasil, fator que facilita sua implementação, tendo em vista que é voltado para a realidade brasileira.
REFERÊNCIAS BIBLIOGRÁFICAS
GIL, A.C. Métodos e técnicas de pesquisa social. São Paulo: Atlas, 1999.
GODOY, A. S. Introdução à pesquisa qualitativa e suas possibilidades. In: Revista de Administração de Empresas. São Paulo: v.35, n.2, p. 57-63, abril 1995.
OLIVEIRA, Marcelo Silva de. Qualidade de Processo de Software: Medição e Análise. Lavras: UFLA/FAEPE, 2006. 146 p.
PRESSMAN, Roger S.. Engenharia de Software. São Paulo: Makron Books, 1995
PAULA FILHO, Wilson de Pádua. Engenharia de Software: fundamentos, métodos e padrões. Rio de Janeiro: LTC, 2001
SOFTEX, ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO. MPS.BR Guia Geral:2009, maio 2009. Disponível em: <www.softex.br>. Acesso em 23/05/2011.
