SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL
Pós-Graduação Lato Sensu em Governança de Tecnologia da Informação
Cristiano Ferreira Soares
Implementação do Modelo de Maturidade CMMI-DEV na Empresa X
Brasília-DF 2013
SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL
Cristiano Ferreira Soares
Implementação do Modelo de Maturidade CMMI-DEV na Empresa X
Trabalho de Conclusão de Curso apresentado como requisito para a obtenção do título de Especialista em Governança de Tecnologia da Informação ao Serviço Nacional de Aprendizagem Comercial – SENAC, Unidade EAD – SENAC/DF.
Orientador: Prof. ME Edilberto Magalhães Silva
Brasília-DF
FICHA CATALOGRÁFICA
Soares, Cristiano F.
Implementação do Modelo de Maturidade CMMI-DEV na Empresa X / Cristiano Ferreira Soares. – Brasília: Senac - DF, 2013.
Monografia (especialização) – SENAC – Serviço Nacional de Aprendizagem Comercial. Centro Nacional de Educação a Distância, 2013.
Inclui Bibliografia.
Cristiano Ferreira Soares
Implementação do Modelo de Maturidade CMMI-DEV na Empresa X
Aprovado em
BANCA EXAMINADORA
____________________________________________________ Prof. ME Edilberto Magalhães Silva
Tutor Orientador
____________________________________________________
Convidado
____________________________________________________ Prof.ª ME Alexandra Cristina Moreira Caetano
Coordenadora Pedagógica
Projeto apresentado ao Serviço Nacional de Aprendizagem Comercial – SENAC, Distrito Federal, como requisito parcial para obtenção do título de Especialista em Governança de Tecnologia da Informação.
Dedico este trabalho à minha mãe. Nunca poderei me esquecer de seu esforço em me proporcionar as condições adequadas ao desenvolvimento de minhas potencialidades no campo do saber. A ela, devo desde o meu primeiro passo até onde eu puder chegar.
AGRADECIMENTOS
Eu não conseguiria enumerar, individualmente, todas as pessoas a quem devo agradecer e, além disso, não agradeceria somente às pessoas, mas a todo o universo que, misteriosamente, testifica nossa caminhada ou colabora para o nosso êxito. As contribuições para mais esta realização foram várias e metamorfoseadas sob diversas formas: o Incentivo veio quando eu estava cansado; o Carinho, quando eu precisava de um pouco mais de atenção; a Instrução, enquanto eu me preparava; a Compreensão, quando a querida família se resignava quanto à minha ausência nos momentos de estudo e trabalho e a Perseverança que me fez prosseguir mesmo quando o apelo do lazer e da companhia de pessoas benquistas parecia mais forte que eu. Ademais, se faço uma breve exceção quanto a não menção daqueles a quem devo minha absoluta gratidão, esta se refere ao meu filho, Miguel. Agradeço à você, filho, cuja existência ilumina e justifica a minha.
Altiora semper petens Brasão de Petrópolis
RESUMO
Este trabalho descreve uma proposta de implementação de um modelo de maturidade para qualidade de software por meio da análise dos modelos CMMI v1.3, desenvolvido pelo Software Engineering Institute (SEI) e do Programa de Melhoria de Processos do Software Brasileiro 2012 (MPS.BR) desenvolvido pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX). Tal proposta visa à implementação do modelo de maturidade considerado, dentre os apresentados, como o mais adequado a uma empresa desenvolvedora de software, seguindo uma metodologia baseada em pesquisas bibliográficas e num estudo de caso desenvolvido no âmbito da referida empresa. O trabalho consta, ainda, de outros modelos empregados na área da governança da tecnologia da informação, como o Control Objectives for Information and Related Technology (COBIT) e a Information Technology Infrastructure Library (ITIL), como forma de relacioná-los ao CMMI. Este, por sua vez, é combinado ao ciclo de vida de processos IDEAL na proposta de implementação aqui descrita. Ressalte-se, ademais, que a importância deste tema está diretamente relacionada à satisfação dos objetivos estratégicos das empresas do ramo de desenvolvimento de software em sua busca pelo aumento da produtividade, da satisfação do cliente e da otimização dos recursos, benefícios advindos da racionalidade técnica e da adoção de boas práticas.
ABSTRACT
This paper describes a proposal to implement a maturity model for software quality through analysis of CMMI v1.3, developed by the Software Engineering Institute (SEI) and the Brazilian Software Process Improvement Program 2012 (MPS.BR) developed by the Associação para Promoção da Excelência do Software Brasileiro (SOFTEX). This proposal aims at the implementation of the maturity model, chosen among those presented in this work, as the most appropriate for a company that develops software, using a methodology based on bibliographical research and a case study conducted inside the considered company. The work consists also of other models used in the area of governance of information technology, such as the Control Objectives for Information and Related Technology (COBIT) and Information Technology Infrastructure Library (ITIL) as a way to relate them to the CMMI. This, in turn, is combined in the present proposal of implementation with the process life cycle of the IDEAL model. It should be noted, moreover, that the importance of this issue is directly related to the fulfillment of the strategic objectives of software development companies regarding their quest for increased productivity, customer satisfaction and resources optimization, benefits which result from the technical rationality and from the adoption of good practices.
LISTA DE ILUSTRAÇÕES
Figura 01 – Cronograma de Implementação...19
Figura 02 – Evolução do CMMI...21
Figura 03 – Componentes do MPS.BR...24
LISTA DE TABELAS
Tabela 01 – Representações do CMMI...22
Tabela 02 – Níveis de Maturidade do MPS.BR...24
Tabela 03 – Relacionando CMMI Nível 2 com o Ciclo de Vida da ITIL...27
Tabela 04 – Resumo das Entrevistas Realizadas...30
Tabela 05 – Análise Comparativa entre CMMI e o MPS.BR...36
Tabela 06 – Áreas de Processo do CMMI-DEV...37
Tabela 07 – Cronograma de Ações...38
Tabela 08 – Metas e Práticas Genéricas do CMMI Nível 2...39
Tabela 09 – Meta e Práticas Específicas da Área de Processos REQM...40
Tabela 10 – Metas e Práticas Específicas da Área de Processos PP...40
Tabela 11 – Metas e Práticas Específicas da Área de Processos PMC...40
Tabela 12 – Metas e Práticas Específicas da Área de Processos SAM...41
Tabela 13 – Metas e Práticas Específicas da Área de Processos MA...41
Tabela 14 – Metas e Práticas Específicas da Área de Processos PPQA...41
Tabela 15 – Metas e Práticas Específicas da Área de Processos CM...41
Tabela 16 – Estimativa de Desembolsos Previstos...42
Tabela 17 – Definição de Papéis e Responsabilidades...44
SUMÁRIO
1 INTRODUÇÃO ... 14
1.1 Formulação da situação problema (Questões de pesquisa) ... 16
1.2 Objetivos e escopo ... 16 1.2.1 Objetivo Geral ... 16 1.2.2 Objetivos Específicos ... 16 1.2.3 Escopo ... 17 1.3 Justificativa ... 17 2 METODOLOGIA... 18 2.1 Cronograma de Implementação ... 19
3 REVISÃO DE LITERATURA E FUNDAMENTOS ... 20
3.1 CMMI – Capability Maturity Model Integration ... 20
3.2 MPS.BR - Melhoria de Processo de Software Brasileiro ... 23
3.3 Relacionando CMMI, ITIL e COBIT ... 25
4 ESTUDO DE CASO ... 28
4.1 Sobre a organização ... 28
4.2 Coleta de dados organização ... 29
5 DISCUSSÃO ... 33
5.1 Critérios para interpretação dos achados do estudo de caso ... 33
5.2 Combinação dos dados para responder às questões de pesquisa ... 33
5.3 Proposição da solução e aplicação de boas práticas ... 35
5.3.1 Escolha do modelo a ser implementado ... 35
5.3.2 Implementando o CMMI-DEV ... 37 5.3.2.1 O Modelo IDEAL ... 43 5.3.2.1.1 Iniciando ... 43 5.3.2.1.2 Diagnosticando ... 43 5.3.2.1.3 Estabelecendo ... 43 5.3.2.1.4 Agindo ... 44
5.3.2.1.5 Aprendendo ... 44
6 CONCLUSÕES E TRABALHOS FUTUROS ... 47
6.1 Conclusões ... 47
6.2 Trabalhos Futuros... 48
14
1 INTRODUÇÃO
Todos os dias, inúmeras atividades são realizadas nas mais diversas situações: e-mails podem ser consultados via laptops na cozinha na hora do café da manhã; games podem ser jogados através de smartphones no trajeto entre a casa e o trabalho; transações bancárias podem ser realizadas durante o horário de almoço por meio de terminais eletrônicos; nos diversos deslocamentos pela cidade, aparelhos de GPS podem ser utilizados para se encontrar determinadas rotas ou pontos de interesse. Por trás de todas estas atividades, há um componente do qual nem sempre nos damos conta, senão através da interface de aparelhos ou de dispositivos que utilizamos: o software.
Ainda mais imperceptível que a noção de sua existência é a maneira como são concebidos. Se é fácil imaginar como carros são produzidos através das linhas de montagem, o mesmo não se pode dizer do ambiente produtivo de uma empresa desenvolvedora de softwares. Ainda assim, é fácil constatar a importância deste segmento na sociedade contemporânea.
Em virtude da emergência com que são demandados e adstritos ao fato de sua, relativamente, curta história, os softwares sofreram, ao longo do tempo que vai do seu surgimento à atualidade, uma tremenda evolução na maneira com que são concebidos, tamanha a velocidade de mutação de ambientes, linguagens, métodos e formas de organização.
Tal evolução não se deu sem sobressaltos, haja vista o que se convencionou chamar de crise do software nos anos 70. A reação a este cenário, entretanto, veio logo a seguir, como resposta de superação a tal contingência. No bojo desta reação, além da revolução na engenharia de software, revolucionou-se também o ambiente organizacional das empresas e novos meios de gerenciamento tomaram forma.
O presente trabalho tem por escopo oferecer uma proposta de implementação de um modelo de maturidade numa empresa desenvolvedora de software com vistas a apresentar um modelo de boas práticas que a capacite ao desafio da melhoria contínua, uma vez que
15 Especialmente para organizações onde o produto principal é o desenvolvimento e manutenção de software, faz-se necessário, senão a implementação do CMMI, o conhecimento e aplicação parcial deste. Seja por necessidades mercadológicas, para maior visibilidade de produtos e serviços da organização ou simplesmente para melhoria de processos, torna-se imprescindível o conhecimento e aplicação destas “melhores práticas” ao processo de desenvolvimento e manutenção de produtos e serviços de software. (SAMARINI, 2005)
Esta contextualização evidencia a relevância da temática que será abordada. Ademais, o aumento da produtividade, da satisfação do cliente e da otimização dos recursos, fruto da racionalidade técnica e da adoção de boas práticas constituem, por si sós, razões suficientes para um olhar mais atento e um interesse decidido ao que é proposto por modelos de maturidade como o MPS.BR ou o CMMI.
Desta forma, ao longo deste trabalho, a proposta de implementação se dará da seguinte forma: no capítulo 1, além desta introdução, estão compreendidos, também, os objetivos, o escopo e a justificativa para este trabalho; no capítulo 2, faz-se uma revisão de literatura e fundamentos, abordando aspectos do CMMI v1.3, do MPS.BR 2012 e da forma como o CMMI está relacionado a outros frameworks, como COBIT e ITIL; no capítulo 3, apresenta-se a metodologia e o cronograma de implementação deste trabalho; no capítulo 4, tem-se o estudo de caso, evidenciando-se o ambiente de produção da empresa; no capítulo 5, faz-se a proposta de implementação do modelo de maturidade para a empresa X e, finalmente, no capítulo 6, são apresentadas as conclusões e as indicações para trabalhos futuros.
16
1.1 Formulação da situação problema (Questões de pesquisa)
No mundo corporativo, a clareza dos objetivos de uma empresa é condição indispensável à elaboração de um bom planejamento estratégico. Este representa o seu plano de vôo no qual constam a rota e o destino traçados. Especificamente, para as empresas voltadas à produção de software, os modelos de maturidade representam, grosso modo, justamente o roteiro de práticas que auxiliam a organização a se situar quanto ao seu estágio atual e a se adequar quanto às suas possibilidades futuras. Assim, no âmbito da empresa X, a questão que move este trabalho é:
Qual deverá ser o modelo de maturidade a ser adotado pela empresa a fim de melhor orientá-la na consecução de seus objetivos?
1.2 Objetivos e escopo
1.2.1 Objetivo Geral
Propor a implementação de processos dos modelos de maturidade para qualidade de software por meio da análise dos modelos CMMI 1.3 - desenvolvido pelo Software Engineering Institute (SEI) e pelo MPS.BR (2012) - desenvolvido pela Associação para Promoção da Excelência do Software Brasileiro (Softex)- para a empresa X.
1.2.2 Objetivos Específicos
1. Efetuar uma revisão bibliográfica e análise comparativa sobre os modelos Capabilitiy Maturity Model Integration (CMMI v1.3) e o modelo de Melhorias de Processos do Software Brasileiro (MPS-BR 2012);
2. Realizar avaliação e análise da melhoria de desenvolvimento de software em relação aos objetivos estratégicos da organização e
3. Propor a implantação de processos do modelo considerado como o mais adequado.
17
1.2.3 Escopo
Este trabalho trata do ambiente de produção de software da empresa X, sobre as condições atuais que regem seus processos de desenvolvimento de softwares e tem por escopo apresentar uma proposta de implementação de um modelo de maturidade.
1.3 Justificativa
O software é, atualmente, um dos produtos comerciais de maior importância no mundo. Dada a sua ubiquidade nos sistemas de informação que permeiam, praticamente, todas as atividades humanas na atualidade, é de se esperar que a mesma diligência outrora voltada à melhoria e racionalização dos sistemas de produção de manufaturas e de bens industriais, também tenha se voltado, neste momento, ao desenvolvimento de programas que agreguem, continuamente, maior confiabilidade, mais qualidade e valor face às necessidades de clientes, usuários e consumidores que requisitam soluções de mercado com um crescente e ininterrupto perfil de exigência.
Na esteira dos esforços que têm sido empreendidos visando a uma efetiva governança da tecnologia da informação, a engenharia de software vem recebendo importante contribuição de modelos de capacidade e maturidade das organizações. Estes modelos balizam o caminho de otimização de processos com vistas aos ganhos de eficiência e eficácia de produtos acabados, por conseguinte, a obtenção da almejada qualidade pelo cliente com a melhor combinação de fatores de que os desenvolvedores e gerentes podem dispor. Esta contextualização evidencia a relevância da temática que será abordada. Ademais, no contexto da empresa X, acredita-se que a melhoria de sua maturidade a credenciará não somente à obtenção de resultados de excelência no que concerne ao gerenciamento de seus projetos de desenvolvimento de software como a fará atingir, também, novos clientes em potencial.
18
2 METODOLOGIA
A metodologia a ser utilizada basear-se-á em pesquisas bibliográficas sobre os temas e tópicos que serão abordados bem como em outros referenciais teóricos consultados através de artigos, monografias, dissertações e teses disponíveis na internet que tratem, sobretudo, de temáticas voltadas a modelos de maturidade, ao framework COBIT e ao modelo ITIL.
Ademais, tendo em vista a proposta prática deste trabalho, qual seja, a pretensão em realizar uma avaliação crítica que contemple, igualmente, uma análise de melhoria no que tange ao desenvolvimento de software levando-se em consideração os objetivos estratégicos da organização, a presente metodologia também abrangerá um estudo de caso.
Este se desenrolará através de detida observação acerca dos processos empregados na empresa X, especificamente, na Seção de Projeto/Desenvolvimento, com vistas a obter um quadro-síntese da situação em que se encontra a organização a fim de traçar as propostas de melhoria subsequentes.
Desta forma, resumidamente, a metodologia empregada neste trabalho para obtenção e análise de dados consiste em:
Levantamento de referencial teórico; Leitura e sistematização do conteúdo; Elaboração do conteúdo;
Obtenção dos dados; Análise dos resultados.
Para a pesquisa de campo, os seguintes métodos foram utilizados: Observação participante;
Observação direta das atividades e serviços executados; Realização de entrevistas;
19
2.1 Cronograma de Implementação
O cronograma abaixo apresenta as metas e as atividades que serão desenvolvidas ao longo deste trabalho.
Figura 01 – Cronograma de Implementação Fonte: Autor
Os próximos capítulos materializam as atividades previstas no quadro acima. Desta forma, no capítulo 3, Revisão de Literatura e Fundamentos, são expostos os conceitos e os entendimentos adquiridos através de consultas em livros e artigos; o capitulo 4 dedica-se ao estudo de caso e compreende: análidedica-se da empresa, formulação de questionamentos e entrevistas e a reunião dos dados coletados e, por fim, os capítulos 5 e 6, Discussão e Conclusão, respectivamente, encerram as atividades necessárias à consecução dos objetivos propostos neste trabalho.
20
3 REVISÃO DE LITERATURA E FUNDAMENTOS
3.1 CMMI – Capability Maturity Model Integration
A quase onipresença da TI é ilustrativa de uma época que muitos alcunham como a Era da Informação. Seu alcance tornou os softwares imprescindíveis a, virtualmente, todas as organizações. Os programas, como vetores básicos da produção, armazenamento e disseminação da informação, ganharam relevo na sociedade contemporânea e seus níveis de qualidade, seus prazos de desenvolvimento e suas conformidades aos requisitos dos clientes e às exigências legais passaram a ser objeto de grande preocupação.
No livro Software Engineering, a Practitioner’s Approach, o autor apresenta a noção de que “as pessoas apostam seus empregos, seu conforto, sua segurança, sua diversão e suas próprias vidas nos softwares de computadores. Eles precisam estar certos”1 (PRESSMAN, 2001, p.4)
É neste quadro que o Instituto de Engenharia de Software da Universidade Carnegie Melon cria, no início dos anos 90, patrocinada pelo Departamento de Defesa (DoD) americano, os CMMs, matriz do atual modelo de maturidade e capacidade, a fim de, simplificadamente, representar o mundo real. Por essa época, o SW-CMM torna-se o padrão “de-facto” para o desenvolvimento de software ajudando as organizações a saírem do caos e a entrarem em um ambiente mais estruturado e estável (DAVIS et al., 2007 apud Marçal).
Os Capability Maturity Models (CMM), segundo o SEI, foram baseados nos conceitos desenvolvidos por Deming, que refinou os princípios de controle estatístico da qualidade estabelecidos por Walter Shewhart nos anos de 1930 e também por Crosby, Juran e Humphrey que, posteriormente, estenderam estes princípios e começaram a aplicá-los aos softwares nos trabalhos que desenvolveram na IBM e no próprio SEI.
O CMMI é uma evolução desses primeiros CMM e, atualmente, encontra-se na versão 1.3. Embora não tenha havido profundas alterações em relação à versão anterior,
1And yet, people bet their jobs, their comfort, their safety, their entertainment, their decisions, and their very lives on computer software. It better be right.
21 segundo pesquisas realizadas no site da ISDBrasil – consultoria especializada em governança de TI - cumpre destacar que a atual deu maior esclarecimento a termos e conceitos que na antecedente pareciam um pouco obscuras, como o conceito de alta maturidade. Há referências também à modernização de práticas, tendo em vista a preocupação em refletir o ambiente de TI atual e suas melhores práticas e, também, uma abordagem para permitir um melhor compartilhamento de práticas entre as constelações.
Figura 02 – Evolução do CMMI Fonte: SEI
O CMMI, como outros CMMs, provê orientações para desenvolvimento de processos, indicando o que fazer sem, no entanto, revelar de qual maneira. Com isto, admite-se que o CMMI, diferentemente das metodologias ágeis, tem foco nos processos e não nos procedimentos.
22 Desta forma, ele instrui sobre as características estruturais e semânticas quanto aos objetivos bem como quanto ao grau de qualidade a ser alcançado pelo trabalho, estabelecendo determinados padrões dentro de um sistema de classificação que o CMMI representa sob a forma de duas diferentes abordagens, sendo uma denominada contínua e a outra entendida por meio de estágios. Estas abordagens representam, respectivamente, os níveis de capacidade e de maturidade da organização.
Tabela 01 – Representações do CMMI NÍVEL NÍVEIS DE CAPACIDADE DA
REPRESENTAÇÃO CONTÍNUA
NÍVEIS DE MATURIDADE DA REPRESENTAÇÃO POR ESTÁGIO
N0 Incompleto N1 Executado Inicial N2 Gerenciado Gerenciado N3 Definido Definido N4 Quantitativamente Gerenciado N5 Em Otimização Fonte: SEI
Na abordagem contínua, a capacidade é medida por processos que são independentes entre si, sendo possível ter processos com níveis diferentes, variando de acordo com os interesses da empresa, possibilitando à organização utilizar a ordem de melhoria que melhor satisfaça os seus objetivos de negócio.
É caracterizada por Níveis de Capacidade (Capability Levels). A representação contínua é indicada quando se deseja tornar apenas alguns processos mais maduros, quando já se utiliza algum modelo de maturidade contínua ou quando não se pretende usar a maturidade alcançada como modelo de comparação com outras empresas.
A representação por estágio disponibiliza, por outro lado, uma sequência pré-determinada para melhoria baseada em estágios, nos quais cada um serve de base para o próximo. Caracteriza-se por Níveis de Maturidade (Maturity Levels).Em cada nível a maturidade é medida por um conjunto de processos. Indica-se esta representação quando a empresa já utiliza algum modelo de maturidade por estágios, quando se deseja utilizar o nível de maturidade alcançado para comparação com outras empresas ou quando se pretende usar o nível de conhecimento obtido por outros para sua área de atuação.
Estas representações, portanto, servem como roteiro no qual as organizações se baseiam para localizarem o ponto de partida bem como as paradas ao longo do caminho
23 em sua jornada rumo ao contínuo processo de otimização. Destaque-se que o CMMI possui 22 áreas de processos, elencadas na seção 5.3.2 deste trabalho, as quais encontram-se distribuídas por 4 categorias: gerenciamento de projetos, gerenciamento de processos, engenharia e suporte.
3.2 MPS.BR - Melhoria de Processo de Software Brasileiro
O mercado de software, no cenário brasileiro, é amplamente dominado por empresas de pequeno e médio porte, segundo dados do SEBRAE. Esta realidade, não obstante, ponha em relevo o empreendedorismo nacional, evidencia, também, a escassez de grandes empresas com disponibilidade e capacidade financeira suficientes para fazer frente a investimentos em tecnologias e certificações.
Para as empresas de menor porte,investir em certificação é algo que, raramente, se leva a cabo em um ambiente onde, segundo o SEBRAE, a maioria delas sucumbe já nos primeiros anos de vida. A acirrada concorrência constitui, igualmente, outro fator a ponderar no tocante a dispêndios com certificações e licenças, uma vez que as reduzidas margens de lucro por conta da competição inviabilizam novas fontes de custos. Atenta a este panorama, a SOFTEX, Associação para Promoção da Excelência do Software Brasileiro, em parceria com o governo e universidades, criou o programa MPS.BR – Melhoria do Processo de Software Brasileiro.
Alicerçado em normas e padrões internacionais, o MPS.BR utiliza, em seu modelo, a ABNT NBR ISO/IEC 12207:2009 e a ABNT NBR ISO/IEC 15504:2008 também conhecida por SPICE (Software Process Improvement and Capability dEtermination. Além disso, o modelo está em conformidade, também, com o CMMI, sendo dividido em três componentes: um modelo de referência (MR-MPS), responsável pelo estabelecimento de níveis de maturidade; um método de avaliação (MA-MPS), cujo escopo é a orientação na realização de avaliações e um modelo de negócio (MN-MPS), modelo que prevê duas formas de implementação do MPS.BR, uma de maneira personalizada através de um Modelo de Negócios Específico (MNE) e outra de forma cooperada, através de um Modelo de Negócios Cooperado (MNC). Todos os modelos são descritos por meio de guias ou documentos do MPS.BR.
24
Figura 03 – Componentes do MPS.BR Fonte: SOFTEX
O Modelo de Referência MPS define níveis de maturidade como sendo uma combinação entre processos e sua capacidade. Ao todo, são sete níveis de maturidade: Tabela 02 – Níveis de Maturidade do MPS.BR
NÍVEL DESCRIÇÃO PROCESSOS
A Em Otimização -
B Gerenciado Quantitativamente Gerência de Projetos (2ª evolução)
C Definido
Desenvolvimento para Reutilização Gerência de Decisões
Gerência de Riscos
D Largamente Definido
Desenvolvimento de Requisitos Integração do Produto Projeto e Construção do Produto
Verificação Validação
E Parcialmente Definido
Gerência de Reutilização
Avaliação e Melhoria do Processo Organizacional Definição do Processo Organizacional
25
NÍVEL DESCRIÇÃO PROCESSOS
Gerência de Recursos Humanos Gerência de Projetos (1ª evolução)
F Gerenciado
Medição
Gerência de Configuração Gerência de Portfólio de Projetos
Aquisição Garantia da Qualidade
G Parcialmente Gerenciado Gerência de Requisitos
Gerência de Projetos
Fonte: SOFTEX
Em comparação ao CMMI, o presente modelo é mais simples, com menos processos e com uma progressão diferente daquele, já que agrega dois outros níveis. Entretanto, estes aspectos permitem uma implementação mais gradual do modelo, o que se traduz em visibilidade de melhorias a prazos mais curtos. O custo reduzido de implantação é outro dos benefícios aventados.
3.3 Relacionando CMMI, COBIT e ITIL
Um dos maiores referenciais quando o assunto é governança de TI, o COBIT pode ser tido como um dos mais abrangentes frameworks da tecnologia da informação e, certamente, o mais integrador dentre todos, dado o seu nível de abstração e generalidade. O Control Objectives for Information and Related Technology, atualmente na versão 5, relaciona-se com o CMMI através dos seguintes domínios:
Build, Acquire and Implement (BAI) no que tange aos processos relacionados à construção, aquisição e aplicação;
Align, Plan and Organise (APO) referente a alguns processos organizacionais e relacionados à qualidade.
Na figura abaixo, uma série de frameworks de TI encontram-se distribuídos segundo as áreas de intersecção com os domínios do COBIT. Em destaque, com os comentários do autor, está o CMMI.
26 Figura 04 – Relacionando CMMI com os Domínios do COBIT
Fonte: ISACA
A ITIL, de maneira sucinta, é uma biblioteca composta por livros contextualizados conforme os conceitos que abrangem. Na Estratégia de Serviços são identificados os requisitos e as necessidades do negócio que possam ser atendidos por serviços de TI; No Desenho de Serviços, formula-se a solução de TI a ser projetada em forma de serviço em todos os seus aspectos; Na Transição de Serviços, parte-se para a implementação de forma que esta seja testada, acompanhada e validada. Na Operação de Serviços, o foco é sua manutenção e funcionamento em consonância com os SLA, os acordos de nível de serviço. Finalmente, na Melhoria Contínua de Serviços, são identificadas as oportunidades de aperfeiçoamento do serviço. Os ciclos de vida do serviço da ITIL em contato com o nível 2 do CMMI são:
27 Tabela 03 – Relacionando CMMI Nível 2 com o Ciclo de Vida da ITIL
RELACIONAMENTO ENTRE ÁREAS DE PROCESSO E CICLO DE VIDA DA ITIL
LEGENDA
AP – Área de Processo do CMMI REQM – Gestão de Requisitos PP – Planejamento de Projeto
PMC – Monitoramento e Controle de Projeto SAM – Gestão de Contrato com Fornecedores CM – Gestão de Configuração
PPQA – Garantia da Qualidade de Processo e Produto MA – Medição e Análise
AP Objetivos Relacionados CMMI/ITIL Ciclo de Vida da ITIL REQM Desenvolver e gerenciar seus requisitos de serviço. Estratégia do Serviço
Desenho do Serviço PP Manter planos de serviços que incluam orçamento
e cronograma necessários ao suporte do cliente.
Estratégia do Serviço
PMC Gerenciar custos e cronograma associados ao serviço.
Estratégia do Serviço
SAM Gerencia fornecedores de ferramentas ou recursos vitais ao sucesso do serviço.
Estratégia do Serviço
CM Produtos do trabalho de gerenciamento e técnicas de controle.
Transição do Serviço
PPQA Assegurar que seus serviços atendam aos objetivos de qualidade e requisitos dos clientes.
Transição do Serviço Contínua Melhoria do Serviço MA Entender medidas de custos, lucros e custo da
qualidade.
Estratégia do Serviço Contínua Melhoria do Serviço Fonte:SEI
Conforme visto, o nível 2 do CMMI-DEV enquadra-se, basicamente, no primeiro estágio do ciclo da ITIL, ou seja, na estratégia de serviço, no qual se busca, prioritariamente, atender aos objetivos estratégicos da organização.
28
4 ESTUDO DE CASO
O presente capítulo apresenta o estudo de caso realizado na empresa X. Este estudo, partindo do referencial teórico, tem o propósito de conhecer e analisar a empresa em questão, abordando os aspectos relacionados à sua constituição bem como a coleta de dados necessária ao entendimento de seu quadro atual para, a partir de então, propor a implementação de um modelo de maturidade que a auxilie a alcançar os objetivos expressos em seu planejamento estratégico.
4.1 Sobre a organização
A empresa X é uma fábrica de software que oferece soluções em tecnologia da informação, atuante no mercado desde 2010. Surgida como uma start-up2 focada no desenvolvimento de sistemas sob medida para uma ampla variedade de setores, possui, entre seus colaboradores, analistas de sistemas, administradores de bancos de dados, designers gráficos, programadores web e gerente financeiro.
Emprega em seus trabalhos, sobretudo, tecnologias Java, MySQL e PHP. Eventualmente, soluções que escapam ao domínio da empresa são providas por meio de outsourcing. A empresa trabalha com foco na customização, desenvolvendo projetos de sistemas personalizados e que atendam às expectativas dos clientes. Estes, geralmente, são compostos por pequenos ou microempresários com necessidades específicas, embora, também, haja cases de sucesso com empresas bem conhecidas no mercado.
Com o fito de transformar idéias e requisitos em produtos e serviços de qualidade, a empresa X adota como valores a criatividade, a inovação e o compromisso com o cliente. Em seu planejamento estratégico, consta, ainda, que sua missão é a de gerar valor para todos os seus stakeholders, atuando no mercado de desenvolvimento de
2 O conceito de startups tem origem nos EUA e significa empresas de pequeno porte, recém-criadas ou ainda em fase de constituição, com atividades ligadas à pesquisa e desenvolvimento, cujos custos de manutenção sejam baixos e ofereçam a possibilidade de rápida e consistente geração de lucros (Leone Farias. Empreendedores com projetos tecnológicos atraem investidores. Diário do Grande ABC, Região do ABC Paulista, 21 de julho de 2013, Economia/Empresas, pag 2)
29 sistemas de modo a alcançar, até 2015, o status de empresa mais reconhecida no ramo em que atua. Seus objetivos estratégicos buscam:
Consolidar o nome da empresa;
Gerar maior valor agregado para os clientes; Aumentar a rentabilidade;
Aprimorar a confiabilidade operacional; Fidelizar clientes;
Diversificar o portfólio de produtos e serviços e Expandir os negócios da empresa.
Como observado, a empresa possui planejamento estratégico e seus sócios-gerentes possuem boa noção de ferramentas e modelos de boas práticas em governança de tecnologia da informação.
Apesar do exposto, a empresa não adota, formalmente, nenhum modelo de maturidade, sob a alegação de que o tempo despendido e os custos incorridos inviabilizam os investimentos necessários.
4.2 Coleta de dados organização
Após o levantamento do referencial teórico e das pesquisas necessárias a uma maior compreensão acerca da aplicação e das particularidades de alguns modelos de maturidade, partiu-se para a coleta de dados na empresa X de maneira a se proceder à sua análise e avaliação quanto às práticas adotadas nos processos de gerência de desenvolvimento de sistemas e de softwares. Dentre os métodos e técnicas existentes de coleta de dados para efeito de estudo de casos, optou-se pela entrevista e pela observação direta, sendo esta realizada em estreita ligação, também, com a observação e consulta de artefatos físicos.
Na entrevista, procurou-se obter todas as informações pertinentes à avaliação da existência, ou não, de processos utilizados no desenvolvimento de softwares pela empresa. Segundo Gil (1999, p. 23) a entrevista “é uma forma de interação social [...], mais especificamente, é uma forma de diálogo assimétrico, em que uma das partes busca
30 coletar dado e a outra se apresenta como fonte de informação.” Desta forma, procurou-se coletar, junto aos entrevistados, os dados mais importantes para a análise da empresa, através de questionamentos semiestruturados, pautados pela temática dos modelos de boas práticas e pelo contexto do ambiente e das atividades exercidas por cada entrevistado.
As observações diretas, segundo (YIN, 2001), podem variar de atividades formais a informais de coleta de dados. No presente caso, as observações foram feitas de maneira informal, atentando-se para o trabalho na empresa, conjugando-se tais observações com registros e artefatos físicos, quando possível.
De maneira geral, as informações obtidas por meio de entrevistas estão apresentadas na tabela a seguir. As respostas obtidas estão expressas em termos percentuais, levando-se em consideração que houve um total de oito pessoas entrevistadas. Cabe salientar, outrossim, que as pessoas entrevistadas fazem parte da gerência ou trabalham na Seção de Projetos/Desenvolvimento, seção considerada o núcleo da empresa e, sempre que se fez necessário, alguns termos próprios da linguagem da governança de TI foram explicados de maneira a se alcançar o entendimento pretendido.
Tabela 04 – Resumo das Entrevistas Realizadas
PERGUNTAS SIM NÃO
A empresa conhece modelos de boas práticas? 100% 0%
A empresa adota, formalmente, algum modelo de boas práticas? 0% 100%
Existe um framework definido de processos? 0% 100%
Os papéis e as responsabilidades são bem definidos? 37,5% 62,5%
31
PERGUNTAS SIM NÃO
A empresa define métricas alinhadas com os objetivos de negócio? 50% 50%
Os projetos desenvolvidos são exaustivamente testados? 100% 0%
Existe controle de qualidade dos produtos e/ou serviços
desenvolvidos, em todas as fases do desenvolvimento? 100% 0%
A empresa estabelece critérios para a aceitação de requisitos? 100% 0%
A empresa, normalmente, cumpre as atividades dentro do prazo
previsto? 25% 75%
A empresa além de estipular o que será feito também evidencia o
que não se deve fazer? 0% 100%
Existe processos para gerenciamento de
fornecedores/provedores/terceirizados? 0% 100%
A empresa costuma fazer estimativas sobre todos os aspectos do
projeto? 75% 25%
Há monitoramento do projeto quanto ao que foi planejado? 100% 0%
Existe eventos de acompanhamento com o cliente? 100% 0%
A empresa adota acordos de nível de serviço com cliente e
fornecedores? 100% 0%
Fonte: Entrevistas realizadas pelo autor entre 08/07 e 12/07/2013
Outros dados levantados, embasados no relacionamento da observação direta às evidências físicas ou palpáveis no ambiente de trabalho, apontam, por vezes, para uma assimetria entre as informações obtidas junto a gestores e aquelas encontradas em
32 evidências materiais. Prova disso, por exemplo, está na análise de que, apesar da comprovação da existência dos acordos de níveis de serviço adotados, estes, não raro, necessitam de uma melhor elaboração, pois há lacunas no que se refere a não conformidade com os requisitos de qualidade, tanto por parte da contratação de terceirizados quanto por parte dos clientes. Estas lacunas, inclusive, sendo objeto de ponderação dos próprios envolvidos.
A empresa apresentou cronogramas de projetos e algumas metas estabelecidas, contudo, percebeu-se, também, que não se faz, de forma sistemática, o devido controle estatístico para verificar a real evolução no alcance das metas.
Por fim, ressalte-se que a documentação de processos e procedimentos encontra-se vinculada apenas aos projetos a que encontra-se refere (ad hoc3) e não há tratamento, a nível organizacional, válido de maneira generalizada para todos os projetos.
3 Ad hoc é uma expressão latina que significa "para esta finalidade" ou "com este objetivo". Geralmente se refere a uma solução destinada a atender a uma necessidade específica ou resolver um problema imediato. (Disponível em: <http//pt.wikipedia.org/wiki/redes_ad_hoc> Acesso em: 22 julho 3013).
33
5 DISCUSSÃO
A reunião dos dados coletados permite, a partir deste capítulo, tecer considerações e traçar um panorama que reflita as reais condições em que a empresa se encontra, através da análise e interpretação dos dados levantados e propicie, igualmente, uma proposta de implementação de um modelo de maturidade que possibilite maiores ganhos de produtividade e qualidade com a adoção de boas práticas nos processos de desenvolvimento de sistemas e de softwares, aumentando, assim, o grau de qualidade dos serviços e produtos ofertados pela empresa.
5.1 Critérios para interpretação dos achados do estudo de caso
Na interpretação dos achados, procurou-se estabelecer um encadeamento entre as fontes de dados consultadas, de modo a corroborar informações obtidas ou relativizá-las no âmbito geral da pesquisa.
As entrevistas foram realizadas de modo individual, tendo em vista a confrontação de respostas para posterior análise. Também, utilizou-se como critério para avaliação das respostas às perguntas feitas, não somente as respostas em si, mas todas as evidências pertinentes ao assunto abordado, como verificação de trabalhos já realizados e as condições de como procederam a sua realização por meio de contratos, anotações e da documentação encontrada.
A próxima seção demonstra a combinação dos dados obtidos à luz dos critérios aqui explanados para a sua interpretação e tem por objetivo, também, apontar que, com base nos dados levantados e na percepção do ambiente analisado, a empresa X encontra-se no nível de maturidade 1 do CMMI.
5.2 Combinação dos dados para responder às questões de pesquisa
A coleta de dados foi empreendida de modo a relacionar a observação direta às evidências físicas ou palpáveis no ambiente de trabalho. Desta forma, procurou-se levar em conta, também, as respostas das entrevistas com os demais dados verificados na
34 empresa. Assim, foi possível, por exemplo, analisar que, apesar da comprovação da existência dos acordos de níveis de serviço adotados, estes, não raro, necessitam de uma melhor elaboração, pois há lacunas no que se refere a não conformidade ou inexistência de requisitos importantes, tanto por parte da contratação de terceirizados quanto por parte de clientes. A implementação da área de processo Gestão de Contrato com Fornecedores do CMMI, por exemplo, seria uma importante medida na solução destes impasses.
A observação direta, pautada na verificação dos objetivos estratégicos e os meios para atingi-los, por outro lado, constatou que, embora alguns dos processos e procedimentos adotados estejam coerentes com que o se recomenda em termos de boa governança, tais práticas decorrem, antes, de comportamentos “intuitivos” ou da experiência acumulada ao longo dos trabalhos que da formalização de processos ou da efetiva implantação ou implementação de qualquer modelo que seja, efetivamente, um padrão de mercado.
Foi verificado que a empresa conta com profissionais qualificados e de reconhecida competência técnica e que estas características podem estar sendo decisivas no cumprimento de projetos, o que ressalta o empenho e o esforço individual ou de uma determinada equipe conquanto fragiliza a cultura da sedimentação de processos.
Foram relatadas diversas situações em que desenvolvimentos de sistemas e de softwares voltados para projetos diferentes, por carecerem de um melhor gerenciamento de maneira que pudessem ser priorizados e integrados a programas e portfólios, sofreram atrasos e tiveram seus custos revisados para cima. Entre os entrevistados, é comum a sensação de que, mesmo quando há tempo excedente, o desdobramento das atividades e tarefas sejam regidas pela chamada Lei de Parkinson que, em linhas gerais, expressa a idéia de que o trabalho tem a propriedade de se expandir tanto quanto seja o tempo alocado para a sua realização.
Um outro aspecto, digno de nota, refere-se ao fato de que, embora haja a preocupação de se realizar a documentação de um processo, esta documentação, via de regra, acaba tendo validade somente para as atividades correntes e, com isso, raramente são consultadas ao término de um projeto. Este tipo de comportamento acarreta a dependência de reiteradas voltas ao ponto de partida, gerando retrabalho e inviabilizando a institucionalização de processos. Neste ponto, a introdução de metas e práticas, genéricas e específicas, preconizadas pelo CMMI, teria o potencial de reverter esta situação. As tabelas 08, metas e práticas genéricas do CMMI, tabela 10, planejamento de
35 projeto e tabela 11, monitoramento e controle de projetos, que constam na seção 5.3.2, detalham cada uma das metas e práticas específicas das áreas de processo que satisfazem o conjunto de soluções para o problema descrito.
A empresa faz uso de metodologias ágeis, especificamente, o SCRUM. Os benefícios desta forma de trabalho são apreciáveis, mormente, no que se refere à agilidade quando comparada a uma abordagem mais processual. A alta rotatividade do setor de TI, contudo, pode ser uma ameaça à boa marcha de um projeto. No desenrolar das pesquisas e das entrevistas na empresa, foi revelado que, por mais de uma vez, um planejamento de projeto teve de ser inteiramente revisto em função da perda de componentes-chave na equipe de desenvolvedores.
Assim, por tudo o que foi visto, a implementação de um modelo de maturidade para desenvolvimento de softwares traria consideráveis vantagens ao ambiente operacional da empresa, ajudando a estabelecer processos que promovessem uma cultura de perenidade de boas soluções de organização de tarefas e relacionamento com os stakeholders, adquiridas ou desenvolvidas no curso das atividades da empresa e, ainda, que focassem na melhoria contínua.
É neste contexto que a proposta de implementação do modelo CMMI se insere a fim de proporcionar à empresa X o estabelecimento de processos mais maduros que a habilite a atingir, com sucesso, os objetivos dispostos em seu planejamento estratégico.
5.3 Proposição da solução e aplicação de boas práticas
5.3.1 Escolha do modelo a ser implementado
A análise da empresa, conforme demonstrado na seção anterior, apontou para a necessidade de um melhor tratamento de seus processos de forma a adotar melhores práticas quanto ao gerenciamento de projetos e de requisitos de desenvolvimento de software. Consoante os objetivos deste trabalho, dois modelos, o CMMI-DEV e o MPS.BR, poderiam ser implementados na perspectiva de solucionar estes problemas. Os dois modelos apresentam semelhanças e diferenças.
36 Ambos são modelos bem conhecidos no cenário nacional e já com históricos de implementação em algumas empresas. O CMMI destaca-se por ser um modelo internacional, reconhecido no mundo todo. O MPS.BR é voltado, até o presente momento, para o mercado interno e com foco em pequenas e médias empresas. Os estágios evolutivos adotados por ambos estão representados, em paralelo, na tabela a seguir.
Tabela 05 – Análise Comparativa entre o CMMI e o MPS.BR Modelo de Maturidade
NÍVEL CMMI MPS.BR
1 Inicial Não é definido
2 Gerenciado G (Parcialmente Gerenciado) F (Gerenciado) 3 Definido E (Parcialmente Definido) D (Largamente Definido) C (Definido)
4 Gerenciado Quantitativamente B (Gerenciado Quantitativamente)
5 Otimizado A (Em Otimização)
Fonte: SOFTEX
Durante a pesquisa, a consulta a vários trabalhos com abordagens sobre a implementação de modelos de maturidade nas empresas brasileiras indicou que, quase sempre, a escolha pelo modelo MPS.BR vincula-se, sobretudo, ao aspecto financeiro e muitas vezes é adotada como estratégia para posterior implementação do modelo CMMI.
Assim sendo, presume-se que, nos níveis mais elevados do modelo MPS.BR, praticamente, haverá grande escassez de certificações. Um dos objetivos expressos da empresa X consiste na expansão de seus negócios, aí incluída, sua estratégia de exportar softwares para mercados externos ou mesmo produzir para clientes internos que condicionem a aquisição de produtos à certificação em CMMI. Ainda que haja equivalência entre níveis dos modelos considerados, a certificação em um deles não implica habilitação idêntica no outro. Pelos motivos expostos, este trabalho propõe a implementação do modelo CMMI-DEV, nos moldes que se seguem.
37
5.3.2 Implementando o CMMI-DEV
Para o CMMI, o nível 1 corresponde a um ambiente caótico e reativo, logo, onde não há processos definidos. Desta forma, a implementação proposta se dará no nível 2 do CMMI-DEV. Este nível é caracterizado por sete áreas de processos. Um área de processo é definida pelo CMMI como um conjunto de práticas relacionadas em uma área que, quando implementadas, coletivamente, satisfazem a uma série de objetivos considerados importantes na melhoria dessa área. Ao todo, o CMMI v1.3 possui 22 áreas de processo.
Tabela 06 – Áreas de Processo do CMMI-DEV
Fonte: Autor
NÍVEL ÁREAS DE PROCESSO
1
2
REQM – Gestão de Requisitos PP – Planejamento de Projeto
PMC – Monitoramento e Controle de Projeto SAM – Gestão de Contrato com Fornecedores CM – Gestão de Configuração
PPQA – Garantia da Qualidade de Processo e Produto MA – Medição e Análise
3
IPM – Gestão Integrada de Projeto RSKM – Gestão de Riscos
OPD – Definição dos Processos da Organização OPF – Foco nos Processos da Organização OT – Treinamento na Organização RD – Desenvolvimento de Requisitos TS – Solução Técnica PI – Integração do Produto VER - Verificação VAL - Validação
DAR – Análise e Tomada de Decisão 4
QPM – Gestão Quantitativa de Projetos
OPP – Desempenho dos Processos da Organização 5
OPM – Gestão do Desempenho da Organização CAR – Análise e Resolução de Causas
38 Uma vez que a implementação de um modelo de maturidade como o CMMI-DEV demanda consideráveis dispêndios de tempo e dinheiro, quanto melhor planejada for esta decisão, maiores serão as chances de êxito da empresa. Esta proposta de implementação, observando o fato de se tratar de uma pequena empresa, entende que uma abordagem preliminar, pautada pelo próprio esforço de conhecimento e assimilação do modelo CMMI é necessária e de vital importância para a organização.
As empresas de menor porte, conquanto possam, comparativamente, ser mais flexíveis e ágeis na adoção de novos modelos e métodos em relação às de maior porte, não dispõem de recursos suficientes para grandes aplicações. Neste sentido, verifica-se que,
Esse tipo de organização possui pouco poder de investimento, dificultando a aquisição de ferramentas automatizadas e a contratação de consultorias por um tempo muito longo, normalmente possuem poucas pessoas para darem suporte à implementação do modelo e o número de treinamento é pequeno. Nestes casos, é mais producente que a organização se familiarize um pouco mais sobre o modelo CMMI, sobre como implantar processos e gerenciar projetos antes de iniciar os trabalhos com consultoria. (SAMARINI, 2005)
Em conformidade com este pensamento, o cronograma abaixo foi elaborado com ênfase no tempo destinado à familiarização e assimilação do modelo de maturidade.
Tabela 07 – Cronograma de Ações CRONOGRAMA DE AÇÕES
ETAPA INÍCIO FIM
Abordagem e compreensão do CMMI 15 AGO 13 10 MAR 15 Diagnóstico dos processos da organização 15 AGO 13 15 NOV 13
Plano de adequação 15 NOV 13 30 MAR 14
Treinamento 30 MAR 14 30 JUN 14
Implementação de processos adequados 30 JUN 14 28 JAN 15
Pré-avaliação dos processos 01 JAN 15 30 MAR 15
Avaliação final 01 MAR 15 10 ABR 15
Fonte: Autor
O cronograma de ações é iniciado pela fase de abordagem e compreensão do modelo de maturidade, fase que o perpassará do início ao fim, já que a implantação de uma nova cultura demanda tempo e observação constante na modificação ou substituição de hábitos e formas de agir. Essa noção é importante, levando-se em consideração que, para se atingir o nível 2 do CMMI, 7 áreas de processo devem ser atendidas.
39 A etapa de análise dos processos da organização corresponde ao levantamento dos processos e da maneira de proceder, atualmente, desempenhados na Seção de Projetos. Tem por objetivo fornecer um quadro das práticas correntes na empresa, por meio do qual se possa, mais facilmente, identificar as causas e consequências dos resultados até então obtidos e, com isso, avaliar as medidas necessárias para alcançar as metas desejadas (gap analysis).
A fase posterior, em que se elaborará o plano de adequação, consiste na preparação efetiva das mudanças que serão implantadas tendo em vista a correção ou a adequação dos processos levantados na etapa anterior.
O treinamento será destinado à disseminação das práticas e dos conhecimentos que se quer implantar com a participação de todos os interessados e afetados pela implementação de uma nova cultura.
A fase de implementação abrange o período da passagem do plano à ação, onde se contará com a presença de especialistas e pessoas mais experientes na direção das práticas que serão implementadas. O CMMI possui, dentre seus componentes, metas (goals) e práticas (practices) que devem ser estabelecidas em conformidade com as áreas de processo a que se referem. Segundo Kulpa e Johnson (Kulpa, Johnson apud Cardoso, 2009), cada área de processo possui metas a serem cumpridas para atingir seu objetivo principal, podendo ser genéricas (generics), quando são comuns a todas as áreas de processo ou específicas (specifics), quando se referem a uma só área; já as práticas são as atividades necessárias para se atingir as áreas de processos. Em relação ao CMMI nível 2, a meta genérica refere-se à institucionalização de um processo gerenciado. Nas tabelas a seguir, estão especificadas a meta e as práticas genéricas do CMMI Nível 2 bem como todas as metas e práticas referentes a cada uma das áreas de processos do supracitado nível do CMMI. Visto que não haja obrigatoriedade da implementação de todas as metas e práticas recomendadas pelo CMMI, estão realçadas, nas tabelas a seguir, apenas aquelas que, no contexto da empresa X, presume-se serem as mais relevantes e de maior efetividade para o alcance dos objetivos propostos.
Tabela 08 – Metas e Práticas Genéricas do CMMI Nível 2 Meta e Práticas Genéricas do CMMI Nível 2 (Generic Practices)
Meta: Institucionalizar um processo gerenciado Prática Genérica 2.1 (GP 2.1) Estabelecer uma política organizacional Prática Genérica 2.2 (GP 2.2) Planejar o processo
Prática Genérica 2.3 (GP 2.3) Fornecer recursos
40 Prática Genérica 2.5 (GP 2.5) Treinar pessoas
Prática Genérica 2.6 (GP 2.6) Gerenciar configurações
Prática Genérica 2.7 (GP 2.7) Gerenciar e envolver as partes interessadas relevantes Prática Genérica 2.8 (GP 2.8) Monitorar e controlar o processo
Prática Genérica 2.9 (GP 2.9) Avaliar, objetivamente, a aderência
Prática Genérica 2.10 (GP 2.10) Revisar status com gerência de nível superior Fonte: SEI
Tabela 09 – Meta e Práticas Específicas da Área de Processos REQM Meta e Práticas Específicas da Gestão de Requisitos (REQM)
Meta Específica 1 (SG1): Gerenciar requisitos Prática Específica 1.1(SP 1.1) Obter entendimento dos requisitos
Prática Específica 1.2(SP 1.2) Obter comprometimento com os requisitos Prática Específica 1.3(SP 1.3) Gerenciar mudanças nos requisitos
Prática Específica 1.4(SP 1.4) Manter rastreabilidade bidirecional dos requisitos
Prática Específica 1.5(SP 1.5) Identificar inconsistências entre produtos de trabalho, planos de projeto e requisitos
Fonte: SEI
Tabela 10 – Metas e Práticas Específicas da Área de Processos PP Metas e Práticas Específicas de Planejamento de Projetos (PP)
Meta Específica 1 (SG1): Estabelecer estimativas Prática Específica 1.1(SP 1.1) Estimar o projeto do escopo
Prática Específica 1.2(SP 1.2) Estabelecer estimativas para atributos de produtos de trabalho e de tarefas
Prática Específica 1.3(SP 1.3) Definir ciclo de vida do projeto
Prática Específica 1.4(SP 1.4) Determinar estimativas de esforço e custo Meta Específica 2 (SG2): Elaborar um plano de projeto Prática Específica 2.1(SP 2.1) Estabelecer orçamento e cronograma
Prática Específica 2.2(SP 2.2) Identificar riscos do projeto Prática Específica 2.3(SP 2.3) Planejar gestão de dados Prática Específica 2.4(SP 2.4) Planejar recursos do projeto
Prática Específica 2.5(SP 2.5) Planejar habilidades e conhecimentos necessários Prática Específica 2.6(SP 2.6) Planejar o envolvimento das partes interessadas Prática Específica 2.7(SP 2.7) Estabelecer o plano do projeto
Meta Específica 3 (SG3): Obter comprometimento com o plano Prática Específica 3.1(SP 3.1) Revisar planos que afetam o projeto
Prática Específica 3.2(SP 3.2) Conciliar carga de trabalho e recursos Prática Específica 3.3(SP 3.3) Obter comprometimento com o plano Fonte: SEI
Tabela 11 – Metas e Práticas Específicas da Área de Processos PMC Metas e Práticas Específicas do Monitoramento e Controle de Projeto (PMC)
Meta Específica 1 (SG1): Monitorar o projeto em relação ao plano Prática Específica 1.1(SP 1.1) Monitorar os parâmetros do planejamento de projeto Prática Específica 1.2(SP 1.2) Monitorar compromissos
Prática Específica 1.3(SP 1.3) Monitorar riscos do projeto Prática Específica 1.4(SP 1.4) Monitorar a gestão de dados
Prática Específica 1.5(SP 1.5) Monitorar o envolvimento das partes interessadas Prática Específica 1.6(SP 1.6) Conduzir revisões de progresso
Prática Específica 1.7(SP 1.7) Conduzir revisões de marco
Meta Específica 2 (SG2): Gerenciar ações corretivas até sua conclusão Prática Específica 2.1(SP 2.1) Analisar questões críticas
Prática Específica 2.2(SP 2.2) Implementar ações corretivas Prática Específica 2.3(SP 2.3) Gerenciar ações corretivas Fonte: SEI
41 Tabela 12 – Metas e Práticas Específicas da Área de Processos SAM
Metas e Práticas Específicas de Gestão de Contrato com Fornecedores (SAM)
Meta Específica 1 (SG1): Estabelecer contratos com fornecedores Prática Específica 1.1(SP 1.1) Monitorar os parâmetros do planejamento de projeto Prática Específica 1.2(SP 1.2) Monitorar compromissos
Prática Específica 1.3(SP 1.3) Monitorar riscos do projeto
Meta Específica 2 (SG2): Cumprir contratos com fornecedores Prática Específica 2.1(SP 2.1) Executar contrato com fornecedor
Prática Específica 2.2(SP 2.2) Monitorar processos selecionados do fornecedor
Prática Específica 2.3(SP 2.3) Avaliar produtos de trabalho selecionados do fornecedor Prática Específica 2.4(SP 2.4) Aceitar produto adquirido
Prática Específica 2.5(SP 2.5) Transferir produtos Fonte: SEI
Tabela 13 – Metas e Práticas Específicas da Área de Processos MA Metas e Práticas Específicas de Medição e Análise (MA)
Meta Específica 1 (SG1): Alinhar atividades de medição e análise Prática Específica 1.1(SP 1.1) Estabelecer objetivos de medição
Prática Específica 1.2(SP 1.2) Especificar medidas
Prática Específica 1.3(SP 1.3) Especificar procedimentos de coleta e armazenamento de dados Prática Específica 1.4(SP 1.4) Especificar procedimento de análise
Meta Específica 2 (SG2): Fornecer resultados de medição Prática Específica 2.1(SP 2.1) Coletar dados resultantes de medição
Prática Específica 2.2(SP 2.2) Analisar dados resultantes de medição Prática Específica 2.3(SP 2.3) Armazenar dados e resultados
Prática Específica 2.4(SP 2.4) Comunicar resultados Fonte: SEI
Tabela 14 – Metas e Práticas Específicas da Área de Processos PPQA
Metas e Práticas Específicas da Garantia da Qualidade de Processo e Produto (PPQA)
Meta Específica 1 (SG1): Avaliar, objetivamente, processos e produtos de trabalho Prática Específica 1.1(SP 1.1) Avaliar, objetivamente, os processos
Prática Específica 1.2(SP 1.2) Avaliar, objetivamente, produtos de trabalho e serviços Meta Específica 2 (SG2): Fornecer visibilidade
Prática Específica 2.1(SP 2.1) Comunicar e assegurar solução de não-conformidades Prática Específica 2.2(SP 2.2) Estabelecer registros
Fonte: SEI
Tabela 15 – Metas e Práticas Específicas da Área de Processos CM Metas e Práticas Específicas de Gestão da Configuração (CM)
Meta Específica 1 (SG1): Estabelecer baselines Prática Específica 1.1(SP 1.1) Identificar itens de configuração
Prática Específica 1.2(SP 1.2) Estabelecer um sistema de gestão da configuração Prática Específica 1.3(SP 1.3) Criar ou liberar baselines
Meta Específica 2 (SG2): Acompanhar e controlar mudanças Prática Específica 2.1(SP 2.1) Acompanhar solicitações de mudança
Prática Específica 2.2(SP 2.2) Controlar itens de configuração
Meta Específica 3 (SG3): Estabelecer integridade Prática Específica 3.1(SP 3.1) Estabelecer registros de gestão da configuração Prática Específica 3.2(SP 3.2) Executar auditorias de configuração
42 As duas últimas etapas se constituem nas atividades derradeiras para a obtenção do grau de maturidade desejado. Elas serão compostas de avaliações de maneira a se verificar os níveis de aderência aos padrões do modelo. O método utilizado para avaliação do nível de maturidade em relação ao CMMI é o Standard CMMI Appraisal Method for Process Improvement (SCAMPI), uma forma de avaliação padronizada e rigorosa aplicada na certificação dos processos de melhoria do CMMI, segundo o site ISDBRASIL.
Abaixo, a tabela de desembolsos previstos apresenta uma estimativa dos custos de implementação na empresa.
Tabela 16 – Estimativa de Desembolsos Previstos TABELA DE CUSTOS
ÍTENS VALORES
Gastos com ferramentas, frameworks R$ 10.000,00
Consultorias R$ 40.000,00
Custos Indiretos (alimentação, horas extras, etc) R$ 10.000,00
Despesas Gerais R$ 10.000,00
Avaliação SCAMPI R$ 80.000,00
Total R$ 150.000,00
Fonte: Autor
5.3.2.1 O modelo IDEAL
Já foi dito neste trabalho que o CMMI tem por característica expressar o que fazer sem revelar como. Sendo assim, para implementá-lo, as organizações devem “traduzir” seus conceitos de acordo com suas necessidades (SAMARINI, 2005).
Esta lacuna, porém, pode ser preenchida por um modelo de ciclo de vida de processos conhecido pelo acrônimo IDEAL, desenvolvido em 1996 pelo SEI. Este modelo de melhoramento organizacional serve como um roteiro para iniciar, planejar e implementar ações de melhoria, subsidiando a organização na compreensão do esforço despendido para implementar as áreas de processo do CMMI.
Suas fases desdobram-se em:
Iniciando (Initiating): estimulo para a mudança;
Diagnosticando (Diagnosing): caracterização do estado atual e do desejado; Estabelendo (Establishing): estabelecimento de prioridades;
43 Agindo (Acting): criar solução;
Aprendendo (Learning): propor ações futuras.
5.3.2.1.1 Iniciando
No modelo IDEAL, este é o ponto de partida após o qual, o processo de melhoria é posto em marcha. No caso da empresa X, os estímulos que a deverão mover em direção a um processo de mudança estão relacionados às deficiências verificadas em seu ambiente organizacional: projetos atrasados, sobrecustos, falta de processos padronizados. A busca por maior qualidade, entregas confiáveis e previsibilidade de tempo e custos são outros aspectos relevantes.
É recomendável que a gerência da organização contextualize, de modo claro e objetivo, as ações que deverão ser tomadas em prol do programa de melhoria de processos.
Faz-se necessário, também, estabelecer mecanismos para gerenciar todos os detalhes de implementação e construir, desde o início, um patrocínio que dê credibilidade ao processo. Esse deverá se apoiar, sobretudo, no convencimento da alta gerência e na disponibilização dos recursos necessários.
5.3.2.1.2 Diagnosticando
Neste estágio, a questão central refere-se à caracterização pormenorizada do modus operandi da empresa, no momento em que ela se encontra e, a partir de então, descrever aonde se quer chegar.
Esta é a conjuntura que a empresa deverá analisar. Para isso, é indispensável que se avalie, atentamente, cada uma das sete áreas de processo que correspondem ao nível de maturidade que se quer alcançar.
5.3.2.1.3 Estabelecendo
Após ter iniciado o programa de melhoria de processos e haver diagnosticado a situação da empresa, parte-se para a elaboração de um plano detalhado em que se
44 estabelecerão as medidas que deverão ser tomadas de maneira a se alcançar os objetivos propostos. Nesta fase, são definidas as áreas que serão trabalhadas e quem serão os responsáveis por cada tarefa. Neste trabalho, que visa à implementação do nível 2 do CMMI, foi elaborada uma matriz RACI com a definição de papéis e responsabilidades pelas etapas que se desenrolarão no âmbito da empresa X.
Tabela 17 – Definição de Papéis e Responsabilidades MATRIZ RACI LEGENDA R = Responsible( Responsável ) A = Accountable( Aprovador ) C = Consulted( Consultado ) I = Informed( Informado ) AN = Analista de Negócio GP = Gerente de Projeto EC = Empresa de Consultoria GC = Gerente de Configuração GQ = Gerente de Qualidade ED = Equipe de Desenvolvimento ETAPAS AN GP EC GC GQ ED Diagnosticar os processos da empresa A R - C C C
Elaborar plano de adequação I A/R I C C C
Treinar a empresa A C R C C I Implementar CMMI A R C C C I Pré-avaliar os processos I R R C A C Encarregar-se da manutenção do modelo A R - C C I Fonte: Autor 5.3.2.1.4 Agindo
Neste momento, se coloca em prática o que foi planejado. Para a empresa X, o foco é a Seção de Projetos. Os problemas identificados no levantamento dos dados da organização apontavam para a necessidade de se estabelecer processos definidos e confiáveis e, ainda, de atribuir, de forma inequívoca, as responsabilidades inerentes a cada um dos envolvidos no processo de desenvolvimento de software.
De acordo com a abordagem desta fase, deverão ser realizados testes-pilotos, verificando-se, na prática, os resultados pretendidos e ajustá-los conforme a necessidade. A matriz RACI, mais uma vez, é eficiente na designação de atividades a seus respectivos responsáveis.
45 Para a Seção de Projetos, cada uma das áreas de processos correspondentes ao nível 2 do CMMI foi atribuída de modo a dar ciência do envolvimento de cada um nos processos abordados.
Tabela 18 – Designação das Áreas de Processo DESIGNAÇÃO DAS ÁREAS DE PROCESSO DO CMMI-N2
LEGENDA R = Responsible A = Accountable C = Consulted I = Informed AP = Área de Processo AN = Analista de Negócio GP = Gerente de Projeto ET = Equipe de Teste GC = Gerente de Configuração GQ = Gerente de Qualidade ED = Equipe de Desenvolvimento AP ATIVIDADE AN GP ET GC GQ ED REQM Entender e documentar, formalmente, as solicitações dos clientes e os propósitos e desenho do sistema que será criado. R A I C I C PP Definir e documentar os objetivos do projeto, as entradas e o produto final a ser entregue. I A/R I C I C Definir os responsáveis por cada etapa do processo de criação. I A/R I I I I Definir um cronograma para o projeto. I A/R I I I C PMC Reportar e acompanhar o andamento do projeto. A R I I I C Agir no caso de atrasos e reportar problemas e/ou atrasos para o cliente. A R I I C C PPQA Testar e documentar os testes realizados. I A R C I I
