INPE-10424-TDI/921

LEVANTAMENTO DA QUALIDADE DO PROCESSO DE

SOFTWARE COM FOCO EM PEQUENAS ORGANIZAES
Jaciara Silva Carosia
Dissertao de Mestrado do Curso da Ps-Graduao em Computao Aplicada,
orientada pelo Dr. Tatuo Nakanishi, aprovada em 30 de setembro de 2003.
INPE
So Jos dos Campos
2004
681.3.06
CAROSIA, J. S.
Levantamento da qualidade do processo de software
com foco em pequenas organizaes / J. S. Carosia. So
Jos dos Campos: INPE, 2003.
158p. (INPE-10424-TDI/921).
1.Engenharia de software. 2.Melhoria. 3.Processos.
4.Qualidade. 5.Avaliaes. I.Ttulo.
Para que haja luz no bastar
temer a presena da sombra.
preciso acend-la.
Andr Luiz
Livro "Estude e Viva"
Psicografado por Chico Xavier
A meus avs Pedro e Lula
pelo apoio e incentivo
em todos os momentos de minha vida,
mas que infelizmente no puderam
presenciar a concluso de mais esta etapa.
Dedico a vocs onde quer que estejam.
AGRADECIMENTOS
A Deus.
A meus pais, Mauro e Regina, pelos incansveis esforos por minha formao, pelo
apoio incondicional e incentivo.
A meu namorado e grande amigo, Fabrcio, pela grande pacincia e companheirismo em
todos os momentos.
A meu irmo, Mauro Junior, tambm pela pacincia nos momentos mais estressantes.
A meu orientador, Prof. Dr. Tatuo, que com sua dedicao e confiana o grande
responsvel pela viabilizao deste trabalho.
s amizades que conquistei no decorrer deste trabalho.
Aos profissionais da rea que colaboraram com suas experincias.
RESUMO
A sociedade passa por severas transformaes. A capacidade de inovar o diferencial
para acompanhar o ritmo acelerado destas mudanas. Muitas organizaes de software
apostam na qualidade como alternativa de inovao. Melhorar a qualidade do processo
de desenvolvimento de software um dos grandes objetivos da engenharia de software.
A avaliao a primeira etapa para a melhoria do processo. O sucesso de um programa
de melhoria depende grandemente da confiabilidade dos dados adquiridos nesta etapa.
Uma avaliao eficiente permite a elaborao de um plano de melhoria compatvel com
a realidade da organizao. Este trabalho apresenta uma estratgia para levantamento da
qualidade do processo, atravs de uma mini-avaliao baseada no modelo CMMI. O
foco especfico deste trabalho organizaes de pequeno porte que esto dando seus
primeiros passos em direo a melhoria de seu processo de desenvolvimento.
SOFTWARE PROCESS QUALITY ASSESSMENT FOCUSED ON
SMALL ORGANIZATIONS
ABSTRACT
Society goes through strict changes. The capacity of innovation is what makes the
difference in order to follow the accelerate rhythm of these changes. Many software
organizations invest on this quality as their innovation alternative. Improving the quality
of the development process is one of the software engineering biggest goals.
Assessment is the first step in order to improve the process. The success of an
improvement program depends widely on the reliability of the acquired data on this
stage. An efficient assessment allows the elaboration of a plan in compliance with the
organization reality. This work presents a strategy to assessment the quality of the
process, through a mini-assessment based on the model CMMI. The specific focus of
this work is the small organizations that are walking the first steps towards the
improvement of their development process.
SUMRIO
Pg.
LISTA DE FIGURAS
LISTA DE TABELAS
CAPTULO 1 INTRODUO.................................................................................19
CAPTULO 2 QUALIDADE.....................................................................................23
2.1 - Origem da Qualidade..............................................................................................23
2.2 - Definies...............................................................................................................23
2.3 - Qualidade de Software............................................................................................27
2.4 - Qualidade do Produto e Qualidade do Processo.....................................................28
2.4.1 - Qualidade do Produto...........................................................................................29
2.4.2 - Qualidade do Processo.........................................................................................31
CAPTULO 3 - MODELOS DE MELHORIA DO PROCESSO DE
SOFTWARE.....................................................................................33
3.1 - Modelo de Maturidade da Capacidade....................................................................34
3.1.1 - Origem do CMM.................................................................................................34
3.1.2 - Maturidade...........................................................................................................35
3.1.3 - Estrutura do CMM...............................................................................................36
3.1.4 - Implementao do CMM.....................................................................................38
3.2 - Modelo de Maturidade da Capacidade Integrado....................................................39
3.2.1 - Estrutura do CMMI..............................................................................................41
3.2.2 - Componentes do Modelo.....................................................................................44
3.2.3 - Abordagem em Estgios.......................................................................................47
3.2.4 - Abordagem Contnua...........................................................................................52
3.2.5 - Perspectivas de Implementao do CMMI..........................................................54
CAPITULO 4 - PANORAMA ATUAL.......................................................................57
4.1 A Indstria do Software.........................................................................................57
4.2 - Os Processos de Software.......................................................................................59
4.3 - A Utilizao do CMM............................................................................................61
4.4 - O CMM e o Porte das Organizaes.......................................................................65
4.5 - Custos e Benefcios do CMM................................................................................68
4.6 CMM em Pequenas Organizaes.........................................................................71
CAPITULO 5 MELHORIA DO PROCESSO DE SOFTWARE..........................75
5.1 - Diretrizes Iniciais....................................................................................................75
5.2 - Escolha do Escopo da Organizao........................................................................76
5.3 - Escolha do Modelo de Melhoria.............................................................................78
5.4 - Escolha da Abordagem............................................................................................78
5.5 - Escolha da Perspectiva............................................................................................80
5.6 - Escolha da Disciplina..............................................................................................80
5.7 - Escolha das reas de Processo...............................................................................81
5.8 Importncia do Gerenciamento de Projetos...........................................................88
CAPTULO 6 LEVANTAMENTO DA QUALIDADE DO PROCESSO DE
SOFTWARE......................................................................................93
6.1 - Avaliaes CMMI..................................................................................................93
6.2 - Avaliaes Alternativas..........................................................................................95
6.3 - Preparao da Avaliao.........................................................................................97
6.4 - Mtodo para Mini-avaliao...................................................................................98
6.5 - Requisitos de Avaliaes Classe C.......................................................................100
6.6 - Interpretao dos Requisitos.................................................................................107
6.7 - Questionrio de Maturidade..................................................................................113
6.8 - Uma Proposta de Questionrio..............................................................................115
6.8.1 - Papis.................................................................................................................116
6.8.2 - Prticas Bsicas..................................................................................................119
6.8.3 - Metodologia para criao dos questionrios......................................................120
CAPTULO 7 CONCLUSO.................................................................................125
7.1 - Consideraes sobre o Desenvolvimento..............................................................127
7.2 - Dificuldades Encontradas......................................................................................129
7.3 - Consideraes Finais.............................................................................................130
REFERNCIAS BIBLIOGRFICAS......................................................................133
APNDICE A .............................................................................................................141
APNDICE B .............................................................................................................149
LISTA DE FIGURAS
3.1 - Estrutura do CMMI em estgios.............................................................................48
3.2 - Estrutura do CMMI contnuo.................................................................................53
4.1 - Conhecimento do Modelo CMM, Norma ISO 12207 e SPICE..............................62
4.2 - Conhecimento no Modelo CMM (%).....................................................................63
4.3 - Porte das empresas quanto a fora de trabalho efetiva e total.................................66
6.1 - Avaliao CMMI....................................................................................................93
6.2 - Limites da avaliao..............................................................................................120
6.3 - Esquema para elaborao dos questionrios.........................................................121
LISTA DE TABELAS
2.1 - Enfoques Antigo e Novo da Qualidade...................................................................24
2.2 Caractersticas de qualidade internas e externas.....................................................30
2.3 - Caractersticas de qualidade em uso........................................................................30
4.1 - Conhecimento dos modelos CMM e SPICE 1999...............................................62
4.2 - Conhecimento dos modelos CMM e SPICE 2001...............................................63
4.3 - Conhecimento do CMM segundo o porte da organizao (%)...............................65
4.4 - Implantao de programas de qualidade (%)..........................................................67
5.1 reas de processo do Nvel 2....................................................................................84

19
CAPTULO 1
INTRODUO

A frase de Georges Clemenceau (1841-1920), estadista e jornalista francs, L'homme
absurde est celui qui ne change jamais (Um homem absurdo aquele que no muda
nunca), tambm pode ser empregada no contexto das organizaes. O dicionrio
Aurlio define absurdo como contrrio razo, ao bom senso; que fere as regras da
lgica ou as leis da razo (Ferreira,1999). Pode-se dizer que uma organizao que no
se preocupa em mudar, em acompanhar a dinmica acelerada que a sociedade imprime,
tambm uma organizao absurda.

No novidade o fato de que a sociedade mundial passa por severas transformaes de
cunho poltico, econmico, cultural e tecnolgico. A velocidade impressa a esta
dinmica transformadora, algo, h apenas alguns anos atrs, praticamente impensvel.
Para que a velocidade das transformaes no cause terrveis danos s organizaes,
necessrio que a inovao (Bastos, 2000) esteja cada vez mais presente como um valor
importante na cultura destas organizaes.

A globalizao, como exemplo claro destas transformaes, mudou clssicos conceitos
de administrao. Hoje, no admissvel permanecer indiferente a esta realidade, sob
pena de colocar em risco o patrimnio da organizao. Conseguir acompanhar o ritmo
das mudanas um critrio indispensvel para garantir competitividade. As
organizaes conseguem e mantm vantagem competitiva por meio da melhoria, da
inovao e do aperfeioamento (Porter, 1993).

Dentro do contexto destas transformaes, o diferencial a capacidade de inovar. As
organizaes que desenvolvem software, obviamente, so tambm afetadas por estas
transformaes. Porm, devem estar mais atentas, visto que os seus produtos - os
softwares - so potenciais alvos de contnuas evolues. Estas organizaes esto

20
apostando na qualidade como ferramenta de inovao. No panorama atual, no
exagero afirmar que o investimento em qualidade questo de sobrevivncia.
Os esforos pela qualidade na indstria automobilstica provaram que o aumento da
qualidade sempre acompanhado pela reduo de custos na forma de menos re-trabalho
e no menor ndice de refugo. Alm da maior satisfao do cliente que pode ser refletida,
muitas vezes, na maior participao no mercado. Assim, o axioma que diz que
investimentos em qualidade do lucro, plenamente aceito pela indstria de
manufatura. As organizaes apostam que este axioma tambm funciona com software.

O interesse pela qualidade j no novidade no setor industrial, visando o aumento da
produtividade e, ao mesmo tempo, a satisfao das crescentes exigncias dos
consumidores. No setor do software tambm notvel este interesse. Com as
progressivas exigncias do mercado, vrias iniciativas tm surgido, objetivando a
elaborao de normas e padres internacionais para melhoria da qualidade do software,
do ponto de vista do produto e do processo de desenvolvimento.

As crescentes demandas dos clientes e usurios, a sempre maior complexidade da
tecnologia disponvel e as exigncias de maior confiabilidade, menor custo e prazo, e
maior produtividade esto levando as organizaes a se convencerem que a abordagem
artesanal no desenvolvimento e manuteno do software tem os dias contados.

So vrios os modelos disponveis que auxiliam na busca pela qualidade do software,
porm ainda h certa resistncia por parte das organizaes em implement-los.

Um dos fatores desta resistncia so certas reaes defensivas (Argyris, 1992), nem
sempre conscientes, de empecilho s inovaes. Estas reaes, como alienao e
oposio, so conseqncias do receio inerente a qualquer mudana (Pereira, 1997).
Este receio uma caracterstica do ser humano, que pode ser superada atravs do
esclarecimento dos benefcios da mudana. A conscientizao de que algumas
mudanas so imprescindveis para melhorar a produtividade e a qualidade do produto
desenvolvido, um passo decisivo para superar possveis mitos.

21
Outros fatores de resistncia adoo aos modelos de melhoria so mais complexos e
de difceis solues. Algumas organizaes apresentam certas carncias que no podem
ser supridas apenas com esclarecimentos. Recursos administrativos, financeiros e
humanos, quando ineficazes ou insuficientes, apresentam-se como uma grande barreira
busca da qualidade. A implementao destes modelos no uma tarefa trivial, mas em
pequenas organizaes, esta tarefa pode ser ainda mais difcil, devido carncia de
recursos.

A importncia da indstria do software para a economia nacional, a relevncia das
pequenas organizaes de software e a crescente importncia da qualidade no mercado
competitivo, motivou o desenvolvimento de um trabalho para auxiliar na aproximao
destas organizaes aos princpios de qualidade de software.

Em qualquer programa de melhoria, a primeira atividade a ser executada a avaliao
do processo atual, pois sem conhecer algo impossvel melhora-lo. A avaliao inicial,
muitas vezes, torna-se uma barreira instransponvel para muitas organizaes.

No contexto das pequenas organizaes que desenvolvem software, este trabalho tem
como objetivo esclarecer algumas questes como: As organizaes de software
brasileiras esto se preocupando com a melhoria do seu processo de desenvolvimento?
Quais as maiores dificuldades encontradas na implementao de um programa de
melhoria de processo? possvel melhorar a qualidade do processo em organizaes
que dispem de poucos recursos? Quais os primeiros passos a serem dados na busca
pela qualidade do processo de software? Qual modelo de melhoria utilizar? Quais as
diretrizes para a elaborao de uma avaliao inicial?

Assim, o presente trabalho descreve algumas diretrizes para a criao de uma avaliao
de processo inicial, visando minimizar as dificuldades que as pequenas organizaes
encontram em seus primeiros passos em direo a melhoria da qualidade de software.
Esta proposta baseada no CMMI (CMM Integrado), que um modelo de melhoria de

22
processo, cujas caractersticas se mostram atraentes a organizaes que aspiram sair do
estado de imaturidade no desenvolvimento de software.

Este trabalho est organizado em 7 captulos.

No Captulo 2, so dadas definies de qualidade e qualidade de software, onde so
mencionadas as caractersticas da qualidade do produto e qualidade de processo, com
nfase especial nesta ltima. A clara compreenso do termo qualidade imprescindvel
para que esta possa ser buscada e assuma funo estratgica na competitividade.

O Captulo 3 composto de uma breve apresentao do CMM (Capability Maturity
Model) e da sua mais recente evoluo, o CMMI (Capability Maturity Model
Integration). Ambos so modelos voltados melhoria do processo de software e foram
utilizados como base no desenvolvimento deste trabalho.

No Captulo 4, so mostrados o panorama atual do desenvolvimento de software, a
aceitao e disseminao do CMM e CMMI, e as principais dificuldades que algumas
organizaes enfrentam na implementao de um modelo de melhoria de processo.

Nos Captulos 5 e 6, proposta uma estratgia para preparao e execuo de uma mini-
avaliao baseada no modelo CMMI.

No Captulo 5, so feitas algumas escolhas visando a adaptao do modelo CMMI ao
escopo da organizao enfocada neste trabalho. Estas escolhas compreendem o primeiro
passo para a elaborao de uma avaliao de processo.

No Captulo 6, apresentada uma estratgia para que a organizao descreva seu
prprio mtodo de levantamento da qualidade do processo de software.

Finalmente, no Captulo 7, so dadas as concluses sobre o desenvolvimento deste
trabalho.

23
CAPTULO 2
QUALIDADE

2.1 Origem da Qualidade

O desenvolvimento contnuo da qualidade comeou no Japo, mas foi inspirada em dois
americanos, Edward Deming e Joseph Juran. Muitas pessoas reconheceram que aps a
Segunda Guerra Mundial, para o Japo se reconstruir e vir a ser uma grande nao
comerciante, um intenso programa de desenvolvimento contnuo da qualidade seria
necessrio. Os produtos japoneses estavam longe da competitividade na qualidade e
confiabilidade e eram vendidos apenas base de baixos preos. Ento, trabalhando com
altos administradores no Japo, Deming e Juran, executando mtodos de controle
estatstico da qualidade, aplicando em todas as reas produtivas da companhia, deram as
condies para se fazer os produtos japoneses mais competitivos. As idias difundiram-
se amplamente e, com este impulso, o Japo liderou os programas de controle total da
qualidade e a idia de melhoria contnua da mesma, sendo fonte de inspirao de muitas
naes (Vieira, 1995).

Muitos nipnicos consideram Deming e Juran os inspiradores do milagre industrial
japons iniciado na dcada de 50. Sobre suas idias foi criada uma revoluo da
qualidade que restabeleceu a confiana na indstria nacional (Cardoso, 1995).

Na dcada de 80 o fator qualidade emergiu mundialmente como uma necessidade bsica
na luta pelo mercado cada vez mais competitivo (Barros, 1999).

2.2 Definies

A definio do termo qualidade depende do mbito em que ocorre, possuindo
interpretaes diversas. Por isso mesmo, a qualidade continua facilmente mal entendida
com decorrncias que prejudicam as organizaes que desejam implement-la. Uma

24
melhor compreenso do termo fundamental para que a qualidade possa assumir funo
estratgica na competitividade. Na formulao de um conceito de qualidade essencial
a clareza de uma definio, mas o fundamental que seu significado esteja
perfeitamente entendido e que seja uma linguagem comum em toda a organizao.

Juran (1990) admite a existncia de vrias definies para o termo qualidade. Segundo
ele, um dos significados de qualidade o desempenho do produto, este desempenho
resulta das caractersticas do produto que levam satisfao do cliente e interferem na
deciso de compra. Ou ainda, qualidade a ausncia de deficincias, as deficincias
do produto afetam os custos, por falhas no uso, repetio de trabalho e desperdcio. A
convenincia de unir estas duas definies levou a conhecida definio simples de
qualidade como sendo a adequao ao uso. Apesar de ser considerada pelo prprio
autor como uma definio muito resumida, este tem sido o conceito mais reconhecido
para a qualidade. A abordagem de Juran possui um forte ingrediente gerencial e focaliza
planejamento, fluxo organizacional, responsabilidade gerencial para qualidade e a
necessidade de estabelecer metas e objetivos para melhoria (Cardoso, 1995). A gerncia
para a qualidade tem passado ao longo dos anos por mudanas profundas. Juran (1992)
lidera uma nova fase para o conceito de qualidade, que passou dos aspectos
tecnolgicos da fbrica para a preocupao com a qualidade global em todos os
aspectos do gerenciamento e em toda a organizao. A Tabela 2.1 ilustra estas
mudanas.
TABELA 2.1 - Enfoques Antigo e Novo da Qualidade.
Enfoque Antigo Enfoque Novo
Qualidade por inspeo Qualidade fabricada
Qualidade maior aumenta custos Qualidade maior diminui custos
Orientada para o procedimento Orientada para o processo
Induzida pelos departamentos Induzida pela liderana
Atende especificaes do cliente Atende e excede expectativas do cliente
Foco no cho de fbrica Foco holstico em toda organizao
Qualidade obrigao de outro Qualidade minha obrigao
FONTE: Juran (1992).

25
Deming (1990) tambm reconhece a amplitude do conceito de qualidade que s pode
ser definida em termos de quem a avalia. Ele afirma que qualidade no significa luxo,
mas um grau previsvel de uniformidade e dependncia, a baixo custo, adequada ao
mercado. Em outras palavras, qualidade qualquer coisa que o cliente necessita ou
deseja. E como as necessidades e desejos dos clientes esto sempre mudando, a soluo
para a definio da qualidade em termos de cliente redefinir os requisitos
constantemente. Deming enfatiza uma sistemtica para soluo de problemas de
qualidade conhecida por Ciclo Deming ou PDCA Plan, Do, Check, Action. Este
mtodo de anlise sistemtica a base para o processo de melhoria contnua em todos
os nveis da organizao que deseja qualidade. No mundo de Deming, voc nunca
chega. Voc sempre pode fazer melhor e nunca deve interromper o processo de
aperfeioamento.

Para salientar a pluralidade de definies para o termo qualidade, pode-se destacar a
opinio de outros consultores reconhecidos internacionalmente por seus trabalhos
desenvolvendo tcnicas ou teorias em qualidade e produtividade.

Crosby (1991) define qualidade como a conformidade com os requisitos e medida
pelo custo da no-qualidade. Para ele qualidade um estado binrio: ou h
conformidade (qualidade) ou h no-conformidade (no-qualidade). Usando esta
abordagem, Crosby desenvolveu, em 1961, o conceito de "zero defeito", enfatizando
que todas as pessoas da organizao so capazes de fazer o seu trabalho de maneira
correta, na primeira e em todas as vezes.

Teboul (1991) associa o conceito de qualidade a trs elementos bsicos: o cliente, a
oferta e a concorrncia. Este autor afirma que qualidade , antes de qualquer coisa, a
conformidade s especificaes. tambm a resposta ajustada utilizao que se tem
em mente, na hora da compra e tambm a longo prazo. Mas tambm aquele algo
mais de seduo e excelncia, mais prximo do desejo do que da qualidade. Nesta
definio, consolidam-se vrias proposies de qualidade que, de acordo com Teboul,
no so exclusivas. Para ele, ter conformidade necessrio, mas em relao s

26
necessidades ou a um certo uso. E esta satisfao das necessidades deve ser feita de
maneira superior da concorrncia, com algo mais de seduo (Vieira, 1995).

Garvin (2002) destaca a necessidade de um melhor entendimento do termo qualidade,
para que ela possa realmente assumir um papel estratgico. Ele afirma que estudiosos de
filosofia, economia, marketing e gerncia de operaes tm visto a qualidade sob
aspectos diferentes. A filosofia concretiza-se nas questes de definio; a economia, na
maximizao dos lucros e no equilbrio do mercado; o marketing, nos elementos crticos
determinantes do comportamento dos compradores e na satisfao dos clientes, e a
gerncia de operaes, nas prticas de engenharia e no controle da produo.

Baseando-se nestes diferentes enfoques, Garvin identifica cinco abordagens principais
para a definio de qualidade (Viera,1995):
- Transcendental: sinnimo de excelncia nata.
- Baseada no produto: que identifica a qualidade com os atributos e/ou
ingredientes de um produto.
- Baseada no cliente: que parte da premissa que a qualidade est diante dos
olhos de quem observa.
- Baseada na fabricao: a qualidade vista como conformidade s
especificaes.
- Baseada no valor: definindo qualidade em termos de custos e preos.

Este mesmo autor tambm identifica oito dimenses ou categorias de qualidade como
esquema de anlise da qualidade: desempenho, caractersticas, confiabilidade,
conformidade, durabilidade, atendimento, esttica e qualidade percebida. Garvin afirma
que estas categorias so estanques e distintas entre si, o que permite que um produto ou
servio com alta qualidade em uma dimenso seja mal classificado em outra. Porm, em
muitos casos, as dimenses esto inter-relacionadas, pois a melhoria de qualidade em
uma dimenso, s pode ser atingida s custas de outra (Vieira,1995).


27
Estes so alguns dos principais conceitos associados qualidade, descritos sob os mais
diversos pontos de vista, embora no se tenha esgotado o assunto. vlido salientar a
necessidade de se escolher uma definio que supra com as necessidades do contexto
(ou do ambiente) onde ser empregada.

2.3 - Qualidade de Software

O software ultrapassou o hardware como a chave para o sucesso de muitos sistemas
baseados em computador. Seja o computador usado para dirigir um negocio, controlar
um produto ou capacitar um sistema, o software um fator que diferencia. A inteireza e
a oportunidade das informaes oferecidas pelo software diferenciam uma empresa de
suas concorrentes. A inteligncia e a funo oferecidas pelo software muitas vezes
diferenciam dois produtos de consumo ou indstrias idnticas.

Com os avanos da informtica cada vez mais os computadores passam a integrar a
rotina diria e a produo de software vem sofrendo um constante aumento. Os sistemas
baseados em computador esto sendo usados nas mais diversas reas e na maioria das
situaes no admitem erros. Se algum sistema de uso global deixar de funcionar,
aproximadamente 40% da populao mundial (Reed, 2000), sofrer as conseqncias do
problema.

Considerando a importncia do software na atualidade, aliada s crescentes exigncias
dos clientes, tem-se verificado um notvel aumento nos interesses pela qualidade do
software. Melhorar a qualidade do software o principal objetivo da engenharia de
software.

O foco principal da maioria das definies de qualidade de software o atendimento s
necessidades do cliente. Muitas vezes aplica-se qualidade de software a definio de
Crosby (1991) que a conformidade com os requisitos. Esta definio resume conceitos
de vrias personalidades que se destacam na engenharia de software (Kan, 1995)
(Pressman, 1995).

28

Existem duas vises de qualidade de software, uma dos clientes e outra dos que
desenvolvem o software, mas ambas concordam que o software no pode ter defeitos. O
cliente avalia o software sem conhecer seus aspectos internos, est apenas interessado
na facilidade do uso, no desempenho, na confiabilidade dos resultados obtidos e
tambm no preo do software. Os que desenvolvem o software avaliam aspectos
internos como taxa de defeitos, confiabilidade, facilidade de manuteno e tambm
aspectos de conformidade em relao aos requisitos dos clientes (ISO, 1991).

Em ambas vises, os requisitos de software formam a base de onde a qualidade
avaliada. Pode-se afirmar que a falta de conformidade com os requisitos falta de
qualidade. Alm dos requisitos, existem padres especficos que definem os critrios de
desenvolvimento que servem como diretriz para o software que est sendo produzido.
Se os critrios no so seguidos, resulta na falta de qualidade (Pressman, 1995).

Pode-se dizer que, um software de boa qualidade produz resultados teis e confiveis na
oportunidade certa; ameno ao uso, mensurvel, corrigvel, modificvel e evolutivo;
opera em mquinas e ambientes reais; foi desenvolvido de forma econmica e no prazo
estipulado; e opera com economia de recursos. Qualidade de software um conceito
muito mais amplo do que o de um software correto e bem documentado, requerendo
para ser conseguida, metodologias e tcnicas de desenvolvimento especficas (Staa,
1987).

2.4 - Qualidade do Produto e Qualidade do Processo

Raramente a qualidade pode ser incorporada ao produto final aps o processo de
desenvolvimento terminado. Portanto, a qualidade do produto de software um objetivo
do processo de desenvolvimento. Assim, ao se desenvolver um produto, importante
que se tenha previamente definidas as caractersticas de qualidade que se desejam
alcanar. Se o processo de desenvolvimento de software considerar as caractersticas de
qualidade, h uma grande tendncia de que o produto final apresente tais caractersticas.

29

Apesar de serem conceitos integrados, e na maioria das vezes dependentes, pode-se
fazer um estudo separado dos conceitos de qualidade de produto e qualidade de
processo de software.

2.4.1 - Qualidade do Produto

A qualidade do produto pode ser vista como um conjunto de caractersticas que devem
ser alcanadas em um determinado grau, para que o produto atenda s necessidades de
seus usurios. Cada caracterstica pode ser detalhada chegando-se a um amplo conjunto
de atributos, que descrevem a qualidade do produto de software. Assim, necessria a
escolha de um modelo que organize os atributos e permita avaliar a qualidade do
software (Rocha, 2001).

Vrios modelos surgiram apresentando uma hierarquia de caractersticas que
contribuem para a qualidade do produto. A norma ISO/IEC 9126 (1999) surgiu para
consolidar as diferentes vises da qualidade de produto em um modelo como norma
internacional. Este modelo est dividido em duas partes: modelo de qualidade para
caractersticas externas e internas e modelo da qualidade para qualidade em uso.

O modelo de qualidade para caractersticas externas e internas classifica os atributos de
qualidade em seis caractersticas, que so descritas brevemente na Tabela 2.2.










30
TABELA 2.2 Caractersticas de Qualidade Internas e Externas.
Funcionalidade Existncia de um conjunto de funes, que satisfazem as
necessidades explcitas e implcitas e suas propriedades
especficas.
Confiabilidade Capacidade de o software manter seu nvel de desempenho, sob
condies estabelecidas, por um perodo de tempo.
Usabilidade Esforo necessrio para usar um produto de software, bem como o
julgamento individual de tal uso por um conjunto de usurios.
Eficincia Relacionamento entre o nvel de desempenho do software e a
quantidade dos recursos utilizados sob as condies estabelecidas.
Manutenibilidade Esforo necessrio para fazer modificaes especficas no
software.
Portabilidade Capacidade de o software ser transferido de um ambiente para
outro.

FONTE: ISO/IEC 9126 (1999).

No modelo de qualidade em uso, os atributos so classificados em quatro caractersticas,
que so mostradas na Tabela 2.3. A qualidade em uso a capacidade de o produto de
software permitir a determinados usurios atingir metas especficas com efetividade,
produtividade, segurana e satisfao em um contexto de uso determinado.

TABELA 2.3 Caractersticas de Qualidade em Uso.

Efetividade
Capacidade de possibilitar aos usurios atingir metas especificadas
com acurcia e completeza.
Produtividade Capacidade de possibilitar aos usurios utilizar uma quantidade
adequada de recursos em relao efetividade.
Segurana Oferecer nveis aceitveis de risco de dados a pessoas, negcios,
software, propriedade ou ao ambiente.
Satisfao Capacidade de satisfazer usurios.

FONTE: ISO/IEC 9126 (1999).

31

2.4.2 - Qualidade do Processo

Um processo de software um conjunto de ferramentas, mtodos e prticas usadas para
produzir software. O processo de software representado por um conjunto seqencial
de atividades, objetivos, transformaes e eventos que integram estratgias para
cumprimento da evoluo de software (Pressman, 1995).

Em meados da dcada de 80, surgiu um movimento focalizando os processos de
desenvolvimento de software. Uma das maiores evolues no estudo da qualidade foi a
verificao de que a qualidade do produto importante, mas a qualidade do processo de
produo tem uma importncia ainda maior. As falhas nos processos de gerncia e
manuteno do desenvolvimento de software foram reconhecidas como inibidores
principais no crescimento da qualidade e produtividade (Lamprech, 1997). O processo
utilizado no desenvolvimento de um projeto tem grande reflexo na produtividade e na
qualidade do software desenvolvido.

Aps anos de estudos e promessas de solucionar problemas de tecnologia com mais
tecnologia, surge um movimento de compreenso de que os problemas de
desenvolvimento de software no so apenas tecnolgicos, mas gerenciais e
organizacionais.

