Documente Academic
Documente Profesional
Documente Cultură
PROCESSOS DE DESENVOLVIMENTO DE
SOFTWARE (CEP-S)
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
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!
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
11
2.1
20
2.2
21
2.3
22
2.4
24
2.5
25
2.6
27
2.7
28
2.8
29
3.1
Variao controlada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.2
Variao no controlada . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.3
41
3.4
46
3.5
Correlao Forte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
3.6
Correlao Fraca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
3.7
Testes de controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
3.8
56
3.9
57
58
4.1
60
4.2
63
4.3
Caractersticas de interesse . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
4.4
75
4.5
Estratgia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
4.6
79
4.7
81
xvii
4.8
86
4.9
Parmetros de controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
88
88
90
5.1
94
5.2
95
5.3
95
5.4
96
5.5
96
5.6
96
5.7
97
5.8
97
5.9
97
98
99
99
99
xix
Lista de Tabelas
3.3
46
57
4.1
4.2
65
77
3.1
3.2
45
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
15
2 Reviso bibliogrfica
17
2.1
Principais conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.2
30
2.2.1
30
2.2.2
31
34
2.3
37
3.1
Mtodos estatsticos . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.2
40
3.3
Limites de controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.4
Limites de especificao . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.5
47
xxiii
3.6
47
3.7
Coeficiente de correlao . . . . . . . . . . . . . . . . . . . . . . . . . .
48
3.8
Testes de normalidade . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
3.9
50
52
53
54
54
55
56
57
4 O Modelo CEP-S
4.1
59
61
4.1.1
62
4.1.2
64
4.1.3
Consideraes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
4.1.4
Guia de personalizaes . . . . . . . . . . . . . . . . . . . . . .
68
70
4.2.1
As Caractersticas de interesse . . . . . . . . . . . . . . . . . . .
70
4.2.2
73
4.3
80
4.4
85
4.5
88
4.6
89
4.2
5 Estudo de caso
5.1
91
91
5.1.1
94
5.1.2
5.1.3
5.1.4
5.2
5.3
6 Concluso
6.1
117
127
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
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
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
1.3
Limites do trabalho
10
Captulo 1. Introduo
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
11
12
Captulo 1. Introduo
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
15
1.5
16
Captulo 1. Introduo
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
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
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
22
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
25
26
27
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
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
30
2.2
2.2.1
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.2
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
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
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-
35
36
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
37
38
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.
39
3.1
Mtodos estatsticos
40
3.2
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)
41
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
43
Limites de controle
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
1
p(um ponto aparece fora-de-controle)
(3.2)
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
0,9772
0,8413
0,5000
CM S1
43,96
6,30
2,00
3.4
Limites de especificao
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
3.5
47
3.6
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)
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:
(3.5)
P = 1 (Z0 )
para o teste superior
(Z )
para o teste inferior
0
3.7
Coeficiente de correlao
cov(X, Y )
E[X E(X)][Y E(Y )]
p
=
x y
V (X)V (Y )
(3.6)
49
k =
cov(Xt , Xtk )
, k = 0, 1, ...
xt
(3.7)
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)
n
X
(2i 1)
i1
(3.9)
3.9
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
3.10
53
3.11
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
LSC = x + 3
MR
d2
(3.10)
LC = x
LIC = x + 3
MR
d2
M Ri = |xi xi1 |
Para amplitude mvel entre duas amostras, n = 2, temos d2 = 1, 128.
(3.11)
54
3.12
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
55
(3.13)
s
LSC = 0 + L
b1 (1 )2i c
(2 )
(3.14)
LC = 0
s
LIC = 0 L
3.14
b1 (1 )2i c
(2 )
56
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)
57
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
3.16
58
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
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.
61
4.1
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]
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
63
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
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
66
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
67
68
4.1.4
Guia de personalizaes
Um nico processo no serve a todo tipo de empresa.
Arajo & Meira [2004]
Processo de Requisitos
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
70
4.2
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.
71
72
73
4.2.2
74
4.2.2.1
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
4.2.2.2
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]
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.
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
78
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
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
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
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
81
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.
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
85
4.4
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.
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
defeitos, que so: Kelly & Shepard [2001], Chillarege et al. [1992], Emam & Wieczorek
[1998] e IEEE [1995].
4.5
89
4.6
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
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
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
93
94
5.1.1
5.1.1.1
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]
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
Teste de Autocorrelao
Correlao de Pearson = 0,004 [fraca e no significativa (|| 0, 09)]
Teste de Normalidade
P-valor < 0,005 [Valor esperado: P-valor > 0,005]
I
Grfico X
I no ser utilizado.
Devido no normalidade, o grfico X
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
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
Teste de Autocorrelao
Correlao de Pearson = -0,078 [fraca e no significativa (|| 0, 09)]
Teste de Normalidade
P-valor < 0,005 [Valor esperado: P-valor > 0,005]
I
Grfico X
I no ser utilizado.
Devido no normalidade, o grfico X
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.
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.
99
5.1.1.4
Teste de Autocorrelao
Correlao de Pearson = -0,034 [fraca e no significativa (|| 0, 09)]
Teste de Normalidade
P-valor < 0,005 [Valor esperado: P-valor > 0,005]
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.
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
5.1.2.1
Teste de Autocorrelao
Correlao de Pearson = 0,227 [fraca]
Teste de Correlao entre esforo de reviso e esforo de correo
Correlao de Pearson = 0,032 [fraca]
Teste de Normalidade
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
Teste de Autocorrelao
Correlao de Pearson = 0,226 [fraca]
Teste de Normalidade
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-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
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
Teste de Autocorrelao
Correlao de Pearson = 0,069 [fraca e no significativa (|| 0, 09)]
Teste de Normalidade
P-valor < 0,005 [Valor esperado: P-valor > 0,005]
I
Grfico X
I no ser utilizado.
Devido no normalidade, o grfico X
Grfico MMEP
[DR-PPP] MMEP (1), Figura 5.19 exibe situao do processo sob controle processo estvel.
103
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
Teste de Autocorrelao
Correlao de Pearson = 0,457 [moderada]
Teste de Normalidade
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.
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
5.1.3.1
105
Teste de Autocorrelao
Correlao de Pearson = 0,288 [fraca]
Teste de Correlao entre esforo de reviso e esforo de correo
Correlao de Pearson = 0,549 [moderada]
Teste de Normalidade
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
[DE-ReP] MMEP (1), Figura 5.22 exibe situao do processo sob controle - processo estvel.
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
Teste de Autocorrelao
Correlao de Pearson = 0,136 [fraca]
Teste de Normalidade
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
[DE-PrP] MMEP (1), Figura 5.23 exibe situao do processo sob controle - processo estvel.
Anlise
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 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
Teste de Autocorrelao
Correlao de Pearson = 0,110 [fraca]
Teste de Normalidade
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
[DE-PPP] MMEP (1), Figura 5.24 exibe situao do processo sob controle processo estvel.
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
5.1.4.1
Teste de Autocorrelao
108
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 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
Teste de Autocorrelao
Correlao de Pearson = -0,008 [fraca e no significativa (|| 0, 09)]
Teste de Normalidade
P-valor = 0,884 [Valor esperado: P-valor > 0,005]
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
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
Teste de Autocorrelao
Correlao de Pearson = 0,040 [fraca e no significativa (|| 0, 09)]
Teste de Normalidade
P-valor < 0,005 [Valor esperado: P-valor > 0,005]
I
Grfico X
I no ser utilizado.
Devido no normalidade, o grfico X
111
Grfico MMEP
[IM-PPP] MMEP (1), Figura 5.30 exibe situao do processo sob controle - processo estvel.
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
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
5.3
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
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
115
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
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
123
(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
(A.4)
(A.5)
Exemplo A.3 R(x) = {0, 1, 2} representa o contra domnio da varivel aleatria X do Exemplo A.2.
124
(A.6)
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)
R +
(A.10)
125
i Y )
(Xi X)(Y
n
ou
X
Y
cov(X, Y ) = XY
P
cov(X, Y ) =
(A.11)
A.2
(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;
127
128
Pacote
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
Vertical
129
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
133
134
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
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].
Referncias Bibliogrficas
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
Referncias Bibliogrficas
model.
Con-
Referncias Bibliogrficas
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
Referncias Bibliogrficas
Referncias Bibliogrficas
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
Referncias Bibliogrficas
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.
Referncias Bibliogrficas
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
Referncias Bibliogrficas
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.