Implementando CMMI em Empresas de Software

Universidade Federal Rural de Pernambuco
Departamento de Estatstica e Informtica
IMPLANTANDO CMMI EM EMPRESAS DE MANUTENO E

DESENVOLVIMENTO DE PRODUTOS DE SOFTWARE :
UM ESTUDO DE CASO
Matheus Benicio Rodrigues Evangelista
Recife
2014
Matheus Benicio Rodrigues Evangelista
IMPLANTANDO CMMI EM EMPRESAS DE MANUTENO E

DESENVOLVIMENTO DE PRODUTOS DE SOFTWARE :
UM ESTUDO DE CASO
Monografia apresentada ao Curso de

Bacharelado em Sistemas de Informao
da Universidade Federal Rural de
Pernambuco, como requisito parcial para
obteno do ttulo de Bacharel em
Sistemas de Informao.
Orientador: Profa. Dra. Ana Cristina Rouiller
Recife
2014
Dedico esse trabalho aos meus pais que sempre me apoiaram e acreditaram em mim e a toda
a equipe da SWQuality .
AGRADECIMENTOS
Deus, por ser a razo da minha vida.
Aos meus pais, meus maiores modelos de fora e coragem, as minhas irms, Ana Luiza,
Ana Carolina e toda a minha famlia. Obrigado pelo amor e incentivo que sempre me
deram.
Ao minha orientadora, professora, mentora, amiga Ana Rouiller, pela orientao, pelo
incentivo, ensinamentos, dedicao e apoio, o que fez com que eu conseguisse chegar onde
estou.
A Aninha, meu amor, pelo carinho, amor, ateno, pacincia e pelo seu inestimvel apoio,
estando sempre ao meu lado.
Aos meus amigos que estiveram comigo em toda essa jornada do curso! Em especial a
aqueles que estiveram comigo no s na faculdade, mas em todas as saidas de fim de semana,
madrugadas de dota e desenvolvimento de projetos: Bruno, Rodrigo e Victor.
Aos meus amigos e companheiros da SWQuality que foram essenciais na minha
caminhada: Ana, Heron, Guilherme, Srgio, Sandro, Mauricio, Carlos, Renata, Mery, Victor,
Mariana, Ea e Luiz. Em especial a Mauricio pelo apoio imensurvel, que fez com que eu
conseguisse finalizar o meu trabalho.
RESUMO
Esta dissertao descreve um estudo de caso sobre a implantao do nvel 2 de

maturidade do modelo "Capability Maturity Model Integration (CMMI)
Development utilizando mtodos geis, realizado no mbito dos trabalhos da
empresa SWQuality Consultoria e Sistemas. Inicialmente esta dissertao apresenta
uma reviso conceitual sobre rea de melhoria de processo e qualidade de
software, bem como uma introduo ao modelo CMMI. Apresenta uma viso geral
sobre mtodos geis e do framework Scrum. A seguir, relata como ocorreu a
implantao do modelo e os resultados obtidos pela empresa decorrente desta
implantao, apresentando o processo de desenvolvimento definido e os
documentos e controles criados para a utilizao deste processo. Alm de serem
mostradas as estratgias de implementao, o antes e aps CMMI e todas as
dificuldades inerentes execuo desta implementao, este trabalho tem como
principal objetivo procurar apurar se todos os resultados obtidos aps a
implementao satisfazem as exigncias do modelo de referncia e mapear os
beneficios obtidos pela organizao ao final do programa de melhoria.
ABSTRACT
This dissertation describes a case study on the deployment of Level 2 maturity model
Capability Maturity Model - Integration (CMMI ) - . Development using Agile
methods , performed in the work of the company SWQuality Consulting and Systems
Initially, this dissertation presents a conceptual review to the area of process
improvement and software quality , as well as an introduction to the CMMI model .
presents an overview of agile methods and Scrum framework . Herein, we report how
the implementation of the model and the results obtained by the company occurred
arising from this deployment, showing the process of development and set the
documents and controls designed for the use of this process . Besides being shown
deployment strategies , before and after the CMMI and all the difficulties inherent in
the implementation of this implementation , this work is main goal seek to ascertain
whether all the results obtained after the implementation meet the requirements of
the reference model and map the benefits obtained by the organization at the end of
the improvement program .
LISTA DE FIGURAS
Figura 1 - Viso do modelo IDEAL ............................................................................ 13

Figura 2 - Processo e seus Componentes ................................................................ 15
Figura 3 - CMMI: reas de Processo em duas Representaes: por Estgio e
Contnua .................................................................................................................... 17
Figura 4 - Scrum: Viso do Processo ........................................................................ 27
Figura 5 - Grfico Burndown ..................................................................................... 30
Figura 6 - Quadro Scrum ........................................................................................... 31
Figura 7 - Resultado do Gap Analysis ....................................................................... 36
Figura 8 - Backlog ..................................................................................................... 37
Figura 9 - Quadro de Atividades................................................................................ 38
Figura 10 - Ata de Planejamento de Sprint ............................................................... 40
Figura 11 - Checklist de Qualidade ........................................................................... 41
Figura 12 - Registro de No Conformidade .............................................................. 42
Figura 13 - Necessidades de medio e indicadores relacionados........................... 42
Figura 14 - Indicadores (parte 1) ............................................................................... 43
Figura 15 - Indicadores (parte 2) ............................................................................... 43
Figura 16 - Ciclo de Vida do Projeto .......................................................................... 44
Figura 17 - Plano de Projeto...................................................................................... 45
Figura 18 - Acompanhamento do Projeto .................................................................. 46
Figura 19 - Documentao do Projeto no Redmine .................................................. 47
Figura 20 - Grfico do Histrico de Revises do SVN ............................................... 48
Figura 21 - Baseline de Produto ................................................................................ 49
Figura 22 - Baseline de Projeto ................................................................................. 50
Figura 23 - Documentos Organizacionais mantidos no Redmine.............................. 51
Figura 24 - Resultado do segundo Gap Analysis Final ............................................. 52
LISTA DE QUADROS
Quadro 1 - Grau de atendimento das evidncias geradas s prticas especficas da

PA Project Planning .................................................................................................. 53
PA Project Monitoring and Control ............................................................................ 54
PA Requirement Management .................................................................................. 55
PA Measurement and Analysis ................................................................................. 56
PA Configuration Management ................................................................................. 57
PA Product and Process Quality Assurance ............................................................. 58
SUMRIO
1 INTRODUO ......................................................................................................... 9
1.1 Contextualizao e Motivao ........................................................................... 9
1.2 Objetivos e Justificativas .................................................................................. 11
1.3 Metodologia ..................................................................................................... 12
1.4 Organizao do Trabalho ................................................................................. 13
2 INTRODUO A PROCESSOS E AO MODELO CMMI ........................................ 14
2.1 Processos ........................................................................................................ 14
2.2 Modelo CMMI ................................................................................................... 15
2.2.1 Arquitetura do Modelo................................................................................ 16
2.2.2 Disciplinas do Modelo ................................................................................ 20
2.2.3 Elementos do Modelo ................................................................................ 23
3 FRAMEWORK SCRUM.......................................................................................... 25
4 RELATO DE EXPERINCIA DA IMPLANTAO DO NVEL 2 DO CMMI-DEV EM
UMA EMPRESA DE MANUTENO ....................................................................... 32
4.1 Objetivos e abordagem de melhoria ................................................................ 32
4.2 Caracterizao da Empresa ............................................................................. 33
4.3 Descrio do caso............................................................................................ 34
4.3.1 Diagnstico e planejamento ....................................................................... 34
4.3.2 Fase 1 ........................................................................................................ 36
4.3.3 Fase 2 ........................................................................................................ 44
4.3.4 Fase 3 ........................................................................................................ 47
4.3.5 Fase 4 ........................................................................................................ 50
4.3.6 Fase 5 ........................................................................................................ 51
4.4 Mapeamento dos resultados obtidos com o CMMI-DEV.................................. 52
4.5 Benefcios observados para a empresa ........................................................... 59
5 CONCLUSO......................................................................................................... 61
REFERNCIAS ......................................................................................................... 62
1 INTRODUO
Neste captulo introdutrio apresentado o contexto, no qual o trabalho est

inserido, a motivao, os objetivos, a metodologia utilizada e a estrutura em que o
mesmo foi descrito
1.1 Contextualizao e Motivao
Grande parte da populao mundial depende de aplicaes de software para

realizar suas atividades dirias [Rocha 2011]. Se alguns sistemas de uso global
deixarem de funcionar, aproximadamente 40% da populao mundial sofrer as
consequncias deste problema [Reed 2010]. Desta forma, a rea de software est
se tornando cada vez mais significativa na economia mundial. No entanto, o Brasil
est em stimo lugar nesse mercado, tendo movimentado cerca de 27 bilhes de
dlares, dedicados ao desenvolvimento, produo e distribuio de software e
prestao de servios com foco em software [ABES 2012]. Isso evidencia uma
oportunidade de crescimento, tanto do mercado interno quanto externo, vinculada
produo de software. Contudo, a insero do Brasil no mercado externo depende
de muitos fatores, dentre eles o reconhecimento por todos os players da qualidade
dos produtos de software brasileiros. A qualidade de produtos de software,
entretanto, est fortemente relacionada qualidade do processo de software
[Fuggetta 2000].
Durante esta dcada, ainda que tenham ajustado seus processos para a
produo de software de qualidade dentro dos prazos e oramentos confiveis, as
organizaes so pressionadas por seus concorrentes a reduzir substancialmente os
prazos para a entrega dos produtos. Organizaes que so capazes de integrar,
harmonizar e acelerar seus processos de desenvolvimento e manuteno de
software tem primazia no mercado [Curtis 2000]. nesse cenrio de aquecimento
que as metodologias de gesto mais avanada, visando obteno de qualidade e
agilidade nos projetos, emergem como um importante diferencial competitivo entre
os players, balizando cada vez mais as atividades do setor.
Atingir padres internacionais de qualidade e produtividade no setor de software
10
no Brasil condio essencial para a busca da competitividade mundial das