O processo utilizado para desenvolver e manter o software afeta significativamente no
custo, qualidade e prazo de entrega do produto. O impacto to significante que a
melhoria do processo de software vista por alguns como a mais importante forma para
melhorar o produto de software (Henry, 1994).

Segundo Humphrey, para que a indstria do software contribua de forma construtiva
para a sociedade, necessrio aprender a entregar produtos com qualidade, no prazo
estabelecido e com os custos planejados. Outras indstrias, medida que

32
amadureceram, atingiram este nvel de desempenho. No h razes para que isso no
seja possvel para o software (Weber, 2001).

Um processo disciplinado faz com que o desenvolvimento e a manuteno sejam
indistinguveis em um ciclo de evoluo do produto. Para que o desenvolvimento e a
manuteno sejam feitos de maneira ordenada, as organizaes devem ter seus
processos como sendo passveis de controle, melhorias e medidas. Isto requer
programas voltados para o aumento da produtividade e da qualidade. Antes de qualquer
tentativa de uma organizao aperfeioar seu processo, deve-se conhecer como o
software desenvolvido. O conhecimento de onde o esforo deve ser concentrado
essencial. Sem o conhecimento do tipo de processo existente e os produtos
caractersticos produzidos durante o desenvolvimento, no h meio de aperfeioar ou
quantificar a qualidade do produto (Kan, 1995).

Considerar o processo de desenvolvimento uma atividade que deve ser controlada,
medida e melhorada um passo importante para torna-lo realmente efetivo. Para tanto,
indispensvel que se tenha o controle do relacionamento entre as atividades, as
ferramentas, o pessoal, os mtodos e principalmente as caractersticas do produto de
software que o objetivo final de todo o processo (Rosa, 1997).

A importncia da qualidade no setor de software indiscutvel. Assim, muitas
instituies preocuparam-se em criar modelos para auxiliar na busca to almejada
qualidade tanto do produto quanto do processo de software.

33
CAPTULO 3
MODELOS DE MELHORIA DO PROCESSO DE SOFTWARE

Como a qualidade do produto pode ser vista como uma conseqncia da qualidade do
processo, os certificados mais valiosos so aqueles que certificam o processo de
produo de um produto e no os que certificam simplesmente o produto. Os estudos
sobre qualidade, mais recentemente, so voltados para o melhoramento do processo de
software, pois ao garantir a qualidade do processo, j se est dando um grande passo
para garantir tambm a qualidade do produto.

Um importante objetivo das organizaes melhorar sistematicamente a qualidade e a
produtividade de seus processos e produtos. Por sistemtico entende-se que a
organizao pode descrever explicitamente seu processo e com base em medies
confiveis, analisar sua eficcia, assim como sugerir melhorias (Pfleeger, 1994).

Com a intensa dinmica que rege os processos de software, a definio explcita de um
processo j no uma tarefa trivial, gerencia-los, ento, ainda mais difcil. Para
amenizar esta dificuldade, foi necessria a definio de modelos de apoio a melhoria da
qualidade do processo de software.

Entre os modelos disponveis, os que mais se destacam so: a norma ISO/IEC 12207 -
Processos de Ciclo de Vida de Software (ISO, 1995); futura norma ISO/IEC 15504 ou
projeto SPICE - Software Process Improvement and Capability Determination (ISO,
1997), e o CMM - Capability Maturity Model (Paulk, 1993).

No desenvolvimento deste trabalho, o modelo CMM, em sua mais nova evoluo, o
CMMI, foi utilizado como base para delinear os pontos do processo a serem avaliados.
Tais pontos referem-se s caractersticas bsicas de um processo qualificado.



34

3.1 Modelo de Maturidade da Capacidade

Em linhas gerais, o Modelo de Maturidade da Capacidade ou CMM (Capability
Maturity Model) um modelo que baseia em um processo gradual, que leva as
organizaes a se aprimorarem continuamente, na busca de solues prprias para os
problemas existentes no desenvolvimento de software.

3.1.1 Origem do CMM

O CMM (Paulk, 1993) foi desenvolvido pelo SEI (Software Engineering Institute),
ligado a Universidade Carnegie Mellon e financiado pelo Departamento de Defesa
Norte-Americano, com o objetivo de estabelecer um padro de qualidade para o
software desenvolvido para as Foras Armadas. Este modelo foi proposto por Watts S.
Humphey, a partir de conceitos de qualidade total estabelecido por Crosby. Segundo
Tingey (1997), Crosby mostrou que a implementao de sistemas de qualidade em
empresas segue um amadurecimento gradativo em patamares denominados incerteza,
despertar, esclarecimento, sabedoria e certeza.

Em 1987, a partir do trabalho de Humphrey, o SEI lanou uma breve descrio de um
ambiente de maturidade de processo de software e um questionrio de maturidade para
avaliar o estado corrente das prticas de software e identificar as reas que necessitavam
de melhoria. Em 1991, o SEI criou o CMM, como uma evoluo deste ambiente. A
partir do lanamento e divulgao da verso 1.1 do CMM, em 1993, o tema de melhoria
do processo foi ganhando fora. Esta fora foi conseqncia dos resultados prticos
obtidos pelas organizaes que realizaram programas de melhoria com o CMM como
modelo de referncia.





35
3.1.2 - Maturidade

O SW-CMM (CMM para software, como tambm conhecido o modelo), tem seu foco
no processo de software por entender que a qualidade de um sistema de software
fortemente influenciado pela qualidade do processo utilizado para desenvolv-lo e
mant-lo. Portanto, uma premissa do SW-CMM o foco no processo da mesma forma
que no produto, pois enfocando apenas o produto se perde conhecimento de como
produzi-lo melhor, por no se ter planejado, conhecido e, constantemente, melhorado o
processo utilizado para desenvolv-lo.

Para um melhor entendimento do modelo necessria a compreenso dos conceitos de:
processo, capacidade e maturidade.

Segundo Humphrey (1989), um processo de software envolve mtodos, ferramentas e
pessoas. Para um processo funcionar satisfatoriamente ele deve possuir:
- Procedimentos e mtodos que descrevam a relao entre as tarefas.
- Ferramentas e equipamentos que dem suporte a realizao das tarefas,
simplificando e automatizando o trabalho.
- Pessoas com perfil adequado, treinadas nos mtodos e nas ferramentas para
poderem realizar as atividades adequadamente.

Este conjunto deve estar integrado harmoniosamente para funcionar de maneira eficaz
(Rocha, 2001).

A capacidade do processo de software descreve o conjunto de resultados esperados que
pode ser atingido quando se segue o processo de software estabelecido. A capacidade do
processo de software de uma organizao fornece um meio de se prever, de forma mais
provvel, os resultados a serem esperados no prximo projeto a ser empreendido pela
organizao (Gonalves, 2001).


36
A maturidade do processo de software quando um processo especfico
explicitamente definido, documentado, gerenciado, medido, controlado e efetivo. A
maturidade implica num potencial de crescimento da capacidade e indica tanto a riqueza
do processo de software de uma organizao, quanto consistncia na qual o processo
aplicado nos projetos de toda a organizao (Paulk, 1993). Em outras palavras, a
maturidade do processo pode ser traduzida como a possibilidade de entregar sistemas de
software dentro dos prazos, utilizando os mesmos recursos, planejando e atendendo
requisitos e qualidade desejados.

Quando uma organizao alcana maturidade no processo de software, ela
institucionaliza seus processos atravs de polticas, padres e estrutura organizacional.
A institucionalizao implica na construo de uma infra-estrutura e uma cultura
corporativa que suportem os mtodos, prticas e procedimentos do processo (Paulk,
1993).

O SW-CMM proporciona s organizaes um guia de como aumentar o controle sobre
seu processo de desenvolvimento e manuteno de software, e de como alterar o
ambiente em direo a uma cultura de excelncia em engenharia de software.
Concentrando-se em um conjunto limitado de atividades, as organizaes podem
melhorar seu processo e possibilitar um contnuo ganho no desempenho (Humphey,
1989).

O CMM foi concebido para o desenvolvimento de grandes projetos militares, portanto,
para sua aplicao em projetos menores e em outras reas necessrio um trabalho
cuidadoso de interpretao e adequao realidade da organizao (Rocha, 2001).

3.1.3 Estrutura do CMM

O objetivo do SW-CMM identificar foras e fraquezas de uma organizao, entender
as atividades necessrias para um programa de melhoria de processo, definir e melhorar
os processos e classificar as empresas de software.

37
O SW-CMM baseia-se em pequenos passos e no em inovaes revolucionrias. Com
base nos estudos de amadurecimento gradativo de Crosby (Tingey, 1997), estes passos
evolutivos foram organizados em cinco nveis de maturidade: inicial, repetitivo,
definido, gerenciado e otimizado. Estes nveis representam a situao da organizao
quanto ao seu processo de software (Lamprech, 1997). Tais nveis definem uma escala
para medir a maturidade do processo e avaliar a capacidade do mesmo. Alm disso,
contm diretrizes para a organizao priorizar seus esforos de melhoria.

Embora no seja uma norma emitida por uma instituio internacional (como a ISO ou
o IEEE), o SW-CMM tem tido uma grande aceitao mundial.

Se algum espera que o CMM oriente a aplicao de algum mtodo de desenvolvimento
de software altamente avanado, ir se decepcionar. O CMM opera em outro nvel, diz
respeito a aspectos que devem ser considerados para o desenvolvimento bem-sucedido
de software. descritivo, no prescritivo (Furlan, 2001), assim, concentra-se no
questionamento, no na resposta. Isto pode parecer pouco estimulante, mas era
exatamente o que a indstria de software precisava para fazer um progresso real no
modo de desenvolvimento de software.

Embora o CMM requeira a documentao minuciosa do processo, ele no tende a
burocratizao, uma vez que prope que o processo documentado seja adaptado s
caractersticas da organizao e da categoria de software que desenvolve. O CMM no
pretende resolver problemas, ele se prope a ajudar pessoas e organizaes a encontrar
suas prprias solues. O CMM tambm no uma proposta de auto-ajuda, , sim, um
modelo estabelecido em bases racionais e que requer, para obter sucesso, apoio da
gerncia, um bom domnio de conhecimento, habilitao tcnica, participao e esforo
de todos os envolvidos (Fiorini, 1999).





38

3.1.4 Implementao do CMM

A implementao do SW-CMM cclica, composta de fases distintas: anlise da
situao (avaliao), comparao com o prximo nvel do modelo, planejamento das
aes corretivas, execuo destas aes e nova anlise da situao (Pires, 1998).

A primeira medida a ser tomada para realizar um programa de melhorias sobre SW-
CMM, a realizao de uma avaliao dos processos de software da organizao. Uma
avaliao formal do CMM, onde a organizao certificada em um nvel de
maturidade, realizada somente por auditores credenciados pelo SEI. Ao contrrio de
outros programas de qualidade, como a srie ISO 9000, no existem entidades
certificadoras, apenas pessoas fsicas certificadas pelo SEI.

O processo de avaliao iniciado com a aplicao de um questionrio. O SW-CMM
acompanhado por um questionrio intitulado Questionrio da Maturidade ou
simplesmente MQ - Maturity Questionnaire (Zubrow, 1994). O objetivo do MQ
colher dados iniciais sobre a organizao avaliada, isto , trata-se de uma fonte primria
de informao. A partir destes dados, novos questionrios so criados, de acordo com a
necessidade dos avaliadores.

De um modo geral, as avaliaes so realizadas atravs de questionrios, entrevistas e
anlise de documentaes da organizao. Todo o trabalho realizado por uma equipe
(grupo avaliador) liderada por um auditor certificado pelo SEI. O resultado final um
relatrio onde so apontados os pontos fracos e fortes, bem como oportunidades de
melhorias, avaliando-se o posicionamento dos processos em relao ao modelo SW-
CMM e seus nveis.

A partir do resultado da avaliao, a organizao dever estabelecer equipes de
melhoria de processo, que conduziro projetos, com o objetivo de definir e implementar
os processos considerados prioritrios.

39
O SEI desenvolveu muitos mtodos de avaliao baseados no CMM com foco no
processo de desenvolvimento de software. Um mtodo um tcnica ou modo de
proceder para se aplicar um modelo.

A iniciativa da avaliao pode ser da prpria empresa, quando esta decide iniciar um
programa de melhorias em seus processos de software (avaliao interna), ou de uma
empresa que deseja avaliar concorrentes para um contrato (avaliao externa).

A Avaliao da Capacidade do Software baseado no CMM, ou SCE - Software
Capability Evaluation (Byrnes, 1996), um mtodo para avaliao do processo de
desenvolvimento de software de um fornecedor, ou seja, para aquisio de software,
para monitoramento de contratos e para incentivos. Esta avaliao feita por um grupo
externo, raramente so includas pessoas da organizao avaliada ao grupo avaliador.

A Avaliao para Melhoria do Processo Interno baseado no CMM, ou CBA-IPI -CMM
Based Appraisal for Internal Process Improvement (Dunaway, 1996), um mtodo para
avaliao interna, tem a caracterstica de uma auto-avaliao, utilizado quando uma
organizao quer avaliar seu prprio processo de desenvolvimento de software.

Estes dois mtodos de avaliao (SCE e CBA-IPI) so de acordo com a Estrutura de
Avaliao do CMM, ou CAF - CMM Appraisal Framework (Marters, 1995). A CAF
identifica os requisitos e caractersticas intrnsecas das avaliaes baseadas no CMM,
para melhorar a consistncia e integridade dos mtodos e seus resultados. A CAF, em
sua nica verso, usa o CMM v1.1 como modelo de referncia.

3.2 Modelo de Maturidade da Capacidade Integrado

O modelo SW-CMM tornou-se, ao longo de uma dcada de uso por vrias organizaes
de software de diversos tamanhos e setores, o modelo mais conhecido, usado e
respeitado pela comunidade de engenharia de software (Belloquim, 2002). Por ser um

40
modelo baseado em experincias de organizaes de software, trata-se de um modelo
que sugere prticas eficientes e eficazes, no sendo apenas um modelo terico.

Desde sua primeira verso, lanada em 1991, na esteira de sucesso do SW-CMM,
diversos outros modelos foram criados visando cobrir outras reas de interesse, como
por exemplo:
- SA-CMM - Software Acquisition CMM: usado para avaliar a maturidade de
uma organizao em seus processos de seleo, compra e instalao de
software desenvolvido por terceiros.
- SE-CMM - System Engineering CMM: avalia a maturidade da organizao em
seus processos de engenharia de sistemas, concebidos como algo maior que o
software. Um sistema inclui o software, o hardware e quaisquer outros
elementos que participam do produto completo.
- IPD-CMM - Integrated Product Development CMM: ainda mais abrangente
que o SE-CMM, inclui tambm outros processos necessrios produo e
suporte ao produto, tais como suporte ao cliente e processos de fabricao.
- P-CMM - People CMM: avalia a maturidade da organizao em seus
processos de administrao de recursos humanos no que se refere a software,
recrutamento e seleo de profissionais e treinamento.

O surgimento de todos estes outros modelos acabou trazendo alguns problemas. Como
nem todos os modelos usavam a mesma terminologia, um mesmo conceito podia
receber nomes diferentes em cada modelo. Os modelos tinham diferentes nmeros de
nveis ou formas diferentes de avaliar o processo. Outro problema era os altos custo de
treinamento, avaliao e harmonizao para organizaes que quisessem usar mais de
um modelo. Assim, tornou-se necessria uma padronizao.

Alm disso, a experincia no uso de SW-CMM, durante uma dcada, serviu para
identificar pontos em que o modelo poderia ser melhorado. O surgimento do projeto
SPICE levou necessidade de tornar o CMM compatvel com a norma ISO 15504
(1997), resultado deste projeto.

41
Por estas razes, o SEI iniciou um projeto chamado CMMI - CMM Integration. Seu
objetivo era gerar uma nova verso do CMM que resolvesse esses problemas.
Concretamente, a primeira idia, como o nome sugere, foi integrar os diversos CMMs
em uma estrutura nica, todos com a mesma terminologia, processos de avaliao e
estrutura. O projeto se preocupou ainda em tornar o CMM compatvel com a norma ISO
15504, de modo que avaliaes em um modelo sejam reconhecidas como equivalentes
aos do outro. E, naturalmente, incorporar ao CMM as sugestes de melhoria surgidas ao
longo dos anos (CMMI, 2002a).

O Modelo de Maturidade da Capacidade Integrado, ou CMMI, foi resultado da
integrao dos modelos (CMMI, 2002a):
- SW-CMM V2C - Capability Maturity Model for Software V2.0, draft C.
- SECM - EIA Interim Standard 731 System Engineering Capability Model.
- IPD-CMM - Integrated Product Development Capability Maturity Model,
draft 0.98.

O CMMI claramente uma melhoria sobre o CMM. No entanto, apesar das melhorias
incorporadas ao CMMI, seu precursor - o CMM - continua sendo um modelo bastante
eficiente (Furlan, 2001).

3.2.1 Estrutura do CMMI

H quatro reas de interesse disponveis para implementar o CMMI, tais reas so
chamadas de disciplinas. So elas (CMMI, 2002a):
- Engenharia de Sistemas.
- Engenharia de Software.
- Desenvolvimento de Processo e Produto Integrado.
- Contratos de Fornecedores.

A disciplina Engenharia de Sistemas compreende o desenvolvimento do sistema como
um todo, podendo incluir ou no o software. Os engenheiros de sistema focalizam na

42
transformao das necessidades do consumidor, expectativas e restries para o
desenvolvimento dos produtos e suporte aos mesmos.

A disciplina Engenharia de Software cobre o desenvolvimento de sistemas de software.
Os engenheiros de software focalizam na aplicao de uma abordagem sistemtica,
disciplinada e quantitativa para desenvolver, operar e manter o software.

A disciplina de Desenvolvimento de Processo e Produto Integrado, baseado no modelo
uma abordagem sistemtica que busca uma oportuna colaborao dos interessados,
atravs da vida do produto para melhor satisfazer as necessidades, expectativas e
requisitos do cliente. Um processo, para suportar esta disciplina, deve estar integrado
com outros processos da organizao.

Quando o projeto muito complexo, normalmente a implementao de algumas funes
terceirizada. A disciplina Contrato de Fornecedores cobre a aquisio de produtos de
fornecedores, atravs do monitoramento das atividades dos fornecedores antes da
entrega do produto.

O CMMI foi criado para integrar estas disciplinas e resolver o problema de
organizaes que utilizam mltiplos modelos CMM. O CMMI fornece modelos com
foco em disciplinas individuais e em disciplinas combinadas. A escolha da disciplina
varia de acordo com o escopo da organizao na qual ser implementado o modelo.

Cada uma destas disciplinas pode ser implementada utilizando duas abordagens:
- Abordagem em estgios: proporciona uma estratgia pr-definida para
melhoria organizacional, similar ao SW-CMM existente.
- Abordagem contnua: proporciona flexibilidade para que as organizaes
escolham quais processos sero enfatizados ou priorizados para melhoria,
conforme sua disponibilidade financeira para a implementao de cada
processo.


43
Os modelos CMMI so:
- CMMI-SW - CMMI for Software Engineering: este modelo inclui apenas a
disciplina Engenharia de software.
- CMMI-SE - CMMI for Systems Engineering: este modelo inclui apenas a
disciplina Engenharia de Sistemas.
- CMMI-SE/SW - CMMI for Systems Engineering and Software Engineering: este
modelo inclui as disciplinas Engenharia de Software e Engenharia de Sistemas.
- CMMI-SE/SW/IPPD - CMMI for Systems Engineering, Software Engineering,
and Integrated Product and Process Development: Este modelo inclui as
disciplinas do modelo anterior acrescido da disciplina Desenvolvimento de
Processo e Produto Integrado.
- CMMI-SE/SW/IPPD/SS - CMMI for Systems Engineering, Software
Engineering, Integrated Product and Process Development, and Supplier
Sourcing: este o modelo mais completo e inclui todas as disciplinas
(Engenharia de software, Engenharia de Sistemas, Desenvolvimento de Processo
e Produto Integrado e Contratos de Fornecedores).

Cada modelo tem sua descrio em cada uma das abordagens (em estgios e contnua).
A escolha do modelo e da abordagem depende da realidade e das necessidades da
organizao. Se uma organizao preocupa-se exclusivamente com Engenharia de
Software ou exclusivamente com Engenharia de Sistemas, ento os modelos
apropriados seriam CMMI-SW e CMMI-SE, respectivamente. No entanto, se a
organizao preocupa-se com ambas disciplinas o modelo CMMI-SE/SW seria o mais
adequado, o que evitaria repeties e a sobrecarga administrativa, que comum na
manuteno de disciplinas isoladas. Finalmente, os modelos CMMI-SE/SW/IPPD e
CMMI-SE/SW/IPPD/SS so apropriados para organizaes que empreguem
Desenvolvimento de Processo e Produto Integrado em suas prticas, combinado ou no
com Contratos de Fornecedores.




44

3.2.2 Componentes do Modelo

Os principais componentes do CMMI so: as reas de processo, os objetivos
especficos, as prticas especficas, os objetivos genricos e as prticas genricas.

Os modelos CMM no descrevem em detalhes todas as reas do processo que so
envolvidas no desenvolvimento e manuteno de software. Certas reas tm sido
identificadas como determinantes da capacidade do processo e melhoria do mesmo.
Estas reas de processo foram identificadas com base em anos de experincia em
engenharia de software e gerenciamento dos profissionais do SEI.

Cada rea de processo um conjunto de prticas que, quando executadas corretamente,
satisfaz um conjunto de objetivos considerados importantes para implementar melhorias
significantes na rea de processo em questo. As reas de processo do CMMI so:

Foco no processo organizacional: o propsito desta rea de processo planejar e
implementar melhorias no processo organizacional, atravs do entendimento dos pontos
positivos e negativos dos processos da organizao.

Definio de Processo Organizacional: o objetivo desta rea estabelecer e manter
um conjunto de itens de processo organizacional. Tais itens incluem a descrio do
processo e elementos (tarefas e atividades) do processo, descrio de modelos de ciclo
de vida, guia de execuo de processo, dados e documentao do processo.

Treinamento Organizacional: esta rea relaciona-se com o desenvolvimento das
habilidades e conhecimentos das pessoas para que elas possam desempenhar seu papel
efetiva e eficientemente.

Desempenho do Processo Organizacional: o propsito desta rea estabelecer e
manter um entendimento quantitativo da capacidade dos processos padres em suportar

45
objetivos de qualidade e de desempenho, visando colher os dados necessrios ao
gerenciamento quantitativo dos projetos da organizao.

Disposio e Inovao Organizacional: esta rea permite a seleo e distribuio
ordenada de melhorais (incrementais e inovadoras) que podem aumentar a habilidade da
organizao para alcanar seus objetivos de qualidade e desempenho do processo.

Planejamento de Projeto: esta rea compreende o estabelecimento e manuteno de
planos que definam as atividades do projeto.

Controle e Monitorao de Projeto: o propsito desta rea proporcionar um
entendimento do processo utilizado em um projeto, tal que aes corretivas apropriadas
possam ser tomadas quando o desempenho do projeto desvia significativamente do
plano estabelecido.

Gerenciamento de Contrato de Fornecedores: esta rea objetiva gerenciar a aquisio
de produtos de fornecedores de forma que exista um contrato formal.

Gerenciamento de Projeto Integrado: esta rea tem por finalidade estabelecer e
gerenciar o projeto e o envolvimento das pessoas relevantes (indivduos ou grupos
envolvidos com o projeto, como fornecedores, clientes, usurios, e outros), de acordo
com um processo definido e integrado baseado nos processos padres da organizao.

Gerenciamento de Riscos: o objetivo desta rea identificar potenciais problemas
antes que eles ocorram, atravs do planejamento e execuo de atividades especficas
em situaes de riscos, visando atenuar os impactos adversos que possam influenciar no
alcance aos objetivos.

Gerenciamento Quantitativo do Projeto: o propsito desta rea gerenciar
quantitativamente o processo definido para o projeto, visando atingir os objetivos de
qualidade e de performance estabelecidos para o mesmo.

46
Gerenciamento de Requisitos: esta rea de processo tem o propsito de gerenciar os
requisitos dos produtos do projeto e seus componentes, e identificar inconsistncias
entre estes requisitos e os estabelecidos no plano.

Desenvolvimento de Requisitos: analisar os requisitos do cliente, do produto e dos
componentes do produto, de modo que eles realmente supram as necessidades das
pessoas envolvidas com o projeto.

Soluo Tcnica: o propsito desta rea projetar, desenvolver e implementar solues
para os requisitos, abrangendo produtos, componentes de produtos e produtos do ciclo
de vida do processo, cada um individualmente ou combinados.

Integrao de Produto: o objetivo reunir todos os componentes do produto,
assegurar que o produto, quando integrado, funciona bem.

Verificao: garantir que os produtos de trabalho vo ao encontro de seus requisitos
especificados.

Validao: demonstrar que um produto ou componentes do produto cumpre seu uso
desejado quando mantido em seu ambiente especfico.

Gerenciamento da Configurao: o propsito estabelecer e manter a integridade dos
produtos de trabalho usando identificao, controle, relatrio de status e auditoria da
configurao.

Garantia de Qualidade de Produto e Processo: o objetivo desta rea garantir a
entrega de produtos e servios de alta qualidade, atravs da avaliao da qualidade do
processo de desenvolvimento.

Medies e Anlises: o objetivo desta rea desenvolver e sustentar uma capacidade
de medio usada para suportar o gerenciamento das informaes necessrias.

47
Resoluo e Anlise de Deciso: o propsito desta rea analisar decises usando um
processo da avaliao formal que avalia as possveis alternativas e estabelece critrios.

Resoluo e Anlise das Causas: o objetivo desta rea analisar as causas dos defeitos
e outros problemas e tomar atitudes para que eles no voltem a ocorrer no futuro.

Cada rea de processo composta por seus objetivos especficos. Estes objetivos
descrevem o que deve atingido para satisfazer cada rea. Cada objetivo especfico, por
sua vez, composto por prticas especificas, tais prticas descrevem o que deve ser
executado para atingir cada objetivo especfico.

Os objetivos genricos so assim chamados porque um mesmo objetivo aplicado a
mltiplas reas de processo. Estes objetivos so organizados em prticas genricas, que
so atributos a serem observados que indicam se a implementao e a
institucionalizao de cada rea de processo efetiva, repetvel e duradoura. As reas de
processo do CMMI so comuns para ambas abordagens.

3.2.3 Abordagem em Estgios

Esta abordagem permite uma fcil migrao do SW-CMM para o CMMI, por terem
uma estrutura bastante semelhante.

A abordagem em estgios descreve uma seqncia de atividades de melhorias, iniciando
com prticas bsicas de gerenciamento e progredindo atravs de um caminho pr-
definido de nveis de melhoria sucessivos, cada um servindo de base para o prximo
nvel (CMMI, 2002a). Cada nvel compreende o nvel de maturidade do processo de
software da organizao como um todo.

A abordagem em estgios organiza as reas de processo em 5 nveis de maturidade, para
dar suporte e orientar a melhoria do processo, indicando quais reas de processo
implementar para atingir cada nvel.

48
Os nveis de maturidade so: inicial, gerenciado, definido, quantitativamente
gerenciado e otimizado. Cada nvel consiste em um conjunto pr-definido de reas de
processo. O nvel de maturidade medido pelo atendimento a todos os objetivos
genricos (agrupados em caractersticas comuns) e especficos de todas as reas de
processo do nvel em questo, como ilustra a 3.1.
















FIGURA 3.1 Estrutura do CMMI em estgios.
FONTE: CMMI, (2002a).

Os Nveis de Maturidade da abordagem em estgios so:

Nvel 1 - Inicial: O desenvolvimento de software caracterizado como ad-hoc ou
catico. A organizao no possui um ambiente estvel, caracterizada pela no
existncia de processos definidos, abandono de processos em momentos de crises e falta
de comprometimento com os projetos. Os sucessos dependem de esforos individuais e
rea de
Processo 1
Nveis de
Maturidade
Objetivo
Especfico
Prticas
Especficas
Caractersticas
Comuns
Prticas
Genricas
rea de
Processo 2
rea de
Processo n
Objetivo
Genrico

49
na maioria das vezes no so capazes de repetir sucessos anteriores. Os projetos destas
organizaes normalmente excedem custos e cronogramas.

Nvel 2 - Gerenciado: Uma organizao neste nvel tem seus processos planejados,
executados, medidos e controlados. A disciplina do processo reflete na continuidade das
prticas mesmo em momentos de crise. Os projetos so executados e gerenciados de
acordo com um plano documentado. Neste nvel os requisitos, processos, produtos de
trabalho e servios so gerenciados. Alm disso, compromissos so estabelecidos e
revisados entre as pessoas interessadas quando necessrio. Os produtos e servios
satisfazem seus requisitos, padres e objetivos.

Nvel 3 - Definido: Os processos das organizaes neste nvel so compreendidos e
descritos em procedimentos, padres, ferramentas e mtodos. estabelecido um
conjunto de processos padres da organizao. Estes processos padres so utilizados
por toda a organizao. Os gerentes de departamento estabelecem objetivos baseados
neste conjunto de processos padres e asseguram que estes objetivos so
apropriadamente enfocados.

A diferena entre o Nvel 2 e o Nvel 3 que no primeiro os padres, descrio de
processos e procedimentos podem ser bastante diferente em cada projeto. No Nvel 3 os
processos devem ser descritos com mais detalhes e devem ser seguidos de forma mais
rigorosa.

Nvel 4 - Quantitativamente Gerenciado: Os processos so controlados utilizando
estatsticas e outras tcnicas quantitativas. Objetivos quantitativos para qualidade e
desempenho so estabelecidos e usados como critrio no gerenciamento dos processos.
Os objetivos quantitativos so baseados nas necessidades dos consumidores, clientes,
organizao e executores do processo. Medidas detalhadas do desempenho do processo
so coletadas e analisadas estatisticamente. Causas de possveis variaes de
desempenho do processo so identificadas e corrigidas para prevenir ocorrncias
futuras.

