SISTEMAS
SILVANE GASS
MPS.BR NÍVEL G: OBTENÇÃO DE QUALIDADE EM DESENVOLVIMENTO DE SOFTWARE
TRABALHO DE DIPLOMAÇÃO
MEDIANEIRA 2011
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
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)
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á.
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á.
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
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
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
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
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
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.
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
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.
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.
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
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).
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
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-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.
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).
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).
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).
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.
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).
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,
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.
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.
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.
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
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).
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
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.
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;
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
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.
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.
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
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.
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).
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.
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%