indstrias [MCT/SEITEC 2007]. Com esta motivao, inclusive, foram desenvolvidos
alguns programas como o Programa Brasileiro da Qualidade e Produtividade de
Software PBQP-Software. Este Programa procura estimular a adoo de normas,
mtodos, tcnicas e ferramentas da qualidade e da engenharia de software,
promovendo a melhoria da qualidade dos processos, produtos e servios de
software brasileiros, de modo a tornar as empresas mais capacitadas a competir no
mercado globalizado.
Desde 1993, entidades governamentais e no governamentais vm investindo
coerentemente na capacitao das empresas para a melhoria da qualidade e
produtividade em software. Em particular, obteve-se excelente resultado com o
projeto denominado Rumo ISO 9000, referenciado internacionalmente na revista
inglesa Quality Word do IQA (Institute of Quality Assurance) em novembro de 1995,
[Weber, 1995]. A mesma metodologia utilizada no projeto Rumo ISO 9000
(consrcio de empresas) vem sendo empregada na conduo de outros projetos
para qualificar empresas de software em CMM, CMMI, ISO/IEC 15504 e, mais
recentemente, no projeto MPS.BR, com o modelo MR-MPS.BR.
O Programa MPS.BR um exemplo claro do direcionamento do governo nesta
rea. O projeto foi criado em dezembro de 2003 sob a coordenao da Associao
para Promoo da Excelncia do Software Brasileiro (SOFTEX), que recebeu
incentivos considerveis do Banco Interamericano de Desenvolvimento (BID) US$
1,35 milho- e do Ministrio da Cincia e Tecnologia atravs do Consrcio de
Municpios/Cincia, Tecnologia e Inovao e possibilitou a melhoria efetiva de
processos de desenvolvimento de software em diversas empresas brasileiras.
Apesar dos esforos realizados at o momento, dados publicados pelo SEISoftware Engineering Institute demonstram o quanto a indstria de software nacional
precisa melhorar para atingir nveis elevados de maturidade. Segundo o SEI, em
2010, apenas 144 empresas no Brasil possuam certificao CMMI (Capability
Maturity Model Integration), sendo a grande maioria no nvel 2 de maturidade.
Traando um comparativo, na ndia, por exemplo, s no ano de 2010, mais de 400
empresas foram avaliadas por este modelo.
Os nmeros acima, ainda que demonstrem que a preocupao com qualidade e
adoo de padres internacionais de qualidade e produtividade apresente-se como
uma realidade da indstria nacional de software, transparece o fato de que, esta
11
uma realidade vivenciada por poucas empresas, uma vez que o total de empresas
de software existentes no Brasil aproximadamente 8.500 [ABES, 2009].
Alguns fatores que levam a esta realidade so:
Altos custos associados adoo de modelos padres da qualidade (CMMI e
MPS.BR) diante de recursos humanos e recursos financeiros limitados;
Adoo de planos, especificaes e documentaes no adequados
realidade das empresas para simplificar o processo de certificao e a conformidade

com os modelos;
Carncia de profissionais que dominem o conhecimento e possuam a
experincia prtica que permita acelerar o processo de qualificao das empresas,

em prazos adequados e a preos condizentes com sua capacidade financeira, e
especialmente produzindo melhoria nas empresas;
Falta e/ou pouca cultura em processos, falta de definio das metas
organizacionais e imaturidade metodolgica.

Neste cenrio, esse projeto tem como objetivo de avaliar um mtodo de
implantao do nvel 2 do CMMI , com o intuito de validar a metodologia. Com essa
validao, este trabalho pode apoiar em trabalhos futuros para consolidao do
mtodo que servir como ferramenta de apoio para empresas de pequeno e mdio
porte que so as principais empresas impactadas pelos fatores listados acima.
1.2 Objetivos e Justificativas
Este trabalho tem como objetivo de avaliar um mtodo de implantao do nvel 2

do CMMI , com o intuito de validar a metodologia utilizada pela SWQuality
Consultoria e Sistemas para implantao do nvel 2 do CMMI em empresas de
pequeno e mdio porte. A SWQuality uma empresa brasileira que iniciou suas
atividades no ano de 2003 oferecendo servios de consultoria, avaliao e
capacitao em Gesto de Projetos, Preparao para Certificao em processos de
Qualidade em Servios, Tecnologia da Informao e desenvolvimento de software.
Com essa validao, este trabalho pode apoiar em trabalhos futuros para
consolidao do mtodo, que servir como ferramenta de apoio para empresas de
pequeno e mdio porte.
12
1.3 Metodologia
Este trabalho foi desenvolvido utilizando o CMMI como modelo de qualidade de

processo e o IDEAL [IDEAL 2014] como modelo de melhoria de processo. Os
passos para criao do processo foram baseados nos 5 estgios(Figura 1) do
IDEALSM:
Iniciao (Iniating): foram feitas reunies para aprovao do trabalho na
empresa do estudo de caso e definio do modelo de processo a ser utilizado, em

seguida foram definidos os recursos necessrios;
Diagnstico (Diagnosing): foi feito um diagnstico da empresa no modelo
CMMI, identificando o nvel de aderncia;
Estabelecimento (Establishing): foi elaborado um plano de projeto, onde foram
identificadas as atividades necessrias para criao do processo, a sua durao e a

estratgia de desenvolvimento;
Ao (Action): foi executado e acompanhado o planejamento feito para o
trabalho;
Aprendizagem (Learning): a cada iterao eram analisados os pontos
negativos e positivos dos trabalhos realizados;
13
Figura 1 - Viso do modelo IDEAL
1.4 Organizao do Trabalho
Este trabalho encontra-se dividido em cinco captulos: Alm deste captulo de

Introduo, o Captulo 2 refere-se ao Modelo CMMI, sendo abordada sua origem,
objetivos e caractersticas. O Captulo 3 diz respeito ao framework SCRUM, que foi
utilizado como base para a implantao do programa de melhoria. No Captulo 4
apresentado o estudo de caso, o processo de definio e implementao do modelo
de maturidade CMMI, as estratgias e aes e aes tomadas, bem como os
estudos e observaes feitas com o objetivo de verificar se o resultado dessas aes
e estratgias atenderam as exigncias do modelo de referncia. No captulo 5 so
feitas diversas consideraes finais.
14
2 INTRODUO A PROCESSOS E AO MODELO CMMI
Neste captulo apresenta-se uma viso geral de Processos e do Modelo CMMI.
2.1 Processos
O conceito de processo quase que intuitivo. As engenharias comumente

descrevem processos como sendo diversas operaes pelas quais passa um
produto at ele ficar pronto[SOUZA 2004].
Algumas definies de processo seguem abaixo:
A NBR define processo como um conjunto de atividades inter-relacionadas,
que transforma entradas em sadas [ABNT 1994];
O IEEE (Institute of Electrical and Electronic Engineers) define Processo como
uma sequncia de passos realizados para um determinado propsito [IEEE 1990].

Esta definio pode ser aplicada a qualquer atividade, seja ela da manufatura ou
no.
Paulk [PAULK 1995] define Processo de Software como um conjunto de
atividades, mtodos, prticas e tecnologias que as pessoas utilizam para
desenvolver e manter software e seus produtos relacionados. A Figura 2 ilustra esta
definio.
15
Figura 2 - Processo e seus Componentes

Fonte: Autoria prpria.
Ainda segundo Paulk, considerando que o software resultado do processo de

desenvolvimento, espera-se que a sua qualidade seja altamente influenciada pela
qualidade do processo que o gera.
Focando-se somente no produto deixam-se de lado assuntos relacionados como
a escalabilidade, ou seja, o aumento do tamanho da equipe possui o risco de se
perder qualidade. Alm disso, no h a preocupao de como realizar melhor as
tarefas.
Focando-se no processo, prev-se a repetio de resultados, tendncias futuras
para os projetos, mantendo as caractersticas do produto. Um processo bem
controlado evita surpresas e minimiza os riscos.
2.2 Modelo CMMI
Grande parte do contedo terico desta seo foi retirada de [AGUIAR, 2004].
A sigla CMMI representa as iniciais de Capability Maturity Model Integration e
nomeia tanto um projeto, quanto os modelos resultantes deste projeto. O Projeto
16
CMMI, que pode ser traduzido como Projeto de Integrao dos Modelos de
Maturidade da Capacidade, est sendo executado pelo CMMI Institute em
cooperao com a indstria e governo, para consolidar um framework para modelos,
evoluir e integrar modelos desenvolvidos pelo SEI (inicialmente os modelos SWCMM, SE-CMM e IPD-CMM), e gerar seus produtos associados, incluindo material
de treinamento e mtodo de avaliao. Estes trs modelos que foram evoludos e
integrados inicialmente foram a verso 2.0 do SW-CMM (Capability Maturity Model
for Software), o SE-CMM: EIA 731 (System Engineering Capability Maturity Model) e
o IPD-CMM (Integrated Product Development Capability Maturity Model).
Esta integrao e evoluo tiveram como objetivo principal a reduo do custo da
implementao de melhoria de processo multidisciplinar baseada em modelos.
Multidisciplinar porque alm da engenharia de software, o CMMI cobre tambm a
engenharia de sistemas, aquisio, e a cadeia de desenvolvimento de produto. Esta
reduo de custo obtida por meio da eliminao de inconsistncias; reduo de
duplicaes, melhoria da clareza e entendimento, utilizao de terminologia comum,
utilizao de estilo consistente, estabelecimento de regras de construo uniforme,
manuteno de componentes comuns, garantia da consistncia com a Norma
ISO/IEC 15504.
2.2.1 Arquitetura do Modelo
A arquitetura do CMMI composta basicamente pela definio de um conjunto

de reas de processo, organizadas em duas representaes diferentes: uma como
um modelo por estgio, semelhante ao SW-CMM, e outra como um modelo contnuo
(semelhante ISO/IEC 15504). A verso atual composta por 25 reas de
processo, conforme ilustrado na Figura 3.
17
Figura 3 - CMMI: reas de Processo em duas Representaes: por Estgio e Contnua

Cada rea de processo definida no modelo por meio da descrio de seu

propsito, notas introdutrias, relacionamentos com outras reas, metas especficas,
metas genricas, prticas e subprticas especficas, prticas e subprticas
genricas, produtos de trabalho tpicos e referncias para outros elementos do
modelo relacionados.
Na representao por estgio, as 25 reas de processo esto agrupadas em 4
nveis de maturidade: nveis 2, 3, 4 e 5. O nvel 1 no contm nenhuma rea de
processo, e a nica exigncia para que a empresa de software seja qualificada neste
nvel a sua prpria existncia. Em relao a esta representao, o processo, de
desenvolvimento e manuteno, de software ou sistema de uma unidade
organizacional, pode estar classificado em um dos seguintes cinco nveis de
maturidade:
nvel 1: Inicial (Initial)
18
nvel 2: Gerenciado (Managed)
nvel 3: Definido (Defined)
nvel 4: Gerenciado Quantitativamente (Quantitatively Managed)
nvel 5: Otimizando (Optimizing)
Cada nvel de maturidade definido basicamente pelo conjunto de reas de

processo do nvel.
Na representao contnua, as mesmas 25 reas de processo esto agrupadas
em quatro grupos (gerncia de processos, gerncia de projetos, engenharia e
suporte) e so definidos seis nveis de capacidade de processo. Nesta
representao, o conjunto de atividades correspondente a cada uma destas reas
de processo, pode ter sua capacidade de execuo classificada em um dos
seguintes seis nveis de capacidade de processo:
nvel 0: Incompleto (Incomplete)
nvel 1: Executado (Performed)
nvel 2: Gerenciado (Managed)
nvel 3: Definido (Defined)
nvel 4: Gerenciado Quantitativamente (Quantitatively Managed)
nvel 5: Otimizando (Optimizing)
Cada nvel de capacidade definido por um conjunto de caractersticas que o