50
Nvel 5 - Otimizado: Os processos so melhorados continuamente baseados na
compreenso quantitativa das causas comuns de variao do processo. As organizaes
neste nvel focalizam na melhoria contnua do desempenho do processo atravs de
melhorias incrementais e inovaes tecnolgicas. Objetivos de melhorias quantitativas
de processo so estabelecidas e continuamente revisados para refletir em mudanas nos
objetivos do negcio.

Na abordagem em estgios, as reas de processo so agrupadas em nveis de
maturidade. Com exceo do Nvel 1, todos os nveis do CMMI em estgios composto
por reas de processo. A seguir so apresentadas as reas de processo em seus
respectivos nveis.

Nvel 2: Gerenciado
- Gerenciamento de Requisitos.
- Planejamento de Projeto.
- Controle e Monitorao de Projeto.
- Gerenciamento de Contrato de Fornecedores.
- Medies e Anlises.
- Garantia de Qualidade de Produto e Processo.
- Gerenciamento da Configurao.

Nvel 3: Definido
- Desenvolvimento de Requisitos.
- Soluo Tcnica.
- Integrao de Produto.
- Verificao.
- Validao.
- Foco no Processo Organizacional.
- Definio de Processo Organizacional.
- Treinamento Organizacional.
- Gerenciamento de Projeto Integrado.

51
- Gerenciamento de Risco.
- Resoluo e Anlise de Deciso.

Nvel 4 : Quantitativamente Gerenciado
- Desempenho do Processo Organizacional.
- Gerenciamento Quantitativo do Projeto.

Nvel 5: Otimizao
- Disposio e Inovao Organizacional.
- Resoluo e Anlise Causal.

Para uma organizao alcanar um nvel de maturidade, deve atingir o objetivo genrico
e os objetivos especficos de todas as reas de processo do nvel em questo, atravs da
execuo das prticas genricas e especficas deste nvel (CMMI, 2002a).

Por exemplo, para atingir o Nvel 2 de maturidade, a organizao deve implementar as
sete reas de processo do Nvel 2. Para implementar cada uma destas reas necessrio
atender aos objetivos especficos de cada uma, atravs da execuo de suas prticas
especficas. Por exemplo, a rea de processo Gerenciamento de Requisitos, em
particular, tem apenas um objetivo especfico, que Gerenciar Requisitos e suas
prticas especficas so: obter um entendimento dos requisitos, obter comprometimento
com os requisitos, gerenciar as mudanas de requisitos, manter um controle bidirecional
dos requisitos, identificar inconsistncia entre os requisitos e os produtos de trabalho.

Alm do cumprimento dos objetivos especficos, a organizao que busca o Nvel 2 de
maturidade, deve alcanar o objetivo genrico deste nvel, que : Institucionalizar um
Processo Gerenciado. Ento, a organizao deve executar todas as prticas genricas
deste objetivo, que so: estabelecer uma poltica organizacional, planejar o processo,
fornecer recursos, designar responsabilidades, treinar pessoas, gerenciar configurao,
identificar e envolver as pessoas interessadas pelo projeto, monitorar e controlar o
processo, avaliar objetivamente o processo, revisar o s situao e comparar com o

52
prximo nvel. Estes objetivos genricos devem ser aplicados a cada rea de processo
do Nvel 2. Vale lembrar que a execuo destas prticas genricas determina o quanto a
implementao da rea de processo institucionalizada na organizao, isto , o quanto
a implementao da rea de processo efetiva, repetvel e duradoura.

Para uma organizao alcanar o Nvel 3 de maturidade, preciso cumprir todas as
reas do Nvel 2 e mais as do Nvel 3. E assim at o nvel 5. Uma organizao pode
estar no Nvel 2 e possuir prticas de nveis superiores, mas ser apenas Nvel 2 por no
executar todas as reas de processo do nvel superior. Assim, nesta abordagem, a
tentativa de saltar um nvel improdutiva, pois cada nvel serve de fundao para o
nvel superior.

3.2.4 Abordagem Contnua

A abordagem contnua utiliza 6 nveis de capacidade, sendo eles: incompleto,
executado, gerenciado, definido, quantitativamente gerenciado e otimizado. Os
nveis de capacidade traam um caminho evolutivo de melhoria para cada rea de
processo.

A abordagem contnua, ao mesmo tempo em que define uma seqncia para melhoria
de uma rea de processo, tambm permite uma flexibilidade na escolha das reas de
processo a serem melhoradas. Assim, a organizao pode direcionar seus esforos de
melhoria nas reas que julgar mais relevantes para o desenvolvimento como um todo.

Nesta abordagem, assim como na abordagem em estgios, cada rea de processo
composta por objetivos especficos e genricos, organizados em prticas especficas e
genricas respectivamente, com exceo do Nvel 0. Cada rea de processo possui seus
objetivos especficos prprios, compostos por suas prticas especficas. Os objetivos
genricos e prticas genricas so aplicados a mltiplas reas de processo, descrevendo
uma seqncia de nveis de capacidade. Cada nvel possui um objetivo genrico,
comum a todas as das as reas no mesmo nvel, como mostrado na Figura 3.2.

53












FIGURA 3.2 Estrutura do CMMI contnuo.
FONTE: CMMI (2002b).

Em resumo, a abordagem contnua, descreve uma discreta seqncia de melhorias a ser
aplicadas a cada rea de processo.

Os Nveis de Capacidade da abordagem contnua so (CMMI, 2002b):

Nvel 0 Incompleto: uma rea de processo considerada incompleta quando ela no
executada ou parcialmente executada. Isto , um ou mais objetivos especficos da rea
no executado.

Nvel 1 Executado: Uma rea de processo executada quando o objetivo genrico e
todos os objetivos especficos da rea so satisfeitos.

Nvel 2 Gerenciado: Uma rea de processo gerenciada uma rea executada que
tambm planejada, est de acordo com uma poltica, emprega pessoas com habilidades
tcnicas para produzir adequadamente seus produtos, envolve as pessoas que tem
interesses no projeto, monitorado, controlado e revisado.
rea de
Processo 1
Objetivo
Especfico
Prticas
Especficas
Prticas
Genricas
rea de
Processo 2
rea de
Processo n
Objetivo
Genrico
Nveis de
Capacidade

54
Nvel 3 Definido: Uma rea de processo definida uma rea gerenciada e que est de
acordo um conjunto de processos padres da organizao.

Nvel 4 Quantitativamente Gerenciado: Uma rea de processo quantitativamente
gerenciada uma rea definida que controlada utilizando estatsticas e outras tcnicas
quantitativas. Os objetivos quantitativos para a qualidade e desempenho do processo so
estabelecidos e usados como critrio no gerenciamento do processo.

Nvel 5 Otimizado: Uma rea de processo otimizada uma rea quantitativamente
gerenciada que modificada e adaptada para atingir os objetivos de negcio. Um
processo otimizado focaliza em melhorais tecnolgicas incrementais e inovadoras.

O nvel de capacidade focaliza na crescente habilidade da organizao para desenvolver,
controlar e melhorar seu desempenho na rea de processo em questo. Cada nvel de
capacidade construdo sobre o outro, seguindo uma ordem de melhoria de processo.

Nesta abordagem cada rea de processo possui caractersticas relativas a mais de um
nvel. Assim, uma rea de processo que, no modelo em estgios, pertence
exclusivamente ao Nvel 2, no modelo contnuo pode ter caractersticas que a coloquem
em outros nveis. Em outras palavras, no modelo contnuo, cada rea classificada
separadamente, de modo que a organizao possa ter reas no Nvel 1, outras no Nvel
2, assim por diante.

3.2.5 Perspectivas de Implementao do CMMI

A implementao do CMMI pode ser visualizada sob duas perspectivas:
- O CMMI pode ser implementado visando uma avaliao para melhoria do
processo interno, que pode ser aplicada a uma organizao ou a um projeto, de
forma expandida ou restrita, tendo em vista os objetivos de melhoria mais
relevantes. A escolha da disciplina, das reas de processo a serem melhoradas,
do nvel de maturidade/capacidade a ser alcanado deve depender das prticas

55
que apiam as necessidades e objetivos de negcio da organizao. A escolha
das reas a serem focalizadas deve ser cuidadosa, devido ao inter relacionamento
entre os componentes do modelo. Os esforos de melhoria tambm devem ser
analisados tendo em vista os objetivos de custo e cronograma das atividades de
melhoria. Esta perspectiva tem as caractersticas de uma auto-avaliao.

- O CMMI tambm implementado visando a formalizao da
capacidade/maturidade do processo da organizao, para fins de comparao
com outras organizaes (em processos de terceirizao) ou disseminao
pblica com propsito de marketing. Neste caso, a implementao deve
obedecer de forma mais rigorosa s indicaes do modelo, com o objetivo de
garantir a consistncia dos resultados da avaliao (CMMI, 2002b).

Os critrios de desenvolvimento, definio e utilizao dos mtodos de avaliao
baseados no CMMI, esto descritos nos Requisitos de Avaliao para CMMI, ou ARC -
Appraisal Requirements for CMMI, compatvel com a ISO/IEC 15504. O ARC uma
evoluo do CAF (CMM Appraisal Framework) (Marsters, 1995) que foi uma estrutura
produzida originalmente para fornecer uma base comum para avaliaes aplicando o
CMM. O ARC define os mtodos para avaliao interna (auto-avaliao) e externa
(avaliao de fornecedores), incorpora as mltiplas disciplinas do CMMI e as
representaes em estgios e contnua (ARC, 2001).


56
































57
CAPITULO 4
PANORAMA ATUAL

4.1 A Indstria do Software

A partir das ltimas dcadas do sculo XX, o desenvolvimento dos pases foi
surpreendido por novos fatores e causas que passaram a determinar os novos padres do
crescimento econmico mundial. Os avanos em Tecnologias de Informao e
Comunicao (TICs) tornaram possvel difundir e acessar informaes em uma
velocidade e em uma escala nunca vista antes.

Os investimentos em TICs tm sido o componente mais dinmico dos investimentos em
negcio. Os pases que obtiveram um aumento do PIB nos anos 1990, geralmente
acumularam mais capital em TICs. Igualmente importantes, so os dados relativos ao
acmulo de capital em software, que entre os anos de 1995 a 1999, representou um
tero de todo o capital investido em TICs. Uma explicao para a onda de investimento
em software o rpido aparecimento e difuso de novas tecnologias de propsito geral,
como a Internet. O que novo, comparado a outras tecnologias, que a Internet prov
uma infra-estrutura para novas formas de negcios eletrnicos (Arajo, 2003).

Organizaes de software em todo o mundo empregam cerca de 7 milhes de tcnicos e
geram anualmente uma receita de US$ 600 bilhes (Cordeiro, 1999). A indstria de
software vista atualmente como um dos segmentos mais promissores, com um enorme
potencial futuro. O mercado do software tem um crescimento invejvel, mantendo taxas
de crescimento superiores a 15% ao ano (Arajo, 2003).

Os Estados Unidos continuam na liderana de gastos com software. Na Amrica Latina,
o Brasil o lder de investimentos e ocupa o dcimo lugar na escala mundial. Em 2001,
os movimentos brasileiros no setor somaram US$ 7,2 bilhes, valor trs vezes maior
que os de 1993 (WITSA, 2002). As importaes brasileiras somam aproximadamente

58
US$ 1 bilho. O Programa para Promoo da Excelncia do Software Brasileiro
SOFTEX, do Ministrio da Cincia e Tecnologia, expandiu o desenvolvimento do
software em vrias partes do pas e contribuiu para o crescimento das exportaes de
software para US$ 100 milhes, em 2001(Arajo, 2003). Porm, o mercado local ainda
detm grande parcela da produo de software nacional.

Apesar do expressivo mercado interno, o Brasil ainda no encontrou o caminho que o
levasse a uma conquista significativa de outros mercados e o projetasse
internacionalmente na indstria do software. Ainda so poucas as organizaes
brasileiras que conseguem avanar no mercado internacional. A insero da indstria do
software nacional no mercado mundial um grande desafio para o pas, e h condies
bsicas para enfrenta-lo, atravs de uma poltica agressiva, articulada e consistente.

Na ltima dcada, polticas governamentais e alguns programas prioritrios do
Ministrio da Cincia e Tecnologia, para o setor de informtica, tm propiciado o
crescimento dos investimentos em pesquisa e desenvolvimento por parte da iniciativa
privada. Isso tem atrado investimentos de grandes empresas internacionais e os
produtos fabricados no pas tm preos competitivos em relao aos seus similares
importados. No campo tecnolgico, o setor de informtica o segmento industrial que
mais investe em pesquisa e desenvolvimento proporcionalmente ao seu faturamento.

Para a indstria de software nacional se destacar internacionalmente, principalmente
considerando o ambiente de avanos tecnolgicos muito rpidos e um processo de
globalizao irreversvel, necessria a articulao de alguns fatores fundamentais.
Segundo a SEPIN - Secretaria de Poltica de Informtica e Automao do Ministrio da
Cincia e Tecnologia, tais fatores so inovao, seletividade e qualidade. A inovao
exercitada atravs da pesquisa e desenvolvimento de novos produtos para nichos
especficos de mercado. A seletividade desenvolvida principalmente atravs da
definio do que produzir no pas e em que escala. A qualidade , inquestionavelmente,
um requisito indispensvel para insero neste mercado.


59
Um atrativo recente da industria do software so os processos de terceirizao
(outsourcing) dos setores de Tecnologia da Informao (Arajo, 2003). O interesse em
reduzir custos um dos principais fatores da terceirizao, que tem se mostrado como
propulsor de crescimento para pases como ndia e China, detentores de mo-de-obra
imensa e barata que tem atrado o mercado norte-americano. Este um mercado
bastante promissor tambm para o Brasil, tanto para a expanso do software no mercado
nacional, quanto para o reconhecimento internacional.

H indstrias de software interessadas em resolver problemas de software atravs da
normalizao da qualidade. A terceirizao de servios de informtica por grandes
empresas pblicas ou privadas, e a necessidade de expanso dos mercados nacionais e
internacionais, so os dois eixos da busca pela certificao de processos do segmento. A
Amrica Latina, principalmente o Brasil, um mercado bastante atrativo e potencial
para consultorias especializadas em resolver problemas de qualidade.

H bases de dados histricos nacionais que permitem afirmar que o Brasil tem projetos
e estratgicas em direo ao alcance de padres internacionais efetivos em qualidade e
produtividade no setor de software, h evidncias de que a qualidade de software no
pas tem apresentado tendncias de melhoria contnua. Programas de qualidade total,
sistemas da qualidade ou similares tem apresentado um nmero crescente de
implantao a cada ano (PBQP, 2002). Muito se tem falado da obteno da certificao
CMM como passaporte para o mercado externo, mas outro motivador da busca de
certificaes a possibilidade de adotar processos que tornem o crescimento mais
consistente.

4.2 Os Processos de Software

Um projeto de software eficiente aquele que visa a construo de um produto de
software que satisfaa as necessidades do cliente e seja desenvolvido e entregue dentro
do custo e prazo especificado. Em outras palavras, as trs principais caractersticas de
um projeto so: custo, planejamento e qualidade, onde qualidade representa quo bom o

60
produto e satisfaz o cliente. Um projeto um sucesso quando atinge estas trs
caractersticas - custo, planejamento e qualidade.

Porm, a indstria de software pode citar muitos exemplos de projetos que fracassaram.
As principais causas destes fracassos podem ser combinadas em uma categoria chamada
falha no processo. Um projeto de software falha, na maioria das muitas vezes, porque o
processo seguido no apropriado. As maiores razes para o descontrole so: objetivos
pouco claros, planejamento ruim, utilizao de novas tecnologias de forma impensada,
falta de metodologia de gerenciamento do projeto e pessoal insuficiente (Glass, 1998).
Para um projeto ter sucesso, necessrio que o processo utilizado seja apropriado.
Como o processo tem grande efeito sobre a qualidade e produtividade, um modo de
melhorar este par est na melhoria do processo utilizado pela organizao.

Infelizmente muitos projetos de informtica, quando no so cancelados antes de
chegarem ao fim, so concludos com custos e prazos muito alm dos estipulados e sem
cumprir com todos os requisitos especificados para o produto (Cordeiro, 1999) (Glass,
1998), o que traz grandes prejuzos para o setor. Os profissionais de desenvolvimento de
software passam mais tempo corrigindo defeitos do que com a inovao de sistemas.

A dinamicidade do processo de software dificulta o gerenciamento efetivo de projetos
de software, devido s alteraes constantes nos planos de projetos, redistribuio de
atividades, incluso/excluso de atividades, adaptao de cronogramas, re-alocao de
recursos, novos acordos com os clientes e entregas intermedirias no previstas. Um
projeto de software tambm deve adaptar-se ao ambiente, dependendo da
disponibilidade de recursos, ferramentas e habilidades da equipe (Roullier, 2001).

Portanto, o problema da melhoria da eficincia do processo de desenvolvimento de
software ainda apresenta-se como um dos grandes desafios a serem superados nos
prximos anos, no s devido ao aumento contnuo da demanda pela sociedade, mas
principalmente pela sua magnitude econmica crescente. Observa-se que ainda
permanecem associados ao desenvolvimento de software problemas crnicos como a

61
baixa qualidade dos produtos gerados, o alto grau de insatisfao dos clientes e o
constante descumprimento das metas oramentrias e prazos estabelecidos (Augusto,
1997).

Normalmente, pode-se verificar que muitas das tomadas de decises vitais ligadas aos
problemas de qualidade so tomadas sem fundamentao em fatos e dados concretos.
Freqentemente prevalecem as experincias do gerente, acrescidas de opinies emitidas
pelos membros da equipe, muitas vezes sem maior embasamento terico ou prtico
(Augusto, 1997).

Felizmente, na ltima dcada, houve uma grande preocupao com a modelagem e
melhorias do processo de software. H uma forte tendncia de que nos prximos anos as
organizaes sejam pressionadas por seus concorrentes a reduzir substancialmente os
prazos para entrega de produtos. As organizaes que forem capazes de integrar,
harmonizar, e acelerar seus processos de desenvolvimento e manuteno de software
tero a primazia do mercado (Rocha, 2001).

4.3 A Utilizao do CMM

Desde 1993, a evoluo da qualidade nas empresas de software no Brasil vem sendo
acompanhada a partir de pesquisas diretas, conduzidas a cada dois anos pela Secretaria
de Poltica de Informtica e Automao do Ministrio da Cincia e Tecnologia, no
mbito do Subcomit Setorial da Qualidade e Produtividade em Software, do Programa
Brasileiro da Qualidade e Produtividade (Weber, 2001). No ltimo levantamento,
publicado em 2002, foi constatado que o CMM o modelo mais utilizado no Brasil,
quando comparado com a Norma ISO/IEC 12207 e projeto SPICE (PBQP, 2002).

O CMM aparece como sendo conhecido por 75% e utilizado por 21% das organizaes
pesquisadas. Percentuais menores foram apurados para conhecimento (61%) e uso (4%)
do SPICE (PBQP, 2002), como mostra o Figura 4.1.


62
12%
21%
4%
55%
54%
57%
25%
33%
39%
ISO 12207 CMM SPICE
No Conhece
Conhece e no
usa
Conhece e usa

FIGURA 4.1 - Conhecimento do Modelo CMM, Norma ISO 12207 e SPICE.
FONTE: PBQP (2002).

As tabelas 4.1 e 4.2 mostram, respectivamente, os dados das duas ltimas pesquisas
realizadas (1999 e 2001), onde pode se ver um acentuado crescimento do conhecimento
e utilizao do SPICE. No entanto, o CMM ainda aparece como mais conhecido e
utilizado.

TABELA 4.1 - Conhecimento dos Modelos CMM e SPICE 1999.

CMM SPICE
Categorias
N % N %
Conhece e usa sistematicamente 8 1,8 1 0,2
Conhece e comea a usar 36 8,1 14 3,2
Conhece, mas no usa 165 37,2 121 27,3
No conhece 234 52,8 308 69,4
Base 443 100 444 100

FONTE: PBQP (2001).






63

TABELA 4.2 - Conhecimento dos Modelos CMM e SPICE 2001.

CMM SPICE
Categorias
N % N %
Conhece e usa sistematicamente 16 3,9 4 1,0
Conhece e comea a usar 71 17,1 13 3,2
Conhece, mas no usa 223 53,7 232 56,7
No conhece 105 25,3 160 39,1
Base 415 100 409 100

FONTE: PBQP (2002).

O nvel de conhecimento do CMM mais que triplicou, em termos percentuais, passando
de 14%, em 1995, para 47% em 1999 (Weber, 2001), conforme o Figura 4.2. O SEI tem
registro de 16 organizaes brasileiras que se submeteram a uma avaliao CMM, e
alcanaram at o Nvel 3 de maturidade (Report, 2003).

3
11
86
5
24
71
10
37
53
Conhece e
usa
Conhece, mas
no usa
No conhece
1995
1997
1999

FIGURA 4.2 - Conhecimento no Modelo CMM (%).
FONTE: (Weber, 2002).


64
O MCT trabalha numa proposta de incentivo financeiro para estimular as empresas de
desenvolvimento de software no Brasil a aprimorar a qualidade. A idia inicial,
estudada pelo grupo que coordena o Programa Brasileiro da Qualidade e Produtividade
a de garantir recursos que financiem a certificao de empresas com base em normas
internacionais. A medida, considerada fundamental para o amadurecimento do setor,
dever resultar em trs importantes benefcios: 1) softwares mais qualificados; 2)
equilbrio na balana comercial do setor; e 3) maior participao do Brasil no mercado
internacional de software. Todos os benefcios conjugados resultariam na acelerao
dos bons resultados que o setor tem conseguido nos ltimos 10 anos. O CMM o
modelo que dever ser adotado pelo Brasil para a certificao das empresas (SOFTEX,
2003).

Em termos mundiais, o sucesso e a crescente aceitao do CMM comprovado pelo
nmero de avaliaes formais realizadas com base neste modelo. Segundo dados do
SEI, entre os anos de 1987 e 2002, foram realizadas 2616 avaliaes formais em 1978
organizaes em 51 pases. O nmero de reavaliaes (mais de 500 organizaes)
tambm comprova a eficincia do modelo (Report, 2003). Em dez anos de existncia, o
CMM serviu para trilhar os caminhos de melhoria (formal e informalmente) em cerca
de 5000 organizaes (Report, 2003).

Devido a recente criao do CMMI, poucos registros ainda se tm sobre a
implementao deste modelo, visto que a eficincia de um modelo s se avalia a mdio
e longo prazo da implementao de suas prticas. No entanto, quando analisado sob o
ponto de vista de seu antecessor - o CMM - pode-se prever que o CMMI tambm ser
um sucesso. O CMMI incorpora toda a teoria de melhoria de processo do CMM, com
conceitos que foram sendo gerados em anos de experincias prticas de implementao
deste modelo em inmeras organizaes. Assim, pode-se afirmar que o CMMI um
modelo to ou mais eficiente que o CMM.

Segundo dados do Relatrio Anual de 2002 do SEI (Report, 2003), h registro de
organizaes com experincia em SW-CMM que esto migrando rapidamente para o

65
CMMI e adequando seus nveis de maturidade aos deste modelo. Alm disso, verifica-
se tambm um grande e crescente nmero de pessoas que recorrem aos cursos de CMMI
oferecidos pelo SEI. As organizaes que esto migrando para este modelo consideram
esta experincia bastante positiva (Carter, 2002).

4.4 O CMM e o Porte das Organizaes

No Brasil, quando a implantao do CMM analisada sob o ponto de vista do porte,
verifica-se o reduzido nmero de micro e pequenas organizaes que utilizam
sistematicamente o modelo, conforme mostra a tabela 4.3. Porm, importante destacar
que o CMM foi criado para ser usado por todos os tipos de organizaes, contudo, para
organizaes menores, ele precisa ser interpretado (CMMI, 2002b). A interpretao do
CMM deve ser feita de modo que prticas j existentes na organizao sejam
aproveitadas e, se necessrio, melhoradas para que contribuam para atingir as metas do
CMM (Fiorini, 1999).

TABELA 4.3 Conhecimento do CMM Segundo o Porte da Organizao (%).
Categorias Total Micro Pequena Mdia Grande
Conhece e usa sistematicamente 3,9 0,7 2,9 2,5 11,4
Conhece e comea a usar 17,1 3,4 20,4 30,0 29,5
Conhece mas no usa 53,7 62,2 48,9 47,5 48,9
No conhece 25,3 33,8 27,7 20,0 10,2

FONTE: PBQP (2002).

Estudos mostram que h uma certa relao entre o nvel de maturidade e o tamanho da
organizao, onde o nvel de maturidade diretamente proporcional ao tamanho da
organizao. As pequenas organizaes tendem a apresentar nveis de maturidade mais
baixos, enquanto as organizaes maiores encontram-se em nveis mais elevados
(McLain, 2001) (Report, 2003). Segundo o SEI, cerca de 28% das organizaes

66
avaliadas com base no CMM no mundo so organizaes com menos de 50 empregados
(Report, 2003).

A definio do porte das organizaes um tanto quanto complexa, visto que h
algumas divergncias sobre o assunto. Uma organizao classificada como de pequeno
porte no Brasil pode no apresentar esta mesma classificao em outros pases. No
entanto, para se entrar em um consenso, tendo em vista a realidade do mercado
nacional, possvel classificar as organizaes por porte considerando sua fora de
trabalho, quer seja efetiva (scios, dirigentes e empregados efetivos) quanto total
(efetivos mais terceiros prestadores de servio, bolsistas e estagirios), adotando-se
como critrio: microempresas (de 1 a 9 pessoas), pequena (de 10 a 49 pessoas), mdias
(de 50 a 99 pessoas) e grandes (100 ou mais pessoas) (PBQP, 2002). Sob este critrio,
confirma-se a predominncia de micro e pequenas empresas, com percentual de 69%
(fora efetiva) e 61% (trabalho total), segundo a Figura a seguir.


36%
33%
9%
22%
27%
11%
37%
24%
Micro Pequena Mdia Grande
Efetiva
Total

FIGURA 4.3 Porte das empresas quanto a fora de trabalho efetiva e total (2000).
FONTE: PBQP (2002).

Rosa (1997), na elaborao de uma proposta de avaliao baseada no SPICE, verificou
que, no Brasil, a maioria das organizaes de software de pequeno porte, que muitas
vezes possuem bons produtos, mas no tm condies financeiras de expandir suas
atividades (Rosa, 1997).

67
Segundo dados do Plano Anual de Servios do Instituto Brasileiro de Geografia e
Estatstica de 2000, empresas com at cinco pessoas representam 88% das empresas de
Tecnologia da Informao e Comunicao (TICs), que lidam com o desenvolvimento de
software, de solues e aplicativos, processamento de dados, atividades de banco de
dados, servios de transmisso de dados, voz e imagem e hospedagem de sites (Arajo,
2003).

Logo, as organizaes classificadas como de micro e pequeno porte juntas tm uma
grande importncia para o mercado econmico brasileiro. Porm, nestas mesmas
organizaes registram-se os menores esforos direcionados qualidade na produo de
software. A maioria das organizaes que j implantaram ou esto em fase de
implantao de programas de qualidade total, sistemas da qualidade ou similares, so
organizaes classificadas como de grande porte (PBQP, 2002).

Tendo em vista os dados mostrados na tabela 4.4, das organizaes que tem implantado
algum programa de qualidade, cerca de 21% caracterizam-se por micro e pequenas
empresas, enquanto as mdias aparecem com 37% e as grandes com 41%. Fica claro
que por algum motivo micro e pequenas organizaes tem mostrado pouco interesse na
implantao destes programas.

TABELA 4.4 - Implantao de Programas de Qualidade (%).

Categorias
Total Micro Pequena Mdia Grande
Implantado 25,1 5,6 22,1 47,6 53,1
Em estudo ou implantao 26,2 23,6 32,4 23,8 22,9
No tem 48,7 70,8 45,5 28,6 24,0

FONTE: PBQP (2002).




68
4.5 Custos e Benefcios do CMM

Segundo Pdua (2003), a organizao imatura comete erros clssicos. Muitos desses
erros so relativos ao produto, decorrentes dos requisitos. Outros decorrem de enganos
relativos aos fatores da produo: processos, pessoas e tecnologia.

Dos trs fatores de produo, a tecnologia o mais atraente. Existe um otimismo natural
quanto aos resultados da aplicao de novas tecnologias. Porm, a tecnologia tem seu
prprio ritmo de evoluo. A tecnologia s oferece retorno do investimento quando
colocada nas mos de pessoas capacitadas, trabalhando dentro de processos adequados.
Investir na capacitao de pessoas absolutamente necessrio. Entretanto no fcil
introduzir e manter um programa consistente de capacitao de pessoas. Formar pessoas
difcil, caro e demorado. Alm disso, muitas pessoas produzem menos que a sua
capacidade permitiria, que pode acontecer por falta de liderana, deficincia de apoio e
inadequao de processos. Dos investimentos nos fatores de produo, as melhorias no
processo trazem retornos em prazos relativamente curtos (Pdua, 2003).

Os anos de experincia com o modelo constataram que quanto maior o nvel de
maturidade alcanado, maior os ndices de produtividade (medida pela habilidade de
prever oramento e cronogramas, pessoal eficiente, deteco precoce de defeitos,
nmero de linhas de cdigo produzidas por unidade de tempo), menor o tempo gasto no
desenvolvimento de um produto, maior a qualidade do produto desenvolvido (medida
pela satisfao dos clientes, nmero de defeitos, gastos relacionados com a manuteno
corretiva) e maiores os benefcios alcanados como retorno dos investimentos (McLain,
2001).

Alguns dos benefcios que podem ser esperados pela implementao efetiva do CMM
so: retorno de investimentos em menor prazo; diminuio de re-trabalho; reduo de
custos de re-testes; comunicao melhorada; diminuio de problemas de integrao;
reduo de custos gerais; diminuio da mdia de taxa de defeito com aumento do
tamanho dos produtos; aumento da produtividade; oramentos coerentes e planejamento

69
de tempo adequado; aumento da moral do empregado; diminuio da presso sobre o
engenheiro de software, e respeito de outras organizaes e clientes em funo da
clareza, prazos e boa documentao liberada.

