mps.br nÍvel g: obtenÇÃo de qualidade em...
TRANSCRIPT
UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ – UTFPR
CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE
SISTEMAS
SILVANE GASS
MPS.BR NÍVEL G: OBTENÇÃO DE QUALIDADE EM DESENVOLVIMENTO DE
SOFTWARE
TRABALHO DE DIPLOMAÇÃO
MEDIANEIRA
2011
SILVANE GASS
MPS.BR NÍVEL G: OBTENÇÃO DE QUALIDADE EM DESENVOLVIMENTO DE
SOFTWARE
Trabalho de Diplomação apresentado à
disciplina de Trabalho de Diplomação, do Curso
Superior de Tecnologia em Análise e
Desenvolvimento de Sistemas – CSTADS – da
Universidade Tecnológica Federal do Paraná –
UTFPR, como requisito parcial para obtenção
do título de Tecnólogo.
Orientador: Prof Alan Gavioli, Msc.
Co-orientador: Juliano Rodrigo Lamb.
MEDIANEIRA
2011
Ministério da Educação Universidade Tecnológica Federal do Paraná Diretoria de Graduação e Educação Profissional
Coordenação do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas
TERMO DE APROVAÇÃO
MPS.BR NÍVEL G: OBTENÇÃO DE QUALIDADE EM DESENVOLVIMENTO DE SOFTWARE.
Por
Silvane Gass
Este Trabalho de Diplomação (TD) foi apresentado às 14:40 h do dia 23 de de
novembro de 2011 como requisito parcial para a obtenção do título de Tecnólogo
no Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas, da
Universidade Tecnológica Federal do Paraná, Campus Medianeira. O candidato foi
argüido pela Banca Examinadora composta pelos professores abaixo assinados.
Após deliberação, a Banca Examinadora considerou o trabalho aprovado.
Prof. Alan Gavioli UTFPR – Campus Medianeira
(Orientador)
Prof. Alessandra Garbelotti Bortolet UTFPR – Campus Medianeira
(Convidado)
Prof. Diego Stiehl UTFPR – Campus Medianeira
(Convidado)
Prof. Juliano Rodrigo Lamb UTFPR – Campus Medianeira
(Responsável pelas atividades de TCC)
A folha de aprovação assinada encontra-se na Coordenação do Curso.
RESUMO
GASS, Silvane. MPS.BR nível G: Obtenção de qualidade em desenvolvimento de software.
Trabalho de conclusão de curso, Universidade Tecnológica Federal do Paraná. Medianeira,
2011.
Este trabalho apresenta um estudo sobre o MPS.BR (Melhoria do Processo de Software
Brasileiro), dando ênfase em como uma empresa que deseja obter certificação MPS.BR nível
G deve proceder para alcançar este objetivo. Este estudo foi baseado, em partes, na
experiência adquirida com a implantação do modelo em uma empresa de software do oeste do
Paraná.
Palavras chaves: qualidade, MPS.BR, melhoria, processo, software.
ABSTRACT
GASS, Silvane. MPS.BR level G: Obtaining quality in software development. Course
completion assignment, Universidade Tecnológica Federal do Paraná. Medianeira, 2011.
This paper presents a study on the MPS.BR (Brazilian Software Process Improvement), with
emphasis on how a company that wishes to obtain MPS.BR level G certification must proceed
toward this goal. This study was based in part on experience gained with the implementation
of the model in a software company in the west of Paraná.
Keywords: quality, MPS.BR, improvement, process, software.
LISTA DE FIGURAS
Figura 1 – Estrutura do MPS.BR .......................................................................................... 18
Figura 2 – Níveis de Maturidade do MPS.BR ....................................................................... 18
Figura 3 – Níveis de maturidade do MPS.BR e seus atributos de processo ........................... 21
Figura 4 – Fases do Projeto Rumo ao MPS.BR .................................................................... 32
Figura 5 – Legenda de Avaliação ......................................................................................... 36
Figura 6 – Percentual de Aderência – Definição ................................................................... 37
Figura 7 – Percentual de Aderência – Institucionalização ..................................................... 37
Figura 8 – Ferramenta BizAgi .............................................................................................. 46
Figura 9 – Arquitetura dos Processos ................................................................................... 47
Figura 10 – Duração do projeto Rumo ao MPS.BR .............................................................. 48
Figura 11 – Planejamento Digitaldoc ................................................................................... 48
LISTA DE TABELAS
Tabela 1 – Dados gerais do projeto MPS.BR ........................................................................ 39
Tabela 2 – Subsídios destinados ao projeto MPS.BR ............................................................ 42
Tabela 3 – Custos relacionados ao projeto MPS.BR ............................................................. 42
Tabela 4 - Horas gastas no projeto Rumo ao MPS.BR .......................................................... 44
Tabela 5 – Execução do Projeto MPS.BR............................................................................. 48
LISTA DE SIGLAS
AMP Avaliação E Melhoria Do Processo Organizacional
AN Analista de Negócios
AP Atributo De Processo
AP Analista de Projeto
APC Analista de Processo
APL Iguassu-IT Arranjo Produtivo Local de Tecnologia da Informação do Oeste do
Paraná
AS Analista de Sistemas
AT Analista de Testes
AQU Aquisição
BID Banco Interamericano De Desenvolvimento
BPMN Business Process Modeling Notation
CA Consultores de Aquisição
CITS Centro Internacional De Tecnologia De Software
CL Cliente
CMMI Capability Maturity Model Integration
CRC Sistema de Controle de Requisições
DFP Definição De Processo Organizacional
DR Diretor
DRE Desenvolvimento De Requisitos
DRU Desenvolvimento Para Reutilização
DS Desenvolvedor
EAP Estrutura Analítica Do Projeto
ECM Enterprise Content Management
Finep Financiadora De Estudos E Projetos
FR Fornecedor de Requisitos
GCO Gerência De Configuração
GDE Gerência De Decisões
GED Gerenciamento Eletrônico de Documentos
GP Gerente de Projetos
GPP Gerência De Portfólios Do Projeto
GPR Gerência De Projetos
GQA Garantia Da Qualidade
GRE Gerência De Requisitos
GRI Gerência De Riscos
GRU Gerência De Reutilização
HTML Hypertext Markup Language
IA Instituição Avaliadora
II Instituição Implementadora
IOGE Instituição Organizadora de Grupo de Empresas
ITP Integração Do Produto
ISO/IEC International Organization For Standardization And The International
Electrotechnical Comission
MA-MPS Método de Avaliação MPS.BR
MCT Ministério Da Ciência E Tecnologia
MED Medição
MNC Modelo de Negócio Cooperado
MNE Modelo de Negócio Específico
MN-MPS Modelo de Negócio MPS.BR
MR-MPS Modelo de Referência MPS.BR
MPS.BR Melhoria do Processo de Software Brasileiro
PCP Projeto E Construção Do Produto
PMBOK Project Management Body Of Knowledge
PME Pequenas e Médias Empresas
PMI Project Management Institute
Pratiq Programa De Análise De Qualidade Em TI
RAP Resultado Do Atributo De Processo
Sebrae Serviço De Apoio As Micro E Pequenas Empresas
Sebraetec Serviços em Inovação e Tecnologia
Softex Associação Para A Promoção Da Excelência Do Software Brasileiro
SVN Subversion
VAL Validação
VER Verificação
WBS Work Breakdown Structure
SUMÁRIO
1 INTRODUÇÃO ........................................................................................................ 9
1.1 OBJETIVO GERAL ................................................................................................. 10
1.2 OBJETIVOS ESPECÍFICOS .................................................................................... 10
1.3 JUSTIFICATIVA ..................................................................................................... 10
1.4 ESTRUTURA DO TRABALHO .............................................................................. 12
2 O MODELO MPS.BR ............................................................................................ 13
2.1 MOTIVAÇÃO ......................................................................................................... 13
2.2 O MODELO MPS.BR .............................................................................................. 15
2.2.1 Estrutura do MPS.BR ............................................................................................... 16
3 MPS.BR NÍVEL G ................................................................................................. 22
3.1 GERÊNCIA DE PROJETOS .................................................................................... 23
3.1.1 Resultados Esperados ............................................................................................... 24
3.2 GERÊNCIA DE REQUISITOS ................................................................................ 25
3.2.1 Resultados Esperados ............................................................................................... 25
4 MODELO DE NEGÓCIO MPS.BR E O NÍVEL G.............................................. 26
4.1 FORMAÇÃO DO GRUPO DE EMPRESAS ............................................................ 27
4.2 PRÉ-DIAGNÓSTICO NA DIGITALDOC ............................................................... 29
4.3 DEFINIÇÃO, INSTITUCIONALIZAÇÃO E AVALIAÇÃO ................................... 31
4.3.1 Definição .................................................................................................................. 32
4.3.2 Institucionalização .................................................................................................... 34
4.3.3 Avaliação ................................................................................................................. 38
4.4 CUSTOS, SUBSÍDIOS E HORAS DESTINADAS AO PROJETO .......................... 39
4.4.1 Cursos ...................................................................................................................... 40
4.4.2 Totais de Subsídios, Custos e Horas Gastas no Projeto.............................................. 41
4.4.3 Ferramentas Utilizadas ............................................................................................. 45
4.5 DURAÇÃO DO PROJETO RUMO AO MPS.BR .................................................... 47
5 CONSIDERAÇÕES FINAIS ................................................................................. 50
5.1 CONCLUSÃO ......................................................................................................... 50
5.2 TRABALHOS FUTUROS/CONTINUAÇÃO DO TRABALHO .............................. 51
REFERÊNCIAS BIBLIOGRÁFICAS .............................................................................. 52
9
1 INTRODUÇÃO
O cenário de mercado cada vez mais competitivo e clientes mais exigentes levam
empresas de software a buscarem qualidade nos processos de desenvolvimento de software,
pois segundo Almeida et al. (2011), “a qualidade tornou-se um dos principais fatores de
destaque no mercado atual”. Ainda de acordo com os mesmos autores “a procura pela excelência
e pela confiabilidade dos produtos gerados é um objetivo a ser alcançado pelas organizações, a
fim de permanecerem atuantes nesse cenário competitivo”.
Em seu artigo sobre Práticas do Modelo MPS em Fábricas de Software, Menolli et al.
(2011) destacam que qualidade em desenvolvimento de software envolve alinhamento total
entre as necessidades do cliente com o que foi criado, compatibilidade entre especificações
aprovadas e o produto construído e produto final com menor quantidade de erros possível.
Informam ainda que para o produto desenvolvido ser de qualidade ele deve ter características
principais como manutenibilidade, reusabilidade, avaliabilidade e implementabilidade.
De acordo com o Guia Geral MPS.BR (SOFTEX..., 2009a) “alcançar competitividade
pela qualidade, para as empresas de software, implica tanto na melhoria da qualidade dos
produtos de software e serviços correlatos, como dos processos de produção e distribuição de
software.”
Portanto, sabendo que “qualidade é fator crítico de sucesso para a indústria de
software” (SOFTEX..., 2009a), a SOFTEX (Associação para a Promoção da Excelência do
Software Brasileiro) juntamente com apoio de outras organizações trouxe às empresas
brasileiras a oportunidade de alcançar qualidade de software através da certificação MPS.BR
(Melhoria do Processo de Software Brasileiro) que, além de se adequar às necessidades de
empresas de pequeno e médio porte quanto a custos, é também compatível com padrões de
qualidade aceitos internacionalmente tendo como pressuposto o aproveitamento de toda
competência existente nos padrões e modelos de melhoria de software já disponíveis
(SOFTEX..., 2009a).
Este projeto pretende apresentar o modelo de qualidade de software MPS.BR nível G,
que é o primeiro nível de maturidade desse modelo, abordando os passos e itens necessários
para que uma empresa possa se beneficiar da melhoria de seus processos de desenvolvimento
de software iniciando pelo nível G. Em suma, pretende-se oferecer uma visão abrangente
sobre o que é necessário para que se possa alcançar este nível no referido modelo.
10
Este trabalho baseou-se na experiência com a implementação do MPS.BR nível G em
uma empresa de desenvolvimento de software, a Anix Sistemas Ltda, cujo nome fantasia é
Digitaldoc, de Medianeira, Paraná.
1.1 OBJETIVO GERAL
Discutir e exemplificar os procedimentos a serem seguidos por empresas que desejem
obter a certificação MPS.BR nível G.
1.2 OBJETIVOS ESPECÍFICOS
Apresentar o modelo MPS.BR, nível G.
Apresentar informações quanto ao que é necessário para implantar o nível G,
mostrando de forma geral como uma organização deve proceder caso deseje a
certificação MPS.BR.
Apresentar os benefícios da melhoria dos processos de software - nível G do
MPS.BR.
1.3 JUSTIFICATIVA
Para empresas de pequeno e médio porte (PMEs – Pequenas e Médias Empresas) o
reconhecimento no mercado é importante para a expansão de seu negócio. Ter uma
certificação em qualidade de software agrega valor ao seu negócio e produto, e também
reconhecimento perante clientes, parceiros e outros interessados. Segundo Kalinowski et al.
(2010) “a melhoria contínua da capacidade de desenvolvimento é fundamental para que
empresas de software prosperem em mercados competitivos”. No entanto, obter uma
certificação como o CMMI exige muito empenho e tempo por parte da empresa, além do
custo ser geralmente inviável a empresas de pequeno e médio porte. Estudos apontaram que
as PMEs, embora reconheçam os benefícios da Engenharia de Software e da melhoria de seus
processos, declaram que a implementação do CMMI é economicamente inviável
(KALINOWSKI et al., 2011).
A qualidade nos processos de software é tão importante quanto a qualidade do produto
gerado, pois quando se tem um processo de qualidade o produto construído tende a ser de
11
qualidade. Neste sentido, a aplicação da engenharia de software torna-se essencial. Muitos dos
problemas encontrados na hora de criar software têm a ver com a Engenharia de Software que
na maioria dos casos é deixada de lado para se concentrar no produto e no cliente. Essa é uma
prática constante em empresas com pouco tempo e experiência no mercado. Pesquisas de
2008 feitas pela SOFTEX indicaram que as empresas só implementavam as boas práticas da
Engenharia de Software quando estas eram exigidas para certificações (SODRÉ,
2011;TRAVASSOS, 2011a).
De acordo com Santos (2011) “acredita-se que o uso de boas práticas de Engenharia
de Software possa melhorar o desempenho das organizações com respeito a custo, prazo,
produtividade, qualidade, satisfação do cliente e retorno do investimento”. Ainda segundo ele,
todos esses itens trazem à empresa aumento de sua vantagem competitiva.
Neste cenário surge o interesse no MPS.BR, que busca aplicar os princípios da
Engenharia de Software melhorando assim os processos de desenvolvimento de software nas
organizações de acordo com cada necessidade específica e de uma forma economicamente
viável para que PMEs também “alcancem os benefícios da melhoria de processos e da
utilização de boas práticas da engenharia de software” (SOFTEX..., 2009; KALINOWSKI et
al., 2011).
O objetivo do MPS.BR, sua estrutura, explicações sobre seus guias – do que se trata e
para que serve cada um, relatos de experiência da implantação, entre outros são assuntos
muito interessantes que não devem deixar de ser publicados. No entanto, pouco se escreve
sobre como proceder quando se deseja iniciar o processo para obtenção da certificação, com
quem obter informações, quais são os custos envolvidos, e talvez até escape fatos como, por
exemplo, de que empresas podem entrar em um grupo de empresas e se beneficiar de
subsídios da SOFTEX e da IOGE (Intuição Organizadora de Grupos de Empresas),
diminuindo ainda mais o custo da certificação.
Ainda surgem dúvidas como por exemplo, por onde iniciar, com quem obter
informações, quais as empresas responsáveis pelo MPS.BR no Brasil, qual o custo da
certificação, quanto tempo leva para implementar o nível G, quais recursos humanos e
materiais/financeiros são necessários à implantação, o MPS.BR é aplicável as necessidades de
determinada empresa, que impacto o MPS.BR terá na forma de trabalho da empresa. No
decorrer deste trabalho serão abordados temas referentes a estes assuntos.
Portanto este trabalho, além de uma descrição do MPS.BR e citar a implantação em
uma empresa de pequeno porte, terá algumas abordagens diferentes das tradicionais para que
uma empresa que queira iniciar o processo de certificação saiba mais detalhes sobre o mesmo.
12
1.4 ESTRUTURA DO TRABALHO
Nas páginas iniciais deste projeto deu-se uma introdução sobre o mesmo, a
justificativa e os objetivos a serem alcançados. O capítulo 2 aborda o modelo MPS.BR além
da motivação, ou seja, algumas informações que mostram que a melhoria dos processos de
software é importante para a empresa. O capítulo 3 fala sobre o nível G e seus resultados
esperados. O capítulo 4 inicia falando um pouco sobre a empresa seguindo com a formação
do grupo de empresas, dando continuidade com o pré-diagnóstico na Digitaldoc. Segue-se
com as fases de definição, institucionalização e avaliação. E ainda nesse capítulo são passadas
informações sobre custos, prazos, subsídios, cursos e ferramentas utilizadas. E por fim no
capítulo 5 estão as considerações finais.
13
2 O MODELO MPS.BR
2.1 MOTIVAÇÃO
Para Sodré (2011), as empresas precisam ter qualidade tanto nos seus produtos quanto
nos seus processos de desenvolvimento de software se quiserem ser mais competitivas tanto
no mercado nacional como internacional, já que um processo de qualidade resulta em produto
de qualidade. Portanto é importante investir cada vez mais na qualidade de seus produtos e
serviços, em busca de competitividade e melhor posicionamento no mercado.
Sodré (2011) ainda acrescenta que, para uma empresa exportar software é
imprescindível ter certificação de qualidade nos processos de desenvolvimento de software
compatível com normas internacionais de qualidade de software.
Alem disso o Standish Group (grupo responsável por pesquisas a respeito do sucesso
em projetos de software) publica periodicamente relatórios sobre sucesso em projetos de
software e os resultados não são animadores. Uma porcentagem muito grande de projetos não
são concluídos conforme planejados e ainda uma porcentagem considerável de projetos são
cancelados (ALMEIDA, 2011).
Esses dados só enfatizam ainda mais a necessidade da engenharia de software e de se
ter processos bem definidos e institucionalizados na empresa (ALMEIDA, 2011).
Dentre os principais problemas que podem causar o fracasso em projetos de software
podem-se citar desvios nos custos e orçamento estipulados, não cumprimento de prazos,
problemas de comunicação, escopo não definido adequadamente e sofrendo mudanças
constantes, recursos humanos insuficientes, riscos não avaliados corretamente, falta de
qualidade nos projetos, insatisfação do cliente, entre outros. A grande maioria dos problemas
não é no código desenvolvido, na linguagem utilizada, na ferramenta utilizada, e sim, na falta
de aplicação da engenharia de software e de se ter processos definidos (ALMEIDA, 2011).
O MPS.BR tem o intuito de minimizar esses e outros problemas encontrados no
desenvolvimento de software aplicando os princípios da Engenharia de Software e
implantando processos de desenvolvimento de software nas empresas de acordo com cada
necessidade específica.
Em pesquisa conduzida pela SOFTEX em 2008 sobre resultados do MPS, desempenho
e satisfação das organizações, Travassos et al. (2011a, p. 6) informam que as empresas só
implementavam as boas práticas da engenharia de software quando estas eram exigidas para
14
certificações. Ele explica que isso indicava uma necessidade de melhorar a capacidade de
desenvolvimento e engenharia de software das organizações brasileiras de maneira que o uso
das boas práticas da engenharia de software pudesse melhorar seu desempenho com respeito a
custo, prazo, produtividade, qualidade, satisfação do cliente e retorno do investimento e,
conseqüentemente, aumentar sua vantagem competitiva.
Já em 2010, a mesma pesquisa mostrou que depois da implantação as empresas
tiveram aumentos significativos na satisfação de seus clientes, produtividade, qualidade,
faturamento e conseqüentemente, a satisfação das mesmas com o modelo MPS aumentou
(TRAVASSOS; KALINOWSKI, 2011).
A pesquisa mostrou que as empresas que adotaram o modelo, agora lidam com
projetos maiores, apresentam mais precisão nas suas estimativas de prazo e se mostraram
mais produtivas se comparado-as com empresas que estão iniciando a implementação.
Também, ficaram visíveis os benefícios da aplicação de Engenharia de Software quanto custo,
prazo, qualidade e produtividade. Portanto, é interessante notar que 92% das empresas se
mostraram parcialmente ou totalmente satisfeitas com o modelo MPS. O modelo realmente
está mudando o cenário das empresas principalmente quanto à produtividade, qualidade e
satisfação dos clientes (TRAVASSOS; KALINOWSKI, 2011).
O MPS.BR representa assim, uma iniciativa da SOFTEX para melhorar a capacidade
de desenvolvimento de software nas organizações Brasileiras. Ele vem sendo utilizado pelas
empresas para estruturar seus processos de software permitindo, principalmente às pequenas e
médias empresas, aprimorar seus processos de software, melhorar a capacidade de produção e
permitir que a qualidade do software, em geral, possa ser garantida e obtida com
embasamento em conhecimentos de engenharia de software (TRAVASSOS; KALINOWSKI,
2011a p. 7).
Processo é definido como um conjunto de atividades inter-relacionadas ou interativas
que transformam entradas em saídas. Serve para conhecer e institucionalizar um fluxo de
trabalho definido papéis e responsabilidades para cada tarefa (ALMEIDA, 2009).
15
2.2 O MODELO MPS.BR
O MPS.BR foi criado em dezembro de 2003. É coordenado pela SOFTEX e conta com
apoio do 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) e Banco
Interamericano de Desenvolvimento (BID). Ele tem por objetivo a melhoria de processo de
software brasileiro (SOFTEX..., 2009a).
O MPS.BR foi adaptado do modelo conhecido internacionalmente como CMMI
(Capability Maturity Model Integration) para a realidade das empresas brasileiras. É, portanto,
voltado para empresas de pequeno e médio porte graças aos empenhos de instituições
brasileiras em criar um modelo de melhoria de processo de software que fosse compatível
com as normas de qualidade de software internacionais e que fosse acessível a empresas que
não tem condições financeiras de obter uma certificação em qualidade de software como o
CMMI. Ele foi criado para que PMEs também tivessem a oportunidade de alcançar os
benefícios na melhoria de processos e da engenharia de software (SOFTEX..., 2009a).
De acordo com Travassos e Kalinowski (2010) a SOFTEX considera 4 níveis de
empresas, citando ainda a porcentagem de empresas que tinham sido avaliadas até maio de
2010. Estão sendo contadas 180 empresas. De acordo com estes dados verifica-se que 72%
são PMEs, ou seja, a maioria:
Microempresas: até 10 funcionários –6% das empresas avaliadas;
Pequenas empresas: entre 11 e 50 funcionários - 45% das empresas avaliadas;
Médias empresas: entre 51 e 100 funcionários - 21% das empresas avaliadas;
Grandes empresas: mais de 100 funcionários - 28% das empresas avaliadas;
A SOFTEX alcançou neste ano de 2011 a marca de mais de 300 empresas avaliadas
no Modelo MPS. A pesquisa iMPS 2010, conduzida pela SOFTEX para avaliar, em vários
aspectos, o desempenho das empresas que adotaram o MPS.BR entre os anos de 2008 e 2010,
apontou que 92% estão parcialmente ou totalmente satisfeitas com o modelo (TRAVASSOS;
KALINOWSKI, 2011).
O MPS.BR é, portanto, um modelo voltado ao aprimoramento do processo de
software. Abrange aplicação dos conceitos de gerência de processos e de melhoria da
qualidade de desenvolvimento e manutenção de software. Ele se baseia também nos conceitos
de maturidade e capacidade de processo para a avaliação e melhoria da produtividade e da
qualidade de produtos de software e serviços correlatos. “É também um modelo para melhoria
16
organizacional, cujo objetivo é promover o aprimoramento contínuo dos processos de
software utilizados pelas organizações” (WORKSHOP..., 2010).
De acordo com o Guia Geral MPS.BR (SOFTEX..., 2009a) a base técnica para a
construção do MPS.BR constitui-se de:
ISO/IEC 12207 – estabelece uma arquitetura comum para ciclo de vida de
processos de software. De acordo com Bergmann(2008), o objetivo dessa ISO é que
“cliente, fornecedor, desenvolvedor, mantenedor, operador, gerentes e
desenvolvedores utilizem a mesma estrutura de processos, com terminologias bem
definidas”.
ISO/IEC 15504 – referência para Avaliação de Processo e Melhoria de Processo.
Avaliação da capacidade dos processos.
CMMI – modelo para melhoria de processos de desenvolvimento de produtos e
serviços.
O MPS.BR ainda conta com as práticas em gerência de projetos baseadas no
PMBOK(Project Management Body of Knowledge), reconhecido mundialmente como um
dos melhores guias de boas práticas em gerenciamento de projetos (SOFTEX..., 2009a).
O PMBOK, publicado pelo Project Management Institute (PMI), se divide em nove
áreas de conhecimentos (PMBOK..., 2008):
Gerenciamento de Integração do Projeto;
Gerenciamento do Escopo do Projeto;
Gerenciamento do Tempo do Projeto;
Gerenciamento de Custos do Projeto;
Gerenciamento da Qualidade do Projeto;
Gerenciamento de Recursos Humanos do Projeto;
Gerenciamento das Comunicações do Projeto;
2.2.1 Estrutura do MPS.BR
A Figura 1 apresenta a estrutura do MPS, sendo que o modelo MPS possui três
componentes: Modelo de Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo
de Negócio (MN-MPS) (SOFTEX..., 2009a).
Modelo de Referência MR-MPS: contém os requisitos que os processos das
unidades organizacionais devem atender para estar em conformidade com o MR-
17
MPS. Ele contém as definições dos níveis de maturidade, processos e atributos do
processo.
Método de Avaliação MA-MPS: método e descrição dos papéis participantes de
uma avaliação de maturidade no MPS.BR.
Modelo de Negócio MN-MPS: descreve regras de negócio para implementação do
MR-MPS pelas Instituições Implementadoras (II), avaliação seguindo o MA-MPS
pelas Instituições Avaliadoras (IA), organização de grupos de empresas pelas
Instituições Organizadoras de Grupos de Empresas (IOGE) para implementação do
MR-MPS e avaliação MA-MPS, certificação de Consultores de Aquisição (CA) e
programas anuais de treinamento do MPS.BR por meio de cursos, provas e
workshops.
De acordo com a SOFTEX (2009) e como ilustrado na Figura 1, cada componente é
descrito por meio de guias e/ou documentos do modelo MPS:
Guia Geral: contém a descrição geral do modelo MPS e detalha o Modelo de
Referência (MR-MPS), seus componentes e as definições comuns necessárias para
seu entendimento e aplicação;
Guia de Aquisição: descreve um processo de aquisição de software e serviços
correlatos. É descrito como forma de apoiar as instituições que queiram adquirir
produtos de software e serviços correlatos apoiando-se no MR-MPS;
Guia de Avaliação: descreve o processo e o método de avaliação MA-MPS, os
requisitos para avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras
(IA);
Guia de Implementação: dez documentos que fornecem orientações para
implementar nas organizações os níveis de maturidade (G ao A) descritos no
Modelo de Referência MR-MPS.
18
Figura 1 – Estrutura do MPS.BR
Fonte: SOFTEX (2009a).
A Figura 2 mostra os níveis de maturidade do MPS.BR que uma organização pode
alcançar. A seguir uma descrição breve de cada nível conforme informa a SOFTEX (2009) no
Guia Geral.
Figura 2 – Níveis de Maturidade do MPS.BR
Fonte: CITS (2010).
19
Nível G – Parcialmente Gerenciado: é o primeiro nível de maturidade a ser
alcançado por uma empresa. São abordados nesse nível a Gerência de Projetos
(GPR) e Gerência de Requisitos (GRE).
Nível F – Gerenciado: além dos processos do nível G inclui também os processos
de Medição (MED), Garantia da Qualidade(GQA), Gerência de Portfólios do
Projeto (GPP), Gerência de Configuração (GCO) e Aquisição (AQU).
Nível E – Parcialmente Definido: inclui todos os processos anteriores mais
Avaliação e Melhoria do Processo Organizacional (AMP), Definição de Processo
Organizacional (DFP), Gerência de Recursos Humanos (GRH) e Gerência de
Reutilização (GRU) e ainda uma evolução da Gerência de Projetos (GPR).
Nível D – Largamente definido: composto pelos processos de maturidade dos
níveis anteriores acrescidos dos processos Desenvolvimento de Requisitos (DRE),
Projeto e Construção do Produto(PCP), Integração do Produto (ITP), Validação
(VAL) e Verificação (VER).
Nível C – Definido: contém os níveis anteriores mais os processos de
Desenvolvimento para Reutilização (DRU), Gerência de Decisões (GDE) e
Gerência de Riscos (GRI).
Nível B – Gerenciado Quantitativamente: esse nível não possui processos
específicos, no entanto o processo de Gerência de Projetos sofre uma alteração,
sendo acrescentados novos resultados a ele.
Nível A – Em Otimização: esse nível não possui processos específicos, mas deve
atender a todos os processos dos níveis anteriores.
Segundo a SOFTEX (2009a) “o alcance de um determinado nível de maturidade se
obtêm quando são atendidos os propósitos e todos os resultados esperados dos respectivos
processos e os resultados esperados dos atributos de processo estabelecidos para aquele
nível”.
Ou seja, a empresa deve atender os atributos do processo (AP), pelo atendimento aos
resultados esperados dos atributos do processo (RAP) e ainda atender os resultados esperados
de cada nível. Por exemplo, para obter certificação nível G, a empresa deve atender os
resultados esperados de Gerência de Projetos (GPR) – 17 resultados, e de Gerência de
Requisitos (GRE) – 5 resultados, além de ter que atender 2 atributos de processo (AP) e 10
resultados esperados dos atributos do processo (RAP). A capacidade do processo de uma
organização a cada nível é medida através dos APs e dos RAPs (SOFTEX..., 2009a).
20
A Figura 3 apresenta todos os níveis do MPS.BR, os atributos de processo e os
resultados dos atributos que cada nível deve atender. Vale lembrar que os níveis são
acumulativos, ou seja, ao passar de um nível para outro, automaticamente os resultados
esperados dos níveis anteriores devem ser também atendidos no próximo nível. Por exemplo,
se a organização passou o nível G e deseja obter o F, ela deve atender todos os itens do nível
F e deve continuar atendendo os APs, RAPs e atributos da Gerência de Projetos e de Gerência
de Requisitos que foram atendidos no nível G (SOFTEX..., 2009a).
21
Figura 3 – Níveis de maturidade do MPS.BR e seus atributos de processo.
Fonte: SOFTEX (2009a)
Ao contrário do CMMI, que possui 5 níveis identificados por números onde os
mesmos devem ser alcançados começando pelo 1, os níveis de maturidade do MPS.BR são 7,
iniciando pelo nível G até o nível A. Ou seja, o primeiro nível a ser obtido é o G.
22
3 MPS.BR NÍVEL G
O nível G do MPS.BR é o primeiro nível de maturidade de processos que uma
empresa deve alcançar. Ao final da implantação deste nível, a empresa deve estar gerenciando
parcialmente seus projetos de desenvolvimento de software. No geral as organizações optam
por iniciar atendendo somente este nível, mas isso não é regra. Uma empresa pode optar por
obter a certificação nível G e F ao mesmo tempo (SOFTEX..., 2009ª; DIGITALDOC...,
2010a).
Neste último caso, deve ser feita uma avaliação da empresa, identificando como estão
os processos da mesma, para poder identificar se esta está apta a atender também o nível F.
Essa avaliação deve ser feita por um consultor MPS.BR autorizado pela SOFTEX. Os
consultores não recomendam iniciar incluindo também o nível F. O motivo é que o nível G
exige muita atenção e empenho pelo fato de se ter mudança na cultura organizacional, o que
causa um impacto interno relativamente grande. Neste cenário, o comprometimento e
colaboração por parte de toda equipe para com as mudanças e melhorias contínuas dos
processos é essencial, sendo um fator chave para o sucesso do projeto rumo ao MPS.BR. Se a
equipe não está comprometida com a melhoria contínua interna o projeto pode ser um
fracasso visto que é a equipe que utilizará os novos processos criados. A resistência à
mudança é um desafio organizacional que precisa ser resolvido (KALINOWSKI et al., 2011).
O nível G exige a aplicação de Gerência de Projetos e Gerência de Requisitos, o que
acaba sendo um dos grandes desafios desse nível para empresas de pequeno porte visto que a
sua grande maioria não trabalha de forma projetizada, não faz as validações de requisitos
mínimas e necessárias junto ao cliente nem tem seu aceite formal e normalmente não estão
acostumadas a gerar documentação do seu produto. O foco é sempre no desenvolvimento do
software solicitado pelo cliente e com prazos geralmente apertados (SOFTEX..., 2009;
KALINOWSKI et al., 2011).
Muitas delas iniciaram seu negócio com um único produto, e na necessidade de entrar
no mercado e de sobrevivência, deixam de lado questões consideradas “morosas” como a
documentação e a aplicação da engenharia de software. No geral, essas empresas até
trabalham com processos de desenvolvimento informais, no entanto, quando surgem
problemas ou quando surge a necessidade de dar prioridade a outro projeto, esses processos
são abandonados. Por isso encontra-se dificuldade na implantação de processos e do nível G
(KALINOWSKI et al., 2011).
23
Na sequência, a descrição dos processos de Gerência de Projetos (GPR), de Gerência
de Requisitos(GRE) e dos resultados esperados desses dois processos, além dos APs e RAPs
que devem ser atendidos no nível G, conforme SOFTEX (2009).
No quadro 1 estão descritos os Atributos de Processo bem, como seus Resultados
Esperados.
APs e RAPs
AP 1.1 - O processo é executado.
RAP 1 O processo atinge seus resultados definidos.
AP 2.1 - O processo é gerenciado.
RAP 2 Existe uma política organizacional estabelecida e mantida para o processo.
RAP 3 A execução do processo é planejada
RAP 4 A execução do processo é monitorada e ajustes são realizados.
RAP 5 As informações e os recursos necessários para a execução do processo são
identificados e disponibilizados.
RAP 6 As responsabilidades e a autoridade para executar o processo são definidas,
atribuídas e comunicadas.
RAP 7 As pessoas que executam o processo são competentes em termos de
formação, treinamento e experiência.
RAP 8 A comunicação entre as partes interessadas no processo é gerenciada de
forma a garantir o seu envolvimento
RAP 9 Os resultados do processo são revistos com a gerência de alto nível para
fornecer visibilidade sobre a sua situação na organização.
RAP 10 O processo planejado para o projeto é executado.
Quadro 1 – Atributos de Processo e Resultado dos Atributos de Processo
Fonte: SOFTEX (2009)
3.1 GERÊNCIA DE PROJETOS
Conforme explicado no Guia Geral MPS.BR (SOFTEX, 2009a), “o propósito do
processo Gerência de Projetos é estabelecer e manter planos que definem as
atividades, recursos e responsabilidades do projeto, bem como prover informações
sobre o andamento do projeto que permitam a realização de correções quando
houver desvios significativos no desempenho do projeto. O propósito deste processo
evolui à medida que a organização cresce em maturidade. Assim, a partir do nível E,
24
alguns resultados evoluem e outros são incorporados, de forma que a gerência de
projetos passe a ser realizada com base no processo definido para o projeto e nos
planos integrados. No nível B, a gerência de projetos passa a ter um enfoque
quantitativo, refletindo a alta maturidade que se espera da organização. Novamente,
alguns resultados evoluem e outros são incorporados”.
3.1.1 Resultados Esperados
Cada nível do MPS.BR tem seus resultados esperados que devem ser atendidos para se
obter a certificação para o nível. Abaixo estão descritos os 17 resultados da área de processo
Gerência de Projetos para o nível G.
GPR1 - O escopo do trabalho para o projeto é definido.
GPR2 - As tarefas e os produtos de trabalho do projeto são dimensionados utilizando
métodos apropriados.
GPR3 - O modelo e as fases do ciclo de vida do projeto são definidos.
GPR4 - O esforço e o custo para a execução das tarefas e dos produtos de trabalho são
estimados com base em dados históricos ou referências técnicas.
GPR5 - O orçamento e o cronograma do projeto, incluindo a definição de marcos e
pontos de controle, são estabelecidos e mantidos.
GPR6 - Os riscos do projeto são identificados e o seu impacto, probabilidade de
ocorrência e prioridade de tratamento são determinados e documentados.
GPR7 - Os recursos humanos para o projeto são planejados considerando o perfil e o
conhecimento necessários para executá-lo.
GPR8 - Os recursos e o ambiente de trabalho necessários para executar o projeto são
planejados.
GPR9 - Os dados relevantes do projeto são identificados e planejados quanto à forma
de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los,
incluindo, se pertinente, questões de privacidade e segurança.
GPR10 - Um plano geral para a execução do projeto é estabelecido com a integração
de planos específicos.
GPR11 - A viabilidade de atingir as metas do projeto, considerando as restrições e os
recursos disponíveis, é avaliada. Se necessário, ajustes são realizados.
GPR12 - O Plano do Projeto é revisado com todos os interessados e o compromisso
com ele é obtido.
25
GPR13 - O projeto é gerenciado utilizando-se o Plano do Projeto e outros planos que
afetam o projeto e os resultados são documentados.
GPR14 - O envolvimento das partes interessadas no projeto é gerenciado.
GPR15 - Revisões são realizadas em marcos do projeto e conforme estabelecido no
planejamento.
GPR16 - Registros de problemas identificados e o resultado da análise de questões
pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes
interessadas.
GPR17 - Ações para corrigir desvios em relação ao planejado e para prevenir a
repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a
sua conclusão.
3.2 GERÊNCIA DE REQUISITOS
Conforme descrito no Guia Geral MPS.BR (SOFTEX..., 2009a) “o propósito do
processo Gerência de Requisitos é gerenciar os requisitos do produto e dos componentes do
produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os
produtos de trabalho do projeto”.
3.2.1 Resultados Esperados
Os resultados esperados da área de processo Gerência de Requisitos, para o nível G
são:
GRE1 - Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de
requisitos, utilizando critérios objetivos.
GRE2 - O comprometimento da equipe técnica com os requisitos aprovados é obtido.
GRE3 - A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é
estabelecida e mantida.
GRE4 - Revisões em planos e produtos de trabalho do projeto são realizadas visando a
identificar e corrigir inconsistências em relação aos requisitos.
GRE5 - Mudanças nos requisitos são gerenciadas ao longo do projeto.
26
4 MODELO DE NEGÓCIO MPS.BR E O NÍVEL G
Muitas das informações apresentadas neste tópico serão baseadas em um estudo de
caso da implantação do nível G do MPS.BR na Anix Sistemas (nome fantasia Digitaldoc),
empresa de pequeno porte do oeste do Paraná. A Digitaldoc já está a mais de 5 anos no
mercado, trabalhando com desenvolvimento de software. Com seus softwares principais – o
Digitaldoc e o Birô de Digitalização – a empresa oferece serviços de Gerenciamento
Eletrônico de Documentos (GED), ECM (Enterprise Content Management) e digitalização de
documentos.
A empresa veio crescendo a cada ano, tendo aumento de clientes, se destacando no
mercado. Neste período sentiu-se a necessidade de melhorias internas, na questão de
qualidade em desenvolvimento de software e também na questão de destaque no mercado. A
empresa precisava melhorar seus processos internos, sair da forma artesanal de
desenvolvimento para uma forma definida e reconhecida, que gerasse resultados positivos,
diminuísse o retrabalho, aumentasse a produtividade e o retorno de investimento. A
Digitaldoc já se mostrou disposta a melhorias ao implantar o Scrum (metodologia de
desenvolvimento ágil) nos seus processos de desenvolvimento de software e para ajudar nessa
etapa, implantou um software para gerenciamento das informações (controle de requisições)
geradas dessa nova forma de trabalho. O Scrum é um processo ágil que busca entregar
software de valor agregado ao cliente se baseando na filosofia ágil e utilizando práticas
iterativas e incrementais. Apesar de a empresa não aplicar o Scrum na sua totalidade, os
resultados já se mostram muito eficientes, tendo mais organização dos itens a serem
desenvolvidos, diminuição de retrabalho, etc. Ainda com relação ao Scrum, quando se optou
por iniciar o MPS.BR uma das questões levantadas foi se o MPS afetaria a utilização dessa
forma de trabalho ágil juntamente com a ferramenta de controle de requisições. Essa dúvida
foi sanada logo de início com a consultora - o MPS não afetou essa forma de trabalho,
somente a empresa deveria adequar o Scrum também a processos e a nova forma de trabalho
(MANIFESTO ÁGIL, 2011).
Após implantação do Scrum, a empresa ainda sentia a necessidade de melhoria de seus
processos de software, um processo de produção organizado e eficiente que trouxesse
benefícios como a redução dos custos de produção, aumento da qualidade, produtividade e
satisfação do cliente além do destaque no mercado.
27
Gerência de projetos e de requisitos era praticamente inexistente, o que dificultava o
trabalho. Pelo fato da empresa trabalhar na melhoria do produto ou customizações, não se
tinha uma visão da necessidade e talvez da possibilidade de trabalhar projetizado. Por causa
disso, não havia um – melhoria do produto, customização ou nova funcionalidade solicitada
pelo cliente. O produto não tinha documentação, havia apenas um início de documentação de
requisitos, entretanto sem formalidades, ou seja, o cliente não aprovava formalmente os
requisitos e, nessas circunstâncias, também não era possível controlar mudanças nos
requisitos que poderiam causar aumentos de prazos, custos, entre outros (DIGITALDOC...,
2010a).
Após implantação do Scrum, um acompanhamento das requisições (ou requisitos) que
estavam sendo desenvolvidas era feito pelo Sistema de Controle de Requisições, onde é
possível acompanhar o que estava sendo feito, por quem e ainda informações do Status (Em
desenvolvimento, Em testes, Homologação, Atualização). No entanto esse gerenciamento por
si só não garante um gerenciamento real de um projeto, não chega nem perto das práticas de
gerência de projetos reconhecidas, como por exemplo, as práticas descritas no PMBOK
(Project Management Body Of Knowledge), considerado um dos melhores guias de boas
práticas em gerenciamento de projetos (PMBOK..., 2008).
Estes e outros fatores levaram a empresa a se interessar pelo MPS.BR quando o
mesmo foi apresentado no PraTIQ (Programa de Análise de Qualidade em TI), que será
considerado no próximo tópico.
4.1 FORMAÇÃO DO GRUPO DE EMPRESAS
De acordo com o Modelo de Negócio para Melhoria de Processo de Software (MN-
MPS), uma empresa pode optar por se juntar a um grupo de empresas para iniciar o processo
de certificação, ou pode caminhar sozinha rumo ao MPS.BR sem os subsídios destinados a
grupos de empresas. Para empresas que desejam compartilhar esforços e custos na
implementação e avaliação MPS, existe o Modelo de Negócio Cooperado (MNC). Para esse
modelo “o primeiro passo é a constituição de grupo de empresas comprometidas com a
implementação e a avaliação”. Esse é o papel da IOGE (Instituição Organizadora de Grupos
de Empresas), que após a formação do grupo, assina um convênio com a SOFTEX para cada
grupo de empresas. Em seguida a coordenação do grupo de empresas irá negociar e assinar
28
um contrato com uma Instituição Implementadora(II) credenciada ao SOFTEX. E ainda,
depois de as empresas já terem implantado o MPS e estiverem aptas a avaliação, a IOGE é
responsável por negociar e assinar contrato com uma ou mais Instituições Avaliadoras (IA)
credenciadas ao SOFTEX. Vale lembrar que cada empresa que participa do grupo de
empresas deve individualmente, assinar um contrato com a II para receber os serviços de
consultoria (SOFTEX..., 2011).
O MNE (Modelo de Negócio Específico) é o modelo destinado a empresas que
desejam exclusividade na implementação do modelo MPS. Neste caso, cada empresa negocia
e assina um contrato com uma Instituição Implementadora (II) credenciada ao SOFTEX.
Quando chegar a época da avaliação, após a implementação, a empresa deve assinar outro
contrato específico com a instituição que fará a avaliação – uma IA credenciada também. É
interessante frisar que as IIs, IAs e as IOGEs devidamente credenciadas estão listadas no site
da própria SOFTEX, www.softex.br, na área MPS.BR. A partir dessa lista uma empresa pode
escolher as instituições com as quais deseja fechar contrato (SOFTEX..., 2011).
Em meados de Abril de 2010, o SEBRAE (Serviço Brasileiro de Apoio as Micro e
Pequenas Empresas do Brasil) juntamente com o CITS (Centro Internacional de Tecnologia
de Software) apresentaram a algumas empresas do oeste do Paraná o programa MPS.BR
através do PraTIQ (Programa de Análise de Qualidade em TI). Este foi o primeiro contato da
Digitaldoc com o modelo. A Digitaldoc viu no MPS mais uma oportunidade de melhorar seus
processos internos, aplicando práticas de engenharia de software, mais precisamente gerência
de projetos e de requisitos, práticas essas que não existiam ou eram muito pouco aplicadas na
empresa.
As empresas do oeste do Paraná que fazem parte do APL Iguassu-IT (Arranjo
Produtivo Local de TI do Oeste) tiveram a oportunidade de participar do PraTIQ (Programa
de Análise de Qualidade em TI). Criado em parceria pelo Centro Internacional de Tecnologia
de Software (CITS) e o Sebrae/PR, o PraTIQ teve como objetivo “fornecer subsídios às
empresas do segmento que desejam melhorar a qualidade dos processos ou almejam a
certificação no Programa de Melhoria de Processo do Software Brasileiro (MPS.BR)”
(AGÊNCIA..., 2011).
Além de o curso abordar temas como o gerenciamento de projetos e de requisitos, no
PraTIQ enfatizou-se a importância da qualidade do produto para a ascensão no negócio, mas o
foco principal foi incentivar a competência e a busca incessante pela melhoria de processos
pois os resultados seriam melhores produtos e serviços (AGÊNCIA..., 2011).
29
Através do programa SEBRAETEC (Serviços em Inovação e Tecnologia), o SEBRAE
possibilita as PMEs “acessar os conhecimentos de Inovação Tecnológica, por meio de
subsídios aos custos dos serviços de consultoria e capacitação tecnológica”. Ou seja, através
deste programa, o SEBRAE subsidiou alguns custos de consultoria da certificação MPS.BR.
Ainda, com a formação do grupo, os custos de consultorias, viagens e orientações individuais
são divididos entre as empresas, diminuindo assim os custos para todas as empresas do grupo.
Mais informações sobre custos e subsídios estão descritas no tópico 4.4 deste trabalho
(AGÊNCIA..., 2011; SERVIÇO..., 2011a).
Neste processo de certificação das empresas do grupo que se formou, o CITS foi a
IOGE (Instituição Organizadora de Grupos de Empresas), ou seja, a instituição que organizou
o grupo de empresas tendo como apoio o SEBRAE e o APL Iguassu-IT. O CITS também é a
II (Instituição Implementadora), ou seja, a instituição que acompanha as empresas no
processo de implantação do modelo MPS, fornecendo consultores especializados para auxiliar
no alcance desse objetivo.
O início deu-se, portanto, através do PraTIQ, ou seja, durante o curso, o modelo MPS
foi apresentado às empresas. Vale lembrar que um dos objetivos do PraTIQ era “despertar o
interesse de pequenas e médias empresas, para importância da implantação de melhoria de
processos de software, uma vez que o mercado está cada vez mais exigente no que diz
respeito à qualidade e complexidade dos produtos” (SERVIÇO..., 2011). O próximo passo do
projeto será considerado na seção 4.2.
4.2 PRÉ-DIAGNÓSTICO NA DIGITALDOC
Na estrutura de trabalho do CITS, o próximo passo após o PraTIQ é fazer um pré-
diagnóstico da empresa. O mesmo foi feito nas empresas participantes do PraTIQ. O
diagnóstico tem duração de 16 horas, ou seja, 2 dias e é realizado na própria empresa. O
objetivo é avaliar a situação do empreendimento em relação aos modelos já existentes. No
final tem-se uma visão geral do status atual do negócio, o que facilita a tomada de decisão
sobre a implementação de novas técnicas ou modelos de qualidade (AGÊNCIA..., 2011).
Também tem o objetivo de identificar as lacunas dos processos e produtos de trabalho
da empresa em relação ao modelo MPS. Essas lacunas são avaliadas sob as perspectivas de
definição e institucionalização, ou seja, se existem processos que definem as atividades
executadas na empresa; e se as atividades previstas no processo são executadas ou se existem
30
atividades realizadas que não estão definidas nos processos. A descoberta destas lacunas
permite a visualização do cenário e da maturidade da empresa atualmente. Esta análise serve
de base para elaborar o planejamento do projeto de melhoria de processos na empresa
(DIGITALDOC..., 2010a).
O pré-diagnóstico é feito pela II (Instituição Implementadora), que neste caso foi o
próprio CITS. Nesta época a Digitaldoc contava com menos de 15 colaboradores incluindo os
sócios. Foram avaliados os 22 resultados esperados do MPS em 2 áreas de processos (GPR e
GRE) e 10 resultados de atributos de processo para cada uma das 2 áreas de processo. O
modelo utilizado foi MPS.BR versão 2009 que, portanto, é utilizado neste trabalho. A
avaliação é feita por meio de entrevistas com a equipe de projetos, documentação de projetos
e processos e apresentações. Algumas das práticas solicitadas pelo MPS eram executadas em
partes na Digitaldoc, no entanto a maioria das práticas era inexistente. No caso específico da
Digitaldoc, dentre algumas coisas que o diagnóstico identificou pode-se citar alguns pontos
fortes e fracos (DIGITALDOC..., 2010a):
O escopo não estava sendo definido adequadamente.
Não existia técnica de estimativa de complexidade e de esforço documentada e em
execução.
Não existiam análise e definição de ciclo de vida de projeto.
Não se fazia estimativas de custos, nem planejamento de riscos, de prazos, de
recursos humanos e materiais, de comunicação e gestão de dados.
Não existia um plano de projeto que integrasse todos os planos específicos do
projeto.
Não era prática o comprometimento com o plano de projeto.
Em nenhum momento era avaliada a viabilidade do projeto a partir de critérios.
Não havia gerenciamento do projeto como um todo, nem registro e gerenciamento
dos problemas.
Não existiam critérios interno de aceitação dos requisitos descritos.
Não estavam sendo utilizados critérios para aprovação de requisitos por parte do
fornecedor de requisitos.
Equipe técnica não se comprometia formalmente com os requisitos.
Não existia estratégia de rastreabilidade de requisitos.
Não existiam atividades de garantia de consistência entre requisitos e artefatos que
tratam de requisitos.
31
Não existia um controle formal de mudanças em requisitos.
Pontos fortes: existia ciclo de vida da requisição em execução na empresa; a
empresa estava estruturando a divisão de responsabilidades e perfis dos
colaboradores; uso de parte do método Scrum; era realizadas revisões de aspectos
técnicos periodicamente; a empresa realizava o entendimento dos requisitos junto
ao fornecedor.
Nessa etapa do MPS a Digitaldoc já estava iniciando a elaboração/definição de
procedimentos e processos, sendo que isso foi contado como ponto forte. No entanto ainda
faltava definir uma política organizacional para processo, planejar e monitorar processos,
definir, atribuir e comunicar as responsabilidades para executar o processo, entre outros
relacionados.
A partir dessa verificação a consultora deu recomendações em todos os pontos fracos e
a partir daí inicia-se a fase de Definição, que será descrita no próximo capítulo (4.3).
Vale lembrar que essa é a estrutura de trabalho do CITS. Não há como ter certeza que
outras empresas prestadoras de serviço para o SOFTEX trabalhem da mesma forma
(DIGITALDOC..., 2010).
Nesta etapa do projeto a Digitaldoc já havia fechado contrato com a II para serviços de
consultoria.
4.3 DEFINIÇÃO, INSTITUCIONALIZAÇÃO E AVALIAÇÃO
A busca pela certificação na Digitaldoc foi tratada como um projeto, intitulado Projeto Rumo ao MPS.BR e como mostra a Figura 4 ele constitui-se das seguintes fases:
Formalização;
Planejamento;
Definição;
Institucionalização;
Avaliação Inicial;
Avaliação Final;
Encerramento;
32
Figura 4 – Fases do Projeto Rumo ao MPS.BR Fonte: CITS (2010).
As duas primeiras fases (Formalização de Planejamento) constituem etapas de
assinatura de contratos com o CITS (Instituição Implementadora - II) e a SOFTEX e
planejamento do projeto Rumo ao MPS.BR por parte da empresa II. A II planeja as etapas do
projeto, datas de consultorias, de workshops e repassa para a empresa (Digitaldoc).
4.3.1 Definição
A fase de definição tem por objetivo definir todos os processos referentes ao nível G
de maturidade o que, de acordo com o CITS (2010), inclui as seguintes atividades:
Planejamento individual de cada empresa (definição de equipe interna,
cronograma e planejamento do projeto) – responsabilidade da Digitaldoc:
neste ponto a empresa definiu a sua equipe do projeto Rumo ao MPS.BR com 3
participantes e delegou responsabilidades específicas a cada membro.
Recurso 1 – Analista de Processos (AP): responsável pela maior parte das
atividades do projeto, o que inclui definição de ferramentas, criação de artefatos e
do processo, criação e execução de treinamentos, participação em consultorias,
workshops e foi a pessoa definida para participar do curso C1 de MPS.BR (item
5.4.1) para a participação efetiva como representante da empresa nas avaliações.
Recurso 2 – Diretor/Analista de Processos Líder: líder da equipe e diretor da
empresa. Participação nas definições de ferramentas, processo, equipe, definições
em geral. Responsável pelo acompanhamento das atividades dos APs. Participação
em consultorias, alinhamentos de atividades, dúvidas, entre outros.
Recurso 3 – Analista de Processos: membro da equipe de desenvolvimento e
teste. Teve participação em consultorias e em definições para que as mudanças
fossem alinhadas de uma forma mais aceitável a equipe técnica, para que as
mudanças não impactassem tanto na forma de trabalho atual.
Definição/ Criação dos ativos de processos (Políticas, Processos,
Procedimentos, Templates, Checklists, Ferramentas) – responsabilidade da
33
Digitaldoc: esta é uma etapa bem demorada pelo fato de ter que estudar a fundo o
modelo (neste caso o nível G) para identificar como atender cada requisito, decidir
quais ferramentas serão utilizadas para apoiar o processo, identificar e criar todos
os artefatos/documentos, adequar algumas coisas às ferramentas selecionadas.
Reuniões para consultoria e direcionamento nos ativos de processos criados –
responsabilidade do CITS (consultora): estão planejadas consultorias para todos
os meses após a realização do pré-diagnóstico. No total, no caso da Digitaldoc
foram planejadas 10 consultorias. Nestas reuniões a consultora (ou o consultor)
avalia como está o andamento das atividades na empresa, verifica o que está sendo
feito, se os artefatos estão sendo criados da forma correta, tira dúvidas, informa
quais são os próximos passos, se as atividades estão atrasadas ou no prazo correto.
Workshops de Capacitação e alinhamento do grupo de empresas – CITS e
Digitaldoc (descrito no item 5.4.1 deste trabalho);
Reuniões de Análise Crítica – CITS e Digitaldoc: reuniões para identificar se a
empresa está com algum problema que possa atrapalhar o alcance do próximo passo
ou até mesmo do objetivo final – a certificação. Nem sempre estas reuniões são
necessárias pois a empresa pode estar em um nível bom, executando as atividades
adequadamente.
Validação conceitual nos ativos criados – CITS: consultor avalia toda a definição
feita pela empresa para identificar possíveis ajustes antes de emitir o laudo de 50%,
que significa que a empresa cumpriu a fase de Definição e está pronta para ir para a
fase de Planejamento.
Ajustes necessários – Digitaldoc: se necessário a empresa faz os ajustes para a
obtenção do laudo de 50%.
Criação dos treinamentos nos novos processos definidos – Digitaldoc: neste
ponto a empresa deve criar os treinamentos que serão executados para que a equipe
conheça o processo, os artefatos, ferramentas, termos utilizados, seus papéis e
perfis no processo, as atividades de sua responsabilidade de acordo com cada perfil.
O laudo de 50% foi alcançado em abril de 2011.
34
4.3.2 Institucionalização
Após a validação da consultora e de vários ajustes a empresa obteve o laudo de 50%,
que significa que a empresa passou da fase de Definição para a fase de Institucionalização.
A fase de Institucionalização se resume em “prover a utilização dos ativos de processo
criados e realizar ajustes necessários”. Ou seja, o processo definido será agora utilizado em
projetos de software, as pessoas envolvidas serão treinadas para executá-lo da forma definida.
O processo e os artefatos devem agora estar disponíveis a toda equipe (CITS..., 2010).
A fase de institucionalização tem as seguintes atividades principais segundo o CITS
(2010):
Execução dos treinamentos nos ativos de processos criados – Digitaldoc: a
primeira coisa feita na Digitaldoc nesta fase foi executar os treinamentos para os
colaboradores que executarão o processo. Foram definidos os perfis Gerente de
Projetos (GP), Analista de Sistemas (AS), Analista de Negócio (AN), Analista de
Projetos (AP), Desenvolvedor (DS), Analista de Testes (AT), Fornecedor de
Requisitos (FR), Cliente (CL), Diretor (DR) e também Analista de Processos
(APC). Com exceção do CL e FR, todos os outros perfis receberam treinamentos no
processo. Alguns treinamentos foram focados no perfil e outros eram treinamentos
para a equipe no geral.
Vale a pena ressaltar no caso dos treinamentos que, para que as coisas
“funcionem”, ou seja, para que o processo seja executado da forma correta, é
importante o comprometimento, motivação e participação de toda equipe, afinal, os
responsáveis pelo sucesso do projeto, desta etapa em diante, é a equipe que utilizará
o software.
Utilização dos ativos de processos em projeto piloto selecionado – Digitaldoc: a
partir da execução do projeto piloto (projeto para teste do processo), foram
identificadas algumas melhorias/lições aprendidas que simplificariam o trabalho ou
que se adequavam melhor à forma de trabalho da empresa.
Reuniões para consultoria e direcionamento para a fase de institucionalização
– CITS: consultorias para acompanhamento e direcionamento quanto às atividades
realizadas também foram feitas nesta fase.
Reuniões de Análise Crítica – CITS;
35
Coleta de oportunidades de melhoria oriundas da utilização do piloto –
Digitaldoc: a partir da execução do projeto piloto (projeto para teste do processo),
foram identificadas algumas melhorias/lições aprendidas que simplificariam o
trabalho ou que se adequava melhor à forma de trabalho da empresa. Nesta etapa
muitas lições aprendidas são coletadas, algumas com impacto maior, por exemplo,
no caso da Digitaldoc foi identificado que alguns requisitos não se encaixavam na
técnica de estimativas de tamanho criada pela empresa. Ações foram tomadas com
relação a esse problema, e no tempo certo. Por isso é preciso a execução de um
projeto piloto.
Implementação das melhorias coletadas – Digitaldoc: os ajustes identificados
com a utilização do processo no projeto piloto foram executados. Ou seja, o
processo e alguns artefatos foram alterados para que algumas inconsistências
fossem resolvidas e para que alguns trabalhos não se tornassem morosos demais.
Ao final desta fase de Institucionalização é feita uma simulação de avaliação, ou seja,
é feito uma avaliação da mesma forma que a avaliação final (item 5.3.3 deste trabalho), no
entanto esta serve para identificar problemas que possam estar ocorrendo e que talvez causem
inconsistências na avaliação final e até o não alcance do objetivo que é a certificação.
A simulação de avaliação é feita por outro consultor do CITS juntamente com a
consultora oficial. Nesta simulação a equipe é entrevistada, os artefatos são avaliados, o
projeto de software executado a partir do processo é avaliado como um todo. A empresa deve
ter executado o processo e gerado evidências disso. Essas evidências são a documentação
gerada e as entrevistas com a equipe.
Neste momento é comum os consultores encontrarem pontos fracos e também pontos
críticos que devem ser resolvidos para a obtenção do laudo de 100% (pronta para avaliação).
Evidências de pontos fracos ou críticos não impedem a obtenção do laudo. Depende sempre
da avaliação dos consultores.
A experiência da Digitaldoc no caso da simulação de avaliação é um caso raro
segundo as consultoras. A empresa obteve um resultado excelente, normalmente não
alcançado pelas empresas: não foi identificado nenhum ponto fraco em todos os itens
avaliados. Apenas foram identificadas recomendações em 3 aspectos.
Segundo as consultoras que fizeram a simulação de avaliação, ficou visível o
comprometimento da equipe com a melhoria contínua na empresa e que um resultado tão bom
na simulação de avaliação é muito difícil conseguir por causa da dificuldade que se tem no
nível G por ser o primeiro nível de maturidade a ser alcançado e, neste momento o impacto
36
das mudanças organizacionais pode ser grande, sendo comum observar certa resistência por
parte dos colaboradores. As consultoras elogiaram muito tanto a equipe como a diretoria pelo
empenho e colaboração. Também comentaram que a Digitaldoc com certeza pode ser um caso
para referência por causa do seu bom desempenho, adaptação, comprometimento e também
pelo resultado excelente alcançado. Também enfatizaram a preocupação da equipe “em
manter metodologia de desenvolvimento de software de acordo com as perspectivas e
necessidades de qualidade de negócio da organização” (KALINOWSKI et al., 2011, p. 4;
DIGITALDOC..., 2011a).
Foram avaliados resultados esperados do GPR e GRE quanto a se os mesmos estavam
Definidos e Institucionalizados. Conforme legenda da Figura 5, os itens são classificados em
Não Definido (ND), Parcialmente Definido (PD), Largamente Definido (LD), Totalmente
Definido (TD) para quesitos de Definição. A legenda para quesitos de Institucionalização
altera apenas de Definido para Implantado – Não Implementado (NI), Parcialmente
Implementado (PI), Largamente Implementado (LI), Totalmente Implementado (TI).
Figura 5 – Legenda de Avaliação
Fonte: Digitaldoc (2011).
Na questão de definição (etapa de Definição), tanto para resultados esperados de GRE
e GPR como para os 10 resultados de Atributos de Processo para cada área de processo (GPR
e GRE), a avaliação constatou Totalmente Definido (TD), conforme Figura 6.
37
Figura 6 – Percentual de Aderência – Definição
Fonte: Digitaldoc (2011).
Em avaliação para identificar se o processo foi institucionalizado (etapa de
Institucionalização), ou seja, se o processo e outros itens que foram definidos estavam
realmente sendo utilizados em projetos, a avaliação constatou Totalmente Implementado (TI),
conforme Figura 7.
Figura 7 – Percentual de Aderência – Institucionalização
Fonte: Digitaldoc (2011).
38
A partir das Figuras 6 e 7 é possível verificar que todos os 24 resultados esperados do
MPS.BR (entre GPR e GRE) e 10 resultado de atributos de processo do MPS.BR para cada
uma das 2 áreas de processo (GPR e GRE) – para o nível G – foram atendidos
completamente.
As avaliações, inicial e final, ocorrem da mesma forma que a simulação de avaliação,
com geração de gráficos de percentual de aderência e identificação de pontos fortes e fracos.
A obtenção do laudo de 100% significa que a empresa está pronta para avaliação
(inicial). A Digitaldoc obteve o laudo no mês de outubro de 2011 após simulação de avaliação
que ocorreu em 15 de setembro de 2011(DIGITALDOC..., 2011a).
4.3.3 Avaliação
Após a obtenção do laudo de 100% a empresa esta apta a ir para avaliação. Nesta etapa
são feitas duas avaliações: a Avaliação Inicial que identifica se a empresa está apta a fazer
uma avaliação formal e concludente, e a Avaliação Final que é a avaliação formal na qual é
definida através das evidências, se a empresa alcança a certificação ou não.
A empresa deve agora assinar um contrato com a Instituição Avaliadora (IA) para as
avaliações. As Ias credenciadas estão disponíveis para consulta no site da Softex.
Segundo o CITS (2010) as seguintes atividades são executadas na avaliação inicial e
final:
Planejar avaliações – Digitaldoc: inclui planejamento interno para avaliação,
treinamentos, organização da equipe, contratação da Instituição Avaliadora (IA)
entre outros. Neste caso a IOGE é responsável pelo levantamento das possíveis IAs
para contratação.
Gerar planilha com evidências – Digitaldoc: esta planilha deve ser preenchida
pela empresa com evidências para os itens do nível G – 19 GPRs, 5 GREs, 2 ATs,
10 RAPs. É a partir desta planilha que a avaliação será conduzida.
Executar Avaliação Inicial- Fornecedor Externo: realização da avaliação inicial
onde, baseado nas evidências da planilha, documentação gerada e em entrevistas
com toda equipe, a empresa é avaliada para identificar se está realmente usando o
processo e da forma que foi definido. Para esta avaliação é contratado uma empresa
a parte, que não seja a II.
39
Orientações sobre as lacunas identificadas na Avaliação Inicial – CITS: se
algumas inconsistências forem encontradas na avaliação inicial, a mesmas são
repassadas a empresa e o consultor orienta para correção das mesmas e fazer os
últimos ajustes.
Correções provenientes da Avaliação Inicial – Digitaldoc: as correções/ajustes
solicitadas pelo consultor são feitas pela empresa para que não haja inconsistências
na avaliação final.
Planejar Avaliação Final- Digitaldoc: novamente a empresa deve planejar a
avaliação final. Após avaliação inicial, a empresa tem normalmente um mês para se
preparar para avaliação final. Para esta, é necessário ter no mínimo 1 projeto
concluído e outro em andamento com evidências relativamente suficientes para ser
avaliado.
Executar Avaliação Final- Fornecedor Externo: instituição Avaliadora
contratada para avaliação executa-a durante um período de 8 horas e nesse
momento a empresa recebe ou não a certificação, de acordo com as evidências
apresentadas e entrevistas feitas com equipe de software – GPs, ASs, DSs, DRs,
ATs, ANs e APs.
4.4 CUSTOS, SUBSÍDIOS E HORAS DESTINADAS AO PROJETO
Os tópicos 4.4.1, 4.4.2, 4.4.3 e 4.4.4 e 4.5 terão explicações mais detalhadas quanto à
duração do projeto Rumo ao MPS.BR, custos, subsídios, ferramentas utilizadas e horas
destinadas ao projeto. Todos estes dados estão resumidos na Tabela 1:
Tabela 1 – Dados gerais do projeto MPS.BR
(continua)
DADOS GERAIS DO PROJETO RUMO AO MPS.BR
Subsídios SOFTEX: 40%
CITS: 22,7%
SEBRAE: 40%
Custos para a Digitaldoc 66,6% do custo da certificação (aproximado)
40
(conclusão)
Horas destinadas ao projeto 4.200* horas (aproximado)
Duração do projeto 17 meses
Cursos realizados em prol do projeto Curso C1 de MPS.BR
Workshop MPS.BR
Gerência de Projetos
Equipe montada para o projeto 3 pessoas. 1 em tempo integral Fonte: Digitaldoc (2011)
Com relação às horas destinadas ao projeto, informadas na Tabela 1, em alguns
aspectos não são considerados o esforço de cada colaborador e sim a duração unitária. Se for
considerado esforço de cada um para cada atividade somar-se-iam em torno de 4.500 horas,
uma base de 12 horas destinadas ao projeto por dia, 22 dias do mês, nos 17 meses de projeto.
Com relação aos custos do da Digitaldoc, a porcentagem foi baseado no custo da
certificação disponibilizado pela SOFTEX. Mais detalhes no capítulo 4.4.2.
4.4.1 Cursos
Uma empresa que inicia o processo de implantação do MPS necessita de treinamento
para executar as atividades relacionadas ao mesmo. Faz parte da estrutura do projeto MPS a
realização de cursos e workshops com o objetivo de situar a empresa, fornecer
esclarecimentos, sanar dúvidas, entre outros relacionados ao modelo. Alguns cursos são
obrigatórios, e outros sugeridos (SOFTEX..., 2009a). Segue-se:
Curso C1 de MPS.BR é um curso obrigatório para implementadores do MPS.BR. É
obrigatório que no mínimo uma pessoa da empresa faça o curso. Essa é a pessoa que estará
ativa nas avaliações inicial e final. De acordo com o Método de Avaliação essa pessoa
compõe a equipe de avaliação, é o representante interno que “contribuem com seu
conhecimento da empresa para que toda equipe melhor a empresa, seus processos e os
artefatos apresentados”. Vale lembrar que mais de uma pessoa pode fazer este curso também
(SOFTEX..., 2011).
São 16 horas de curso que tem por objetivo focar no modelo, abordando o que fazer,
ou seja, o que é necessário fazer para conseguir alcançar cada item do mesmo. São repassados
41
neste curso todos os níveis do MPS, do G ao A, enfatizando mais o nível em que as empresas
presentes estão se certificando – normalmente nível G e F. Ainda são repassadas informações
quanto a avaliação e quanto ao modelo de negócio e também informações para quem quer
seguir carreira neste ramo. O curso deve ser realizado antes da avaliação.
Informações sobre datas e cidades de realização do C1 estão sempre disponíveis no
site da SOFTEX na página reservada ao MPS.BR.
Workshop de MPS.BR, onde todas as empresas da região que estão implantando o
modelo participaram, e teve como objetivo mostrar às empresas como fazer, ou seja, quais as
formas possíveis de criar documentos, criar o processo, usar ferramentas, definição de
modelos, para atender os itens do MPS.BR. Foram apresentados exemplos de artefatos,
processo, contado experiências obtidas em outras empresas certificadas pelo MPS.BR que
tiveram que passar pelo mesmo procedimento. Vale ressaltar que o Workshop foi específico
nível G e F, pois as empresas que participaram estavam se certificando em um destes níveis.
Este também é um curso obrigatório e teve duração de 16 horas. Cabe a instituição
implementadora a realização do workshop.
Curso de Gerência de Projetos: não é um curso obrigatório, no entanto é obrigatório
que alguém que passe a exercer o perfil de gerente de projetos, tenha qualificação para isso
comprovada de no mínimo 16 horas de cursos ou qualificação nesta área. Não se pode ignorar
o fato de que 17 itens a serem atendidos do MPS 2009 nível G são de gerência de projetos. A
Digitaldoc participou deste curso que teve duração de 16 horas e foi uma oportunidade de
aprimoramento de conhecimentos em gerência de projetos a serem aplicados tanto na fase de
Definição quanto na fase de Institucionalização (DIGITALDOC..., 2010).
Cabe a empresa, ou as empresas do grupo, buscar o curso caso necessário, no entanto,
o curso pode ser ministrado pela própria II Instituição Implementadora que está prestando
consultoria, que neste caso específico, foi o próprio CITS que disponibilizou pessoal
qualificado para ministrar o curso (DIGITALDOC..., 2010).
4.4.2 Totais de Subsídios, Custos e Horas Gastas no Projeto
O custo total do projeto MPS.BR nível G para empresas que não tem os subsídios, não
está em um grupo de empresas, chega ao total de R$45.000,00 mais custos relacionados. A
Digitaldoc, por ter optado pelo grupo de empresas, tendo o apoio também do SEBRAE, CITS
e SOFTEX teve ao final um custo de cerca de 37% dos R$ 45.000,00, o que incluiu além dos
42
custos da certificação e gastos com deslocamento da consultora e dos avaliadores. Este valor
inclui gastos com consultoria e com as avaliações Inicial e Final. No entanto não inclui gastos
com salário da equipe definida para o projeto, gastos com cursos e viagens, gastos com
ferramentas, etc. Portanto na Tabela 2 estão descritos os subsídios recebidos e na Tabela 3
estão descritos todos os custos (em %) com o projeto.
Os custos com recursos humanos foram calculados baseado no salário e nas horas que
cada pessoa gastou no projeto. Vale lembrar que é um valor aproximado.
É muito interessante que a empresa aloque uma pessoa em tempo integral para ficar
responsável pelo MPS.BR no mínimo nas etapas de definição e criação do processo e
artefatos, pois ela pode se dedicar a estudar e criar o processo da forma mais adequada a
empresa, além de ficar responsável pela criação de todos os artefatos relacionados, pelo
treinamento da equipe que utilizará o processo, pelos ajustes, melhorias no processo,
documentação, vindos de lições aprendidas com a utilização do processo, ou até mesmo
ajustes solicitados pela consultora. A Digitaldoc optou pela contratação de uma pessoa para
este trabalho em tempo integral, sendo que em algumas etapas não foi necessário todo o
tempo da mesma.
Tabela 2 – Subsídios destinados ao projeto MPS.BR
SUBSÍDIOS
SOFTEX CITS SEBRAE 40% 22,7% 40%
Fonte: Digitaldoc (2011)
Na questão de subsídios, a SOFTEX contribuiu com 40% do custo total, o CITS com
22,7% do restante, e por último o SEBRAE contribuiu com 40% do que ainda havia de custos
(DIGITALDOC..., 2010).
Tabela 3 – Custos relacionados ao projeto MPS.BR
(continua)
CUSTOS
1 - Custos normais do projeto: 37% de R$ 45.000,00
43
Tabela 3 – Custos relacionados ao projeto MPS.BR
(conclusão)
2 - Cursos (entre valor de viagens e
os cursos):
C1: R$ 800,00 (1 pessoa)
Gerência de Projetos (3 pessoas): R$2.100,00
Workshop: N/A – incluso nos custos do projeto.
3 - Recursos Humanos (equipe de
processo):
Recurso 1* - N/D*
Recurso 2* - N/A
Recurso 3* - N/A
4 - Ferramentas: 0 – não se teve custo com aquisição de
ferramentas.
5 - Avaliação N/A – incluso no valor do projeto. Fonte: Digitaldoc (2011)
Custos com recurso humano 1 – Analista de Processos (APC) responsável pela
execução da maior parte das atividades do projeto, o que inclui definição de ferramentas,
criação de artefatos e do processo, criação e execução de treinamentos, entre outros. Este foi o
recurso alocado integralmente para o projeto. Foram necessárias todas as horas nas etapas de
Definição e uma parte na Institucionalização para acompanhamento dos resultados. No
entanto em algumas etapas não foram utilizadas todas as horas para este fim. Os custos para
os recursos não foram divulgados. Foram considerados para o recurso 1:
Meio período de trabalho nos 4 primeiros meses;
Período integral no ano inteiro de 2011, mais Janeiro e Fevereiro de 2012. Neste
caso, nem todas as horas foram utilizadas para o projeto MPS, principalmente
quando inicia os projetos com execução do processo. No entanto, foram
contabilizadas todas as horas.
Custos com recurso humano 2 – Diretor/APC – os custos relacionados a este recurso
não será abordado pelo fato do cargo exercido pelo mesmo e de que não houve a contratação
do mesmo. Também pelo fato de não se ter acesso ao valor do salário do mesmo. As horas
gastas deste recurso serão consideradas na Tabela 4.
Custos com recurso humano 3 – APC – os custos deste recurso também não será
abordado pelo fato da pouca participação deste no projeto e as horas gastas serem
aproximadas, e também pelo fato de já ser um colaborador efetivo. Também pelo fato de não
44
se ter acesso ao valor do salário do mesmo. As horas gastas deste recurso serão consideradas
na Tabela 4.
Foram gastas quantidade de horas bem relevante no projeto como um todo, com a
definição, criação do processo e dos artefatos, acompanhamento do projeto, cursos,
workshops, avaliações, consultorias. Os mesmos estão citados na Tabela 4 que se segue.
Tabela 4 - Horas gastas no projeto Rumo ao MPS.BR
HORAS GASTAS NO PROJETO
1 – Consultorias 80 horas (aproximado)
2 – Cursos e Workshops C1: 16 horas
Gerência de Projetos: 48 horas (3
pessoas)
Workshop MPS.BR: 48 horas (3
pessoas)
3 - Recursos Humanos (equipe de processo): Recurso 1* - 2.950 horas (aproximado)
Recurso 2* - 200 horas (aproximado)
Recurso 3* - 200 horas (aproximado)
4 – Treinamentos da equipe interna no
processo:
20 horas (aproximado)
5 - Avaliações: Pré-diagnóstico: 16 horas
Simulação de Avaliação: 8 horas
Avaliação Inicial: 8 horas
Avaliação Final: 8 horas Fonte: Digitaldoc (2011)
Foram considerados para o recurso 1:
Meio período de trabalho nos 4 primeiros meses;
Período integral no ano inteiro de 2011, mais Janeiro e Fevereiro de 2012.
Foram considerados para o recurso 2 e 3:
Participação em consultorias
Cursos;
45
Planejamento e Definição;
4.4.3 Ferramentas Utilizadas
Para a criação dos artefatos/documentação necessários para atender os itens do MPS
devem ser definidas ferramentas que serão utilizadas, principalmente para a criação do
processo. No caso da Digitaldoc foram definidas as seguintes ferramentas para o auxilio na
criação dos artefatos ou ativos de processo: BizAgi, Word, Excel, PowerPoint, MsProject,
WBS Chart Pro, SVN (Subversion) o CRC (Sistema de Controle de Requisições) e o
Digitaldoc para armazenamento e gerenciamento dos dados. Nenhuma das ferramentas teve
custo para a empresa pelo fato de algumas serem gratuitas, outras serem fruto de parcerias e o
Digitaldoc que é a ferramenta da empresa para gestão eletrônica de documentos.
O BizAgi foi o software utilizado para a construção do processo de software. É um
modelador de processos em BPMN (Business Process Modeling Notation) que possibilita
diagramar os processos de uma forma dinâmica e simples, permitindo organizar graficamente
os processos e as relações existentes em cada etapa, possibilitando uma visualização do
processo como um todo. A Figura 8 mostra o processo na ferramenta BizAgi:
46
Figura 8 – Ferramenta BizAgi
Fonte: Digitaldoc (2011).
Atividades podem ser criadas em seqüência identificando exatamente os passos a
serem seguidos e a relação entre elas. Podem ser criados para essa atividade todos os atributos
necessários a mesma, como Descrição, Entrada, Saída, Recursos, Responsáveis, Participantes
entre outros. É possível inserir links para documentos, apresentações, URLs, tabelas, imagens
entre outros. A Figura 9 apresenta uma estrutura padrão de processo sugerida pelo CITS,
sendo também uniforme à disponibilizada e citada em trabalhos a respeito deste assunto. Um
ciclo de vida em forma de processo pode ser criado utilizando o BizAgi.
47
Figura 9 – Arquitetura dos Processos
Fonte: CITS(2010).
Uma das opções interessantes do BizAgi é que um processo pode ser exportado para
HTML(Hypertext Markup Language ), o que proporciona facilidade na hora da manipulação
do mesmo. Ele pode ser disponibilizado facilmente na intranet da empresa para que os
funcionários visualizem e leiam o mesmo, já que, ao clicar em uma atividade nesse formato,
abre uma visualização da atividade, sua descrição e os outros atributos da mesma. No entanto
além dessa opção o processo pode também ser exportado para Word, PDF, imagem, Visio,
XPDL, SharePoint e Wiki.
4.5 DURAÇÃO DO PROJETO RUMO AO MPS.BR
O projeto rumo ao MPS.BR tem duração normal de 15 meses conforme Figura 10. Ou
seja, se tudo correr normalmente, em um prazo de 15 meses a empresa obtém a certificação.
Como pode ser visto na Figura 11, o primeiro mês é para formalização, assinaturas de
contrato com CITS(II) e SOFTEX, e para planejamento do projeto (tarefa da II). A fase de
Definição tem por padrão duração de 6 meses. A etapa de Institucionalização tem duração de
8 meses até a certificação. Entre a execução da Institucionalização tem-se as avaliações Inicial
e Final, além da simulação de avaliação que não é citada na Figura. E por fim o Encerramento
também no último mês.
48
Figura 10 – Duração do projeto Rumo ao MPS.BR
Fonte: CITS (2010)
A Figura 11 apresenta o planejamento de consultorias, workshop, avaliações, datas de
emissão do laudo de 50% e 100%, entre outros, feito pelo CITS. Neste calendário é planejado
também um cronograma para as outras empresas do grupo, para que os custos sejam
divididos. No entanto, fazendo comparação da figura 11 com a Tabela 5 pode-se notar que a
maioria das datas não foram cumpridas. O CITS e SOFTEX possibilitam esta flexibilidade, no
entanto alguns fatores devem ser levados em consideração para o adiamento de algum dos
marcos estabelecidos. Por exemplo, deve haver consentimento de todas as empresas do grupo
em caso de necessidade do mesmo, também pode haver conflito na agenda dos consultores,
entre outros fatores. No entanto, a II deve comunicar formalmente à SOFTEX alguma
alteração para que a mesma avalie e aprove.
Figura 11 – Planejamento Digitaldoc
Fonte: Digitaldoc (2010)
Tabela 5 – Execução do Projeto MPS.BR
EXECUÇÃO DO PLANEJAMENTO Novembro /2010
Abril /2011
Setembro /2011
Outubro /2011
Janeiro /2012
Fevereiro /2012
Gap analisys (diagnóstico)
Obtenção do laudo de 50%
Simulação de avaliação
Obtenção do laudo de 100%
Avaliação Inicial*
Avaliação Final*
Fonte: Digitaldoc (2011)
49
As avaliações Inicial e Final ainda não foram executadas, mas estão previstas para
Janeiro e Fevereiro de 2012 respectivamente. Pode-se observar na Tabela 5 que houve atrasos
em várias atividades. Como um todo o projeto teve duração de 17 meses (incluindo o mês de
Formalização e Planejamento). No caso da Digitaldoc a fase de Definição (incluindo gap
analisys e workshop) teve duração de 6 meses, a fase de Institucionalização 8 meses (não
contando Janeiro e Fevereiro que são os meses das avaliações).
50
5 CONSIDERAÇÕES FINAIS
5.1 CONCLUSÃO
Através de fundamentações teóricas deste projeto é notável que o MPS.BR surgiu de
uma necessidade real das empresas de pequeno e médio porte do Brasil. Pesquisas mostraram
que as empresas são conscientes da necessidade de melhoria de processos e principalmente da
prática da Engenharia de Software. É grande o número de projetos que falham por motivos
óbvios, como a falta de gerenciamento do projeto, não controlando prazos, custos, desvios no
orçamento, falta de gerenciamento de requisitos tendo um escopo não definido
adequadamente e mudando sempre, sem se ter controle dessas mudanças, e por fim um
agravante maior: a insatisfação do cliente.
No entanto implantar um modelo de melhoria de software como o CMMI era
economicamente inviável para empresas de pequeno porte, as chamadas PMEs, que é a
grande maioria no Brasil – 73% de acordo com a SOFTEX.
O MPS.BR surgiu para atender essa necessidade, melhorar a capacidade de
desenvolvimento de software das organizações através da melhoria contínua de seus
processos aplicando as boas práticas da engenharia de software e a um custo acessível. O
MPS.BR é um caminho economicamente viável para que as organizações alcancem os
benefícios da melhoria de processos e da utilização das boas práticas da engenharia de
software, em um tempo razoável. As pesquisas realizadas anualmente pela SOFTEX têm
mostrado que as empresas estão tendo resultados positivos com a implantação do MPS, como
aumento da produtividade, qualidade e satisfação dos clientes.
O estudo de caso da Digitaldoc mostrou que o APL-Iguassu IT, a SOFTEX, o CITS e
o SEBRAE contribuíram muito para a empresa estar a um passo de obter a certificação e ter
melhoria nos seus processos de desenvolvimento de software. Cada uma destas empresas teve
um papel fundamental inclusive na questão de subsídios aos custos do projeto, que, como
apresentados neste trabalho, não são baixos.
É importante destacar também os benefícios de participar de um grupo de empresas
que estão no mesmo rumo, com os mesmos problemas, e alcançando também resultados
positivos.
O trabalho também mostrou que não é necessário que uma empresa esteja altamente
estruturada para então poder entrar no processo de obtenção da certificação. Tudo depende da
51
avaliação que o consultor faz da situação atual da empresa quanto a processos, equipe, etc. A
Digitaldoc no início da implantação contava apenas com uma equipe de menos de 15
colaboradores incluindo os sócios. No entanto, a empresa deve estar disposta à mudanças
organizacionais e a equipe deve estar comprometida com melhorias contínuas.
A Digitaldoc já mostra avanço nos seus processos. Os benefícios já são visíveis
internamente. É possível identificar que há um gerenciamento melhor dos projetos,
conseguindo identificar os benefícios do escopo negativo que agora é usado não apenas para
projetos de software, mas em vários outros aspectos na empresa. Os projetos são agora
mensuráveis, inclusive o desenvolvimento dos requisitos, pois a partir da técnica de
estimativa de tamanho criada, é possível identificar o tamanho de cada requisito levantado.
Com isso foi identificada a produtividade da equipe, conseguindo ainda calcular quanto
esforço e prazo são necessários para concluir o projeto. Passou-se também a calcular os custos
relacionados a cada projeto e até identificar se determinado projeto seria viável ou não. Todos
os novos negócios – projetos, customizações – estão sendo executados a partir do Processo de
Software Digitaldoc.
5.2 TRABALHOS FUTUROS/CONTINUAÇÃO DO TRABALHO
É interessante pesquisar como as empresas que já tem a certificação nível G estão se
comportando quanto à continuação do projeto tendo como objetivo a melhoria contínua e
alcance dos próximos níveis do MPS. Verificar se os processos continuam sendo utilizados, se
continuam a trazer benefícios, se é de interesse das empresas o alcance dos próximos níveis.
Por exemplo, o nível F trata do Gerenciamento de Portfólios de Projetos, Medição, Garantia
da Qualidade, Gerência de Portfólios do Projeto, Gerência de Configuração e Aquisição.
52
REFERÊNCIAS BIBLIOGRÁFICAS
ABNT – ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO 9000:2000 – Sistemas de gestão da qualidade e garantia da qualidade – Fundamentos e Vocabulário. Rio de Janeiro: ABNT, 2001. AGÊNCIA SEBRAE DE NOTÍCIAS DO PARANÁ. 28/04/2010 - Novo programa para o setor de TI é aplicado em Cascavel. Disponível em: <http://www.sebraepr.com.br/portal/page/portal/PORTAL_INTERNET/ASN_AGENDA/ASN_PAUTA?_dad=portal&_pauta=8049>. Acesso em 07 out. 2011. ALMEIDA, Alessandro. O modelo MPS.BR. Disponível em: <http://www.alessandroalmeida.com/files/Workshop.OModeloMpsBr.pdf>. Acesso em: 01 out. 2011. ALMEIDA, Carlos, D. A.; MACEDO, Thiago, C.; ALBUQUERQUE, Adriano, B. A continuidade da execução dos processos de software em empresas avaliadas no MPS.BR. Fortaleza, 2011. BÉRGMANN , Thais. Implantação do MPS.BR nível G. Disponível em: <http://projetos.inf.ufsc.br/arquivos_projetos/projeto_783/Artigo_Thais_Bergmann.pdf>. Acesso em: 04 out. 2011. CITS – CENTRO INTERNACIONAL DE TECNOLOGIA DE SOFTWARE. Rumo ao MPS.BR Kickoff do Projeto APL Paraná. Curitiba, 2010. DIGITALDOC – Anix Sistemas Ltda. Medianeira, 2010. DIGITALDOC – Anix Sistemas Ltda. Relatório de Pontos Fortes e Pontos Fracos. Medianeira, 2010a. DIGITALDOC – Anix Sistemas Ltda. Resultado da Simulação de Avaliação. Medianeira, 2011. DIGITALDOC – Anix Sistemas Ltda. Digitaldoc alcança resultados excelentes no – MPS.BR. Disponível em: <http://www.digitaldoc.com.br/blog/digitaldoc-alcanca-resultados-excelentes-no-mpsbr>. Acesso em: 23 out. 2011a.
53
FRANCESCHI, Rudinei, A.; DUARTE, Ana M. D. Uma abordagem para gerência de requisitos integrada com práticas ágeis de gerência de projetos. Chapecó, 2011. KALINOWSKI, Marcos; SANTOS, Gleison; REINEHR, Sheila; MONTONI, Mariano; ROCHA, Ana R.; WEBER, Kival C.; TRAVASSOS, Guilherme H. MPS BR: Promovendo a Adoção de Boas Práticas de Engenharia de Software pela Indústria Brasileira. Disponível em: <http://www.softex.br/portal/softexweb/uploadDocuments/CIBSE2010_MPSBR_CameraReady.pdf>. Acesso em: 25 out. 2011. MANIFESTO ÁGIL. Disponível em: <http://agilemanifesto.org>. Acesso em: 07 out. 2011. MENOLLI, Andre; BELMONTE, Danilo; SGARBI, Edilson; MALUCALLI, Andreia; REINEHR, Sheila. Práticas do Modelo MPS em Fábricas de Software: um estudo exploratório sobre as percepções dos gerentes de projeto. Curitiba, 2011. PMBOK - PROJECT MANAGEMENT INSTITUTE. PMBOK: A Guide To The Project Management Body of Knowledge. 4. ed. Newton Square: PMI Publications, 2008. SANTOS, Gleison. Influência e Impacto do Programa MPS.BR na Pesquisa Relacionada à Qualidade de Software no Brasil. Rio de Janeiro, 2011. SERVIÇO BRASILEIRO DE APOIO ÀS MICRO E PEQUENAS EMPRESAS. Programa Sebraetec. Disponível em: <http://www.sebrae.com.br/uf/rio-grande-do-norte/areas-de-atuacao/inovacao-e-tecnologia/programa-sebraetec/>. Acesso em: 07 out. 2011. SERVIÇO BRASILEIRO DE APOIO ÀS MICRO E PEQUENAS EMPRESAS – PR. Tecnologia da Informação. Disponível em: <http://portal.pr.sebrae.com.br/portalsetor/Conteudo.do?conteudo=1858&nivel=685&portal=22>. Acesso em 12 out. 2011a. SODRÉ, Elisângela B. Mps Br – Melhoria do Processo de Software Brasileiro . Disponível em: <http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/245>. Acesso em: 28 set. 2011. SOFTEX - ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO. MPS.BR – Guia de Implementação – Parte 1: Fundamentação para Implementação do Nível G do MR-MPS:2009. São Paulo, 2009. ______. MPS.BR – Guia Geral:2009. São Paulo, 2009a.
54
______. Modelo de Negócio para Melhoria de Processo de Software(MN-MPS): Resumo Executivo – v30JUL2010. Disponível em: <http://www.softex.br/mpsbr/_outros/MN-MPS.pdf>. Acesso em 09 out. 2011. TRAVASSOS, Guilherme, H.; KALINOWSKI, Marcos. iMPS 2010. Desempenho das Empresas que Adotaram o Modelo MPS de 2008 a 2010. Disponível em: <http://www.softex.br/mpsbr/_livros/resultado_desempenho.asp>. Acesso em: 28 set. 2011. ______. iMPS: Resultados de desempenho de organizações que adotaram o modelo MPS. Disponível em: <http://www.softex.br/mpsbr/_livros/resultado_desempenho.asp>. Acesso em: 28 set. 2011a. WORKSHOP MPS.BR NÍVEL G, 2010, Foz do Iguaçu. Workshop MPS.BR Nível G. Curitiba: Centro Internacional de Tecnologia de Software, 2010.