processo deve satisfazer para estar naquele nvel.
De forma semelhante ao que ocorre em relao ao modelo SW-CMM e futura
Norma ISO/IEC 15504, existem vrias intersees, relacionamentos e contribuies
do CMMI com a disciplina de gerncia de projetos. Entre elas podemos destacar
como talvez a mais relevante, o grupo de reas de processo de gerncia de projeto.
Este grupo est descrito na seo seguinte.
Na representao contnua da verso atual do CMMI, oito reas de processo
contm atividades relacionadas ao planejamento, acompanhamento e controle de
projetos. Por isto estas oito reas de processo compem o grupo de gerncia de
projeto:
Planejamento de Projeto (Project Planning PP)
Acompanhamento e Controle de Projeto (Project Monitoring and Control
PMC)
Gerenciamento de Acordo com Fornecedor (Supplier Agreement Management
SAM)
19
Gerenciamento Integrado de Projeto para IPPD (Desenvolvimento Integrado
de Produto e Processo) (Integrated Project Management for IPPD (Integrated

Development of Product and Process IPM for IPPD))
Gerenciamento de Riscos (Risk Management RSKM)
Construo Integrada de Equipes (Integrated Teaming IT)
Gerenciamento Integrado de Fornecedor (Integrated Supplier Management
ISM)
Gerenciamento Quantitativo de Projeto (Quantitative Project Management
QPM)
As reas de processo PP, PMC e SAM representam, na viso do CMMI, uma
gerncia bsica de projetos, compatvel com organizaes no nvel 2 de maturidade,
segundo a representao por estgio. Estas trs reas de processo definem
referncias para o estabelecimento e manuteno de planos de projeto e
comprometimentos,
acompanhamento
do
desempenho
real
do
projeto,
gerenciamento e execuo das aes corretivas, e gerenciamento dos acordos com

os fornecedores.
O planejamento iniciado com os requisitos definidos para o produto a ser
desenvolvido e do projeto para o desenvolvimento. Este plano cobre vrias
atividades da engenharia e do gerenciamento do projeto, incluindo o nvel
apropriado do acompanhamento do projeto, a freqncia das revises do progresso
e as medidas a serem utilizadas. O progresso determinado basicamente pelo
comparao do realizado em relao ao planejado. Quando o realizado desvia
significativamente do planejado, aes corretivas devem ser tomadas e gerenciadas
para resolver o problema. Estas aes podem envolver o replanejamento.
O gerenciamento dos acordos com os fornecedores realizado quando o projeto
decide adquirir componentes do trabalho de fornecedores. Quando este componente
identificado, um fornecedor que produza este componente selecionado e um
acordo estabelecido e mantido para gerenciar este fornecimento. O progresso e
desempenho do fornecedor so acompanhados. Testes e revises de aceitao so
conduzidos nos produtos e componentes fornecidos.
As reas de processo IPM, RSKM, IT, ISM e QPM representam, na viso do
CMMI, uma gerncia de projetos avanada, compatvel com organizaes nos nvel
3 e superiores de maturidade, segundo a representao por estgio. Estas cinco
reas de processo definem referncias para o estabelecimento de um processo
20
definido que adaptado do conjunto de processos padres; a coordenao e

colaboraes com os interessados, incluindo os fornecedores; o gerenciamento dos
riscos; a construo e manuteno de equipes integradas para a conduo dos
projetos; e o gerenciamento quantitativo do processo definido do projeto.
Em relao disciplina de gerncia de projeto, o modelo CMMI apresenta um
conjunto compreensivo de reas de processo para orientar a implantao e evoluo
das atividades desta gerncia. O CMMI evoluiu e ampliou as orientaes para
gerncia de projeto do SW-CMM e dos outros modelos precursores. A
representao como um modelo contnuo, consistente com a futura Norma ISO/IEC
15504, permite uma maior flexibilidade na utilizao das reas de processo,
facilitando a obteno de melhorias adicionais.
Como o objetivo do CMMI representar no modelo metas e recomendaes
genricas para orientar a melhoria dos processos em geral, no so descritas
solues prontas para serem executadas nas organizaes. Cabe a cada
organizao entender e interpretar estas orientaes no contexto, objetivo e
estratgia de negcio da organizao para obter melhorias relevantes.
2.2.2 Disciplinas do Modelo
O objetivo do CMMI ser um framework extensvel, para poder acrescentar

novas disciplinas. Cada modelo do CMMI inclui uma ou mais disciplinas, de forma
integrada. Atualmente os modelos do CMMI cobrem 4 disciplinas:
Engenharia de Sistemas (System Engineering SE)
Engenharia de Software (Software Engineering SW)
Desenvolvimento de produtos e processos integrados (Integrated Product and
Process Development IPPD)
Aquisio (Supplier Sourcing SS)
Conforme resumido na Figura 2.2, apresentada anteriormente, a base dos

modelos CMMI so as reas de processo, que so organizadas em nveis de
maturidade (na representao por estgio) e em categorias de processo (na
representao contnua).
21
Na representao por estgio, as reas de processo so organizadas por quatro

nveis de maturidade. A seguir esto relacionadas as reas de processo em cada
nvel de maturidade. Cada rea de processo identificada por uma sigla (baseada
no nome em ingls), uma traduo do nome para o portugus e o nome original em
ingls:
Nvel 2:
REQM: Gesto de Requisitos (Requirements Management)
PP: Planejamento de Projeto (Project Planning)
PMC: Acompanhamento e Controle de Projeto (Project Monitoring and Control)
SAM: Gesto de Acordos com Fornecedores (Supplier Agreement Management)
CM: Gesto de Configurao (Configuration Management)
PPQA: Garantia da Qualidade de Processo e Produto (Process and Product
Quality Assurance)
MA: Medio e Anlise (Measurement and Analysis)
Nvel 3:
RD: Desenvolvimento de Requisitos (Requirements Development)
TS: Soluo Tcnica (Technical Solution)
PI: Integrao de Produto (Product Integration)
VER: Verificao (Verification)
VAL: Validao (Validation)
OPF: Foco no Processo Organizacional (Organizational Process Focus)
OPD: Definio do Processo Organizacional (Organizational Process Definition)
OT: Treinamento Organizacional (Organizational Training)
IPM: Gesto Integrada de Projeto (Integrated Project Management)
RSKM: Gesto de Riscos (Risk Management)
DAR: Anlise de Deciso e Resoluo (Decision Analysis and Resolution)
Nvel 4:
QPM: Gesto Quantitativa de Projeto (Quantitative Project Management)
OPP: Desempenho do Processo Organizacional (Organizational Process
Performance)
Nvel 5:
CAR: Anlise de Causa e Resoluo (Causal Analysis and Resolution)
OID: Inovao e Melhoria Organizacional (Organizational Innovation and
Deployment)
22
Na representao contnua, as reas de processo so organizadas em quatro

categorias de processo. A seguir esto relacionadas as reas de processo em cada
categoria de processo. Cada rea de processo identificada por uma sigla (baseada
no nome em ingls), uma traduo do nome para o portugus e o nome original em
ingls:
Categoria Gesto de Projeto:
PP: Planejamento de Projeto (Project Planning)
PMC: Acompanhamento e Controle de Projeto (Project Monitoring and Control)
SAM: Gesto de Acordos com Fornecedores (Supplier Agreement Management)
IPM: Gesto Integrada de Projeto (Integrated Project Management)
RSKM: Gesto de Riscos (Risk Management)
QPM: Gesto Quantitativa de Projeto (Quantitative Project Management)
Categoria Gesto de Processo:
OPF: Foco no Processo Organizacional (Organizational Process Focus)
OPD: Definio do Processo Organizacional (Organizational Process Definition)
OT: Treinamento Organizacional (Organizational Training)
OPP: Desempenho do Processo Organizacional (Organizational Process
Performance)
OID: Inovao e Melhoria Organizacional (Organizational Innovation and
Deployment)
Categoria Engenharia:
REQM: Gesto de Requisitos (Requirements Management)
RD: Desenvolvimento de Requisitos (Requirements Development)
TS: Soluo Tcnica (Technical Solution)
PI: Integrao de Produto (Product Integration)
VER: Verificao (Verification)
VAL: Validao (Validation)
Categoria Apoio:
CM: Gesto de Configurao (Configuration Management)
PPQA: Garantia da Qualidade de Processo e Produto (Process and Product
Quality Assurance)
MA: Medio e Anlise (Measurement and Analysis)
CAR: Anlise de Causa e Resoluo (Causal Analysis and Resolution)
DAR: Anlise de Deciso e Resoluo (Decision Analysis and Resolution)
23
Em relao ao SW-CMM, o CMMI por estgio uma reviso deste modelo, com
ajustes. No nvel 2 de maturidade, por exemplo, foi includa a rea de processo de
medio e anlise como uma ampliao deste assunto, que j era coberto em parte
em cada rea do SW-CMM. No nvel 3, por exemplo, a rea de engenharia de
produto do SW-CMM foi melhor descrita por meio de cinco reas de processo:
Desenvolvimento
de
Requisitos,
Soluo
Tcnica,
Integrao
de
Produto,
Verificao, e Validao. Outras mudanas ocorrem para refletir melhor a orientao

para atendimento dos nveis de maturidade.
Em relao utilizao para melhoria de processo, o CMMI por estgio sugere
abordagens semelhantes quelas utilizadas com sucesso com o SW-CMM. Em
relao ao CMMI contnuo, a tendncia toda a experincia de utilizao da
ISO/IEC 15504, ser aproveitada para ajustar as abordagens j utilizadas com
sucesso pelo SW-CMM.
2.2.3 Elementos do Modelo
Os elementos que compe o modelo CMMI so agrupados em trs categorias

que refletem como eles devem ser interpretados:
Elementos Requeridos: Metas especficas e as genricas so elementos
requeridos do modelo. Estes elementos devem ser estabelecidos pelos processos
definidos, e implementados pela organizao. So essenciais para avaliar a
satisfao de uma rea de processo. O estabelecimento (ou satisfao) das metas
usado em avaliaes como base para satisfao da rea de processo e maturidade
organizacional. Apenas a declarao das metas um elemento requerido do
modelo, o ttulo e qualquer nota associada so considerados elementos informativos
do modelo.
Elementos Esperados: Prticas especficas e as genricas so elementos
esperados no modelo. Estes elementos descrevem o que uma organizao
tipicamente ir implementar para satisfazer um componente requerido. Servem como
guia para aqueles que implementam melhorias e ou executam avaliaes. As
prticas descritas, ou as alternativas aceitveis para elas, espera-se que estejam
presentes nos processos planejados e implementados da organizao antes que as
24
metas sejam consideradas satisfeitas. Apenas a declarao da prtica um

elemento esperado do modelo, o ttulo e qualquer nota associada so considerados
elementos informativos do modelo.
Componentes
Informativos:
Subprticas,
produtos
de
trabalho
tpicos,
particularidades da disciplina, elaboraes de prticas genricas, ttulos, notas e

