z
PROGRAMA DE PÓS-GRADUAÇÃO STRICTO SENSU EM
GESTÃO DO CONHECIMENTO E DA TECNOLOGIA DA INFORMAÇÃO
Mestrado
DEFINIÇÃO DE UM CATÁLOGO DE MEDIDAS
PARA A ANÁLISE DE DESEMPENHO DE
PROCESSO DE SOFTWARE
Autor: Luis Felipe Salin Monteiro
Orientador: Profª Drª Káthia Marçal de Oliveira
LUIS FELIPE SALIN MONTEIRO
Definição de um Catálogo de Medidas para a Análise de Desempenho de
Processo de Software
Dissertação apresentada ao Programa de Pós-Graduação
Strictu Sensu em Gestão do Conhecimento e Tecnologia
da Informação da Universidade Católica de Brasília, como
requisito para obtenção do Título de Mestre em Gestão do
Conhecimento e Tecnologia da Informação.
Orientadora
: Prof.ª Dra. Káthia Marçal de Oliveira
Ficha elaborada pela Coordenação de Processamento do Acervo do SIBI – UCB.
Dissertação (mestrado) – Universidade Católica de Brasília, 2008.
Orientador: Káthia Marçal de Oliveira
1. Software – Medição. 2. Software - Desempenho. I. Oliveira,
Kathia Marçal de, orient. II. Título.
Agradecimentos
A Deus por ter-me concedido saúde, paz e a oportunidade de realizar este trabalho.
À minha esposa Suzana por ter compreendido os longos momentos de ausência,
dedicados inteiramente à elaboração deste trabalho.
Aos meus pais e irmãos pela convivência acolhedora, incentivo à pesquisa e educação
exemplar transmitida durante toda a minha vida, que culmina hoje com a publicação deste
trabalho.
À minha orientadora Dra. Káthia, pela orientação e cobrança constantes, mantendo a
motivação e persistência que me fizeram concluir esta pesquisa.
Aos meus colegas Ricardo Ajax, Luiz Carlos Ribeiro e Ana Paula Fukuda, pelo apoio
e por estarem sempre disponíveis para dividir idéias sobre a pesquisa.
RESUMO
Projetos de desenvolvimento de software têm apresentado problemas recorrentes de
desempenho de custo, prazo e qualidade. A complexidade de gestão destes projetos requer
que medidas de desempenho e técnicas de gestão quantitativa sejam aplicadas para identificar
de forma precisa a situação do projeto e prever a sua capacidade de atender aos objetivos
futuros. Contudo, os estudos a respeito deste tema apresentam exemplos de fracassos na
implantação de programas de medições nas organizações, devido à definição de um grande
número de medidas inúteis, muito complexas, não padronizadas e desalinhadas com a
estratégia da organização. Torna-se importante, então, identificar as medidas relevantes para a
avaliação de desempenho dos processos envolvidos no desenvolvimento de software.
Considerando que as áreas de processos da categoria de engenharia do CMMI-DEV
(
Capability Maturity Model Integration for Development
) correspondem à maior parcela do
esforço dos projetos de software, esta pesquisa tem como objetivo identificar um catálogo de
medidas que permitam a análise de desempenho destes processos. Para tal, foram coletadas e
classificadas as medidas de desempenho de software mais referenciadas na literatura. Estas
medidas foram então consolidadas em indicadores e organizadas em um catálogo, que permite
a análise do desempenho dos processos das áreas de processos de engenharia do modelo
CMMI-DEV, a partir de diferentes perspectivas de desempenho. Esta pesquisa apresenta um
exemplo da aplicação de algumas medidas do catálogo em um projeto de software, sugerindo
os passos para a implantação do catálogo nas organizações que buscam a análise precisa do
desempenho de seus processos de desenvolvimento de software.
ABSTRACT
Software development projects have showed recurring problems of performance on costs,
schedule and quality. The high complexity of managing these projects requires that
performance measures and quantitative management techniques be applied to identify
precisely the project’s situation and its ability to meet future goals. However, studies on this
subject have show several examples of failures in the implementation of measurement
programs due to a large number of complex, not standardized and unnecessary measures, not
aligned with the organization strategy. It is important to identify relevant measures to assess
the performance of the processes involved in software development. Considering that the
engineering process areas of CMMI-DEV (Capability Maturity Model for Development)
represents the largest amount of effort involved in software projects, this research aims to
identify a catalogue of measures, which allow the performance analysis of these processes. To
this end, the software performance measures most referenced in the literature were collected
and classified. These measures were then consolidated into indicators and organized in a
catalogue, which allows the analysis from different performance perspectives of the
engineering processes areas of CMMI-DEV. This research presents an application example of
the catalog of measures, and suggests the steps for the deployment of the catalog in
organizations that aims to precisely analyze the performance of its software development
processes.
LISTA DE FIGURAS
Figura 1: As três dimensões críticas de uma organização (Chrissis, Konrad, Shrum, 2003a, p.
4). ... 7
Figura 2: Áreas de processo envolvidas na gestão quantitativa (Adaptado de SEI, 2002). ... 19
Figura 3: Estrutura do gráfico de controle (Adaptada de Florac e Carleton, 1999, p. 77). ... 25
Figura 4: Fluxograma de decisão do gráfico de controle (Adaptado de Stapenhrust, 2005, p.
264) ... 27
Figura 5: Testes de instabilidade de processo ... 33
Figura 6: Passos para desenvolvimento do catálogo de medidas ... 38
Figura 7: Índice de desempenho de custos (XmR) ... 72
Figura 8: Índice de desempenho de prazo (XmR) ... 73
Figura 9: Valor agregado (Curva S) ... 73
Figura 10: Variação de custo ... 74
Figura 11: Orçamento no término ... 74
Figura 12: Cobertura de testes (XmR) ... 78
Figura 13: Custo da qualidade (Barras) ... 81
Figura 14: Percentual de custo da qualidade (XmR) ... 82
Figura 15: u Chart de Densidade de defeitos ... 85
Figura 16: Diagrama de Pareto de Densidade de defeitos ... 85
Figura 17: Eficácia de testes (XmR) ... 88
Figura 18: Eficácia de revisão (XmR) ... 89
Figura 19: Taxa de mudanças (XmR) ... 92
Figura 20: Volatilidade de requisitos (XmR) ... 93
Figura 21: Prazo de ciclo (barras)... 95
Figura 22: Prazo de ciclo relativo ao tamanho (XmR) ... 96
Figura 23: Prazo médio para a falha (XmR) ... 98
Figura 24: Produtividade (XmR) ... 101
Figura 25: Taxa de entrega (PF/mês) (XmR) ... 102
Figura 26: Reuso de código (XmR) ... 104
Figura 27: Taxa de remoção de defeitos (XmR) ... 107
Figura 29: Taxa de retrabalho por disciplina (Pareto) ... 110
Figura 30: Variação de esforço total (XmR) ... 113
Figura 31: Variação de esforço por disciplina (Pareto) ... 113
Figura 32: Variação de prazo total (XmR) ... 116
Figura 33: Variação de prazo por disciplina (Pareto) ... 116
Figura 34: Variação de tamanho (XmR) ... 119
Figura 35: Cartas XmR para medida de IDC do projeto ... 128
Figura 36: Cartas XmR para a medida IDP do projeto ... 129
Figura 37: Densidade de defeitos total do projeto ... 130
LISTA DE QUADROS
Quadro 1: Estrutura do modelo CMMI-DEV (SEI, 2006a, p. 31) ... 9
Quadro 2: Áreas de processo do modelo CMMI-DEV (Adaptado de SEI, 2006a, p. 44) ... 10
Quadro 3: Escalas de medição (FENTON; PFLEEGER, 1997, p. 45-53) (KAN, 2003, p.
59-61) (ISO/IEC, 2002, p. 5) ... 13
Quadro 4: Comparação dos modelos de especificação de medida ... 16
Quadro 5: Ferramentas para gestão quantitativa de projetos ... 23
Quadro 6: Resumo dos tipos de cartas de controle ... 28
Quadro 7: Fórmulas para o gráfico de controle XmR (Adaptado de Florac e Carleton, 1999, p.
95) ... 31
Quadro 8: Fórmulas para o gráfico de controle
u Chart
(Adaptado de Florac e Carleton, 1999,
p. 116) ... 32
Quadro 9: Medidas redundantes em diferentes trabalhos pesquisados ... 41
Quadro 10: Categorias de medição ... 41
Quadro 11: Exemplos de categorização de medidas ... 42
Quadro 12: Exemplos de eliminação de redundância pelo nome e descrição das medidas .... 43
Quadro 13: Exemplos de eliminação de redundâncias pela fórmula das medidas ... 45
Quadro 14: Exemplos de medidas cuja relação com as APs do CMMI-DEV é apresentada na
literatura... 48
Quadro 15: Exemplos de medidas cuja relação com as APs do CMMI-DEV foi identificada a
partir de suas características ... 50
Quadro 16: Conjunto final de medidas do catálogo ... 56
Quadro 17: Distribuição das medidas do catálogo por categoria e área de processo ... 59
Quadro 18: Exemplos de diferentes interpretações das medidas para cada área de processo . 61
Quadro 19: Definição dos indicadores e medidas a serem especificadas no catálogo ... 66
Quadro 20: Distribuição dos indicadores do catálogo por categoria e área de processo ... 69
Quadro 21: Linha de base para as medidas IDC e IDP (XmR)... 127
Quadro 22: Linha de base para a medida de Densidade de defeitos (u
Chart
) ... 127
LISTA DE TABELAS
Tabela 1: Distribuição de medidas por categoria ... 42
Tabela 2: Distribuição de medidas por área de processo ... 48
Tabela 3: Lista de medidas referenciadas por três ou mais autores ... 52
Tabela 4: Medidas eliminadas pela redundância de objetivo ... 54
SUMÁRIO
1.
Introdução ... 1
1.1.
Motivação e contexto ... 1
1.2.
Objetivos ... 3
1.2.1.
Objetivo geral ... 3
1.2.2.
Objetivos específicos ... 3
1.3.
Metodologia ... 4
1.3.1.
Classificação da pesquisa ... 4
1.3.2.
Hipóteses e suposições ... 4
1.3.3.
Coleta de dados... 5
1.3.4.
Organização da dissertação ... 6
2.
Referencial teórico ... 7
2.1.
Processos de software ... 7
2.1.1.
Modelos de processos de software ... 8
2.2.
Medição de software... 11
2.2.1.
Conceituação ... 11
2.2.2.
Fatores críticos da implantação de programas de medição ... 13
2.2.3.
Modelos de especificação de medidas ... 15
2.2.4.
Medidas de processos de software... 15
2.3.
Análise de desempenho de processos de software ... 18
2.3.1.
Análise de desempenho de processos segundo o modelo CMMI-DEV ... 18
2.3.2.
Entendimento do desempenho do processo organizacional ... 20
2.3.3.
Importância da estabilidade do processo ... 21
2.3.4.
Ferramentas de análise de desempenho de processos ... 22
2.3.5.
Gráficos de controle ... 24
2.4.
Gestão quantitativa de projetos de software ... 34
2.5.
Considerações finais do capítulo ... 36
3.
Definição do catálogo de Medidas ... 37
3.1.
Visão geral dos passos para definição do catálogo ... 37
3.2.
Seleção das medidas de desempenho de software ... 40
3.2.1.
Revisão da literatura e identificação das medidas ... 40
3.2.2.
Categorização das medidas ... 41
3.2.4.
Mapeamento das medidas em relação ao CMMI-DEV ... 47
3.2.5.
Seleção das medidas mais referenciadas na literatura ... 50
3.3.
Consolidação do catálogo ... 62
3.3.1.
Seleção do modelo de especificação de indicador ... 62
3.3.2.
Seleção do conjunto de indicadores a serem especificados ... 65
3.3.3.
Seleção de técnicas para a gestão quantitativa de projetos ... 70
3.3.4.
Especificação dos indicadores e consolidação do catálogo ... 70
3.4.
Considerações finais do capítulo ... 120
4.
Exemplo de Uso do Catálogo de Medidas ... 122
4.1.
Caracterização do estudo de caso ... 122
4.2.
Seleção dos processos e medidas de desempenho ... 123
4.3.
Coleta de dados de desempenho dos processos ... 124
4.4.
Definição da linha de base de desempenho dos processos ... 126
4.5.
Avaliação do desempenho dos processos ... 128
4.6.
Considerações finais do capítulo ... 131
5.
Conclusão ... 132
Referências Bibliográficas ... 135
APÊNDICE A
- Lista completa de medidas citadas na literatura ... 143
1.
INTRODUÇÃO
1.1.
Motivação e contexto
Projetos de desenvolvimento de software têm demonstrado problemas recorrentes de
desempenho, sendo que a maioria destes projetos utiliza mais recursos e tempo do que o
planejado e provê menos funcionalidades e qualidade no produto do que o esperado
(BARROS; WERNER; TRAVASSOS, 2006, p. 1).
Após diversos anos de falhas e compromissos não atingidos, torna-se necessário
encontrar uma forma mais adequada de produzir produtos e serviços de software (FLORAC;
CARLETON, 1999, p. 1). A complexidade de gestão de projetos de desenvolvimento de
software requer que, além da experiência do gerente de projetos, técnicas de gestão
quantitativa sejam aplicadas de forma a perceber objetivamente a situação do projeto e prever
a sua capacidade em atender aos seus objetivos.
O sucesso dos projetos de software depende da capacidade da organização prever o
seu desempenho e assumir compromissos atingíveis. Processos efetivos de medição auxiliam
no gerenciamento destes projetos, pois permitem à organização entender a sua capacidade de
forma a desenvolver planos atingíveis para a entrega de produtos e serviços (FLORAC;
CARLETON, 1999, p. 10).
Modelos de melhoria de processos como o CMMI-DEV (SEI, 2006a, p. 58), afirmam
que a gestão quantitativa de projetos envolve a aplicação de técnicas estatísticas para
gerenciar o desempenho do projeto e a qualidade do produto de software.
Diversos autores (HALL; FENTON, 1997) (TAKARA; BETTIN; TOLEDO, 2007)
(AGRESTI, 2006) (BERANDER; JÖNSSON, 2006) (MUKHOPADHYAY; KRISHNAN,
2005) expõem as barreiras e melhores práticas da implantação de medições no contexto de
uma organização de software. As melhores práticas buscam normalmente uniformizar e
simplificar os mecanismos de medição, tornando mais clara e menos custosa esta atividade
para o processo de desenvolvimento de software.
e Grinter (1998) afirmam que a implementação de um programa efetivo de medições é uma
tarefa árdua e de alto risco.
Com o passar do tempo, os autores passaram a focar seus trabalhos na avaliação dos
programas de medições em prática nas organizações. Takara, Bettin e Toledo (2007), Agresti
(2006) e Berander e Jönsson (2006) abordam o problema da grande quantidade de medidas
inúteis e acrescentam que esta realidade tem como conseqüência a perda do foco e
credibilidade dos programas de medições. Agresti (2006) e Berander e Jönsson (2006),
propõem diferentes
frameworks,
apoiados na utilização do GQM (
Goal Question Metric),
introduzido por Basili, Caldiera e Rombach (2002), como ferramenta de apoio à definição de
medidas efetivas.
Nesta mesma linha de trabalho, Hall e Fenton (1997) e Gopal, Mukhopadhyay e
Krishnan (2005), avaliam diferentes programas de medições em corporações de TI por meio
de pesquisas com o objetivo de obter o nível de aceitação das medições pelos profissionais
das organizações. Os resultados esclarecem os principais aspectos a considerar para a
implantação de um programa efetivo de medições.
Diversos trabalhos abordam a aplicação de medições orientada por modelos de
maturidade e capacidade, como o CMMI (
Capability Maturity Model Integration
). O SEI
(2006b) realizou uma pesquisa envolvendo 2.109 profissionais com o objetivo de avaliar o
estado da prática dos programas de medição de processos nas organizações de software. Os
resultados do estudo apresentam as principais abordagens e tipos de medidas em uso, bem
como as barreiras para o seu uso efetivo e concluem que ainda é precária a utilização de
medições para apoio aos projetos nas organizações de software.
O trabalho de Takara, Bettin e Toledo (2007) aborda a estratégia, desafios e lições
aprendidas no caminho do nível 3 para o nível 4 do modelo CMMI em uma organização
brasileira. Os autores ressaltam a importância das medições na gestão de processos de
desenvolvimento de software, principalmente relacionadas ao controle do cronograma, custo,
escopo e qualidade. Entre as barreiras apresentadas no artigo, destacam-se:
•
A dificuldade de atingir a cobertura entre medidas e as áreas de processo do
modelo CMMI;
•
O problema de definição de medidas nos níveis 2 e 3 do modelo sem a
compreensão das necessidades dos níveis de maturidade superiores;
Autores como Johnson et al (2005) e Lawler e Kitchenham (2003) apresentam as
diferenças entre a teoria e prática de medições de software, e criticam a falta de padrões nas
medidas e no processo de coleta e análise. Esta realidade torna alto o custo da coleta de
medidas pelas equipes e mantém incerto o valor agregado para a gestão dos projetos.
Eickelmann e Anant (2003) criticam a aplicação indiscriminada de gráficos de
controle e a definição de seus limites argumentando que as características dos processos de
software exigem uma adaptação destas técnicas para que se tornem efetivas.
Apesar da contribuição real das medições na gestão de projetos de software, muito
trabalho ainda precisa ser realizado para que as organizações de software utilizem as medidas
de desempenho de processos de forma efetiva (SEI, 2006b). A implementação de um processo
de gestão quantitativa de projetos de software é normalmente equivocada, pois as medidas são
definidas sem a devida avaliação da sua utilidade para gestão e do seu alinhamento aos
objetivos da organização. (HALL; FENTON, 1997) (BERANDER; JÖNSSON, 2006).
Nesse contexto, uma questão importante a ser resolvida é: quais são as medidas
relevantes de serem consideradas na avaliação do desempenho dos processos de
desenvolvimento de software? De forma mais específica, quais medidas são pertinentes para a
análise de desempenho dos processos das áreas de processos da categoria de engenharia do
modelo CMMI-DEV
1, considerando que esses são os processos centrais do desenvolvimento
de software?
1.2.
Objetivos
1.2.1.
Objetivo geral
O presente trabalho tem por objetivo estabelecer um catálogo de medidas que permita
à análise de desempenho dos processos das áreas de processos da categoria de engenharia do
CMMI-DEV.
1.2.2.
Objetivos específicos
i.
Selecionar medidas relacionadas às áreas de processos da categoria de
engenharia do CMMI-DEV a partir do conjunto de medidas tipicamente
utilizadas nas organizações e as propostas de medidas encontradas na literatura;
1 As áreas de processos da categoria de Engenharia do modelo CMMI-DEV são: Desenvolvimento de
ii.
Consolidar as medidas em indicadores de desempenho de processo;
iii.
Especificar as medidas e seus indicadores, definindo os métodos de coleta e
análise dos dados e os critérios de decisão sobre o desempenho dos processos,
organizando todas informações em um catálogo;
iv.
Realizar um exemplo de aplicação do catálogo de medidas em um projeto de
desenvolvimento de software, considerando a análise de desempenho dos
processos das áreas de processos da categoria de engenharia do CMMI-DEV.
1.3.
Metodologia
1.3.1.
Classificação da pesquisa
Segundo Moresi (2004, p. 11-14) uma pesquisa pode ser classificada quanto a sua
natureza, abordagem, fins e meios.
O presente trabalho tem por objetivo identificar um conjunto de medidas que permita a
análise de desempenho de processos de software . Portanto, a pesquisa caracteriza-se como
aplicada
quanto à sua natureza, já que pretende gerar conhecimentos para aplicações práticas,
dirigidas à solução de um problema específico.
Quanto à abordagem utilizada, a pesquisa caracteriza-se como
qualitativa
, pois
buscará apresentar um exemplo prático da utilização do catálogo na definição de medidas nas
organizações e nos seus projetos.
A pesquisa irá propor instrumentos, caminhos e procedimentos para a gestão
quantitativa de projetos de software, tratando-se, portanto, de um instrumento de captação e
manipulação da realidade, configurando-se como pesquisa
metodológica
quanto aos fins.
Quanto aos meios de investigação, será realizada uma busca em material científico
publicado em livros, revistas e jornais, o que caracteriza a pesquisa como
bibliográfica
. A
partir do referencial teórico e do catálogo de medidas estabelecido, será realizada uma
aplicação prática
em campo
das medidas do catálogo na análise de desempenho dos
processos de um projeto de desenvolvimento de software.
1.3.2.
Hipóteses e suposições
•
As áreas de processos do modelo CMMI-DEV configuram a estrutura mínima
de processos necessária a uma organização para o fornecimento de produtos e
serviços de software.
•
As áreas de processos da categoria de Engenharia do modelo CMMI-DEV
correspondem às principais atividades envolvidas em projetos de
desenvolvimento de software, por englobar as tradicionais atividades de
engenharia de software (requisitos, análise, projeto, codificação e testes). Nesta
categoria estão incluídas as seguintes áreas de processos: Desenvolvimento de
Requisitos, Gerenciamento de Requisitos, Solução Técnica, Integração de
Produto, Verificação e Validação.
•
Existe um conjunto de medidas de desempenho que permite a análise de
desempenho dos processos das áreas de processos da categoria de engenharia
do CMIM-DEV;
1.3.3.
Coleta de dados
A coleta de dados nesta pesquisa teve por objetivo primário obter informações sobre a
utilização do catálogo de medidas como instrumento para a análise de desempenho de
processos. Com este intuito, a coleta de dados para a aplicação do catálogo desta pesquisa foi
realizada na unidade de fábrica de uma empresa brasileira.
O catálogo de medidas estabelecido não tem por finalidade listar todas as medidas
existentes e suas variações, mas sim identificar um conjunto de medidas que permita a análise
de desempenho dos processos das áreas de processos da categoria de engenharia do
CMMI-DEV. Sendo assim, não fazem parte do escopo desta pesquisa medidas de desempenho
relacionadas à gestão organizacional, como os processos de suporte (qualidade de produtos e
processo, medição e análise, entre outros) e gestão dos processos (definição de processos,
melhoria de processos, treinamento, entre outros).
1.3.4.
Organização da dissertação
Esta dissertação é constituída de 5 capítulos, incluindo esta Introdução.
O capítulo 2 que segue, apresenta as definições e conceitos pertinentes aos tópicos
principais do tema da pesquisa, que são: processos de software, medidas de desempenho de
software, análise de desempenho de processos de software e gerenciamento quantitativo de
projetos.
No capítulo 3 é apresentada a abordagem defendida nesta pesquisa, detalhando os
passos realizados na busca pela definição do catálogo de medidas de desempenho de
processos de software.
O capítulo 4 aborda um exemplo de utilização do catálogo de medidas, realizado por
meio da aplicação de medidas na análise de desempenho dos processos envolvidos em um
projeto real de desenvolvimento de software.
2.
REFERENCIAL TEÓRICO
Nesta seção é apresentado o referencial teórico que embasa o trabalho, envolvendo os
conceitos de processos de software, medição de software, análise de desempenho de
processos e gestão quantitativa de projetos de software.
2.1.
Processos de software
Segundo Chrissis, Konrad e Shrum (2003), uma organização pode focar várias
dimensões para melhorar o desempenho de seus projetos de desenvolvimento de software.
Tipicamente, três destas dimensões são consideradas críticas: pessoas, procedimentos e
ferramentas, conforme a Figura 1.
Figura 1: As três dimensões críticas de uma organização (Chrissis, Konrad, Shrum, 2003a, p. 4).
O que mantêm as três dimensões trabalhando em conjunto é o processo da
organização, permitindo o alinhamento de como a organização realiza o negócio (CHRISSIS;
KONRAD; SHRUM, 2003).
precisa reconhecer suas atividades e os recursos envolvidos. O próximo desafio para a
organização é a avaliação dos processos. Muitas vezes a organização não possui mecanismos
que permitam comparar os seus processos com o desempenho do mercado para identificar
oportunidades de melhoria.
Segundo Florac e Carleton (1999, p. 4) o gerenciamento do processo de software
envolve gerenciar as atividades associadas com o desenvolvimento, manutenção e suporte aos
produtos de software. O gerenciamento é considerado eficaz quando os produtos e serviços
resultantes do processo atendem completamente aos requisitos dos clientes. A premissa
principal defendida pelo Software Engineering Institute (SEI) é de que a qualidade de um
sistema ou produto é altamente influenciada pela qualidade do processo utilizado para
desenvolvê-lo e mantê-lo (SEI, 2006a, p. 5).
O conceito de gerenciamento de processos é fundamentado nos princípios do controle
estatístico de processos. Estes princípios sustentam que, ao estabilizar e manter os níveis de
variação, os processos tendem a apresentar resultados previsíveis (FLORAC; CARLETON,
1999, p. 5).
De acordo com Florac e Carleton (1999, p. 5), o gerenciamento de processos de
software envolve as atividades de medição e controle a fim de coletar o desempenho dos
processos e analisá-los em relação aos limites de desempenho considerados normais pela
organização.
2.1.1.
Modelos de processos de software
Com o objetivo de apoiar a gestão de seus processos, e conseqüentemente obter
melhoria no desempenho, as organizações têm cada vez mais recorrido a normas e modelos de
processos de software. Os diferentes modelos disponíveis provêm às organizações um guia
baseado em melhores práticas internacionais para o gerenciamento eficaz de seus processos.
Dentre as normas e modelos mais difundidos no mercado, destacam-se o CMMI (
Capability
Maturity Model Integration
), a ISO/IEC 12207 (Engenharia de software e sistemas -
Processos do ciclo de vida de software) e o modelo brasileiro MBS.BR (Melhoria do processo
de software brasileiro).
uma solução integrada para atividades de manutenção e desenvolvimento aplicadas a produtos
e serviços.
A estrutura do modelo varia de acordo com sua a representação, conforme Quadro 1.
A representação por estágios é estruturada em cinco níveis de maturidade, enquanto a
representação contínua é estruturada em seis níveis de capacidade, numerados de 0 a 5, para
cada área de processo selecionada pela organização. Na representação em estágio cada nível é
composto de um conjunto de áreas de processo e para que a organização evolua nos níveis de
maturidade, todas as áreas de processos dos níveis anteriores devem ser implementadas. Na
representação contínua, de acordo com os objetivos da organização, é permitida a seleção
individual de uma ou várias áreas de processos para implementação e melhoria através dos
níveis de capacidade.
Quadro 1: Estrutura do modelo CMMI-DEV (SEI, 2006a, p. 31)
Nível Representação continua Representação por estágios Níveis de capacidade Níveis de maturidade
Nível 0 Incompleto
Nível 1 Realizado Inicial
Nível 2 Gerenciado Gerenciado
Nível 3 Definido Definido
Nível 4 Gerenciado Quantitativamente Gerenciado Quantitativamente
Nível 5 Otimizado Otimizado
As áreas de processos são um conjunto de melhores práticas em determinada área, que
quando implementadas coletivamente, satisfazem um conjunto de metas consideradas
importantes para a melhoria naquela área (SEI, 2006a, p. 548). As diferentes áreas de
processo são agrupadas em quatro categorias (Engenharia, Gerenciamento de processos,
Gerenciamento de projetos e Suporte) e distribuídas de acordo com os níveis de cada
representação do modelo. O Quadro 2 lista as categorias, áreas de processos e o nível de
maturidade correspondente, de acordo com a representação por estágios do modelo
CMMI-DEV.
A norma ISO/IEC 12207 é um padrão internacional que estabelece um
framework
Quadro 2: Áreas de processo do modelo CMMI-DEV (Adaptado de SEI, 2006a, p. 44)
Categoria Área de processo Nível de maturidade
Engenharia Integração de produto 3 - Definido
Desenvolvimento de requisitos 3 - Definido Gerenciamento de requisitos 2 - Gerenciado Solução técnica 3 - Definido Validação 3 - Definido Verificação 3 - Definido
Gerenciamento de
processos Inovação organizacional e implantação Definição do processo organizacional + IPPD 5 - Otimizado
(Desenvolvimento integrado de produto e processo) 3 - Definido Foco do processo organizacional 3 - Definido Desempenho do processo organizacional 4 - Gerenciado
Quantitativamente Treinamento organizacional 3 - Definido
Gerenciamento de
projetos Gerenciamento integrado do projeto + IPPD Monitoramento e controle do projeto 3 - Definido 2 - Gerenciado
Planejamento do projeto 2 - Gerenciado Gerenciamento quantitativo do projeto 4 - Gerenciado
Quantitativamente Gerenciamento de riscos 3 - Definido Gerenciamento de acordos com fornecedores 2 - Gerenciado
Suporte Análise de causas e resoluções 5 - Otimizado
Gerenciamento de configuração 2 - Gerenciado Análise de decisões e resoluções 3 - Definido Medições e análises 2 - Gerenciado Garantia da qualidade do processo e produto 2 - Gerenciado
A ISO/IEC 12207 agrupa as atividades associadas a um sistema de software em dois
ciclos de vida e sete grupos. Os processos do ciclo de vida de sistema estabelecem a
infra-estrutura para tratar de um produto ou serviço de software. Por sua vez, ciclo de vida de
software fornece processos específicos para a implementação de um produto ou serviço de
software como parte de um sistema mais amplo (ISO/IEC, 2008, p. 19).
O MPS.BR tem o objetivo de fornecer às organizações brasileiras um guia para
direcionar os esforços de melhoria de processos de software. O modelo, distribuído em sete
níveis de maturidade, foi desenvolvido em conformidade com os padrões internacionais de
qualidade de software e estabelece um modelo de processos baseado nas normas NBR
ISO/IEC 12207 e ISO/IEC 12207 e um método de avaliação baseado na norma ISO/IEC
15504 (SOFTEX, 2007, p. 12).
2006a, p. 517) (SOFTEX, 2007, p. 47), a relação de processos dos modelos possui
semelhanças de nomenclatura, propósitos e resultados.
A partir das semelhanças entre os processos do ciclo de vida de software, pode-se
concluir que todos os três modelos servem como referência para o gerenciamento de
processos de software, já que abrangem todos os aspectos envolvidos na produção de
produtos e serviços de software.
O uso de uma abordagem baseada em processos pela indústria de software traz
consigo a necessidade de avaliar e evoluir estes processos, a fim de executar projetos
controlados e previsíveis. As ferramentas e técnicas de medição e análise quantitativa
permitem as organizações determinar e prever o desempenho dos seus processos, detectarem
desvios e identificar oportunidades de melhoria.
2.2.
Medição de software
A engenharia de software envolve a aplicação de técnicas de engenharia em conjunto
com a ciência da computação para a construção e suporte de produtos de software. Neste
processo, a abordagem da engenharia quer dizer que cada atividade é planejada e a sua
execução é objetivamente controlada. Medições realizam um papel importante no
desenvolvimento de software efetivo e eficiente, bem como fornecem a base científica que
torna a área de software uma verdadeira disciplina da engenharia. (FENTON; PFLEEGER,
1997, p. 9) (KAN, 2003).
Processos efetivos de medição do desempenho auxiliam na obtenção de sucesso, pois
permitem à organização entender a sua capacidade de forma desenvolver planos atingíveis
para a entrega de produtos e serviços. As medições auxiliam também na detecção de
tendências e na antecipação de problemas, resultando em um melhor controle de custos,
redução de riscos, melhoria da qualidade e garantindo que os objetivos de negócio sejam
atingidos (FLORAC; CARLETON, 1999, p. 10).
2.2.1.
Conceituação
Medição é um conjunto de operações com objetivo de determinar um valor a uma
medida (ISO/IEC, 2002, p. 4).
Segundo Fenton e Pfleeger (1997, p. 5), medição é o processo pelo qual números ou
símbolos são atribuídos para atributos de entidades no mundo real, como meio de
descrevê-los de acordo com regras claramente definidas. Medições, portanto capturam informação
sobre atributos de entidades. Uma entidade é um objeto ou um evento do mundo real. Um
atributo é uma característica ou propriedade de uma entidade. Quando as entidades são
descritas através de seus atributos, normalmente estes atributos são definidos por números ou
símbolos, ou seja, medidas.
Por fim, medição pode ser definida como o mapeamento do mundo empírico ou real
para o mundo formal, representado por elementos de um sistema numérico.
Conseqüentemente, uma medida é o número ou símbolo atribuído a uma entidade através
deste mapeamento de forma a caracterizar um atributo desta entidade (FENTON,
PFLEEGER, 1997, p. 28).
A partir do momento onde exista um modelo para representar as entidades e seus
atributos, podem ser definidas medidas que permitam a sua avaliação e comparação com
outras entidades (FENTON; PFLEEGER, 1997, p. 39). Medidas básicas ou diretas podem ser
definidas em termos de um atributo e o método para quantificá-lo e são independentes de
outras medidas. Medidas derivadas ou indiretas são definidas como uma função de dois ou
mais valores de medidas básicas ou diretas. (ISO/IEC, 2002, p. 3) (ABNT, 2008).
As medidas podem, ainda, ser classificadas de acordo com o método de medição como
subjetivas, quando a obtenção de um valor para a medida envolve o julgamento humano, ou
objetivas, nos casos em que, a partir de regras estabelecidas, é obtido um valor numérico para
a medida (ISO/IEC, 2002, p. 4).
O método de medição representa a seqüência lógica de operações para quantificar um
atributo em relação à determinada escala. As principais escalas de medição descritas na
literatura são apresentadas no Quadro 3.
Quadro 3: Escalas de medição (FENTON; PFLEEGER, 1997, p. 45-53) (KAN, 2003, p. 59-61) (ISO/IEC, 2002, p. 5)
Escalas de
medição Descrição Exemplos
Absoluta A medição para uma escala absoluta é feita simplesmente pela contagem do número de elementos no conjunto da entidade.
Número de defeitos encontrados no software, número de pessoas da equipe, número de
ocorrências de um determinado tipo, etc.
Nominal Os valores das medidas são categorizados, representados por um nome ou rótulo. Não existe ordenação implícita entre as classes.
Cor dos olhos, classes de defeitos, nomes de linguagens, classes de custos (custos diretos, custos indiretos), etc.
Ordinal Os valores das medidas são classificados, acrescentando a noção de ordem e comparação. Porém, neste tipo de escala não podem ser realizadas operações matemáticas entre as medidas.
Níveis de maturidade do CMMI (níveis de 1 a 5), complexidade de um sistema (baixa, média, alta), classificação de severidade de um defeito em níveis, etc.
Intervalar
Os valores das medidas têm distâncias iguais correspondendo a quantidades iguais dos atributos. Preserva a importância da ordem dos resultados da escala ordinal e ainda possui informações sobre o tamanho dos intervalos que separam seus pontos. Operações matemáticas de adição e subtração podem ser aplicadas, porém não são permitidas multiplicações e divisões entre as medidas. O valor zero não é possível.
Complexidade ciclomática, intervalo de datas, horários, etc.
Razão
Preserva a ordem, o tamanho dos intervalos entre entidades, mas apresenta também as razões entre elas. Incorpora o elemento zero absoluto (representando a total falta do atributo). Todas as funções aritméticas podem ser utilizadas aplicadas em cada intervalo do mapeamento, gerando resultados significativos.
Tamanho, peso, altura, tempo entre falhas, custo, prazo, esforço, etc.
Takara, Bettin e Toledo (2007, p. 92) complementam que um indicador é uma medida
extremamente importante para a organização, sendo acompanhada e analisada periodicamente
a partir de uma meta de desempenho pré-estabelecida.
A experiência de SEI (2001, p. 5) sugere que, em um programa de medição,
normalmente não é suficiente a definição de questões e medidas sem a visualização e reporte
de um indicador como forma de comunicação dos resultados.
2.2.2.
Fatores críticos da implantação de programas de medição
listadas as principais falhas cometidas na implantação de programas de medições
(MCGARRY et al, 2002):
•
A
sobrecarga
envolve a coleta simultânea de muitos dados, o que resulta em
esforço desperdiçado e perda da credibilidade do programa de medição.
•
O
uso incorreto da medição
é a utilização dos resultados de medições para
avaliação dos profissionais, resultando em perda da integridade dos dados, pois
os profissionais tendem a mascarar os dados com medo de que estes sejam
utilizados contra eles.
•
As
falhas de medição
são a obtenção de medidas erradas, ambíguas e
inconsistentes, resultando em análises não conclusivas.
•
As
falhas de processo
são a obtenção de medidas que motivam as falhas de
processo (exemplo: o objetivo de diminuir a taxa de resolução de problemas
induz à ação indesejada de que as equipes tratem primeiramente os problemas
mais simples).
Berander e Jönsson (2006, p. 316), complementam que, devido à ausência de foco, os
modelos de gestão quantitativa aplicados nas organizações resultam em grande quantidade de
dados que nunca são analisados ou utilizados. Nestes casos, o fato dos envolvidos não
saberem claramente quais medidas são importantes, torna o esforço de medição uma perda de
tempo, causando a perda da credibilidade do processo de medição. Sendo assim, é melhor que
as organizações possuam poucas métricas úteis do que muitas sem utilidade alguma.
Segundo McGarry et al (2001, p. 7), a experiência de uma grande gama de projetos de
desenvolvimento e manutenção de software sugere que, para se obter sucesso em um
programa de medições é necessário desenvolver dois aspectos chaves: os procedimentos de
coleta, análise e reporte das medidas devem ser relacionados diretamente às necessidades de
informação dos tomadores de decisão nos projetos de software; e um processo de medição
estruturado, repetível e adaptável deve estar em prática para apoiar os processos técnicos e
gerenciais da engenharia de software.
Diferentes abordagens de medição estão disponíveis na literatura com o objetivo de
auxiliar a identificação de medidas, métodos e técnicas de medição dos processos de software,
alinhados com os objetivos da organização e de seus projetos. Dentre estas, destacam-se o
framework
de medição proposto por Florac e Carleton (1999), O GQM (
Goal-Question-Metric)
proposto por Basili, Caldiera e Rombach (2002), O PSM (
Practical Software
2.2.3.
Modelos de especificação de medidas
A fim de minimizar as dificuldades apresentadas na seção anterior, o SEI (SEI, 2004),
o PSM (DoD, 2004) e a ISO 15939 (ISO/IEC, 2002) apresentam modelos de especificação de
medidas, que podem ser utilizados como guia para a definição clara das medidas necessárias
para a avaliação dos processos da organização.
O Quadro 4 a seguir apresenta um paralelo realizado, mostrando lado a lado as
semelhanças e diferenças entre os três modelos de especificação de medidas referenciados,
identificando principalmente as informações que não são contempladas por algum dos
modelos de documento.
A partir da análise dos diferentes modelos de especificação, é possível concluir que o
modelo do PSM proposto por DoD (2004) é o mais completo, contendo a maior quantidade de
seções para especificação da medida.
2.2.4.
Medidas de processos de software
O assunto de medição de processos de software tem sido tema recorrente em
publicações especializadas. Diversos autores apresentam em seus trabalhos propostas e
conclusões a respeito de programas de medições implementados em diferentes contextos e
organizações.
Publicações como as de Florac e Carleton (1999) e McGarry et al (2002) dissertam de
forma abrangente sobre o tema de medição de processos de software, apresentando as
técnicas, boas práticas e também exemplos de medidas para avaliação destes processos.
SEI (SEI, 2004) PSM (DoD, 2004) ISO 15939 (ISO/IEC, 2002)
Nome/título do indicador Nome da medição Não contém a informação Data Versão da medição Não contém a informação
Descrição da necessidade de informação
Questões Necessidade de informação Necessidade de informação Não contém a informação Categoria de informação Não contém a informação Objetivo Conceito mensurável Conceito mensurável
Entidade e atributos
Não contém a informação Entidades relevantes Entidades relevantes
Não contém a informação Atributos Atributos
Entradas Especificação de medida básica
Elementos de dados
Medidas básicas Medidas básicas Definição
Não contém a informação Métodos de medição Método de medição Não contém a informação Tipos de métodos Tipo de método de medição
Não contém a informação Escala Escala
Não contém a informação Tipos de escalas Tipo de escala Não contém a informação Unidade de medição Unidade de medição
Especificação de medida derivada
Não contém a informação Medidas derivadas Medida derivada Algoritmo Função de medição Função de medição
Especificação de indicador
Visualização gráfica Descrição do indicador e amostra Indicador
Análise Modelo de analise Modelo
SEI (SEI, 2004) PSM (DoD, 2004) ISO 15939 (ISO/IEC, 2002)
Coleta de dados Procedimento de coleta de dados (para cada medida básica)
Como Não contém a informação Não contém a informação Quando/Em que freqüência Freqüência da coleta de dados Não contém a informação Por quem Responsável Não contém a informação Não contém a informação Fase ou atividade de coleta de dados Não contém a informação Formulários Ferramentas utilizadas para coleta de dados Não contém a informação Não contém a informação Verificação e Validação Não contém a informação
Armazenamento de dados
Onde Repositório de dados coletados Não contém a informação Como Não contém a informação Não contém a informação Segurança Não contém a informação Não contém a informação
Reporte de dados Procedimento de análise de dados (para cada indicador)
Em que freqüência Freqüência de reporte dos dados Não contém a informação Responsável pelo reporte Responsável Não contém a informação Não contém a informação Fase ou atividade de análise dos dados Não contém a informação Não contém a informação Fonte de dados para análise Não contém a informação Não contém a informação Ferramentas utilizadas para análise de dados Não contém a informação Por quem/Para quem
Revisão, reporte e usuário Não contém a informação
Perspectiva Não contém a informação
Informação adicional
Questões de sondagem
Guia de análise adicional Não contém a informação
Referência cruzada Não contém a informação
Relatórios redigidos por SEI (2006b) e Kulik e Weber (2002), fazem uma ampla
avaliação da maturidade das organizações no que tange os processos de medição e análise do
desempenho dos seus processos. Ambos concluem que as organizações têm inúmeras
dificuldades na implantação de programas de medição.
Apesar disto, autores publicam também os resultados de pesquisas experimentais,
realizadas em organizações de reconhecida maturidade em processos de software, como a
IBM, NASA e HP (KITCHENHAM et al, 2006) (RESEMBERG; SHEPPARD; 1994)
(MCGARRY; BURKE; DECKER, 1998) (LINDSTRÖM, 2004) (GRADY, 1994)
(AGRAWAL; CHARI, 2007) (HERBSLEB; GRINTER, 1998) (GALIN; AVRAHAMI,
2007) (HALL; FENTON, 1997).
As diferentes medidas identificadas nestes trabalhos formam a base conceitual para a
definição do catálogo proposto nesta pesquisa, sendo apresentadas no capítulo 3.
2.3.
Análise de desempenho de processos de software
Quando definidas e relacionadas aos processos de software, as medidas permitem a
avaliação precisa do desempenho dos processos e projetos. Esta seção apresenta o objetivo,
instrumentos e outros conceitos a respeito da análise de desempenho de processos de
software.
2.3.1.
Análise de desempenho de processos segundo o modelo CMMI-DEV
Figura 2: Áreas de processo envolvidas na gestão quantitativa (Adaptado de SEI, 2002).
Segundo o CMMI-DEV (SEI, 2006a), a execução de todas as áreas de processos em
um projeto de desenvolvimento de software fornece informações a partir das quais é possível
avaliar o desempenho do projeto
(Passo 1 da Figura 2)
. Estas informações de desempenho
são coletadas pela área de
Medição e Análise (MA)
, que é focada na definição de medidas,
coleta de dados, apuração e análise dos resultados obtidos pela organização ao desenvolver
seus produtos
O histórico de medidas de desempenho coletadas pela organização nos seus diferentes
projetos
(Passo 2 da Figura 2)
é insumo para o estabelecimento do
Desempenho do
Processo Organizacional (DPO)
.
A área de processo de DPO proporciona um entendimento
quantitativo de desempenho dos processos da organização, provendo linhas de base de
medidas e modelos estatísticos de avaliação do desempenho dos processos a serem aplicados
na gestão quantitativa dos projetos
(Passo 3 da Figura 2)
.
A
Gestão Quantitativa de Projetos (GQP)
utiliza os modelos de desempenho para
gerenciar quantitativamente o projeto, comparando o resultado das medidas de desempenho
dos processos do projeto
(Passo 4 da Figura 2)
com a linha de base estabelecida em DPO. O
foco desta área de processos é identificar sinais de desvios e prever o desempenho futuro do
projeto para suportar a tomada de decisões, a fim de manter o projeto alinhado com os seus
objetivos.
preciso e aderente à realidade do projeto e da organização. O
Monitoramento e Controle do
Projeto (MCP)
envolve a avaliação da gravidade dos desvios para estabelecer ações
corretivas e preventivas, baseado nos resultados da análise quantitativa do projeto
(Passo 5 da
Figura 2)
.
Para os desvios críticos, por exemplo, aqueles que podem comprometer
significativamente o resultado do projeto, a avaliação das alternativas de ações deve ser
realizada por um processo formal de tomada de decisões
(Passo 6 da Figura 2)
. Através da
área de
Análise de Decisão e Resolução (ADR)
, o gerente pode utilizar métodos formais de
avaliação de alternativas a fim de decidir as ações mais adequadas em cada caso
(Passo 7 da
Figura 2)
.
Por fim, as ações gerenciais corretivas e preventivas para tratamento dos desvios são
então implementadas nos processos do projeto
(Passo 8 da Figura 2)
, fechando o ciclo que
tem como objetivo melhorar continuamente o desempenho dos processos alinhado com os
objetivos do projeto.
2.3.2.
Entendimento do desempenho do processo organizacional
De acordo com o SEI (2006a, p. 261), obter o entendimento do desempenho do
processo organizacional, descritos na área de processo de Desempenho do Processo
Organizacional (DPO), envolve estabelecer e manter um entendimento quantitativo do
desempenho dos processos e prover dados de desempenho, linhas de base
para comparação e
modelos para gerenciar quantitativamente os projetos da organização. As seguintes práticas
são específicas para a citada área de processo do modelo CMMI-DEV:
1)
Selecionar processos
2)
Estabelecer medidas de desempenho dos processos
3)
Estabelecer objetivos de desempenho dos processos
4)
Estabelecer linhas de base
de desempenho dos processos
5)
Estabelecer modelos de desempenho dos processos
Quando a organização possui medidas, dados e técnicas analíticas para processos
críticos, produtos e serviços, ela é capaz de (SEI, 2006a, p. 262):
•
Determinar se o processo está se comportando de forma consistente ou possui
tendência estável, ou seja, se seus resultados são previsíveis.
•
Identificar processos para os quais o desempenho está dentro de limites
naturais.
•
Estabelecer critérios para identificar quando um processo ou subprocesso deve
ser estatisticamente gerenciado, determinando as medições e técnicas
necessárias para tal.
•
Identificar processos que demonstram comportamento incomum, ou seja, que
são instáveis ou imprevisíveis.
•
Identificar os aspectos nos processos que possam ser melhorados.
•
Identificar qual implementação de processo que é realizada com maior
eficiência.
2.3.3.
Importância da estabilidade do processo
Em toda e qualquer atividade, automatizada ou realizada manualmente, os resultados
não são uniformes, estes variam de acordo com as condições nas quais a atividade foi
realizada. Ao realizar o controle estatístico de um processo, as variações nos dados de suas
medições precisam ser avaliadas a fim de identificar se estas se tratam de ruídos ou sinais
(FLORAC; CARLETON, 1999, pp. 65-70).
Ruídos (variações randômicas ou variações por causas comuns) descrevem condições
normais de execução do processo, ou seja, condições previstas devido à instabilidade natural
de todo e qualquer processo. Sinais (variações não randômicas ou variações por causas
especiais) identificam condições de desvio, ou seja, situações onde o desempenho do processo
desviou consideravelmente e, portanto ações para tratamento das causas devem ser
implementadas. De acordo com Florac e Carleton (1999, p. 67), agir em ruídos como se
fossem sinais apenas amplifica a instabilidade e aumenta a variabilidade dos resultados do
processo. Deixar de agir em sinais avaliando-os como ruídos mascara as deficiências do
processo e limita a identificação de oportunidades de melhoria.
momento o processo pode ser considerado estável e, portanto o seu desempenho futuro
torna-se previsível. (FLORAC; CARLETON, 1999, p. 70).
A estabilidade do processo é crucial para que a organização seja capaz de produzir
seus resultados de acordo com os planos. Florac e Carleton (1999, p. 71), justificam a
importância de se obter processos estáveis:
•
Sem estabilidade
e o entendimento da capacidade do processo, não existe
forma de distinguir sinais de ruídos, o que pode resultar em ações
inapropriadas.
•
Sem um histórico de desempenho estável, situações descontroladas podem
ocorrer a qualquer tempo. Não existe base para prever as situações futuras e,
portanto todos os planos são considerados de alto risco.
•
Desconhecendo o nível de estabilidade do processo, não existe base de
comparação para reconhecer causas especiais de desvio que demandem ações
de melhoria.
•
Sem estabilidade não se obtém um processo repetível para usar como linha de
base para a implementação de melhorias. De fato, não existe um único
processo, mas diversos, todos diferentes. Os efeitos das ações de melhoria
podem ser imperceptíveis em meio a todas as variações.
2.3.4.
Ferramentas de análise de desempenho de processos
Conforme apresentado anteriormente, a execução de processos de software
normalmente apresenta variação de desempenho. De acordo com a linha de base
do processo,
as variações são consideradas de causas comuns ou de causas especiais. Neste último caso, o
processo passa a ser considerado em estado de desvio e, portanto necessita ser tratado por
ações corretivas.
Diversos instrumentos de controle estatístico de processos são utilizados para avaliar o
desempenho dos processos de uma organização ou de um projeto de software específico.
Estas ferramentas apóiam a identificação e análise de causas especiais e, portanto são
fundamentais para a análise de desempenho de processos.
Quadro 5: Ferramentas para gestão quantitativa de projetos
Ferramenta Descrição Apresentação
Fluxograma A ferramenta de fluxograma é uma representação
gráfica das atividades do processo e pode ser utilizada para analisar onde um problema ocorre.
Folha de
verificação Instrumento utilizando quando se quer coletar informação relacionada à freqüência de ocorrência de um determinado evento.
Uma lista de verificação quando virada 90o fornece
um bom indício de como o processo seria apresentado em um histograma ou diagrama de Pareto.
Disciplina Recusas
Requisitos √√
Análise e projeto √√√√
Implementação √√√√√
Testes √√
Gerenciamento de
Projetos √√√√√
Diagrama de
dispersão Este diagrama apresenta relacionamentos entre duas variáveis ou características de um processo. A observação de padrões nos pontos do digrama sugere que as variáveis analisadas são associadas,
possivelmente em uma relação de causa-e-efeito.
-20,00 40,00 60,00 80,00 100,00
- 50,00 100,00 150,00
Q u a n ti d a d e d e d e fe it o s Tamanho Quantidade de defeitos X
Tam anho
Histograma Um histograma exibe os dados coletados do processo
por freqüência. Os valores observados do processo são distribuídos em determinados intervalos de mesmo tamanho (colunas). A altura das barras de um histograma é proporcional ao número de observações dentro da do intervalo.
Os histogramas são úteis, pois permitem analisam a taxa de variação de um processo.
0 1 2 3 4 5 6 0,0 0 to 0,0 8 0,08 t o 0,16 0,16 t o 0,24 0,24 to 0,32 0,32 t o 0,40 0,40 t o 0,48 0,48 to 0,56 0,56 t o 0,64 0,64 to 0,72 0 ,72 to 0 ,80 0,80 t o 0,88 0,8 8 to 0,9 6 0,96 t o 1,04 1,04 t o 1,12 1,12 to 1,20 Histogram a Diagrama de causa-e-efeito, Espinha de peixe ou Ishikawa
O Diagrama de causa e efeito é uma representação gráfica de problemas e suas causas.
Esta ferramenta é muito útil em reuniões de brainstorming, para capturar dos envolvidos na execução do processo as causas prováveis de um determinado problema.
Gráfico de
barras Da mesma forma que um histograma, um gráfico de barras é utilizado para investigar o perfil de um processo. Porém, os gráficos de barras podem conter quaisquer valores, não somente freqüências como nos histogramas. Neste caso, a largura das colunas e barras é livre, e, juntamente com cores, sombras e textos, podem ser utilizadas para diferenciar os dados do gráfico. -5,00 10,00 15,00 20,00 25,00 30,00 35,00
Defeitos x Disciplinas x Builds
Quadro 5 (cont.): Ferramentas para gestão quantitativa de projetos
Ferramenta Descrição Apresentação
Gráfico ou diagrama de Pareto
Um Diagrama de Pareto é simplesmente a exibição de freqüências de determinado dado em ordem
decrescente.
Esta ferramenta pode é utilizada para analisar as ocorrências mais comuns de um evento e priorizar as ações a serem tomadas no tratamento do processo. Diagramas de Pareto são conceitualmente relacionados com a Lei de Pareto, que defende que um número relativamente pequeno de causas é responsável pela produção da grande maioria dos problemas ou defeitos.
0,32 5
0 ,0 55 0,046
0 ,0 14 0,010 0,009 0,003 - -0 ,-0 -0% 20 ,0 0% 40 ,0 0% 60 ,0 0% 80 ,0 0% 1 00 ,0 0%
-0 ,-0 5-0 0 ,1 00 0 ,1 50 0 ,2 00 0 ,2 50 0 ,3 00 0 ,3 50
D e n si d a d e d e d e fe it o s
Densidade de defeitos (Pareto)
Gráfico ou carta de execução
Um gráfico ou carta de execução exibe observações individuais de um processo no decorrer do tempo. Esta ferramenta pode ser utilizada para identificar tendências ou mudanças no desempenho do processo. Um risco de utilizar simplesmente gráficos de execução é a tendência de reagir às variações naturais do processo. 0 ,00 0
0 ,10 0 0 ,20 0 0 ,30 0 0 ,40 0 0 ,50 0 0 ,60 0
n o v/ 05 d e z/ 05jan/ 06f e v/ 06 m ar / 06 abr / 06 m ai/ 06 ju n/ 06jul/ 06ago / 06set / 06 IDC
Gráfico ou carta de controle
Um gráfico de controle é basicamente um gráfico de execução com o acréscimo de uma linha central e limites de controle inferior e superior associados. Os limites de controle, definidos de acordo com cada tipo de gráfico, permitem a organização acompanhar o desempenho do processo e identificar as causas normais e especiais de variação.
0,000 0,100 0,200 0,300 0,400 0,500 0,600 0,700
nov/ 05dez/ 05jan/ 06f ev/ 06mar/ 06abr / 06mai/ 06 jun/ 06jul/ 06ago/ 06set/ 06 IDC (X)
IDC (X) LC LCS (+3 sigm as) + 2 sigm as + 1 sigma LCI (- 3 sigm as) - 2 sigm as - 1 sigma
Segundo Kulpa e Johnson (2008, p. 242), alguns autores não consideram o
Fluxograma e o Diagrama de causa-e-efeito ferramentas estatísticas, pois as mesmas não
necessariamente são focadas em dados quantitativos.
2.3.5.
Gráficos de controle
Os gráficos de controle são uma das principais ferramentas para a análise de
desempenho de processos. Um gráfico de controle é uma ferramenta de controle estatístico de
processos que apresenta a execução de determinado processo geralmente no decorrer do
tempo, incluindo uma linha central que representa a média ou mediana do desempenho
observado no processo, e limites de controle superior e inferior para avaliação da estabilidade
do processo (STEPENHRUST, 2005, p. 447).
Figura 3: Estrutura do gráfico de controle (Adaptada de Florac e Carleton, 1999, p. 77).
