dissertacao leonardo schwindt - v4.7 - final - sem capa

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



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



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



iii



iv

Dedico este trabalho a Deus, minha esposa e família.



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.



vi

“Procure ser um homem de valor, em vez de ser um homem de sucesso." Albert Einstein



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.



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



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



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



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



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



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



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



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



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



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.



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



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.



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.



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.



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.



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



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.



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.



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



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



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).



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



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.



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.



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



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.



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.



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.



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.



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).



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




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;



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



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



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



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.



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



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.



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



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)



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.



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)



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.



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.



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.



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



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



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?



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



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.



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



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.



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.



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.



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:



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.

http://apps.isiknowledge.com/

http://www2.computer.org/

http://www.scirus.com/

http://www.scirus.com/

http://www2.computer.org/

http://apps.isiknowledge.com/



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.



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.



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.



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.



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.



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.



70

3.4.5. Passo: Estudo da Teoria de Base sobre Métricas e Indicadores Existentes para a


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.



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.



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.



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.



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.



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.



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.



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



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



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



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



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



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)



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



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.



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 à


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


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


ControleA organização necessita melhor monitorar os custos despendidos nas


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


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.



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.



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.



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


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



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.



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.



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)



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.



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.



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


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



94


Categoria

Dimensão

Foco


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.



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



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.



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.



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



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.



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.



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.



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.



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


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.



104

Tabela 10 – Consolidação dos dados da Segunda Etapa do Questionário


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


29. Em sua opinião, a atividade Estruturar o Indicador é de fácil


30. Em sua opinião, a atividade Divulgar/Aprimorar o Indicador é

de fácil entendimento?

SIM SIM SIM SIM SIM SIM



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


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


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



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



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.


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.



108


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.


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



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.



110


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



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


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).



112


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.



113


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


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


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


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.



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


SIM NÃO NÃO NÃO

O processo proporciona uma evolução incremental

no que tange a utilização de indicadores para a


SIM PAR PAR PAR



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



116

pode chegar, de acordo com suas necessidades e expectativas no que tange a gestão de

requisitos.



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



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



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



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:



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.



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.



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.



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.



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.



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



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.

http://www.jiludwig.com/Requirements_Management.html

http://www.jiludwig.com/Requirements_Management.html



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



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.

http://www.psmsc.com/

http://www.softex.br/mpsbr/_guias/MPS.BR_Guia_Geral_V1.2.pdf

http://www.softex.br/mpsbr/_guias/MPS.BR_Guia_Geral_V1.2.pdf

http://www.psmsc.com/



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.

http://www.bfpug.com.br/

http://www.bfpug.com.br/



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.



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.



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.



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.



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



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.



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).



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



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



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


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.



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.



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.


Pós-atividade: Definir Foco dos Indicadores



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



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.



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


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.



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



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


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.



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.



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.



150


É 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.



151


Produtos Gerados: Dimensão foco selecionada


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 à


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


ControleA organização necessita melhor monitorar o tempo/esforço despendido


AprimoramentoA organização deseja reduzir o tempo/esforço despendido nas


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


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


ControleA organização necessita melhor monitorar a qualidade dos produtos


AprimoramentoA organização deseja aprimorar a qualidade dos produtos gerados

pelas atividades de requisitos em projetos de software.



152

Subprocesso: DefinirObjetivos (Metas)


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


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



Papel

Produto requerido

Produto gerado

MTODMF

MTO

OBJ

OBJ

ObjetivoSelecionado

Figura 27 – Subprocesso para Definir Objetivos (Metas)



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.


Pós-atividade: Criar Objetivo(s).



154

Considerações sobre a atividade Selecionar os objetivos da Organização de TI para a


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


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.



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.


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.


Pós-atividade: Criar Perguntas.



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


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



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.



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.


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.


Pós-atividade: Definir as Perguntas.

Considerações sobre a atividade Selecionar Pergunta(s) pré-definidas



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



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.


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.


Pós-atividade: Definir Indicadores.



160

Subprocesso: DefinirIndicadores


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.



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.



162

Figura 30 - Subprocesso para Definir Indicadores

A seguir são detalhadas as quatro atividades contidas no subprocesso DefinirIndicadores.



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.



Produtos Requeridos: Perguntas definidas.

Matriz contendo os Indicadores para a Gerência deRequisitos (Tabela 22)

Produtos Gerados: Breve detalhamento dos indicadores necessários para



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)


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


Categoria

Dimensão

Foco


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



165


Categoria

Dimensão

Foco


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)



166


Categoria

Dimensão

Foco


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.



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



168


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



169


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.



170


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



171


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).


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



172


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.



173


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)


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



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



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,



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.



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.


Pós-atividade: --



177

Aprimorar o Processode Desenvolvimento deSoftware


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.



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)



179


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:


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.


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



180


é 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


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



181


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.



182


18. Gráfico:


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.


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



183


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


A divulgação do indicador deverá ser feita pelo gerente de projetos através

de e-mail para todos os stakeholders envolvidos no projeto.



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



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



16. Em sua opinião, a atividade Definir Categoria é de fácil




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



18. Em sua opinião, a atividade Priorizar Dimensão Foco é de fácil




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




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



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



186

entendimento?




subprocesso Definir Objetivos.

Avaliação do Subprocesso Definir Perguntas

23. Em sua opinião, a introdução do subprocesso Definir Perguntas é




24. Em sua opinião, a atividade Selecionar Perguntas Pré-Definidas

é de fácil entendimento?( ) SIM ( ) PAR ( ) NÃO


favor relatar as principais dificuldades encontradas.25. Em sua opinião, a atividade Criar Perguntas é de fácil





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



27. Em sua opinião, a atividade Selecionar Indicadores Pré-

Definidos é de fácil entendimento?( ) SIM ( ) PAR ( ) NÃO



28. Em sua opinião, a atividade Descrever o Indicador é de fácil




29. Em sua opinião, a atividade Estruturar o Indicador é de fácil




30. Em sua opinião, a atividade Divulgar/Aprimorar o Indicador é




Descreva nesse item eventuais observações ou sugestão a respeito dosubprocesso Definir Indicadores.

3ª ETAPA – Avaliação Final do PGIGR



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


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



dissertacao leonardo schwindt - v4.7 - final - sem capa

Documents