Para algumas empresas j certificadas, os principais motivadores da melhoria de
processo variam em torno da organizao interna e da possibilidade de adotar processos
que tornem o crescimento mais consistente. A organizao interna e seu conseqente
ganho de eficincia parecem ser o principal benefcio percebido pelas empresas recm
certificadas. Mudanas contnuas e sistemticas permitem a definio clara dos papis
de cada um dentro da empresa, os processos tornam-se previsveis, sendo possvel
estimar prazos mais realistas subsidiados por argumentos tcnicos.

Relatrios apontam que na relao custo benefcio, observou-se um retorno de 5 para 1,
ou seja, para cada dlar investido, economizaram 5 dlares posteriormente, em termos
de reduo de custos de re-trabalho e aumento de produtividade e qualidade (Spinola,
1997).

A nica forma de medir o resultado da implementao de processos de qualidade a
medio contnua e agregada ao longo do tempo. Aumentos de produtividade superiores
a 100%, e redues de defeitos na entrega superiores a 70% so freqentemente
relatados. A qualidade d resultado e se paga facilmente, mas necessrio esperar sua
maturao. Falta de qualidade sai muito mais caro.

Seria de se indagar em quanto tempo um determinado nvel CMM pode ser atingido. A
passagem do Nvel 1 (imaturo) para o Nvel 2 pode levar mais tempo, a movimentao
entre os outros nveis geralmente levar cerca de dois anos (Gonalves, 2001). O SEI
tambm reporta esses nmeros com base nas avaliaes realizadas no mundo,
mostrando que o tempo mdio de maturao de um nvel para o outro de 2 anos (do
Nvel 1 ao 2: 23 meses; do Nvel 2 ao 3: 22 meses; do Nvel 3 ao 4: 28 meses; do Nvel
4 ao 5: 17 meses). Embora haja um intervalo de oscilao para esses nmeros, uma
organizao precisaria ter uma razo muito boa para acreditar que pode fazer isso mais

70
rapidamente que a mdia mundial (Furlan, 2001). Os Nveis 2 e 3 so os que trazem
maior retorno imediato (Fiorini, 1999).

A dificuldade em se alcanar os nveis depende do contexto da organizao que busca a
melhoria. Se uma organizao comea do incio (Nvel 1), ento provvel que achar
o Nvel 2 muito difcil. Satisfazer o Nvel 2 pode ser uma tarefa complexa, pois as
pessoas que trabalham no Nvel 1 usualmente encontram-se pressionadas com os limites
de prazos e custos, trabalham em ambientes pouco organizados, vendo as melhorias
meramente como esforo adicional, e no como uma forma de reduzir esforos atravs
de uma melhor organizao do trabalho (Fiorini, 1999). Se conseguir atingir o Nvel 2
provvel que considere os nveis sucessivos mais fceis. Se j possui um programa de
melhoria de processo implementado, baseado em outro modelo (por exemplo, ISO
9000), ento poderia evoluir para o Nvel 3 relativamente depressa. O Nvel 4 seria o
prximo grande desafio, pois inclui o uso de mtodos estatsticos para controle do
desenvolvimento de software, o que requer mais conhecimento de estatstica aplicada do
que o gerente de software comum possui. O Nvel 5, finalmente, seria relativamente
direto para os que j atingiram o Nvel 4 (Furlan, 2001).

Ao mesmo tempo em que demanda altos investimentos, o processo de conquista da
CMM no garantia de novos negcios, ou mesmo de transio interna tranqila.
Alguns desafios se colocam para as organizaes e os benefcios podem ser percebidos
ao longo prazo.

O custo de um programa de melhoria varia de acordo com o contexto em que ocorre. As
avaliaes com o intuito de obteno de certificao formal no CMM so caras e
consomem muito tempo. Assim, muitas organizaes encontram dificuldades em
executa-las (Wiegers, 2000). Vrias organizaes tm buscado aperfeioar o seu
processo de desenvolvimento a partir de referncias do modelo CMM, mas no buscam
uma certificao formal, apenas usam o modelo para estabelecer um caminho de
melhoria no processo de desenvolvimento e manuteno do software. Estas
organizaes devero adaptar o CMM sua realidade e implementar melhorias

71
focalizadas (uma ou outra rea chave). Neste caso, a organizao pode optar por realizar
a avaliao por sua conta, baseada nos documentos do SEI, ou contar com o auxlio de
consultores especializados. Esta abordagem tem custos mais baixos.

4.6 CMM em Pequenas Organizaes

No incio deste trabalho foi feita uma pesquisa emprica em organizaes brasileiras que
obtiveram certificao formal no CMM e com aquelas que se apiam neste modelo
informalmente. Neste estudo, foram abordadas as maiores dificuldades que estas
organizaes encontram na implementao do CMM.

A primeira dificuldade encontrada a escolha do modelo a utilizar (CMM, SPICE ou
outras normas ISO). As organizaes no tm conhecimento sobre qual modelo
atender melhor s suas necessidades, evidenciando o desconhecimento sobre o
contedo dos modelos disponveis e a necessidade de uma maior publicidade sobre o
tema.

A complexidade do CMM um fator que dificulta sua implementao. At mesmo as
organizaes maiores, encontram barreiras para interpretar as prticas do CMM. Outra
dificuldade a interpretao das respostas do Questionrio de Maturidade do CMM
(Zubrow, 1994) para o levantamento da qualidade do processo. O fato da maioria da
documentao do CMM estar em ingls tambm considerado um obstculo
implementao do modelo.

Outra barreira comum a necessidade do envolvimento e a disponibilidade das pessoas,
para reunies, planejamentos e workshops. O apoio diretivo tambm decisivo. O
sucesso do mtodo depende da interao das pessoas com o CMM, a falta de
treinamento dificulta o envolvimento das pessoas.

A institucionalizao das prticas tambm dificultosa, visto que, muitas vezes uma
prtica executada, mas diante de qualquer problema, os procedimentos so esquecidos

72
e parte-se para a codificao. Muitas organizaes que desenvolvem softwares acabam
desconsiderando os procedimentos quando aumentam as presses de final de prazo.

O grau de dificuldade encontrado na implementao do CMM varia muito, dependendo
de diversos fatores como cultura, nmero de profissionais envolvidos, conhecimentos
do modelo, apoio de consultoria externa, objetivos de negcios, entre outros.

A eficincia do CMM indiscutvel, o que muitas vezes se questiona a viabilidade de
uma certificao formal em organizaes menores, devido aos recursos que so
indispensveis avaliao e melhoria do processo.

Segundo Rosa (1997), os modelos de avaliao e melhoria de processo de software mais
conhecidos e utilizados por grandes organizaes so difceis de serem aplicados a
organizaes menores. Esta dificuldade ocorre porque estes modelos no se adaptam
facilmente a realidade da pequena organizao, onde o nmero de funcionrios e o
faturamento so reduzidos. Alm disso, freqentemente h orientaes e
responsabilidades citadas nestes modelos que so totalmente desconhecidos ou
inadequados a um ambiente menor (Roullier, 2001).

So normalmente duas as razes que distanciam as organizaes de pequeno porte da
adoo de um modelo de melhoria de processo, como o CMM.
- Dificuldade e/ou impossibilidade de satisfazer as prticas CMM.
- Custo para implementar um programa de melhoria de processo (Broadman,
1994).

O CMM mostra-se eficiente em empresas de mdio e grande porte, onde nveis
sucessivos do CMM so crescentemente atingidos. Contudo, as pequenas empresas
freqentemente enfrentam problemas de falta de recursos, o que torna difcil manter um
foco e interesse em atingir o prximo nvel CMM, o qual representa uma grande
melhoria ao nvel corrente.


73
verdade que o modelo CMM foi desenvolvido de incio tendo-se em mente as grandes
empresas que forneciam software para a Fora Area Americana. Entretanto, foi feito
um esforo para que o texto do CMM fosse to genrico quanto possvel, de modo a
permitir a aplicao do modelo a organizaes de qualquer tamanho.

O ncleo do problema que o texto do CMM passvel de interpretao, isto ,
necessrio no entender muito literalmente algumas coisas. A forma mais literal de
interpretao do CMM aplica-se principalmente a organizaes grandes. A necessidade
destes vrios grupos, por exemplo, pode assustar muita gente em organizaes menores.
A impresso que d que ter mais gente nestes grupos do que desenvolvendo o
software propriamente dito. O problema est em se interpretar o conceito destes grupos.
(Belloquim, 1999). Na verdade, tudo uma questo de se trabalhar com "papis", isto ,
uma mesma pessoa pode assumir diferentes papis ao longo do projeto, participando de
vrios daqueles grupos. O importante que as atividades sejam cumpridas e que se
saiba claramente quem so as pessoas responsveis por cada uma. Portanto, possvel
que estes grupos existam em organizaes de qualquer tamanho.

importante destacar que a interpretao do CMM para atender as necessidades da
pequena empresa no um trabalho simples (Broadman, 1994). No processo de
implantao do CMM em uma organizao pequena necessrio saber interpretar as
regras gerais em um contexto menor. Deve-se, tambm, ter muito cuidado para no
torna-lo uma burocracia em pequenas organizaes (Fiorini, 1999).

Segundo Paulk (1998), um dos pais do CMM, os objetivos das reas de processo,
definidas pelo CMM, so suficientemente gerais para serem aplicadas em organizaes
ou projetos de qualquer tamanho, embora sua implementao possa ser radicalmente
diferente. Paulk afirma que o objetivo primrio da pequena empresa a sobrevivncia.
O principal problema no incio do processo de melhoria decidir se a situao atual
mesmo insatisfatria, em que a melhoria ajudar, encontrar os recursos e assumir
responsabilidades para a melhoria do processo e para definir e dispor de processos

74
existentes. Um dos requisitos para o sucesso do CMM investir tempo e dinheiro na
melhoria do processo (Paulk, 1999).

As dificuldades de implementao do CMM, relacionadas com a adequao das prticas
em ambientes menores, j foram abordadas e solues foram propostas como: o
Processo Pessoal de Software, ou PSP - Personal Software Process (Humphrey, 2000a);
o Processo de Software para Equipes, ou TSP - Team Software Process (Humphrey,
2000b), e o prprio CMMI.

Com o intuito de iniciar a melhoria de processo em nvel pessoal, Humphrey props
uma srie de processos pessoais. O PSP um modelo pessoal, que objetiva treinar o
programador para que este seja capaz de definir seus prprios processos de
desenvolvimento e medir o seu trabalho. Em resumo, o PSP descreve uma seqncia de
pequenos projetos, que devem ser realizados seguindo rigorosamente os processos, que
incluem um conjunto de formulrios, scripts e relatrios predefinidos (Humphrey,
2000a). Como uma seqncia natural, Humphrey introduziu o TSP, que uma
disciplina de desenvolvimento em equipe baseada no PSP (Humphrey, 2000b).

notrio que qualquer tipo de atividade que provoque mudanas causa algum tipo de
desconforto. A implementao do CMM no trivial, obviamente que apresenta
algumas dificuldades para todos os tipos de organizao que queira implementa-lo,
pode-se admitir tambm que em pequenas organizaes estas dificuldades so ainda
maiores (como custo e interpretao das prticas). Porm, organizaes menores tm
algumas vantagens em situaes de mudana de cultura, pois geralmente apresentam
menos inrcia e burocracia, alm da maior facilidade de comunicao e
acompanhamento de projetos.

75
CAPITULO 5
MELHORIA DO PROCESSO DE SOFTWARE

5.1 Diretrizes Iniciais

So muitos os obstculos enfrentados pelas organizaes na busca pela melhoria da
qualidade de seu processo de desenvolvimento e manuteno do software. No entanto,
os benefcios colhidos pela implementao de um programa de melhoria bem
direcionado so comprovadamente gratificantes.

Comear talvez a mais importante e mais difcil parte de qualquer trabalho. No caso
da melhoria do processo, o levantamento de como o software est sendo desenvolvido
na organizao a primeira atividade a ser executada. O sucesso de um programa de
melhoria do processo depende grandemente da confiabilidade dos dados adquiridos na
fase de avaliao, visto que uma avaliao competente permite a elaborao de um
plano de melhoria mais eficiente e compatvel com a realidade da organizao. O
objetivo de um programa de melhoria de processo no simplesmente impor regras pr-
definidas de como fazer as coisas, mas necessrio levar em considerao as
caractersticas e necessidades da organizao em questo.

Este trabalho busca minimizar as dificuldades que as organizaes encontram para sair
da inrcia da imaturidade do processo, isto , aqui so propostas diretrizes para a criao
de um mtodo que permita a elaborao de uma avaliao inicial menos rigorosa, mas
efetiva. Porm, difcil, se no impossvel, uma proposta que possa ser til a todos os
tipos de organizaes. Melhorar a qualidade do processo envolve algumas variveis, tais
como: as caractersticas e necessidades da organizao, as pessoas envolvidas, as
prticas j existentes, os recursos disponveis, entre outras.

A necessidade de se adaptar os modelos existentes realidade da organizao que
deseja implementa-los, comprova a subjetividade quanto ao direcionamento de um

76
programa de melhoria. Segundo Fiorini (1999), no existem solues gerais,
simplesmente porque cada caso um caso. Qualquer processo de desenvolvimento
utilizado precisa ser adaptado organizao e aos projetos por ela desenvolvidos.

Para que este trabalho pudesse ser realmente til na introduo aos conceitos de
qualidade de processo, considerando a impossibilidade de atender a todas as
organizaes, foi necessria a definio clara do escopo da organizao a ser enfocada.
Depois de escolhido o escopo da organizao, foi necessrio a escolha do modelo mais
adequado s necessidades da mesma.

5.2 Escolha do Escopo da Organizao

As caractersticas de uma avaliao variam de acordo com o tipo da organizao e seus
interesses. Assim, preciso a escolha e a determinao clara do ambiente para o qual a
avaliao ser desenvolvida.

O termo organizao, aqui utilizado, deve ser compreendido como uma empresa
privada, instituio governamental ou um departamento dentro de uma organizao, que
desenvolva software como produto de venda ou para uso prprio.

Como constatado anteriormente, as organizaes que desenvolvem software,
classificadas como de micro e pequeno porte (PBQP, 2002), so de grande importncia
para a economia nacional (Arajo, 2003). Uma infeliz coincidncia que estas mesmas
organizaes so as que mais se distanciam dos termos de qualidade de software.
Trabalhos direcionados a estas organizaes so de grande valia para a engenharia de
software.

No entanto, a classificao por porte ainda muito vasta para o contexto deste trabalho,
pois as organizaes classificadas como de micro e pequeno porte so aquelas com at
49 pessoas (PBQP, 2002). A introduo de um programa de melhoria em uma

77
organizao que possui 10 pessoas desenvolvendo software, pode ser bastante distinta
de um programa direcionado a uma organizao com quase 50 pessoas.

Com o intuito de limitar mais o conceito de pequenas organizaes aqui utilizado,
este trabalho est direcionado a organizaes que possuem de 5 a 15 profissionais
envolvidos no desenvolvimento de software. Esta uma mdia razovel, visto que, em
organizaes muito pequenas (neste caso, com menos de 5 profissionais), o
estabelecimento de padres ou procedimento especficos para o processo pode ser
invivel, justamente pelo acentuado grau de informalidade presente na cultura das
mesmas. Por outro lado, quanto maior o nmero de pessoas envolvidas, maior a
complexidade para a introduo de padres e mudanas de procedimentos. Para garantir
a eficincia de um programa de melhoria em organizaes com mais profissionais (no
caso, mais de 15 pessoas), pode se fazer necessrio um apoio especializado e maior
disponibilidade de recursos.

O escopo da organizao a que se destina este trabalho, no se define apenas pelo
nmero de profissionais. H ainda outros fatores a serem observados. Este trabalho
prope as diretrizes para que organizaes com recursos limitados possam caminhar em
direo ao mnimo de qualidade no processo de desenvolvimento. Assim, a
primariedade das prticas aqui propostas, no sero teis para organizaes que j
tiveram contato com um programa de melhoria.

Em resumo, os trs fatores definidores do escopo organizacional so: o tamanho da
organizao, a capacidade do processo atual e a disponibilidade de recursos. Portanto,
este trabalho se destina a pequenas organizaes (de 5 a 15 profissionais de software),
que apresentam um processo de software imaturo e poucos recursos disponveis a um
programa de melhoria.

vlido salientar que uma organizao caracterizada como imatura pode desenvolver
produtos de software com qualidade, mas seu desempenho depende da competncia das
pessoas. Mudando as pessoas a qualidade pode cair. Assim, os maiores problemas so

78
de ordem gerencial e no de ordem tcnica (Rocha, 2001). A maturidade de uma
organizao em engenharia de software mede o grau de competncia tcnica e gerencial
que esta organizao possui para produzir software de boa qualidade, dentro de prazos e
custos razoveis e previsveis (Pdua, 2003).

5.3 - Escolha do Modelo de Melhoria

Na corrida pela qualidade do processo de desenvolvimento de software, uma dos
primeiro desafios a escolha do modelo de melhoria a ser utilizado. A escolha do
modelo deve ser baseada nas necessidades da organizao.

Como j mencionado (na seo 4.3), o CMM um modelo j consagrado e comea a ser
fortemente utilizado no Brasil. Este trabalho baseado na mais nova evoluo deste
modelo - o CMMI. Este modelo, alm de reunir as mais novas prticas de excelncia em
engenharia de software, apresenta facilidade de adaptao aos mais variados tipos de
organizao e compatvel com outras normas como SPICE.

Outro atrativo do CMM (e seus derivados) a disponibilidade de informaes, tanto do
modelo em si, quanto a sua base conceitual e a interpretao por avaliadores (Paula,
2003), na Internet pelo endereo http://www.sei.cmu.edu

A estrutura flexvel do CMMI bastante interessante, permitindo que este modelo possa
se adaptar s mais diferentes realidades. O CMMI oferece muitas opes visando a
adaptabilidade do modelo ao escopo da organizao. Assim, so necessrias outras
escolhas referentes a este modelo, como: a abordagem, a perspectiva, a disciplina e as
reas de processo.

5.4 - Escolha da Abordagem

O CMMI apresentado em duas abordagens: abordagem em estgios e abordagem
contnua (que foram respectivamente apresentadas nas sees 3.2.3 e 3.2.4). A escolha

79
da abordagem a ser utilizada tambm deve ser cuidadosa. Enquanto a abordagem em
estgios usa os nveis de maturidade para medir a melhoria do processo, a abordagem
contnua utiliza nveis de capacidade.

Os nveis de maturidade, que pertencem abordagem em estgios, avaliam a
maturidade da organizao como um todo. H 5 nveis de maturidade e cada nvel
compreende um conjunto pr-definido de reas de processo.

Os nveis de capacidade, utilizado pela abordagem contnua, avaliam a melhoria de cada
rea de processo. Pode-se dizer que a abordagem contnua mais flexvel, mas mais
complexa de administrar. indicada para organizaes que no tem necessidade de
implementar todas as reas de processo, podendo priorizar a melhoria de reas mais
importantes ou urgentes. Alm de dar flexibilidade de escolha na ordem de prioridade
na melhoria destas reas (CMMI, 2002b).

Uma outra situao em que a organizao se beneficia da abordagem contnua quando
existe uma carncia de suporte pela alta administrao. Se um gerente de nvel mdio
quer implementar o CMM, mas no consegue sensibilizar a alta administrao, ele
pode, em escala reduzida, implantar um conjunto menor de reas de processo, com
maior rapidez e custo mais baixo, de modo a ser capaz de mostrar resultados que
facilitem a venda do CMM para a alta administrao (Belloquim, 2002).

Porm, a representao contnua pode dar a falsa impresso de que as reas de processo
do CMMI so completamente independentes, que possvel ser Nvel 5 em algumas
reas e Nvel 0 em outras. Embora esta representao seja mais flexvel na hora de
priorizar a implementao de prticas, existem dependncias entre as reas que no
podem ser ignoradas (CMMI, 2002b).

A abordagem contnua, em particular, pode ser de grande valia para organizaes que
estejam comeando sua jornada nos caminhos da melhoria da qualidade dos processos

80
de software (Belloquim, 2002). Portanto, neste trabalho foi escolhida a abordagem
contnua, por ser a mais adequada para o escopo da organizao em questo.

5.5 - Escolha da Perspectiva

O CMMI pode ser implementado sob duas perspectivas: na forma de uma auto-
avaliao para melhoria do processo interno ou na forma de uma avaliao externa para
fins de comparaes em processos de terceirizao (como mostradas na seo 3.2.5).

A avaliao aqui proposta no tem o objetivo de enquadrar uma organizao em um
nvel de maturidade/capacidade do CMMI. Este modelo est sendo utilizado na
determinao das prticas necessrias a melhoria do processo interno de
desenvolvimento e manuteno do software. Este trabalho prope uma estratgia para
que a organizao auto-avalie seu processo de software, de modo a identificar e
priorizar os pontos que necessitarem de maiores esforos de melhoria.

Alm disso, este trabalho prope uma avaliao informal. Uma avaliao formal
quando realizada por um auditor certificado pelo SEI. A avaliao aqui proposta bem
menos rigorosa, isto , no cumpre com todos os requisitos de uma avaliao CMMI
definidos no ARC (2001), assim seus resultados no podem ser comparados com
avaliaes formais deste modelo.

5.6 - Escolha da Disciplina

Os modelos CMMI so direcionados em reas de interesse ou disciplinas (Engenharia
de Software, Engenharia de Sistemas, Desenvolvimento de Processo e Produto
Integrado e Contratos de Fornecedores, apresentadas na seo 3.2.1). A escolha da
disciplina depende das caractersticas da organizao e do que se quer melhorar,
lembrando que uma das caractersticas do CMMI o oferecimento de modelos que
integram estas disciplinas.


81
O presente trabalho foi baseado no modelo CMMI direcionado disciplina de
Engenharia de Software, sendo assim, foi utilizado o modelo CMMI-SW (CMMI,
2002b). Porm, vale citar que, como neste trabalho foram utilizadas somente as prticas
bsicas, tais prticas so encontradas em todos os modelos CMMI que incluem a
disciplina Engenharia de Software.

As escolhas feitas at o momento, permitiram a definio de uma base para o
levantamento da qualidade do processo de software. Em resumo, este trabalho prope as
diretrizes para o desenvolvimento de um mtodo de auto-avaliao menos rigorosa,
baseado no modelo CMMI para Engenharia de Software em sua abordagem contnua - o
CMMI-SW Contnuo (CMMI, 2002b), direcionado a pequenas organizaes que
disponibilizam de poucos recursos para iniciar um programa de melhoria de processo de
software.

5.7 - Escolha das reas de Processo

A escolha das reas a serem avaliadas na abordagem contnua no uma tarefa simples,
pois depende a realidade da organizao em questo (como seus objetivos de negcio,
recursos disponveis, entre outros). O CMMI descreve 22 reas de processo. As
organizaes que esto dando seus primeiros passos em direo a melhoria de processo
podem encontrar dificuldades na escolha das reas a serem enfocadas em um primeiro
momento. Obviamente que, para a obteno da excelncia em qualidade de software, o
CMMI aconselha que todas suas reas sejam enfocadas gradualmente.

A observao do histrico de sucesso do SW-CMM (Paulk, 1993) pode auxiliar na
escolha destas reas. O SW-CMM baseou-se em algumas premissas para organizar parte
do conhecimento em engenharia de software em um modelo que concretamente pudesse
auxiliar na melhoria do processo. Uma das premissas a de que os maiores problemas
das organizaes de software eram gerenciais e no tcnicos. Essas premissas
apontavam para solues que, em um primeiro momento, focassem na utilizao de
princpios bsicos de gerencia de projetos para arrumar a casa, gerar resultados

82
imediatos e preparar a organizao para as prximas etapas de melhoria. Sem uma
gerncia de projetos bem estabelecida, o risco de qualquer outra iniciativa no produzir
os resultados esperados muito grande.

As primeiras reas de processo a serem satisfeitas pelo SW-CMM (e tambm CMMI)
so referentes a aspectos gerenciais, que visam orientar a organizao para que esta seja
capaz de planejar suas atividades e cumpri-las. Este aspecto dos modelos CMM muito
importante, pois muitas vezes a organizao possui conhecimento tcnico, para o
desenvolvimento de software, mas faltam os conhecimentos administrativos, o que
essencial para que a organizao cresa e seja competitiva.

O SW-CMM define 5 nveis incrementais de maturidade a ser buscada, dos quais o
primeiro nvel apenas um ponto de referncia (como no CMMI em estgios). O Nvel
2 a primeira referncia a ser buscada, focado exatamente no estabelecimento de uma
gerncia de projetos. Os processos bsicos de gesto de projeto so estabelecidos para
acompanhar custo, cronograma e funcionalidade. O Nvel 2 caracterizado pela
existncia de um processo de gerenciamento de software onde os controle sobre os
procedimentos, compromissos e atividades so bem fundamentados.

A eficincia comprovada do SW-CMM, com suas caractersticas de melhoria contnua e
em nveis, confirma a eficincia de um processo gradual de melhorias. Como um nvel
de maturidade construdo sobre outro e a tentativa de saltar um nvel improdutiva,
pode-se afirmar que as reas de processo do Nvel 2, as primeiras a serem enfocadas,
so a base para as reas dos nveis seguintes.

Na rota do SW-CMM, o caminho para a melhoria dos processos comea pela
capacitao em cumprir compromissos. A organizao deve aprender a cumprir o que
promete a seus clientes em termos de requisitos, de custos, de prazos e de qualidade.
Isso no significa eliminar as incertezas inerentes a qualquer planejamento, mas sim que
os erros de previso devero se tornar pequenos e aleatrios. O comprometimento o

83
tema central do Nvel 2 do SW-CMM, suas reas de processo tm como foco o
cumprimento dos compromissos (Pdua, 2003).

As principais metas de melhoria de processo no Nvel 2 de maturidade do SW-CMM
podem ser resumidas em:
- Definir e gerenciar requisitos do projeto, incluindo as mudanas destes
requisitos.
- Comprometer-se apenas com o trabalho estimado e planejado.
- Acompanhar a execuo do trabalho em relao ao planejado.
- Garantir que o trabalho satisfaa os padres de qualidade estabelecidos.
- Manter um controle rigoroso dos produtos, incluindo as mudanas destes
produtos.
- Garantir que todos os fornecedores sigam estes padres.
- Monitorar o andamento de todos os itens anteriores.

Diante da importncia do Nvel 2 no processo de melhoria baseado no CMM e o escopo
da organizao aqui enfocada, este trabalho prope que a escolha das reas a serem
avaliadas seja feita entre as que compem o Nvel 2 do SW-CMM.

O CMMI em estgios possui a mesma estrutura do SW-CMM. O nome dos nveis de
maturidade foi modificado para dar maior preciso. Muitas reas de processo tiveram
pequenas modificaes de nome e contedo. A rea de processo Medies e Anlises
passou a ser uma rea do Nvel 2 (antes compreendia um grupo de atividades
responsvel pela institucionalizao das outras reas de processo).

Apesar de o Nvel 2 de maturidade ter nomes distintos nos modelos (Nvel Repetitivo
no SW-CMM e Nvel Gerenciado no CMMI em estgios), possuem o mesmo enfoque.
A tabela 5.1 mostra a correspondncia entre as reas de processo do Nvel 2 do SW-
CMM e CMMI em estgio.



84
TABELA 5.1 reas de Processo do Nvel 2.
SW-CMM Nvel Repetitivo CMMI em estgios Nvel Gerenciado
Gerenciamento de Requisitos Gerenciamento de Requisitos
Planejamento do Projeto Planejamento de Projeto
Viso Geral e Acompanhamento do Projeto Controle e Monitorao de Projeto
Gerenciamento de Subcontratos Gerenciamento de Contrato de Fornecedores
Garantia da Qualidade de Software Garantia de Qualidade de Produto e Processo
Gerenciamento de Configurao Gerenciamento da Configurao
Medies e Anlises
FONTE: (Paulk, 1993) e (CMMI, 2002b).

Assim, mantendo a base deste trabalho no modelo CMMI, recomenda-se que as
primeiras reas a serem enfocadas sejam:
- Gerenciamento de Requisitos.
- Planejamento de Projeto.
- Controle e Monitorao de Projeto.
- Gerenciamento de Contrato de Fornecedores.
- Garantia de Qualidade de Produto e Processo.
- Gerenciamento da Configurao.
- Medies e Anlises.

A grande maioria das organizaes que desenvolvem software encontram-se no Nvel 1
de maturidade. O caminho para o Nvel 2 talvez o mais difcil de ser percorrido, pois
trata-se de tirar a organizao da inrcia da imaturidade. Considerando os nveis de
maturidade do SW-CMM (de 1 a 5), seria razovel esperar que uma organizao-padro
de software estivesse nivelada em 3. Mas este no o caso. Mesmo depois de vrios
anos de experincia da indstria de software com o modelo CMM, os nveis 4 e 5 foram
conquistados por poucas organizaes. Apesar da popularidade do SW-CMM, somente
uma pequena parcela do universo de organizaes de software se submeteu a uma
avaliao formal. Nos relatrios publicados pelo SEI, com o resumo das avaliaes
mostrando evoluo na maturidade, a mdia ainda nvel 2. Assumindo-se que

85
organizaes que no se preocupam com melhoria de processo de software apresentam
baixa maturidade, ter atingido o nvel 2 representa uma realizao extraordinria.

As reas de processo do Nvel 2 so as reas que as organizaes que buscam melhorar
seu processo de desenvolvimento devem enfocar em um primeiro momento. Porm,
mesmo dentro destas reas pode-se destacar algumas de maior prioridade. Priorizar
algumas reas no significa que elas sejam mais importantes que outras, pois na maioria
das vezes, o sucesso de uma rea depende da eficincia de outra. Indicar algumas reas
mais relevantes pode ser til para organizaes que no querem ou no podem enfocar
todas as reas em uma primeira avaliao.

Se os recursos (financeiros e pessoal) que a organizao tm disponveis a um programa
de melhoria so limitados, interessante que as melhorias sejam introduzidas de forma
mais lenta e objetiva. Melhorias bem direcionadas e incorporadas organizao
gradualmente, evita desperdcios de recursos e pode ser uma garantia de que estas
melhorias sejam duradouras e eficientes. Alm disso, mudanas graduais so menos
traumticas. Mudanas radicais podem provocar averso e desestimular os profissionais
envolvidos.