referncias so elementos informativos do modelo. Estes elementos ajudam o
usurio do modelo a entender as metas e prticas e como elas podem ser
estabelecidas, fornecendo detalhes para ajudar a comear a pensar em como
estabelecer as prticas e metas.
Caractersticas comuns so elementos no classificados do modelo, apenas
constituem um grupo que fornece uma maneira de apresentar as prticas genricas.
Quando se usa um modelo CMMI como guia, processos so planejados e
implementados em conformidade com os elementos esperados e requeridos das
reas de processo. Conformidade com uma rea de processo significa que nos
processos planejados e implementados existe um processo associado (ou
processos) que enderea as prticas especficas e genricas da rea de processo,
ou alternativas, que geram um resultado de acordo com a meta associada com
aquela prtica especfica ou genrica.
25
3 FRAMEWORK SCRUM
Dentre as vrias metodologias geis existentes, podemos destacar o XP, do

ingls,
Extreme
Programming
(BECK,
2000)
Lean
Development
(POPPENDIECK, 2003) para o desenvolvimento de software, e o Scrum, para o

gerenciamento de projetos, como as mais citadas em artigos e livros sobre o tema.
O Scrum foi criado na empresa de fabricao de automveis e produtos Toyota
por Takeuchi e Nonaka e a primeira utilizao do termo ocorreu no livro "The New
Product Development Game" (TAKEUCHI & NONAKA, 1986). Eles notaram que
projetos usando equipes pequenas e multidisciplinares (cross-functional) produziam
os melhores resultados, e associaram estas equipes altamente eficazes formao
do Scrum, uma jogada do Rugby, esporte coletivo semelhante ao futebol americano.
Jeff Sutherland documentou, concebeu e implantou o Scrum na empresa Easel
Corporation, em 1993, incorporando estilos de gerenciamento observados por
Takeuchi e Nonaka. Em 1996, Ken Schwaber formalizou a definio de Scrum e
ajudou a implant-lo no gerenciamento de projetos de software ao redor do mundo.
Desde ento, o Scrum se tornou uma das principais alternativas s metodologias
tradicionais. O Scrum tem sido adotado por gestores que buscam garantir a
obteno do melhor produto possvel e por engenheiros que buscam garantir que
faro seu trabalho da melhor forma possvel, sendo usado em milhares de projetos
por todo o mundo (SCHWABER & BEEDLE, 2002).
O Scrum uma evoluo na forma de se pensar e desenvolver projetos de
software, mantendo sempre o foco na relao entre os principais envolvidos no
processo de desenvolvimento: o desenvolvedor, o gestor e o cliente. O uso de
Scrum implica na colaborao e cumplicidade entre todas as reas, dando a TI a
visibilidade de apoiadora, viabilizadora e aliada.
No h a definio de um mtodo especfico para o desenvolvimento do software
no Scrum, mas so definidas regras e prticas de gesto que devem ser adotadas
para garantir o sucesso de um projeto. As anlises de estudos de caso como os
apresentados por KNIBERG (2007), QUMER (2008) e (CHENG, 2009) mostram que
a utilizao de um mtodo bem definido para implantao das prticas do Scrum
pode aumentar a agilidade no desenvolvimento e trazer um maior retorno do
investimento realizado no projeto em menos tempo.
26
O Scrum fundamentado na teoria de controle de processos empricos e

emprega uma abordagem iterativa e incremental para aperfeioar a previsibilidade e
controlar riscos. Seguindo esta abordagem, tem-se a produo frequente de
incrementos que podem ser testados, ajustados, documentados e expandidos e para
tal,
as
iteraes
devem
ser
curtas
para
promover
visibilidade
para
desenvolvimento. Trs pilares sustentam qualquer implementao de controle de

processos empricos, so eles: transparncia, inspeo e adaptao.
O primeiro pilar a transparncia que garante que aspectos do processo que
afetam o resultado devem ser visveis para aqueles que gerenciam os resultados.
Esses aspectos no apenas devem ser transparentes, mas tambm o que est
sendo visto deve ser conhecido. Isto , quando algum que inspeciona um processo
acredita que algo est pronto, isso deve ser equivalente definio de pronto
utilizada.
O segundo pilar a inspeo, pois diversos aspectos do processo devem ser
inspecionados com uma frequncia suficiente para que variaes inaceitveis no
processo possam ser detectadas. A frequncia da inspeo deve levar em
considerao que qualquer processo modificado pelo prprio ato da inspeo. O
problema acontece quando a frequncia de inspeo necessria excede a tolerncia
do processo inspeo. Os outros fatores relacionados so a habilidade e a
aplicao das pessoas em inspecionar os resultados do trabalho.
A adaptao o terceiro pilar, pois muitas vezes a partir da inspeo,
observado que um ou mais aspectos do processo esto fora dos limites aceitveis e
que consequentemente o produto resultante ser inaceitvel. Neste caso, ajustes
devero ser feitos no processo ou no software sendo desenvolvido. Esses ajustes
devem ser efetuados o mais rpido possvel para minimizar desvios posteriores.
Existem trs pontos para inspeo e adaptao em Scrum. A Reunio Diria
utilizada para inspecionar o progresso em direo Meta da Sprint (tempo de 2 a 4
semanas onde o software desenvolvido) e para realizar adaptaes que otimizem
o valor do prximo dia de trabalho. Alm disso, as reunies de Reviso de Sprint e
de Planejamento de Sprint so utilizadas para inspecionar o progresso em direo
Meta da Verso para Entrega e para fazer as adaptaes que otimizem o valor da
prximo Sprint.
Finalmente, a Retrospectiva da Sprint utilizada para revisar o Sprint passado e
definir que adaptaes tornaro a prxima Sprint mais produtiva, recompensadora e
27
gratificante. A Figura 4 demonstra a viso geral do processo.
Figura 4 - Scrum: Viso do Processo
Equipes Scrum so projetadas para otimizao, flexibilidade e produtividade.

Para isso, eles so auto-organizveis, multifuncionais e trabalham em interaes. A
auto-organizao um aspecto essencial no Scrum, pois permite que a equipe se
auto gerencie, aperfeioando a colaborao, aumentando a moral da equipe, alm
de aumentar a motivao e responsabilidade no cumprimento dos prazos. Segundo
(SCHWABER & BEEDLE, 2002), cada equipe Scrum possui trs papis:
O Scrum Master responsvel por garantir que o Scrum seja compreendido e
seguido na empresa, remover impedimentos (elementos que estejam impedindo o
time de completar uma tarefa) e auxiliar o time a ser auto-organizvel. O Scrum
Master no faz parte do time e no o gerencia;
O Product Owner (Dono do Produto) responsvel por maximizar o valor do
trabalho do time Scrum atravs da priorizao dos itens do Backlog do Produto (lista
de funcionalidades que sero desenvolvidas no projeto) e garantir a sua visibilidade.
importante que este papel seja realizado por apenas uma pessoa por projeto de
forma que no haja divergncias e conflitos de opinies. O Product Owner pode ser
aconselhado por outras pessoas, mas ele quem tem a palavra final;
O Time realiza o trabalho, transformando os itens do Backlog do Produto em
incrementos de produto potencialmente entregveis a cada Sprint, devendo ser
interdisciplinar, sem ttulos e auto-organizvel. O tamanho do time deve ser de 5 a 9
pessoas, de forma a otimizar a comunicao e produtividade.
28
Scrum emprega os eventos com durao fixa (time-boxes) para criar regularidade
e facilitar o controle, dentre esses eventos temos: a reunio de planejamento de
release, a reviso da Sprint, a retrospectiva da Sprint e a reunio diria, detalhadas
a seguir.
A Reunio de Planejamento do Release tem como objetivo estabelecer um plano
de metas para a release (grupo de Sprints necessrios para atingir uma meta),
maiores prioridades do Backlog do Produto, os principais riscos e funcionalidades
que devero estar contidas no release e uma data de entrega e custo provveis se
houverem poucas alteraes. Esta reunio a nica opcional, mas importante
para reduzir os impedimentos durante os Sprints;
A Sprint o corao do Scrum. Consiste em uma iterao de duas a quatro
semanas de durao, onde ocorre o esforo de desenvolvimento. Todas as Sprints
utilizam o mesmo modelo de Scrum e todas as Sprints tm como resultado um
incremento do produto final que potencialmente entregvel. Cada Sprint comea
imediatamente aps a anterior;
A Reunio de Planejamento da Sprint o momento no qual a iterao
planejada. Tem um time-box de 5% do tempo do Sprint e dividida em duas partes.
Na primeira, com o auxlio do Product Owner(PO), o time define o que vai ser feito
no Sprint. Na segunda parte, o time entende como desenvolver cada item do
Backlog do Produto. Nesta reunio, o PO tambm define a meta da Sprint;
A Reviso da Sprint tambm possui um time-box de at 5% do tempo da Sprint.
a reunio onde o time mostra ao PO o que foi realizado e responde a
questionamentos. Neste momento, o PO aceita ou rejeita o resultado de cada estria
do Sprint e gera discusses que servem como entradas para o planejamento dos
Sprints seguintes;
A Retrospectiva da Sprint ocorre aps a Reviso da Sprint e onde o time revisa
o modelo de trabalho e prticas do processo de forma a adapt-lo para um melhor
aproveitamento. O resultado desta reunio uma lista de itens que foram realizados
com sucesso e outra dos que devem ser melhorados para o prximo Sprint;
A Reunio Diria onde o time se encontra diariamente para uma reunio de 15
minutos como uma forma de melhorar a comunicao, eliminar outras reunies,
identificar e remover impedimentos e melhorar o conhecimento de todos sobre o
andamento do projeto. Nela, cada membro do time responde a trs perguntas: 1) O
que ele realizou desde a ltima reunio diria; 2) o que ele vai fazer antes da
29
prxima reunio diria; e 3) quais os obstculos esto em seu caminho. Ela no

uma reunio de Status para o Scrum Master. A reunio diria serve como uma
inspeo do time sobre o cumprimento da meta estabelecida para o Sprint. parte
importante do processo de inspeo e adaptao do Scrum.
Scrum utiliza trs artefatos principais, que so o Backlog do Produto, Backlog da
Sprint e o Sprint Burndown.
O Backlog do Produto uma lista priorizada de tudo que pode ser necessrio no
produto. medida que o projeto e o produto a ser desenvolvido evoluem mais itens
podem ser acrescentados ou removidos. Um item do Backlog do Produto chamado
de estria. Ele deve ser constantemente atualizado e priorizado pelo Product Owner.
O Backlog da Sprint uma lista de tarefas para transformar os itens do Backlog
do Produto que tenham maior prioridade, no perodo de um Sprint, em um
incremento de produto a ser entregue. O time responsvel por criar e estimar as
tarefas do Backlog do Sprint na reunio de planejamento do Sprint, e, se necessrio
criar ou remover tarefas durante a execuo do Sprint. O Backlog da Sprint sempre
deve conter tarefas que derivem de estrias que auxiliem a atingir a meta do Sprint.
O grfico Sprint Burndown mede os itens do Backlog da Sprint restantes ao longo
do tempo de um Sprint. O Sprint Burndown, mostrado na Figura 5, um grfico que
possui, no eixo x o nmero de dias da Sprint e no eixo y a estimativa de horas do
time para completar todas as estrias selecionadas para o Sprint. Este nmero de
horas vai caindo medida que algumas estrias so concludas (linha irregular do
grfico). Uma linha traada do maior valor de X at o maior valor de Y que serve
como guia da produtividade do time (SCHWABER & SUTHERLAND, 2009).
30
Figura 5 - Grfico Burndown
Outro artefato importante para o time o quadro Scrum. Ele mostra todo o
trabalho
que
est
sendo
realizado
dentro
do
Sprint,
sendo
atualizado
constantemente no decorrer deste. Tarefas podem ser adicionadas ou removidas e

