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

Quadro 2 - Grau de atendimento das evidncias geradas s prticas especficas da PA Project Monitoring and Control ............................................................................ 54

Quadro 3 - Grau de atendimento das evidncias geradas s prticas especficas da PA Requirement Management .................................................................................. 55

Quadro 4 - Grau de atendimento das evidncias geradas s prticas especficas da PA Measurement and Analysis ................................................................................. 56

Quadro 5 - Grau de atendimento das evidncias geradas s prticas especficas da PA Configuration Management ................................................................................. 57

Quadro 6 - Grau de atendimento das evidncias geradas s prticas especficas da 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

9

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 SEI-

Software 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 SW-

CMM, 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 Fonte: Autoria prpria.

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) e o 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 o

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 a entender a 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 a realizao da auditoria e 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) Fonte: Autoria prpria.

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 2 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 ciclo de vida.

Planejamento do Projeto Plano de Projeto - Planejamento do Cronograma

Atende Totalmente

SP 1.4 Estimar esforo e custo

Planejamento do Projeto - Plano de Projeto Planejamento do Esforo

Atende Totalmente

SP 2.1 Estabelecer o Oramento e Cronograma

Planejamento do Projeto - Plano de Projeto Planejamento do Cronograma

Atende Totalmente

SP 2.2 Identificar os Riscos do Projeto

Planejamento do Projeto Plano de Projeto Planejamento dos Riscos; Tickets do tipo Risco no Redmine.

Atende Totalmente

SP 2.3 Plano de Planejamento do Projeto Plano de Atende

54

Gerenciamento de Dados Projeto Planejamento da Gerncia de Configurao; Plano de Gerncia de Configurao.

Totalmente

SP 2.4 Planejar os Recursos do Projeto

Planejamento do Projeto Plano de Projeto Planejamento da Gerncia de Configurao; Plano de Gerncia de Configurao.

Atende Totalmente

SP 2.5 Plano de conhecimentos e habilidades necessrios.

Planejamento do Projeto - Plano de Projeto Planejamento da Equipe e Treinamentos; Documento de Papeis e Responsabilidades.

Atende Totalmente

SP 2.6 Plano de Envolvimento das Partes Interessadas

Planejamento do Projeto - Plano de Projeto Planejamento da Comunicao

Atende Totalmente

SP 2.7 Estabelecer o plano do projeto

Planejamento do Projeto - Plano de Projeto

Atende Totalmente

SP 3.1 Rever os planos que afetam o projeto.

Planejamento do Projeto Apresentao do Plano de Projeto para Equipe

Atende Totalmente

SP 3.2 Conciliar o Trabalho e os Nveis de Recursos

Planejamento do Projeto Apresentao do Plano de Projeto para Equipe

Atende Totalmente

SP 3.3 Obter Plano de Compromisso

Planejamento do Projeto Apresentao do Plano de Projeto para Equipe

Atende Totalmente

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.

Execuo do Projeto Anlise de Marco Monitoramento dos Compromissos dos Envolvidos

Atende Totalmente

SP 1.3 Monitorar os riscos.

Execuo do Projeto Anlise de Marco Monitoramento dos Riscos

Atende Totalmente

SP 1.4 Monitorar a Gesto de Dados

Execuo do Projeto Anlise de Marco Monitoramento dos Recursos

Atende Totalmente

SP 1.5 Monitorar de Participao das Partes Interessadas

Execuo do Projeto Anlise de Marco Monitoramento dos Compromissos com os Envolvidos

Atende Totalmente

SP 1.6 Conduzir Revises de Progresso

Execuo do Projeto Anlise de Marco; Cerimnia de Reviso de Sprint.

Atende Totalmente

SP 1.7 Conduzir Revises de Marcos

Execuo do Projeto Anlise de Marco

Atende Totalmente

SP 2.1 Analisar Questes Execuo do Projeto Anlise de Marco Anlise de Causa dos Desvios; Cerimnias de Retrospectiva.

Atende Totalmente

SP 2.2 Tomar uma Ao Corretiva

Execuo do Projeto Anlise de Marco Anlise de Causa dos Desvios

Atende Totalmente

SP 2.3 Gerenciar Aes Corretivas

Execuo do Projeto Anlise de 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

Execuo do Projeto Cerimnia 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 do Projeto e Requisitos

Execuo do Projeto Cerimnia de Reviso de Sprint.

Atende Totalmente

Quadro 4 - Grau de atendimento das evidncias geradas s prticas especficas da PA 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 de dados e procedimentos de armazenamento

Guia de Medio Especificao dos Indicadores

Atende Totalmente

SP 1.4 Especificar Procedimentos de Anlise

Guia de Medio Especificao dos Indicadores

Atende Totalmente

57

SP 2.1 Obter Dados de Medio

Execuo do Projeto Anlise de Marco Coleta dos Indicadores

Atende Totalmente

SP 2.2 Analisar os Dados de Medio

Execuo do Projeto Anlise de Marco Analise dos Indicadores

Atende Totalmente

SP 2.3 Armazenamento de Dados e Resultados

Execuo do Projeto Anlise de Marco Planilha de Indicadores Armazenada no Redmine

Atende Totalmente

SP 2.4 Comunicar os Resultados

Execuo do Projeto Anlise de Marco Comunicao do Resultado do Acompanhamento

Atende Totalmente

Quadro 5 - Grau de atendimento das evidncias geradas s prticas especficas da PA 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

Execuo do Projeto Auditoria de Qualidade

Atende Totalmente

SP 2.1 Comunicar e Resolver Problemas de No Conformidade

Execuo do Projeto Auditoria de Qualidade Comunicao das No Conformidades

Atende Totalmente

SP 2.2 Estabelecer Registros

Execuo do Projeto Auditoria de 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 do Projeto Planejamento da Gerncia de Configurao; Plano de Gerncia de Configurao.

Atende Totalmente

SP 1.2 Estabelecer um Sistema de Gerncia de configurao

Planejamento do Projeto Planejamento da Gerncia de Configurao; Plano de 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 v