Rosa (1997), recomenda s pequenas organizaes ateno maior para as reas:
Planejamento de Projetos, Gerenciamento de Configurao, Gerenciamento de
Requisitos e Garantia da Qualidade de Software.

Segundo Pdua (2003), requisitos, custo e prazo formam os vrtices do tringulo crtico
da engenharia de software, que deve ser sustentado pelas disciplinas: gerenciamento de
requisitos, planejamento e controle do projeto, garantia da qualidade, gerenciamento da
configurao e gerenciamento de contratos (em caso de terceirizao).

Os requisitos so as caractersticas que definem os critrios de aceitao de um produto.
Um dos grandes problemas da engenharia de software o levantamento e a
documentao dos requisitos do produto. Quando este levantamento e a documentao

86
so bem-feitos, os requisitos tm maior chances de serem atendidos. Porm, os
requisitos so bastante instveis. Esta instabilidade tem um custo muito alto, geralmente
significa perder trabalho j feito, desfazer algumas coisas e remendar outras. O
Gerenciamento dos Requisitos a disciplina da engenharia de software que procura
manter sob controle o conjunto dos requisitos de um produto, mesmo diante de algumas
alteraes inevitveis (Pdua, 2003).

Porm, para um produto ser vivel, no basta que atenda aos requisitos desejados, tem
que ser produzido dentro de parmetros de custo e prazo. Se isto no for possvel, o
produto pode no ser vivel do ponto de vista de mercado, ou pode ser prefervel
adquirir outro produto, ainda que sacrificando alguns dos requisitos. Para cumprir
compromissos de prazos e custos, esses compromissos devem ser assumidos com base
em requisitos bem-levantados, analisados e documentados. Os planos dos projetos
devem ser feitos com boas tcnicas de estimativas e anlise de tamanho, esforos,
prazos e riscos. Essas tcnicas pertencem disciplina de Planejamento de Projetos
(Pdua, 2003).

Todo plano comporta incertezas. A produtividade dos profissionais de software pode ser
feita com base em projetos anteriores da organizao, mas afetada por muitas
variaes, que dependem de pessoas, processos e tecnologia. Riscos previstos e
imprevistos podem ser materializados. Ao longo do projeto, os gerentes normalmente
enfrentam problemas e devem controlar variveis que afetam o cumprimento de seus
compromissos. Algumas vezes, os problemas podem ser resolvidos por meio de
contratao e remanejamento de pessoal ou de melhoria no uso de ferramentas. Outras
vezes, necessrio renegociar requisitos, prazos e custos. Para renegociar necessrio
re-planejar, atualizando as estimativas para levar em conta os outros dados. A disciplina
complementar ao planejamento que auxilia neste momento o Controle de Projetos
(Pdua, 2003).

Um erro conceitual comum imaginar que possvel trocar prazo, e talvez custo, por
qualidade. possvel, em alguns casos, reduzir custos e prazos atravs da reduo dos

87
requisitos do produto. A qualidade conseqncia do processo, das pessoas e da
tecnologia. A relao entre a qualidade e esses fatores, complexa. Por isso, mais
difcil controlar o grau de qualidade de um produto do que controlar seus requisitos. Em
todas as fases do desenvolvimento as pessoas acabam introduzindo alguns defeitos. Em
todo bom processo existem atividades de Garantia da Qualidade, tais como: revises,
testes e auditorias. Estas atividades removem parte dos defeitos introduzidos. O tempo
gasto no desenvolvimento geralmente reduzido com o aumento da qualidade do
processo (Pdua, 2003).

Um produto de software composto por muitos artefatos (cdigo executvel, cdigo
fonte, modelos, relatrios, e outros). A maioria dos artefatos evolui ao longo do projeto,
e at ao longo de toda a vida de um produto. Mesmo terminado um projeto, importante
que seus resultados sejam documentados e guardados, para eventuais manutenes.
Organizar e controlar a proliferao dos artefatos o objetivo da disciplina
Gerenciamento da Configurao. Sem esta disciplina impossvel atingir sequer nveis
razoveis de qualidade (Pdua, 2003).

Algumas organizaes terceirizam o desenvolvimento de software. O esforo de uma
organizao em melhorar a qualidade de seus sistemas informatizados pode ser perdido
por causa de falhas nos contratados. Para que isso no ocorra, a organizao contratante
deve estar capacitada no Gerenciamento de Contratos (Pdua, 2003).

Diante destas consideraes, o presente trabalho prioriza algumas reas e recomenda
que a escolha das reas de processo a serem avaliadas em uma avaliao inicial,
considere as seguintes reas de processo do Nvel 2 do CMMI em estgio (CMMI,
2002a):
- Gerenciamento de Requisitos.
- Planejamento de Projeto.
- Controle e Monitorao de Projeto.
- Garantia de Qualidade de Produto e Processo.
- Gerenciamento da Configurao.

88

As demais reas de processo do Nvel 2 do CMMI em estgios: Medies e Anlises e
Gerenciamento de Contrato de Fornecedores devem ser enfocadas em um segundo
momento, sendo a ltima em caso de terceirizao.

O nmero de reas a serem avaliadas, depende da necessidade e recursos da
organizao. O importante que todas elas sejam enfocadas em um processo de
melhoria contnua. No entanto, a dependncia existente entre estas cinco reas, faz com
que a real eficincia de uma, s atingida com a implementao das outras.

importante deixar claro que o CMMI em estgios s est sendo usado na escolha das
reas a serem enfocadas em um primeiro momento, devido a sua estrutura em estgio
ser semelhante ao SW-CMM e ao sucesso deste modelo. O contedo e a estratgia de
implementao das reas escolhidas devem ser observados com base no CMMI
contnuo (CMMI, 2002b).

5.8 Importncia do Gerenciamento de Projetos

Uma das grandes contribuies do CMM foi consolidar a importncia da gerencia de
projetos para a engenharia de software. O foco das reas Gerenciamento de Requisitos,
Planejamento de Projeto, Controle e Monitorao de Projeto, Garantia de Qualidade de
Produto e Processo, Gerenciamento da Configurao o estabelecimento de
procedimentos bsicos de Gerenciamento de Projetos (estas reas esto descritas em
maiores detalhes no Anexo 2). A falta de planejamento a primeira coisa a ser atacada,
sem a qual qualquer esforo de melhoria baldado. Uma equipe que desenvolve seu
trabalho aleatoriamente no pode se beneficiar de tcnicas de inspeo, metodologias de
desenvolvimentos ou mtricas.

Segundo Koontz e ODonnell (Koontz, 1986), gerenciar consiste em executar atividades
e tarefas que tm como propsito planejar e controlar atividades de outras pessoas para
atingir objetivos que no podem ser alcanados caso as pessoas atuem por conta prpria.

89
A importncia deste conceito facilmente percebida em um ambiente de projeto de
software onde, com freqncia, existem pessoas sem tarefas definidas e onde muitas
atividades importantes deixam de ser realizadas (Rocha, 2001).

Alguns estudos e pesquisas que foram realizados nos anos 90 (Roullier, 2001)
demonstraram que o gerenciamento de projeto a causa mais evidente das falhas na
execuo e entrega de produtos e servios de software.

J em 1989, Humphrey (1989) constatou que a ausncia de prticas administrativas no
desenvolvimento de software a principal causa de srios problemas enfrentados pelas
organizaes, como: atrasos em cronogramas, custo maior do que o esperado e presena
de defeitos, ocasionando uma srie de inconvenincias para os clientes e enorme perda
de tempo e de recursos.

Na atual cultura das organizaes de software, o planejamento, quando ocorre, feito de
forma superficial (Weber, 2001). Muitos projetos de software so realizados sem um
planejamento de como a idia modelada pelo levantamento de requisitos e necessidades
dos clientes pode ser transformada em produto. Muitas organizaes tm dificuldade na
elaborao de cronograma a ser cumprido e tambm na estimativa de custos (Rosa,
1997).

Os gerentes de projeto esto desacostumados a estimar. Quando estimam, costumam
basear-se em estimativas passadas, mesmo sabendo que elas podem estar incorretas (no
sabem tambm precisar o quanto elas esto incorretas). H gerentes que se recusam a
estimar somente por julgarem perda de tempo e correrem o risco de obter resultados
incorretos. Boas estimativas de custo, esforo e prazo de software requerem um
processo ordenado que defina a utilizao de mtricas de software, mtodo e ferramenta
de estimativa. As organizaes de software, de forma geral, no detm conhecimentos e
recursos para isso (Roullier, 2001).


90
Segundo Humphrey (1989), com poucas excees, estimativas iniciais de recursos e
cronogramas so inaceitveis. Isto no ocorre por falta de competncia dos
programadores, mas porque os clientes geralmente desconhecem que construir software
leva tempo.

Assim, as negociaes de planejamento so testes crticos ao time gerencial. Este time
deve tratar o plano inicial como ponto de partida e, quando prazos e custos tiverem que
ser reduzidos, o escopo do trabalho deve ser igualmente cortado.

Observa-se que na prtica, em ambientes de desenvolvimentos caticos, qualquer
esforo de melhoria, por mais simples que sejam, causam melhorias na produtividade. O
simples esforo por melhorar a documentao do projeto e as verificaes de qualidade
desde o incio, reduzem significativamente o tempo gasto em testes e re-trabalho.

As pequenas organizaes tambm possuem dificuldades de parte gerencial. Na maioria
das vezes, o conhecimento tcnico das pessoas que trabalham em pequenas empresas
no envolve assuntos relacionados formao de empreendedores (Rosa, 1997). Outros
fatores ainda agravam os problemas de gerenciamento de projetos de software em
organizaes de pequeno porte, tais como: inexistncia de um processo definido,
recursos pessoais e financeiros limitados, falta e/ou pouca cultura em processos, pouco
treinamento em engenharia de software, imaturidade metodolgica, crescimento
ocorrido por demanda, falta de experincia administrativa por parte dos gerentes e
diretores e falta de definio das metas organizacionais (Roullier, 2001).

As dificuldades de se implantar um processo para gerenciamento de projetos de
software em organizaes de pequeno porte est principalmente na falta de cultura em
qualidade que as mesmas possuem. O alto rodzio de pessoal e o constante
deslocamento de recursos humanos para suprir a demanda de um outro projeto, tambm
dificulta o bom desempenho de um processo de gerenciamento de projetos de software
(Roullier, 2001).


91
Rosa (1997), em uma pesquisa emprica feita em pequenas organizaes de software no
interior de So Paulo, verificou que a falta de formalismo caracterstica clara de
organizaes de pequeno porte, onde as tarefas de um modo geral so feitas sem
procedimentos explcitos. As pequenas organizaes no possuem um processo de
software que possa ser considerado tpico, pois quando realizam atividades de
engenharia de software, as fazem informalmente. Atividades como documentao e
controle de mudanas, quando realizadas, no so utilizados mtodos e procedimentos
especficos. Muitos profissionais consideram estas atividades muito burocrticas e no
lhes do a devida importncia (Rosa, 1997).

A carncia de prticas de gerenciamento distancia estas organizaes dos conceitos
bsicos de qualidade em software. A formalizao do gerenciamento de projeto a base
sobre a qual se constri um processo de software eficiente. Um projeto gerenciado
reflete no custo, planejamento e qualidade do produto desenvolvido. Este trabalho busca
diminuir a barreira da informalidade que separa as pequenas organizaes do caminho
da excelncia em qualidade de software.

Tendo em vista a carncia de gerenciamento nas pequenas organizaes, o presente
trabalho prioriza algumas prticas indispensveis introduo de formalismo na
gerencia de projetos. Tais prticas e suas referidas reas de processo esto apresentadas
no Anexo 2.






92
































93
CAPTULO 6
LEVANTAMENTO DA QUALIDADE DO PROCESSO DE SOFTWARE

6.1 Avaliaes CMMI

A implementao do CMMI consiste em um ciclo composto pelo levantamento do
estado atual do processo da organizao (avaliao propriamente dita), comparao com
o prximo nvel de maturidade/capacidade, elaborao de um plano para reduzir a
distncia entre o estado atual e o almejado, e a execuo das aes planejadas.









FIGURA 6.1 Avaliao CMMI.

De modo geral os princpios bsicos de avaliaes CMMI so os mesmos princpios
histricos de avaliaes SW-CMM, que so (ARC, 2001):
- Iniciar com um modelo de referncia (neste caso o CMMI-SW).
- Usar um processo de avaliao formalizado.
- Envolver a alta administrao como os responsveis pela avaliao (sponsor).
- Enderear a avaliao aos objetivos de negcio do sponsor.
- Observar rigorosa confidncia e no atribuio dos dados.
- Focalizar em aes de melhoria de processo.

Execuo de aes
corretivas
Comparao com
o prximo nvel
Elaborao do
Plano de Melhoria
Avaliao

94
Todos os requisitos para execuo de avaliaes CMMI esto descritos no ARC (2001).
Contudo, as avaliaes do CMMI no precisam cumprir rigorosamente todos os
critrios definidos pelo ARC. A avaliao deve ter como foco principal os objetivos do
sponsor (por exemplo, a alta administrao ou um gerente de departamento). O ARC
define 3 classes de avaliao: classe A, classe B e classe C. As classes se diferenciam
basicamente no grau de rigorosidade da investigao e classificao dos processos,
pessoal e recursos envolvidos, custo e durao. A avaliao Classe A a mais rigorosa e
deve satisfazer todos os requisitos do ARC.

O Mtodo de Avaliao CMMI Padro para Melhoria de Processo, ou SCAMPII -
Standard CMMI Assessment Method for Process Improvement, um mtodo de
avaliao Classe A (SCAMPI, 2001). Este mtodo utilizado em avaliaes formais
(internas e externas) do CMMI, sendo tambm compatvel com a ISO 15504.

Uma avaliao CMMI se resume nas seguintes atividades (SCAMPI, 2001):
- Plano e preparo da avaliao.
o Analisar os requisitos da avaliao.
o Desenvolver um plano de avaliao.
o Selecionar e preparar o grupo avaliador.
o Definir os objetivos a serem alcanados e analisar as informaes
necessrias para atingir os objetivos.
o Preparar a coleta destas informaes.
- Execuo da avaliao.
o Coletar as informaes.
o Examinar as informaes.
o Verificar a validade das informaes.
o Documentar as informaes.
o Gerar resultados da avaliao
- Relatrio de resultados.
o Entregar os resultados da avaliao aos interessados.
o Arquivar os documentos da avaliao.

95

Quando uma organizao no busca a certificao formal no CMMI, ela pode criar seu
mtodo de avaliao prprio, baseado neste modelo, observando suas verdadeiras
necessidades. Este trabalho apresenta aqui as diretrizes para a elaborao de um mtodo
de avaliao menos rigoroso, tendo em vista as caractersticas da organizao e as
escolhas referentes ao modelo CMMI, apresentadas no captulo anterior.

6.2 Avaliaes Alternativas

A avaliao do SEI bastante rigorosa e, certamente, traumtica. Por isso, dificilmente
deve ser utilizada como pontap inicial na implantao do CMM. O primeiro ciclo de
anlise/planejamento/ao tem caractersticas especiais. Um mtodo menos abrangente
e ao mesmo tempo flexvel pode reduzir os traumas e liberar a criatividade (Pires,
1998). A avaliao inicial deve ser o menos traumtica possvel, para que as pessoas
no criem averso ao modelo j neste momento. Embora, para fins de certificao,
exista apenas uma forma de avaliao vlida, definida pelo SEI (denominada, neste
trabalho, de avaliao formal), existem outras tcnicas que podem minimizar as
dificuldades e encurtar o caminho at o prximo nvel.

Uma avaliao formal do CMM bastante abrangente, cara e consome tempo. Assim,
muitas organizaes encontram dificuldades em executa-las com freqncia. Para
amenizar as dificuldades e acompanhar cada passo do programa de melhoria, muitas
organizaes vem criando tcnicas de avaliao em pequena escala que so aplicadas
entre avaliaes completas. Estas mini-avaliaes (mini-assessment) normalmente
focalizam poucas reas de processo, servindo para estimular o processo de melhoria e
verificar se uma organizao est preparada para uma avaliao em escala completa
(Wiegers, 2000). As grandes organizaes que objetivam alcanar nveis de maturidade
mais elevados, freqentemente fazem uso destas mini-avaliaes (Carter, 2002)
(Dunaway, 1999). Normalmente, a maioria das avaliaes formais precedida de mini-
avaliaes. Organizaes como Motorola, Xerox e Kodak, tm aplicado esta estratgia
com bastante sucesso, alcanando altos nveis de maturidade (Wiegers, 2000).

96
Avaliaes em pequena escala mostra-se como uma alternativa tambm para
organizaes que buscam melhorar seu processo de desenvolvimento sem a necessidade
de uma certificao formal. Tcnicas de mini-avaliaes podem ser eficientes e de custo
acessvel (Carter, 2002).

As avaliaes classe C, por terem um conjunto menor de requisitos, mostram-se como
uma alternativa bastante interessante para uma avaliao inicial e em pequena escala.
Estas avaliaes so uma opo para organizaes menores que no possuem recursos
para uma avaliao completa. Portanto, avaliaes classe C so as que mais se
enquadram no contexto deste trabalho. Ressaltando que a classe da avaliao tem
relao com a rigorosidade da mesma e no com o tamanho da organizao.

O SEI oferece todo o apoio terico para avaliaes classe A, atravs do ARC e do
SCAMPI, pois seu objetivo primordial a certificao formal das organizaes de
software. Um mtodo para avaliaes menos rigorosas pode ser definido pela
adaptao do SCAMPI a um contexto menor, baseando nos requisitos classe C do ARC.
Um mtodo de avaliao mais rigoroso, como o SCAMPI (2001) pode ser utilizado
como guia para elaborao de uma avaliao em pequena escala. Obviamente a grupo
avaliador deve extrair deste mtodo apenas o que julgar importante para a melhor
obteno de resultados.

Na implementao informal do CMMI, isto , sem a necessidade de certificao, a
avaliao pode ser executada ou por profissionais da prpria organizao, ou atravs do
apoio de consultorias especializadas, ou ainda por ambos.

Quando a iniciativa de avaliao vem dos prprios profissionais da organizao, o SEI
recomenda que eles tenham experincia em avaliaes de processo e conhecimento no
CMM. Porm, importante considerar a hiptese da ausncia destas experincias. Esta
no a situao mais indicada pelo SEI para a execuo de avaliaes, mas isso no
exclui totalmente a possibilidade de que a avaliao ocorra. Neste caso, fundamental
que estes profissionais tenham no mnimo larga experincia em desenvolvimento de

97
software. Assim, antes de qualquer iniciativa imprescindvel que os profissionais
delegados execuo da avaliao, se instruam sobre o modelo. No Brasil, h
consultorias que disponibilizam cursos de CMM. Alm disso, uma importante fonte de
informao o prprio SEI, que disponibiliza aos interessados a documentao do
CMM (e seus derivados) via Internet, sem qualquer custo. O sucesso neste caso vai
depender da dedicao e desenvoltura destes profissionais.

Tendo em vista a disponibilidade destas fontes de informao, o menor problema destes
profissionais ainda ser conhecer o modelo e suas especificaes. O maior problema
ser adaptar as informaes adquiridas em um contexto reduzido e em uma avaliao
inicial, considerando ainda as caractersticas da organizao a ser avaliada.

6.3 Preparao da Avaliao

Na preparao da mini-avaliao aqui proposta necessrio considerar: o escopo da
avaliao (avaliao inicial em pequena escala) e o escopo da organizao (pequenas
organizaes que buscam sair da imaturidade do processo), adicionando ainda a
escassez de recursos para a avaliao e a falta de experincia em CMM de seus
profissionais.

Pode at parecer contraditrio, mas apesar da informalidade da avaliao tratada neste
trabalho, busca-se com ela justamente a formalizao dos processos da organizao e a
melhoria dos mesmos. Assim, importante que a avaliao tenha uma fundamentao
terica, obedecendo as regras de seu modelo de referncia, no caso o CMMI. Como as
regras de avaliao deste modelo so descritas no ARC, necessrio conhecer e cumprir
com o mnimo de requisitos do mesmo. Desta forma, possvel ter: mais controle sobre
a avaliao, o conhecimento do caminho correto para conduzi-la, maior garantia de
sucesso na obteno dos resultados, alm de preparar a organizao para uma futura e
eventual avaliao mais rigorosa.


98
O primeiro passo para executar uma avaliao do CMMI estabelecer o escopo da
avaliao, atravs do levantamento as caractersticas da organizao, escolha das reas
de processo a serem investigadas e o nvel a ser avaliado. Estas informaes foram
tratadas no captulo anterior.

O passo seguinte a seleo do mtodo de avaliao, dos membros do grupo avaliador e
de outros participantes da avaliao (pessoas que sero submetidas a questionrios e/ou
entrevistas, responsveis pelas entradas da avaliao), o estabelecimento das sadas
(evidenciar o que se espera classificar) e restries da avaliao, com base nas
informaes obtidas no passo anterior.

6.4 Mtodo para Mini-avaliao

Na execuo de mini-avaliaes, quando a organizao tem o apoio de consultores
especializados, estes normalmente tm seus prprios mtodos de avaliao. Alguns
auditores credenciados pelo SEI desenvolveram seu prprio mtodo da avaliao em
pequena escala. Obviamente que, para ter acesso a estes mtodos necessrio contratar
os servios das consultorias que os desenvolveram.

Grandes organizaes tambm criaram seu prprio mtodo de avaliao, que so
executados entre avaliaes formais. Um exemplo destes mtodos o Mtodod de
Mini-avaliao Modular, ou MMA Modular Mini-assessment Method (Wiegers,
2000), desenvolvido pela Kodak e tambm utilizado por outras organizaes. O MMA
composto das fases: planejamento reunio de abertura orientao CMM
administrao do questionrio anlise das respostas do questionrio discusso com
os participantes gerao de resultados apresentao dos resultados. O grupo
avaliador do MMA representado por apenas 2 avaliadores. O MMA baseado no
CMM, mas no cumpre com todos os requisitos da CAF.

O planejamento feito pelos avaliadores, estes se renem com os lderes dos projetos
para colher informaes sobre seus projetos e identificao dos participantes da

99
avaliao (as pessoas-chave dos projetos). Depois os avaliadores documentam o plano,
identificando os objetivos da avaliao, as reas de processo a serem investigadas, os
projetos a serem avaliados, os participantes e o cronograma das atividades da avaliao.

A reunio de abertura a primeira oportunidade para que as equipes dos projetos se
informem sobre a mini-avaliao e estratgias para implementao de melhorias. Alm
disso, esta reunio pode servir tambm para aplicao dos questionrios, ou ento pode
ser feita outra reunio para esse fim.

A fase de orientao sobre CMM varia de acordo com a realidade da organizao. Esta
fase pode compreender desde uma pauta na reunio de abertura at um curso de 4 horas
sobre as caractersticas do modelo.

O principal instrumento de coleta de dados um questionrio de maturidade. Os dados
colhidos devem ser mantidos em carter confidencial. A escolha das pessoas que
respondero o questionrio deve ser feita pelos avaliadores com o auxlio dos lderes
dos projetos (normalmente isso feito na fase de planejamento). Na administrao dos
questionrios, devem ser dados esclarecimentos sobre as reas de processo avaliadas.
Alm das respostar, interessante que os participantes sejam encorajados a fazer
comentrios.

Se a fase para discusso com os participantes est planejada, os comentrios feitos pelos
participantes sero discutidos nesta fase. Se esta fase no necessria, os avaliadores
utilizam estes comentrios em suas concluses. recomendvel que esta fase exista,
pois servir como fonte para consolidao dos dados dos questionrios.

A gerao dos resultados pode ser feita pelos avaliadores ou em reunio com a equipe
de cada projeto avaliado. O avaliador tira suas concluses depois da discusso (ou do
questionrio, quando no houver a discusso), utilizando todos os dados coletados
durante a avaliao.


100
O ltimo passo a apresentao dos resultados. Se os avaliadores tiraram suas
concluses sem a participao das equipes de projeto, os resultados devem ser
apresentados a elas e aos gerentes. Se as equipes participaram na gerao de concluses,
os resultados devem ser apresentados aos gerentes. Alm dos resultados da avaliao,
nesta apresentao devem ser apontados os prximos passos para a implementao de
melhorias.

importante a criao de um banco de dados com as informaes da avaliao como:
data, durao, nmero de participantes, o questionrio usado, as reas de processo
avaliadas, os resultados dos questionrios, as reas que so selecionadas para
desenvolvimento do plano de melhoria e o tempo gasto em cada fase da mini-avaliao.
Estes dados sero teis para uma prxima avaliao.

O custo de uma avaliao deste tipo de 5% a 10% do que seria gasto em uma
avaliao formal. Os participantes gastam uma mdia de 4 horas e os avaliadores 48
horas nas atividades da avaliao. O tempo de esforo dos avaliadores diminui medida
que aumentam suas experincias (Wiegers, 2000).

A simplicidade e objetividade deste mtodo vo ao encontro proposta este trabalho.
Assim, MMA, pode ser utilizado como um roteiro para a que organizao prepare seu
prprio mtodo de avaliao. Porm, o conhecimento sobre os requisitos de avaliaes
CMMI tambm de grande importncia na elaborao do mtodo de avaliao.

6.5 Requisitos de Avaliaes Classe C

Os requisitos para mtodos de avaliao classe C so relacionados com as
responsabilidades dos profissionais envolvidos com a avaliao, a documentao do
mtodo, o planejamento e a preparao da avaliao, coleta, consolidao e validao
dos dados e o relatrio dos resultados.


101
Os requisitos de avaliao do ARC concentram todas as regras para se ter uma avaliao
bem sucedida. A eficincia dos requisitos de avaliaes CMM, visveis desde a CAF
(Masters, 1995), comprovada pela indiscutvel satisfao dos que j se submeteram a
uma avaliao deste modelo. O ARC possui as mais efetivas prticas percebidas ao
longo dos anos de utilizao da CAF, adicionadas a uma flexibilidade que permite a
satisfao dos mais diversos tipos de organizaes.

Os requisitos classe C do ARC so os que mais se conformam proposta deste trabalho.
Os requisitos mnimos de avaliaes classe C so descritos no ARC da seguinte forma
(ARC, 2001):

- Responsabilidades:
1- O mtodo de avaliao deve definir as responsabilidades do sponsor, que no
mnimo deve incluir:
- Verificar se os membros do grupo avaliador tm experincia, conhecimento
e habilidade para assumir responsabilidades e liderar a avaliao.
- Garantir que as unidades organizacionais apropriadas (por exemplo, projetos,
unidade funcional) participem da avaliao.
- Garantir que o mtodo apie a no atribuio dos dados aos participantes.
- Garantir que os recursos necessrios sejam disponveis para a avaliao.
- Revisar e aprovar os objetivos da avaliao para que o grupo avaliador possa
iniciar a coleta de dados.
2- O mtodo deve definir as responsabilidades do lder do grupo avaliador que no
mnimo deve incluir:
- Garantir que a avaliao seja conduzida de acordo com processo
documentado do mtodo.
- Confirmar o comprometimento do sponsor para prosseguir com a avaliao.
- Garantir que todos os participantes da avaliao estejam informados sobre o
propsito, escopo e enfoque da avaliao.
- Garantir que todos os membros do grupo avaliador tenham: experincia,
conhecimento e habilidade no modelo de referncia da avaliao e no

102
mtodo da avaliao; a competncia necessria para usar os instrumentos ou
ferramentas escolhidas para apoiar a avaliao, e garantir que tenham acesso
a documentos que descrevam como executar as tarefas definidas para a
avaliao.
- Verificar e documentar que os requisitos do mtodo de avaliao esto sendo
mantidos.

- Documentao do mtodo:
1) O mtodo deve ser documentado e no mnimo incluir (ou pelo menos o item
a e d):
- Identificao dos modelos CMMI (verso, disciplina, abordagem) para os
quais o mtodo pode ser usado.
- Identificao da verso ARC em que o mtodo baseado.
- Identificao dos requisitos de avaliao CMMI satisfeitos pelo mtodo,
determinando em que classe de avaliao CMMI (A, B, ou C) o mtodo est
relacionado.
- Descrio das atividades e dos recursos para implementao de cada
requisitos da avaliao.
2) A documentao do mtodo deve fornecer informaes que permitam:
- Identificao dos propsitos, objetivos e restries da avaliao.
- Determinao da adaptabilidade do mtodo de avaliao em relao aos
propsitos, objetivos e restries (identificados no item anterior).
3) A documentao do mtodo deve identificar o escopo do modelo(s) CMMI(s) a
ser usado pela avaliao:
- reas de processo ser investigadas (na abordagem em estgios ou contnua).
- O nvel da capacidade a ser investigado para cada rea de processo (na
representao contnua).
4) A documentao do mtodo deve permitir a identificao da organizao (ou
unidade organizacional) a ser avaliada:
- O sponsor (patrocinador) da avaliao e seu relacionamento com a
organizao a ser avaliada (cargo).

103
- Os projetos da organizao que sero avaliados.
- Os elementos funcionais da organizao que devero participar (gerentes,
engenheiros, programadores).
- Os nomes e funo (na organizao) dos participantes da avaliao.
5) A documentao do mtodo deve permitir a seleo dos membros do grupo
avaliador e os critrios para qualificao, incluindo:
- Experincia tcnica na disciplina especfica.
- Experincia em gerenciamento.
- Experincia, conhecimento e habilidades no modelo de referncia da
avaliao e no mtodo de avaliao.
6) A documentao do mtodo deve fornecer critrio de qualificao do lder do
grupo avaliador:
- Treinamento e experincia usando o modelo de referncia da avaliao.
- Treinamento e experincia usando o mtodo de avaliao.
- Experincia em ministrar treinamentos, em gerenciamento de grupos,
liderana, versatilidade em discusses e apresentaes.
7) A documentao do mtodo deve determinar o tamanho apropriado do grupo
avaliador.
8) A documentao deve oferecer informaes:
- Sobre as regras e responsabilidades do grupo avaliador.
- Para endereamento das responsabilidades do sponsor.
- Para endereamento das responsabilidades do lder do grupo.
- Para estimar os recursos requeridos na conduo da avaliao (incluindo o
tempo para a avaliao).
- Sobre a logstica da avaliao.
- Para coleta dos dados relevantes da organizao e para associao dos dados
s prticas genricas e especficas do modelo de referncia da avaliao.
- Para tomadas de decises, incluindo os pontos fracos e fortes do processo da
organizao em relao ao modelo de referncia da avaliao.
- Para manter os dados em carter confidencial e garantir a no atribuio dos
dados aos participantes da avaliao.