estimativas podem ser modificadas. Na maior parte dos casos, junto com as tarefas
que esto sendo realizadas, tambm ficam no quadro Scrum a meta do Sprint,
definida pelo Product Owner, os Impedimentos problemas que o time no
consegue resolver internamente, precisando de auxlio externo e o grfico de
Sprint Burndown.
O quadro Scrum, tradicionalmente, composto por trs colunas: To Do, Doing e
Done; pelo objetivo do Sprint: uma frase que guia o desenvolvimento do time e o
aceite das estrias; um grfico de burndown, que auxilia na medio da velocidade
do time durante o Sprint e gerenciamento de riscos; itens no planejados, como
correes de bugs; e itens extras para o caso de o time finalizar as tarefas antes do
31
planejado. A Figura 6 demonstra um quadro Scrum tpico.
Figura 6 - Quadro Scrum
32
4 RELATO DE EXPERINCIA DA IMPLANTAO DO NVEL 2 DO CMMI-DEV

EM UMA EMPRESA DE MANUTENO
Neste captulo descrito um relato de implementao do Nvel de Maturidade 2

do CMMI-DEV utilizando conceito da metodologia Scrum, em um empresa de
software de pequeno porte. A abordagem utilizada foi desenvolvida pela empresa
SWQuality, e por questes de propriedade intelectual, as diretrizes e detalhes da
implementao desta abordagem no so descritas.
Este captulo apresenta, inicialmente, os objetivos e a estratgia do projeto de
melhoria de processo realizado; descreve o cenrio da empresa em que o projeto de
melhoria foi realizado; relata a execuo do projeto de melhoria, com exemplos de
evidncias geradas e por fim faz um mapeamento entre as evidncias desenvolvidas
e as Prticas especficas do Nvel 2 do CMMI-DEV.
A fim de zelar pela confidencialidade das informaes, no sero disponibilizados
dados que identifiquem pessoas, produtos ou organizaes.
4.1 Objetivos e abordagem de melhoria
O projeto de melhoria de processo descrito neste captulo teve como principal

objetivo a implementao do Nvel 2 de Maturidade do CMMI-DEV em uma empresa
de desenvolvimento e manuteno de software do Estado da Paraba. Dado que o
objetivo do projeto era o Nvel 2 do CMMI, o projeto adotou como metas a definio
e institucionalizao das reas de Processo (PA):
Planejamento do Projeto - Project Planning (PP);
Monitoramento e Controle do projeto - Project Monitoring and Control (PMC);
Gesto de Requisitos - Requirement Management (REQM);
Medio e Anlise - Measurement and Analysis (MA);
Gerncia de Configurao - Configuration Management (CM);
Garantia da Qualidade - Process and Product Quality Assurance (PPQA);
Para isto, a equipe de consultores responsvel empregou uma metodologia de

implantao de melhoria de processo baseada no modelo IDEAL, realizando ciclos
bimestrais de melhoria (conforme descrito na subseo 4.3).
33
Desde o incio do projeto, foi levado em conta que esta implementao do

modelo de maturidade de processos de desenvolvimento de software iria ser uma
mudana muito grande no dia-a-dia e no modo de trabalho dos colaboradores da
empresa e, tambm, que iria ser encontrada muita resistncia por parte dos
mesmos..
De modo a tentar combater estes problemas foi determinado que a definio dos
processos e criao de documentos fossem o mais de acordo possvel com as
pretenses e necessidades de trabalho dirias de todos os colaboradores, ou seja,
seria definido um processo de mudana mas com o mnimo de impacto na sua forma
de trabalho diria na organizao. Todas as definies foram feitas com o feedback
de todos os membros da organizao.
A estratgia definida foi a de tentar definir e criar apenas a documentao
necessria e mnima que permitisse dar resposta aos processos do nvel 2 do CMMI.
4.2 Caracterizao da Empresa
A empresa alvo deste estudo uma empresa de pequeno porte da Paraba, que
atua no desenvolvimento e manuteno de software, fornecendo solues para
gesto de vendas, estoque, emisso de notas atravs de um portflio de produtos
mantidos. Tem uma extensa base de clientes ( tem domnio de 7% dos clientes em
seu segmento de mercado). As principais tecnologias adotadas so Delphi, PHP e
Javascript.
A empresa estruturada nos seguintes setores:
Atendimento (2 pessoas): Registra chamados de cliente e abre ocorrncias;
Suporte (6 pessoas): Atende ocorrncias e identifica bugs dos produtos;
Teste (1 pessoa): Analisa se as ocorrncias reportadas pelo suporte so bugs
e os encaminha ao desenvolvimento quando necessrio;
Desenvolvimento (4 pessoas): Responsvel pela manuteno e evoluo dos
produtos
Em relao ao desenvolvimento, foco do trabalho de melhoria de processo neste
contexto, os principais problemas apontados eram:
Necessidade de organizao do trabalho;
34
Falta de visibilidade;
Insatisfao dos clientes;
Adaptao as mudanas;
Atraso na liberao de verses;
Interferncias externas.
4.3 Descrio do caso
A execuo do projeto de melhoria de processo foi organizado em 6 etapas,

sendo uma etapa inicial de diagnstico e planejamento, e cinco ciclos de
implantao da melhoria (Fase 1 a Fase 5) adotando os princpios do modelo IDEAL,
com periodicidade bimestral. Cada etapa descrita, nas subsees a seguir, a
respeito de seus objetivos, resultados, dificuldades e lies aprendidas.
4.3.1 Diagnstico e planejamento
Para elaborar o planejamento das atividades e saber o estado da empresa, com

relao aos elementos requeridos no nvel 2 do modelo CMMI, foi feito um
diagnstico, levantando todos os pontos de melhoria, considerando os processos
atuais existentes na organizao.
Para realizao do diagnstico foi feito um Gap Analysis. O Gap Analysis um
estudo formal do que o negcio faz e onde se quer posicionar no futuro. conduzido
na perspectiva da organizao, da direo ou processos do negcio e/ou das
tecnologias da Informao.
O objetivo de um Gap Analysis encontrar as diferenas entre as prticas em
uso numa dada organizao e o guia dado por um modelo de referncia, neste caso
o CMMI, ou seja, uma ferramenta que permite a organizao determinar,
documentar e aprovar a varincia entre a sua performance atual e os requisitos do
negcio. Tal anlise pode ser feita a um nvel operacional ou estratgico.
Foi realizado um Gap, considerando as reas de processo do nvel 2 do modelo
35
CMMI, cujo seu propsito foi: (i) identificar das prticas da engenharia e gesto
usadas no desenvolvimento do software e atividades de manuteno; (ii) identificar
pontos fortes e pontos de melhoria nos processos da organizao; (iii) identificar o
grau de satisfao para as reas de processo examinadas e (iv) estabelecer
recomendaes e aes a serem tomadas para a melhoria dos processos.
O Gap contemplou as atividades da equipe de desenvolvimento (manuteno e
evoluo dos produtos da organizao), assim participaram do diagnstico como
entrevistados:
1 Diretor de TI;
1 Gerente de desenvolvimento;
4 Desenvolvedores;
1 Testador
Neste diagnstico, constatou-se que a organizao encontrava-se no Nvel 1

(Inicial) de maturidade do modelo CMMI. O diagnstico constatou que as prticas
realizadas pela empresa eram insatisfatrias em relao ao esperado para o Nvel 2
do CMMI, sendo as prticas relacionadas a PPQA as mais crticas, seguida pelas
prticas de MA, PMC, PP, CM e REQM. O resultado da aderncia entre as prticas
observadas no diagnstico e as recomendaes do CMMI pode ser observado na
Figura 7.
36
Figura 7 - Resultado do Gap Analysis
Foi observado que a PA SAM (Software Acquisition Management - Gesto de

Aquisio de Software) no se aplicava aos negcios da empresa, assim no foi
avaliada durante o Gap Analysis realizado. Uma vez que uma prtica no
obrigatria em uma avaliao oficial do nvel 2 do CMMI, a excluso desta PA no
traz impactos ao projeto de melhoria de processo realizado.
Com base no resultado identificado, um plano de melhoria foi estabelecido
definindo uma estratgia para a implantao do CMMI na empresa.
4.3.2 Fase 1
As metas definidas para a primeira fase foram
a implantao do Scrum, a
implantao de uma ferramenta gerencial para registro e acompanhamento de

atividades, a institucionalizao de auditorias de qualidade sobre as atividades do
Scrum e a definio de um conjunto de indicadores.
Nesta fase, os processos do setor de desenvolvimento foram reformulados
conforme o programa de melhoria da qualidade utilizando como referncia
metodologias geis. Foi ministrado um curso introdutrio da metodologia Scrum e
depois um acompanhamento da introduo e adaptao da metodologia no
ambiente da empresa.
O primeiro passo foi definir os papeis e responsabilidades necessrios para
execuo do Scrum, o Product Owner, Scrum Master e Time. O Diretor de TI
assumiu o papel de Product Owner. O Coordenador de Desenvolvimento assumiu o
papel de Scrum Master. Os quatro desenvolvedores juntamente com o testador
formaram o Time Scrum.
A durao definida para as Sprints foi de uma semana. Dois fatores foram
considerados para escolher esse time-box: (i) ciclos menores agilizam a
institucionalizao das cerimnias e (ii) garantem maior estabilidade do escopo
planejado (sprints maiores estariam muito suscetveis a mudanas, dado o histrico
da organizao).
A implantao do Scrum permitiu a gesto do desenvolvimento em ciclos curtos,
37
com cerimnias em marcos (planejamento e reviso). A partir deste ponto, foi

possvel organizar o escopo em forma de um backlog de estrias e bugs para as
demandas da equipe de desenvolvimento. O backlog foi mantido em um quadro para
facilitar a visibilidade do seu tamanho e, atravs de uma organizao de cores,
facilitar a anlise do mesmo (Figura 8).
Figura 8 Backlog
As cerimnias estabelecidas foram: (i) planejamento de sprint, (ii) reviso de

