Controle Estat Do Processo

MODELO PARA CONTROLE ESTATSTICO DE
PROCESSOS DE DESENVOLVIMENTO DE
SOFTWARE (CEP-S)
PATRCIA CORRA FONSECA
MODELO PARA CONTROLE ESTATSTICO DE

PROCESSOS DE DESENVOLVIMENTO DE
SOFTWARE (CEP-S)
Dissertao apresentada ao Programa de

Ps-Graduao em Cincia da Computao
do Instituto de Cincias Exatas da Universidade Federal de Minas Gerais como requisito parcial para a obteno do grau de
Mestre em Cincia da Computao.
Orientador: Clarindo Isaas P. S. Pdua

Coorientadora: Letcia Pereira Pinto
Belo Horizonte, Minas Gerais

Setembro de 2010
c 2010, Patrcia Corra Fonseca.

Todos os direitos reservados.
Fonseca,Patrcia Corra
F676m
Modelo para Controle Estatstico de Processos de
Desenvolvimento de Software (CEP-S) / Patrcia
Corra Fonseca. Belo Horizonte, Minas Gerais, 2010
xxvi, 144 f. : il. ; 29cm
Dissertao (mestrado) Universidade Federal de
Minas Gerais
Orientador: Clarindo Isaas P. S. Pdua
Coorientadora: Letcia Pereira Pinto
1. Computao - Teses. 2. Engenharia de Software Testes. I. Orientador. II. Coorientadora. III. Ttulo.
CDU 519.6*32(043)
vi
Dedico este trabalho a meus pais, Glria e Marconi.
vii
Agradecimentos
Aos professores ngelo de Moura Guimares e Antnio Alfredo F. Loureiro, pelos incentivos e pelas recomendaes, que viabilizaram a oportunidade para o desenvolvimento
deste trabalho.
Ao meu orientador, professor Clarindo, pelas orientaes, que culminaram nesta
dissertao.
Letcia Pereira Pinto, minha co-orientadora, pelas orientaes em estatstica,
que guiaram grande parte do trabalho nesse assunto.
Ao Vitor Alcntara Batista, pela prontido e apoio na coleta e anlise dos dados,
e ao Laboratrio Synergia, que colocou disposio tais dados. Ambos tornaram
possvel a realizao dos estudos de caso.
Ao professor Rodolfo F. Resende, pelas revises do artigo que escrevermos, juntamente com o Professor Clarindo e a Letcia. O artigo foi um marco importante na fase
de elaborao desta dissertao, pois favoreceu a construo de uma viso sintetizada
e, ao mesmo tempo, completa.
Ao Departamento de Cincia da Computao e UFMG pela excelncia no ensino
e pesquisa, que gera a satisfao de ser formada por esta instituio. Ao CNPq pelo
apoio financeiro trazido pela bolsa de estudos concedida durante um semestre.
Fernanda Sander, ao Bruno, Waltin e Rabelo pela disponibilidade em ajudarem
com as preciosas revises do texto.
Ao Andr, meu amor, por no revidar minhas ausncias, por ser meu porto seguro.
Cleo e Toninho pelo carinho, suporte e tambm pelos exemplos de vida acadmica.
Ao Sr Eteg, que com benevolncia, me manteve em seu quadro de profissionais,
mesmo quando minha dedicao estava focada, em grande parte, nos trabalhos de
pesquisas.
Mrcia Tupinambs, minha amiga e terapeuta, pelas conversas e pelo reiki,
que me ajudam a lidar melhor com as questes cotidianas.
ix
E so muitos a quem tenho que agradecer, que, de alguma forma, com uma
palavra, uma ideia, uma piada, uma companhia, fazem parte desta conquista! Em
especial, aos familiares, aos amigos, s super poderosas: Ana, Luluzinha e Quel, amigas
de toda hora, dvd-session e hellmans, grupo de amigos e colegas que promovem os
eventos sociais, que fazem a vida mais divertida!
Pensar estatisticamente ser um dia, para a eficiente prtica da cidadania, to