104
9) A documentao deve fornecer orientao para (1) registrar o relacionamento
entre os dados coletados durante a avaliao e as concluses e/ou classificaes,
(2) reservar e proteger os registros da avaliao, e (3) reunir e manter um
registro que apie as concluses e/ou classificaes do grupo avaliador e que
contenha no mnimo:
- Datas da avaliao.
- Entradas da avaliao.
- Identificao do mtodo usado na avaliao (verso) e com algumas
eventuais opes de execuo deste mtodo.
- Concluses.

- Planejamento e preparao da avaliao:
1) O mtodo deve fornecer aos participantes da avaliao no mnimo:
- O propsito da avaliao.
- O escopo da avaliao.
- O enfoque da avaliao.
- As regras e responsabilidades dos participantes na avaliao.
- O cronograma das atividades da avaliao.
2) A documentao do mtodo deve fornecer as prioridades de entradas da
avaliao para incio da coleta dos dados pelo grupo avaliador.
3) No mnimo, as entradas da avaliao devem especificar:
- A identidade do sponsor da avaliao e seu relacionamento com a
organizao.
- Os propsitos da avaliao, incluindo o alinhamento com os objetivos de
negcios.
- O escopo do modelo de referncia, incluindo: (1) as reas de processo que
precisam ser investigadas e (2) o nvel de maturidade ou capacidade a ser
investigado em cada rea no escopo da avaliao.
- A organizao (ou unidade organizacional) que ser submetida a avaliao.
- O contexto do processo, que deve incluir no mnimo: (1) o tamanho da
organizao; (2) dados demogrficos (quantidade de funcionrios); (3)

105
domnio da aplicao dos produtos ou servios desenvolvidos na
organizao; (4) tamanho, a complexidade e caractersticas crticas dos
produtos ou servios; e (5) caractersticas de qualidade dos produtos ou
servios (como densidade de defeitos, confiabilidade).
- Restries da avaliao, que deve incluir no mnimo: (1) disponibilidade de
recursos; (2) o mximo de tempo a ser gasto na avaliao; (3) reas de
processo especficas ou entidades organizacionais a serem excludas da
avaliao; (4) o mnimo, o mximo ou o tamanho especfico da amostra que
se pretende avaliar; (5) restries quanto ao uso das sadas da avaliao, (6)
informaes sobre um acordo de confidencialidade; (7) no atribuio dos
dados da avaliao s fontes.
- Identificar o(s) modelo(s) CMMI utilizado, incluindo verso, disciplina e
abordagem (estgios ou contnua).
- Os critrios de conhecimento, experincia e habilidades dos membros do
grupo avaliador.
- Identificao dos membros do grupo avaliador, incluindo suas
responsabilidades especficas na avaliao.
- Identificao dos participantes (nome e funo) dos participantes e suas
responsabilidades na avaliao.
- Algumas informaes adicionais a serem coletadas durante a avaliao que
serviro de apoio no alcance aos objetivos da avaliao.
- Descrio das sadas planejadas incluindo classificaes a serem geradas
(rea de processo, nvel de maturidade).
- Prever a execuo de seguintes (como relatrio de resultados, planos de
ao, reavaliao).
- Planejar a implementao do mtodo e atividades associadas, incluindo o
tamanho da amostra e cobertura da organizao.
4) O mtodo deve determinar que as entradas da avaliao e possveis mudanas
nestas entradas devem ser aprovadas pelo sponsor (ou autoridade delegada) e
documentado no registro da avaliao.

106
5) O mtodo deve requerer o desenvolvimento de um plano que contenha no
mnimo:
- As entradas da avaliao.
- As atividades a serem executadas na conduo da avaliao.
- Recursos e programas destinados avaliao.
- Avaliao logstica.
- Passos para atenuar os riscos associados execuo da avaliao.

- Coleta dos dados da avaliao:
O grupo avaliador tira suas concluses baseadas nos dados coletados por uma ou mais
fontes. Em avaliaes classe C a coleta dos dados deve ser feita por pelo menos uma das
fontes abaixo.
1) O mtodo deve coletar dados pela administrao de instrumentos (como
questionrios, inspees).
2) O mtodo deve coletar dados pela conduo de entrevistas (com os lderes do
projeto, gerentes e envolvidos).
3) O mtodo deve coletar dados pela reviso de documentos (como polticas
organizacionais, procedimentos de projetos).

- Consolidao e Validao:
1) O mtodo deve oferecer um mecanismo para consolidar precisamente os dados
coletados durante uma avaliao, de acordo com os critrios:
- As observaes foram derivadas de evidencias vistas ou ouvidas durante a
sesso de coletas de dados.
- As observaes esto claramente escritas, expressas sem atribuies e na
terminologia usada na organizao.
- As observaes so relevantes para o modelo de referncia da avaliao e
pode ser associado com um componente especfico do modelo.




107
- Relatrio dos resultados:
1) O mtodo deve requerer documentao e relatrios das concluses e/ou
classificaes para o sponsor e para a organizao avaliada.
2) O mtodo deve requerer tambm que o relatrio da avaliao seja fornecido ao
sponsor para ser arquivado.

6.6 Interpretao dos Requisitos

A os requisitos classe C e o mtodo MMA (Modular Mini-assessment Method)
(Wiegers, 2000) podem ser utilizados como roteiros para a elaborao de um mtodo de
avaliao menos rigoroso e que atenda as necessidades da organizao. Porm, algumas
observaes quanto o ARC podem auxiliar na interpretao dos requisitos.

O primeiro passo na elaborao de uma avaliao a escolha do lder da avaliao
(sponsor), o grupo avaliador e o lder deste grupo (ARC, 2001). Neste momento o
interesse de buscar a melhoria do processo comea a sair do pessoal e atingir o coletivo.

muito importante o apoio da alta gerncia para o sucesso da avaliao. interessante
que o sponsor seja algum profissional deste nvel hierrquico. A obteno do patrocnio
do gerente snior fundamental para melhoria da capacidade organizacional (Paulk,
1999). possvel que em alguns momentos o andamento da avaliao no seja
satisfatrio, podendo ocorrer, entre outras coisas, um desvio quanto aos verdadeiros
objetivos da avaliao, ou pode faltar colaborao de alguns profissionais envolvidos.
Neste momento necessria a interveno do sponsor para estimular estes profissionais,
impor regras, cobrar a colaborao. Aes deste tipo no surtem mais efeitos quando
desempenhada por algum que tenha maiores poderes na organizao. O envolvimento
da alta gerncia importante tambm no patrocnio aos recursos necessrios avaliao
(tempo, pessoal, treinamentos, etc).

O sponsor tambm responsvel pela seleo dos membros do grupo avaliador e seu
lder (SCAMPI, 2001). Dependendo do tamanho e complexidade da organizao e da

108
urgncia em se obter resultados, o grupo avaliador pode ser composto por 3 a 10
pessoas.

Na literatura este grupo chamado de SEPG Software Engineering Process Group
(Pires, 1998). Este grupo pode ser composto por consultores especializados em CMM
ou certificados pelo SEI (Pires, 1998). Porm, se a organizao no possui recursos para
isso recomendvel que seja aproveitada a experincia de profissionais da prpria
organizao que j tenha tido algum contato com o CMM, com avaliaes de processo
ou tenha vivenciado um programa de melhoria, ou pelo menos tenha bastante
experincia em desenvolvimento de software. Neste ltimo caso, necessrio que estes
profissionais recebam treinamentos, verbas para adquirir fontes de informao e tempo
para estudo.

Uma alternativa para reduzir os investimentos em treinamento a possibilidade de uma
organizao se unir a outras para dividir os custos de treinamento. Um profissional faz
um curso e distribui o conhecimento para os demais profissionais envolvidos. O
importante que os componentes do grupo estejam familiarizados com os termos do
CMM antes de qualquer outra iniciativa. O grupo avaliador o corao do projeto,
aquilo que vai garantir que todo o processo de implantao do modelo flua da maneira
adequada. A experincia do grupo sempre maior que a maior das experincias
individuais de cada um de seus componentes.

importante considerar que a organizao no se faz apenas de processos e tecnologias,
as pessoas so um aspecto essencial para o sucesso de ambos. Como as pessoas so
responsveis pelo processo e o processo no fala por si s, o bom esclarecimento destas
pessoas crucial para a obteno de resultados consistentes com a realidade. Tambm
nesta fase necessrio fazer circular pela organizao informaes a respeito do CMM.
A eficincia do programa depender grandemente dos esforos despendidos nesta fase.
necessrio que seja divulgando principalmente que no se trata de uma reengenharia
(Pires, 1998) e que no h previso de demisses. Afinal, a informao evita boa dose

109
de resistncia. A divulgao das informaes pode ser feita atravs de jornais internos,
palestras, circulares e e-mails com pequenos resumos.

Depois de devidamente treinado, o trabalho do grupo avaliador comea pela seleo de
projetos tpicos do trabalho da organizao, em diferentes fases de desenvolvimento.
No necessrio avaliar todos os projetos, mas importante que os escolhidos sejam
representativos das prticas habituais e cultura da organizao. Os demais participantes
da avaliao sero selecionados mediante sua relao com estes projetos escolhidos.
Devem ser selecionadas as pessoas chave de cada projeto, ou seja, aquelas que detm o
conhecimento de como o desenvolvimento e a manuteno do software na
organizao. Esta escolha deve considerar a rea de processo do CMMI que est sendo
investigada. Estas pessoas so as responsveis pelos dados de entrada da avaliao.
necessrio que estas pessoas sejam conscientizadas da sua importncia para a avaliao
e tambm sobre os benefcios da melhoria de processo. medida que o processo de
avaliao executado, outras pessoas podem ser selecionadas posteriormente.

Uma organizao pode ter vrias maneiras de executar uma mesma tarefa, cada uma
dessas maneiras representa um processo diferente. Mais de uma metodologia pode estar
sendo utilizada ou at mesmo nenhuma. importante que o grupo avaliador tome
conhecimento de todos esses processos. O conhecimento dos processos existentes til
no momento de propor melhorias, aproveitando ao mximo as experincias bem
sucedidas dentro da prpria organizao.

O grupo avaliador dever elaborar e documentar o plano da avaliao, aprovar um
cronograma de trabalho e atualizar este cronograma. Este plano um instrumento de
apoio avaliao, importante que seja levado a srio, mas tambm pode ser alterado
para o melhor andamento da avaliao. O cronograma de atividades, por exemplo, deve
ser mudado sempre que isso se fizer necessrio ao processo de avaliao, sendo
importante que tudo isto seja documentado. Normalmente cronogramas com macro
atividades (Pires, 1998) funcionam melhor do que um excessivamente detalhado. A
aplicao de questionrio e/ou entrevistas com as pessoas-chave devem ser marcadas de

110
acordo com a necessidade e disponibilidade, mas as reunies do grupo avaliador devem
acontecer de maneira peridica e de acordo com o previsto no cronograma.

O grupo avaliador deve elaborar questionrios e determinar as estratgias de entrevistas
tendo em mente sempre a rea de processo do CMMI a ser explorada. Na elaborao do
questionrio, grupo avaliador deve mapear as prticas CMMI, da rea de processo a ser
avaliada, para a realidade da organizao. As pessoas-chave de cada projeto devem ser
esclarecidas sobre a metodologia de avaliao. O processo de avaliao comea com a
aplicao dos questionrios, anlise das respostas, iniciando um ciclo de entrevistas
voltadas para esclarecer falhas e contradies encontradas no preenchimento dos
questionrios. As entrevistas servem tambm para coletar preocupaes e sugestes
para o programa de melhoramento.

O ideal que sejam feitas reunies com as pessoas-chave para a entrega dos
questionrios, pois se surgir alguma dvida membros do grupo avaliador poder
esclarece-la. No contexto deste trabalho interessante que seja feita uma reunio para
cada rea de processo. Nesta reunio necessria que seja dada uma explanao da rea
de processo em questo, se possvel com a leitura das questes. No produtivo utilizar
muitos questionrios em uma mesma reunio. Quando um mesmo indivduo
desempenha papis diferentes em um mesmo projeto, ou participa de vrios projetos,
necessrio que o grupo avaliador se preocupe em no tornar cansativa a aplicao de
questionrios, podendo dividir as reunies por projetos tambm. Neste caso necessrio
que o participante seja instrudo sobre seus papeis no projeto que est sendo avaliado.

Nesta reunio, os membros do grupo avaliador devem anotar as maiores dvidas
encontradas pelos participantes, que poder auxiliar na consolidao das respostas.
necessrio, para se ter sucesso no levantamento, falar a mesma lngua da organizao,
estar coerente com sua realidade. Os participantes devero ter o prazo de alguns dias
para entregar suas respostas e anotaes por escrito.


111
Depois de entregues as respostas, o grupo avaliador dever comparar suas anotaes
com estas respostas para preparar as respostas consolidadas. Cada participante do grupo
avaliador deve receber uma cpia das respostas consolidadas e uma reunio de reviso
deve ser marcada.

Durante o processo as informaes especficas de cada projeto devem ser mantidas
confidenciais para estimular a fidelidade das respostas, j que no existe o objetivo de
avaliar os projetos individualmente.

Nesta reunio de reviso, devem ser levantados possveis pontos de ambigidade e
verificada a necessidade de maiores esclarecimentos (necessidade de entrevistas e/ou
reviso de documentao). Se isto for necessrio, estas atividades devem ser executadas
e novas reunies devem ser marcadas, at que se tenham os dados necessrios sobre os
projetos da organizao.

Depois disso, os resultados da avaliao devem ser mapeados e comparados com as
prticas CMMI. O objetivo no enquadrar a organizao em um nvel de capacidade,
mas importante estar sempre mantendo o vnculo com o modelo. O registro destes
dados pode ser til em uma prxima avaliao. Deve ento ser feito um relatrio final
da avaliao, identificando os pontos positivos e negativos, e apresentados os resultados
aos interessados. Assim finalizado o processo de avaliao.

Os resultados da avaliao so registrados no relatrio final, que deve conter os
seguintes assuntos:
- Transcurso da avaliao: pequeno histrico, os eventuais problemas encontrados
e recomendaes para as prximas avaliaes.
- rea de processo avaliada e prticas CMMI atendidas: define o estado atual da
organizao, de acordo com os critrios do SEI.
- Pontos fortes: capacidades existentes na organizao ou em projetos individuais,
que podem ser facilmente difundidas.

112
- Deficincias: prticas ruins e capacidades ausentes ou que devem ser melhoradas
para se atingir o prximo nvel de maturidade, conseqncias na organizao e
exemplos.
- Recomendaes: pontos que devem ser melhorados no processo de
desenvolvimento de software.

Aps a apresentao do relatrio final necessrio desenvolver um plano, identificando
cada capacidade que deve ser criada ou melhorada, responsabilidades e prazos para o
seu desenvolvimento e implantao. Para garantir a realizao do plano, muito
importante que ele seja realista e coerente com a estratgia de longo prazo da
organizao. fundamental que se use as prticas CMMI como guia implementao de
melhorias.

O TSP - Team Software Process, pode tambm ser considerado (Paulk, 1999) na
elaborao e execuo de melhorias direcionadas. O TSP (Humphrey, 2000b)
caracteriza-se por um controle rigoroso de tamanhos, esforos, prazos e defeitos,
tambm presentes no PSP. Porm, o TSP enfatiza as reas de processo: gerenciamento
de requisitos, planejamento e controle de projetos, garantia da qualidade e
gerenciamento da configurao.

Somente aps a realizao de todas estas etapas que os benefcios sero colhidos.

A partir da avaliao, em que se encontram os pontos fracos do processo, necessrio
fazer com que todos dentro da organizao comprem a idia de melhoria, de cima para
baixo, ou seja, desde a alta administrao. Isto implica na necessidade de se construir
uma disciplina de comprometimento. Todos os envolvidos devem a acostumar a assumir
compromissos com seriedade. Isto significa, entre outras coisas, no assumir
responsabilidades que no possam cumprir, isto , no prometer o que no pode cumprir
e cumprir o que prometeu. Isto especialmente importante em relao a tratamento de
prazos


113
Sem ao no h melhoria. Obviamente a avaliao do processo por si s no trs
nenhum benefcio, apenas benefcios para o conhecimento. Uma avaliao uma parte
do investimento para uma organizao produzir melhorias no processo de software.
importante para verificar o que precisa ser mudado no processo, evitando desperdcios
de investimentos em pontos desnecessrios, e mais, para criar nos participantes cticos o
verdadeiro comprometimento com a organizao para melhoria da capacidade do
processo (Wiegers, 2000).

6.7 Questionrio de Maturidade

Nas avaliaes CMM so normalmente utilizados questionrios, entrevistas e revises
de documentao na investigao dos processos da organizao. No MMA recomenda-
se a utilizao de questionrios como instrumento de coleta de dados.

O Questionrio de Maturidade, ou MQ - Maturity Questionnaire, (Zubrow, 1994) tem
sido utilizado como uma ferramenta de coleta de dados no auxlio implementao dos
mtodos de avaliao baseados no SW-CMM, como o SCE (Byrnes, 1996) e CBA IPI
(Dunaway, 1996). O MQ utilizado como fonte primria de coleta de dados, a partir de
sua aplicao que outros questionrios so criados e as entrevistas e revises so
direcionadas, visando maiores esclarecimentos do grupo avaliador.

O objetivo do MQ auxiliar o grupo avaliador a chegar a uma concluso sobre a
situao da organizao como um todo. Os dados obtidos pelo questionrio devem ser
confirmados atravs da reviso dos documentos e de entrevistas, ou seja, somente estes
dados no podem ser levados em considerao para o julgamento da capacidade do
processo de software.

As reas de processo, no SW-CMM, so chamadas de reas chave de processo, ou KPA
- Key Process reas. O MQ focaliza essencialmente o processo de desenvolvimento de
software e organizado em KPAs (que so no total 18).


114
No MQ as questes so apresentadas em forma de teste. As respostas possveis so: sim,
no, no se aplica (quando a pessoa considera que a questo no deve ser aplicada ao
projeto) e no sei (quando a pessoa no tem certeza sobre a resposta).

O MQ apresenta 124 questes que so apresentadas formando grupos de acordo com a
KPA a que elas se referem, ou seja, para cada KPA disponvel uma mdia de sete
questes. As questes se referem ao cumprimento e institucionalizao das KPAs.
Alm das questes, disponvel um espao onde possvel comentar e esclarecer as
respostas ou apontar referncias como documentao de suporte s mesmas.

No h regras sobre como as respostas do questionrio de maturidade devem ser
analisadas. Para se chegar a uma concluso sobre a avaliao necessrio levar em
considerao as evidncias de: implementao ou no das prticas chave do CMM,
prticas alternativas que concordam com objetivos das KPAs, pontos fracos e fortes do
processo de software.

Apesar de indicar o questionrio para coleta de dados, o CMMI no acompanhado por
questionrios criados pelo SEI. A caracterstica flexvel deste modelo implica tambm
na flexibilidade na criao de questionrios, visto que o que se quer avaliar depende da
realidade da organizao e das caractersticas da avaliao.

A origem e a estrutura do MQ no permitem que este seja to eficiente em avaliaes
baseadas na abordagem contnua do CMMI. Apesar de ser fonte primria de coleta de
dados em avaliaes SW-CMM, o MQ apresenta algumas desvantagens, at mesmo no
modelo para o qual foi criado. Este questionrio bastante extenso, pois cobre todas as
reas de processo definidas pelo SW-CMM, sem qualquer distino das caractersticas e
maturidade da organizao avaliada. Do ponto de vista de quem responde, o MQ pode
tornar-se cansativo, o que improdutivo. Alm de disso, deve-se considerar que na
avaliao de organizaes imaturas, questionamentos sobre prticas avanadas, podem
trazer a sensao de desnimo devido sobrecarga de informao. Diante da comum

115
averso inerente a mudanas, esta sobrecarga pode dar a sensao de que as mudanas
so mais dramticas do que realmente so.

6.8 Uma Proposta de Questionrio

A disponibilidade e facilidade de obteno dos documentos a respeito do CMM
permitem que organizaes se aventurem a implementao do modelo por conta
prpria. Aqui proposta uma estratgia para a criao e utilizao de questionrios, que
podem servir como fonte de coleta de dados da avaliao.

A estratgia utilizada para a criao dos questionrios baseada na observao de dois
itens:
- As prticas das reas de processo do CMMI (prticas bsicas).
- As ocupaes profissionais das pessoas envolvidas com o desenvolvimento de
software (papis).

Neste momento, importante considerar o escopo da organizao e o que quer avaliar.
Partindo do princpio que a organizao est saindo do estado de inrcia e dando seus
primeiros passos em direo a qualidade, considera-se que esta se encontra em um
estado imaturo. Sendo assim, sero questionadas as prticas que so indispensveis a
sada da situao de imaturidade. Por este motivo, somente as prticas consideradas
bsicas pelo CMMI sero avaliadas. Esta estratgia evita questionamentos
desnecessrios sobre prticas que no fazem parte do contexto da avaliao.

Outro ponto importante a escolha das pessoas que sero submetidas aos questionrios.
As questes devem ser endereadas s pessoas corretas, evitando que algum seja
questionado sobre uma atividade que no seja de sua competncia. Cada pessoa
responder sobre as atividades que desenvolve na organizao. Assim, os questionrios
sero mais produtivos, visto que, se uma pessoa desconhece a execuo de alguma
prtica na organizao, porque simplesmente esta prtica no executada.


116
6.8.1 Papis

A integrao harmoniosa de mtodos, ferramentas e pessoas que determina o
funcionamento eficaz de um processo de software (Rocha, 2001). Como parte integrante
deste trio, as pessoas tm um papel relevante no funcionamento de um processo. Dentro
de uma organizao h uma ou mais pessoas dedicadas a cada atividade, e o bom
andamento da organizao como um todo depende do bom desempenho destes
profissionais individualmente.

Devido a esta diversidade de atividades improdutiva a aplicao de um questionrio
nico para pessoas que desempenhem atividades diferentes, sob pena de se obter
resultados errneos. Sendo assim, a avaliao proposta neste trabalho trata-se de um
questionrio para cada categoria profissional.

O Questionrio de Maturidade (MQ) (Zubrow, 1994) no faz distino entre
profissionais, ou seja, um mesmo questionrio submetido aos indivduos selecionados,
independente de suas responsabilidades no desenvolvimento do software. O MQ
extenso e nem todas as questes so relevantes para uma mini-avaliao.

Na construo dos questionrios devem ser consideradas 3 categorias. A escolha destas
categorias deve-se ao fato de serem as categorias bsicas presentes em qualquer
organizao de desenvolvimento de software. As categorias consideradas foram: gerente
de projeto, analista de sistemas e programador.

Apesar desta distino, sabe-se que na realidade das organizaes de software, as
obrigaes da cada categoria acabam se confundindo. muito comum, principalmente
em organizaes menores, a existncia de analista-programador, ou seja, um mesmo
indivduo que executa a funo de programador e de analista. Outra situao, o analista
de sistema, normalmente assume tambm a funo de gerente do projeto. Objetivando
atender a organizaes com estas caractersticas, neste trabalho utilizado o conceito de
papis. Assim, questionrios diferentes devem ser criados para cada um dos 3 papis

117
(gerente de projeto, analista de sistema e programador). Na prtica isto significa que,
em situaes em que um mesmo indivduo assume a ocupao de analista e
programador, e ele seja escolhido para responder os questionrio, ele assumir o papel
de analista para responder o questionrio desta categoria e posteriormente assumir o
papel de programador, para responder o questionrio desta segunda categoria. Isso vale
para situaes de gerentes-analistas tambm. Profissionais que assumem mltiplas
funes em organizaes de software uma caracterstica bastante comum em
organizaes nacionais.

Antes de elaborar as questes de cada papel, necessrio identificar claramente as
obrigaes profissionais de cada categoria. Na prtica, pode at parecer uma tarefa
simples identificar o que cada um destes profissionais faz dentro de uma organizao,
mas seria bastante oportuno buscar uma base terica para esta identificao.

Esta no uma tarefa muito simples, visto que falta na literatura uma padronizao para
as ocupaes de cada categoria. Mesmo os poucos trabalhos tericos que existem neste
sentido, muitas vezes no so aplicveis realidade, justamente por esta caracterstica
multidisciplinar dos profissionais de software.

Para tentar identificar as ocupaes dos profissionais de cada categoria, foi utilizada a
ltima edio da Classificao Brasileira de Ocupaes CBO, disponibilizada pelo
Ministrio do Trabalho e Emprego, em 2002. A CBO, desenvolvida com o apoio de
pesquisadores da Unicamp, UFMG e Fipe/USP e profissionais do Servio Nacional de
Aprendizagem Industrial Senai, o documento que reconhece, nomeia e codifica os
ttulos e descreve as caractersticas das ocupaes do mercado de trabalho brasileiro.
Sua ltima edio acompanha as profundas mudanas ocorridas no cenrio cultural,
econmico e social do pas nos ltimos anos, que implicam em alteraes estruturais no
mercado de trabalho (CBO, 2002).

A CBO descreve estas categorias profissionais de forma bastante concisa da seguinte
forma:

118
- GERENTES DE TECNOLOGIA DA INFORMAO: Gerenciam projetos e
operaes de servios de tecnologia da informao; identificam oportunidades de
aplicao dessa tecnologia; administram pessoas e equipes e interagem com outras
reas (CBO, 2002).

- ANALISTAS DE SISTEMAS COMPUTACIONAIS: Desenvolvem e implantam
sistemas informatizados dimensionando requisitos e funcionalidade do sistema,
especificando sua arquitetura, escolhendo ferramentas de desenvolvimento,
especificando programas, codificando aplicativos. Administram ambientes
informatizados, prestam suporte tcnico ao cliente e o treinam, elaboram
documentao tcnica. Estabelecem padres, coordenam projetos, oferecem
solues para ambientes informatizados e pesquisam tecnologias em informtica
(CBO, 2002).

- TCNICOS DE DESENVOLVIMENTO DE SISTEMAS E APLICAES:
(Programador de Computador): Desenvolvem sistemas e aplicaes, determinando
interface grfica, critrios ergonmicos de navegao, montagem da estrutura de
banco de dados e codificao de programas; projetam, implantam e realizam
manuteno de sistemas e aplicaes; selecionam recursos de trabalho, tais como
metodologias de desenvolvimento de sistemas, linguagem de programao e
ferramentas de desenvolvimento. Planejam etapas e aes de trabalho (CBO,
2002) (maiores informaes a respeito destas ocupaes esto apresentadas no
Anexo 1).

Na elaborao de uma avaliao deve-se considerar as necessidades e caractersticas da
organizao. Assim, na primeira reunio para preparao da avaliao, o grupo
avaliador pode identificar outros papis presentes na organizao (como por exemplo,
gerente de qualidade e gerente de configurao, apesar de no serem profissionais
comuns em pequenas organizaes) e novos questionrios podem ser criados para ser
submetido a estes papis.


119
6.8.2 Prticas Bsicas

Este trabalho prope a criao de um questionrio para cada rea de processo do
CMMI, permitindo assim, que a organizao possa escolher as reas a serem avaliadas.
Observando a prioridade entre as reas j mencionadas.

Como j dito, cada rea de processo definida pelo CMMI composta por objetivos
especficos e genricos, organizados em prticas especficas e genricas
respectivamente.

Na abordagem contnua as prticas especficas so divididas em: prticas bsicas e
prticas avanadas. Todas as prticas especficas com nvel de capacidade 1 so
chamadas de prticas bsicas. As prticas especficas de nvel de capacidade 2 ou
superior so chamadas de prticas avanadas (CMMI, 2002b).

Considerando o escopo da organizao para a qual este trabalho se direciona,
desnecessrio o questionamento sobre a execuo de prticas avanadas. Desta forma,
esta avaliao prope a analise somente de prticas bsicas, visando a maior eficincia
da avaliao, mediante a criao de questes que fazem parte da realidade destas
organizaes. Evitando o desperdcio de tempo com questionamentos desnecessrios,
permitindo que a avaliao seja de certa forma rpida, objetiva e menos cansativa (as
prticas bsicas das reas de processo Planejamento de Projeto, Garantia de Qualidade
de Produto e Processo, Gerenciamento de Requisitos e Gerenciamento da Configurao
so apresentadas no Anexo 2).

Este trabalho indica as reas de processo a serem enfocadas em uma avaliao inicial, e
a profundidade em que cada rea ser investigada, o que determinado pela observao
das prticas bsicas de cada rea. Dentro da grande variedade de opes que a
engenharia de software oferece para a melhoria do processo, esta estratgia visa limitar
horizontal (reas de processo) e verticalmente (prticas bsicas) o enfoque da avaliao,
como ilustra a Figura 6.2.

120














FIGURA 6.2 Limites da avaliao.

6.8.3 Metodologia para Criao dos Questionrios

Lembrando que, cada rea de processo composta por vrias prticas bsicas. Quando
todas as prticas bsicas de uma rea de processo so executadas, a organizao atinge o
Nvel 1 de capacidade naquela rea. O cumprimento de cada rea envolve o trabalho de
vrios profissionais da organizao. Aqui foram considerados 3 categorias de
profissionais, que desempenham papis diferentes na organizao.

- Os questionrios:
Com o objetivo de dar liberdade para a organizao escolher a rea de processo a ser
avaliada, prope-se a criao de um questionrio para cada rea de processo, de forma
independente, apesar de algumas reas apresentarem certa dependncia.

Outro fator que deve ser considerado as obrigaes de cada profissional (gerente,
analista e programador) aqui chamado de papel.
Mini-
avaliao
reas de
Processo
Prticas
Bsicas
ENGENHARIA DE
SOFTWARE