sprint, (iii) retrospectiva. A primeira cerimnia (i) tem o propsito de estabelecer
38
quais os itens de backlog que sero trabalhados durante a sprint. Ao longo da sprint
as atividades so acompanhadas atravs de um quadro de atividades (Figura 9),
atualizado diariamente durante reunies dirias, permitindo o acompanhamento das
demandas e o registro e comunicao de impedimentos.
Figura 9 - Quadro de Atividades
Ao trmino da durao da sprint, as atividades desempenhadas durante a sprint

so validadas junto ao Product Owner (ii) e realizado um levantamento dos pontos
fortes, fracos e oportunidades de melhoria da sprint (iii).
Ao longo da institucionalizao do Scrum, a ferramenta Redmine foi selecionada
e configurada para fornecer suporte a metodologia definida. O Redmine uma
39
ferramenta de software livre para a gesto de projetos, fornecida sobre licena GNU
General Public License [REDMINE, 2014]. A Figura 10 ilustra a adaptao do
Redmine para o acompanhamento das Sprints e a Figura 11 apresenta uma ata de
cerimnia registrada na ferramenta.
Figura 10- Representao de uma Sprint no Redmine
40
Figura Error! Bookmark not defined. - Ata de Planejamento de Sprint
Aps a execuo de seis Sprints, foi concluda a institucionalizao do Scrum.

Para garantir que o processo fosse mantido, foi criado um Checklist de Auditoria,
que tem como objetivo garantir que todos as cerimnias, prticas, mtodos e
tcnicas consideradas importantes para organizao so seguidas.
A periodicidade definida para as auditorias foram semanais. Ao final de cada
Sprint, o checklist era aplicado para verificar a aderncia do processo executado em
relao ao processo definido. O checklist pode ser visualizado da Figura 11.
41
Figura 11 - Checklist de Qualidade
Devido a necessidade de um indivduo externo para aplicar o checklist de

auditoria de forma imparcial, um membro do suporte foi selecionado e treinado para
assumir o papel de analista de qualidade (SQA). O analista de qualidade o
responsvel por auditar os processos e produtos de trabalho da organizao,
identificar pontos de no conformidade aos padres definidos, atribuir e acompanhar
aes para corrigir os desvios identificados e escalonar aes no realizadas dentro
do prazo acordado.
A partir da realizao das auditorias, No Conformidades (pontos de desvio do
processo) passaram a ser identificados. As No Conformidades eram comunicadas
aos responsveis atravs do Redmine, conforme Figura 12.
42
Figura 12 - Registro de No Conformidade
Com a realizao das auditorias foi possvel garantir a integridade dos dados
armazenados no Redmine e iniciar o processo de medio e anlise, para extrair
informaes que
pudessem
ajudar
entender
situao
do
setor de
desenvolvimento para apoiar o alcance de objetivos organizacionais.

Foi realizada uma reunio com a alta gesto para identificar os objetivos de
medio da organizao. Os objetivos definidos foram: (i) Aumentar a produtividade
e realizar alocao de pontos da Sprint de forma mais efetiva, (ii) Cumprir os prazos
estabelecidos, (iii) Evoluo do Time, (iv) Evitar desvio de escopo durante o
andamento das Sprints, (v) Equipe cumprir com suas horas de trabalho e garantir a
veracidade dos indicadores, (vi) Equipe trabalhar mais em novas funcionalidades e
menos em Bugs ou Defeitos, (vii) Melhorar a aderncia do projeto ao processo. Para
cada objetivo de medio foram identificadas as necessidades de medio,
conforme Figura 13
Aps identificar as necessidades de medio, foi possvel identificar quais
indicadores seriam necessrios para dar a visibilidade para alta gesto e para
monitorar se os objetivos de medio estavam sendo atendidos. Conforme Figura
13, os indicadores definidos foram: (i) Custo do Ponto, (ii) Efetividade do Time, (iii)
Velocidade do Time, (iv) Instabilidade do Escopo, (v) Apontamentos de Horas, (vi)
Esforo por categoria, (vii) Aderncia ao Processo.
Figura 13 - Necessidades de medio e indicadores relacionados
Os indicadores passaram a ser coletados e analisados com a periodicidade

semanal.
Aps
realizao
da
auditoria
resoluo
das
no
conformidades(momento que possvel garantir a integridade dos dados), os dados

eram coletados e os indicadores gerados e analisados, conforme Figuras 14 e 15.
43
Figura 14 - Indicadores (parte 1)
Figura 15 - Indicadores (parte 2)

Para os Indicadores fora da meta definida para organizao, foram identificadas

as causas dos desvios e definidas aes corretivas.
44
4.3.3 Fase 2
As metas definidas para esta fase eram o estabelecimento do conceito de

projetos e auditorias para os mesmos. Assim, foi abordado, nesta fase, o grupo de
reas de processos do CMMI formado por PP e PMC. Inicialmente foi ministrado um
curso de Gesto de Projetos, apresentando conceitos, prticas e mtodos. Foram
enfatizados os resultados requeridos, pontos chaves, elementos essenciais, limites
de aplicao, formas de aplicao recomendadas, ilustradas atravs de anlise de
casos. Aps o curso, foram definidos os processos de gesto de projetos. Os
mesmos foram validados, implantados e monitorados em projetos pilotos, avaliados
e posteriormente corrigidos e adaptados.
Foi definido que um projeto seria composto por um conjunto de quatro Sprints. A
estratgia foi fixar o tempo e equipe e variar os parmetros escopo, risco, qualidade,
custo, comunicao. Esta estratgia foi adotada devido a quantidade varivel de
demandas que podiam surgir para os diferentes produtos, alm do fato de que uma
nica equipe responsvel pela manuteno e evoluo de todos os produtos da
empresa.
Para gerenciar os projetos foi definido o papel do Gerente de Projetos(GP). O GP
o responsvel por definir junto a equipe um planejamento e garantir que o projeto
se mantenha alinhado ao mesmo, identificando riscos e definindo aes para
garantir o sucesso do projeto.
O ciclo de vida do projeto foi dividido nas seguintes fases: (i) planejamento, (ii)
execuo e, (iii) encerramento, conforme Figura 16.
Figura 16 - Ciclo de Vida do Projeto
Na fase (i) o Gerente de Projeto realiza o planejamento do projeto, levando em conta

os seguintes parmetros: equipe, esforo, treinamentos, tamanho, cronograma,
45
riscos,
escopo, custo, oramento, gerncia de configurao, recursos e
comunicao. O plano de projeto (Figura 17) apresentado a equipe buscando o

comprometimento de todos os envolvidos com o planejado.
Figura 17 - Plano de Projeto
Na fase (ii) so executadas as Sprints conforme descrito anteriormente. As

cerimnias de fim das Sprints passam a ser marcos do projeto, onde este
acompanhado e monitorado. A cada marco do projeto, as medidas coletadas e
indicadores analisados, servem como instrumentos para avaliar o desempenho do
projeto. Neste momento os riscos so reavaliados e aes so estabelecidas para
garantir que desvios do planejamento sejam corrigidos e que o projeto possa atingir
seus objetivos. As informaes de monitoramento e controle do projeto so
registradas no Redmine, conforme a Figura 18.
46
Figura 18 - Acompanhamento do Projeto
Na fase (iii) realizado o encerramento do projeto. Os resultados do projeto so

apresentados a alta direo. Em seguida o projeto avaliado para verificar se os
objetivos iniciais foram atendidos. Ainda nessa fase so levantadas as lies
aprendidas do projeto.
Durante esta etapa do projeto de melhoria, as auditorias de qualidade foram
incrementadas, de forma que foram definidas auditorias para o planejamento,
acompanhamento e encerramento do projeto. A anlise de indicadores tambm
passou a consolidar informaes a respeito dos projetos, facilitando a definio de
uma base histrica de medies para a organizao.
As informaes de cada projeto so organizadas individualmente no Redmine,
conforme apresentado na Figura 19.
47
Figura 19 - Documentao do Projeto no Redmine

.
4.3.4 Fase 3
Para esta fase, as principais metas esto relacionadas a definio e

institucionalizao de prticas relacionadas a gerncia de configurao. Inicialmente
um curso de gerncia de configurao foi ministrado para difundir os conhecimentos
e termos bsicos relacionados a esta rea de processo.
A empresa j adotava o Subversion (SVN) como ferramenta de controle de
verso. O SVN uma ferramenta de controle de verso que permite que se trabalhe
com diversas verses de arquivos organizados em um diretrio e localizados local
ou remotamente, mantendo-se suas verses antigas e os registros de quem e
quando manipulou os arquivos. especialmente til para se controlar verses de um
software durante seu desenvolvimento, ou para composio colaborativa de um
documento.
A primeira atividade realizada foi reestruturar os repositrios da empresa de
forma que cada produto fosse um projeto dentro da estrutura do SVN, e treinar o
time para gerenciar o repositrio de forma que os registros da ferramenta pudessem
ser entendidos de forma clara (Figura 20). Em seguida, foi configurada a integrao
entre o SVN e o Redmine, de modo que as alteraes feitas nos produtos de
software estejam justificadas em termos de tarefas (estrias e bugs) previamente
48
acordadas. Assim as mudanas podem ser rastreadas em relao a requisitos e

outros fatores de mudana registrados no Redmine. Esta rastreabilidade cruzada
entre Redmine e SVN foi obtida atravs da padronizao de mensagens de
comentrios durante operaes de commit (operao de envio de dados ao
repositrio).
Figura 20 - Grfico do Histrico de Revises do SVN
Em seguida mecanismos para controlar as configuraes estveis (baselines) do

produto e as liberaes foram estabelecidos atravs de tickets do Redmine ligados
somados a funcionalidade de tags (rtulos) do SVN. Permitindo o controle da
situao dos itens de configurao relacionados ao produto de software (Figura 21).
49
Figura 21 - Baseline de Produto
Baselines tambm foram institucionalizadas em relao ao conceito de projetos

mensais estabelecido. Assim baselines so definidas durante os marcos de
planejamento e encerramento dos projetos. Mudanas em relao ao planejamento
(plano de projeto e escopo) so controladas atravs do redmine (Figura 22).
50
Figura 22 - Baseline de Projeto
Os padres definidos para a gerncia de configurao tambm foram includos

nas auditorias de qualidade e procedimentos foram definidos para a validao das
baselines, garantindo que estejam ntegras e consistentes.
4.3.5 Fase 4
Para esta fase, as principais metas definidas estavam relacionadas a definio

dos planos e polticas referentes s prticas institucionalizadas at ento. Isto refletiu
na concepo dos documentos (Figura 23): (i) Politica Organizacional, (ii) Processo
de Desenvolvimento, (iii) Plano de Garantia da Qualidade, (iv) Guia de Medio e
Anlise, (v) Plano de Gerncia de Configurao, (vi) Papis e Responsabilidades.
51
Figura 23 - Documentos Organizacionais mantidos no Redmine
O documento (i) descreve todas as premissas da organizao em relao a seus

