5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
PROGRAMA DE PÓS-GRADUAÇÃO STRICTO SENSU EM
GESTÃO DO CONHECIMENTO E DA TECNOLOGIA DA INFORMAÇÃO
MestradoABORDAGEM PARA DEFINIÇÃO DE
INDICADORES DE REQUISITOS EM PROJETOSDE SOFTWARE
Autor: Leonardo Schwindt
Orientador: Prof. Dr. Fábio Bianchi Campos
Co-orientador: Prof. Dr. Cláudio Chauke Nehme
2009
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 2
i
LEONARDO SCHWINDT
ABORDAGEM PARA DEFINIÇÃO DE INDICADORES DEREQUISITOS EM PROJETOS DE SOFTWARE
Dissertação apresentada ao Programa de Pós-GraduaçãoStrictu 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 da Tecnologia da Informação.
Orientadora: Prof. Dr. Fábio Bianchi Campos
Co-orientador: Prof. Dr. Cláudio Chauke Nehme
Brasília
2009
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 3
ii
Ficha elaborada pela Biblioteca Central da Universidade Católica de Brasília – UCB
06/10/2009
S415a Schwindt, Leonardo
Abordagem para definição de requisitos em projetos de software / Leonardo Schwindt,
184 f.: il.; 30 cm
Dissertação (mestrado) – Universidade Católica de Brasília, 2009.Orientadora: Fábio Bianchi Campos.Co-orientação: Cláudio Chauke Nehme.
1.Administração de projetos. 2. Software – Controle de qualidade.3. Software - Desenvolvimento. I. Campos, Fábio Bianchi, orient.II. Nehme, Clúudio Chauke, co-orient. III. Título.
CDU 004.05
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 4
iii
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 5
iv
Dedico este trabalho a Deus, minha esposa e família.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 6
v
Agradecimentos
A Deus por ter me dado saúde e força para concluir este trabalho.
Aos meus pais João Alberto Schwindt e Claudete Rossignoli Motta pelo carinho, atenção,
apoio e contribuição na minha formação pessoal, educacional, desportiva e profissional.
À minha esposa Mariana Caetano da Silva Souza Schwindt pela paciência, compreensão
e incentivo nos momentos mais difíceis.
Aos meus irmãos João Alberto Schwindt Filho, Anne Rossignoli Schwindt e Bruno
Rossignoli Schwindt pelo companheirismo e amizade.
Aos meus avós Osvino Breno Schwindt, Geraldo Rossignoli, Maria Polonia Schwindt e
Juracy Motta Rossignoli pelos ensinamentos e carinho.
Aos meus sogros Juarez de Souza e Maria Regina Souza por me acolherem como um
filho.
Aos professores Cláudio Chauke Nehme e Fábio Bianchi Campos pela contribuição
direta com a concretização deste trabalho, mostrando dedicação, paciência e entusiasmo em
todos os momentos.
A todos os meus amigos de trabalho pela amizade e troca de experiências.
Aos meus colegas de turma do mestrado da Católica, pelo coleguismo.
Aos professores da Católica, pelo profissionalismo demonstrado e conhecimentos
compartilhados.
Finalmente, a todos aqueles que direta ou indiretamente contribuíram para concretização
deste sonho.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 7
vi
“Procure ser um homem de valor, em vez de ser um homem de sucesso." Albert Einstein
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 8
vii
RESUMO
Projetos possuem características singulares que estão diretamente relacionadas a questões queenvolvem riscos, pois a proposta de um projeto é de se gerar um produto, serviço ou resultadoexclusivo. A indústria de software tem se deparado com inúmeras dificuldades que fazemcom que a maioria de seus projetos atrase, ultrapasse limites orçamentários e não atenda porcompleto às necessidades das organizações e dos clientes. São vários os fatores quecontribuem para que isso ocorra, sendo a má gestão de requisitos uma das principais causas.Para aprimorar a gerência de requisitos é importante que se utilize ferramentas quantitativas.Indicadores podem auxiliar gerentes e equipe no aprimoramento do controle e previsibilidadedos projetos de software. Este trabalho teve como objetivo principal definir um processo paraa geração de indicadores que fosse específico para a gerência de requisitos. Esse processo,
quando avaliado, mostrou ser de fácil entendimento, apresentando nível de detalhes quepermite com que profissionais não especialistas na área de métricas possam segui-lo e utilizá-lo, sendo possível a criação gradual de indicadores de acordo com as características enecessidades específicas de cada organização.
Palavras-Chave: Gerenciamento de Projetos, Qualidade de Software, Desenvolvimento deSoftware, Gerência de Requisitos, Métricas e Indicadores.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 9
viii
ABSTRACT
Projects have particular characteristics that are directly related to issues that involve risks,since the goal of a project is to generate a product, service or an exclusive result. The software industry has faced many difficulties that make most of the software development projects late,over budget and less than exemplary when reviewing the expectations set by organizationsand end users. There are many variables that collaborate in order to this to occur, but a poorrequirement management is known as one of the main reasons. In order to improverequirement management it is important to use quantitative tools. Indicators can helpmanagers and teams to improve the control and predictability of projects. This paper had asthe main goal to develop a process specific to create indicators for requirement management.The process, when evaluated, showed to be easy to understated, presenting a level of details
that allows professionals that are not specialists to create indicators gradually, according tothe characteristics and needs of each organization.
Keywords: Project Management, Software Quality, Software Development, RequirementManagement, Metrics, Indicators
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
ix
LISTA DE FIGURAS
Figura 1 - Taxas de Sucesso e Fracasso em Projetos de Software (Chaos Report , 2007) ....... 26 Figura 2 – Efeitos do aprimoramento da Qualidade de Software (SANDERS,1994) .............. 30 Figura 3 - MPS.BR (SOFTEX 2007) ....................................................................................... 32 Figura 4 - Processo de Engenharia de Requisitos (Adaptação de KOTONYA, 2002) ............ 35 Figura 5 - Exemplo de Aplicação do GQM .............................................................................. 44 Figura 6 - Goal Question Indicator Metric - GQ(I)M (ARAÚJO, 2004) ................................ 47 Figura 7 - Practical Software Measurement (PSM) ................................................................. 49 Figura 8 - Estruturação de criação de um Indicador no PSM (HAZAN, 2002) ....................... 52 Figura 9 - Exemplo de estruturação de Indicador através do PSM (HAZAN, 2002) ............... 53 Figura 10 – Exemplo de gráfico de controle de volatilidade dos requisitos (LOCONSOLE,
2007) ................................................................................................................................. 60 Figura 11 – Processo de definição do PGIGR .......................................................................... 65 Figura 12 – Subprocessos do PGIGR ....................................................................................... 72 Figura 13 - Categorias de Classificação do Processo de Software da Organização de TI ....... 75 Figura 14 - Subprocesso para Categorizar o Processo de Software da Organização de TI ...... 76 Figura 15 - Quatro Dimensões Foco para a geração de indicadores (Adaptação de Solingen e
Berghout, 1999) ................................................................................................................ 82 Figura 16 - Subprocesso para Definir Dimensão Foco............................................................. 83 Figura 17 - Subprocesso para Definir Objetivos (Metas) ......................................................... 86 Figura 18 - Subprocesso para Definir Perguntas (Questões) ................................................... 88 Figura 19 - Relacionamento entre Objetivos, Perguntas, Indicadores, Medidas Derivadas e
Medidas básicas (base) ..................................................................................................... 90 Figura 20 - Subprocesso para Definir Indicador ...................................................................... 92 Figura 21 - Subprocessos do PGIGR ...................................................................................... 132 Figura 22 – Categorias de Classificação do Processo de Software da Organização de TI ..... 139 Figura 23 - Subprocesso para Categorizar a Organização de TI ............................................ 140 Figura 24 - Visão Macro do Processo de Categorização da Organização de TI .................... 146 Figura 25 - Quatro Dimensões Focos para a geração de indicadores ..................................... 148 Figura 26 - Subprocesso para Definir Foco para Definição de Indicadores ........................... 149 Figura 27 – Subprocesso para Definir Objetivos (Metas) ...................................................... 152
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
x
Figura 28 - Subprocesso para Definir Perguntas (Questões) .................................................. 156 Figura 29 - Relacionamento entre Objetivos, Perguntas, Indicadores, Medidas Derivadas e
Medidas básicas (base) ................................................................................................... 161 Figura 30 - Subprocesso para Definir Indicadores ................................................................. 162
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
xi
LISTA DE QUADROS
Quadro 1 – Grupo de processos de gerenciamento de projetos (PMI, 2004). .......................... 22 Quadro 2 – Ferramentas para Gestão Quantitativa (adaptação de MONTEIRO, 2008) .......... 54 Quadro 3 – Estrutura de Template de Indicador (Adaptado do SEI, 2004).............................. 58 Quadro 4 - Características Definidas para o Processo PGIGR ................................................. 71 Quadro 5 – Exemplos de Gráficos para Geração de Indicadores ........................................... 173 Quadro 6 - Questionário de avaliação do PGIGR .................................................................. 184
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
xii
LISTA DE TABELAS
Tabela 1 – Níveis de Maturidade do MPS.BR ......................................................................... 33 Tabela 2 - Fontes de Pesquisas ................................................................................................. 63 Tabela 3 – Subprocesso e as Atividades do PGIGR ................................................................. 73 Tabela 4 - Matriz de Categorização do processo de software da Organização de TI............... 77 Tabela 5 - Matriz contendo as dimensões foco e descrição para cada uma das categorias ...... 85 Tabela 6 - Matriz contendo sugestões de objetivos (metas) para cada categoria e dimensão
foco ................................................................................................................................... 87 Tabela 7 - Matriz contendo sugestão de Perguntas (Questões) para cada categoria e dimensão
foco ................................................................................................................................... 89 Tabela 8 - Matriz contendo os Indicadores Sugeridos para cada categoria e dimensão foco .. 93 Tabela 9 - Consolidação dos dados da Primeira Etapa do Questionário ................................ 102 Tabela 10 – Consolidação dos dados da Segunda Etapa do Questionário ............................. 104 Tabela 11 - Consolidação dos dados da Terceira Etapa do Questionário .............................. 105 Tabela 12 - Avaliação do PGIGR Quanto ao Atendimento às Características Traçadas para o
Processo .......................................................................................................................... 111 Tabela 13 - Comparativo do PGIGR com os Demais Modelos de Criação de Indicadores ... 114 Tabela 14 - Objetivo do PGIGR – formato GQM .................................................................. 131 Tabela 15 - Subprocessos e Atividades do PGIGR ................................................................ 135 Tabela 16 – Definição de Papéis e Habilidades necessárias para o PGIGR........................... 136 Tabela 17 - Itens para detalhamento de uma atividade .......................................................... 137 Tabela 18 - Matriz de Categorização do processo de software da Organização de TI ........... 143 Tabela 19 – Matriz contendo as dimensões foco e descrição para cada uma das categorias . 151 Tabela 20 – Matriz contendo sugestões de objetivos (metas) para cada categoria e dimensão
foco ................................................................................................................................. 154 Tabela 21 - Matriz contendo sugestão de Perguntas (Questões) para cada categoria e dimensão
foco ................................................................................................................................. 158 Tabela 22 - Matriz contendo os Indicadores Sugeridos para cada categoria e dimensão foco
........................................................................................................................................ 164 Tabela 23 – Exemplo do Template para Especificar Indicadores .......................................... 167 Tabela 24 – Detalhamento do Indicador de Horas Gastas em Atividades de Requisitos (EGR)
........................................................................................................................................ 178 Tabela 25 – Detalhamento do Indicador de Custo Total de Defeitos em Requisitos (CTD) 180
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
xiii
SUMÁRIO
Lista de Figuras ......................................................................................................................... ix Lista de Quadros ........................................................................................................................ xi Lista de Tabelas ........................................................................................................................ xii 1. Introdução ........................................................................................................................ 16
1.1. Motivação e Contexto ............................................................................................. 16 1.2. Objetivos ................................................................................................................. 19
1.2.1. Objetivo Geral ........................................................................................... 19 1.2.2. Objetivos Específicos ................................................................................ 20 1.2.3. Suposições ................................................................................................. 20 1.2.4. Organização da Dissertação ...................................................................... 20
2. Referencial Teórico ......................................................................................................... 21 2.1. Gerenciamento de Projetos ..................................................................................... 21 2.2. Gerenciamento de Riscos ....................................................................................... 22 2.3. Definição de Sucesso em Projetos de Desenvolvimento de Software.................... 24 2.4. Diagnóstico do Sucesso em Projetos de TI ............................................................ 25 2.5. Qualidade de Software............................................................................................ 27
2.5.1. Problemas Relacionados à Baixa Qualidade de Software ......................... 28 2.5.2. Qualidade de Software e o Mercado Atual .............................................. 29 2.5.3. Capability Maturity Model Integration - CMMI ....................................... 30 2.5.4. Melhoria do Processo de Software Brasileiro - MPS.BR ......................... 31
2.6. Gestão de Requisitos .............................................................................................. 34 2.6.1. Gerenciamento de Requisitos .................................................................... 36
2.7. Medição de Software .............................................................................................. 37 2.7.1. Conceitos ................................................................................................... 37 2.7.2. Indicadores ................................................................................................ 38 2.7.3. Objetivos de Medições em Projetos de Desenvolvimento de Software .... 39 2.7.4. Modelos para Geração de Indicadores ...................................................... 43 2.7.5. Goal Question Metric - GQM .................................................................. 43 2.7.6. Goal Question Indicator Metric - GQ(I)M ................................................ 46 2.7.7. Practical Software Measurement - PSM ................................................... 48 2.7.8. Instrumentos de Análise de Desempenho ................................................. 53
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
xiv
2.8. Desafios na Definição de Indicadores em Projetos de Desenvolvimento de
Software ........................................................................................................................... 55 2.9. Estrutura de Template (modelo de documento) para Geração de Indicadores ....... 56 2.10. Indicadores para o Gerenciamento de Requisitos................................................... 59 2.11. Considerações Finais do Capítulo .......................................................................... 61
3. Materiais e Métodos de Pesquisa..................................................................................... 62 3.1. Classificação da Pesquisa ....................................................................................... 62 3.2. Fontes de Informações Utilizadas........................................................................... 62 3.3. Etapas de Definição do Processo Proposto ............................................................ 64 3.4. Etapa de Revisão da Literatura ............................................................................... 67
3.4.1. Passo: Revisão da Literatura Referente a Sucesso e Fracasso em Projetos
de Software 67 3.4.2. Passo: Estudo da Teoria de Base sobre Gestão de Requisitos ................. 68 3.4.3. Passo: Estudo da Teoria de Base sobre Medição em Projetos de Software
68 3.4.4. Passo: Estudo da Teoria de Base sobre Métodos para Definição de
Indicadores 69 3.4.5. Passo: Estudo da Teoria de Base sobre Métricas e Indicadores Existentespara a Gerência de Requisitos ................................................................................ 70
3.5. Etapa de Definição do Processo PGIGR ................................................................ 70 3.5.1. Passo: Definição das Características Desejadas para o Processo .............. 71 3.5.2. Passo: Definição da Estrutura Geral do Processo PGIGR ........................ 72 3.5.3. Passo: Definição das Atividades do Processo ........................................... 73
3.6. Avaliação do Processo Proposto ............................................................................ 96 3.6.1. Propósito da Avaliação e Delimitação ...................................................... 96 3.6.2. Elaboração do Questionário de Avaliação ................................................ 96 3.6.3. Identificação e Amostragem da População ............................................... 97 3.6.4. Aplicação do Questionário ........................................................................ 97 3.6.5. Etapa de Análise dos Dados ...................................................................... 98
4. Resultados e Discussões ................................................................................................ 100 4.1. Contextualização dos Avaliadores e das Organizações onde Trabalham. ............ 100 4.2. Consolidação dos dados da Primeira Etapa do Questionário .............................. 101 4.3. Consolidação dos dados da Segunda Etapa do Questionário ............................... 103 4.4. Consolidação dos dados da Terceira Etapa do Questionário ............................... 105
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
xv
4.5. Consolidação dos Comentários e Observações Feitas pelos Avaliadores do
Processo PGIGR ............................................................................................................ 106 4.5.1. Comentários e Sugestões do Avaliador 1 ................................................ 106 4.5.2. Comentários e Sugestões do Avaliador 2 ................................................ 107 4.5.3. Comentários e Sugestões do Avaliador 3 ................................................ 108 4.5.4. Comentários e Sugestões do Avaliador 4 ................................................ 108 4.5.5. Comentários e Sugestões do Avaliador 5 ................................................ 110
4.6. Avaliação do PGIGR Quanto ao Atendimento às Características Traçadas para o
Processo ......................................................................................................................... 111 4.7. Comparativo do PGIGR com os Demais Modelos de Criação de Indicadores e
Análise dos Principais Benefícios Obtidos .................................................................... 113 5. Conclusão ...................................................................................................................... 117 Referências Bibliográficas ...................................................................................................... 122 APÊNDICE A - Processo de Geração de Indicadores para a Gestão de Requisitos - PGIGR
131 APÊNDICE B - Exemplos de Indicadores Detalhados ......................................................... 178 APÊNDICE C - Questionário de Avaliação do Processo PGIGR ........................................ 184
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
16
1. INTRODUÇÃO
Este capítulo apresenta o contexto em que a pesquisa foi realizada e como o trabalho foi
organizado.
1.1. Motivação e Contexto
A tecnologia da informação – TI – tornou-se onipresente nos dias atuais. Seu impacto nas
organizações evoluiu de tal forma que tem participação na manufatura, logística, marketing,
pesquisa e desenvolvimento, suporte à decisão e até mesmo na forma como os indivíduos se
relacionam. A evolução de TI está diretamente relacionada a projetos de desenvolvimento de
software, pois eles são o meio pelo qual organizações concretizam seus objetivos estratégicos e
colocam seus produtos no mercado (LUFTMAN, 2004).
Projetos possuem características que estão diretamente relacionadas a questões que
envolvem riscos, pois a proposta de um projeto é de gerar um produto, serviço ou resultado
exclusivo (PMBOK, 2004). Quando tratamos de projetos de desenvolvimento de software o fatorrisco se torna ainda mais eminente devido a fatores como: software é complexo; software é
abstrato; tecnologia muda rapidamente; tecnologia é um domínio vasto; requisitos muitas vezes
são incompletos; as melhores práticas ainda estão em processo de amadurecimento;
desenvolvimento de software é praticamente uma atividade de pesquisa; mudanças são
inevitáveis. (STEPANEK, 2005)
Pode-se observar a necessidade de melhorar a qualidade do software desenvolvido. No
entanto, os esforços em melhoria da qualidade não podem ter seu foco no produto apenas (fazero software melhor), mas principalmente no processo (fazer melhor o software). A qualidade do
processo é essencial para se ter a qualidade do produto (software desenvolvido), porque o
produto e o processo estão fortemente relacionados e não podem ser separados quando se analisa
a qualidade. Como em qualquer ramo industrial, a qualidade do produto é um objetivo de projeto
e deve ser incorporada durante o seu processo de construção.
Pesquisas feitas pelo Standish Group (2007) referente a projetos de desenvolvimento de
software estimam que apenas 29% dos projetos em empresas de larga escala obtiveram sucesso(com resultados aceitáveis, dentro do prazo e orçamentos previstos), 53% dos projetos ficaram
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
17
acima do orçamento e 18% não entregou produto algum. A pesquisa também mostra que os
projetos que têm estouro de orçamento normalmente acabam custando em média 56% a mais do
que a previsão original.
Entre os fatores mais críticos que influenciam para o sucesso ou fracasso de projetos de
desenvolvimento de software está a gerência de requisitos, por definir o produto que deve ser
gerado e estar diretamente relacionada com o escopo do projeto (Standish Group, 2007).
Pesquisas realizadas no Reino Unido mostram que 48% dos problemas relacionados a projetos
de software estão vinculados à gerência de requisitos (LAMSWEERDE, 2000).
Como exemplo de problemas relacionados à gerência de requisitos em projetos de
desenvolvimento de software, podemos citar: scope creep (perda de controle do escopo);documentação mal elaborada; requisitos que não são factíveis de serem contemplados; mudanças
realizadas sem controle e requisitos que não atingem as expectativas dos usuários. Um bom
gerenciamento de requisitos pode proporcionar uma melhor satisfação do usuário final, diminuir
os custos de desenvolvimento e aumentar as chances de se obter sucesso em projetos de
desenvolvimento de software.
A complexidade da gestão de requisitos, dentro de projetos de desenvolvimento de
software, requer que além da experiência do gerente de projetos, técnicas de gestão quantitativasejam aplicadas de forma a perceber objetivamente a situação do projeto e prever a sua
capacidade em atender aos seus objetivos. Isso demonstra que é de extrema importância que se
monitore tais projetos de forma eficaz para que problemas relacionados à gerência de requisitos
possam ser identificados com antecedência, possibilitando maior controle e previsibilidade para
os tomadores de decisões.
Organizações estão cada vez mais preocupadas em aferir os resultados de seus processos
utilizando dados objetivos para apoiar suas decisões em todos os níveis. Assim, busca-se definirindicadores com o propósito de utilizá-los como ferramenta de controle e de tomada de decisões.
A medição de software tem evoluído dentro da disciplina Engenharia de Software. Hazan (2002)
menciona que no passado muitas organizações de software tratavam as medições como um
trabalho adicional, muitas vezes considerada sem valor. Agora, a medição é implementada como
uma disciplina pró-ativa, e os indicadores constituem uma ferramenta estratégica. Kardec (2002)
destaca que “o indicador é a expressão didática da realidade”. Costello (1995) destaca que as
métricas e indicadores trazem informações objetivas e úteis para o acompanhamento,gerenciamento e controle do processo de desenvolvimento.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
18
Pesquisas bibliográficas mostram que vários autores exploraram aspectos relacionados às
métricas e indicadores dentro do processo de desenvolvimento de software (BASILI, 1992;
1994; BAUMERT, 1992; BOEHM, 1987; EVERALD, 1988; FENTON e PFEEGER, 1998;
FLORAC, 1999; GRADY, 1992; GOETHERT, WOLFHART, FISCHER, MATT, 2003;
GOODMAN, 1993; HALL e FENTON, 1997; MCGARRY, 2001; ROSENBERG, 1995; SEI,
2004; 2006; COSTELLO, 1995; HAZAN, 1999; 2001; 2002; LOCONSOLE, 2001, 2002; 2003;
2004, 2007). Contudo, grande parte dos autores citados explorou abordagens para a geração de
medições e indicadores em um contexto mais amplo dentro da engenharia de software. Poucos
tiveram como foco principal a gestão de requisitos.
Entre os que exploraram a gerência de requisitos com maior ênfase podemos citar: Hazan
(1999, 2001, 2002), que demonstra a criação de indicadores visando maior controle da
estabilidade e rastreabilidade dos requisitos, utilizando o GQM (BASILI, CALDIERA e
ROMBACH, 2002; SOLINGEN e BERGHOUT, 1999) e PSM (2008) como ferramentas base; e
Loconsole (2002 e 2004), que apresenta um conjunto de métricas e indicadores para a gerência
de requisitos com o foco de validação das mesmas. Loconsole (2002, 2004) foca principalmente
em indicadores de controle de volatilidade dos requisitos dentro de projetos de desenvolvimento
de software.
As duas autoras citadas acima, apesar de terem explorado aspectos relacionados à
geração de métricas e indicadores para a gerência de requisitos utilizando os métodos GQM
(BASILI, CALDIERA e ROMBACH, 1992, 1994; SOLINGEN e BERGHOUT, 1999) e PSM
(2008), que são modelos para especificação de indicadores de software, não entram em detalhes
a respeito de como se chegar aos indicadores gerados, tendo como foco principal em seus
trabalhos a validação e aplicabilidade dos indicadores propostos. Também nota-se certa carência
nos trabalhos no que tange à descrição do contexto organizacional em que as métricas e
indicadores foram criados. Isso acaba tornando difícil replicar os indicadores propostos dentro de
outro contexto organizacional, pois organizações distintas apresentam diferentes realidades e
necessidades.
Nesse contexto, no qual a gerência de requisitos se posiciona como um dos pilares para o
sucesso de projetos de desenvolvimento de software e a utilização de indicadores sendo uma
ferramenta essencial para que se tenha um correto controle de projetos, uma questão importante a
ser resolvida é como apoiar organizações que desenvolvem software na tentativa de aprimorar a
gestão de requisitos, visando, consequentemente, dar maior controle e previsibilidade. De forma
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 2
19
mais específica, como uma organização deve proceder para que possa gerar indicadores para
melhor gerenciar requisitos?
1.2. Objetivos
Apesar de existirem modelos que auxiliem na definição de indicadores, como por
exemplo GQM; GQ(i)M e PSM, todos eles são de certa forma genéricos. Por serem genéricos
acabam exigindo alto grau de adaptação e profissionais com qualificação específica para este
tipo de trabalho, visando adequar os processos às necessidades de cada organização, o que acaba
acarretando em maior investimento em tempo e custo para uma correta compreensão e adaptação
dos modelos às necessidades da organização.
Devido ao fato das definições de objetivos, perguntas e indicadores – padrão em todos os
modelos supracitados – ficarem totalmente a critério das organizações, acaba-se gerando maior
margem para erros, seja por inexperiência dos profissionais envolvidos, falta de clareza do
processo ou dos objetivos da organização.
Mas, com o intuito de agilizar e facilitar o processo de definição de indicadores para a
gerência de requisitos, faz-se necessário a utilização de um processo consistente, simples e
específico para requisitos. Um processo que direcione seus usuários em cada uma das etapas deconstrução dos indicadores, possibilitando um correto monitoramento de fatores relacionados a
requisitos em projetos de desenvolvimento de software, possibilitando maior previsibilidade e
mitigação de riscos. É nesse contexto que são apresentados os objetivos abaixo.
1.2.1. Objetivo Geral
O objetivo deste trabalho é propor um processo para a definição de indicadores
específicos para a gestão de requisitos em projetos de desenvolvimento de software. Esse
processo, quando executado, deve permitir que diferentes organizações possam seguir passos
claros e bem definidos, possibilitando criar indicadores específicos para suas necessidades e
características no que tange à gestão de requisitos, visando mitigar riscos e fornecer maior
controle e previsibilidade em projetos de software.
Um aspecto importante relativo ao processo proposto é que o mesmo deve ser
compreendido e executado por profissionais típicos das organizações, sem a necessidade de
especialistas em métricas.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 2
20
1.2.2. Objetivos Específicos
i. Definir um conjunto de características desejadas para um processo de definição de
indicadores para gestão de requisitos;
ii. Elaborar um processo para geração de indicadores para gestão de requisitos,
atendendo às características previamente traçadas;
iii. Avaliar o processo proposto;
iv. Aprimorar o processo após avaliação;
1.2.3. Suposições
Este trabalho de pesquisa está orientado pela seguinte suposição:
O processo proposto neste trabalho irá conduzir profissionais típicos de
desenvolvimento de software na definição de indicadores de requisitos, mesmo
que estes profissionais não sejam especialistas na área de métricas.
1.2.4. Organização da Dissertação
Este trabalho é constituído de cinco capítulos, incluindo esta Introdução.
O capítulo 2 apresenta o referencial teórico, onde as definições e conceitos pertinentes
aos tópicos principais do tema da pesquisa são apresentados, são eles: gerência de projetos,
medição de software, modelos de especificação de métricas e indicadores, e engenharia de
requisitos de software.
No capítulo 3 são apresentados os materiais e métodos de pesquisa, onde é descrita a
metodologia seguida para se criar o processo proposto por este trabalho.
No capítulo 4 são apresentados os resultados e análises a partir da avaliação do processo
proposto.
Por fim, o capítulo 5 apresenta as conclusões da pesquisa, destacando-se as contribuições
e perspectivas de trabalhos futuros.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 2
21
2. REFERENCIAL TEÓRICO
Nesta seção é apresentado o referencial teórico que embasa o trabalho, envolvendo os
conceitos de gerência de projetos, qualidade de software, gestão de requisitos, medição de
software e modelos de especificação de indicadores.
2.1. Gerenciamento de Projetos
Como este trabalho irá tratar sobre a gerência de requisitos dentro do contexto de projetos
de desenvolvimento de software, é necessário entender as práticas e conceitos a respeito desse
assunto. Esta seção apresenta uma breve explanação teórica a respeito de conceitos relacionados
à Gerência de Projetos.
Segundo Prado (1998), a Gerência de Projetos é um ramo da Administração que trata do
planejamento e controle de projetos. Gerenciar um projeto significa, resumidamente, planejar a
sua execução antes de iniciá-lo e acompanhar a sua execução.
Um projeto é um sistema de recursos e atividades com a finalidade de fornecer umproduto, atendendo a restrições de prazo, orçamento e qualidade. Gerenciamento de projetos é o
processo de tomar decisões que envolvam o uso dos recursos para realização de atividades em
um projeto (MAXIMIANO, 2002).
O gerenciamento de projetos é realizado através de processos, utilizando conhecimentos,
habilidades, ferramentas e técnicas. Para que o projeto seja bem sucedido, devem ser
selecionados os processos necessários para atender seus objetivos dentro dos grupos de processo
de gerenciamento de projetos (PMI, 2004).
O PMBOK (2004) organiza os conhecimentos em gerenciamento de projetos como um
conjunto de processos que estão agregados em cinco grupos, em função da integração entre eles
e de seus objetivos. O Quadro 1 relaciona os grupos de processo e seus objetivos.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 2
22
Quadro 1 – Grupo de processos de gerenciamento de projetos (PMI, 2004).
Grupo de Processos ObjetivoIniciação Define e autoriza o projeto ou uma fase do projeto
PlanejamentoDefine e refina o escopo do projeto e seus objetivos e
planeja as ações necessárias para alcançar esses objetivos.
ExecuçãoIntegra pessoas e outros recursos para realizar o plano de
gerenciamento do projeto
Monitoramento e
controle
Mede e monitora regularmente o progresso do projeto
para identificar variações com relação ao plano para que
possam ser tomadas as ações corretivas necessárias
EncerramentoFormaliza a aceitação do produto do projeto e conduz o
projeto (ou fase) a um final ordenado.
Os mesmos processos estão agrupados também em nove áreas de conhecimento,
conforme a natureza do conhecimento que os caracteriza. Cada uma das áreas de conhecimento
visa gerenciar um dos seguintes aspectos do projeto: integração, escopo, tempo, custos,
qualidade, recursos humanos, comunicações, riscos e aquisições.
Ao descrever um processo, o PMBOK (2004) indica quais devem ser suas entradas e
saídas. Sugere também um conjunto de conhecimentos, técnicas e ferramentas que podem ser
utilizados na sua execução. Essa definição, entretanto, não é mandatória, ou seja, nem todas as
saídas devem ser geradas obrigatoriamente e nem todas as técnicas precisam ser aplicadas. Cabe
a cada equipe de projeto adaptar o processo às suas necessidades.
2.2. Gerenciamento de Riscos
Este trabalho não pretende abordar diretamente a área de conhecimento de riscos, porém
a mitigação de risco é um aspecto inerente aos objetivos almejados, tendo em vista que o efetivo
monitoramento de projetos por meio de indicadores para gerência de requisitos visa minimizar
riscos e apoiar na tomada de decisões. Sendo assim, torna-se relevante a abordagem de aspectos
conceituais relacionados ao assunto. Esta seção apresenta uma breve explanação teórica a
respeito de riscos.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 2
23
Todo projeto tem risco. Sempre há um nível de incerteza associado ao resultado de um
projeto. Projetos de software são especialmente arriscados, seja por conta do alto grau de
variação ou pelas rápidas mudanças no contexto. A importância dada ao gerenciamento de riscos
num projeto é tal que se pode dizer que gerenciar um projeto é, basicamente, gerenciar riscos
(KENDRICK, 2003).
Os projetos de software estão inseridos no contexto maior e mais complexo dos negócios
e não estão isentos de interferências desse mundo. Interferências que são independentes da
vontade do gerente ou da equipe do projeto e são imprevisíveis e podem afetar seu sucesso.
Esses fatores representam, portanto, uma classe específica de riscos que estão muitas vezes
ligadas à gerência de requisitos, pois é através dela que se define e se controla as necessidades
dos stakeholders (envolvidos) nos projetos.
O dicionário Aurélio (HOLANDA, 1986) da Língua Portuguesa define risco como sendo
a probabilidade de insucesso, de malogro de determinada coisa, em função de acontecimento
eventual, incerto, cuja ocorrência não depende exclusivamente da vontade dos interessados.
O CMMI (SEI, 2002) define a área de processo Gerenciamento de Riscos (RSKM – Risk
Management ) como uma das áreas básicas na categoria de Gerenciamento de Projetos em sua
visão contínua. O objetivo do gerenciamento de riscos, segundo o CMMI, é identificarproblemas previamente, possibilitando que atividades de tratamento de riscos sejam planejadas e
acionadas para mitigá-los.
O PMBOK (2004) também define o gerenciamento de riscos como uma das áreas de
conhecimento, incluindo processos de identificação, análise, respostas, monitoramento e controle
dos riscos do projeto. O objetivo perseguido é aumentar as chances de sucesso do projeto.
De um ponto de vista de administração financeira, Saunders (2000) caracteriza o risco
tecnológico, associado à crescente dependência das empresas com relação aos sistemas baseados
em software. Ao investir em Sistemas de Informação (SI), as empresas buscam economia de
escala – com redução dos custos médios operacionais – e economias de escopo – com a
capacidade de produzir mais de um serviço com o mesmo recurso. Além disso, os SI têm um
papel fundamental na inovação, na conquista de novos mercados e na diferenciação com relação
à concorrência. O risco tecnológico, nesse caso, se dá quando os investimentos não produzem os
resultados esperados, podendo reduzir a capacidade competitiva da empresa.
O maior risco que um projeto enfrenta é o de não atender às condições de sucesso de seus
stakeholders críticos. Mais importantes que o risco de não cumprir o cronograma ou o
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 2
24
orçamento, é o risco de não gerar valor para a organização patrocinadora. Esse risco deve sempre
ser levado em conta pelo gerente do projeto. A geração de valor está diretamente relacionada a
aspectos vinculados à gerência de requisitos, pois é por meio dela que se definem as
necessidades dos stakeholders.
Este trabalho utilizará conceitos relacionados ao monitoramento, controle e mitigação de
riscos envolvendo a gerência de requisitos dentro do contexto de projetos de desenvolvimento de
software.
2.3. Definição de Sucesso em Projetos de Desenvolvimento de Software
Um projeto por definição é um empreendimento temporário, com objetivo de criar umproduto, serviço ou resultado único (PMI, 2004). Mas como se define sucesso? A busca por essa
definição talvez seja um dos temas mais discutidos na área de gerência de projetos.
De acordo com Cajado (1999), para que um projeto de software seja bem sucedido é
necessário que alguns parâmetros sejam bem analisados como, por exemplo, o escopo do
software, os riscos envolvidos, os recursos necessários, as tarefas a serem realizadas, os marcos
de referência a serem acompanhados, os esforços (custos) aplicados e a sistemática a ser seguida.
A análise de todos estes parâmetros é a função típica do gerenciamento de projetos, função estaque se inicia antes do trabalho técnico e que prossegue à medida que o software vai se
concretizando na forma de um produto. A atividade de gerenciar projetos deve objetivar
principalmente a qualidade, a produtividade e a redução de riscos, particularmente em projetos
de tecnologia da informação, nos quais as próprias métricas que permitiriam a medição de
sucesso têm que ser acordadas.
Segundo o dicionário Michaelis, a palavra sucesso tem o seguinte significado: “su.ces.so:
sm (lat successu): 1 resultado bom ou mau de um negócio. 2 conclusão. 3. êxito, resultadofeliz.”.
O PMBOK (PMI, 2004) estabelece sucesso em projetos a partir de quatro fatores
primários:
Escopo: o projeto foi finalizado dentro da especificação prevista;
Custos: o projeto foi finalizado dentro do orçamento previsto;
Tempo: o projeto foi finalizado dentro do tempo (cronograma) previsto;
Qualidade: o projeto entregou a qualidade esperada.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 2
25
2.4. Diagnóstico do Sucesso em Projetos de TI
O setor de tecnologia da informação (TI), apesar de ser uma das áreas que mais evoluiu
recentemente, apresenta desvantagem histórica quando comparada com outras áreas deconhecimento. Um exemplo bastante utilizado é a comparação com a área da construção civil,
que no decorrer de séculos faz com que seja comum empreendimentos dentro do prazo previsto,
dentro do orçamento e com a garantia que não desmoronem após sua conclusão.
Uma das razões conhecidas por trás deste fato é em função do tempo que é gasto com
detalhes do desenho do empreendimento antes de sua construção. O desenho tem que ficar
estável em determinado momento para que possa ser construído. A flexibilidade para mudanças,
apesar de existir, é menor durante seu desenvolvimento.
Quando nos voltamos para projetos de desenvolvimento de software essa realidade não é
necessariamente a mesma. Até em função das constantes mudanças que o ambiente de negócios
impõe à realidade das corporações e a velocidade da evolução que TI teve que apresentar para
acomodar estas mudanças de uma forma mais flexível. Não existe outro setor que tenha se
desenvolvido e evoluído tanto e em um ritmo tão devastador quanto o de tecnologia (IEEE,
2001; 2004). E, particularmente, quando nos referimos ao desenvolvimento de software esta
evolução frenética teria que apresentar conseqüências, principalmente no que diz respeito à taxa
de sucesso em projetos.
O Standish Group (2007), há mais de uma década, realiza estudos sobre os resultados dos
projetos de software ao redor do mundo. O resultado desses estudos é um relatório batizado de
Chaos Report – Relatório do Caos. Parte dos resultados desses estudos podem ser melhor
visualizados na Figura 1 abaixo.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 2
26
Figura 1 - Taxas de Sucesso e Fracasso em Projetos de Software (Chaos Report, 2007)
De acordo com o relatório, a taxa de sucesso em projetos de tecnologia da informação
ainda é baixa. Dos 600.000 projetos analisados em todo o mundo, atualmente apenas 34% dos
iniciados obtiveram sucesso – aqueles que terminaram dentro do prazo com o custo previsto e
com todas as funcionalidades atendidas; 51% foram classificados como projetos desafiadores –
finalizaram em um prazo maior que o estimado inicialmente, com custo superior e entregando
menos funcionalidades que as especificadas no início do projeto; e 15% dos projetos estãoclassificados como projetos cancelados – foram abandonados em algum momento do ciclo do
projeto.
Isso demonstra que mais da metade dos projetos apresentam problemas ligados a prazo,
escopo ou orçamento. A pesquisa também levantou as 10 principais causas que trilham para o
sucesso dos projetos de desenvolvimento de software, sendo que as três primeiras são:
1. Envolvimento dos Usuários
2. Apoio da alta direção
3. Requisitos bem estabelecidos
Entre os fatores que mais contribuem para o fracasso também foram listados os 10
principais, sendo que os três primeiros são:
1. Falta de envolvimento dos usuários
2. Requisitos incompletos
3. Constantes alterações de requisitos
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 2
27
Todos os três fatores de fracasso mencionados acima estão relacionados com a gestão dos
requisitos. (EASTERBROOK, 2004).
2.5. Qualidade de Software
Crosby (CROSBY,1979) define qualidade como “conformidade aos requisitos” e Juran
(JURAN e GRYNA, 1970) define qualidade como “adequação ao uso”. Conformidade aos
requisitos implica que requisitos devem ser claramente apresentados. Então, em qualquer
processo de produção, medições devem ser obtidas continuamente para determinar a
conformidade aos requisitos. As não conformidades relacionam-se aos defeitos encontrados no
produto.
A definição de qualidade como “conformidade aos requisitos dos clientes” é
especialmente relevante à indústria de software. Conforme apresentado anteriormente, os erros
de requisitos constituem uma das maiores causas de problemas no desenvolvimento de software.
De acordo com Jones (1992), 15% ou mais de todos os defeitos do software são erros de
requisitos. Um processo de desenvolvimento que não estabelece requisitos de qualidade está
limitado a produzir software de má qualidade.
De uma forma genérica, um software de boa qualidade produz resultados úteis e
confiáveis na oportunidade certa; é mensurável e auditável; é corrigível, modificável, e
evolutivo; opera em máquinas e ambientes reais; foi desenvolvido de forma econômica e no
prazo estipulado; e opera com economia de recursos. Qualidade de software é, pois, um conceito
muito mais amplo do que software correto e bem documentado, requerendo, para ser conseguida,
métodos e técnicas de desenvolvimento específicas (KAN, 1995).
Conforme a definição anterior, a qualidade de software depende de um conjunto de
propriedades que devem ser avaliadas de forma objetiva e padronizada para determinar se o
software é de boa qualidade. Assim, se faz necessário um sistema de medições implantado para a
coleta dos dados quantitativos necessários para a gerência do processo através de indicadores da
qualidade. Na visão do usuário, a qualidade do software depende das funcionalidades embutidas
no software, bem como a facilidade de uso. Caso a qualidade final do produto seja menor do que
o mínimo tolerado, o software será considerado inútil pelo usuário. No entanto, um software
contendo muitos recursos (funcionalidades), extrapolando as funcionalidades exigidas pelo
usuário, pode extrapolar limites orçamentários.
Além disso, o software deve ter características que atendam às necessidades de todos seususuários. Os usuários do software são: Cliente (quem contrata a equipe para o desenvolvimento
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 2
28
do projeto de software), Usuário Final (quem utilizará o software desenvolvido),
Desenvolvedores (profissionais que atuam no desenvolvimento e na manutenção do software) e
Suporte (profissionais que auxiliam tanto o desenvolvedor quanto o usuário final).
Portanto, deve-se avaliar os resultados de cada fase do processo de desenvolvimento de
software para assegurar a qualidade dos produtos intermediários e, conseqüentemente, garantir
um software de boa qualidade, pois, em cada fase do processo, um produto intermediário é
produzido para um usuário intermediário. Assim, cada produto intermediário possui atributos da
qualidade que afetam a qualidade do produto final.
2.5.1. Problemas Relacionados à Baixa Qualidade de Software
De modo geral, os problemas relativos à baixa qualidade de software (prazos
extrapolados, baixa produtividade, custos altos, qualidade deficiente) caem em uma das duas
categorias seguintes: falhas na qualidade de conformidade e falhas na qualidade de desempenho.
Qualidade de conformidade diz respeito à aderência do produto à finalidade para a qual
este foi construído. Ou seja, o software que dá ao usuário a funcionalidade que ele precisa. Por
sua vez, qualidade de desempenho refere-se à capacidade do produto em apresentar
consistentemente a funcionalidade desejada. Em termos de software, isso quer dizer boaperformance, ausência de bugs (a presença de bugs reduz a confiança do usuário), tolerância a
falhas de infra-estrutura (hardware), tolerância a erros do usuário (KAN, 1995).
Investimentos em qualidade minimizam custos. O aumento da qualidade normalmente é
acompanhado por aumento de produtividade e redução de custos na forma de menos retrabalho.
Isso sem falar em maior satisfação do cliente, que pode ser refletida muitas vezes em maior
participação no mercado. Em médio prazo, o software com melhor qualidade sofre menos
manutenções e as manutenções necessárias são feitas rapidamente.
Isso libera recursos para o desenvolvimento de novos projetos de software, reduzindo o
backlog (pendências) e acelerando o desenvolvimento. Além disso, o processo de
desenvolvimento pode ser continuamente melhorado para aumentar sua eficiência (prazos
menores e menos recursos gastos) e melhorar sua eficácia (resultados), com o objetivo de
garantir a satisfação do cliente.
Quando dividimos o processo de desenvolvimento de software dentro da descrição do
problema: projeto funcional; projeto técnico; construção e implementação, um erro que é
introduzido na fase de projeto e tenha que ser reparado em uma fase posterior, incorre
consideravelmente em alto custo e esforço (KRISTEN, 1996).
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 3
29
Assim, a solução para mudanças nas especificações do usuário final pode também ser
encontrada na melhora da qualidade das especificações do projeto do software. Mas, a qualidade
das especificações depende de um alto grau de entendimento mútuo das pessoas envolvidas.
Segundo Jones (1994), algumas das principais motivações para se investir em qualidade
de software são:
I. Redução dos atrasos dos projetos: produtos com muitos defeitos implicam gasto
de muitas horas na correção, sendo que essas horas poderiam ser utilizadas para
avançar o projeto. Além disso, o número de horas consumidas para corrigir um
defeito aumenta proporcionalmente ao tempo entre a sua introdução e a sua
exclusão, ou seja, quanto mais cedo se descobrir o defeito, menos tempo se gastará
para corrigi-lo.
II. Evita cancelamento de projetos: metade dos cancelamentos de projetos é devido à
baixa qualidade do software produzido.
III. Redução dos custos de manutenção: quanto menos defeito tiver um software no
seu desenvolvimento, menos horas serão despendidas na correção após a
implantação.
IV. Minimiza desgaste com os usuários (ou clientes): gerentes reconhecem este custo
como “declínio da reputação entre consumidores”. Eles ressaltam a fragilidade desua reputação com seus clientes e a importância de ganhar a confiança do cliente.
Em resumo, todas estas motivações acima têm um ponto de intercessão em comum,
minimizar perda de dinheiro.
2.5.2. Qualidade de Software e o Mercado Atual
No momento atual, a qualidade de software é trazida para o centro do processo de
desenvolvimento de software. Com o maior amadurecimento do mercado de software, maior é a
exigência de garantia da qualidade por parte dos clientes. A tendência das instituições é reduzir o
número de seus fornecedores de software, excluindo dos seus negócios aqueles que não estão
aptos a fornecer qualidade em seus produtos. Algumas instituições já utilizam como pré-requisito
para escolha de seus fornecedores de software determinado nível de maturidade do CMMI (SEI,
2001) ou do MPS.BR (SOFTEX, 2008).
A necessidade de qualidade em software está, portanto, conduzindo o mercado atual,
tanto internamente nas empresas de desenvolvimento de software, quanto externamente no
ambiente competitivo de negócios. Deming (SANDERS, 1994) sugere que esse fenômeno é uma
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 3
30
relação em cadeia, como mostra a Figura 2 – Efeitos do aprimoramento da Qualidade de
Software (SANDERS,1994). Melhorar a qualidade do desenvolvimento de software implica em
melhorar a produtividade, o que leva à redução de custos. Com isso, aumenta-se o mercado,
havendo um crescimento nos negócios da empresa, o que gera retorno de investimentos.
Figura 2 – Efeitos do aprimoramento da Qualidade de Software (SANDERS,1994)
Atualmente são vários os modelos de melhoria de processo de software disponíveis no
mercado, dos quais se destacam: CMMI, ISO 15504 e o modelo brasileiro MPS.BR. Todos têm
em comum a busca da qualidade nos processos, o que normalmente implica na melhoria da
qualidade dos produtos. Este trabalho aborda principalmente aspectos apresentados pelo CMMI
e MPS.BR no que diz respeito a aplicação de técnicas de medição e gerência de requisitos.
2.5.3. Capability Maturity Model Integration - CMMI
Com o intuito de aprimorar a qualidade do processo de desenvolvimento de software, o
Software Engineering Institute – SEI criou o CMM (PAULK, 1993). O CMM foi posteriormente
evoluído para o CMMI (2001). A principal mudança entre o CMM e o CMMI no que tange o
nível 2 de maturidade é a ênfase no estabelecimento de um processo de medição, por meio da
criação de uma nova área de processo chamada de Medição e Análise.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 3
31
A área de processo Medição e Análise do nível 2 do modelo CMMI tem o objetivo de
desenvolver e sustentar uma capacidade de medição usada para suportar gerencialmente as
necessidades de informação. Esta área inclui o seguinte:
i. Especificação dos objetivos de medição e análise de forma que estes sejam
alinhados com as necessidades de informação identificadas e objetivos;
ii. Especificação das medidas, mecanismos de coleta de dados e de armazenamento,
técnicas de análise, e mecanismos de comunicação e de feedback ;
iii. Implementação da coleta, armazenamento, análise, e comunicação dos dados;
iv. Fornecimento de resultados objetivos que podem ser usados na tomada de decisão
e implementação de ações corretivas apropriadas.
A Gerência de Requisitos de Software é uma área de processo do nível 2 – Gerenciado do
CMMI, tendo como propósito gerenciar os requisitos dos produtos, do projeto e dos
componentes do produto e identificar as inconsistências entre os requisitos e os planos do projeto
e produtos de trabalho. As principais atividades da gerência de requisitos são documentar as
mudanças de requisitos e manter a rastreabilidade bidirecional entre requisitos fonte, os
requisitos do produto e seus componentes (CMMI, 2001).
É um dos requisitos do CMMI (2001) que os processos implementados sejam
monitorados (G.P. 2.8), sendo a utilização de indicadores uma possível forma de se fazer talmonitoramento.
2.5.4. Melhoria do Processo de Software Brasileiro - MPS.BR
O MPS.BR é um modelo de melhoria e avaliação de processo de software brasileiro,
voltado para as micro, pequenas e médias empresas, de forma a atender as suas necessidades de
negócio.
Conforme a SOFTEX (2007), a base técnica utilizada para a construção do MPS.BR
(SOFTEX, 2007) é composta pelas normas NBR ISO/IEC 12207 (2008) – Processo de Ciclo de
Vida de Software e suas emendas 1 e 2; a ISO/IEC 15504 (2004) – Avaliação de Processo e seu
Modelo de Avaliação de Processo de Software ISO/IEC 15504-5 (2004); e o modelo CMMI-
DEV (SEI, 2006). Portanto, o modelo está totalmente aderente a essas normas. O MPS.BR
também cobre o conteúdo do CMMI-SE/SW (2001), através da inclusão de processos e
resultados de processos em relação aos processos da Norma NBR ISO/IEC 12207 (2008),
conforme Figura 3 abaixo.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 3
32
Figura 3 - MPS.BR (SOFTEX 2007)
O MPS.BR está dividido em 3 componentes:
• Modelo de Referência (MR -MPS) – contém os requisitos que as organizações deverão
atender para estar em conformidade com o MR-MPS. Ele contém as definições dos níveis de
maturidade, da capacidade de processos e dos processos em si. É baseado nas normas NBR
ISO/IEC 12207 (2008) e suas emendas 1 e 2, ISO/IEC 15504 (2004) e adequado ao CMMI-SE/SW (2001);
• Método de Avaliação (MA-MPS) – contém o processo de avaliação, os requisitos para
os avaliadores e os requisitos para averiguação da conformidade ao modelo MR-MPS. É baseado
na norma ISO/IEC 15504 (2004);
• Modelo de Negócio (MN-MPS) – contém uma descrição das regras para a
implementação do MR-MPS pelas empresas de consultoria, de software e de avaliação.
2.5.4.1. Níveis de Maturidade
Os níveis de maturidade estabelecem marcos de evolução de processos, caracterizando os
estágios de melhoria de implementação de processos na organização e permitindo prever o seu
desempenho futuro em uma ou mais disciplinas.
O MR-MPS (SOFTEX, 2007) define sete níveis de maturidade: A (Em Otimização), B
(Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente
Definido), F (Gerenciado) e G (Parcialmente Gerenciado), com a escala de maturidade
começando no nível G e terminando no nível A. Para cada um destes sete níveis de maturidade
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 3
33
foi atribuído um perfil de processos e de capacidade de processos. Indicando os pontos fracos
nos quais a organização deverá manter seu esforço para melhorar, de forma a atender os
objetivos de negócio.
A Tabela 1 mostra os níveis de maturidade com seus respectivos perfis de processo e
capacidade de processo.
Tabela 1 – Níveis de Maturidade do MPS.BR
Pode ser observado na tabela acima, a área de processo de gerência de requisitos, assim
como a gerência de projetos são a base de sustentação para os demais níveis, estando localizadas
no primeiro nível (G – Parcialmente Gerenciado). Já a área de medição encontra-se no nível logo
acima (F - Gerenciado), portanto não é requerido de uma organização que implante no nível G oprocesso de Medição. Este trabalho irá abordar práticas utilizadas em ambos os processos.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 3
34
2.6. Gestão de Requisitos
Projetos de software complexos são normalmente entregues com atraso, com orçamentos
estourados e não atendem às necessidades dos stakeholders, conforme mostrado em váriosestudos e pesquisas (BRAY, 2003; KOTONYA, 2002; SHENHAR, 2003; STANDISH GROUP,
2007). A ocorrência desses problemas normalmente tem algum relacionamento com os requisitos
do software. Uma pesquisa recente feita em 3800 empresas em 17 países concluiu que mais de
50% dos problemas apresentados em projetos de software estão diretamente relacionados com a
engenharia de requisitos e gerência de requisitos (LAMSWEERDE, 2000).
Um requisito é uma declaração que descreve uma funcionalidade (requisito funcional) ou
uma propriedade (requisito não funcional) de um sistema. A ideia é descrever o que o sistemadeve fazer ao em vez de como fazer. Requisitos precisam ser levantados, analisados,
documentados e validados, conforme ilustrado na Figura 4 abaixo. Essas são as principais
atividades no processo de engenharia de software (KOTONYA, 2002).
Segundo Davis (1993), o objetivo da engenharia de requisitos é converter definições
“pobres” do problema a ser tratado em uma especificação coesa e inteligível.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 3
35
Gerência de Requisitos
Levantamentodos Requisitos
Análise dosRequisitos
Documentaçãodos
Requisitos
Validação dosRequisitos
Necessidades dosusuários, informações
de domínio,
informações de
sistemas existentes,regulamentações,
padrões, etc...
Requisitos
acordados
Figura 4 - Processo de Engenharia de Requisitos (Adaptação de KOTONYA, 2002)
Requisitos são basicamente as necessidades do cliente. Podemos resumir como sendo as
condições ou necessidade que um sistema em desenvolvimento deve atender. Easterbrook
(2004) define a Engenharia de Requisitos como sendo uma ponte entre as necessidades dos
usuários e a sua concretização em um sistema computacional.
Requisitos implica que existe alguém solicitando, um cliente que sabe aquilo que
necessita. Em alguns projetos, requisitos são interpretados como sendo uma lista de
características (funcionalidades) demandadas por um cliente. O termo “Engenharia” sugere que a
engenharia de requisitos é uma disciplina por si só, porém faz parte de um contexto maior, que é
a engenharia de software (EASTERBROOK, 2004).
O resultado da engenharia de requisitos é o produto que irá “alimentar” e direcionar o
projeto de software, pois se trata da “matéria prima” para a geração do produto final.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 3
36
2.6.1. Gerenciamento de Requisitos
Pressman (2004) define o gerenciamento de requisitos como sendo o conjunto de
atividades que auxiliam o time de projeto na identificação, controle e acompanhamento dos
requisitos e suas mudanças durante toda a duração do projeto.
Conforme apresentado anteriormente, a gerência de requisitos também é um processo
chave (KPA) do CMMI (2001) e do MPS.BR (SOFTEX, 2007). No CMMI ele encontra-se no
nível 2 de maturidade e no MPS.BR no nível G. A gerência de requisitos inclui o
estabelecimento e a manutenção de acordos entre clientes e desenvolvedores com relação a
requisitos técnicos e não técnicos. Esses acordos formam a base de um conjunto de atividades
que visam identificar, controlar, acompanhar e alterar os requisitos em qualquer tempo, durante
toda a extensão do projeto, com o intuito de aprimorar o desenvolvimento do software. Algumas
das atividades envolvidas são:
Planejamento da fase de requisitos.
Estabelecimento do processo de requisitos.
Controle de alteração de requisitos.
Minimização da adição de novos requisitos (scope creep).
Acompanhamento do progresso.
Resolução de conflitos entre clientes e equipe técnica.
Estabelecimento de revisão de requisitos (revisão por pares).
Gerenciamento de requisitos inicia com a definição dos requisitos e continua durante toda
a extensão do projeto, culminando na validação do produto final com as especificações
previamente acordadas com o cliente (LUDWIG, 2002).
2.6.1.1. Problemas e Riscos associados à Gerência de Requisitos
Segundo El Emam (1997), os principais problemas relacionados à gerência de requisitos
são: dificuldades de identificar as mudanças nos requisitos; falta de habilidade para chegar a um
consenso sobre as mudanças chave para os stakeholders; falta de habilidade para manter o
documento de requisitos consistente; falta de habilidade para estimar adequadamente os recursosnecessários para implementar as mudanças nos requisitos.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 3
37
Segundo Jones (1994), o principal risco que atinge 80% dos projetos de software é o da
evolução de requisitos de forma descontrolada. Este risco é definido como:
Novos requisitos ou modificações significativas nos requisitos existentes que são feitas
após o conjunto básico de requisitos acordado pelos clientes e desenvolvedores.
Falhas para antecipar mudanças de requisitos (previsão de aumento ou mudança do
escopo do projeto – scope creep) e fazer planos para lidar com estes.
Como os requisitos são voláteis, a própria natureza do processo leva ao que Jones (1994)
classifica de risco inerente. Os principais problemas associados a este risco são os seguintes:
atritos entre a equipe de desenvolvimento, gerentes e usuários; não atendimento ao prazo
acordado; software de baixa qualidade e altos custos.
Isso tudo faz da Gerência de Requisitos fator fundamental para o tratamento de riscos em
projetos de desenvolvimento de software. Uma das formas de aprimorar o controle, aprimorando
a visibilidade e tomada de decisão é através da utilização de técnicas de medições.
2.7. Medição de Software
Processos efetivos de medição do desempenho maximizam as chances de se obter
sucesso, pois permitem à organização entender a sua capacidade de forma a 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, agregando previsibilidade, melhor controle de custos,
redução de riscos, melhoria da qualidade e garantindo que os objetivos do negócio sejam
atingidos (FLORAC; CARLETON, 1999).
2.7.1. Conceitos
Medição é um conjunto de operações com objetivo de determinar um valor a uma medida
(ISO/IEC, 2002).
Medição é o processo pelo qual números ou símbolos são designados para atributos de
entidades do mundo real através de um conjunto definido de regras. Uma vez que essa
associação é estabelecida é possível comparar a entidade física através dos números associados.
Essa comparação resulta em medições. Por exemplo, idade é um atributo comum da entidade
pessoa. A medida resultante de pessoa poderia ser número de anos, número de meses ou número
de dias (FENTON e PFLEEGER, 1998).
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 3
38
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 e PFLEEGER, 1998, p. 28).
Lord Kelvin (1989) disse: “Quando se pode medir o assunto no qual está sendo tratado e
é possível expressá-lo em números, pode-se dizer que você sabe o que está sendo tratado,
porém, quanto não se pode expressa-lo em números, seu conhecimento a respeito do assunto é
insuficiente e insatisfatório.”
O aspecto importante sobre medições é que elas trazem um senso comum para um
determinado assunto, pois precisam ser padronizadas no intuito de significar a mesma coisa paratodos. A utilização de medições faz com que seja possível avaliar o processo de desenvolvimento
de software, possibilitando identificar aspectos que estão fora dos resultados esperados,
possibilitando o seu ajuste durante o processo.
Os custos gerados pelo processo de desenvolvimento de software são altos. Através de
medições é possível gerar melhores estimativas de custo e maior previsibilidade de duração dos
projetos, minimizando erros e custos com retrabalho. A ideia é que a todo momento se tenha
informações precisas para aprimorar a tomada de decisão.García et al (2006, p. 635) afirma não haver tratamento uniforme para alguns conceitos
básicos de medição como métrica, medida básica, medida derivada e indicador. Neste contexto, é
importante definir os conceitos que serão utilizados como base para este trabalho.
Outro conceito importante na área de medição é o indicador. Para a ISO/IEC (2002, p.
22), Mcgarry et al (2002), SEI (2004, p. 1) e GQM (BASILI, CALDIERA e ROMBACH, 2002),
um indicador é uma medida ou uma combinação de medidas, normalmente apresentado na forma
gráfica, que provê entendimento a respeito de uma questão ou conceito desoftware
. Os
indicadores são a base para a análise e tomada de decisão, portanto são eles que devem ser
apresentados aos usuários ou consumidores das informações.
2.7.2. Indicadores
O SEI (2004) define um indicador como uma representação de uma medição com o
intuito de promover uma visibilidade quantitativa específica de determinado aspecto do
desenvolvimento de software.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 4
39
Um indicador é um dado numérico, expresso em uma unidade de medida ao qual se
atribui uma meta e que é trazido periodicamente à atenção dos gestores dos processos com a
finalidade de apoiá-los na avaliação do desempenho (TAKASHINA e FLORES, 1996; FPNQ,
2001). As decisões devem ser baseadas no resultado dos indicadores, considerando as tendências
e os referenciais de comparação. Uma análise de tendência leva em consideração o
comportamento de um conjunto de resultados de um indicador específico ao longo do tempo.
Segundo os Critérios de Excelência (FPNQ, 2003), uma tendência é favorável quando
ocorre uma variação positiva de resultados de no mínimo três períodos de tempo consecutivos.
Os resultados dos indicadores de referenciais comparativos podem ser internos ou externos à
organização.
Deve-se selecionar um conjunto de métricas pequeno e equilibrado, que irá ajudar a
organização a acompanhar o progresso na direção de seus objetivos (HAZAN, 2001). Os
métodos GQM (BASILI, 1992; BASILI, CALDEIRA, ROMBACH, 1994), GQ(I)M (PARK et
al., 1996) e PSM (2008) são exemplos de frameworks utilizados para definir métricas e
indicadores apropriados aos objetivos das organizações. Todos esses métodos tem em comum a
seleção de alguns objetivos de medição. As fontes para os objetivos podem ser necessidades
gerenciais, técnicas, de projeto, de produto, ou de implementação do processo. Declaram-se os
objetivos de modo que sejam quantificáveis e mensuráveis. Posteriormente, para cada objetivo,
identificam-se as perguntas que precisam ser respondidas para determinar se o objetivo está
sendo alcançado. Finalmente, identificam-se métricas e indicadores que ajudam a responder cada
pergunta.
2.7.3. Objetivos de Medições em Projetos de Desenvolvimento de Software
Porque medir software? Segundo Fenton e Pfleeger (1998), “ Não se pode prever ou
controlar aquilo que não é possível medir.”
Hazan (1999) destaca um conjunto de razões para se medir software:
formar uma linha de base (baseline) para estimativas;
determinar se as metas de produtividade do processo estão sendo atingidas;
determinar se as metas de qualidade do processo estão sendo atingidas;
determinar se as metas de qualidade do produto estão sendo atingidas;
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 4
40
avaliar os benefícios de novos métodos, treinamentos e ferramentas;
melhorar o relacionamento com o cliente;
melhorar a gerência de contratos de software;
reduzir o risco de pressão excessiva do cronograma;
melhorar a gerência de projetos de desenvolvimento de software;
entender e aperfeiçoar o processo de software;
As métricas e indicadores trazem informações objetivas e úteis para o acompanhamento,
gerenciamento e controle do processo de desenvolvimento (COSTELLO, 1995). As métricas
identificadas na literatura para o processo de requisitos podem ser agrupadas nas seguintesclasses (COSTELLO, 1995; DAVIS, 1993; FARBEY, 1990; FENTON, 1998; HAMMER,
1998):
métricas para aferição da qualidade;
métricas para gerenciamento e evolução de requisitos;
métricas para verificação/validação.
Segundo Goodman (1993), métricas são o alicerce da engenharia de software. Ele
classifica todo esse processo como sendo a aplicação contínua de técnicas de medição ao
desenvolvimento de software e seus produtos no intuito de promover informações úteis e
temporalmente relevantes (métricas) para o aprimoramento do processo de desenvolvimento e
seus produtos.
Costello e Liu (1995) definem métrica como sendo a derivação de medição de um
produto de software, processo ou recursos. O seu propósito é promover uma avaliação
quantitativa a respeito do produto, processo ou recursos através da utilização de alguns atributos
associados.
Uma métrica é uma medida de qualidade. Métricas podem ser utilizadas para aprimorar a
qualidade do software, produtividade e promover melhor utilização dos recursos, produtos e
processo. Métricas de software apresentam informações sobre o processo de desenvolvimento,
como custos, tempo durante todas as fases do projeto. O ideal é que as métricas sejam (Everald,
1988):
Simples
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 4
41
Objetivas
De fácil coleta
Válidas (consistentes)
Robustas
Métricas devem medir o que elas foram concebidas para medir, e devem ser de fácil
entendimento para o público alvo a um custo razoável.
Medições em projetos de desenvolvimento de software permitem um melhor
entendimento do ambiente de desenvolvimento e promovem informações detalhadas sobre o
projeto. Métricas são utilizadas no intuito de melhor prever, gerenciar e controlar o projeto. Com
o apoio de um conjunto consistente de métricas é possível se planejar de forma mais apropriada e
assertiva. Medições de software promovem guias que nos indicam onde estamos e para onde
estamos indo dentro do processo de desenvolvimento de software.
A medição em projetos de software deve percorrer todas as fases do desenvolvimento de
software. De acordo com Fenton e Pfleeger (1998) na engenharia de software existem classes e
entidades que devem ser medidas:
1. Processos: conjunto de atividades que são executadas durante o desenvolvimento desoftware.
2. Produto: qualquer artefato, entregável ou documento que resulte de uma atividade de
processo, por exemplo, o código fonte.
3. Recursos: entidades essenciais para a execução das atividades do processo, como por
exemplo, ferramentas e pessoas.
Medição em projetos de software provê uma forte motivação para que organizaçõesanalisem os dados e resultados gerados pelos seus projetos. Existem três razões para que
organizações utilizem medições em seus processos de desenvolvimento de software
(MCGARRY, 2001):
Melhor entendimento - O aumento do entendimento através de medições possibilita um
melhor gerenciamento de um projeto de software e o seu constante aprimoramento. Um
melhor entendimento do processo de engenharia de software possibilita o aprimoramento
da tomada de decisão. Um programa de medições possibilita uma melhor estimativa de
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 4
42
custos, melhor desenvolvimento do cronograma, maior visibilidade de recursos
necessários e melhor controle de riscos.
Melhor controle - Uma melhor visibilidade da gerência de requisitos no que tange o
progresso e o status do projeto irá proporcionar uma melhor adaptabilidade do projeto no
intuito de realizar eventuais ajustes em cronogramas.
Promover aprimoramento – O foco primário de qualquer organização de engenharia de
software é de produzir produtos de qualidade dentro do prazo e orçamento previstos. Mas
um constante objetivo que devem seguir é o aprimoramento contínuo em qualidade de
seus produtos e serviços. O aprimoramento de produtos pode ser atingido através do
aprimoramento de processo utilizado para gerar o produto. O aprimoramento de processorequer a incorporação de mudanças no processo, que podem ser alcançadas através de
mudanças gerenciais, tecnológicas. Em qualquer um dos dois casos a medição de
software é parte fundamental do processo de aprimoramento, pois ela está diretamente
relacionada ao fato de ser necessário saber a qualidade do produto antes e depois da
alteração do processo. O modelo CMMI (2001) e MPS.BR (SOFTEX, 2007) são
exemplos de processos de melhoria do processo de desenvolvimento de software.
Comunicar eficientemente: Medições ajudam a identificar, priorizar, acompanhar ecomunicar os objetivos e questões associadas em todos os níveis da organização. E
também na comunicação entre organizações contratantes e contratadas. Leite (2001)
ressalta que as métricas são essenciais para uma comunicação objetiva e precisa.
Acompanhar Objetivos de Projetos Específicos: Medições indicam o status dos
processos e produtos do projeto de software, representando objetivamente o progresso
das atividades do projeto e a qualidade dos produtos de software associados. Segundo De
Marco (1991), o gerenciamento eficaz dos parâmetros quantitativos de projeto resulta emplanejamento e controle eficazes.
Identificar e Corrigir Problemas Cedo: Medições apóiam a estratégia de gerência pró-
ativa. Problemas potenciais são objetivamente identificados, conforme os riscos sejam
avaliados e gerenciados. Os problemas existentes são avaliados e priorizados.
Apoiar Decisões Chaves: Os projetos de software estão sujeitos a restrições tais como:
custo, prazo e qualidade, que devem ser negociadas entre si e gerenciadas juntas para
atingir os objetivos do projeto. As medições apóiam as decisões relativas à gestão. Os
gerentes de projeto devem ser capazes de defender a base de suas estimativas e planos
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 4
43
com dados de desempenho históricos. Eles devem ser capazes de justificar as mudanças
de planos com dados de desempenho atuais.
Deve-se observar que as métricas não devem ser analisadas isoladamente, dado que
podem existir correlações entre elas; por exemplo, se a volatilidade do sistema é alta, o número
de requisitos já implementados e verificados (aprovados na fase de testes) pode refletir um valor
que rapidamente irá ser modificado.
Para melhor avaliar os índices e valores obtidos, a organização deve manter uma linha de
base (baseline) com as medições obtidas em seus projetos, comparando então o valor obtido
numa determinada avaliação com outros anteriormente registrados na base. Se a organização em
questão dispõe de uma boa linha de base (baseline), pode aplicar técnicas estatísticas eidentificar se o valor encontrado está fora do esperado, considerando uma distribuição de
freqüências que seja adequada à métrica ou indicador em questão (FENTON, 1997).
No intuito de definir métricas consistentes é recomendado o uso de um framework para a
definição sistemática de métricas para um determinado propósito. Lott (1996) descreve sete
frameworks goal-oriented, d entre eles está o Goal Question Metrics (GQM). O GQM se tornou
uma ferramenta largamente utilizada em todo mundo (BASILI, 1999; FUTRELL, 2001;
HARRISON, 1999). Também existem extensões do método GQM disponíveis na literatura(OFFEN e JEFFERY, 1997).
2.7.4. Modelos para Geração de Indicadores
A fim de possibilitar a criação de indicadores, foram feitas pesquisas com o intuito de
mapear os principais processos e metodologias presentes na literatura acadêmica. Esta seção irá
apresentar conceitos relacionados ao Goal Question Metric, GQ(i)M e Personal Software
Measurement (PSM).
2.7.5. Goal Question Metric - GQM
O GQM é um framework para elaborar um programa de métricas. Uma métrica confiável
provê uma evidência para o aprimoramento, possibilitando uma melhor análise de
custo/benefício e promovendo uma base para a tomada de decisões.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 4
44
A abordagem GQM representa um método para especificação de programas de medição
de software permitindo que as medições selecionadas sejam utilizadas para acompanhamento do
sucesso no alcance dos objetivos traçados para o programa (GOETHERT; FISCHER, 2003).
O GQM pode ser utilizado em qualquer fase do desenvolvimento de software. Esta
técnica foi aplicada no processo de software da NASA e obteve resultados extremamente
satisfatórios (NICK, ALTHOFF e TAUTZ, 1999). O paradigma do GQM consiste em 3 passos:
1. Levantar um conjunto de objetivos baseados nas necessidades de uma organização
2. Derivar um conjunto de questões
3. Desenvolver um conjunto de métricas que promovem a informação necessária para
responder as questões e aferir o atendimento dos objetivos.
A Figura 5 a seguir demonstra um exemplo da aplicação do GQM para criar indicadores
que possibilitam avaliar o atendimento de um Help Desk.
Metas
(Goals)
Questões
(Perguntas)
Indicadores eMétricas
(Metrics)
Exemplo
M1: Avaliar o atendimento do Help Desk
Q1: Qual a qualidade da abertura dos
chamados?Q2: Qual a qualidade das resoluções de primeironível?
I1: Tempo médio de abertura dos chamadosI2: Quantidade de chamados abertos por diaI3: Quantidade de chamados resolvidos noprimeiro nível.
Figura 5 - Exemplo de Aplicação do GQM
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 4
45
2.7.5.1. Levantar um conjunto de objetivos baseados na necessidade de uma organização
Esse é o primeiro estágio do GQM. Nele a organização define objetivos no intuito de
atingir a qualidade desejada. A equipe de desenvolvimento ou a gerência pode definir um
conjunto de objetivos para o aprimoramento de uma atividade de acordo com a estratégia
organizacional. Objetivos são definidos em termos de propostas, perspectivas e ambiente
(ROSENBERG e HYATT, 1995).
Propostas: Para caracterizar, avaliar, prever ou motivar melhorias no processo ou
produto com o intuito de melhor entender, avaliar gerenciar, aprender e aprimorar.
Perspectiva: Examina o custo, efetividade, defeitos, mudanças, métricas do produto,
confiabilidade, de um determinado ponto de vista: desenvolvedor, gerência, cliente,
corporação.
Ambiente: O ambiente está diretamente relacionado a fatores relacionados a processos,
pessoas, problemas, métodos, ferramentas, etc.
Objetivos são como um alicerce na elaboração de planejamento para o desenvolvimento.
Alguns exemplos de possíveis objetivos relacionados à gerência de requisitos são:
Aprimoramento das estimativas de software
Minimizar retrabalho nos projetos
Redução de custos das atividades de requisitos
Aprimoramento da qualidade dos artefatos de requisitos
Aumento da produtividade das atividades de requisitos
2.7.5.2. Identificação das perguntas
As perguntas têm o intuito de prover o entendimento a respeito do alcance dos objetivos
estabelecidos pela organização. As perguntas informam à organização o que deve ser atingindo
no intuito de desenvolver um produto de qualidade. Através das perguntas não se perde o foco
dos objetivos estabelecidos previamente. As perguntas são como um guia para que não se gere
dúvida a respeito das ações que devem ser tomadas.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 4
46
2.7.5.3. Desenvolver um conjunto de métricas que promovem a informação necessária para
responder as questões
É neste passo que as méticas são identificadas. No processo de desenvolvimento de
software os dados devem ser coletados, avaliados e validados. O dado identificado é avaliado
com o intuito de responder as perguntas para alcançar os objetivos. A validação é feita para aferir
se os dados coletados estão atingindo os objetivos ou não. As métricas derivam das perguntas
elaboradas com intuito de atingir os objetivos estabelecidos.
Como o GQM é um framework genérico para elaboração de um programa de métricas
que visa aprimorar a análise de projetos e a tomada de decisões, algumas de suas limitações são:
Devido ao fato de ser genérico, para sua utilização muitas vezes é necessário que
organizações possuam profissionais especializados que possam compreender sua
estrutura e adaptá-lo às necessidades da organização, o que normalmente acarreta
em tempo e custos;
Devido ao fato de ser genérico, não apresenta foco ou direcionamento para
resolução de necessidades específicas de uma organização. Sendo assim, na etapa
de definição de objetivos, há margem para se definir objetivos inadequados, o quetambém acarretaria na definição de indicadores inapropriados, fazendo com que o
processo caia em descrédito;
Devido ao fato de ser genérico, não leva em consideração eventuais limitações
que uma organização possa vir a ter, o que a impossibilitaria de cria determinados
indicadores.
O GQM não faz distinção clara entre o que é uma métrica e um indicador, o que
pode acarretar em dificuldades de interpretação durante a sua utilização e
acarretar na má estruturação dos indicadores;
O GQM não apresenta um detalhamento de quais informações devem fazer parte
da estrutura de um indicador
2.7.6. Goal Question Indicator Metric - GQ(I)M
Algumas extensões do GQM foram elaboradas com base na abordagem inicial de Basili eWeiss (1984). Entre as extensões temos a do SEI – Software Engineering Institute da
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 4
47
Universidade de Carnegie Mellon dos Estados Unidos (PARK et al., 1996), focadas na definição
de objetivos estratégicos e indicadores para visualização das métricas.
A versão do Software Engineering Institute da Universidade de Carnegie Mellon dos
Estados Unidos foi publicada em 1996 e denominada como GQ(I)M (PARK et al., 1996). Esta
tem por objetivo ser uma técnica para a definição de uma política de medição. O guia possui a
seqüência de atividades recomendadas, produzindo ao final um conjunto de indicadores e
métricas adequadas às necessidades de uma organização.
Nesta técnica os objetivos do programa de medição devem ser definidos de acordo com
os objetivos da organização. A partir dos objetivos traçados, transformar estes objetivos em
atividades que podem ser medidas durante o decorrer do projeto de software (SOLINGEN;BERGHOUT, 1999).
A Figura 6 a seguir apresenta uma visão geral do método GQ(I)M. Primeiro identifica-se
os objetivos do negócio em uma visão de alto nível. Estes objetivos de negócio são obtidos da
visão e missão, definidos pela alta direção.
Figura 6 - Goal Question Indicator Metric - GQ(I)M (ARAÚJO, 2004)
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 4
48
Em seguida, com os objetivos definidos, estes são refinados com o intuito de se validar e
entender de que maneira estes objetivos podem ser medidos. O resultado deste refinamento é
uma lista de questões que estão associadas a cada um dos objetivos.
Com as questões descritas, estas servem de base para a identificação de informações para
a composição dos indicadores e métricas. Exemplo de questões para obtenção de informações
podem ser: existem ferramentas necessárias para controlar a volatilidade dos requisitos?; qual o
impacto da mudança de requisitos durante o desenvolvimento do projeto?
Com as informações obtidas através das questões, as métricas e indicadores são
detalhados em um plano de projeto. Detalhes como características do tipo de gráfico a ser
utilizado e tipo de público de visualização do gráfico são identificadas. A apresentação ourelatório usado para comunicar os dados é a chave para entender porque um dado específico está
sendo coletado.
Comparando com a abordagem GQM de Basili e Rombach (BASILI et al. 1994), o
GQ(I)M prevê que os indicadores sejam parte integrante do processo, a fim de se analisar e
acompanhar graficamente o andamento e a concretização das metas traçadas.
Segundo Goethert (2003), identificar questões e métricas sem visualizar um indicador
não é suficiente para começar um programa bem sucedido de medição. Estes indicadores servem
como uma especificação de requisitos para os dados que devem ser coletados, processados e
analisados.
O GQ(I)M apresenta uma pequena evolução quando comparado ao GQM, pois ele faz
uma distinção entre o que é um indicador e uma métrica, apresentando métrica como sendo as
informações que servem de insumo para a criação de um indicador, conforme apresentado na
Figura 6. Porém, trata-se também de um processo genérico para definição de indicadores,
acarretando nos demais problemas listados anteriormente para o GQM.
2.7.7. Practical Software Measurement - PSM
O Modelo de Informação do Practical Software Measurement – PSM (2008) também
pode ser considerado uma evolução do modelo GQM. O PSM fornece um apoio para a definição
das necessidades de Informações, o Goal do GQM (WIEGERS, 2001) e um guia para chegar-se
na especificação da métrica e indicadores.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 5
49
O modelo PSM relaciona-se ao desenvolvimento de uma estrutura de informação de
medição de projeto usando o Modelo de Informação de Medição, e descreve atividades e tarefas
de medição usando o Modelo de Processo de Medição. Estes modelos fornecem a base para um
programa de medição de software efetivo (MCGARRY, 2002; PSM, 2008).
O PSM é um processo para se analisar questões relacionadas a projetos de software, seus
riscos e custos. Ele é baseado na experiência obtida em projetos do departamento de defesa dos
Estados Unidos, representando as melhores práticas da comunidade de engenharia de software.
O processo é completamente flexível para se adaptar a uma necessidade específica de uma
organização (DOD, 2008).
2.7.7.1. O Modelo de Processo de Medição
O Modelo de Processo de Medição do PSM fornece um framework para implementação
de medição em um projeto. Ele é construído baseando-se no ciclo PDCA (Plan - Do - Check -
Act ) de Deming (1982), adaptado para suportar atividades e tarefas específicas de medição. A
Figura 7 apresenta o Modelo de Processo de Medição que inclui quatro atividades principais:
planejar medição, executar medição, avaliar medição, estabelecer e sustentar compromisso.
Figura 7 - Practical Software Measurement (PSM)
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 5
50
O subprocesso Planejar Medição compreende a identificação das necessidades de
informação do projeto e a seleção das medidas apropriadas para tratar estas necessidades
utilizando o Modelo de Informação de Medição. Este subprocesso compreende 3 atividades:
Identificar e priorizar necessidades de informação
Selecionar e especificar métricas
Integrar mensuração aos processos do projeto
O subprocesso Executar Medição engloba a coleta e o processamento dos dados de
medição; o uso dos dados para analisar as necessidades de informação e questões associadas; e a
geração de produtos de informação para apresentar os resultados da análise, ações alternativas, e
recomendações para os responsáveis pelas decisões. Este subprocesso também é composto por 3
atividades:
Coletar e processar dados
Analisar dados
Produzir recomendações
O subprocesso Avaliar Medição aplica técnicas de medição e de análise para medir o
processo. As medidas aplicadas e a capacidade do processo de medição são avaliadas, ajudando
a identificar as ações de melhoria associadas. As atividades que compõe este subprocesso são:
Avaliar medidas
Avaliar o processo de mensuração
Atualizar a base de experiências
Identificar e implementar melhoriasO processo Estabelecer e Sustentar Compromissos garante que sejam fornecidos os
recursos e a infra-estrutura organizacional requeridos para implementar um programa de
medição viável.
Os Processos Técnicos e Gerenciais também estão representados no Modelo de
Processo de Medição. Os responsáveis pelas decisões operam dentro destes processos, definindo
necessidades de informação e usando produtos de informação de medição para apoiar suas
decisões.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 5
51
2.7.7.2. Estrutura de formação de Indicadores do PSM
A estruturação de um indicador descreve como os atributos relevantes de software são
quantificados e convertidos para indicadores. A Figura 8 ilustra a estrutura de formação de um
indicador (HAZAN, 2002). Os componentes chave são os seguintes:
Atributo mensurável é uma propriedade distinguível de uma entidade de software.
Entidades incluem processos, produtos, projetos e recursos. Os atributos devem ser
relevantes para atender às necessidades de informação do usuário.
Medida Básica é uma medida de um único atributo definido por um método de medição
específico. Uma medição básica é funcionalmente independente de todas as outras medidas ecaptura informação sobre um único atributo.
Método de Medição é uma seqüência lógica de operações, descrito genericamente, usado na
quantificação de um atributo com respeito a uma escala específica. Cada combinação única
de um atributo e um método produz uma medida básica diferente.
Tipo de Método depende da natureza das operações usadas para quantificar um atributo
específico. Os métodos podem ser subjetivos, os quais envolvem julgamento humano ou
objetivos, os quais se baseiam em regras numéricas tais como contagem. Estas regras podem
ser implementadas manualmente ou automaticamente.
Escala é um conjunto de valores ordenado, contínuo ou discreto, ou um conjunto de
categorias, nas quais um atributo é mapeado. A escala define o conjunto de possíveis valores
que podem ser produzidos pela execução de um método de medição.
Unidade de Medição é uma quantidade específica, definida e adotada por convenção, com a
qual outras quantidades do mesmo tipo são comparadas para expressar sua magnituderelativa para aquela quantidade.
Medida Derivada é uma medida, ou quantidade, que é definida como uma função de duas
ou mais medidas básicas ou derivadas.
Função Medição é um algoritmo ou cálculo executado para combinar dois ou mais valores
de medidas básicas e/ou derivadas.
Indicador é uma medida que fornece uma estimativa ou avaliação de atributos derivados de
um modelo de análise com respeito a definição de necessidades de informação. Indicadores
constituem a base para a tomada de decisões.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 5
52
Modelo de Análise envolve duas ou mais medidas básicas ou derivadas com um critério de
decisão associado. Os modelos de análise produzem estimativas ou avaliações relevantes
para as necessidades de informação definidas.
Critério de Decisão são limiares, metas e limites usados para determinar a necessidade para
ação ou investigação adicional ou descrever o nível de confiança em um resultado dado. O
critério de decisão ajuda a interpretar os resultados da medição.
Figura 8 - Estruturação de criação de um Indicador no PSM (HAZAN, 2002)
A Figura 9 a seguir apresenta um exemplo de uma construção de um indicador de
produtividade. A produtividade está relacionada ao esforço gasto e ao tamanho do software.
Assim, o esforço e o tamanho são as entidades de software mensuráveis de interesse. Atributos
específicos destas entidades devem ser selecionados para que seja possível quantificar e uma
função de medição deve ser projetada para combiná-los em uma medida derivada para cada
projeto. A estimativa de produtividade baseada em dados históricos permite a computação de
intervalos de confiança que ajudam a avaliar se os resultados atuais são similares aos valores
estimados.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 5
53
Figura 9 - Exemplo de estruturação de Indicador através do PSM (HAZAN, 2002)
Os principais benefícios de se utilizar a estrutura do PSM são: padronização da
nomenclatura de componentes utilizados para compor um indicador; redução de redundância,
identificando um conjunto essencial de medidas básicas; aumento da precisão e repetibilidade
pela garantia de que todos os aspectos essenciais da abordagem da medição estão adequadamente
definidos; maximização do valor das medições básicas pela criação de padrões para indicadores
que podem ser facilmente reconhecidos, reusados, e adaptados; documentação do link entre a
necessidade de informação e como esta é satisfeita.
O PSM apresenta a estrutura mais completa, quando comparamos com o GQM e
GQ(I)M. Ele possui um detalhamento de cada um dos componentes de um indicador e faz o
mapeamento até o objetivo traçado, conforme demonstrado na Figura 8 e Figura 9.
Porém, também se trata de uma processo genérico para definição de indicadores, acarretando nos
mesmos problemas listados anteriormente para o GQM e GQ(I)M.
2.7.8. Instrumentos de Análise de Desempenho
Diversos instrumentos de controle são utilizados para avaliar o desempenho dos
processos de uma organização ou de um projeto de software específico. Estas ferramentas
auxiliam na interpretação de indicadores, dando visibilidade para controle, análise e identificação
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 5
54
de causas de problemas e, portanto, são fundamentais para a análise de desempenho de projetos
de software.
Monteiro (2008) apresenta um consolidado das principais ferramentas utilizadas para a
análise quantitativa de desempenho, dentre as quais se destacam as listadas no Quadro 2 abaixo.
Quadro 2 – Ferramentas para Gestão Quantitativa (adaptação de MONTEIRO, 2008)
Ferramenta Descrição Apresentação
Diagrama dedispersão
Este diagrama apresenta relacionamentos entre duasvariáveis ou características de um processo. A observaçãode padrões nos pontos do digrama sugere que as variáveisanalisadas são associadas, possivelmente em uma relação decausa-e-efeito. -
20,00
40,00
60,00
80,00
100,00
- 50,00 100,00 150,00 Q u a n t i d a d e d e d e f e i t o s
Tamanho
Quantidade de defeitos X
Tamanho
Histograma
Um histograma exibe os dados coletados do processo porfreqüência. Os valores observados do processo sãodistribuídos em determinados intervalos de mesmo tamanho(colunas). A altura das barras de um histograma éproporcional ao número de observações dentro do intervalo.Os histogramas são úteis, pois permitem analisar a taxa devariação de um processo.
0
1
2
3
4
5
6
0,00
to
0,08
0,08
to
0,16
0,16
to
0,24
0,24
to
0,32
0,32
to
0,40
0,40
to
0,48
0,48
to
0,56
0,56
to
0,64
0,64
to
0,72
0,72
to
0,80
0,80
to
0,88
0,88
to
0,96
0,96
to
1,04
1,04
to
1,12
1,12
to
1,20
Histograma
Gráfico debarras
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ãosomente freqüências como nos histogramas. Neste caso, alargura das colunas e barras é livre, e, juntamente comcores, sombras e textos, podem ser utilizadas paradiferenciar os dados do gráfico.
-
5,00
10,00
15,00
20,00
25,00
30,00
35,00
Defeitos x Dis ciplinas x Builds
Build 1
Build 2
Build 3
Build 4
Gráfico oudiagrama dePareto
Um Diagrama de Pareto é simplesmente a exibição defreqüências de determinado dado em ordem decrescente.Esta ferramenta é utilizada para analisar as ocorrências maiscomuns de um evento e priorizar as ações a serem tomadasno tratamento do processo.Diagramas de Pareto são conceitualmente relacionados coma Lei de Pareto, que defende que um número relativamentepequeno de causas é responsável pela produção da grandemaioria dos problemas ou defeitos.
0,325
0,055 0,0460,014 0,010 0,009 0,003 - -
0,00%
20,00%
40,00%
60,00%
80,00%
100,00%
-0,0500,1000,1500,2000,2500,3000,350
D e n s i d a d e d e d e f e i t o s
Densidade de defeitos (Pareto)
Gráfico oucarta deexecução
Um gráfico ou carta de execução exibe observaçõesindividuais de um processo no decorrer do tempo.Esta ferramenta pode ser utilizada para identificartendências ou mudanças no desempenho do processo.Um risco de utilizar simplesmente gráficos de execução é atendência de reagir às variações naturais do processo. 0,000
0,100
0,200
0,300
0,400
0,500
0,600
n ov /0 5 d ez/0 5 j an /0 6 fe v/ 06 m ar/ 06 a br/ 06 m ai /0 6 j un /0 6 j ul /0 6 a go /0 6 se t/ 0 6
IDC
Gráfico oucarta decontrole
Um gráfico de controle é basicamente um gráfico deexecução com o acréscimo de uma linha central e limites decontrole inferior e superior associados.Os limites de controle, definidos de acordo com cada tipo degráfico, permitem a organização acompanhar o desempenhodo processo e identificar as causas normais e especiais devariação.
0,000
0,100
0,200
0,300
0,400
0,500
0,600
0,700
n ov /0 5 d ez /0 5 j an /0 6 f ev /0 6 m ar /0 6 a br /0 6 m ai /0 6 j un /0 6 j ul /0 6 a go /0 6 s et /0 6
IDC (X)
IDC (X) LC LCS (+3 sigmas) + 2 sigmas
+ 1 sigma LCI (- 3 sigmas) - 2 sigmas - 1 sigma
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 5
55
2.8. Desafios na Definição de Indicadores em Projetos de Desenvolvimento de Software
Quando da elaboração de indicadores, a maioria das organizações acabam enfrentando
quase sempre os mesmos problemas (JONES, 1992):
Falta de visão do “todo”.
Gráficos que são coloridos, mas com pouco ou nenhum significado.
Indicadores que geram interpretação dúbia.
Inconsistência na definição de medidas e elementos de dados.
Indicadores fora de um contexto previamente definido.
Utilização de dados inconsistentes.
Falta de uma linha de base ou benchmark que possibilite a comparação de desempenho.
Falta de freqüência ou ineficiência das atividades de coleta e integração de dados.
Comparação ou previsão de resultados sem a garantia de um processo estável.
Coleta-se muitos dados, resultando em desperdício de esforço e redução da moral da
equipe.
Obtém-se medidas erradas, ambíguas ou inconsistentes, resultando em análise de dados
sem conclusões ou interpretações inválidas. Isto torna a mensuração inútil e muitas vezes
prejudicial.
As conseqüências desses problemas podem ser cruciais em um processo de medições. Por
exemplo, gráficos que aparentemente são “bonitos e coloridos” podem estar representandoinformações equivocadas e inconsistentes. Isso pode gerar conseqüências desastrosas no
processo de tomada de decisões em um projeto, apresentando uma perspectiva que não reflete a
real situação do contexto em análise.
Com o objetivo de definir um conjunto consistente de indicadores, o SEI (2004)
apresenta um guia e um conjunto de questões que a organização deve seguir:
Quais os objetivos a serem alcançados?
Qual o propósito de um determinado indicador?
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 5
56
O que você quer saber quando receber a informação?
Quem é o responsável?
Quem é o dono do indicador?
Quem é o responsável por medir a informação?
Quem é o usuário do indicador?
Como se coleta a informação?
O quanto consistentes são os dados?
O indicador está claramente definido?
Como o indicador é calculado?
Com qual freqüência o indicador deve ser reportado? Até quando o usuário deve receber
a informação do indicador?
Questões como essas são respondidas através da estrutura do template de indicadores
sugerido pelo SEI (2004). A utilização de templates serve como um guia que visa endereçar os
detalhes da infra-estrutura de medição de uma organização com o objetivo de estruturar um
programa consistente de medições e análises (Baumert e McWhinney, 1992). Assim é possível
obter os seguintes resultados:
Maior visibilidade do projeto.
Capacidade de melhor quantificar e qualificar decisões a serem tomadas.
Melhor planejamento, controle e monitoramento de projetos.
Melhor entendimento tanto do processo de desenvolvimento de software quanto ambiente
de desenvolvimento.
Identificação de áreas onde é necessário aprimoramento.
Aprimoramento da comunicação.
2.9. Estrutura de Template (modelo de documento) para Geração de Indicadores
Organizações normalmente não atingem por completo os benefícios de um programa de
medições devido a inconsistências no processo de construção de um programa de indicadores. O
SEI (2004) elaborou um template que visa auxiliar na elaboração de indicadores. Esse template
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 5
57
objetiva auxiliar organizações a definir indicadores consistentes e coesos, representando quem, o
quê, onde, quando, porque e como analisar e coletar medições.
O SEI (2004) identificou que a utilização de templates para geração de indicadores pode
ajudar organizações a melhorar os processos de medições no desenvolvimento de software. Os
indicadores acabam servindo como um aliado tático no processo de tomada de decições. As
informações geradas pelos indicadores fornecem um meio para o aprimoramento do desempenho
de projetos.
O Quadro 3 demonstra uma estrutura de template sugerida pelo SEI (2004) visando
elaborar um conjunto de indicadores.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 5
58
Quadro 3 – Estrutura de Template de Indicador (Adaptado do SEI, 2004)
Abaixo segue uma breve explanação a respeito dos objetivos de cada campo encontrado
no template:
Objetivo do indicador: a proposta de se ter o indicador
Questões: as questões/perguntas que o responsável pelo indicador está tentandoresponder
Gráfico: um display gráfico do indicador
Entradas: a lista de medidas requeridas para construir o indicador e suas definições
Algoritmo: a definição de um algoritmo utilizado na construção do indicador
Premissas: lista de premissas a respeito da organização, seus processos e modelos que
sejam relevantes para a coleta e utilização do indicador
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 6
59
Coleta de dados: Informações a respeito de como, quando, qual freqüência, por quem os
elementos de dados requeridos para a construção do indicador são coletados.
Divulgação das informações: Informações a respeito de quem é responsável por reportar
as informações, para quem e com qual freqüência.
Armazenamento: Informações a respeito do armazenamento, recuperação e segurança dos
dados.
Análise e Interpretação dos resultados: Informações a respeito de como analisar e
interpretar o indicador.
A estrutura sugerida no Quatro 3 permite que organizações possam adaptar o template às
suas necessidades, adicionando, modificando e excluindo campos no intuito de aprimorar a
definição de seus indicadores. O template é apenas um ponto de partida sugerido pelo SEI
(2004). Conceitos propostos pelo template do SEI serão utilizados e adaptados no processo
sugerido neste trabalho.
2.10. Indicadores para o Gerenciamento de Requisitos
A literatura apresenta alguns autores que exploraram a definição de indicadores para aGerência de requisitos (GOODMAN, 1993; HAZAN, 2003; LOCONSOLE, 2002; 2003; 2004;
2007, MONTEIRO, 2008). Porém, os estudos mais aprofundados foram apresentados por Hazan
(2003) e Loconsole (2002, 2003, 2004 e 2007).
Hazan (2003) propõe a criação de indicadores para a gerência de requisitos utilizando os
métodos GQM e PSM. A autora apresenta indicadores relacionados à estabilidade e
rastreabilidade dos requisitos. O objetivo da autora em criar indicadores para melhor controlar a
estabilidade dos requisitos visa possibilitar uma projeção antecipada das mudanças de requisitos,devido ao fato da indústria ter evidenciado que a instabilidade dos requisitos contribui
fortemente para os riscos de pressão excessiva do cronograma e de não aceitação do produto
final.
No que tange à elaboração de indicadores de rastreabilidade, a autora se baseia no fato de
que a rastreabilidade ajuda na identificação do tamanho da mudança solicitada, apontado todos
os artefatos impactados. Quando mudanças nos requisitos emergirem, uma análise de impactos
deve ser executada, visando verificar a viabilidade de implementação, bem como o esforço,custo e cronograma associados.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 6
60
Já Loconsole (2002, 2003, 2004, 2007) foca seus trabalhos na definição e validação de
indicadores para a gerência de requisitos. Seus trabalhos possuem ênfase em indicadores de
aprimoramento do controle da volatilidade dos requisitos. A autora se baseia na premissa de que
os requisitos mudam durante todo o processo de desenvolvimento do software, sendo importante
controlar e identificar tendências de mudanças em requisitos, permitindo assim uma maior
previsibilidade e controle dos projetos de desenvolvimento de software. Loconsole, assim como
Hazan, também utiliza o GQM como instrumento de geração dos indicadores. A Figura 10
abaixo apresenta um exemplo de gráfico de controle de volatilidade (adição, modificação e
deleção) dos requisitos no decorrer dos meses, o que permite identificar tendências ao logo do
tempo.
Figura 10 – Exemplo de gráfico de controle de volatilidade dos requisitos (LOCONSOLE, 2007)
As duas autoras citadas acima, apesar de terem explorado aspectos relacionados à geração
de métricas e indicadores para a gerência de requisitos utilizando os métodos GQM (BASILI,
CALDIERA e ROMBACH, 1992, 1994; SOLINGEN e BERGHOUT, 1999) e PSM (2008), não
apresentam grandes detalhes a respeito de como chegaram aos indicadores gerados, tendo como
foco principal em seus trabalhos a validação e aplicabilidade dos indicadores propostos. Também
nota-se certa carência nos trabalhos quanto a descrição do contexto organizacional em que as
métricas e indicadores foram criados, o que torna difícil replicar os indicadores propostos dentro
de outro contexto organizacional, pois organizações distintas apresentam diferentes realidades e
necessidades.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 6
61
2.11. Considerações Finais do Capítulo
A partir dos conceitos expostos neste referencial teórico é possível perceber a
importância da gerência de requisitos para o sucesso de projetos de desenvolvimento desoftware, assim como a importância de controles efetivos para projetos. A complexidade da
gestão de requisitos, dentro de projetos de software, requer que técnicas de gestão quantitativa
sejam aplicadas de forma a perceber objetivamente a situação do projeto, possibilitando maior
controle e previsibilidade para os tomadores de decisões.
Apesar de existirem modelos que auxiliem na definição de indicadores como o GQM,
GQ(i)M e PSM; todos eles são de certa forma genéricos. Por serem genéricos, muitas vezes
acabam exigindo profissionais com qualificação específica para este tipo de trabalho, visandoadaptá-los às necessidades de cada organização, o que acarreta maior investimento em tempo e
custos para uma correta compreensão e adaptação dos modelos. Um outro aspecto a ser
ressaltado é que devido ao fato das definições de objetivos, perguntas e indicadores (padrão em
todos os modelos) ficarem totalmente a critério das organizações, acaba-se gerando maior
margem para erros, seja por inexperiência dos profissionais envolvidos, falta de clareza do
processo ou dos objetivos da organização.
Para que organizações possam criar indicadores consistentes, com maior facilidade e
agilidade, é preciso um processo em que a geração de indicadores tenha como foco a gestão de
requisitos, trilhando assim um caminho que minimize as chances de erros na execução do
processo, apresentando clareza e facilidade para sua compreensão e utilização. Um processo que
apresente um conjunto de passos bem definidos e informações pré-definidas para que diferentes
organizações de TI possam utilizá-lo de acordo com suas características e necessidades.
O próximo capítulo mescla e complementa alguns dos conceitos apresentados neste
capítulo, buscando a definição de um processo específico para a geração de indicadores para uma
correta gestão de requisitos.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 6
62
3. MATERIAIS E MÉTODOS DE PESQUISA
Neste capítulo é apresentada a abordagem metodológica utilizada neste trabalho. A
suposição orientadora é que por meio de um processo detalhado para definição de indicadores
seria possível resolver o problema. Tal processo foi proposto e avaliado. Este capítulo apresenta
todas as etapas de pesquisa, descrevendo em especial as principais etapas de construção do
processo proposto.
3.1. Classificação da Pesquisa
Segundo Moresi (2004, p. 11-14, 66-68) uma pesquisa pode ser classificada quanto à sua
natureza, abordagem, fins e meios.
O presente trabalho tem por objetivo propor um processo para a criação de indicadores
para a gerência de requisitos para projetos de desenvolvimento de software. Portanto, a pesquisa
caracteriza-se como aplicada quanto à sua natureza, já que pretende gerar conhecimentos paraaplicações práticas, dirigidas à solução de um problema específico.
Quanto à abordagem utilizada, a pesquisa caracteriza-se como qualitativa, pois buscará
apresentar uma avaliação do processo proposto.
A pesquisa propõe 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, foi 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 da proposta de processo, foi realizada uma avaliação em campo do
processo proposto.
3.2. Fontes de Informações Utilizadas
A pesquisa inicial para este trabalho foi realizada nas seguintes fontes de referência, todas
de reconhecida credibilidade e completeza:
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 6
63
ISI Web of Knowledge – portal internacional contendo publicações de periódicos. É
acessada através do endereço http://apps.isiknowledge.com;
Computer Society Digital Library (CSDL) – produzida pela IEEE-Computer Society,
indexa todos os periódicos da CS, além da base de periódicos da ACM. Acessada através do
endereço http://www2.computer.org/ csdl;
Scirus – que indexa a base da Science Direct, acessada através do endereço
http://www.scirus.com.
A busca nessas fontes utilizou como parâmetro diversas combinações de expressões-
chave (em inglês). A Tabela 2 apresenta os resultados dessa pesquisa inicial, indicando a
quantidade de entradas identificadas em cada fonte para as expressões e suas combinações com
“E” lógico.
Tabela 2 - Fontes de Pesquisas
Expressões-chaveFontes
ISI CSDL Scirus
Software Project 13.422 >100 317.005
Requirement Management 14.850 >100 5.738
Indicadores >100.000 >100 4.235
Metrics >100.000 >100 1.139
Software Project
Requirement Management 55 >100 65
Indicator 11 58 9
Metrics 34 36 14
Software ProjectRequirement
Management
Indicator 2 3 0
Metrics 11 2 14
Measurement 5 2 6
O resultado da pesquisa inicial mostrou que existe grande número de publicações
tratando de temas isolados como projetos de software, gerência de requisitos, métricas para
projetos de software e indicadores.
Entretanto, quando esses temas se associam a quantidade de publicações se reduz
consideravelmente, sendo bastante pequena quando se trata de projetos de software associados a
indicadores e gerenciamento de requisitos.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 6
64
A segunda fase da pesquisa se baseou numa rápida avaliação dos títulos e resumos dos
trabalhos mais relevantes e próximos do tema pesquisado, tendo sido selecionados originalmente
45 textos para leitura mais detalhada.
A leitura desses textos apontou referências a outros que foram agregados à pesquisa.
Dessa fase resultou um total de 51 textos – artigos ou livros – dos quais foram selecionados
aqueles que compõem as referências bibliográficas deste trabalho.
A utilização das fontes bibliográficas listadas na tabela acima está detalhada nas seções
subseqüentes da etapa de revisão da literatura deste trabalho.
3.3. Etapas de Definição do Processo Proposto
O processo proposto foi batizado de Processo de Geração de Indicadores para a
Gestão de Requisitos – PGIGR. Os passos descritos neste capítulo ilustram desde a motivação
em se gerar o PGIGR até a descrição dos passos envolvidos para a definição de indicadores.
Nesse contexto, foram realizados no desenvolvimento desta pesquisa oito passos para
criar o PGIGR, resumidos graficamente na Figura 11 a seguir e detalhados nas seções
subsequentes.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 6
65
Figura 11 – Processo de definição do PGIGR
As setas sólidas apresentadas na figura acima demonstram a sequência lógica da
pesquisa. As setas pontilhadas apresentam o trabalho iterativo, incremental e de refinamento que
se deu durante a definição do processo.
O desenvolvimento do PGIGR envolveu duas grandes etapas: a revisão da literatura e a
definição do processo PGIGR em si. A análise da literatura é composta por cinco passos, desde a
análise de problemas relacionados a projetos de desenvolvimento de software até a análise de
métricas e indicadores existentes para a gerência de requisitos.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 6
66
O primeiro passo foi realizar uma ampla revisão da literatura para identificar as
principais causas de fracasso em projetos de desenvolvimento de software. A partir da literatura
pesquisada e apresentada na seção de revisão bibliográfica deste trabalho, a gerência de
requisitos foi selecionada como foco da pesquisa. A razão da gerência de requisitos ter sido
selecionada é devido ao fato dela exercer um papel central no desenvolvimento de software, no
qual problemas no gerenciamento de requisitos acabam sendo propagados para todo o restante do
processo de desenvolvimento de software. Pesquisas mostram também que das 10 principais
causas de fracasso em projetos de desenvolvimento de software, as três primeiras estão
relacionadas à gestão de requisitos (CHAOS REPORT, 2007; EASTERBROOK, 2004).
A partir da seleção da gestão de requisitos como foco para a geração de indicadores, o
segundo passo da pesquisa foi estudar as principais características e problemas enfrentados na
gestão de requisitos em projetos de desenvolvimento de software.
Uma vez analisadas as principais características e problemas da gestão de requisitos, o
terceiro passo ficou responsável por analisar o contexto atual da utilização de medições e
indicadores em projetos de desenvolvimento de software, assim como apresentar as principais
necessidades e benefícios em se utilizar ferramentas de controle quantitativo para o
aprimoramento do controle e tomada de decisões.
Concluída a análise da situação dos projetos de desenvolvimento de software quanto aouso de métodos de controle quantitativos, o quarto passo encarregou-se de avaliar os principais
métodos e processos existentes na literatura para a geração de indicadores, visando uma
adaptação para as organizações de TI e mais especificamente para a gerência de requisitos de
projetos de desenvolvimento de software.
Uma vez analisados os métodos e processos existentes para a geração de métricas e
indicadores, no quinto passo foram pesquisados trabalhos acadêmicos que apresentam
indicadores e métricas para aprimorar a gestão de requisitos.A segunda etapa da pesquisa, a etapa de definição do processo PGIGR, envolveu três
passos, desde a definição de características desejadas para o processo PGIGR até o detalhamento
das atividades do processo.
O sexto passo da pesquisa se encarregou de definir um conjunto de características que o
PGIGR deveria possuir para que fosse possível gerar indicadores para a gerência de requisitos de
forma objetiva, eficiente e eficaz.
A partir das características definidas no passo anterior, o sétimo passo ficou encarregado
de elaborar uma estrutura macro do PGIGR, onde foram definidos cinco subprocessos para uma
correta gestão de indicadores para a gerência de requisitos.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 6
67
No oitavo e último passo da pesquisa foram definidas e detalhadas todas as atividades
contidas em cada um dos cinco subprocessos definidos no passo anterior.
Nas seções seguintes será apresentado detalhadamente cada um dos passos supracitados.
3.4. Etapa de Revisão da Literatura
Conforme apresentado na Figura 11 anteriormente, a etapa de revisão da literatura deste
trabalho foi subdividida em cinco passos. Todos eles estão detalhados abaixo.
3.4.1. Passo: Revisão da Literatura Referente a Sucesso e Fracasso em Projetos de Software
O início do trabalho de pesquisa teve o enfoque de avaliar a situação atual do mercado no
que tange os projetos de desenvolvimento de software. Com esse foco foi feito um estudo
bibliográfico a respeito de definições de projeto e a importância de gerenciar seus riscos. A
definição de projeto adotado por esta pesquisa é derivada do PMI (2004), no qual projeto é
definido como “um esforço temporário empreendido para criar um produto, serviço ou resultado
exclusivo.”
Também foram pesquisadas bibliografias que definem o conceito de sucesso e optou-se
por adotar o conceito apresentado pelo PMBOK (PMI, 2004), onde projetos são consideradosbem sucedidos quando são finalizados dentro do prazo, custos, qualidade e escopo previstos.
Posteriormente foi feito um diagnóstico do nível de sucesso em projetos de TI em âmbito
mundial. Para isso foi utilizado como base o Relatório do Chaos do Standish Group (2007).
Nesse estudo, que tem abrangência e reconhecimento mundial, os dados mostram que os índices
de insucesso e dificuldades enfrentados em projetos de software são altíssimos, demonstrando
que 66% dos projetos fracassam ou não atingem os seus objetivos por completo.
Nesse mesmo estudo foram mapeadas as dez principais causas de fracasso em projetos desoftware, estando as três primeiras diretamente relacionadas à gestão de requisitos, quais sejam:
falta de envolvimento dos usuários, requisitos incompletos e constante alteração nos requisitos.
Baseando-se no princípio 80:20 de Pareto, que afirma que para muitos fenômenos, 80%
das consequências advém de 20% das causas e sabendo que a gerência de requisitos se posiciona
como um dos pilares para o sucesso de projetos de desenvolvimento de software, este estudo
selecionou a mesma como foco de aprimoramento, visando possibilitar meios para aprimorar a
gestão dos requisitos e consequentemente aumentar as chances de sucesso dos projetos.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 6
68
A partir da literatura pesquisada a respeito de problemas relacionados a projetos de TI,
foi feito um estudo bibliográfico sobre a qualidade de software com o enfoque em gerência de
requisitos. Nele foram analisados os principais problemas vinculados à baixa qualidade de
software no mercado atual.
3.4.2. Passo: Estudo da Teoria de Base sobre Gestão de Requisitos
Com o enfoque dado na gestão de requisitos, foi feito uma análise da literatura buscando
melhor entender as atividades e problemas envolvidos na gestão de requisitos. Foi feito um
estudo de conceitos relacionados à engenharia de requisitos, assim como um mapeamento das
principais atividades envolvidas.
Segundo conceito apresentado por Pressman (2004), gerenciamento de requisitos é o
conjunto de atividades que auxiliam o time de projeto na identificação, controle e
acompanhamento dos requisitos e suas mudanças durante toda a duração do projeto. A
importância da gerência de requisitos fica clara quando analisados o CMMI (2001) e MPS.BR
(SOFTEX, 2007), no qual ela é um processo chave (KPA) em ambos e aparece nos níveis mais
fundamentais. No CMMI (2001) encontra-se no nível 2 de maturidade e no MPS.BR (SOFTEX,
2007) no nível G.
Para cada um desses processos foram mapeadas as atividades relacionadas à gerência de
requisitos. Após o levantamento das atividades envolvidas na gerência de requisitos, foi feito um
estudo para identificar os principais problemas e riscos relacionados à gestão de requisitos. O
intuito foi identificar os principais problemas para que a geração de indicadores tivesse um
melhor direcionamento e foco.
3.4.3. Passo: Estudo da Teoria de Base sobre Medição em Projetos de Software
Tendo em vista que organizações estão cada vez mais preocupadas em aprimorar seus
controles e melhor aferir os resultados de seus projetos de desenvolvimento de software, a
utilização de dados quantitativos vem sendo cada vez mais adotada. Neste passo da pesquisa
foram analisados trabalhos de conceituação de medição. A utilização de dados objetivos para
apoiar as decisões em todos os níveis visa apoiar o gerenciamento e o processo de tomada de
decisão através de indicadores, que tem como propósito ser uma ferramenta de controle emonitoramento.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 7
69
Foi constado que um dos aspectos importantes sobre medições e indicadores é que eles
trazem um senso comum para um determinado assunto. A utilização de medições faz com que
seja possível avaliar o processo de desenvolvimento de software, possibilitando identificar
aspectos que estão fora dos resultados esperados, proporcionando a possibilidade de ajustes.
Dentro do contexto de medição é encontrado o conceito de indicador. Existem algumas
definições para indicadores em ISO/IEC (2002, p. 22), Mcgarry (2002), SEI (2004, p. 1) e GQM
(Basili, Caldiera e Rombach, 2002). Para este trabalho foi adotado o conceito de indicador como
sendo uma medida ou uma combinação de medidas, normalmente apresentado na forma gráfica,
que provê entendimento a respeito de uma questão ou conceito de software. Os indicadores são a
base para a análise e tomada de decisão, portanto são eles que devem ser apresentados aos
tomadores de decisão.
Uma vez analisados e contextualizados os conceitos de medição e indicador que irão ser
utilizados neste trabalho, foram feitos estudos a respeito dos objetivos em se utilizar medições
em projetos de desenvolvimento de software. Nesta etapa foram pesquisados diferentes autores
(GOODMAN, 1993; COSTELLO e LIU, 1995; HAZAN, 1999; FENTON, PFLEEGER, 1998;
EVERALD, 1998; MECGARRY, 2001; LOCONSOLE, 2002; 2003; 2004; 2007) que
apresentam várias razões e motivos para se medir o processo de desenvolvimento de software.
Pode-se resumir que medições em projetos de desenvolvimento de software permitem um
melhor entendimento do ambiente de desenvolvimento e promovem informações detalhadas
sobre o projeto. Métricas são utilizadas no intuito de melhor prever, gerenciar e controlar
projetos de desenvolvimento de software.
3.4.4. Passo: Estudo da Teoria de Base sobre Métodos para Definição de Indicadores
Uma vez contextualizada a necessidade e importância da utilização de métricas e
indicadores em projetos de desenvolvimento de software, este passo da pesquisa encarregou-se
de analisar os principais modelos de geração de métricas e indicadores existentes na literatura.
Nele foram identificados e detalhados os três principais modelos existentes atualmente na
literatura: GQM, GQ(i)M e PSM. Como no PGIGR foram utilizados (mesclados) conceitos dos
três métodos, todos os três métodos foram detalhados no referencial teórico deste trabalho,
visando apresentar suas características.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 7
70
3.4.5. Passo: Estudo da Teoria de Base sobre Métricas e Indicadores Existentes para a
Gerência de Requisitos
Neste passo da pesquisa foram analisados trabalhos acadêmicos que abordam aspectos
relacionados à geração de medições e indicadores especificamente para a gerência de requisitos.
Duas autoras abordam o assunto com maior veemência e foco: Hazan e Loconsole.
Hazan (2002, 2003) propõe a criação de indicadores para a gerência de requisitos
utilizando os métodos GQM e PSM. A autora apresenta indicadores relacionados à estabilidade e
rastreabilidade dos requisitos, baseando-se em rastreabilidade entre os requisitos e a aplicação de
métrica de tamanho de software – pontos de função.
Loconsole (2002, 2003, 2004, 2007) foca seus trabalhos no aprimoramento do controle
da volatilidade dos requisitos. A autora se baseia na premissa de que os requisitos mudam
durante todo o processo de desenvolvimento do software, sendo importante controlar e
identificar tendências de mudanças em requisitos, permitindo assim uma maior previsibilidade
de mudanças nos projetos.
As duas autoras citadas, apesar de terem explorado aspectos relacionados à geração de
métricas e indicadores para a gerência de requisitos utilizando os métodos GQM (BASILI,CALDIERA e ROMBACH, 2002) e PSM (2008), não entram em detalhes a respeito de como
chegaram aos indicadores gerados, tendo como foco principal em seus trabalhos a validação e
aplicabilidade dos indicadores propostos. Também nota-se certa carência nos trabalhos no que
tange a descrição do contexto organizacional em que as métricas e os indicadores foram criados
e aplicados. Isso acaba tornando difícil replicar os indicadores propostos dentro de outro
contexto organizacional, pois organizações distintas apresentam diferentes realidades e
necessidades.
3.5. Etapa de Definição do Processo PGIGR
Após conclusão da etapa de revisão da literatura, iniciou-se a etapa de definição do
processo PGIGR. Conforme apresentado na Figura 11, esta etapa da pesquisa foi subdividida em
três passos, detalhados abaixo.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 7
71
3.5.1. Passo: Definição das Características Desejadas para o Processo
Após análise dos principais problemas e limitações quanto a criação e utilização de
métodos de medição e indicadores em projetos de desenvolvimento de software, este passo da
pesquisa utilizou o método GQM para demonstrar uma síntese dos objetivos do PGIGR,
conforme pode ser observado na Tabela 14 do APÊNDICE A.
À luz dos objetivos macro traçados, foi definido um conjunto de características desejadas
para o PGIGR, conforme quadro a seguir.
Quadro 4 - Características Definidas para o Processo PGIGR
Características Definidas para o Processo PGIGR1. O processo deve ser de fácil compreensão (CRC01)
2. O processo deve ser de fácil utilização (CRC02)
3. O processo deve agilizar a criação de indicadores para a gerência de requisitos. (CRC03)
4. O processo deve apresentar características mínimas necessárias para a geração de indicadores consistentes
para a gerência de requisitos. (CRC04)
5. O processo deve permitir que organizações criem indicadores para a gerência de requisitos com o foco em
suas necessidades. (CRC05)
6. O processo deve apresentar um conjunto prévio das principais necessidades da gerência de requisitos.
(CRC06)
7. O processo deve apresentar uma forma de rastrear um objetivo até os indicadores, facilitando assim a
visibilidade e análise de aferição de resultados. (CRC07)
8. O processo deve apresentar sugestões de indicadores específicos para a gerência de requisitos, visando
facilitar a compreensão de seus usuários. (CRC08)
9. O processo deve apresentar um template que possa ser utilizado para facilitar a criação de um indicador,
apresentando todas as informações necessárias. (CRC09)
10. O processo deve ser simples o suficiente ao ponto de não requerer que sua utilização necessite de um
especialista em métricas (CRC10)
11. O processo deve proporcionar uma evolução incremental no que tange a utilização de indicadores para a
gerência de requisitos (CRC11)
A partir das características traçadas acima, deu-se prosseguimento na definição estrutural
do processo PGIGR.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 7
72
3.5.2. Passo: Definição da Estrutura Geral do Processo PGIGR
Neste passo foram definidos cinco subsuprocessos para compor o PGIGR. Os cinco
subprocessos definidos visam direcionar a geração de indicadores para a gerência de requisitos.
1. Categorizar o Processo de Software da organização de TI2. Definir Dimensão Foco3. Definir Objetivos (Metas)4. Definir Perguntas5. Definir Indicadores
A interação e sequência entre cada um dos subprocessos pode ser melhor visualizada na
Figura 12 abaixo.
Figura 12 – Subprocessos do PGIGR
O propósito de cada um dos subprocessos definidos para o PGIGR foi baseado naconsolidação de conceitos consolidados a partir do GQM, GQ(i)M e PSM, detalhados durante a
fase de revisão bibliográfica deste trabalho. O intuito dos subprocessos é guiar o processo de
criação de indicadores de forma a facilitar a visibilidade do sequenciamento e relacionamento
dos subprocessos. As setas sólidas demonstram a sequência e interação entre os subprocessos. O
detalhamento de cada um dos subprocessos pode ser visto no APÊNDICE A.
Para atendimento de cada subprocesso do PGIGR, foram definidos conjuntos de
atividades. Nas atividades estão todos os detalhes para a sua execução. Os subprocessos e as suas
atividades podem ser visualizados na Tabela 3 a seguir.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 7
73
Tabela 3 – Subprocesso e as Atividades do PGIGR
Processo PGIGR
Subprocessos Atividades
Categorizar o processo de software da Organização de TI
Definir os Envolvidos
Definir Categoria
Definir Foco dos IndicadoresDefinir a Dimensão Foco para a geração de
indicadores.
Definir Objetivos (Metas)
Selecionar objetivos pré-definidos para Gestão
de Requisitos.
Criar Objetivo(s)
Definir Perguntas (Questões)Selecionar perguntas pré-definidas
Criar Pergunta(s)
Definir Indicadores
Selecionar Indicadores pré-definidos
Descrever o Indicador
Estruturar o Indicador
Divulgar/aprimorar o Indicador
Neste passo também foram detalhados os principais papéis utilizados para a correta
utilização do PGIGR. Essas atribuições foram baseadas no Rational Unified Process – RUP
(1998). A definição dos papéis e suas atribuições podem ser visualizadas na Tabela 16 do
APÊNDICE A.
3.5.3. Passo: Definição das Atividades do Processo
Cada uma das atividades contida nos subprocessos do PGIGR (Tabela 3) foi detalhada
utilizando o template de atividades proposto pela SOFTEX (2007), conforme apresentado na
Tabela 17 do APÊNDICE A.
O detalhamento da criação dos subprocessos e suas respectivas atividades está descrito
nas seções subsequentes.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 7
74
3.5.3.1. Subprocesso: Categorizar o Processo de Software da organização de TI
Este subprocesso foi elaborado com o intuito de proporcionar uma categorização do
processo de desenvolvimento de software da organização de TI avaliando algumas características
que são fundamentais para que a criação de indicadores seja feita de forma correta.
Para a elaboração deste subprocesso foram utilizados conceitos propostos por Solingen e
Berghout (1999, p. 21), visando complementar o processo GQM. Segundo os autores, a medição
em processos de software tem como objetivo prover informações que podem ser aplicadas em
três diferentes aspectos:
1. Adquirir melhor entendimento das necessidades.
2. Permitir maior controle do processo e produtos gerados.
3. Permitir o aprimoramento do processo existente.
O PGIGR adaptou esse conceito proposto por Solingen e Berghout (1999) com o intuito
de avaliar alguns aspectos (características) do processo de software das organizações de TI antes
de definir os indicadores. O objetivo é melhor direcionar a geração de indicadores para a gestão
de requisitos, de acordo com algumas características do processo de desenvolvimento desoftware da organização de TI, pois, segundo Jones (1992), um dos grandes problemas na
definição de indicadores é falta de uma contextualização da situação atual da organização. Para
isso, o PGIGR propõe quatro categorias de classificação: Inicial, Entendimento, Controle e
Aprimoramento, conforme pode ser visualizado na Figura 13.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 7
75
Figura 13 - Categorias de Classificação do Processo de Software da Organização de TI
(Adaptada de Solingen e Berghout, 1999)
A estrutura proposta visa permitir um melhor entendimento do processo de
desenvolvimento de software da organização para então direcionar a geração de indicadores.
Como exemplo, pode-se dizer que não adianta uma organização querer definir indicadores para
aprimorar o seu processo de gerência de requisitos se ela não possui o mínimo de organização e
infra-estrutura necessárias para tal. Isso provavelmente acarretaria na geração de informações
ambíguas e inconsistentes. Ela também possibilita uma evolução gradual da organização quanto
a utilização de indicadores para uma correta gestão de requisitos.Esta etapa do processo visa evitar com que a organização defina um conjunto de
indicadores que estão além do que o seu processo atual e/ou infra-estrutura podem suportar.
Este subprocesso é composto por duas atividades: Definir os Envolvidos e Definir
Categoria. Na Figura 14 é apresentado o diagrama do subprocesso contendo as atividades,
artefatos e responsabilidades. O processo (APÊNDICE A) apresenta o detalhamento de cada uma
das atividades.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 7
76
Figura 14 - Subprocesso para Categorizar o Processo de Software da Organização de TI
O conceito, empregado nesta pesquisa para de classificar o processo de desenvolvimentode software da organização de TI, baseou-se em áreas de processo do CMMI (2001) e do
MPS.BR (SOFTEX, 2007). Para cada uma das categorias foram definidas características
baseadas em práticas que são empregadas em ambos os processos supracitados e que se
mostraram importantes para a geração de indicadores para a gerência de requisitos. As
características definidas para cada categoria podem ser visualizadas a seguir na Matriz de
Categorização - Tabela 4.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 7
77
Tabela 4 - Matriz de Categorização do processo de software da Organização de TI
CATEGORIZAR O PROCESSO DE SOFTWARE DA ORGANIZAÇÃO DE TI
1º - INICIAL 2º - ENTENDIMENTO 3º - CONTROLE 4º - APRIMORAMENTO
A organização não possui osrequisitosnecessários para seenquadrar nacategoriaEntendimento
A organização possuipráticas de gerência deprojetos dedesenvolvimento desoftware; eA organização possuiferramenta para controlede atividades dos
projetos. (Ex.: MicrosoftProject); eA organização possuipráticas de gerência derequisitos; eA organização utilizapráticas e ferramentasde controle de versão para os artefatos derequisitos; eA organização possuipráticas de medição detamanho de software.
A organização possuiuma base histórica demétricas e indicadores;eA organização possuium processopadronizado degerência de requisitos;
eA organização possuium processopadronizado degerência de projetos
A organização possui um baseline de desempenho do processo de requisitos;
Os indicadores gerados na categoria Entendimento têm o intuito de dar uma visibilidade
e maior entendimento da situação atual dos projetos de desenvolvimento de software da
organização no que tange à gestão de requisitos. Para que a organização ingresse nessa categoria,
foram coletadas algumas práticas das áreas de processo do nível 2 de maturidade (Gerenciado)
do CMMI (2001) e do nível G (Parcialmente Gerenciado) do MPS.BR, visando garantir a
existência de um mínimo de organização para sustentar um processo consistente de geração e
manutenção de indicadores para gerenciar requisitos. As características definidas para a categoriaEntendimento foram:
1. A organização possui práticas de gerência de projetos de desenvolvimento de
software
Esta característica é necessária para criar insumos para fonte de coleta de várias
medidas básicas e derivadas que são utilizadas nos indicadores propostos. Visa-se
constatar evidências que demonstrem que a organização possui práticas de
gerência de projetos no seu processo de desenvolvimento de software. Ela se
baseia em práticas da área de processo de Gerência de Projetos contida no nível 2
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 7
78
de maturidade do CMMI (2001) e do nível G (Parcialmente Gerenciado) do
MPS.BR (SOFTEX, 2007).
2. A organização de TI possui ferramenta para controle de atividades dos projetos (Ex.:
cronograma)
Esta característica objetiva constatar evidências de utilização de uma ferramenta
de controle de atividades para gerenciar projetos de desenvolvimento de software.
Esta característica é necessária porque a ferramenta de controle de atividades é a
fonte de coleta de várias medidas básicas e derivadas que são utilizadas nos
indicadores propostos. Ela se baseia em práticas da área de processo de Gerência
de Projetos contida no nível 2 (Gerenciado) de maturidade do CMMI (2001) e donível G (Parcialmente Gerenciado) do MPS.BR (SOFTEX, 2007). Um dos
resultados esperados pelo MPS.BR neste nível é o orçamento e o cronograma do
projeto, no qual marcos e/ou pontos de controle são estabelecidos e mantidos
(GPR5).
3. A organização possui práticas de gerência de requisitos
Esta característica é necessária por quanto é preciso ter atividades de requisitos
planejadas, pois elas servirão de insumo para coleta de medidas básicas do
processo de requisitos. Visa-se constatar evidências da existência de práticas de
gerência de requisitos nos projetos de desenvolvimento de software. Esta
característica está embasada em práticas da área de processo de Gerência de
Requisitos, contida no nível 2 (Gerenciado) de maturidade do CMMI (2001) e no
nível G (Parcialmente Gerenciado) do MPS.BR (SOFTEX, 2007). O propósito do
processo Gerência de Requisitos é gerenciar os requisitos dos produtos e
componentes do produto do projeto e identificar inconsistências entre osrequisitos, os planos do projeto e os produtos de trabalho do projeto.
4. A organização utiliza práticas e ferramentas de controle de versão para os artefatos de
requisitos
Esta característica é necessária porque vários indicadores utilizam o quantitativo
de alterações em artefatos de requisitos como medida derivada, o que tornaria
praticamente inviável a coleta dessas informações sem uma ferramenta adequada
de controle de versões. Aqui visa-se constatar evidências da utilização de uma
ferramenta e práticas de controle de versão nos projetos de desenvolvimento de
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 8
79
software. Esta característica está embasada em práticas da área de processo de
Gerência de Configuração contida no nível 2 (Gerenciado) de maturidade do
CMMI (2001) e no nível F (Gerenciado) do MPS.BR (SOFTEX, 2007). O nível F
do MPS.BR tem como uma das áreas de processo a Gerência de Configuração. O
propósito do processo de Gerência de Configuração é estabelecer e manter a
integridade de todos os produtos de trabalho de um processo ou projeto e
disponibilizá-los a todos os envolvidos.
5. A organização possui práticas de medição de tamanho de software
Foi constatado que alguns indicadores ficam muito vagos e ineficientes caso não
tenham como medida derivada um indicativo de tamanho do software. Visa-seconstatar evidências da utilização de técnicas de mensuração de tamanho do
software nos projetos de desenvolvimento de software. Esta característica está
embasada em prática da área de processo de Medição contida no nível 2 de
maturidade (Gerenciado) do CMMI (2001) e no nível F (Gerenciado) do MPS.BR
(SOFTEX, 2007). O propósito do processo Medição é coletar, analisar e relatar os
dados relativos aos produtos desenvolvidos e aos processos implementados na
organização e em seus projetos, de forma a apoiar os objetivos organizacionais.
Caso a organização não possua todas as características listadas acima para ingressar na
categoria de Entendimento (segunda), o PGIGR sugere que a organização ajuste o seu processo
de desenvolvimento de software para atendê-las, antes de ingressar na categoria, ficando, a
princípio, na categoria Inicial (primeira), conforme representado na Figura 13 e Tabela 4 acima.
Isso porque as características definidas como necessárias pelo PGIGR objetivam avaliar a
existência de um conjunto mínimo de organização e padronização para que haja fontes para uma
correta coleta de medidas básicas e derivadas, que são insumos fundamentais para que os
indicadores propostos possam ser gerados de forma consistente.
Vale ressaltar que o fato da organização não possuir todas as características exigidas pela
categoria Entendimento não significa que ela não conseguirá gerar alguns indicadores propostos.
Talvez seja possível gerar alguns indicadores, porém a organização corre o risco de despender
um esforço muito grande para gerá-los e mantê-los, além de correr o risco de gerar informações
inconsistentes e ambíguas.
Os indicadores gerados na Categoria Controle têm o intuito de serem utilizados durante a
execução do projeto, permitindo que o gerente tenha maior controle do projeto e possa tomar
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 8
80
medidas corretivas durante a execução do mesmo. Para que a organização ingresse nessa
categoria, foram utilizados conceitos do nível 3 de maturidade (Definido) do CMMI (2001) e do
nível E (Parcialmente Definido) do MPS.BR (SOFTEX, 2007). Neste ponto, o PGIGR procura
aferir se a organização possui um repositório com medidas históricas coletadas a partir da
execução de projetos na categoria Entendimento, assim como a padronização de alguns
processos. As características definidas para esta categoria Controle são:
1. A organização possui uma base histórica (repositório de medidas) de métricas eindicadores
O intuito é que haja um conjunto de medidas previamente coletadas durante a
categoria de Entendimento para que se possa gerar dados comparativos entre
projetos que apresentam semelhanças, visando gerar gráficos de controle comlimites superior e, conforme exemplos apresentados no Quadro 2 do referencial
teórico. Esta característica está embasada na área de processo de gerência de
projetos do MPS.BR (SOFTEX, 2007). Um dos produtos esperados da gerência
de projetos para o nível E (Parcialmente Definido) é a definição de um repositório
de medidas da organização (DFP6). O repositório de medidas da organização
deve ser, continuamente, atualizado com dados dos projetos executados na
categoria Entendimento, para que, na categoria de Controle, dados históricos
sejam utilizados em novos projetos. Como critério de avaliação visando migrar
para a categoria Controle do PGIGR, sugere-se um quantitativo de métricas de
gerência de requisitos coletadas a partir de três projetos similares (mesma
tecnologia, mesmo método de desenvolvimento e complexidade) e,
preferencialmente, já concluídos.
2. A organização possui um processo padronizado de gerência de requisitos
O PGIGR propõe que a organização tenha um processo padrão para gerenciar
requisitos, antes de ingressar na categoria de Controle. Isso se faz necessário para
que a organização colete medidas básicas e derivadas que sejam equivalentes, o
que possibilita uma correta e efetiva comparação entre os indicadores gerados, já
que os mesmo são resultado de um processo equivalente. Esta característica está
embasada no nível E (Parcialmente Definido) de maturidade do MPS.BR
(SOFTEX, 2007). A implementação do nível E numa organização tem como foco
principal a padronização dos processos da organização, através da definição de
processos padrão.
3. A organização possui um processo padronizado de gerência de projetos
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 8
81
O PGIGR propõe que a organização tenha um processo padrão de gerenciamento
de projetos antes de ingressar na categoria de Controle. Isso se faz necessário para
que a organização colete medidas básicas e derivadas que sejam equivalentes, o
que possibilita uma efetiva comparação entre os indicadores gerados na categoria
controle, já que os mesmo são resultado de um processo equivalente. Esta
característica está embasada no nível E (Parcialmente Definido) de maturidade do
MPS.BR (SOFTEX, 2007). Assim como para a gerência de requisitos, é
importante que a organização também padronize o seu processo de gerência de
projetos.
O objetivo da categoria Aprimoramento é permitir que uma organização avalie a
evolução da gestão de requisitos a partir de aprimoramentos realizados no processo de
desenvolvimento de software. Os indicadores gerados nesta categoria darão uma visão do
comportamento do processo antes e depois das medidas de aprimoramento. Isso sugere que esses
indicadores deverão ser avaliados após a conclusão dos projetos.
Segundo KULPA e JOHNSON (2004), o objetivo dos modelos de desempenho é permitir
a previsão de desempenho futuro dos processos a partir de outros atributos do processo ou
produtos. Estes modelos descrevem relacionamentos entre atributos do processo e produtos de
trabalho. Modelos de desempenho são utilizados principalmente nas estimativas que servem de
base para o planejamento e na monitoração dos projetos.
Os conceitos empregados nesta categoria foram extraídos do nível 4 de maturidade
(Gerenciado Quantitativamente) do CMMI (2001) e nível B (Gerenciado Quantitativamente) do
MPS.BR. Um dos produtos esperados pelo nível B (Gerenciado Quantitativamente) do MSP.BR
é a utilização dos resultados históricos do seu desempenho (baseline). Neste ponto, o PGIGR
procura aferir se há um baseline com a qual o desempenho dos projetos atuais pode sercomparado. A característica definida para a categoria Aprimoramento é:
1. A organização possui baseline de desempenho do processo de requisitos
O PGIGR sugere que a organização tenha aproximadamente 20 medições distintas
dos indicadores em seu baseline, antes de passar para a categoria de
Aprimoramento. Isso permitirá que alterações feitas no processo possam ser
aferidas e comparações estatísticas possam ser feitas a partir de medidas coletadas
na categoria de Controle e armazenadas. Esta característica está embasada em um
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 8
82
dos produtos esperados pelo nível B (Gerenciado Quantitativamente) do MPS.BR
(SOFTEX, 2007).
Para facilitar a visualização do processo de categorização da organização, o PGIGR
apresenta a Figura 24 do APÊNDICE A. Trata-se de uma espécie de fluxograma, onde é possível
ter uma visão macro da sequência das etapas de categorização do processo de desenvolvimento
de software da organização de TI pode ser melhor visualizada.
3.5.3.2. Subprocesso: Definir Foco dos Indicadores
Esse subprocesso foi criado com o intuito de direcionar a organização para aspectos
determinantes no que tange a criação de indicadores. O PGIGR adaptou conceitos propostos por
Solingen e Berghout (1999, p. 11 - 17), no qual os autores indicam que a definição de objetivo
para o aprimoramento do processo de desenvolvimento de software através de medições pode
possuir quatro vertentes distintas: risco, custo, tempo e qualidade.
Partindo desse princípio, o PGIGR adaptou a ideia original e criou o conceito de
dimensões foco (Figura 15), com o intuito de melhor direcionar o foco da geração de
indicadores naquilo que a organização considera mais relevante, de acordo com suas principais
necessidades e características.
Figura 15 - Quatro Dimensões Foco para a geração de indicadores (Adaptação de Solingen e Berghout, 1999)
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 8
83
O PGIGR propõe que a organização deve avaliar suas características, necessidades e
questionar o que é mais prioritário para ela no que tange a gestão de requisitos, de acordo com a
sua categorização (classificação), definida no subprocesso anterior.
Para este subprocesso foi definida uma única atividade: Definir Dimensão Foco. Na
Figura 16 é apresentado o diagrama do subprocesso com a atividade, artefatos e
responsabilidades. No processo PGIGR (APÊNDICE A) é apresentado o detalhamento da
atividade.
Figura 16 - Subprocesso para Definir Dimensão Foco
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 8
84
Com o intuito de facilitar a análise e definição da escolha da dimensão foco que será
utilizada, o PGIGR apresenta uma matriz contendo cada uma das dimensões foco e uma
descrição para cada uma das categorias, conforme apresentado na Tabela 5. Isso facilita para os
usuários do processo, pois eles conseguem mais fácil e rapidamente definir qual deve ser o foco
de seus indicadores, de acordo com aquilo que for definido como prioritário pela organização.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 8
85
Tabela 5 - Matriz contendo as dimensões foco e descrição para cada uma das categorias
Dimensão Foco Categoria Descrição
R I S C O
EntendimentoA organização necessita melhor entender os riscos relacionados à
gerência de requisitos nos projetos de software.
ControleA organização necessita melhor monitorar os riscos relacionados à
gerência de requisitos nos projetos de software.
AprimoramentoA organização deseja minimizar os riscos relacionados à gerência de
requisitos nos projetos de software.
T E
M P O
EntendimentoA organização necessita melhor entender o tempo/esforço despendido
nas atividades de requisitos em projetos de software.
ControleA organização necessita melhor monitorar o tempo/esforço despendido
nas atividades de requisitos em projetos de software.
AprimoramentoA organização deseja reduzir o tempo/esforço despendido nas
atividades de requisitos em projetos de software.
C U S T O
EntendimentoA organização necessita melhor entender os custos despendidos nas
atividades de requisitos em projetos de software.
ControleA organização necessita melhor monitorar os custos despendidos nas
atividades de requisitos em projetos de software.
AprimoramentoA organização deseja reduzir os custos despendidos nas atividades de
requisitos em projetos de software.
Q U A L I D A D
E
Entendimento
A organização necessita melhor entender a qualidade dos produtos
gerados pelas atividades de requisitos em projetos de software.
ControleA organização necessita melhor monitorar a qualidade dos produtos
gerados pelas atividades de requisitos em projetos de software.
AprimoramentoA organização deseja aprimorar a qualidade dos produtos gerados
pelas atividades de requisitos em projetos de software.
3.5.3.3. Subprocesso: Definir Objetivos (Metas)
A criação desse subprocesso visa definir os objetivos (metas) para a dimensão foco
previamente selecionada, de acordo com a categorização da organização de TI.
Para este subprocesso foram criadas duas atividades: Selecionar Objetivo(s) pré-
definido(s) para a Gerência de Requisitos e Criar Objetivo(s). Na Figura 17 é apresentado o
diagrama do subprocesso com as atividades, artefatos e responsabilidades. O APÊNDICE A
apresenta o detalhamento de cada uma das atividades.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 8
86
Subprocesso – Definir Objetivos (Metas)
Definir Objetivos (Meta)Legenda
Objetivo não
selecionado
Objetivo(s)Definido(s)
Papéis:zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzGP – Gerentes de Projetos
AM – Analista de Métricas
EP – Engenheiro de Processo
AR – Analista de Requisitos
Artefatos: zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
MTO – Matriz contendo os objetivos para cada categoria edimensão foco
OBJ - Objetivo(s)
DMF - Dimensão Foco
Criar Objetivo(s)
GPAMEPAR
Selecionar Objetivo(s)pré-definido(s) para aGestão de Requisitos
GPAMEPAR
Dimensão FocoDefinida
Símbolos
Início ou fim do processo
Atividades do processo
Papel
Produto requerido
Produto gerado
MTO
DMF
MTO
OBJ
OBJ
Objetivo
Selecionado
Figura 17 - Subprocesso para Definir Objetivos (Metas)
Esta etapa do processo utiliza os conceitos originalmente apresentados pelo GQM
(BASILI, CALDIERA e ROMBACH, 2002), que também possui a etapa de definição de
objetivos. Complementarmente, o PGIGR apresenta uma matriz (Tabela 6) onde cada uma das
categorias (Entendimento, Controle e Aprimoramento) foi cruzada com cada uma das dimensões
foco (Tempo, Custo, Qualidade e Risco). Para cada categoria/dimensão foco foi definido no
PGIGR um objetivo específico para a gerência de requisitos. A organização pode utilizar os
objetivos propostos, pode adequá-los às suas necessidades ou pode criar novos. Essa matriz visa
facilitar e agilizar a escolha de objetivos, já que apresenta um conjunto pré-definido de acordo
com cada categoria e dimensão foco, minimizando as chances da organização definir objetivos
de forma equivocada, pois direciona os usuários do processo.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 8
87
Tabela 6 - Matriz contendo sugestões de objetivos (metas) para cada categoria e dimensão foco
OBJETIVOS (Metas)
Categoria
Dimensão Foco
ENTENDIMENTO CONTROLE APRIMORAMENTO
TEMPO (T)
Conhecer o esforço e/ouprazo necessário paraexecutar as atividades derequisitos. (Meta T1)
Monitorar e controlar se oesforço e/ou prazo dasatividades de requisitosestão dentro dos valoresestipulados. (Meta T2)
Reduzir o esforço e/ouprazo para executar asatividades de requisitos.(Meta T3)
CUSTO (C)
Conhecer o custo
despendido para executar asatividades de requisitos.(Meta C1)
Monitorar e controlar se os
custos das atividades derequisitos estão dentro dosvalores estipulados. (MetaC2)
Reduzir os custos dasatividades de requisitos.(Meta C3)
QUALIDADE (Q)Conhecer a qualidade dosartefatos de requisitos.(Meta Q1)
Monitorar e controlar se aqualidade dos artefatos derequisitos está dentro dosvalores estipulados. (MetaQ2)
Aprimorar a qualidade dosartefatos de requisitos eminimizar retrabalho.(Meta Q3)
RISCO (R)
Entender os riscosrelacionados aogerenciamento de requisitos(Meta R1)
Monitorar e controlar osriscos relacionados aogerenciamento dosrequisitos (Meta R2)
Reduzir os riscosrelacionados aogerenciamento dosrequisitos (Meta R3)
Com o intuito de possibilitar uma rastreabilidade entre os indicadores e objetivos, foi
definida uma forma de identificação do objetivo, no qual o mesmo inicia com a primeira letra,
que representa a da dimensão foco, e tem um seqüencial numérico, de acordo com o quantitativo
de objetivos criados. Isso pode ser visualizado nos parênteses apresentados na Tabela 6.
3.5.3.4. Subprocesso: Definir Perguntas
O objetivo deste subprocesso é definir as perguntas para o aferir se os objetivos (metas)
previamente traçados foram ou não atendidos.
Para este subprocesso foram criadas duas atividades: Selecionar Perguntas pré-definidas
e Criar Pergunta(s). Na Figura 18 é apresentado o diagrama do subprocesso com as atividades,
artefatos e responsabilidades. O processo apresenta o detalhamento de cada uma das atividades.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 8
88
Subprocesso – Definir Perguntas (Questões)
Definir Perguntas (Questões)Legenda
Pergunta não
selecionada
PerguntasDefinidas
Papéis:zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
GP – Gerentes de Projetos
AM – Analista de métricas
AR – Analista de Requisitos
Artefatos: zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
MTP – Matriz contendo as perguntas para cada categoria edimensão focoOBJ - Objetivo(s)
PGT - Pergunta(s)
Criar Perguntas(s)
GMGPAR
Selecionarpergunta(s) pré-
definida(s)
AMGPAR
ObjetivosDefinidos
PGT
Símbolos
Início ou fim do processo
Atividades do processo
Papel
Produto requerido
Produto gerado
OBJMTP
MTP
PGT
PerguntaSelecionada
Figura 18 - Subprocesso para Definir Perguntas (Questões)
Este passo do processo utiliza os conceitos originalmente apresentados pelo GQM
(BASILI, CALDIERA e ROMBACH, 2002), que também apresenta a etapa de definição de
perguntas. Assim como foi feito para os objetivos, complementarmente o PGIGR apresenta uma
matriz – Tabela 7 – na qual cada uma das categorias (Entendimento, Controle e Aprimoramento)
foi cruzada com cada uma das dimensões foco (Tempo, Custo, Qualidade e Risco). Para cadacategoria/dimensão foco foi definido uma pergunta aderente aos objetivos propostos na Tabela 6
acima. O intuito foi facilitar a escolha de perguntas de acordo com os objetivos previamente
traçados. A organização pode utilizar as perguntas propostas, pode adequá-las às suas
necessidades ou pode criar novas, caso as existentes não atendam as necessidades.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 9
89
Tabela 7 - Matriz contendo sugestão de Perguntas (Questões) para cada categoria e dimensão foco
PERGUNTAS (Questões)
Categorias
Dimensão
Foco
ENTENDER CONTROLAR APRIMORAR
TEMPO (T)
Qual o esforço e/ouprodutividade nasatividades de requisitos?
(T1.P1)
O esforço e/ouprodutividade dasatividades de requisitos
está de acordo com osvalores (faixa) esperados?(T2.P1)
O esforço e/ouprodutividade dasatividades de requisitos
foi aprimorado apósações de melhoria?(T3.P1)
CUSTO (C)
Quanto custa paralevantar, analisar edocumentar os requisitos?(C1.P1)
Os custos das atividades derequisitos estão de acordocom os valores (faixas)esperados? (C2.P1)
Os custos de execuçãodas atividades derequisitos foramreduzidos após asações de melhoria?(C3.P1)
QUALIDADE (Q)
Qual a quantidade dedefeitos nos artefatos derequisitos? (Q1.P1)
Qual o custo de correçãode defeitos nos artefatosde requisitos? (Q1.P2)
A qualidade dos artefatosde requisitos já concluídosestá dentro dos valoresestimados de qualidade?
(Q2.P1)Qual o índice de retrabalhodas atividades derequisitos? (Q2.P2)
A densidade dedefeitos nos artefatos
de requisitos foireduzida após as açõesde melhoria? (Q3.P1)
RISCO (R)
Quais os principais riscosassociados às atividadesde requisitos? (R1.P1)Quais riscos associados àsatividades de requisitosestão se concretizandodurante o projeto?(R1.P2)
Os riscos do projeto,relacionados às atividadesde requisitos, estão dentrodas faixas estabelecidas noplanejamento? (R2.P1)
Qual o índice deaprimoramento dasatividades da gerênciade requisitos apósimplantação doscontroles de risco emgerência de requisitos?(R3.P1)
Seguindo o padrão de rastreabilidade proposto anteriormente na matriz de objetivos, o
conteúdo contido entre parênteses após cada pergunta da Tabela 7 é para permitir a identificação
e rastreabilidade entre os objetivos traçados anteriormente e as perguntas, em qual o primeiro par
de letras e número identifica o objetivo e o segundo par de letras e número identifica a pergunta.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 9
90
3.5.3.5. Subprocesso: Definir Indicadores
Este subprocesso tem como objetivo final criar os indicadores necessários para responder
as perguntas previamente definidas e aferir o atendimento dos objetivos estabelecidos.
Neste subprocesso o PGIGR mescla conceitos do GQM (BASILI, CALDIERA e
ROMBACH, 2002), GQ(I)M (PARK et al., 1996) e PSM (2008) para definir a formação dos
indicadores, que são compostos no PGIGR por cinco elementos:
1. Objetivo2. Pergunta3. Indicador4. Medida derivada5. Medida básica (ou base)
O intuito foi facilitar o entendimento e relacionamento entre os diferentes componentes
que fazem parte do indicador. O relacionamento e multiplicidade entre cada um dos cinco
elementos acima pode ser melhor visualizado na Figura 19.
Figura 19 - Relacionamento entre Objetivos, Perguntas, Indicadores, Medidas Derivadas e Medidas básicas
(base)
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 9
91
O intuito em utilizar essa estrutura e nomenclatura é viabilizar uma correta verificação do
atendimento de um objetivo através de uma pergunta, que por sua vez é respondida por um
indicador. No entanto, um indicador é formado por duas ou mais medidas derivadas, nas quais
medidas derivadas são compostas de duas ou mais medidas básicas (ou base).
Os conceitos de medidas derivadas e medidas básica foram extraídos do PSM (2008) com
o intuito de facilitar o entendimento e padronizar a nomenclatura dos componentes de
estruturação de um indicador.
Como esta etapa do processo é a que apresenta o maior número de detalhes, este
subprocesso é composto por quatro atividades: Selecionar indicadores pré-definidos, Descrever
o indicador, Estruturar o indicador e Divulgar/aprimorar o indicador . Na Figura 20 é
apresentado o diagrama do subprocesso contendo as atividades, artefatos e responsabilidades. O
APÊNDICE A apresenta o detalhamento de cada uma das atividades.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 9
92
Figura 20 - Subprocesso para Definir Indicador
Uma observação a ser feita é o fato da atividade de criação do indicador ser composta por
uma grande quantidade de informações visando o seu detalhamento. Por isso, a mesma foi
subdividida em 3 atividades: 1) Descrever o indicador, 2) Estruturar o indicador e 3)Divulgar/aprimorar o indicador, conforme agrupador pontilhado demonstrado na Figura 20
acima.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 9
93
Com o intuito de facilitar a definição de indicadores, o PGIGR apresenta uma matriz –
Tabela 8 – em que cada uma das categorias (Entendimento, Controle e Aprimoramento) foi
cruzada com cada uma das dimensões foco (Tempo, Custo, Qualidade e Risco). Para cada
categoria/dimensão foco foram definidos indicadores que a organização pode utilizar, adaptar ou
criar novos, conforme as suas necessidades e características. Isso irá facilitar a utilização do
processo, pois seus usuários podem escolher a partir de indicadores pré-definidos, podendo
adaptá-los à medida que for necessário. Cada indicador deve estar necessariamente relacionado a
pelo menos uma pergunta previamente definida, de acordo com a categoria e dimensão foco.
Tabela 8 - Matriz contendo os Indicadores Sugeridos para cada categoria e dimensão foco
INDICADORES SUGERIDOS
Categoria
Dimensão
Foco
ENTENDER CONTROLAR APRIMORAR
TEMPO (T)
PAR – Produtividade nasAtividades de Requisitos =(Somatório de horasdespendidas em atividadesde requisitos) / (Tamanho dosoftware)
PVE – Percentual de Variação
do Esforço = (Esforço realizadoaté o presente momento / Esforço Estimado) * 100
IVP - Índice de Variaçãode Produtividade =(percentual do esforço
gasto em atividades derequisitos por ponto defunção) / (média históricade esforço por ponto defunção) * 100
CUSTO (C)
CAR – Custos dasAtividades de Requisitos =(Somatório dos custos comatividades de requisitos) / (Tamanho do software)
PVC - Percentual de Variaçãodos Custos = (Somatório doscustos até o presente momento / Custos Estimados) * 100
IVC - Índice de Variaçãodos Custos = (percentualdos custos de requisitospor ponto de função) / (média histórica doscustos por ponto defunção) * 100
QUALIDADE (Q)
QDR – Quantidade deDefeitos em Requisitos =(Somatório dos errosidentificados em requisitos)
/ (Tamanho do Software)
CTD – Custo Total deDefeito em Requisitos =(somatório dos custos decorreção de errosidentificados em requisitos)
/ (Tamanho do software)
PRR - Percentual de RequisitosRejeitados = (percentual derequisitos rejeitados / percentualestimado de rejeição) *100
IVQ – Índice de variaçãoda qualidade =[(porcentagem derequisitos rejeitados porponto de função) / (porcentagem histórica derequisitos rejeitados porponto de função)] * 100
RISCO (R)
QRI – Quantidade de
Requisitos Incorporados aoescopo = (Quantidade deRequisitos após ofechamento da linha de
PSM - Percentual de
solicitações de mudança =(percentual de solicitações demudança de escopo / percentualestimado de alterações no
IVR - Índice de Variação
de Risco = (porcentagemde requisitos concluídosna release / porcentagemhistórica de requisitos
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 9
94
INDICADORES SUGERIDOS
Categoria
Dimensão
Foco
ENTENDER CONTROLAR APRIMORAR
base) / (Quantidade deRequisitos ao final doprojeto) *100
PPU - Percentual deParticipação do Usuário =(número de reuniões querepresentantes dos usuáriosparticiparam / número de
reuniões realizadas) * 100
PVR - Percentual deValidação de Requisitospelo Cliente = (número dedocumentos de requisitosvalidados / número total dedocumentos de requisitos) *100
PAR - Percentual deAlteração dos Requisitos jáaprovados = (número desolicitações de mudanças derequisitos / número total derequisitos já aprovados) *100
PMT - Quantitativo deMudanças nos Requisitos deacordo com o Tamanho doSoftware = (número derequisitos alterados / Tamanho do Software) *100
escopo) *100 concluídos) * 100
Durante o processo de criação da Tabela 8, alguns dos indicadores propostos foram
adaptados a partir de indicadores apresentados por Hazan (2002, 2003) e Loconsole (2001, 2002,
2003, 2004). Porém, a grande maioria dos indicadores descritos pelas autoras apresentava
somente a fórmula, não entrando em detalhes necessários para a sua implantação em um
ambiente corporativo. Maiores detalhes a respeito de como utilizar a Tabela 8 podem ser
visualizados no APÊNDICE A.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 9
95
Com o intuito de detalhar cada indicador definido, o PGIGR apresenta um template
(Tabela 23 do APÊNDICE A). O template tem o intuito de servir como guia para um correto
detalhamento dos indicadores. Cada campo do template foi devidamente detalhado com o
objetivo de proporcionar maior facilidade de entendimento para aqueles que irão utilizar o
processo, tendo em vista que parte da literatura pesquisada apresentou escassez de detalhes nesta
etapa do processo (GOODMAN, 1993; HAZAN, 2003; LOCONSOLE, 2001; 2002; 2003,
MONTEIRO, 2008).
O template foi concebido visando maximizar o nível de detalhamento e minimizar
ambigüidade e falhas na descrição dos indicadores. Para elaborar a estrutura do template foram
mesclados conceito do SEI (2004), Hazan (2003), GQM (BASILI, CALDIERA e ROMBACH,
2002) e PSM (2008). O template apresentado no processo utiliza como exemplo um dos
indicadores propostos pelo PGIGR, o que teve como intuito facilitar o entendimento dos usuários
do processo através da visualização de um exemplo já preenchido.
No APÊNDICE B são apresentados mais dois exemplos de indicadores detalhados
utilizando o template. Esses dois indicadores são anexos dos PGIGR. Os dois indicadores são da
categoria Entendimento, sendo um da dimensão foco tempo e o outro de custo.
3.5.3.6. Aprimorar o Processo de Software da Organização de TI
O Aprimoramento do Processo de Software não é um subprocesso do PGIGR e por isso
ele encontra-se destacado na Figura 12. Porém, ele é elemento necessário dentro do ciclo
proposto pelo PGIGR para que a organização de TI possa evoluir entre as quatro categorias
propostas (Inicial, Entendimento, Controle e Aprimoramento), permitindo assim a geração de
indicadores mais robustos ao longo do tempo.
O PGIGR destaca esta etapa do processo devido à sua importância dentro da estrutura
proposta pelo processo. Para que a organização possa criar novos indicadores, quase sempre é
necessário avaliar se o seu processo de desenvolvimento de software e infra-estrutura estão aptos
a suportar as novas necessidades. Grande parte das medidas básicas e derivadas necessárias na
formação dos indicadores derivam de atividades e ferramentas utilizadas no processo de
desenvolvimento de software, conforme as características apresentadas na Figura 13.
É importante ressaltar que a evolução entre as diferentes categorias fica a critério da
organização de TI. Sugere-se a evolução entre as categorias de Entendimento, Controle e
Aprimoramento de acordo com a evolução das necessidades da organização, não sendo ela
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 9
96
obrigada a evoluir, caso suas necessidades estejam sendo atendidas pelos indicadores da
categoria na qual ela se encontra.
3.6. Avaliação do Processo Proposto
Nesta seção descreve-se como foi avaliado o processo proposto e no capítulo 4 são
apresentados os resultados dessa avaliação.
3.6.1. Propósito da Avaliação e Delimitação
A avaliação do processo torna-se necessária para que seja possível aferir o atendimento
das características traçadas para o processo, conforme apresentado no Quadro 4.
Para isso, optou-se por uma avaliação através de questionário, onde foi definido um
conjunto de perguntas que pudessem avaliar se todas as características foram ou não atendidas.
O questionário não teve como escopo avaliar os resultados da aplicação do PGIGR na
prática, pois não haveria tempo hábil para a sua aplicação e coleta dos resultados obtidos.
3.6.2. Elaboração do Questionário de Avaliação
O questionário de avaliação foi subdividido em três seções distintas, visando facilitar o
seu preenchimento e segmentar as informações coletadas.
A primeira seção apresenta um conjunto de questões que visa coletar algumas
características a respeito do avaliador e da organização onde o mesmo trabalha.
Essa seção foi respondida durante a apresentação do questionário e antes do início
da avaliação do processo PGIGR.
A segunda seção do questionário apresenta as questões que avaliam cada um dossubprocessos e as atividades do PGIGR. Os avaliadores foram orientados a
responder as questões desta seção à medida que fossem lendo o processo PGIGR.
A terceira e última seção do questionário é composta de questões que deveriam
ser respondidas após a avaliação do processo. Elas têm um caráter mais
abrangente e visam avaliar o processo como um todo.
O questionário é composto de perguntas de múltipla escolha e perguntas onde as
respostas são descritivas. O questionário pode ser visualizado no APÊNDICE C.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 9
97
3.6.3. Identificação e Amostragem da População
Para a aplicação do questionário foram selecionados cinco avaliadores de três diferentes
organizações. Os profissionais selecionados possuem diferentes perfis, porém todos possuem
formação superior, são atuantes na área de desenvolvimento de software e possuem perfis e
experiências distintas: dois gerentes de projetos, dois analistas de sistema e um analista de
requisitos.
Essa diversidade de perfis teve como intuito mesclar profissionais com diferentes
backgrounds, e proporcionar uma visão mais precisa do processo a partir de diferentes pontos de
vista.
O número ímpar de avaliadores deve-se ao fato de se buscar um resultado que nãogerasse um empate ao final da avaliação, o que dificultaria na aferição do atendimento das
características definidas para o processo.
Como um dos objetivos do PGIGR é de ser um processo intuitivo, de fácil compreensão e
utilização, optou-se por não selecionar um especialista de métricas como avaliador, pois trata-se
de um profissional que já possui conhecimentos a respeito do assunto e poderia gerar uma
avaliação destoante a respeito da facilidade em se utilizar o PGIGR.
3.6.4. Aplicação do Questionário
O processo de aplicação do questionário seguiu os seguintes passos:
I. Entrega de uma cópia impressa do PGIGR para cada avaliador. Também foi
enviada a versão digital do processo por e-mail, caso o avaliador optasse pela sua
utilização em meio digital.
II. Apresentação individual de 30 minutos para cada avaliador para dar uma visão
geral do PGIGR, assim como descrever os objetivos da avaliação.
III. Entrega de uma cópia impressa do questionário de avaliação para cada avaliador.
Também foi enviada a versão digital do questionário por e-mail, caso o avaliador
optasse pelo seu preenchimento em meio digital.
IV. Apresentação de 15 minutos para cada avaliador visando esclarecer o questionário
e forma de preenchimento.
V. O avaliador foi orientado a responder a primeira seção do questionário antes de
iniciar a avaliação do processo. A primeira seção do questionário visa apenas
coletar algumas características da organização onde o avaliador trabalha.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 9
98
VI. Foi dado um prazo de 14 dias corridos para que os avaliadores pudessem avaliar o
PGIGR e responder as seções 2 e 3 do questionário. O avaliador foi orientado a
responder a seção 2 do questionário à medida que fosse lendo o processo, e a
seção 3 após a conclusão da leitura.
VII. Após a conclusão do prazo de avaliação, foram coletados os questionários e as
cópias impressas dos processos contendo comentários e sugestões. Eventuais
sugestões verbais também foram consideradas e registradas.
VIII. Foi feita uma consolidação e tabulação das respostas apresentadas nos
questionários.
IX. A partir das observações, comentários e sugestões feitas pelos avaliadores do
processo, ajustes foram feitos no PGIGR, gerando-se assim a versão final do
processo apresentado no APÊNDICE A.
X. Por fim, foi feito um mapeamento entre as características traçadas para o PGIGR
e as evidências coletadas através dos questionários, com o intuito de aferir se
todas as características traçadas foram atendidas ou não.
Observações a respeito do processo de avaliação do PGIGR: não houve qualquer
intervenção durante o período de avaliação; caso o avaliador tivesse algum tipo de dúvida a
respeito do processo, eles foram instruídos a descrever as dificuldades no questionário deavaliação, não havendo qualquer tipo de contato para retirada de dúvidas após a apresentação
inicial, realizada pelo pesquisador. Essa abordagem teve como objetivo avaliar a clareza e
facilidade de entendimento do processo, assim como proporcionar um cenário de avaliação
igualitário para todos os avaliadores.
3.6.5. Etapa de Análise dos Dados
Após a avaliação do processo realizada pelos cinco Avaliadores, os dados dos
questionários, comentários e sugestões foram consolidados, tabulados e processados.
Para cada uma das três seções contidas no questionário de avaliação foi gerada uma
matriz. Cada linha da matriz representa uma das perguntas objetivas do questionário e as colunas
representam as respostas de cada um dos cinco avaliadores. Para aferição dos resultados, na
última coluna foi utilizado o calculo da moda, que representa a resposta de maior ocorrência.
Após análise das respostas objetivas, os comentários, críticas e sugestões feitas pelos
avaliadores foram analisados individualmente. Foram descritos, principalmente, os comentários
e sugestões de aprimoramento que abordavam aspectos mais estruturais do processo, assim como
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
99
as alterações sofridas pelo processo PGIGR a partir das sugestões feitas. Correções e sugestões
mais pontuais, como correções ortográficas e estruturação frasal foram analisadas e incorporadas
ao processo, porém não foram detalhadas.
Com o intuito de avaliar se as características traçadas para o processo no Quadro 4 foram
ou não atendidas, foram utilizadas as respostas dos avaliadores, assim como o conteúdo
detalhado no processo. Para cada uma das características foram mapeadas as evidências que
apontavam para o seu atendimento.
Posteriormente, o processo foi comparado com os principais modelos de criação de
indicadores já existentes na literatura. O objetivo da comparação foi apresentar os benefícios
trazidos pelo PGIGR, quando contrastado com os demais. Como critério de comparação foi
criada uma matriz contendo nas linhas as características traçadas para o PGIGR e nas colunas os
modelos que foram utilizados na comparação. Posteriormente foi feita uma consolidação e
análise crítica dos principais benefícios trazidos pelo PGIGR.
Os detalhes dos resultados obtidos pela avaliação do processo podem ser visualizados no
capítulo 4.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
100
4. RESULTADOS E DISCUSSÕES
Este capítulo apresenta os resultados da pesquisa efetuada com profissionais da área de
desenvolvimento de software que avaliaram o processo PGIGR, discutindo esses resultados e
encerrando com uma análise crítica do processo proposto.
As respostas objetivas foram organizadas e tabuladas para serem apresentadas no
formato de tabelas.
4.1. Contextualização dos Avaliadores e das Organizações onde Trabalham.
As duas primeiras questões do questionário, por serem descritivas e coletarem
informações a respeito dos avaliadores e suas organizações, estão consolidadas abaixo. Optou-se
por não revelar os nomes dos avaliadores e das organizações ou empresas onde trabalham.
O Avaliador 1 é um Analista de Sistemas e possui sete anos de experiência na área de
desenvolvimento de sistemas. Ele trabalha em uma empresa privada especializada em serviços
de TI. A empresa possui nível 5 de maturidade no CMMI e nível A no MPS.BR. Trata-se de uma
empresa de grande porte, com mais de quatro mil funcionários. Porém, atualmente o Avaliador
presta serviços lotado em uma instituição governamental do Distrito Federal que possui seu
próprio processo de desenvolvimento de software. A área de desenvolvimento de software dessa
instituição é constituída por aproximadamente setenta profissionais de variados perfis.
O Avaliador 2 é um Analista de Requisitos e possui quinze anos de experiência na área
de desenvolvimento de software. Os Avaliadores 1 e 2 trabalham para a mesma empresa e
prestam serviço para o mesmo cliente.
O Avaliador 3 é um funcionário público, especialista em gerência de projetos e trabalha
em um banco governamental federal. Ele possui vinte e seis anos de experiência na área de TI. É
mestre em ciência da computação pela Universidade de Brasília (UNB) e aluno especial no curso
de doutorado da UNB em Ciência da Informação. O banco para o qual o avaliador trabalha é de
grande porte e possui capilaridade em todo o Brasil, possuindo processo de software bem
definido e com mais de seiscentos profissionais lotados somente na área de desenvolvimento de
software.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
101
O Avaliador 4 é um servidor público com especialidade em desenvolvimento de software
e trabalha para um órgão governamental federal. Ele possui cinco anos de experiência na área de
desenvolvimento de software e é mestrando em Ciência da Computação pela Universidade
Federal de Goiás – UFG. O órgão para o qual o avaliador trabalha presta serviços eleitorais para
o estado de Goiás e possui aproximadamente trinta pessoas na área de desenvolvimento de
software. Apesar do órgão não possuir um processo formal de desenvolvimento de software,
grande parte dos projetos utiliza técnicas de desenvolvimento ágil.
O Avaliador 5 é um servidor público que atualmente coordena a área de desenvolvimento
de sistemas de um órgão governamental federal. Ele possui seis anos de experiência na área de
desenvolvimento de sistemas e é pós-graduado em Gestão de Sistemas pela Universidade
Federal de Goiás – UFG. Os Avaliadores 4 e 5 trabalham para o mesmo órgão.
4.2. Consolidação dos dados da Primeira Etapa do Questionário
Nesta seção, os dados da primeira etapa do questionário de avaliação do processo PGIGR
foram consolidados em uma tabela, visando identificar as respostas objetivas com maior
ocorrência (moda). Esta etapa do questionário tem como objetivo coletar algumas informações a
respeito dos avaliadores e sobre as organizações onde trabalham ou prestam serviços.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
102
Tabela 9 - Consolidação dos dados da Primeira Etapa do Questionário
Legenda: PAR – Parcialmente, NSI – Não soube informar
Perguntas
A v a l i a d o r 1
A v a l i a d o r 2
A v a l i a d o r 3
A v a l i a d o r 4
A v a l i a d o r 5
Moda
3. Você possui experiência prática quanto a utilização de
medições e indicadores em desenvolvimento de
software?
NÃO SIM SIM NÃO NÃO NÃO
4. Você acredita que a gestão de requisito é um dos
fundamentos mais críticos para o sucesso dos projetosna organização onde trabalha?
NÃO SIM PAR PAR SIM SIM/PAR
5. A organização onde trabalha enfrenta dificuldades no
que tange a gestão de requisitos?SIM PAR SIM SIM SIM SIM
6. A organização onde trabalha possui um processo para
a gestão de requisitos?PAR SIM SIM NÃO NÃO SIM/NÃO
7. A organização onde trabalha possui práticas de
gerência de projetos?PAR SIM SIM PAR SIM SIM
8. A organização onde trabalha possui ferramenta
gerencial para controle de atividades de projetos? PAR PAR SIM PAR SIM PAR
9. A organização onde trabalha possui ferramenta e
processo para controle de versionamento dos artefatos
de requisitos?
SIM SIM SIM PAR SIM SIM
10. A organização onde trabalha possui práticas de
mensuração do tamanho de software?SIM SIM SIM NÃO NÃO SIM
11. Atualmente a organização onde trabalha utiliza
indicadores para gerenciar requisitos?NÃO PAR PAR NÃO NÃO NÃO
12. A organização onde trabalha possui um processo dedesenvolvimento de software?
PAR SIM SIM NÃO NÃO SIM/NÃO
Os resultados obtidos com as respostas dos avaliadores na primeira etapa do questionário
demonstram que a maioria dos avaliadores não possui experiência quanto ao uso de medições e
indicadores em projetos de desenvolvimento de software. Os dados também mostram que apenas
um avaliador não concordou que a gestão de requisitos é um dos fatores mais críticos para o
sucesso em projetos de software nas organizações onde trabalham.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
103
Praticamente todas as organizações onde os avaliadores trabalham apresentam
dificuldades no que tange a gestão de requisitos, apesar da maioria delas possuir práticas de
gerência de requisitos.
Grande parte das organizações também possui práticas de gerência de projetos, possuem
ferramentas de controle de versão e práticas de mensuração de software. As questões de número
seis a dez tinham como intuito representar as características exigidas para que uma organização
ingresse na categoria de Entendimento. Pelos resultados obtidos, foi constatado que apenas a
organização do Avaliador 3 apresentou todos os critérios exigidos para ingressar na categoria
Entendimento. Já a organização dos Avaliadores 1 e 2 apresentou alguns resultados parciais,
sendo que a organização dos Avaliadores 4 e 5 não possui alguns dos critérios exigidos, como
um processo para gestão de requisitos e práticas de mensuração de software.
Um fator interessante a ser ressaltado é que, apesar dos Avaliadores 1 e 2 trabalharem
para a mesma empresa, assim como os Avaliadores 4 e 5 trabalham para o mesmo órgão
governamental, as respostas a respeito das características da organização onde trabalham não
foram necessariamente iguais. Isso ressalta a importância do processo de categorização da
organização ser feito por um grupo de pessoas da organização que chegue a um consenso a
respeito do assunto, pois essa decisão é fundamental para a correta utilização do processo.
4.3. Consolidação dos dados da Segunda Etapa do Questionário
Nesta seção, os dados da segunda etapa do questionário de avaliação do processo PGIGR
foram consolidados em uma tabela, visando identificar as respostas objetivas com maior
ocorrência (moda). Esta etapa do questionário foi respondida pelos avaliadores à medida que eles
foram lendo o processo, visando obter uma impressão precisa a respeito de cada um dos
subprocessos e atividades avaliadas.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
104
Tabela 10 – Consolidação dos dados da Segunda Etapa do Questionário
Legenda: PAR – Parcialmente, NSI – Não soube informar
Perguntas
A v a l i a d o r 1
A v a l i a d o r 2
A v a l i a d o r 3
A v a l i a d o r 4
A v a l i a d o r 5
Moda
13. Em sua opinião, a parte introdutória do PGIGR, que apresenta
uma visão geral do processo, é de fácil entendimento?SIM SIM SIM SIM SIM SIM
14. Em sua opinião, a introdução do subprocesso Categorizar o
Processo de Software é de fácil entendimento?SIM SIM SIM SIM SIM SIM
15. Em sua opinião, a atividade Definir Envolvidos é de fácil
entendimento?
SIM PAR SIM SIM SIM SIM
16. Em sua opinião, a atividade Definir Categoria é de fácil
entendimento?SIM PAR SIM SIM SIM SIM
17. Em sua opinião, a introdução do subprocesso Definir Dimensão
Foco é de fácil entendimento?SIM SIM SIM SIM SIM SIM
18. Em sua opinião, a atividade Priorizar Dimensão Foco é de fácil
entendimento?SIM SIM SIM PAR SIM SIM
19. Em sua opinião, a atividade Definir Dimensão Foco para a
Geração de Indicadores é de fácil entendimento?SIM SIM SIM PAR PAR SIM
20. Em sua opinião, a introdução do subprocesso Definir Objetivos é
de fácil entendimento?
SIM PAR PAR SIM SIM SIM
21. Em sua opinião, a atividade Selecionar os Objetivos pré-
definidos para Gerência de Requisitos é de fácil entendimento?SIM SIM SIM PAR SIM SIM
22. Em sua opinião, a atividade Criar Objetivos é de fácil
entendimento?SIM SIM SIM SIM SIM SIM
23. Em sua opinião, a introdução do subprocesso Definir Perguntas
é de fácil entendimento?SIM SIM SIM SIM SIM SIM
24. Em sua opinião, a atividade Selecionar Perguntas Pré-Definidas
é de fácil entendimento?SIM SIM SIM PAR SIM SIM
25. Em sua opinião, a atividade Criar Perguntas é de fácil
entendimento?
SIM SIM PAR PAR SIM SIM
26. Em sua opinião, a introdução do subprocesso Definir
Indicadores é de fácil entendimento?SIM SIM PAR SIM PAR SIM
27. Em sua opinião, a atividade Selecionar Indicadores Pré-
Definidos é de fácil entendimento?SIM SIM SIM SIM SIM SIM
28. Em sua opinião, a atividade Descrever o Indicador é de fácil
entendimento?SIM SIM SIM SIM SIM SIM
29. Em sua opinião, a atividade Estruturar o Indicador é de fácil
entendimento?SIM SIM SIM SIM SIM SIM
30. Em sua opinião, a atividade Divulgar/Aprimorar o Indicador é
de fácil entendimento?
SIM SIM SIM SIM SIM SIM
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
105
Os resultados obtidos com as respostas dos avaliadores na segunda etapa do questionário
demonstram que todos os avaliadores consideraram os 17 itens avaliados do processo como
sendo de fácil compreensão e entendimento, não havendo nenhum item que apresentasse moda
diferente de “SIM”.
Essa informação é muito importante devido ao fato de caracterizar um consenso no que
diz respeito a facilidade para entender o processo e os passos que ele propõe a criação dos
indicadores para a gerência de requisitos.
4.4. Consolidação dos dados da Terceira Etapa do Questionário
Nesta seção, os dados da terceira etapa do questionário de avaliação do processo PGIGR
foram consolidados em uma tabela, visando identificar as respostas objetivas com maior
ocorrência (moda). Esta etapa do questionário foi respondida pelos avaliadores após a conclusão
da leitura do processo.
Tabela 11 - Consolidação dos dados da Terceira Etapa do Questionário
Legenda: PAR – Parcialmente, NSI – Não soube informar
Perguntas A v a l i a d
o r 1
A v a l i a d
o r 2
A v a l i a d
o r 3
A v a l i a d
o r 4
A v a l i a d
o r 5
Média /
Moda
31. Quanto tempo você levou para avaliar o
processo PGIGR?5h 4h 2h30 5h 2h 3h45
32. Em sua opinião, qual o nível de dificuldade
para compreender PGIGR?BAIXO MÉDIO BAIXO BAIXO BAIXO BAIXO
33. Em sua opinião, qual o nível de dificuldade
para utilizar o PGIGR?MÉDIO BAIXO MÉDIO MÉDIO MÉDIO MÉDIO
34. Você acredita que o PGIGR poderia seraplicado na organização onde trabalha?
SIM PAR SIM PAR SIM SIM
35. Você acredita ser necessário um especialista
em métricas para utilizar o PGIGR?NÃO SIM NÃO NSI NÃO NÃO
36. Você conseguiria criar um indicador seguindo
o processo?SIM SIM SIM PAR SIM SIM
Os resultados obtidos com as respostas dos avaliadores na terceira etapa do questionário
demonstram que é necessário, em média, 3 horas e 45 minutos para ler e compreender oprocesso. Esse tempo é considerado satisfatório, tendo em vista a grande quantidade de detalhes
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
106
apresentados pelo processo e o fato da maioria dos avaliadores não possuir experiência no
assunto.
O processo foi considerado como sendo de baixa complexidade. Apesar da maioria dos
avaliadores acreditar que o PGIGR pode ser implantado na organização onde trabalham, alguns
acreditam também que dificuldades seriam enfrentadas devido a questões estruturais das
organizações e, por isso, a maioria considerou que a sua utilização (ou implantação) seria de
média complexidade.
Para que o processo fosse acessível à maioria das organizações, uma das principais
características que ele deveria ter era a simplicidade, não sendo necessário especialistas na área
de métricas para a sua utilização. De acordo com os avaliadores, essa característica também foi
atendida, pois, segundo eles, não é necessário um especialista em métricas para utilizar o
processo e todos conseguiriam criar um indicador seguindo os passos apresentados pelo PGIGR.
4.5. Consolidação dos Comentários e Observações Feitas pelos Avaliadores do Processo
PGIGR
Nesta seção são relatadas as principais observações e sugestões feitas pelos cinco
avaliadores do processo. Foram descritos, principalmente, os comentários que abordam aspectos
mais estruturais do processo, assim como as alterações sofridas pelo processo PGIGR a partir das
sugestões feitas pelos avaliadores. Correções e sugestões mais pontuais, como correções
ortográficas e estruturação frasal foram analisadas e incorporadas ao processo, porém não foram
detalhadas abaixo.
4.5.1. Comentários e Sugestões do Avaliador 1
O Avaliador fez algumas observações e comentários a respeito da parte introdutória doprocesso. Segundo ele, era necessário maior detalhamento a respeito das diferentes categorias de
classificação de uma organização. Tendo isso em vista, foi feito uma alteração no processo, em
que um breve relato no início do processo descreve o objetivo de cada uma das quatro categorias
propostas: Inicial, Controle, Entendimento e Aprimoramento.
O Avaliador sugeriu que na descrição da etapa de Aprimorar o Processo de
Desenvolvimento de Software fossem descritos os principais problemas encontrados em
organizações, assim como sugestões de possíveis soluções. Essa sugestão não foi incorporada aoprocesso, pois para isso seria necessário aplicar o processo em diferentes organizações para que
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
107
fosse possível ter um histórico com esse tipo de informação. Mas, nada impede que uma
organização que adote o processo possa vir a adaptar o processo, incluindo esse tipo de
informação.
O Avaliador sugeriu a inserção de um resumo logo após a conclusão da descrição de cada
um dos subprocessos e suas atividades. Essa sugestão não foi acatada devido ao volume de
páginas já existentes no processo. Ao invés de se inserir um resumo, o que acarretaria em
repetição de informações, optou-se por reorganizar o conteúdo previamente existente no
processo, assim como adequar a escrita, deixando-a mais clara e objetiva.
O Avaliador fez o seguinte comentário: “... ficou muito bom! Claro, elegante, conciso,
bem embasado e inovador...”
Uma observação final feita pelo Avaliador foi a respeito da aplicabilidade do PGIGR em
um ambiente que utiliza técnicas de Extreme Programming (XP) para desenvolvimento de
software. Segundo ele, talvez alguns aspectos do PGIGR tivessem que ser adaptados para que
organizações que utilizam esse tipo de metodologia possam utilizar o PGIGR. Esse fator teria
que ser melhor estudado e eventuais limitações poderiam ser apontadas para organizações que
têm interesse em utilizar o PGIGR, porém utilizam técnicas de desenvolvimento ágil.
4.5.2. Comentários e Sugestões do Avaliador 2
O Avaliador fez observações mais pontuais no que tange às sugestões de melhoria. Assim
como o Avaliador 1, ele também achou que a parte introdutória do processo, principalmente a
que explana cada um dos subprocessos, necessitava de mais detalhes para melhor contextualizar
o leitor do processo. Dessa forma, foram feitos ajustes no processo de forma a deixar o texto
mais completo e coeso.
O Avaliador apresentou certa dificuldade com relação ao termo “Dimensão Foco”. Por
conta disso, o nome original do Subprocesso “Definir Dimensão Foco” foi alterado para “Definir
Foco dos Indicadores”, o que, segundo o Avaliador, é mais direto e objetivo para quem está
procurando ter um entendimento do PGIGR logo nas primeiras páginas do processo.
O Avaliador fez o seguinte comentário: “... o processo aborda um tema de extrema
relevância e pode melhor direcionar organizações que pretendem ingressar em um processo de
medição de software, porém não possuem profissionais com larga experiência no assunto.”
O Avaliador considerou como sendo as maiores contribuições do processo a matriz
contendo os objetivos para a gerência de requisitos e os indicadores propostos pelo processo.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
108
4.5.3. Comentários e Sugestões do Avaliador 3
Grande parte das observações feitas pelo Avaliador no texto do processo são referentes a
ajustes ortográficos e estrutura textual. Não houve qualquer sugestão de ajuste estrutural do
processo, apenas sugestões de ajustes textuais com o intuito de deixar a compreensão do
processo mais clara e objetiva.
Em conversa com o Avaliador, notou-se que houve certa confusão a respeito do que seria
um subprocesso e uma atividade. Por conta disso, na parte introdutória do processo PGIGR
foram inseridos trechos de texto visando deixar clara a função e composição dos subprocessos e
suas atividades.
O Avaliador fez o seguinte comentário: “... o template de criação de indicadores irá
facilitar bastante o detalhamento dos indicadores.” O Avaliador classificou o processo como
“simples e objetivo”, apesar de acreditar que profissionais com baixa experiência provavelmente
ainda teriam um pouco de dificuldade para compreender o processo rapidamente, devido ao
volume de conteúdo apresentado pelo mesmo.
4.5.4. Comentários e Sugestões do Avaliador 4
O Avaliador fez várias observações a respeito do processo. No que diz respeito à parte
introdutória do processo, o Avaliador achou que seria interessante melhor descrever a respeito
dos papéis que executam as atividades do processo. Tendo isso em vista, foi elaborado um texto
e uma tabela que apresentam detalhes a respeito de cada um dos papéis e suas atribuições.
Também foi melhor descrito os papéis envolvidos dentro de cada uma das atividades do
processo.
O Avaliador achou que as atividades de Priorização da Dimensão Foco e Definição da
Dimensão Foco poderiam ser fundidas em uma só. Como este Avaliador e o Avaliador 5 também
fizeram a mesma observação, optou-se por fundir as duas atividades em uma só, deixando o
processo mais objetivo e claro.
O Avaliador também levantou dúvidas a respeito do porquê em se escolher apenas uma
dimensão foco para a definição de indicadores. Como se trata de uma recomendação do processo
e não de uma imposição, tal explanação foi refinada e uma observação foi inserida na atividade
Definição da Dimensão Foco para a Geração de Indicadores.
No subprocesso Definir Objetivos (Metas), o Avaliador entendeu que os objetivos
sugeridos pelo processo estavam muito genéricos e em pouca quantidade. Como o objetivo do
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
109
PGIGR não foi exaurir todas as possibilidades de objetivos que uma organização possa vir a ter
para a gerência de requisitos, foram sugeridos objetivos mais genéricos, visando abranger o
maior número possível de organizações. Porém, a forma como o processo está estruturado provê
meios para que uma organização crie seus próprios objetivos, de acordo com suas necessidades.
Para isso, existe a atividade de criação de objetivos, na qual a organização pode adaptar os
objetivos sugeridos pelo PGIGR ou criar novos. Visando aprimorar esse entendimento, o texto
das atividades desse subprocesso foi adequado, com o intuito de torná-lo mais claro.
No subprocesso Definir Perguntas (Questões), o Avaliador fez comentários similares aos
feitos no subprocesso Definir Objetivos. Ele achou importante ressaltar que o usuário do
processo pode criar novas perguntas ou adaptar as perguntas sugeridas. Visando aprimorar esse
entendimento, o texto das atividades desse subprocesso foi adequado, com o intuito de torná-lo
mais claro.
No subprocesso Definir Indicadores, o Avaliador achou a quantidade de indicadores pré-
definidos um pouco reduzida, com exceção dos indicadores de risco na categoria Entender.
Como o objetivo do PGIGR não é exaurir todos os indicadores possíveis para uma correta gestão
de requisitos, mas apresentar os passos que devem ser seguidos para se criar um indicador, foi
feita essa ressalva na descrição desse subprocesso para que esse entendimento fique melhor
evidenciado.O Avaliador considerou como “extremamente positivo” o fato do template de indicador
proposto pelo PGIGR já vir preenchido com os dados de um indicador. Segundo ele, isso foi
“essencial” para que ele pudesse ter um correto entendimento do template proposto pelo PGIGR.
Segundo o Avaliador, “o subprocesso de Definir Indicadores é o mais fácil de entender
devido ao fato dele estar bem exemplificado, facilitando o entendimento de leigos no assunto.”
Como observação final, o Avaliador fez o seguinte comentário: “ Apesar de o PGIGR ser
de fácil compreensão, creio que ele não é facilmente aplicável por profissionais sem (ou com pouca) experiência em métricas e/ou gerência de projetos. Também não acho que o processo
seja difícil de ser implantado por esses mesmos profissionais, mas acho que o esforço
demandado por eles será razoável, pois, por mais claro e bem explicado que esteja o processo,
não há como fugir de alguns aspectos teóricos e práticos da engenharia de software que
demandarão estudo e/ou treinamento por parte de uma equipe inexperiente.” As observações
feitas por este Avaliador evidenciam uma possível necessidade de o PGIGR definir um mínimo
de experiência do(s) profissional(is) que venha(m) a utilizar o processo.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
110
4.5.5. Comentários e Sugestões do Avaliador 5
O Avaliador fez várias observações a respeito do processo. No subprocesso Categorizar o
Processo de Software da Organização de TI, o Avaliador achou que a quantidade de
características definidas para a categoria Entendimento deveria ser dividida. Segundo ele, seria
interessante criar uma nova categoria entre a Inicial e a de Entendimento, pois a forma como o
processo está estruturado atualmente torna difícil para uma organização de menor porte atender
todas as características exigidas pela categoria Entendimento.
A ideia apresentada pelo avaliador é bastante válida, pois de acordo com as informações
coletadas na parte inicial do questionário (questões 6 a 10 da Tabela 9), apenas a organização do
Avaliador 3 apresentou todas as características exigidas para ingressar na categoriaEntendimento. Porém, a sugestão do avaliador não foi acatada para esta versão do processo, pois
a proposta tem que ser melhor avaliada à medida que organizações forem utilizando o processo.
Como trabalho futuro, pode-se avaliar a possibilidade de criar novas categorias, gerando maior
segmentação, conforme foi feito pelo MPS.BR, quando comparado com o CMMI.
Assim como o Avaliador 4, o Avaliador 5 também achou que as atividades de Priorização
da Dimensão Foco e Definição da Dimensão foco poderiam ser fundidas em uma só. Conforme
mencionado anteriormente, após análise da sugestão, optou-se por fundir as duas atividades emuma só, deixando o processo mais objetivo e claro.
O Avaliador apresentou dúvidas com relação à figura que mostra o relacionamento entre
os objetivos, perguntas, indicadores, medidas derivadas e medidas básicas. Por isso o texto que
explica a Figura 29 do APÊNDICE A foi modificado, visando deixar mais claro o propósito da
figura.
Como observação final, o avaliador ressaltou: “... foi simples compreender o processo,
porém para utilizá-lo na organização onde trabalho seria um pouco difícil, principalmente pelo fato de não utilizarmos técnicas de contagem do tamanho do software. Talvez fosse interessante
criar um nível onde essa característica não fosse exigida, permitindo a geração de alguns
indicadores.” Conforme mencionado anteriormente, a sugestão do Avaliador não foi acatada
para esta versão devido a quantidade de alterações que seria necessário nesse momento e
também pelo fato de ser necessário avaliar se outras organizações terão a mesma impressão (ou
dificuldade). Foi ressaltado no texto do processo que o fato da organização não possuir todas as
características exigidas pela categoria Entendimento não significa que ela não conseguirá utilizar
alguns dos indicadores propostos. Talvez seja possível gerar alguns indicadores, porém a
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
111
organização corre o risco de despender um esforço muito grande para gerá-los e/ou mantê-los,
além de correr o risco de gerar informações inconsistentes e ambíguas.
4.6. Avaliação do PGIGR Quanto ao Atendimento às Características Traçadas para o
Processo
Esta etapa da pesquisa visa avaliar se todas as características traçadas para o PGIGR no
Quadro 4 foram ou não atendidas. Para realizar essa avaliação foram utilizadas as respostas dos
profissionais que avaliaram o processo, assim como o conteúdo detalhado no processo.
Para cada uma das característica foram mapeadas as evidências que apontam para o seu
atendimento, conforme apresentado na Tabela 12.
Tabela 12 - Avaliação do PGIGR Quanto ao Atendimento às Características Traçadas para o Processo
Legenda: PAR – Parcialmente, NSI – Não soube informar
Característica Atendida Evidência
O processo é de fácil compreensão.
(CRC01)SIM
Essa característica foi considerada atendida, pois a maioria
dos avaliadores considerou como BAIXA a dificuldade para
compreender o processo (Questão 32 da Tabela 11).
O processo é de fácil utilização.
(CRC02)PAR
Essa característica foi considerada parcialmente atendida,
pois a maioria dos avaliadores considerou o processo como
sendo de dificuldade MÉDIA, quanto a utilização (Questão
33 da Tabela 11). A maioria dos avaliadores considerou que
apesar do processo ser de simples compreensão, a sua
implantação dentro de um contexto organizacional seria um
pouco mais complicado, apesar de factível. Essa resposta
está de certa forma relacionada com a Questão 34 da Tabela
11, em que a maioria considerou que seria possívelimplantar o processo na organização onde trabalha.
O processo agiliza a criação de
indicadores para a gerência de
requisitos. (CRC03)
SIM
A média de tempo utilizado pelos respondentes para ler todo
o processo foi de 3 horas e 45 minutos, conforme
apresentado na questão 31 da Tabela 11. Também podemos
utilizar como evidência do atendimento desta característica o
fato da maioria dos avaliadores considerar possível a criação
de um indicador seguindo o processo (Questão 36 da Tabela
11).
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
112
Característica Atendida Evidência
O processo apresenta características
mínimas necessárias para a geração
de indicadores consistentes para agerência de requisitos. (CRC04)
SIM Essa característica pode ser considerada atendida através da
matriz de categorização do processo de software de
organização de TI (Tabela 18 do APÊNDICE A). Nela sãodefinidas as características mínimas para que a organização
crie indicadores na categoria de Entendimento, Controle e
Aprimoramento. Essas características externalizam critérios
necessários que uma organização deve possuir para que
consiga criar seus indicadores de forma correta. Como
evidência quantitativa, pode-se utilizar as respostas 14 a 16
da Tabela 10, em que a maioria dos avaliadores considerou
como simples o processo de Categorização da Organização
de TI.
O processo permite que organizações
criem indicadores para a gerência de
requisitos com o foco em suas
necessidades. (CRC05)
SIM
Essa característica pode ser considera atendida, pois o
subprocesso Definir Foco dos Indicadores permite esse
direcionamento. A matriz que possibilita o direcionamento
dos indicadores de acordo com a dimensão foco (Tabela 19
do APÊNDICE A) permite que a organização direcione a
criação dos indicadores de acordo com as suas necessidades.
Como evidência quantitativa, pode-se utilizar as respostas da
Questão 17 a 19 da Tabela 10, em que a maioria considerou
o referido subprocesso e suas atividades como de fácil
entendimento.
O processo apresenta um conjunto
prévio dos principais objetivos da
gerência de requisitos. (CRC06)
SIM
Essa característica pode ser considerada atendida, pois o
PGIGR apresenta uma matriz com um conjunto de objetivos
que podem ser selecionados pelos usuários do processo.
(Tabela 20 do APÊNDICE A). Como evidência quantitativa,
pode-se utilizar as respostas da Questão 20 a 22 da Tabela
10, em que a maioria considerou o referido subprocesso e
suas atividades como de fácil entendimento.
O processo apresenta uma forma de
rastrear um objetivo até os
indicadores, facilitando assim a
visibilidade e análise de aferição de
resultados. (CRC07)
SIM
Conforme apresentado na matriz de indicadores (Tabela 22
do APÊNDICE A), cada indicador é identificado de forma
que possa ser rastreado o objetivo e a pergunta. Essa
identificação permite uma correta rastreabilidade.
O processo apresenta sugestões de
indicadores específicos para a
gerência de requisitos, visando
facilitar a compreensão de seus
usuários. (CRC08)
SIM
Conforme apresentado na matriz de indicadores (Tabela 22
do APÊNDICE A), são apresentados vários indicadores para
a gerência de requisitos. Esses indicadores podem ser
selecionados ou adaptados pelos usuários do processo.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
113
Característica Atendida Evidência
O processo apresenta template quepossa ser utilizado para facilitar a
criação de um indicador,
apresentando todas as informações
necessárias. (CRC09)
SIM
Conforme apresentado na Tabela 23 do APÊNDICE A, o
PGIGR apresenta um template que serve como guia para a
criação e detalhamento de um indicador. Para facilitar o seuentendimento, o template vem preenchido com os dados de
um dos indicadores propostos pelo processo. Esse fato foi
inclusive elogiado por alguns avaliadores, conforme
reportado anteriormente. O APÊNDICE B é um anexo do
PGIGR e nele é apresentado o detalhamento de mais dois
indicadores, utilizando o template do PGIGR.
O processo é simples o suficiente ao
ponto de não requerer que sua
utilização necessite de um
especialista em métricas (CRC10)
SIM
Esta característica foi atendida, conforme pode ser
evidenciado na questão 35 da Tabela 11. A maioria dos
avaliadores considerou que não seria necessário um
especialista em métricas para utilizar o processo.
O processo proporciona uma
evolução incremental no que tange a
utilização de indicadores para a
gerência de requisitos (CRC11)
SIM
Conforme pode ser visto na Figura 22 e Figura 24 do
APÊNDICE A, o processo apresenta critérios objetivos para
implantar de forma incremental novos indicadores. Essa
evolução está diretamente relacionada às necessidades da
organização e às características de seu processo de
desenvolvimento de software.
Os resultados obtidos demonstram que somente uma das características não foi atendida
em sua completude (CRC02). Isso demonstra que o processo atendeu de forma satisfatória os
objetivos que foram inicialmente traçados, conforme as evidências apresentadas na Tabela 12.
4.7. Comparativo do PGIGR com os Demais Modelos de Criação de Indicadores e Análise
dos Principais Benefícios Obtidos
A Tabela 13 a seguir apresenta um comparativo entre o PGIGR e os demais modelos de
criação de indicadores utilizados no referencial teórico deste trabalho, são eles: GQM, GQ(I)M e
PSM. O objetivo da comparação é apresentar os principais benefícios trazidos pelo PGIGR,
quando contrastado com os demais modelos existentes. Como critério de comparação foram
utilizadas as características traçadas para o PGIGR.
Todas as respostas utilizadas na coluna do PGIGR foram baseadas nas respostas e
comentários dos avaliadores do processo, de acordo com as evidências apresentadas na Tabela
12. Já as respostas dos demais modelos foram embasadas na literatura pesquisada e nascaracterísticas apresentadas no referencial teórico deste trabalho.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
114
Tabela 13 - Comparativo do PGIGR com os Demais Modelos de Criação de Indicadores
Legenda: PAR – Parcialmente
Processos/Modelos
Características
do processo
PGIGR GQM PSM GQ(I)M
O processo é de fácil compreensão. (CRC01) SIM SIM PAR SIM
O processo é de fácil utilização. (CRC02) PAR NÃO NÃO NÃO
O processo agiliza a criação de indicadores para a
gerência de requisitos. (CRC03)
SIM PAR PAR PAR
O processo apresenta características mínimas
necessárias para a geração de indicadores
consistentes para a gerência de requisitos. (CRC04)
SIM NÃO NÃO NÃO
O processo permite que organizações criem
indicadores para a gerência de requisitos com o
foco em suas necessidades. (CRC05)
SIM PAR PAR PAR
O processo apresenta um conjunto prévio dos
principais objetivos da gerência de requisitos.
(CRC06)
SIM NÃO NÃO NÃO
O processo apresenta uma forma de rastrear um
objetivo até os indicadores, facilitando assim a
visibilidade e análise de aferição de resultados.
(CRC07)
SIM PAR PAR PAR
O processo apresenta sugestões de indicadores
específicos para a gerência de requisitos, visando
facilitar a compreensão de seus usuários. (CRC08)
SIM NÃO NÃO NÃO
O processo apresenta template que possa serutilizado para facilitar a criação de um indicador,
apresentando todas as informações necessárias.
(CRC09)
SIM NÃO PAR NÃO
O processo é simples o suficiente ao ponto de não
requerer que sua utilização necessite de um
especialista em métricas (CRC10)
SIM NÃO NÃO NÃO
O processo proporciona uma evolução incremental
no que tange a utilização de indicadores para a
gerência de requisitos (CRC11)
SIM PAR PAR PAR
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
115
A tabela acima demonstra os benefícios trazidos pelo PGIGR, quando comparado com
os demais modelos existentes na literatura. Como o PGIGR possui foco na gestão de
requisitos, ele acaba se sobressaindo quando comparado com os demais modelos,
principalmente pelo fato deles serem genéricos.
Um diferencial importante é o fato de o PGIGR apresentar, no subprocesso de
Categorização do Processo de Software da Organização de TI, critérios objetivos que avaliam
a existência de características importantes para uma correta geração de indicadores para a
gerência de requisitos. Essas características são fontes de medidas básicas e derivadas que são
geradas a partir do processo de desenvolvimento de software. Isso acaba criando um
importante diferencial, pois muitas organizações que utilizam os demais processos acabam
gerando indicadores ambíguos ou incorretos devido ao fato de utilizarem fontes de dados
inconsistentes, informações inapropriadas ou simplesmente não estarem preparadas para
ingressar em um processo de medição.
O processo também guia a criação de indicadores com foco em necessidades pré-
definidas: risco, tempo, custo e qualidade. Isso faz com que os usuários do processo possam
focar a criação dos indicadores nas áreas que são consideradas como prioritárias para a
organização.
Por ser específico para a gestão de requisitos, o processo já trás objetivos, perguntas eindicadores pré-definidos, o que agiliza, facilita e minimiza as chances de erro durante a
criação de indicadores, uma vez que os modelos existentes deixam essas definições e decisões
a critério dos usuários do processo.
Por apresentar alta granularidade de detalhes, passos bem definidos e informações pré-
definidas, o processo foi considerado pelos avaliadores como simples de ser compreendido,
não sendo necessário ser um especialista em métricas para compreendê-lo.
O PGIGR também se destaca por apresentar um template que contempla um conjuntobem completo de informações para detalhar e manter um indicador, minimizando as chances
de definição de um indicador inconsistente. O template também foi construído de forma que
possa guiar os usuários do processo durante o detalhamento do indicador. Os demais
processos não apresentam templates, o que acarreta muitas vezes na definição de indicadores
que são difíceis de serem interpretados ou mantidos.
Outro aspecto relevante é o fato do PGIGR possibilitar uma evolução gradual quanto a
utilização dos indicadores, baseando-se em critérios objetivos e importantes para uma correta
gestão de requisitos. Isso permite determinar onde uma organização se encontra e onde ela
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
116
pode chegar, de acordo com suas necessidades e expectativas no que tange a gestão de
requisitos.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
117
5. CONCLUSÃO
Várias atividades foram realizadas no desenvolvimento desta pesquisa, com o objetivo
principal de se criar um processo de geração de indicadores para a gestão de requisitos – PGIGR.
Primeiramente foi feita uma ampla revisão da literatura para identificar as principais
causas de fracasso em projetos de desenvolvimento de software. A partir da literatura pesquisada
e apresentada no capítulo de revisão bibliográfica deste trabalho, a gerência de requisitos foi
selecionada como foco da pesquisa. A razão da gerência de requisitos ter sido selecionada é
devido ao fato dela exercer um papel central no desenvolvimento de software, em que problemas
no gerenciamento de requisitos acabam sendo propagados para as demais etapas do processo de
desenvolvimento de software. O relatório do Caos do Standish Group foi utilizado como
principal referência devido à sua abrangência e reconhecimento. Nele foram mapeadas as dez
principais causas de fracasso em projetos de software em vários países, estando as três principais
causas diretamente relacionadas à gestão de requisitos: falta de envolvimento dos usuários,
requisitos incompletos e constante alteração nos requisitos.O histórico de falhas e a complexidade da gestão de projetos de desenvolvimento de
software requerem que gerentes utilizem técnicas de gestão quantitativa para que sejam aplicadas
de forma a possibilitar uma melhor tomada de decisão e possibilitar maior previsibilidade para
atender os objetivos traçados. Indicadores podem promover a visibilidade de diversos aspectos
relacionados às atividades de gestão de desenvolvimento.
Uma vez contextualizada a necessidade e importância da utilização de métricas e
indicadores em projetos de desenvolvimento de software, foram analisados os principaismodelos de geração de métricas e indicadores existentes na literatura. Foram identificados e
detalhados os três principais modelos: GQM, GQ(i)M e PSM. Cada um dos modelos foi
analisado visando identificar suas características e eventuais limitações.
Os modelos para a definição de medidas e indicadores supracitados são genéricos e
muitas vezes necessitam que especialistas em métricas ou pessoas com larga experiência estejam
envolvidos para que interpretações e adaptações sejam feitas de forma correta para cada
organização, o que acaba dificultado para organizações que não possuem esses profissionais.
Também foram analisados trabalhos acadêmicos que abordam aspectos relacionados à
geração de medições e indicadores especificamente para a gerência de requisitos. Alguns autores
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
118
pesquisados apresentam indicadores específicos para a gerência de requisitos (GOODMAN,
1993; HAZAN, 2003; LOCONSOLE, 2002; 2003; 2004; 2007, MONTEIRO, 2008). Contudo,
os autores que exploraram esse nicho de pesquisa pouco detalharam o processo de construção
dos indicadores ou o contexto no qual os mesmos foram gerados ou aplicados, tornando-se
muitas vezes difícil a sua replicação em outro contexto organizacional. O foco principal dos
autores foi na validação dos indicadores propostos. Isso demonstra a necessidade da análise de
algumas características da organização de TI antes que sejam definidos e utilizados indicadores.
Para que organizações possam criar indicadores consistentes, com maior facilidade e
assertividade é preciso um processo em que a geração de indicadores tenha como foco a gestão
de requisitos, trilhando assim um caminho que minimize as chances de erros na execução do
processo através do foco, clareza e facilidade para sua compreensão e utilização. Um processo
que apresente um conjunto de passos bem definidos para que diferentes organizações de TI
possam utilizá-lo de acordo com suas características e necessidades.
Com esta motivação em mente, o objetivo desta pesquisa foi definir um processo de
geração de indicadores específicos para a gerência de requisitos – PGIGR, que permitisse a
criação de indicadores de, possibilitando um correto monitoramento e controle dos projetos de
desenvolvimento de software. Para atender a esta expectativa, foram definidos originalmente os
seguintes objetivos específicos:i. Definir um conjunto de características desejadas para um processo de definição de
indicadores para gestão de requisitos;
ii. Elaborar um processo para criação de indicadores para gestão de requisitos,
atendendo às características previamente traçadas;
iii. Avaliar o processo proposto;
iv. Aprimorar o processo após avaliação;
Após análise das pesquisas realizadas, para o objetivo (i) foi definido um conjunto decaracterísticas desejadas para o PGIGR, conforme apresentado no Quadro 4. Essas características
foram definidas a partir dos principais dificuldades e limitações identificadas nos modelos
avaliados, limitações nos trabalhos acadêmicos existentes e nas necessidades para uma correta
geração de indicadores para a gerência de requisitos.
A partir das características traçadas para o processo PGIGR, o objetivo (ii) foi atendido
através da criação do processo. Esta etapa do trabalho foi a que envolveu maior quantidade de
esforço, pois foram consolidados conceitos apresentados pelo GQM, GQ(I)M e PSM; assimcomo também foram mapeadas as principais limitações nos trabalhos apresentados por Hazan e
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
119
Loconsole, visando criar um processo mais completo e coeso, conforme apresentado no
APÊNDICE A.
Uma vez concluída a elaboração do processo, o objetivo (iii) encarregou-se de submetê-lo
a avaliação de profissionais da área de desenvolvimento de software. A avaliação do processo foi
feita através de questionário, visando evidenciar se as características traçadas originalmente para
o processo, conforme apresentado no Quadro 4, foram ou não atendidas. Esta etapa foi bastante
trabalhosa, porém a mais enriquecedora. Ela permitiu que o processo fosse avaliado por cinco
profissionais com diferentes perfis, o que contribuiu para evidenciar o atendimento das
características traçadas para o processo, além de ter gerado insumos para o aprimoramento do
mesmo. Foi através dela que foi possível ter uma visão mais realista a respeito das possibilidades
de implantação do processo em um ambiente coorporativo, assim como evidenciar os principais
benefícios e limitações existentes no processo.
Para avaliar o atendimento das características traçadas para o processo PGIGR (Quadro
4), foram mapeadas as evidências, através das respostas e comentários feitos pelos Avaliadores,
que apontassem para o seu atendimento, conforme apresentado na Tabela 12. Os resultados
obtidos a partir das respostas dos Avaliadores foram extremamente satisfatórios, pois das onze
características traçadas para o processo, somente uma foi atendida de forma parcial (CRC02),
tendo sido as demais atendidas por completo. Isso demonstra que o processo atingiu de formasatisfatória os objetivos que foram inicialmente traçados.
Uma vez concluída a avaliação do processo, o objetivo (iv) foi aprimorá-lo a partir das
sugestões e comentários feitos pelos Avaliadores. Esta etapa da pesquisa foi muito importante,
pois os feedbacks dos Avaliadores permitiram a identificação de pontos importantes de
aprimoramento, o que possibilitou deixar o processo ainda mais alinhado às características
previamente traçadas no Quadro 4. Grande parte das críticas e sugestões feitas ajudaram a
aprimorar principalmente aspectos relacionados ao seu entendimento e aplicabilidade.Este trabalho gerou as seguintes contribuições para a gestão de requisitos em projetos de
desenvolvimento de software:
Criou-se um processo para geração de indicadores específicos para a gerência de
requisitos (PGIGR), rápido de ser compreendido, de fácil entendimento e factível
de ser implanto em diferentes organizações.
O processo proposto apresenta um nível de detalhes que permite com que
profissionais típicos de desenvolvimento de software consigam entendê-lo eutilizá-lo, não sendo necessário ser um especialista na área de métricas. Isso acaba
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
120
evidenciando o atendimento da suposição previamente estabelecida para esta
pesquisa.
O processo proposto apresenta características mínimas necessárias que uma
organização deve possuir em seu processo de desenvolvimento de software para
que possa ingressar, de forma gradual e eficiente, em um processo de definição de
indicadores para a gerência de requisitos.
O processo proposto permite focar a geração de indicadores para a gerência de
requisitos de acordo com as características e necessidades da organização,
minimizando as chances de definição de indicadores ambíguos ou que não
atendam as suas necessidades.
O processo proposto apresenta objetivos, perguntas e indicadores pré-definidos e
específicos para a gerência de requisitos, possibilitando aos usuários do processo
ter um ponto de partida. Isso faz com que organizações consigam de forma mais
rápida, objetiva e direcionada definir seus indicadores, o que minimiza as chances
de erro durante a utilização do processo.
O processo proposto apresenta um template de indicador que pode ser utilizado
para facilitar a criação e detalhamento dos indicadores, apresentando as
informações consideradas como necessárias para a sua correta criação e
manutenção.
É apresentada uma forma simples de se manter uma rastreabilidade entre os
objetivos, perguntas e indicadores, possibilitando assim avaliar o atendimento dos
objetivos traçados.
O processo proporciona uma evolução gradual e incremental no que tange a
utilização de indicadores para a gerência de requisitos.
Por fim, este trabalho procura auxiliar organizações que não possuem muitos recursos ouprofissionais especialistas em métricas, ma que têm interesse em implantar práticas de medição
em projetos de desenvolvimento de software. O PGIGR permite que organizações implantem
indicadores para a gerência de requisitos de forma mais objetiva, pois é um processo focado em
requisitos, não necessitando de grande investimento de tempo para o seu entendimento ou
adaptação.
No entanto, entende-se que outros trabalhos podem ser realizados com as seguintes
perspectivas de pesquisas futuras:
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
121
Aplicar o PGIGR em diferentes organizações e mapear as principais dificuldades
e ganhos obtidos.
Verificar a possibilidade de criar novas categorias de classificação da organização
de TI.
Aumentar a quantidade de indicadores propostos pelo processo.
Avaliar a aplicabilidade do PGIGR em organizações que utilizam processos de
desenvolvimento ágil.
Avaliar a possibilidade de adaptar o PGIGR para gerar indicadores para outras
disciplinas da engenharia de software, tais como: implementação, gerência de
configuração, testes, etc.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
122
REFERÊNCIAS BIBLIOGRÁFICAS
ARAÚJO, A. EDUARDO. Diretrizes para o estabelecimento de indicadores para aquisição
de software. Monografia de Especialização. Universidade de São Paulo, p-12, 2004.
BERANDER, P.; JÖNSSON, P. A goal question metric based approach for efficient
measurement framework definition, In: International Symposium on Empirical Software
Engineering, 2006, Rio de Janeiro, Brasil, Anais eletrônico. Disponível em:
<http://portal.acm.org/citation.cfm?id=1159781>. Acesso em: 03 jan. 2009.
BASILI, V.R.;D. WEISS, “A Methodology for Collecting Valid Software Engineering Data”,
IEEE Tram. Software Engineering, Vol. 10, No. 6, pp.728-738, 1984.
BASILI, V. R., ROMBACH, H. D. The TAME Project: Towards Improvement-Oriented
Software Environments, IEEE Transactions in Software Engineering 14(6) November 1988.
BASILI. Software Modelling and Measurement: The Goal/Question/Metric Paradigm. TechnicalReport CS-TR-2956, University of Maryland, September 1992.
BASILI, CALDIERA, ROMBACH. Goal Question Metric Paradigm. Encyclopedia of
Software Engineering, volume 1, John Wiley & Sons, 1994.
BASILI, V.R., SHULL, F., LANUBILE, F. Building Knowledge through Families of
Experiments. IEEE Transaction on Software Engineering, 25, 4 (Jul. 1999), 456 – 473.
BRAY, I. Introduction to Requirements Engineering, Addison-Wesley, 2003.
BAUMERT, J; MCWHINNEY, M. Software Measures and the Capability Maturity Model,
Software Engineering Institute Technical Report, CMU/SEI-92-TR-25, ESC-TR-92-0, 1992.
BOEHM, B. Industrial Software Metrics Top 10 List, IEEE Software, Vol. 4, No. 5, September
1987, pp. 84-85.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
123
CAJADO, EDUARDO A. (1999). Gerência de Projetos: Conceitos, Objetivos e Softwares de
Apoio. Revista Developers’ Magazine, Rio de Janeiro, Ano IV, n. 37, p. 18-20.
CMMI Product Team, Capability Maturity Model Integration, version 1.1 – CMMI for Systems
Engineering, Software Engineering and Integrated Product and Process Development (CMMI
SE/SW/IPPD v1.1), Software Engineering Institute, Carnegie Melon University, 2001.
COSTELLO, R. J., LIU D., Metrics for Requirements Engineering, in Journal of Systems and
Software, 29(1), April 1995, pp. 39-63.
CROSBY, P.B., Quality Is Free: The Art of Making Quality Certain; Mc Graw-Hill, 1979
DAVIS, A.M. 1993. Software Requirements: Objects, Functions and States. Prentice- Hall, Inc.
DEMING, E. Quality, Productivity, and Competitive Position. Center for Advanced
Engineering Study, Massachussets Institute of Technology, Cambridge, MA, 1982.
DE MARCO. Controle de Projetos de Software. Editora Campus, 1991.
DoD – Departament of Defense e Us Army. Measurement Specification Template, Jan, 2004.
Disponível em:
<http://www.psmsc.com/Downloads/MeasurementSpecs/MeasurementSpecTemplateV2Jan04.zi
p>. Acesso em: 27/10/2008.
EASTERBROOK, S., What are Requirements, 2004
<http://jasonnolan.net/kmd1002/easterbrook.pdf>. Acesso em: 10/05/2008
EL EMAM. Causal Analyses of the Requirements Change Process for a Large System.
IESE-Report No. 054.97/E, 1997.
EVERALD, Software Metrics SEI Curriculum Module SEI-CM-12-1.1, Carnegie Mellon
University Software Institute, Dec 1988.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
124
FARBEY, B. Software Quality Metrics: Considerations About Requirements and
Requirements Specifications. Information and Software Technology, vol. 32, nº 1, p. 60-64,
jan./feb. 1990.
FENTON E. N., PFEEGER L S., Software Metrics- A Rigorous & Practical approach, 2nd
Edition, International Thomson Publishing, Boston, MA, 1998
FLORAC W. A.; CARLETON, A. D. Measuring the Software Process: Statistical Process
Control for Software Process Improvement. Reading, MA, EUA: Addison-Wesley, 1999.
FUTRELL, R.T., SHAFER, L.I., SHAFER, D.F. 2001. Quality Software ProjectManagement. Prentice Hall PTR Upper Saddle River, NJ, USA.
FPNQ. Critérios de Excelência: Planejamento do Sistema de Medição do Desempenho Global.
Fundação para o Prêmio Nacional da Qualidade, 2001.
FPNQ. Critérios de Excelência: O estado da arte da gestão para excelência do desempenho.
Fundação para o Prêmio Nacional da Qualidade, www.fpnq.org.br, 2003.
GARCÍA, F. et al. Towards a consistent terminology for software measurement. Information
and Software Technology. Vol. 48, no. 8, pp. 631-644, Ago, 2006.
GRADY, R. Practical Software Metrics for Software Management and Process
Improvement. Prentice Hall, 1992.
GOETHERT, WOLFHART; FISCHER, MATT, Deriving Enterprise-Based Measure Usingthe Balanced Scorecard and Goal-Driven Measurement Techniques, Software Engineering
Institute, p-3, 2003
GOODMAN, P., Practical Implementation of Software Metrics, McGraw Hill, London, 1993.
HALL T.; FENTON, N. Implementing effective software metrics programs. IEEE Software.
vol. 14, no. 2, pp. 55-65, Mar/Abr, 1997.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
125
HAMMER, T.F.; HUFFMAN L.L.; ROSSENBERG L.H. Doing requirements right the first
time, in CROSSTALK The Journal of Defence Software Engineering, December 1998, pp 20-
25.
HARRISON, R., BADOO, N., BARRY, E., BIFFL, S., PARRA, A., WINTER, B., WUEST, J.
1999. Directions and Methodologies for Empirical Software Engineering Research.
Empirical Software Engineering, 4, 4 (Dec. 1999), 405 – 410.
HAZAN, C. Metodologia para o Uso de Indicadores na Gerência de Projetos de
Desenvolvimento de Software. Tese de Mestrado, IME, Maio 1999.
HAZAN, C., Introdução da Gerência pela Qualidade Total em Organizações de
Desenvolvimento de Software. WQS, 1999.
HAZAN, C., Implantação de um Processo de Medições de Software. CITS:QS, Junho 2001.
HAZAN, C., Definição de Indicadores Utilizando o Modelo Practical Software Management
(PSM). 2002
HAZAN, C., Indicadores para a Gerência de Requisitos. Workshop em Engenharia de
Requisitos, 2003.
HOLANDA, A. B. Novo Dicionário Aurélio da Língua Portuguesa. 2ª ed. 1986.
IEEE 26th International Conference on Software Engineering, 2004.
IEEE. Software Engineeirng Body of Knowledge (SWEBoK). Institute of Electrical and
Electronics Engineers. Computer Society, Los Alamitos, California, EUA, 2001.
ISO/IEC - International Organization for Standardization and International Electrotechnical
Commission. ISO/IEC 15939:2002 Software engineering – Software measurement process,
2002.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
126
ISO/IEC 12207, 2008 - International Organization for Standardization and International
Electrotechnical Commission. ISO/IEC 12207:2008 Systems and Software Engineering -
Software Life Cycle Processes, 2008.
ISO/IEC 15504-1, 2004 - International Organization for Standardization and International
Electrotechnical Commission. ISO/IEC 15504-1: Information Technology - Process
Assessment – Part 1 - Concepts and Vocabulary, Genebra: ISO, 2004.
JONES. Assessment and Control of Software Risks. Prentice Hall, 1994.
JONES, C. Critical Problems in Software Measurement. Version 1, Software ProductivityResearch (SPR), Agosto 1992.
JURAN J. M., GRYNA F. M. Quality Planning and Analysis: From Product Development
Through Use; Mc Graw-Hill, 1970
KAN, S. Metrics and Models in Software Quality Engineering. Addison Wesley ,1995.
KARDEC Et All. Gestão Estratégica e Avaliação do Desempenho. Qualitymark, 2002.
KELVIN, L. Popular Lectures and Addresses, 1989 http://www-history.mcs.st-
andrews.ac.uk/history/ Mathematicians /Thomson.html
KENDRICK, T. Identifying and managing project risk: Essential Tools for Failure-proofing
your Project. New York: AMACOM, 2003
KOTONYA, G., SOMMERVILLE, I. Requirements Engineering Processes and Techniques.
John Wiley & Sons, Chichester, UK, 2002.
KRISTEN, G. Total Quality Management with Object Orientation; Magazine: Business
Objects Object Magazine, Março - Abril 1996
KULPA, M; JOHNSON, K. Interpreting the CMMI : a process improvement approach. 2nd
Ed. CRC Press. 2008
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
127
LAMSWEERDE V., A. 2000. Requirements Engineering in the Year 2000: A Research
Perspective. In Proceedings of the 22nd International Conference on Software Engineering
(Limerick, Ireland, Jun. 04 – 11, 2000). ACM Press, New York, NY, 5 – 19.
LEITE, J.C.S.P, Qualidade de Software: Teoria e Prática, Rocha, A. R., Maldonado, J.C. e
Weber, K. C., Prentice Hall, 2001, pp. 238-246, 2001.
LOCONSOLE, A. Measuring the Requirements Management Key Process Area. European
Software Control and Metrics Conference, Londres, Abril 2001.
LOCONSOLE, A., Non Empirical Validation of Requirements Management Measures,Workshop on Software Quality at ICSE02, Orlando, Fl, May 2002.
LOCONSOLE, A., Börstler J. Theoretical Validation and Case Study of Requirements
Management Measures, Umeå University Internal Report, Uminf, July 2003.
LOCONSOLE, A. Empirical Studies on Requirement Management Measures. IEEE 26th
International Conference on Software Engennering, 2004.
LOCONSOLE, A. Definition and Validation of requirement Management Measures. Tese
de Doutorado, UMINF-07.22, 2007.
LOTT, C.M. 1996. Measurement-Based Feedback in a Process-Centered Software
Engineering Environment. PhD Thesis, Internal Report 283/96, Kaiserslautern (1996).
LUDWIG Consulting Services, LLC, Managing Requirements, 2002http://www.jiludwig.com/Requirements_Management.html (acessado em 10/2008)
LUFTMAN, J. Managing the Information Technology Resource. New Jersey (EUA): Pearson
Prentice Hall, 2004.
MAXIMIANO, A. Administração de Projetos: como transformar idéias em resultados. 2ª.
Edição. Atlas, São Paulo (SP), 2002.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
128
MCGARRY, J.; et al. Practical Software Measurement: objective information for decision
makers. 1. ed. Boston: Addison-Wesley, 2002.
MONTEIRO, L. Definição de um Catálogo de Medidas para a Análise de Desempenho deProcesso de Software. Tese de Mestrado, UCB, 2008.
MORESI, E. Metodologia da Pesquisa. Universidade Católica De Brasília, 2004.
NICK, M., ALTHOFF, K. D., TAUTZ, C. Facilitating the Practical Evaluation Organizational
Memories Using the Goal-Question-Metric Technique, Fraunhofer Institute for Experimental
Software Engineering Sauerwiesen 6, D-67661 Kaiserslautern, Germany, 1999http://www.iese.fhg.de/pdf_files/althoff_pub/kaw99-crc.pdf . (Acessado em 10/2008)
OFFEN, R.J., JEFFERY, R. 1997. Establishing Software Measurement Programs. IEEE
Software, 14, 2 (Mar. 1997), 45 – 53.
PARK, E. ROBERT; GOETHERT B. WOLFHART; FLORAC, A. WILLIAM, “GQ(I)M – A
Guidebook”, Software Engineering Institute, p-21, 1996
PAULK, M. C.; et al. The Capability Maturity Model For Software Version 1. 1(CMU/SEI-
93-TR-24). Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA (USA),
1993.
PMBOK. A Guide to the Project Management Body of Knowledge (PMBOK), 3ª. ed.,
Project Management Institute-PMI, Pennsylvania, USA. 2004.
PMI. Project Management Body of Knowledge (PMBoK). Project Management Institute.
Newton Square, PA. EUA, 2004.
PRADO, DARCI SANTOS DO (1998). Planejamento e controle de projetos. Minas Gerais:
Editora de Desenvolvimento Gerencial.
PRESSMAN S. R., Software Engineering, A Practitioner’s Approach, Fifth Edition, McGraw
Hill College, 2004
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
129
PSM. Practical Software Measurement. Disponível em: <http:/ /www.psmsc.com>. Acesso em
20/09/2008.
ROSENBERG, L. H.; HYATT, L. E. Developing a Successful Metrics Program, presented at the
International Conference on Software Engineering, Wednesday April 24, 1995.
RUP – The Rational Unified Process – an Introduction, Philippe Kruchten. Addison-Wesley,
1998. ISBN: 0-201-60459-0.
SANDERS J., CURRAN E. A Framework for Sucess in Software Development and Support;
Addison-Wesley Publishing Company, 1994
SAUNDERS, Anthony Administração de Instituições Financeiras, tradução de Antônio
Zoratto Sanvicente, São Paulo:Atlas, 2000.
SEI – Software Engineering Institute. Applications of the Indicator Template for
Measurement and Analysis. Pittsburgh, PA, EUA 2004. Disponível em:
<http://www.sei.cmu.edu/pub/documents/04.reports/pdf/04tn024.pdf>. Acesso em: 19/10/2008.
SEI – Software Engineering Institute. The State of Software Measurement Practice: Results
of 2006 Survey. Pittsburgh, PA, EUA 2006. Disponível em:
<http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr009.pdf>. Acesso em: 10/09/2008.
SEI. SOFTWARE ENGINEERING INSTITUTE. CMMI for Development (CMMI-DEV),
Version 1.2, Technical report CMU/SEI-2006-TR-008. Pittsburgh, PA: Software Engineering
Institute, Carnegie Mellon University, 2006.
SHENHAR, Aaron. Mapping the Dimension of Project Success. School of Technology
Management, Stevens Institute of Technology. Hoboken, NJ, EUA, 1997. STANDISH
GROUP. Chaos Chronicles 3.0. The Standish Group International, Inc. EUA, 2003.
SOFTEX - Associação para Promoção da Excelência do Software Brasileiro. MPS.Br –
Melhoria de Processo do Software Brasileiro – Guia Geral (Versão 1.2). Brasília, DF, 2007.
Disponível em: < http://www.softex.br/mpsbr/_guias/MPS.BR_Guia_Geral_V1.2.pdf >. Acesso
em: 27/10/2008.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
130
SOLINGEN, V. RINI, BERGHOUT, EGON, The Goal/Question/Metric Method: a practical
guide for quality improvement of software development, MCGraw Hill Companies, p-39,
1999
Standish Group International, Inc. EUA, 2008 Chaos Report 2007. Pesquisa publicada pelo
Standish Group International. Disponível em:
<http://www.standishgroup.com/sample_research/>. Acesso em: 12/06/2008.
STEPANEK, G. Software Project Secrets: Why software Projects Fail, Apress, Vol. 1, 2005.
TAKASHINA & FLORES. Indicadores da qualidade e do desempenho – como estabelecermetas e medir resultados, Qualitymark Editora, 1996.
WIEGERS, K. Introdução a Métricas de Software. Newsletter BFPUG www.bfpug.com.br,
Janeiro 2001.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
131
APÊNDICE A - PROCESSO DE GERAÇÃO DE INDICADORES PARA A GESTÃO DEREQUISITOS - PGIGR
Propósito do processo:
O propósito do processo é sistematizar a geração de indicadores para a gestão de
requisitos de projetos de desenvolvimento de software. Essa sistematização
define todas as atividades necessárias para a execução do PGIGR. A Tabela 14demonstra uma síntese dos objetivos do PGIGR no formato do GQM1.
Tabela 14 - Objetivo do PGIGR – formato GQM
Analisar: As atividades de gestão de requisitos
Com o propósito de: Entender, controlar e aprimorar
Com respeito a: Qualidade, custo, tempo e risco
Do ponto de vista: Dos patrocinadores e gerentes de projetos
No contexto: Do desenvolvimento e manutenção de software
Os Subprocessos do processo PGIGR
No intuito de melhor entender o PGIGR, ele foi dividido em subprocessos. Os
subprocessos do PGIGR podem ser representados conforme Figura 21.
1 GQM – Goal Question Metric é um tipo de abordagem para definição de indicadores.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
132
Figura 21 - Subprocessos do PGIGR
A seguir é feita uma breve descrição sobre cada um dos subprocesso. Cada um deles será
detalhado posteriormente.
1. Categorizar o Processo de Software
Este subprocesso é executado no início do ciclo do processo. Ele tem como
objetivo categorizar o processo de software da organização de TI de acordo com
características definidas como relevantes para uma correta gestão de indicadores
de requisitos. Nesta etapa as características definidas visam classificar a
organização para se ter um correto direcionamento na definição de indicadores.
Para isso o PGIGR propõe quatro categorias de classificação: Inicial,Entendimento, Controle e Aprimoramento.
Inicial: A organização não possui os requisitos básicos necessários para se
enquadrar na categoria Entendimento. Ela deve amadurecer alguns aspectos do
seu processo de desenvolvimento de software antes de passar para a próxima
categoria. Os aspectos que devem ser amadurecidos são detalhados
posteriormente.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
133
Entendimento: Nesta categoria a organização possui um conjunto uma
organização que permite a geração de indicadores que darão maior visibilidade e
entendimento da situação atual dos projetos de desenvolvimento de software da
organização no que tange a gestão de requisitos.
Controle: Os indicadores gerados nesta categoria têm o intuito de serem
utilizados durante a execução do projeto, permitindo que o gerente tenha maior
controle do projeto comparando os resultados obtidos com os resultados
históricos, podendo assim tomar ações corretivas durante a execução dos projetos.
Aprimoramento: O objetivo da categoria Aprimoramento é permitir que uma
organização avalie a evolução da gestão de requisitos a partir dos aprimoramentos
realizados no seu processo de desenvolvimento de software. Os indicadores
gerados nesta categoria darão uma visão do comportamento do processo antes e
depois das medidas de aprimoramento. Isso indica que esses indicadores deverão
ser avaliados após a conclusão dos projetos.
2. Definir Foco dos Indicadores
Este subprocesso tem como objetivo definir o foco da organização para a geração
de indicadores. As opções de foco propostas pelo PGIGR para serem selecionadas
pela organização visando direcionar a geração de indicadores são: tempo, custo,
qualidade e risco. A escolha de um foco visa direcionar os indicadores para
aquilo que é mais relevante para organização.
3. Definir Objetivos (Metas)
Este subprocesso visa definir os objetivos da organização de TI no que tange a
gerência de requisitos, de acordo com a sua categorização e dimensão foco
previamente selecionadas.
4. Definir Perguntas
Este subprocesso visa definir perguntas que estejam alinhadas com o atendimento
dos objetivos previamente traçados. Ao responder as perguntas deve ser possível
concluir se o objetivo foi ou não atingido.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
134
5. Definir Indicadores
Este subprocesso tem como objetivo definir indicadores que irão responder as
perguntas. Ao interpretar os indicadores deve ser possível avaliar se as perguntas
foram respondidas e os objetivos alcançados. Para auxiliar na geração de
indicadores, o PGIGR apresenta um guia para construção e manutenção de
indicadores.
O Aprimoramento do Processo de Software não é um subprocesso do PGIGR, mas
torna-se necessário dentro do ciclo proposto pelo PGIGR, para que a organização de TI possaevoluir entre as diferentes categorias propostas (Inicial, Entendimento, Controle e
Aprimoramento), permitindo assim a geração de indicadores mais robustos de acordo com a
evolução das necessidades da organização.
Cada um dos subprocessos do PGIGR é composto por um conjunto de atividades. Os
subprocessos e suas atividades estão identificados na Tabela 15 e detalhadas no detalhadas no
corpo do processo.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
135
Tabela 15 - Subprocessos e Atividades do PGIGR
Processo PGIGRSubprocessos Atividades
Categorizar o processo de software da Organização de TI
Definir os Envolvidos
Definir Categoria
Definir Foco dos IndicadoresDefinir a Dimensão Foco para a geração de
indicadores.
Definir Objetivos (Metas)
Selecionar objetivos pré-definidos para Gestão
de Requisitos.Criar Objetivo(s)
Definir Perguntas (Questões)Selecionar perguntas pré-definidas
Criar Pergunta(s)
Definir Indicadores
Selecionar Indicadores pré-definidos
Descrever o Indicador
Estruturar o Indicador
Divulgar/aprimorar o Indicador
As diferentes atividades listadas acima são executadas por diferentes papéis. Os papéis
utilizados no PGIGR para executar cada uma das atividades, assim como suas principais
atribuições, estão listados na Tabela 16 a seguir.
Os papéis apresentados foram extraídos do RUP2. Os papéis apresentados não implicam
que a organização necessariamente precisa ter indivíduos específicos para exercê-los. Um papel
pode ser exercido por um ou mais indivíduos em um determinado período de tempo e um
indivíduo pode exercer mais de um papel. O importante é que o indivíduo ou grupo de
indivíduos que exerça um determinado papel tenha as habilidades necessárias para executar as
atividades que lhe foram atribuídas. Na Tabela 16 são descritas as habilidades necessárias para
cada papel.
2 RUP - Abreviação de Rational Unified Process (ou Processo Unificado da Rational, fornece técnicas a seremseguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
136
Tabela 16 – Definição de Papéis e Habilidades necessárias para o PGIGR
Papel Descrição de Habilidades Recomendadas
Gerente de Projetos
Experiência em projetos de desenvolvimento de software. Boa comunicação escrita e verbal. Capacidade para análise de riscos e tomada de decisões. Liderança e construção de times.
Analista de Requisitos
Boa comunicação escrita e verbal. Conhecer de forma satisfatória o negócio que abrange o
sistema. Conhecer a tecnologia envolvida na solução do sistema.
Analista de Métricas
Conhecimento básico em processos e metodologias demétricas e indicadores.
Conhecimento de técnicas de medição de tamanho desoftware.
Engenheiro de Processo
Conhecimentos aprofundados em engenharia de software. Adaptar processo de software de acordo com as
necessidades da instituição. Apoiar a equipe de desenvolvimento no que tange a
engenharia de software.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
137
Descrição dos Subprocessos
Cada subprocesso é descrito por um conjunto de atividades. Cada atividade serádetalhada conforme Tabela 17 a seguir.
Tabela 17 - Itens para detalhamento de uma atividade3
Nome da atividade Identifica a atividade através de um nome
Descrição Descreve a atividade
Pré-atividade Atividade que deve ser executada antes da atividade em questão
Critério de Entrada Critérios necessários a serem atendidos para que a atividade seja iniciada
Critério de Saída Critérios necessários a serem atendidos para que a atividade seja
considerada finalizada
Responsável Quem responde pela execução da atividade
Participantes Quem são os envolvidos na execução da atividade
Produtos Requeridos Relaciona os insumos necessários para executar a atividade Produtos Gerados Relaciona os produtos que foram produzidos na execução da atividade
Pós-atividade Relaciona a atividade que deve ser executada, após esta ser finalizada
3 A estrutura de detalhamento de atividades é baseada no processo MPS.Br – Melhoria de Processo do SoftwareBrasileiro – Guia Geral (Versão 1.2).
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
138
Subprocesso:Categorizar o Processo deSoftware da Organização
de TI
Processo de Geração de Indicadores para a Gestão de Requisitos (PGIGR)
O propósito do subprocesso Categorizar o Processo de Software da Organização de TI é
avaliar algumas características do processo de software da organização visando classificá-la.
Neste subprocesso a organização avalia a existência de características definidas como relevantes
pelo PGIGR para uma correta geração de indicadores para a gestão de requisitos. O intuito final
é categorizar (classificar) a organização.
O objetivo é melhor direcionar a geração de indicadores para a gestão de requisitos, de
acordo com as características e necessidades atuais da organização de TI. Para isso o PGIGR
propõe uma hierarquia contendo quatro categorias, conforme Figura 22
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
139
Figura 22 – Categorias de Classificação do Processo de Software da Organização de TI
Essa hierarquia demonstra que é preciso, antes de definir indicadores para umaorganização de TI, categorizar (classificar) o seu processo de desenvolvimento de software de
acordo com algumas características importantes para a definição e manutenção de indicadores de
gestão de requisitos. Isso tem como objetivo evitar que organizações definam indicadores que
estão além do que o seu processo atual e/ou infra-estrutura pode suportar.
Isso permitirá um melhor entendimento do processo de desenvolvimento de software para
então direcionar a geração de indicadores consistentes. Como exemplo, pode-se dizer que nãoadianta uma organização querer definir indicadores para aprimorar o seu processo de gerência de
requisitos se ela não possui uma infra-estrutura necessária para tal. Isso provavelmente
acarretaria na geração de informações ambíguas e inconsistentes.
Os indicadores propostos na categoria Entendimento têm o intuito de dar uma
visibilidade e maior entendimento da situação atual dos projetos de desenvolvimento de software
da organização no que tange a gestão de requisitos. Já os indicadores propostos na categoria
Controle têm o intuito de serem utilizados durante a execução do projeto, permitindo que o
gerente tenha maior controle do projeto e possa tomar medidas corretivas durante a execução do
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
140
mesmo. Os indicadores propostos para a categoria Aprimoramento darão uma visão do
comportamento do processo antes e depois das medidas de aprimoramento. Isso sugere que esses
indicadores deverão ser avaliados após a conclusão dos projetos.
Este subprocesso é composto por duas atividades: Definir os Envolvidos, e Definir
categoria. Na Figura 23 é apresentado o diagrama do subprocesso com as atividades, artefatos e
responsabilidades.
Figura 23 - Subprocesso para Categorizar a Organização de TI
A seguir segue o detalhamento das duas atividades contidas no subprocesso Categorizar o
Processo de Software da Organização de TI.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
141
Atividade: Definir os Envolvidos
Descrição: O engenheiro de processo da organização de TI (ougrupo de indivíduos que esteja exercendo esse papel) fazuma reunião com os gerentes de projetos para definir oindivíduo (ou indivíduos) que irá categorizar o processode desenvolvimento de software da organização de TI.
Observação: Caso o(s) gerente(s) e o grupo de melhoriade processos da organização tenham conhecimento sobreo processo de software, eles mesmos podem realizar acategorização da organização.
Pré-atividade: --Critério de Entrada: Ter o patrocínio da organização em investir esforços
adicionais para gerar informações com o intuito deaprimorar seus projetos no que tange a gerência derequisitos.
Critério de Saída: Identificação do(s) indivíduo(s) que irá(ão) categorizar oprocesso de desenvolvimento de software daorganização de TI.
Responsável: Engenheiro de Processo (EP)
Participantes: Engenheiro de Processo (EP) e Gerentes de Projetos(GP)
Produtos Requeridos: --
Produtos Gerados: Responsável(eis) pela categorização da OrganizaçãoDefinido(s) e divulgado.
Ferramentas: Email e Editor de textos.
Pós-atividade: Definir Categoria
Atividade: Definir Categoria
Descrição: Categorizar o processo de desenvolvimento de software da organização de TI utilizando a matriz contida naTabela 18 a seguir. Uma vez feito isso é necessário queos envolvidos se reúnam e cheguem a um consenso emqual das quatro categorias se enquadra a organizaçãoavaliada. É de extrema importância que essa
classificação esteja correta, pois ela irá direcionar todosos demais passos do PGIGR.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
142
Atividade: Definir Categoria
Pré-atividade: Definir os envolvidos
Critério de Entrada: Ter os envolvidos na categorização identificados
Critério de Saída: Organização categorizada (classificada) em um dosquatro níveis propostos (Inicial, Entendimento, Controleou Aprimoramento).
Responsável: Responsável(is) pela categorização da organização (RP)
Participantes: Responsável(is) pela categorização da organização (RP)
Produtos Requeridos: Matriz de Categorização da Organização de TI (Tabela18)
Produtos Gerados: Organização de TI categorizada em um dos quatroníveis: Inicial, Entendimento, Controle ouAprimoramento.
Ferramentas: Email e Editor de textos.
Pós-atividade: Definir Foco dos Indicadores
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
143
Considerações sobre a atividade Definir Categoria
Tabela 18 - Matriz de Categorização do processo de software da Organização de TI
CATEGORIZAR O PROCESSO DE SOFTWARE DA ORGANIZAÇÃO DE TI
1º - INICIAL 2º - ENTENDIMENTO 3º - CONTROLE 4º - APRIMORAMENTO
A organizaçãonão possui osrequisitos
necessáriospara seenquadrar acategoriaEntendimento
A organização possuipráticas de gerência deprojetos de
desenvolvimento desoftware; eA organização possuiferramenta para controlede atividades dosprojetos. (Ex.: MicrosoftProject); eA organização possuipráticas de gerência derequisitos; eA organização utilizapráticas e ferramentas decontrole de versão para
os artefatos de requisitos;eA organização possuipráticas de medição detamanho de software.
A organização possuiuma base histórica demétricas e indicadores; e
A organização possuium processopadronizado degerência de requisitos; eA organização possuium processopadronizado degerência de projetos
A organização possuiuma baseline dedesempenho do
processo de requisitos;
Caso a organização não possua as características necessárias para ingressar na categoria
Entendimento, sugere-se que ela primeiro adéque os aspectos do seu processo de
desenvolvimento de software antes de ingressar no processo, ficando, a princípio, na categoriaInicial, conforme representado na Figura 22 acima. Isso porque o PGIGR identificou um
conjunto mínimo de organização e infra-estrutura necessária para que os indicadores de
requisitos possam ser gerados de forma consistente e, para isso, faz-se necessário adequar o
processo de desenvolvimento de software da organização para atender as características
propostas na categoria Entendimento.
Para que a organização enquadre-se na categoria Entendimento é importante que haja
um consenso entre os envolvidos na avaliação de que todas as características estão presentes no
processo de software da organização. Caso alguma das características não seja constatada e a
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
144
organização mesmo assim decida ingressar nessa categoria, ela corre o risco de: não conseguir
gerar determinados indicadores, gerar informações inconsistentes e despender um esforço muito
grande para conseguir gerar e manter os indicadores. Para que isso não ocorra, o PGIGR sugere
que a organização fique na categoria Inicial até que o seu processo de software esteja de acordo
com as características apresentadas na Tabela 18.
Vale ressaltar que o fato da organização não possuir todas as características exigidas pela
categoria Entendimento não significa que ela não conseguirá utilizar alguns indicadores
propostos. Talvez seja possível gerar alguns indicadores, porém a organização corre o risco de
despender um esforço muito grande para gerá-los e mantê-los, além de correr o risco de gerar
informações inconsistentes e ambíguas.
Observações: É importante ressaltar que as características apresentadas na Matriz de
Categorização da Organização – Tabela 18 – são acumulativas, isto é, para que uma
organização passe de uma categoria para a outra é necessário que as características das categorias
anteriores estejam todas presentes, caso contrário, ela estará impossibilitada, ou terá
dificuldades, em gerar os indicadores propostos nas categorias superiores.
Para se enquadrar na categoria de Controle é importante que a organização tenha um
conjunto satisfatório de dados históricos (repositório de medidas 4) coletados na categoria de
Entendimento. Dessa forma o PGIGR sugere que a organização possua um conjunto mínimo de
indicadores coletados de pelo menos três projetos similares já concluídos. O intuito é que haja
um conjunto de informações para gerar dados comparativos entre projetos que apresentam
semelhanças, visando gerar indicadores que permitam a tomada de ações corretivas durante a
execução dos projetos. Também é necessário ter um processo de gerência de requisitos e degerência de projetos padronizados para que a coleta e comparação dos indicadores sejam feitas a
partir de projetos que seguiram processos equivalentes.
4 Um repositório de medidas para a organização deve conter medidas dos processos e
produtos relacionados ao conjunto de processos padrão da organização, além de informaçõesnecessárias para entender e interpretar as medidas.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
145
A quarta e última categoria, Aprimorar, tem como objetivo gerar indicadores que
permitam visualizar o aprimoramento do processo de gerência de requisitos após a implantação
de melhorias no processo. Esses indicadores visam aferir se determinada ação corretiva no
processo gerou ou não resultados positivos. Para que isso seja possível é sugerido que a
organização já tenha um conjunto de 20 medições de um determinado indicador (baseline)
coletado na categoria de Controle. Os indicadores gerados nesta categoria darão uma visão do
comportamento do processo antes e depois das medidas de aprimoramento. Isso indica que esses
indicadores deverão ser avaliados após a conclusão dos projetos.
Considerações finais sobre o subprocesso Categorizar o Processo de Software da
Organização de TI
É importante que a organização identifique com clareza onde ela se encontra, pois os
demais passos do PGIGR dependem da correta classificação executada neste subprocesso. Uma
falha de classificação pode acarretar na tentativa de gerar indicadores que estão além da
capacidade atual da organização de TI, o que acarretaria na geração de informações
inconsistentes.
Outra visualização das etapas de categorização do processo de desenvolvimento de
software da organização de TI pode ser feita através da Figura 24 a seguir.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
146
Figura 24 - Visão Macro do Processo de Categorização da Organização de TI
As setas pontilhadas na figura acima demonstram que uma organização pode ter vários
ciclos de definição de indicadores em uma mesma categoria, não sendo necessário passar para
categorias superiores para que novos indicadores sejam gerados. Porém vale lembrar queindicadores das categorias de Controle e Aprimoramento necessitam de dados históricos e de
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
147
certo grau de padronização para que possam ser criados. Para isso são necessários ajustes no
processo de desenvolvimento de software da organização.
Subprocesso: DefinirFoco dos Indicadores
Processo de Geração de Indicadores para a Gestão de Requisitos (PGIGR)
Uma vez concluída a categorização do processo de desenvolvimento de software da
organização de TI, é necessário definir qual é o foco da geração de indicadores para a gestão de
requisitos. O PGIGR propõe quatro focos, que foram denominados dimensões foco. Eles tem o
intuito de direcionar a geração de indicadores que a organização considera mais relevantes, de
acordo com seu contexto e necessidades. São eles:
1. Tempo2. Custo3. Qualidade4. Riscos
O relacionamento entre as quatro dimensões focos pode ser visualizado conforme Figura25.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
148
Figura 25 - Quatro Dimensões Focos para a geração de indicadores
Este subprocesso é composto por uma atividade: Definir Dimensão Foco para Geração
de Indicadores. Na Figura 26 é apresentado o diagrama do subprocesso com as atividades,
artefatos e responsabilidades.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
149
Figura 26 - Subprocesso para Definir Foco para Definição de Indicadores
A seguir é detalhada a atividade contida no subprocesso Definir Dimensão Foco.
Atividade: Definir Dimensão Foco para a criação de Indicadores
Descrição: O engenheiro de processo da organização de TI (ougrupo de indivíduos que esteja exercendo esse papel),assim como o Analista de Requisitos e Gerentes deProjetos da organização devem discutir em conjunto epriorizar as quatro dimensões foco (tempo, custo,
qualidade e risco) de acordo com as principaisnecessidades identificadas na organização de TI no quetange a gerência de requisitos.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
150
Atividade: Definir Dimensão Foco para a criação de Indicadores
É sugerido, preferencialmente, escolher apenas uma dasquatro dimensões foco, principalmente aquelas
organizações que foram classificadas emEntendimento. Esse direcionamento tem como objetivoprincipal não dispersar os esforços ou gerarinconsistências na geração das informações e nasinterpretações das mesmas. A escolha de mais de umadimensão foco, visando a geração de indicadores, pode influenciar umas nas outras, o que pode dificultar nainterpretação e nos resultados obtidos através dosindicadores.
Sugere-se que, à medida que a organização vai
amadurecendo no processo, ela, eventualmente, poderádefinir mais de uma dimensão foco por ciclo.
Ao final desta atividade deve ser o foco da geração dosindicadores definido. Para auxiliar nesta tarefa, oPGIGR sugere a utilização da Matriz contendo asdimensões foco e descrição para cada uma dascategorias (Tabela 19).
Observação: As dimensões foco estão relacionadas umasàs outras. Um exemplo disso é um indicador de
qualidade, que à medida que for sendo utilizado natomada de decisão, indiretamente pode impactar nosindicadores de risco, custo e tempo.
Pré-atividade: Categorização do processo de software da Organizaçãode TI.
Critério de Entrada: Ter o correto entendimento da classificação em que oprocesso de desenvolvimento de software daorganização de TI de acordo com os quatro categorias
Critério de Saída: Consenso entre os envolvidos de que a dimensão focoselecionada é a mais prioritária para a organizaçãonaquele determinado momento.
Responsável: Engenheiro de Processo (EP)
Participantes: Engenheiro de Processo (EP), Analistas de Requisitos(AR) e Gerentes de Projetos (GP)
Produtos Requeridos: Informações de problemas e riscos enfrentados emprojetos antigos (se existentes).
Categorização da organização de TI.
Matriz contendo as dimensões foco e descrição paracada uma das categorias.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
151
Atividade: Definir Dimensão Foco para a criação de Indicadores
Produtos Gerados: Dimensão foco selecionada
Ferramentas: Email e Editor de textos.
Pós-atividade: Definir Objetivos (Metas) para a dimensão focoselecionada.
Considerações sobre a atividade Definir Dimensão Foco para a criação de Indicadores
O PGIGR propõe que a organização deve avaliar suas características, necessidades e
questionar o que é mais prioritário para ela no que tange a gestão de requisitos, de acordo com
sua categorização previamente definida. Nesse sentido as dimensões foco devem ser avaliadasutilizando-se a Tabela 19.
Tabela 19 – Matriz contendo as dimensões foco e descrição para cada uma das categorias
Dimensão
FocoCategoria Descrição
R I S C
O
EntendimentoA organização necessita melhor entender os riscos relacionados à
gerência de requisitos nos projetos de software.
Controle A organização necessita melhor monitorar os riscos relacionados àgerência de requisitos nos projetos de software.
AprimoramentoA organização deseja minimizar os riscos relacionados à gerência de
requisitos nos projetos de software.
T E M P
O
EntendimentoA organização necessita melhor entender o tempo/esforço despendido
nas atividades de requisitos em projetos de software.
ControleA organização necessita melhor monitorar o tempo/esforço despendido
nas atividades de requisitos em projetos de software.
AprimoramentoA organização deseja reduzir o tempo/esforço despendido nas
atividades de requisitos em projetos de software.
C U S T O
Entendimento A organização necessita melhor entender os custos despendidos nasatividades de requisitos em projetos de software.
ControleA organização necessita melhor monitorar os custos despendidos nas
atividades de requisitos em projetos de software.
AprimoramentoA organização deseja reduzir os custos despendidos nas atividades de
requisitos em projetos de software.
Q U A
L I D A D E
EntendimentoA organização necessita melhor entender a qualidade dos produtos
gerados pelas atividades de requisitos em projetos de software.
ControleA organização necessita melhor monitorar a qualidade dos produtos
gerados pelas atividades de requisitos em projetos de software.
AprimoramentoA organização deseja aprimorar a qualidade dos produtos gerados
pelas atividades de requisitos em projetos de software.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
152
Subprocesso: DefinirObjetivos (Metas)
Processo de Geração de Indicadores para a Gestão de Requisitos (PGIGR)
Uma vez definida a dimensão foco é necessário definir os objetivos (metas) para ela. Este
subprocesso é composto por duas atividades: Selecionar o(s) objetivo(s) pré-definidos para a
Gerência de Requisitos e Criar Objetivo(s). Na Figura 27 a seguir é apresentado o diagrama do
subprocesso com as atividades, artefatos e responsabilidades.
Subprocesso – Definir Objetivos (Metas)
Definir Objetivos (Meta)Legenda
Objetivo nãoselecionado
Objetivo(s)Definido(s)
Papéis:zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzGP – Gerentes de Projetos
AM – Analista de Métricas
EP – Engenheiro de Processo
AR – Analista de Requisitos
Artefatos: zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzMTO – Matriz contendo os objetivos para cada categoria e
dimensão focoOBJ - Objetivo(s)DMF - Dimensão Foco
Criar Objetivo(s)
GPAMEPAR
Selecionar Objetivo(s)pré-definido(s) para aGestão de Requisitos
GPAMEPAR
Dimensão FocoDefinida
Símbolos
Início ou fim do processo
Atividades do processo
Papel
Produto requerido
Produto gerado
MTODMF
MTO
OBJ
OBJ
ObjetivoSelecionado
Figura 27 – Subprocesso para Definir Objetivos (Metas)
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
153
A seguir são detalhadas as duas atividades contidas no subprocesso Definir Objetivos.
Atividade: Selecionar objetivo(s) pré-definidos para a Gestão deRequisitos
Descrição: O engenheiro de processo da organização de TI, assimcomo o analista de métricas, gerentes de projetos eanalistas de requisitos devem discutir a matriz contendoos objetivos pré-definidos pelo PGIGR (Tabela 20 aseguir). Deve-se analisar se os objetivos apresentadosatendem às necessidades da organização para a categoriae dimensão foco previamente definidos.
A Figura 27 indica que, caso todos os objetivo
almejados pela organização estejam na matriz deObjetivos (metas) propostas pelo PGIGR na Tabela 20, deve-se pular a atividade Criar Objetivos.
Se for necessário definir ou refinar algum dos objetivos,deve-se seguir para a próxima atividade.
Pré-atividade: Definir Dimensão Foco.
Critério de Entrada: Ter o processo de software da organização categorizado
Ter a dimensão foco selecionada.
Critério de Saída: Consenso entre os participantes de que os objetivoselecionado está aderente às necessidades daorganização e de acordo com a dimensão focopreviamente selecionada.
Responsável: Analista de Métricas (AM)
Participantes: Engenheiro de processo da organização de TI (EP),analista de métricas (AM), gerentes de projetos (GP) eanalistas de requisitos (AR).
Produtos Requeridos: Matriz contendo os objetivos para cada dimensão foco(Tabela 20).
Produtos Gerados: Lista contendo os objetivos traçados pela organização deTI para a gerência de requisitos, de acordo com adimensão foco selecionada.
Ferramentas: Email e Editor de textos.
Pós-atividade: Criar Objetivo(s).
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
154
Considerações sobre a atividade Selecionar os objetivos da Organização de TI para a
Gerência de Requisitos
O PGIGR apresenta uma matriz (Tabela 20 a seguir) onde cada uma das categorias(Entendimento, Controle e Aprimoramento) foi cruzada com cada uma das dimensões foco
(Tempo, Custo, Qualidade e Risco). Para cada categoria/dimensão foco foi definido um
objetivo, que a organização pode selecionar.
Tabela 20 – Matriz contendo sugestões de objetivos (metas) para cada categoria e dimensão foco
OBJETIVOS (Metas)
Categoria
Dimensão
Foco
ENTENDIMENTO CONTROLE APRIMORAMENTO
TEMPO (T)
Conhecer o esforçoe/ou prazo necessáriopara executar asatividades de requisitos.(Meta T1)
Monitorar e controlarse o esforço e/ou prazodas atividades derequisitos estão dentrodos valoresestipulados. (Meta T2)
Reduzir o esforço e/ouprazo para executar asatividades derequisitos. (Meta T3)
CUSTO (C)
Conhecer o custodespendido paraexecutar as atividadesde requisitos. (MetaC1)
Monitorar e controlarse os custos dasatividades de requisitosestão dentro dosvalores estipulados.(Meta C2)
Reduzir os custos dasatividades derequisitos. (Meta C3)
QUALIDADE (Q)Conhecer a qualidadedos artefatos derequisitos. (Meta Q1)
Monitorar e controlarse a qualidade dosartefatos de requisitosestá dentro dos valoresestipulados. (Meta Q2)
Aprimorar a qualidadedos artefatos derequisitos e minimizarretrabalho. (Meta Q3)
RISCO (R)
Entender os riscos
relacionados aogerenciamento derequisitos (Meta R1)
Monitorar e controlar
os riscos relacionadosao gerenciamento dosrequisitos (Meta R2)
Reduzir os riscos
relacionados aogerenciamento dosrequisitos (Meta R3)
O conteúdo contido entre parênteses após cada objetivo é para permitir a correta
identificação e posterior rastreabilidade entre os objetivos e os indicadores. Cada objetivo inicia
com a primeira letra da dimensão foco e tem um seqüencial numérico, de acordo com o
quantitativo de objetivos criados para cada categoria/dimensão foco.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
155
Atividade: Criar Objetivos
Descrição: Caso o objetivo traçado pela organização de TI nãoesteja presente na Tabela 20, o engenheiro de processo
da organização de TI, assim como o analista de métricas,gerentes de projetos e analistas de requisitos, devemcriar um ou mais objetivos, de acordo com asnecessidades.
Nesta atividade é importante que o grupo faça umbrainstorm de todos os objetivos que podem sertraçados, de acordo com a categoria da organização edimensão foco previamente selecionados. É importanteque o grupo estabeleça objetivos factíveis de serematingidos, de acordo com a categorização da organização
e aderente à dimensão foco previamente selecionada.
Observação: Sugere-se que a organização trabalhe comum conjunto limitado de objetivos, com o intuito demanter o foco.
Pré-atividade: Selecionar os objetivos pré-definidos para a Gerência deRequisitos
Critério de Entrada: Matriz contendo os objetivos para cada categoria edimensão foco.
Critério de Saída: Consenso entre os participantes de que os objetivosdefinidos estão claros e são factíveis de serem atingidospela organização.
Responsável: Analista de Métricas (AM)
Participantes: Engenheiro de processo da organização de TI (EP),analista de métricas (AM), gerentes de projetos (GP) eanalistas de requisitos (AR).
Produtos Requeridos: Matriz contendo os objetivos para cada categoria e
dimensão foco.Produtos Gerados: Lista contendo o(s) objetivo(s) da organização de TI
para a gerência de requisitos, de acordo com a dimensãofoco e categoria previamente definidas.
Ferramentas: Email e Editor de textos.
Pós-atividade: Criar Perguntas.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
156
Subprocesso: DefinirPerguntas (Questões)
Processo de Geração de Indicadores para a Gerência de Requisitos (PGIGR)
Uma vez definidos os objetivos (metas), devem ser definidas as perguntas que precisam
ser respondidas para determinar se o objetivo foi ou não alcançado. Este subprocesso é composto
por duas atividades: Selecionar perguntas pré-definidas e Criar Pergunta(s). Na Figura 28 a
seguir é apresentado o diagrama do subprocesso com as atividades, artefatos e responsabilidades.
Subprocesso – Definir Perguntas (Questões)
Definir Perguntas (Questões)Legenda
Pergunta nãoselecionada
PerguntasDefinidas
Papéis:zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzGP – Gerentes de Projetos
AM – Analista de métricas
AR – Analista de Requisitos
Artefatos: zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzMTP – Matriz contendo as perguntas para cada categoria e
dimensão focoOBJ - Objetivo(s)PGT - Pergunta(s)
Criar Perguntas(s)
GMGP
AR
Selecionarpergunta(s) pré-
definida(s)
AMGPAR
ObjetivosDefinidos
PGT
Símbolos
Início ou fim do processo
Atividades do processo
Papel
Produto requerido
Produto gerado
OBJMTP
MTP
PGT
Pergunta
Selecionada
Figura 28 - Subprocesso para Definir Perguntas (Questões)
A seguir são detalhadas as duas atividades contidas no subprocesso Definir Perguntas.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
157
Atividade: Selecionar perguntas pré-definidas.
Descrição: O Analista de métricas, gerentes de projetos e analistasde requisitos devem discutir em conjunto a matrizcontendo as perguntas pré-definidas pelo PGIGR(Tabela 21 a seguir). Deve-se analisar se as perguntasestão alinhadas com os objetivos traçados previamente ese atendem às necessidades da organização de TI.
A Figura 28 indica que caso a pergunta necessária paraavaliar o atendimento do objetivo esteja na matriz dePerguntas proposta pelo PGIGR (Tabela 21), deve-sepular a atividade Criar Perguntas.
É importante ter em mente que é através das respostas àsperguntas que será possível definir se o objetivo foi ounão atingido, sendo as perguntas o elo de conexão entreos objetivos e indicadores.
Se for necessário definir ou refinar alguma dasperguntas, deve-se seguir para a próxima atividade.
Pré-atividade: Criar Objetivos.
Critério de Entrada: Ter os objetivos definidos.
Critério de Saída: Consenso entre os participantes de que as perguntasdefinidas estão aderentes aos objetivos traçados e deacordo com a dimensão foco previamente selecionada.
Responsável: Analista de Métricas (AM)
Participantes: Analista de Métricas (AM), Gerentes de Projetos (GP) eAnalistas de Requisitos (AR)
Produtos Requeridos: Objetivo(s) definido(s).
Matriz de Perguntas
Produtos Gerados: Lista contendo todas as perguntas da organização de TIpara os objetivos traçados, de acordo com a dimensãofoco e categoria previamente definidos.
Ferramentas: Email e Editor de textos.
Pós-atividade: Definir as Perguntas.
Considerações sobre a atividade Selecionar Pergunta(s) pré-definidas
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
158
O PGIGR apresenta uma matriz (Tabela 21) onde cada uma das categorias
(Entendimento, Controle e Aprimoramento) foi cruzada com cada uma das dimensões foco
(Tempo, Custo, Qualidade e Risco). Para cada categoria/dimensão foco foram definidas
perguntas que a organização pode utilizar, adequar ou criar novas, conforme as suas
necessidades. Cada pergunta deve estar necessariamente relacionada a um objetivo.
Tabela 21 - Matriz contendo sugestão de Perguntas (Questões) para cada categoria e dimensão foco
PERGUNTAS (Questões)
Categorias
Dimensão
Foco ENTENDIMENTO CONTROLE APRIMORAMENTO
TEMPO (T)
Qual o esforço ouprodutividade nasatividades de requisitos?(T1.P1)
O esforço ou produtividadedas atividades de requisitosestá de acordo com osvalores (faixa) esperados?(T2.P1)
O esforço e/ouprodutividade dasatividades de requisitosfoi aprimorado apósações de melhoria?(T3.P1)
CUSTO (C)
Quanto custa paralevantar, analisar edocumentar os requisitos?(C1.P1)
Os custos das atividades derequisitos estão de acordocom os valores (faixas)
esperados? (C2.P1)
Os custos de execuçãodas atividades derequisitos foram
reduzidos após as açõesde melhoria? (C3.P1)
QUALIDADE
(Q)
Qual a quantidade dedefeitos nos artefatos derequisitos? (Q1.P1)Qual o custo de correçãode defeitos nos artefatosde requisitos? (Q1.P2)
A qualidade dos artefatosde requisitos já concluídosestá dentro dos valoresestimados de qualidade?(Q2.P1)Qual o índice de retrabalhodas atividades derequisitos? (Q2.P2)
A densidade de defeitosnos artefatos derequisitos foi reduzidaapós as ações demelhoria? (Q3.P1)
RISCO (R)
Quais os principais riscos
associados às atividadesde requisitos? (R1.P1)Quais riscos associados àsatividades de requisitosestão se concretizandodurante o projeto?(R1.P2)
Os riscos do projeto,relacionados às atividadesde requisitos, estão dentrodas faixas estabelecidas noplanejamento? (R2.P1)
Qual o índice de
aprimoramento dasatividades da gerência derequisitos apósimplantação doscontroles de risco emgerência de requisitos?(R3.P1)
O conteúdo contido entre parênteses após cada pergunta é para permitir a identificação e
rastreabilidade entre os objetivos traçados anteriormente e as perguntas definidas. Cada pergunta
inicia com a primeira letra da dimensão foco e tem um sequencial numérico, de acordo com o
quantitativo de perguntas criadas. Para gerar um relacionamento entre cada objetivo (meta) e as
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
159
perguntas (questões), foi definido um padrão conforme exemplo a seguir: O objetivo de custo
para a categoria Controle (C2) está sendo respondida pela pergunta P1, sendo a pergunta
identificada como C2.P1.
Atividade: Criar Perguntas
Descrição: Caso as perguntas necessárias para avaliar se o objetivo foiatendido não estejam presentes na Tabela 21, ou caso precisem deajustes, o Analista de Métricas, Gerentes de Projetos e Analistasde Requisitos da organização de TI devem definir as perguntasnecessárias para que essa verificação possa ser feita.
É importante que o grupo faça uma brainstorm para levantartodas as perguntas que precisam ser respondidas para aferir oatendimento dos objetivos. Deve-se estabelecer perguntasaderentes aos objetivos previamente definidos.
Deve ser feita a rastreabilidade entre as perguntas elaboradas e osobjetivos traçados, relacionando cada pergunta ao seu objetivo,conforme demonstrado no conteúdo entre parênteses na Tabela21.
Cabe uma discussão entre o grupo para avaliar se todas asperguntas são factíveis de serem respondidas e se estão aderentesaos objetivos e dimensão foco previamente definidos. Aquelasperguntas que não estiverem de acordo devem ser adequadas.
Pré-atividade: Selecionar perguntas pré-definidas
Critério de Entrada: Matriz contendo as perguntas para cada categoria e dimensãofoco.
Critério de Saída: Consenso entre os participantes de que as perguntas definidasestão claras, são factíveis de serem respondidas e estão rastreadasaté os objetivos.
Responsável: Analista de Métricas (AM)
Participantes: Analista de Métricas (AM), Gerentes de Projetos (GP) e Analistasde Requisitos (AR)
Produtos Requeridos: Matriz contendo as perguntas para cada categoria e dimensãofoco.
Produtos Gerados: Lista contendo a(s) perguntas da organização de TI e arastreabilidade das mesmas com os objetivos traçados, de acordocom a dimensão foco selecionada e categoria da organização.
Ferramentas: Email e Editor de textos.
Pós-atividade: Definir Indicadores.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
160
Subprocesso: DefinirIndicadores
Processo de Geração de Indicadores para a Gerência de Requisitos (PGIGR)
Uma vez definidas as perguntas, devem ser definidos os indicadores que irão dar
sustentação para que seja possível respondê-las. Este subprocesso tem como objetivo final
definir e detalhar os indicadores necessários para atendimento dos objetivos e perguntas
estabelecidas previamente. Para isso sugere-se que todos indicadores sejam definidos seguindo a
sequência de estruturação sugerida no template proposto pelo PGIGR adiante (Tabela 23).
Neste subprocesso o PGIGR mescla conceitos do GQM e PSM5 para definir a formação
dos indicadores, que são compostos por cinco elementos:
6. Objetivo7. Pergunta8. Indicador9. Medida derivada6 10. Medida básica7 (ou base)
O relacionamento e multiplicidade entre cada um dos cinco elementos acima pode ser
melhor visualizado na Figura 29 a seguir.
5 O PSM (Practical Software Measurement ) é um modelo para a mensuração de projetos de software.6 Medidas Derivadas são valores resultantes de um algoritmo que combina uma ou mais medidas básicas.7 Medias Básicas são insumos para as medidas derivadas. Um exemplo de medida básica é o somatório de horas detrabalho de um analista.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
161
Figura 29 - Relacionamento entre Objetivos, Perguntas, Indicadores, Medidas Derivadas e Medidas básicas(base)
A figura acima mostra que a verificação do atendimento de um objetivo é feita através de
uma pergunta, que por sua vez é respondida por um indicador. Um indicador é formado por um
conjunto de medidas derivadas, onde medidas derivadas são compostas de medidas básicas (ou
base). O exemplo mostrado na Figura 29 é meramente ilustrativo, onde o objetivo é mostrar os
possíveis relacionamento entre os objetos que compõem um indicador.
Dessa forma, este subprocesso é composto por quatro atividades: Selecionar indicadores
pré-definidos, Descrever o indicador, Estruturar o indicador e Divulgar/aprimorar o indicador;
sendo que as últimas 3 atividades fazem parte do processo de criação do indicador, conforme
agrupador apresentado na Figura 30.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
162
Figura 30 - Subprocesso para Definir Indicadores
A seguir são detalhadas as quatro atividades contidas no subprocesso DefinirIndicadores.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
163
Atividade: Selecionar Indicadores pré-definidos.
Descrição: O Analista de Métricas, Gerentes de Projetos e Analistasde Requisitos devem discutir em conjunto a matrizcontendo os indicadores propostos pelo PGIGR (Tabela22 a seguir). Deve-se analisar se os indicadores estãoalinhados com os objetivos, perguntas e se atendem asnecessidades da organização de TI.
Caso os indicadores necessários não sejam encontrados,o grupo pode criar novos indicadores à medida que fornecessário. É através dos indicadores que será possívelresponder as perguntas e consequentemente aferir se os
objetivos foram ou não atingidos. Nesta atividade éimportante que o grupo faça uma brainstrom paraidentificar e gerar uma breve descrição de todos osindicadores que precisam ser gerados para responder asperguntas.
Observação: O envolvimento participativo dosAnalistas de Requisitos é muito importante, pois elesprecisam apontar eventuais dificuldades na coleta deinformações que compõem a estrutura do indicador
(medidas básicas e derivadas). Eles também precisamestar convencidos de que este trabalho irá agregar nageração de conhecimento a respeito da gerência derequisitos, visando aprimorá-la, caso contrário é possívelque informações sejam coletadas de forma equivocada egerem indicadores inconsistentes.
Pré-atividade: Criar Perguntas.
Critério de Entrada: Ter a dimensão foco selecionada, os objetivos traçados eperguntas definidas.
Critério de Saída: Consenso entre os participantes de que os indicadoresselecionados ou descritos estão aderentes aos objetivos,perguntas e dimensão foco previamente definidos.
Responsável: Analista de Métricas (AM)
Participantes: Analista de Métricas (AM), Gerentes de Projetos (GP) eAnalistas de Requisitos (AR)
Produtos Requeridos: Perguntas definidas.
Matriz contendo os Indicadores para a Gerência deRequisitos (Tabela 22)
Produtos Gerados: Breve detalhamento dos indicadores necessários para
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
164
Atividade: Selecionar Indicadores pré-definidos.
responder as perguntas levantadas, de acordo com osobjetivos e dimensão foco selecionados. Exemplo: Custos
das Atividades de Requisitos = (Somatório dos custos comatividades de requisitos) / (Tamanho do software)
Ferramentas: Email e Editor de textos.
Pós-atividade: Descrever o Indicador.
Considerações sobre a Atividade Selecionar Indicadores pré-definidos
O PGIGR apresenta uma matriz (Tabela 22) onde cada uma das categorias(Entendimento, Controle e Aprimoramento) foi cruzada com cada uma das dimensões foco
(Tempo, Custo, Qualidade e Risco). Para cada categoria/dimensão foco foram definidos
indicadores que a organização pode utilizar, adaptar ou criar novos, conforme as suas
necessidades e características. Cada indicador deve estar necessariamente relacionado a pelo
menos uma pergunta.
Tabela 22 - Matriz contendo os Indicadores Sugeridos para cada categoria e dimensão foco
INDICADORES SUGERIDOS
Categoria
Dimensão
Foco
ENTENDIMENTO CONTROLE APRIMORAMENTO
TEMPO (T)
PAR – Produtividade nasAtividades de Requisitos= (Somatório de horasdespendidas em atividadesde requisitos) / (Tamanhodo software) (T1.P1.I1)
PVE – Percentual deVariação do Esforço =(Esforço realizado até opresente momento / Esforço Estimado) * 100(T2.P1.I1)
IVP - Índice deVariação deProdutividade =(percentual doesforço gasto ematividades derequisitos por pontode função) / (médiahistórica de esforçopor ponto de função)* 100 (T3.P1.I1)
CUSTO (C)
CAR – Custos dasAtividades de Requisitos= (Somatório dos custos
com atividades derequisitos) / (Tamanho dosoftware)(C1.P1.I1)
PVC - Percentual deVariação dos Custos =(Somatório dos custos até
o presente momento / Custos Estimados) * 100(C2.P1.I1)
IVC - Índice deVariação dos Custos= (percentual dos
custos de requisitospor ponto de função) / (média históricados custos por ponto
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
165
INDICADORES SUGERIDOS
Categoria
Dimensão
Foco
ENTENDIMENTO CONTROLE APRIMORAMENTO
de função) * 100(C3.P1.I1)
QUALIDADE
(Q)
QDR – Quantidade deDefeitos em Requisitos =(Somatório dos errosidentificados emrequisitos) / (Tamanho doSoftware) (Q1.P1.I1)CTD – Custo Total deDefeito em Requisitos =(somatório dos custos decorreção de errosidentificados emrequisitos) / (Tamanho dosoftware) (Q1.P1.I2)
PRR - Percentual deRequisitos Rejeitados =(percentual de requisitosrejeitados / percentualestimado de rejeição) *100
(Q2.P1.I1)
IVQ – Índice devariação daqualidade =[(porcentagem derequisitos rejeitadospor ponto de função)
/ (porcentagemhistórica derequisitos rejeitadospor ponto defunção)] * 100(Q3.P1.I1)
RISCO (R)
QRI – Quantidade deRequisitos Incorporadosao escopo = (Quantidadede Requisitos após ofechamento da linha debase) / (Quantidade de
Requisitos ao final doprojeto) *100. (R1.P1.I1)PPU - Percentual deParticipação do Usuário =(número de reuniões querepresentantes dosusuários participaram / número de reuniõesrealizadas) * 100(R1.P1.I2)PVR - Percentual deValidação de Requisitospelo Cliente = (número de
documentos de requisitosvalidados / número totalde documentos derequisitos) * 100(R1.P1.I3)PAR - Percentual deAlteração dos Requisitos
já aprovados = (númerode solicitações demudanças de requisitos / número total de requisitos
já aprovados) * 100(R1.P1.I4)
PMT - Quantitativo deMudanças nos Requisitosde acordo com o Tamanhodo Software = (número de
PSM - Percentual desolicitações de mudança =(percentual de solicitaçõesde mudança de escopo / percentual estimado de
alterações no escopo) *100(R2.P1.I1)
IVR - Índice deVariação de Risco =(porcentagem derequisitos concluídosna release / porcentagemhistórica de
requisitosconcluídos) * 100(R3.P1.I1)
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
166
INDICADORES SUGERIDOS
Categoria
Dimensão
Foco
ENTENDIMENTO CONTROLE APRIMORAMENTO
requisitos alterados / Tamanho do Software) *100 (R1.P1.I5)
O conteúdo contido entre parênteses após cada indicador na Matriz de Indicadores é para
permitir sua identificação e rastreabilidade entre os objetivos, perguntas e indicadores. Cadaobjetivo inicia com a primeira letra da dimensão foco e tem um seqüencial numérico, de acordo
com o quantitativo de perguntas e indicadores criados. Para gerar um relacionamento entre cada
objetivo (meta), perguntas (questões) e indicadores, foi definido um padrão conforme exemplo a
seguir: O objetivo de custo para a categoria de Controle (C2) está sendo respondida pela
pergunta P1 e atendido pelo indicador I1, sendo o indicador identificado como C2.P1.I1,
conforme demonstrado na Tabela 22.
Vale ressaltar que os indicadores contidos na Tabela 22 são apenas sugestões e não
abrangem todas as necessidades de todas as organizações. Os indicadores sugeridos podem e
devem ser adaptados de acordo com as necessidades e características de cada organização de TI.
No intuito de orientar a criação e detalhamento de um indicador, o PGIGR apresenta um
template (Tabela 23) que serve como guia para a criação, detalhamento e manutenção dos
indicadores. No intuito de facilitar o entendimento do template proposto, o PGIGR apresenta um
exemplo já preenchido, utilizando um dos indicadores propostos pelo na Tabela 22 apresentada
anteriormente. A ordem dos campos no template é a sequência sugerida de preenchimento do
mesmo.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
167
Tabela 23 – Exemplo do Template para Especificar Indicadores
TEMPLATE PARA ESPECIFICAÇÃO DE INDICADORES
1. Nome do Indicador 2. Sigla 3. Data da RevisãoPercentual e Variação dos Custos PVC 20/07/2009
4. Categoria 5. Dimensão FocoControlar Custo (C)
6. Objetivo/Meta 7. Pergunta 8. Identificador
Monitorar e Controlar se os custos dasatividades de requisitos estão dentro
dos valores estipulados. (Meta C2)
Os custos das atividades de requisitos estão deacordo com os valores (faixas) esperados?
(C2.P1)
C2.P1.I1
9. Unidades de Medida 10. PeriodicidadePorcentual (%) Após a conclusão de uma iteração ou fase ou projeto.
11. Definição
O indicador de variação dos custos de requisitos afere o grau de assertividade entre os
custos despendidos e os custos estimados para as atividades de requisitos, visando
identificar desvios.
12. Medidas base
Esforço despendido nas atividades de requisitos
Valor homem/hora Pontos de função (ou pontos por caso de uso)
13. Medidas derivadas
CE = Custo Estimado (média histórica de custo da organização de TI com a gerência de
requisitos por pontos de função)
CR = Custo Real (multiplicação das horas gastas em atividades de requisitos pelo valor
homem/hora dos recursos envolvidos nas atividades, dividido pela quantidade de
pontos de função do software)
14. Fórmula de cálculo PVC = (CR/CE) * 100
15. Sugestão de fonte dedados
Cronograma do Projeto contendo as atividades de requisitos. O esforço real de trabalho
pode ser multiplicado pelo custo dos recursos e adicionado aos custos fixos do projeto
(infra-estrutura, por exemplo).
16. Métodos de medição
Ao planejar as atividades do cronograma, salvar uma linha de base do planejamento
proposto e acordado. Uma vez feito isso, registrar a variação de esforço das atividades e
inserir novas atividades que venham a ser necessárias, representando todo o esforço de
levantamento, análise, documentação, validação e correção dos requisitos.
17. Exemplo
CE = R$ 350,00 por ponto de função
CR = R$ 535,00 por ponto de função
PVC = (CR/CE) * 100
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
168
TEMPLATE PARA ESPECIFICAÇÃO DE INDICADORES
PVC = (535,00/350,00) * 100
PVC = 53%
Quando interpretando o exemplo acima, vemos que se gastou 53% a mais com
atividades de requisitos do que o estimado inicialmente pela organização para cada
ponto de função.
18. Gráfico:
Custo Estimado
Custo Real
0
100
200
300
400
500
600
jan/09 fev/09 mar/09 abr/09 mai/09
19. Método de análise
O resultado do indicador deve ser analisado nos marcos definidos no projeto (ex.: Acada fim de iteração ou fase ou projeto). Caso o resultado do indicador seja igual a 1, os
custos despendidos com requisitos estão exatamente iguais aos custos médios
históricos. Caso o indicador seja maior que 1, os custos de requisitos foram acima do
que os gastos médios, caso contrário (abaixo de 1), os custos foram abaixo do previsto.
O indicador irá apresentar a variação para mais ou para menos em percentual. Caso o
indicador esteja muito acima dos limites estipulados pela organização, deve-se tomar
ações corretivas.
20. Método de melhoriaou uso
O indicador deve ser revisto a cada fim de projeto, visando a verificação de sua
aderência com os objetivos relacionados aos custos de requisitos.
21. Referências decomparação
Projetos antigos similaresOutras unidades da organizaçãoBenchmark externo
22. Coleta de dadosA coleta dos dados para o indicador inicia-se no começo do projeto e depende,
necessariamente, da identificação e coleta dos custos das atividades de requisitos.
23. Responsável (eis)pela medição eanálise
Gerente de projetos
24. Responsável (eis)pela melhoria do uso
Grupo de métricas
25. ArmazenamentoFerramenta de controle de atividades; e
Ferramenta de controle de versão
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
169
TEMPLATE PARA ESPECIFICAÇÃO DE INDICADORES
26. Premissas:
Utilização de ferramenta de controle de atividades onde possam ser definidas as
atividades e custos das atividades de requisitos.
Repositório contendo os custos médios organizacionais para as atividades de requisitos
por pontos de função.
27. Divulgação dasInformações:
A divulgação do indicador deverá ser feita pelo gerente de projetos através de relatório
disponibilizado na intranet e acessível a todos os envolvidos no projeto.
As próximas três atividades orientam como preencher cada um dos campos apresentados
no template acima.
Atividade: Descrever o Indicador
Descrição: Esta atividade representa a primeira das três subatividades deconcepção de um indicador. Nela o grupo de métricas, gerentesde projetos e analistas de requisitos da organização de TI deveminiciar a concepção do indicador.
Sugere-se que as atividades que compõem a criação do
indicador sejam feitas utilizando-se como referência o templateapresentado na Tabela 23.
Para esta atividade os onze primeiros campos do template deverão ser preenchidos. Esses campos têm o intuito de permitira correta identificação e descrição do indicador.
A seguir é feita uma descrição das tarefas envolvidas parapreenchimento de cada campo:
1. Nome do Indicador: Definir conjuntamente um nome
para o indicador que seja claro, sucinto e que possa sercompreendido por terceiros.
2. Sigla: Definir uma abreviação para o nome do indicador.
3. Data de Revisão: A data de revisão deverá ser
preenchida na criação do indicador e cada vez que o mesmo
for revisado ou alterado.
4. Categoria: Neste ponto uma das quatro categorias já terá
sido definida no subprocesso de categorização do processo
de software (Figura 23), e deverá ser descrito neste campo.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
170
Atividade: Descrever o Indicador
5. Dimensão Foco: Neste ponto uma das quatro dimensões
foco já terá sido definida no subprocesso de definição da
dimensão foco (Figura 26), e deverá ser descrito neste
campo
6. Objetivo/Meta: Neste ponto um objetivo já terá sido
definido no subprocesso de definição de objetivos (Figura
27), e deverá ser descrito neste campo.
7. Pergunta (ou Questão): Neste ponto a pergunta que
precisa ser respondida para avaliar o atendimento doobjetivo traçado já terá sido definida no subprocesso de
definição de perguntas (Figura 28), e deverá ser descrita
neste campo. Ao responder a pergunta deve ser possível
concluir se o objetivo foi ou não atingido.
8. Identificador: O identificador do indicador visa
possibilitar a rastreabilidade entre objetivos, perguntas e
indicadores. Sugere-se que seja utilizada uma letra e número
para identificar cada objetivo, pergunta e indicador,
conforme demonstrado na Tabela 22 contendo as sugestões
de indicadores.
9. Unidade de Medida: Descrição da unidade de medida
utilizada no indicador. Alguns exemplos de unidades de
medida são: porcentagem, somatória, média, unidade de
tempo, etc.
10. Periodicidade: Neste campo deve ser definida a
periodicidade que o indicador deverá ser gerado/reportado.
Essa informação tem que ser acordada com os indivíduos
que irão utilizar (consumir) as informações geradas pelo
indicador.
11. Definição: Breve descrição a respeito do propósito doindicador. Essa descrição não deve entrar em detalhes a
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
171
Atividade: Descrever o Indicador
respeito da composição do indicador, devendo permitir que
uma pessoa leiga compreenda a sua finalidade.
Pré-atividade: Selecionar os indicadores pré-definidos
Critério de Entrada: Ter uma lista contendo uma breve descrição dos indicadorestraçados para os objetivos e perguntas previamente elencadas.
Critério de Saída: Ter os onze primeiros campos do template de indicadorpreenchidos, possibilitando o seu entendimento erastreabilidade.
Responsável: Analista de Métricas (AM)Participantes: Analista de Métricas (AM), Gerentes de Projetos (GP) e
Analistas de Requisitos (AR)
Produtos Requeridos: Lista de Indicadores.
Template para geração de Indicadores.
Produtos Gerados: Indicador detalhado até o campo onze do template. (Tabela 23).
Ferramentas: Email e Editor de textos.
Pós-atividade: Estruturar Indicador
Atividade: Estruturar o Indicador
Descrição: Esta atividade representa a segunda das três subatividades deconcepção do indicador. Nela devem ser descritos os campos denúmero doze até o dezenove do template de indicador (Tabela23). Esses campos têm o intuito de detalhar a formação eestruturação do indicador.
A seguir é feita uma descrição das tarefas envolvidas parapreenchimento de cada campo:
12. Medidas básicas: Descrever as medidas básicas que irão
compor as medidas derivadas e posteriormente o indicador.
Uma medição básica é funcionalmente independente de todas as
outras medidas e captura informação sobre um único atributo.
Exemplos de medidas básicas são: horas de trabalho e data
prevista de término.
13. Medidas Derivadas: Descrever as medidas derivadas que
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
172
Atividade: Estruturar o Indicador
irão compor os indicadores. Medidas derivadas capturam
informação de mais de uma medida básica. Um exemplo de
medida derivada é o cálculo de produtividade através da divisão
do número de horas de esforço pela quantidade de pontos de
função gerados, onde o número de horas de esforço e a
quantidade de pontos de função são exemplos de medidas
básicas.
14. Fórmula de Cálculo: Definir o algoritmo que combina
medidas básicas e/ou derivadas para se criar o indicador.
15. Sugestão de fonte de dados: Descrever as fontes para coletar
as medidas básicas e/ou derivadas. (Exemplos: cronogramas,
ferramenta de controle de versões)
16. Método de Medição: Descrever os procedimentos de coleta
das informações necessárias para se criar o indicador.
17. Exemplo: Demonstrar como se gera o indicador,
representando as medidas básicas, medidas derivadas e
algoritmo utilizado para se chegar ao indicador.
18. Gráfico: um display gráfico do indicador conforme as
características do indicador. O PGIGR apresenta algumas
sugestões de gráficos no Quadro 5 a seguir.
19. Método de Análise: Neste campo deve ser descrito como os
resultados apresentados pelo indicador deverão ser
interpretados. O método de análise tem que estar bem claro para
os indivíduos que irão utilizar as informações geradas pelos
indicadores para que não haja dúvidas ou interpretações
equivocadas.
Pré-atividade: Descrever o indicador
Critério de Entrada: Ter os onze primeiros campos do template de indicadorpreenchidos.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
173
Atividade: Estruturar o Indicador
Critério de Saída: Ter os dezenove primeiros campos do template de indicadorpreenchidos, possibilitando o seu entendimento, rastreabilidade
e detalhamento da estrutura para geração do indicador.Responsável: Analista de Métricas (AM)
Participantes: Analista de Métricas (AM), Gerentes de Projetos (GP) eAnalistas de Requisitos (AR)
Produtos Requeridos: Lista prévia contendo breve descrição de Indicadores
Template para geração de Indicadores preenchido até o campode número onze.
Produtos Gerados: Ao final da atividade o template de geração de indicador tem
que estar detalhado até o campo de número dezenove.Ferramentas: Email e Editor de textos.
Pós-atividade: Divulgar/aprimorar o indicador
Considerações Finais Sobre a Atividade Estruturar o Indicador
O Quadro 5 a seguir apresenta um conjunto de tipos de gráficos que podem ser utilizados
para melhor demonstrar graficamente as informações geradas pelos indicadores (campo 18 do
template).
Quadro 5 – Exemplos de Gráficos para Geração de Indicadores
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
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,00
to
0,08
0,08
to
0,16
0,16
to
0,24
0,24
to
0,32
0,32
to
0,40
0,40
to
0,48
0,48
to
0,56
0,56
to
0,64
0,64
to
0,72
0,72
to
0,80
0,80
to
0,88
0,88
to
0,96
0,96
to
1,04
1,04
to
1,12
1,12
to
1,20
Histograma
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
174
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ãosomente 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
Build 1
Build 2
Build 3
Build 4
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,325
0,055 0,0460,014 0,010 0,009 0,003 - -
0,00%
20,00%
40,00%
60,00%
80,00%
100,00%
-0,0500,1000,1500,2000,2500,3000,350
D e n s i d a d e d e d e f e i t 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,000
0,100
0,200
0,300
0,400
0,500
0,600
n ov /0 5 d ez/0 5 j an /0 6 fev /0 6 m ar/ 06 a br/ 06 m ai /0 6 j un /0 6 j ul /0 6 a go /0 6 se t/ 0 6
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
n ov /0 5 d ez /0 5 j an /0 6 f ev /0 6 m ar /0 6 a br /0 6 ma i/ 06 j un /0 6 j ul /0 6 a go /0 6 s et /0 6
IDC (X)
IDC (X) LC LCS (+3 sigmas) + 2 sigmas
+ 1 sigma LCI (- 3 sigmas) - 2 sigmas - 1 sigma
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
175
Atividade: Divulgar/aprimorar o indicador
Descrição: Esta atividade representa a terceira e última atividade que
compõe a concepção do indicador. Nela devem ser descritosos campos de número vinte até o vinte sete do template.Esses campos englobam informações a respeito dadivulgação das informações geradas pelo indicador, assimcomo o seu aprimoramento e manutenção no decorrer dotempo. A seguir são descritas as tarefas envolvidas parapreenchimento de cada campo:
20. Método de Melhoria ou uso: Neste campo deverá ser
definida a periodicidade que o indicador deverá ser revisto
visando o seu aprimoramento.
21. Referências de comparação: Neste campo deverão ser
definidas fontes de dados que poderão ser utilizadas para
comparar os dados gerados pelo indicador. Exemplos de
fontes de comparação: projetos antigos, outras unidades da
organização e benchmark externo.
22. Coleta de dados: Descrever informações a respeito decomo, quando e com qual freqüência as medidas básicas e
derivadas requeridas para a construção do indicador deverão
ser coletadas. Esses dados são fundamentais para que as
informações geradas pelos indicadores estejam sempre
atualizadas de acordo com as necessidades.
23. Responsável (eis) pela Medição e Análise: Definir o
papel ou indivíduo que ficará responsável pelo indicador.24. Responsável (eis) pela melhoria do uso: Definir o papel
ou indivíduo que ficará responsável por revisar/aprimorar o
indicador.
25. Armazenamento: Definir onde as informações
necessárias para compor o indicador serão armazenadas,
visando segurar a integridade dos dados.
26. Premissas: Listar as premissas a respeito da organização,
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
176
Atividade: Divulgar/aprimorar o indicador
seus processos e ferramentas que sejam relevantes para a
coleta de dados e utilização do indicador.
27. Divulgação das informações: Definir o papel ou
indivíduo responsável por divulgar as informações geradas
pelo indicador, assim como definir claramente os
stakeholders que necessitam receber as informações geradas.
Também é importante definir o local onde as informações
serão publicadas (Ex.: E-mail, Intranet, apresentação
PowerPoint, Internet).
Uma vez o indicador detalhado através do preenchimento dotemplate (Tabela 23), sugere-se que o mesmo seja submetidoà validação dos stakeholders que irão utilizar as informaçõesgeradas. Isso possibilitará que eventuais falhas naestruturação do indicador sejam corrigidas e irá garantir oalinhamento entre os indicadores e objetivos organizacionais.
Pré-atividade: Estruturar o Indicador
Critério de Entrada: Ter os dezenove primeiros campos do template de indicador
(Tabela 23) preenchidos.
Critério de Saída: Ter todos os campos do template preenchidos e a estruturado indicador validada pelos stakeholders que irão utilizar osindicadores para tomar decisões.
Responsável: Analista de Métricas (AM)
Participantes: Analista de Métricas (AM), Gerentes de Projetos (GP) eAnalistas de Requisitos (AR)
Produtos Requeridos: Lista prévia contendo breve descrição de Indicadores
Template para geração de indicadores preenchido até ocampo dezenove.
Produtos Gerados: Detalhamento de todos os campos do template de definiçãode indicadores preenchidos e validados pelos stakeholders.
Ferramentas: Email e Editor de textos.
Pós-atividade: --
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
177
Aprimorar o Processode Desenvolvimento deSoftware
Processo de Geração de Indicadores para a Gerência de Requisitos (PGIGR)
Conforme mencionado anteriormente, o Aprimoramento do Processo de Software não
é um subprocesso do PGIGR, mas torna-se elemento necessária dentro do ciclo proposto pelo
PGIGR para que a organização de TI possa evoluir entre as quatro categorias propostos (Inicial,
Entendimento, Controle e Aprimoramento), permitindo assim a geração de indicadores mais
robustos ao longo do tempo.
Esse aprimoramento está diretamente relacionado às características definidas na Tabela
18 - Matriz de Categorização do processo de software da Organização de TI. As iterações entre o
aprimoramento do processo de software e o processo de categorização da organização podem ser
melhor visualizadas na Figura 24 apresentada anteriormente.
É importante ressaltar que a evolução entre as diferentes categorias fica a critério da
organização de TI. Sugere-se a evolução entre as categorias de Entendimento, Controle e
Aprimoramento de acordo com a evolução das necessidades da organização.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
178
APÊNDICE B - EXEMPLOS DE INDICADORES DETALHADOS
Tabela 24 – Detalhamento do Indicador de Horas Gastas em Atividades de Requisitos (EGR)
Detalhamento do Indicador de Esforço Gasto em Atividades de Requisitos (EGR)
1. Nome do Indicador 2. Sigla 3. Data da RevisãoEsforço Gasto em Atividades de
RequisitosEGR 20/07/2009
4. Categoria 5. Dimensão Foco
Entendimento Tempo (T)
6. Objetivo/Meta 7. Pergunta 8. IdentificadorConhecer o esforço e/ou
produtividade para executar as
atividades de requisitos. (Meta T1)
Qual o esforço e/ou produtividade nas
atividades de requisitos? (T1.P1) T1.P1.I1
9. Unidades de Medida 10. PeriodicidadeSomatório Após a conclusão de uma iteração, fase ou do projeto.
11. DefiniçãoO indicador serve para identificar o quantitativo de horas gastas com
atividades relacionadas a requisitos de acordo com o tamanho do software.
12. Medidas base Somatório de horas gastas em atividades de requisitos Pontos de função ou pontos por caso de uso do software documentado
13. Medidas derivadas
SHG = Somatório de horas gastas com atividades de requisitos
TMS = Tamanho do software ou da parte do software que foi documentada
pelas atividades de requisitos.
14. Fórmula decálculo
EGR = (SHG/TMS)
15. Sugestão de fontede dados
Cronograma do Projeto contendo as atividades de requisitos. O esforço registrado nas atividades de requisitos pode ser coletado docronograma. O quantitativo de pontos de função ou use case points pode serdefinido a partir de características e documentação do software.
16. Métodos demedição
Após a conclusão de uma iteração, fase ou do projeto, coletar do cronograma
todo o esforço despendido em atividades relacionadas a requisitos.
Deve ser feita uma contagem do software utilizando a técnica de APF ou
UCP para definir o tamanho do software documentado.
17. Exemplo
SHG = 355 horas
TMS = 36 pontos de funçãoEGR = (SHG/TMS)
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
179
Detalhamento do Indicador de Esforço Gasto em Atividades de Requisitos (EGR)
EGR = (355/36)EGR = 9,86 horas por ponto de função
Quando interpretando o exemplo acima, vemos que se gastou 9,86 horas em
atividades de requisitos para cada ponto de função do software.
18. Gráfico:
19. Método de análise
O resultado do indicador deve ser analisado nos marcos definidos no projeto
(ex.: A cada fim de iteração, fase ou do projeto). Como o objetivo na
categoria Entendimento é conhecer o esforço despendido em atividades de
requisitos, a organização deve armazenar os dados registrados para que façam
parte de uma base histórica. Os mesmos poderão ser comparados com novas
iterações ou fases do projeto, servindo como base de futuras comparações e
apoio ao planejamento. É importante ressaltar que pode haver variação nos
valores de acordo com a tecnologia e linguagem utilizada para codificar o
sistema.
20. Método demelhoria ou uso
O indicador deve ser revisto a cada fim de projeto visando a verificação de
sua aderência com os objetivos relacionados aos esforços em atividades de
requisitos.
21. Referências decomparação
Iterações mais antigasProjetos antigos similaresOutras unidades da organizaçãoBenchmark externo
22. Coleta de dados
A coleta dos dados para o indicador inicia no começo do projeto edepende, necessariamente, do planejamento das atividades de requisitos,
assim como a coleta rotineira do esforço despendido com as atividades derequisitos.
Também é necessário a mensuração do software documentado. Para isso
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
180
Detalhamento do Indicador de Esforço Gasto em Atividades de Requisitos (EGR)
é preciso descrever as funcionalidades do sistema e dar uma visão deescopo.23. Responsável (eis)
pela medição eanálise
Gerente de projetos
24. Responsável (eis)pela melhoria douso
Analista de Métricas
25. ArmazenamentoFerramenta de controle de atividades; e
Ferramenta de controle de versão
26. Premissas:
Utilização de ferramenta de controle de atividades onde possa ser
registrado o esforço gasto com as atividades de requisitos. Utilização de técnicas que possibilitem definir o tamanho do software (APF ou UCP são exemplos de técnicas que podem ser utilizadas) Documentação das funcionalidades do software
27. Divulgação dasInformações:
A divulgação do indicador deverá ser feita pelo gerente de projetos através do
site do projeto.
Tabela 25 – Detalhamento do Indicador de Custo Total de Defeitos em Requisitos (CTD)
Detalhamento do Indicador de Custo Total de Defeitos em Requisitos (CTD)
1. Nome do Indicador 2. Sigla 3. Data da RevisãoCusto Total de Defeitos em
Requisitos.CTD 20/07/2009
4. Categoria 5. Dimensão FocoEntendimento Qualidade (Q)
6. Objetivo/Meta 7. Pergunta 8. Identificador
Conhecer a qualidade dos artefatos
de requisitos. (Meta Q1)
Qual o custo de correção de defeitos nos
artefatos de requisitos (Q1.P2) Q1.P2.I2
9. Unidades de Medida 10. PeriodicidadeSomatório Após a conclusão de uma iteração, fase ou do projeto.
11. DefiniçãoO indicador serve para identificar o custo de retrabalho em artefatos de
requisitos de acordo com o tamanho do software.
12. Medidas base
Somatório de horas gastas em atividades de retrabalho emrequisitos Custo homem/hora de cada indivíduo que participou das atividadesde correção dos artefatos
Pontos de função ou pontos por caso de uso do software documentado
13. Medidas derivadas SHR = Somatório de horas gastas com atividades de retrabalho emrequisitos
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
181
Detalhamento do Indicador de Custo Total de Defeitos em Requisitos (CTD)
CHH = Custo Homem-Hora dos recursos envolvidos nas atividadesde correção dos requisitos TMS = Tamanho do software ou da parte do software que foidocumentada pelas atividades de requisitos.
14. Fórmula decálculo
CTD = ((SHR*CHH)/TMS)
15. Sugestão de fontede dados
Cronograma do Projeto contendo as atividades de requisitos. Oesforço registrado nas atividades de retrabalho em requisitos pode sercoletado do cronograma. Cronograma do Projeto contendo o custo Homem-Hora de cadarecurso do projeto. Esse custo também pode ser acrescido do custo de
infra-estrutura. O quantitativo de pontos de função ou use case points pode serdefinido a partir de características e documentação do software.
16. Métodos demedição
Após a conclusão de uma iteração, fase ou do projeto, coletar docronograma todo o esforço despendido em atividades de retrabalho ematividades de requisitos, assim como o custo dos recursos envolvidosnas atividades. Deve ser feita uma contagem do software utilizando a técnica deAPF ou UCP para definir o tamanho do software documentado.
17. Exemplo
SHR = 35 horas
SHH = 50 reais custo homem-hora
TMS = 23 pontos de função
CTD = ((SHR*CHH)/TMS)
CTD = ((35*50)/23)
CTD = R$ 76,08 por ponto de função
Quando interpretando o exemplo acima, vemos que se gastou 76,09 reais
por ponto de função somente em atividades de correção de defeitos em
requisitos.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
182
Detalhamento do Indicador de Custo Total de Defeitos em Requisitos (CTD)
18. Gráfico:
19. Método de análise
O resultado do indicador deve ser analisado nos marcos definidos no
projeto (ex.: A cada fim de iteração, fase ou do projeto). Como o objetivo
na categoria Entendimento é conhecer os custos de retrabalho em
atividades de requisitos, a organização deve armazenar os dados
registrados para que façam parte de uma base histórica. Os mesmos
poderão ser comparados com novas iterações ou fases do projeto, servindo
como base de futuras comparações e apoio ao planejamento. É importante
ressaltar que pode haver variação nos valores de acordo com a metodologia
e linguagem de programação utilizada para codificar o sistema.
20. Método demelhoria ou uso
O indicador deve ser revisto a cada fim de projeto, visando a verificação de
sua aderência com os objetivos relacionados aos esforços em atividades de
requisitos.
21. Referências decomparação
Iterações mais antigasProjetos antigos similaresOutras unidades da organizaçãoBenchmark externo
22. Coleta de dados
A coleta dos dados para o indicador se da no início do projeto edepende, necessariamente, de um marco para que seja salva a linha de baseinicial, contendo um planejamento de atividades de requisitos, assim comoa coleta rotineira do esforço despendido com as atividades e seus custos, deacordo com a alocação dos recursos em cada uma das atividades. Também é necessário a mensuração do software documentado, oque fará necessário a utilização de documentos que descrevem asfuncionalidades do sistema e dêem uma visão de escopo.
23. Responsável (eis)
pela medição eanálise Gerente de projetos
24. Responsável (eis)pela melhoria do
Analista de métricas
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
183
Detalhamento do Indicador de Custo Total de Defeitos em Requisitos (CTD)
uso
25. Armazenamento
Ferramenta de controle de atividades; e Ferramenta de controle de versão
26. Premissas:
Utilização de ferramenta de controle de atividades onde possa serregistrado o esforço gasto com as atividades de requisitos e os custos dasmesmas. Utilização de técnicas que possibilitem definir o tamanho dosoftware (APF ou UCP são exemplos de técnicas que podem ser utilizadas) Controle das atividades de retrabalho
27. Divulgação dasInformações:
A divulgação do indicador deverá ser feita pelo gerente de projetos através
de e-mail para todos os stakeholders envolvidos no projeto.
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
184
APÊNDICE C - QUESTIONÁRIO DE AVALIAÇÃO DO PROCESSO PGIGR
Quadro 6 - Questionário de avaliação do PGIGR
Legenda: PAR – Parcialmente; NSI – Não Soube Informar
1ª ETAPA – Contextualização a respeito de características do Avaliador e da Organização de TI
1. Atualmente qual o cargo que você ocupa na empresa onde
trabalha?
2. Quantos anos de experiência você possui em desenvolvimento de
software?
3. Você possui experiência prática quanto a utilização de medições e
indicadores em desenvolvimento de software? ( ) SIM ( ) NÃO ( ) NSI
4. Você acredita que a gestão de requisito é um dos fundamentos
mais críticos para o sucesso dos projetos na organização onde
trabalha?( ) SIM ( ) PAR ( ) NÃO
5. A organização onde trabalha enfrenta dificuldades no que tange a
gestão de requisitos?( ) SIM ( ) PAR ( ) NÃO
6. A organização onde trabalha possui um processo para a gestão de
requisitos?( ) SIM ( ) PAR ( ) NÃO
7. A organização onde trabalha possui práticas de gerência deprojetos?
( ) SIM ( ) PAR ( ) NÃO
8. A organização onde trabalha possui ferramenta gerencial para
controle de atividades de projetos?( ) SIM ( ) PAR ( ) NÃO
9. A organização onde trabalha possui ferramenta e processo para
controle de versionamento dos artefatos de requisitos?( ) SIM ( ) PAR ( ) NÃO
10. A organização onde trabalha possui práticas de mensuração do
tamanho de software?( ) SIM ( ) PAR ( ) NÃO
11. Atualmente a organização onde trabalha utiliza indicadores para
gerenciar requisitos?( ) SIM ( ) PAR ( ) NÃO
12. A organização onde trabalha possui um processo de
desenvolvimento de software?( ) SIM ( ) PAR ( ) NÃO
2ª ETAPA – Avaliação do PGIGR
13. Em sua opinião, a parte introdutória do PGIGR, que apresenta uma
visão geral do processo, é de fácil entendimento?( ) SIM ( ) PAR ( ) NÃO
13.1. Se a resposta anterior for NÃO ou PARCIALMENTE, favor
relatar as principais dificuldades encontradas.
Avaliação do Subprocesso Categorizar o Processo de Software da Organização de TI
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
185
14. Em sua opinião, a introdução do subprocesso Categorizar o
Processo de Software é de fácil entendimento? ( ) SIM ( ) PAR ( ) NÃO
14.1. Se a resposta anterior for NÃO ou PARCIALMENTE,
favor relatar as principais dificuldades encontradas.
15. Em sua opinião, a atividade Definir Envolvidos é de fácil
entendimento?( ) SIM ( ) PAR ( ) NÃO
15.1. Se a resposta anterior for NÃO ou PARCIALMENTE,
favor relatar as principais dificuldades encontradas.
16. Em sua opinião, a atividade Definir Categoria é de fácil
entendimento?( ) SIM ( ) PAR ( ) NÃO
16.1. Se a resposta anterior for NÃO ou PARCIALMENTE,
favor relatar as principais dificuldades encontradas.
Descreva nesse item eventuais observações ou sugestão a respeito do
subprocesso Categorizar o Processo de Software da Organização de
TI.
Avaliação do Subprocesso Definir Dimensão Foco
17. Em sua opinião, a introdução do subprocesso Definir Dimensão
Foco é de fácil entendimento?( ) SIM ( ) PAR ( ) NÃO
17.1. Se a resposta anterior for NÃO ou PARCIALMENTE,
favor relatar as principais dificuldades encontradas.
18. Em sua opinião, a atividade Priorizar Dimensão Foco é de fácil
entendimento?( ) SIM ( ) PAR ( ) NÃO
18.1. Se a resposta anterior for NÃO ou PARCIALMENTE,
favor relatar as principais dificuldades encontradas.
19. Em sua opinião, a atividade Definir Dimensão Foco para a
Geração de Indicadores é de fácil entendimento?( ) SIM ( ) PAR ( ) NÃO
19.1. Se a resposta anterior for NÃO ou PARCIALMENTE,
favor relatar as principais dificuldades encontradas.
Descreva nesse item eventuais observações ou sugestão a respeito do
subprocesso Definir Dimensão Foco.
Avaliação do Subprocesso Definir Objetivos
20. Em sua opinião, a introdução do subprocesso Definir Objetivos é
de fácil entendimento?( ) SIM ( ) PAR ( ) NÃO
20.1. Se a resposta anterior for NÃO ou PARCIALMENTE,
favor relatar as principais dificuldades encontradas.
21. Em sua opinião, a atividade Selecionar os Objetivos pré-
definidos para Gerência de Requisitos é de fácil entendimento? ( ) SIM ( ) PAR ( ) NÃO
21.1. Se a resposta anterior for NÃO ou PARCIALMENTE,favor relatar as principais dificuldades encontradas.
22. Em sua opinião, a atividade Criar Objetivos é de fácil ( ) SIM ( ) PAR ( ) NÃO
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
186
entendimento?
22.1. Se a resposta anterior for NÃO ou PARCIALMENTE,
favor relatar as principais dificuldades encontradas.
Descreva nesse item eventuais observações ou sugestão a respeito do
subprocesso Definir Objetivos.
Avaliação do Subprocesso Definir Perguntas
23. Em sua opinião, a introdução do subprocesso Definir Perguntas é
de fácil entendimento?( ) SIM ( ) PAR ( ) NÃO
23.1. Se a resposta anterior for NÃO ou PARCIALMENTE,
favor relatar as principais dificuldades encontradas.
24. Em sua opinião, a atividade Selecionar Perguntas Pré-Definidas
é de fácil entendimento?( ) SIM ( ) PAR ( ) NÃO
24.1. Se a resposta anterior for NÃO ou PARCIALMENTE,
favor relatar as principais dificuldades encontradas.25. Em sua opinião, a atividade Criar Perguntas é de fácil
entendimento?( ) SIM ( ) PAR ( ) NÃO
25.1. Se a resposta anterior for NÃO ou PARCIALMENTE,
favor relatar as principais dificuldades encontradas.
Descreva nesse item eventuais observações ou sugestão a respeito do
subprocesso Definir Perguntas.
Avaliação do Subprocesso Definir Indicadores
26. Em sua opinião, a introdução do subprocesso Definir Indicadores
é de fácil entendimento?( ) SIM ( ) PAR ( ) NÃO
26.1. Se a resposta anterior for NÃO ou PARCIALMENTE,
favor relatar as principais dificuldades encontradas.
27. Em sua opinião, a atividade Selecionar Indicadores Pré-
Definidos é de fácil entendimento?( ) SIM ( ) PAR ( ) NÃO
27.1. Se a resposta anterior for NÃO ou PARCIALMENTE,
favor relatar as principais dificuldades encontradas.
28. Em sua opinião, a atividade Descrever o Indicador é de fácil
entendimento?( ) SIM ( ) PAR ( ) NÃO
28.1. Se a resposta anterior for NÃO ou PARCIALMENTE,
favor relatar as principais dificuldades encontradas.
29. Em sua opinião, a atividade Estruturar o Indicador é de fácil
entendimento?( ) SIM ( ) PAR ( ) NÃO
29.1. Se a resposta anterior for NÃO ou PARCIALMENTE,
favor relatar as principais dificuldades encontradas.
30. Em sua opinião, a atividade Divulgar/Aprimorar o Indicador é
de fácil entendimento?( ) SIM ( ) PAR ( ) NÃO
30.1. Se a resposta anterior for NÃO ou PARCIALMENTE,
favor relatar as principais dificuldades encontradas.
Descreva nesse item eventuais observações ou sugestão a respeito dosubprocesso Definir Indicadores.
3ª ETAPA – Avaliação Final do PGIGR
5/9/2018 Dissertacao Leonardo Schwindt - V4.7 - FINAL - Sem Capa - slidepdf.com
http://slidepdf.com/reader/full/dissertacao-leonardo-schwindt-v47-final-sem-capa 1
187
31. Quanto tempo você levou para avaliar o processo PGIGR?
32. Você acredita que o PGIGR poderia ser aplicado na organização
onde trabalha?( ) SIM ( ) PAR ( ) NÃO
32.1. Se a resposta anterior for NÃO ou PARCIALMENTE,
favor relatar as principais dificuldades.
33. Em sua opinião, qual o nível de dificuldade para compreender o
PGIGR?( ) Baixo ( ) Médio ( ) Alto
34. Em sua opinião, qual o nível de dificuldade para utilizar o
PGIGR?( ) Baixo ( ) Médio ( ) Alto
35. Você acredita ser necessário um especialista em métricas para
utilizar o PGIGR? ( ) SIM ( ) NÃO ( ) NSI
36. Você conseguiria criar um indicador seguindo o processo?
( ) SIM ( ) PAR ( ) NÃO
36.1. Se a resposta anterior for NÃO ou PARCIALMENTE,
favor relatar as principais dificuldades encontradas.
Top Related