121
Sendo assim, os questionrios devem ser feitos pelo cruzamento de duas informaes:
reas de processo e ocupaes profissionais das pessoas envolvidas, como ilustra a
Figura 6.3. Cada rea de processo ento ter 3 questionrios, sendo cada questionrio
feito para um papel. Por exemplo, para a rea de processo Planejamento de Projeto
haver 3 questionrios, um para cada profissional.






FIGURA 6.3 Esquema para elaborao dos questionrios.

- As questes:
As questes de cada questionrio, obviamente, devem ser criadas tambm pelo
cruzamento das informaes: prticas bsicas da rea de processo em questo e
obrigaes do profissional da categoria para a qual est sendo feito o questionrio.
Considerando como exemplo a rea de processo Planejamento de Projeto e a categoria
Analista, as questes para este questionrio sero feitas observando as obrigaes do
analista no planejamento de projetos, ou seja, as questes avaliaro o trabalho deste
profissional no planejamento de projeto.

O objetivo de estruturar o questionrio desta forma minimizar erros causados pelo
questionamento de atividades realizadas por terceiros. Assim, cada profissional
responder sobre suas prprias atividades. O objetivo no constranger o profissional
responsabilizando-o pelos possveis erros ou fracassos do projeto, mas sim conscientiza-
lo de que ele componente ativo da mquina do desenvolvimento e se cada um
disciplinar seu trabalho, o resultado ser o bom desempenho da maquina como um todo.
Valorizar o profissional uma das formas de incentiva-lo a melhorar continuamente.

reas de
Processo

Papis
QUESTIONRIOS

122
Considerando a caracterstica imatura das organizaes a que se destina este trabalho,
deve-se considerar a imaturidade tambm de seus profissionais quanto aos termos
tcnicos do CMMI. No desenvolvimento das questes importante utilizar uma
linguagem mais simplificada, em ocasies em que isso for impossvel, procurar
esclarecer ao mximo significado do termo. Muitas vezes o profissional pode no
compreender a questo e dar respostas que fogem da realidade. Obviamente o grau de
detalhamento tambm vai depender da cultura da organizao e seus profissionais.

Outro cuidado a ser tomado na formulao das questes com relao ao tipo de
resposta que o avaliador julgar mais convenientes. Como j mencionado, os
questionrios devem explorar as atividades dos prprios profissionais a que so
submetidos, ou seja, devem induzir respostas pessoais. Assim, as questes podem ser de
trs tipos:
- Questes qualitativas: so questes que permite o profissional descrever a forma
como ele executa uma determinada prtica. Por exemplo: Descreva a forma
como so obtidas estimativas de custo e prazos. As questes qualitativas (ou
descritivas) so mais fceis de serem elaboradas pela grupo avaliador e do
maior liberdade para o profissional se expressar. Porm, so mais trabalhosas na
concatenao dos dados para obteno do resultado final.
- Questes teste ou objetivas: estas questes podem ser do tipo booleanas, ou seja,
que permitem as respostas Sim ou No. Por exemplo: So utilizadas
ferramentas para automatizar o gerenciamento de verses?. As questes
booleanas so as mais difceis de serem elaboradas, sendo necessrio uma certa
percia do grupo avaliador na sua elaborao. Estas questes limitam as
respostas, e conseqentemente faz-se necessrio maior nmero de questes para
detalhar uma determinada prtica (quando comparada com questes
qualitativas). Um questionrio inteiro com questes deste tipo pode se tornar
muito extenso. Por outro lado, questionrios desta forma permitem maior
facilidade de obteno de resultados e comparaes entre profissionais de uma
mesma categoria.

123
- Questes quantitativas: so questes relacionadas com nmeros, por exemplo:
Qual o tempo mdio gasto na anlise de requisitos de software?. As questes
quantitativas nem sempre so convenientes no contexto de todas as prticas.

O grupo avaliador deve encontrar a melhor maneira para coletar os dados. Na maioria
das vezes, torna-se necessrio o emprego de mais um tipo de questes. O importante
que se usem termos condizentes com a cultura dos profissionais, que os questionrios
no sejam muito extensos e que sejam teis no levantamento de dados reais. Qualquer
ambigidade nas respostas faz necessrio o uso de entrevistas.

Muitos profissionais no esto acostumados com termos tcnicos, importante que, na
elaborao dos questionrios, seja utilizada a linguagem da organizao. Pois a no
compreenso ou compreenso errnea de termos pode causar distoro nos resultados
da avaliao.

No Anexo 1 e Anexo 2 deste trabalho esto descritos respectivamente as obrigaes dos
profissionais (gerente de projeto, analista, programador) e as reas de processo
consideradas mais relevantes no contexto deste trabalho (Planejamento de Projeto,
Garantia de Qualidade de Produto e Processo, Gerenciamento de Requisitos e
Gerenciamento da Configurao). Estas informaes podem ser teis na elaborao das
questes e para maiores esclarecimentos sobre as reas de processo do CMMI.


124
































125
CAPTULO 7
CONCLUSO

Ns odiamos mudanas e amamos ao mesmo tempo, o que realmente queremos que
tudo continue como est... mas que melhore (autor desconhecido) (Pinho, 2001). Esta
frase resume o anseio e o receio, sentimentos to contraditrios e caractersticos na
expectativa de mudanas. Mudana cultural difcil. Inserir novos conceitos nas
prticas de trabalho requer conhecimento, mas tambm persistncia. A princpio,
quando novos processos so implementados, comum que se crie uma situao
desconfortvel, uma sensao de trabalho a mais, que desaparece com o tempo, quando
estes processos passam a fazer parte da rotina. nesse momento que se constata um
acrscimo de maturidade e novos desafios podem ser lanados.

A introduo de procedimentos visando o aumento de qualidade pode causar, em um
primeiro momento, uma pequena reduo da produtividade, devido crtica fase de
aprendizado. Isto acontece com a introduo de qualquer tecnologia em um ambiente
de produo. necessrio que se tome cuidado para que os programas de melhoria no
sejam abandonados neste momento, fazendo com que os recursos investidos se percam,
baixando a moral dos envolvidos.

Muitas pessoas resistem a melhorias por sentirem-se ameaadas, uma vez que melhores
prticas e um acompanhamento mais eficaz pode trazer tona deficincias de
proficincia pessoal (Fiorini, 1999). Muitos tambm resistem, pois j possuem prticas
estabelecidas, algumas vezes eficazes, e no gostariam que estas prticas fossem
alteradas, pois as dominam. Portanto, a forma como as pessoas so envolvidas com a
implementao de um programa de melhoria, crucial.

O objetivo dos modelos CMM uma evoluo consciente, estruturada e contnua. A
vantagem em propor nveis diferentes de maturidade e capacidade, a de tornar mais

126
fcil a implementao das tarefas e possibilitar que a melhoria do processo da
organizao ocorra de forma gradativa, dando oportunidade de mudana de cultura.

Avaliar as prticas bsicas de uma rea de processo no significa que o trabalho acabou,
pois uma das principais metas do CMM e seus modelos derivados o contnuo
aprimoramento do processo.

O que h de positivo para a indstria brasileira de software, que existe um amplo
mercado a ser explorado e, principalmente, a importncia dos softwares para que o
mundo funcione em todos os campos, do trabalho ao lazer, passando por conflitos
armados at misses de paz e programas sociais. O que h de negativo que a indstria
brasileira ainda tem um longo caminho a percorrer para assumir uma posio importante
no contexto mundial. A qualificao do processo de desenvolvimento vista como um
poderoso recurso para vencer este desafio.

Nos dias de hoje, a qualidade um dos requisitos para garantir a sobrevida de um
software no mercado. Portanto, podemos concluir que as organizaes mais
competitivas so as que trabalham sob a tica da melhoria contnua dos processos para
aumentar a qualidade do processo de desenvolvimento e, conseqentemente, aumentar a
qualidade do produto final. A qualidade no um estado permanente, mas uma busca
constante.

A qualidade tambm no privilgio restrito a um tipo de organizao. Todas as
organizaes, inclusive as pequenas que dispe de poucos recursos, podem e devem
introduzir um mnimo de qualidade no seu processo de desenvolvimento e manuteno
de software. Esta no uma tarefa fcil, mas tambm no impossvel. Neste trabalho,
foi apresentado um caminho para que estas organizaes possam se aproximar dos
conceitos mais bsicos da busca da excelncia em engenharia de software.




127
7.1 Consideraes sobre o Desenvolvimento

Durante o desenvolvimento deste trabalho, algumas modificaes foram ocorrendo com
relao proposta inicial. Ao longo do tempo, muitas das expectativas iniciais foram se
mostrando inviveis e novas idias foram surgindo.

A meta era desenvolver um trabalho que auxiliasse no levantamento da qualidade do
processo de software e que fosse til a um vasto nmero de organizaes. Assim, foi
proposta inicialmente a criao de uma forma de avaliao baseada no CMM, que
pudesse ser executada por um questionrio. O questionrio teria como base o MQ
(Matutity Questionnaire), mas procurando extrair deste as suas desvantagens. O
questionrio no deveria ser extenso e cansativo; deveria considerar a maturidade da
organizao, evitar questionamentos sobre prticas de nveis mais elevados e utilizar um
vocabulrio coerente com a cultura dos profissionais; cada profissional responderia um
questionrio referente sua ocupao na organizao; as questes seriam booleanas
(Sim/No); medida que o questionrio fosse sendo respondido, novas questes seriam
apresentadas dependendo das respostas anteriores; o questionrio seria automatizado,
podendo ser respondido via Internet; no final da avaliao seria impresso um relatrio
sobre o levantamento da qualidade do processo da organizao avaliada.

O levantamento da qualidade do processo de software desta forma, quase que a um
passe de mgica, seria sem dvida um verdadeiro achado para a engenharia de software.
medida que esta idia foi amadurecendo, foram surgindo os obstculos. Foi verificado
que um questionrio desta forma deveria ser suficientemente longo para que no
deixasse nenhuma dvida a respeito do processo da organizao, principalmente
considerando-o como nica fonte de coleta de dados. Para um levantamento detalhado
seria necessria a criao de muitas questes. Assim, a tentativa de desenvolver um
questionrio menos extenso e cansativo seria descartada.

Alm disso, foi verificada a impossibilidade de se criar um questionrio, com as
caractersticas descritas anteriormente, que pudesse avaliar precisamente uma

128
organizao e ser utilizado por outras com a mesma eficincia. Era necessrio diminuir
o universo de cobertura da avaliao, definindo detalhadamente o escopo da
organizao para a qual a proposta seria til.

A imaturidade desta proposta inicial foi sendo constata a medida que se acumulavam os
estudos sobre sua viabilidade. Um questionrio deste tipo, para ser eficiente, deveria ser
direcionado a um universo muito restrito de organizaes, diminuindo
significativamente o nmero de organizaes que pudesse se beneficiar com o trabalho.
Assim, alguns conceitos iniciais foram sendo abandonados, modificados e outros
criados, para que fosse possvel uma proposta concreta para apoiar o levantamento da
qualidade do processo de software de um maior nmero de organizaes. O resultado
disso foi o presente trabalho, cujo escopo da organizao pode atender a um universo
bem maior de organizaes.

A proposta inicial no foi completamente abandonada. Ela foi inserida dentro de um
contexto maior, ou seja, ela est contida em uma estratgia de avaliao mais completa,
aqui apresentada. Assim, o presente trabalho tem uma caracterstica mais genrica.
Nestes termos a proposta do questionrio continua vlida, mas deve ser implementada
tendo em vista as caractersticas especficas da organizao a ser avaliada.

Outra considerao que merece nota a migrao para o CMMI. A princpio, a proposta
era baseada no CMM pelo seu contexto histrico de sucesso. Tendo em vista a
adaptabilidade do CMM ao escopo da organizao definida neste trabalho, foi
verificado que a flexibilidade do CMMI era mais indicada. Neste momento, o trabalho
passou a basear-se no CMMI. Porm, por ser um modelo recente, falta literatura que
fundamente sua eficincia. Dessa forma, toda a fundamentao terica sobre os
benefcios de se apoiar no CMMI feita com base em anos de utilizao do SW-CMM.

No decorrer deste trabalho outros fatores foram observados e vlidos de nota:
- Foi verificado o aumento do nmero de analistas em relao ao nmero de
programadores em organizaes de software. Assim, est havendo uma

129
conscientizao de que construir software muito mais do que simplesmente
criar inmeras linhas de cdigos.
- Os profissionais que j conhecem e/ou se beneficiaram com a melhoria da
qualidade de processo, esto muito abertos divulgao de suas experincias.
Todos os que foram procurados durante o desenvolvimento deste trabalho
(profissionais que vivenciaram a implementao de modelos de melhoria em
suas organizaes, especialistas em CMM [inclusive auditores certificados pelo
SEI] e pesquisadores) se mostraram bastantes solcitos colaborao.
- So muitos os profissionais de software que desconhecem completamente a
existncia de modelos para melhoria da qualidade de processo. Muitos destes se
interessavam pelo assunto e solicitavam fontes de pesquisa para maior interao
com os modelos. Talvez seja necessria uma maior divulgao.
- Muitos so os profissionais, at mesmo de grandes organizaes, que
simplesmente desconhecem termos bsicos de qualidade. Os que conhecem,
muitas vezes no aplicam em seu trabalho por falta de tempo, ou seja, seus
projetos esto sempre com cronogramas atrasados, ento abandonam vrios
procedimentos devido presso de gerentes e clientes.

7.2 Dificuldades Encontradas

No decorrer deste trabalho vrios obstculos foram sendo superados. importante
registrar algumas das dificuldades pessoais encontradas, que podem ser teis para outras
pessoas que queiram aventurar-se neste caminho. As principais dificuldades esto
relacionadas a:
- Falta de experincia pessoal no desenvolvimento de software. Por no ter
sentido na prtica o problema da falta de qualidade, ou usufrudo os benefcios
desta, foram muitas as dificuldades em propor uma maneira de busca-la.
- A grande diversidade de organizaes de software (como o tamanho, o tipo de
software, as necessidades e carncias, a metodologia de desenvolvimento ou
falta de uma, entre outros). Tudo isso dificulta a proposta de uma soluo

130
genrica para o problema de desenvolvimento, que possa atender as
necessidades de vrias organizaes.
- A inexistncia, na literatura, de uma receita de bolo onde se possa encontrar o
como que o CMM no define. O CMM no prescritivo, ou seja, ele no diz
organizao como melhorar, mas sim o que melhorar. O como uma
particularidade de cada organizao, pois depende de uma srie de fatores
(Pinho, 2001).

7.3 - Consideraes Finais

No se pretendia com este trabalho discutir a aplicabilidade do CMM em pequenas
organizaes, nem apresentar uma proposta revolucionria para o problema da falta de
qualidade, pois difcil algo nesta rea que ainda no tenha sido proposto. O problema
na engenharia de software no a falta de propostas tericas, o problema a falta de por
em prtica estas propostas. Este trabalho apresenta uma estratgia para diminuir a
distncia entre a teoria e a prtica que ainda assombra a engenharia de software.

O presente trabalho foi resultado da concatenao concluses extradas de: experincias
de mini-avaliaes (mini-assessment) que foram bem sucedidas em outras organizaes;
sugestes j consagradas de adaptao do CMM em pequenas organizaes; e, tcnicas
que se mostraram eficientes em avaliaes iniciais.

Espera-se que a necessidade eminente da qualificao dos processos, a importncia das
pequenas organizaes no contexto nacional e as dificuldades iniciais da busca pela
qualidade, expostas neste trabalho, sirvam de motivao para que outros trabalhos sejam
feitos neste sentido. Que as diretrizes aqui apresentadas contribuam positivamente para
que as organizaes descrevam seus prprios mtodos de avaliao. E que estes
mtodos sejam eficientes no levantamento e, posteriormente, na melhoria da qualidade
do processo.


131
Neste trabalho no foi proposta uma receita de bolo para elaborao e execuo de
uma avaliao de processo, mas apenas as diretrizes para a criao de um mtodo
efetivo. Que este trabalho sirva de incentivo s pequenas organizaes de software na
introduo de prticas mais efetivas de gerenciamento de projetos e que elas possam
colher os benefcios destas prticas. Para que um modelo de melhoria seja
positivamente implementado necessrio entender como funciona a organizao, o que
precisa ser modificado e o que precisa ser adicionado, e principalmente documentar os
procedimentos e formas de implementao de cada rea de processo enfocada.

Avaliar as prticas bsicas de uma rea de processo no significa que o trabalho acabou,
pois uma das principais metas do CMM e seus modelos derivados o contnuo
aprimoramento do processo. Neste trabalho foram apresentados primeiros passos de um
longo, mas bastante gratificante caminho em busca da qualidade do software.