projetos e processos. O (ii) descreve o processo de desenvolvimento, bem como o
ciclo de vida e fases dos projetos. O (iii) descreve o processo de garantia da
qualidade, realizao de auditorias, comunicao de no conformidades, plano de
escalonamento de no conformidades. O (iv) tem por objetivo definir o conjunto de
indicadores e medies a serem coletados e analisados para os projetos. O (v)
apresentado um conjunto de diretrizes a serem seguidas nos projetos de software no
contexto da Gerncia de Configurao. O (vi) documenta todos os papis da
organizao, bem como suas responsabilidades e qualificaes necessrias.
4.3.6 Fase 5
Esta fase teve como meta identificar o grau de institucionalizao do processo e

estabelecer um mecanismo para garantir que a institucionalizao seja mantida.
Para isto, um novo Gap Analysis foi conduzido para identificar o nvel de
atendimento das prticas institucionalizadas na empresa em relao aos requisitos
do Nvel 2 de maturidade do CMMI. Os resultados so observados na Figura 24.
52
Figura 24 - Resultado do segundo Gap Analysis Final
Os resultados apontaram que havia evidncias para todas as Prticas

Especficas
do
Nvel
do
CMMI-DEV,
no
entanto
algumas
falhas
na
institucionalizao de prticas, sobretudo em relao a garantia da qualidade. Um

plano de ao foi definido para sanar determinados problemas e auditorias externas
mensais foram estabelecidas para garantir que a institucionalizao do processo
fosse mantida e averiguar se as auditorias de qualidade da empresa so realizadas
e se as No Conformidades geradas estavam de fato sendo contempladas.
Com implementao da auditoria externa, aps dois projetos foi diagnosticada
a aderncia de 100% das prticas da empresa em relao as exigncias do nvel 2
do CMMI.
4.4 Mapeamento dos resultados obtidos com o CMMI-DEV
Afim de avaliar os resultados obtidos, os quadros 1, 2, 3, 4, 5 e 6 apresentam

uma anlise do grau de atendimento das Prticas Especficas do Nvel 2 de
maturidade do CMMI-DEV, para cada PA, em relao s evidncias geradas na
implantao da melhoria de processo na empresa apresentada. O Quadro 5.1
apresenta as reas de Processo (PA) do Nvel 2 do CMMI-DEV com suas
53
respectivas Prticas Especficas (SP), as evidncias produzidas com base nos ativos
propostos e o grau de atendimento das prticas.
A anlise do grau de atendimento aponta se as evidncias geradas so
suficientes para indicar o atendimento de uma prtica especfica. Os valores
possveis so: "Atende totalmente" (as evidncias so suficientes), "atende
parcialmente" (as evidncias por si s no so suficientes para atender a prtica
especfica, sendo necessrias evidncias complementares) e "no atende" (a
proposta no gerou evidncia alguma que possa ser usada para indicar o
atendimento de uma prtica especfica).
Quadro 1 - Grau de atendimento das evidncias geradas s prticas especficas da PA Project
Planning
SP
Evidncia Gerada
Grau de
Atendimento
SP 1.1 Estimar o escopo

do projeto.
Planejamento do Projeto Plano de

Projeto Planejamento do Escopo;
Cerimnia de Planejamento de Sprint;
Backlog
Atende
Totalmente
SP 1.2 Estabelecer
estimativas de produto de
trabalho e atributos de
tarefas.
Planejamento do Projeto - Plano de

Projeto Planejamento do Tamanho
do Projeto; Cerimnia de Planejamento
de Sprint.
Atende
Totalmente
SP 1.3 Definir as fases do Planejamento do Projeto Plano de

ciclo de vida.
Projeto - Planejamento do Cronograma
Atende
Totalmente
SP 1.4 Estimar esforo e

custo

Projeto Planejamento do Esforo
Atende
Totalmente
SP 2.1 Estabelecer o
Oramento e Cronograma Projeto Planejamento do
Cronograma
Atende
Totalmente
SP 2.2 Identificar os
Riscos do Projeto

Projeto Planejamento dos Riscos;
Tickets do tipo Risco no Redmine.
Atende
Totalmente
SP 2.3 Plano de
Atende
54
Gerenciamento de Dados
Projeto Planejamento da Gerncia de Totalmente

Configurao; Plano de Gerncia de
Configurao.
SP 2.4 Planejar os
Recursos do Projeto

Atende
Projeto Planejamento da Gerncia de Totalmente
Configurao.
SP 2.5 Plano de
conhecimentos e
habilidades necessrios.

Projeto Planejamento da Equipe e
Treinamentos; Documento de Papeis e
Responsabilidades.
Atende
Totalmente
SP 2.6 Plano de
Envolvimento das Partes
Interessadas

Projeto Planejamento da
Comunicao
Atende
Totalmente
SP 2.7 Estabelecer o
plano do projeto

Projeto
Atende
Totalmente
SP 3.1 Rever os planos

que afetam o projeto.
Planejamento do Projeto
Atende
Apresentao do Plano de Projeto para Totalmente
Equipe
SP 3.2 Conciliar o
Trabalho e os Nveis de
Recursos
Atende
Equipe
SP 3.3 Obter Plano de

Compromisso
Atende
Equipe
Quadro 2 - Grau de atendimento das evidncias geradas s prticas especficas da PA Project

Monitoring and Control
SP
Evidncia Gerada
Grau de
Atendimento
55
SP 1.1 Monitorar
parmetros de
planejamento de trabalho.
Execuo do Projeto Anlise de

Marco Monitoramento dos
Indicadores
Atende
Totalmente
SP 1.2 Monitorar os
compromissos.

Compromissos dos Envolvidos
Atende
Totalmente
SP 1.3 Monitorar os
riscos.

Marco Monitoramento dos Riscos
Atende
Totalmente
SP 1.4 Monitorar a
Gesto de Dados

Marco Monitoramento dos Recursos
Atende
Totalmente
SP 1.5 Monitorar de
Participao das Partes
Interessadas

Compromissos com os Envolvidos
Atende
Totalmente
SP 1.6 Conduzir Revises

de Progresso

Marco; Cerimnia de Reviso de
Sprint.
Atende
Totalmente
SP 1.7 Conduzir Revises Execuo do Projeto Anlise de

de Marcos
Marco
Atende
Totalmente
SP 2.1 Analisar Questes

Marco Anlise de Causa dos
Desvios; Cerimnias de
Retrospectiva.
Atende
Totalmente
SP 2.2 Tomar uma Ao

Corretiva

Marco Anlise de Causa dos
Desvios
Atende
Totalmente
SP 2.3 Gerenciar Aes

Corretivas

Marco Aes Corretivas; Tickets do
Redmine do Tipo Ao.
Atende
Totalmente
Quadro 3 - Grau de atendimento das evidncias geradas s prticas especficas da PA

Requirement Management
56
SP
Evidncia Gerada
Grau de
Atendimento
SP 1.1 Compreender os
Requisitos
Execuo do Projeto Cerimnia

de Planejamento de Sprint;
Backlog
Atende
Totalmente
SP 1.2 Obter Compromisso

de Requisitos

de Planejamento de Sprint
Atende
Totalmente
SP 1.3 Gerenciar Mudanas

nos Requisitos
Gerncia de Configurao
Controle de Mudanas.
Atende
Totalmente
SP 1.4 Manter
Rastreabilidade Bidirecional
dos Requisitos
Gerncia de Configurao
Rastreabilidade Tickets do
Redmine com Cdigo no
Subversion
Atende
Totalmente
SP 1.5 Garantir o
Alinhamento Entre o Trabalho de Reviso de Sprint.
do Projeto e Requisitos
Atende
Totalmente

Measurement and Analysis
SP
Evidncia Gerada
Grau de
Atendimento
SP 1.1 Estabelecer Objetivos

de Medio
Guia de Medio Objetivos de

Medio.
Atende
Totalmente
SP 1.2 Especificar Medies
Guia de Medio Definio dos

Indicadores
Atende
Totalmente
SP 1.3 Especifique a coleta

Guia de Medio Especificao
de dados e procedimentos de dos Indicadores
armazenamento
Atende
Totalmente
Guia de Medio Especificao

dos Indicadores
Atende
Totalmente
SP 1.4 Especificar
Procedimentos de Anlise
57
SP 2.1 Obter Dados de

Medio

Marco Coleta dos Indicadores
Atende
Totalmente
SP 2.2 Analisar os Dados de

Medio

Marco Analise dos Indicadores
Atende
Totalmente
SP 2.3 Armazenamento de
Dados e Resultados

Marco Planilha de Indicadores
Armazenada no Redmine
Atende
Totalmente
SP 2.4 Comunicar os
Resultados

Marco Comunicao do
Resultado do Acompanhamento
Atende
Totalmente

Configuration Management
SP
Evidncia Gerada
Grau de
Atendimento
SP 1.1 Avaliar
Objetivamente
Processos.
Execuo do Projeto Auditoria de

Qualidade
Atende
Totalmente
SP 1.2 Avaliar
Objetivamente Produtos
de Trabalho

Qualidade
Atende
Totalmente
SP 2.1 Comunicar e
Resolver Problemas de
No Conformidade

Qualidade Comunicao das No
Conformidades
Atende
Totalmente
SP 2.2 Estabelecer
Registros

Qualidade Tickets de Auditorias no
Redmine/ Tickets de No
Conformidades
Atende
Totalmente
58
Quadro 6 - Grau de atendimento das evidncias geradas s prticas especficas da PA Product

and Process Quality Assurance
SP
Evidncia Gerada
Grau de
Atendimento
SP 1.1 Identificar Itens

de Configurao
Planejamento da Gerncia de
Configurao.
Atende
Totalmente
SP 1.2 Estabelecer um
Sistema de Gerncia de
configurao
Planejamento da Gerncia de
Configurao; Ferramenta Redmine;
Ferramenta Subversion.
Atende
Totalmente
SP 1.3 Criar ou liberar

baselines
Planejamento do Projeto Criao de

Baseline de Planejamento;
Encerramento do Projeto Baseline de
Encerramento do Projeto.
Atende
Totalmente
SP 2.1 Acompanhar as
solicitaes de
mudana.
Gerncia de Configurao Controle de

Mudanas; Tickets do Tipo Ao no
Redmine.
Atende
Totalmente
SP 2.2 Controlar a
Configurao de Itens
Baselines; Redmine; Subversion
Atende
Totalmente
SP 3.1 Estabelecer
Gerenciamento de
Registros de
Configurao
Log do Redmine; Log do SVN.
Atende
Totalmente
SP 3.2 Realizar
Auditorias de
Execuo do Projeto Auditoria da

Qualidade
Atende
Totalmente
59
Configurao
A anlise dos quadros revela que as evidncias geradas nesta abordagem, so

suficientes para o atendimento do Nvel 2 do CMMI-DEV.
4.5 Benefcios observados para a empresa
A execuo do projeto de melhoria de processo descrita neste trabalho,

