MPS.BR Lições Aprendidas
0 gostou1,348 visualizações
O documento descreve a gestão do programa MPS.BR, que tem como objetivo disseminar um modelo de melhoria de processos de software no Brasil. A gestão envolve uma estrutura organizacional com diferentes entidades responsáveis por atividades como o desenvolvimento do modelo MPS, credenciamento de instituições e disseminação do programa. O ciclo PDCA é utilizado para planejamento e monitoramento das atividades. Lições aprendidas na gestão incluem a importância de alinhamento com objetivos da indústria de software e envolvimento de diversas partes interessadas.
![Lições Aprendidas com Implementação do Modelo MPS
em Empresas
Mariano Angel Montoni
COPPE/UFRJ – Universidade Federal do Rio de Janeiro
Caixa Postal 68511 – CEP 21945-970 – Rio de Janeiro-RJ, Brasil
mmontoni@cos.ufrj.br
Resumo. Este trabalho descreve as lições aprendidas pelas instituições
implementadoras do MPS.BR e de empresas que implementaram o modelo
MPS no período de 2005-2008. Espera-se que essas lições possam contribuir
no aumento da eficácia das estratégias de implementação existentes, bem
como, no aumento das chances de sucesso das iniciativas de melhoria
baseadas no modelo MPS.
1. Introdução
A implementação de melhoria de processos de software é uma atividade complexa e
intensa em conhecimento [Zaharan, 1998]. Diversas barreiras críticas existem e devem
ser superadas para aumentar as chances de sucesso de iniciativas de melhoria, por
exemplo, a falta de comprometimento da alta gerência e a falta de recursos financeiros
[Niazi et al., 2006]. Essas barreiras têm sido um dos principais fatores pelos quais as
organizações evitam implementar melhoria de processo de software com base em
modelos e padrões [Staples et al., 2007]. Portanto, a garantia do sucesso do modelo
MPS depende, fundamentalmente, da capacidade das organizações de desenvolvimento
de software superarem essas barreiras, por exemplo, através da retenção e reutilização
de conhecimento sobre implementação de melhorias em processo de software.
Neste contexto, é de grande importância a aquisição de conhecimento sobre potenciais
problemas que podem ocorrer ao longo da execução de iniciativas de melhoria para
maximizar as chances de sucesso [Montoni et al., 2008]. Por exemplo, o acúmulo de
conhecimento sobre lições aprendidas na condução de iniciativas de melhoria pode ser
bastante útil como mecanismo de preservação do conhecimento organizacional, além de
fornecer a base para promover a disseminação do conhecimento necessário para evitar,
em novas iniciativas, a ocorrência de problemas detectados em iniciativas anteriores.
Além disso, o acúmulo de conhecimento sobre lições aprendidas com a implementação
de melhorias baseadas no modelo MPS, pode servir como rica fonte de informação
sobre questões relacionadas à adoção do modelo MPS que podem ser úteis no
aprimoramento do modelo para torná-lo mais adequado às características peculiares do
setor de software brasileiro.
Este artigo tem como objetivo descrever as principais lições aprendidas na
implementação de melhoria de processo de software com base no modelo MPS. Essas
lições foram aprendidas a partir da experiência das Instituições Implementadoras (IIs) e
das empresas que implementaram o modelo MPS. A seção 2 apresenta os modelos
básicos de implementação do MPS, bem como os conceitos de II e os requisitos
necessários para credenciamento de uma II. A seção 3 apresenta as principais lições
31](https://image.slidesharecdn.com/mpsbrpt-130604084219-phpapp02/85/MPS-BR-Licoes-Aprendidas-32-320.jpg)
![aprendidas na implementação de melhorias de processo baseada no modelo MPS.
Finalmente, a seção 4 apresenta as conclusões deste trabalho.
2. Implementação do MPS.BR e Instituições Implementadoras
O modelo MPS foi desenvolvido com foco nas pequenas e médias empresas que
possuem diversas restrições técnicas e financeiras. No entanto, o modelo também é
completamente adequado para grandes organizações que possuem recursos suficientes
para investir em melhoria de processo de software [SOFTEX, 2007].
Para atender à diversidade de características, necessidades e restrições das organizações
brasileiras de desenvolvimento de software, foi desenvolvido e integrado ao modelo
MPS um componente chamado de MN-MPS que abrange os modelos de negócio para
implementação do programa MPS.BR. O MN-MPS compreende dois tipos de modelos
de implementação de melhoria de processo de software de acordo com as necessidades
específicas das organizações e a disponibilidade de recursos:
• Um Modelo Específico de Negócio adequado para grandes organizações que
não desejam compartilhar serviços de melhoria de processo de software
baseados no modelo MPS com outras organizações.
• Um Modelo Cooperado de Negócio para grupos de pequenas e médias
empresas interessadas em implementar e avaliar o modelo MPS e
compartilhar serviços e custos de melhoria de processo de software
O Modelo Cooperado de Negócio é especialmente atraente para pequenas e médias
empresas, pois a implementação baseada nesse modelo é factível de obter recursos
externos para apoiar atividades de implementação e avaliação de melhoria de processo
de software. No entanto, as organizações que integram este modelo devem estar sujeitas
a algumas restrições. Por exemplo, marcos de implementação e de avaliação são
estabelecidos no contexto do grupo cooperado de empresas e o apoio financeiro para a
implementação do modelo MPS somente é obtido caso a organização que integra o
grupo alcance com sucesso cada um desses marcos. Além disso, é requisito que a
implementação seja coordenada por uma Instituição Implementadora (II) e, também,
que o grupo cooperado de empresas seja coordenado por uma Instituição Organizadora
de Grupos de Empresas (IOGE), ambas credenciadas pela SOFTEX.
Uma II é uma organização autorizada para conduzir uma implementação do MPS.BR
composta de consultores em implementação de melhoria de processo de software
baseada no modelo MPS. O conceito de II do MPS.BR é um diferencial desse modelo
para outros modelos de melhoria de processo de software existentes, o que torna o
modelo MPS único na sua definição.
O estabelecimento de IIs e a formação de consultores de implementação de melhoria
baseada no modelo MPS ajudam a estabelecer uma comunidade de prática com
interesses comuns de troca e compartilhamento de informações com o objetivo de
facilitar a adoção do modelo MPS e reduzir a influência de barreiras críticas que podem
afetar o sucesso de iniciativas de melhoria baseadas no modelo MPS. Os workshops
anuais de implementadores e de empresas que implementaram o modelo MPS são
eventos que estimulam a troca de conhecimento entre membros da comunidade de
prática do MPS.BR.
32](https://image.slidesharecdn.com/mpsbrpt-130604084219-phpapp02/85/MPS-BR-Licoes-Aprendidas-33-320.jpg)
![A autorização de uma II é realizada através de um convênio com a SOFTEX. O Fórum
de Credenciamento e Controle (FCC) do modelo MPS é responsável por fornecer um
parecer da aprovação do credenciamento da II. Essa aprovação é realizada mediante o
atendimento dos seguintes requisitos institucionais pelas instituições proponentes
[SOFTEX, 2007]:
• Demonstrar experiência da instituição na área de processos de software.
• Possuir uma estratégia de implementação do Modelo de Referência MR-MPS.
• Possuir uma estratégia de seleção, capacitação e manutenção da competência
dos membros da equipe de Implementação do MPS.BR.
• Ter a ela vinculados, no mínimo, 3 (três) profissionais que cumpram os
seguintes requisitos, sendo que um deve ser o coordenador da equipe: (i)
aprovação na prova de Introdução (P1-MPS.BR); (ii) aprovação na prova para
implementadores (P2-MPS.BR); (iii) graduação completa; (iv) experiência
em desenvolvimento de software e implantação de processos de software.
Caso o Fórum de Credenciamento e Controle (FCC) forneça um parecer favorável após
análise da documentação fornecida pela instituição proponente, é assinado um Termo de
Convênio entre a SOFTEX e a II para seu credenciamento.
O período de duração do credenciamento de uma II é de 2 anos. Ao longo deste período,
a II deve enviar, semestralmente, para a SOFTEX, um relatório de atividades realizadas
no período de referência. Geralmente, esses relatórios contêm informações sobre os
trabalhos de implementação do modelo MPS realizados no período, bem como
atividades para formação de implementadores e os resultados alcançados, por exemplo,
a realização com sucesso de uma avaliação oficial MPS em empresas que
implementaram o modelo sob coordenação da respectiva II, entre outras informações.
Atualmente, existem 18 IIs credenciadas [SOFTEX, 2008]. A distribuição da
localização das IIs conforme as regiões do Brasil é apresentada na tabela 1.
Tabela 1 – Distribuição da Localização das IIs conforme as regiões do Brasil
Região Número de IIs Credenciadas
Centro-oeste 3
Norte 0
Nordeste 1
Sudeste 10
Sul 4
Os relatórios de atividades das IIs também contêm informações sobre as lições
aprendidas por cada II na implementação do modelo MPS. Essas lições compreendem
um rico conhecimento sobre potenciais problemas que podem ocorrer ao longo da
condução de iniciativas de melhoria, além de conhecimento sobre os procedimentos
adequados para tratar esses problemas maximizando as chances de alcançar sucesso na
condução de iniciativas de melhoria de processo de software com base no modelo MPS.
Além de estarem descritas nos relatórios de atividades das IIs, as lições aprendidas com
implementação do modelo MPS em empresas também são divulgadas na forma de
comunicados nos workshops anuais de implementadores e de empresas que
implementaram o modelo MPS.
33](https://image.slidesharecdn.com/mpsbrpt-130604084219-phpapp02/85/MPS-BR-Licoes-Aprendidas-34-320.jpg)
![3. Lições Aprendidas
Cada organização implementa melhoria de processo de software baseada no modelo
MPS seguindo estratégias específicas de implementação. Essas estratégias são
adaptadas para cada organização segundo suas características, necessidades e restrições.
Portanto, pode-se assumir que, no contexto de uma iniciativa de melhoria, é importante
tratar adequadamente as diversas questões que podem afetar o sucesso das iniciativas de
melhoria, tanto de forma positiva, quanto de forma negativa.
No entanto, pode-se observar nos relatos de lições aprendidas das IIs e das empresas
que implementaram o modelo MPS que existe uma certa homogeneidade nos tipos de
questões que devem ser tratadas ao longo da execução das iniciativas de melhoria
[Zabeu, 2007a], [Zabeu, 2007b], [Salviano, 2006], [Salviano, 2008], [Sória, 2007],
[Sória, 2008a], [Sória, 2008b], [Rocha, 2006], [Souza, 2006], [Souza, 2007a], [Souza,
2007b], [Souza, 2008], [Palestino, 2006], [Palestino, 2007a], [Palestino, 2007b],
[Palestino, 2007c], [Palestino, 2008], [Yoshida, 2007a], [Yoshida, 2007b], [Becker,
2006a], [Becker, 2006b], [Becker, 2007], [Rouiller, 2005], [Rouiller, 2007], [Oliveira,
2006a], [Oliveira, 2006b], [Oliveira, 2007a], [Oliveira, 2007b], [Salgado, 2008], [Rocha
et al., 2005], [Mendes et al., 2007], [Tsukumo et al., 2006], [Yoshida et al., 2007],
[Santos et al., 2007], [Thiry et al., 2007], [Mega et al., 2007], [Ribeiro, 2007],
[Monteiro et al., 2007], [Scheid et al., 2007], [Borssatto, 2007], [Vargas et al., 2007] e
[Souza e Pinto, 2007].
Portanto, é fundamental garantir a preservação do conhecimento relacionado a essas
questões, bem como o conhecimento sobre os procedimentos adequados para tratar
essas questões no contexto de iniciativas de melhoria baseadas no modelo MPS. Essas
questões foram documentadas na forma de lições aprendidas e são descritas a seguir.
3.1. Lição 1: Tratar a implementação de melhoria de processo de software como
um projeto
Diversas IIs e empresas que implementaram o modelo MPS reconhecem a importância
de gerenciar as iniciativas de melhoria como um projeto. A ISO/IEC 15504-4 define
que um programa de melhoria de processo deve ser implementado como um projeto
propriamente dito, com patrocinadores definidos, gerência de projeto, orçamento, metas
e acompanhamento financeiro [ISO/IEC 15504-4, 2004]. Para tanto, deve haver um
planejamento adequado das iniciativas de melhoria de uma organização. Um plano de
melhoria deve conter informações sobre a situação atual das atividades de melhoria de
processo, o escopo da organização (os limites organizacionais para o programa de
melhoria), o escopo do processo (os processos a serem melhorados), o ciclo de vida da
melhoria de processo, papéis principais e responsabilidades, recursos, riscos associados
com o programa de melhoria entre outras [ISO/IEC 15504-4, 2004].
No contexto desta lição aprendida, também é importante reconhecer a necessidade de
monitorar e acompanhar as iniciativas de melhoria com base no planejamento do projeto
de melhoria. Portanto, metas e pontos de revisão, bem como mecanismos de relato da
situação do programa de melhoria devem ser definidos e estabelecidos adequadamente.
34](https://image.slidesharecdn.com/mpsbrpt-130604084219-phpapp02/85/MPS-BR-Licoes-Aprendidas-35-320.jpg)
![O planejamento adequado de iniciativas de melhoria é ainda mais necessário quando a
implementação de melhoria de processos segue o Modelo Cooperado de Negócio.
Algumas IIs perceberam que a antecipação na coordenação das ações de implementação
de melhoria aumenta a chance de sucesso na formação de um grupo.
Um aspecto relevante de ser considerado no planejamento de uma iniciativa de melhoria
é a necessidade de realizar uma análise criteriosa da situação atual da empresa que
esteja iniciando a implementação de processos do MR-MPS. Algumas IIs constataram
que as empresas, normalmente, têm uma percepção muito mais otimista do que realista
quanto ao nível de maturidade em que se encontram. Portanto, atividades de gap
analysis podem ser úteis para obter um dimensionamento correto do trabalho a ser
realizado e, conseqüentemente, aumentar a precisão das estimativas de esforço e custo
das iniciativas de melhoria.
3.2. Lição 2: Manter o foco da implementação de melhoria de processo de software
O foco de um programa de melhoria de processos deve estar vinculado aos objetivos de
negócio da organização [Santos et al., 2007]. Para tanto, é fundamental garantir que os
objetivos de melhoria a serem alcançados são derivados dos objetivos de negócio
organizacionais.
A mudança constante de foco da implementação ou a falta de gerência dessas mudanças
podem prejudicar a visibilidade dos benefícios reais alcançados com o investimento
realizado na implementação das melhorias nos processos de uma organização. Um
mecanismo identificado por algumas IIs e empresas que implementaram o modelo MPS
para tratar este problema é a realização de reuniões periódicas de acompanhamento com
o patrocinador e os responsáveis pela equipe interna para que haja um entendimento da
situação das atividades de implementação e sejam tomadas ações corretivas necessárias
para que os envolvidos na iniciativa de melhoria mantenham o foco desejado na
implementação.
3.3. Lição 3: Estabelecer liderança da implementação de melhoria de processo de
software
Muitas barreiras são encontradas durante as iniciativas de melhoria, como por exemplo,
políticas organizacionais, falta de apoio e de recursos, falta de conhecimento e pressões
de cronograma. A capacidade de motivar, sensibilizar e orientar os membros da
organização na realização de ações é fundamental para superar essas e outras
dificuldades.
Também é reconhecida a importância do patrocinador do programa de melhoria na
implementação das melhorias, pois muitas vezes, sua intervenção é necessária para
tratar resistências a mudanças. Além disso, o patrocinador tem o poder de atribuir
autoridade e tempo aos responsáveis pela implementação das melhorias de forma que
haja autonomia nas decisões visando reduzir a morosidade na análise de alternativas de
implementação e na implantação das alternativas selecionadas.
35](https://image.slidesharecdn.com/mpsbrpt-130604084219-phpapp02/85/MPS-BR-Licoes-Aprendidas-36-320.jpg)
![3.4. Lição 4: Obter e manter o comprometimento para a implementação de
melhoria de processo de software
Um fator que tem influência no sucesso das iniciativas de melhoria está relacionado ao
comprometimento da organização desde os níveis mais baixos até os níveis mais altos
da hierarquia organizacional. No entanto, foi observado que a obtenção e manutenção
do comprometimento dos membros de uma organização de software não é uma tarefa
trivial. Para tratar esse problema é preciso garantir que as pessoas envolvidas nas
iniciativas de melhoria percebem os benefícios derivados da implementação, e não
apenas o esforço e custos associados. Isto poder ser alcançado, por exemplo, através da
comunicação contínua para a alta gerência de dados quantitativos de tempo, custo,
qualidade e satisfação do cliente relacionados à iniciativa de melhoria.
A atribuição explícita do papel e das responsabilidades de cada um dos envolvidos na
iniciativa de melhoria também é muito importante. A definição de um macro-processo
no início do programa de melhoria relacionando todas as ações de melhoria, bem como
as responsabilidades e dependências entre elas é um mecanismo eficiente para aumentar
a visibilidade das atribuições de cada pessoa envolvida na iniciativa de melhoria, pois
permite uma melhor compreensão das responsabilidades individuais, bem como a falta
de comprometimento pode afetar o programa de melhoria como um todo.
3.5. Lição 5: Garantir efetividade dos processos de software
Uma boa visibilidade dos resultados obtidos com a melhoria dos processos de software
é essencial para garantir que as melhorias estão tornando os processos mais efetivos.
Um processo disciplinado de software deve ajudar os projetos a alcançar suas metas de
qualidade, custo e cronograma. Uma infra-estrutura de processo deve ser projetada com
esse objetivo principal em mente, que é ajudar projetos a alcançar (e talvez exceder) os
objetivos estabelecidos. Portanto, uma forma eficiente para justificar o investimento na
melhoria dos processos de software é estabelecer uma relação direta entre um ambiente
de processo efetivo e a qualidade melhorada dos produtos e serviços resultantes
[Zaharan, 1998].
Neste contexto, foi observado que as iniciativas de melhoria devem ser monitoradas
através de indicadores de desempenho capazes de evidenciar a manutenção e/ou
melhora do desempenho dos processos. A monitoração dos processos e os mecanismos
de relato da situação dos processos com base nesses indicadores também são úteis para
apoiar a avaliação do retorno no investimento em melhoria de processos. Indicadores de
desempenho associados às iniciativas de melhoria incluem, por exemplo, medidas de
qualidade do produto, qualidade do processo, previsibilidade do projeto e satisfação do
cliente. No entanto, alguns dos maiores retornos da melhoria dos processos de software
são expressos em termos humanos e não em unidades monetárias, por exemplo,
satisfação no trabalho, orgulho do trabalho realizado, aumento da capacidade de atrair e
reter especialistas capazes de introduzir práticas inovadoras na organização, entre outros
[Krasner, 2001].
36](https://image.slidesharecdn.com/mpsbrpt-130604084219-phpapp02/85/MPS-BR-Licoes-Aprendidas-37-320.jpg)
![3.6. Lição 6: Estabelecer e manter uma infra-estrutura adequada para
implementação de melhoria de processo de software
Os relatos de lições aprendidas com implementação do modelo MPS em empresas
apontam que a maior parte das organizações de baixa maturidade não possui uma infra-
estrutura adequada para os processos de software. A infra-estrutura de processo de
software abrange os seguintes dois aspectos que devem ser cobertos completamente
para obter um ambiente para melhoria de processo de software efetivo [Zaharan, 1998]:
• Infra-estrutura organizacional e gerencial: inclui os papéis e responsabilidades
que devem ser estabelecidas para patrocinar, gerenciar, realizar e monitorar
atividades de melhoria de processo de software.
• Infra-estrutura tecnológica e ferramental: incorpora as facilidades e ferramentas
necessárias para automatizar atividades de processo e apoiar os diversos papéis e
responsabilidades de melhoria de processo.
A dificuldade em adquirir e implantar ferramentas de software adequadas às
necessidades e restrições da organização é um fator que tem impacto direto na infra-
estrutura de processos. Uma análise das funcionalidades das ferramentas existentes no
mercado com base em critérios objetivos, por exemplo, capacidade de integração entre
ferramentas e capacidade de adaptação das ferramentas, é bastante útil para apoiar a
seleção de uma infra-estrutura ferramental adequada para a realidade dos projetos e da
organização. A definição desde o início da implementação de ferramentas de apoio aos
processos também ajuda a minimizar o retrabalho na definição dos procedimentos da
empresa e a diminuir a resistência à mudanças na forma atual de trabalho.
A falta de recursos humanos para assumir papéis e responsabilidades também tem
impacto na infra-estrutura de processos. Para resolver este problema, diversas
organizações têm contratado serviços de consultores das IIs para assumir
responsabilidades na execução de alguns processos de apoio, por exemplo, atividades de
análise de métricas e avaliação de qualidade de processos e produtos. Dessa forma,
essas organizações mantêm o foco no negócio evitando alocar seus membros em
atividades não fundamentais no desenvolvimento do software.
A excessiva concentração das atividades no grupo de processos também pode prejudicar
o andamento de uma iniciativa de melhoria, principalmente em empresas de pequeno e
médio porte. Para tratar esta questão, é recomendada a criação de grupos de trabalho
para processos específicos compostos de membros selecionados de acordo com a
especialidade necessária para definir as atividades dos processos. O estabelecimento de
prazos maiores para a definição e implementação dos processos ajuda a evitar a
ocorrência de atrasos e a aumentar as chances de atender as expectativas das partes
interessadas na iniciativa de melhoria.
37](https://image.slidesharecdn.com/mpsbrpt-130604084219-phpapp02/85/MPS-BR-Licoes-Aprendidas-38-320.jpg)
![Referências
[Becker, 2006a] Becker, C.A. Relatório Semestral da Instituição Implementadora
Softsul, Março 2006.
[Becker, 2006b] Becker, C.A. Relatório Semestral da Instituição Implementadora
Softsul, Setembro 2006.
[Becker, 2007] Becker, C.A. Relatório Semestral da Instituição Implementadora
Softsul, Julho 2007.
[Borssatto, 2007] Borssatto, I., 2007, “A Implementação do MPS.BR Nível F na Synos”,
In: PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp. 105-110,
Novembro.
[ISO/IEC 15504-4, 2004] - International Organization for Standardization and
International Electrotechnical Commission. ISO/IEC 15504-4: Information Technology
- Process Assessment – Part 4 - Guidance on use for Process Improvement and Process
Capability Determination, Genebra: ISO, 2004.
[Krasner, 2001] Krasner, H., 2001, "Accumulating the Body of Evidence for The Payoff
of Software Process Improvement", Software Process Improvement, IEEE Computer
Society Press.
[Mega et al., 2007] Mega, B., Fonseca, K., Boessio, R., et al., 2007, “Melhoria de
Processos de Software na Drive”, In: PROQUALITY – Qualidade na Produção de
Software, v. 3, n. 2, pp. 82-86, Novembro.
[Mendes et al., 2007] Mendes, F.F., Oliveira, J.L., Fernandes, P.G., Souza, A.S., 2007,
“Análise de Riscos na Implantação de Melhorias de Processos de Software”, In:
PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp. 25-32, Novembro.
[Monteiro et al., 2007] Monteiro, R. W., Martins, C., Cabral., R., Rocha, A.R., 2007,
“A Empresa de Processamento de Dados do Estado do Pará Rumo ao Nível F do MR-
MPS”, In: PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp. 91-96,
Novembro.
[Montoni et al., 2008] Montoni, M.A., Cerdeiral, C., Zanetti, D., et al., 2008, "A
Knowledge Management Approach to Support Software Process Improvement
Implementation Initiatives". In: EuroSPI 2008, pp. 164-175, Dublin, Irlanda.
[Niazi et al., 2006] Niazi, M., Wilson, D., Zowghi, D., 2006, "Critical success factors
for software process improvement implementation: An empirical study", Software
Process Improvement and Practice, v. 11, n. 2, pp. 193-211.
[Oliveira, 2006a] Oliveira, K.M. Relatório Semestral da Instituição Implementadora
UCB, Junho 2006.
41](https://image.slidesharecdn.com/mpsbrpt-130604084219-phpapp02/85/MPS-BR-Licoes-Aprendidas-42-320.jpg)
![[Oliveira, 2006b] Oliveira, K.M. Relatório Semestral da Instituição Implementadora
UCB, Dezembro 2006.
[Oliveira, 2007a] Oliveira, K.M. Relatório Semestral da Instituição Implementadora
UCB, Junho 2007.
[Oliveira, 2007b] Oliveira, K.M. Relatório Semestral da Instituição Implementadora
UCB, Dezembro 2007.
[Palestino, 2006] Palestino, C.V.B. Relatório Semestral da Instituição Implementadora
FUMSOFT, Julho 2006.
[Palestino, 2007a] Palestino, C.V.B. Relatório Semestral da Instituição Implementadora
FUMSOFT, Abril 2007.
[Palestino, 2007b] Palestino, C.V.B. Relatório Semestral da Instituição
Implementadora FUMSOFT, Agosto 2007.
[Palestino, 2007c] Palestino, C.V.B. Relatório Semestral da Instituição Implementadora
FUMSOFT, Dezembro 2007.
[Palestino, 2008] Palestino, C.V.B. Relatório Semestral da Instituição Implementadora
FUMSOFT, Junho 2008.
[Ribeiro, 2007] Ribeiro, A.F., 2007, “Melhoria de Processos de Software com Base no
Nível G do MPS.BR na Prodemge”, In: PROQUALITY – Qualidade na Produção de
Software, v. 3, n. 2, pp. 87-90, Novembro.
[Rocha et al., 2005] Rocha, A. R., Montoni, M., Santos, G., et al., 2005, “Fatores de
Sucesso e Dificuldades na Implementação de Processos de Software Utilizando o MR-
MPS e o CMMI”, In: PROQUALITY – Qualidade na Produção de Software, pp. 13-18,
Junho.
[Rocha, 2006] Rocha, A.R. Relatório Semestral da Instituição Implementadora
COPPE/UFRJ, Março 2006.
[Rouiller, 2005] Rouiller, A.C. Relatório Semestral da Instituição Implementadora
SWQuality, Novembro 2005.
[Rouiller, 2007] Rouiller, A.C. Relatório Semestral da Instituição Implementadora
SWQuality, Abril 2007.
[Salgado, 2008] Salgado, C.G. Relatório Semestral da Instituição Implementadora
UCB, Junho 2008.
[Salviano, 2006] Salviano, C. F. Relatório Semestral da Instituição Implementadora
CenPRA, Dezembro 2006.
[Salviano, 2008] Salviano, C. F. Relatório Semestral da Instituição Implementadora
CenPRA, Maio 2008.
42](https://image.slidesharecdn.com/mpsbrpt-130604084219-phpapp02/85/MPS-BR-Licoes-Aprendidas-43-320.jpg)
![[Santos et al., 2007] Santos, G., Montoni, M., Figueiredo, S., et al., 2007, "SPI-KM -
Lessons Learned from Applying a Software Process Improvement Strategy Supported
by Knowledge Management", Product-Focused Software Process Improvement.
[Santos et al., 2007] Santos, G., Montoni, M., Vasconcellos, J, et al., 2007,
“Implementação do MR-MPS Níveis G e F em Grupos de Empresas do Rio de Janeiro”,
In: PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp. 53-58,
Novembro.
[Scheid et al., 2007] Scheid, M., Pessoa, M., Gomes, R.F., et al., 2007, “Implantação do
MR-MPS Nível E no Centro de Computação da Aeronáutica de São José dos Campos”,
In: PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp. 97-104,
Novembro.
[SOFTEX, 2007] SOFTEX, 2007, "MPS.BR – Melhoria de Processo do Software
Brasileiro, Guia Geral (v. 1.2)". In: http://www.softex.br/mpsbr/_guias/default.asp.
[SOFTEX, 2008] SOFTEX, 2008, "Site do MPS.BR - Melhoria de Processos do
Software Brasileiro". In: http://www.softex.br/mpsbr, acessado em 20/08/2008.
[Sória, 2007] Sória, F. Relatório Semestral da Instituição Implementadora CITS, Março
2007.
[Sória, 2008a] Sória, F. Relatório Semestral da Instituição Implementadora CITS, Maio
2008.
[Sória, 2008b] Sória, F. Relatório Semestral da Instituição Implementadora CITS, Julho
2008.
[Souza e Pinto, 2007] Souza, J.P., Pinto, M.V., 2007, “Prodabel: Diagnóstico da
Implantação do Nível G do MPS.BR”, In: PROQUALITY – Qualidade na Produção de
Software, v. 3, n. 2, pp. 123-128, Novembro.
[Souza, 2006] Souza, A.S. Relatório Semestral da Instituição Implementadora
Estratégia, Outubro 2006.
[Souza, 2007a] Souza, A.S. Relatório Semestral da Instituição Implementadora
Estratégia, Abril 2007.
[Souza, 2007b] Souza, A.S. Relatório Semestral da Instituição Implementadora
Estratégia, Julho 2007.
[Souza, 2008] Souza, A.S. Relatório Semestral da Instituição Implementadora
Estratégia, Janeiro 2008.
[Staples et al., 2007] Staples, M., Niazi, M., Jeffery, R., et al., 2007, "An exploratory
study of why organizations do not adopt CMMI", Journal of Systems and Software, v.
80, n. 6, pp. 883-895.
43](https://image.slidesharecdn.com/mpsbrpt-130604084219-phpapp02/85/MPS-BR-Licoes-Aprendidas-44-320.jpg)
![44
[Thiry et al., 2007] Thiry, M., Wangenheim, C.G., Zoucas, A., 2007, “Implementação
do MPS.BR em Grupo de Empresas da ACATE em Florianópolis 2007/2008”, In:
PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp. 59-64, Novembro.
[Tsukumo et al., 2006] Tsukumo, A. N., De Martino, W. R., Sérgio, M. P., Salviano,
C.F., 2006, “Lições aprendidas na aplicação do Método Coop-MPS para Projetos
Cooperativos de Melhoria de Processo de Software com MPS.BR”, In: PROQUALITY
– Qualidade na Produção de Software, v. 2, n.2, pp. 51-56, Novembro.
[Vargas et al., 2007] Vargas, D., Nigri, M., Krieger, M., et al., 2007, “Melhoria de
Processos na Marlin”, In: PROQUALITY – Qualidade na Produção de Software, v. 3, n.
2, pp. 117-122, Novembro.
[Yoshida et al., 2007] Yoshida, D., Kohan, S., Salvettie, N., Hirama, K., 2007,
“Convênio ComQualidade: Implementação MPS.BR Nível G em Grupo de Empresas de
São Paulo”, In: PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp.
49-52, Novembro.
[Yoshida, 2007a] Yoshida, D. Relatório Semestral da Instituição Implementadora ITS,
Abril 2007.
[Yoshida, 2007b] Yoshida, D. Relatório Semestral da Instituição Implementadora ITS,
Julho 2007.
[Zabeu, 2007a] Zabeu, A. Relatório Semestral da Instituição Implementadora ASR,
Julho 2007.
[Zabeu, 2007b] Zabeu, A. Relatório Semestral da Instituição Implementadora ASR,
Dezembro 2007.
[Zaharan, 1998] Zaharan, S., 1998, Software Process Improvement – Practical
Guidelines for Business Success, Addison-Wesley.](https://image.slidesharecdn.com/mpsbrpt-130604084219-phpapp02/85/MPS-BR-Licoes-Aprendidas-45-320.jpg)
![Lições Aprendidas em Avaliações MPS
Ana Regina Rocha
COPPE/UFRJ – Universidade Federal do Rio de Janeiro
Caixa Postal 68511 – CEP 21945-970 – Rio de Janeiro-RJ, Brasil
darocha@cos.ufrj.br
Resumo. Este trabalho descreve as lições aprendidas pelas instituições
avaliadoras do MPS.BR no período 2005-2008. Após três anos de
avaliações MPS podemos afirmar que o método de avaliação MA-MPS e o
processo de avaliação MPS, bem como o modelo de referência MR-MPS,
são consistentes e possibilitam conduzir avaliações de forma adequada e
segura.
1. Introdução
O sucesso do Programa MPS.BR é indiscutível e superou qualquer expectativa, mesmo
as mais otimistas. Neste momento (outubro de 2008) tem-se cerca de 110 empresas
avaliadas. Mais de 200 empresas, públicas e privadas, implementaram ou estão
implementando o MR-MPS. A avaliação MPS está sendo adotada como critério de
pontuação técnica em importantes licitações.
Esta ampla aceitação deve-se, entre outros fatores, à seriedade do programa MPS.BR e
do modelo MPS e garantir esta seriedade tem sido uma das principais preocupações da
SOFTEX e das Instituições Avaliadoras. Ela se reflete na seleção adequada da equipe de
avaliação, no conhecimento que os avaliadores têm do modelo e da Engenharia de
Software, na organização e pontualidade no planejamento e realização das avaliações,
na postura ética dos avaliadores, no cuidado com a qualidade da documentação da
avaliação, na seleção dos entrevistados, na relação das Instituições Avaliadoras (IAs)
com as empresas, as Instituições Organizadoras de Grupo de Empresas (IOGEs) e as
Instituições Implementadoras (IIs).
Este artigo descreve um conjunto de lições aprendidas pelas Instituições Avaliadoras
MPS.BR com a realização de avaliações ao longo dos últimos 3 anos.
2. Avaliação MPS e Instituições Avaliadoras
O propósito do método de avaliação MA-MPS é verificar a maturidade de uma
organização/unidade organizacional na execução de seus processos de software. O
processo e o método de avaliação MA-MPS foram definidos de forma a permitir a
avaliação objetiva dos processos de software de uma organização/unidade
organizacional; permitir a atribuição de um nível de maturidade do MR-MPS com base
no resultado da avaliação; ser aplicável a qualquer domínio de aplicação na indústria de
software e ser aplicável a organizações/unidades organizacionais de qualquer tamanho.
Uma avaliação MPS tem validade de três anos [MPS.BR, 2007a].
45](https://image.slidesharecdn.com/mpsbrpt-130604084219-phpapp02/85/MPS-BR-Licoes-Aprendidas-46-320.jpg)
![O processo e o método de avaliação MA-MPS foram definidos de forma aderente à
norma internacional ISO/IEC 15504-3:2003 [ISO/IEC 15504-2:2003]. As avaliações
MPS tem como modelo de referência o MR-MPS descrito no Guia Geral v. 1.2
[MPS.BR, 2007b], que tem como comunidade de interesse empresas públicas e privadas,
de diferentes tamanhos e características que atuem no desenvolvimento e manutenção
de software.
O modelo de referência MPS (MR-MPS) busca atender à necessidade de implantar os
princípios de Engenharia de Software de forma adequada ao contexto das empresas
brasileiras. O MR-MPS é definido em consonância com a norma internacional ISO/IEC
12207 [ISO/IEC 12207:1995] e suas emendas 1 [ISO/IEC 12207:1995/Amd 1:2002]e 2
[ISO/IEC 12207:1995/Amd 2:2004], adaptando-a às necessidades da comunidade de
interesse. Para definição e revisão do modelo de referência é feita uma ampla consulta à
comunidade de implementadores e avaliadores MPS.BR. A elaboração final é
responsabilidade da ETM. Atualmente estão sendo realizados os ajustes necessários
para conformidade com a ISO/IEC 12207:2008 [ISO/IEC 12207:2008].
O processo de avaliação MPS é aderente à ISO/IEC 15504-2:2003 quanto às atividades
e tarefas do processo. A tabela 1 mostra o mapeamento entre as atividades requeridas
para um processo de avaliação aderente à norma ISO/IEC 15504-2:2003 e as atividades
do processo de avaliação MPS.
Tabela 1 - Atividades requeridas para um processo de avaliação aderente à
ISO/IEC 15504-2:2003 e as atividades do processo de avaliação MPS
ISO/IEC 15504-2:2003 Processo de Avaliação MPS
- Pesquisar instituições avaliadoras
- Estabelecer contrato
- Viabilizar a avaliação
Planejamento Planejar a avaliação
Coleta de dados Preparar a avaliação
Validação de dados Conduzir a avaliação inicial
Planejamento/ Coleta de dados Completar a preparação da avaliação
Validação de dados/ Atribuição de
grau aos atributos do processo/
Relato dos resultados
Conduzir a avaliação final
- Avaliar a execução do processo de
avaliação
Relato dos resultados Relatar Resultados
Relato dos resultados Registrar Resultados
Os papéis e responsabilidades relacionados ao processo de avaliação MPS estão
descritos no Guia de Avaliação MPS e atendem aos requisitos descritos na seção 4.3 da
Norma ISO/IEC 15504-2:2003.
As entradas para a avaliação MPS estão descritas no Plano de Avaliação, elaborado na
tarefa Planejar a avaliação que contém: (i) identificação do processo e método de
avaliação MPS e do modelo de referência MR-MPS como base da avaliação; (ii)
46](https://image.slidesharecdn.com/mpsbrpt-130604084219-phpapp02/85/MPS-BR-Licoes-Aprendidas-47-320.jpg)
![No programa MPS.BR existem três níveis de avaliadores líderes: (i) avaliador líder
inicial, que deve atender aos requisitos descritos acima e está habilitado para liderar
avaliações níveis G e F; (ii) avaliador líder intermediário, habilitado a liderar avaliações
até o nível C e que além dos requisitos de avaliador líder inicial deve cumprir novos
requisitos de formação acadêmica (ter mestrado e/ou doutorado concluídos em
computação ou áreas afins), treinamento MPS.BR (participação em avaliações de níveis
E, C ou D) e experiência profissional (seis anos em gerência de projetos de software,
experiência de implementação de processos de software onde a unidade organizacional
obteve nível de maturidade em avaliação oficial e ter liderado quatro avaliações de
níveis G ou F, sendo pelo menos duas de nível F) e (iii) avaliador líder experiente,
habilitado a liderar avaliações de todos os níveis e que deve cumprir, além dos
requisitos anteriores, novos requisitos de formação acadêmica (é desejável que tenha
doutorado em computação ou áreas afins e é obrigatório possuir conhecimento
comprovado em controle estatístico de processos); treinamento MPS.BR (participação
em uma avaliação de níveis B ou A como avaliador adjunto onde participou de mini-
equipe responsável por processos destes níveis); experiência profissional (ter liderado
quatro avaliações de níveis E, D ou C, sendo pelo menos duas de níveis D ou C).
Uma avaliação MPS sempre tem a participação de um avaliador adjunto, cujo papel é
apoiar o avaliador líder. Um avaliador adjunto cumpre os seguintes requisitos de
formação acadêmica (especialização, mestrado ou doutorado concluídos e
conhecimento comprovado de Engenharia de Software com foco em processos de
software), treinamento MPS.BR (participação no curso e aprovação na prova para
formação de avaliadores) e experiência profissional (no mínimo três anos em gerência
de projetos de software ou experiência de implementação de processos de software onde
a unidade organizacional obteve nível de maturidade ou certificado ISO 9000:2000 com
avaliação oficial).
3. Lições Aprendidas nas Avaliações MPS
Avaliações MPS estão sendo realizadas desde 2005 e nestes três anos foram realizadas
avaliações em empresas públicas e privadas, de diferentes tamanhos e localizadas em
todas as regiões do Brasil. Esta experiência permitiu identificar um conjunto de lições
aprendidas e melhores práticas adotadas pelas várias Instituições Avaliadoras
[Galarraga, 2007], [Rocha,2007], [Machado,2007], [Oliveira, 2007], [Palestino, 2007],
[Amaral, 2008], [Oliveira, 2008], [Rocha, 2008] que relatamos a seguir agrupadas em
sete categorias: capacitação da equipe, preparação da avaliação, clima da avaliação,
resultado da avaliação, auditoria das avaliações, formação de novas instituições
avaliadoras e relação com as instituições implementadoras.
3.1. Lições aprendidas e práticas relacionadas à capacitação da equipe
(i). Um fator de sucesso para uma IA é contar com uma equipe bem formada
no modelo MPS e em Engenharia de Software. Quanto maior for este
conhecimento, maior será a capacidade do avaliador de entender a
implementação da empresa e ser flexível aceitando soluções válidas,
mesmo que estas não sejam as melhores soluções ou as que escolheria, ao
implementar um ou mais resultados. Investir na formação teórico/prática da
equipe é imprescindível.
48](https://image.slidesharecdn.com/mpsbrpt-130604084219-phpapp02/85/MPS-BR-Licoes-Aprendidas-49-320.jpg)
![Referências
[Amaral, 2008] Amaral,M.P. do Relatório Semestral da Instituição Avaliadora
RIOSOFT, Agosto 2008
[Galarraga, 2007] Galarraga, O. et al. A Experiência da IA Estratégia em Avaliações
MPS.BR, II Workshop de Avaliadores MPS.BR, Belo Horizonte, MG, novembro 2007
[ISO/IEC 12207:1995] - International Organization for Standardization and
International Electrotechnical Commission. ISO/IEC 12207 Information technology –
Software life cycle processes, Genebra: ISO, 1995.
[ISO/IEC 12207:1995/Amd 1:2002] - International Organization for Standardization
and International Electrotechnical Commission. ISO/IEC 12207 Amendment:
Information Technology - Amendment 1 to ISO/IEC 12207, Genebra: ISO, 2002.
[ISO/IEC 12207:1995/Amd 2:2004] - International Organization for Standardization
and International Electrotechnical Commission. ISO/IEC 12207 Amendment:
Information Technology - Amendment 2 to ISO/IEC 12207, Genebra: ISO, 2004.
[ISO/IEC 12207:2008] - International Organization for Standardization and
International Electrotechnical Commission. ISO/IEC 12207/IEEE Std 12207 Systems
andSoftware Engineering – Software life cycle processes, Genebra: ISO, 2008.
[ISO/IEC 15504-2, 2003] - the International Organization for Standardization and the
International Electrotechnical Commission. ISO/IEC 15504-2: Information Technology
- Process Assessment – Part 2 - Performing an Assessment, Geneve: ISO, 2003.
[Machado,2007] Machado, C.F. et al. Instituição avaliadora SwQuality: Aprendizado
Obtido nas avaliações MPS.BR, II Workshop de Avaliadores MPS.BR, Belo Horizonte,
MG, novembro 2007
[MPS.BR, 2007b] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO
SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guia de Avaliação, versão 1.1,
junho 2007. Disponível em: www.softex.br.
[MPS.BR, 2007b] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO
SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guia Geral, versão 1.2, junho
2007. Disponível em: www.softex.br.
54](https://image.slidesharecdn.com/mpsbrpt-130604084219-phpapp02/85/MPS-BR-Licoes-Aprendidas-55-320.jpg)
![[Oliveira, 2007] Oliveira,K.M. et al. Instituição Avaliadora Universidade Católica de
Brasília: Primeiras Avaliações e Impressões, II Workshop de Avaliadores MPS.BR,
Belo Horizonte, MG, novembro 2007
[Oliveira, 2008] Oliveira,J. Relatório Semestral da Instituição Avaliadora Estratégia,
agosto 2008
[Palestino, 2007] Palestino,C.B. Relatório Semestral da Instituição Avaliadora
CCOMP.MG/ FUMSOFT, dezembro 2007.
[Rocha,2007] Rocha,A.R. et al. IA COPPE/UFRJ: Lições Aprendidas e Melhores
Práticas, II Workshop de Avaliadores MPS.BR, Belo Horizonte, MG, novembro 2007
[Rocha, 2008] Rocha,A.R. Relatório Semestral da Instituição Avaliadora COPPE/UFRJ,
agosto 2008.
55](https://image.slidesharecdn.com/mpsbrpt-130604084219-phpapp02/85/MPS-BR-Licoes-Aprendidas-56-320.jpg)
MPS.BR Lições Aprendidas
- 1. MPS.BR Lições Aprendidas Ministério da Ciência e Tecnologia MPS.BR - Lições Aprendidas Os resultados alcançados até agora no programa MPS.BR - Melhoria de Processo do Software Brasileiro, lançado em dezembro de 2003 pela SOFTEX - Associação para Pro- moção da Excelência do Software Brasileiro, superaram os resultados esperados. As lições aprendidas tanto no progama MPS.BR quanto com o modelo MPS, no período 2004-2008, despertam interesse crescente no Brasil e em outros países. Esta publicação apresenta este Corpo de Conhecimento do MPS.BR, com as principais lições aprendidas em quatro áreas: Gestão do programa MPS.BRff Organização de grupos de empresas noff programa MPS.BR Implementação do modelo MPS em empresasff Avaliações MPSff Apoio: www.softex.br/mpsbr ISBN 978–85–99334–10–2 9 788599 334102 Organizadores Ana Regina Cavalcanti da Rocha Kival Chaves Weber Gestão do programa MPS.BR Organização de grupos de empresas no programa MPS.BR Implementação do modelo MPS em empresas Avaliações MPS
- 2. MPS.BR Lições Aprendidas Gestão do programa MPS.BR Organização de grupos de empresas no programa MPS.BR Implementação do modelo MPS em empresas Avaliações MPS Organizadores Ana Regina Cavalcanti da Rocha Kival Chaves Weber
- 3. FICHA CATALOGRÁFICA ELABORADA PELO Sistemas de Bibliotecas da UNICAMP / Diretoria de Tratamento da Informação Índices para Catálogo Sistemático 1. Software – Lições aprendidas – 001.6425 2. Programas de computador – 001.642 M879 MPS.BR : lições aprendidas / organizadores: Ana Regina Cavalcanti da Rocha e Kival Chaves Weber. -- Campinas, SP : Associação para Promoção da Excelência do Software Brasileiro- SOFTEX, 2008. 56 p. 1. Software – Lições aprendidas. 2. Programas de Computador. I. Rocha, Ana Regina Cavalcanti da. II. Weber, Kival Chaves. III. Título. CDD – 001.6425 - 001.642 ISBN 978-85-99334-10-2
- 4. MPS.BR – Lições Aprendidas Sumário Prefácio ........................................................................................... 4 1. Lições Aprendidas na Gestão do Programa MPS.BR (Gleison Santos e Kival Weber) ............................................................................... 5 2. Lições Aprendidas na Organização de Grupos de Empresas no Programa MPS.BR (Carlos Vicente Barbieri Palestino e Rosângela Miriam Mendonça) ........................................................................ 19 3. Lições Aprendidas na Implementação do Modelo MPS (Mariano Angel Montoni) .............................................................................. 31 4. Lições Aprendidas em Avaliações MPS (Ana Regina Rocha) ........................................................................................................ 41 3
- 5. MPS.BR – Lições Aprendidas Prefácio Uma lição aprendida é algo que se fez ou se deixou de fazer, é um acerto ou erro (no bom sentido) que se cometeu, é uma boa prática adotada, é tomar conhecimento de algo (graças a estudo, observação, experiência, etc.) que possa ser útil a outros interessados em uma determinada área do conhecimento. O programa mobilizador MPS.BR – Melhoria de Processo do Software Brasileiro foi criado em dezembro de 2003, sob coordenação da Associação para Promoção da Excelência do Software Brasileiro (SOFTEX). Nestes quase cinco anos de atividade, tanto os resultados alcançados superaram os resultados esperados como foram muitas as lições aprendidas. Por que publicar essas lições aprendidas? Primeiro, porque trata-se de um Corpo de Conhecimento do MPS.BR muito rico e útil a todos os interessados em programas de melhoria de processos de software baseados em modelos como o modelo MPS e o CMMI. Segundo, para atender ao disposto no documento "Reglamento Operativo 01mar05" do Programa de Apoio à Competitividade das PMEs de Software (BR-M1015), no qual o MPS.BR contou com apoio financeiro do Banco Interamericano de Desenvolvimento (BID): “Análise de lições aprendidas com a implementação e avaliação do modelo MPS em empresas (gestão do conhecimento na comunidade onde se praticou o mesmo), cujo objetivo é obter um documento contendo as lições aprendidas sobre a implementação, monitoramento, controle e avaliação tanto do programa MPS.BR quanto do modelo MPS”. Assim, é com muita satisfação que apresentamos esse documento-síntese das lições aprendidas nas seguintes áreas: i) gestão do programa MPS.BR; ii) organização de grupos de empresas no MPS.BR; iii) implementação do modelo MPS em empresas; e avaliações MPS. Campinas, Brasil, outubro de 2008 Organizadores: Ana Regina Cavalcanti da Rocha Kival Chaves Weber 4
- 6. Lições Aprendidas na Gestão do Programa MPS.BR Gleison Santos1 , Kival Chaves Weber2 1 COPPE/UFRJ – Universidade Federal do Rio de Janeiro Caixa Postal 68511 – CEP 21945-970 – Rio de Janeiro-RJ, Brasil [email protected] 2 SOFTEX – Associação para Promoção da Excelência do Software Brasileiro Caixa Postal 6123 – CEP 13081-970 – Campinas-SP, Brasil [email protected] Resumo. O principal objetivo do programa MPS.BR foi desenvolver e disseminar um modelo de processos de software visando a estabelecer um caminho economicamente viável para que organizações implementem a melhoria de seus processos de software em um intervalo de tempo justo a um custo razoável. Várias ações técnicas e gerenciais foram realizadas neste sentido e, também, para garantir a viabilidade, sustentabilidade e credibilidade do programa sob coordenação da Sociedade SOFTEX. Este artigo apresenta as principais lições aprendidas no contexto da gestão do programa MPS.BR que possibilitaram a sua rápida e eficaz disseminação. 1. Introdução O principal objetivo do programa MPS.BR (Melhoria de Processo do Software Brasileiro) foi desenvolver e disseminar um modelo de processos de software (o modelo MPS) visando a estabelecer um caminho economicamente viável para que organizações, incluindo as Pequenas e Médias Empresas (PME), alcancem os benefícios da melhoria de processos e da utilização de boas práticas da engenharia de software em um intervalo de tempo justo a um custo razoável. Embora o foco da iniciativa seja PMEs, o modelo é adequado também para apoiar a melhoria de processos em grandes empresas. Na etapa de implantação do programa MPS.BR, no período 2004-2007, foram enfrentados três desafios: técnico-científico, de mercado e gerencial. Em decorrência do desafio técnico-científico identificou-se que, para garantir sua relevância e sustentabilidade para a efetiva melhoria de processos de software no Brasil, seria necessário incorporar tanto práticas internacionalmente reconhecidas para implementação e avaliação de processos de engenharia de software quanto atender às necessidades de negócio da indústria de software brasileira. Foram, então, definidos o Modelo de Referência MR-MPS (SOFTEX, 2007j) e o Método de Avaliação MA-MPS (SOFTEX, 2007b) tendo como base as normas internacionais ISO/IEC 12207 e suas emendas (ISO/IEC, 1995; ISO/IEC, 2002; ISO/IEC, 2004) e ISO/IEC 15504 (ISO/IEC, 2003) e, devido a sua importância para organizações brasileiras que atuam em mercados internacionais, o modelo de maturidade CMMI (CHRISSIS et al., 2006). Atualmente estão sendo realizados os ajustes necessários para conformidade com a ISO/IEC 12207:2008 (ISO/IEC, 2008). Para atender ao desafio de mercado foi criado e aprimorado o Modelo de Negócio MN-MPS visando à disseminação do modelo MPS no Brasil, a um custo razoável para as Pequenas e Médias Empresas (PMEs), mas que também possa ser utilizado por grandes organizações públicas e privadas. Quanto ao desafio gerencial, o programa MPS.BR foi estruturado nacionalmente com a administração do programa e a execução das atividades sob coordenação da Associação para Promoção da Excelência do Software Brasileiro (SOFTEX). 5
- 7. Este artigo apresenta as principais lições aprendidas no contexto da gestão do programa MPS.BR. A próxima seção discute a gestão do programa MPS.BR. A seção 3 apresenta as lições aprendidas e, por fim, a seção 4 apresenta as considerações finais. 2. A Gestão do Programa MPS.BR Para gerenciar o programa MPS.BR, uma estrutura organizacional foi definida e responsabilidades foram atribuídas tanto a pessoal da SOFTEX quanto a pesquisadores e profissionais de engenharia de software. Esta estrutura organizacional tem a seguinte composição: • Unidade de Execução do Programa MPS.BR (UEP): responsável por definir estratégias e gerenciar as atividades do programa. A UEP é composta pelo Diretor de Qualidade e Competitividade da SOFTEX, Coordenador Executivo do MPS.BR e Gerente de Operações do MPS.BR. Esta unidade é coordenada pela SOFTEX. • Equipe Técnica do Modelo MPS (ETM): responsável pela (i) criação e aprimoramento contínuo do modelo MPS; e (ii) capacitação de pessoas por meio de cursos, provas e workshops do MPS.BR. Esta equipe é coordenada, atualmente, por um representante da Universidade Federal do Rio de Janeiro(COPPE/UFRJ). • Fórum de Credenciamento e Controle do MPS.BR (FCC): responsável por (i) emitir parecer que subsidie a decisão da Sociedade SOFTEX sobre o credenciamento de Instituições Implementadoras (II) e Instituições Avaliadoras (IA); e (ii) avaliar e controlar resultados de implementações e avaliações MPS; e (iii) assegurar que organizações avaliadas segundo o modelo MPS realizam suas atividades dentro dos limites éticos e de qualidade esperados. Este fórum é composto por representantes do governo, da indústria e da academia. • Conselho de Gestão do Programa MPS.BR (CGP): responsável por apoiar a Sociedade SOFTEX no planejamento das atividades anuais do programa e no acompanhamento da execução dessas atividades. O CGP é composto pelas principais partes interessadas no MPS.BR: direção da SOFTEX, membros da UEP, um representante por entidade com convênio assinado e vigente (que engloba as Instituições Organizadoras de Grupos de Empresas (IOGE), Instituições Implementadoras (II) e Instituições Avaliadoras (IA)), coordenador geral e de áreas da Equipe Técnica do Modelo (ETM) e membros do Fórum de Credenciamento e Controle (FCC). O ciclo PDCA (Plan-Do-Check-Act) (DEMING, 1986) provê um conjunto de ações geralmente associadas com a idéia central de que, para uma organização atingir um determinado objetivo, é preciso planejar e controlar as atividades necessárias para sua concretização. Neste modelo, a partir de um planejamento das metas e objetivos a serem cumpridos num determinado prazo, são executadas as atividades previstas seguidas de monitorações periódicas para avaliar o andamento do projeto e ações são elaboradas no sentido de aprimorar a execução das atividades. Para o MPS.BR há dois tipos de planejamento: um de longo prazo e outro de curto prazo. O de curto prazo compreende as atividades a serem realizadas num período de um ano de forma a atingir as metas de (i) desenvolvimento e aprimoramento do programa MPS.BR e do modelo MPS e (ii) implementação e avaliação do modelo MPS nas Empresas. Este planejamento está em sintonia com o planejamento de longo prazo que compreende um período de quatro anos 6
- 8. e define componentes/atividades usando a metodologia do Marco Lógico (LFA – Logical Framework Approach). No planejamento de longo prazo são traçadas as metas a serem cumpridas no período, é destacado o alinhamento do programa MPS.BR com o objetivo da Sociedade SOFTEX de desenvolvimento de mercado e aumento sustentável da competitividade da Indústria Brasileira de Software e Serviços e, também, são descritas as ações que devem ser executadas para o sucesso do programa. A operacionalização destas ações é feita pela equipe envolvida com o modelo MPS. São realizados dois tipos de reuniões periódicas para monitoração do andamento do programa: (i) reunião de acompanhamento do programa (RAP), presencial a cada dois meses, com participação de membros da UEP e coordenação da ETM; e (ii) reuniões semestrais do Conselho de Gestão do Programa (CGP) onde sempre é feita uma apreciação da sustentabilidade operacional, financeira e institucional do programa MPS.BR. Além disto, na reunião do final do primeiro semestre é feita uma verificação da execução do planejamento anual e na reunião do final do segundo semestre é feita uma análise crítica em relação aos resultados obtidos no ano e é aprovado o planejamento para o ano seguinte. Em sua fase atual, o programa mantém basicamente os dois grandes desafios originais do MPS.BR: • Consolidação da estrutura do programa MPS.BR e aprimoramento do modelo MPS, com quatro metas no período 2008-2010: • Consolidação da estrutura do programa MPS.BR; • Aprimoramento do modelo MPS; • Credenciamento de Instituições Implementadoras (II) e Instituições Avaliadoras (IA) do MPS.BR; • Análise de Lições Aprendidas (LA) e Resultados de Desempenho (RD) do MPS.BR. • Disseminação do modelo MPS no Brasil, com quatro metas no período 2008- 2010: • Treinamento no modelo MPS: cursos, provas e workshops do MPS.BR; • Apoio a grupo de empresas para implementação e avaliação MPS nos níveis G e F (base da pirâmide), mediante convênio com IOGEs; • Apoio a grupo de empresas para implementação e avaliação MPS nos níveis E, D e C (meio da pirâmide), mediante convênio com IOGEs; • Disseminação do processo de aquisição de software do MPS.BR (Guia de Aquisição). 3. Lições Aprendidas Desde o início, foram muitas as lições aprendidas na execução do programa MPS.BR e gestão de seu modelo de negócios. A seguir, são resumidas as cinco principais lições aprendidas neste contexto: 3.1 Modelo de Negócio – Um Modelo de Negócio, consistente com as necessidades de um programa abrangente como o MPS.BR, é necessário para garantir sua sobrevivência e gestão a longo prazo Para garantir o sucesso do modelo MPS, é essencial que as organizações possam efetivamente adotá-lo e se beneficiar da implementação de melhoria de processos de software. Dessa forma, um componente denominado Modelo de Negócio para Melhoria 7
- 9. de Processo de Software (MN-MPS) foi desenvolvido para apoiar a adoção e disseminação do modelo MPS. O modelo de negócio tem um papel muito importante na gestão do programa MPS.BR, descrevendo as regras de negócio para: implementação do modelo de referência MR-MPS pelas Instituições Implementadoras (II); avaliação seguindo o Método de Avaliação MA-MPS pelas Instituições Avaliadoras (IA); organização de grupos de empresas para implementação do MR-MPS e avaliação MA-MPS pelas Instituições Organizadoras de Grupos de Empresas (IOGE); certificação de Consultores de Aquisição (CA) de software e serviços correlatos, segundo o Guia de Aquisição do MPS.BR; realização de cursos, provas e workshops do MPS.BR, para treinamento de pessoas no modelo MPS. O MN-MPS compreende dois tipos de modelos de implementação de melhoria de processos de software de acordo com as necessidades específicas da organização e da disponibilidade de recursos: (i) o Modelo de Negócio Específico (MNE) adequado a grandes empresas que não querem compartilhar os serviços e custos de melhoria de processos de software baseados no modelo MPS; e (ii) o Modelo de Negócio Cooperado (MNC) para grupos de pequenas e médias empresas interessadas na implementação e avaliação do modelo MPS e no compartilhamento de serviços e custos, por exemplo, relacionados a atividades de treinamentos. O Modelo Cooperado de Negócio é especialmente atrativo para pequenas e médias empresas por que é passível de obtenção de recursos financeiros externos para o apoio à implantação e avaliação de melhoria de processos de software baseado no MPS.BR. Na Figura 1, que ilustra o MN-MPS, podem-se observar três domínios: domínio do Programa MPS.BR, coordenado pela SOFTEX, onde se encontram a UEP, ETM e FCC; domínio das Instituições Implementadoras (II) e Instituições Avaliadoras (IA) do MPS.BR; e domínio das empresas que adotaram o modelo MPS e das Instituições Organizadoras de Grupos de Empresas (IOGE). Sendo que o domínio das IOGEs compreende o Modelo de Negócio Cooperado (MNC) (pacote para grupos de empresas, próprio para Pequenas e Médias Empresas (PME) que desejam compartilhar custos e esforços principalmente na implementação do modelo MPS visando a uma avaliação seguindo o MA-MPS) e o Modelo de Negócio Específico (MNE) (personalizado para uma empresa, próprio para organizações que desejam exclusividade na implementação e avaliação MPS). Figura 1 – Modelo de Negócio do MPS.BR No Modelo de Negócio Específico para uma empresa (MNE), cada empresa interessada na implementação do modelo MPS negocia e assina um contrato específico com uma Instituição Implementadora (II) credenciada. Para avaliação do modelo MPS, 8
- 10. após sua implementação, a empresa negocia e assina outro contrato específico com uma Instituição Avaliadora (IA) credenciada - observando que a instituição avaliadora não poderá ser a mesma que implementou o Modelo MPS na empresa. No Modelo de Negócio Cooperado em Grupo de Empresas (MNC), o primeiro passo é a constituição de grupo de empresas comprometidas com a implementação e avaliação do Modelo MPS (o que pode acontecer, por exemplo, por iniciativa de um Agente SOFTEX). Sempre que pertinente, a SOFTEX (entidade coordenadora do programa MPS.BR) assina um convênio com uma Instituição Organizadora de Grupos de Empresas (IOGE) para cada grupo de empresas. A partir de sua constituição, a coordenação do grupo de empresas irá negociar e assinar um contrato com uma Instituição Implementadora (II) credenciada. Posteriormente, após a implementação, a IOGE negocia e assina contrato com uma ou mais IA credenciada - observando que a Instituição Avaliadora (IA) não pode ser a mesma instituição que implementou o modelo de referência MR-MPS nas empresas, nem a instituição que organizou o grupo de empresas. Pode-se fazer um paralelo entre o modelo de negócio MN-MPS com o triângulo de serviços (TEBOUL, 2008), que destaca a relação entre a Empresa, o Cliente e os Colaboradores da Linha de Frente, conforme pode ser visto na Figura 2. A Empresa é representada pelo próprio programa MPS.BR, na linha de frente, ou seja, no contato direto com os clientes, estão as IIs, IAs, IOGEs e Instrutores dos cursos oficiais. São estas entidades e pessoas os responsáveis por grande parte da imagem que os clientes têm do modelo MPS e estão em pé de igualdade com eles na responsabilidade pelo sucesso do projeto. De forma geral, na relação descrita no modelo de negócio MN-MPS destaca-se a busca pelo equilíbrio e sinergia entre as parte envolvidas. Procura-se, também, que o ciclo de relacionamento seja realimentado constantemente na busca por uma relação em que todos ganhem, visando à continuidade e aprimoramento do modelo MPS. Figura 2 – Triângulo de Serviços 3.2 Sustentabilidade - É necessário que haja sustentabilidade do programa MPS.BR em relação a aspectos operacionais, financeiros e institucionais Além de prover resultados, é importante que um programa como o MPS.BR seja sustentável em diferentes aspectos. Dessa forma, dentre os fatores de sucesso na gestão do programa, destacam-se tanto os resultados alcançados, ativos construídos e valor agregado pelo MPS.BR quanto sua sustentabilidade operacional, financeira e institucional. Esta sustentabilidade é conseguida através da coordenação do programa 9
- 11. MPS.BR exercida pela Sociedade SOFTEX e compreende todas as ações necessárias ao planejamento, execução, verificação e correções do programa, incluindo aspectos políticos, institucionais, operacionais, técnicos, administrativos e financeiros. A Sustentabilidade Operacional é conseguida através da coordenação geral efetuada pela SOFTEX por meio da Unidade de Execução do Programa MPS.BR (UEP) com apoio do Conselho de Gestão do Programa MPS.BR (CGP), da Equipe Técnica do Modelo MPS (ETM) e do Fórum de Credenciamento e Controle do MPS.BR (FCC)1 . Como resultados dessa cooperação são feitos o planejamento das atividades anuais do programa e o acompanhamento de suas execuções. A presença de representantes do FCC, da ETM e das entidades conveniadas garante representatividade dos maiores envolvidos com a execução do programa, procurando dar voz àqueles que estão na linha de frente da adoção do modelo pela comunidade brasileira e busca, assim, garantir um maior comprometimento de todos para com o sucesso do modelo. Como resultados visíveis desta sustentabilidade estão o contínuo interesse das empresas na implementação e avaliação segundo o modelo MPS e o contínuo interesse das fontes de recursos em apoiar o programa MPS.BR. A Sustentabilidade Financeira é importante para que haja continuidade das ações de implantação e disseminação do modelo e é conseguida através das receitas de serviços relacionados (por exemplo, cursos, provas, credenciamentos etc.) e, também, de apoio financeiro no âmbito dos convênios assinados entre a SOFTEX e Ministério da Ciência e Tecnologia (MCT), Financiadora de Estudos e Projetos(FINEP), Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE/PROIMPE) e Banco Interamericano de Desenvolvimento (BID/FUMIN). É importante notar que a sustentabilidade financeira do modelo não se refere apenas a despesas técnicas e gerenciais necessárias para prover uma infra-estrutura para a execução das atividades da UEP, CGP, ETM e FCC. É de conhecimento que a implantação de melhoria de processos de software não é barata (STAPLES et al., 2007). Dessa forma, parte importante e fundamental está no incentivo dado às empresas interessadas na adoção do modelo na forma de apoio financeiro para que iniciem as iniciativas de melhoria de processos, afinal sem elas não haveria o MPS.BR. Pode-se considerar que um dos fatores críticos de sucesso do MPS.BR até agora foi o apoio a Grupos de Empresas na Implementação e Avaliação do MPS.BR através das Instituições Organizadoras de Grupos de Empresas (IOGE) conveniadas com a SOFTEX. Neste modelo, há uma divisão das despesas envolvidas com implementação e avaliação entre o agente financiador (de até 40% do Custo de Referência por empresa) e a IOGE através da captação de recursos (sendo que deste total, pelo menos 30% deve vir de cada empresa envolvida). Na etapa de implantação do programa (2004-2007), privilegiaram-se as empresas ainda sem avaliações oficiais que estavam interessadas nos Níveis G e F do modelo. Na etapa de consolidação do MPS.BR (2008-2010), visando à maior disseminação do modelo e também que as empresas já avaliadas continuem na busca pela qualidade, o apoio financeiro deverá ser expandido também às empresas interessadas em implementações e avaliações nos Níveis E, D e C. A Sustentabilidade Institucional do MPS.BR é importante para garantir uma contínua adoção do modelo pelas organizações brasileiras tanto pelo reconhecimento das empresas de software que o adotam para melhorar seus processos quanto pelas demais empresas que as contratam para prestação de serviços ou adquirem seus produtos. O MPS.BR é um projeto estruturante do setor de software que visa à Melhoria de Processo 1 A composição e função da ETM e do FCC são muito importantes na gerência e sustentabilidade do programa MPS.BR e, por isso, serão descritas no contexto de duas outras lições aprendidas. 10
- 12. do Software Brasileiro em todas as regiões do país e, devido aos resultados obtidos desde sua criação, pode ser considerado um programa mobilizador bem sucedido. A disseminação e auxílio à implantação de melhores práticas aderentes aos padrões internacionais na Indústria Brasileira de Software e Serviços é feita através da implementação e avaliação MPS em empresas, da capacitação no uso do modelo MPS, da disseminação de melhores práticas além do escopo de processo de software (por exemplo, BSC, ITIL, COBIT, PMI, CMMI, entre outros) através da implementação e avaliação em empresas e da capacitação e certificação de profissionais. Assim, com o MPS.BR, estimula-se a adoção das melhores práticas de engenharia de software (por exemplo, qualidade, associativismo, gestão etc.) pelas empresas em seus processos de desenvolvimento bem como nos processos de aquisição de software e serviços correlatos, em conformidade com o estado da arte e as normas internacionais de qualidade aplicáveis. Desta forma, espera-se elevar a competitividade e a capacidade produtiva do setor de software e serviços correlatos, para ampliar a participação das empresas nacionais nos mercados interno e externo, tornando o Brasil uma das referências no cenário internacional do setor. Algumas ações são importantes para garantir a sustentabilidade institucional prolongada do modelo, por exemplo, a capacidade de mobilização e divulgação, a visibilidade dos ganhos obtidos com a adoção do modelo e a parceria indústria- academia. A parceria indústria-academia pode ser vista na composição da Equipe Técnica do Modelo (ETM), parte do foco da próxima lição aprendida, e também através da divulgação dos benefícios e resultados da execução do MPS.BR em fóruns especializados de engenharia de software no país e no exterior. Neste aspecto é importante salientar a constante e crescente apresentação de trabalhos técnicos e relatos de experiências em conferências internacionais e nacionais, tanto produzidas pela ETM quanto por empresas e pesquisadores que utilizam o MPS.BR no seu dia-a-dia. Um dos efeitos da iteração com a academia é a criação de um público para a melhoria de processos de software no ambiente universitário, sejam alunos ou professores tanto de graduação ou pós-graduação, que, uma vez no mercado de trabalho, contribuirão para fomentar a utilização do modelo na indústria. A capacidade de mobilização e divulgação não se restringe, no entanto, a eventos acadêmicos. Ela está presente também: (i) na divulgação dos resultados oficiais das avaliações MA-MPS realizadas, sempre acompanhadas de depoimentos do patrocinador e membros da empresa sobre o significado da implantação do MPS.BR na organização em questão; (ii) na divulgação do modelo em outros países; (iii) na busca pela implementação do MPS.BR em todas as regiões e os estados brasileiros; e (iv) na organização de fóruns específicos, na forma de workshops anuais, de discussão de melhores práticas e lições aprendidas entre os implementadores, avaliadores e empresas envolvidos com o MPS.BR. Tendo em vista o cenário da crescente disseminação do modelo e a constatação que normalmente as empresas só implementam as boas práticas da engenharia de software quando estas são exigidas para certificações (NOGUEIRA, 2006), acreditamos que o programa MPS.BR esteja contribuindo para promover boas práticas da engenharia de software na indústria nacional, incluindo as PMEs. Afinal, os resultados de processo do modelo prevêem boas práticas como a condução de revisões por pares, a realização de testes, a mitigação de riscos, a gerência de conhecimento, práticas de reutilização de software, entre outros. Diferentes resultados podem ser observados com a implementação dessas boas práticas pelas organizações. 11
- 13. Com o cenário da crescente adoção do modelo e das boas práticas da engenharia de software nele previstas surge o interesse por compreender qualitativamente variáveis de desempenho decorrentes da adoção destas práticas, como custo, produtividade e qualidade. Adicionalmente um dos desafios para a melhoria dos processos de engenharia de software nas PMEs de acordo com modelos de maturidade é convencê-las dos resultados de negócio esperados (CATER-STEEL et al., 2006; GRESSE VON WANGENHEIM et al., 2006). Dessa forma, além da visibilidade dos ganhos obtidos com a adoção do modelo que pode ser vista em decorrência da apresentação de trabalhos nos workshops do MPS, foi definido uma sistemática para coleta de informações sobre Resultados de Desempenho de organizações que adotaram o modelo MPS, denominada iMPS (KALINOWSKI et al., 2008). Esta sistemática é decorrente de um convênio assinado entre a SOFTEX e o BID e prevê a monitoração junto às organizações que adotaram o modelo MPS do seu índice de satisfação com o MPS.BR e os resultados de desempenho decorrentes da melhoria de processos baseada no modelo MPS, em categorias tais como: custo, prazo, produtividade, qualidade, satisfação do cliente e retorno do investimento (ROI). 3.3 Competência Técnica – Competência técnica é um importante fator para dar credibilidade ao modelo e atender às necessidades de melhoria de processos de software das empresas Um fator crítico de sucesso na gestão do MPS.BR é a Equipe Técnica do Modelo (ETM) composta por membros convidados pela SOFTEX, escolhidos anualmente entre profissionais com larga experiência em engenharia de software e melhoria de processos de software na indústria, academia e governo. A ETM é responsável pela criação e aprimoramento contínuo do modelo de referência MR-MPS e método de avaliação MA- MPS, incluindo sua documentação por meio de Guias do MPS, e pela capacitação de pessoas por meio de cursos, provas e workshops do MPS.BR. Atualmente a ETM é composta por profissionais oriundos da COPPE/UFRJ, Companhia de Informática do Paraná (CELEPAR), Sociedade Mineira de Software (FUMSOFT), Universidade Católica de Brasília (UCB), SwQuality Consultoria e Sistemas, Centro de Tecnologia da Informação Renato Archer (atual CTI, antigo CenPRA), Sociedade Núcleo de Apoio a Produção e Exportação de Software do Rio de Janeiro (RIOSOFT), Marinha do Brasil, SOFTEX Campinas, ASR Consultoria e Assessoria em Qualidade, Fundação Vanzolini (FCAV), Associação Sul-riograndense de Apoio ao Desenvolvimento de Software (SOFTSUL) e Estratégia Tecnologia da Informação, sob coordenação da COPPE/UFRJ. Atualmente há seis áreas na ETM, cada uma com um foco específico: Aquisição, Avaliação, Disseminação Nacional, Implementação, Introdução e Publicações. A parte técnica do modelo MPS é composta pelo modelo de referência MR-MPS e o método de avaliação MA-MPS, documentados através de guias disponíveis gratuitamente a todos os interessados na seção Guias em <www.softex.br/mpsbr>, em Português e Espanhol, que incluem: Guia Geral (SOFTEX, 2007j), Guia de Implementação (SOFTEX, 2007c; SOFTEX, 2007d; SOFTEX, 2007e; SOFTEX, 2007f; SOFTEX, 2007g; SOFTEX, 2007h; SOFTEX, 2007i), Guia de Aquisição (SOFTEX, 2007a) e Guia de Avaliação (SOFTEX, 2007b). Estes guias são constantemente aprimorados visando ao pleno atendimento de requisitos de conformidade com novas versões das normas internacionais aplicáveis e de compatibilidade com o CMMI (CHRISSIS et al., 2006), além de estarem consistentes com as melhores práticas da engenharia de software e com as necessidades e a realidade das empresas brasileiras desenvolvedoras de software. Deve-se ressaltar que o modelo MPS contém resultados 12
- 14. exigidos para processos e para atributos de processo, não determinando os métodos, técnicas e ferramentas que devem ser empregados para alcançar estes resultados. Esta natureza do modelo permite assegurar uma interação sinérgica com a academia, convidando esta a exercer a importante função de gerar conhecimento a respeito de métodos, técnicas e ferramentas da engenharia de software que permitam alcançar seus resultados, de modo a maximizar o retorno de investimento. Assim, o modelo poderia servir como um arcabouço motivador de pesquisas na academia, por indicar as áreas que demandam geração de conhecimento de engenharia de software concretamente aplicável pela indústria brasileira, visando o estabelecimento de vantagens competitivas tanto no mercado local quanto global. A capacitação de pessoas no modelo MPS é feita por meio de cursos, provas e workshops do MPS.BR, sob supervisão da ETM, e da certificação MPS de Consultores de Aquisição (CA) de software e serviços correlatos. Os seguintes cursos e provas do MPS.BR são ministrados por instrutores treinados e autorizados, a custos bem mais acessíveis que os de modelos equivalentes: Curso de Introdução (C1), Prova de Introdução (P1), Curso para Implementadores (C2), Prova para Implementadores (P2), Curso para Avaliadores (C3), Prova para Avaliadores (P3), Curso de Aquisição (C4), Prova de Aquisição (P4). Estes cursos e provas são ministrados e aplicados em todas as regiões do país. Até 2007, mais de 2.800 pessoas participaram de cursos do MPS.BR, tendo mais de 800 aprovados nas provas, e havia mais de 30 instrutores treinados e autorizados a ministrar estes cursos. Além disso, atenta à realidade das empresas implementando o modelo MPS e visando a uma maior capacitação dos implementadores MPS e dos participantes da implementação de processos nas organizações, a ETM procura rever periodicamente a lista de cursos oficiais disponíveis. Neste sentido, há treinamentos visando à atualização de conhecimento decorrente de evoluções no guias e também novos treinamentos específicos para níveis de maturidade e processos específicos, por exemplo, está sendo criado um novo curso relacionado à Implementação dos Níveis F e E (C21). 3.4 Acreditação – A credibilidade do modelo MPS deve ser uma preocupação constante da gestão do programa MPS.BR Na gestão do programa, é fundamental o papel do Fórum de Credenciamento e Controle (FCC) constituído por representantes do Governo, Universidades e Indústria (SOFTEX). O FCC é responsável pela emissão de pareceres para subsidiar decisão da SOFTEX sobre o credenciamento de Instituições Implementadoras (II) e Instituições Avaliadoras (IA) e pela monitoração dos resultados das IIs e IAs, emitindo parecer propondo à SOFTEX seu descredenciamento no caso de comprometimento da credibilidade do modelo MPS. Atualmente o FCC é composto por representantes do MCT, Universidade de São Paulo em São Carlos (USP SCar), COPPE/UFRJ e SOFTEX. As Instituições Implementadoras (II) são instituições autorizadas, mediante convênio assinado com a SOFTEX, como implementadora do MR-MPS. Como tal, para serem autorizadas, devem apresentar-se dando ênfase na experiência em processos de software, possuir uma estratégia definida de Implementação do MR-MPS nas organizações e, também, uma estratégia para seleção, capacitação e manutenção da competência dos membros da equipe de implementação do MR-MPS. Em sua estrutura deve haver pelo menos 3 consultores de implementação treinados no Modelo e aprovados em prova específica (no mínimo 1 coordenador e 2 membros de equipe). As Instituições Avaliadoras (IA) são instituições autorizadas, mediante convênio assinado com a SOFTEX, como avaliadora seguindo o MA-MPS e, como tal, devem, 13
- 15. para serem autorizadas, demonstrar possuir uma estratégia institucional de capacitação dos avaliadores, líder e adjunto, com destaque para os processos de seleção, capacitação e manutenção da competência dos avaliadores, considerando uma combinação de conhecimento, habilidades e atributos pessoais; ter um coordenador da IA que cumpra os requisitos de avaliador líder inicial, intermediário ou experiente; e ter, no mínimo, 1 (um) profissional que cumpra os requisitos de avaliador líder inicial, intermediário ou experiente e 1 (um) profissional que cumpra os requisitos de avaliador adjunto. Uma das preocupações do FCC é manter-se fiel à estratégia de procurar credenciar novas IIs e IAs em todas as regiões do país para minimizar os custos com serviços de consultoria de implementação e avaliação do modelo MPS pelas organizações. Não só a existência de IIs e IAs garante o controle sobre as implementações e avaliações segundo o Modelo MPS, a realização de auditorias também procurar dar maior credibilidade às ações relacionadas a implementação e avaliação dos processos. Todas as avaliações MPS são auditadas pelo Grupo de Auditores do MPS.BR, sob supervisão do FCC e coordenação da SOFTEX. O auditor emite parecer sobre a auditoria, que pode ser “Aprovado” (a documentação está completa, correta e não há dúvidas com relação ao resultado da avaliação), “Aprovado com Modificações” (não há dúvidas com relação ao resultado da avaliação, mas a documentação não está completa ou correta), “Não Aprovado” (há dúvidas com relação ao resultado da avaliação). No caso de um parecer “Não Aprovado”, o auditor envia o parecer à SOFTEX e a documentação da avaliação à SOFTEX e esta convoca o avaliador líder para uma reunião de esclarecimentos com o auditor analisando-se a planilha de indicadores. Caso as dúvidas não sejam resolvidas com esta reunião, a SOFTEX realiza uma auditoria na unidade organizacional que foi avaliada. Além disso, é feito um controle sobre o trabalho das Instituições Organizadoras de Grupos de Empresas (IOGE) em conjunto com as Instituições Implementadoras. A declaração de uma IOGE de que a unidade organizacional cumpriu 100% da implementação significa que a unidade organizacional está pronta para ser avaliada com sucesso segundo o julgamento da IOGE e da II. Isto significa que, se o resultado da avaliação não for positivo, a IOGE poderá ser responsabilizada após a auditoria da avaliação por fornecer declaração inadequada. 3.5 Ferramentas – O uso de ferramentas adequadas facilita a gerência das atividades e aumenta o poder de comunicação entre os interessados Da mesma forma que há estudos que indicam que a melhoria de processos de software pode ser facilitada pela infra-estrutura de processos de software (por exemplo, (SANTOS et al., 2007)), um bom conjunto de ferramentas é fundamental para facilitar a execução das atividades inerentes à gerência do programa MPS.BR. Neste sentido, as principais ferramentas em uso pela SOFTEX na gestão do programa são o portal do MPS.BR, o MPS.Web, o CoreKM e o iMPS. O Portal do MPS.BR, disponível no endereço <www.softex.br/mpsbr>, é a principal ferramenta de gestão do programa MPS.BR e de comunicação com as diversas partes interessadas. Através deste portal são disponibilizados gratuitamente os guias oficiais do modelo MPS, em versões em Português e Espanhol: Guia Geral, Guia de Implementação, Guia de Avaliação e Guia de Aquisição. Também estão disponíveis neste website os Comunicados oficiais do programa MPS.BR que tratam de assuntos como divulgação de cursos e provas, regras de credenciamento, divulgação de apoio a grupos de empresa, etc. Além disso, pode-se encontrar listas de: Instituições Avaliadoras (IA) capacitadas para avaliar o MPS.BR em organizações que implementaram o modelo de referência MR-MPS, seguindo o método de avaliação MA-MPS; Instituições 14
- 16. Organizadoras de Grupos de Empresas (IOGE) que assinaram Termo de Convênio com a Sociedade SOFTEX para Implementação e Avaliação do MPS.BR em grupos de empresas; Instituições Implementadoras (II) que demonstraram capacidade para promover a implementação do modelo de referência MR-MPS em empresas e grupos de empresas, única e exclusivamente através das pessoas habilitadas como Consultores de Implementação do MPS.BR; empresas avaliadas com sucesso no MPS.BR desde 2005 segundo o método de avaliação MA-MPS; participantes dos cursos oficiais e aprovados nas provas de Introdução, Implementadores, Avaliadores e Aquisição de Software do MPS.BR; participantes dos workshops de reciclagem de implementadores e avaliadores do MPS.BR. O MPS.Web é o software que auxilia na gerência e planejamento dos cursos, provas e workshops do MPS.BR. O CoreKM é um Ambiente de Gestão do Conhecimento composto de ferramentas de apoio a processos organizacionais que foi adaptado para possibilitar o controle de informações relevantes para a gerência do MPS.BR, tais como as relacionadas a: avaliadores; Instituições Avaliadores (IA) e propostas de credenciamento de IAs; avaliações realizadas; implementadores; Instituições Implementadoras (II) e propostas de credenciamento de IIs; Instituições Organizadoras de Grupos de Empresas (IOGE) e propostas de credenciamento de IOGEs. O iMPS foi construído com base na infra-estrutura do CoreKM e é responsável pelo armazenamento e gerência das informações sobre o Resultado de Desempenho de organizações que adotaram o modelo MPS. 4. Conclusão As lições aprendidas relatadas neste artigo procuraram apresentar um panorama geral sobre a gestão do programa MPS.BR em relação a sustentabilidade, competência técnica, acreditação, modelo de negócio e ferramentas. De certa forma, estas lições aprendidas resumem fatores que, uma vez combinados entre si e com o trabalho realizado por todos os envolvidos, levaram até agora a uma boa gestão do programa MPS.BR. Esta lista, no entanto, não é final e, com certeza, novos itens serão acrescentados com uma maior maturidade do programa ao longo do tempo. Além disso, elas devem ser complementadas com a visão das lições aprendidas no contexto da organização de grupos de empresas no programa MPS.BR, implementações do modelo MPS em empresas e avaliações MPS. Quanto ao programa MPS.BR, chegamos às seguintes conclusões: (i) até agora, foi garantida a sustentabilidade do programa e os resultados alcançados foram excelentes, superando os resultados esperados; (ii) é empreendimento magno no setor de software brasileiro, com forte interação Universidade-Empresa-Governo; (ii) o MPS.BR é um programa de longo prazo; (iv) o MPS.BR é um programa mobilizador; e, sobretudo (v) trata-se de um grande esforço de capacitação nacional (de pessoas, instituições e organizações interessadas no modelo MPS) para melhorar continuamente os processos de software nas empresas, sua capacidade de inovar e de competir no mercado local e global. Além disso, como resultados relevantes do MPS.BR no cenário nacional espera- se: (i) consolidação do programa MPS.BR, com forte interação Academia-Indústria- Governo; (ii) aprimoramento do modelo MPS, em conformidade com as normas internacionais aplicáveis, compatível com o CMMI, baseado nas melhores práticas da engenharia de software e adequado à realidade das empresas brasileiras; (iii) estimulo à adoção de melhores práticas de engenharia de software pelas empresas do setor em seu 15
- 17. processo de desenvolvimento e manutenção bem como nos processos de aquisição de software e serviços correlatos, em conformidade com o estado da arte e as normas internacionais de qualidade aplicáveis; (iv) aumento da capacitação por meio de cursos e provas do MPS.BR, em todas as regiões do país; (vi) aumento significativo no número de empresas com avaliação MPS publicadas, seja na base da pirâmide (níveis G e F do modelo MPS) seja no meio da pirâmide (níveis E, D e C), em todas as regiões brasileiras; e (vii) aumento da competitividade da indústria de software do Brasil no mercado local e mundial de software. Dessa forma, o desafio dos próximos anos para a gestão do programa será a consolidação da estrutura organizacional do MPS.BR visando a manter sua sustentabilidade institucional, operacional e financeira. Referências CATER-STEEL, A., TOLEMAN, M., ROUT, T., 2006, "Process improvement for small firms: An evaluation of the RAPID assessment-based method", v. 48, pp. 323- 334. CHRISSIS, M.B., KONRAD, M., SHRUM, S., 2006, CMMI (Second Edition): Guidelines for Process Integration and Product Improvement, Addison Wesley Professional. DEMING, W.E., 1986, Out of the Crisis, Cambridge: MIT Center for Advanced Engineering Study. GRESSE VON WANGENHEIM, C., VARKOI, T., SALVIANO, C.F., 2006, "Standard based software process assessments in small companies", v. 11, n. 3, pp. 329-- 335. ISO/IEC, 1995, "Systems and software engineering – Software life cycle processes", The International Organization for Standardization and the International Electrotechnical Commission, v. ISO/IEC 12207:1995. ISO/IEC, 2002, "Information Technology - Amendment 1 to ISO/IEC 12207", The International Organization for Standardization and the International Electrotechnical Commission, v. ISO/IEC-12207:Amd1. ISO/IEC, 2003, "Information Technology – Software Process Assessment", Parts 1-9, The International Organization for Standardization and the International Electrotechnical Commission, v. ISO/IEC 15504. ISO/IEC, 2004, "Information Technology - Amendment 2 to ISO/IEC 12207", The International Organization for Standardization and the International Electrotechnical Commission, v. ISO/IEC-12207:Amd2. ISO/IEC, 2008, "Systems and software engineering – Software life cycle processes", The International Organization for Standardization and the International Electrotechnical Commission, v. ISO/IEC 12207:2008. KALINOWSKI, M., WEBER, K.C., TRAVASSOS, G.H., 2008, "iMPS: An Experimentation Based Investigation of a Nationwide Software Development Reference Model". In: 2nd International Symposium on Empirical Software Engineering and Measurement (ESEM 2008), Kaiserslautern, Germany, October 9-10. NOGUEIRA, M.O., 2006, Qualidade no Setor de Software Brasileiro, Tese de D. Sc., COPPE, UFRJ, Rio de Janeiro, Brasil. SANTOS, G., MONTONI, M., FIGUEIREDO, S., et al., 2007, "SPI-KM - Lessons Learned from Applying a Software Process Improvement Strategy Supported by Knowledge Management", Product-Focused Software Process Improvement. 16
- 18. SOFTEX, 2007a, "MPS.BR - Guia de Aquisição". SOFTEX, 2007b, "MPS.BR – Guia de Avaliação". SOFTEX, 2007c, "MPS.BR – Guia de Implementação – Parte 1: Nível G". SOFTEX, 2007d, "MPS.BR – Guia de Implementação – Parte 2: Nível F". SOFTEX, 2007e, "MPS.BR – Guia de Implementação – Parte 3: Nível E". SOFTEX, 2007f, "MPS.BR – Guia de Implementação – Parte 4: Nível D". SOFTEX, 2007g, "MPS.BR – Guia de Implementação – Parte 5: Nível C". SOFTEX, 2007h, "MPS.BR – Guia de Implementação – Parte 6: Nível B". SOFTEX, 2007i, "MPS.BR – Guia de Implementação – Parte 7: Nível A". SOFTEX, 2007j, "MPS.BR – Guia Geral". STAPLES, M., NIAZI, M., JEFFERY, R., et al., 2007, "An exploratory study of why organizations do not adopt CMMI", v. 80 pp. 883–895. TEBOUL, J., 2008, Serviços em cena: o diferencial que agrega valor ao seu negócio, Brasília, IEL/NC. 17
- 19. 18
- 20. Lições Aprendidas na Organização de Grupos de Empresas no Programa MPS.BR Carlos Vicente Barbieri Palestino, Rosângela Miriam L. O. Mendonça FUMSOFT/CCOMP.MG - Centro de Competência Fumsoft em MPS.BR e CMMI Av. Afonso Pena 4000, 3º andar - Cruzeiro - Belo Horizonte - MG - CEP: 30130-009 {carlos_barbieri,rosangela}@fumsoft.softex.br Resumo. Este trabalho descreve as lições aprendidas por instituições na organização e gerenciamento de grupos de empresas para implementação e qualificação no modelo MPS. 1. Introdução Os trabalhos relacionados à implementação do modelo MPS são muitas vezes tratados congregando um conjunto de empresas com um objetivo comum: melhorar seus produtos e serviços por meio do amadurecimento de seus processos com conseqüente adequação da sua estrutura organizacional e de sua forma de trabalho. Nesse contexto, a atuação de uma organização no gerenciamento desses grupos é imprescindível e a eficiência de suas ações é fator decisivo para o sucesso dessa iniciativa de estilo cooperado e sinérgico. Essa organização, chamada IOGE – Instituição Organizadora de Grupos de Empresa, que funciona como uma articuladora de grande parte dessas ações, deve possuir alguns atributos, praticar certos valores e desenvolver determinadas habilidades, que podem ser consideradas fatores críticos de sucesso nessa empreitada. Este artigo descreve as experiências observadas por diversas instituições desempenhando esse papel de aglutinador de empresas, dentro do contexto do programa MPS.BR da SOFTEX e sob a sua gerência, e relata as suas lições aprendidas nas diversas formações de grupos. 2. Organização de Grupos de Empresas e o Modelo de Negócio Cooperado (MNC) O modelo MPS, do ponto de vista de modelo de negócio, pode ser implementado como Negócio Cooperado (MNC) ou Específico (MNE). O MNC é um pacote para grupos de empresas, próprio para Pequenas e Médias Empresas (PME) que desejam compartilhar custos e esforços principalmente na implementação do Modelo MPS visando uma avaliação seguindo o MA-MPS. Já o MNE é próprio para organizações que desejam exclusividade ao implementar individualmente, no seu próprio ritmo, o Modelo MPS. No contexto do Modelo de Negócio Cooperado (MNC) é que aparece o papel fundamental das IOGEs, que congregam empresas interessadas, criando um agrupamento onde ações e experiências são compartilhadas e os custos de implementação são diluídos. Esse movimento de sinergia facilita sobremaneira a inclusão de empresas, que pelas vias normais do modelo de 19
- 21. 20 negócio específico (MNE), por vezes, não poderiam participar, dados os investimentos requeridos. A IOGE deve estabelecer um relacionamento formal com as empresas, através de um contrato de prestação de serviços, contendo todos os direitos e obrigações das partes. A IOGE pode acumular o papel de II (Instituição Implementadora1 ) ficando ao seu encargo também as questões técnicas de implementação, além daquelas de cunho administrativo-gerencial, que envolvem os agrupamentos de empresas. No caso do cenário onde não exista esta sobreposição de papéis (IOGE e II), será necessário contratar implementadores credenciados independentes ou uma II. Além disso, IOGE e II deverão elaborar um Projeto Técnico de Implementação, onde serão detalhadas as atividades necessárias à implementação em cada empresa. Esse documento formaliza o relacionamento técnico entre as três partes – IOGE, II e Grupo de Empresas. Ao final do processo de implementação, a IOGE definirá um relacionamento com um outro ator deste cenário, a IA (Instituição Avaliadora), objetivando a execução das avaliações formais, concluindo o ciclo. A Sociedade SOFTEX algumas vezes atua como catalisadora das ações de formação de grupo de empresas ao oferecer às IOGEs apoio financeiro para implementação e avaliação MPS em organizações desenvolvedoras de software. Para isso define as regras regulamentando os relacionamentos e contrapartidas entre ela (SOFTEX) e os demais atores: IOGE, II, IA e as empresas. Para que uma IOGE receba apoio é necessário que ela submeta para avaliação da SOFTEX, uma série de documentos e comprometimentos de ações como: um Projeto(s) de Implementação e Avaliação MPS, assinatura de contrato com as empresas participantes do grupo garantindo seu desembolso financeiro mínimo de 30%; assinatura de contrato com uma Instituição Implementadora (II) do MR-MPS, autorizada pela SOFTEX; especificação de marcos a serem alcançados correspondentes a 50% e 100% em relação ao planejado no cronograma de implementação; designação do gerente do grupo de empresas na instituição organizadora e do coordenador da instituição implementadora (II) e a definição de penalidades para a desistência da empresa ao longo dos trabalhos do grupo e o não cumprimento dos marcos pelas empresas. A Figura 1 mostra a forma pela qual, nesse caso, a IOGE se relaciona com os outros atores envolvidos. 1 É chamada II uma organização previamente credenciada pela SOFTEX que tenha demonstrado capacidade para promover a implementação do modelo MR-MPS em empresas e grupos de empresas, única e exclusivamente através das pessoas habilitadas, cadastradas pela II junto à SOFTEX como seu corpo de Consultores de Implementação do MPS.BR.
- 22. 21 Figura 1: Relacionamento da IOGE com demais atores apoiados pela SOFTEX 3. A Atuação das IOGEs A SOFTEX atua com um grupo de IOGEs que são qualificadas e credenciadas ao recebimento de apoio financeiro mediante assinatura de convênio. Estão habilitadas a se candidatarem agentes SOFTEX no país e outras instituições sem fins lucrativos2 , mediante apresentação de Projeto(s) de Implementação e Avaliação MPS, bem como uma série de outros documentos que formalizam os comprometimentos entre os envolvidos. Desde 2005, quando foi publicado o primeiro Comunicado para Apoio a Grupo de Empresas (Apoio a Grupos de Empresas para Implementação e Avaliação MPS – Níveis G e F (COMUNICADO SOFTEX MPS.BR 20/2005), um acervo de experiências e lições aprendidas tem sido coletado e registrado por diversas instituições organizadoras de grupos de empresas. As IOGEs FUMSOFT (Belo Horizonte-MG), TECSOFT (Brasília-DF), ACATE (Florianópolis-SC), ITS (São Paulo-SP), INSOFT (Fortaleza-CE), RIOSOFT (Rio de Janeiro- RJ), SOFTEX Campinas (Campinas - SP), SOFTEX Recife (Recife-PE), SOFTSUL (Porto Alegre-RS), COPPE (Rio de Janeiro-RJ), Fundação Vanzolini (São Paulo-SP) e 2 Estas instituições sem fins lucrativos (entidades civis ou congêneres no país) devem ter experiência comprovada na organização de grupos de empresas para melhoria de processo de software, tais como grupos de empresas Rumo à ISO 9000 e Rumo ao CMM/CMMI.
- 23. 22 TECVITÓRIA (Vitória-ES) apresentaram diversas experiências no II Workshop de IOGEs MPS.BR, cujo relato constitui a essência desse texto. Algumas dessas instituições iniciaram as suas atividades de melhoria de qualidade em modelos anteriores ao MPS. Algumas já haviam promovido grupos de empresas objetivando a qualificação em CMM e CMMI. Outras, já haviam tido incursões em modelos mais genéricos de qualidade como ISO-9000. Dessa forma, para algumas delas, já havia uma experiência pregressa, cujo resultado foi a criação de núcleos de conhecimentos e disseminação em qualidade de processos. Esses núcleos atenderam à demanda das suas empresas associadas na busca pela melhoria de seus produtos e serviços, expandindo assim seu perfil competitivo para novos mercados, tanto no âmbito nacional quanto internacional. Essa experiência, anteriormente acumulada, facilitou o engajamento desses agentes no modelo MPS, quando este apareceu em 2004. Para incentivar a adesão ao programa MPS.BR as IOGEs adotam hoje diferentes estratégias. Algumas, como a TECSOFT, promovem o MPS.BR incentivando a formação de IIs e IAs, com as quais se associam objetivando o alcance de seus objetivos. Outras, como Fumsoft, Riosoft e COPPE/UFRJ, formam seu próprio núcleo de implementação de qualidade, criando uma sobreposição de papéis que pode ser considerada como um facilitador no processo, pois evita canais heterogêneos de comunicação entre a organizadora e a implementadora, agilizando eventuais resoluções de conflitos. Por outro lado, eventuais problemas detectados na implementação, refletem diretamente na IOGE, visto serem, na realidade, a mesma entidade, com dois papéis diferentes. Além desses aspectos organizacionais, outros fatores contribuem para o alcance pleno dos objetivos de uma IOGE. A análise das experiências relatadas por elas, constitui as lições aprendidas, descritas a seguir. 4. Lições aprendidas São elementos importantes na formação de grupos de empresas para implementação e avaliação MPS: 4.1. Definir um plano para formação e condução dos grupos de empresas Para a formação de um grupo de empresas, deverá ser seguido um conjunto de ações, que formam um plano de implementação dos grupos. Basicamente essas ações podem ser traduzidas por: Atividades de esclarecimento sobre o modelo MPS Essas atividades deverão ser desenvolvidas procurando-se mobilizar a comunidade de empresas, através de palestras onde são mostrados o modelo MPS, com seus detalhes, valores e condições contratuais, um esboço do plano de implementação contendo as atividades a serem realizadas e exemplos de resultados alcançados por empresas do setor.
- 24. 23 Atividades para seleção de empresas Um aspecto muito importante, observados por diversas IOGEs, se refere a heterogeneidade das empresas participantes dos grupos. As variações de tamanho, nível de amadurecimento e capacidade das empresas que compõem o grupo devem ser observadas com cuidado. Alguns relatos de experiência apontam que empresas com menos de 10 colaboradores, bem como aquelas com mais de 99 colaboradores podem sugerir maior dificuldade nos trabalhos dentro do modelo cooperado. Uma análise prévia, abrangendo o detalhamento do perfil da empresa, uma entrevista com diretores e um mapeamento de suas potencialidades pode mitigar esses problemas. Entretanto, um ponto de cautela é sugerido: a grande maioria dos empresários superestima a capacidade de gerenciamento e controle de processos de sua equipe, imaginando um patamar maior do que onde realmente se encontram. Assim, numa primeira manifestação de intenção tendem a buscar uma avaliação MPS em um nível mais alto que a sua capacidade real de esforço, o que certamente dificultará o processo de implantação da metodologia. Assim é fundamental que, nas entrevistas iniciais, as empresas sejam orientadas a buscar um grau de maturidade compatível com a sua capacidade efetiva de realização. Atividades de formalização dos contratos Essas atividades envolvem os esclarecimentos e definição dos detalhes legais do contrato, normalmente feito através de interlocuções entre as áreas jurídicas das partes envolvidas (IOGE e empresas). Atividades de implementação e acompanhamento dos trabalhos Representam a execução das atividades técnicas definidas no Plano de Implementação e seus respectivos acompanhamentos. As atividades de implementação estarão a cargo da II, e a IOGE deverá estabelecer mecanismos de acompanhamento, aferindo a devida execução do ponto de vista do cronograma definido e da qualidade da prestação dos serviços envolvidos. Isso deverá ser feito, por meio de contatos formais como reuniões de análise crítica com as empresas alvo. Baseada nessas percepções é que a IOGE prestará contas à SOFTEX, quando for o caso, através do envio regular de relatórios de andamento, definidos no contrato assinado por ambas. Atividades de avaliação e finalização do ciclo As atividades de avaliação seguirão à finalização do ciclo definido de implementação e envolverão os contatos e negociações com as diversas IAs. Essa interlocução e escolha final da IA deverá ter a participação de cada empresa, que deverá conhecer os detalhes dos contratos acordados e dos estilos de cada avaliadora, no que tange a sua história de experiência e estilos de interpretação das exigências. Observação geral: Como o conjunto de participantes pode ser grande, fornecer um plano bem elaborado e definido para a adesão das empresas é um facilitador significativo, evitando particularidades que dificultam a gestão dos trabalhos. A definição de marcos com atividades com a participação de todos, estabelecendo um sincronismo macro é bastante benéfico.
- 25. 24 Mesmo sendo um trabalho cooperado, por vezes, é necessário atender a alguns pontos que sejam importantes para uma empresa e que não afetem o conjunto. Às vezes especificidades de empresas em função de prioridades momentâneas precisam ser relevadas. Por isso, é necessário ter um nível adequado de flexibilidade, que é conseguido ao se fornecer aos atores os limites de atuação e delegar a eles, dentro destes limites, a decisão final (por exemplo, pode ser deixado a critério dos consultores e empresas a definição das datas de consultoria, controlando-se apenas a distribuição possível do total de horas alocado). Sem necessariamente estar relacionado a uma representação hierárquica, ter um líder global do projeto que conte com o respeito de todos é um facilitador em momentos de impasse. 4.2.Oferecer Credibilidade A credibilidade da IOGE por seu histórico no mercado, em função de seus movimentos de apoio às empresas em projetos diversos como incubação, incentivo à elaboração de projetos de pesquisa, desenvolvimento e inovação são fatores importantes. Na realidade, o processo de implementação de um programa de qualidade pode ser entendido como mais uma etapa do ciclo de vida das empresas. Como as IOGEs, normalmente são agentes SOFTEX que poderão ter participado desse ciclo com programas de apoio a pré-incubação e incubação, cria-se um clima de credibilidade e de parceria fundamental para a execução dos trabalhos. Algumas empresas que adotaram o modelo MPS, são originadas das células de incubação da própria IOGE, aproveitando elos cultivados desde a sua gênese. Outras empresas usufruíram de ações empreendidas pelo agente/IOGE, através de projetos de financiamentos, capturados em fontes diversas de fomento, o que estreita também os laços reforçados pela credibilidade anterior. Para as empresas que não tiveram essa origem, o projeto deverá ter um foco mercadológico. 4.3. Definir apoios e ações sensibilizadoras A formação de grupos iniciais de empresas deverá ter contorno de mercadologia e marketing, parecidos com o lançamento de um novo produto no mercado. A ciência do marketing conhece bem os conceitos de mercados, onde as empresas são definidas como “early” ou “later adopter”. Algumas empresas têm o estilo denominado “early adopter”, centradas numa postura mais flexível e imediata para a adoção de propostas inéditas, apostando em conceitos inovadores, sempre dosando ousadia com visão de futuro. Outras empresas, por outro lado (“later adopter”), somente aderem a propostas inéditas após uma intensa observação de resultados e um convencimento moldado por números positivos obtidos pelos seus pares no mercado. Algumas regiões, estados e conseqüentemente mercados podem ter essas particularidades. Uma IOGE, como agente que pretende introduzir um conceito inovador como o MPS.BR, deve se aperceber dessas nuances e definir estratégias que procurem “vender bem” o valor da proposta nova, sua relação custo-benefício e a comparação com propostas semelhantes (CMMI,CMM). Esse trabalho, espécie de “marketing pelas beiradas”, é fator crítico em culturas onde o ceticismo somente é vencido por ações que fundem a
- 26. 25 credibilidade da instituição organizadora de grupos de empresas, conforme item anterior, com evidências de ganhos palpáveis e de riscos conhecidos. O estado de Minas Gerais, por exemplo, onde atua a IOGE Fumsoft, é muito conhecido pela indústria do marketing por essas nuances. As empresas que pretendem vender aqui algum produto em fase de lançamento, adotam abordagens e estratégias diferentes das usuais, justamente pela maior incidência de consumidores “later adopter”. A atenuação desses fatores de resistência pode ser materializada por ações como: • Divulgação do modelo MPS e dos seus casos de sucesso através de palestras, apresentações, distribuição de material de divulgação, promoção de cursos relacionados às áreas de foco do MPS.BR; • Criação de um fluxo constante de informações abastecendo os setores ressonantes do mercado (como jornais, revistas, televisões) a respeito do andamento, alcance, números dos projetos, etc; • Criação e participação em eventos locais da área de informática, com palestras de usuários e depoimentos de sucesso de empresas que vivenciaram os resultados de melhoria na adoção de um programa como MPS.BR, CMMI, etc; • Criação de treinamentos complementares (não oficiais) em áreas do modelo, com foco em ferramentas e experiências de empresas; • Participação em grupos de discussão especializados em áreas correlatas, como CMMI, XP, Modelagem Ágil, com o objetivo de mostrar as convergências dos modelos aparentemente antagônicos e discutir e dissipar mitos de inflexibilidade e de burocratização de modelos mais estruturados e formais; • Atuação integrada em movimentos que congregam entidades da área de informática, como Assespro, Sucesu e Sindicato de empresas de informática, procurando estabelecer uma química de afinidade entre elas, no sentido de conscientizar as suas empresas afiliadas, sobre as vantagens da qualidade, como movimento estratégico do setor. A criação da área de Disseminação Nacional na Equipe Técnica do Modelo MPS (ETM) tem sido fator preponderante como elemento de sensibilização na adoção do MPS.BR, agindo proativamente em mercados onde o programa não se faz presente e os resultados de sucessos de outras regiões não são plenamente conhecidos. Atualmente algumas empresas já procuram espontaneamente apoio para o desenvolvimento de trabalhos de implementação e avaliação MPS. Entretanto, o apoio financeiro é ainda ponto chave de decisão das empresas para a adesão a esses projetos. Apesar de algumas médias e grandes empresas empreenderem essa iniciativa de forma independente, no modelo específico, acordos da SOFTEX com entidades para obter aportes para os grupos de empresas
- 27. 26 são, mais que um grande incentivo, fundamentais para tornar o projeto viável para as micro e pequenas empresas. Trazer outros agentes, como SEBRAE, fundações de amparo à pesquisa, secretarias estaduais, atuando como fontes de aporte de recursos, significa não apenas uma facilidade financeira, mas constitui fator de garantia e credibilidade. Também a ampliação do apoio SOFTEX para além dos níveis de maturidade G e F já tem sido uma demanda do mercado. 4.4.Oferecer e exigir garantias contratuais de forma clara e transparente Esse fator se refere à necessidade de uma espessa demonstração de transparência nos relacionamentos da IOGE com as empresas. Significa definir regras amplamente divulgadas e formalizadas por meio de contratos dando clareza aos compromissos formais entre as partes envolvidas. Para tal se faz necessário um amplo respaldo jurídico das partes, no que concerne ao instrumento legal que regulamenta os acordos. Esse aspecto pode ser materializado através de reuniões de esclarecimentos sobre pontos polêmicos, como ruptura de contrato, aplicação de multas e caracterização de atrasos no cronograma. 4.5.Demonstrar parcerias Um aspecto importante na sedimentação da credibilidade do projeto é o agente demonstrar que mais do que um elo de intermediação entre duas partes (empresas clientes do projeto e SOFTEX), ele é um parceiro. A parceria transcende os aspectos formais e contratuais definidos pelo modelo de negócios e deságua numa cumplicidade positiva pela busca dos mesmos objetivos como a melhoria dos processos e o alcance da avaliação bem sucedida. Isso se materializa pela proximidade dos gestores da IOGE com as empresas clientes do projeto, dando assistência contínua, gerenciando a qualidade dos trabalhos de implementação e apoiando as empresas na fase da avaliação MPS. Um canal efetivamente aberto e constante de comunicação, com as empresas e com a SOFTEX prova ser importante ferramenta de gestão e de integração entre todos os participantes do projeto. Um outro tipo de parceria que precisa ser estimulado é entre as próprias empresas – afinal, ao comporem um grupo estão viabilizando mutuamente seus projetos de implementação e avaliação MPS e já por isso são “parceiras”. Algumas IOGEs incentivam reuniões formais do grupo (workshops), onde as empresas participantes apresentam seus trabalhos de implementação, comentam seus obstáculos, normalmente comuns, e explicam seus processos e ferramentas. É importante deixar claro desde o início para as empresas que a troca de determinadas informações durante o projeto não se constitui em risco ao seu mercado e estratégias, mesmo considerando empresas que atuam num mesmo segmento. Antes, é o compartilhamento de experiências que faz com que as dificuldades e dúvidas sejam mais facilmente superadas, uma vez que estão vivenciando o mesmo momento de implantar o modelo MPS em domínios semelhantes de problema.
- 28. 27 A troca de experiência entre as diversas esferas é um acelerador de desenvolvimento para todos – IOGEs, consultores e empresas. Para que isso aconteça devem ser criadas oportunidades, tanto estruturadas para os grupos como um todo, quanto atendendo a demandas específicas. Assim, por exemplo, no caso de alguma empresa desejar conhecer a experiência de outra, podem ser intermediadas visitas entre empresas por meio da solicitação de alguém de confiança mútua (como o líder do programa MPS.BR) ou programados workshops com todo o grupo. Também a cooperação entre IOGEs, IIs e IAs permite que trabalhos complementares sejam realizados, como auditorias e revisões intermediárias, que garantem a objetividade e a isenção dos resultados agregando à credibilidade do programa MPS.BR como um todo. Também com relação aos implementadores é importante que sejam considerados parceiros das empresas. Algumas IOGEs/IIs possuem em sua equipe de implementadores, elementos oriundos da academia e também do mercado. Especialmente nesta situação, onde implementadores fazem parte de empresas que atuam em desenvolvimento de software, é importante que se certifique que a empresa cliente e a implementadora não concorram na mesma faixa do mercado. Para evitar isso, é necessário que seja analisado, anteriormente à alocação, o perfil de cada um dos implementadores e o nicho das empresas onde atuarão, neutralizando-se, dessa forma, possíveis zonas de desconforto, ao longo do projeto de implementação. 4.6.Envolvimento de empresas públicas Empresas públicas locais, principalmente as de processamento de dados, constituem uma forte caixa de ressonância para o programa MPS.BR. Isso porque são, além de produtoras, também grandes consumidoras de software e serviços correlatos. A incorporação dessas empresas no rol das que adotam o MPS.BR é emblemático no sentido de demonstrar ao mercado a força da qualidade. Se uma empresa que é uma grande compradora de software do mercado adota um modelo de qualidade, como o modelo MPS, sugere também, seja apenas pelo exemplo ou pela explicitação de critério de pontuação em editais, que as suas potenciais vendedoras ou prestadoras de serviço devam seguir o mesmo caminho. 4.7.Integração Mercado-Academia Em diversos momentos, na trilha pela busca da qualidade, é importante que a visão mercadológica e acadêmica sejam confluentes. Para a implementação, é muito benéfico ter um grupo de consultores que conheçam os dois aspectos. Para a empresa é enriquecedor ter acesso aos aspectos teóricos. A combinação de embasamento acadêmico e vivência empresarial permite uma troca de experiências que confere a todo o grupo riqueza, abrangência de pontos de vistas e maturidade. Alguns relatos mostram que esse contágio mútuo entre as influências acadêmica e empresarial se mostra
- 29. 28 como um excelente fator de equilíbrio nas equipes que bem conduzem seus trabalhos de implementação. Com esse propósito, a IOGE deve buscar formar parcerias com universidades, visando à divulgação dos novos conceitos associados, integrando o modelo MPS nas grades curriculares das disciplinas de Engenharia de Software e de Análise e Projeto de Sistemas. Além disso, o incentivo a trabalhos acadêmicos, a monografias de final de licenciatura, a realização de palestras em eventos acadêmicos e a distribuição de material promocional do modelo ajudam o processo de semeadura do modelo MPS na comunidade acadêmica e daí para o mercado. 4.8.Formação dos implementadores Um outro ponto importante relatado pelas IOGEs se refere à formação dos implementadores. Alguns relatos apontam que apenas a formação obrigatória para implementadores, com cursos C1 e C2 e provas P1 e P2, pode não ser suficiente para uma perfeita orientação do modelo. Algumas alternativas observadas é a formação de uma dupla de implementadores, ambos com a formação mínima necessária, porém tendo um deles (implementador líder) maior experiência prática e de consultoria, ficando o outro como um adjunto, que poderá se tornar líder, num ciclo de implementação subseqüente. 5. Conclusão Tendo em vista a importância da atuação das IOGEs no sucesso dos projetos de implementação e avaliação MPS, este artigo apresentou as lições aprendidas no planejamento e execução de projetos realizados através do Modelo de Negócios Cooperado, do programa MPS.BR, desde a criação dos primeiros grupos de empresas. Foram relatadas, na forma de lições aprendidas, as diferentes visões de IOGEs, com suas principais atividades desenvolvidas, dificuldades enfrentadas e soluções adotadas. Essas informações poderão e deverão servir de balizamento para as futuras IOGEs a serem criadas, ou mesmo para as atuais, como forma de lapidação de seus processos atuais ensejando melhorias futuras. Alguns dos resultados apresentados neste artigo são a síntese das diversas experiências vivenciadas pelas IOGEs e apresentadas no II Workshop de IOGEs MPS.BR, em novembro de 2007, em Belo Horizonte-MG e outras reportadas nos relatórios periódicos que as IOGEs enviam à SOFTEX. O Modelo de Negócios Cooperado, definido pela SOFTEX para a implementação de grupos de empresa, sugere a força da sinergia entre as empresas interessadas, as IIs e seus consultores, as IAs e seus avaliadores e a IOGE e sua coordenação. Entre os principais resultados alcançados, podemos agrupá-los por domínios: a) Planejamento das atividades: envolve uma cuidadosa ação de planejamento dos trabalhos na sua fase inicial, focando no processo de seleção das empresas. Nesse contexto, deve-se
- 30. 29 procurar homogeneidade, no que tange a tamanho, objetivos e grau de maturidade e não desconsiderar especificidades de algumas delas. Na fase de acompanhamento do projeto, deve-se atentar para a observação direta dos trabalhos, os resultados intermediários obtidos, além do suporte dado pelos patrocinadores, principalmente os que praticam o apoio retórico. b) Relacionamento entre IOGE, II, IA e empresas: o processo de comunicação entre os quatro atores principais envolvidos, onde a clareza de objetivos e transparência de ações devem balizar as interlocuções, é um ponto estratégico de atenção. A história pregressa do agente SOFTEX, no papel de IOGE, é de fundamental importância no equilíbrio dessas relações, devido aos aspectos de credibilidade. Os aspectos contratuais devem merecer cuidado especial neste item em particular. c) Recursos humanos envolvidos: como em qualquer projeto, o “peopleware” envolvido é fator crítico de sucesso. Isso passa pela proatividade da coordenação da IOGE em observar atentamente os resultados obtidos confrontados com a satisfação das empresas, a adequada formação das equipes de implementadores, com cuidados de formação suplementar contínua além dos treinamentos básicos oficiais e a alocação estudada dos consultores nas respectivas empresas em função de características, compatibilidades e afinidades. A coordenação da IOGE deve ser um contínuo facilitador dos trabalhos, estando atenta às dificuldades encontradas por qualquer das partes, atuando prontamente na remoção dos obstáculos e no estímulo de todos os envolvidos. Referências Barbieri, C.V., Mendonça, R.M.L.O., Faria, A. L., Torres, M., “Experiências do CCOMP.MG/ FUMSOFT na Organização de Grupos de Implementação MPS.BR”, In: ProQualiti – Qualidade na Produção de Software, v. 3, nro. 2, pp. 45 – 48, Nov/2007. Barbosa, V. C., Cunha, K.R.,(2007) “Projeto Rota do MPS.BR 2006”, In: ProQualiti – Qualidade na Produção de Software, v. 3, nro. 2, pp. 71 – 73, Nov/2007. Becker, C. A., Galarraga, O., Prikladnicki, R., (2007) “Cooperativa MPS.BR – Relato de experiências, lições aprendidas, melhores práticas e dificuldades da II e IOGE SOFTSUL do RS”, In: ProQualiti – Qualidade na Produção de Software, v. 3, nro. 2, pp. 39 – 44, Nov/2007. Cardoso, M “Comunicação Sobre as Operações e Experiências da IOGE MPS.BR ACATE- SOFTPOLIS”, In: ProQualiti – Qualidade na Produção de Software, v. 3, nro. 2, pp. 37 – 38, Nov/2007. Junior, E. P., (2007) “IOGE MPS.BR SOFTEX Campinas – “Lições aprendidas”, In: ProQualiti – Qualidade na Produção de Software, v. 3, nro. 2, pp. 55 – 58, Nov/2007. Lima, G. N., Gomes, M.A.,(2007) “Fatores críticos de sucesso em programas de melhoria de processo de forma cooperada”, In: ProQualiti – Qualidade na Produção de Software, v. 3, nro. 2, pp. 49 – 54, Nov/2007.
- 31. 30 Paret, B.D, Amaral, M. P. “Lições Aprendidas em Cinco Anos de Apoio a Grupos para a Implantação de Processos de Software” In: ProQualiti – Qualidade na Produção de Software, v. 3, nro. 2, 59 – 61, Nov/2007. Rocha, C.A.S., Câmara, S.F. “Projeto MPS-BR INSOFT – CEARÁ” In: ProQualiti – Qualidade na Produção de Software, v. 3, nro. 2, pp. 67 – 68, Nov/2007. Véras, P.S. “ Projeto MPS.BR – TECSoft” In: ProQualiti – Qualidade na Produção de Software, v. 3, nro. 2, pp. 69 – 70, Nov/2007. Weber, K. C., Montoni, M. et al “MPS.BR - Melhoria de Processo do Software Brasileiro: resultados alcançados e lições aprendidas (2004-2008)” XXXIV Conferencia Latinoamericana de Informática - 8 a 12 de Setembro de 2008, Santa Fe, Argentina. Yoshida, D. Kohan, S. “Organização de Grupo de Empresas com duas Instituições Implementadoras MPS.BR: Convênio Com Qualidade” In: ProQualiti – Qualidade na Produção de Software, v. 3, nro. 2, pp. 63 – 66, Nov/2007. “Comunicado SOFTEX MPS.BR 14/2007 - Apoio a Grupos de Empresas para Implementação e Avaliação MPS – Níveis G e F”. Disponível em: http://www.softex.br/mpsbr/_comunicados/. Acesso em: 29 de agosto de 2008. “Modelo de Negócio para Melhoria de Processo de Software (MN-MPS): resumo executivo”. Disponível em: http://www.softex.br/mpsbr/_outros/MN-MPS.pdf. Acesso em: 29 de agosto de 2008. “MPS.BR - Melhoria de Processo do Software Brasileiro - Guia Geral (Versão 1.2)”. Disponível em: http://www.softex.br/mpsbr/_guias/default.asp. Acesso em: 29 de agosto de 2008.
- 32. Lições Aprendidas com Implementação do Modelo MPS em Empresas Mariano Angel Montoni COPPE/UFRJ – Universidade Federal do Rio de Janeiro Caixa Postal 68511 – CEP 21945-970 – Rio de Janeiro-RJ, Brasil [email protected] Resumo. Este trabalho descreve as lições aprendidas pelas instituições implementadoras do MPS.BR e de empresas que implementaram o modelo MPS no período de 2005-2008. Espera-se que essas lições possam contribuir no aumento da eficácia das estratégias de implementação existentes, bem como, no aumento das chances de sucesso das iniciativas de melhoria baseadas no modelo MPS. 1. Introdução A implementação de melhoria de processos de software é uma atividade complexa e intensa em conhecimento [Zaharan, 1998]. Diversas barreiras críticas existem e devem ser superadas para aumentar as chances de sucesso de iniciativas de melhoria, por exemplo, a falta de comprometimento da alta gerência e a falta de recursos financeiros [Niazi et al., 2006]. Essas barreiras têm sido um dos principais fatores pelos quais as organizações evitam implementar melhoria de processo de software com base em modelos e padrões [Staples et al., 2007]. Portanto, a garantia do sucesso do modelo MPS depende, fundamentalmente, da capacidade das organizações de desenvolvimento de software superarem essas barreiras, por exemplo, através da retenção e reutilização de conhecimento sobre implementação de melhorias em processo de software. Neste contexto, é de grande importância a aquisição de conhecimento sobre potenciais problemas que podem ocorrer ao longo da execução de iniciativas de melhoria para maximizar as chances de sucesso [Montoni et al., 2008]. Por exemplo, o acúmulo de conhecimento sobre lições aprendidas na condução de iniciativas de melhoria pode ser bastante útil como mecanismo de preservação do conhecimento organizacional, além de fornecer a base para promover a disseminação do conhecimento necessário para evitar, em novas iniciativas, a ocorrência de problemas detectados em iniciativas anteriores. Além disso, o acúmulo de conhecimento sobre lições aprendidas com a implementação de melhorias baseadas no modelo MPS, pode servir como rica fonte de informação sobre questões relacionadas à adoção do modelo MPS que podem ser úteis no aprimoramento do modelo para torná-lo mais adequado às características peculiares do setor de software brasileiro. Este artigo tem como objetivo descrever as principais lições aprendidas na implementação de melhoria de processo de software com base no modelo MPS. Essas lições foram aprendidas a partir da experiência das Instituições Implementadoras (IIs) e das empresas que implementaram o modelo MPS. A seção 2 apresenta os modelos básicos de implementação do MPS, bem como os conceitos de II e os requisitos necessários para credenciamento de uma II. A seção 3 apresenta as principais lições 31
- 33. aprendidas na implementação de melhorias de processo baseada no modelo MPS. Finalmente, a seção 4 apresenta as conclusões deste trabalho. 2. Implementação do MPS.BR e Instituições Implementadoras O modelo MPS foi desenvolvido com foco nas pequenas e médias empresas que possuem diversas restrições técnicas e financeiras. No entanto, o modelo também é completamente adequado para grandes organizações que possuem recursos suficientes para investir em melhoria de processo de software [SOFTEX, 2007]. Para atender à diversidade de características, necessidades e restrições das organizações brasileiras de desenvolvimento de software, foi desenvolvido e integrado ao modelo MPS um componente chamado de MN-MPS que abrange os modelos de negócio para implementação do programa MPS.BR. O MN-MPS compreende dois tipos de modelos de implementação de melhoria de processo de software de acordo com as necessidades específicas das organizações e a disponibilidade de recursos: • Um Modelo Específico de Negócio adequado para grandes organizações que não desejam compartilhar serviços de melhoria de processo de software baseados no modelo MPS com outras organizações. • Um Modelo Cooperado de Negócio para grupos de pequenas e médias empresas interessadas em implementar e avaliar o modelo MPS e compartilhar serviços e custos de melhoria de processo de software O Modelo Cooperado de Negócio é especialmente atraente para pequenas e médias empresas, pois a implementação baseada nesse modelo é factível de obter recursos externos para apoiar atividades de implementação e avaliação de melhoria de processo de software. No entanto, as organizações que integram este modelo devem estar sujeitas a algumas restrições. Por exemplo, marcos de implementação e de avaliação são estabelecidos no contexto do grupo cooperado de empresas e o apoio financeiro para a implementação do modelo MPS somente é obtido caso a organização que integra o grupo alcance com sucesso cada um desses marcos. Além disso, é requisito que a implementação seja coordenada por uma Instituição Implementadora (II) e, também, que o grupo cooperado de empresas seja coordenado por uma Instituição Organizadora de Grupos de Empresas (IOGE), ambas credenciadas pela SOFTEX. Uma II é uma organização autorizada para conduzir uma implementação do MPS.BR composta de consultores em implementação de melhoria de processo de software baseada no modelo MPS. O conceito de II do MPS.BR é um diferencial desse modelo para outros modelos de melhoria de processo de software existentes, o que torna o modelo MPS único na sua definição. O estabelecimento de IIs e a formação de consultores de implementação de melhoria baseada no modelo MPS ajudam a estabelecer uma comunidade de prática com interesses comuns de troca e compartilhamento de informações com o objetivo de facilitar a adoção do modelo MPS e reduzir a influência de barreiras críticas que podem afetar o sucesso de iniciativas de melhoria baseadas no modelo MPS. Os workshops anuais de implementadores e de empresas que implementaram o modelo MPS são eventos que estimulam a troca de conhecimento entre membros da comunidade de prática do MPS.BR. 32
- 34. A autorização de uma II é realizada através de um convênio com a SOFTEX. O Fórum de Credenciamento e Controle (FCC) do modelo MPS é responsável por fornecer um parecer da aprovação do credenciamento da II. Essa aprovação é realizada mediante o atendimento dos seguintes requisitos institucionais pelas instituições proponentes [SOFTEX, 2007]: • Demonstrar experiência da instituição na área de processos de software. • Possuir uma estratégia de implementação do Modelo de Referência MR-MPS. • Possuir uma estratégia de seleção, capacitação e manutenção da competência dos membros da equipe de Implementação do MPS.BR. • Ter a ela vinculados, no mínimo, 3 (três) profissionais que cumpram os seguintes requisitos, sendo que um deve ser o coordenador da equipe: (i) aprovação na prova de Introdução (P1-MPS.BR); (ii) aprovação na prova para implementadores (P2-MPS.BR); (iii) graduação completa; (iv) experiência em desenvolvimento de software e implantação de processos de software. Caso o Fórum de Credenciamento e Controle (FCC) forneça um parecer favorável após análise da documentação fornecida pela instituição proponente, é assinado um Termo de Convênio entre a SOFTEX e a II para seu credenciamento. O período de duração do credenciamento de uma II é de 2 anos. Ao longo deste período, a II deve enviar, semestralmente, para a SOFTEX, um relatório de atividades realizadas no período de referência. Geralmente, esses relatórios contêm informações sobre os trabalhos de implementação do modelo MPS realizados no período, bem como atividades para formação de implementadores e os resultados alcançados, por exemplo, a realização com sucesso de uma avaliação oficial MPS em empresas que implementaram o modelo sob coordenação da respectiva II, entre outras informações. Atualmente, existem 18 IIs credenciadas [SOFTEX, 2008]. A distribuição da localização das IIs conforme as regiões do Brasil é apresentada na tabela 1. Tabela 1 – Distribuição da Localização das IIs conforme as regiões do Brasil Região Número de IIs Credenciadas Centro-oeste 3 Norte 0 Nordeste 1 Sudeste 10 Sul 4 Os relatórios de atividades das IIs também contêm informações sobre as lições aprendidas por cada II na implementação do modelo MPS. Essas lições compreendem um rico conhecimento sobre potenciais problemas que podem ocorrer ao longo da condução de iniciativas de melhoria, além de conhecimento sobre os procedimentos adequados para tratar esses problemas maximizando as chances de alcançar sucesso na condução de iniciativas de melhoria de processo de software com base no modelo MPS. Além de estarem descritas nos relatórios de atividades das IIs, as lições aprendidas com implementação do modelo MPS em empresas também são divulgadas na forma de comunicados nos workshops anuais de implementadores e de empresas que implementaram o modelo MPS. 33
- 35. 3. Lições Aprendidas Cada organização implementa melhoria de processo de software baseada no modelo MPS seguindo estratégias específicas de implementação. Essas estratégias são adaptadas para cada organização segundo suas características, necessidades e restrições. Portanto, pode-se assumir que, no contexto de uma iniciativa de melhoria, é importante tratar adequadamente as diversas questões que podem afetar o sucesso das iniciativas de melhoria, tanto de forma positiva, quanto de forma negativa. No entanto, pode-se observar nos relatos de lições aprendidas das IIs e das empresas que implementaram o modelo MPS que existe uma certa homogeneidade nos tipos de questões que devem ser tratadas ao longo da execução das iniciativas de melhoria [Zabeu, 2007a], [Zabeu, 2007b], [Salviano, 2006], [Salviano, 2008], [Sória, 2007], [Sória, 2008a], [Sória, 2008b], [Rocha, 2006], [Souza, 2006], [Souza, 2007a], [Souza, 2007b], [Souza, 2008], [Palestino, 2006], [Palestino, 2007a], [Palestino, 2007b], [Palestino, 2007c], [Palestino, 2008], [Yoshida, 2007a], [Yoshida, 2007b], [Becker, 2006a], [Becker, 2006b], [Becker, 2007], [Rouiller, 2005], [Rouiller, 2007], [Oliveira, 2006a], [Oliveira, 2006b], [Oliveira, 2007a], [Oliveira, 2007b], [Salgado, 2008], [Rocha et al., 2005], [Mendes et al., 2007], [Tsukumo et al., 2006], [Yoshida et al., 2007], [Santos et al., 2007], [Thiry et al., 2007], [Mega et al., 2007], [Ribeiro, 2007], [Monteiro et al., 2007], [Scheid et al., 2007], [Borssatto, 2007], [Vargas et al., 2007] e [Souza e Pinto, 2007]. Portanto, é fundamental garantir a preservação do conhecimento relacionado a essas questões, bem como o conhecimento sobre os procedimentos adequados para tratar essas questões no contexto de iniciativas de melhoria baseadas no modelo MPS. Essas questões foram documentadas na forma de lições aprendidas e são descritas a seguir. 3.1. Lição 1: Tratar a implementação de melhoria de processo de software como um projeto Diversas IIs e empresas que implementaram o modelo MPS reconhecem a importância de gerenciar as iniciativas de melhoria como um projeto. A ISO/IEC 15504-4 define que um programa de melhoria de processo deve ser implementado como um projeto propriamente dito, com patrocinadores definidos, gerência de projeto, orçamento, metas e acompanhamento financeiro [ISO/IEC 15504-4, 2004]. Para tanto, deve haver um planejamento adequado das iniciativas de melhoria de uma organização. Um plano de melhoria deve conter informações sobre a situação atual das atividades de melhoria de processo, o escopo da organização (os limites organizacionais para o programa de melhoria), o escopo do processo (os processos a serem melhorados), o ciclo de vida da melhoria de processo, papéis principais e responsabilidades, recursos, riscos associados com o programa de melhoria entre outras [ISO/IEC 15504-4, 2004]. No contexto desta lição aprendida, também é importante reconhecer a necessidade de monitorar e acompanhar as iniciativas de melhoria com base no planejamento do projeto de melhoria. Portanto, metas e pontos de revisão, bem como mecanismos de relato da situação do programa de melhoria devem ser definidos e estabelecidos adequadamente. 34
- 36. O planejamento adequado de iniciativas de melhoria é ainda mais necessário quando a implementação de melhoria de processos segue o Modelo Cooperado de Negócio. Algumas IIs perceberam que a antecipação na coordenação das ações de implementação de melhoria aumenta a chance de sucesso na formação de um grupo. Um aspecto relevante de ser considerado no planejamento de uma iniciativa de melhoria é a necessidade de realizar uma análise criteriosa da situação atual da empresa que esteja iniciando a implementação de processos do MR-MPS. Algumas IIs constataram que as empresas, normalmente, têm uma percepção muito mais otimista do que realista quanto ao nível de maturidade em que se encontram. Portanto, atividades de gap analysis podem ser úteis para obter um dimensionamento correto do trabalho a ser realizado e, conseqüentemente, aumentar a precisão das estimativas de esforço e custo das iniciativas de melhoria. 3.2. Lição 2: Manter o foco da implementação de melhoria de processo de software O foco de um programa de melhoria de processos deve estar vinculado aos objetivos de negócio da organização [Santos et al., 2007]. Para tanto, é fundamental garantir que os objetivos de melhoria a serem alcançados são derivados dos objetivos de negócio organizacionais. A mudança constante de foco da implementação ou a falta de gerência dessas mudanças podem prejudicar a visibilidade dos benefícios reais alcançados com o investimento realizado na implementação das melhorias nos processos de uma organização. Um mecanismo identificado por algumas IIs e empresas que implementaram o modelo MPS para tratar este problema é a realização de reuniões periódicas de acompanhamento com o patrocinador e os responsáveis pela equipe interna para que haja um entendimento da situação das atividades de implementação e sejam tomadas ações corretivas necessárias para que os envolvidos na iniciativa de melhoria mantenham o foco desejado na implementação. 3.3. Lição 3: Estabelecer liderança da implementação de melhoria de processo de software Muitas barreiras são encontradas durante as iniciativas de melhoria, como por exemplo, políticas organizacionais, falta de apoio e de recursos, falta de conhecimento e pressões de cronograma. A capacidade de motivar, sensibilizar e orientar os membros da organização na realização de ações é fundamental para superar essas e outras dificuldades. Também é reconhecida a importância do patrocinador do programa de melhoria na implementação das melhorias, pois muitas vezes, sua intervenção é necessária para tratar resistências a mudanças. Além disso, o patrocinador tem o poder de atribuir autoridade e tempo aos responsáveis pela implementação das melhorias de forma que haja autonomia nas decisões visando reduzir a morosidade na análise de alternativas de implementação e na implantação das alternativas selecionadas. 35
- 37. 3.4. Lição 4: Obter e manter o comprometimento para a implementação de melhoria de processo de software Um fator que tem influência no sucesso das iniciativas de melhoria está relacionado ao comprometimento da organização desde os níveis mais baixos até os níveis mais altos da hierarquia organizacional. No entanto, foi observado que a obtenção e manutenção do comprometimento dos membros de uma organização de software não é uma tarefa trivial. Para tratar esse problema é preciso garantir que as pessoas envolvidas nas iniciativas de melhoria percebem os benefícios derivados da implementação, e não apenas o esforço e custos associados. Isto poder ser alcançado, por exemplo, através da comunicação contínua para a alta gerência de dados quantitativos de tempo, custo, qualidade e satisfação do cliente relacionados à iniciativa de melhoria. A atribuição explícita do papel e das responsabilidades de cada um dos envolvidos na iniciativa de melhoria também é muito importante. A definição de um macro-processo no início do programa de melhoria relacionando todas as ações de melhoria, bem como as responsabilidades e dependências entre elas é um mecanismo eficiente para aumentar a visibilidade das atribuições de cada pessoa envolvida na iniciativa de melhoria, pois permite uma melhor compreensão das responsabilidades individuais, bem como a falta de comprometimento pode afetar o programa de melhoria como um todo. 3.5. Lição 5: Garantir efetividade dos processos de software Uma boa visibilidade dos resultados obtidos com a melhoria dos processos de software é essencial para garantir que as melhorias estão tornando os processos mais efetivos. Um processo disciplinado de software deve ajudar os projetos a alcançar suas metas de qualidade, custo e cronograma. Uma infra-estrutura de processo deve ser projetada com esse objetivo principal em mente, que é ajudar projetos a alcançar (e talvez exceder) os objetivos estabelecidos. Portanto, uma forma eficiente para justificar o investimento na melhoria dos processos de software é estabelecer uma relação direta entre um ambiente de processo efetivo e a qualidade melhorada dos produtos e serviços resultantes [Zaharan, 1998]. Neste contexto, foi observado que as iniciativas de melhoria devem ser monitoradas através de indicadores de desempenho capazes de evidenciar a manutenção e/ou melhora do desempenho dos processos. A monitoração dos processos e os mecanismos de relato da situação dos processos com base nesses indicadores também são úteis para apoiar a avaliação do retorno no investimento em melhoria de processos. Indicadores de desempenho associados às iniciativas de melhoria incluem, por exemplo, medidas de qualidade do produto, qualidade do processo, previsibilidade do projeto e satisfação do cliente. No entanto, alguns dos maiores retornos da melhoria dos processos de software são expressos em termos humanos e não em unidades monetárias, por exemplo, satisfação no trabalho, orgulho do trabalho realizado, aumento da capacidade de atrair e reter especialistas capazes de introduzir práticas inovadoras na organização, entre outros [Krasner, 2001]. 36
- 38. 3.6. Lição 6: Estabelecer e manter uma infra-estrutura adequada para implementação de melhoria de processo de software Os relatos de lições aprendidas com implementação do modelo MPS em empresas apontam que a maior parte das organizações de baixa maturidade não possui uma infra- estrutura adequada para os processos de software. A infra-estrutura de processo de software abrange os seguintes dois aspectos que devem ser cobertos completamente para obter um ambiente para melhoria de processo de software efetivo [Zaharan, 1998]: • Infra-estrutura organizacional e gerencial: inclui os papéis e responsabilidades que devem ser estabelecidas para patrocinar, gerenciar, realizar e monitorar atividades de melhoria de processo de software. • Infra-estrutura tecnológica e ferramental: incorpora as facilidades e ferramentas necessárias para automatizar atividades de processo e apoiar os diversos papéis e responsabilidades de melhoria de processo. A dificuldade em adquirir e implantar ferramentas de software adequadas às necessidades e restrições da organização é um fator que tem impacto direto na infra- estrutura de processos. Uma análise das funcionalidades das ferramentas existentes no mercado com base em critérios objetivos, por exemplo, capacidade de integração entre ferramentas e capacidade de adaptação das ferramentas, é bastante útil para apoiar a seleção de uma infra-estrutura ferramental adequada para a realidade dos projetos e da organização. A definição desde o início da implementação de ferramentas de apoio aos processos também ajuda a minimizar o retrabalho na definição dos procedimentos da empresa e a diminuir a resistência à mudanças na forma atual de trabalho. A falta de recursos humanos para assumir papéis e responsabilidades também tem impacto na infra-estrutura de processos. Para resolver este problema, diversas organizações têm contratado serviços de consultores das IIs para assumir responsabilidades na execução de alguns processos de apoio, por exemplo, atividades de análise de métricas e avaliação de qualidade de processos e produtos. Dessa forma, essas organizações mantêm o foco no negócio evitando alocar seus membros em atividades não fundamentais no desenvolvimento do software. A excessiva concentração das atividades no grupo de processos também pode prejudicar o andamento de uma iniciativa de melhoria, principalmente em empresas de pequeno e médio porte. Para tratar esta questão, é recomendada a criação de grupos de trabalho para processos específicos compostos de membros selecionados de acordo com a especialidade necessária para definir as atividades dos processos. O estabelecimento de prazos maiores para a definição e implementação dos processos ajuda a evitar a ocorrência de atrasos e a aumentar as chances de atender as expectativas das partes interessadas na iniciativa de melhoria. 37
- 39. 3.7. Lição 7: Implementar estratégias adequadas de capacitação dos envolvidos na implementação de melhoria de processo de software A transferência de conhecimento sobre métodos e técnicas de engenharia de software é uma atividade comum na implementação de melhorias em processos de software. No entanto, essa prática tem um impacto direto tanto no tempo, quanto no custo das iniciativas de melhoria. A transferência de conhecimento também tem impacto nos projetos de software, pois deixa-se de lado a execução das atividades do projeto de software para ensinar conhecimento sobre os processos. Uma outra questão relevante é que a realização de treinamentos nos processos no início da implementação, geralmente, acarreta no risco dos participantes nos treinamentos não estarem mais envolvidos na implementação quando for necessário executar os processos definidos. Este fato é muito comum quando se implementa o MR-MPS em empresas segundo o Modelo Cooperado de Negócio, pois, normalmente, essas empresas são pequenas e possuem alta rotatividade de pessoal. Além disso, como a implementação é uma atividade gradual, há, também, o risco de alguns conhecimentos não serem mais “lembrados” na situação real de sua aplicação. Neste contexto, é importante estabelecer estratégias adequadas para capacitar os envolvidos nas iniciativas de melhoria. Estratégias de capacitação servem como catalisador na transferência de conhecimento e é um dos pilares de uma organização que aprende com suas próprias experiências. Por exemplo, a realização de mentoring é bastante eficaz na capacitação de envolvidos nos processos, pois permite a rápida transferência de conhecimento sem impactar significativamente no andamento dos projetos de software. O mentoring ajuda também a reforçar os benefícios do programa de melhoria e a manter o comprometimento dos envolvidos. No Modelo Cooperado de Negócio, as diferenças de conhecimento técnico e de nível de maturidade entre as organizações de um grupo cooperado aumentam a dificuldade das atividades de implementação. Isto ocorre, pois cada empresa tem barreiras críticas diferentes que podem afetar negativamente o sucesso da iniciativa de melhoria. Portanto, a implementação tende a ser mais individual para considerar as peculiaridades de cada empresa, o que acarreta na perda dos benefícios de compartilhamento de esforços, que é uma das vantagens do modelo cooperado de negócio do MPS.BR. Pra tratar esta questão, os grupos cooperados devem ser constituídos de empresas em estágios similares de maturidade. Isto facilita, também, a troca de experiências entre os membros das empresas que participam de um mesmo grupo cooperado. 38
- 40. 3.8. Lição 8: Disponibilizar recursos internos para a implementação da melhoria de processo de software As organizações de desenvolvimento de software devem estar conscientes da necessidade de disponibilizar recursos internos para o andamento das atividades de implementação, bem como dos custos e investimentos internos envolvidos. Caso não haja tal conscientização, a organização corre o risco de impactar o planejamento da iniciativa de melhoria em decorrência da baixa alocação de recursos humanos para o desenvolvimento dos processos e a constante alteração do tempo alocado para os mesmos. A realização de atividades de conscientização ajuda a reduzir o risco de falta de recursos internos para a iniciativa de melhoria. Essas atividades envolvem desde workshops de discussão de casos de sucesso na implementação de melhorias em processos de software até reuniões envolvendo membros de todos os níveis hierárquicos das organizações para apresentar a estratégia de implementação a ser adotada e esclarecer dúvidas relacionadas ao esforço e recursos necessários para operacionalizar a estratégia. Esta lição aprendida é essencialmente útil na adoção do Modelo Cooperado de Negócio. Nesse modelo, o trabalho cooperativo e articulado não é trivial, pois se gasta muito esforço e tempo na comunicação e na troca de informações. Portanto, as iniciativas de melhoria no modelo cooperado somente devem ser iniciadas após a aprovação formal de toda a documentação do grupo de empresas e dos recursos subsidiados. A dificuldade que muitas empresas enfrentam em ter projetos iniciando para começarem as atividades de implementação tem um impacto grande em uma iniciativa de melhoria, principalmente quando se adota o Modelo Cooperado de Negócio. As empresas de um grupo cooperado, geralmente, devem atingir metas específicas de implementação e avaliação. A demora em iniciar projetos pode acarretar, então, na não obtenção dos recursos subsidiados, além de multas. Portanto, uma empresa que deseja integrar um grupo cooperado deve saber, a priori, estas restrições e procurar implementar a melhoria dos processos em um maior número de projetos possível. 3.9. Lição 9: Estabelecer estratégias adequadas para a implementação de melhoria de processo de software O sucesso de uma iniciativa de melhoria depende da adequação da estratégia de implementação adotada. A diversidade das necessidades e restrições das organizações sugere que diferentes estratégias devem ser adotadas em diferentes contextos. A adoção de estratégias diversificadas que considerem alguns resultados dos processos de níveis mais altos de maturidade daquele almejado por uma organização demonstrou ser bastante eficaz em muitas implementações do modelo MPS. Por exemplo, o nível G do modelo MPS tem sido implementado em algumas organizações em conjunto com algumas práticas relacionadas aos processos Gerência de Configuração e Garantia da Qualidade do nível F e, também, algumas práticas relacionadas aos processos Definição do Processo Organizacional e Avaliação e Melhoria do Processo Organizacional do nível E. Este tipo de estratégia demonstrou ser eficiente para motivar as pessoas nas iniciativas de melhoria e para reduzir o impacto das mudanças introduzidas pela implementação de novos processos. 39
- 41. Um outro exemplo de uma estratégia de implementação considerada eficiente nas implementações em empresas baseadas no MPS.BR é a implementação de melhoria baseada em reutilização de ativos de processo, por exemplo, definições de processos, diretrizes e roteiros de documentos. O fornecimento de processos pré-definidos para apoiar a construção dos processos de uma organização facilita e agiliza as atividades de implementação de melhoria. No entanto, se a organização já possui seu processo definido, um tratamento especial deve ser dado para evitar a interrupção de trabalhos já realizados. É importante estabelecer estratégias específicas para implementar melhoria em grupos de empresas. Na implementação em grupo, existe um aumento da complexidade e do esforço no diagnóstico das empresas, pois como os implementadores estão envolvidos em muitas empresas, há uma necessidade maior de entender o contexto do negócio e separar as particularidades individuais de cada organização. Portanto, nesse caso, o rigor e a disciplina na execução das estratégias de implementação devem ser maiores. 3.10. Lição 10: Realizar avaliações informais da implementação da melhoria de processo de software O sucesso de uma iniciativa de melhoria baseada no modelo MPS pode ser medido pelo nível de alcance da implementação dos processos. A realização de avaliações informais segundo o método de avaliação MA-MPS, também chamadas de diagnósticos pré- avaliação, tem como objetivo apoiar a verificação de deficiências na implementação das melhorias. O tratamento adequado dessas deficiências garante um melhor atendimento aos requisitos do MR-MPS e aumenta as chances de sucesso de uma avaliação oficial MPS. Avaliações informais também servem para alinhar os conceitos de Engenharia de Software com as práticas relacionadas ao modelo MPS. É importante que as avaliações informais se aproximem ao máximo de uma avaliação oficial para que os envolvidos na implementação das melhorias percebam a complexidade e o nível de profundidade de uma avaliação de processos com base no MA-MPS. Além disso, o envolvimento, nas avaliações informais das pessoas de todos os níveis de atuação nos projetos ajuda a aumentar a profundidade da avaliação e a obter corroboração dos fatos e dados levantados. 4. Conclusão Este artigo apresentou as principais lições aprendidas na implementação do modelo MPS sob o ponto de vista das Instituições Implementadoras e das empresas que implementaram o modelo MPS. As lições aprendidas apresentadas abrangem diversos aspectos da implementação de melhoria de processo de software. Além disso, aspectos particulares dos modelos de negócio para a implementação do MPS.BR, quando pertinentes, também foram considerados na descrição das lições aprendidas. As lições aprendidas apresentadas são bastante genéricas para que possam ser adaptadas nos diversos contextos de iniciativas de melhoria. Espera-se que instituições implementadoras e empresas de software brasileiras utilizem essas lições para melhorar as suas estratégias de implementação e aumentar as chances de sucesso das suas iniciativas de melhoria com base no modelo MPS. 40
- 42. Referências [Becker, 2006a] Becker, C.A. Relatório Semestral da Instituição Implementadora Softsul, Março 2006. [Becker, 2006b] Becker, C.A. Relatório Semestral da Instituição Implementadora Softsul, Setembro 2006. [Becker, 2007] Becker, C.A. Relatório Semestral da Instituição Implementadora Softsul, Julho 2007. [Borssatto, 2007] Borssatto, I., 2007, “A Implementação do MPS.BR Nível F na Synos”, In: PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp. 105-110, Novembro. [ISO/IEC 15504-4, 2004] - International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 15504-4: Information Technology - Process Assessment – Part 4 - Guidance on use for Process Improvement and Process Capability Determination, Genebra: ISO, 2004. [Krasner, 2001] Krasner, H., 2001, "Accumulating the Body of Evidence for The Payoff of Software Process Improvement", Software Process Improvement, IEEE Computer Society Press. [Mega et al., 2007] Mega, B., Fonseca, K., Boessio, R., et al., 2007, “Melhoria de Processos de Software na Drive”, In: PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp. 82-86, Novembro. [Mendes et al., 2007] Mendes, F.F., Oliveira, J.L., Fernandes, P.G., Souza, A.S., 2007, “Análise de Riscos na Implantação de Melhorias de Processos de Software”, In: PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp. 25-32, Novembro. [Monteiro et al., 2007] Monteiro, R. W., Martins, C., Cabral., R., Rocha, A.R., 2007, “A Empresa de Processamento de Dados do Estado do Pará Rumo ao Nível F do MR- MPS”, In: PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp. 91-96, Novembro. [Montoni et al., 2008] Montoni, M.A., Cerdeiral, C., Zanetti, D., et al., 2008, "A Knowledge Management Approach to Support Software Process Improvement Implementation Initiatives". In: EuroSPI 2008, pp. 164-175, Dublin, Irlanda. [Niazi et al., 2006] Niazi, M., Wilson, D., Zowghi, D., 2006, "Critical success factors for software process improvement implementation: An empirical study", Software Process Improvement and Practice, v. 11, n. 2, pp. 193-211. [Oliveira, 2006a] Oliveira, K.M. Relatório Semestral da Instituição Implementadora UCB, Junho 2006. 41
- 43. [Oliveira, 2006b] Oliveira, K.M. Relatório Semestral da Instituição Implementadora UCB, Dezembro 2006. [Oliveira, 2007a] Oliveira, K.M. Relatório Semestral da Instituição Implementadora UCB, Junho 2007. [Oliveira, 2007b] Oliveira, K.M. Relatório Semestral da Instituição Implementadora UCB, Dezembro 2007. [Palestino, 2006] Palestino, C.V.B. Relatório Semestral da Instituição Implementadora FUMSOFT, Julho 2006. [Palestino, 2007a] Palestino, C.V.B. Relatório Semestral da Instituição Implementadora FUMSOFT, Abril 2007. [Palestino, 2007b] Palestino, C.V.B. Relatório Semestral da Instituição Implementadora FUMSOFT, Agosto 2007. [Palestino, 2007c] Palestino, C.V.B. Relatório Semestral da Instituição Implementadora FUMSOFT, Dezembro 2007. [Palestino, 2008] Palestino, C.V.B. Relatório Semestral da Instituição Implementadora FUMSOFT, Junho 2008. [Ribeiro, 2007] Ribeiro, A.F., 2007, “Melhoria de Processos de Software com Base no Nível G do MPS.BR na Prodemge”, In: PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp. 87-90, Novembro. [Rocha et al., 2005] Rocha, A. R., Montoni, M., Santos, G., et al., 2005, “Fatores de Sucesso e Dificuldades na Implementação de Processos de Software Utilizando o MR- MPS e o CMMI”, In: PROQUALITY – Qualidade na Produção de Software, pp. 13-18, Junho. [Rocha, 2006] Rocha, A.R. Relatório Semestral da Instituição Implementadora COPPE/UFRJ, Março 2006. [Rouiller, 2005] Rouiller, A.C. Relatório Semestral da Instituição Implementadora SWQuality, Novembro 2005. [Rouiller, 2007] Rouiller, A.C. Relatório Semestral da Instituição Implementadora SWQuality, Abril 2007. [Salgado, 2008] Salgado, C.G. Relatório Semestral da Instituição Implementadora UCB, Junho 2008. [Salviano, 2006] Salviano, C. F. Relatório Semestral da Instituição Implementadora CenPRA, Dezembro 2006. [Salviano, 2008] Salviano, C. F. Relatório Semestral da Instituição Implementadora CenPRA, Maio 2008. 42
- 44. [Santos et al., 2007] Santos, G., Montoni, M., Figueiredo, S., et al., 2007, "SPI-KM - Lessons Learned from Applying a Software Process Improvement Strategy Supported by Knowledge Management", Product-Focused Software Process Improvement. [Santos et al., 2007] Santos, G., Montoni, M., Vasconcellos, J, et al., 2007, “Implementação do MR-MPS Níveis G e F em Grupos de Empresas do Rio de Janeiro”, In: PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp. 53-58, Novembro. [Scheid et al., 2007] Scheid, M., Pessoa, M., Gomes, R.F., et al., 2007, “Implantação do MR-MPS Nível E no Centro de Computação da Aeronáutica de São José dos Campos”, In: PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp. 97-104, Novembro. [SOFTEX, 2007] SOFTEX, 2007, "MPS.BR – Melhoria de Processo do Software Brasileiro, Guia Geral (v. 1.2)". In: http://www.softex.br/mpsbr/_guias/default.asp. [SOFTEX, 2008] SOFTEX, 2008, "Site do MPS.BR - Melhoria de Processos do Software Brasileiro". In: http://www.softex.br/mpsbr, acessado em 20/08/2008. [Sória, 2007] Sória, F. Relatório Semestral da Instituição Implementadora CITS, Março 2007. [Sória, 2008a] Sória, F. Relatório Semestral da Instituição Implementadora CITS, Maio 2008. [Sória, 2008b] Sória, F. Relatório Semestral da Instituição Implementadora CITS, Julho 2008. [Souza e Pinto, 2007] Souza, J.P., Pinto, M.V., 2007, “Prodabel: Diagnóstico da Implantação do Nível G do MPS.BR”, In: PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp. 123-128, Novembro. [Souza, 2006] Souza, A.S. Relatório Semestral da Instituição Implementadora Estratégia, Outubro 2006. [Souza, 2007a] Souza, A.S. Relatório Semestral da Instituição Implementadora Estratégia, Abril 2007. [Souza, 2007b] Souza, A.S. Relatório Semestral da Instituição Implementadora Estratégia, Julho 2007. [Souza, 2008] Souza, A.S. Relatório Semestral da Instituição Implementadora Estratégia, Janeiro 2008. [Staples et al., 2007] Staples, M., Niazi, M., Jeffery, R., et al., 2007, "An exploratory study of why organizations do not adopt CMMI", Journal of Systems and Software, v. 80, n. 6, pp. 883-895. 43
- 45. 44 [Thiry et al., 2007] Thiry, M., Wangenheim, C.G., Zoucas, A., 2007, “Implementação do MPS.BR em Grupo de Empresas da ACATE em Florianópolis 2007/2008”, In: PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp. 59-64, Novembro. [Tsukumo et al., 2006] Tsukumo, A. N., De Martino, W. R., Sérgio, M. P., Salviano, C.F., 2006, “Lições aprendidas na aplicação do Método Coop-MPS para Projetos Cooperativos de Melhoria de Processo de Software com MPS.BR”, In: PROQUALITY – Qualidade na Produção de Software, v. 2, n.2, pp. 51-56, Novembro. [Vargas et al., 2007] Vargas, D., Nigri, M., Krieger, M., et al., 2007, “Melhoria de Processos na Marlin”, In: PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp. 117-122, Novembro. [Yoshida et al., 2007] Yoshida, D., Kohan, S., Salvettie, N., Hirama, K., 2007, “Convênio ComQualidade: Implementação MPS.BR Nível G em Grupo de Empresas de São Paulo”, In: PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp. 49-52, Novembro. [Yoshida, 2007a] Yoshida, D. Relatório Semestral da Instituição Implementadora ITS, Abril 2007. [Yoshida, 2007b] Yoshida, D. Relatório Semestral da Instituição Implementadora ITS, Julho 2007. [Zabeu, 2007a] Zabeu, A. Relatório Semestral da Instituição Implementadora ASR, Julho 2007. [Zabeu, 2007b] Zabeu, A. Relatório Semestral da Instituição Implementadora ASR, Dezembro 2007. [Zaharan, 1998] Zaharan, S., 1998, Software Process Improvement – Practical Guidelines for Business Success, Addison-Wesley.
- 46. Lições Aprendidas em Avaliações MPS Ana Regina Rocha COPPE/UFRJ – Universidade Federal do Rio de Janeiro Caixa Postal 68511 – CEP 21945-970 – Rio de Janeiro-RJ, Brasil [email protected] Resumo. Este trabalho descreve as lições aprendidas pelas instituições avaliadoras do MPS.BR no período 2005-2008. Após três anos de avaliações MPS podemos afirmar que o método de avaliação MA-MPS e o processo de avaliação MPS, bem como o modelo de referência MR-MPS, são consistentes e possibilitam conduzir avaliações de forma adequada e segura. 1. Introdução O sucesso do Programa MPS.BR é indiscutível e superou qualquer expectativa, mesmo as mais otimistas. Neste momento (outubro de 2008) tem-se cerca de 110 empresas avaliadas. Mais de 200 empresas, públicas e privadas, implementaram ou estão implementando o MR-MPS. A avaliação MPS está sendo adotada como critério de pontuação técnica em importantes licitações. Esta ampla aceitação deve-se, entre outros fatores, à seriedade do programa MPS.BR e do modelo MPS e garantir esta seriedade tem sido uma das principais preocupações da SOFTEX e das Instituições Avaliadoras. Ela se reflete na seleção adequada da equipe de avaliação, no conhecimento que os avaliadores têm do modelo e da Engenharia de Software, na organização e pontualidade no planejamento e realização das avaliações, na postura ética dos avaliadores, no cuidado com a qualidade da documentação da avaliação, na seleção dos entrevistados, na relação das Instituições Avaliadoras (IAs) com as empresas, as Instituições Organizadoras de Grupo de Empresas (IOGEs) e as Instituições Implementadoras (IIs). Este artigo descreve um conjunto de lições aprendidas pelas Instituições Avaliadoras MPS.BR com a realização de avaliações ao longo dos últimos 3 anos. 2. Avaliação MPS e Instituições Avaliadoras O propósito do método de avaliação MA-MPS é verificar a maturidade de uma organização/unidade organizacional na execução de seus processos de software. O processo e o método de avaliação MA-MPS foram definidos de forma a permitir a avaliação objetiva dos processos de software de uma organização/unidade organizacional; permitir a atribuição de um nível de maturidade do MR-MPS com base no resultado da avaliação; ser aplicável a qualquer domínio de aplicação na indústria de software e ser aplicável a organizações/unidades organizacionais de qualquer tamanho. Uma avaliação MPS tem validade de três anos [MPS.BR, 2007a]. 45
- 47. O processo e o método de avaliação MA-MPS foram definidos de forma aderente à norma internacional ISO/IEC 15504-3:2003 [ISO/IEC 15504-2:2003]. As avaliações MPS tem como modelo de referência o MR-MPS descrito no Guia Geral v. 1.2 [MPS.BR, 2007b], que tem como comunidade de interesse empresas públicas e privadas, de diferentes tamanhos e características que atuem no desenvolvimento e manutenção de software. O modelo de referência MPS (MR-MPS) busca atender à necessidade de implantar os princípios de Engenharia de Software de forma adequada ao contexto das empresas brasileiras. O MR-MPS é definido em consonância com a norma internacional ISO/IEC 12207 [ISO/IEC 12207:1995] e suas emendas 1 [ISO/IEC 12207:1995/Amd 1:2002]e 2 [ISO/IEC 12207:1995/Amd 2:2004], adaptando-a às necessidades da comunidade de interesse. Para definição e revisão do modelo de referência é feita uma ampla consulta à comunidade de implementadores e avaliadores MPS.BR. A elaboração final é responsabilidade da ETM. Atualmente estão sendo realizados os ajustes necessários para conformidade com a ISO/IEC 12207:2008 [ISO/IEC 12207:2008]. O processo de avaliação MPS é aderente à ISO/IEC 15504-2:2003 quanto às atividades e tarefas do processo. A tabela 1 mostra o mapeamento entre as atividades requeridas para um processo de avaliação aderente à norma ISO/IEC 15504-2:2003 e as atividades do processo de avaliação MPS. Tabela 1 - Atividades requeridas para um processo de avaliação aderente à ISO/IEC 15504-2:2003 e as atividades do processo de avaliação MPS ISO/IEC 15504-2:2003 Processo de Avaliação MPS - Pesquisar instituições avaliadoras - Estabelecer contrato - Viabilizar a avaliação Planejamento Planejar a avaliação Coleta de dados Preparar a avaliação Validação de dados Conduzir a avaliação inicial Planejamento/ Coleta de dados Completar a preparação da avaliação Validação de dados/ Atribuição de grau aos atributos do processo/ Relato dos resultados Conduzir a avaliação final - Avaliar a execução do processo de avaliação Relato dos resultados Relatar Resultados Relato dos resultados Registrar Resultados Os papéis e responsabilidades relacionados ao processo de avaliação MPS estão descritos no Guia de Avaliação MPS e atendem aos requisitos descritos na seção 4.3 da Norma ISO/IEC 15504-2:2003. As entradas para a avaliação MPS estão descritas no Plano de Avaliação, elaborado na tarefa Planejar a avaliação que contém: (i) identificação do processo e método de avaliação MPS e do modelo de referência MR-MPS como base da avaliação; (ii) 46
- 48. informações sobre a empresa; (iii) objetivo da avaliação; (iv) parâmetros da avaliação; (v) cronograma geral da avaliação; (vi) projetos selecionados para avaliação; (vii) equipe de avaliação; (viii) participantes da avaliação e respectivos papeis; (ix) duração e cronograma das atividades de avaliação; (x) propriedade dos resultados da avaliação; (xi) restrições para uso dos resultados da avaliação. Um Acordo de Confidencialidade é assinado pelo avaliador líder, avaliador adjunto e patrocinador e pelos demais membros da equipe antes de iniciarem qualquer tarefa de avaliação. Estas entradas obedecem aos requisitos descritos na seção 4.4 da norma ISO/IEC 15504-2:2003. O processo de avaliação MPS, também, é aderente à ISO/IEC 15504-2:2003 quanto ao registro da avaliação. O Relatório de Avaliação MPS contém: (i) identificação do Processo e Método de Avaliação MPS; (ii) Informações sobre a empresa; (iii) objetivo da avaliação; (iv) parâmetros da avaliação; (v) data da avaliação; (vi) projetos selecionados para avaliação; (vii) equipe de avaliação; (viii) participantes da avaliação e respectivos papéis; (ix) evidências coletadas; (x) resultados por área de processo; (xi) observações gerais quanto ao Modelo; (xii) outras observações gerais e (xiii) nível de maturidade MPS da Unidade Organizacional. Este registro obedece aos requisitos descritos na seção 4.5 da norma ISO/IEC 15504-2:2003. De acordo com o processo e método de avaliação MPS, os resultados de processo e de atributos de processo são medidos usando a escala ordinal definida na seção 5.7 da norma ISO/IEC 15504-2:2003. A atribuição de nível MPS é feita considerando os resultados de processo e de atributos de processo o que inclui as dimensões de maturidade e de capacidade. A atribuição de nível no que se refere aos atributos de processo segue a tabela definida na seção 5.8 da norma ISO/IEC 15504-2:2003. A atribuição de nível no que se refere aos resultados de processo segue a escala de porcentagem definida na seção 5.7 da norma ISO/IEC 15504-2:2003. A conformidade das avaliações com o processo e método de avaliação MA-MPS são garantidas através das auditorias realizadas pelo grupo de auditores MPS. Uma avaliação MPS é conduzida por uma Instituição Avaliadora (IA) credenciada pela SOFTEX. Para solicitar o seu credenciamento, as instituições proponentes devem: (i) demonstrar possuir uma estratégia institucional de capacitação dos avaliadores, líder e adjunto, com destaque para os processos de seleção, capacitação e manutenção da competência dos avaliadores; (ii) ter vinculado à mesma, no mínimo, um profissional que cumpra os requisitos de avaliador líder (coordenador da IA) e um profissional que cumpra os requisitos de avaliador adjunto. Um avaliador líder deve cumprir requisitos de formação acadêmica (especialização, mestrado ou doutorado concluídos e conhecimento comprovado de Engenharia de Software com foco em processos de software), treinamento MPS.BR (participação no curso e aprovação na prova para formação de avaliadores MPS, participação em quatro avaliações como avaliador adjunto e aprovação como avaliador líder após conduzir uma avaliação observada por um avaliador líder indicado pela SOFTEX) e experiência profissional comprovada (no mínimo oito anos na área de Engenharia de Software e seis anos em gerência de projetos de software ou experiência de implementação de processos de software onde a unidade organizacional obteve nível de maturidade em avaliação oficial). 47
- 49. No programa MPS.BR existem três níveis de avaliadores líderes: (i) avaliador líder inicial, que deve atender aos requisitos descritos acima e está habilitado para liderar avaliações níveis G e F; (ii) avaliador líder intermediário, habilitado a liderar avaliações até o nível C e que além dos requisitos de avaliador líder inicial deve cumprir novos requisitos de formação acadêmica (ter mestrado e/ou doutorado concluídos em computação ou áreas afins), treinamento MPS.BR (participação em avaliações de níveis E, C ou D) e experiência profissional (seis anos em gerência de projetos de software, experiência de implementação de processos de software onde a unidade organizacional obteve nível de maturidade em avaliação oficial e ter liderado quatro avaliações de níveis G ou F, sendo pelo menos duas de nível F) e (iii) avaliador líder experiente, habilitado a liderar avaliações de todos os níveis e que deve cumprir, além dos requisitos anteriores, novos requisitos de formação acadêmica (é desejável que tenha doutorado em computação ou áreas afins e é obrigatório possuir conhecimento comprovado em controle estatístico de processos); treinamento MPS.BR (participação em uma avaliação de níveis B ou A como avaliador adjunto onde participou de mini- equipe responsável por processos destes níveis); experiência profissional (ter liderado quatro avaliações de níveis E, D ou C, sendo pelo menos duas de níveis D ou C). Uma avaliação MPS sempre tem a participação de um avaliador adjunto, cujo papel é apoiar o avaliador líder. Um avaliador adjunto cumpre os seguintes requisitos de formação acadêmica (especialização, mestrado ou doutorado concluídos e conhecimento comprovado de Engenharia de Software com foco em processos de software), treinamento MPS.BR (participação no curso e aprovação na prova para formação de avaliadores) e experiência profissional (no mínimo três anos em gerência de projetos de software ou experiência de implementação de processos de software onde a unidade organizacional obteve nível de maturidade ou certificado ISO 9000:2000 com avaliação oficial). 3. Lições Aprendidas nas Avaliações MPS Avaliações MPS estão sendo realizadas desde 2005 e nestes três anos foram realizadas avaliações em empresas públicas e privadas, de diferentes tamanhos e localizadas em todas as regiões do Brasil. Esta experiência permitiu identificar um conjunto de lições aprendidas e melhores práticas adotadas pelas várias Instituições Avaliadoras [Galarraga, 2007], [Rocha,2007], [Machado,2007], [Oliveira, 2007], [Palestino, 2007], [Amaral, 2008], [Oliveira, 2008], [Rocha, 2008] que relatamos a seguir agrupadas em sete categorias: capacitação da equipe, preparação da avaliação, clima da avaliação, resultado da avaliação, auditoria das avaliações, formação de novas instituições avaliadoras e relação com as instituições implementadoras. 3.1. Lições aprendidas e práticas relacionadas à capacitação da equipe (i). Um fator de sucesso para uma IA é contar com uma equipe bem formada no modelo MPS e em Engenharia de Software. Quanto maior for este conhecimento, maior será a capacidade do avaliador de entender a implementação da empresa e ser flexível aceitando soluções válidas, mesmo que estas não sejam as melhores soluções ou as que escolheria, ao implementar um ou mais resultados. Investir na formação teórico/prática da equipe é imprescindível. 48
- 50. (ii). A maior parte dos avaliadores MPS são, também, implementadores. Consideramos esta uma boa prática. A experiência de implementação em diversas empresas contribui para a formação do avaliador. (iii). A SOFTEX organiza, anualmente, um Workshop de Avaliadores MPS onde a participação dos avaliadores é obrigatória a cada 2 anos. Participar regularmente, deste e de outros fóruns, nacionais e internacionais, favorece a atualização dos avaliadores MPS em relação aos mais modernos métodos e técnicas para gerência, desenvolvimento e manutenção de software. 3.2. Lições aprendidas e práticas relacionadas à preparação da avaliação (i). Uma avaliação MPS tem uma avaliação inicial, onde é feita uma avaliação das evidências apresentadas pela organização/unidade organizacional avaliada, e uma avaliação final onde as evidências são revistas, conforme necessário, são realizadas entrevistas e é atribuído um grau de implementação aos resultados esperados que culmina com a atribuição de um nível de maturidade MPS. A avaliação inicial é de fundamental importância para o sucesso de uma avaliação MPS e é recomendável que toda a equipe de avaliação participe da avaliação inicial. (ii). O relatório de avaliação inicial é a melhor forma de ajudar a empresa a se preparar para a avaliação final. Para isso, é importante sempre indicar a sugestão de correção para o problema identificado, mesmo que isso seja opcional pelo Guia de Avaliação. Deve-se, ainda, garantir que essa sugestão para correção seja claramente entendida pela empresa. (iii). A organização da avaliação e o cumprimento do cronograma são de grande importância. No planejamento de uma avaliação deve-se considerar o horário normal de funcionamento da empresa e considerá-lo na elaboração do cronograma. Nunca se deve planejar iniciar o trabalho antes deste horário, nem terminá-lo depois. (iv). A duração das avaliações depende do grau de experiência do avaliador líder e dos avaliadores adjuntos. É conveniente que nas primeiras avaliações de um avaliador líder este use o tempo máximo de referência que consta no Guia de Avaliação. Progressivamente um avaliador líder irá ajustar a duração das avaliações baseado em sua experiência e em seu ritmo pessoal. (v). Em qualquer circunstância é fundamental que a avaliação seja conduzida com tranqüilidade. Para isso, muitas IAs têm optado por utilizar, sempre, o tempo máximo estimado para a avaliação no Guia de Avaliação. (vi). Durante o planejamento da avaliação, é boa prática estabelecer o prazo de um mês entre a avaliação inicial e a avaliação final. Após o resultado da avaliação inicial, esta data pode ser alterada, garantindo-se sempre que a empresa possa se preparar com tranqüilidade para a avaliação final. 49
- 51. (vii). Uma avaliação MPS pode ser solicitada por uma unidade organizacional muito grande. Neste caso é importante que se garanta a representatividade dos projetos selecionados para a avaliação. Sempre que possível, a seleção dos projetos que serão avaliados, deve ser feita em visita à empresa, antes da avaliação inicial. (viii). Avaliações onde a implementação não foi feita por uma II ou, nem mesmo, por um implementador MPS são especialmente críticas, pois a unidade organizacional pode não ter tido uma interpretação adequada do modelo. Nestes casos a avaliação inicial deve ter a maior duração prevista no Guia de Avaliação e a IA deve procurar que a equipe de avaliação seja formada por seus avaliadores mais experientes. (ix). Um aspecto que tem facilitado o trabalho das IAs é o uso de documentos padrão para as comunicações que ocorrem no processo de avaliação, tais como e-mails e instruções que a equipe de avaliação deve enviar à empresa avaliada, especialmente orientações para a realização da avaliação e especificação da infra-estrutura necessária para as avaliações. (x). Algumas IAs buscam obter, antes da avaliação inicial, informações sobre as características da implementação e da empresa, tais como a ocorrência de sucessos ou dificuldades durante a implementação, tipo de ciclo de vida adotado, ferramentas utilizadas, grau de formação da equipe. Consideram que com estas informações o avaliador líder terá maior facilidade para realizar o planejamento da avaliação, analisar riscos e manter o foco nos aspectos críticos, aumentando a produtividade da equipe de avaliação. 3.3. Lições aprendidas e práticas relacionadas ao clima durante a avaliação (i). É importante estabelecer um ambiente de avaliação agradável e buscar um clima harmonioso com a empresa desde o primeiro contato na avaliação inicial de forma a tornar a avaliação menos tensa e mais produtiva. (ii). Os treinamentos do MPS.BR na avaliação são, normalmente, mais direcionados aos representantes da empresa. Esses representantes, em geral, estão nervosos o que os leva a não questionarem e manterem suas duvidas durante o treinamento. É importante incentivá-los a explicitar suas dúvidas, de forma a atuarem da melhor forma na avaliação. (iii). É importante integrar o melhor possível o representante da empresa para que ele/ela se sinta participante do processo e se sinta confortável para colocar suas opiniões durante a avaliação. (iv). Em uma avaliação, os membros da organização avaliada que participam da avaliação, algumas vezes, adotam posturas defensivas, principalmente nas discussões quanto à adequação das evidências dos processos implementados. Essas posturas criam barreiras que dificultam a avaliação dos processos. É importante que a equipe de avaliação saiba superar essas barreiras por meio da promoção de um ambiente amigável entre os avaliadores e os membros da organização de forma que haja colaboração mútua entre as pessoas na avaliação dos processos. 50
- 52. (v). Um dos aspectos mais importantes em uma avaliação MPS é a comunicação. Quando a comunicação flui entre os membros da equipe de avaliação e os demais envolvidos, todos os problemas encontrados são equacionados, brevemente e sem sobressaltos, permitindo a construção de uma visão consensual. Neste contexto, percebe-se claramente que uma das qualidades imprescindíveis ao avaliador líder é a boa comunicação, sobre tudo o saber ouvir. (vi). O principal responsável pelo resultado de uma avaliação é o avaliador líder. A organização avaliada poderá perder a confiança no avaliador líder e, consequentemente, no resultado da avaliação, se perceber que este é desrespeitado pelos outros membros da equipe de avaliação. Portanto, os membros da equipe devem sempre demonstrar respeito pelo avaliador líder, principalmente na presença de membros da organização avaliada. (vii). É comum, e compreensível, que as empresas fiquem muito ansiosas para a avaliação. Isto pode ser contornado através de um contato prévio do avaliador líder com a empresa. Muitas vezes basta um telefonema para deixar as pessoas mais tranqüilas. Nas empresas em que ocorreu uma preparação maior para a avaliação, com palestras relacionadas ao assunto fornecidas pela própria II ou pela IA, foi percebida uma maior tranqüilidade em relação à avaliação, o que facilitou o trabalho dos avaliadores e a compreensão, pela empresa, de suas fraquezas, possibilitando melhorar seus processos entre as avaliações inicial e final. 3.4. Lições aprendidas e práticas relacionadas aos resultados da avaliação (i). O resultado de uma avaliação MPS pode ser usado tanto para orientar a organização na melhoria dos processos implementados, quanto para apoiar na definição dos próximos passos para crescimento da maturidade dos seus processos. Portanto, a equipe de avaliação deve avaliar também aspectos da implementação que, apesar de atenderem adequadamente o nível solicitado, devem ser melhorados para que a organização alcance rapidamente e de forma adequada níveis mais altos de maturidade. (ii). Em algumas organizações, as IAs percebem que a implementação do modelo está desalinhada com o negócio da empresa. O avaliador líder tem que ter a percepção de que realmente a utilização do processo da empresa trouxe resultados satisfatórios em relação ao negócio, de forma que a melhoria de processos possa colaborar efetivamente com o crescimento da empresa. Essa percepção deve orientar a conversa final com o patrocinador e enriquecer a contribuição da IA com a melhoria de processos. (iii). Deve ser evitada uma abordagem de apresentação dos resultados restrita a divulgar se a empresa conseguiu o nível almejado. O momento da apresentação dos resultados, tanto da avaliação inicial quanto da final, deve ser um momento em que o patrocinador possa discutir, questionar e obter subsídios para a melhoria de processos na sua empresa. Essas informações podem extrapolar os processos que estão sendo avaliados. Uma vez que os avaliadores tiveram a oportunidade de conhecer mais a fundo a forma de trabalho da empresa, deve-se explorar esta visibilidade obtida, fornecendo um feedback detalhado para a melhoria de processos e para a evolução da 51
- 53. 3.5. Lições aprendidas e práticas relacionadas à auditoria das avaliações (i). Todas as avaliações MPS são auditadas e esta prática tem se mostrado muito importante. Consideramos importante, entretanto, que antes de enviar ao auditor a documentação, a IA tenha seus próprios procedimentos de garantia da qualidade com algum tipo de revisão por pares. A presteza no envio para a auditoria também é importante, pois as empresas aguardam a publicação dos resultados e esta só é liberada após o término da auditoria. 3.6. Lições aprendidas e práticas relacionadas à formação de novas Instituições Avaliadoras (i). É responsabilidade de todas as IAs credenciadas, contribuir para a formação de novas IAs e para a promoção de avaliadores líderes a níveis mais altos. Todas as IAs têm muito clara esta responsabilidade e estão comprometidas em torná-la realidade. Entretanto, envolver avaliadores voluntários não pode significar prejuízo para o resultado da avaliação. Desta forma, é necessário extremo cuidado na alocação de avaliadores voluntários, especialmente, quando estes têm pouca experiência em implementações e avaliações. Consideramos adequado, de inicio, alocá-los em uma mini- equipe com outro avaliador adjunto da IA, mais experiente, o que favorece o seu aprendizado e não oferece riscos para a avaliação. Avaliadores voluntários, também, só devem ser alocados em avaliações observadas caso o observador esteja seguro de sua experiência. (ii). Os avaliadores voluntários estão em momento de formação e é importante que a participação em uma avaliação seja, de fato, relevante para a sua formação. Deve-se, portanto, evitar colocar avaliadores em formação, nas primeiras avaliações realizadas por um novo avaliador líder. 3.7. Lições aprendidas e práticas relacionadas às Instituições Implementadoras (i). A presença de um representante da Instituição Implementadora durante a avaliação inicial tem se revelado de grande importância, ajudando a empresa a entender os ajustes necessários na implementação e as oportunidades de melhoria para as empresas. (ii). Algumas IAs têm como prática fornecer feedback para a instituição implementadora, após o encerramento da avaliação. Esse procedimento, realizado sem a participação da empresa que foi avaliada, visa o aprendizado mútuo, tanto para a II quanto para a IA. 52
- 54. (iii). Quando existem problemas estruturais de implementação de processos detectados na avaliação inicial, é importante envolver o implementador durante o acompanhamento realizado pela IA entre a avaliação inicial e a avaliação final, pois este possui mais facilidade de entender os problemas e de se comunicar com a IA. Este procedimento foi utilizado em alguns casos e apresentou um resultado satisfatório, gerando soluções que realmente contribuíram para a melhoria do processo existente. Assim, caso alguma questão não seja resolvida na própria avaliação inicial, diversas idéias e soluções podem ser discutidas com o implementador. (iv). Algumas vezes as IAs percebem um desgaste no relacionamento entre o implementador MPS e a empresa. Nestes casos, o papel da IA é de parceria com os implementadores e, portanto, deve-se sempre adotar uma postura ética, valorizando a relação entre a empresa e o implementador. 4. Conclusão Este trabalho descreveu um conjunto de lições aprendidas e práticas adotadas como resultado da experiência das diversas Instituições avaliadoras MPS. Após um período de três anos realizando avaliações, podemos afirmar que o método e o processo de avaliação MPS, bem como o modelo de referência MR-MPS, são consistentes e possibilitam conduzir avaliações de forma adequada e segura. Constatou-se, também, nas avaliações realizadas que a implementação do MR-MPS é, realmente, viável desde pequenas unidade organizacionais com menos de 20 colaboradores até grandes unidades com mais de 1.300 funcionários. As formas de implementação, embora distintas, atendem ao MR-MPS permitindo uma adequação ao porte e ao interesse da empresa em melhoria de processos. 53
- 55. Referências [Amaral, 2008] Amaral,M.P. do Relatório Semestral da Instituição Avaliadora RIOSOFT, Agosto 2008 [Galarraga, 2007] Galarraga, O. et al. A Experiência da IA Estratégia em Avaliações MPS.BR, II Workshop de Avaliadores MPS.BR, Belo Horizonte, MG, novembro 2007 [ISO/IEC 12207:1995] - International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 12207 Information technology – Software life cycle processes, Genebra: ISO, 1995. [ISO/IEC 12207:1995/Amd 1:2002] - International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 12207 Amendment: Information Technology - Amendment 1 to ISO/IEC 12207, Genebra: ISO, 2002. [ISO/IEC 12207:1995/Amd 2:2004] - International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 12207 Amendment: Information Technology - Amendment 2 to ISO/IEC 12207, Genebra: ISO, 2004. [ISO/IEC 12207:2008] - International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 12207/IEEE Std 12207 Systems andSoftware Engineering – Software life cycle processes, Genebra: ISO, 2008. [ISO/IEC 15504-2, 2003] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 15504-2: Information Technology - Process Assessment – Part 2 - Performing an Assessment, Geneve: ISO, 2003. [Machado,2007] Machado, C.F. et al. Instituição avaliadora SwQuality: Aprendizado Obtido nas avaliações MPS.BR, II Workshop de Avaliadores MPS.BR, Belo Horizonte, MG, novembro 2007 [MPS.BR, 2007b] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guia de Avaliação, versão 1.1, junho 2007. Disponível em: www.softex.br. [MPS.BR, 2007b] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guia Geral, versão 1.2, junho 2007. Disponível em: www.softex.br. 54
- 56. [Oliveira, 2007] Oliveira,K.M. et al. Instituição Avaliadora Universidade Católica de Brasília: Primeiras Avaliações e Impressões, II Workshop de Avaliadores MPS.BR, Belo Horizonte, MG, novembro 2007 [Oliveira, 2008] Oliveira,J. Relatório Semestral da Instituição Avaliadora Estratégia, agosto 2008 [Palestino, 2007] Palestino,C.B. Relatório Semestral da Instituição Avaliadora CCOMP.MG/ FUMSOFT, dezembro 2007. [Rocha,2007] Rocha,A.R. et al. IA COPPE/UFRJ: Lições Aprendidas e Melhores Práticas, II Workshop de Avaliadores MPS.BR, Belo Horizonte, MG, novembro 2007 [Rocha, 2008] Rocha,A.R. Relatório Semestral da Instituição Avaliadora COPPE/UFRJ, agosto 2008. 55