133
REFERNCIAS BIBLIOGRFICAS
Arajo, E. E. R. Oportunidades e desafios para o desenvolvimento de uma indstria de
software nacional. Revista Cincia e Cultura, v.55, n.2, p.42-45, jun, 2003.
Argyris, C.; Schon, D. A. Organizational learning II: theory, method, and practice. 2
a
ed. New York: Editora Adison-Wesley, USA, 1995. 305 p.
Augusto Neto, . Uma estratgia para gerncia de qualidade e produtividade no
desenvolvimento de software. So Jos dos Campos, 1997. 172 p.
Dissertao ( Mestrado em Engenharia Eletrnica e Computao), Instituto Tecnolgico
da Aeronutica, 1997.
Barros, C. D. C Qualidade & participao: o caminho para o xito. So Paulo: Editora
Nobel, 1999. 129 p.
Bastos Jr, P. A. - INOVAO: Garantia de competitividade sustentvel s
organizaes. Revista Eletrnica Acadmica. Rio de Janeiro, set/out. 2000. Disponvel
em: <http://www.academica.cjb.net/> Acesso em : 02/10/2002.
Belloquim, A. CMM em pequenas organizaes: possvel? Infochoose n. 10. Ano I.
maio, 1999. Disponvel em:<http://www.choose.com.br/infochoose/infochoose10.htm>
Acesso em: 01/06/2003.
Belloquim, A. CMMI: O futuro do CMM. InfoChoose n. 42. Ano III. Janeiro/Fevereiro
2002. Disponvel em: < http://www.choose.com.br/infochoose/infochoose42.htm#1>
Acesso em: 02/03/2003.
Broadman, J. G; Johnson, D. L. What Small Business and Small Organizations Say
About the CMM. Sorento: ACM Digital Library 1994. Experience Report, p.331-340
Byrnes, P.; Phillps, M. Software capability avaluation. Version 3.0. Method
Description. Pittsburgh: Software Engineering Institute, Carnegie Mellon University.
Technical Report (CMU/SEI-96-TR-002/ESC-TR-96-002), Apr 1996. 192 p.
134
Capability Maturity Model Integration (CMMI). CMMI for software engineering
version 1.1(CMMI-SW, V1.1). Pittsburgh: Software Engineering Institute, Carnegie
Mellon University. Staged Representation, Improving processes for better products
(CMU/SEI-2002-TR-029/ESC-TR-2002-029), Aug., 2002a. 639 p.
Capability Maturity Model Integration (CMMI)., CMMI for software engineering
version 1.1 (CMMI-SW, V1.1). Pittsburgh: Software Engineering Institute, Carnegie
Mellon University. Continuous Representation, Improving processes for better products
(CMU/SEI-2002-TR-028/ESC-TR-2002-028), Aug 2002b. 645 p.
Cardoso, O. R. Foco da qualidade total de servios no conceito de produto
ampliado, Florianpolis, SC. Tese de Doutorado em Engenharia de Produo,
Universidade Federal de Santa Catarina, 1995. Disponvel em:
http://www.eps.ufsc.br/teses/olga/volume1/ Acesso em: 01/02/2003.
Carter, L.; Graettinger C.; Patrick, M.; Wemyss, G.; Zasadni S. The road to CMMI:
results of the first technology transition. Pittsburgh: Software Engineering Institute,
Carnegie Mellon University. Technical Report (CMU/SEI-2002-TR-007/ESC-TR-
2002-007), Feb 2002. 127 p.
Cordeiro, M. A. Modelos de qualidade de desenvolvimento de software. Jornal Bate
Byte - CELEPAR Companhia de Informtica do Paran, jul 2000. Disponvel em:
http://www.pr.gov.br/celepar/celepar/batebyte/edicoes/2000/bb99/modelos Acesso em:
04/12/2002.
Crosby, P. B. Qualidade Investimento. Rio de Janeiro: Editora Jos Olympio, 1991.
327 p.
Deming, W. E. Qualidade: a revoluo da administrao. Rio de Janeiro: Marques-
Saraiva, 1990. 368 p.
Dunaway, D. K. e Masters, S. CMM based appraisal for internal process
improvement (CBA IPI): method description. Pittsburgh : Software Engineering
Institute, Carnegie Mellon University. Technical Report (CMU/SEI-96-TR-007/ ESC-
TR-96-007), Apr 1996. 57 p.
135
Dunaway, D.; Berggren, R; Rochettes, G; Iredale, P; Lavi, I.; Taylor, G. Why do
organizations have assessments? do they pay off? Pitsburg: Software Engineering
Institute, Carnegie Mellon University. Technical Report (CMU/SEI-99-TR-012/ESC-
TR-99-012), July 1999. 35 p.
Ferreira, A. B. H - Novo Aurlio Sculo XXI. O dicionrio da lngua portuguesa. Rio
de Janeiro: Editora Nova Fronteira, 1999. 2128 p.
Fiorini, S. T. ; Staa, A.; Baptista, R. M. Engenharia de software com CMM. Rio de
Janeiro: Editora Brasport, , 1999. 354 p.
Furlan, J. D. CMM versus CMMI. Qual o melhor modelo para minha organizao?
Comunidade Digital, 2001.Disponvel em:
http://www.jdfurlan.com.br/Download/CMMxCMMI.PDF Acesso em: 04/08/2003.
2001.
Garvin, D. A. Gerenciando a Qualidade. Rio de Janeiro: Editora Qualitymark, 2002.
357 p.
Glass, R.L. Software runaways, lessons learned from massive software project
failures. Upper Saddle River, NJ: Prentice Hall, 1998. 245 p.
Gonalves, J. M; Villas Boas, A. Modelo de maturidade da capacidade de software
(CMM). Campinas: Fundao CPqD. Verso 1.2. Traduo no oficial do CMU/SEI-
93-TR-24-(CMM V1.1), 2001. 60 p.
Henry, J; Kafura, D; Henry S.; Matherson, L. Improving Software Maintenance at
Martin Marietta. IEEE Software, v. 11, n. 4 , p. 8 - 11. jul 1994.
Humphrey, W. Managing the software process. Massachussets: Addison-Wesley,
1989. 512 p.
Humphrey, W. The personal software process (PSP). Pittsburgh: Software
Engineering Institute, Carnegie Mellon University. Technical Report (CMU/SEI-2000-
TR-022/ESC-TR-2000-022), Nov 2000a. 40 p.
136
Humphrey, W. The team software process (TSP). Pittsburgh: Software Engineering
Institute, Carnegie Mellon University. Technical Report (CMU/SEI-2000-TR-023
ESC-TR-2000-023), Nov 2000b. 36 p.
International Standard Organization (ISO) ISO/IEC 12207. Standard for information
technology - software life cycle processes. Geneva: ISO, 1995. 75 p.
International Standard Organization (ISO). ISO/IEC 9126-1-1nformation technology.
Part 1: quality model. software product quality. Geneva: ISO, 1999. 40 p.
International Standard Organization (ISO). ISO/IEC TR 15504 - Information
technology. Part 1: concepts and introductory guide, process software assessment.
Geneva: ISO, 1997. 28 p.
Jones, C. Software project management in the 21st century. American Programmer,
v.11, n. 2, p. 12 18, Feb, 1999.
Juran, J. M. A qualidade desde o projeto - novos passos para o planejamento da
qualidade de produtos e servios. So Paulo: Pioneira, 1992. 538 p.
Juran, J. M. Juran planejando para a qualidade. So Paulo: Pioneira, 1990. 376 p.
Kan, S. H. Metrics and models in software quality engineering, Massachusetts.
Addison-Wesley, 1995. 560 p.
Koontz, H.; ODonnell, C. Management. 7
a
. ed. New York: Editora McGraw-Hill,
1986. 608 p.
Lamprech, J.L. ISO 9000 e o setor de servios. Rio de Janeiro: Editora Qualitymark, p.
237-253, 1997. p. 268.
Masters, S.; Bothwell, C. CMM apraisal framework CAF, version 1.0 . Pittsburgh:
Software Engineering Institute, Carnegie Mellon University . Tecnical Report
(CMU/SEI-95-TR-001/ESC-TR-95-001), Feb. 1995. 76 p.
137
McLain, J. Impact of CMM based software process improvement. Dissertao de
Mestrado em Sistema de Informao, Diviso de Estudos Profissionais. Honolulu:
Hawaii Pacific University, 2001. 230 p.
Ministrio da Cincia e Tecnologia / Secretaria de Poltica de Informtica Programa
Brasileiro de Qualidade e Produtividade em Software (PBQP). Qualidade e
produtividade no setor de software brasileiro: resultados da pesquisa bienal de 2001.
Braslia: Editora Brazilian Software, n. 4, 2002. 258 p.
Ministrio do Trabalho e Emprego (MTE). CBO - Classificao brasileira de
ocupaes CBO2002 Livro 1: Cdigos Ttulos e Descries, , Braslia-DF, ago. 2002.
650 p. Disponvel em: http://www.mtecbo.gov.br. Acesso em: 12/02/2003.
Paula Filho, W. P. Engenharia de software fundamentos, mtodos e padres. 2 ed.
o. Rio de janeiro: LTC, , 2003. 600p.
Paulk, M. C. Using the software CMM in small organizations. In: Pacific Northwest
Software Quality Conference, 16., with International Conference on Software Quality,
8.,13-14 Oct, 1998, Portland, Oregon. Proceedings. Portland: PNSQC/ASQ, 1998, p.
350-361.
Paulk, M. C. Using the software CMM with good judgment. ASQ Software Quality
Professional. Pttsburgh: SEI, v. 1, n. 3, June 1999, p. 19-29.
Paulk, M. C.; Curtis, B; Chississ, M; Weber, C. V. Capability maturity model version
1.1. Pittsburgh: Software Engineering Institute, Carnegie Mellon University. Technical
Report (CMU/SEI-93-TR-024/ESC-TR-93-177), Feb. 1993. 82 p.
Pereira, M. J. L. B.; Fonseca, J. G. M. Faces da Deciso, as mudanas de paradigma
e o poder da deciso. So Paulo: Makron Books, 1997. 278 p.
Pfleeger, S. L. ; Rombach H. D. Mesurement Based Process Improvement. IEEE
Softwrae, v. 11, n. 4 , p. 8 - 11. Julho 1994.
Pires, A, ; Mendes, J. R. B. CMM: o difcil dar o primeiro passo. Developers
Magazine, n. 30 - Ano 3, 1998.
138
Porter, M. E. A Vantagem competitiva das naes. Rio de Janeiro: Campus. 1993.
932 p.
Pressman, R. S. Engenharia de Software. So Paulo: Makron Books, 1995. 1056 p.
Reed, K. Software engineering a new millennium? IEEE Software, p. 17 201
July/ago, 2000.
Rocha, A. R. C. ; Maldonado, J.C. ; Webwr, K.C. Qualidade de software teoria e
prtica. So Paulo: Prentice Hall, , 2001. 303 p.
Rosa, P. G. Modelo de avaliao do processo de software para a pequena empresa.
So Paulo. Dissertao ( mestrado em Cincias Matemtica e de Computao)
Instituto de Cincias Matemticas e de Computao da Universidade de So Paulo,
1997. 90 p.
Roullier, A. C. Gerenciamento de projetos de software para empresas de pequeno
porte. Recife: 2001, 175p. Tese ( Doutorado em Cincia da Computao), UFPE.
Engenharia de Software e Qualidade de Software. 2001.
Sftware Engeneering Institute (SEI). ARC assessment requirements for CMMI.
Verso 1.1. Pittsburg: Software Engineering Institute, Carnegie Mellon Institute.
Technical Report (CMU/SEI-2001-TR-034/ ESC-TR-2001-034), Dez. 2001. 49 p.
SOFTEX Ministrio discute incentivo a melhoria da qualidade. Disponvel em:
http://www.softex.br/ Acesso em: 01/08/2003.
Software Engineering Institute, Carnegie Mellon University. 2002 SEI annual report
published . Pittsburgh: CMU, Feb, 2003. 76 p.
Sotware Engeneering Institute (SEI). SCAMPI standard CMMI appraisal method
for process improvement, version 1.1: method definition document. Pittsburgh :
Software Engineering Institute, Carnegie Mellon University Handbook (CMU/SEI-
2001-HB-001), , Dec., 2001. 245 p.
139
Spinola, M.; Pessoa, A.; e Volpe, R.L.D. Uma experincia na implantao do modelo
CMM., In: Simpsio Brasileiro de Engenharia de Software, WQS97 Workshop
Qualidade de Software, 1997, Fortaleza. Anais. Fortaleza: UFC, 1997.
Staa, A. Engenharia de programas. Rio de Janeiro: Ed LTC - Livros Tcnicos, 1987.
293 p.
Teboul, J. Gerenciando a dinmica da qualidade. Rio de Janeiro: Editora
Qualitymark, 1991. 292 p.
Tingey, M.O. Comparing ISO 9000, Malcolm Baldrige, and the SEI CMM for
software: a reference and selection guide. Upper Sadle River, NJ: Prentice Hall,
1997. 312 p.
Vieira, C.G.G. Uma metodologia para melhoria de processos, Florianpolis, SC.
Tese ( Mestrado em Engenharia de Produo), Universidade Federal de Santa Catarina,
1995. 156 p.
Weber, K.C. ; Rocha, A.R.C. ; Nascimento, C, J. Qualidade e produtividade em
software. 4 ed. So Paulo: Makron Books, 2001. 188 p.
Wiegers, K. E. A modular software process mini-assessment method. IEEE Software, ,
v. 17, n. 1, p. 62 69, Jan/Feb. 2000.
Zubrow, D.; Hayes, W.; Siegel, J. e Goldenson, D. Maturity questionnaire .
Pittsburgh: Software Engineering Institute, Carnegie Mellon University. Special Report
(CMU/SEI-94-SR-7), July 1994. 57 p.
141
APNDICE A
1 - O que a CBO2002
A Classificao Brasileira de Ocupaes - CBO o documento que normaliza o
reconhecimento, a nomeao e a codificao dos ttulos e contedos das ocupaes do
mercado de trabalho brasileiro.
A CBO codifica empregos e outras situaes de trabalho para fins estatsticos de
registros administrativos (por exemplo, Relao Anual de Informaes Sociais, Seguro
Desemprego, Declarao do Imposto de Renda de Pessoa Fsica, dentre outros), censos
populacionais e outras pesquisas domiciliares. Inclui cdigos e ttulos ocupacionais e a
descrio sumria.
Alm disso, a CBO tambm inventaria detalhadamente as atividades realizadas no
trabalho, os requisitos de formao e experincia profissionais e as condies de
trabalho. A CBO utilizada nos servios de recolocao de trabalhadores, na elaborao
de currculos e na avaliao de formao profissional, nas atividades educativas das
empresas e dos sindicatos, nas escolas, nos servios de imigrao, enfim, em atividades
em que informaes do contedo do trabalho sejam requeridas.
A CBO 2002 estruturada em Famlias Ocupacionais. Para efeitos prticos, define-se a
ocupao como o conjunto de postos de trabalho substancialmente iguais quanto a sua
natureza e as qualificaes exigidas. Constitui-se de tarefas, obrigaes e
responsabilidades atribudas a cada trabalhador. Pode-se ainda conceituar a ocupao
como o conjunto articulado de funes, tarefas e operaes destinadas obteno de
produtos ou servios (representado pelo cdigo total de 4 dgitos, cada dgito referente a
um grupo e subgrupos ocupacionais) (CBO, 2002).
2 Famlias Ocupacionais
A CBO foi utilizada como fonte de caracterizao dos profissionais de software
mencionados neste trabalho.
142
2.1 Gerentes da Tecnologia da Informao
O papel de Gerente de Projetos, utilizado neste trabalho, definido na Famlia 1425 da
CBO, que composta pelas seguintes ocupaes: Gerente de Rede, Gerente de
Desenvolvimento de Sistemas e Gerente de Produo de Tecnologia da Informao.
Condies gerais de exerccio: Os profissionais dessa famlia ocupacional podem
exercer suas funes em instituies financeiras, em empresas de tele-processamento,
de segurana, de suporte e manuteno informtica, de manuteno e expanso de
redes, de processamento e comunicao de dados, em setores empresariais de
desenvolvimento e produo de tecnologia da informao empresarial, entre outros.
Formao e experincia: Essas ocupaes so exercidas por pessoas com escolaridade
de ensino superior, acrescida de curso bsico com mais de quatrocentas horas, alm de
constantes cursos de especializao e aperfeioamento. O exerccio pleno das funes
ocorre aps o perodo de cinco anos de experincia profissional.
reas de Atividade:
a) Gerenciar a operaes de servios de Tecnologia da Informao: garantir aos usurios
a disponibilidade dos servios de tecnologia da informao; garantir cumprimento das
polticas da empresa; avaliar performance de recursos de tecnologia da informao;
avaliar indicadores de ocorrncias; validar solues propostas para ocorrncias; otimizar
o uso de recursos; propor melhorias nos processos operacionais; acompanhar
implementao de correes e mudanas no processo; monitorar operacionalizao de
projetos (operao assistida); revisar pontos que sofreram auditorias; garantir
atualizao do plano de contingncia; acionar plano de contingncia; acompanhar
atividades de gesto de mudanas; monitorar resultados; garantir integrao dos
produtos; acompanhar execuo oramentria; garantir manuteno do conhecimento de
tecnologia da informao na organizao, e garantir qualidade de servios e projetos.
b) Gerir projetos de Tecnologia da Informao: assegurar cumprimento de normas e
padres; alocar recursos humanos, materiais e tecnolgicos; controlar escopo do
projeto; controlar custos, prazos de execuo e andamento do projeto; gerir prestao de
servios terceirizados; analisar desvios na execuo de projetos e servios; corrigir
143
desvios; negociar mudanas de escopo com clientes e com fornecedores; aprovar
produtos do projeto; homologar equipamentos e softwares, e coordenar implantao do
projeto.
c) Identificar oportunidades de aplicao de Tecnologia da Informao: identificar
escopo das necessidades de clientes; prospectar solues tecnolgicas; estimar prazo,
custo e benefcios de solues propostas; presumir riscos e analisar qualidade de
solues propostas, e apresentar solues e alternativas.
d) Planejar atividades de Tecnologia da Informao: prever impactos de projetos e
servios e solues para situaes de risco; definir escopo do projeto e servio; analisar
escopo do negcio; definir estratgia de desenvolvimento e necessidades de recursos
humanos, materiais (infra-estrutura) e recursos tecnolgicos (software e hardware);
estabelecer prazos, custos de execuo e prioridades; elaborar propostas de projetos,
servios e oramento; definir matriz de responsabilidades e padres de performance e
qualidade; estabelecer acordo de nvel de servios, metas, poltica de segurana e pontos
de controle; traar plano de comunicao e plano de contingncia; homologar plano de
contingncia, e planejar simulao e execuo de plano de contingncia.
e) Administrar pessoas e equipes: disponibilizar recursos de trabalhos; distribuir
servios equipe; promover integrao; administrar conflitos; supervisionar
produtividade individual; avaliar desempenho; distinguir potencialidades individuais;
aprovar promoo de funcionrios; prover meios para treinamento e desenvolvimento;
especificar perfis dos profissionais da rea; selecionar profissionais; aprovar
programao de frias, e dispensar de funcionrios.
f) Interagir com outras reas: participar da criao de normas e procedimentos, da
avaliao de impactos de novas tecnologias, da definio de padres de
desenvolvimento de projetos e da definio de padres de segurana; negociar execuo
de servios de apoio (eltrica, civil, logstica, redes, sistemas); participar da simulao
de plano de contingncia; subsidiar elaborao de oramento de outras reas;
acompanhar processos de auditoria interna e externa, e relatar andamento de projetos;
divulgar planos, metas e resultados da rea.
144
2.2 Analista de Sistemas Computacionais
O papel de Analista, utilizado neste trabalho, definido na Famlia 2124 da CBO, que
composta pelas seguintes ocupaes: Analista de Desenvolvimento de Sistemas, Analista de
Redes e de Comunicao de Dados, Analista de Suporte Computacional e Analista de Sistemas
de Automao.
Condies gerais de exerccio: Os profissionais podem trabalhar em atividades
industriais, comerciais e de servios de informtica e atividades conexas, em atividades
econmicas como as da rea financeira, das comunicaes, das comerciais em geral.
Seu trabalho se realiza em equipe, com superviso ocasional.
Formao e experincia: O exerccio dessas ocupaes requer curso superior completo
em Cincia da Computao. Para os profissionais com outra formao de nvel superior,
o mercado de trabalho tem valorizado especializao e ps-graduao na rea de
informtica. O exerccio pleno das atividades ocorre, em mdia, aps dois anos de
experincia. Em funo da inovao tecnolgica, a permanncia no mercado de trabalho
requer atualizao contnua dos profissionais.
reas de atividade:
a) Desenvolver sistemas informatizados: estudar as regras de negcio inerentes aos
objetivos e abrangncia de sistema; dimensionar requisitos e funcionalidade de sistema;
fazer levantamento de dados; prever taxa de crescimento do sistema; definir alternativas
fsicas de implantao; especificar a arquitetura do sistema; escolher ferramentas de
desenvolvimento; modelar dados; especificar programas; codificar aplicativos; montar
prottipo do sistema; testar sistema; definir infra-estrutura de hardware, software e rede;
aprovar infra-estrutura de hardware, software e rede, e implantar sistemas.
b) Administrar ambiente informatizado: monitorar performance do sistema; administrar
recursos de rede, banco de dados e ambiente operacional, executar procedimentos para
melhoria de performance de sistema; identificar e corrigir falhas no sistema; controlar
acesso aos dados e recursos; administrar perfil de acesso s informaes, e realizar
auditoria de sistema.
145
c) Prestar suporte tcnico ao Cliente: orientar reas de apoio; consultar documentao
tcnica e fontes alternativas de informaes; simular problema em ambiente controlado;
acionar suporte de terceiros, e instalar e configurar software e hardware.
d) Treinar Cliente: consultar referncias bibliogrficas: preparar contedo programtico,
material didtico e instrumentos para avaliao de treinamento; determinar os pr-
requisitos do treinando, recursos udio visuais, hardware e software; configurar e
validar ambiente de treinamento, e ministrar treinamento.
e) Elaborar documentao para ambiente informatizado: descrever processos; desenhar
diagrama de fluxos de informaes; elaborar dicionrio de dados, manuais do sistema e
relatrios tcnicos; emitir pareceres tcnicos; inventariar software e hardware;
documentar estrutura da rede, nveis de servios, capacidade, performance e solues
disponveis; divulgar documentao, e elaborar propostas tcnicas e comerciais, estudos
de viabilidade tcnica e econmica e especificao tcnica.
f) Estabelecer padres para ambiente informatizado: estabelecer padro de hardware e
software; criar normas de segurana; definir requisitos tcnicos para contratao de
produtos e servios e metodologias a serem utilizadas; padronizar nomenclatura;
instituir padro de interface com usurio; divulgar utilizao de novos padres, e
especificar procedimentos para recuperao de ambiente operacional.
g) Coordenar projetos em ambiente informatizado: selecionar equipe de trabalho;
preparar cronograma de atividades e financeiro; administrar recursos internos e
externos; delegar funes equipe; acompanhar execuo do projeto; realizar revises
tcnicas; avaliar qualidade de produtos gerados, e validar produtos junto a clientes em
cada etapa.
h) Oferecer solues para ambientes informatizados: propor mudanas de processos e
funes; prestar consultoria tcnica; identificar necessidade do cliente; avaliar proposta
de fornecedores; negociar alternativas de soluo com cliente e fornecedor; adequar
solues a necessidade do cliente; demonstrar alternativas de soluo; divulgar soluo;
propor adoo de novos mtodos e tcnicas, e organizar fruns de discusso.
146
i) Pesquisar tecnologias em informtica: pesquisar padres, tcnicas e ferramentas
disponveis no mercado; identificar fornecedores; solicitar demonstraes de produto;
avaliar novas tecnologias por meio de visitas tcnicas; construir plataforma de testes;
analisar funcionalidade do produto; comparar alternativas tecnolgicas, e participar de
eventos para qualificao profissional.
j) Comunicar-se: desenvolver expresso oral e escrita e capacidade de negociao;
assimilar idias; desenvolver expresso em forma grfica; interpretar grficos,
diagramas e smbolos; adaptar linguagem, e trabalhar em equipe.
2.3 Tcnicos de Desenvolvimento de Sistemas e Aplicaes
O papel de Programador, utilizado neste trabalho, definido na Famlia 3171 da CBO,
que composta pelas seguintes ocupaes: Programador de Sistemas de Informao,
Programador de Multimdia, Programador de Mquinas com Comando Numrico e
Programador de Internet.
Condies gerais de exerccio: Trabalham em atividades de informtica e conexas,
presentes em todas as atividades econmicas. Trabalham individualmente e com
superviso ocasional, exceto o programador de internet, o programador de multimdia e
o programador de sistemas de informao, que podem, eventualmente, trabalhar em
equipe. Em algumas ocupaes, possvel o trabalho a distncia.
Formao e experincia: Para o exerccio dessas ocupaes requer-se ensino tcnico
de nvel mdio de informtica ou superior incompleto em reas como cincias exatas,
informtica, engenharia. A atualizao profissional permanente condio para o seu
exerccio. O desempenho pleno das atividades do programador requer de dois a quatro
anos de experincia, dependendo da ocupao.
reas de Atividades:
a) Desenvolver sistemas e aplicaes: desenvolver interface grfica; aplicar critrios
ergonmicos de navegao em sistemas e aplicaes; montar estrutura de banco de
dados; codificar, compilar e testar programas; prover sistemas de rotinas de segurana;
147
gerar aplicativos para instalao e gerenciamento de sistemas, e documentar sistemas e
aplicaes.
b) Realizar manuteno de sistemas e aplicaes: alterar sistemas e aplicaes e
estrutura de armazenamento de dados; atualizar informaes grficas e textuais;
converter sistemas e aplicaes para outras linguagens ou plataformas; atualizar
documentaes de sistemas e aplicaes; fornecer suporte tcnico, e monitorar
desempenho e performance de sistemas e aplicaes.
c) Implantar sistemas e aplicaes: instalar programas; adaptar contedo para mdias
interativas; homologar sistemas e aplicaes junto a clientes; treinar usurios; verificar
resultados obtidos, e avaliar objetivos e metas de projetos de sistemas e aplicaes.
d) Projetar sistemas e aplicaes: identificar demanda de mercado; coletar dados;
desenvolver leiaute de telas e relatrios; elaborar anteprojeto, projetos conceitual,
lgico, estrutural, fsico e grfico; definir critrios ergonmicos e de navegao em
sistemas e aplicaes; definir interface de comunicao e interatividade; elaborar
croquis e desenhos para gerao de programas em CNC; projetar dispositivos,
ferramentas e posicionamento de peas em mquinas; dimensionar vida til de sistema e
aplicaes, e modelar estrutura de banco de dados.
e) Selecionar recursos de trabalho: selecionar metodologias de desenvolvimento de
sistemas, linguagem de programao e ferramentas de desenvolvimento; especificar
configuraes de mquinas e equipamentos (hardware); especificar mquinas,
ferramentas, acessrios e suprimentos; compor equipe tcnica; especificar recursos e
estratgias de comunicao e comercializao, e solicitar consultoria tcnica.
f) Planejar etapas e aes de trabalho: definir cronograma de trabalho; reunir-se com
equipe de trabalho ou cliente; definir padronizaes de sistemas e aplicaes;
especificar atividades e tarefas e distribuir tarefas.
OBS: CBO completa pode ser obtida pela internet no endereo:
http://www.mtecbo.gov.br.
149
APNDICE B
1 reas de Processo
Neste trabalho foram levantadas algumas reas de processo consideradas mais crticas
no gerenciamento de projetos, que so: Planejamento de Projeto, Controle e
Monitorao de Projeto, Gerenciamento de Requisitos, Gerenciamento da Configurao
e Garantia de Qualidade de Processo e Produto. Estas reas devem ser enfocadas mais
urgentemente em um programa de melhoria.
A descrio destas reas apresentada a seguir. O intuito desta descrio introduzir os
objetivos do CMMI para cada uma destas reas.
Quando uma rea de processo no executada ou parcialmente executada, ela encontra-
se no Nvel 0 Incompleto. Para alcanar um nvel de capacidade, o objetivo genrico e
objetivos especficos do referente nvel devem ser alcanados. O objetivo genrico
comum para todas as reas. Cada nvel de capacidade possui um nico objetivo
genrico, que composto por prticas genricas. As prticas determinam o que deve ser
feito para atingir os objetivos.
Objetivo Genrico do Nvel 1: Alcanar os Objetivos Especficos.
Para uma rea de processo alcanar o nvel Executado (Nvel 1), a organizao deve
executar os objetivos especficos da referida rea. Este objetivo s possui uma prtica
genrica.
Prtica Genrica 1: Executar as prticas bsicas.
Para se atingir o objetivo genrico 1 necessrio executar todas as prticas especficas
consideradas bsicas da rea de processo em questo.
Cada rea de processo possui um ou mais objetivos especficos, composto por prticas
especficas. Nem todos os objetivos e prticas especficas so mencionados aqui, apenas
os que se relacionam com as prticas bsicas.
O CMMI utiliza os conceitos de produtos de trabalho e componentes do produto.
150
Os produtos de trabalho (work products) so alguns artefatos produzidos pelo processo,
como os arquivos, documentos, partes do produto, servios, especificaes, processos, e
outros. Os componentes do produto (product component) so integrados na construo
um produto (no caso o software). A diferena entre produtos de trabalho e componente
do produto que o primeiro no precisa necessariamente fazer parte do produto final a
ser entregue ao cliente. Os componentes do produto fazem parte do produto final e
podem ser necessrios para o uso do produto.
A seguir, so apresentados as reas de processo, consideradas prioritrias em um
programa de melhoria, e os objetivos especficos relacionados com as prticas bsicas.
1.1 rea de Processo Planejamento de Projeto
O propsito do Planejamento de Projeto estabelecer e manter planos que definam as
atividades do projeto.
O planejamento inicia-se com os requisitos que definem o produto e o projeto. Planejar
inclui estimar os atributos dos produtos e as tarefas, determinar os recursos necessrios,
negociar de comprometimentos, produzir um cronograma, identificar e analisar os riscos
do projeto. A interao entre estas atividades necessria para o estabelecimento do
plano razovel. O plano fornece a base para executar e controlar as atividades do projeto
que correspondem os compromissos com o cliente.
O plano deve ser revisado quando houver: mudanas nos requisitos e nos
compromissos, estimativas imprecisas, aes corretivas e mudanas no processo. Esta
rea de processo possui prticas especficas para planejamento e re-planejamento do
projeto.
Objetivo Especfico 1 Estabelecer Estimativas.
Estimativas de parmetros de planejamento devem ser estabelecidas e mantidas. Os
fatores que normalmente so considerados na estimativa destes parmetros so:
151
- Os requisitos do projeto, incluindo requisitos do produto, requisitos impostos
pela organizao, os requisitos impostos pelo cliente, e outros requisitos que
causam impacto no projeto.
- O escopo do projeto.
- As tarefas identificadas e produtos de trabalho.
- Abordagem tcnica.
- O modelo de ciclo-de-vida escolhido para o projeto (por exemplo, tamanho e
complexidade).
- Os atributos dos produtos e das tarefas.
- Os modelos ou dados histricos de tempo e custo em projetos passados.
- A metodologia (modelos, dados, algoritmos) usada para determinar a
necessidade de material, treinamento, horas de trabalho e custo.
As Prticas Bsicas relacionadas com este objetivo so:
1- Estimar o escopo do projeto.
2 - Estabelecer estimativas de produtos e atribuio de tarefas.
3 - Definir as fases do ciclo de vida do projeto.
4 - Determinar estimativas de esforos e custos do projeto.
Objetivo Especfico 2 Desenvolver um plano para o projeto.
Deve ser estabelecido e mantido um plano como base para o gerenciamento do projeto.
Um plano um documento formal, aprovado e usado para gerenciar e controlar a
execuo do projeto. baseado nos requisitos do projeto e em estimativas estabelecidas.
O plano deve considerar todo o ciclo de vida do projeto e garantir que todos os planos
que afetem o projeto sejam consistentes com o plano geral do projeto.
As Prticas Bsicas relacionadas com este objetivo so:
1 Estabelecer e manter o oramento e o cronograma do projeto.
2 Identificar e analisar os riscos do projeto.
3 Planejar o gerenciamento dos dados do projeto.
4 Planejar os recursos do projeto.
5 Planejar as necessidades de treinamentos e qualificao para a execuo do projeto.
6 Planejar o envolvimento dos interessados no projeto.
7 Estabelecer e manter plano geral do projeto.
152
Objetivo Especfico 3 Obter o comprometimento com o plano.
Compromissos com o plano devem ser estabelecidos e mantidos.
As Prticas Bsicas relacionadas com este objetivo so:
1 Revisar todos os planos que afetam os projetos.
2 Conciliar o plano do projeto com os recursos estimados e disponveis.
3 Obter o comprometimento das pessoas relevantes responsveis pela execuo e
apoio ao plano.
1.2 rea de Processo Controle e Monitorao de Projeto
O objetivo do Controle e Monitorao de Projeto permitir um entendimento do
progresso do projeto e tomada de aes corretivas apropriadas, quando a execuo do
projeto desvia significativamente do plano estabelecido. Estas aes podem requerer re-
planejamento, reviso do plano original, estabelecimento de novos compromissos e
adio de novas atividades no plano corrente.
Um plano documentado do projeto a base para monitorar atividades, comunicar status
e executar aes corretivas.
Objetivo Especfico 1 Monitorar o contraste entre o plano e o projeto.
O desempenho atual e o progresso do projeto so confrontados com o plano do projeto.
As Prticas Bsicas relacionadas com este objetivo so:
1 Monitorar os parmetros do planejamento do projeto.
2 Monitorar os compromissos.
3 Monitorar os riscos do projeto.
4 Monitorar o gerenciamento dos dados do projeto.
5 Monitorar o envolvimento das pessoas interessadas com o projeto.
6 Conduzir revises progressivas.
7 Conduzir revises formais em marcos pr-determinados do desenvolvimento.
Objetivo Especfico 2 Gerenciar aes corretivas.
153
O gerenciamento de aes corretivas necessrio quando a execuo do projeto ou os
resultados desviam significativamente do plano.
As Prticas Bsicas relacionadas com este objetivo so:
1 Coletar e analisar os pontos onde h contraste entre o plano e o andamento do
projeto.
2 Tomar aes corretivas.
3 Gerenciar aes corretivas.
1.3 - rea de Processo Gerenciamento de Requisitos
O propsito do Gerenciamento de Requisitos gerenciar os requisitos do produto e de
seus componentes e identificar inconsistncias entre estes requisitos, o plano e o
produto desenvolvido.
O Gerenciamento de Requisitos gerencia todos os requisitos recebidos ou gerados pelo
projeto, incluindo requisitos tcnicos e no tcnicos, assim como os requisitos
determinados pela organizao. Se a rea Gerenciamento de Requisitos implementada,
normalmente seus processos geraro tambm requisitos de produto e componentes do
produto, que tambm devero ser gerenciados.
Os requisitos devem ser revisados entre as entidades que os definem (como o cliente, a
organizao) e quem deve aceita-lo (por exemplo, gerente, analista). Uma vez chegado
a um acordo, os demais participantes do projeto devem se comprometer com estes
requisitos.
Os requisitos tendem a ser bastante volteis, isto , podem mudar bastante durante o
desenvolvimento do projeto. Gerenciar os requisitos tambm documentar as mudanas
de requisitos, e manter um controle bi-direcional entre os requisitos definidos e os
requisitos do produto e componentes do produto.
Objetivo Especfico 1 Gerenciamento de requisitos.
Os requisitos devem ser gerenciados e inconsistncias com os planos do projeto e
produtos de trabalho deve ser identificado.
154
As Prticas Bsicas relacionadas com este objetivo so:
1 Obter o entendimento dos requisitos.
2 Obter comprometimento dos participantes do projeto com os requisitos.
3 Gerenciar as mudanas nos requisitos durante a execuo do projeto.
4 Manter um controle entre os requisitos, o plano e os produtos de trabalho.
5 Identificar inconsistncias entre o plano do projeto, os produtos de trabalho e os
requisitos.
1.4 - rea de Processo Gerenciamento de Configurao
O propsito do Gerenciamento de Configurao estabelecer e manter a integridade dos
produtos de trabalho usando identificao de configurao, controle de configurao,
relatrio do status de configurao e auditoria da configurao.
Os produtos de trabalhos mantidos sob gerenciamento da configurao incluem os
produtos que so entregues ao cliente, componentes internos do produto, produtos
adquiridos, ferramentas, e outros itens usados na criao e descrio destes produtos de
trabalho. Exemplos destes produtos so: os planos, descrio de processo, requisitos,
dados de projeto, diagramas, especificao do produto, cdigo-fonte, arquivos de dados
do produto e publicaes tcnicas do produto.
O gerenciamento da configurao pode ser executado em vrios nveis, ou seja, os itens
de configurao podem ser decompostos em componentes de configurao e unidades
de configurao. Em um sistema composto por hardware e software, o software pode
ser considerado como um nico item de configurao, ou o software pode ser
decomposto em mltiplos itens de configurao. Nesta prtica o termo item de
configurao usado para referir os elementos sob controle de configurao.
As linhas bsicas (baselines) fornecem uma base estvel para a evoluo contnua dos
itens de configurao. As linhas bsicas so adicionadas ao sistema de gerenciamento
de configurao quando so desenvolvidas. Mudanas na construo de linhas bsicas e
releases dos produtos de trabalho de um sistema de gerenciamento de configurao so
155
sistematicamente controladas e gerenciadas atravs de controle de configurao,
gerenciamento de mudanas e auditoria da configurao.
Esta rea de processo se aplica no somente ao gerenciamento da configurao, mas
tambm para gerenciar a configurao dos produtos de trabalho como padres,
procedimentos e reuso de bibliotecas.
Objetivo Especfico 1 Estabelecer linhas bsicas.
As prticas especficas deste objetivo so relacionadas com o estabelecimento de linhas
bsicas e seleo dos itens de configurao. A seleo destes itens deve obedecer a
algum critrio documentado. Cada item deve ter uma identificao nica, suas
caractersticas devem ser especificadas, alm da identificao dos responsveis por cada
item de configurao.
Um sistema de gerenciamento de configurao deve incluir os meios, os procedimentos
e as ferramentas para acesso ao sistema de configurao. necessrio um mecanismo
de nveis de controle para gerenciar a configurao. Armazenar e recuperar os itens de
configurao e a verso destes itens. Criar relatrios dos itens de configurao. Revisar
a estrutura de configurao quando necessrio.
As Prticas Bsicas relacionadas com este objetivo so:
1 - Identificar os itens de configurao, componentes e produtos de trabalho
relacionados que sero mantidos sob gerenciamento da configurao.
2 Estabelecer e manter um sistema de gerenciamento de mudanas e gerenciamento da
configurao, para controlar os produtos de trabalho.
3 Criar linhas bsicas para uso interno e para ser entregue ao cliente.
Objetivo Especfico 2 Acompanhar e controlar mudanas.
Mudanas nos produtos de trabalho mantidas sobre gerenciamento de configurao
devem ser acompanhadas e controladas. Mudanas no controladas nos itens pode gerar
defeitos e falhas nos produtos. necessrio anlise do impacto das mudanas nos itens.
As Prticas Bsicas relacionadas com este objetivo so:
1 Acompanhar os pedidos de mudana para os itens de configurao.
156
2 Controlar as mudanas nos itens de configurao.
Objetivo Especfico 3 Estabelecer a integridade.
A integridade das linhas bsicas deve ser estabelecida e mantida.
As Prticas Bsicas relacionadas com este objetivo so:
1 Estabelecer e manter registros com descrio dos itens de configurao.
2 Executar auditoria da configurao para manter a integridade das linhas bsicas.
1.5 rea de Processo Garantia de Qualidade de Processo e Produto
Esta rea de processo apia a entrega de produtos e servios de alta qualidade por
fornecer ao gerente e pessoal envolvido no projeto a viso geral da eficcia do processo
e produtos associados em todo o ciclo de vida deste projeto.
No CMMI, as prticas desta rea objetiva que os processos planejados sejam
implementados.
A objetividade na avaliao da qualidade determinante para o sucesso do projeto. A
objetividade alcanada pela independncia e pelo uso de critrios. Normalmente,
quando o grupo de qualidade independente do projeto, fica mais fcil manter esta
objetividade. Porm, h organizaes que a funo de garantir a qualidade est
embutida no processo. Neste caso, necessrio ter o cuidado de focalizar na
objetividade. Todos os envolvidos com atividades de garantia da qualidade devem ser
treinados. As atividades de garantia da qualidade devem ser separadas das atividades
diretamente envolvidas com o desenvolvimento e manuteno dos produtos de trabalho.
Os casos de no conformidade verificados devem primeiramente ser tratados entre as
pessoas envolvidas com o projeto e, se possvel, serem resolvidas ali. Quando no forem
resolvidas nesta instncia devem ser conduzidas para uma instncia de gerenciamento
apropriada. Assim, necessrio que exista um canal independente de comunicao com
a gerncia.
157
Atividades de garantia da qualidade devem comear nas primeiras fases de um projeto
para estabelecer planos, processos, padres e procedimentos com o objetivo de
adicionar valor ao projeto e satisfazer os requisitos do projeto considerando a poltica
organizacional. Estas atividades devem acompanhar todo o ciclo de vida do projeto. As
revises e auditorias so aplicadas em vrios pontos durante o desenvolvimento e
servem para descobrir defeitos enquanto estes ainda so relativamente baratos para
serem encontrados e tratados.
Objetivo Especfico 1 Avaliar objetivamente os processos e produtos de trabalho.
Avaliar objetivamente a conformidade entre a execuo dos processos, produtos de
trabalho e servios e a descrio do processo, padres e procedimentos e planos
aprovados.
As Prticas Bsicas relacionadas com este objetivo so:
1 - Avaliar objetivamente buscando garantir de que os planos, descries, padres e
procedimentos definidos para o processo esto sendo cumpridos.
2 - Avaliar objetivamente buscando garantir de que os planos, descries, padres e
procedimentos definidos para os produtos de trabalho e servios sendo cumpridos.
Objetivo Especfico 2 Providenciar o cumprimento dos objetivos.
Casos de no conformidade devem ser objetivamente investigados e comunicados, e
solues devem ser encontradas.
As Prticas Bsicas relacionadas com este objetivo so:
1 Comunicar questes de qualidade e encontrar solues para os casos de no
conformidade com o gerente e demais pessoas envolvidas.
2 Estabelecer e manter registros de atividades de garantia de qualidade.
2 - Relacionamento entre as reas de Processo
H um forte relacionamento entre estas reas de processo, dentre os quais podem ser
citados:
- O Planejamento de Projetos e o Gerenciamento de Requisitos relacionam-se
mutuamente na obteno de maiores informaes sobre os requisitos necessrios
158
no planejamento e re-planejamento e tambm sobre a necessidade de reviso no
plano quando h mudanas nos requisitos.
- O Controle e Monitorao do Projeto e Planejamento do Projeto se completam.
- O Gerenciamento de Requisitos, por sua vez, relaciona-se com o Gerenciamento
da Configurao na obteno de maiores informaes sobre as linhas bsicas e
controle de mudanas para documentao da configurao dos requisitos.
- O Gerenciamento de Configurao relaciona-se tambm com o Planejamento de
Projeto na determinao dos itens de configurao.
Foram apresentadas aqui as principais consideraes a respeito das prticas bsicas
destas reas de processo. No modelo CMMI-SW so disponibilizadas informaes
detalhadas sobre cada uma destas reas (CMMI, 2002b).