promoveu um conjunto de benefcios na empresa alvo. Em relao aos principais
problemas inicialmente identificados (Seo 4.2), as seguintes melhorias puderam
ser observadas:
Necessidade de organizao do trabalho: Com a implantao dos projetos,
houve maior visibilidade das aes e a possibilidade de planejar as aes,

inicialmente em unidades de tempo semanais (sprint) e posteriormente mensal
(projeto);
Definir um escopo e garantir o foco das atividades: Ao garantir a identificao
de um backlog de atividades e a priorizao deste ao longo das sprints, foi possvel

estabilizar o escopo de atividades, permitindo que o time se concentrasse nas
atividades prioritrias;
Insatisfao do cliente: Com a implantao das Sprints, criou-se a cultura de
entregar software funcionando constantemente, agilizando a evoluo dos produtos.

Os bugs reportados pelos clientes passaram a ser analisados e priorizados, o que
ajudou o time a dar vazo aos bugs realmente prioritrios.
Interferncias externas: A entrada de novos requisitos nas sprints/projetos
passou a ser controlada, assim as mudanas passaram a ter seu impacto

identificado e controlado; Ao institucionalizar o papel de Scrum Master, a equipe
passou a ter maior proteo a interferncias externas, e estas passaram a ser mais
visveis para a alta gesto a partir da anlise do indicador de instabilidade do
escopo, assim aes puderam ser tomadas para garantir maior estabilidade.
Com a implantao dos indicadores foi possvel medir a evoluo da performance
ao longo do programa de melhoria. A produtividade do time passou de 50 pontos por
Sprint para 90 pontos, o que representou um aumento de 80% na produtividade. O
60
ndice de retrabalho, esforo gasto para corrigir bugs, passou de 70% para 15%. A
instabilidade do escopo diminuiu cerca de 30%.
Esses resultados mostram que o programa de melhoria no s garantiu a
aderncia as exigncias do nvel 2 do CMMI, mas garantiu a resoluo de problemas
que eram crticos para organizao, consequentemente melhorando a performance
e qualidades dos processos e produtos.
61
5 CONCLUSO
Ao longo deste trabalho pretendeu-se, sobretudo, focar o processo de

desenvolvimento de software, dando destaque necessidade da sua qualidade
como fator determinante para a obteno de melhores resultados, do prprio
sucesso das organizaes e da otimizao das atividades inerentes a todo o
processo de desenvolvimento.
No caso especfico de processos de desenvolvimento de software, a melhoria da
qualidade pode ser obtida atravs da implementao de Modelos de Maturidade,
modelos esses que permitem organizao avaliar os seus processos de
desenvolvimento e manuteno, implementar melhorias no seu modo de
funcionamento e determinar os progressos obtidos.
No caso da empresa estudada, aps a constatao de que existiam alguns
problemas que vinham ameaando a qualidade do software como a necessidade de
organizao do trabalho, falta de visibilidade, insatisfao dos clientes, atrasos na
liberao de verses, muitas interferncias externas, entre outros, resolveu avanar
para a resoluo destes mesmos problemas e tambm para a melhoria global dos
processos e atividades da empresa atravs da adoo do modelo de maturidade
CMMI, para guiar a melhoria do seu processo de desenvolvimento. O objetivo
passou ento pela certificao em nvel 2 de CMMI, sendo necessrio para isso a
definio e implementao das reas de processo correspondentes a esse nvel.
Este trabalho permitiu demonstrar todo o caminho que a empresa passou para
definir e implementar todas as mudanas na sua organizao. Foram apresentados
os processos, estratgias e aes necessrias para implementar o modelo e
conseguir a aderncia a exigncia do nvel 2 de maturidade do CMMI,
consequentemente resolvendo todos os problemas que existiam na empresa.
Alm de todos os ganhos alcanados pela empresa em estudo, o principal
benefcio deste trabalho diz respeito validao da metodologia de implantao
aplicada neste estudo de caso. Validao essa que permite que o mtodo seja
consolidado e disponibilizado, para que pequenas empresas, que no possuem
recursos financeiros para contratar uma consultoria, consigam implantar um
programa de melhoria de processos para melhorar a qualidade dos seus produtos.
62
REFERNCIAS
[ABNT 1994] Associao Brasileira de Normas Tcnicas. NBR ISO 8402/1994 Gesto da qualidade e garantia da qualidade - Terminologia. Rio de Janeiro: ABNT,
1994.
[AGUIAR, 2004] AGUIAR, H. V. PEPPE Processo de Implantao de Pequenas
Empresas. Monografia apresenta a UFLA, 2004.
[ANDRADE 2002] Andrade, P. I. Qualidade nos Processos do Ciclo de Vida do
Produto com CMMI: Uma Aplicao Prtica de Gerncia de Configurao na
COMPSIS. Dez. 2002.
[CNDIDO 2004] Cndido, Edlson J. D. Uma simplificao da tcnica anlise de
pontos de funo para estimar tamanho de aplicativos web. Dissertao de
Mestrado, USP, 2004.
[CMMI 2014] Capability Maturity Model Integration. Software Engineering
Institute(SEI). Disponvel em http://www.sei.cmu.edu/cmmi/ . Acesso em:
05/01/2014.
[HUMPHREY 1989] Humphrey W. S. Managing the software Process. AddisonWesley, 1989.
[IDEAL 2014] The IDEALSM Model. Software Engineering Institute(SEI). Disponvel
em http://www.sei.cmu.edu/ideal/ . Acesso em 05/01/2014.
[IEEE 1990] Institute of Eletrical and Eletronics and Engineers. IEEE Std 610.121990 - Standard glossary of software engineering terminology. Piscataway: IEEE,
1990.
[LIBERATO, 2008] Liberato, T. E. M., Implementao do Modelo CMMI na
Esprito Santo Informtica. Dissertao de Mestrado, UTM, 2008.
[PAULK 1995] Paulk, M.C.; Weber, C.V.; Curtis, B.; Chrissis, M.B.; E Outros. The
Capability Maturity Model: Guidelines for Improving the Software Process. Estados
Unidos: Addison-Wesley. 1995.
[PRESSMAN 2002] R. S. Pressman. Engenharia de Software, 5 ed. Rio de Janeiro,
Mc Graw Hill, 2002.
[RAMOS, 2011] RAMOS, E. S., Implantao do Modelo MPS.BR: Estudo de Caso da
Empresa CIENTEC Consultoria e Desenvolvimento de Sistemas. Trabalho de
Concluso de Curso, FUMEC, 2011.
[Redmine 2014] Disponvel em www.redmine.org. Acesso 02/02/2014
[ROUILLER 2001] Rouiller, A. C. Gerenciamento de Projetos de Software para
empresas de Pequeno Porte. Tese de Doutorado, UFPE, 2001.
63
[SALVIANO 2003] Clenio F. Salviano. Melhoria e Avaliao de Processo com

ISO/IEC 15504 (SPICE) e CMMI, 1 ed, Editora UFLA, 2003.
[SCHWABER, 2013] SCHWABER, K.; SUTHERLAND, J, Guia do Scrum. Disponvel
em https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/ScrumGuide-Portuguese-BR.pdf. Acesso em 01/02/2014.

Implementando CMMI em Empresas de Software

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Implementando CMMI em Empresas de Software

Transféré par

Droits d'auteur :

Formats disponibles

Universidade Federal Rural de Pernambuco

Departamento de Estatstica e Informtica

IMPLANTANDO CMMI EM EMPRESAS DE MANUTENO E

Matheus Benicio Rodrigues Evangelista

Matheus Benicio Rodrigues Evangelista

IMPLANTANDO CMMI EM EMPRESAS DE MANUTENO E

Monografia apresentada ao Curso de

Orientador: Profa. Dra. Ana Cristina Rouiller

Esta dissertao descreve um estudo de caso sobre a implantao do nvel 2 de

Figura 1 - Viso do modelo IDEAL ............................................................................ 13

Quadro 1 - Grau de atendimento das evidncias geradas s prticas especficas da

Neste captulo introdutrio apresentado o contexto, no qual o trabalho est

1.1 Contextualizao e Motivao

Grande parte da populao mundial depende de aplicaes de software para

no Brasil condio essencial para a busca da competitividade mundial das

Altos custos associados adoo de modelos padres da qualidade (CMMI e

MPS.BR) diante de recursos humanos e recursos financeiros limitados;

Adoo de planos, especificaes e documentaes no adequados

realidade das empresas para simplificar o processo de certificao e a conformidade

Carncia de profissionais que dominem o conhecimento e possuam a

experincia prtica que permita acelerar o processo de qualificao das empresas,

Falta e/ou pouca cultura em processos, falta de definio das metas

organizacionais e imaturidade metodolgica.

1.2 Objetivos e Justificativas

Este trabalho tem como objetivo de avaliar um mtodo de implantao do nvel 2

Este trabalho foi desenvolvido utilizando o CMMI como modelo de qualidade de

Iniciao (Iniating): foram feitas reunies para aprovao do trabalho na

empresa do estudo de caso e definio do modelo de processo a ser utilizado, em

Diagnstico (Diagnosing): foi feito um diagnstico da empresa no modelo

CMMI, identificando o nvel de aderncia;

Estabelecimento (Establishing): foi elaborado um plano de projeto, onde foram

identificadas as atividades necessrias para criao do processo, a sua durao e a

Ao (Action): foi executado e acompanhado o planejamento feito para o

Aprendizagem (Learning): a cada iterao eram analisados os pontos

negativos e positivos dos trabalhos realizados;

Figura 1 - Viso do modelo IDEAL

1.4 Organizao do Trabalho

Este trabalho encontra-se dividido em cinco captulos: Alm deste captulo de

2 INTRODUO A PROCESSOS E AO MODELO CMMI

Neste captulo apresenta-se uma viso geral de Processos e do Modelo CMMI.

O conceito de processo quase que intuitivo. As engenharias comumente

A NBR define processo como um conjunto de atividades inter-relacionadas,

que transforma entradas em sadas [ABNT 1994];

O IEEE (Institute of Electrical and Electronic Engineers) define Processo como

uma sequncia de passos realizados para um determinado propsito [IEEE 1990].

Figura 2 - Processo e seus Componentes

Ainda segundo Paulk, considerando que o software resultado do processo de

2.2 Modelo CMMI

2.2.1 Arquitetura do Modelo

A arquitetura do CMMI composta basicamente pela definio de um conjunto

Figura 3 - CMMI: reas de Processo em duas Representaes: por Estgio e Contnua

Cada rea de processo definida no modelo por meio da descrio de seu

nvel 1: Inicial (Initial)

nvel 2: Gerenciado (Managed)

nvel 3: Definido (Defined)

nvel 4: Gerenciado Quantitativamente (Quantitatively Managed)

nvel 5: Otimizando (Optimizing)

Cada nvel de maturidade definido basicamente pelo conjunto de reas de

nvel 0: Incompleto (Incomplete)

nvel 1: Executado (Performed)

nvel 2: Gerenciado (Managed)

nvel 3: Definido (Defined)