necessrio como a habilidade de ler e escrever.
(H.G.Wells)
xi
Resumo
Considerando a importncia da indstria de software no mercado nacional, o fato de ela
ser, na maioria, representada por pequenas e mdias empresas (PME) e pela crena de
que a promoo dessa indstria se d, em parte, pela promoo da qualidade e produtividade, propomos um modelo para PME aplicarem Controle Estatstico de Processo
(CEP) no desenvolvimento de software, o Controle Estatstico de Processo de Software (CEP-S). O CEP utiliza a estatstica para gerenciar os processos de produo,
promover continuamente a melhoria de qualidade atravs da reduo da variabilidade
dos parmetros de controle e dar apoio tomada de deciso da alta gerncia. O seu
objetivo principal permitir diagnosticar se o processo est sob influncia de causas
atribuveis que precisam ser investigadas e eliminadas. O modelo CEP-S prope um
conjunto de caractersticas de qualidade a serem monitoradas para determinados processos, os grficos de controle mais adequados para cada processo e sugestes para a
escolha dos parmetros de controle. Esses elementos so organizados em um mtodo
proposto no modelo, fornecendo um arcabouo com escolhas pr-definidas, porm flexveis, que contribui para tornar a aplicao de CEP em PME facilitada, favorecendo
as investidas iniciais nas atividades de controle estatstico.
xiii
Abstract
Considering the importance of software industry in the national market, the fact that
it is mostly composed of small and medium enterprises (SMEs) and based on the belief that the advancement of this industry occurs, in part, by improving quality and
productivity we propose here a model for the application of a Statistical Process Control (SPC) to software development by SMEs. The SPC uses statistics to manage the
production process, to continually improve quality by reducing the variability of the
control parameters and to support decision making by top management. Its main purpose is to diagnose whether the process is under the influence of assignable causes that
need to be investigated and eliminated. The model proposes a set of quality characteristics to be monitored for certain processes, and the control charts most appropriate
for each case and suggestions for choosing the control parameters. These elements are
organized in a method proposed in the model, providing a framework flexible but with
pre-defined choices, to facilitate the application of SPC by SMEs, enabling their initial
forays in statistical control activities.
xv
Lista de Figuras
1.1
Tipos de pesquisa segundo Jung [2004] . . . . . . . . . . . . . . . . . . . .
11
2.1
Grfico das Baleias - RUP Rational Unified Process . . . . . . . . . . . . .
20
2.2
Ilustrao de um Ciclo do PDCA . . . . . . . . . . . . . . . . . . . . . . .
21
2.3
Ilustrao do Modelo IDEAL . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.4
Ilustrao do Ciclo DMAIC . . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.5
Exemplo de um Diagrama SIPOC . . . . . . . . . . . . . . . . . . . . . . .
25
2.6
Escada Qualidade em Servios . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.7
Viso de uma matriz Desdobramento da Funo da Qualidade . . . . . . .
28
2.8
Tabela Classificao Modelo Kano . . . . . . . . . . . . . . . . . . . . . . .
29
3.1
Variao controlada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.2
Variao no controlada . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.3
Parmetros de controle LC, LSC e LIC . . . . . . . . . . . . . . . . . . . .
41
3.4
Limites de controle e especificao . . . . . . . . . . . . . . . . . . . . . . .
46
3.5
Correlao Forte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
3.6
Correlao Fraca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
3.7
Testes de controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
3.8
Exemplo de Histograma - nmero de defeitos por tipo . . . . . . . . . . . .
56
3.9
Exemplo de Diagrama de Pareto - nmero de defeito por tipo . . . . . . .
57
3.10 Exemplo de grfico para anlise de custo x benefcio . . . . . . . . . . . . .
58
4.1
Viso das atividades para aplicao de CEP . . . . . . . . . . . . . . . . .
60
4.2
Viso dos processos de desenvolvimento de software . . . . . . . . . . . . .
63
4.3
Caractersticas de interesse . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
4.4
Goal-Driven Software Measurement . . . . . . . . . . . . . . . . . . . . . .
75
4.5
Estratgia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
4.6
Mapa estratgico BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
4.7
Viso integrada das 3 ferramentas . . . . . . . . . . . . . . . . . . . . . . .
81
xvii
4.8
Digrama de deciso para grfico de controle . . . . . . . . . . . . . . . . .
86
4.9
Parmetros de controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
4.10 Classificao de defeitos . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
4.11 Atividades para estabilizar o processo . . . . . . . . . . . . . . . . . . . . .
88
4.12 Controle Estatstico de Processo . . . . . . . . . . . . . . . . . . . . . . . .
90
5.1
[IR-ReP] Teste de normalidade . . . . . . . . . . . . . . . . . . . . . . . .
94
5.2
[IR-ReP] MMEP (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
5.3
[IR-ReP] MMEP (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
5.4
[IR-PrP] Teste de normalidade . . . . . . . . . . . . . . . . . . . . . . . . .
96
5.5
[IR-PrP] MMEP (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
5.6
[IR-PrP] MMEP (4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
5.7
[IR-PPP] Teste de normalidade . . . . . . . . . . . . . . . . . . . . . . . .
97
5.8
[IR-PPP] MMEP (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
5.9
[IR-PPP] MMEP (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
5.10 Participao dos Processos em Produo . . . . . . . . . . . . . . . . . . .
98
5.11 [IR-DeP] Teste de normalidade . . . . . . . . . . . . . . . . . . . . . . . .
99
5.12 [IR-DeP] MMEP (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
5.13 [IR-DeP] MMEP (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
5.14 [DR-ReP] MMEP (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.15 [DR-ReP] MMEP (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.16 [DR-PrP] MMEP (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.17 [DR-PrP] MMEP (9) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.18 [DR-PPP] Teste de normalidade . . . . . . . . . . . . . . . . . . . . . . . . 103
5.19 [DR-PPP] MMEP (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.20 [DR-DeP] MMEP (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.21 [DR-DeP] MMEP (4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.22 [DE-ReP] MMEP (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.23 [DE-PrP] MMEP (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.24 [DE-PPP] MMEP (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.25 [IM-ReP] MMEP (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.26 [IM-PrP] Teste de normalidade . . . . . . . . . . . . . . . . . . . . . . . . 109
I (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.27 [IM-PrP] X
5.28 [IM-PrP] MMEP (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.29 [IM-PPP] Teste de normalidade . . . . . . . . . . . . . . . . . . . . . . . . 110
5.30 [IM-PPP] MMEP (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
xviii
C.1 Porte das empresas brasileiras de software . . . . . . . . . . . . . . . . . . 132

C.2 Fatores da competitividade . . . . . . . . . . . . . . . . . . . . . . . . . . 135
xix
Lista de Tabelas
3.3
Comprimentos Mdios de Sequncias para CM S1 . . . . . . . . . . . . . .

Comprimentos Mdios de Sequncias para Vrios Esquemas de Controle
MMEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Estimativa de ppm para Cp . . . . . . . . . . . . . . . . . . . . . . . . . .
46
57
4.1
4.2
Atividades dos processos alvo de CEP . . . . . . . . . . . . . . . . . . . .

Processos da estratgia . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
77
3.1
3.2
45
B.1 Classificao do Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

C.1 Histrico dos marcos das aes polticas do Brasil . . . . . . . . . . . . . . 132
xxi
Sumrio
Agradecimentos
ix
Resumo
xiii
Abstract
xv
Lista de Figuras
xvii
Lista de Tabelas
xxi
1 Introduo
1.1
Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Objetivos do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3
Limites do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4
Mtodo de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.5
Organizao deste documento . . . . . . . . . . . . . . . . . . . . . . .
15
2 Reviso bibliogrfica
17
2.1
Principais conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.2
CEP e a melhoria de processos de desenvolvimento de software . . . . .
30
2.2.1
O primeiro momento de reviso . . . . . . . . . . . . . . . . . .
30
2.2.2
O segundo momento de reviso . . . . . . . . . . . . . . . . . .
31
Caracterizao das PME desenvolvedoras de software . . . . . . . . . .
34
2.3
3 O controle estatstico de processo (CEP)
37
3.1
Mtodos estatsticos . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.2
Viso geral dos grficos de controle . . . . . . . . . . . . . . . . . . . .
40
3.3
Limites de controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.4
Limites de especificao . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.5
Tamanho da amostra e frequncia de amostragem . . . . . . . . . . . .
47
xxiii
3.6
Testes de hiptese, nvel de significncia e P-valor . . . . . . . . . . . .
47
3.7
Coeficiente de correlao . . . . . . . . . . . . . . . . . . . . . . . . . .
48
3.8
Testes de normalidade . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
3.9
Testes para deteco de situaes fora-de-controle . . . . . . . . . . . .
50
3.10 Grficos de controle X-Barra, S e R . . . . . . . . . . . . . . . . . . . .
52
3.11 Grfico de controle X Barra-Individual . . . . . . . . . . . . . . . . . .
53
3.12 Grficos de controle para no-conformidades (Defeitos) . . . . . . . . .
54
3.13 Grfico MMEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
3.14 Histograma e Grfico de Pareto . . . . . . . . . . . . . . . . . . . . . .
55
3.15 Capacidade do processo . . . . . . . . . . . . . . . . . . . . . . . . . .
56
3.16 Grfico de custo benefcio . . . . . . . . . . . . . . . . . . . . . . . . .
57
4 O Modelo CEP-S
4.1
59
Seleo dos processos alvo do controle estatstico . . . . . . . . . . . . .
61
4.1.1
Viso dos processos alvo de CEP . . . . . . . . . . . . . . . . .
62
4.1.2
Viso das atividades dos processos alvo de CEP . . . . . . . . .
64
4.1.3
Consideraes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
4.1.4
Guia de personalizaes . . . . . . . . . . . . . . . . . . . . . .
68
Identificao das caractersticas de interesse . . . . . . . . . . . . . . .
70
4.2.1
As Caractersticas de interesse . . . . . . . . . . . . . . . . . . .
70
4.2.2
Seleo das caractersticas de interesse . . . . . . . . . . . . . .
73
4.3
Planejamento e execuo das medies . . . . . . . . . . . . . . . . . .
80
4.4
Construo dos grficos de controle . . . . . . . . . . . . . . . . . . . .
85
4.5
Estabilizao dos processos . . . . . . . . . . . . . . . . . . . . . . . . .
88
4.6
Controle estatstico dos processos . . . . . . . . . . . . . . . . . . . . .
89
4.2
5 Estudo de caso
5.1
91
Aplicando o Modelo CEP-S . . . . . . . . . . . . . . . . . . . . . . . .
91
5.1.1
Processo: Identificao de Requisitos (IR) . . . . . . . . . . . .
94
5.1.2
Processo: Detalhamento de Requisitos (DR) . . . . . . . . . . . 100
5.1.3
Processo: Desenho Externo (DE) . . . . . . . . . . . . . . . . . 105
5.1.4
Processo: Implementao (IM) . . . . . . . . . . . . . . . . . . . 107
5.2
Viso geral das anlises dos resultados . . . . . . . . . . . . . . . . . . 111
5.3
Anlise de viabilidade Modelo CEP-S . . . . . . . . . . . . . . . . . . . 112
6 Concluso
6.1
117
Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

xxiv
Apndice A Conceitos e frmulas estatsticas

121
A.1 Definies iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
A.2 Erros de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Apndice B Caracterizao do software
127
Apndice C Anlise do cenrio atual do mercado de software nacional 131

Referncias Bibliogrficas
137
xxv
Glossrio
Glossrio
amostra Parte da populao selecionada para anlise. 33
anlise de ponto de funo uma tcnica usada para medir o tamanho funcional
do software (tamanho na viso do usurio) e cuja utilizao vem ganhando cada
vez mais adeptos, utiliza o fator de ajuste para ajustar o tamanho do software em
funo de 14 caractersticas gerais do sistema, que so: Comunicao de Dados,
Processamento de Dados Distribudo, Desempenho, Utilizao do Equipamento
(Restries de Recursos Computacionais), Volume de Transaes, Entrada de
Dados On-line, Eficincia do Usurio Final (Usabilidade), Atualizao On-line,
Processamento Complexo, Reusabilidade, Facilidade de Implantao, Facilidade
Operacional (Processos Operacionais, tais como Inicializao, Cpia de Segurana, Recuperao etc), Mltiplos Locais e Organizaes do Usurio e Facilidade
de Mudanas (Manutenibilidade). 3
distribuio de probabilidade Coleo de pares, [xi , p(xi )], onde xi so os possveis
resultados para i=1,2,... e p(xi ) as probabilidades do resultado xi . 33
subgrupo racional Consiste na retirada de pequenas amostras a intervalos de tempo
regulares, onde cada amostra ou subgrupo racional constitudo de unidades produzidas quase num mesmo instante. Se houver uma causa atribuvel dificilmente
ele ocorrer durante a formao do subgrupo. Isso minimiza a probabilidade de
que a amostra seja formada por elementos de diferentes populaes. Costa et al.
[2008]. 43
Acrnimos
Acrnimos
APF Anlise de Ponto de Funo. 3
BSC Balanced Scorecard. 6, 66, 69, 72, 74, 76
CEO Chief executive officer. 62
CEP Controle Estatstico de Processo. xiii, 15, 911, 13, 14, 18, 21, 2729, 33, 35,
3840, 44, 48, 55, 56, 62, 66, 76, 88, 113115, 130
CEP-S Controle Estatstico de Processo de Software. xiii, 1, 36, 10, 11, 28, 30, 33,
34, 37, 38, 43, 48, 52, 53, 5558, 6266, 68, 69, 74, 76, 81, 83, 84, 87, 88, 108110,
113115
CMMI Capability Maturity Model Integration. 9, 14, 17, 18, 26, 62
CMS Comprimento Mdio da Sequncia. 40, 41, 48
CUSUM Soma Cumulativa. 50
GQ(I)M Goal-Question-Indicator-Measurement. 6, 66, 69, 70, 76
GQM Goal-Question-Metric. 70
LOC Linhas de Cdigo. 3
MMEP Mdia Mvel Exponencialmente Ponderada. 50, 51, 110, 114
MPS.BR Melhoria de Processos do Software Brasileiro. 1, 18, 62, 110
PDCA Plan Do Check Act. 9, 14, 15, 17, 19, 26, 62
3
GLOSSRIO
PME pequenas e mdias empresas. xiii, 1, 2, 4, 6, 9, 12, 13, 19, 30, 31, 40, 55, 56, 63,
127130
PSM Practical Software and Systems Measurement: A Foundation for Objective Project Management. 4, 76
TIC Tecnologias da Informao e da Comunicao. 128
UML Unified Modeling Language. 15
Captulo 1
Introduo
A viagem de descoberta consiste no em achar novas paisagens, mas em ver com novos olhos.
Marcel Proust
O setor brasileiro de software composto por 8,5 mil empresas que desenvolvem,
distribuem e comercializam software. Dentre as que desenvolvem, 94% so micro e
pequenas empresas, Fuoco [2009], e dessas, a grande maioria atuante apenas no
mercado nacional.
O carter transversal do software nas cadeias produtivas e sua disseminao nas
diversas atividades humanas tem eleito essa indstria como estratgica, uma vez que
os resultados de seu desenvolvimento tm efeitos relevantes em vrias frentes. E mais
relevante do que a participao quantitativa direta da indstria de software no produto
agregado de cada pas o papel crucial desempenhado por tais tecnologias para o
funcionamento de inmeras atividades, sejam elas diretamente produtivas ou ligadas
ao consumo, Roselino [2006a]. Vrios programas e incentivos nacionais vm sendo
realizados para promoo dessa indstria. Os apoios vo desde incentivos fiscais e
de financiamentos diretos via BNDES at subsdios para programas de melhorias da
qualidade e da produtividade, como o Melhoria de Processos do Software Brasileiro
(MPS.BR), voltado para a realidade de PME que desenvolvem software.
Considerando a importncia da indstria de software no mercado nacional, o fato
de ela ser, na maioria, representada por PME e pela crena de que a promoo dessa
indstria se d, em parte, pela promoo da qualidade e produtividade, propomos um
modelo para PME aplicarem CEP no desenvolvimento de software, o CEP-S. O CEP
utiliza a estatstica para gerenciar os processos de produo e promover continuamente
a melhoria de qualidade atravs da reduo da variabilidade dos parmetros de controle.
O seu objetivo principal permitir diagnosticar se o processo est sob influncia de
causas atribuveis que precisam ser investigadas e eliminadas. O modelo CEP-S prope
5
Captulo 1. Introduo
um conjunto de caractersticas de qualidade a serem monitoradas para determinados

processos, os grficos de controle mais adequados para cada processo e sugestes para
a escolha dos parmetros de controle, fornecendo um arcabouo com escolhas prdefinidas que contribui para tornar a aplicao de CEP em PME facilitada, favorecendo
as investidas iniciais nas atividades de controle estatstico.
1.1
Motivao
O raciocnio do controle estatstico, segundo Levine et al. [2000], pode ser definido
como os processos voltados para o entendimento, o gerenciamento e a reduo de
variaes nas execues dos processos de produo. Ele uma ferramenta estatstica
muito popular em manufaturas mas no na indstria de software, Florac & Carleton
[1999]. Em parte, essa falta de popularidade da aplicao de CEP em processos de
desenvolvimento de software pode ser resultante de alguns desafios, distintos daqueles
da aplicao em manufatura. Seguem alguns fatores responsveis por essa distino:
A quantidade de dados (medidas) gerada na produo (projetos de desenvolvimento) de software e sistemas pequena, o que limita ou at inviabiliza as pesquisas como amostragens, medies, projetos de experimentos (DOE, do ingls
Design Of Experiments) e anlises estatsticas, Serrano [2004]. Essa quantidade
pode apresentar-se ainda mais reduzida para empresas de menor porte, onde o
nmero de projetos executados em cada perodo de tempo pequeno;
As atividades so intensivamente dependentes da interferncia humana, de fatores
como a criatividade, por exemplo, e so mais centradas em processos do que em
produtos, o que dificulta a aplicao direta de CEP, Komuro [2006]. Empresas
que tm seus processos informais tm esse fator agravado, pois so fortemente
dependentes de seus profissionais;
Kan, em Kan [2004], aponta que a aplicao simples de CEP nos processos de
desenvolvimento de software difcil porque, alm de envolver um alto grau de
criatividade e atividades mentais, tais processos so bastante complexos;
Em software, cada unidade de produto desenvolvido um novo produto, distinto
do anterior. Isso dificulta a definio das caractersticas de interesse normalizadas,
das caractersticas de qualidade a serem controladas estatisticamente;
Em manufatura, as medidas para as caractersticas de interesse so bem definidas. Como exemplos tpicos de tais caractersticas podemos citar volume, cor,
1.1. Motivao
densidade, peso e resistncia. Em contraposio manufatura, as medidas das

caractersticas de interesse em software tm alto grau de subjetividade. Como
exemplos dessas medidas citamos tamanho (Anlise de Ponto de Funo (APF)
e Linhas de Cdigo (LOC))1 e nmero de defeitos ou no-conformidades 2 .
Alm dos desafios citados, relativos indstria de software, adicionamos um desafio especfico de organizaes de pequeno e mdio porte. Essas, que representam
a grande maioria da indstria de software nacional, por definio, tm um quadro
limitado de profissionais, sendo tal prtica uma forte restrio presena de um profissional dedicado e capacitado em definir um modelo de CEP para essas organizaes.
A demanda por profissionais com habilidades tcnicas diretamente relacionadas ao desenvolvimento de software, ou seja, rea fim, tende a absorver todo o potencial de
contratao de profissionais disponvel nessas organizaes.
A motivao para a construo do modelo CEP-S est no fato de que CEP uma
poderosa ferramenta, que apoia o gerenciamento quantitativo e a melhoria contnua
dos processos. Porm, para que seja uma proposta aplicvel a empresas que prestam
servios de desenvolvimento de software necessrio que haja mecanismos que enderecem os desafios apresentados. Espera-se que o modelo defina tais mecanismos para
permitir o uso de CEP e para:
Apoiar a gesto da qualidade e a promoo da maturidade dos processos;
Fornecer informaes sobre a existncia de causas especiais de variao e a previsibilidade dos processos. Um estudo da Associao Brasileira das Empresas de
Software, ABES [2009b], mostrou que 29% das empresas de software determinaram a otimizao e a previsibilidade como objetivos estratgicos em 2009;
Apoiar a quantificao dos ganhos providos pelas aes de melhoria;
Apoiar a sintetizao de informaes para a tomada de deciso;
Apoiar a formulao de estimativas confiveis a partir das informaes da capacidade dos processos;
1
As caractersticas gerais de sistema da anlise de ponto de funo so baseadas em padres e

recursos computacionais antigos, que pouco refletem a realidade, tornando seu uso pouco efetivo e
deixando o tamanho funcional subjetivo em relao lacuna das caractersticas gerais. O nmero de
linhas de cdigo, alm de ser usado somente depois do sistema codificado, dependente da linguagem
de implementao e no h um padro que defina objetivamente o que uma linha de cdigo.
2
O nmero de defeitos ou no-conformidades no reflete o impacto do prazo de correo ou dos
custos incorrido para o cliente e o fornecedor, ou seja, o impacto dos defeitos no proporcional ao
nmero de defeitos
Captulo 1. Introduo
Uma abordagem, proposta por Deming, Florac & Carleton [1999], afirma que,
para a organizao ser competitiva, melhorar a qualidade e aumentar a produtividade
algumas aes precisam ser realizadas. Tais aes podem ser realizadas a partir da
aplicao de CEP e consistem em: focar nos processos que geram os produtos e servios;
certificar-se de que os processos tm os suportes adequados; reconhecer que variaes
esto presentes em todos os processos e que identificar as causas de sua existncia uma
oportunidade para aplicao de aes de melhorias; usar as variaes dos processos para
apoiar as tomadas de deciso e gerenciar o comportamento inadequado dos processos.
1.2
Objetivos do trabalho
A proposta principal deste trabalho consiste na construo de um modelo que defina os

passos para a aplicao de CEP em PME que prestam servios de desenvolvimento de
software. Esse modelo composto por um conjunto de atividades que foram agrupadas
em duas fases: planejamento e execuo. A fase do planejamento corresponde s
atividades descritas a seguir, nos itens A, B, C, D e E. A fase de execuo corresponde
atividade descrita no item F.
A. Seleo dos processos alvo do controle estatstico: a aplicao de CEP
dispendiosa, deve se restringir a um nmero pequeno de processos, a apenas os
considerados estratgicos e que influenciam fortemente o sucesso do negcio. A
presente atividade seleciona tais processos, define uma viso de como eles so organizados para o planejamento das medies e apresenta os conceitos envolvidos
e as personalizaes necessrias para adaptar o modelo CEP-S organizao;
B. Identificao das caractersticas de interesse: essa atividade identifica um
conjunto de caractersticas de interesse, cuja mensurao seja tangvel e estrategicamente significativa. Em seguida, apresenta um mecanismo para apoiar a
organizao na seleo de um subconjunto de caractersticas, dentre as propostas,
aquelas que estiverem alinhadas aos objetivos estratgicos;
C. Planejamento e execuo das medies: a organizao precisa ser capaz de
planejar e executar eficientemente um plano de medio, para que os dados disponibilizados para anlise sejam confiveis. Para o planejamento e a execuo de
polticas de medio, recomendamos o mtodo Practical Software and Systems
Measurement: A Foundation for Objective Project Management (PSM), PSM
[2003], cujos passos so apresentados ao longo dessa atividade;
1.3. Limites do trabalho
D. Construo dos grficos de controle: os grficos planejados para o controle

estatstico devem ser eficientes na deteco rpida e confivel de condies forade-controle. Essa construo apresentada a partir dos seguintes passos: (i)
a escolha dos grficos; (ii) a definio dos parmetros, que so: os limites de
controle, o tamanho da amostra e a frequncia da amostragem; (iii) a definio
dos testes de estabilidade e a identificao das causas atribuveis;
E. Estabilizao dos processos: essa atividade responsvel pela promoo das
melhorias mais significativas de processos. Ela complexa e desafiadora para
a organizao, podendo colocar em risco o sucesso do controle estatstico se as
melhorias no forem efetivas e, por consequncia, no levarem o processo a uma
situao de estabilidade. O processo estvel permite o clculo dos parmetros
de controle que conduziro o controle estatstico. A organizao nem sempre
conseguir eliminar as causas atribuveis e levar o processo a uma situao de
estabilidade, inviabilizando assim a aplicao do modelo CEP-S.
F. Controle estatstico dos processos: essa atividade envolve os passos para execuo do CEP, que so: a coleta e plotagem dos dados; os testes de controle; a
investigao das causas atribuveis; a aplicao de melhorias; e a eliminao dos
dados influenciados por causas atribuveis.
1.3
Limites do trabalho
Estabelecer os limites do trabalho to importante quanto definir seus objetivos, pois

delimita mais rigorosamente o seu escopo. Para o presente trabalho os limites so:
O modelo CEP-S prope uma estrutura para o controle estatstico dos processos
de Requisitos e de Implementao de software, definindo as consideraes para
a sua aplicao, a partir de uma viso desses processos. O modelo extensvel,
podendo ser aplicado a outros processos de software, porm ele se limita a definir uma viso e as consideraes apenas para os processos de Requisitos e de
Implementao;
O modelo CEP-S no define os processos de medio da organizao, mas apresenta o mtodo PSM como recomendao. necessrio que a organizao tenha
seus processos de medio definidos e institucionalizados, pois tais processos so
os responsveis pela produo dos insumos para a aplicao do modelo CEP-S;
10
Captulo 1. Introduo
O modelo CEP-S no esgota as necessidades de medies da organizao. Ele

trata exclusivamente das medies que so usadas nos controles estatsticos propostos. Logo, a organizao deve tratar de outras medies, indo alm das estabelecidas no presente trabalho. O vasto conjunto de medies que uma organizao
necessita diferente do conjunto que ela deve controlar estatisticamente, visto o
alto custo para realizar os controles estatsticos. Esses controles estatsticos devem enfocar apenas nos processos que esto relacionados e colaboram diretamente
com os objetivos estratgicos.
O modelo voltado para PME que prestam servios de desenvolvimento de software sob encomenda e vertical. A aplicao do modelo em outros cenrios no
ser abordada neste trabalho.
Espera-se que o modelo CEP-S seja usado em conjunto com outras ferramentas
da organizao, para o gerenciamento da estratgia, do portflio, dos projetos ou
da qualidade, apropriado para a anlise estatstica. A Seo 4.2.2.4 apresenta um
exemplo de como o CEP-S pode ser integrado ao Balanced Scorecard (BSC) e
ao Goal-Question-Indicator-Measurement (GQ(I)M) para a seleo das caractersticas de interesse. Porm, desvia-se do escopo do presente trabalho a oferta de
mecanismos para integrao do modelo com a vasta quantidade de ferramentas
de gerenciamento que podem estar em uso em uma organizao. O estudo desses
mecanismos poderia, inteiramente s, compor um trabalho completo de pesquisa,
devido sua dimenso.
1.4
Mtodo de pesquisa
O mtodo cientfico um conjunto de regras bsicas para desenvolver uma experincia a fim de produzir
um novo conhecimento, bem como corrigir e integrar conhecimentos pr-existentes. Na maioria das
disciplinas cientficas consiste em juntar evidncias observveis, empricas (ou seja, baseadas apenas na
experincia) e mensurveis e as analisar com o uso da lgica.
Wikipdia(2009)
Esta Seo apresenta o tipo de pesquisa e os procedimentos planejados e realizados para o desenvolvimento do presente trabalho. Para definir o tipo da pesquisa,
apresentamos duas classificaes, dadas por Jung, Jung [2004], e Wohlin, Wohlin et al.
[2000]. Jung prope uma classificao que abrange a natureza, os objetivos, os procedimentos e o local de realizao da pesquisa, como exposto na figura 1.1. Segundo ele,
quanto natureza, uma pesquisa pode ser bsica/fundamental ou aplicada/tecnolgica;
quanto aos objetivos, ela pode ser exploratria, descritiva ou explicativa; quanto aos
1.4. Mtodo de pesquisa
11
procedimentos, pode ser experimental, operacional ou um estudo de caso; e, finalmente,

quanto ao local pode ser de laboratrio ou de campo. Wohlin prope uma classificao que abrange quatro mtodos relevantes de pesquisa e enfoca no detalhamento do
mtodo emprico, por esse ser bastante apropriado para pesquisas em Engenharia de
Software. Os quatro mtodos so:
Figura 1.1: Tipos de pesquisa segundo Jung [2004]
Mtodo cientfico: a realidade observada e um modelo construdo para

represent-la;
Mtodo de engenharia: alguma evoluo das solues atuais proposta aps essas
terem sido estudadas;
Mtodo emprico: um modelo proposto e evoludo atravs de estudos empricos.
Mtodo analtico: uma teoria formal proposta e ento comparada com as observaes empricas.
12
Captulo 1. Introduo
Segundo Wohlin, a Engenharia de Software governada mais pelo comportamento

humano, atravs das pessoas envolvidas no desenvolvimento de software, que por regras
formais ou leis. Sendo assim, o modelo emprico um modelo adequado para estudos
dessa disciplina. Wohlin divide os estudos empricos em dois paradigmas, sendo eles a
pesquisa qualitativa e a pesquisa quantitativa, e em trs estratgias, a vistoria, o estudo
de caso e o experimento. Os paradigmas e as estratgias so detalhados a seguir:
Os dois paradigmas empricos propostos so:
Pesquisa qualitativa: interpreta os fenmenos sobre a tica das pessoas que os avaliam;
Pesquisa quantitativa: compara dois ou mais grupos, geralmente a partir de experimentos controlados ou coleta de dados de estudos de caso e promove anlise
estatstica dos resultados.
Essas duas abordagens so complementares, podem ser usadas para investigar
um mesmo tpico, onde cada uma enderea questes diferentes.
As trs principais estratgias empricas so:
Vistoria: uma investigao desenvolvida em retrospectiva, via questionrios ou entrevistas. realizada atravs de uma amostragem representativa da populao
a ser estudada. Os resultados obtidos so analisados e concluses descritivas ou
exploratrias so estabelecidas. Esses resultados podem ser analisados a partir
do paradigma qualitativo ou quantitativo ou a partir de ambos os paradigmas.
Estudo de caso: um monitoramento de projetos e atividades, uma observao da
realidade, sem interveno sistemtica do pesquisador, Wazlawick [2008], onde os
dados so coletados com um propsito especfico e os resultados documentados.
O controle sobre o ambiente menor que no uso de experimentos. Os resultados
de um estudo de caso podem ser analisados a partir do paradigma qualitativo
ou quantitativo ou a partir de ambos os paradigmas. Para que um estudo de
caso seja vlido necessrio que haja bases slidas de validao e minimizao de
m interpretao dos resultados. Wohlin sumariza uma proposta de trs meios
para validar um estudo de caso: (i) comparar os resultados obtidos contrapondoos aos resultados de uma linha de base anterior; (ii) comparar os resultados de
duas execues paralelas, cujas caractersticas sejam semelhantes; (iii) aplicar o
mtodo para algumas execues individuais e randomicamente no aplicar para
outras.
1.4. Mtodo de pesquisa
13
Experimento: so estudos em ambientes controlados sistematicamente pelo pesquisador, realizados normalmente em laboratrios, cujos dados coletados so analisados sempre quantitativamente.
Quanto natureza, segundo a viso de Jung, o presente trabalho foi planejado
para ser uma pesquisa aplicada/tecnolgica, ou seja, a partir de conhecimentos bsicos
gerar um novo produto e modificar prticas existentes. Quanto aos objetivos, foi planejado para ser uma pesquisa exploratria, que visa os estudos exploratrios iniciais e
a descoberta de novas prticas. Quanto aos procedimentos, um estudo de caso que
investiga um fenmeno dentro de um contexto real, cujos passos consistiram de:
( i) projetar e construir um modelo com componentes pr-definidos de CEP, que favorea o uso em PME prestadora de servios de desenvolvimento de software e
que aborde caractersticas de interesse significativas;
( ii) planejar e executar os estudos de caso em duas organizaes, de pequeno e mdio
porte, as quais se dispuseram de antemo a participar dessa etapa;
(iii) retroalimentar o modelo, com melhorias identificadas durante a execuo dos
estudos de caso;
( iv) avaliar o modelo final e elaborar a concluso do trabalho.
Os procedimentos descritos foram estabelecidos aps dois momentos distintos de
revises bibliogrficas e aps os objetivos do presente trabalho terem sido definidos em
detalhes e avaliados qualitativamente como relevantes.
A primeira etapa de reviso bibliogrfica foi realizada com foco principal no progama de melhorias Six Sigma e, secundariamente, no uso desse programa, assim como
de outros (Plan Do Check Act (PDCA), IDEAL e Capability Maturity Model Integration (CMMI)), por PME prestadoras de servios de desenvolvimento de software. A
proposta consistia na construo de um Modelo para Estabilizao de Processos de Desenvolvimento Software para Aplicao Prvia a Projetos de Melhorias Estatisticamente
Controladas. Durante as revises foi percebida uma ateno especial importncia da
escolha correta das caractersticas de interesse, nos vrios trabalhos revisados, nos quais
contraditoriamente, as caractersticas escolhidas, de acordo com a avaliao da autora
do presente trabalho, aparentavam-se pouco significativas, pois baseavam se no nmero
de defeitos. A necessidade de caractersticas de interesse significativas levou elaborao de uma proposta mais abrangente e a uma segunda etapa de reviso bibliogrfica,
com foco principal em CEP de desenvolvimento de software. A nova reviso forneceu
14
Captulo 1. Introduo
os subsdios necessrios para a consolidao da nova proposta, a qual culminou no

presente modelo.
O modelo foi definido a partir da evoluo de modelos de CEP genricos existentes, na direo de especializ-los para os processos de desenvolvimento de software.
Estavam previstos o projeto e desenvolvimento de nico modelo, porm, dois foram
elaborados devido s falhas de projeto no primeiro. Houve uma primeira definio,
o respectivo modelo definido e uma prova de conceito realizada, porm tal definio
resultou em um modelo complexo, pouco inteligvel e com aplicabilidade duvidosa. Foi
ento necessrio reprojet-lo, tratando os pontos falhos iniciais, assim como executar
uma nova prova de conceito. O novo modelo foi avaliado como satisfatrio aps ter
sido submetido a uma prova de conceito com dados reais e a uma avaliao qualitativa
de seu enunciado.
O passo seguinte, planejar e executar os estudos de caso, foi realizado e, em
paralelo, deu-se o incio da redao do presente documento. O planejamento consistiu
nas seguintes atividades e definies: (i) aplicar o modelo, inicialmente, em apenas
uma das organizaes; (ii) avaliar ferramentas disponveis de apoio ao CEP, selecionar
e adquirir uma para ser utilizada nos estudos de caso; (iii) definir um responsvel na
organizao para apoiar o planejamento do CEP e as coletas e validaes dos dados;
(iv) planejar a aplicao do CEP, ou seja, executar as atividades do Modelo CEP-S,
relativas ao planejamento do CEP, que so: seleo dos processos, identificao das
caractersticas de interesse, coleta e validao dos dados, construo dos grficos de
controle e estabilizao dos processos; (v) analisar os resultados.
A execuo dos estudos de caso transcorreu como planejada. A organizao escolhida para aplicao inicial de CEP foi o Laboratrio Synergia, devido aos dados
disponveis. O Synergia o Laboratrio de Engenharia de Software e Sistemas do
Departamento de Cincia da Computao da UFMG que oferece servios de desenvolvimento de sistemas, implantao de processos, consultoria em TI e treinamentos
diversos. Em seguida, vrias ferramentas disponveis no mercado, algumas prprias
para CEP, outras com foco em estatstica geral, foram avaliadas (EView, SAS, Statistica, Gretl, R e Minitab). Aps a avaliao optamos pelo uso do Minitab por ele
oferecer as funcionalidades requeridas pelo modelo CEP-S, por ter interface grfica de
fcil aprendizado, por ser bastante usado em universidades e empresas e por ter diferentes modalidades de licena, o que possibilitou a aquisio de uma adequada para
o desenvolvimento deste trabalho. Em seguida, as atividades planejadas para o CEP
foram realizadas, sendo algumas delas junto ao responsvel na organizao pelo apoio
ao estudo de caso, como: a seleo dos processos, a coleta e avaliao dos dados e
parte da anlise dos resultados. Essa anlise foi executada em duas etapas: a primeira
1.5. Organizao deste documento
15
gerou um resultado intermedirio, com erros nas interpretaes de agrupamentos de

alguns dados. Uma nova anlise foi necessria, cujos resultados gerados se mostraram
consistentes e satisfatrios, os quais esto registrados no presente trabalho. Todas as
caractersticas de interesse possveis de serem controladas, de acordo com os dados
disponveis, foram utilizadas no estudo de caso e a estabilizao dos processos foi executada atravs da simulao de excluso dos pontos fora-de-controle e no de fato, no
ambiente de produo do Laboratrio Synergia.
A execuo do estudo de caso resultou tanto na evoluo e validao do modelo
quanto na melhoria da organizao da redao do presente trabalho. Por fim, com os
objetivos do modelo tendo sido alcanados, a concluso do trabalho foi elaborada.
1.5
Organizao deste documento
A primeira atividade que culminou na construo do modelo CEP-S consistiu em uma

investigao sobre o estado da arte da aplicao de CEP em desenvolvimento de software. Os resultados dessa investigao, assim como os principais conceitos envolvidos,
encontram-se descritos no Captulo 2. Em seguida, foi realizado um estudo sobre
os conceitos relacionados a CEP, como, aspectos tericos, ferramentas e diretrizes. O
resultado desse estudo est descrito no Captulo 3 e foi utilizado como fundamentao
para todo restante do trabalho.
Uma vez realizados os estudos para fundamentao terica, iniciou-se a elaborao
do modelo CEP-S propriamente dito. A descrio detalhada desse modelo encontra-se
no Captulo 4. Esse Captulo apresenta os processos selecionados para o CEP e uma
viso de como tais processos so organizados para a execuo das medies, juntamente
com os conceitos envolvidos e as personalizaes necessrias para a adaptao do modelo CEP-S aos processos das organizaes. Em seguida, as caractersticas de interesse
so identificadas, juntamente com as convenes e os procedimentos que descrevem a
forma pela qual tais atributos devem ser mensurados. Os passos para o planejamento e
execuo das medies so descritos, seguidos pela definio de um mecanismo para a
organizao escolher os grficos de controle de acordo com os dados que foram coletados, definir os parmetros de controle e os testes de estabilidade. Por fim, as atividades
para estabilizao dos processos so apresentadas.
O Captulo 5 apresenta o estudo de caso, onde o modelo CEP-S aplicado
aos processos de uma organizao real, o Laboratrio Synergia, de porte mdio, com a
inteno de validar as prticas propostas, via a comparao dos processos antes e depois
do estudo de caso. Uma anlise da aplicabilidade do modelo CEP-S apresentada nesse
16
Captulo 1. Introduo
Captulo. Essa anlise examina a proposta do modelo versus os resultados alcanados

no estudo de caso, os pontos fortes e fracos identificados durante a aplicao desse
estudo de caso, as estimativas de custo e prazo para executar uma instncia do CEP-S
e os possveis riscos envolvidos.
Finalmente, o Captulo 6 apresenta as contribuies e as concluses observadas,
assim como propostas de trabalhos futuros.
O documento vem acompanhado ainda de trs apndices, com informaes complementares. O Apndice A apresenta os conceitos e as frmulas estatsticas, que
complementam os conceitos apresentados, principalmente, no Captulo 3 e usados para
construo e anlise dos grficos de controle, no Captulo 4. Os Apndices B e C
apresentam uma caracterizao do software e uma anlise do cenrio atual do mercado
de software nacional, respectivamente, com o objetivo de contextualizar as diferenas
entre o cenrio de PME que prestam servios de desenvolvimento de software (foco do
modelo) dos demais cenrios.
Captulo 2
Reviso bibliogrfica
Este Captulo apresenta as revises bibliogrficas que apoiaram a formulao do presente trabalho. Como introduo, citamos um artigo que discute o estado da arte e
futuras pesquisas em CEP e em melhoria de processos de desenvolvimento de software
(SPI - Software Process Improvement). Em seguida, a Seo 2.1 apresenta, como referncia, os principais conceitos da rea de pesquisa. A Seo 2.2 relata as revises
realizadas, as quais ocorreram em dois momentos distintos. No primeiro, o foco dos
estudos foram as atividades de estabilizao de processos para aplicao prvia de Six
Sigma para melhoria de processos de software. No segundo momento, com a evoluo
da proposta, o foco dos estudos foi a aplicao de CEP em desenvolvimento de software, o que conduziu ao presente trabalho. Por fim, a Seo 2.3, apresenta a reviso
sobre as caractersticas de PME desenvolvedoras de software sob encomenda.
Serrano, em Serrano [2004], relata que a melhoria de processos de software
uma rea relativamente nova e que muitas das ideias foram trazidas e adaptadas de
teorias e metodologias da aplicao da qualidade em sistemas de manufatura, que foram
desenvolvidas nas ltimas dcadas por Deming [1986], Crosby [1979], Shewhart [1931] e
Juran [1998]. Cita ainda que cada modelo e metodologia desenvolvidos e em pesquisas
tm sido apoiados por diferentes grupos de pessoas, o que os tornam difceis de serem
estudados, adaptados, aplicados, entendidos, ensinados e desenvolvidos. Complementa
que mudanas s sero percebidas eficiente e efetivamente se esses conceitos e princpios
(qualidade, CEP, SPI) forem introduzidos no corpo de conhecimento dos programas
de Engenharia de Software e cincia da computao das universidades.
17
18
Captulo 2. Reviso bibliogrfica
2.1
Principais conceitos
Esta Seo apresenta os principais conceitos da rea de pesquisa, desde os conceitos

fundamentais, como qualidade, estatstica e CEP, at os modelos e ferramentas, como
SixSigma, PDCA, IDEAL e o CMMI,que foram referenciados no presente trabalho.
Qualidade: h vrias definies de qualidade, algumas mais genricas, como: o
grau negativo ou positivo de excelncia 1 ou o grau com que um conjunto de
caractersticas inerentes atende s necessidades 2 . Outras especficas, como:
a capacidade de um produto de software satisfazer as necessidades explcitas e
implcitas quando utilizados sob condies especificadas 3 . Em ambos os nveis de
definio, a qualidade tratada como algo relacionado s caractersticas desejveis
em um produto ou servio.
Essas definies tambm evoluram ao longo do tempo. Durante a Revoluo Industrial, sculo XVIII, com as mudanas tecnolgicas e nos processos produtivos,
o foco da qualidade e da produtividade era o trabalhador, ou seja, poderia ser
usado o seguinte lema: se voc quer que o barco navegue mais rpido, chicoteie
mais duramente os remadores. No sculo XX, com o Gerenciamento Cientfico,
o foco passou a ser nos processos, em COMO fazer e no mais no O QUE
fazer, ou seja, se voc quer que o barco navegue mais rpido examine e analise os
elementos que fazem o barco navegar e determine o melhor modo de aceler-lo.
Podemos citar a influncia de Frederik Winslow Taylor, considerado o pai da
administrao cientfica, que introduziu os princpios do planejamento, controle
e execuo e tinha como objetivo acelerar o processo produtivo com qualidade.
Outras influncias complementaram a evoluo dos conceitos, como a abordagem de Shewhart, onde qualidade inversamente proporcional variabilidade,
de William Edwards Deming, onde inspeo torna-se o principal mtodo para
atingir a conformidade com os requisitos e de Joseph Juran, que expandiu as
estratgias de qualidade para todas as funes de uma organizao e suas diretrizes eram para atender as necessidades dos usurios, atravs da adequao para
uso.
Em 1924 Shewart introduz o conceito de grfico de controle, considerado o incio
do controle estatstico da qualidade, e marca o incio dos movimentos de melhorias
substanciais da qualidade, custo e produtividade nas organizaes. Dedicamos
1
de acordo com o dicionrio Houaiss;

de acordo com PMBOK e a ISO9000:20000;
3
de acordo com a ABNT NBR ISO/IEC 25000 - Engenharia de Software - Requisitos e avaliao
da qualidade de produtos de software - Guia do SQuaRE.
2
2.1. Principais conceitos
19
todo o Captulo 3 para apresentar os conceitos relativos estatstica e ao Controle Estatstico de Processo (CEP).
Processo: Um processo pode ser definido como uma organizao lgica de pessoas,
materiais, energia, equipamento e procedimentos em atividades designadas para
produzir um especfico resultado, Gabriel A. Pall 1987.
Atividade: Um componente de trabalho realizado durante o andamento de um projeto, PMBOK 2004.
RUP - Rational Unified Process: um processo proprietrio de Engenharia de
Software criado pela Rational Software Corporation, hoje pertence IBM. Fornece tcnicas e boas prticas de processos para o desenvolvimento de software,
amplamente conhecido na indstria de software. O RUP usa a abordagem da
orientao a objetos em sua concepo e projetado e documentado utilizando a
notao Unified Modeling Language (UML) para ilustrar os processos em ao.
considerado um processo pesado por sua proposta consistir em muitos artefatos e atividades, porm, amplamente customizvel para projetos de qualquer
escala. Foi utilizado no presente trabalho para estabelecer a viso dos processos
de desenvolvimento de software.
A figura 2.1 ilustra a proposta do RUP. O grfico conhecido como Grfico das
Baleias, pelo fato de seu formato assemelhar-se ao de baleias. Uma dimenso relacionada ao tempo, onde o produto desenvolvido em fases. Fase um intervalo
de tempo entre dois marcos definidos. So quatro as fases apresentadas: Concepo, Elaborao, Construo e Transio. Cada uma possui divises menores, as
iteraes, que permitem pontos de controle (marcos) intermedirios. A segunda
dimenso apresenta as nove disciplinas, as quais so: Modelagem de Negcios,
Requisitos, Anlise e Projeto, Implementao, Teste, Implantao, Configurao
e Gerenciamento de Mudana, Gerenciamento de Projeto e Ambiente. Uma disciplina, segundo o RUP uma coleo de atividades relacionadas a uma rea de
interesse principal.
PDCA: abordagem bastante conhecida para melhoria contnua da qualidade, descrita
por Walter Shewhart no livro Statistical Method from the Viewpoin of Quality
Control, publicado em 1939, tambm conhecida como ciclo de Deming, Brocka
& Brocka [1995], devido a Deming ter sido um forte difusor dessa prtica. As
etapas do PDCA constituem em planejamento, execuo, verificao e ao:
20
Figura 2.1: Grfico das Baleias - RUP Rational Unified Process
Planejar (plan): escolha um processo que sugira um bom retorno. O Princpio de Pareto (80/20) pode ser usado como ferramenta de apoio escolha.
Planeje uma mudana que ter benefcios efetivos, estabelea os objetivos
sobre os itens de controle e o caminho para atingi-los. Por fim, defina os
mtodos a serem usados para executar o planejamento.
Executar (do): aplique as mudanas planejadas. Essa uma etapa importante,
ao realiz-la deve-se ter cuidado para que a confiana no modelo no seja
perdida. Atue com treinamento e inicie os novos processos. Colete e analise
os dados da execuo.
Verificar (check): observe e analise objetivamente os efeitos das mudanas, ou
seja, verifique: se o trabalho est sendo realizado de acordo com o planejado
(padro) e se os itens de controle correspondem aos objetivos.
Agir (act): se os resultados foram os esperados, institucionalize a mudana.
Caso contrrio, reinicie o planejamento, revisando outro processo. Se o resultado estiver fora do padro, investigue as causas e tome aes preventivas
e corretivas.
A figura 2.2 ilustra um exemplo do ciclo do PDCA
IDEAL: um modelo para melhoria de processo que pode ser usado como roteiro
para iniciar, planejar e executar aes de melhorias em processo de desenvolvimento de software. O guia foi publicado em 1996 pela SEI, Software Engineering
21
Figura 2.2: Ilustrao de um Ciclo do PDCA
Institute, da Universidade Carnegie Mellon, Pittsburg, Pennsylvania, SEI [1996].

Ele consiste em cinco fases:
Iniciao (initiating): definio das bases para o esforo bem sucedido das
melhorias;
Diagnstico (diagnosing): determinao de onde o processo est relativo a
onde desejado que ele esteja;
Estabelecimento (establishing): planejamento dos detalhes de como alcanar
o desejado;
Ao (acting): realizao do trabalho de acordo com o planejado;
Aprendizado (learning): aprendizado com as experincias de melhorias para
adaptar futuramente novas tecnologias.
A figura 2.3, extrada do referido guia, ilustra o Modelo IDEAL
Podemos perceber que o Modelo IDEAL uma adaptao do PDCA para o
desenvolvimento de software. Ele segue o mesmo princpio de ciclos de melhorias
e retroalimentao das aes, onde lies aprendidas de uma execuo constituem
uma entrada importante para a realizao do prximo ciclo de execuo.
CMMI: um modelo de referncia que contm prticas necessrias maturidade dos
processos de desenvolvimento de software. Entende-se por capacidade a habilidade do processo alcanar o resultado desejado. Assim com o IDEAL, o CMMI
tambm foi desenvolvido pela SEI, Chrissis et al. [2005]. A verso atual do CMMI
(verso 1.2) apresenta trs modelos:
CMMI for Development (CMMI-DEV) para os processos de desenvolvimento
de produtos e servios.
CMMI for Acquisition (CMMI-ACQ) para os processos de aquisio e terceirizao de bens e servios.
22
Figura 2.3: Ilustrao do Modelo IDEAL
CMMI for Services (CMMI-SVC) para os processos de empresas prestadoras

de servios.
O CMMI-DEV prope cinco nveis que so: (nvel 1) inicial; (nvel 2) gerenciado; (nvel 3) definido; (nvel 4) quantitativamente gerenciado; (nvel 5) em
otimizao.
Esse um modelo que prope um conjunto de requisitos que precisam ser atendidos para uma organizao amadurecer seus processos, mas no apresenta como
fazer para atender tais requisitos. Vrias ferramentas so usadas em complemento a esse modelo, que apoiam o como fazer, por exemplo: o guia PMBOK,
o RUP, o SixSigma, entre outras. Para os nveis mais avanados, onde a viso
quantitativa esperada, o CEP uma poderosa ferramenta de apoio.
MPS.BR: um modelo de qualidade para processo de desenvolvimento de software
(Modelo MPS) voltado para a realidade do mercado de pequenas e mdias empresas de software do Brasil. Ele baseado nas normas ISO/IEC 12207 e ISO/IEC
15504 e na realidade do mercado brasileiro, bem como compatvel com o CMMI.
Atualmente, pode tambm ser entendido como um programa do governo para promoo da melhoria da qualidade dos processos de desenvolvimento de software,
23
onde o governo subsidia os custos das avaliaes e das consultorias para as aes
de melhorias em PME. Os nveis definidos no modelo so sete: A - Em Otimizao; B - Gerenciado quantitativamente; C - Definido; D - Largamente Definido;
E - Parcialmente Definido; F - Gerenciado; G - Parcialmente Gerenciado.
Six Sigma (6): o termo Six Sigma pode ser entendido como um programa, uma
metodologia ou uma mensurao. Como programa ele consiste em um direcionamento organizacional estratgico de mudanas para aumentar a satisfao
do cliente, reduzir erros, aumentar a eficincia da produo e consequentemente
melhorar os lucros. Como metodologia, um conjunto de prticas aplicadas sistematicamente para eliminar defeitos. Como mensurao, o smbolo (sigma)
usado em estatstica para representar o desvio padro, onde 6 3,4 defeitos por
milho de oportunidades (DPMO) ou 99,9997% das amostras livres de defeitos.
A metodologia e o programa Six Sigma foram inicialmente desenvolvidos pela
Motorola, em meados dos anos 80 e, de acordo com Rose [2005], em 10 anos de
programa economizou $414 bilhes, aumentou 5 vezes suas vendas e 20% seus lucros. Eles contemplam caractersticas de outros modelos de qualidade, tais como:
controle da qualidade e o uso sistemtico de ferramentas estatsticas, a anlise
e soluo de problemas, os ciclos de melhoria como o PDCA, o alinhamento da
qualidade com as estratgias da organizao, e a nfase na relao custo-benefcio
dos projetos de melhorias. Tem duas metodologias chave - DMAIC e DFSS.
DMAIC usado para melhorar um processo de negcio existente. Consiste nos
estgios seguintes:
Definir (define): formalizar os objetivos de melhoria do processo que sejam
consistentes com as demandas do cliente e a estratgia da empresa;
Medir (measure): definir as medies do processo atual para comparao futura, medir e coletar os dados necessrios;
Analisar (analyze): verificar o relacionamento e causalidade dos fatores;
Melhorar (improve): melhorar e otimizar o processo;
Controlar (control): controlar a aplicao do processo piloto, realizar a transio para a produo e medir continuamente o processo para garantir que
as variaes sejam corrigidas antes de se transformarem em defeitos.
A figura 2.4 ilustra o Ciclo DMAIC.
DFSS o acrnimo para Design for Six Sigma (projeto para Six Sigma). usado
para projetar ou reprojetar um novo produto ou servio de forma a se obter um
24
Figura 2.4: Ilustrao do Ciclo DMAIC
desempenho previsvel, maduro e livre de defeitos. As fases ou passos, ao contrrio

de DEMAIC, no so universais. Como exemplos de DFSS conhecidos citamos
o DMADV (definir, medir, analisar, projetar e verificar) e o IDOV (identificar,
projetar, otimizar e validar).
SIPOC: o acrnimo para fornecedores (suppliers), entradas (inputs), processos (processes), sadas (outputs) e consumidor (customers). um diagrama para prover
um nvel abstrato de entendimento dos problemas e processos da organizao,
Tinnirello [2002], e apoiar a identificao dos elementos relevantes de um projeto
de melhoria para a aplicao de Six Sigma, Kloppenborg & Petrick [2002]. particularmente til quando os elementos entrada, sada, fornecedores ou processos
no forem conhecidos. A figura 2.5 ilustra um exemplo de Diagrama SIPOC.
Lean: no primeiro momento, na busca por maior competitividade, a organizao enfoca em entregas no prazo, estimativas de custos confiveis e produtos aderentes
necessidade dos clientes. No segundo momento, a primazia no mercado pode ser
estabelecida pela capacidade de realizar entregas mais rpidas, Arajo & Meira
[2004], o que pode ser resultado de processos mais enxutos, precisos e modelos
de gesto mais avanada. Lean o conceito que visa a promoo de melhoria
simultnea de custo, qualidade, velocidade e agilidade nos processos. usado em
conjunto com Six Sigma e com os seguintes princpios: entenda como o valor
percebido pelo cliente; elimine desperdcios em toda a cadeia de valor; estabelea
um fluxo contnuo do incio ao fim; faa conforme demanda do cliente, no gere
estoque e busque a perfeio atravs de melhoria contnua.
A natureza de servios: o desenvolvimento de software sob encomenda, ou outsour-
25
Figura 2.5: Exemplo de um Diagrama SIPOC
cing, um modelo de negcio de terceirizao onde ocorre a transferncia de

uma parte significativa da responsabilidade do gerenciamento dos servios para
o fornecedor. Por esse modelo de negcio ser bastante semelhante ao modelo
de prestao de servios, as caractersticas de servios foram estudadas, com o
objetivo de identificar questes importantes para a definio de caractersticas
de interesse significativas para CEP de desenvolvimento de software. Segundo
Fitzsimmons, Fitzsimmons & Fitzsimmons [2004], h em servios:
Participao do cliente nos processos de servio: a presena do cliente
como um participante no processo de servio requer ateno ao ambiente
fsico, onde ocorre o processo, o que no acontece no caso das operaes
de manufatura tradicional. Cuidados especiais com a decorao interior,
moblia, leiaute, nvel de rudo e at cores pode influenciar a percepo dos
servios pelo cliente.
Simultaneidade: os servios so criados e consumidos simultaneamente e, portanto, no podem ser estocados, o que constitui uma caracterstica fundamental para a administrao de servios. Essa impossibilidade de estocar
servios impede o uso da estratgia da manufatura tradicional, de confiar
nos estoques como um amortecedor de absoro de flutuao na demanda.
O fato dos servios serem simultneos elimina muitas oportunidades de interveno no controle de qualidade. Um produto pode ser inspecionado
26
antes de ser entregue, um servio precisa confiar em outros indicadores para

assegurar a qualidade.
Mercadoria perecvel: os servios podem ser considerados mercadoria perecvel.
Intangibilidade: servios so ideias e conceitos, produtos so objetos.
Heterogeneidade: a combinao da natureza intangvel dos servios e do cliente
como participante do sistema de prestao de servios resulta na variao
de servios de cliente para cliente.
Um servio, de acordo com James Fitzsimmons, uma experincia perecvel,
intangvel, desenvolvida para um consumidor que desempenha o papel de coprodutor. Medir a qualidade de servios um desafio, pois a satisfao determinada por muitos fatores intangveis, ao contrrio de produtos com caractersticas
fsicas que podem ser objetivamente mensuradas.
A figura 2.6, extrada de Fitzsimmons & Fitzsimmons [2004], apresenta as etapas do desenvolvimento da qualidade. A Inspeo mostrada como primeira
atividade, pois normalmente por onde as organizaes comeam a lidar com as
questes de qualidade. Como ltimo degrau, apresentado o desdobramento da
funo da qualidade.
QFD Quality Function Deployment: desdobramento da funo qualidade o mtodo usado para transformar as demandas (necessidades) dos usurios em projetos
de qualidade. O QFD desdobra os requisitos expostos pelos clientes, atravs
do uso de matrizes, transformando-os em especificao tcnica do projeto.
uma tcnica bastante difundida no mercado, porm, complexa de ser utilizada.
Foi desenvolvida por Dr. Yoji Akao, apud Cheng & Melo [2007]. A figura 2.7,
extrada de Faria [2009], apresenta uma viso de uma matriz de desdobramento
da funo qualidade.
Voz do Cliente (VOC): um termo usado para descrever as expectativas, preferncias e averses dos clientes quanto a um produto ou servio.
Modelo Kano: um modelo para categorizao da satisfao dos consumidores. O
modelo prope a classificao dos atributos do produto baseado em como eles so
percebidos, consciente ou inconscientemente, pelos consumidores. Essa classificao usada para guiar decises de projetos e melhorias nos produtos indicando
27
Figura 2.6: Escada Qualidade em Servios
quando o bom suficiente ou quando mais melhor. Tal modelo foi desenvolvido pelo professor Noriaki Kano Tontini [2003]; Dodson [2008]; Apostila [2002]
apud Kano [1984].
As categorias propostas so:
28
Figura 2.7: Viso de uma matriz Desdobramento da Funo da Qualidade
Atributos bsicos (obrigatrios): so obrigatrios e esperados. Sua existncia ou melhoria no implica em satisfao extra nem diferencial competitivo.
Sua inexistncia resulta em grande insatisfao. Podem ser no verbalizados.
Atributos unidimensionais: os requisitos so solicitados pelos consumidores
e quanto maior o nvel de atendimento maior ser a satisfao dos consumidores.
Atributos atrativos: os consumidores no tm expectativas sobre esses requisitos e so surpreendidos ao t-los. Porm, caso no haja tais requisitos
no h descontentamento por parte dos consumidores.
Atributos neutros: no trazem nem satisfao nem insatisfao. Podem no
ser conhecidos ou raramente utilizados pelos usurios.
Atributos reversos: so aqueles cuja presena traz insatisfao.
Passos para aplicao do mtodo:
29
1. Elaborar e aplicar um questionrio aos consumidores. O questionrio deve

conter, para cada atributo, duas questes: (i) qual o seu sentimento se
o atributo x estiver presente no produto; (ii) qual o seu sentimento se o
atributo x no estiver presente no produto. Ou seja, uma questo funcional e
uma disfuncional sobre o atributo. As opes de respostas podem ser: muito
satisfeito, satisfeito, indiferente, no atrapalha e insatisfeito. Cada questo
deve tratar de um nico atributo que deve ser claramente definido. Deve-se
evitar questes negativas, ou seja, que utilizem o termo no e questes
disfuncionais seguidas das funcionais (para evitar respostas automticas).
Deve-se definir o pblico de modo que seja possvel estratificar as respostas e
estudar a classificao dos atributos entre diferentes grupos de consumidores.
Um consumidor que usa o produto pode classific-lo como unidimensional
enquanto um novo consumidor o classificaria como bsico.
2. Gerar uma planilha a partir da tabela 2.8 de classificao bidirecional para
categorizar cada atributo por entrevistado se atrativo, unidimensional, obrigatrio, neutro ou reverso.
Figura 2.8: Tabela Classificao Modelo Kano
3. Computar o percentual de cada categoria por atributo. As informaes

podem ser exibidas em quadrante.
Algumas ferramentas apoiam o uso do modelo Kano: elicitao das entradas dos
consumidores, matriz de prioridades, QFD e anlise de valor. mais comum que
os requisitos lineares e inesperados sejam usados como entrada na aplicao de
QFD.
BSC - Balanced Scorecard: segundo Kaplan, Kaplan & Norton [1997], um carto de resultados equilibrado, uma ferramenta gerencial que permite equilibrar,
30
monitorar e controlar o desempenho empresarial a partir da definio de medidas

de desempenho em quatro perspectivas: a financeira, a do cliente, a dos processos
internos e a do aprendizado e crescimento.
2.2
CEP e a melhoria de processos de

desenvolvimento de software
2.2.1
O primeiro momento de reviso
A proposta inicial do presente trabalho consistiu na construo de um modelo para estabilizao de processos de desenvolvimento de software para aplicao prvia a projetos
de melhorias estatisticamente controlados. Essa proposta foi motivada pelas dificuldades em estabilizar os processos de desenvolvimento de software, que a autora do
presente trabalho vivenciou, em um ambiente real. A reviso bibliogrfica para essa
proposta abordou modelos e ferramentas que apoiam a gerncia quantitativa de melhoria e a otimizao de processos. Dentre esses modelos e ferramentas foram estudados o
PDCA, o IDEAL, o SixSigma e o CMMI. Os artigos mais relevantes da aplicao dos
modelos Six Sigma e CMMI em estudos de caso so citados a seguir.
Zhao, em Zhao et al. [2008a], faz uma descrio breve de alguns modelos de
medio e de modelos de melhorias para processos de desenvolvimento de software.
Prope o uso de Six Sigma combinado ao modelo de gerenciamento de processo de
software e apresenta um estudo de caso da aplicao dessa proposta. A abordagem
visualiza dois aspectos: o projeto conceitual do produto de software atravs do modelo
IDOV e a otimizao dos demais processos atravs do DMAIC. Foi definido o escopo
do projeto utilizando SIPOC em seguida definido o seu objetivo a partir do Modelo
Kano. O autor conclui que Six Sigma um modelo factvel de ser aplicado em processos
de desenvolvimento de software. Ainda o mesmo autor, no artigo Zhao et al. [2008b],
prope o uso de SixSigma combinado ao CMMI para alcanar melhorias de processo em
desenvolvimento de software. Apresenta um estudo de caso da aplicao desses modelos
combinados e conclui que eles so complementares, centrados no cliente, na reduo da
variao e na otimizao do desenvolvimento. Outros artigos que apresentam propostas
semelhantes so: Siviy et al. [2005]; Murugappan & Keeni [2000]; Kim et al. [2008];
Gonalves et al. [2008]; Pan et al. [2007].
Redzic, em Redzic & Baik [2006], apresenta a aplicao de DMAIC para melhoria
da qualidade de software. O objetivo foi identificar e estabelecer mudanas tticas que
incrementem a qualidade do software. Um plano de medio foi sistematicamente
2.2. CEP e a melhoria de processos de desenvolvimento de software31
desenvolvido e para analisar quantitativamente as melhorias providas pelas mudanas,

a capacidade dos processos da organizao foi calculada, uma linha de base foi gerada
e depois comparada com os resultados obtidos pela aplicao do DMAIC. A concluso
relata que o software um produto muito complexo e que Six Sigma pode ser aplicado
com sucesso para prover melhorias de qualidade em processos de desenvolvimento de
software.
Outra abordagem estudada foi a aplicao de Six Sigma para servios, visto a natureza de servio do desenvolvimento de software sob encomenda. George, em George
[2004], apresenta como a aplicao de Lean e Six Sigma podem reduzir os custos e a
complexidade e melhorar a qualidade dos servios. Ele cita vrios estudos de caso, enfatiza a importncia do comprometimento da alta gerncia para o sucesso de projetos de
melhorias de processos. Apresenta a abordagem do Lean para maximizar a velocidade
do processo, reduzir os desperdcios e a complexidade dos processos e a abordagem do
Six Sigma para reconhecer as oportunidades de eliminar defeitos do ponto de vista do
cliente, reduzir a variao e tomar decises baseadas em anlises quantitativas. Ainda
na abordagem de servios, Wood, em Wood [1994], apresenta um guia para evoluir os
mtodos aplicados em manufaturas para o contexto de servios, discute que a reduo
da variabilidade no deve ser o objetivo final do controle estatstico de processos e
que a terminologia grfico de nvel de qualidade seria mais apropriado que grfico de
controle.
Tinnirello, em Tinnirello [2002], discursa sobre o gerenciamento de projetos de
software, o gerenciamento da qualidade e das relaes de negcio para software. Para
o gerenciamento da qualidade ele apresenta exemplos de uso dos modelos ISO 9000 e
CMM e como o Six Sigma pode apoiar organizaes no desenvolvimento de software.
O autor enfatiza as vantagens do uso do Six Sigma mesmo quando nem todos os seus
conceitos so utilizados pela organizao.
2.2.2
O segundo momento de reviso
Durante a primeira reviso foi percebida, nos vrios trabalhos revisados, uma ateno
especial dada escolha correta de mtricas para CEP que refletissem os objetivos da
organizao ou a voz do cliente. A necessidade de caractersticas de interesse significativas levou elaborao de uma proposta mais abrangente, para a construo de um
modelo que abordasse no somente a estabilizao dos processos mas tambm demais
questes de CEP, como a definio das caracterstica de interesse e a escolha dos processos alvo de controle. Trs livros formam a base das referncias sobre os princpios
e mtodos estatsticos, tradicionais e modernos, utilizados nesse segundo momento de
32
reviso, que so: Florac & Carleton [1999]; Montgomery [2004]; Costa et al. [2008].
Alm desses, alguns trabalhos publicados em congressos e peridicos de qualidade reconhecida, que apresentam o estado da arte da aplicao de CEP em processos de
desenvolvimento de software complementam as referncias, que so: Komuro [2006];
Jalote [2003]; Jalote & Saxena [2002]; Lantzy [1992]; Caivano [2005]; Baldassare et al.
[2005]; Cobb & Mills [1990]; Weller [2000]; Montoni et al. [2007]; Sargut & Demirrs
[2006].
Florac, alm de apresentar alguns conceitos e mtodos estatsticos, tambm discute como as caractersticas de qualidade dos processos e produtos de softwares podem
ser quantificadas, esboadas graficamente e analisadas para que as atividades de desenvolvimento de software sejam previsveis, controladas e guiadas para alcanar os
objetivos estratgicos e tcnicos. Essa referncia foi elaborada com apoio da SEI e
tem o objetivo de encorajar e guiar organizaes desenvolvedoras de software a usarem
medidas para gerenciar quantitativamente os produtos e projetos de software.
Baldassare, em Baldassarre et al. [2007], apresenta uma reviso sistemtica da
aplicao de CEP, cuja motivao foi entender quo bem sucedida a aplicao de CEP
est sendo realizada nos processos de produo de software. Como concluso, h relatos
das dificuldades de uso de CEP em processos de desenvolvimento de software devido
s amostragens com pequenas quantidades de dados, dados sem distribuio normal
usados indiscriminadamente, uso de grficos que demandam grupos de observaes
sendo usados com observaes individuais entre outras aes e situaes inadequadas.
Todos esses pontos foram tratados cuidadosamente pelo presente trabalho, na tentativa
de observar os modelos estatsticos.
Vrios dos trabalhos consultados que relatam a aplicao de CEP em software
se restringem ao controle estatstico de taxa de defeitos, revises e no-conformidades.
Apenas um deles, o trabalho de Sargut, prope outras caractersticas de interesse para
o controle estatstico, bastante similares proposta do presente trabalho. Sargut apresenta uma forte crtica aos artigos de CEP de desenvolvimento de software, justamente
pelo fato dos controles serem estritamente para densidade de defeitos e efetividade das
inspees e devido maioria deles no apresentarem detalhes suficientes do experimento, de modo que o mesmo pudesse ser reproduzido por outras organizaes. Vale
ressaltar que o artigo de Sargut foi revisado em 11/04/2010, quando o modelo CEP-S
j havia sido projetado e estava sendo validado por meio dos estudos de caso, ou seja,
a presente proposta no se baseou no artigo de Sargut. O acesso a ele, no entanto, foi
importante pois ele mostra a viabilidade do uso das caractersticas de interesse, as quais
so similares s propostas no modelo CEP-S. As duas propostas, o artigo de Sargut e
o presente trabalho, foram comparadas e os pontos de similaridades e de distines so
2.2. CEP e a melhoria de processos de desenvolvimento de software33
apresentados a seguir.
Pontos de Similaridade:
As caractersticas de interesse propostas enfocam no controle dos processos
e no no controle dos produtos. Esse ponto um diferencial, visto que o
desenvolvimento de software altamente dependente do fator humano (criatividade, produtividade, etc). A maioria dos artigos revisados durante a
reviso bibliogrfica tratam apenas a taxa de defeitos ou de revises, cujo
foco o controle do produto. Logo, estabelecer o foco do controle nos processos necessrio e mais aderente ao contexto de desenvolvimento software;
Tratam com detalhes os grficos adequados para cada situao. A maioria
dos artigos revisados no aborda tais detalhes;
Definem o uso de apenas um teste de estabilidade, o qual consiste na identificao de um ponto fora dos limites de controle;
Prope a aplicao de CEP para empresas ainda em estgios iniciais de
maturidade de seus processos;
Prope a estratificao dos defeitos por tipo de ocorrncia;
Pontos de Distino: no presente trabalho
A seleo das caractersticas de interesse realizada a partir de seu alinhamento com os objetivos estratgicos;
As caractersticas de interesse so definidas por processo, por fase do ciclo
de vida (produo e ps-produo) e por um agrupador (mdulo do sistema
ou caso de uso ou algum outro a ser escolhido pela organizao). Isso reduz
a restrio de quantidade de dados para o controle, alm de favorecer o
controle por processo e por fases;
Os grficos de controle propostos podem monitorar pequenos desvios. Sargut somente cita o problema de falta de ferramenta para monitoramento de
pequenos desvios, mas no apresenta uma proposta de soluo.
A viso dos processos a serem controlados um modelo flexvel, possvel
de ser adaptado a vrios tipos de organizaes, devido s personalizaes
e consideraes apresentadas para tal. Sargut relata o modelo usado e no
trata sua personalizao de modo a permitir o uso por outras organizaes;
A estratificao dos defeitos mais robusta que a apresentada no artigo de
Sargut;
34
Por fim, um ltimo item avaliado foi a definio dos parmetros de controle. Jalote, em Jalote & Saxena [2002], e Montgomery, em Montgomery [2004], apresentam
estudos para o planejamento otimizado dos grficos de controle e em especial, para a
definio dos limites de controle, visando os aspectos econmicos, como: o custo da
amostragem, as perdas pela fabricao de produtos defeituosos, os custos de investigao de alarmes falsos. Jalote define um modelo para o clculo dos limites de controle
em funo da otimizao das variveis: custo de alarmes falsos (erro tipo I), custo de
falhas no detectadas (erro tipo II) e custo de reparar uma falha.
2.3
Caracterizao das PME desenvolvedoras de

software
O modelo CEP-S foi proposto visando apoiar PME prestadoras de servios de desenvolvimento de software (outsourcing) vertical sob encomenda. As PME de software
representam a maioria das empresas de software nacionais, so fortemente impactadas
pela dificuldade de estimativas, visto o grau de subjetividade das medidas de software
e pela produo de software sob encomenda ser um produto nico em cada produo.
Essas caractersticas motivaram a construo do modelo CEP-S. Este captulo apresenta a caracterizao dessas empresas de forma mais detalhada, quanto ao modelo de
negcio, forma de comercializao e ao mercado alvo. Apresenta tambm os desafios
de mercado destas empresas.
Quanto ao modelo de negcio, a prestao de servios de desenvolvimento de software a terceirizao do desenvolvimento de software ou outros servios, onde ocorre
a transferncia de uma parte significativa da responsabilidade pelo gerenciamento do
servio para o provedor do servio. Esse pode ser convencional, que a terceirizao
de uma atividade na rea de TI, ou pode ser BPO (business process outsourcing), que
o fornecedor ser responsvel pelo processo ou funo de negcio do cliente. Quanto
forma de comercializao, o software sob encomenda desenvolvido para atendimento
s necessidades exclusivas de um usurio. A relao da empresa desenvolvedora e do
usurio intensa. E, quanto ao mercado alvo, o software vertical um software de
uso especfico, para um determinado processo de negcio. Para mais detalhes sobre a
caracterizao do software, vide apndice B-Caracterizao do software.
As PME empresas atuam em nichos atrativos do mercado, onde grandes empresas
no conseguem atuar, Freire [2002]. Porm, estas empresas enfrentam desafios como:
O mercado de software impe fortes barreiras ao crescimento, de modo que gran-
2.3. Caracterizao das PME desenvolvedoras de software
35
des empresas dominam os principais mercados e, ao mesmo tempo, o mercado

no impe barreiras entrada de novos concorrentes, visto o custo de entrada
nesse mercado ser relativamente baixo;
O modelo de comercializao de software sob encomenda tem se tornado uma
commodity, vende quem tem o menor preo;
As empresas enfrentam dificuldades para avaliar o retorno de investimentos em
qualidade devido s caractersticas no funcionais do software (usabilidade, robustez, desempenho, reusabilidade, corretude, adequao), dificuldades para integrar estratgia no dia-a-dia operacional e dificuldades em realizar estimativas
de custo e prazo confiveis.
Os custos do desenvolvimento do software esto concentrados na produo da
primeira unidade, custos de criao, Pressman [1997]. Esses custos so altos e caracterizam o cenrio de empresas de outsourcing de software vertical sob encomenda.
Os custos de reproduo e distribuio, custos marginais, so mnimos, praticamente
desprezveis, visto que o custo da reproduo (cpia) zero e o custo de distribuio
insignificante em relao ao custo de produo. Esses custos caracterizam o cenrio
das empresas desenvolvedoras de software como produto. Os custos de criao altos,
sem economia de escala, e a intangibilidade so alguns dos fatores que diferenciam negativamente a competitividade das empresas que prestam servios de desenvolvimento
de software das empresas que desenvolvem software como produto.
A venda de servios de software depende da reputao da empresa fornecedora,
da existncia de um relacionamento de confiana mtua entre as partes vendedor e
comprador, visto a caracterstica intangvel do software. Por um lado, esse fator favorece PME em atuaes locais mas, por outro lado, considerado uma das barreiras
mais significativas exportao devido inexistncia de uma estrutura de vendas e
suporte no exterior, prximo ao cliente, Pond [1993]. De acordo com Martins, Martins
[2004], considerando a intangibilidade dos servios de software, indispensvel dedicar
ateno capacitao em processos, com certificaes que sejam amplamente aceitas
e que facilitem as negociaes com os mercados potenciais.
E para finalizar esta caracterizao, olhamos para as causas mais significativas
de morte dessas empresas. Quase 30% das empresas nascentes, de qualquer segmento,
morrem antes de completarem um ano. Estudos apontam como causas a falta de foco
no cliente e o desperdcio. As empresas de software enfrentam, alm das causas citadas,
a alta taxa de re-trabalho. Estima-se que em empresas de baixa maturidade, at 45%
36
do esforo total relativo ao re-trabalho, o que causa impacto negativo no custo e

prazo, Garcia & Leite [2006].
Captulo 3
O controle estatstico de processo
(CEP)
Um fenmeno ser dito ser controlado quando, atravs do uso de experincias passadas, ns podemos
prever, pelo menos com limites, como ser a variao do fenmeno no futuro.
Walter A. Shewhart 1931
Este captulo apresenta os conceitos de controle estatstico de processos, as frmulas e conceitos dos grficos de controles usados no modelo CEP-S, a definio para
limites de controle, testes de estabilidade, testes de correlao e teste de normalidade
e para algumas ferramentas da qualidade que sero usadas para apoiar o controle estatstico, tais como o grfico de custo benefcio e o histograma.
Uma estatstica uma medida calculada para descrever uma caracterstica de
qualidade de uma amostra1 da populao, Levine et al. [2000], e apoiar a tomada de
deciso. a cincia de analisar dados e tirar concluses, levando em conta a variao
dos dados, Montgomery [2004]. A modelagem ou descrio desses dados pode ser feita
via distribuio de probabilidade2 . A distribuio de probabilidade de uma estatstica,
distribuio amostral, descrita pelos seus parmetros de controle que, em geral, so
desconhecidos, podem mudar ao longo do tempo e so estimados a partir de dados de
uma amostra. Exemplos de parmetros: mdia () e varincia ( 2 ).
O CEP uma ferramenta que usa a estatstica para gerenciar os processos e promover continuamente a melhoria de qualidade atravs da reduo da variabilidade dos
parmetros de controle. Alguma variabilidade inerente aos processos de produo,
no possvel elimin-la inteiramente, mas inteno do CEP reduzi-la. Segundo
1
Parte da populao selecionada para anlise.

Coleo de pares, [xi , p(xi )], onde xi so os possveis resultados para i=1,2,... e p(xi ) as probabilidades do resultado xi .
2
37
38
Captulo 3. O controle estatstico de processo (CEP)
Montgomery, Montgomery [2004], a qualidade inversamente proporcional variabilidade, ou seja, quanto menor a variabilidade maior a qualidade dos produtos e
processos.
A variao total de um processo pode ser expressa, segundo Florac, Florac &
Carleton [1999], por:
Variao Total =
Variao devido s causas aleatrias + Variao devido s causas atribuveis
A variao devido s causas aleatrias, tambm conhecidas como causas comuns,
inerente ao processo, devido s interaes de seus componentes (pessoas, equipamentos,
processos, mtodos, insumos) e so inevitveis. Os processos que tm apenas causas
aleatrias so processos estveis, onde h variaes randmicas, porm, essas ocorrem
dentro de um intervalo previsvel, uma variao conhecida. Resultados inesperados
so extremamente raros. Um processo previsvel um processo sob controle, Florac &
Carleton [1999]. A figura 3.1, obtida de Florac & Carleton [1999], ilustra a variao
devido s causas aleatrias, onde as amostras variam dentro dos limites conhecidos.
Figura 3.1: Variao controlada

A variao devido s causas atribuveis, tambm referenciada como causas especiais pelo PMBOK, PMI [2009], deve-se eventos que no fazem parte do processo.
Quando uma ou mais medidas no se mantm dentro dos limites de variao estimados, o processo tido como instvel, ou seja, no est sob controle e as causas devem
ser investigadas. Providncias para eliminar futuras ocorrncias devem ser tomadas.
A figura 3.2, obtida de Florac & Carleton [1999], ilustra a variao devido s causas
atribuveis, onde as amostras variam sem limites conhecidos.
As Sees seguintes apresentam os conceitos propostos para esse captulo, enfocando nos detalhes para a construo dos grficos de controle propostos para o modelo
3.1. Mtodos estatsticos
39
Figura 3.2: Variao no controlada
CEP-S. As ferramentas de qualidade histograma, grfico de Pareto e diagrama de

disperso, que apoiam a aplicao de CEP, so tambm apresentadas. As definies
descritas nas sees seguintes foram extradas de Costa et al. [2008]; Levine et al. [2000];
Meyer [1983]; Montgomery [2004].
3.1
Mtodos estatsticos
Estatstica um conjunto de tcnicas teis para tomada de deciso sobre um processo

ou populao, baseada na anlise da informao contida em uma amostra dessa populao. Os mtodos estatsticos desempenham um papel fundamental na melhoria de
qualidade. Dentre os mtodos citamos a Estatstica Descritiva e a Estatstica Inferencial.
A Estatstica Descritiva envolve a coleta, apresentao e caracterizao de
um conjunto de dados que descrevem apropriadamente as vrias caractersticas desse
conjunto. A Estatstica Inferencial torna possvel a estimativa de uma caracterstica
de uma populao ou a tomada de uma deciso referente populao com base somente
em resultados de amostras.
A Estatstica Inferencial o mtodo utilizado no presente trabalho, ele pode ser
realizado a partir de uma estimativa de parmetros (valores) da populao ou de testes
de hiptese, Cooper & Schindler [2001]. A Estimativa de Parmetros Populacional pode ser estimao pontual ou por intervalo. Na estimao pontual obtido
um valor numrico nico que esperamos estar relativamente prximo ao verdadeiro
valor e na estimao por intervalo construdo um intervalo que contm, com grau
de confiana conhecido, o verdadeiro valor do parmetro. Os Testes de Hiptese
so uma afirmao sobre os parmetros de uma distribuio de probabilidade, que
podem ser realizados atravs da Teoria da Amostragem ou o Mtodo Bayesiano. A
40
Teoria da Amostragem a abordagem clssica que representa uma viso objetiva

de probabilidade na qual se baseia a tomada de deciso a partir da anlise de dados
das amostragens disponveis. Uma hiptese estabelecida e ela aceita ou rejeitada,
com base na amostragem dos dados coletados. Esse o mtodo utilizado no presente
trabalho. O Mtodo Bayesiano usa dados das amostragens disponveis e informaes adicionais que consistem de estimativas de probabilidade subjetivas, declaradas
em termo de grau de crenas, onde tais informaes subjetivas so periodicamente
modificadas.
3.2
Viso geral dos grficos de controle
Grficos de controle so usados para monitorar a estabilidade dos processos, identificar necessidade de aes de melhoria para a reduo da variabilidade e estimar os
parmetros do processo ou do produto.
Os grficos de controle precisam ser planejados de forma a serem eficientes em
detectar confiavelmente condies de fora-de-controle. Esse planejamento envolve a definio dos limites de controle, o tamanho da amostra, a frequncia da amostragem e os
testes de estabilidade. Tais itens sero detalhados nas prximas sees. Um grfico de
controle indica apenas se o processo est ou no sob controle, ou seja, se existem apenas
causas aleatrias ou se h tambm causas atribuveis. Caso o grfico de controle aponte
a existncia de causas atribuveis, essas devem ser investigadas e o que deu origem a
elas deve ser eliminado do processo. Como exemplos de parmetros do processo ou do
produto estimados pelo grficos de controle podemos citar: a capacidade, a mdia (),
o desvio padro () ou a varincia ( 2 ), a frao de no-conformidades, entre outros.
Um grfico de controle contm uma linha central (LC) que representa o valor
mdio da caracterstica de qualidade, a linha superior que representa o Limite Superior
de Controle (LSC) e a linha inferior que representa o Limite Inferior de Controle (LIC).
Detalhamos, a seguir, o modelo geral para a construo de grficos de controle:
Seja w uma estatstica amostral que mede alguma caracterstica de qualidade de
interesse e suponha que a mdia de w seja w e o desvio padro w . Ento, a linha
central, o limite superior de controle e o limite inferior de controle so:
LSC = w + Lw
LC = w
LIC = w Lw
(3.1)
3.2. Viso geral dos grficos de controle
41
Onde L a distncia dos limites de controle linha central, expressa em unidades

de desvio padro.
A figura 3.3 apresenta um exemplo de grfico de controle com LC, LSC e LIC.
Figura 3.3: Parmetros de controle LC, LSC e LIC
Os parmetros e podem ser definidos de antemo, se seus valores alvo forem

conhecidos, ou, caso contrrio, podem ser estimados. Um exemplo de parmetros de
controle definidos previamente a quantidade de leite em um saquinho de 1 litro:
a mdia esperada = 1 litro, com um desvio de = 0, 02. No caso onde os
parmetros no so definidos previamente, a estimativa realizada a partir de dados
coletados durante um perodo em que necessariamente o processo esteja operando sob
controle, ou seja, isento de causas atribuveis. Portanto, para estimar os parmetros
de controle necessrio identificar e eliminar as causas atribuveis. Em um processo
sob controle, os pontos plotados em um grfico de controle tm um comportamento
aleatrio e praticamente todos esses pontos estaro entre os limites de controle LSC
e LIC. Em um processo fora-de-controle, os pontos plotados tm um comportamento
no aleatrio e alguns pontos estaro plotados fora dos limites de controle. H vrios
testes que podem ser usados para detectar a existncia de variao devido causas
atribuveis. O teste mais comumente usado a verificao da existncia de algum
ponto que tenha sido plotado fora dos limites LSC e LIC. Esse e outros testes sero
detalhados na seo 3.9 Testes para deteco de situaes fora-de-controle.
Os grficos de controle podem ser usados para variveis ou atributos. Variveis
so normalmente medies de fenmenos contnuos, como exemplos temos: volume,
voltagem, esforo despendido, anos de experincia. Atributos so informaes sobre
42
um item, se ele conforme ou no, e quase sempre originam de uma contagem Florac
& Carleton [2000].
Os grficos de controle de variveis usados no modelo CEP-S so:
Grfico X-Individual
(XI);
Grfico Mdia Mvel Exponencialmente Ponderada (MMEP):
O grfico para controle de atributos usado no modelo CEP-S o:
Grfico de Controle para No-Conformidades por unidade ou Defeitos (u);
Os grficos citados acima sero apresentados nas prximas sees. Tambm sero
S e R, conhecidos como grficos de Shewhart, que so os
apresentados os grficos X,
mais utilizados para o controle estatstico de processo. Porm, esses no sero usados no
modelo CEP-S por no serem apropriados para amostras de tamanho n = 1, tamanho
que, em geral, so colhidas as amostras de desenvolvimento de software.
Os grficos de variveis so usados no modelo CEP-S para o controle dos processos
aps a execuo dos projetos. O grfico de atributo usado no modelo CEP-S para
o controle do processo durante a execuo dos projetos. Destacamos que o controle
estatstico de processos de manufatura acontecem durante a produo. Em software,
isso no possvel para a maioria dos casos, sendo ento realizado aps a produo.
As aes de melhorias derivadas das informaes dos grficos so corretivas e para
preveno de futuras ocorrncias, e normalmente no so usadas para a produo
corrente de onde os dados foram gerados.
Montgomery cita algumas razes para a popularidade dos grficos de controle:
Tcnica comprovada para a melhoria da produtividade. Um programa bem definido de CEP reduz retrabalho causando o aumento de produtividade, a reduo
dos custos e o aumento da capacidade de produo;
Eficazes na preveno de defeitos;
Evitam o ajuste desnecessrio. O CEP pode distinguir entre um rudo de fundo,
variao aleatria, de uma variao de causa atribuvel, que precisa ser investigada e ter uma ao de melhoria;
Fornecem informao de diagnstico;
Fornecem informao sobre a capacidade do processo.
3.3. Limites de controle
3.3
43
Limites de controle
A definio dos limites de controle uma deciso crtica no momento do planejamento

do grfico de controle. Se aproximarmos os limites de controle da linha central, aumentamos o risco de um erro tipo I, ou seja, o risco de um ponto cair fora dos limites,
quando nenhuma causa atribuvel est presente. Se afastarmos os limites de controle
da linha central, aumentamos o erro tipo II, ou seja, o risco de um ponto cair entre os
limites de controle indicando falsamente que o processo est sob controle.1
Nos Estados Unidos prtica padro, independente da distribuio da caracterstica de qualidade ou do tipo de grfico usado, o uso de 3 (3 desvio padro) para o
clculo dos limites de controle. Isso corresponde a 99,73% da produo estarem dentro
dos limites de controle e 2.700 defeitos por milho de oportunidades. No Reino Unido e
em parte da Europa Ocidental, os limites utilizados so o de probabilidade = 0, 001.
Esse valor corresponde probabilidade do erro tipo I, onde temos o risco de 10 alarmes
falsos em 10.000 pontos. Haver pouca diferena entre os dois padres citados se as
caractersticas da qualidade tiverem distribuio normal. De acordo com a tabela rea
em caudas simtricas da distribuio normal padro a probabilidade do erro tipo I para
3 de uma distribuio normal p=0,00135 para cada lado da curva (0,0027 no total)
e o desvio padro para a probabilidade =0,001 3, 09.
Jalote, Jalote & Saxena [2002], e Montgomery apresentam estudos para o planejamento otimizado dos grficos de controle e, em especial, para a definio dos limites
de controle, visando os aspectos econmicos, como: o custo da amostragem, as perdas
pela fabricao de produtos defeituosos, os custos de investigao de alarmes falsos.
Jalote define um modelo para o clculo dos limites de controle em funo da otimizao
das variveis: custo de alarmes falsos (erro tipo I), custo de falhas no detectadas (erro
tipo II) e custo de reparar uma falha. Tais otimizaes so dignas de ateno, porm,
optamos por utilizar a aplicao padro de CEP, ou seja, limites de controle L=3,
tambm conhecidos como limites naturais, e no otimiz-los pelos seguintes motivos:
Os limites calculados com base em 3 fornecem bons resultados na prtica;

1
Para testar uma hiptese, toma-se uma amostra aleatria da populao em estudo, calcula-se a
estatstica de teste apropriada e ento, rejeita-se ou no a hiptese nula (H0 ). Dois tipos de erros
podem acontecer nesses testes: Se a hiptese nula rejeitada mesmo ela sendo verdadeira, diz-se
ERRO I. Se a hiptese nula no rejeitada e ela falsa, diz-se ERRO II. As probabilidades (P) desses
tipos de erros so denotadas como:
= P(erro tipo I) = P(rejeitar H0 |H0 verdadeira)
= P(erro tipo II) = P(no rejeitar H0 |H0 falsa)
No controle de qualidade, tambm chamado de risco do fabricante.
44
Em muitos casos a distribuio da caracterstica da qualidade no conhecida a

ponto de permitir o clculo dos limites de probabilidades exatos;
Os custos dos erros tipo I e II em software no so estimados com facilidade
para permitir otimizaes nas definies dos limites de controle;
A utilizao de CEP em PME de servios de desenvolvimento de software ainda
incipiente, com fortes limitaes de dados para amostragem. Portanto, nesse
caso, a aplicao padro de CEP pode ser suficiente para controle dos processos.
Shewhart, para justificar o uso de limites de controle 3, cita que se um processo estiver
sob controle, evite ajustes desnecessrios, que s tendem a aumentar a sua variabilidade. A otimizao dos limites de controle para a prtica de CEP em software pode
ser considerada um objetivo futuro para empresas que esto iniciando nessa prtica.
A definio dos limites de controle pode ser feita a partir da anlise do Comprimento Mdio da Sequncia (CMS), o qual representa o nmero mdio de observaes
necessrio para que um ponto sinalize uma condio de fora-de-controle, sendo CMS0
no processo sob controle (alarme falso) e CMS1 no processo fora-de-controle. A anlise conjunta do CMS0 e CMS1 indica a eficcia do grfico de controle. A Inteno
definirmos esses parmetros de modo a termos o maior CMS0 possvel e o menor
CMS1 possvel. Assim, o grfico de controle sinalizar a falta de controle rapidamente
quando o processo sofrer alguma alterao e vagarosamente quando o processo no sofrer qualquer alterao (alarme falso). Para os grficos de Shewhart, com observaes
no autocorrelacionadas e distribudas normalmente, o CMS calculado pela equao
3.2:
CM S =
1
p(um ponto aparece fora-de-controle)
(3.2)
Onde p a probabilidade de que qualquer ponto exceda os limites de controle,

dada pela equao 3.3:
CM S0 =
CM S1 =
1
1
(3.3)
= (L k n) (L k n)
Onde o risco de no se detectar o deslocamento k na primeira amostra e n
o tamanho da amostra.
45
3.4. Limites de especificao
Para = 0, 0027, que corresponde a L=3, considerando a distribuio normal e

a no autocorrelao, temos CM S0 = 370 e CM S1 de acordo com a tabela 3.1. Isso
o mesmo que dizer que, para um processo sob controle, um alarme falso ser dado a
cada 370 amostras e uma causa atribuvel ser sinalizada a cada 43, 9 pontos, para
um deslocamento de 1 da mdia, a cada 6, 3 pontos para 2 e a cada 2, 0 pontos
para 3.
Tamanho do Deslocamento
1
2
3
0,9772
0,8413
0,5000
CM S1
43,96
6,30
2,00
Tabela 3.1: Comprimentos Mdios de Sequncias para CM S1
Para a construo do grfico MMEP, ser necessrio planejar dois parmetros

para os limites de controle: o L, que tem o mesmo significado apresentado anteriormente, e o , que uma constante 0 < 1. Valores pequenos de fazem com que
os dados histricos tenham peso maior e valores grandes de fazem com que a ltima
observao tenha peso maior. Para = 1 o grfico MMEP se reduz ao grfico de
Shewhart. O planejamento timo para o grfico MMEP deve considerar os CMS sob
controle e fora-de-controle. E, em geral, no intervalo de 0, 05 0, 25 funciona
bem na prtica. De acordo com Hunter, Hunter [1989], apud Montgomery [2004], o
grfico MMEP com os parmetros L = 3,054 e = 0, 4 teria o peso das observaes
correntes e anteriores igualadas aos pesos das observaes dos grficos de Shewhart.
Esses parmetros resultam em um CM S0 = 500 e um CM S1 14, 3. Logo, assumimos para a aplicao do grfico MMEP os parmetros L = 3, 054 e = 0, 4, o que
resulta na equivalncia dos grficos de Shewhart e MMEP. Porm, a organizao pode
optar por definir parmetros diferentes dos sugeridos. A tabela 3.2 pode ser utilizada
para apoiar essa nova definio. Ela apresenta o CMS para vrias combinaes dos
parmetros L e para o grfico MMEP.
3.4
Limites de especificao
Os Limites de Especificao, segundo Florac, Florac & Carleton [1999], so tambm

conhecidos como a voz do cliente. So os limites especificados externamente, pelo
cliente, pelo negcio, pelos engenheiros de produo ou pela gerncia. Segundo o
PMBOK, PMI [2009], a rea do grfico de ambos os lados da linha central, ou mdia,
de dados traados em um grfico de controle que atende aos requisitos do cliente para
46
Mudana na
Mdia (multiplo de )
0
0,25
0,50
0,75
1,00
1,50
2,00
2,50
3,00
4,00
L = 3, 054
= 0, 40
L = 2, 998
= 0, 25
L = 2, 962
= 0, 20
L = 2, 814
= 0, 10
L = 2, 615
= 0, 05
500
224
71,2
28,4
14,3
5,9
3,5
2,5
2,0
1,4
500
170
48,2
20,1
11,1
5,5
3,6
2,7
2,3
1,7
500
150
41,8
18,2
10,5
5,5
3,7
2,9
2,4
1,9
500
106
31,3
15,9
10,3
6,1
4,4
3,4
2,9
2,2
500
84,1
28,8
16,4
11,4
7,1
5,2
4,2
3,5
2,7
Tabela 3.2: Comprimentos Mdios de Sequncias para Vrios Esquemas de Controle

MMEP
um produto ou servio. No h uma relao estatstica ou matemtica entre os limites

de controle e os limites de especificao. importante no confundir tais limites e,
principalmente, entender que para produzir produtos que atendam especificao, os
limites de especificao devem conter os limites de controle. A figura 3.4 apresenta
um grfico de controle que ilustra, alm dos limites de controle LC, LSC e LIC os
limites de especificao LSE (limite superior de especificao) e LIE (limite inferior de
especificao).
Figura 3.4: Limites de controle e especificao
3.5. Tamanho da amostra e frequncia de amostragem
3.5
47
Tamanho da amostra e frequncia de

amostragem
Definir o tamanho da amostra e a frequncia da amostragem faz parte do planejamento

de um grfico de controle. O ideal seria coletar grandes amostras em um curto intervalo
de tempo, porm esse cenrio pode ser invivel economicamente. Alm disso, quando
a taxa de produo lenta, o que a caracterstica do desenvolvimento de software,
Florac & Carleton [1999], torna-se inconveniente acumular amostras de tamanho n > 1,
pois intervalos longos entre as observaes podem gerar problemas na formao de
subgrupo racional1 . Diante dessas consideraes, assumimos, para o modelo CEPS, o tamanho das amostras n = 1, o que torna desnecessria a definio de subgrupo
racional, e a frequncia amostral=frequncia da produo, ou seja, toda sada produzida
(artefato, produto de software, processo executado, etc).
3.6
Testes de hiptese, nvel de significncia e

P-valor
Teste de Hiptese um dos mtodos de inferncia estatstica que torna possvel a estimativa de uma caracterstica de uma populao ou a tomada de uma deciso referente
populao com base somente em resultados de amostras. Para testar uma hiptese
toma-se uma amostra aleatria da populao em estudo, calcula-se a estatstica de
teste apropriada e ento, rejeita-se ou no a hiptese nula. Os testes de hiptese so
constitudos por duas hipteses:
H0 = hiptese nula (ausncia do efeito que se quer verificar);
H1 = hiptese alternativa (hiptese a ser verificada);
O procedimento para testar a hiptese tomar uma amostra aleatria de n observaes e calcular a estatstica de teste por:
Z0 =
x 0
(3.4)
H0 rejeitada se |Z0 | > Z 2 , onde Z 2 o ponto da distribuio normal padro

correspondendo porcentagem superior 2 , para alternativa bilateral. Para alternativa
unilateral, rejeita-se H0 se Z0 > Z ou Z0 < Z .
1
Subgrupo racional consiste na retirada de amostras em intervalos de tempo regulares, com o

objetivo de, na presena de causas atribuveis, maximizar a chance de diferena entre as amostras e
minimizar a chance de diferena dentro de cada amostra.
48
Dois tipos de erros podem acontecer nesses testes: se a hiptese nula rejeitada
mesmo ela sendo verdadeira, diz-se ERRO I. Se a hiptese nula no rejeitada e ela
falsa, diz-se ERRO II. As probabilidades desses tipos de erros so denotadas como:
= P(erro tipo I) = P(rejeitar H0 |H0 verdadeira)
= P(erro tipo II) = P(no rejeitar H0 |H0 falsa)
No controle de qualidade, tambm conhecido de risco do fabricante, por
denotar a probabilidade de um lote bom ser rejeitado e o risco do consumidor, por
denotar a probabilidade de aceite de um lote de baixa qualidade.
O nvel de Significncia, ou valor , a probabilidade do erro tipo I ocorrer, ou
seja, rejeitar indevidamente a hiptese nula. Por exemplo, a hiptese nula rejeitada
se o 0, 05, o que significa 95% de confiana da hiptese nula ser verdadeira.
O P-Valor o menor nvel de significncia que levaria rejeio da hiptese nula
H0 . Ele fornece mais informao sobre a evidncia contra H0 que o valor e pode ser
calculado por:
2d1 |Z0 |e para o teste bilateral
(3.5)
P = 1 (Z0 )
para o teste superior
(Z )
para o teste inferior
0
Onde (Z) a funo da distribuio acumulada da normal padro.

Nem sempre fcil calcular exatamente o P-Valor, no entanto, esse clculo pode
ser facilmente realizado por ferramentas que apoiam o CEP. Nos estudos de caso do
presente trabalho os clculos foram realizados a partir da ferramenta Minitab.
3.7
Coeficiente de correlao
O uso de alguns grficos convencionais de controle estatstico torna-se inapropriado

caso haja dependncia entre as observaes das caractersticas de interesse. Porm,
alguns grficos podem ser usados ainda que a hiptese de independncia seja violada,
num grau fraco ou moderado.
O coeficiente de correlao a medida do grau de dependncia linear entre duas
variveis. H vrias frmulas de clculo, sendo o Coeficiente de Pearson a mais simples
e conhecida. De acordo com Meyer, Meyer [1983], o Coeficiente de Pearson definido
por: Seja (X,Y) uma varivel aleatria bidimensional. xy o coeficiente de correlao
entre X e Y, dado por:
xy =
cov(X, Y )
E[X E(X)][Y E(Y )]
p
=
x y
V (X)V (Y )
(3.6)
49
3.7. Coeficiente de correlao
Para verificar a autocorrelao, o clculo do coeficiente dado por:
k =
cov(Xt , Xtk )
, k = 0, 1, ...
xt
(3.7)
Onde t o instante da observao.

O valor de xy est sempre entre -1 e 1. xy > 0 significa que o comportamento
de X diretamente proporcional ao comportamento de Y, ou seja, se X cresce Y
tambm cresce, o que conhecido como correlao positiva. xy < 0 significa que
o comportamento de X inverso ao de Y, ou seja, se X cresce Y decresce, o que
conhecido como correlao negativa. Quanto maior o valor absoluto de xy mais forte
a correlao e xy = 0 corresponde a inexistncia de correlao. Vamos considerar
o valor absoluto do coeficiente de correlao 0 < 0, 4 fraco, 0, 4 < 0, 7
moderado e 0, 7 1 forte, Shimakura [2006]. Segundo Junior, Junior & ten
Caten [2004], quando a autocorrelao fraca prxima de zero, geralmente ela no
significativa, e as tcnicas de CEP tradicional podem ser utilizadas. Vamos considerar
prxima de zero a autocorrelao com Pearson 0, 09.
O diagrama de disperso um grfico til para a identificao de correlaes
potenciais entre duas variveis. construdo plotando Xi versus Yi para i = 1, 2, ..., n.
Os pontos do diagrama de disperso indicam que quanto menos dispersos e mais aproximados de uma reta mais forte a correlao. Salientamos que correlao no implica
necessariamente em causalidade.
As figuras seguintes ilustram dois diagramas de disperso. A figura 3.5 apresenta
uma correlao forte, cujo coeficiente 0,83 e a figura 3.6 apresenta uma correlao
fraca, cujo coeficiente 0,16.
Figura 3.5: Correlao Forte
Figura 3.6: Correlao Fraca
50
3.8
Testes de normalidade
Os dados devem ter uma distribuio normal para que o uso dos grficos de Shewhart
seja vivel. Entre as propostas de testes de normalidade esto as de Anderson-Darling,
Kolmogorov-Smirnov e Ryan-Joiner (similar a Shapiro-Wilk). Os testes de AndersonDarling e Kolmogorov-Smirnov so baseados em uma funo de distribuio emprica e
o teste de Ryan-Joiner baseado na regresso e na correlao. Em geral, entre os testes
baseados na funo de distribuio emprica, o teste de Anderson-Darling tende a ser o
mais utilizado, Minitab [2008]. Ele tem a vantagem de ser um teste mais sensvel, por
ser especfico para cada distribuio, porm, o valor crtico precisa ser calculado para
cada distribuio. A hiptese para o teste de Anderson-Darlin definido como:
H0 : Os dados seguem uma distribuio especificada;
H1 : Os dados no seguem a distribuio especificada.
(3.8)
O teste de Anderson-Darlin definido como:

A2 = n S, onde
S=
n
X
(2i 1)
i1
ln F (Yi ) + ln(1 F (Yn + 1 i))
(3.9)
Onde F a funo cumulativa da distribuio e Y so os dados ordenados.

A hiptese que a distribuio de uma determinada forma rejeitada se a estatstica A for maior que o valor crtico, NIST/SEMATECH [2010]. Como resultado do
teste para distribuio normal, esperamos um P-Valor > 0,005, onde a hiptese nula
aceita, ou seja, a distribuio normal. Esse teste usualmente realizado com o apoio
de um aplicativo de software. O presente trabalho utiliza a ferramenta Minitab para
apoiar os testes, Minitab [2008].
3.9
Testes para deteco de situaes

fora-de-controle
Um grfico de controle pode indicar que um processo encontra-se fora-de-controle

quando um ou mais pontos se localizarem fora dos limites de controle ou quando os
pontos exibirem algum padro de comportamento no aleatrio.
O comportamento no aleatrio pode ser identificado se alguma sequncia for
3.9. Testes para deteco de situaes fora-de-controle
51
detectada. Uma sequncia uma fila de observaes do mesmo tipo, um comportamento cclico ou tendencioso das observaes. Por exemplo, se uma fila tem oito
ou mais pontos consecutivos, de um mesmo lado da mdia, muito provvel que o
comportamento do processo seja no aleatrio.
Florac, Florac & Carleton [1999], cita 4 tipos de testes para deteco de situao
fora-de-controle, referenciando The Western Electric Handbook e Montgomery acrescenta mais 6 tipos a esse conjunto de testes. Os 10 tipos de testes so apresentados a
seguir e a figura 3.7 exemplifica os 4 primeiros.
Teste 1 Um ponto localizado fora dos limites de controle 3;
Teste 2 Pelo menos dois pontos de trs pontos consecutivos localizados entre 2 e 3;
Teste 3 Pelo menos quatro pontos de cinco pontos consecutivos localizados entre 1
e 2;
Teste 4 Pelo menos oito pontos consecutivos localizados de um mesmo lado da linha
central (LC);
Teste 5 Seis pontos em uma sequncia crescente ou decrescente;
Teste 6 Quinze pontos em sequncia entre a linha central LC e 1 (conhecido como
zona C);
Teste 7 Quatorze pontos em sequncia alternadamente para cima e para baixo;
Teste 8 Oito pontos em sequncia de ambos os lados da linha central com nenhum
entre a linha central LC e 1;
Teste 9 Um padro no-usual ou no aleatrio de dados;
Teste 10 Um ou mais pontos perto de um limite de alerta ou de controle.
A escolha dos tipos de testes a serem usados deve ser feita durante o planejamento
dos grficos de controle. Segundo Champ, Champ & Woodall [1987], em grficos de
controle de Shewhart, com variveis independentes, o uso concomitante dos testes 1,
2, 3 e 4 resultaram em um CMS sob controle de 91,25 contra 370 para o uso apenas do
teste 1. Ou seja, uso de mais de um tipo de teste aumenta a sensibilidade dos grficos
para detectar causas atribuveis, porm, aumenta tambm as possibilidades de alarmes
falsos. Por isso, para o modelo CEP-S assumimos usar o Teste 1.
52
Figura 3.7: Testes de controle
3.10
Grficos de controle X-Barra, S e R
O valor mdio das caractersticas de qualidade, geralmente, monitorado atravs do

e a variabilidade atravs do grfico da amplitude R ou do desvio
grfico de controle X
padro S. Tais grficos esto entre as tcnicas mais importantes de monitoramento de
processos. Para a aplicao desses grficos preciso que as amostras tenham uma distribuio normal e que as observaes individuais sejam independentes. Vrios outros
autores assumem que a distribuio da caracterstica de qualidade tem uma boa aproximao da distribuio normal, devido ao Teorema do Limite Central. Esse teorema
assume que a distribuio da soma de n variveis aleatrias independentes aproximadamente normal, independentemente das distribuies individuais das variveis. A
aproximao melhora medida que n aumenta. Assim, considera-se que o tamanho n
da amostra suficientemente grande quando n superior a 30 observaes.
construdo de acordo com a equao 3.1, apresentada na Seo 3.2
O grfico X
do presente Captulo. bastante razovel assumir a hiptese de normalidade para esse
grfico. Ele eficiente para detectar moderados a grandes deslocamentos da mdia do
processo, na ordem de 2 a 3 , quando o tamanho das amostras for pequeno, com n =4,
5 ou 6 observaes. Para que ele seja eficiente em detectar pequenos deslocamentos,
< 2, so necessrias amostras de tamanhos maiores, com n de 15 a 20 observaes.
Para o grfico R, a hiptese de normalidade no aplicvel. A distribuio
amostral de R no simtrica, mesmo se a populao tiver distribuio normal. Logo,
o risco de R no 0,0027 para L=3. Esse grfico insensvel para amostras pequenas
3.11. Grfico de controle X Barra-Individual
53
e pouco eficiente para amostras grandes, com n > 10 observaes.

e S so preferidos quando as amostras forem moderadamente
Os grficos X
grande, com n de 10 a 12 observaes, ou quando elas forem de tamanho varivel.
Em desenvolvimento de software, as amostras so, na maioria, de tamanho n = 1
R e S, ainda que sejam as tcnicas mais utilizadas
observao. Logo, os grficos X,
em CEP, no so os mais adequados para CEP de desenvolvimento de software. Uma
alternativa de Shewhart para amostras de tamanho n = 1 observao o grfico XI,

que ser apresentado na Seo seguinte.
3.11
Grfico de controle X Barra-Individual
se constitui
O grfico de controle de Shewhart para amostras de tamanho n = 1, o XI,
como alternativa ao uso dos grficos convencionais, cujas amostras so de tamanho
n > 1. Para que o seu uso seja vivel necessrio, assim como nos grficos convencionais, que as amostras sejam independentes e que a distribuio seja normal. A no
normalidade da distribuio das amostras afeta drasticamente os parmetros de con apropriado
trole e os limites de 3 tornam-se inapropriados. Alm disso, o grfico XI
para quando a magnitude do deslocamento na mdia do processo for de moderada a
grande, > 2. Se desejarmos detectar pequenos deslocamentos na mdia do processo,
os grficos da soma cumulativa e da mdia mvel exponencialmente ponderada so mais
apropriados. A equao 3.10 apresenta os parmetros para a construo do grfico XI:
LSC = x + 3
MR
d2
(3.10)
LC = x
LIC = x + 3
MR
d2
Onde MR a mdia da amplitude mvel e M Ri calculado pela equao 3.11:
M Ri = |xi xi1 |
Para amplitude mvel entre duas amostras, n = 2, temos d2 = 1, 128.
(3.11)
54
3.12
Grficos de controle para no-conformidades

(Defeitos)
Os grficos para controle de nmero de defeitos so muito utilizados em servios e

em melhorias de processos no industriais, onde as caractersticas de interesse so, em
geral, mensurveis em uma escala no numrica. Esses grficos, so conhecidos como
grficos para controle de atributos e so menos precisos que os grficos para o controle
de variveis. Montgomery apresenta trs grficos de controle de atributos amplamente
usados:
Grfico de controle para frao no-conforme p
Grfico de controle para no-conformidades c;
Grfico de controle para no-conformidades por unidade u.
O grfico de no-conformidades por unidade, grfico u, adequado para os controles onde os tamanhos das amostras so variveis. Em atividades de garantia da
qualidade em desenvolvimento de software, como inspees, testes e revises em pares,
as amostras tm tamanhos variados, sendo esse grfico, portanto, adequado.
A equao 3.12 usada para a construo do grfico u:
r
LSC = u + 3
u
n
(3.12)
LC = u
r
LIC = u 3
Onde u =
3.13
P
P Def eitos
Amostras
e o valor plotado o
u
n
Def eitosi
Amostrai
Grfico MMEP
Montgomery descreve dois grficos para controle estatstico de processos, que se constituem como alternativas mais eficazes que os grficos de controle de Shewhart para
deslocamentos de magnitudes inferiores a 2, e em particular para tamanho de amostra n = 1, que so: Soma Cumulativa (CUSUM) e Mdia Mvel Exponencialmente
Ponderada (MMEP). Esse ltimo, de acordo com autor, mais fcil de estabelecer e
operar que o primeiro, insensvel hiptese de normalidade e ideal para observaes
3.14. Histograma e Grfico de Pareto
55
individuais, sendo quase um procedimento no paramtrico (livre de distribuio). Ele

construdo plotando Zi versus o nmero da amostra i, onde Zi definido como:
Zi = xi + (1 )Zi1
(3.13)
Onde 0 < 1 a constante e o valor inicial Z0 o alvo do processo, Z0 = 0 .

Os parmetros do grfico MMEP so definidos como:
s
LSC = 0 + L
b1 (1 )2i c
(2 )
(3.14)
LC = 0
s
LIC = 0 L
3.14
b1 (1 )2i c
(2 )
Histograma e Grfico de Pareto
O histograma uma representao grfica da distribuio de frequncia, normalmente

um grfico de barras verticais, onde as variveis de interesse so plotadas no eixo horizontal e no eixo vertical plotado o percentual de observaes ou a frequncia de
ocorrncia de cada varivel. Ele permite ver mais facilmente a posio ou tendncia
central e o espalhamento ou disperso dos dados. Um exemplo de histograma apresentado na figura 3.8. No eixo horizontal esto as categorias dos Tipos de Defeitos e
no eixo vertical o nmero de defeitos de cada tipo.
O grfico de Pareto, cuja anlise tambm conhecida como o princpio 20/80,
um histograma de atributos, onde as categorias so ordenadas decrescentemente.
Ele foi proposto por Vilfredo Pareto (um economista) que, ao analisar a sociedade,
concluiu que grande parte da riqueza se concentrava na mo de um nmero reduzido
de pessoas. Em seguida, concluiu que esse princpio era vlido para vrios fenmenos,
e estabeleceu a anlise de Pareto, a qual afirma que 80% das consequncias advm
de 20% das causas. Aplicando esse princpio para os defeitos em desenvolvimento de
software, teramos 20% das causas gerando 80% dos defeitos. Considerar esse princpio
importante para direcionar os esforos em aes de melhorias, enfocando os 20%
das causas para resolver 80% dos problemas. A figura 3.9 apresenta um exemplo
do grfico de Pareto. A construo realizada a partir do histograma, plotando os
dados em ordem decrescente, e adicionando uma curva da porcentagem acumulada de
participao de cada categoria.
56
Figura 3.8: Exemplo de Histograma - nmero de defeitos por tipo
Tanto o Histograma quando o grfico de Pareto podem apoiar a aplicao do

modelo CEP-S. Eles podem ser utilizados em conjunto, por exemplo, com o grfico u,
para analisar quais tipos defeitos ocorrem com maior frequncia.
3.15
Capacidade do processo
A capacidade do processo refere-se a habilidade do processo de produzir itens conformes, ou seja, de acordo com as especificaes dos clientes, legais, do projeto, etc. Ela
pode ser expressa quantitativamente de forma simples por um ndice de capacidade do
processo, Cp , que indica o quanto o processo atende s especificaes, e dado por:
Cp =
LSE LIE
6
(3.15)
Onde LSE e LIE so os limites de especificao superior e inferior, respectivamente.

Cp um parmetro adimensional que pode indicar a quantidade de falhas no
processo, caso as seguintes consideraes sejam atendidas: (i) a caracterstica de qualidade deve ser normalmente distribuda; (ii) o processo deve estar sob controle; (iii) a
mdia do processo deve estar centrada entre os limites de especificao superior e inferior. Caso essas condies no sejam satisfeitas, Cp no pode ser usado para indicar a
quantidade de falhas no processo. Essa quantidade comumente expressa em defeitos
57
3.16. Grfico de custo benefcio
Figura 3.9: Exemplo de Diagrama de Pareto - nmero de defeito por tipo
por milhes de peas (ppm). A tabela 3.3 apresenta alguns valores Cp e os respectivos
ppm.
Cp
0,25
0,50
1,00
1,50
2,00
ppm
453.255
133.614
2.700
7
0,0018
Tabela 3.3: Estimativa de ppm para Cp
3.16
Grfico de custo benefcio
O grfico de custo benefcio consiste no clculo da taxa de retorno em relao ao valor

investido. No modelo CEP-S proposto para analisar at quando o custo do esforo
com as atividades de testes vale o benefcio de encontrar mais um defeito (ou noconformidade). Para tanto, usaremos o nmero de defeitos encontrados versus HH
(homem hora). A figura 3.10 apresenta um exemplo de grfico para anlise de custo
58
benefcio. No eixo horizontal plota-se o tempo decorrido em horas e no eixo vertical

plotam-se o as quantidades acumuladas de defeitos encontrados e de HH em cada
instante.
Figura 3.10: Exemplo de grfico para anlise de custo x benefcio
Captulo 4
O Modelo CEP-S
O Modelo CEP-S auxilia a aplicao de CEP nas PME que prestam servios de desenvolvimento de software vertical sob encomenda. importante ressaltar que o esforo
de preparao para a aplicao de CEP considervel e que o modelo se restringe a
organizaes capazes de planejar e executar efetivamente um plano de medio e de
realizar aes efetivas de melhorias. Esses pr-requisitos so os meios para garantir a
gerao de dados confiveis e a estabilizao dos processos. O modelo prope quatro
ideias estruturadoras que formam a base das contribuies:
Visualizao das atividades dos processos alvo de CEP em uma estrutura composta por trs categorias: atividade fim, atividade de garantia de qualidade e atividade de retrabalho. Essa visualizao favorece a identificao de um conjunto
de caractersticas de interesse significativas estrategicamente e normalizadas;
Vamos assumir que o desenvolvimento de software ocorre em projetos, ou seja,
em uma aplicao de um esforo temporrio, com incio e fim, para produo
de um produto ou servio exclusivo, nesse caso, o aplicativo de software. Logo,
a segunda considerao a diviso do projeto de software em partes menores,
por algum agrupador: mdulos do sistema, casos de uso ou outro agrupador
que a organizao visualizar. Essa definio favorece a reduo da restrio de
quantidade de dados para o controle estatstico;
Identificao de caractersticas de qualidade com foco no processo e no no produto, baseadas no esforo e no na taxa de defeitos, sendo assim mais significativas. Tambm apresenta a identificao de caractersticas que permitem o controle
estatstico para as fases de produo e manuteno do software;
59
60
Captulo 4. O Modelo CEP-S
Uso combinado de grficos de controle eficazes para grandes e pequenas magnitudes de desvios da mdia. Alm da proposta de combinao dos grficos, o
presente trabalho apresenta sugestes para a definio dos parmetros de controle
e para os testes de estabilidade.
A proposta do modelo CEP-S fornecer um arcabouo com escolhas pr-definidas,
prprias para os processos de desenvolvimento de software, para tornar a aplicao de
CEP em PME facilitada, favorecendo as investidas iniciais nas atividades de controle
estatstico. Esse arcabouo complementa os guias de referncia de aplicao de CEP,
como apresentados em Florac & Carleton [1999]; Costa et al. [2008]; Montgomery
[2004], entre outros, com as contribuies citadas acima. A Figura 4.1 apresenta as
atividades propostas para a aplicao de CEP, divididas em planejamento e execuo. As contribuies apresentadas acima so detalhadas ao longo da descrio dessas
atividades, nas prximas sees.
Figura 4.1: Viso das atividades para aplicao de CEP

As atividades de preparao para a execuo do CEP esto agrupadas na etapa
de planejamento, como apresentada na figura 4.1. A Seo 4.1 detalha a atividade
de seleo dos processos e uma viso de como tais processos so organizados para a
execuo das medies, os conceitos envolvidos e as personalizaes necessrias para
a adaptao do modelo CEP-S aos processos das organizaes. Em seguida, na Seo
4.2, as caractersticas de interesse so identificadas, juntamente com as convenes e os
procedimentos que descrevem a forma pela qual tais atributos devem ser mensurados
e como selecion-los para cada organizao. Seo 4.3 apresenta os passos para o
planejamento e execuo das medies. A Seo 4.4 apresenta um mecanismo para a
organizao escolher os grficos de controle de acordo com os dados coletados e definir
os parmetros de controle e os testes de estabilidade. Na Seo 4.5, as atividades para
estabilizao dos processos so apresentadas. O processo estvel permite o clculo dos
parmetros de controle que conduziro o controle estatstico. No momento em que os
processos se tornam estveis possvel iniciar a execuo do CEP, que consiste nas
atividades: coleta e plotagem dos dados, testes de controle, investigao de causas
4.1. Seleo dos processos alvo do controle estatstico
61
atribuveis, aplicao de melhorias e excluso de dados afetados por causas atribuveis.

Essa execuo apresentada na Seo 4.6.
4.1
Seleo dos processos alvo do controle

estatstico
85% de todos os problemas organizacionais so devido aos processos, aos mecanismos de controle e s
estruturas, os demais 15% so relativos s pessoas. O mapeamento dos processos pode evidenciar tais
problemas.
Madison [2005]
Este trabalho define uma proposta de controle estatstico para os processos de

Requisitos e de Implementao. A seleo desses considerou quais dos processos de
desenvolvimento de software so importantes e influenciam fortemente o sucesso do
negcio e, se limitou apenas a dois, visto que CEP deve se restringir a um nmero
pequeno de processos, apenas os estratgicos para a organizao. Porm, apesar de,
em nmeros, serem poucos processos, os selecionados, na viso que ser apresentada,
correspondem maior parte do esforo total do desenvolvimento de software, portanto,
significativos para a organizao desenvolvedora de software. A ideia inicial estruturadora do modelo CEP-S pensar em cada um desses processos como composto pelas
seguintes atividades:
Atividade fim;
Atividade de garantia da qualidade do produto;
Atividade de retrabalho (correes em produo e manutenes corretivas).
A viso dos processos de Requisitos e Implementao divididos em trs atividades,
fim, de garantia da qualidade e de retrabalho, e do projeto de desenvolvimento de
software dividido por algum agrupador permitir a definio das medidas bsicas para
derivao das caractersticas de interesse. As medidas definidas, de acordo com a viso
estabelecida, so: o tamanho por unidade de produto, medido por agrupador; o esforo
realizado (em horas ou minutos) e o nmero de no-conformidades (ou defeitos) medidos
separadamente por processo (Requisitos e Implementao), por agrupador (caso de uso,
mdulo do sistema ou outro que a organizao definir) e por categoria de atividade
(fim, de garantia da qualidade e de retrabalho).
As caractersticas de interesse, derivadas das medidas bsicas citadas, para serem
comparadas precisam ser normalizadas, ou seja, ser homogneas. Ao se comparar o esforo do processo de Requisitos no desejvel que esse esforo seja composto tambm
62
pelo esforo, por exemplo, do processo de modelagem de negcio, principalmente porque esse ltimo pode no estar distribudo homogeneamente por agrupador. Por isso,
delimitamos o que entendemos por processos de Requisitos e Implementao, a partir
da viso do processo de desenvolvimento de software definidos a seguir e do escopo
de suas respectivas atividades. Alm da viso dos processos, apresentamos tambm
algumas consideraes e sugestes para personalizar o modelo CEP-S de acordo com
as organizaes.
4.1.1
Viso dos processos alvo de CEP
A figura 4.2 apresenta a viso dos processos e das atividades do desenvolvimento de

software proposta pelo modelo CEP-S. Esses processos e atividades encontram-se distribudos em trs fases: Pr-produo, Produo e Ps-produo. A fase Pr-produo
composta pelo processo de Venda. A fase Produo composta pelos processos de
Modelagem de negcio, Requisitos, Projeto Arquitetural, Implementao, Implantao e Suporte ao Desenvolvimento. A fase Ps-produo composta pelos processos
de Manuteno e Suporte ao Usurio.
Os processos e as atividades exibidos na fase Produo so baseados no RUP,
um framework proprietrio, que prov muitas das melhores prticas conhecidas para o
desenvolvimento de software. O RUP foi utilizado no presente trabalho com a finalidade
nica de ser uma referncia para a definio da viso apresentada, mas isso no significa
que seu uso pr-requisito para aplicao do modelo CEP-S.
A viso aqui proposta faz referncia a todas essas disciplinas do RUP, porm
as reorganiza de forma diferente, para refletir a ideia estruturadora apresentada. As
medidas bsicas usadas para derivar as caractersticas de interesse dependem dos agrupamentos corretos dessas disciplinas na viso estabelecida. Por isso, optamos por
mostrar na viso todas as disciplinas, mesmo as que no fazem parte do controle estatstico, na tentativa de evidenciar a reorganizao proposta, apresentando o escopo e
o contra-escopo dos processos selecionados.
Alteramos a disciplina de Implementao para ser vista como um processo composto pela disciplina de Testes. Evidenciamos a atividade de reviso, relativa garantia
de qualidade do processo Requisitos. Essas alteraes definem o processo de modo a
atender necessidade de cada um ser composto pelas trs categorias de atividades, a
atividade fim, de garantia da qualidade e de retrabalho. Como a disciplina de Implementao foi promovida processo, foi necessrio promover tambm as disciplinas
Modelagem de Negcio, Requisitos, e Implantao, pois todas essas devem ter o mesmo
nvel de abstrao no processo visualizado. A disciplina Anlise e Projeto foi dividida,
63
Figura 4.2: Viso dos processos de desenvolvimento de software
parte no processo denominado Projeto Arquitetural e parte na atividade de Levantamento e Anlise do processo de Requisitos. Essa reorganizao objetivou separar as
tarefas que podem ser distribudas por agrupador (anlise) das tarefas que no so por
agrupador e sim por projeto (arquitetura).
No RUP, a Gesto da Qualidade apresentada como responsabilidade da disciplina de Gerenciamento de Projetos, no sendo explicitada como uma disciplina distinta. Na viso proposta, a Gesto da Qualidade foi dividida em atividades de garantia
64
da qualidade do produto e atividades de garantia da qualidade do processo. As atividades de garantia da qualidade do produto foram evidenciadas nos processos de Requisitos
e Implementao, como j citado. A atividade de garantia da qualidade do processo foi
evidenciada no processo de Suporte ao Desenvolvimento, como atividade distinta da
Gesto do Projeto. Essa reorganizao objetivou identificar que tipo de atividade de
garantia da qualidade deve ser considerada nos processos de Requisitos e Implementao. Os processos de Venda, Manuteno e Suporte ao Usurio no so tratados pelo
RUP, mas foram evidenciados devido proposta de exibir o contra-escopo do controle
estatstico. Os esforos de execuo desses processos devem ser considerados distintos
dos processos de Requisitos e Implementao.
E, por fim, como ltima alterao, as atividades de manuteno corretiva e manuteno evolutiva foram apresentadas distintamente, para permitir a derivao das
caractersticas de interesse que dependem do esforo executado apenas na atividade de
manuteno corretiva. O IEEE [1998] define o processo de manuteno como sendo as
modificaes de um produto de software aps a entrega desse, geralmente para corrigir
defeitos, melhorar o desempenho ou outros atributos, ou adaptar o produto a um ambiente diferente. Classifica a manuteno em quatro tipos: manuteno corretiva
para corrigir as falhas/defeitos descobertos aps a entrega; manuteno adaptativa
para acomodar mudanas no ambiente externo ou nas regras de negcio; manuteno perfectiva/evolutiva para melhorar o desempenho ou a manutenabilidade ou
incorporar novas funcionalidades; manuteno emergencial para manter o software
operacional - uma manuteno no planejada. O foco do presente trabalho separar
o esforo de retrabalho cujo custo da empresa contratada para desenvolver o software
do esforo de retrabalho cujo custo pode ser repassado ao cliente. Logo, consideramos
aqui apenas a diviso manuteno corretiva, relativa aos erros no processo de desenvolvimento de software (manuteno corretiva ou emergencial de acordo com o IEEE)
e a manutenes evolutiva, relativa s novas solicitaes do cliente (manuteno
perfectiva ou adaptativa de acordo com o IEEE).
4.1.2
Viso das atividades dos processos alvo de CEP
A tabela 4.1 apresenta a estrutura proposta de diviso dos processos alvo de CEP
instanciada para os processos de Requisitos e Implementao. As respectivas atividades
so detalhadas a seguir, com o objetivo de delimitar o escopo a ser considerado em cada
uma.
Atividades do Processo de Requisitos
Levantamento e Anlise: o Levantamento e Anlise tm por objetivo obter o enun-
Processos
Requisitos
Implementao
Atividade
Fim
Levantamento
e Anlise
Codificao
Garantia da
Qualidade
Revises
Revises
e Testes
65
Retrabalho
Correes em Produo e
Manutenes Corretivas
Correes em Produo e
Manutenes Corretivas
Tabela 4.1: Atividades dos processos alvo de CEP
ciado completo, claro e preciso dos requisitos de um produto de software e modelar

de forma precisa os conceitos relevantes do domnio do problema.
Revises: as Revises tm por objetivo garantir a qualidade dos artefatos produzidos
pelo Levantamento e Anlise. De acordo com o IEEE, IEEE [1997], um processo ou uma reunio durante a qual um produto de software apresentada ao
projeto pessoal, gerentes, usurios, clientes, representantes de usurios, ou outras partes interessadas para comentrios ou aprovao. Classifica as revises em
quatro tipos: auditoria - um exame independente de um produto de software,
processos de software, ou conjunto de processos de software para avaliar a conformidade com as especificaes, normas, acordos contratuais ou outros critrios;
inspeo - inspeo visual de um produto de software para detectar e identificar
anomalias no software, incluindo os erros e desvios dos padres e especificaes.
As inspees so exames de pares liderado por facilitadores imparciais que so
treinados em tcnicas de inspeo. A determinao de recursos para a reparao
ou a investigao de uma anomalia um elemento obrigatrio, embora a soluo
no deve ser determinada na reunio de inspeo; reviso tcnica - avaliao
sistemtica de um produto de software por uma equipe de profissionais qualificados que examina a adequao do produto de software para o uso pretendido
e identifica discrepncias das especificaes e normas. Essas avaliaes devem
prover recomendaes alternativas; walk-through - tcnica de anlise esttica
na qual um projetista ou programador leva os membros da equipe de desenvolvimento e outras partes interessadas atravs de um produto de software, e os
participantes fazem perguntas e fazer comentrios sobre possveis erros, violao
de padres de desenvolvimento, e outros problemas.
Correes: as Correes tm por objetivo corrigir os defeitos/falhas apontadas pelas
revises ou pelo usurio final (aps o produto ser implantado em produo).
Atividades do Processo de Implementao
66
Codificao: a Codificao tem por objetivo codificar as funcionalidades, de acordo

com os insumos recebidos dos processos de Requisitos e Anlise e Projeto Arquitetural, realizar os testes de unidade e integrar os resultados produzidos.
Testes: os Testes tem por objetivo garantir a qualidade dos artefatos produzidos na
implementao, avaliando se o que foi definido em Requisitos e Anlise e no
Projeto Arquitetural foi produzido. Todas as atividades relativas garantia da
codificao devem ser consideradas como Testes, exceto os testes de unidade,
que sero considerados como codificao. Essa considerao visa simplificar a
alocao de horas em cada categoria visando alocaes de horas mais consistentes;
Correes: as Correes tm por objetivo corrigir as falhas apontadas pelos testes ou
pelo usurio final aps implantao do produto. No devem ser consideradas as
correes de testes de unidade, visto que elas foram consideradas na atividade de
codificao.
4.1.3
Consideraes
A organizao deve escolher os processos alvo de CEP de acordo com os objetivos estratgicos. A necessidade desse alinhamento justificada pelo fato de que a aplicao de
CEP pode apontar necessidade de mudanas nos processos organizacionais decorrentes
da identificao de desperdcios, falhas de produo ou otimizaes. Mudanas nos
processos internos podem impactar a cultura organizacional e para que sejam efetivas
necessrio que o diretor executivo (CEO1 ) ou a alta gerncia comunique e demonstre
regularmente seu engajamento, aloque os recursos apropriados, comprometendo pessoal
e esforo, e priorize as mudanas. Melhorias de processos, se movidas por iniciativas
isoladas, sem o comprometimento da alta gerncia tendem ao fracasso. O engajamento
do CEO ou da alta gerncia se d pelos objetivos estratgicos. A importncia do
engajamento da alta gerncia para o sucesso de aplicaes de CEP e de melhorias de
processo enfatizado em vrios modelos de melhorias como CMMI, MPS.BR, SixSigma
e PDCA.
A organizao que opta por ser aderente ao MPS.BR para a melhoria de seus
processos, implantar o processo de Medio (MED) no nvel F, o segundo nvel de
maturidade. Porm, o MPS.BR exige os atributos de processo (AP) de medio e controle somente a partir do nvel B, os quais preveem tcnicas quantitativas e estatsticas
para controlar os processos e a qualidade. Logo, o Modelo CEP-S til para as organizaes que buscam o nvel B do MPS.BR, porm estar a caminho desse nvel (B) no
1
Chief executive officer (CEO)
67
um pr-requisito para a aplicao do presente modelo, e sim ser capaz de planejar e

executar efetivamente um plano de medio e de realizar aes efetivas de melhorias.
O modelo CEP-S foi projetado de modo a permitir sua aplicao em cada um
dos processos de Requisitos e Implementao de forma independente, logo, um ponto
de simplificao aplic-lo em apenas um dos processos. A organizao pode optar
por iniciar o controle estatstico apenas pelo processo de Requisitos ou apenas pelo
processo de Implementao.
Um ponto de extenso do modelo CEP-S a incluso de outros processos no controle estatstico, indo alm dos processos Requisitos e Implementao. Um exemplo de
extenso do modelo a aplicao de CEP no processo de Projeto Arquitetural, quando
esse for significativo (em esforo ou complexidade ou importncia) para a organizao.
Para isso, a organizao deve, como primeiro passo, para o processo a ser includo, ter a
capacidade de visualizar distintamente as atividades nas trs categorias: atividade fim
(produo), atividade de garantia da qualidade do produto e atividade de correes.
A viso dos processos distingue as atividades de garantia da qualidade dos produtos das atividades de garantia da qualidade dos processos. A garantia da qualidade
dos produtos corresponde s atividades de revises e testes de software. Evidenciamos
tais atividades apenas para os processos Requisitos e Implementao. Para os demais
processos tais atividades no foram evidenciadas, fato esse que no as tornam desnecessrias. A atividade garantia da qualidade dos processos, includa no processo Suporte
ao Desenvolvimento, trata das auditorias que verificam e validam se as atividades e
artefatos produzidos esto em conformidade dos processos definidos pela organizao.
Os testes de unidade compem a atividade de codificao. Essa abordagem tambm utilizada pelo RUP e favorece muito a coleta do esforo nas trs atividades,
codificao, testes de unidade e correes, visto que, geralmente elas so executadas
por um mesmo executor e indistintamente no tempo. A execuo dessas trs atividades,
caso realizadas por um nico profissional de desenvolvimento, tende a se misturar num
mesmo perodo de tempo, tornando ineficiente e propcia a erros a coleta dos esforos
de realizao de cada uma separadamente.
Os processos Modelagem de Negcio e Projeto Arquitetural podem ser vistos indistintamente dos processos Requisitos e Implementao, respectivamente, em algumas
PME, onde o nmero de funcionrios pequeno para que cada um desempenhe um
nico papel. O fato de um profissional desempenhar mais de um papel pode trazer
essa indistino, principalmente quando algumas atividades ocorrem simultaneamente
ou prximas, so de papeis distintos, mas realizadas por profissionais no distintos. Visualizar tais processos distintamente pode favorecer a corretude das anlises dos dados
de esforos coletados, visto que favorece a homogeneidade das atividades.
68
4.1.4
Guia de personalizaes
Um nico processo no serve a todo tipo de empresa.
Arajo & Meira [2004]
Esta Subseo apresenta possveis configuraes para a viso proposta, com o

objetivo de orientar a personalizao da mesma, conforme necessidade ou preferncia
da organizao, para os processos de Requisitos e Implementao, em funo dos demais
processos ou atividades que podem influenci-los.
4.1.4.1
Processo de Requisitos
Modelagem de Negcio: caso a organizao execute indistintamente os processos

Modelagem de Negcio e Requisitos ainda assim possvel aplicar o controle estatstico no processo de Requisitos. Porm, como j citado, essa indistino pode
distorcer a caracterizao das atividades do processo de Requisitos se as horas
executadas no processo Modelagem de Negcio forem distribudas no uniformemente entre os agrupadores. O ideal a organizao planejar a execuo das
atividades de forma a visualizar distintamente tais processos ou garantir que a
distribuio de cada uma por agrupador seja homognea.
Revises: a execuo da atividade Revises pr-requisito para a aplicao do modelo CEP-S ao processo de Requisitos. Porm, no indicado a incluso de tal
atividade em funo apenas da aplicao do modelo. Ela deve ser includa quando
a organizao definir atuar na garantida da qualidade dos produtos do processo
de Requisitos e mostrar-se capaz dessa atuao, ou seja, a aplicao do modelo
CEP-S deve ser considerada para quando as atividades da garantia da qualidade
estiverem em uso pela organizao.
4.1.4.2
Processo de Implementao
Testes de Integrao ou Sistema ou Aceitao: esperado que a organizao realize atividade de testes de software e bastante desejado que tal atividade seja
executada por uma equipe distinta da equipe que executa a atividade de implementao.
Caso a atividade de testes seja realizada, porm pela mesma equipe que executa
a atividade de codificao, espera-se que as execues de tais atividades sejam
separadas por um marco, definido pela disponibilizao em um ambiente de testes
do pacote a ser testado. Isso viabiliza a alocao correta das horas nas atividades
de codificao, testes e correo.
69
Caso a atividade de testes no seja realizada ou caso um nico profissional seja

o responsvel por ambas as atividades, testes e codificao, e essas ocorrerem
simultaneamente, sem distino dos momentos, o modelo CEP-S no aplicvel.
A indistino do momento de execuo das atividades testes e codificao pode
acarretar indistino nos registros das horas, impossibilitando a obteno dos
dados para aplicao do modelo CEP-S.
Antes das primeiras investidas em um modelo de controle estatstico de processo
recomendado que a organizao execute a atividade de testes durante os projetos
de desenvolvimento de software. A atividade de testes pr-requisito para a
aplicao do modelo CEP-S no processo de Implementao. Segundo AppLabs
[2008], que discursa sobre o futuro dos testes de software, testes e garantia da
qualidade iro se tornar mais importantes e adicionaro maior valor medida que
adotarmos arquiteturas e tecnologias que do suporte ao negcio em seu objetivo
de trazer produtos e servios para o mercado to rpido quanto possvel, com o
mnimo de riscos.
Testes de Unidade: a atividade de testes de unidade, como j citado, se for executada pelo mesmo profissional que executa a codificao, deve ser considerada
como atividade de codificao e as respectivas horas de execuo alocadas na
categoria de codificao. Isso uma viso simplificada para aplicao do modelo
e completamente aderente ao RUP.
Caso a atividade de testes de unidade seja realizada por uma equipe distinta da
equipe de codificao ou pela mesma equipe, porm, em momentos separados por
um marco, o registro das horas de execuo dessa atividade pode ser realizado
na categoria de testes, distinto da codificao, como ocorre para os testes de
integrao, sistema ou aceitao.
Caso a atividade de testes de unidade no seja executada durante os projetos
de desenvolvimento de software no h necessidade de inclu-la, ela no um
pr-requisito para a aplicao do modelo CEP-S.
Projeto Arquitetural: caso a organizao execute indistintamente os processos Implementao e Projeto Arquitetural ainda assim possvel aplicar o controle
estatstico no processo de Implementao. Porm, como j citado, essa indistino pode distorcer a caracterizao das atividades do processo de Implementao
se as horas executadas no processo Projeto Arquitetural forem distribudas no
uniformemente entre os agrupadores. O ideal a organizao planejar a execuo
70
das atividades de forma a visualizar distintamente tais processos ou garantir que

a distribuio de cada uma por agrupador seja homognea.
4.2
Identificao das caractersticas de interesse
Caractersticas de interesse so medidas referentes ao desempenho dos processos, que

proveem informaes para a gesto estratgica e podem ser atributos dos produtos ou
dos processos, Florac & Carleton [2000]. A escolha adequada dessas caractersticas
um dos fatores de sucesso para o alcance dos objetivos estratgicos da organizao.
Este trabalho identifica um conjunto de caractersticas de interesse e apresenta um
mecanismo para guiar a organizao na seleo de um subconjunto de caractersticas,
dentre as propostas, aquelas que estiverem alinhadas aos objetivos estratgicos. O
mecanismo baseado na proposta de Goethert, Goethert & Fisher [2003], a partir do
guia Goal-Driven Software Measurement, conhecido como GQ(I)M, e do BSC. A Seo
4.2.1 apresenta as caractersticas de interesses e a Seo 4.2.2 apresenta o mecanismo
para a seleo de um subconjunto dessas caractersticas.
4.2.1
As Caractersticas de interesse
A definio das caractersticas de interesse foi feita com base na necessidade de se ter
medidas que refletissem o desempenho do processo, que tivessem alinhamento com os
objetivos estratgicos, que fossem factveis de serem coletadas e comparveis entre si
(normalizadas). Ressaltamos o comentrio de Montgomery, Montgomery [2004], sobre
a identificao das caractersticas de interesse, ao citar que, ... a aplicao de CEP
em software demanda criatividade na escolha das variveis a serem controladas... as
medidas precisam ter mais foco em processos que em produto. Essa afirmao considera a intangibilidade do produto final de software e a forte dependncia da produo
no fator humano. Porm, como vimos no Captulo Reviso bibliogrfica, a maioria dos
trabalhos encontrados, relacionados aplicao de CEP no desenvolvimento de software, define as caractersticas de interesse se restringindo taxa de defeitos ou taxa
de no-conformidades das revises, ou seja, com foco em produto e no nos processos. As caractersticas propostas constituem a terceira ideia estruturadora do modelo
CEP-S, visto que grande parte delas se baseiam no esforo (em horas ou minutos) realizado nas atividades e no no nmero de no-conformidades (defeitos), o que prov
informaes mais significativas e homogneas, alm de serem relativas ao processo e
no ao produto produzido. A figura 4.3 apresenta tais caractersticas, juntamente com
as medidas bsicas para suas derivaes.
4.2. Identificao das caractersticas de interesse
71
Figura 4.3: Caractersticas de interesse
Das caractersticas propostas, Defeitos Produo (DeP) e Defeitos Manuteno

(DeM) devem ser tratadas, para construo dos grficos de controle, como atributos
e as demais, como variveis. O motivo da distino entre varivel e atributo e seus
respectivos conceitos so apresentados no Captulo 3.
A taxa de defeitos, apesar de ser a caracterstica de interesse mais utilizada em
72
CEP de desenvolvimento de software, uma medida pouco significativa para a base de

estimativas da organizao, pois no homognea de forma a permitir comparaes
entre unidades de produo distintas. No possvel dizer que 500 defeitos em um
projeto de 100 pontos de funo ocasionaram um efeito pior, em termos de custo ou
prazo, que 50 defeitos em um projeto tambm de 100 pontos de funo. Isso porque
cada defeito demanda um esforo diferente para ser corrigido. Para permitir que o impacto do retrabalho (defeitos ou no-confirmidade) fosse significativamente refletido, as
caractersticas de interesse Retrabalho Produo (ReP), Retrabalho Manuteno Corretiva (ReM), Retrabalho Total (ReT) e Retrabalho Manuteno por Retrabalho Produo
(RMT) foram propostas. Elas so significativas por serem derivadas do esforo de execuo (horas ou minutos) e no do nmero de defeitos. Elas esto alinhadas a objetivos
estratgicos que visam reduzir o custo da qualidade, reduzir desperdcios e avaliar a
percepo do cliente/usurio em relao qualidade do produto. Outro aspecto importante dessas caractersticas que elas fornecem a viso de retrabalho tanto para
a fase de produo quanto para a fase de manuteno. No significativo avaliar a
qualidade do produto de software apenas para a fase de produo, imediatamente aps
disponibilizao do mesmo para o uso, no trmino do projeto. necessrio que a
fase de manuteno seja tambm avaliada pois, aps um perodo em uso, o qual pode
variar para mais ou menos tempo dependendo da intensidade desse uso, o software
apresenta defeitos que precisam ser considerados no custo do projeto e que afetam a
percepo da qualidade do produto pelo cliente. Logo, a caracterstica ReT pode ser
utilizada para o controle do esforo perdido com retrabalho na fase de produo. A
caracterstica ReM permite analisar a percepo de qualidade do produto pelo cliente,
quando esse utiliza o software por um perodo e identifica defeitos ou no adequao ao
uso. A caracterstica RMT permite avaliar se as aes de garantia da qualidade esto
sendo efetivas em detectar os defeitos e no conformidades durante a fase de produo
comparados com a fase de manuteno. E por fim, a caracterstica ReT avalia o esforo com retrabalho que a organizao despendeu com todo o projeto (produo e
manuteno).
A taxa de defeitos, mesmo sendo uma caracterstica de interesse pouco adequada
para CEP de desenvolvimento de software, devido insignificncia do resultado de
comparar seus valores entre as unidades de produto de software ou entre projetos na
organizao, ela pode auxiliar o gerente de projetos a acompanhar a situao dos defeitos e no conformidade durante a execuo dos projetos e a monitorar a percepo
do cliente quanto qualidade do produto. Por essas razes, as caractersticas Defeito
Produo (DeP) e Defeito Manuteno (DeM) compem o modelo CEP-S. A caracterstica DeP usada para analisar at quando o custo do esforo com as atividades
73
de testes vale o benefcio de encontrar mais um defeito. A caracterstica DeM usada

para analisar a percepo da qualidade do produto pelo cliente/usurio. Ambas as
caractersticas DeP e DeM podem ser usadas para analisar os tipos de defeitos, de
acordo com a frequncia de suas ocorrncias. O modelo CEP-S prope anlises mais
adequadas para a taxa de defeitos, indo alm do CEP, e sugestes significativas para
a classificao dos defeitos, o que permite aes de melhorias mais efetivas a partir de
informaes mais rigorosas de suas causas. Essas anlises e as classificaes propostas
so apresentadas na Seo 4.4 do presente Captulo.
Algumas caractersticas foram propostas com o objetivo de apoiar a organizao a
conhecer e melhorar suas estimativas, ou seja, ter maior previsibilidade no planejamento
de suas atividades: Participao Processo Produo (PPP), Participao Processo Total (PPT), ndice de Capacidade do Processo (ICP) e ndice Erro Estimativa (IEE).
As caractersticas PPP e PPT objetivam fornecer uma anlise de como o processo participa, em porcentagem de esforo, da produo do software, seja apenas para a fase de
produo (PPP) ou considerando todo o esforo de produo e manuteno do software
(PPT). Essa anlise apoia a construo de bases de estimativas para o planejamento
dos projetos e tambm para a projeo e balanceamento de recursos humanos em cada
um dos perfis necessrios para o desenvolvimento de software. A caracterstica ICP
indica como o processo est se comportando em relao especificao. Para que essa
caracterstica seja utilizada necessrio os limites de controle de especificao, sejam
eles definidos pelo cliente ou por alguma norma ou mesmo da alta gerncia da organizao. A caracterstica IEE indica quo boas esto sendo as estimativas de esforos
por processo, o qual compara o realizado versus o planejado.
Por fim, as caractersticas Produtividade Produo (PrP) e Produtividade Total
(PrT) visam apoiar a organizao no controle da produtividade. PrP a produtividade
durante a produo e a caracterstica PrT a produtividade total, que considera o
esforo de execuo das atividades nas fases produo e manuteno.
4.2.2
Seleo das caractersticas de interesse
A presente Seo apresenta um mecanismo para guiar a seleo de um subconjunto de

caractersticas, dentre as propostas na Seo anterior, aquelas que estiverem alinhadas
aos objetivos estratgicos da organizao. O mecanismo baseado na proposta de
Goethert, Goethert & Fisher [2003], que utiliza o guia GQ(I)M e o BSC. Apresentamos o conceito do Guia GQ(I)M, de objetivos estratgicos, do BSC e um exemplo da
aplicao desses s Caractersticas de Interesse definidas. Por fim, apresentamos uma
viso de como o CEP-S se integra proposta de Goethert.
74
4.2.2.1
O guia Goal-Driven Software Mensurement
O guia GQ(I)M foi proposto por Park, Park et al. [1996]. Ele define que a escolha das
caractersticas de interesse seja feita a partir dos objetivos estratgicos que a organizao pretende atingir e no a partir das medidas em si. uma extenso do paradigma
Goal-Question-Metric (GQM), Basili [1993], e uma das propostas mais simples e extensivamente referenciada na literatura, para o processo de seleo de medidas.
O guia baseado em trs preceitos e consiste de dez passos. Os trs preceitos
consistem nos objetivos de medio serem derivados de objetivos de negcio; no uso
de modelos mentais para prover contexto e foco; e no uso do GQ(I)M para traduzir os
objetivos informais em uma estrutura executvel de medio. Os dez passos so:
1. Identificar seus objetivos estratgicos;
2. Identificar o que voc deseja aprender ou conhecer;
3. Identificar os sub-objetivos, derivados de seus objetivos de negcio;
4. Identificar as entidades e atributos relacionados aos sub-objetivos;
5. Formalizar os objetivos de medio;
6. Identificar as questes mensurveis e os respectivos indicadores;
7. Identificar os elementos de dados a serem coletados para a elaborao de indicadores;
8. Definir as medidas a serem usadas;
9. Identificar aes para a implementao dos processos de medio;
10. Elaborar um plano de medio.
Os passos iniciais, de 1 a 4, correspondem s atividades que geram os insumos
para a definio dos objetivos de medio e so dependentes dos objetivos estratgicos
da organizao. Os objetivos de negcio devem representar os objetivos estratgicos da
organizao. Os passos seguintes, de 5 a 8, correspondem ao GQ(I)M. Os passos finais
visam criar a estrutura para a operacionalizao das medies. A figura 4.4 apresenta
o modelo mental para os passos de 1 a 8.
75
Figura 4.4: Goal-Driven Software Measurement
4.2.2.2
Objetivos Estratgicos e o Balanced Scorecard
Por trs de uma empresa de sucesso existe uma estratgia eficaz. Os gerentes podem ter desenvolvido
tal estratgia por meio de anlises formais, de tentativa e erro, intuio ou at mera sorte.
Independentemente de como tenha surgido, a estratgia sustenta o sucesso de qualquer empresa.
Obviamente, as empresas precisam desenvolver ou adquirir o conhecimento e as habilidades necessrias
para que suas estratgias deem certo.
Cusumano & Markides [2002]
A seleo das caractersticas de interesse deve considerar os objetivos estratgicos

da organizao. Cusumano, Cusumano & Markides [2002], relata haver uma falta de
consenso, tanto no meio acadmico quanto no empresarial, para definir o que estratgia e qual o processo ideal de desenvolvimento de uma boa estratgia. Afirma ainda
que a elaborao de uma estratgia bem-sucedida no uma cincia e sim uma arte.
a arte de fazer perguntas inteligentes, explorar as possveis respostas, experimentar as
possveis solues e reiniciar o processo de desenvolvimento, questionando constantemente as respostas obtidas. Consideramos a definio de Wright, Wright et al. [2000],
que se refere estratgia como os planos da alta administrao para alcanar resultados
76
consistentes com a misso e os objetivos gerais da organizao. Pode ser visto como o
planejamento, a implementao e o controle estratgico. A figura 4.5 apresenta esses
processos e suas principais entradas e sadas. uma viso simplificada, evidenciando
apenas elementos importantes para o entendimento geral da estratgia. A tabela 4.2
apresenta o detalhamento desses elementos.
Figura 4.5: Estratgia
A estratgia pode ser traduzida em um conjunto coerente de medidas de desempenho a partir do uso do BSC. O BSC, segundo Kaplan, em Kaplan & Norton [1997],
um carto de resultados equilibrado, uma ferramenta gerencial que permite equilibrar, monitorar e controlar o desempenho empresarial a partir da definio de medidas
de desempenho em quatro perspectivas: a financeira, a do cliente, a dos processos
internos e a do aprendizado e crescimento.
As empresas podem adotar o BSC como um sistema de gesto estratgica para
administrar a estratgia a longo prazo e viabilizar processos gerenciais crticos, como
esclarecer e traduzir a viso e a estratgia, comunicar e associar objetivos e medidas
estratgicas, planejar, estabelecer metas e alinhar as iniciativas estratgicas e melhorar
o feedback (a realimentao) e o aprendizado estratgico. A organizao pode ter
estratgias diferentes para cada unidade de negcio e diferir de acordo com a fase do
ciclo de vida de crescimento, sustentao ou colheita. Abaixo, apresentamos exemplos
de indicadores para cada perspectiva e ciclo de vida, de acordo com o autor citado:
Financeira: empresas em crescimento encontram-se nos estgios iniciais de seus ciclos de vida. Os objetivos financeiros so: aumentar receita lquida e aumentar
77
Processo: Planejamento
Entradas
Atividades
Misso e viso or- Analisar o ambiente interno (fraquezas
ganizacional; fatores e foras) e externo (ameaas e opordo ambiente interno tunidades); definir as direes; estabee externo.
lecer objetivos, metas e aes; definir
indicadores de desempenho
Processo: Execuo
Entradas
Atividades
Plano Estratgico
Executar as aes definidas; manter
toda a organizao engajada; coletar
indicadores.
Processo: Controle
Entradas
Atividades
Indicadores de De- Controlar a execuo; reavaliar, semsempenho
pre, os resultados obtidos e as alteraes nos fatores internos e externos; replanejar caso necessrio
Sadas
Plano Estratgico
Sadas
Indicadores
de Desempenho
Sadas
Replanejamentos
Tabela 4.2: Processos da estratgia
vendas. Empresas em sustentao ainda conseguem atrair investimentos mas

precisam obter excelentes retornos sobre o capital investido, manter ou aumentar a participao no mercado. Os objetivos financeiros so: maximizar lucro,
maximizar fluxos de receita e aumentar retorno de investimento. Empresas em
colheita so aquelas onde investimentos significativos no se justificam. Os objetivos financeiros so: maximizar o fluxo de caixa e diminuir da necessidade de
capital de giro.
Cliente: atualmente as empresas precisam identificar os segmentos de clientes e mercado nos quais desejam competir para oferecer produtos e servios melhores alinhados s preferncias desses segmentos. Os indicadores propostos so: participao de mercado, captao de clientes, reteno de clientes, satisfao dos clientes, lucratividade dos clientes. Para esses indicadores Kaplan & Norton [1997]
define trs classes de atributos: atributos de produtos e servios (funcionalidade,
qualidade e preo), atributos de relacionamento com o cliente ( qualidade da experincia de compra e das relaes pessoais) e atributos de imagem e reputao.
Processos Internos: os processos internos podem ser inovaes, operaes e servios
de ps venda. Os indicadores devem ser definidos de modo a identificar problemas
de qualidade que afetam o custo do produto ou servio, a capacidade de resposta
78
ou o nvel de satisfao do cliente. Alguns exemplos: taxa de defeitos em peas

por milho(por processo), ndice de acerto (quociente de itens corretos produzidos em relao a itens corretos processados), desperdcio, perdas, retrabalho,
devolues, percentual de processos sob controle estatstico.
Aprendizado e Crescimento: essa perspectiva orienta o aprendizado e o crescimento organizacional e foi apresentada pelo autor em trs categorias: capacidade
dos funcionrios (satisfao, reteno e produtividade), capacidade dos sistemas
de informao (percentual de processos que oferecem feedback em tempo real sobre qualidade, tempo e custos, percentual de funcionrios que lidam diretamente
com o cliente e tm acesso on-line s informaes referentes a eles) e motivao,
autoridade (empowerment) e alinhamento (sugestes apresentadas e implementadas, melhorias, alinhamento individual e organizacional, desempenho da equipe).
4.2.2.3
Associao das caractersticas de interesse aos objetivos estratgicos
A Figura 4.6 apresenta um exemplo do uso do mapa estratgico BSC para associar as
caractersticas de interesse aos objetivos estratgicos propostos por Kaplan, em Kaplan
& Norton [1997]. Segundo Kaplan, tais objetivos aparecem na maioria dos scorecards 1
das empresas, podendo, portanto, representar a estratgia de uma organizao alvo da
aplicao do modelo CEP-S. Os indicadores evidenciados em cinza so os propostos
pelo modelo CEP-S e os demais, em branco, so apenas complementao do BSC e
no fazem parte do modelo de controle estatstico.
Como esse um exemplo, baseado em objetivos estratgicos genricos, espera-se
que a organizao incorpore objetivos prprios e elimine os objetivos que no representam a estratgia organizao, para ento selecionarem as caractersticas de interesse a
partir dos objetivos resultantes. A partir do mapa estratgico possvel avaliar se h
alinhamento entre a aplicao do modelo CEP-S e a estratgia da organizao alvo de
CEP.
A coluna da esquerda, Objetivos Estratgicos, lista objetivos estratgicos para
as quatro perspectivas do BSC, sugeridos por Kaplan em Kaplan & Norton [1997].
A coluna Indicadores lista indicadores propostos neste trabalho para cada objetivo
estratgico. Um objetivo estratgico pode ser monitorado por um ou mais indicadores.
Um exemplo o objetivo Reduzir o Custo da Qualidade, cuja proposta de monitorao
pode ser pelos indicadores ReT (retrabalho total), ReM (retrabalho em manuteno),
ReP (retrabalho em produo), RMP (retrabalho em manuteno por retrabalho total),
ou DeM (defeitos em manuteno). Um indicador pode monitorar um ou mais objetivos
1
Cartes de Resultados
79
Figura 4.6: Mapa estratgico BSC
estratgicos, como o exemplo dos indicadores ReT e ReM. Um indicador pode ser
sintetizado a partir de outros indicadores do prprio BSC, sendo a sntese realizada
na perspectiva vertical, dos indicadores inferiores (de aprendizado e crescimento) para
gerarem indicadores superiores (na direo da viso financeira).
80
4.2.2.4
Viso integrada das ferramentas
Segundo Goethert, Goethert & Fisher [2003], as metodologias GQ(I)M e BSC so bem
definidas, mas o mais comum encontrar aplicao das mesmas em separado. Ele
sugere combin-las, absorvendo o melhor de cada uma. A abordagem GQ(I)M uma
forma disciplinada de derivar os requisitos de mensurao e os indicadores a partir
dos objetivos estratgicos. Combinada abordagem BSC, a organizao ir definir
os objetivos para as quatro perspectivas: financeira, do cliente, dos processos internos
e do aprendizado e crescimento. Estendemos o arcabouo de Goethert, incluindo o
modelo CEP-S, que sugere indicadores prprios para processos de desenvolvimento de
software e modelos para analis-los estatisticamente. A Figura 4.7 exibe a abordagem
extrada de Goethert, Goethert & Fisher [2003], que a integrao do GQ(I)M ao BSC,
estendida com o modelo CEP-S.
4.3
Planejamento e execuo das medies
Esta seo apresenta o modelo Practical Software and Systems Measurement: A Foundation for Objective Project Management (PSM) como sugesto de referncia para as
organizaes que desejarem formalizar o processo de medio. Esse modelo tem como
objetivo estabelecer um conjunto de prticas e ferramentas para auxiliar o gerenciamento dos projetos atravs de indicadores de prazo, custo e qualidade. O planejamento
de polticas de medio, segundo o guia PSM, PSM [2003], envolve os passos descritos
a seguir. Os passos 1 e 2 correspondem ao que foi apresentado nas sees 4.1 e 4.2, respectivamente. O modelo CEP-S no prope nenhum diferencial para os demais passos,
visto que seu foco no em um modelo de medio. Deixamos a cargo da organizao
a escolha do melhor mecanismo de planejamento e execuo das medies. Porm, o
PSM evidenciado como um modelo para apoiar esses processos, por serem cruciais
para o sucesso da aplicao de CEP. A organizao precisa ter a capacidade de planejar e executar eficientemente um plano de medio, para que os dados disponibilizados
para anlise sejam confiveis.
O guia PSM enderea quatro grandes atividades:
Tailoring (personalizao): as medidas de software so personalizadas para as questes especficas do projeto. As atividades do Tailoring correspondem aos passos
1, 2 e 3 apresentados abaixo;
Aplicao : as medidas so convertidas em informaes teis. As atividades da
aplicao correspondem aos passos 4, 5 e 6 apresentados abaixo e so atividades
4.3. Planejamento e execuo das medies
81
Figura 4.7: Viso integrada das 3 ferramentas
repetidas periodicamente ao longo do ciclo de vida de um projeto;

Implementao : os processos de medio so implementados. As atividades correspondem aos passos 7, 8 e 9 apresentados abaixo;
Avaliao : o programa de medio avaliado. As atividades correspondem ao passo
10 apresentado abaixo.
Tais atividades so tratadas detalhadamente nos 10 passos seguintes:
1. Identificar e priorizar as necessidades de informao :
Inicialmente as
questes do projeto so identificadas e priorizadas. Elas so derivadas de informaes do projeto, da experincia da gerncia, das avaliaes dos riscos, entre
82
outros fatores. Nessa etapa a elaborao do plano de medies deve ser iniciada.
Ele deve conter informaes como: os dados a serem acessados, quando eles estaro disponveis, o formato de entrada, a ferramenta (ou software) a ser usado
para armazenamento e os responsveis pela coleta e anlise.
2. Selecionar e especificar as medidas adequadas : O segundo passo selecionar e detalhar as medidas que endeream as questes identificadas. O detalhamento das medidas deve abordar informaes como:
Itens de Dado: como exemplo de itens de dados temos: (i) para marcos, as
datas de incio e fim das atividades; (ii) para esforo, as horas trabalhadas;
(iii) para linha de cdigo, o item de dado finalizado por um ponto e vrgula;
Atributo: so as caractersticas associadas s medidas. Como exemplo temos: nome da organizao, verso do sistema, prioridade de um defeito,
causa de um defeito, nome de um caso de teste;
Estrutura de agregao: as medidas so usualmente geradas em uma estrutura de baixo nvel e agrupadas em nveis mais elevados por componentes.
Essa estrutura de componentes ou agrupamento deve ser definida;
Nvel de Coleta: para dar suporte s anlises, os dados devem ser coletados
em um nvel que permita que os problemas sejam isolados e entendidos.
Esse item deve descrever o menor nvel necessrio em que um dado deva ser
coletado;
Critrio de Contagem: cada medida deve especificar quando um item
contado. Um exemplo: para a contagem de nmero de defeitos reportados e
fechado, deve-se especificar o que se entende por fechado, ou seja, que tenha
sido excludo do software e passou pelo critrio de qualidade.
3. Integrar medies nos processos tcnicos e gerenciais : Os passos 1 e 2 dizem o que o projeto precisa conhecer. O passo 3 diz como os processos de medio
devem funcionar no contexto do atual projeto. Para isso feita a caracterizao
do ambiente do projeto (os processos do projeto e o ciclo de vida do ambiente);
em seguida realizada a identificao das oportunidades de medio; por fim,
os requisitos para implementao das medies so especificados. Dentre os requisitos de especificao de medidas citamos: definio das medidas, escopo das
medies, coleta de dados, anlise de dados, reporte dos resultados, avaliao das
medies.
4.3. Planejamento e execuo das medies
83
4. Coletar e processar os dados : O primeiro passo da atividade Aplicao de Medidas a coleta e o entendimento dos dados. Dados vlidos so a base para os
processos de medies. Os resultados das medidas dependem de entradas confiveis dos dados. Aps a coleta dos dados uma verificao ser deve realizada para
garantir a acurcia e a fidelidade com a qual eles foram transmitidos. Todos os
dados devem ser identificados com a respectiva coleta e a origem. A comunicao
clara sobre os itens de dados, a conformidade com os termos bvios e as suposies devem ser verificadas e divulgadas pois ajudam a manter a consistncia
dos mesmos. Ainda antes de analisar as questes necessrio normalizar os dados, que corresponde a convert-los em uma unidade comum de medida ou nvel
de agrupamento que possa ser comparado ou combinado com outros dados. As
regras e os procedimentos de normalizao devem ser documentados.
5. Analisar as questes : Analisar os dados a tarefa de convert-los em informaes teis, usadas nas tomadas de deciso. Nas fases iniciais dos projetos o foco
da anlise nas estimativas de tamanho, esforo e cronograma. As Estimativas
so produzidas inicialmente a partir de dados histricos e suposies dos especialistas. Em seguida, a anlise de viabilidade trata dos riscos e do quo realsticos
esto os objetivos e metas estabelecidos para o projeto. Uma vez que o projeto
esteja planejado e aprovado pelos responsveis a partir da anlise de viabilidade,
necessrio realizar a anlise de desempenho do projeto, ao longo de sua execuo.
Essa anlise determina se a execuo est alcanando os resultados planejados.
6. Fazer recomendaes : O propsito maior das anlises prover informaes para
a tomada de deciso, identificando e avaliando alternativas que devem ser recomendadas aos responsveis por aes corretivas, preventivas ou de melhorias. O
objetivo da atividade de fazer recomendaes maximizar a probabilidade de
sucesso do projeto. As anlises dos resultados devem ser comunicadas regularmente, juntamente com recomendaes de aes para todos os integrantes da
equipe do projeto.
7. Obter suporte da organizao : Implantar polticas de medies quase sempre
requer mudanas de cultura organizacional. Tais mudanas podem causar incertezas e ansiedades nos profissionais da organizao. Uma forma de contornar essa
questo comunicar claramente os objetivos e processos de medies, para que
os resultados sejam usados em todos os nveis organizacionais. A atividade de
suportar a organizao envolve definir as polticas de medio, prover os recur-
84
sos necessrios, estabelecer os objetivos de comunicao e os fatores crticos de

sucesso, revisar e analisar os dados medidos e tomar aes recomendadas.
8. Definir responsabilidades : A equipe responsvel pelas tarefas de medies deve
ser definidos. O tamanho dessa equipe depende do porte organizacional e as tarefas podem ser segmentadas entre os membros. Como sugesto dada pelo PSM,
cada segmento pode ter um responsvel da equipe. Um modelo de segmentao
apresentado abaixo:
Polticas, planos e definies das medies;
Gerao dos dados;
Repositrio de medidas;
Anlise e reporte dos resultados.
9. Prover recursos : Os recursos para o processo de medio incluem recursos humanos e ferramentas para gerar, processar, analisar e reportar os dados. Quando
o nvel de maturidade dos processos organizacionais maior, esperado que a
organizao tenha uma estrutura comum para os processos de medio, compartilhado entre projetos. Caso a organizao no tenha tal estrutura, no h
compartilhamento de estrutura e cada projeto arca com os custos e os esforos
de criar e manter a estrutura de medio para o projeto.
10. Avaliar as medies : necessrio no s avaliar as medidas e indicadores como,
regularmente, os processos de medio. Essa atividade inclui quatro tarefas, que
so:
Avaliar as medidas e indicadores para saber se eles satisfazem as necessidades
de informao;
Avaliar os processos de medio examinando a eficcia do desempenho, a
conformidade com o plano de medio e a capacidade (maturidade) em
relao aos padres;
Atualizar a base de conhecimento com as lies aprendidas das avaliaes
das medies dos processos e dos produtos;
Identificar e implementar melhorias.
Dois grandes desafios precisam ser assumidos pelas organizaes candidatas a
colocarem em prtica o controle estatstico: a elaborao e execuo efetiva de um
4.4. Construo dos grficos de controle
85
plano de medies que resulte em dados confiveis para as anlises e a execuo de

melhorias de processos, para a estabilizao dos mesmos, a partir das indicaes de
existncia de causas atribuveis, pelos grficos de controle. A aplicao do modelo
CEP-S no produzir efeito real enquanto esses dois desafios no forem superados.
Ao planejar o controle estatstico, a organizao deve planejar controles distintos
para projetos no semelhantes, pois dados de projetos no semelhantes no so normalizveis (comparveis entre si). Por exemplo, no significativo realizar o controle
estatstico com dados de projetos cujas linguagens ou framework de desenvolvimento
sejam diferentes. Tambm no significativo se, mesmo com linguagem e framework
iguais, as funcionalidades so de complexidade muito distintas, com exemplo um sistema cujas funcionalidades construdas contm muitos clculos, grficos e relatrios
complexos versus um sistema simples de cadastros bsicos.
4.4
Construo dos grficos de controle
Esta Seo apresenta um mecanismo para a escolha dos grficos de controle de acordo
com os dados que foram coletados, a definio dos parmetros de controle e dos testes de
estabilidade. Grficos de controle so ferramentas usadas para monitorar visualmente
a estabilidade dos processos. Eles devem ser planejados de forma a serem eficientes
em detectar rpida e confiavelmente condies de fora-de-controle. Esse planejamento
envolve a definio dos limites de controle, do tamanho da amostra, da frequncia da
amostragem e dos testes de estabilidade. O modelo CEP-S prope utilizar os grficos
e MMEP combinados, para quando a caracterstica de interesse for tipo varivel,
X-I
sendo essa a quarta ideia estruturadora desse modelo. Se a caracterstica de controle
for tipo atributo o grfico adequado o u.
mais eficiente para monitorar desvios maiores que 1,5 . Ele
O grfico X-I
no pode ser utilizado quando houver autocorrelao, mesmo que fraca, e quando
a distribuio dos dados amostrais for diferente de normal. Ento, para seu uso,
necessrio ter o coeficiente de Pearson 0 para o teste de autocorrelao e o P-valor
> 0.005 para o teste de normalidade.
O grfico MMEP mais eficiente para desvios menores que 1,5 . Ele menos
sensvel normalidade, logo, no depende dos dados amostrais terem uma distribuio
normal. Ele pode ser utilizado ainda que exista autocorrelao moderada ou fraca, mas
no indicado para autocorrelao forte pois pode apresentar muitos alarmes falsos.
Ento, para seu uso necessrio ter o coeficiente de Pearson < 0.70 para os testes
de autocorrelao. A Figura 4.8 apresenta o diagrama de deciso para as situaes
86
descritas.
Figura 4.8: Digrama de deciso para grfico de controle
As frmulas subjacentes aos grficos X-I,

MMEP e u foram apresentadas no
Captulo 3, O controle estatstico de processo (CEP), assim como a justificativa dos
valores indicados na Figura 4.9 para os parmetros de controle.
Figura 4.9: Parmetros de controle
As caractersticas de interesse DeP (defeitos em produo) e DeM (defeitos em

manuteno) devem ser tratadas como atributos e usar o respectivo grfico para atributos. A caracterstica de interesse ICP um parmetro adimensional que indiretamente
mede o quanto o processo consegue atender s especificaes, Costa et al. [2008], no
monitorada por grficos de controle. As caractersticas de interesse ReP (retrabalho em produo), ReM (retrabalho em manuteno), ReT (retrabalho total), RMP
(retrabalho em manuteno por retrabalho total), PrP (produtividade em produo),
4.4. Construo dos grficos de controle
87
PrT (produtividade total), PPP (participao do processo em produo), PPT (participao do processo total) devem ser tratadas como variveis e usar os respectivos
grficos para variveis.
O modelo CEP-S formula as principais caractersticas de interesses a partir do
esforo (em horas ou minutos) de execuo nas atividades dos processos alvos. um
diferencial, visto que as caractersticas formuladas so mais significativas que nmero
de defeitos (ou no-conformidades), comumente usado em CEP de desenvolvimento de
software. Porm, ainda assim, o modelo considera o nmero de defeitos para derivar as
caractersticas DeP e DeM. Isso se deve ao fato de elas apoiarem o gerente de projetos
durante a execuo das atividades de testes e o cliente na percepo da qualidade do
produto final. Para essas caractersticas propomos dois grficos, complementares aos
grficos de controles: grfico de custo x benefcio e um histograma de tipos de defeitos.
O grfico Custo Benefcio usado durante a execuo das atividades de testes,
para analisar at quando o custo do esforo com as atividades de testes vale o benefcio
de encontrar mais um defeito (ou no-conformidade). O grfico construdo a partir
da soma cumulativa do nmero de defeitos encontrados por hora de esforo despendido
para encontr-los versus as soma cumulativa das horas. O gerente do projeto pode
decidir, a partir do resultado do grfico, suspender as atividades de testes quando o
esforo despendido para encontrar mais um defeito no for mais benfico. Tendo em
vista que o resultado desse grfico busca uma correlao entre o esforo de reviso e
o esforo de correo, uma anlise complementar pode ser realizada para verificar se o
esforo realizado com reviso est sendo eficiente, ou seja, tem correlao com o esforo
realizado para correes.
O histograma usado para analisar quais defeitos, por processo, so mais recorrentes. Ele pode ser construdo para duas perspectivas: do projeto ou da organizao.
Para construir o histograma a organizao deve classificar o defeito, aps a sua correo, de acordo com o que foi a causa origem. comum organizaes classificarem os
defeitos de forma muito simples, como baixo, mdio, alto e crtico, para as caractersticas de severidade e prioridade, Kelly & Shepard [2001]. Essa classificao simples no
auxilia a definio de aes para evitar ou reduzir recorrncias futuras, preciso saber
mais sobre os defeitos. Uma forma de obter mais informaes usar uma classificao
significativa. A Figura 4.10 apresenta a classificao proposta pelo modelo CEP-S.
O nvel de detalhes da classificao deve ser tal que permita a organizao entender o problema e tomar aes de melhorias e no pode ser detalhado a ponto de
dificultar o uso. A classificao proposta neste trabalho deve ser revisada pela organizao, para que atenda s suas necessidades especficas. Indicamos trabalhos que
podem auxiliar a organizao no propsito de definir as categorias para classificao de
88
Figura 4.10: Classificao de defeitos
defeitos, que so: Kelly & Shepard [2001], Chillarege et al. [1992], Emam & Wieczorek
[1998] e IEEE [1995].
4.5
Estabilizao dos processos
A Figura 4.11 apresenta as atividades para a estabilizao de um processo. O objetivo

maior delas a eliminao das causas atribuveis, pr-requisito para a aplicao do CEP.
Somente aps o processo estar estvel possvel definir adequadamente os parmetros
de controle. Porm, a organizao nem sempre conseguir eliminar as causas atribuveis
e levar o processo a uma situao de estabilidade, inviabilizando assim a aplicao do
modelo CEP-S.
Figura 4.11: Atividades para estabilizar o processo
A organizao seleciona o processo alvo de controle, identifica as caractersticas

de interesse, planeja e executa as medies e constri os grficos de controle apropriados. Nesse momento, os limites de controle calculados podem ser inadequados para a
4.6. Controle estatstico dos processos
89
rotina de CEP, devido a possvel presena de causas atribuveis, porm, a organizao

poder us-los para testar a existncia dessas causas. Caso pontos fora-de-controle
sejam identificados a organizao deve investigar a causa raiz de tais pontos, planejar
e executar aes para eliminar seu efeito e evitar futuras ocorrncias, excluir os pontos
da amostra e recalcular os limites de controle para o restante da amostra. necessrio
executar esse loop at que no haja mais causas atribuveis, aonde os limites de controle
so recalculados e assumidos para o CEP.
Em casos de amostragem para avaliar a estabilidade do processo temos duas
hipteses possveis:
H0 : Processo em controle ( = 0 )
H1 : Processo fora-de-controle ( 6= 0 )
Onde 0 o valor-alvo ou valor mdio em controle da varivel aleatria X.
Quando h de antemo um valor-alvo definido, mais apropriado falar em valoralvo. Quando o valor de 0 no definido a priori mais apropriado utilizar a expresso
valor mdio(ou valor mdio em controle).Costa et al. [2008]
A eliminao das causas atribuveis realizada a partir de aes de melhorias.
Essa uma atividade complexa e bastante susceptvel ao fracasso se as aes de melhorias no forem efetivas. Aps a excluso dos pontos fora-de-controle, se o restante
da amostra formar um conjunto pequeno, de poucos pontos, ser necessrio aguardar
a coleta de mais pontos antes de dar continuidade s atividades de estabilizao.
4.6
Controle estatstico dos processos
Executadas as atividades previstas nas Sees de 4.1 a 4.5 espera-se que os processos
estejam estveis, os grficos construdos e a organizao apta a iniciar as atividades
que visam o controle estatstico. Essas atividades so apresentadas na Figura 4.12:
O controle estatstico constitudo de um loop das atividades: coletar dados,
plotar dados, testar o controle, investigar causas atribuveis, excluir pontos fora-decontrole da amostra e aplicar aes de melhorias. Esse loop deve ser executado at
que alguma ao de melhoria, cujo foco seja ir alm da eliminao das causas atribuveis, seja aplicada ao processo e cause a alterao dos parmetros de controle. Como
exemplo dessas aes podemos citar a insero de automaes, a melhoria na qualidade dos insumos e a capacitao tcnica dos profissionais. Essas aes no enfocam
na eliminao de causas atribuveis, mas sim na elevao do nvel de maturidade dos
processos. No momento aps as melhorias os parmetros de controle (mdia e desvio
90
Figura 4.12: Controle Estatstico de Processo
padro) devem ser recalculados o que permite quantificar facilmente tais melhorias a
partir da comparao dos parmetros antes e depois sua realizao.
Os parmetros do controle estatstico de um processo so vlidos para dados coletados a partir da execuo do processo em uma determinada verso. Caso o processo
alvo de controle seja alterado (evoludo), uma nova verso do controle deve ser definida,
com os parmetros de controle recalculados.
Captulo 5
Estudo de caso
Os estudos empricos verificam a previso terica de encontro realidade, no buscam provas absolutas.
Travassos et al. [2002]
O estudo de caso uma estratgia de pesquisa emprica, onde ocorre uma observao da realidade, de projetos e atividades, sem interveno sistemtica do pesquisador,
Wazlawick [2008], onde os dados so coletados com um propsito especfico e os resultados documentados. Os resultados de um estudo de caso podem ser analisados a
partir de um paradigma qualitativo ou quantitativo ou a partir de ambos.
O propsito do presente estudo verificar a viabilidade de aplicao do Modelo
CEP-S a processos de desenvolvimento de software do Laboratrio Synergia, comparando os estados dos processos antes e depois da aplicao do modelo. A realizao
deste estudo foi possvel devido ao patrocnio do Laboratrio Synergia, que colocou
disposio os dados para anlise. O Synergia o laboratrio de Engenharia de Software e Sistemas do Departamento de Cincia da Computao da UFMG que oferece
servios de desenvolvimento de sistemas, implantao de processos, consultoria em TI
e treinamentos diversos.
Este Captulo apresenta-se dividido em trs sees. A Seo 5.1 apresenta os
resultados da aplicao do Modelo CEP-S aos processos do Laboratrio Synergia. A
Seo 5.2 apresenta uma anlise dos resultados registrados na Seo anterior. E, finalmente, a Seo 5.3 apresenta concluses sobre a aplicabilidade do Modelo CEP-S.
5.1
Aplicando o Modelo CEP-S
A seleo dos processos e a identificao das caractersticas de interesse foram realizadas de acordo com o Modelo CEP-S e os dados j coletados do Laboratrio Synergia. A
91
92
Captulo 5. Estudo de caso
aplicao no se restringiu apenas s caractersticas alinhadas os objetivos estratgicos

da organizao, visto que o objetivo do presente estudo de caso validar a proposta.
O modelo CEP-S prope CEP para os processos de Requisitos e Implementao, porm o Laboratrio Synergia coleta o esforo, em horas, distintos para os processos de
Detalhamento de Requisitos, Identificao de Requisitos, Desenho Externo e Implementao. Logo, foi possvel estender o modelo CEP-S e aplic-lo para cada um dos
quatro processos. Dentre as caractersticas de interesse propostas, foram utilizadas,
para cada um dos 4 processos, o Retrabalho em Produo (ReP), a Produtividade em
Produo (PrP), a Participao do Processo em Produo (PPP) e os Defeitos em Produo (DeP). Para cada uma dessas caractersticas, so realizados/construdos: o teste
de autocorrelao, o teste de correlao entre o esforo realizado em reviso e o esforo
realizado em correo, o teste de normalidade e os grficos de controle pertinentes
situao de cada caracterstica.
Os grficos de controle de variveis foram construdos a partir do Diagrama de
Deciso da figura 4.8 e dos parmetros de controle da figura 4.9. A estabilizao
dos processos se baseou nas atividades da figura 4.11. A etapa de estabilizao foi
executada aps algumas adaptaes para este estudo de caso. Os dados originaram-se
de um base histrica recente e no de uma coleta em tempo de execuo do controle.
No houve investigao de causas atribuveis nem aplicao de aes de melhorias nos
processos. Essas adaptaes so plausveis de serem aplicadas ao estudo de caso, mas
devem ser feitas apenas nesse contexto, visto que com elas os processos permanecem
instveis.
Como a investigao de causas atribuveis e as aes de melhorias no foram
executadas, a excluso dos pontos fora-de-controle fictcia. Ela foi utilizada para
prever o resultado do que seriam os valores da situao sob controle dos processos
estveis. Tais parmetros s podem ser assumidos em uma situao real se as causas
atribuveis que geraram os pontos fora-de-controle forem eliminadas do processo. Para
obter os valores finais dos parmetros partimos da construo de um primeiro grfico
de controle, e em seguida, iniciamos um ciclo de excluso dos pontos plotados fora dos
limites de controle e gerao de um novo grfico. Esse ciclo foi executado at no haver
mais plotagem de pontos fora dos limites de controle, chegando assim a uma situao
fictcia de processo estvel.
Os dados utilizados nesse estudo de caso foram descaracterizados, atravs da
multiplicao deles por valores racionais, de modo a manter as curvas dos grficos
com dados descaracterizados fiis s curvas dos grficos originais e, ao mesmo tempo,
manter a confidencialidade das informaes estratgicas do Laboratrio Synergia.
O resultado da aplicao do Modelo CEP-S aos processos do Laboratrio Sy-
5.1. Aplicando o Modelo CEP-S
93
nergia apresentado a seguir. Para cada caracterstica de interesse, so apresentados

o teste de autocorrelao, o teste de correlao do esforo realizado em reviso e o
esforo realizado em correo, o teste de normalidade, se pertinente, os pontos fora-decontrole excludos e apenas o primeiro e o ltimo dos grficos de controles construdos.
Os grficos intermedirios do ciclo de excluso dos pontos fora-de-controle no so exibidos. Para identificao dos grficos, usaremos a nomenclatura [ID do processo-ID
da caracterstica] ID do grfico, onde:
ID do processo pode assumir:
IR Identificao de Requisitos;
DR Detalhamento de Requisitos;
DE Desenho Externo;
IM Implementao;
ID da caracterstica pode assumir:
ReP Retrabalho em Produo;
PrP Produtividade em Produo;
PPP Participao do Processo em Produo;
DeP Defeitos em Produo;
ID do grfico pode assumir:
Teste de normalidade;
MMEP;
X-Bar I;
U.
O valor absoluto do coeficiente de correlao de Pearson para 0 < 0, 4
representa uma correlao fraca, para 0, 4 < 0, 7 moderada e para 0, 7
1 forte, Shimakura [2006]. Para 0, 09 a correlao pode ser considerada no
I de Shewhart, Junior & ten Caten
significativa, permitindo assim o uso do grfico X
[2004]. Como resultado do teste para distribuio normal, esperamos um P-Valor >
0,005. Apresentamos novamente as referncias usadas para os testes de correlao
e normalidade como forma de facilitar a avaliao do estudo de caso, porm, essas
referncias, assim como as referncias para a escolha dos parmetros e dos grficos de
controle e as respectivas justificativas so apresentadas em detalhe no Captulo 3.
94
5.1.1
Processo: Identificao de Requisitos (IR)
5.1.1.1
Caracterstica de interesse: Retrabalho em Produo (ReP)
Teste de Autocorrelao
Correlao de Pearson = -0,049 [fraca e no significativa (|| 0, 09)]
Teste de Correlao entre esforo de reviso e esforo de correo
Correlao de Pearson = 0,282 [fraca]
Teste de Normalidade
P-valor < 0,005 [Valor esperado: P-valor > 0,005]
Figura 5.1: [IR-ReP] Teste de normalidade
I
Grfico X
I no ser utilizado.
Devido no normalidade, o grfico X
Grfico MMEP
[IR-ReP] MMEP (1), Figura 5.2 - Teste detectou falha no(s) ponto(s): 66.
[IR-ReP] MMEP (2), Teste detectou falha no(s) ponto(s): 36.
[IR-ReP] MMEP (3), Figura 5.3 exibe situao do processo sob controle.
Anlise
Apenas dois pontos fora-de-controle foram detectados, apesar disso no indicar
que esse processo ser fcil ou rapidamente conduzido uma situao de controle.
Percebe-se que se as causas atribuveis que os originaram forem eliminadas desse
processo, a mdia de retrabalho reduz de 45,7% (figura 5.2) para 42,5% (figura
5.3), uma melhoria de 7% na mdia de retrabalho. Ressaltamos que os valores
absolutos da mdia de retrabalho foram descaracterizados, porm a proporo de
95
Figura 5.2: [IR-ReP] MMEP (1)
Figura 5.3: [IR-ReP] MMEP (3)
reduo no influenciada por essa descaracterizao. O custo benefcio dessa

reduo pode compensar o esforo a ser despendido na investigao das causas
atribuveis e na realizao de aes de melhoria para eliminar tais causas do processo. Alm da investigao e eliminao dessas causas atribuveis, o esforo de
reviso outro ponto passvel de ateno. Para ser efetivo ele deveria ser proporcional ao esforo de correes, ou seja, refletir uma correlao mais significativa
que a apresentada, de apenas 0,282 de Pearson. As aes de melhoria para esse
ponto esto relacionadas ao planejamento e execuo do esforo realizado com
revises ser proporcional ao esforo realizado com correo. O grfico de custo
benefcio pode auxiliar essas aes.
5.1.1.2
Caracterstica de interesse: Produtividade em Produo (PrP)
Correlao de Pearson = 0,004 [fraca e no significativa (|| 0, 09)]
I
Grfico X
I no ser utilizado.
Grfico MMEP
[IR-PrP] MMEP (1), Figura 5.5 - Teste detectou falha no(s) ponto(s): 1; 23; 65;
68.
[IR-PrP] MMEP (2) e (3), Teste detectou falha no(s) ponto(s): 43; 56; 22.
[IR-PrP] MMEP (4), Figura 5.6 exibe situao do processo sob controle.
96
Figura 5.4: [IR-PrP] Teste de normalidade
Figura 5.5: [IR-PrP] MMEP (1)
Figura 5.6: [IR-PrP] MMEP (4)
Anlise
A excluso fictcia dos pontos fora-de-controle conduziu o processo a uma situao de produtividade pior, onde o processo sob controle executaria, em mdia
3,28 PF/hora (figura 5.6) contra 4,55 PF/hora (figura 5.5) no processo fora de
controle. Nesse caso podemos perceber que o ponto 1 da figura 5.6 desvia a mdia do processo, fornecendo ilusoriamente uma mdia de produtividade alta. A
organizao deve avaliar se o novo valor de produtividade aceitvel e caso no
seja, alm das aes de melhoria para eliminar tais causas atribuveis, so necessrias tambm aes de melhorias que conduzam o processo a uma produtividade
melhor. Porm, se a nova produtividade aceitvel, pertinente entender que a
anlise trouxe benefcios, pois, mesmo indicando uma produtividade pior, fornece
a previsibilidade real sobre o comportamento do processo.
97
5.1.1.3
Caracterstica de interesse: Participao do Processo em Produo

(PPP)
Figura 5.7: [IR-PPP] Teste de normalidade
I
Grfico X
I no ser utilizado.
Grfico MMEP
[IR-PPP] MMEP (1), Figura 5.8 - Teste detectou falha no(s) ponto(s): 15.
[IR-PPP] MMEP (2), Figura 5.9 exibe situao do processo sob controle.
Figura 5.8: [IR-PPP] MMEP (1)
Figura 5.9: [IR-PPP] MMEP (2)
98
Anlise
Essa caracterstica no foi descaracterizada, visto que o somatrio de suas mdias
nos quatro processos (Identificao de requisitos - IR, Detalhamento de Requisitos
- DR, Desenho Externo - DE e Implementao - IM) deve resultar em aproximadamente 100% de participao na fase de produo. O presente processo foi o nico
a apresentar-se instvel, apesar de evidenciar apenas um ponto fora-de-controle.
Todos os demais processos (Detalhamento de Requisitos - DR, Desenho Externo
- DE e Implementao - IM), para a presente caracterstica, apresentaram-se sob
controle. A diferena entre as mdias do processo Identificao de Requisito IR instvel (8,55% na figura 5.8) e aps a simulao de estabilidade (7,09% na
figura 5.9) consistiu na reduo de 17% de participao. Porm, esse nmero no
significativo o bastante para justificar a investigao e a realizao de ao de
melhorias para a eliminao das causas atribuveis, pois ele representa apenas
1,46% de erro de estimativa, se considerarmos a participao dessa caracterstica
nos 100% do esforo da fase de produo. As informaes da participao de cada
processo no total do desenvolvimento so teis para o planejamento da equipe,
pois permite que a organizao estime o percentual de recursos humanos necessrio em cada perfil tcnico e o custo de produo (em hora ou ponto de funo), a
partir do custo mdio de cada um desses perfis. Logo, a estabilidade dos processos Detalhamento dos Requisitos - DR, Desenho Externo - DE e Implementao
- IM permite previsibilidade nas estimativas de demanda de recursos humanos,
conhecimento essencial para a organizao. Para ilustrar a participao desses
quatro processos no esforo de produo do Laboratrio Synergia apresentamos
a figura 5.10.
Figura 5.10: Participao dos Processos em Produo
99
5.1.1.4
Caracterstica de interesse: Defeitos em Produo (DeP)
Figura 5.11: [IR-DeP] Teste de normalidade
Grfico u
Devido no normalidade, o grfico u no ser utilizado.
Grfico MMEP
[IR-DeP] MMEP (1), Figura 5.12 - Teste detectou falha no(s) ponto(s): 21.
[IR-DeP] MMEP (2), Figura 5.13 exibe situao do processo sob controle.
Figura 5.12: [IR-DeP] MMEP (1)
Figura 5.13: [IR-DeP] MMEP (2)
100
Anlise
A caracterstica Defeitos em Produo (DeP) atributo e deve ser controlada
atravs do grfico u e do grfico MMEP. Apenas um ponto foi plotado fora-decontrole, no total de 60 amostras. Apesar disso, se as causas forem investigadas e
eliminadas do processo, haver uma reduo de quase 8% no nmero de defeitos
por 1000PF. Foi utilizada a proporo de nmero de defeitos por 1000 pontos de
funo (PF) para que, no caso de se plotar o grfico u, a unidade pudesse ser
convertida para nmero inteiro. O benefcio da investigao das causas atribuveis
e das aes de melhorias podem ser justificados pelo custo de corrigir um defeito
multiplicado pela reduo do nmero de defeitos por 1000 PF. No presente caso,
77 multiplicado pelo custo mdio de corrigir um defeito.
5.1.2
Processo: Detalhamento de Requisitos (DR)
5.1.2.1
I no ser utilizado, consequenteDevido autocorrelao fraca, o grfico X
mente, no ser necessrio o teste de normalidade.
I
Grfico X
I no ser utilizado.
Devido autocorrelao fraca, o grfico X
Grfico MMEP
[DR-ReP] MMEP (1), Figura 5.14 - Teste detectou falha no(s) ponto(s): 37; 84;
85; 86; 89.
[DR-ReP] MMEP (2), Teste detectou falha no(s) ponto(s): 8; 17; 32.
[DR-ReP] MMEP (3), Figura 5.15 exibe situao do processo sob controle.
Anlise
Vrios pontos fora-de-controle foram detectados, os quais representam aproximadamente 10% das amostras. Percebe-se que se as causas atribuveis que os
101
Figura 5.14: [DR-ReP] MMEP (1)
Figura 5.15: [DR-ReP] MMEP (3)
originaram forem eliminadas do processo, a mdia de retrabalho reduz de 75,9%

(figura 5.14) para 67,9% (figura 5.15), uma melhoria quase 10% na mdia de retrabalho. A correlao entre o esforo de reviso e o esforo de correo ( = 0, 032)
ainda menor que no processo Identificao de Requisitos (IR). As recomendaes
so semelhantes s do processo IR, porm, ressaltamos que, apesar das melhorias nesse processo serem maiores caso as causas atribuveis sejam investigadas
e eliminadas, o nmero de pontos fora-de-controle tambm significativamente
maior.
5.1.2.2
I
Grfico X
I no ser utilizado.
Grfico MMEP
[DR-PrP] MMEP (1), Figura 5.16 - Teste detectou falha no(s) ponto(s): 36; 84;
85; 86.
[DR-PrP] MMEP (2),(3),(4),(5),(6),(7) e (8), Teste detectou falha no(s) ponto(s):
1; 3; 4; 5; 7; 9; 24; 35; 57; 72; 92; 95.
[DR-PrP] MMEP (9), Figura 5.17 exibe situao do processo sob controle.
102
Figura 5.16: [DR-PrP] MMEP (1)
Figura 5.17: [DR-PrP] MMEP (9)
Anlise
Podemos perceber que o que ocorreu com o processo Identificao de Requisitos
(IR) para a presente caracterstica ocorre para o presente processo. Esse processo sob controle executaria, em mdia, 2,19 PF/hora (figura 5.16), contra 1,54
PF/hora (figura 5.17) no processo fora-de-controle, ou seja, a produtividade piora. Porm, diferente do processo IR, o nmero de pontos fora-de-controle no
presente processo significativamente maior. Ressaltamos novamente que se a
nova produtividade aceitvel, pertinente entender que a anlise trouxe benefcios ao fornecer a previsibilidade real sobre o comportamento do processo.
5.1.2.3

(PPP)
I
Grfico X
I no ser utilizado.
Grfico MMEP
[DR-PPP] MMEP (1), Figura 5.19 exibe situao do processo sob controle processo estvel.
103
Figura 5.18: [DR-PPP] Teste de normalidade
Figura 5.19: [DR-PPP] MMEP (1)
Anlise
Essa caracterstica apresentou-se estvel, ela participa, em mdia, com 11,51%
do esforo total de desenvolvimento e no foi descaracterizada, visto que o somatrio de suas mdias nos quatro processos (Identificao de Requisitos - IR,
Detalhamento de Requisitos - DR, Desenho Externo - DE e Implementao - IM)
deve resultar em aproximadamente 100% de participao na fase de produo,
como j citado na Seo 5.1.1.3.
5.1.2.4
Caracterstica de interesse: Defeitos em Produo (DeP)
Correlao de Pearson = 0,457 [moderada]
Devido autocorrelao moderada, o grfico u no ser utilizado, consequentemente, no ser necessrio o teste de normalidade.
104
Grfico u
Devido autocorrelao moderada, o grfico u no ser utilizado.
Grfico MMEP
[DR-DeP] MMEP (1), Figura 5.20 - Teste detectou falha no(s) ponto(s): 70; 71;
72; 73; 74; 75.
[DR-DeP] MMEP (2) e (3), Teste detectou falha no(s) ponto(s): 67; 69; 77; 83.
[DR-DeP] MMEP (4), Figura 5.21 exibe situao do processo sob controle.
Figura 5.20: [DR-DeP] MMEP (1)
Figura 5.21: [DR-DeP] MMEP (4)
Anlise
A caracterstica Defeitos em Produo (DeP) atributo e deve ser controlada
atravs do grfico u e do grfico MMEP. Foram 10 pontos plotados fora-decontrole no total de 83 amostras, ou seja, quase 12% do total de pontos foram
plotados fora dos limites de controle. Isso demonstra que esse processo no estvel e estabiliz-lo pode demandar muito esforo. Caso seja despendido esforo
para investigar as causas atribuveis e aplicar melhorias para estabiliz-lo, ou seja,
torn-lo previsvel, a mdia de defeitos por 1000 pontos de funo reduzir de
2956 (figura 5.20) para 2067 (figura 5.21) defeitos por 1000 PF, aproximadamente
30% de reduo. Esse nmero significativo e no deve ser fcil para a organizao empreender tamanha melhoria em aes pontuais. Isso deve levar tempo e
impactar significativamente outros processos. O benefcio da investigao de tais
causas atribuveis e das aes de melhorias podem ser justificados pelo custo de
corrigir um defeito multiplicado pela reduo do nmero de defeitos por ponto de
funo. No presente caso, 889 defeitos multiplicados pelo custo mdio de corrigir
um defeito.
5.1.3
Processo: Desenho Externo (DE)
5.1.3.1
105
Correlao de Pearson = 0,549 [moderada]
I
Grfico X
I no ser utilizado.
Grfico MMEP
[DE-ReP] MMEP (1), Figura 5.22 exibe situao do processo sob controle - processo estvel.
Figura 5.22: [DE-ReP] MMEP (1)
Anlise
O teste no detectou falhas, logo, o processo considerado estvel. Comparando
o valor da mdia com os demais processos para essa mesma caracterstica, o
presente processo apresenta o melhor valor entre elas. Lembrando que os valores
foram descaracterizados, o que no impede essa comparao relativa. Apesar de
haver previsibilidade a organizao deve avaliar se o valor aceitvel, ou seja,
competitivo.
106
5.1.3.2
I
Grfico X
I no ser utilizado.
Grfico MMEP
[DE-PrP] MMEP (1), Figura 5.23 exibe situao do processo sob controle - processo estvel.
Figura 5.23: [DE-PrP] MMEP (1)
Anlise
o valor dessa mdia com os demais processos para essa mesma caracterstica,
o presente processo apresenta o segundo pior valor entre elas, porm, tambm o segundo em participao no processo. Lembrando que os valores foram
descaracterizados, o que no impede essa comparao relativa. Apesar de haver previsibilidade a organizao deve avaliar se o valor aceitvel, ou seja, se
competitivo. Como a participao desse processo no total do projeto a segunda maior, aproximadamente 23,3% e, considerando o Princpio de Pareto, a
aplicao de melhorias para conduz-lo a uma produtividade melhor pode trazer
significativos impactos positivos tanto no prazo quanto no custo da produo.
5.1.3.3
107

(PPP)
I
Grfico X
I no ser utilizado.
Grfico MMEP
[DE-PPP] MMEP (1), Figura 5.24 exibe situao do processo sob controle processo estvel.
Figura 5.24: [DE-PPP] MMEP (1)
Anlise
Essa caracterstica apresentou-se estvel, ela participa, em mdia, com 23,31%
do esforo total de desenvolvimento e no foi descaracterizada, visto que o somatrio de suas mdias nos quatro processos (Identificao de Requisitos - IR,
Detalhamento de Requisitos - DR, Desenho Externo - DE e Implementao - IM)
deve resultar em aproximadamente 100% de participao na fase de produo.
5.1.4
Processo: Implementao (IM)
5.1.4.1
108

I
Grfico X
I no ser utilizado.
Grfico MMEP
[IM-ReP] MMEP (1), Figura 5.25 exibe situao do processo sob controle - processo estvel.
Figura 5.25: [IM-ReP] MMEP (1)
Anlise
o valor da mdia com os demais processos para essa mesma caracterstica, o
presente processo apresenta o pior valor entre elas. Lembrando que os valores
foram descaracterizados, o que no impede essa comparao relativa. Apesar
de haver previsibilidade a organizao deve avaliar se o valor aceitvel, ou
seja, competitivo. Esse processo tambm o de maior impacto na participao
da produo, logo, melhorias para conduz-lo a um menor ndice de retrabalho
traro significativos impactos positivos no custo e prazo do projeto.
109
5.1.4.2
P-valor = 0,884 [Valor esperado: P-valor > 0,005]
Figura 5.26: [IM-PrP] Teste de normalidade
I
Grfico X
[IM-PrP] X-Bar I (1), Figura 5.27 exibe situao do processo sob controle - processo estvel.
Grfico MMEP
[IM-PrP] MMEP (1), Figura 5.28 exibe situao do processo sob controle - processo estvel.
I (1)
Figura 5.27: [IM-PrP] X
Figura 5.28: [IM-PrP] MMEP (1)
110
Anlise
Essa caracterstica foi o nico exemplo onde foi possvel utilizar o grfico X
I. Para todos os demais ou as caractersticas eram autocorrelacionadas ou no
eram normalmente distribudas. O teste no detectou falhas, logo, o processo
considerado estvel. Comparando o valor dessa mdia com os demais processos
para essa mesma caracterstica, o presente processo apresenta o pior valor entre
elas, e o primeiro em participao no processo. Lembrando que os valores
foram descaracterizados, o que no impede essa comparao relativa. Apesar de
haver previsibilidade a organizao deve avaliar se o valor aceitvel, ou seja,
se competitivo. Como a participao desse processo no total do projeto a
primeira maior, aproximadamente 56,6% e, considerando o Princpio de Pareto,
a aplicao de melhorias para conduz-lo a uma produtividade melhor pode trazer
significativos impactos positivos tanto no prazo quanto no custo da produo.
5.1.4.3

(PPP)
Figura 5.29: [IM-PPP] Teste de normalidade
I
Grfico X
I no ser utilizado.
5.2. Viso geral das anlises dos resultados
111
Grfico MMEP
[IM-PPP] MMEP (1), Figura 5.30 exibe situao do processo sob controle - processo estvel.
Figura 5.30: [IM-PPP] MMEP (1)
Anlise
Essa caracterstica apresentou-se estvel, ela participa, em mdia, com 56,6% do
esforo total de desenvolvimento e no foi descaracterizada, visto que o somatrio
de suas mdias nos quatro processos (Identificao de Requisitos - IR, Detalhamento de Requisitos - DR, Desenho Externo - DE e Implementao - IM) deve
resultar em aproximadamente 100% de participao na fase de produo.
5.2
Viso geral das anlises dos resultados
A anlise dos resultados foi realizada qualitativamente, a partir dos resultados apresentados na Seo anterior.
A correlao entre o esforo realizado em reviso e o esforo realizado em correo
foi moderada apenas para o processo Desenho Externo - DE, sendo que para os
demais processos, Identificao Requisitos - IR, Detalhamento de Requisitos DR e Implementao - IM, a correlao foi fraca e no significativa. Esse fato
pode significar que o esforo em reviso, nos processos Identificao de Requisitos
- IR, Detalhamento de Requisitos - DR e Implementao - IM, no est sendo
planejado e executado de modo eficiente, visto que no h correlao entre ele e o
esforo de correo. Como ao de melhoria, o uso do grfico de Custo x Benefcio
sugerido para apoiar a deciso do planejamento e execuo da reviso.
112
A taxa de retrabalho precisa ser comparada com valores de benchmark para se

concluir se ela est entre os valores executados pelo mercado, ou seja, competitiva.
Porm, dentre todas as caractersticas avaliadas, a que apresentou maior valor
absoluto, o que torna maior as chanches das melhorias serem mais significativas.
Logo, aes de melhorias com foco em reduo de retrabalho so sugeridas. O
processo Implementao - IM, com maior Participao em Produo (PPP)
tambm o que apresenta maior Retrabalho em Produo (ReP). Esse fato sugere
que as aes de melhoria se iniciem e sejam mais focadas nesse processo.
Os processos Desenho Externo - DE e Implementao - IM se mostraram estveis
para as trs caractersticas de interesse Retrabalho em Produo (ReP), Produtividade em Produo (PrP) e Participao do Processo em Produo (PPP).
Disso conclui-se que a organizao tem previsibilidade para planejar com preciso
tais processos, porm, isso no significa que a mdia ou o desvio padro atuais
estejam dentro do limite de especificao desejado, ou seja, se so competitivos.
Os limites de especificao no foram informados.
A caracterstica de interesse Produtividade em Produo (PPP) encontra-se estvel para os quatro processos Identificao de Requisitos - ID, Detalhamento de
Requisitos - DR, Desenho Externo - DE e Implementao - IM. Disso conclui-se
que a organizao j tem previsibilidade para planejar com preciso a distribuio
do esforo entre esses processos.
O desvio padro encontrado para a maioria dos processos levados a uma situao
fictcia de estabilidade alto. Isso pode ser entendido como caracterstica prpria
dos processos de software, onde a produo depende fortemente da interferncia
e criatividade humana, no tendo alta preciso como processos automatizados de
produo.
5.3
Anlise de viabilidade Modelo CEP-S
Esta Seo apresenta uma anlise do Modelo CEP-S do ponto de vista de sua aplicabilidade e avalia se os objetivos a que ele se prope esto sendo atendidos. Essa
anlise foi feita a partir da realizao do estudo de caso, onde o Modelo foi aplicado ao
Laboratrio Synergia, organizao de mdio porte.
Quatro caractersticas de interesse foram planejadas e monitoradas no estudo de
caso. A escolha dessas quatro caractersticas, dentre as doze propostas pelo Modelo,
considerou quais poderiam ser derivadas de dados que j eram coletados e analisados
5.3. Anlise de viabilidade Modelo CEP-S
113
pelo Laboratrio Synergia, ou seja, que j faziam parte de seu plano de medies.
Conclumos que foi possvel aplicar o Modelo a uma organizao de mdio porte e
ainda utilizar o plano atual de medies dessa organizao sem que alteraes fossem
demandadas.
Essa escolha no se restringiu ao uso apenas das caractersticas que estivessem
alinhadas aos objetivos estratgicos do Laboratrio Synergia, visto que o objetivo do
estudo de caso era validar a proposta do Modelo. Porm tais objetivos foram avaliados
e foi possvel identificar que as caractersticas de interesse que tratam de retrabalho
esto alinhadas e podem colaborar com a estratgia dessa organizao.
No foi possvel planejar, monitorar e validar, atravs do estudo do caso, todas
as caractersticas de interesse propostas pelo Modelo, visto que no havia dados disponveis para deriv-las. Para viabilizar essa derivao, seria necessria a realizao
de um experimento e no do estudo de caso. O experimento demandaria alteraes no
plano de medio da organizao, as quais no poderiam ser justificadas apenas pelos
objetivos do presente trabalho acadmico, o que torna a execuo de tal experimento
invivel. Porm, foi possvel, somente com o estudo de caso, monitorar essas quatro caractersticas para quatro processos: identificao de requisitos, detalhamento de
requisitos, desenho externo e implementao. Concluses significativas desse monitoramento foram alcanadas, mesmo com algumas condies fictcias de estabilizao dos
processos, as quais so: identificao dos processos estveis, evidenciao da mdia e
desvio padro das caractersticas por processo, informaes sobre as causas atribuveis,
quantificao dos ganhos e, finalmente, a viabilidade de extenso do Modelo para ser
aplicado a quatro processos.
Tomamos como exemplo a caracterstica Retrabalho em Produo (ReP) do processo de Detalhamento de Requisitos (DR). Antes da aplicao do Modelo CEP-S ela
mostrava 75,9% de retrabalho em produo e aps a aplicao do Modelo, simulando
a eliminao das causas atribuveis do processo, ela passou a mostrar 67,9% de retrabalho. Temos que considerar o risco da organizao no conseguir identificar todas as
causas atribuveis ou realizar aes que sejam efetivas para levar o processo situao
de estabilidade, mas analisando qualitativamente a situao, possvel concluir que
poderia haver uma reduo de mais de 10,5% do retrabalho, sendo possvel quantificar
o ganho entre a situao anterior e posterior aplicao do controle e das aes de
melhorias. Nesse mesmo exemplo podemos mostrar que o modelo auxiliou na identificao dos momentos que os pontos foram plotados fora-de-controle, facilitando as
investigaes da causa atribuvel.
Foi possvel gerar um grfico de controle para todas as quatro caractersticas de
interesse, para cada um dos quatro processos, ou seja, no houve restrio quanto
114
quantidade dos dados, devido aos controles terem sido estabelecidos por agrupamento
de casos de uso. Isso evidencia que, para o estudo de caso realizado, foi possvel,
novamente sem alterao no plano de medies da organizao, utilizar um agrupador
para as medidas.
Comparando os testes de autocorrelao para trs caractersticas (Retrabalho
em Produo - ReP, Produtividade em Produo PrP e Participao do Processo em
Produo - PPP) em cada um dos quatro processos (Identificao de Requisitos - ID,
Detalhamento de Requisitos - DR, Desenho Externo - DE e Implementao - IM),
temos que 50% delas resultaram em autocorrelao fraca e 50% em autocorrelao
I a 50% dos casos. Alm disso, o
inexistente. Isso restringiu o uso do grfico X
teste de normalidade limitou a apenas um caso, dos seis restantes, o uso do grfico
I, visto que apenas um apresentou distribuio normal. Logo, para o estudo de
X
I colaborou em apenas em 8,3% dos casos, o que mostra
caso realizado, o grfico X
que a utilizao do grfico MMEP teve um papel importante no modelo proposto.
O tempo para executar uma aplicao do modelo depende do estado atual de
maturidade da organizao em relao aos requisitos do modelo. Para a aplicao
no Laboratrio Synergia, considerando a estabilizao fictcia dos processos, 40 horas
foram suficientes, para quatro caractersticas de interesse de quatro processos cada.
Essa aplicao foi realizada em pouco tempo devido organizao j ter disponveis os
dados necessrios, ou seja, j executar eficientemente seu plano de medies. Caso a
organizao ainda no execute a coleta e anlise das medidas necessrias, o perodo de
aplicao do modelo depender de quo rpido ela conseguir implantar tal execuo.
Tomando como referncia uma pesquisa recente realizada sobre a adoo do modelo
MPS.BR, Travassos & Kalinowski [2008], as organizaes levam, em mdia, doze meses
para avanar um nvel. Se avaliarmos o primeiro nvel que indica a implantao de
medies e outras prticas e considerarmos a pesquisa, podemos dizer que um ano
um prazo factvel para a organizao implantar a coleta e anlise de medies. A
execuo real da estabilizao dos processos, que pode ser significativa, outro ponto
que deve ser considerado para o tempo da aplicao do modelo. Porm, como no estudo
de caso tais atividades foram simuladas, no dispomos de referncias que nos permitam
prever quo demoradas podem ser essas atividades.
No foi possvel avaliar o modelo quanto ao impacto do reuso, da linguagem de
programao, do framework, da complexidade dos requisitos ou de outros fatores que
distinguem os controles, visto que no havia dados disponveis.
Considerando a anlise dos resultados e a anlise sobre a aplicabilidade do Modelo
CEP-S, foi possvel evidenciar que ele auxilia a gesto da qualidade e a promoo da
maturidade dos processos; fornece informaes sobre a existncia de causas especiais
5.3. Anlise de viabilidade Modelo CEP-S
115
de variao e a previsibilidade dos processos; apoia a quantificao dos ganhos providos

pelas aes de melhoria; apoia a apresentao e descrio de informaes para a tomada
de deciso; apoia a formulao de estimativas confiveis a partir das informaes da
capacidade dos processos; e finalmente, mostrou-se aplicvel a organizao de mdio
porte, sem demandar mudanas no plano de medies existente.
Captulo 6
Concluso
A taxa de defeitos, apesar de ser a caracterstica de interesse mais utilizada em CEP
de desenvolvimento de software, uma medida pouco significativa para a base de
estimativa da organizao, pois no homognea de forma a permitir comparaes
entre unidades de produo distintas. No possvel dizer que 500 defeitos em um
projeto de 100 pontos de funo ocasionam um efeito pior, em termos de custo ou
prazo, que 50 defeitos em um projeto tambm de 100 pontos de funo. Isso porque
cada defeito demanda um esforo diferente para ser corrigido e nem sempre a contagem
de um defeito precisa, de forma a refletir exatamente suas causas. Outro ponto a se
destacar o fato dos defeitos serem classificados de forma simplista pela maioria das
organizaes, o que impede uma anlise expressiva de suas causas.
As caractersticas de interesse propostas no modelo CEP-S, baseadas em esforo,
so mais significativas que a taxa de defeitos, transmitem mais informaes, so comparveis entre as unidades de produto de software e alinhadas com as questes estratgicas. A maioria das caractersticas propostas so formadas pela medida do esforo para
execuo das atividades fim, de qualidade e de retrabalho. Explorar tais caractersticas
possibilitou a criao de um arcabouo com escolhas pr-definidas, porm flexvel, para
aplicao de CEP em processos de desenvolvimento de software. Consideramos esse
arcabouo bem definido por ele fornecer uma viso geral das atividades para o planejamento e a execuo de CEP e por tratar especificamente: (i) da seleo dos processos
alvo de CEP; (ii) da definio de uma viso de como tais processos so organizados
para o planejamento das medies; (iii) da apresentao dos conceitos envolvidos e das
personalizaes necessrias para adaptar o modelo organizao; (iv) da identificao
das caractersticas de interesse e de um mecanismo de seleo dessas a partir da viso
dos objetivos estratgicos; (v) da sugesto de uma segmentao da produo, o que
reduz a restrio da quantidade de dados inerentes a projetos de software; (vi) da de117
118
Captulo 6. Concluso
finio dos grficos adequados para os processos; (vii) e por fim, das sugestes para os
parmetros de controle e os testes de estabilidade.
A taxa de defeitos, mesmo sendo uma caracterstica de interesse pouco adequada
para CEP, devido baixa significncia do resultado da comparao de seus valores
dentre as unidades de produto de software, pode auxiliar o gerente de projetos a acompanhar a situao dos defeitos durante a execuo dos projetos e a monitorar a percepo do cliente quanto qualidade do produto. Por essas razes, a taxa de defeitos
uma caracterstica de interesse que compe o modelo CEP-S. Ela usada tambm
para analisar at quando o custo do esforo com as atividades de testes vale o benefcio
de encontrar mais um defeito e para analisar os tipos de defeitos, de acordo com a
frequncia de suas ocorrncias. O modelo CEP-S prope anlises mais adequadas para
a taxa de defeitos, indo alm do CEP, e sugestes significativas para a classificao dos
defeitos, o que permite aes de melhorias mais efetivas a partir de informaes mais
rigorosas de suas causas.
I e MMEP,
Finalmente, o modelo prope o uso combinado dos grficos X
criando um arcabouo eficiente tanto para grandes quanto para pequenas magnitudes
de desvios da mdia. Alm disso, uma alternativa e evitar o uso indevido do grfico
de Shewhart para quando os dados no respeitarem as restries de normalidade e
autocorrelao.
Por ser uma ferramenta poderosa para apoiar o gerenciamento quantitativo e a
melhoria contnua dos processos e por ser bem definido, espera-se que o modelo aqui
proposto possa ser utilizado por organizaes, ainda que de pequeno e mdio porte,
nas primeiras investidas em controle estatstico de processos. importante ressaltar
que o esforo de preparao para a aplicao de CEP considervel e que o modelo
se restringe a organizaes capazes de planejar e executar efetivamente um plano de
medio e de realizar aes efetivas de melhorias. Esses pr-requisitos so os meios
para garantir a gerao de dados confiveis e a estabilizao dos processos.
6.1
Trabalhos futuros
O modelo CEP-S prope uma combinao de grficos de controle para caractersticas

de interesse que tenham autocorrelao inexistente, fraca ou moderada. O grfico
I aplicvel quando a autocorrelao das caractersticas for inexistente e o grfico
X
MMEP para quando as caractersticas tiverem autocorrelao inexistente, fraca ou
moderada. Apesar dos estudos de caso revelarem a inexistncia de autocorrelao
forte, para as caractersticas de interesse propostas, a incorporao de mecanismos que
6.1. Trabalhos futuros
119
tratem tambm essa situao vivel e pode deixar o modelo mais robusto.
Dentre as caractersticas de interesse propostas, nenhuma atua diretamente para o
controle dos custos do projeto, o que seria uma extenso interessante para este trabalho.
Estudos preliminares foram realizados, os quais apontaram redes bayesianas como um
bom mecanismo para tratar predies de custos. Redes bayesianas so modelos grficos
que representam relaes probabilsticas entre as variveis de um sistema, lida com
raciocnio probabilstico e usa dados subjetivos de especialistas, quando as informaes
histricas forem insuficientes para construo das predies.
A caracterstica DeM (defeitos em manuteno) pode monitorar o objetivo estratgico qualidade percebida pelo cliente. Porm, a realizao de um estudo com foco
no mapeamento da voz do cliente de servios de desenvolvimento de software sob
encomenda pode desdobrar outras necessidades de monitoramento e consequentemente
outras caractersticas de interesse. Dentre as ferramentas existentes para apoiar a execuo desse mapeamento citamos a metodologia QFD (Quality Function Deployment)
e o Modelo Kano. O QFD desdobra os requisitos expostos pelos clientes, atravs do
uso de matrizes, transformando-os em especificao tcnica do projeto. uma tcnica
bastante difundida no mercado, porm, complexa de ser utilizada. Foi desenvolvida
por Dr. Yoji Akao, apud Cheng & Melo [2007]. Kano um modelo para categorizao da satisfao dos consumidores que prope a classificao dos atributos do
produto baseado em como eles so percebidos, consciente ou inconscientemente, pelos
consumidores. Essa classificao usada para guiar decises de projetos e melhorias
nos produtos indicando quando o bom suficiente ou quando mais melhor. Esse
modelo foi desenvolvido pelo professor Noriaki Kano, Tontini [2003]; Dodson [2008];
Apostila [2002] apud Kano [1984], tambm bastante difundido e no to complexo
quanto QFD.
O modelo se prope a apoiar as organizaes nas primeiras investidas em CEP,
mas no fornece uma anlise se alguma de suas propostas pode beneficiar organizaes
que j utilizam CEP. Acreditamos que, ainda que as organizaes j tenham seus modelos de CEP elaborados, pelo menos as caractersticas de interesse propostas possam
ser teis. Para validar essa suposio necessria a realizao de um estudo atravs
de pesquisa de campo nas empresas que j utilizam CEP.
E, finalmente, como ltima sugesto de trabalhos futuros, entendemos que a
utilizao do modelo CEP-S em outros projetos de desenvolvimento de software, indo
alm do estudo de caso realizado, poderia consolidar e promover as prticas propostas
assim como desenvolv-las.
Apndice A
Conceitos e frmulas estatsticas
A.1
Definies iniciais
As definies descritas neste Apndice foram extradas de Costa et al. [2008]; Levine
et al. [2000]; Meyer [1983].
Estudo Analtico Realizao de algumas aes num processo para melhorar o desempenho futuro.
Estudo Enumerativo Tomada de deciso voltada para uma populao e/ou suas
caractersticas.
Parmetro Uma medida numrica que descreve alguma caracterstica de uma populao.
Populao ou Universo A totalidade dos itens ou objetos considerados.
Teorema do Limite Central A distribuio normal considerada, com frequncia,
como o modelo probabilstico apropriado para uma varivel aleatria. A distribuio da soma de n variveis aleatrias independentes aproximadamente normal,
independentemente das distribuies individuais das variveis. A aproximao
melhora a medida que n aumenta. Montgomery [2004]. usual considerar que o
tamanho n da amostra suficientemente grande quando n superior a 30, Costa
et al. [2008]
Experimento Determinstico Modelo cujas condies sob as quais um experimento seja executado determinem o resultado do mesmo. Se o experimento for
executado repetidamente toda vez utilizando as mesmas condies o valor resultante o mesmo.
121
122
Apndice A. Conceitos e frmulas estatsticas
Experimento No-determinstico Tambm conhecido como Modelo Aleatrio ou

Probabilstico ou Estocstico. No sabido de antemo qual particular resultado
ir ocorrer apesar do conjunto dos possveis resultados serem conhecidos; cada
experimento pode ser repetido indefinidamente sob condies essencialmente inalteradas. As condies da experimentao determinam somente o comportamento
probabilstico do resultado observvel.
Espao Amostral S Conjunto de todos os resultados possveis para cada experimento realizado. Utilizaremos S para representar o espao amostral.
Exemplo A.1 O espao amostral S = {HH, HT, TH, TT} representa os resultados do experimento de jogar duas moedas, onde H representa o evento cara,
T representa o evento coroa
Evento A Conjunto de resultados possveis associados a um experimento num espao amostral S.
Probabilidade P Seja um experimento. Seja S um espao amostral associado a . A
cada evento A associado a um nmero real representado por P(A) e denominado
probabilidade de A, que satisfaa as propriedades:
(1) 0 P (A) 1
(2) P (S) = 1
(3) Se A e B forem eventos mutuamente excludentes, ento,
P (A B) = P (A) + P (B)
(4) Se A1 ,A2 ,...,An ,... forem, dois a dois, eventos mutuamente excludentes,ento,
P (
i=1 Ai ) = P (A1 ) + P (A2 ) + ... + P (An ) + ...
(A.1)
Varivel Aleatria X Uma funo X, que associe cada elemento s S, um nmero
real X(s). Uma varivel aleatria discreta produz resposta numrica finito ou
infinito numervel, que surge a partir de um processo de contagem enquanto uma
varivel aleatria contnua produz resposta com infinitos valores, que surge a
partir de um processo de medio.
Exemplo A.2 A varivel aleatria X para o Exemplo A.1 o nmero de caras
obtidas.
123
A.1. Definies iniciais
Varivel Aleatria Discreta

x1 , x2 , ..., xn
(A.2)
A cada possvel resultado xi associaremos um nmero p(xi ) = P(X=xi ) denominado funo de probabilidade de X que deve satisfazer as condies:
(a) p(xi ) 0 para todo i
X
(b)
p(xi ) = 1
(A.3)
i=1
Varivel Aleatria Contnua

0 x 1.
(A.4)
Para todos os valores de x associaremos a funo f denominada funo densidade

de probabilidade de X que deve satisfazer as condies:
(a) f (x) 0 para todo x,
Z +
(b)
f (x)dx = 1
(A.5)
(c) para quaisquer a, b, com < a < b < +, teremos

Z b
P (a X b) =
f (x)dx.
a
Contra Domnio R(x) Conjunto de todos os valores possveis de X.
Exemplo A.3 R(x) = {0, 1, 2} representa o contra domnio da varivel aleatria X do Exemplo A.2.
Distribuio Binomial P(X=k ) Distribuio de probabilidade discreta do nmero

de sucesso para n repeties de um experimento, onde as repeties so independentes e a probabilidade de cada repetio p permanece constante. A varivel X
binomial tem apenas duas possibilidades: sucesso ou fracasso; defeituoso ou no
defeituoso; 0 ou 1.
124
Apndice A. Conceitos e frmulas estatsticas
Teorema A.1 Seja X uma varivel binomial, baseada em n repeties. Ento

n k
P (X = k) =
p (1 p)nk , k = 0, 1, ..., n.
k
(A.6)
Distribuio Normal f(x) Distribuio de probabilidade contnua do
Teorema A.2 Seja X uma varivel aleatria normal, ento:

1 x 2
] )
1 ( 2 [
f (x) =
2
, < x < .
(A.7)
Esperana E(X) Seja x uma varivel aleatria discreta, com valores possveis
x1 ,...,xn ... Seja p(xi ) = P(X=xi ), i = 1,2,...,n,... Ento, a esperana (ou valor esperado ou valor mdio ou expectncia) de X, denotado por E(X) definido
como:
X
E(X) =
xi p(xi )
(A.8)
i=1
Seja X uma varivel aleatria contnua com fdp f. O valor esperado de X definido
como:
Z +
E(X) =
xf (x)dx
(A.9)
e E(X) existir se, e somente se, E(X) =
R +
|x|f (x)dx for finita.
Varincia x2 Seja X uma varivel aleatria. Definimos a varincia de X, denotada

por x2 ou Var(X) ou ainda 2 , como:
x2 = E[X E(X)]2 .
(A.10)
O Desvio Padro x a raiz quadrada positiva de x2 .

A varincia e o desvio padro avaliam o modo como os dados flutuam em torno da
mdia, medindo a disperso mdia em torno da mdia aritmtica. A varincia
x2 expressa em unidades quadradas de X. Esse um motivo para considerar o
desvio-padro x que expresso na mesma medida de X.
125
A.2. Erros de pesquisa
Covarincia Cov A covarincia a medida da disperso entre duas variveis.
i Y )
(Xi X)(Y
n
ou
X
Y
cov(X, Y ) = XY
P
cov(X, Y ) =
(A.11)
Desigualdade de Tchebycheff Seja X uma varivel aleatria, com E(X) =, e seja

c um nmero real qualquer. Ento, se E(X-c)2 for finita e for qualquer nmero
positivo, teremos:
1
P [|X c| ] 2 E(X c)2
(A.12)

Coeficiente de Correlao Seja (X,Y) uma varivel aleatria bidimensional. xy
o coeficiente de correlao entre X e Y, dado por:
xy =
A.2
E[X E(X)][Y E(Y )]

p
V (X)V (Y )
(A.13)
Erros de pesquisa
Existem quatro tipo de erros de pesquisa cujos experimentos devem tentar reduzir
pois geralmente incorrem em custo considervel, Levine et al. [2000]. O Erro de
Cobertura a seleo no apropriada da populao, onde certos grupos so excludos;
a Falta de Resposta a falha na coleta de dados de todos os elementos da amostra
por falta de resposta; o Erro de Amostragem que refletem a heterogeneidade de
amostra para amostra, com base na probabilidade dos elementos serem selecionados
nas amostras em particular; o Erro de Medio que se refere a falta de exatido das
respostas registradas, o que pode ocorrer por deficincia na formulao da pergunta,
por efeito causado pelo entrevistador ou por causa do esforo realizado pelo informante.
Apndice B
Caracterizao do software
A tabela B.1 apresenta as classificaes do software, dada por Gutierrez & Alexandre
[2004], quanto ao modelo de negcio, forma de comercializao e quanto ao mercado
alvo.
Quanto ao Modelo de Negcio
Produto
Servios
Infra-estrutura: sistema operacional, servidores, middleware, gerenciador de rede, gerenciador de arquivos, gerenciador de sistemas,
segurana;
Ferramentas: linguagem de programao, editor, planilha, compilador, gerenciador de desenvolvimento, modelagem de dados, business
intelligence (BI), data warehouse (DW), ferramentas da internet;
Aplicativos: enterprise resource planning (ERP), customer relationship management (CRM), recursos humanos, supply chain management(SCM);
Discretos: servios em geral contratados por perodos curtos;
Outsourcing: a terceirizao do desenvolvimento de software ou
outros servios, onde ocorre a transferncia de uma parte significativa
da responsabilidade pelo gerenciamento do servio para o provedor do
servio. Esse pode ser convencional, que a terceirizao de uma atividade na rea de TI, ou BPO (business process outsourcing), onde o
fornecedor responsvel pelo processo ou funo de negcio do cliente;
Embarcado Software construdo para um determinado produto eletrnico, uma

mquina;
Quanto Forma de Comercializao
127
128
Apndice B. Caracterizao do software
Pacote
Produto totalmente desenvolvido antes de ser lanado no mercado,

busca atender s necessidades gerais dos usurios. A relao da empresa desenvolvedora e do usurio fraca;
Grande parte do produto desenvolvido antes de ser lanado no mercado, mas com algumas adaptaes para cada usurio ou instalao;
Customizado
busca atender s necessidades especficas dos usurios. A relao da
empresa desenvolvedora e do usurio forte;
Produto desenvolvido para atendimento a necessidades exclusivas de
Sob
um usurio. A relao da empresa desenvolvedora e do usurio
Encomenda
intensa.
Quanto ao Mercado Alvo
Horizontal
Software de uso geral, exemplos: planilhas, editores;
Vertical
Software de uso especfico, para um determinado processo de negcio,

exemplos: gesto hospitalar, projeto de circuitos integrados;
Tabela B.1: Classificao do Software
Outras caractersticas do software so descritas abaixo:

uma mercadoria de natureza no-material que no emprega matrias-primas
consumveis ao longo de seu ciclo produtivo, Roselino [2006a].
Pelo lado da demanda, diferentemente de informao que se valora pela sua capacidade de influenciar ou informar, o software similar a muitos bens materiais
e servios que tm os seus valores determinados pelas aes que desempenham,
Messerschmitt & Szyperski [2000].
ainda majoritariamente produzido manualmente, Pressman [1997];
Os custos do software esto concentrados na produo da primeira unidade, custos
de criao, Pressman [1997]. Esses custos caracterizam o cenrio de empresas
desenvolvedoras de software como servio. Os custos de reproduo e distribuio,
custos marginais, so mnimos (praticamente desprezveis), o que caracteriza os
custos das empresas desenvolvedoras de software como produto.
O uso do software no resulta em desgastes. A troca de uma verso decorrente
da evoluo tecnolgica e no dos desgastes, Pressman [1997].
A interatividade entre usurio e desenvolvedores de software como servio intrnseca ao processo de produo, diferentemente do que acontece no software
129
pacote. Como fator competitivo preponderante esto no s o conhecimento das

atividades como tambm das necessidades dos clientes. Os riscos de mercado so
menores, pois as vendas so efetuadas antes, porm os custos de desenvolvimento
so mais significativos, Freire [2002].
Software intangvel. A definio tradicional de intangibilidade focaliza, principalmente, a impossibilidade de um produto ser tocado e a dificuldade de ser
visualizado ou claramente definido na mente do consumidor. Como conseqncia,
diversos desafios manifestam-se no gerenciamento de servios, incluindo a prpria
impossibilidade de estocagem, maiores dificuldades na definio de preo, limitaes na obteno de patentes, restries na comunicao com o mercado e maior
complexidade nas avaliaes por parte do consumidor em todas as etapas da
compra e consumo, Berry & Pasuraman [2004].
Apndice C
Anlise do cenrio atual do
mercado de software nacional
O Brasil movimentou em 2008 aproximadamente 10 bilhes de dlares em servios de
software, com uma expectativa de crescimento superior a 10% ao ano at 2010. Em
relao s exportaes, o valor 2.2 bilhes de dlares com estimativa de 3 bilhes
para 2009. Fontes: Lobo [2009]; ABES [2009a]. A ndia, que ocupa o primeiro no
ranking mundial em valores de exportao de servios de software, exportou 40 bilhes
de dlares e estima ultrapassar 50 bilhes em 2009.Comparando esses dois pases na
tica de exportao, o Brasil est bastante acanhado.
Ressaltamos que em 2007 o Brasil produzia, para o mercado interno e exportao, prximo a 94% da produo total da ndia, que era praticamente de exportao.
Atualmente, a produo brasileira representa apenas 30% da produo total da ndia e mesmo com programas governamentais de incentivos exportao, vide tabela
C.1 Histrico dos marcos das aes polticas do Brasil, no conseguiu acompanhar o
crescimento do mercado mundial, muito menos aumentar a fatia de participao nas
exportaes, como vrias vezes foi objetivado pelos programas. Esses programas continuam na tentativa de fazer com que o Brasil entre significativamente nesse mercado,
cujas projees so promissoras.
Aproximadamente 94% das empresas brasileiras de software, que atuam com
desenvolvimento e produo, so classificadas como micro e pequenas empresas, ABES
[2009a]. Considerando todos os segmentos de software, 57% so pequenas e 5% mdias,
vide distribuio por porte na figura C.1, extado de ABES [2009b]:
H vrios fatores que colocam o Brasil numa posio significativa no mercado
interno e sem grande relevncia no mercado de exportaes. A anlise realizada aqui
considera que ambos os mercados, interno e de exportao, podem ser de interesse de
131
132
Ano
70s/80s
90s
1991
1992
1996
2000
2003
2004
Apndice C. Anlise do cenrio atual do mercado de software

nacional
Ao Poltica
Lei 7.232 (outubro/84) controle das importaes.
Liberao das importaes.
Lei 8.248/91 (Lei de Informtica - outubro/91) isenes fiscais (IPI, IR
e CAP), processos produtivos bsicos e P&D.
Fim da poltica de reserva de mercado e criao do Programa SOFTEX
2000 (Programa Nacional de Software para Exportao).
Criao da Sociedade SOFTEX, organizao no-governamental para gerenciar o programa SOFTEX.
Lei 10.176/01 (substitui a anterior - janeiro/01) plano de P&D, modifica
os percentuais de incentivos (IPI), credenciamentos.
Portaria MCT-051/2003 regula a participao das empresas beneficirias
dos incentivos fiscais previstos no art. 4 da Lei 8248, de 23/10/1991.
Lei 11.077 (substitui a anterior - dezembro/04) incluindo tecnologia nacional.
Tabela C.1: Histrico dos marcos das aes polticas do Brasil
Figura C.1: Porte das empresas brasileiras de software
PME que visam crescimento.

O mercado interno atrativo favorece PME na atuao em nichos que grandes
empresas no conseguem atuar, Freire [2002];
As redes de relacionamento foram importantes para o sucesso da ndia no mercado de Tecnologias da Informao e da Comunicao (TIC). O elevado nmero
de indianos atuantes em empresas norte-americanas facilitou o contato com empresas do pas asitico. Kubota [2006]. A venda de servios de software depende
133
da reputao da empresa fornecedora, da existncia de um relacionamento de

confiana mtua entre as partes vendedor e comprador, visto a caracterstica intangvel do software. Por um lado, esse fator favorece PME em atuaes locais
porm, considerado um das barreiras mais significativas exportao devido
inexistncia de uma estrutura de vendas e suporte no exterior, prximo ao cliente,
Pond [1993];
Existe no mercado brasileiro carncia de pessoal com habilidades no ingls e em
tecnologias mais avanadas, Kubota [2006].
O Brasil vem desenvolvendo vrios programas de incentivos exportao, como
incentivos fiscais, financiamento direto via BNDES, programas de melhoria da
qualidade e produtividade. fato que os programas de incentivos exportao
tem estado longe de alcanar as metas colocadas. As aes no tm sido efetivas,
Kubota [2006]. Outros orgos buscam, ainda com incentivos governamentais,
planos de ao para promover a importncia do Brasil no mercado mundial de
sourcing. Exemplos: A Brascom, Associao Brasileira de Companhias Exportadoras de Software e Servios, a Sociedade Softex, Sociedade Brasileira para
Promoo da Exportao de Software.
Com foco na exportao para o mercado norte americano, o Brasil tem barreiras
com a lingua inglsa e tem facilitadores como proximidade das caractersticas culturais, similaridades de negcios, como o sistema financeiro, alm da proximidade
do fuso horrio, Arajo & Meira [2004].
De acordo com empresas pesquisadas em Softex & Unicamp [2005], os Estados
Unidos, com cerca de 30% e em seguida, a Unio Europeia com 20%, representam
os principais mercados-alvo das exportaes de software e servios correlatos.
O mercado de software no impe barreiras para a entrada de novas empresas,
alm do custo inicial para criao da empresa ser relativamente baixo, comparado a outros produtos que demanda processos industriais. Porm, software como
servio tem custo fixo muito alto, fator que impe barreiras ao crescimento dessas empresas. Grandes empresas dominam os principais mercados e tm poder
financeiro que permite a essas diversificar suas atividades, Freire [2002].
O modelo de comercializao de software sobre encomenda tem virado commodity, vende quem tem o menor preo. Esse modelo caracteriza o mercado interno
e boa parte da expanso das exportaes brasileiras Softex & Unicamp [2005].
134
Apndice C. Anlise do cenrio atual do mercado de software

nacional
A economia de rede garante o poder de mercado para empresas que estabeleceram primordiamente padres tecnolgicos dominantes, resultando no efeito de
"trancamento"(lock-in), Roselino [2006b].
A obteno de crdito, no mercado financeiro, para empresas desenvolvedoras
de software no amplamente exercido, visto a natureza intangvel do software
que dificulta a apresentao de garantigas reais. Esse fato motivou o BNDES,
atravs do programa Prosoft, a disponibilizar, sem garantias reais, financiamentos
a partir de um piso muito baixo (R$ 400 mil), que favorece empresas de pequeno
porte, Gutierrez [2007]. Por outro lado os riscos de mercado so menores, pois
as vendas so efetuadas antes da produo, Pond [1993].
Em empresas de servios profissionais, de acordo com Cardozo [2009], os ativos
mais importantes - metodologias, carteira de clientes, cultura, reputao - so
intangveis e "o acervo de conhecimento seu estoque de produtos". Esse o
caso das empresas de software como servios.
A interatividade entre cliente e o desenvolvedor, para software como servio, intrnseca ao processo de produo. Como fator competitivo preponderante esto o
conhecimento nas atividades tcnicas e o conhecimento negocial das necessidades
dos clientes, Pond [1993].
Empresas desenvolvedoras de software tm uma demanda de variados perfis profissionais qualificados, desde analistas de requisitos, desenvolvedores, testadores,
gestores da qualidade, entre outros. Em PME o nmero total de profissional
limitado, tornando restrita a disponibilidade de um profissional qualificado para
realizar controle estatstico de processos, alm da carncia desse tipo de profissional. De acordo com Costa et al. [2008], CEP assunto obrigatrio em todos os
cursos de Engenharia. Contraditoriamente, o CEP no disciplina obrigatria
nos currculos dos engenheiros de software.
As 20 maiores indstrias de software do mundo se concentram nos EUA, Japo
e Alemanha. Essa indstria representa, para a maioria dos paises listados, entre 1% a
2% da economia dos respectivos pases. Irlanda, Israel e ndia, conhecidas como 3Is, se
destacam nas exportaes. O Brasil no tem relevncia no mercado de exportao mas
se destaca no mercado nacional, em tamanho e nvel de desenvolvimento econmico.
A tabela C.2 apresenta os Fatores de competitividade da indstria de software,
para software em pacotes e sob encomenda, de acordo com Pond [1993]:
135
Figura C.2: Fatores da competitividade
As grandes empresas no mercado de software de pacote horizontal atuam explorando as vantagens da economia de escala: rede de vendas, suporte e marca reconhecida,
onde o papel do marketing um fator decisivo, Pond [1993]. As grandes empresas dos
mercados de software por encomenda competem com base nas habilidades de fornecer solues "customizadas"para os problemas especficos dos clientes e servios como
consultorias, treinamentos, etc.
Para as empresas de menor porte, a sobrevivncia no mercado, em parte, pela
"estratgia de nicho", na qual a empresa se especializa no atendimento das necessidades
especficas de um grupo de clientes. Para isso necessrio que essas empresas construam
uma imagem de confiabilidade consolidada, baseadas em vnculos de confiana mtua.
Outra estratgia de sobrevivncia a "estratgia de interstcio", onde o software
explorado na diferenciao para ocupar espaos deixados por empresas lderes, Pond
[1993].
ABES
(2009a).
Mercado
brasileiro
de
software
2009.
http://www.abes.org.br/templ3.aspx?id=306&sub=487. ABES Associao Brasileira das Empresas de Software - Consultado em outubro/09.
ABES (2009b). Mercado brasileiro de software panorama e tendncias - 2009.
http://www.abes.org.br. ABES Associao Brasileira das Empresas de Software.
Apostila (2002). Kano model analysis. http://www.ucalgary.ca/ design/engg251/First
Year Files/kano.pdf. Design and Communication Course. Consultado em 26/06/09.
AppLabs (2008). Future of software testing. http://www.applabs.com/internal/app_whitepaper_future_software_testing_1v001.pdf. Consultado em 12/10/09.
Arajo, E. E. R. & Meira, S. R. L. (2004). Insero competitiva do Brasil no mercado internacional de software. http://www.scribd.com/doc/4672450/Industria-desoftware-no-Brasil. Captulo 6 - O futuro da indstria de software. Consultado em
24/09/09.
Baldassare, M. T.; Boffoli, N.; Caivano, D. & Visaggio, G. (2005). Improving dynamic calibration through statistical process controle. In Conference on Software
Maintenance and Reengineering (CSMR).
Baldassarre, M. T.; Caivano, D.; Kitchenham, B. & Visaggio, G. (2007).
Systematic review of statistical process control:
An experience report.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.101.6305rep=rep1type=pdf.
Basili, V. R. (1993). Applying the goal/question/metric paradigm in the experience factory. In Tenth Annual Workshop Centre for Software Reliability (CSR),
http://www.cs.umd.edu/ basili/publications/proceedings/P62.pdf.
Berry, L. L. & Pasuraman, A. (2004). Marketing Services: Competing Through Quality.
Simon & Schuster.
137
138
Brocka, B. & Brocka, M. S. (1995). Gerenciamento da qualidade Implementando TQM,

passo a passo, atravs dos processos e ferramentas recomendadas por Juran, Deming,
Crosby e outros mestres. Markon Books.
Caivano, D. (2005). Continuous Software Process Improvement through satatistical
process control. In Conference on Software Maintenance and Reengineering (CSMR).
Cardozo, J. S. (2009). O fim do taxmetro. HSM Management.
Champ, W. C. & Woodall, H. W. (1987). Exact Results for Shewhart Control Charts
With Supplementary Runs Rules. Technometrics.
Cheng, L. C. & Melo, L. D. R. (2007). QFD - Desdobramento Da Funo Qualidade
Na Gesto De Desenvolvimento De Produtos. Edgard Blucher.
Chillarege, R.; Bhandari, I. S.; Chaar, J. K.; Halliday, M. J.; Moebus, D. S.; Ray, B. K.
& Wong, M.-Y. (1992). Orthogonal defect classification - A concept for in-process
measurements. In IEET, volume 18, pp. 943 956.
Chrissis, M. B.; Konrad, M. & Shrum, S. (2005). CMMI Guidelines for Process Integration and Product Improvement. Addison Wesley, 1.1 edio.
Cobb, R. H. & Mills, H. D. (1990). Engineering software under statistical quality
control. IEEE Software, 7:4454.
Cooper, D. & Schindler, P. (2001).
Mtodos de Pesquisa em Administrao.
The McGraw-Hill Companies, Inc.
E-book consultado em 11/09/09
http://books.google.com.br/books?id=lpfVATveeckC&printsec=frontcover.
Costa, A. F. B.; Epprecht, E. K. & Carpinetti, L. C. R. (2008). Controle Estatstico
de Qualidade. Editora Atlas S.A.
Crosby, P. B. (1979). Quality Is Free. Mentor.
Cusumano, M. A. & Markides, C. C. (2002). Pensamento Estratgico. Editora Campus.
Deming, W. E. (1986). Out of the Crisis. The MIT Press.
Dodson, J. (2008).
Customer defined attributes:
The Kano
http://faculty.washington.edu/jdods/pdf/MktgTool_Kano_Generic.pdf.
sultado em 26/06/09.
model.
Con-
Emam, K. E. & Wieczorek, I. (1998). The repeatability of code defect classifications.

In International Symposium on Software Reliability Engineering (ISSRE), p. 322.
139
Faria,
C. (2009).
Desdobramento da funo qualidade (QFD).
http://www.infoescola.com/administracao_/desdobramentodafuncaoqualidadeqfd.
Fitzsimmons, J. A. & Fitzsimmons, M. J. (2004). Administrao de Servios: Operaes, Estratgias e Tecnologia da Informao. Artmed Editora S.A. E-book consultado em 25/09/09 http://books.google.com.br/books?hl=pt-BR&lr=&id=zJ_zE4I38CMC&oi=fnd.
Florac, W. A. & Carleton, A. D. (1999). Measuring the Software Process - Statistical
Process Control for Software Process Improvement. Addison-Wesley. Foreword by
Watts S. Humphrey.
Florac, W. A. & Carleton, A. D. (2000). Statistical process control: Analysing a space
shuttle onboard software process. IEEE Software. Consultado em 10/07/09.
Freire, E. (2002).
Inovao e competitividade: O desafio a ser enfrentado
pela indstria de software. Masters thesis, Universidade Estadual de Campinas, http://libdigi.unicamp.br/document/?code=vtls000242713. Consultado em
14/10/09.
Fuoco, T. (2009). Mercado de software chega a US$15 bi no brasil com alta
de 35 porcento.
http://portalexame.abril.com.br/agencias/reuters/reuterstecnologia/detail/mercado-software-chega-us-15-bi-brasil-alta-35-375775.shtml.
Consultado em 24/09/09.
Garcia, D. & Leite, M. M. (2006). Anlise e gesto de riscos nas micro e pequenas
empresas de softwares. Consultado em novembro 2009.
George, M. L. (2004). Lean Seis Sigma para Servios. Quality Mark.
Goethert, W. & Fisher, M. (2003). Deriving Enterprise-Based Measures Using the
Balanced Scorecard and Goal-Driven Measurement Techniques. Software Engineering
Institute - SEI.
Gonalves, F. M. G.; Bezerra, C. I. M.; Belchior, A. D. C.; Carneiro, C. & Pires, C.
G. S. (2008). A strategy for identifying, classifying and prioritizing improvement
and innovation actions: A CMMI level 5 and Six Sigma approach. ASWEC 19th
Australian Conference on Software Engineering, pp. 104 111.
Gutierrez, R. M. V. (2007). Complexo eletrnico: O setor de software brasileiro e o
Prosoft. Technical Report 26, Departamento da Indstria Eletrnica do BNDES.
140
Gutierrez, R. M. V. & Alexandre, P. V. M. (2004). Complexo eletrnico: Introduo

ao software. Technical Report 20, Departamento da Indstria Eletrnica do BNDES.
Hunter, J. S. (1989). A One-Point Plot Equivalent to the Shewhart Chart with Western
Electric rules, volume 2. Quality Engineering.
IEEE (1995). IEEE Guide to Classification for Software Anomalies. IEEE Power
Engineering Society.
IEEE (1997). Ieee standard for software reviews.
IEEE (1998). Ieee standard for software maintenance.
Jalote, P. (2003).
On optimum module size for software inspections.
http://www.cse.iitk.ac.in/users/jalote/OptModuleSize/Optimum%20Module
ize%20for%20Software%20Inspection.PDF. Consultado em novembro/2009.
Jalote, P. & Saxena, A. (2002). Optimum control limits for employing statistical
process control in software process. In IEEE Transactions on Software Engineering,
volume 28, pp. 1126 1134.
Jung, C. F. (2004). Metodologia para pesquisa e desenvolvimento: aplicada a novas
tecnologias, produtos e processos. Axcel Books do Brasil.
Junior, F. J. M. & ten Caten, C. S. (2004).
Estudo sobre o efeito
da autocorrelao de modelos ar(1) no controle estatstico de processo.
XXIV Encontro Nac. de Eng. de Produo - Florianpolis, SC, Brasil.
http://www.abepro.org.br/biblioteca/ENEGEP2004_Enegep0202_1891.pdf.
Juran, J. M. (1998). Juran on Planning for Quality. Free Pr.
Kan, S. H. (2004).
Metrics and models in software quality engineering.
Addison-Wesley.
E-book consultado em 09/09/09
http://books.google.com.br/books?id=EaefcL3pWJYC&printsec=frontcover.
Kano, N. (1984). Attractive quality and must-be quality. Hinshitsu: The Journal of
the Japanese Society for Quality Control, 14(2):3948.
Kaplan, R. S. & Norton, D. P. (1997). A Estratgia em Ao Balanced Scorcard.
Editora Campus.
Kelly, D. & Shepard, T. (2001). A case study in the use of defect classification in
inspections. IBM Centre for Advanced Studies Conference, p. 7. Proceedings of the
2001 conference of the Centre for Advanced Studies on Collaborative research.
141
Kim, J. A.; Choi, S. Y. & Kim, T.-H. (2008). Management environment for Software
Process Improvement. CSA 08 International Symposium on Computer Science and
its Applications, pp. 292 296.
Kloppenborg, T. J. & Petrick, J. A. (2002). Managing Project Quality. Management
Concepts Inc.
Komuro, M. (2006). Experiences of applying SPC techniques to software development
processes. In Proceedings of the International Conference on Software Engineering
(ICSE).
Kubota, L. C. (2006). Desafios para a indstria de sofware. IPEA Instituto de Pesquisa
Econmica Aplicada.
Lantzy, M. A. (1992). Application of statistical process control to the software process.
Washington Ada Symposium, pp. 113 123.
Levine, D. M.; Berenson, M. L. & Stephan, D. (2000). Estatstica: Teoria e Aplicaes.
LTC - Livros Tcnicos e Cientficos Editora S.A.
Lobo, A. P. (2009). Exportao brasileira de software e servios de TI cresce 36%.
http://www.convergenciadigital.com.br/cgi/cgilua.exe/sys/start.htm?infoid=20444&sid=16
ou
http://naaltaounabaixa.wordpress.com/2009/09/25/exportacao-brasileira-desoftware-e-servicos-de-ti-cresce-36/. Consultado em 08/11/09.
Madison, D. (2005). Process mapping, process improvement, and process management:
a practical guide to enhancing work and information flow. Scott M. Paton. E-book
consultado em 24/09/09 http://books.google.com/books?id=n0k0Rbkbq3YC.
Martins, W. M. (2004). Competitividade brasileira e casos de sucesso do software nacional. http://www.scribd.com/doc/4672450/Industria-de-software-no-Brasil. Captulo
8 - O futuro da indstria de software. Consultado em 24/09/09.
Messerschmitt, D. G. & Szyperski, C. (2000). Industrial and economic properties of
software technology, processes, and value. Technical report, Department of Electrical
Engineering and Computer Sciences University of California and Microsoft Research.
Meyer, P. L. (1983). Probabilidade Aplicaes Estatstica. LTC Livros Tcnicos e
Cientficos Editora. Traduo: Ruy de C.B. Loureno Filho.
142
Minitab
(2008).
Minitab
Support.
Minitab
Software
for
Quality
Improvement,
http://www.minitab.com/enBR/support/answers/answer.aspx?log=0&id=1167&langType=1033. Consultado
em 04/2010.
Montgomery, D. C. (2004). Introduo ao Controle Estatstico da Qualidade. Livros
Tcnicos e Cientficos Editora S.A.
Montoni, M.; Kalinowski, M.; Lupo, P.; Abrantes, J. F.; Ferreira, A. I. F. & Rocha,
A. R. (2007). Uma metodologia para desenvolvimento de modelos de desempenho de
processos para gerncia quantitativa de projetos de software. SBQS - VI Simpsio
Brasileiro de Qualidade de Software.
Murugappan, M. & Keeni, G. (2000). Quality improvement-the Six Sigma way. In
First Asia-Pacific Conference on Quality Software, 2000, pp. 248 257.
NIST/SEMATECH
(2010).
Engineering
http://www.itl.nist.gov/div898/handbook.
statistics
handbook.
Pan, Z.; Park, H.; Baik, J. & Choi, H. (2007). A Six Sigma framework for Software
Process Improvements and its implementation. APSEC 14th Asia-Pacific Software
Engineering Conference, pp. 446 453.
Park, R. E.; Goethert, W. B. & Florac, W. A. (1996). Goal-Driven Software Measurement - A Guidebook. Software Engineering Institute - SEI.
PMI, P. M. I. (2009). A Guide to the Project Management Body of Knowledge - Third
Edition, Paperback. Project Management Institute, Inc.
Pond, J. L. (1993). Estudo da competitividade da indstria brasileira - competitividade da indstria de software. Nota Tcnica Setorial do Complexo Eletrnico MCT
http://www.mct.gov.br/upd_blob/0002/2327.pdf. MCT, FINEP, PADCT.
Pressman, R. S. (1997). Software Engineering A Practitioners Approach. MacGrawHill Companies, fourth edition edio.
PSM (2003). Practical Software and Systems Measurement A Foundation for Objective
Project Management. Department of Defense US Army.
Redzic, C. & Baik, J. (2006). Six Sigma approach in software quality improvement. In
Proceedings of the Fourth International Conference on Software Engineering Research, Management and Applications (SERA), pp. 396 406.
143
Rose, K. H. (2005). Project Quality Management: Why, What and How. J. Rosss
Publishing.
Roselino, J. E. (2006a). A Indstria de Software: o modelo brasileiro perspectiva comparada. PhD thesis, Universidade Estadual de Campinas Instituto de Econ2006omia.
Roselino,
J.
E.
(2006b).
Panorama
da
indstria
brasileira
de
software:
Consideraes
sobre
a
poltica
industrial.
http://www.ipea.gov.br/sites/000/2/livros/estruturadinamica/capitulo%208_roselino.pdf. Captulo 8 - H espao no mercado de software? - Consultado em
dezembro/09.
Sargut, K. U. & Demirrs, O. (2006). Utilization of Statistical Process Control (SPC) in
emergent software organizations: Pitfalls and suggestions. Software Quality Journal,
14(2):135157.
SEI, S. E. I. (1996). IDEAL: A Users Guide for Software Process Improvement.
Software Engineering Institute SEI, http://www.sei.cmu.edu/ideal/. Handbook
CMU/SEI-96-HB-001.
Serrano, M. A. (2004). State of the art and future of research in Software Process
Improvement. In Proceedings of the Annual International Conference on Computer
Software and Applications (COMPSAC), p. 239.
Shewhart, W. A. (1931). Economical Control of Quality of Manufactured Product.
Amer Society for Quality.
Shimakura, S. (2006). Ce003 - Estatstica II. Departamento de Estatstica-UFPR,
http://leg.ufpr.br/ silvia/CE003/notes.html. Consultado em 11/09.
Siviy, J.; Penn, M. L. & Harper, E. (2005).
Relationships Between
R
CMMI
and Six Sigma.
Software Engineering Insttute SEI,
ftp://ftp.sei.cmu.edu/public/documents/05.reports/pdf/05tn005.pdf.
Technical
Note CMU/SEI-2005-TN-005.
Softex & Unicamp (2005). Perfil das empresas brasileiras exportadoras de software.
http://www.mbi.com.br/MBI/biblioteca/papers/200510softex/. Relatrio de Pesquisa Consultado em 12/05/09.
Tinnirello, P. C. (2002). New Directions in Project Management. Auerbach Publications. Captulo 15 - Incorporating Six Sigma Concepts into Systems Analysis.
144
Tontini, G. (2003). Como identificar atributos atrativos e obrigatrios para o consumidor. http://proxy.furb.br/ojs/index.php/rn/article/view/325/0. Revista de Negcios, Vol. 8, No 1 Consultado em 26/06/09.
Travassos, G. H.; ; Gurov, D. & do Amaral, E. A. G. (2002). Introduo Engenharia de Software Experimental. http://www2.ufpa.br/cdesouza/teaching/topes/4-ESExperimental.pdf. Consultado em 12/05/09.
Travassos, G. H. & Kalinowski, M. (2008). iMPS Resultados de desempenho de
organizaes que adotaram o modelo MPS. http://www.softex.br/mpsbr/_livros/imps/imps.pdf. Consultado em Junho/2010.
Wazlawick, R. S. (2008). Metodologia de Pesquisa para Cincia da Computao. Editora Campus.
Weller, E. F. (2000). Practical applications of statistical process control [in software
development projects]. IEEE Software, 17(3):48 55.
Wohlin, C.; Runeson, P.; Host, M.; Ohlsson, M. C.; Regneel, B. & Wessln, A. (2000).
Experimentation in Software Engineering: An Introduction. Kluwer Academic Plublishers. 1. Software engineering 2. Computer software-evaluation.
Wood, M. (1994). Statistical methods for monitoring service processes. In Internacional
Journal of Service Industry Management, volume 5, pp. 5368.
Wright, P.; Kroll, M. J. & Parnell, J. (2000). Administrao Estratgica - Conceitos.
Editora Atlas S.A.
Zhao, X.; He, Z.; Gui, F. & Zhang, S. (2008a). Research on the application of Six Sigma
in Software Process Improvement. In Proceedings of the International Conference
on Intelligent Information Hiding and Multimedia Signal Processing (IIHMSP), pp.
937940.
Zhao, X.; Zhen, H.; ZhangMin; Jing, W. & Dainuan, Y. (2008b). Process integration of
Six Sigma and CMMI. 6th IEEE International Conference on Industrial Informatics,
pp. 1650 1653.

Controle Estat Do Processo

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Controle Estat Do Processo

Enviado por

Direitos autorais:

Formatos disponíveis

MODELO PARA CONTROLE ESTATSTICO DE

PATRCIA CORRA FONSECA

MODELO PARA CONTROLE ESTATSTICO DE

Dissertao apresentada ao Programa de

Orientador: Clarindo Isaas P. S. Pdua

Belo Horizonte, Minas Gerais

c 2010, Patrcia Corra Fonseca.

Dedico este trabalho a meus pais, Glria e Marconi.

Pensar estatisticamente ser um dia, para a eficiente prtica da cidadania, to

Tipos de pesquisa segundo Jung [2004] . . . . . . . . . . . . . . . . . . . .

Grfico das Baleias - RUP Rational Unified Process . . . . . . . . . . . . .

Ilustrao de um Ciclo do PDCA . . . . . . . . . . . . . . . . . . . . . . .

Ilustrao do Modelo IDEAL . . . . . . . . . . . . . . . . . . . . . . . . .

Ilustrao do Ciclo DMAIC . . . . . . . . . . . . . . . . . . . . . . . . . .

Exemplo de um Diagrama SIPOC . . . . . . . . . . . . . . . . . . . . . . .

Escada Qualidade em Servios . . . . . . . . . . . . . . . . . . . . . . . . .

Viso de uma matriz Desdobramento da Funo da Qualidade . . . . . . .

Tabela Classificao Modelo Kano . . . . . . . . . . . . . . . . . . . . . . .

Parmetros de controle LC, LSC e LIC . . . . . . . . . . . . . . . . . . . .

Limites de controle e especificao . . . . . . . . . . . . . . . . . . . . . . .

Exemplo de Histograma - nmero de defeitos por tipo . . . . . . . . . . . .

Exemplo de Diagrama de Pareto - nmero de defeito por tipo . . . . . . .

3.10 Exemplo de grfico para anlise de custo x benefcio . . . . . . . . . . . . .

Viso das atividades para aplicao de CEP . . . . . . . . . . . . . . . . .

Viso dos processos de desenvolvimento de software . . . . . . . . . . . . .

Goal-Driven Software Measurement . . . . . . . . . . . . . . . . . . . . . .

Mapa estratgico BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Viso integrada das 3 ferramentas . . . . . . . . . . . . . . . . . . . . . . .

Digrama de deciso para grfico de controle . . . . . . . . . . . . . . . . .

4.10 Classificao de defeitos . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.11 Atividades para estabilizar o processo . . . . . . . . . . . . . . . . . . . . .

4.12 Controle Estatstico de Processo . . . . . . . . . . . . . . . . . . . . . . . .

[IR-ReP] Teste de normalidade . . . . . . . . . . . . . . . . . . . . . . . .

[IR-ReP] MMEP (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

[IR-ReP] MMEP (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

[IR-PrP] Teste de normalidade . . . . . . . . . . . . . . . . . . . . . . . . .

[IR-PrP] MMEP (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

[IR-PrP] MMEP (4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

[IR-PPP] Teste de normalidade . . . . . . . . . . . . . . . . . . . . . . . .

[IR-PPP] MMEP (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

[IR-PPP] MMEP (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.10 Participao dos Processos em Produo . . . . . . . . . . . . . . . . . . .

5.11 [IR-DeP] Teste de normalidade . . . . . . . . . . . . . . . . . . . . . . . .

5.12 [IR-DeP] MMEP (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.13 [IR-DeP] MMEP (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.14 [DR-ReP] MMEP (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

C.1 Porte das empresas brasileiras de software . . . . . . . . . . . . . . . . . . 132

Comprimentos Mdios de Sequncias para CM S1 . . . . . . . . . . . . . .

Atividades dos processos alvo de CEP . . . . . . . . . . . . . . . . . . . .

B.1 Classificao do Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Organizao deste documento . . . . . . . . . . . . . . . . . . . . . . .

CEP e a melhoria de processos de desenvolvimento de software . . . . .

O primeiro momento de reviso . . . . . . . . . . . . . . . . . .

O segundo momento de reviso . . . . . . . . . . . . . . . . . .

Caracterizao das PME desenvolvedoras de software . . . . . . . . . .

3 O controle estatstico de processo (CEP)

Viso geral dos grficos de controle . . . . . . . . . . . . . . . . . . . .

Tamanho da amostra e frequncia de amostragem . . . . . . . . . . . .

Testes de hiptese, nvel de significncia e P-valor . . . . . . . . . . . .

Testes para deteco de situaes fora-de-controle . . . . . . . . . . . .

3.10 Grficos de controle X-Barra, S e R . . . . . . . . . . . . . . . . . . . .

3.11 Grfico de controle X Barra-Individual . . . . . . . . . . . . . . . . . .

3.12 Grficos de controle para no-conformidades (Defeitos) . . . . . . . . .