PROGRAMA DE PS-GRADUAO STRICTO SENSU EM GESTO DO CONHECIMENTO E DA TECNOLOGIA DA INFORMAO

Mestrado
ABORDAGEM PARA DEFINIO DE INDICADORES DE REQUISITOS EM PROJETOS DE SOFTWARE Autor: Leonardo Schwindt Orientador: Prof. Dr. Fbio Bianchi Campos Co-orientador: Prof. Dr. Cludio Chauke Nehme

da Silva

2009

LEONARDO SCHWINDT

ABORDAGEM PARA DEFINIO DE INDICADORES DE REQUISITOS EM PROJETOS DE SOFTWARE

Dissertao apresentada ao Programa de Ps-Graduao Strictu Sensu em Gesto do Conhecimento e Tecnologia da Informao da Universidade Catlica de Braslia, como requisito para obteno do Ttulo de Mestre em Gesto do Conhecimento e da Tecnologia da Informao.

Orientadora: Prof. Dr. Fbio Bianchi Campos Co-orientador: Prof. Dr. Cludio Chauke Nehme

Braslia 2009

ii

S415a

Schwindt, Leonardo Abordagem para definio de requisitos em projetos de software Leonardo Schwindt, 184 f.: il.; 30 cm Dissertao (mestrado) Universidade Catlica de Braslia, 2009. Orientadora: Fbio Bianchi Campos. Co-orientao: Cludio Chauke Nehme. 1.Administrao de projetos. 2. Software Controle de qualidade. 3. Software - Desenvolvimento. I. Campos, Fbio Bianchi, orient. II. Nehme, Cludio Chauke, co-orient. III. Ttulo. CDU 004.05 /

Ficha elaborada pela Biblioteca Central da Universidade Catlica de Braslia UCB

06/10/2009

iii

iv

Dedico este trabalho a Deus, minha esposa e famlia.

Agradecimentos A Deus por ter me dado sade e fora para concluir este trabalho. Aos meus pais Joo Alberto Schwindt e Claudete Rossignoli Motta pelo carinho, ateno, apoio e contribuio na minha formao pessoal, educacional, desportiva e profissional. minha esposa Mariana Caetano da Silva Souza Schwindt pela pacincia, compreenso e incentivo nos momentos mais difceis. Aos meus irmos Joo Alberto Schwindt Filho, Anne Rossignoli Schwindt e Bruno Rossignoli Schwindt pelo companheirismo e amizade. Aos meus avs 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 Cludio Chauke Nehme e Fbio Bianchi Campos pela contribuio direta com a concretizao deste trabalho, mostrando dedicao, pacincia e entusiasmo em todos os momentos. A todos os meus amigos de trabalho pela amizade e troca de experincias. Aos meus colegas de turma do mestrado da Catlica, pelo coleguismo. Aos professores da Catlica, pelo profissionalismo demonstrado e conhecimentos compartilhados. Finalmente, a todos aqueles que direta ou indiretamente contriburam para concretizao deste sonho.

vi

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

vii

RESUMO

Projetos possuem caractersticas singulares que esto diretamente relacionadas a questes que envolvem riscos, pois a proposta de um projeto de se gerar um produto, servio ou resultado exclusivo. A indstria de software tem se deparado com inmeras dificuldades que fazem com que a maioria de seus projetos atrase, ultrapasse limites oramentrios e no atenda por completo s necessidades das organizaes e dos clientes. So vrios os fatores que contribuem para que isso ocorra, sendo a m gesto de requisitos uma das principais causas. Para aprimorar a gerncia de requisitos importante que se utilize ferramentas quantitativas. Indicadores podem auxiliar gerentes e equipe no aprimoramento do controle e previsibilidade dos projetos de software. Este trabalho teve como objetivo principal definir um processo para a gerao de indicadores que fosse especfico para a gerncia de requisitos. Esse processo, quando avaliado, mostrou ser de fcil entendimento, apresentando nvel de detalhes que permite com que profissionais no especialistas na rea de mtricas possam segui-lo e utilizlo, sendo possvel a criao gradual de indicadores de acordo com as caractersticas e necessidades especficas de cada organizao. Palavras-Chave: Gerenciamento de Projetos, Qualidade de Software, Desenvolvimento de Software, Gerncia de Requisitos, Mtricas 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 organizations and end users. There are many variables that collaborate in order to this to occur, but a poor requirement management is known as one of the main reasons. In order to improve requirement management it is important to use quantitative tools. Indicators can help managers and teams to improve the control and predictability of projects. This paper had as the 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 to the characteristics and needs of each organization.

Keywords: Project Management, Software Quality, Software Development, Requirement Management, 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 (Adaptao de KOTONYA, 2002) ............ 35 Figura 5 - Exemplo de Aplicao do GQM .............................................................................. 44 Figura 6 - Goal Question Indicator Metric - GQ(I)M (ARAJO, 2004) ................................ 47 Figura 7 - Practical Software Measurement (PSM) ................................................................. 49 Figura 8 - Estruturao de criao de um Indicador no PSM (HAZAN, 2002) ....................... 52 Figura 9 - Exemplo de estruturao de Indicador atravs do PSM (HAZAN, 2002)............... 53 Figura 10 Exemplo de grfico de controle de volatilidade dos requisitos (LOCONSOLE, 2007) ................................................................................................................................. 60 Figura 11 Processo de definio do PGIGR .......................................................................... 65 Figura 12 Subprocessos do PGIGR ....................................................................................... 72 Figura 13 - Categorias de Classificao do Processo de Software da Organizao de TI ....... 75 Figura 14 - Subprocesso para Categorizar o Processo de Software da Organizao de TI ...... 76 Figura 15 - Quatro Dimenses Foco para a gerao de indicadores (Adaptao de Solingen e Berghout, 1999) ................................................................................................................ 82 Figura 16 - Subprocesso para Definir Dimenso Foco............................................................. 83 Figura 17 - Subprocesso para Definir Objetivos (Metas) ......................................................... 86 Figura 18 - Subprocesso para Definir Perguntas (Questes) ................................................... 88 Figura 19 - Relacionamento entre Objetivos, Perguntas, Indicadores, Medidas Derivadas e Medidas bsicas (base) ..................................................................................................... 90 Figura 20 - Subprocesso para Definir Indicador ...................................................................... 92 Figura 21 - Subprocessos do PGIGR ...................................................................................... 132 Figura 22 Categorias de Classificao do Processo de Software da Organizao de TI..... 139 Figura 23 - Subprocesso para Categorizar a Organizao de TI ............................................ 140 Figura 24 - Viso Macro do Processo de Categorizao da Organizao de TI .................... 146 Figura 25 - Quatro Dimenses Focos para a gerao de indicadores ..................................... 148 Figura 26 - Subprocesso para Definir Foco para Definio de Indicadores ........................... 149 Figura 27 Subprocesso para Definir Objetivos (Metas) ...................................................... 152

Figura 28 - Subprocesso para Definir Perguntas (Questes) .................................................. 156 Figura 29 - Relacionamento entre Objetivos, Perguntas, Indicadores, Medidas Derivadas e Medidas bsicas (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 Gesto Quantitativa (adaptao de MONTEIRO, 2008) .......... 54 Quadro 3 Estrutura de Template de Indicador (Adaptado do SEI, 2004).............................. 58 Quadro 4 - Caractersticas Definidas para o Processo PGIGR ................................................. 71 Quadro 5 Exemplos de Grficos para Gerao de Indicadores ........................................... 173 Quadro 6 - Questionrio de avaliao do PGIGR .................................................................. 184

xii

LISTA DE TABELAS

Tabela 1 Nveis 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 Categorizao do processo de software da Organizao de TI............... 77 Tabela 5 - Matriz contendo as dimenses foco e descrio para cada uma das categorias ...... 85 Tabela 6 - Matriz contendo sugestes de objetivos (metas) para cada categoria e dimenso foco ................................................................................................................................... 87 Tabela 7 - Matriz contendo sugesto de Perguntas (Questes) para cada categoria e dimenso foco ................................................................................................................................... 89 Tabela 8 - Matriz contendo os Indicadores Sugeridos para cada categoria e dimenso foco .. 93 Tabela 9 - Consolidao dos dados da Primeira Etapa do Questionrio ................................ 102 Tabela 10 Consolidao dos dados da Segunda Etapa do Questionrio ............................. 104 Tabela 11 - Consolidao dos dados da Terceira Etapa do Questionrio .............................. 105 Tabela 12 - Avaliao do PGIGR Quanto ao Atendimento s Caractersticas Traadas para o Processo .......................................................................................................................... 111 Tabela 13 - Comparativo do PGIGR com os Demais Modelos de Criao de Indicadores ... 114 Tabela 14 - Objetivo do PGIGR formato GQM .................................................................. 131 Tabela 15 - Subprocessos e Atividades do PGIGR ................................................................ 135 Tabela 16 Definio de Papis e Habilidades necessrias para o PGIGR........................... 136 Tabela 17 - Itens para detalhamento de uma atividade .......................................................... 137 Tabela 18 - Matriz de Categorizao do processo de software da Organizao de TI........... 143 Tabela 19 Matriz contendo as dimenses foco e descrio para cada uma das categorias . 151 Tabela 20 Matriz contendo sugestes de objetivos (metas) para cada categoria e dimenso foco ................................................................................................................................. 154 Tabela 21 - Matriz contendo sugesto de Perguntas (Questes) para cada categoria e dimenso foco ................................................................................................................................. 158 Tabela 22 - Matriz contendo os Indicadores Sugeridos para cada categoria e dimenso 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

SUMRIO

Lista de Figuras ......................................................................................................................... ix Lista de Quadros ........................................................................................................................ xi Lista de Tabelas ........................................................................................................................ xii 1. Introduo ........................................................................................................................ 16 1.1. Motivao e Contexto............................................................................................. 16 1.2. Objetivos................................................................................................................. 19 1.2.1. 1.2.2. 1.2.3. 1.2.4. 2. Objetivo Geral ........................................................................................... 19 Objetivos Especficos ................................................................................ 20 Suposies ................................................................................................. 20 Organizao da Dissertao ...................................................................... 20

Referencial Terico ......................................................................................................... 21 2.1. Gerenciamento de Projetos ..................................................................................... 21 2.2. Gerenciamento de Riscos ....................................................................................... 22 2.3. Definio de Sucesso em Projetos de Desenvolvimento de Software.................... 24 2.4. Diagnstico do Sucesso em Projetos de TI ............................................................ 25 2.5. Qualidade de Software............................................................................................ 27 2.5.1. 2.5.2. 2.5.3. 2.5.4. Problemas Relacionados Baixa Qualidade de Software ......................... 28 Qualidade de Software e o Mercado Atual .............................................. 29 Capability Maturity Model Integration - CMMI ....................................... 30 Melhoria do Processo de Software Brasileiro - MPS.BR ......................... 31

2.6. Gesto de Requisitos .............................................................................................. 34 2.6.1. Gerenciamento de Requisitos .................................................................... 36

2.7. Medio de Software .............................................................................................. 37 2.7.1. 2.7.2. 2.7.3. 2.7.4. 2.7.5. 2.7.6. 2.7.7. 2.7.8. Conceitos ................................................................................................... 37 Indicadores ................................................................................................ 38 Objetivos de Medies em Projetos de Desenvolvimento de Software .... 39 Modelos para Gerao de Indicadores ...................................................... 43 Goal Question Metric - GQM .................................................................. 43 Goal Question Indicator Metric - GQ(I)M ................................................ 46 Practical Software Measurement - PSM ................................................... 48 Instrumentos de Anlise de Desempenho ................................................. 53

xiv

2.8. Desafios na Definio de Indicadores em Projetos de Desenvolvimento de Software ........................................................................................................................... 55 2.9. Estrutura de Template (modelo de documento) para Gerao de Indicadores ....... 56 2.10. Indicadores para o Gerenciamento de Requisitos................................................... 59 2.11. Consideraes Finais do Captulo .......................................................................... 61 3. Materiais e Mtodos de Pesquisa..................................................................................... 62 3.1. Classificao da Pesquisa ....................................................................................... 62 3.2. Fontes de Informaes Utilizadas........................................................................... 62 3.3. Etapas de Definio do Processo Proposto ............................................................ 64 3.4. Etapa de Reviso da Literatura ............................................................................... 67 3.4.1. Passo: Reviso da Literatura Referente a Sucesso e Fracasso em Projetos

de Software 67 3.4.2. 3.4.3. Passo: Estudo da Teoria de Base sobre Gesto de Requisitos ................. 68 Passo: Estudo da Teoria de Base sobre Medio em Projetos de Software 68 3.4.4. Passo: Estudo da Teoria de Base sobre Mtodos para Definio de

Indicadores 69 3.4.5. Passo: Estudo da Teoria de Base sobre Mtricas e Indicadores Existentes

para a Gerncia de Requisitos ................................................................................ 70 3.5. Etapa de Definio do Processo PGIGR ................................................................ 70 3.5.1. 3.5.2. 3.5.3. Passo: Definio das Caractersticas Desejadas para o Processo .............. 71 Passo: Definio da Estrutura Geral do Processo PGIGR ........................ 72 Passo: Definio das Atividades do Processo ........................................... 73

3.6. Avaliao do Processo Proposto ............................................................................ 96 3.6.1. 3.6.2. 3.6.3. 3.6.4. 3.6.5. 4. Propsito da Avaliao e Delimitao ...................................................... 96 Elaborao do Questionrio de Avaliao ................................................ 96 Identificao e Amostragem da Populao ............................................... 97 Aplicao do Questionrio ........................................................................ 97 Etapa de Anlise dos Dados ...................................................................... 98

Resultados e Discusses ................................................................................................ 100 4.1. Contextualizao dos Avaliadores e das Organizaes onde Trabalham. ............ 100 4.2. Consolidao dos dados da Primeira Etapa do Questionrio .............................. 101 4.3. Consolidao dos dados da Segunda Etapa do Questionrio ............................... 103 4.4. Consolidao dos dados da Terceira Etapa do Questionrio ............................... 105

xv

4.5. Consolidao dos Comentrios e Observaes Feitas pelos Avaliadores do Processo PGIGR ............................................................................................................ 106 4.5.1. 4.5.2. 4.5.3. 4.5.4. 4.5.5. Comentrios e Sugestes do Avaliador 1 ................................................ 106 Comentrios e Sugestes do Avaliador 2 ................................................ 107 Comentrios e Sugestes do Avaliador 3 ................................................ 108 Comentrios e Sugestes do Avaliador 4 ................................................ 108 Comentrios e Sugestes do Avaliador 5 ................................................ 110

4.6. Avaliao do PGIGR Quanto ao Atendimento s Caractersticas Traadas para o Processo ......................................................................................................................... 111 4.7. Comparativo do PGIGR com os Demais Modelos de Criao de Indicadores e Anlise dos Principais Benefcios Obtidos .................................................................... 113 5. Concluso ...................................................................................................................... 117

Referncias Bibliogrficas ...................................................................................................... 122 APNDICE A - Processo de Gerao de Indicadores para a Gesto de Requisitos - PGIGR 131 APNDICE B - Exemplos de Indicadores Detalhados ......................................................... 178 APNDICE C - Questionrio de Avaliao do Processo PGIGR ........................................ 184

16

1. INTRODUO
Este captulo apresenta o contexto em que a pesquisa foi realizada e como o trabalho foi organizado. 1.1. Motivao e Contexto A tecnologia da informao TI tornou-se onipresente nos dias atuais. Seu impacto nas organizaes evoluiu de tal forma que tem participao na manufatura, logstica, marketing, pesquisa e desenvolvimento, suporte deciso e at mesmo na forma como os indivduos se relacionam. A evoluo de TI est diretamente relacionada a projetos de desenvolvimento de software, pois eles so o meio pelo qual organizaes concretizam seus objetivos estratgicos e colocam seus produtos no mercado (LUFTMAN, 2004). Projetos possuem caractersticas que esto diretamente relacionadas a questes que envolvem riscos, pois a proposta de um projeto de gerar um produto, servio ou resultado exclusivo (PMBOK, 2004). Quando tratamos de projetos de desenvolvimento de software o fator risco se torna ainda mais eminente devido a fatores como: software complexo; software abstrato; tecnologia muda rapidamente; tecnologia um domnio vasto; requisitos muitas vezes so incompletos; as melhores prticas ainda esto em processo de amadurecimento; desenvolvimento de software praticamente uma atividade de pesquisa; mudanas so inevitveis. (STEPANEK, 2005) Pode-se observar a necessidade de melhorar a qualidade do software desenvolvido. No entanto, os esforos em melhoria da qualidade no podem ter seu foco no produto apenas (fazer o 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 esto fortemente relacionados e no 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 construo. 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 aceitveis, dentro do prazo e oramentos previstos), 53% dos projetos ficaram

17

acima do oramento e 18% no entregou produto algum. A pesquisa tambm mostra que os projetos que tm estouro de oramento normalmente acabam custando em mdia 56% a mais do que a previso original. Entre os fatores mais crticos que influenciam para o sucesso ou fracasso de projetos de desenvolvimento de software est a gerncia 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 esto vinculados gerncia de requisitos (LAMSWEERDE, 2000). Como exemplo de problemas relacionados gerncia de requisitos em projetos de desenvolvimento de software, podemos citar: scope creep (perda de controle do escopo); documentao mal elaborada; requisitos que no so factveis de serem contemplados; mudanas realizadas sem controle e requisitos que no atingem as expectativas dos usurios. Um bom gerenciamento de requisitos pode proporcionar uma melhor satisfao do usurio final, diminuir os custos de desenvolvimento e aumentar as chances de se obter sucesso em projetos de desenvolvimento de software. A complexidade da gesto de requisitos, dentro de projetos de desenvolvimento de software, requer que alm da experincia do gerente de projetos, tcnicas de gesto quantitativa sejam aplicadas de forma a perceber objetivamente a situao do projeto e prever a sua capacidade em atender aos seus objetivos. Isso demonstra que de extrema importncia que se monitore tais projetos de forma eficaz para que problemas relacionados gerncia de requisitos possam ser identificados com antecedncia, possibilitando maior controle e previsibilidade para os tomadores de decises. Organizaes esto cada vez mais preocupadas em aferir os resultados de seus processos utilizando dados objetivos para apoiar suas decises em todos os nveis. Assim, busca-se definir indicadores com o propsito de utiliz-los como ferramenta de controle e de tomada de decises. A medio de software tem evoludo dentro da disciplina Engenharia de Software. Hazan (2002) menciona que no passado muitas organizaes de software tratavam as medies como um trabalho adicional, muitas vezes considerada sem valor. Agora, a medio implementada como uma disciplina pr-ativa, e os indicadores constituem uma ferramenta estratgica. Kardec (2002) destaca que o indicador a expresso didtica da realidade. Costello (1995) destaca que as mtricas e indicadores trazem informaes objetivas e teis para o acompanhamento, gerenciamento e controle do processo de desenvolvimento.

18

Pesquisas bibliogrficas mostram que vrios autores exploraram aspectos relacionados s mtricas 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 gerao de medies e indicadores em um contexto mais amplo dentro da engenharia de software. Poucos tiveram como foco principal a gesto de requisitos. Entre os que exploraram a gerncia de requisitos com maior nfase podemos citar: Hazan (1999, 2001, 2002), que demonstra a criao 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 mtricas e indicadores para a gerncia de requisitos com o foco de validao 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 gerao de mtricas e indicadores para a gerncia de requisitos utilizando os mtodos GQM (BASILI, CALDIERA e ROMBACH, 1992, 1994; SOLINGEN e BERGHOUT, 1999) e PSM (2008), que so modelos para especificao de indicadores de software, no entram em detalhes a respeito de como se chegar aos indicadores gerados, tendo como foco principal em seus trabalhos a validao e aplicabilidade dos indicadores propostos. Tambm nota-se certa carncia nos trabalhos no que tange descrio do contexto organizacional em que as mtricas e indicadores foram criados. Isso acaba tornando difcil replicar os indicadores propostos dentro de outro contexto organizacional, pois organizaes distintas apresentam diferentes realidades e necessidades. Nesse contexto, no qual a gerncia de requisitos se posiciona como um dos pilares para o sucesso de projetos de desenvolvimento de software e a utilizao de indicadores sendo uma ferramenta essencial para que se tenha um correto controle de projetos, uma questo importante a ser resolvida como apoiar organizaes que desenvolvem software na tentativa de aprimorar a gesto de requisitos, visando, consequentemente, dar maior controle e previsibilidade. De forma

19

mais especfica, como uma organizao deve proceder para que possa gerar indicadores para melhor gerenciar requisitos? 1.2. Objetivos Apesar de existirem modelos que auxiliem na definio de indicadores, como por exemplo GQM; GQ(i)M e PSM, todos eles so de certa forma genricos. Por serem genricos acabam exigindo alto grau de adaptao e profissionais com qualificao especfica para este tipo de trabalho, visando adequar os processos s necessidades de cada organizao, o que acaba acarretando em maior investimento em tempo e custo para uma correta compreenso e adaptao dos modelos s necessidades da organizao. Devido ao fato das definies de objetivos, perguntas e indicadores padro em todos os modelos supracitados ficarem totalmente a critrio das organizaes, acaba-se gerando maior margem para erros, seja por inexperincia dos profissionais envolvidos, falta de clareza do processo ou dos objetivos da organizao. Mas, com o intuito de agilizar e facilitar o processo de definio de indicadores para a gerncia de requisitos, faz-se necessrio a utilizao de um processo consistente, simples e especfico para requisitos. Um processo que direcione seus usurios em cada uma das etapas de construo dos indicadores, possibilitando um correto monitoramento de fatores relacionados a requisitos em projetos de desenvolvimento de software, possibilitando maior previsibilidade e mitigao de riscos. nesse contexto que so apresentados os objetivos abaixo. 1.2.1. Objetivo Geral O objetivo deste trabalho propor um processo para a definio de indicadores especficos para a gesto de requisitos em projetos de desenvolvimento de software. Esse processo, quando executado, deve permitir que diferentes organizaes possam seguir passos claros e bem definidos, possibilitando criar indicadores especficos para suas necessidades e caractersticas no que tange gesto 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 tpicos das organizaes, sem a necessidade de especialistas em mtricas.

20

1.2.2.

Objetivos Especficos i. Definir um conjunto de caractersticas desejadas para um processo de definio de indicadores para gesto de requisitos; ii. Elaborar um processo para gerao de indicadores para gesto de requisitos, atendendo s caractersticas previamente traadas; iii. iv. Avaliar o processo proposto; Aprimorar o processo aps avaliao;

1.2.3.

Suposies Este trabalho de pesquisa est orientado pela seguinte suposio: O processo proposto neste trabalho ir conduzir profissionais tpicos de desenvolvimento de software na definio de indicadores de requisitos, mesmo que estes profissionais no sejam especialistas na rea de mtricas.

1.2.4.

Organizao da Dissertao Este trabalho constitudo de cinco captulos, incluindo esta Introduo. O captulo 2 apresenta o referencial terico, onde as definies e conceitos pertinentes

aos tpicos principais do tema da pesquisa so apresentados, so eles: gerncia de projetos, medio de software, modelos de especificao de mtricas e indicadores, e engenharia de requisitos de software. No captulo 3 so apresentados os materiais e mtodos de pesquisa, onde descrita a metodologia seguida para se criar o processo proposto por este trabalho. No captulo 4 so apresentados os resultados e anlises a partir da avaliao do processo proposto. Por fim, o captulo 5 apresenta as concluses da pesquisa, destacando-se as contribuies e perspectivas de trabalhos futuros.

21

2. REFERENCIAL TERICO
Nesta seo apresentado o referencial terico que embasa o trabalho, envolvendo os conceitos de gerncia de projetos, qualidade de software, gesto de requisitos, medio de software e modelos de especificao de indicadores. 2.1. Gerenciamento de Projetos Como este trabalho ir tratar sobre a gerncia de requisitos dentro do contexto de projetos de desenvolvimento de software, necessrio entender as prticas e conceitos a respeito desse assunto. Esta seo apresenta uma breve explanao terica a respeito de conceitos relacionados Gerncia de Projetos. Segundo Prado (1998), a Gerncia de Projetos um ramo da Administrao que trata do planejamento e controle de projetos. Gerenciar um projeto significa, resumidamente, planejar a sua execuo antes de inici-lo e acompanhar a sua execuo. Um projeto um sistema de recursos e atividades com a finalidade de fornecer um produto, atendendo a restries de prazo, oramento e qualidade. Gerenciamento de projetos o processo de tomar decises que envolvam o uso dos recursos para realizao de atividades em um projeto (MAXIMIANO, 2002). O gerenciamento de projetos realizado atravs de processos, utilizando conhecimentos, habilidades, ferramentas e tcnicas. Para que o projeto seja bem sucedido, devem ser selecionados os processos necessrios 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 esto agregados em cinco grupos, em funo da integrao 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 Iniciao Planejamento Execuo Monitoramento e controle Encerramento Objetivo Define e autoriza o projeto ou uma fase do projeto Define e refina o escopo do projeto e seus objetivos e planeja as aes necessrias para alcanar esses objetivos. Integra pessoas e outros recursos para realizar o plano de gerenciamento do projeto Mede e monitora regularmente o progresso do projeto para identificar variaes com relao ao plano para que possam ser tomadas as aes corretivas necessrias Formaliza a aceitao do produto do projeto e conduz o projeto (ou fase) a um final ordenado.

Os mesmos processos esto agrupados tambm 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: integrao, escopo, tempo, custos, qualidade, recursos humanos, comunicaes, riscos e aquisies. Ao descrever um processo, o PMBOK (2004) indica quais devem ser suas entradas e sadas. Sugere tambm um conjunto de conhecimentos, tcnicas e ferramentas que podem ser utilizados na sua execuo. Essa definio, entretanto, no mandatria, ou seja, nem todas as sadas devem ser geradas obrigatoriamente e nem todas as tcnicas precisam ser aplicadas. Cabe a cada equipe de projeto adaptar o processo s suas necessidades. 2.2. Gerenciamento de Riscos Este trabalho no pretende abordar diretamente a rea de conhecimento de riscos, porm a mitigao de risco um aspecto inerente aos objetivos almejados, tendo em vista que o efetivo monitoramento de projetos por meio de indicadores para gerncia de requisitos visa minimizar riscos e apoiar na tomada de decises. Sendo assim, torna-se relevante a abordagem de aspectos conceituais relacionados ao assunto. Esta seo apresenta uma breve explanao terica a respeito de riscos.

23

Todo projeto tem risco. Sempre h um nvel de incerteza associado ao resultado de um projeto. Projetos de software so especialmente arriscados, seja por conta do alto grau de variao ou pelas rpidas mudanas no contexto. A importncia 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 esto inseridos no contexto maior e mais complexo dos negcios e no esto isentos de interferncias desse mundo. Interferncias que so independentes da vontade do gerente ou da equipe do projeto e so imprevisveis e podem afetar seu sucesso. Esses fatores representam, portanto, uma classe especfica de riscos que esto muitas vezes ligadas gerncia de requisitos, pois atravs dela que se define e se controla as necessidades dos stakeholders (envolvidos) nos projetos. O dicionrio Aurlio (HOLANDA, 1986) da Lngua Portuguesa define risco como sendo a probabilidade de insucesso, de malogro de determinada coisa, em funo de acontecimento eventual, incerto, cuja ocorrncia no 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 bsicas na categoria de Gerenciamento de Projetos em sua viso contnua. O objetivo do gerenciamento de riscos, segundo o CMMI, identificar problemas previamente, possibilitando que atividades de tratamento de riscos sejam planejadas e acionadas para mitig-los. O PMBOK (2004) tambm define o gerenciamento de riscos como uma das reas de conhecimento, incluindo processos de identificao, anlise, respostas, monitoramento e controle dos riscos do projeto. O objetivo perseguido aumentar as chances de sucesso do projeto. De um ponto de vista de administrao financeira, Saunders (2000) caracteriza o risco tecnolgico, associado crescente dependncia das empresas com relao aos sistemas baseados em software. Ao investir em Sistemas de Informao (SI), as empresas buscam economia de escala com reduo dos custos mdios operacionais e economias de escopo com a capacidade de produzir mais de um servio com o mesmo recurso. Alm disso, os SI tm um papel fundamental na inovao, na conquista de novos mercados e na diferenciao com relao concorrncia. O risco tecnolgico, nesse caso, se d quando os investimentos no produzem os resultados esperados, podendo reduzir a capacidade competitiva da empresa. O maior risco que um projeto enfrenta o de no atender s condies de sucesso de seus stakeholders crticos. Mais importantes que o risco de no cumprir o cronograma ou o

24

oramento, o risco de no gerar valor para a organizao patrocinadora. Esse risco deve sempre ser levado em conta pelo gerente do projeto. A gerao de valor est diretamente relacionada a aspectos vinculados gerncia de requisitos, pois por meio dela que se definem as necessidades dos stakeholders. Este trabalho utilizar conceitos relacionados ao monitoramento, controle e mitigao de riscos envolvendo a gerncia de requisitos dentro do contexto de projetos de desenvolvimento de software. 2.3. Definio de Sucesso em Projetos de Desenvolvimento de Software Um projeto por definio um empreendimento temporrio, com objetivo de criar um produto, servio ou resultado nico (PMI, 2004). Mas como se define sucesso? A busca por essa definio talvez seja um dos temas mais discutidos na rea de gerncia de projetos. De acordo com Cajado (1999), para que um projeto de software seja bem sucedido necessrio que alguns parmetros sejam bem analisados como, por exemplo, o escopo do software, os riscos envolvidos, os recursos necessrios, as tarefas a serem realizadas, os marcos de referncia a serem acompanhados, os esforos (custos) aplicados e a sistemtica a ser seguida. A anlise de todos estes parmetros a funo tpica do gerenciamento de projetos, funo esta que se inicia antes do trabalho tcnico 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 reduo de riscos, particularmente em projetos de tecnologia da informao, nos quais as prprias mtricas que permitiriam a medio de sucesso tm que ser acordadas. Segundo o dicionrio Michaelis, a palavra sucesso tem o seguinte significado: su.ces.so: sm (lat successu): 1 resultado bom ou mau de um negcio. 2 concluso. 3. xito, resultado feliz.. O primrios: Escopo: o projeto foi finalizado dentro da especificao prevista; Custos: o projeto foi finalizado dentro do oramento previsto; Tempo: o projeto foi finalizado dentro do tempo (cronograma) previsto; Qualidade: o projeto entregou a qualidade esperada. PMBOK (PMI, 2004) estabelece sucesso em projetos a partir de quatro fatores

25

2.4. Diagnstico do Sucesso em Projetos de TI O setor de tecnologia da informao (TI), apesar de ser uma das reas que mais evoluiu recentemente, apresenta desvantagem histrica quando comparada com outras reas de conhecimento. Um exemplo bastante utilizado a comparao com a rea da construo civil, que no decorrer de sculos faz com que seja comum empreendimentos dentro do prazo previsto, dentro do oramento e com a garantia que no desmoronem aps sua concluso. Uma das razes conhecidas por trs deste fato em funo do tempo que gasto com detalhes do desenho do empreendimento antes de sua construo. O desenho tem que ficar estvel em determinado momento para que possa ser construdo. A flexibilidade para mudanas, apesar de existir, menor durante seu desenvolvimento. Quando nos voltamos para projetos de desenvolvimento de software essa realidade no necessariamente a mesma. At em funo das constantes mudanas que o ambiente de negcios impe realidade das corporaes e a velocidade da evoluo que TI teve que apresentar para acomodar estas mudanas de uma forma mais flexvel. No existe outro setor que tenha se desenvolvido e evoludo tanto e em um ritmo to devastador quanto o de tecnologia (IEEE, 2001; 2004). E, particularmente, quando nos referimos ao desenvolvimento de software esta evoluo frentica teria que apresentar conseqncias, principalmente no que diz respeito taxa de sucesso em projetos. O Standish Group (2007), h mais de uma dcada, realiza estudos sobre os resultados dos projetos de software ao redor do mundo. O resultado desses estudos um relatrio batizado de Chaos Report Relatrio 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 relatrio, a taxa de sucesso em projetos de tecnologia da informao 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 incio do projeto; e 15% dos projetos esto classificados 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 oramento. A pesquisa tambm levantou as 10 principais causas que trilham para o sucesso dos projetos de desenvolvimento de software, sendo que as trs primeiras so: 1. Envolvimento dos Usurios 2. Apoio da alta direo 3. Requisitos bem estabelecidos Entre os fatores que mais contribuem para o fracasso tambm foram listados os 10 principais, sendo que os trs primeiros so: 1. Falta de envolvimento dos usurios 2. Requisitos incompletos 3. Constantes alteraes de requisitos

27

Todos os trs fatores de fracasso mencionados acima esto relacionados com a gesto 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 adequao ao uso. Conformidade aos requisitos implica que requisitos devem ser claramente apresentados. Ento, em qualquer processo de produo, medies devem ser obtidas continuamente para determinar a conformidade aos requisitos. As no conformidades relacionam-se aos defeitos encontrados no produto. A definio de qualidade como conformidade aos requisitos dos clientes especialmente relevante indstria 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 so erros de requisitos. Um processo de desenvolvimento que no estabelece requisitos de qualidade est limitado a produzir software de m qualidade. De uma forma genrica, um software de boa qualidade produz resultados teis e confiveis na oportunidade certa; mensurvel e auditvel; corrigvel, modificvel, e evolutivo; opera em mquinas e ambientes reais; foi desenvolvido de forma econmica 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, mtodos e tcnicas de desenvolvimento especficas (KAN, 1995). Conforme a definio 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 necessrio um sistema de medies implantado para a coleta dos dados quantitativos necessrios para a gerncia do processo atravs de indicadores da qualidade. Na viso do usurio, 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 mnimo tolerado, o software ser considerado intil pelo usurio. No entanto, um software contendo muitos recursos (funcionalidades), extrapolando as funcionalidades exigidas pelo usurio, pode extrapolar limites oramentrios. Alm disso, o software deve ter caractersticas que atendam s necessidades de todos seus usurios. Os usurios do software so: Cliente (quem contrata a equipe para o desenvolvimento

28

do projeto de software), Usurio Final (quem utilizar o software desenvolvido), Desenvolvedores (profissionais que atuam no desenvolvimento e na manuteno do software) e Suporte (profissionais que auxiliam tanto o desenvolvedor quanto o usurio final). Portanto, deve-se avaliar os resultados de cada fase do processo de desenvolvimento de software para assegurar a qualidade dos produtos intermedirios e, conseqentemente, garantir um software de boa qualidade, pois, em cada fase do processo, um produto intermedirio produzido para um usurio intermedirio. Assim, cada produto intermedirio 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 aderncia do produto finalidade para a qual este foi construdo. Ou seja, o software que d ao usurio 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 boa performance, ausncia de bugs (a presena de bugs reduz a confiana do usurio), tolerncia a falhas de infra-estrutura (hardware), tolerncia a erros do usurio (KAN, 1995). Investimentos em qualidade minimizam custos. O aumento da qualidade normalmente acompanhado por aumento de produtividade e reduo de custos na forma de menos retrabalho. Isso sem falar em maior satisfao do cliente, que pode ser refletida muitas vezes em maior participao no mercado. Em mdio prazo, o software com melhor qualidade sofre menos manutenes e as manutenes necessrias so feitas rapidamente. Isso libera recursos para o desenvolvimento de novos projetos de software, reduzindo o backlog (pendncias) e acelerando o desenvolvimento. Alm disso, o processo de desenvolvimento pode ser continuamente melhorado para aumentar sua eficincia (prazos menores e menos recursos gastos) e melhorar sua eficcia (resultados), com o objetivo de garantir a satisfao do cliente. Quando dividimos o processo de desenvolvimento de software dentro da descrio do problema: projeto funcional; projeto tcnico; construo e implementao, um erro que introduzido na fase de projeto e tenha que ser reparado em uma fase posterior, incorre consideravelmente em alto custo e esforo (KRISTEN, 1996).

29

Assim, a soluo para mudanas nas especificaes do usurio final pode tambm ser encontrada na melhora da qualidade das especificaes do projeto do software. Mas, a qualidade das especificaes depende de um alto grau de entendimento mtuo das pessoas envolvidas. Segundo Jones (1994), algumas das principais motivaes para se investir em qualidade de software so: I. Reduo dos atrasos dos projetos: produtos com muitos defeitos implicam gasto de muitas horas na correo, sendo que essas horas poderiam ser utilizadas para avanar o projeto. Alm disso, o nmero de horas consumidas para corrigir um defeito aumenta proporcionalmente ao tempo entre a sua introduo e a sua excluso, 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. Reduo dos custos de manuteno: quanto menos defeito tiver um software no seu desenvolvimento, menos horas sero despendidas na correo aps a implantao. IV. Minimiza desgaste com os usurios (ou clientes): gerentes reconhecem este custo como declnio da reputao entre consumidores. Eles ressaltam a fragilidade de sua reputao com seus clientes e a importncia de ganhar a confiana do cliente. Em resumo, todas estas motivaes acima tm um ponto de intercesso 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 exigncia de garantia da qualidade por parte dos clientes. A tendncia das instituies reduzir o nmero de seus fornecedores de software, excluindo dos seus negcios aqueles que no esto aptos a fornecer qualidade em seus produtos. Algumas instituies j utilizam como pr-requisito para escolha de seus fornecedores de software determinado nvel 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 negcios. Deming (SANDERS, 1994) sugere que esse fenmeno uma

30

relao 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 reduo de custos. Com isso, aumenta-se o mercado, havendo um crescimento nos negcios da empresa, o que gera retorno de investimentos.

Figura 2 Efeitos do aprimoramento da Qualidade de Software (SANDERS,1994)

Atualmente so vrios os modelos de melhoria de processo de software disponveis no mercado, dos quais se destacam: CMMI, ISO 15504 e o modelo brasileiro MPS.BR. Todos tm 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 aplicao de tcnicas de medio e gerncia 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 evoludo para o CMMI (2001). A principal mudana entre o CMM e o CMMI no que tange o nvel 2 de maturidade a nfase no estabelecimento de um processo de medio, por meio da criao de uma nova rea de processo chamada de Medio e Anlise.

31

A rea de processo Medio e Anlise do nvel 2 do modelo CMMI tem o objetivo de desenvolver e sustentar uma capacidade de medio usada para suportar gerencialmente as necessidades de informao. Esta rea inclui o seguinte: i. Especificao dos objetivos de medio e anlise de forma que estes sejam alinhados com as necessidades de informao identificadas e objetivos; ii. Especificao das medidas, mecanismos de coleta de dados e de armazenamento, tcnicas de anlise, e mecanismos de comunicao e de feedback; iii. iv. Implementao da coleta, armazenamento, anlise, e comunicao dos dados; Fornecimento de resultados objetivos que podem ser usados na tomada de deciso e implementao de aes corretivas apropriadas. A Gerncia de Requisitos de Software uma rea de processo do nvel 2 Gerenciado do CMMI, tendo como propsito gerenciar os requisitos dos produtos, do projeto e dos componentes do produto e identificar as inconsistncias entre os requisitos e os planos do projeto e produtos de trabalho. As principais atividades da gerncia de requisitos so documentar as mudanas 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 utilizao de indicadores uma possvel forma de se fazer tal monitoramento. 2.5.4. Melhoria do Processo de Software Brasileiro - MPS.BR O MPS.BR um modelo de melhoria e avaliao de processo de software brasileiro, voltado para as micro, pequenas e mdias empresas, de forma a atender as suas necessidades de negcio. Conforme a SOFTEX (2007), a base tcnica utilizada para a construo 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) Avaliao de Processo e seu Modelo de Avaliao de Processo de Software ISO/IEC 15504-5 (2004); e o modelo CMMIDEV (SEI, 2006). Portanto, o modelo est totalmente aderente a essas normas. O MPS.BR tambm cobre o contedo do CMMI-SE/SW (2001), atravs da incluso de processos e resultados de processos em relao 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 Referncia (MR-MPS) contm os requisitos que as organizaes devero atender para estar em conformidade com o MR-MPS. Ele contm as definies dos nveis 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 CMMISE/SW (2001); Mtodo de Avaliao (MA-MPS) contm o processo de avaliao, os requisitos para os avaliadores e os requisitos para averiguao da conformidade ao modelo MR-MPS. baseado na norma ISO/IEC 15504 (2004); Modelo de Negcio (MN-MPS) contm uma descrio das regras para a implementao do MR-MPS pelas empresas de consultoria, de software e de avaliao. 2.5.4.1. Nveis de Maturidade

Os nveis de maturidade estabelecem marcos de evoluo de processos, caracterizando os estgios de melhoria de implementao de processos na organizao e permitindo prever o seu desempenho futuro em uma ou mais disciplinas. O MR-MPS (SOFTEX, 2007) define sete nveis de maturidade: A (Em Otimizao), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado), com a escala de maturidade comeando no nvel G e terminando no nvel A. Para cada um destes sete nveis de maturidade

33

foi atribudo um perfil de processos e de capacidade de processos. Indicando os pontos fracos nos quais a organizao dever manter seu esforo para melhorar, de forma a atender os objetivos de negcio. A Tabela 1 mostra os nveis de maturidade com seus respectivos perfis de processo e capacidade de processo.
Tabela 1 Nveis de Maturidade do MPS.BR

Pode ser observado na tabela acima, a rea de processo de gerncia de requisitos, assim como a gerncia de projetos so a base de sustentao para os demais nveis, estando localizadas no primeiro nvel (G Parcialmente Gerenciado). J a rea de medio encontra-se no nvel logo acima (F - Gerenciado), portanto no requerido de uma organizao que implante no nvel G o processo de Medio. Este trabalho ir abordar prticas utilizadas em ambos os processos.

34

2.6. Gesto de Requisitos Projetos de software complexos so normalmente entregues com atraso, com oramentos estourados e no atendem s necessidades dos stakeholders, conforme mostrado em vrios estudos e pesquisas (BRAY, 2003; KOTONYA, 2002; SHENHAR, 2003; STANDISH GROUP, 2007). A ocorrncia desses problemas normalmente tem algum relacionamento com os requisitos do software. Uma pesquisa recente feita em 3800 empresas em 17 pases concluiu que mais de 50% dos problemas apresentados em projetos de software esto diretamente relacionados com a engenharia de requisitos e gerncia de requisitos (LAMSWEERDE, 2000). Um requisito uma declarao que descreve uma funcionalidade (requisito funcional) ou uma propriedade (requisito no funcional) de um sistema. A ideia descrever o que o sistema deve fazer ao em vez de como fazer. Requisitos precisam ser levantados, analisados, documentados e validados, conforme ilustrado na Figura 4 abaixo. Essas so as principais atividades no processo de engenharia de software (KOTONYA, 2002). Segundo Davis (1993), o objetivo da engenharia de requisitos converter definies pobres do problema a ser tratado em uma especificao coesa e inteligvel.

35

Gerncia de Requisitos

Levantamento dos Requisitos

Anlise dos Requisitos

Documentao dos Requisitos

Validao dos Requisitos

Necessidades dos usurios, informaes de domnio, informaes de sistemas existentes, regulamentaes, padres, etc...

Requisitos acordados

Figura 4 - Processo de Engenharia de Requisitos (Adaptao de KOTONYA, 2002)

Requisitos so basicamente as necessidades do cliente. Podemos resumir como sendo as condies ou necessidade que um sistema em desenvolvimento deve atender. Easterbrook (2004) define a Engenharia de Requisitos como sendo uma ponte entre as necessidades dos usurios e a sua concretizao em um sistema computacional. Requisitos implica que existe algum solicitando, um cliente que sabe aquilo que necessita. Em alguns projetos, requisitos so interpretados como sendo uma lista de caractersticas (funcionalidades) demandadas por um cliente. O termo Engenharia sugere que a engenharia de requisitos uma disciplina por si s, porm 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 matria prima para a gerao 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 identificao, controle e acompanhamento dos requisitos e suas mudanas durante toda a durao do projeto. Conforme apresentado anteriormente, a gerncia de requisitos tambm um processo chave (KPA) do CMMI (2001) e do MPS.BR (SOFTEX, 2007). No CMMI ele encontra-se no nvel 2 de maturidade e no MPS.BR no nvel G. A gerncia de requisitos inclui o estabelecimento e a manuteno de acordos entre clientes e desenvolvedores com relao a requisitos tcnicos e no tcnicos. 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 extenso do projeto, com o intuito de aprimorar o desenvolvimento do software. Algumas das atividades envolvidas so: Planejamento da fase de requisitos. Estabelecimento do processo de requisitos. Controle de alterao de requisitos. Minimizao da adio de novos requisitos (scope creep). Acompanhamento do progresso. Resoluo de conflitos entre clientes e equipe tcnica. Estabelecimento de reviso de requisitos (reviso por pares). Gerenciamento de requisitos inicia com a definio dos requisitos e continua durante toda a extenso do projeto, culminando na validao do produto final com as especificaes previamente acordadas com o cliente (LUDWIG, 2002). 2.6.1.1. Problemas e Riscos associados Gerncia de Requisitos

Segundo El Emam (1997), os principais problemas relacionados gerncia de requisitos so: dificuldades de identificar as mudanas nos requisitos; falta de habilidade para chegar a um consenso sobre as mudanas chave para os stakeholders; falta de habilidade para manter o documento de requisitos consistente; falta de habilidade para estimar adequadamente os recursos necessrios para implementar as mudanas nos requisitos.

37

Segundo Jones (1994), o principal risco que atinge 80% dos projetos de software o da evoluo de requisitos de forma descontrolada. Este risco definido como: Novos requisitos ou modificaes significativas nos requisitos existentes que so feitas aps o conjunto bsico de requisitos acordado pelos clientes e desenvolvedores. Falhas para antecipar mudanas de requisitos (previso de aumento ou mudana do escopo do projeto scope creep) e fazer planos para lidar com estes. Como os requisitos so volteis, a prpria natureza do processo leva ao que Jones (1994) classifica de risco inerente. Os principais problemas associados a este risco so os seguintes: atritos entre a equipe de desenvolvimento, gerentes e usurios; no atendimento ao prazo acordado; software de baixa qualidade e altos custos. Isso tudo faz da Gerncia 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 deciso atravs da utilizao de tcnicas de medies. 2.7. Medio de Software Processos efetivos de medio do desempenho maximizam as chances de se obter sucesso, pois permitem organizao entender a sua capacidade de forma a desenvolver planos atingveis para a entrega de produtos e servios. As medies auxiliam tambm na deteco de tendncias e na antecipao de problemas, agregando previsibilidade, melhor controle de custos, reduo de riscos, melhoria da qualidade e garantindo que os objetivos do negcio sejam atingidos (FLORAC; CARLETON, 1999). 2.7.1. Conceitos Medio um conjunto de operaes com objetivo de determinar um valor a uma medida (ISO/IEC, 2002). Medio o processo pelo qual nmeros ou smbolos so designados para atributos de entidades do mundo real atravs de um conjunto definido de regras. Uma vez que essa associao estabelecida possvel comparar a entidade fsica atravs dos nmeros associados. Essa comparao resulta em medies. Por exemplo, idade um atributo comum da entidade pessoa. A medida resultante de pessoa poderia ser nmero de anos, nmero de meses ou nmero de dias (FENTON e PFLEEGER, 1998).

38

Medio pode ser definida como o mapeamento do mundo emprico ou real para o mundo formal, representado por elementos de um sistema numrico. Conseqentemente, uma medida o nmero ou smbolo atribudo a uma entidade atravs 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 possvel express-lo em nmeros, pode-se dizer que voc sabe o que est sendo tratado, porm, quanto no se pode expressa-lo em nmeros, seu conhecimento a respeito do assunto insuficiente e insatisfatrio. O aspecto importante sobre medies que elas trazem um senso comum para um determinado assunto, pois precisam ser padronizadas no intuito de significar a mesma coisa para todos. A utilizao de medies faz com que seja possvel avaliar o processo de desenvolvimento de software, possibilitando identificar aspectos que esto fora dos resultados esperados, possibilitando o seu ajuste durante o processo. Os custos gerados pelo processo de desenvolvimento de software so altos. Atravs de medies possvel gerar melhores estimativas de custo e maior previsibilidade de durao dos projetos, minimizando erros e custos com retrabalho. A ideia que a todo momento se tenha informaes precisas para aprimorar a tomada de deciso. Garca et al (2006, p. 635) afirma no haver tratamento uniforme para alguns conceitos bsicos de medio como mtrica, medida bsica, medida derivada e indicador. Neste contexto, importante definir os conceitos que sero utilizados como base para este trabalho. Outro conceito importante na rea de medio 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 combinao de medidas, normalmente apresentado na forma grfica, que prov entendimento a respeito de uma questo ou conceito de software. Os indicadores so a base para a anlise e tomada de deciso, portanto so eles que devem ser apresentados aos usurios ou consumidores das informaes. 2.7.2. Indicadores O SEI (2004) define um indicador como uma representao de uma medio com o intuito de promover uma visibilidade quantitativa especfica de determinado aspecto do desenvolvimento de software.

39

Um indicador um dado numrico, expresso em uma unidade de medida ao qual se atribui uma meta e que trazido periodicamente ateno dos gestores dos processos com a finalidade de apoi-los na avaliao do desempenho (TAKASHINA e FLORES, 1996; FPNQ, 2001). As decises devem ser baseadas no resultado dos indicadores, considerando as tendncias e os referenciais de comparao. Uma anlise de tendncia leva em considerao o comportamento de um conjunto de resultados de um indicador especfico ao longo do tempo. Segundo os Critrios de Excelncia (FPNQ, 2003), uma tendncia favorvel quando ocorre uma variao positiva de resultados de no mnimo trs perodos de tempo consecutivos. Os resultados dos indicadores de referenciais comparativos podem ser internos ou externos organizao. Deve-se selecionar um conjunto de mtricas pequeno e equilibrado, que ir ajudar a organizao a acompanhar o progresso na direo de seus objetivos (HAZAN, 2001). Os mtodos GQM (BASILI, 1992; BASILI, CALDEIRA, ROMBACH, 1994), GQ(I)M (PARK et al., 1996) e PSM (2008) so exemplos de frameworks utilizados para definir mtricas e indicadores apropriados aos objetivos das organizaes. Todos esses mtodos tem em comum a seleo de alguns objetivos de medio. As fontes para os objetivos podem ser necessidades gerenciais, tcnicas, de projeto, de produto, ou de implementao do processo. Declaram-se os objetivos de modo que sejam quantificveis e mensurveis. Posteriormente, para cada objetivo, identificam-se as perguntas que precisam ser respondidas para determinar se o objetivo est sendo alcanado. Finalmente, identificam-se mtricas e indicadores que ajudam a responder cada pergunta.

2.7.3.

Objetivos de Medies em Projetos de Desenvolvimento de Software Porque medir software? Segundo Fenton e Pfleeger (1998), No se pode prever ou

controlar aquilo que no possvel medir. Hazan (1999) destaca um conjunto de razes para se medir software: formar uma linha de base (baseline) para estimativas; determinar se as metas de produtividade do processo esto sendo atingidas; determinar se as metas de qualidade do processo esto sendo atingidas; determinar se as metas de qualidade do produto esto sendo atingidas;

40

avaliar os benefcios de novos mtodos, treinamentos e ferramentas; melhorar o relacionamento com o cliente; melhorar a gerncia de contratos de software; reduzir o risco de presso excessiva do cronograma; melhorar a gerncia de projetos de desenvolvimento de software; entender e aperfeioar o processo de software; As mtricas e indicadores trazem informaes objetivas e teis para o acompanhamento, gerenciamento e controle do processo de desenvolvimento (COSTELLO, 1995). As mtricas identificadas na literatura para o processo de requisitos podem ser agrupadas nas seguintes classes (COSTELLO, 1995; DAVIS, 1993; FARBEY, 1990; FENTON, 1998; HAMMER, 1998): mtricas para aferio da qualidade; mtricas para gerenciamento e evoluo de requisitos; mtricas para verificao/validao. Segundo Goodman (1993), mtricas so o alicerce da engenharia de software. Ele classifica todo esse processo como sendo a aplicao contnua de tcnicas de medio ao desenvolvimento de software e seus produtos no intuito de promover informaes teis e temporalmente relevantes (mtricas) para o aprimoramento do processo de desenvolvimento e seus produtos. Costello e Liu (1995) definem mtrica como sendo a derivao de medio de um produto de software, processo ou recursos. O seu propsito promover uma avaliao quantitativa a respeito do produto, processo ou recursos atravs da utilizao de alguns atributos associados. Uma mtrica uma medida de qualidade. Mtricas podem ser utilizadas para aprimorar a qualidade do software, produtividade e promover melhor utilizao dos recursos, produtos e processo. Mtricas de software apresentam informaes sobre o processo de desenvolvimento, como custos, tempo durante todas as fases do projeto. O ideal que as mtricas sejam (Everald, 1988): Simples

41

Objetivas De fcil coleta Vlidas (consistentes) Robustas Mtricas devem medir o que elas foram concebidas para medir, e devem ser de fcil

entendimento para o pblico alvo a um custo razovel. Medies em projetos de desenvolvimento de software permitem um melhor entendimento do ambiente de desenvolvimento e promovem informaes detalhadas sobre o projeto. Mtricas so utilizadas no intuito de melhor prever, gerenciar e controlar o projeto. Com o apoio de um conjunto consistente de mtricas possvel se planejar de forma mais apropriada e assertiva. Medies de software promovem guias que nos indicam onde estamos e para onde estamos indo dentro do processo de desenvolvimento de software. A medio 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 so executadas durante o desenvolvimento de software. 2. Produto: qualquer artefato, entregvel ou documento que resulte de uma atividade de processo, por exemplo, o cdigo fonte. 3. Recursos: entidades essenciais para a execuo das atividades do processo, como por exemplo, ferramentas e pessoas. Medio em projetos de software prov uma forte motivao para que organizaes analisem os dados e resultados gerados pelos seus projetos. Existem trs razes para que organizaes utilizem medies em seus processos de desenvolvimento de software (MCGARRY, 2001): Melhor entendimento - O aumento do entendimento atravs de medies 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 deciso. Um programa de medies possibilita uma melhor estimativa de

42

custos, melhor desenvolvimento do cronograma, maior visibilidade de recursos necessrios e melhor controle de riscos. Melhor controle - Uma melhor visibilidade da gerncia 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 primrio de qualquer organizao de engenharia de software de produzir produtos de qualidade dentro do prazo e oramento previstos. Mas um constante objetivo que devem seguir o aprimoramento contnuo em qualidade de seus produtos e servios. O aprimoramento de produtos pode ser atingido atravs do aprimoramento de processo utilizado para gerar o produto. O aprimoramento de processo requer a incorporao de mudanas no processo, que podem ser alcanadas atravs de mudanas gerenciais, tecnolgicas. Em qualquer um dos dois casos a medio de software parte fundamental do processo de aprimoramento, pois ela est diretamente relacionada ao fato de ser necessrio saber a qualidade do produto antes e depois da alterao do processo. O modelo CMMI (2001) e MPS.BR (SOFTEX, 2007) so exemplos de processos de melhoria do processo de desenvolvimento de software. Comunicar eficientemente: Medies ajudam a identificar, priorizar, acompanhar e comunicar os objetivos e questes associadas em todos os nveis da organizao. E tambm na comunicao entre organizaes contratantes e contratadas. Leite (2001) ressalta que as mtricas so essenciais para uma comunicao objetiva e precisa. Acompanhar Objetivos de Projetos Especficos: Medies 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 parmetros quantitativos de projeto resulta em planejamento e controle eficazes. Identificar e Corrigir Problemas Cedo: Medies apiam a estratgia de gerncia prativa. Problemas potenciais so objetivamente identificados, conforme os riscos sejam avaliados e gerenciados. Os problemas existentes so avaliados e priorizados. Apoiar Decises Chaves: Os projetos de software esto sujeitos a restries tais como: custo, prazo e qualidade, que devem ser negociadas entre si e gerenciadas juntas para atingir os objetivos do projeto. As medies apiam as decises relativas gesto. Os gerentes de projeto devem ser capazes de defender a base de suas estimativas e planos

43

com dados de desempenho histricos. Eles devem ser capazes de justificar as mudanas de planos com dados de desempenho atuais. Deve-se observar que as mtricas no devem ser analisadas isoladamente, dado que podem existir correlaes entre elas; por exemplo, se a volatilidade do sistema alta, o nmero 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 organizao deve manter uma linha de base (baseline) com as medies obtidas em seus projetos, comparando ento o valor obtido numa determinada avaliao com outros anteriormente registrados na base. Se a organizao em questo dispe de uma boa linha de base (baseline), pode aplicar tcnicas estatsticas e identificar se o valor encontrado est fora do esperado, considerando uma distribuio de freqncias que seja adequada mtrica ou indicador em questo (FENTON, 1997). No intuito de definir mtricas consistentes recomendado o uso de um framework para a definio sistemtica de mtricas para um determinado propsito. Lott (1996) descreve sete frameworks goal-oriented, dentre eles est o Goal Question Metrics (GQM). O GQM se tornou uma ferramenta largamente utilizada em todo mundo (BASILI, 1999; FUTRELL, 2001; HARRISON, 1999). Tambm existem extenses do mtodo GQM disponveis na literatura (OFFEN e JEFFERY, 1997). 2.7.4. Modelos para Gerao de Indicadores A fim de possibilitar a criao de indicadores, foram feitas pesquisas com o intuito de mapear os principais processos e metodologias presentes na literatura acadmica. Esta seo 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 mtricas. Uma mtrica confivel prov uma evidncia para o aprimoramento, possibilitando uma melhor anlise de custo/benefcio e promovendo uma base para a tomada de decises.

44

A abordagem GQM representa um mtodo para especificao de programas de medio de software permitindo que as medies selecionadas sejam utilizadas para acompanhamento do sucesso no alcance dos objetivos traados para o programa (GOETHERT; FISCHER, 2003). O GQM pode ser utilizado em qualquer fase do desenvolvimento de software. Esta tcnica foi aplicada no processo de software da NASA e obteve resultados extremamente satisfatrios (NICK, ALTHOFF e TAUTZ, 1999). O paradigma do GQM consiste em 3 passos: 1. Levantar um conjunto de objetivos baseados nas necessidades de uma organizao 2. Derivar um conjunto de questes 3. Desenvolver um conjunto de mtricas que promovem a informao necessria para responder as questes e aferir o atendimento dos objetivos. A Figura 5 a seguir demonstra um exemplo da aplicao do GQM para criar indicadores que possibilitam avaliar o atendimento de um Help Desk.

Exemplo

Metas (Goals)

M1: Avaliar o atendimento do Help Desk

Questes (Perguntas)

Q1: Qual a qualidade da abertura dos chamados? Q2: Qual a qualidade das resolues de primeiro nvel?

Indicadores e Mtricas (Metrics)

I1: Tempo mdio de abertura dos chamados I2: Quantidade de chamados abertos por dia I3: Quantidade de chamados resolvidos no primeiro nvel.

Figura 5 - Exemplo de Aplicao do GQM

45

2.7.5.1.

Levantar um conjunto de objetivos baseados na necessidade de uma organizao

Esse o primeiro estgio do GQM. Nele a organizao define objetivos no intuito de atingir a qualidade desejada. A equipe de desenvolvimento ou a gerncia pode definir um conjunto de objetivos para o aprimoramento de uma atividade de acordo com a estratgia organizacional. Objetivos so 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, mudanas, mtricas do produto, confiabilidade, de um determinado ponto de vista: desenvolvedor, gerncia, cliente, corporao. Ambiente: O ambiente est diretamente relacionado a fatores relacionados a processos, pessoas, problemas, mtodos, ferramentas, etc. Objetivos so como um alicerce na elaborao de planejamento para o desenvolvimento. Alguns exemplos de possveis objetivos relacionados gerncia de requisitos so: Aprimoramento das estimativas de software Minimizar retrabalho nos projetos Reduo de custos das atividades de requisitos Aprimoramento da qualidade dos artefatos de requisitos Aumento da produtividade das atividades de requisitos Identificao das perguntas

2.7.5.2.

As perguntas tm o intuito de prover o entendimento a respeito do alcance dos objetivos estabelecidos pela organizao. As perguntas informam organizao o que deve ser atingindo no intuito de desenvolver um produto de qualidade. Atravs das perguntas no se perde o foco dos objetivos estabelecidos previamente. As perguntas so como um guia para que no se gere dvida a respeito das aes que devem ser tomadas.

46

2.7.5.3.

Desenvolver um conjunto de mtricas que promovem a informao necessria para

responder as questes neste passo que as mticas so 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 alcanar os objetivos. A validao feita para aferir se os dados coletados esto atingindo os objetivos ou no. As mtricas derivam das perguntas elaboradas com intuito de atingir os objetivos estabelecidos. Como o GQM um framework genrico para elaborao de um programa de mtricas que visa aprimorar a anlise de projetos e a tomada de decises, algumas de suas limitaes so: Devido ao fato de ser genrico, para sua utilizao muitas vezes necessrio que organizaes possuam profissionais especializados que possam compreender sua estrutura e adapt-lo s necessidades da organizao, o que normalmente acarreta em tempo e custos; Devido ao fato de ser genrico, no apresenta foco ou direcionamento para resoluo de necessidades especficas de uma organizao. Sendo assim, na etapa de definio de objetivos, h margem para se definir objetivos inadequados, o que tambm acarretaria na definio de indicadores inapropriados, fazendo com que o processo caia em descrdito; Devido ao fato de ser genrico, no leva em considerao eventuais limitaes que uma organizao possa vir a ter, o que a impossibilitaria de cria determinados indicadores. O GQM no faz distino clara entre o que uma mtrica e um indicador, o que pode acarretar em dificuldades de interpretao durante a sua utilizao e acarretar na m estruturao dos indicadores; O GQM no apresenta um detalhamento de quais informaes devem fazer parte da estrutura de um indicador 2.7.6. Goal Question Indicator Metric - GQ(I)M Algumas extenses do GQM foram elaboradas com base na abordagem inicial de Basili e Weiss (1984). Entre as extenses temos a do SEI Software Engineering Institute da

47

Universidade de Carnegie Mellon dos Estados Unidos (PARK et al., 1996), focadas na definio de objetivos estratgicos e indicadores para visualizao das mtricas. A verso 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 tcnica para a definio de uma poltica de medio. O guia possui a seqncia de atividades recomendadas, produzindo ao final um conjunto de indicadores e mtricas adequadas s necessidades de uma organizao. Nesta tcnica os objetivos do programa de medio devem ser definidos de acordo com os objetivos da organizao. A partir dos objetivos traados, 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 viso geral do mtodo GQ(I)M. Primeiro identifica-se os objetivos do negcio em uma viso de alto nvel. Estes objetivos de negcio so obtidos da viso e misso, definidos pela alta direo.

Figura 6 - Goal Question Indicator Metric - GQ(I)M (ARAJO, 2004)

48

Em seguida, com os objetivos definidos, estes so refinados com o intuito de se validar e entender de que maneira estes objetivos podem ser medidos. O resultado deste refinamento uma lista de questes que esto associadas a cada um dos objetivos. Com as questes descritas, estas servem de base para a identificao de informaes para a composio dos indicadores e mtricas. Exemplo de questes para obteno de informaes podem ser: existem ferramentas necessrias para controlar a volatilidade dos requisitos?; qual o impacto da mudana de requisitos durante o desenvolvimento do projeto? Com as informaes obtidas atravs das questes, as mtricas e indicadores so detalhados em um plano de projeto. Detalhes como caractersticas do tipo de grfico a ser utilizado e tipo de pblico de visualizao do grfico so identificadas. A apresentao ou relatrio usado para comunicar os dados a chave para entender porque um dado especfico 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 concretizao das metas traadas. Segundo Goethert (2003), identificar questes e mtricas sem visualizar um indicador no suficiente para comear um programa bem sucedido de medio. Estes indicadores servem como uma especificao de requisitos para os dados que devem ser coletados, processados e analisados. O GQ(I)M apresenta uma pequena evoluo quando comparado ao GQM, pois ele faz uma distino entre o que um indicador e uma mtrica, apresentando mtrica como sendo as informaes que servem de insumo para a criao de um indicador, conforme apresentado na Figura 6. Porm, trata-se tambm de um processo genrico para definio de indicadores, acarretando nos demais problemas listados anteriormente para o GQM. 2.7.7. Practical Software Measurement - PSM O Modelo de Informao do Practical Software Measurement PSM (2008) tambm pode ser considerado uma evoluo do modelo GQM. O PSM fornece um apoio para a definio das necessidades de Informaes, o Goal do GQM (WIEGERS, 2001) e um guia para chegar-se na especificao da mtrica e indicadores.

49

O modelo PSM relaciona-se ao desenvolvimento de uma estrutura de informao de medio de projeto usando o Modelo de Informao de Medio, e descreve atividades e tarefas de medio usando o Modelo de Processo de Medio. Estes modelos fornecem a base para um programa de medio de software efetivo (MCGARRY, 2002; PSM, 2008). O PSM um processo para se analisar questes relacionadas a projetos de software, seus riscos e custos. Ele baseado na experincia obtida em projetos do departamento de defesa dos Estados Unidos, representando as melhores prticas da comunidade de engenharia de software. O processo completamente flexvel para se adaptar a uma necessidade especfica de uma organizao (DOD, 2008). 2.7.7.1. O Modelo de Processo de Medio

O Modelo de Processo de Medio do PSM fornece um framework para implementao de medio em um projeto. Ele construdo baseando-se no ciclo PDCA (Plan - Do - Check Act) de Deming (1982), adaptado para suportar atividades e tarefas especficas de medio. A Figura 7 apresenta o Modelo de Processo de Medio que inclui quatro atividades principais: planejar medio, executar medio, avaliar medio, estabelecer e sustentar compromisso.

Figura 7 - Practical Software Measurement (PSM)

50

O subprocesso Planejar Medio compreende a identificao das necessidades de informao do projeto e a seleo das medidas apropriadas para tratar estas necessidades utilizando o Modelo de Informao de Medio. Este subprocesso compreende 3 atividades: Identificar e priorizar necessidades de informao Selecionar e especificar mtricas Integrar mensurao aos processos do projeto O subprocesso Executar Medio engloba a coleta e o processamento dos dados de medio; o uso dos dados para analisar as necessidades de informao e questes associadas; e a gerao de produtos de informao para apresentar os resultados da anlise, aes alternativas, e recomendaes para os responsveis pelas decises. Este subprocesso tambm composto por 3 atividades: Coletar e processar dados Analisar dados Produzir recomendaes O subprocesso Avaliar Medio aplica tcnicas de medio e de anlise para medir o processo. As medidas aplicadas e a capacidade do processo de medio so avaliadas, ajudando a identificar as aes de melhoria associadas. As atividades que compe este subprocesso so: Avaliar medidas Avaliar o processo de mensurao Atualizar a base de experincias Identificar e implementar melhorias O processo Estabelecer e Sustentar Compromissos garante que sejam fornecidos os recursos e a infra-estrutura organizacional requeridos para implementar um programa de medio vivel. Os Processos Tcnicos e Gerenciais tambm esto representados no Modelo de Processo de Medio. Os responsveis pelas decises operam dentro destes processos, definindo necessidades de informao e usando produtos de informao de medio para apoiar suas decises.

51

2.7.7.2.

Estrutura de formao de Indicadores do PSM

A estruturao de um indicador descreve como os atributos relevantes de software so quantificados e convertidos para indicadores. A Figura 8 ilustra a estrutura de formao de um indicador (HAZAN, 2002). Os componentes chave so os seguintes: Atributo mensurvel uma propriedade distinguvel de uma entidade de software. Entidades incluem processos, produtos, projetos e recursos. Os atributos devem ser relevantes para atender s necessidades de informao do usurio. Medida Bsica uma medida de um nico atributo definido por um mtodo de medio especfico. Uma medio bsica funcionalmente independente de todas as outras medidas e captura informao sobre um nico atributo. Mtodo de Medio uma seqncia lgica de operaes, descrito genericamente, usado na quantificao de um atributo com respeito a uma escala especfica. Cada combinao nica de um atributo e um mtodo produz uma medida bsica diferente. Tipo de Mtodo depende da natureza das operaes usadas para quantificar um atributo especfico. Os mtodos podem ser subjetivos, os quais envolvem julgamento humano ou objetivos, os quais se baseiam em regras numricas tais como contagem. Estas regras podem ser implementadas manualmente ou automaticamente. Escala um conjunto de valores ordenado, contnuo ou discreto, ou um conjunto de categorias, nas quais um atributo mapeado. A escala define o conjunto de possveis valores que podem ser produzidos pela execuo de um mtodo de medio. Unidade de Medio uma quantidade especfica, definida e adotada por conveno, com a qual outras quantidades do mesmo tipo so comparadas para expressar sua magnitude relativa para aquela quantidade. Medida Derivada uma medida, ou quantidade, que definida como uma funo de duas ou mais medidas bsicas ou derivadas. Funo Medio um algoritmo ou clculo executado para combinar dois ou mais valores de medidas bsicas e/ou derivadas. Indicador uma medida que fornece uma estimativa ou avaliao de atributos derivados de um modelo de anlise com respeito a definio de necessidades de informao. Indicadores constituem a base para a tomada de decises.

52

Modelo de Anlise envolve duas ou mais medidas bsicas ou derivadas com um critrio de deciso associado. Os modelos de anlise produzem estimativas ou avaliaes relevantes para as necessidades de informao definidas.

Critrio de Deciso so limiares, metas e limites usados para determinar a necessidade para ao ou investigao adicional ou descrever o nvel de confiana em um resultado dado. O critrio de deciso ajuda a interpretar os resultados da medio.

Figura 8 - Estruturao de criao de um Indicador no PSM (HAZAN, 2002)

A Figura 9 a seguir apresenta um exemplo de uma construo de um indicador de produtividade. A produtividade est relacionada ao esforo gasto e ao tamanho do software. Assim, o esforo e o tamanho so as entidades de software mensurveis de interesse. Atributos especficos destas entidades devem ser selecionados para que seja possvel quantificar e uma funo de medio deve ser projetada para combin-los em uma medida derivada para cada projeto. A estimativa de produtividade baseada em dados histricos permite a computao de intervalos de confiana que ajudam a avaliar se os resultados atuais so similares aos valores estimados.

53

Figura 9 - Exemplo de estruturao de Indicador atravs do PSM (HAZAN, 2002)

Os principais benefcios de se utilizar a estrutura do PSM so: padronizao da nomenclatura de componentes utilizados para compor um indicador; reduo de redundncia, identificando um conjunto essencial de medidas bsicas; aumento da preciso e repetibilidade pela garantia de que todos os aspectos essenciais da abordagem da medio esto adequadamente definidos; maximizao do valor das medies bsicas pela criao de padres para indicadores que podem ser facilmente reconhecidos, reusados, e adaptados; documentao do link entre a necessidade de informao 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 traado, conforme demonstrado na Figura 8 e Figura 9. Porm, tambm se trata de uma processo genrico para definio de indicadores, acarretando nos mesmos problemas listados anteriormente para o GQM e GQ(I)M. 2.7.8. Instrumentos de Anlise de Desempenho Diversos instrumentos de controle so utilizados para avaliar o desempenho dos processos de uma organizao ou de um projeto de software especfico. Estas ferramentas auxiliam na interpretao de indicadores, dando visibilidade para controle, anlise e identificao

54

de causas de problemas e, portanto, so fundamentais para a anlise de desempenho de projetos de software. Monteiro (2008) apresenta um consolidado das principais ferramentas utilizadas para a anlise quantitativa de desempenho, dentre as quais se destacam as listadas no Quadro 2 abaixo.
Quadro 2 Ferramentas para Gesto Quantitativa (adaptao de MONTEIRO, 2008) Ferramenta Descrio Este diagrama apresenta relacionamentos entre duas variveis ou caractersticas de um processo. A observao de padres nos pontos do digrama sugere que as variveis analisadas so associadas, possivelmente em uma relao de causa-e-efeito. Apresentao
Quantidade de defeitos X Tamanho
Quantidade de defeitos

100,00
80,00 60,00

Diagrama de disperso

40,00 20,00
-

50,00

100,00 Tamanho

150,00

Histograma

Um histograma exibe os dados coletados do processo por freqncia. Os valores observados do processo so distribudos em determinados intervalos de mesmo tamanho (colunas). A altura das barras de um histograma proporcional ao nmero de observaes dentro do intervalo. Os histogramas so teis, pois permitem analisar a taxa de variao de um processo. Da mesma forma que um histograma, um grfico de barras utilizado para investigar o perfil de um processo. Porm, os grficos de barras podem conter quaisquer valores, no somente freqncias 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 grfico. Um Diagrama de Pareto simplesmente a exibio de freqncias de determinado dado em ordem decrescente. Esta ferramenta utilizada para analisar as ocorrncias mais comuns de um evento e priorizar as aes a serem tomadas no tratamento do processo. Diagramas de Pareto so conceitualmente relacionados com a Lei de Pareto, que defende que um nmero relativamente pequeno de causas responsvel pela produo da grande maioria dos problemas ou defeitos. Um grfico ou carta de execuo exibe observaes individuais de um processo no decorrer do tempo. Esta ferramenta pode ser utilizada para identificar tendncias ou mudanas no desempenho do processo. Um risco de utilizar simplesmente grficos de execuo a tendncia de reagir s variaes naturais do processo. Um grfico de controle basicamente um grfico de execuo com o acrscimo de uma linha central e limites de controle inferior e superior associados. Os limites de controle, definidos de acordo com cada tipo de grfico, permitem a organizao acompanhar o desempenho do processo e identificar as causas normais e especiais de variao.

Histograma
6 5 4 3 2 1 0 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

Defeitos x Disciplinas x Builds

35,00 Build 1 30,00
25,00

Build 2 Build 3
Build 4

20,00 15,00
10,00

Grfico de barras

5,00 -

Densidade de defeitos (Pareto)

Densidade de defeitos

Grfico ou diagrama de Pareto

0,350 0,300 0,250 0,200 0,150 0,100 0,050 -

0,325

0,055 0,046

0,014 0,010 0,009 0,003

100,00% 80,00% 60,00% 40,00% 20,00% 0,00%

IDC
0,600
0,500 0,400 0,300 0,200 0,100 0,000 nov/05 dez/05 jan/06 fev/06 mar/06 abr/06 mai/06 jun/06 jul/06 ago/06 set/06

Grfico ou carta de execuo

IDC (X)
0,700 0,600 0,500 0,400 0,300 0,200 0,100 0,000
nov/05 dez/05 jan/06 fev/06 mar/06 abr/06 mai/06 jun/06 jul/06 ago/06 set/06

Grfico ou carta de controle

IDC (X)
+ 1 sigma

LC
LCI (- 3 sigmas)

LCS (+3 sigmas)

- 2 sigmas

+ 2 sigmas
- 1 sigma

55

2.8. Desafios na Definio de Indicadores em Projetos de Desenvolvimento de Software Quando da elaborao de indicadores, a maioria das organizaes acabam enfrentando quase sempre os mesmos problemas (JONES, 1992): Falta de viso do todo. Grficos que so coloridos, mas com pouco ou nenhum significado. Indicadores que geram interpretao dbia. Inconsistncia na definio de medidas e elementos de dados. Indicadores fora de um contexto previamente definido. Utilizao de dados inconsistentes. Falta de uma linha de base ou benchmark que possibilite a comparao de desempenho. Falta de freqncia ou ineficincia das atividades de coleta e integrao de dados. Comparao ou previso de resultados sem a garantia de um processo estvel. Coleta-se muitos dados, resultando em desperdcio de esforo e reduo da moral da equipe. Obtm-se medidas erradas, ambguas ou inconsistentes, resultando em anlise de dados sem concluses ou interpretaes invlidas. Isto torna a mensurao intil e muitas vezes prejudicial. As conseqncias desses problemas podem ser cruciais em um processo de medies. Por exemplo, grficos que aparentemente so bonitos e coloridos podem estar representando informaes equivocadas e inconsistentes. Isso pode gerar conseqncias desastrosas no processo de tomada de decises em um projeto, apresentando uma perspectiva que no reflete a real situao do contexto em anlise. Com o objetivo de definir um conjunto consistente de indicadores, o SEI (2004) apresenta um guia e um conjunto de questes que a organizao deve seguir: Quais os objetivos a serem alcanados? Qual o propsito de um determinado indicador?

56

O que voc quer saber quando receber a informao? Quem o responsvel? Quem o dono do indicador? Quem o responsvel por medir a informao? Quem o usurio do indicador? Como se coleta a informao? O quanto consistentes so os dados? O indicador est claramente definido? Como o indicador calculado? Com qual freqncia o indicador deve ser reportado? At quando o usurio deve receber a informao do indicador? Questes como essas so respondidas atravs da estrutura do template de indicadores sugerido pelo SEI (2004). A utilizao de templates serve como um guia que visa enderear os detalhes da infra-estrutura de medio de uma organizao com o objetivo de estruturar um programa consistente de medies e anlises (Baumert e McWhinney, 1992). Assim possvel obter os seguintes resultados: Maior visibilidade do projeto. Capacidade de melhor quantificar e qualificar decises a serem tomadas. Melhor planejamento, controle e monitoramento de projetos. Melhor entendimento tanto do processo de desenvolvimento de software quanto ambiente de desenvolvimento. Identificao de reas onde necessrio aprimoramento. Aprimoramento da comunicao. 2.9. Estrutura de Template (modelo de documento) para Gerao de Indicadores Organizaes normalmente no atingem por completo os benefcios de um programa de medies devido a inconsistncias no processo de construo de um programa de indicadores. O SEI (2004) elaborou um template que visa auxiliar na elaborao de indicadores. Esse template

57

objetiva auxiliar organizaes a definir indicadores consistentes e coesos, representando quem, o qu, onde, quando, porque e como analisar e coletar medies. O SEI (2004) identificou que a utilizao de templates para gerao de indicadores pode ajudar organizaes a melhorar os processos de medies no desenvolvimento de software. Os indicadores acabam servindo como um aliado ttico no processo de tomada de decies. As informaes 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 explanao a respeito dos objetivos de cada campo encontrado no template: Objetivo do indicador: a proposta de se ter o indicador Questes: as questes/perguntas que o responsvel pelo indicador est tentando responder Grfico: um display grfico do indicador Entradas: a lista de medidas requeridas para construir o indicador e suas definies Algoritmo: a definio de um algoritmo utilizado na construo do indicador Premissas: lista de premissas a respeito da organizao, seus processos e modelos que sejam relevantes para a coleta e utilizao do indicador

59

Coleta de dados: Informaes a respeito de como, quando, qual freqncia, por quem os elementos de dados requeridos para a construo do indicador so coletados. Divulgao das informaes: Informaes a respeito de quem responsvel por reportar as informaes, para quem e com qual freqncia. Armazenamento: Informaes a respeito do armazenamento, recuperao e segurana dos dados. Anlise e Interpretao dos resultados: Informaes a respeito de como analisar e interpretar o indicador. A estrutura sugerida no Quatro 3 permite que organizaes possam adaptar o template s suas necessidades, adicionando, modificando e excluindo campos no intuito de aprimorar a definio de seus indicadores. O template apenas um ponto de partida sugerido pelo SEI (2004). Conceitos propostos pelo template do SEI sero utilizados e adaptados no processo sugerido neste trabalho. 2.10. Indicadores para o Gerenciamento de Requisitos A literatura apresenta alguns autores que exploraram a definio de indicadores para a Gerncia de requisitos (GOODMAN, 1993; HAZAN, 2003; LOCONSOLE, 2002; 2003; 2004; 2007, MONTEIRO, 2008). Porm, os estudos mais aprofundados foram apresentados por Hazan (2003) e Loconsole (2002, 2003, 2004 e 2007). Hazan (2003) prope a criao de indicadores para a gerncia de requisitos utilizando os mtodos 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 projeo antecipada das mudanas de requisitos, devido ao fato da indstria ter evidenciado que a instabilidade dos requisitos contribui fortemente para os riscos de presso excessiva do cronograma e de no aceitao do produto final. No que tange elaborao de indicadores de rastreabilidade, a autora se baseia no fato de que a rastreabilidade ajuda na identificao do tamanho da mudana solicitada, apontado todos os artefatos impactados. Quando mudanas nos requisitos emergirem, uma anlise de impactos deve ser executada, visando verificar a viabilidade de implementao, bem como o esforo, custo e cronograma associados.

60

J Loconsole (2002, 2003, 2004, 2007) foca seus trabalhos na definio e validao de indicadores para a gerncia 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 tendncias de mudanas em requisitos, permitindo assim uma maior previsibilidade e controle dos projetos de desenvolvimento de software. Loconsole, assim como Hazan, tambm utiliza o GQM como instrumento de gerao dos indicadores. A Figura 10 abaixo apresenta um exemplo de grfico de controle de volatilidade (adio, modificao e deleo) dos requisitos no decorrer dos meses, o que permite identificar tendncias ao logo do tempo.

Figura 10 Exemplo de grfico de controle de volatilidade dos requisitos (LOCONSOLE, 2007)

As duas autoras citadas acima, apesar de terem explorado aspectos relacionados gerao de mtricas e indicadores para a gerncia de requisitos utilizando os mtodos GQM (BASILI, CALDIERA e ROMBACH, 1992, 1994; SOLINGEN e BERGHOUT, 1999) e PSM (2008), no apresentam grandes detalhes a respeito de como chegaram aos indicadores gerados, tendo como foco principal em seus trabalhos a validao e aplicabilidade dos indicadores propostos. Tambm nota-se certa carncia nos trabalhos quanto a descrio do contexto organizacional em que as mtricas e indicadores foram criados, o que torna difcil replicar os indicadores propostos dentro de outro contexto organizacional, pois organizaes distintas apresentam diferentes realidades e necessidades.

61

2.11. Consideraes Finais do Captulo A partir dos conceitos expostos neste referencial terico possvel perceber a importncia da gerncia de requisitos para o sucesso de projetos de desenvolvimento de software, assim como a importncia de controles efetivos para projetos. A complexidade da gesto de requisitos, dentro de projetos de software, requer que tcnicas de gesto quantitativa sejam aplicadas de forma a perceber objetivamente a situao do projeto, possibilitando maior controle e previsibilidade para os tomadores de decises. Apesar de existirem modelos que auxiliem na definio de indicadores como o GQM, GQ(i)M e PSM; todos eles so de certa forma genricos. Por serem genricos, muitas vezes acabam exigindo profissionais com qualificao especfica para este tipo de trabalho, visando adapt-los s necessidades de cada organizao, o que acarreta maior investimento em tempo e custos para uma correta compreenso e adaptao dos modelos. Um outro aspecto a ser ressaltado que devido ao fato das definies de objetivos, perguntas e indicadores (padro em todos os modelos) ficarem totalmente a critrio das organizaes, acaba-se gerando maior margem para erros, seja por inexperincia dos profissionais envolvidos, falta de clareza do processo ou dos objetivos da organizao. Para que organizaes possam criar indicadores consistentes, com maior facilidade e agilidade, preciso um processo em que a gerao de indicadores tenha como foco a gesto de requisitos, trilhando assim um caminho que minimize as chances de erros na execuo do processo, apresentando clareza e facilidade para sua compreenso e utilizao. Um processo que apresente um conjunto de passos bem definidos e informaes pr-definidas para que diferentes organizaes de TI possam utiliz-lo de acordo com suas caractersticas e necessidades. O prximo captulo mescla e complementa alguns dos conceitos apresentados neste captulo, buscando a definio de um processo especfico para a gerao de indicadores para uma correta gesto de requisitos.

62

3. MATERIAIS E MTODOS DE PESQUISA

Neste captulo apresentada a abordagem metodolgica utilizada neste trabalho. A suposio orientadora que por meio de um processo detalhado para definio de indicadores seria possvel resolver o problema. Tal processo foi proposto e avaliado. Este captulo apresenta todas as etapas de pesquisa, descrevendo em especial as principais etapas de construo do processo proposto. 3.1. Classificao 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 criao de indicadores para a gerncia de requisitos para projetos de desenvolvimento de software. Portanto, a pesquisa caracteriza-se como aplicada quanto sua natureza, j que pretende gerar conhecimentos para aplicaes prticas, dirigidas soluo de um problema especfico. Quanto abordagem utilizada, a pesquisa caracteriza-se como qualitativa, pois buscar apresentar uma avaliao do processo proposto. A pesquisa prope instrumentos, caminhos e procedimentos para a gesto quantitativa de projetos de software, tratando-se, portanto, de um instrumento de captao e manipulao da realidade, configurando-se como pesquisa metodolgica quanto aos fins. Quanto aos meios de investigao, foi realizada uma busca em material cientfico publicado em livros, revistas e jornais, o que caracteriza a pesquisa como bibliogrfica. A partir do referencial terico e da proposta de processo, foi realizada uma avaliao em campo do processo proposto. 3.2. Fontes de Informaes Utilizadas A pesquisa inicial para este trabalho foi realizada nas seguintes fontes de referncia, todas de reconhecida credibilidade e completeza:

63

ISI Web of Knowledge portal internacional contendo publicaes de peridicos. acessada atravs do endereo http://apps.isiknowledge.com; Computer Society Digital Library (CSDL) produzida pela IEEE-Computer Society, indexa todos os peridicos da CS, alm da base de peridicos da ACM. Acessada atravs do endereo http://www2.computer.org/csdl; Scirus que indexa a base da Science Direct, acessada atravs do endereo http://www.scirus.com. A busca nessas fontes utilizou como parmetro diversas combinaes de expresseschave (em ingls). A Tabela 2 apresenta os resultados dessa pesquisa inicial, indicando a quantidade de entradas identificadas em cada fonte para as expresses e suas combinaes com E lgico.
Tabela 2 - Fontes de Pesquisas

Expresses-chave
Software Project Requirement Management Indicadores Metrics Requirement Management Software Project Indicator Metrics Indicator Software Project Requirement Management Measurement Metrics

Fontes

ISI
13.422 14.850 >100.000 >100.000 55 11 34 2 11 5

CSDL
>100 >100 >100 >100 >100 58 36 3 2 2

Scirus
317.005 5.738 4.235 1.139 65 9 14 0 14 6

O resultado da pesquisa inicial mostrou que existe grande nmero de publicaes tratando de temas isolados como projetos de software, gerncia de requisitos, mtricas para projetos de software e indicadores. Entretanto, quando esses temas se associam a quantidade de publicaes se reduz consideravelmente, sendo bastante pequena quando se trata de projetos de software associados a indicadores e gerenciamento de requisitos.

64

A segunda fase da pesquisa se baseou numa rpida avaliao dos ttulos e resumos dos trabalhos mais relevantes e prximos do tema pesquisado, tendo sido selecionados originalmente 45 textos para leitura mais detalhada. A leitura desses textos apontou referncias a outros que foram agregados pesquisa. Dessa fase resultou um total de 51 textos artigos ou livros dos quais foram selecionados aqueles que compem as referncias bibliogrficas deste trabalho. A utilizao das fontes bibliogrficas listadas na tabela acima est detalhada nas sees subseqentes da etapa de reviso da literatura deste trabalho. 3.3. Etapas de Definio do Processo Proposto O processo proposto foi batizado de Processo de Gerao de Indicadores para a Gesto de Requisitos PGIGR. Os passos descritos neste captulo ilustram desde a motivao em se gerar o PGIGR at a descrio dos passos envolvidos para a definio 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 sees subsequentes.

65

Etapas para Definio do PGIGR

Reviso da Literatura Definio do Processo

Incio

1. Reviso da Literatura referente a sucesso e fracasso em projetos de software

2. Estudo da Teoria de Base sobre Gesto de Requisitos

6. Definio das caractersticas desejadas para o processo 3. Estudo da Teoria de Base sobre Medio em Projetos de Software

7. Definio da estrutura geral do processo 4. Estudo da Teoria de Base sobre mtodos para definio de indicadores

8. Definio das atividades do processo 5. Estudo da Teoria de Base sobre mtricas e Indicadores existentes para a gerncia de Requisitos Fim

Figura 11 Processo de definio do PGIGR

As setas slidas apresentadas na figura acima demonstram a sequncia lgica da pesquisa. As setas pontilhadas apresentam o trabalho iterativo, incremental e de refinamento que se deu durante a definio do processo. O desenvolvimento do PGIGR envolveu duas grandes etapas: a reviso da literatura e a definio do processo PGIGR em si. A anlise da literatura composta por cinco passos, desde a anlise de problemas relacionados a projetos de desenvolvimento de software at a anlise de mtricas e indicadores existentes para a gerncia de requisitos.

66

O primeiro passo foi realizar uma ampla reviso da literatura para identificar as principais causas de fracasso em projetos de desenvolvimento de software. A partir da literatura pesquisada e apresentada na seo de reviso bibliogrfica deste trabalho, a gerncia de requisitos foi selecionada como foco da pesquisa. A razo da gerncia 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 tambm que das 10 principais causas de fracasso em projetos de desenvolvimento de software, as trs primeiras esto relacionadas gesto de requisitos (CHAOS REPORT, 2007; EASTERBROOK, 2004). A partir da seleo da gesto de requisitos como foco para a gerao de indicadores, o segundo passo da pesquisa foi estudar as principais caractersticas e problemas enfrentados na gesto de requisitos em projetos de desenvolvimento de software. Uma vez analisadas as principais caractersticas e problemas da gesto de requisitos, o terceiro passo ficou responsvel por analisar o contexto atual da utilizao de medies e indicadores em projetos de desenvolvimento de software, assim como apresentar as principais necessidades e benefcios em se utilizar ferramentas de controle quantitativo para o aprimoramento do controle e tomada de decises. Concluda a anlise da situao dos projetos de desenvolvimento de software quanto ao uso de mtodos de controle quantitativos, o quarto passo encarregou-se de avaliar os principais mtodos e processos existentes na literatura para a gerao de indicadores, visando uma adaptao para as organizaes de TI e mais especificamente para a gerncia de requisitos de projetos de desenvolvimento de software. Uma vez analisados os mtodos e processos existentes para a gerao de mtricas e indicadores, no quinto passo foram pesquisados trabalhos acadmicos que apresentam indicadores e mtricas para aprimorar a gesto de requisitos. A segunda etapa da pesquisa, a etapa de definio do processo PGIGR, envolveu trs passos, desde a definio de caractersticas desejadas para o processo PGIGR at o detalhamento das atividades do processo. O sexto passo da pesquisa se encarregou de definir um conjunto de caractersticas que o PGIGR deveria possuir para que fosse possvel gerar indicadores para a gerncia de requisitos de forma objetiva, eficiente e eficaz. A partir das caractersticas definidas no passo anterior, o stimo passo ficou encarregado de elaborar uma estrutura macro do PGIGR, onde foram definidos cinco subprocessos para uma correta gesto de indicadores para a gerncia 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 sees seguintes ser apresentado detalhadamente cada um dos passos supracitados. 3.4. Etapa de Reviso da Literatura Conforme apresentado na Figura 11 anteriormente, a etapa de reviso da literatura deste trabalho foi subdividida em cinco passos. Todos eles esto detalhados abaixo. 3.4.1. Passo: Reviso da Literatura Referente a Sucesso e Fracasso em Projetos de Software O incio do trabalho de pesquisa teve o enfoque de avaliar a situao atual do mercado no que tange os projetos de desenvolvimento de software. Com esse foco foi feito um estudo bibliogrfico a respeito de definies de projeto e a importncia de gerenciar seus riscos. A definio de projeto adotado por esta pesquisa derivada do PMI (2004), no qual projeto definido como um esforo temporrio empreendido para criar um produto, servio ou resultado
exclusivo.

Tambm foram pesquisadas bibliografias que definem o conceito de sucesso e optou-se por adotar o conceito apresentado pelo PMBOK (PMI, 2004), onde projetos so considerados bem sucedidos quando so finalizados dentro do prazo, custos, qualidade e escopo previstos. Posteriormente foi feito um diagnstico do nvel de sucesso em projetos de TI em mbito mundial. Para isso foi utilizado como base o Relatrio do Chaos do Standish Group (2007). Nesse estudo, que tem abrangncia e reconhecimento mundial, os dados mostram que os ndices de insucesso e dificuldades enfrentados em projetos de software so altssimos, demonstrando que 66% dos projetos fracassam ou no atingem os seus objetivos por completo. Nesse mesmo estudo foram mapeadas as dez principais causas de fracasso em projetos de software, estando as trs primeiras diretamente relacionadas gesto de requisitos, quais sejam: falta de envolvimento dos usurios, requisitos incompletos e constante alterao nos requisitos. Baseando-se no princpio 80:20 de Pareto, que afirma que para muitos fenmenos, 80% das consequncias advm de 20% das causas e sabendo que a gerncia 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 gesto 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 bibliogrfico sobre a qualidade de software com o enfoque em gerncia 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 Gesto de Requisitos Com o enfoque dado na gesto de requisitos, foi feito uma anlise da literatura buscando melhor entender as atividades e problemas envolvidos na gesto 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 identificao, controle e acompanhamento dos requisitos e suas mudanas durante toda a durao do projeto. A importncia da gerncia 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 nveis mais fundamentais. No CMMI (2001) encontra-se no nvel 2 de maturidade e no MPS.BR (SOFTEX, 2007) no nvel G. Para cada um desses processos foram mapeadas as atividades relacionadas gerncia de requisitos. Aps o levantamento das atividades envolvidas na gerncia de requisitos, foi feito um estudo para identificar os principais problemas e riscos relacionados gesto de requisitos. O intuito foi identificar os principais problemas para que a gerao de indicadores tivesse um melhor direcionamento e foco. 3.4.3. Passo: Estudo da Teoria de Base sobre Medio em Projetos de Software Tendo em vista que organizaes esto cada vez mais preocupadas em aprimorar seus controles e melhor aferir os resultados de seus projetos de desenvolvimento de software, a utilizao de dados quantitativos vem sendo cada vez mais adotada. Neste passo da pesquisa foram analisados trabalhos de conceituao de medio. A utilizao de dados objetivos para apoiar as decises em todos os nveis visa apoiar o gerenciamento e o processo de tomada de deciso atravs de indicadores, que tem como propsito ser uma ferramenta de controle e monitoramento.

69

Foi constado que um dos aspectos importantes sobre medies e indicadores que eles trazem um senso comum para um determinado assunto. A utilizao de medies faz com que seja possvel avaliar o processo de desenvolvimento de software, possibilitando identificar aspectos que esto fora dos resultados esperados, proporcionando a possibilidade de ajustes. Dentro do contexto de medio encontrado o conceito de indicador. Existem algumas definies 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 combinao de medidas, normalmente apresentado na forma grfica, que prov entendimento a respeito de uma questo ou conceito de software. Os indicadores so a base para a anlise e tomada de deciso, portanto so eles que devem ser apresentados aos tomadores de deciso. Uma vez analisados e contextualizados os conceitos de medio e indicador que iro ser utilizados neste trabalho, foram feitos estudos a respeito dos objetivos em se utilizar medies 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 vrias razes e motivos para se medir o processo de desenvolvimento de software. Pode-se resumir que medies em projetos de desenvolvimento de software permitem um melhor entendimento do ambiente de desenvolvimento e promovem informaes detalhadas sobre o projeto. Mtricas so utilizadas no intuito de melhor prever, gerenciar e controlar projetos de desenvolvimento de software. 3.4.4. Passo: Estudo da Teoria de Base sobre Mtodos para Definio de Indicadores Uma vez contextualizada a necessidade e importncia da utilizao de mtricas e indicadores em projetos de desenvolvimento de software, este passo da pesquisa encarregou-se de analisar os principais modelos de gerao de mtricas e indicadores existentes na literatura. Nele foram identificados e detalhados os trs principais modelos existentes atualmente na literatura: GQM, GQ(i)M e PSM. Como no PGIGR foram utilizados (mesclados) conceitos dos trs mtodos, todos os trs mtodos foram detalhados no referencial terico deste trabalho, visando apresentar suas caractersticas.

70

3.4.5.

Passo: Estudo da Teoria de Base sobre Mtricas e Indicadores Existentes para a Gerncia de Requisitos Neste passo da pesquisa foram analisados trabalhos acadmicos que abordam aspectos

relacionados gerao de medies e indicadores especificamente para a gerncia de requisitos. Duas autoras abordam o assunto com maior veemncia e foco: Hazan e Loconsole. Hazan (2002, 2003) prope a criao de indicadores para a gerncia de requisitos utilizando os mtodos GQM e PSM. A autora apresenta indicadores relacionados estabilidade e rastreabilidade dos requisitos, baseando-se em rastreabilidade entre os requisitos e a aplicao de mtrica de tamanho de software pontos de funo. 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 tendncias de mudanas em requisitos, permitindo assim uma maior previsibilidade de mudanas nos projetos. As duas autoras citadas, apesar de terem explorado aspectos relacionados gerao de mtricas e indicadores para a gerncia de requisitos utilizando os mtodos GQM (BASILI, CALDIERA e ROMBACH, 2002) e PSM (2008), no entram em detalhes a respeito de como chegaram aos indicadores gerados, tendo como foco principal em seus trabalhos a validao e aplicabilidade dos indicadores propostos. Tambm nota-se certa carncia nos trabalhos no que tange a descrio do contexto organizacional em que as mtricas e os indicadores foram criados e aplicados. Isso acaba tornando difcil replicar os indicadores propostos dentro de outro contexto organizacional, pois organizaes distintas apresentam diferentes realidades e necessidades. 3.5. Etapa de Definio do Processo PGIGR Aps concluso da etapa de reviso da literatura, iniciou-se a etapa de definio do processo PGIGR. Conforme apresentado na Figura 11, esta etapa da pesquisa foi subdividida em trs passos, detalhados abaixo.

71

3.5.1.

Passo: Definio das Caractersticas Desejadas para o Processo Aps anlise dos principais problemas e limitaes quanto a criao e utilizao de

mtodos de medio e indicadores em projetos de desenvolvimento de software, este passo da pesquisa utilizou o mtodo GQM para demonstrar uma sntese dos objetivos do PGIGR, conforme pode ser observado na Tabela 14 do APNDICE A. luz dos objetivos macro traados, foi definido um conjunto de caractersticas desejadas para o PGIGR, conforme quadro a seguir.
Quadro 4 - Caractersticas

Definidas para o Processo PGIGR

Caractersticas Definidas para o Processo PGIGR

1. 2. 3. 4. O processo deve ser de fcil compreenso (CRC01) O processo deve ser de fcil utilizao (CRC02) O processo deve agilizar a criao de indicadores para a gerncia de requisitos. (CRC03) O processo deve apresentar caractersticas mnimas necessrias para a gerao de indicadores consistentes para a gerncia de requisitos. (CRC04) 5. O processo deve permitir que organizaes criem indicadores para a gerncia de requisitos com o foco em suas necessidades. (CRC05) 6. O processo deve apresentar um conjunto prvio das principais necessidades da gerncia de requisitos. (CRC06) 7. O processo deve apresentar uma forma de rastrear um objetivo at os indicadores, facilitando assim a visibilidade e anlise de aferio de resultados. (CRC07) 8. O processo deve apresentar sugestes de indicadores especficos para a gerncia de requisitos, visando facilitar a compreenso de seus usurios. (CRC08) 9. O processo deve apresentar um template que possa ser utilizado para facilitar a criao de um indicador, apresentando todas as informaes necessrias. (CRC09) 10. O processo deve ser simples o suficiente ao ponto de no requerer que sua utilizao necessite de um especialista em mtricas (CRC10) 11. O processo deve proporcionar uma evoluo incremental no que tange a utilizao de indicadores para a gerncia de requisitos (CRC11)

A partir das caractersticas traadas acima, deu-se prosseguimento na definio estrutural do processo PGIGR.

72

3.5.2.

Passo: Definio da Estrutura Geral do Processo PGIGR Neste passo foram definidos cinco subsuprocessos para compor o PGIGR. Os cinco

subprocessos definidos visam direcionar a gerao de indicadores para a gerncia de requisitos. 1. 2. 3. 4. 5. Categorizar o Processo de Software da organizao de TI Definir Dimenso Foco Definir Objetivos (Metas) Definir Perguntas Definir Indicadores

A interao e sequncia entre cada um dos subprocessos pode ser melhor visualizada na Figura 12 abaixo.

Figura 12 Subprocessos do PGIGR

O propsito de cada um dos subprocessos definidos para o PGIGR foi baseado na consolidao de conceitos consolidados a partir do GQM, GQ(i)M e PSM, detalhados durante a fase de reviso bibliogrfica deste trabalho. O intuito dos subprocessos guiar o processo de criao de indicadores de forma a facilitar a visibilidade do sequenciamento e relacionamento dos subprocessos. As setas slidas demonstram a sequncia e interao entre os subprocessos. O detalhamento de cada um dos subprocessos pode ser visto no APNDICE A. Para atendimento de cada subprocesso do PGIGR, foram definidos conjuntos de atividades. Nas atividades esto todos os detalhes para a sua execuo. 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 Categorizar o processo de software da Organizao de TI Definir os Envolvidos Definir Categoria Definir a Dimenso Foco para a gerao de Definir Foco dos Indicadores indicadores. Selecionar objetivos pr-definidos para Gesto Definir Objetivos (Metas) de Requisitos. Criar Objetivo(s) Selecionar perguntas pr-definidas Definir Perguntas (Questes) Criar Pergunta(s) Selecionar Indicadores pr-definidos Descrever o Indicador Definir Indicadores Estruturar o Indicador Divulgar/aprimorar o Indicador Atividades

Neste passo tambm foram detalhados os principais papis utilizados para a correta utilizao do PGIGR. Essas atribuies foram baseadas no Rational Unified Process RUP (1998). A definio dos papis e suas atribuies podem ser visualizadas na Tabela 16 do APNDICE A. 3.5.3. Passo: Definio 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 APNDICE A. O detalhamento da criao dos subprocessos e suas respectivas atividades est descrito nas sees subsequentes.

74

3.5.3.1.

Subprocesso: Categorizar o Processo de Software da organizao de TI

Este subprocesso foi elaborado com o intuito de proporcionar uma categorizao do processo de desenvolvimento de software da organizao de TI avaliando algumas caractersticas que so fundamentais para que a criao de indicadores seja feita de forma correta. Para a elaborao deste subprocesso foram utilizados conceitos propostos por Solingen e Berghout (1999, p. 21), visando complementar o processo GQM. Segundo os autores, a medio em processos de software tem como objetivo prover informaes que podem ser aplicadas em trs 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 (caractersticas) do processo de software das organizaes de TI antes de definir os indicadores. O objetivo melhor direcionar a gerao de indicadores para a gesto de requisitos, de acordo com algumas caractersticas do processo de desenvolvimento de software da organizao de TI, pois, segundo Jones (1992), um dos grandes problemas na definio de indicadores falta de uma contextualizao da situao atual da organizao. Para isso, o PGIGR prope quatro categorias de classificao: Inicial, Entendimento, Controle e Aprimoramento, conforme pode ser visualizado na Figura 13.

75

Figura 13 - Categorias de Classificao do Processo de Software da Organizao de TI (Adaptada de Solingen e Berghout, 1999)

A estrutura proposta visa permitir um melhor entendimento do processo de desenvolvimento de software da organizao para ento direcionar a gerao de indicadores. Como exemplo, pode-se dizer que no adianta uma organizao querer definir indicadores para aprimorar o seu processo de gerncia de requisitos se ela no possui o mnimo de organizao e infra-estrutura necessrias para tal. Isso provavelmente acarretaria na gerao de informaes ambguas e inconsistentes. Ela tambm possibilita uma evoluo gradual da organizao quanto a utilizao de indicadores para uma correta gesto de requisitos. Esta etapa do processo visa evitar com que a organizao defina um conjunto de indicadores que esto alm 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 (APNDICE A) apresenta o detalhamento de cada uma das atividades.

76

Figura 14 - Subprocesso para Categorizar o Processo de Software da Organizao de TI

O conceito, empregado nesta pesquisa para de classificar o processo de desenvolvimento de software da organizao de TI, baseou-se em reas de processo do CMMI (2001) e do MPS.BR (SOFTEX, 2007). Para cada uma das categorias foram definidas caractersticas baseadas em prticas que so empregadas em ambos os processos supracitados e que se mostraram importantes para a gerao de indicadores para a gerncia de requisitos. As caractersticas definidas para cada categoria podem ser visualizadas a seguir na Matriz de Categorizao - Tabela 4.

77

Tabela 4 - Matriz de Categorizao do processo de software da Organizao de TI

CATEGORIZAR O PROCESSO DE SOFTWARE DA ORGANIZAO DE TI

1 - INICIAL
A organizao no possui os requisitos necessrios para se enquadrar na categoria Entendimento

2 - ENTENDIMENTO
A organizao possui prticas de gerncia de projetos de desenvolvimento de software; e A organizao possui ferramenta para controle de atividades dos projetos. (Ex.: Microsoft Project); e A organizao possui prticas de gerncia de requisitos; e A organizao utiliza prticas e ferramentas de controle de verso para os artefatos de requisitos; e A organizao possui prticas de medio de tamanho de software.

3 - CONTROLE
A organizao possui uma base histrica de mtricas e indicadores; e A organizao possui um processo padronizado de gerncia de requisitos; e A organizao possui um processo padronizado de gerncia de projetos

4 - APRIMORAMENTO
A organizao possui um baseline de desempenho do processo de requisitos;

Os indicadores gerados na categoria Entendimento tm o intuito de dar uma visibilidade e maior entendimento da situao atual dos projetos de desenvolvimento de software da organizao no que tange gesto de requisitos. Para que a organizao ingresse nessa categoria, foram coletadas algumas prticas das reas de processo do nvel 2 de maturidade (Gerenciado) do CMMI (2001) e do nvel G (Parcialmente Gerenciado) do MPS.BR, visando garantir a existncia de um mnimo de organizao para sustentar um processo consistente de gerao e manuteno de indicadores para gerenciar requisitos. As caractersticas definidas para a categoria Entendimento foram: 1. A organizao possui prticas de gerncia de projetos de desenvolvimento de software Esta caracterstica necessria para criar insumos para fonte de coleta de vrias medidas bsicas e derivadas que so utilizadas nos indicadores propostos. Visa-se constatar evidncias que demonstrem que a organizao possui prticas de gerncia de projetos no seu processo de desenvolvimento de software. Ela se baseia em prticas da rea de processo de Gerncia de Projetos contida no nvel 2

78

de maturidade do CMMI (2001) e do nvel G (Parcialmente Gerenciado) do MPS.BR (SOFTEX, 2007). 2. A organizao de TI possui ferramenta para controle de atividades dos projetos (Ex.: cronograma) Esta caracterstica objetiva constatar evidncias de utilizao de uma ferramenta de controle de atividades para gerenciar projetos de desenvolvimento de software. Esta caracterstica necessria porque a ferramenta de controle de atividades a fonte de coleta de vrias medidas bsicas e derivadas que so utilizadas nos indicadores propostos. Ela se baseia em prticas da rea de processo de Gerncia de Projetos contida no nvel 2 (Gerenciado) de maturidade do CMMI (2001) e do nvel G (Parcialmente Gerenciado) do MPS.BR (SOFTEX, 2007). Um dos resultados esperados pelo MPS.BR neste nvel o oramento e o cronograma do projeto, no qual marcos e/ou pontos de controle so estabelecidos e mantidos (GPR5). 3. A organizao possui prticas de gerncia de requisitos Esta caracterstica necessria por quanto preciso ter atividades de requisitos planejadas, pois elas serviro de insumo para coleta de medidas bsicas do processo de requisitos. Visa-se constatar evidncias da existncia de prticas de gerncia de requisitos nos projetos de desenvolvimento de software. Esta caracterstica est embasada em prticas da rea de processo de Gerncia de Requisitos, contida no nvel 2 (Gerenciado) de maturidade do CMMI (2001) e no nvel G (Parcialmente Gerenciado) do MPS.BR (SOFTEX, 2007). O propsito do processo Gerncia de Requisitos gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistncias entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. 4. A organizao utiliza prticas e ferramentas de controle de verso para os artefatos de requisitos Esta caracterstica necessria porque vrios indicadores utilizam o quantitativo de alteraes em artefatos de requisitos como medida derivada, o que tornaria praticamente invivel a coleta dessas informaes sem uma ferramenta adequada de controle de verses. Aqui visa-se constatar evidncias da utilizao de uma ferramenta e prticas de controle de verso nos projetos de desenvolvimento de

79

software. Esta caracterstica est embasada em prticas da rea de processo de Gerncia de Configurao contida no nvel 2 (Gerenciado) de maturidade do CMMI (2001) e no nvel F (Gerenciado) do MPS.BR (SOFTEX, 2007). O nvel F do MPS.BR tem como uma das reas de processo a Gerncia de Configurao. O propsito do processo de Gerncia de Configurao 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 organizao possui prticas de medio de tamanho de software Foi constatado que alguns indicadores ficam muito vagos e ineficientes caso no tenham como medida derivada um indicativo de tamanho do software. Visa-se constatar evidncias da utilizao de tcnicas de mensurao de tamanho do software nos projetos de desenvolvimento de software. Esta caracterstica est embasada em prtica da rea de processo de Medio contida no nvel 2 de maturidade (Gerenciado) do CMMI (2001) e no nvel F (Gerenciado) do MPS.BR (SOFTEX, 2007). O propsito do processo Medio coletar, analisar e relatar os dados relativos aos produtos desenvolvidos e aos processos implementados na organizao e em seus projetos, de forma a apoiar os objetivos organizacionais.

Caso a organizao no possua todas as caractersticas listadas acima para ingressar na categoria de Entendimento (segunda), o PGIGR sugere que a organizao ajuste o seu processo de desenvolvimento de software para atend-las, antes de ingressar na categoria, ficando, a princpio, na categoria Inicial (primeira), conforme representado na Figura 13 e Tabela 4 acima. Isso porque as caractersticas definidas como necessrias pelo PGIGR objetivam avaliar a existncia de um conjunto mnimo de organizao e padronizao para que haja fontes para uma correta coleta de medidas bsicas e derivadas, que so insumos fundamentais para que os indicadores propostos possam ser gerados de forma consistente. Vale ressaltar que o fato da organizao no possuir todas as caractersticas exigidas pela categoria Entendimento no significa que ela no conseguir gerar alguns indicadores propostos. Talvez seja possvel gerar alguns indicadores, porm a organizao corre o risco de despender um esforo muito grande para ger-los e mant-los, alm de correr o risco de gerar informaes inconsistentes e ambguas. Os indicadores gerados na Categoria Controle tm o intuito de serem utilizados durante a execuo do projeto, permitindo que o gerente tenha maior controle do projeto e possa tomar

80

medidas corretivas durante a execuo do mesmo. Para que a organizao ingresse nessa categoria, foram utilizados conceitos do nvel 3 de maturidade (Definido) do CMMI (2001) e do nvel E (Parcialmente Definido) do MPS.BR (SOFTEX, 2007). Neste ponto, o PGIGR procura aferir se a organizao possui um repositrio com medidas histricas coletadas a partir da execuo de projetos na categoria Entendimento, assim como a padronizao de alguns processos. As caractersticas definidas para esta categoria Controle so: 1. A organizao possui uma base histrica (repositrio de medidas) de mtricas e indicadores 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 semelhanas, visando gerar grficos de controle com limites superior e, conforme exemplos apresentados no Quadro 2 do referencial terico. Esta caracterstica est embasada na rea de processo de gerncia de projetos do MPS.BR (SOFTEX, 2007). Um dos produtos esperados da gerncia de projetos para o nvel E (Parcialmente Definido) a definio de um repositrio de medidas da organizao (DFP6). O repositrio de medidas da organizao deve ser, continuamente, atualizado com dados dos projetos executados na categoria Entendimento, para que, na categoria de Controle, dados histricos sejam utilizados em novos projetos. Como critrio de avaliao visando migrar para a categoria Controle do PGIGR, sugere-se um quantitativo de mtricas de gerncia de requisitos coletadas a partir de trs projetos similares (mesma tecnologia, mesmo mtodo de desenvolvimento e complexidade) e,

preferencialmente, j concludos. 2. A organizao possui um processo padronizado de gerncia de requisitos O PGIGR prope que a organizao tenha um processo padro para gerenciar requisitos, antes de ingressar na categoria de Controle. Isso se faz necessrio para que a organizao colete medidas bsicas e derivadas que sejam equivalentes, o que possibilita uma correta e efetiva comparao entre os indicadores gerados, j que os mesmo so resultado de um processo equivalente. Esta caracterstica est embasada no nvel E (Parcialmente Definido) de maturidade do MPS.BR (SOFTEX, 2007). A implementao do nvel E numa organizao tem como foco principal a padronizao dos processos da organizao, atravs da definio de processos padro. 3. A organizao possui um processo padronizado de gerncia de projetos

81

O PGIGR prope que a organizao tenha um processo padro de gerenciamento de projetos antes de ingressar na categoria de Controle. Isso se faz necessrio para que a organizao colete medidas bsicas e derivadas que sejam equivalentes, o que possibilita uma efetiva comparao entre os indicadores gerados na categoria controle, j que os mesmo so resultado de um processo equivalente. Esta caracterstica est embasada no nvel E (Parcialmente Definido) de maturidade do MPS.BR (SOFTEX, 2007). Assim como para a gerncia de requisitos, importante que a organizao tambm padronize o seu processo de gerncia de projetos.

O objetivo da categoria Aprimoramento permitir que uma organizao avalie a evoluo da gesto de requisitos a partir de aprimoramentos realizados no processo de desenvolvimento de software. Os indicadores gerados nesta categoria daro uma viso do comportamento do processo antes e depois das medidas de aprimoramento. Isso sugere que esses indicadores devero ser avaliados aps a concluso dos projetos. Segundo KULPA e JOHNSON (2004), o objetivo dos modelos de desempenho permitir a previso 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 so utilizados principalmente nas estimativas que servem de base para o planejamento e na monitorao dos projetos. Os conceitos empregados nesta categoria foram extrados do nvel 4 de maturidade (Gerenciado Quantitativamente) do CMMI (2001) e nvel B (Gerenciado Quantitativamente) do MPS.BR. Um dos produtos esperados pelo nvel B (Gerenciado Quantitativamente) do MSP.BR a utilizao dos resultados histricos do seu desempenho (baseline). Neste ponto, o PGIGR procura aferir se h um baseline com a qual o desempenho dos projetos atuais pode ser comparado. A caracterstica definida para a categoria Aprimoramento : 1. A organizao possui baseline de desempenho do processo de requisitos O PGIGR sugere que a organizao tenha aproximadamente 20 medies distintas dos indicadores em seu baseline, antes de passar para a categoria de Aprimoramento. Isso permitir que alteraes feitas no processo possam ser aferidas e comparaes estatsticas possam ser feitas a partir de medidas coletadas na categoria de Controle e armazenadas. Esta caracterstica est embasada em um

82

dos produtos esperados pelo nvel B (Gerenciado Quantitativamente) do MPS.BR (SOFTEX, 2007). Para facilitar a visualizao do processo de categorizao da organizao, o PGIGR apresenta a Figura 24 do APNDICE A. Trata-se de uma espcie de fluxograma, onde possvel ter uma viso macro da sequncia das etapas de categorizao do processo de desenvolvimento de software da organizao 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 organizao para aspectos determinantes no que tange a criao de indicadores. O PGIGR adaptou conceitos propostos por Solingen e Berghout (1999, p. 11 - 17), no qual os autores indicam que a definio de objetivo para o aprimoramento do processo de desenvolvimento de software atravs de medies pode possuir quatro vertentes distintas: risco, custo, tempo e qualidade. Partindo desse princpio, o PGIGR adaptou a ideia original e criou o conceito de dimenses foco (Figura 15), com o intuito de melhor direcionar o foco da gerao de indicadores naquilo que a organizao considera mais relevante, de acordo com suas principais necessidades e caractersticas.

Figura 15 - Quatro Dimenses Foco para a gerao de indicadores (Adaptao de Solingen e Berghout, 1999)

83

O PGIGR prope que a organizao deve avaliar suas caractersticas, necessidades e questionar o que mais prioritrio para ela no que tange a gesto de requisitos, de acordo com a sua categorizao (classificao), definida no subprocesso anterior. Para este subprocesso foi definida uma nica atividade: Definir Dimenso Foco. Na Figura 16 apresentado o diagrama do subprocesso com a atividade, artefatos e responsabilidades. No processo PGIGR (APNDICE A) apresentado o detalhamento da atividade.

Figura 16 - Subprocesso para Definir Dimenso Foco

84

Com o intuito de facilitar a anlise e definio da escolha da dimenso foco que ser utilizada, o PGIGR apresenta uma matriz contendo cada uma das dimenses foco e uma descrio para cada uma das categorias, conforme apresentado na Tabela 5. Isso facilita para os usurios do processo, pois eles conseguem mais fcil e rapidamente definir qual deve ser o foco de seus indicadores, de acordo com aquilo que for definido como prioritrio pela organizao.

85

Tabela 5 - Matriz contendo as dimenses foco e descrio para cada uma das categorias Dimenso Foco Categoria Entendimento
RISCO

Descrio A organizao necessita melhor entender os riscos relacionados gerncia de requisitos nos projetos de software. A organizao necessita melhor monitorar os riscos relacionados gerncia de requisitos nos projetos de software. A organizao deseja minimizar os riscos relacionados gerncia de requisitos nos projetos de software. A organizao necessita melhor entender o tempo/esforo despendido nas atividades de requisitos em projetos de software. A organizao necessita melhor monitorar o tempo/esforo despendido nas atividades de requisitos em projetos de software. A organizao deseja reduzir o tempo/esforo despendido nas atividades de requisitos em projetos de software. A organizao necessita melhor entender os custos despendidos nas atividades de requisitos em projetos de software. A organizao necessita melhor monitorar os custos despendidos nas atividades de requisitos em projetos de software. A organizao deseja reduzir os custos despendidos nas atividades de requisitos em projetos de software. A organizao necessita melhor entender a qualidade dos produtos gerados pelas atividades de requisitos em projetos de software. A organizao necessita melhor monitorar a qualidade dos produtos gerados pelas atividades de requisitos em projetos de software. A organizao deseja aprimorar a qualidade dos produtos gerados pelas atividades de requisitos em projetos de software.

Controle Aprimoramento Entendimento

TEMPO

Controle Aprimoramento Entendimento

CUSTO

Controle Aprimoramento

QUALIDADE

Entendimento Controle Aprimoramento

3.5.3.3.

Subprocesso: Definir Objetivos (Metas)

A criao desse subprocesso visa definir os objetivos (metas) para a dimenso foco previamente selecionada, de acordo com a categorizao da organizao de TI. Para este subprocesso foram criadas duas atividades: Selecionar Objetivo(s) prdefinido(s) para a Gerncia de Requisitos e Criar Objetivo(s). Na Figura 17 apresentado o diagrama do subprocesso com as atividades, artefatos e responsabilidades. O APNDICE A apresenta o detalhamento de cada uma das atividades.

86

Subprocesso Definir Objetivos (Metas)

Legenda Definir Objetivos (Meta)

Papis:zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz GP Gerentes de Projetos AM Analista de Mtricas EP Engenheiro de Processo AR Analista de Requisitos

Dimenso Foco Definida

OBJ
GP AM EP AR

Selecionar Objetivo(s) pr-definido(s) para a Gesto de Requisitos

Artefatos: zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz MTO Matriz contendo os objetivos para cada categoria e dimenso foco OBJ - Objetivo(s) DMF - Dimenso Foco

MTO DMF Objetivo no selecionado OBJ

GP AM EP AR

Criar Objetivo(s)

Objetivo Selecionado

Smbolos Incio ou fim do processo Atividades do processo Papel Produto requerido Produto gerado

MTO

Objetivo(s) Definido(s)

Figura 17 - Subprocesso para Definir Objetivos (Metas)

Esta etapa do processo utiliza os conceitos originalmente apresentados pelo GQM (BASILI, CALDIERA e ROMBACH, 2002), que tambm possui a etapa de definio 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 dimenses foco (Tempo, Custo, Qualidade e Risco). Para cada categoria/dimenso foco foi definido no PGIGR um objetivo especfico para a gerncia de requisitos. A organizao 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 dimenso foco, minimizando as chances da organizao definir objetivos de forma equivocada, pois direciona os usurios do processo.

87

Tabela 6 - Matriz contendo sugestes de objetivos (metas) para cada categoria e dimenso foco

OBJETIVOS (Metas)
Categoria

ENTENDIMENTO
Dimenso Foco

CONTROLE Monitorar e controlar se o esforo e/ou prazo das atividades de requisitos esto dentro dos valores estipulados. (Meta T2) Monitorar e controlar se os custos das atividades de requisitos esto dentro dos valores estipulados. (Meta C2) Monitorar e controlar se a qualidade dos artefatos de requisitos est dentro dos valores estipulados. (Meta Q2) Monitorar e controlar os riscos relacionados ao gerenciamento dos requisitos (Meta R2)

APRIMORAMENTO

TEMPO (T)

Conhecer o esforo e/ou prazo necessrio para executar as atividades de requisitos. (Meta T1) Conhecer o custo despendido para executar as atividades de requisitos. (Meta C1) Conhecer a qualidade dos artefatos de requisitos. (Meta Q1) Entender os riscos relacionados ao gerenciamento de requisitos (Meta R1)

Reduzir o esforo e/ou prazo para executar as atividades de requisitos. (Meta T3) Reduzir os custos das atividades de requisitos. (Meta C3) Aprimorar a qualidade dos artefatos de requisitos e minimizar retrabalho. (Meta Q3) Reduzir os riscos relacionados ao gerenciamento dos requisitos (Meta R3)

CUSTO (C)

QUALIDADE (Q)

RISCO (R)

Com o intuito de possibilitar uma rastreabilidade entre os indicadores e objetivos, foi definida uma forma de identificao do objetivo, no qual o mesmo inicia com a primeira letra, que representa a da dimenso foco, e tem um seqencial numrico, de acordo com o quantitativo de objetivos criados. Isso pode ser visualizado nos parnteses 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 traados foram ou no 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 (Questes)

Legenda Definir Perguntas (Questes)

Papis:zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz GP Gerentes de Projetos AM Analista de mtricas AR Analista de Requisitos

Objetivos Definidos

PGT
AM GP AR

Selecionar pergunta(s) prdefinida(s)

Artefatos: zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz MTP Matriz contendo as perguntas para cada categoria e dimenso foco OBJ - Objetivo(s) PGT - Pergunta(s)

OBJ MTP Pergunta no selecionada PGT

GM GP AR

Criar Perguntas(s)

Pergunta Selecionada

Smbolos Incio ou fim do processo Atividades do processo Papel Produto requerido Produto gerado

MTP

Perguntas Definidas

Figura 18 - Subprocesso para Definir Perguntas (Questes)

Este passo do processo utiliza os conceitos originalmente apresentados pelo GQM (BASILI, CALDIERA e ROMBACH, 2002), que tambm apresenta a etapa de definio 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 dimenses foco (Tempo, Custo, Qualidade e Risco). Para cada categoria/dimenso 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 traados. A organizao pode utilizar as perguntas propostas, pode adequ-las s suas necessidades ou pode criar novas, caso as existentes no atendam as necessidades.

89

Tabela 7 - Matriz contendo sugesto de Perguntas (Questes) para cada categoria e dimenso foco

PERGUNTAS (Questes)
Categorias

Dimenso Foco

ENTENDER

CONTROLAR

APRIMORAR

TEMPO (T)

Qual o esforo e/ou produtividade nas atividades de requisitos? (T1.P1)

O esforo e/ou produtividade das atividades de requisitos est de acordo com os valores (faixa) esperados? (T2.P1) Os custos das atividades de requisitos esto de acordo com os valores (faixas) esperados? (C2.P1) A qualidade dos artefatos de requisitos j concludos est dentro dos valores estimados de qualidade? (Q2.P1) Qual o ndice de retrabalho das atividades de requisitos? (Q2.P2)

CUSTO (C)

Quanto custa para levantar, analisar e documentar os requisitos? (C1.P1)

O esforo e/ou produtividade das atividades de requisitos foi aprimorado aps aes de melhoria? (T3.P1) Os custos de execuo das atividades de requisitos foram reduzidos aps as aes de melhoria? (C3.P1) A densidade de defeitos nos artefatos de requisitos foi reduzida aps as aes de melhoria? (Q3.P1) Qual o ndice de aprimoramento das atividades da gerncia de requisitos aps implantao dos controles de risco em gerncia de requisitos? (R3.P1)

QUALIDADE (Q)

Qual a quantidade de defeitos nos artefatos de requisitos? (Q1.P1) Qual o custo de correo de defeitos nos artefatos de requisitos? (Q1.P2) Quais os principais riscos associados s atividades de requisitos? (R1.P1) Quais riscos associados s atividades de requisitos esto se concretizando durante o projeto? (R1.P2)

RISCO (R)

Os riscos do projeto, relacionados s atividades de requisitos, esto dentro das faixas estabelecidas no planejamento? (R2.P1)

Seguindo o padro de rastreabilidade proposto anteriormente na matriz de objetivos, o contedo contido entre parnteses aps cada pergunta da Tabela 7 para permitir a identificao e rastreabilidade entre os objetivos traados anteriormente e as perguntas, em qual o primeiro par de letras e nmero identifica o objetivo e o segundo par de letras e nmero identifica a pergunta.

90

3.5.3.5.

Subprocesso: Definir Indicadores

Este subprocesso tem como objetivo final criar os indicadores necessrios 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 formao dos indicadores, que so compostos no PGIGR por cinco elementos: 1. 2. 3. 4. 5. Objetivo Pergunta Indicador Medida derivada Medida bsica (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 bsicas (base)

91

O intuito em utilizar essa estrutura e nomenclatura viabilizar uma correta verificao do atendimento de um objetivo atravs 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 so compostas de duas ou mais medidas bsicas (ou base). Os conceitos de medidas derivadas e medidas bsica foram extrados do PSM (2008) com o intuito de facilitar o entendimento e padronizar a nomenclatura dos componentes de estruturao de um indicador. Como esta etapa do processo a que apresenta o maior nmero 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 APNDICE A apresenta o detalhamento de cada uma das atividades.

92

Figura 20 - Subprocesso para Definir Indicador

Uma observao a ser feita o fato da atividade de criao do indicador ser composta por uma grande quantidade de informaes 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 definio 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 dimenses foco (Tempo, Custo, Qualidade e Risco). Para cada categoria/dimenso foco foram definidos indicadores que a organizao pode utilizar, adaptar ou criar novos, conforme as suas necessidades e caractersticas. Isso ir facilitar a utilizao do processo, pois seus usurios podem escolher a partir de indicadores pr-definidos, podendo adapt-los medida que for necessrio. Cada indicador deve estar necessariamente relacionado a pelo menos uma pergunta previamente definida, de acordo com a categoria e dimenso foco.

Tabela 8 - Matriz contendo os Indicadores Sugeridos para cada categoria e dimenso foco

INDICADORES SUGERIDOS
Categoria

Dimenso Foco

ENTENDER
PAR Produtividade nas Atividades de Requisitos = (Somatrio de horas despendidas em atividades de requisitos) / (Tamanho do software) CAR Custos das Atividades de Requisitos = (Somatrio dos custos com atividades de requisitos) / (Tamanho do software)

CONTROLAR

APRIMORAR
IVP - ndice de Variao de Produtividade = (percentual do esforo gasto em atividades de requisitos por ponto de funo) / (mdia histrica de esforo por ponto de funo) * 100 IVC - ndice de Variao dos Custos = (percentual dos custos de requisitos por ponto de funo) / (mdia histrica dos custos por ponto de funo) * 100

TEMPO (T)

PVE Percentual de Variao do Esforo = (Esforo realizado at o presente momento / Esforo Estimado) * 100

CUSTO (C)

PVC - Percentual de Variao dos Custos = (Somatrio dos custos at o presente momento / Custos Estimados) * 100

QDR Quantidade de Defeitos em Requisitos = (Somatrio dos erros identificados em requisitos) / (Tamanho do Software)
QUALIDADE (Q)

PRR - Percentual de Requisitos Rejeitados = (percentual de requisitos rejeitados / percentual estimado de rejeio) *100

RISCO (R)

CTD Custo Total de Defeito em Requisitos = (somatrio dos custos de correo de erros identificados em requisitos) / (Tamanho do software) QRI Quantidade de Requisitos Incorporados ao escopo = (Quantidade de Requisitos aps o fechamento da linha de

IVQ ndice de variao da qualidade = [(porcentagem de requisitos rejeitados por ponto de funo) / (porcentagem histrica de requisitos rejeitados por ponto de funo)] * 100

PSM - Percentual de solicitaes de mudana = (percentual de solicitaes de mudana de escopo / percentual estimado de alteraes no

IVR - ndice de Variao de Risco = (porcentagem de requisitos concludos na release / porcentagem histrica de requisitos

94

INDICADORES SUGERIDOS
Categoria

Dimenso Foco

ENTENDER
base) / (Quantidade de Requisitos ao final do projeto) *100 PPU - Percentual de Participao do Usurio = (nmero de reunies que representantes dos usurios participaram / nmero de reunies realizadas) * 100 PVR - Percentual de Validao de Requisitos pelo Cliente = (nmero de documentos de requisitos validados / nmero total de documentos de requisitos) * 100

CONTROLAR
escopo) *100

APRIMORAR
concludos) * 100

PAR - Percentual de Alterao dos Requisitos j aprovados = (nmero de solicitaes de mudanas de requisitos / nmero total de requisitos j aprovados) * 100 PMT - Quantitativo de Mudanas nos Requisitos de acordo com o Tamanho do Software = (nmero de requisitos alterados / Tamanho do Software) * 100

Durante o processo de criao da Tabela 8, alguns dos indicadores propostos foram adaptados a partir de indicadores apresentados por Hazan (2002, 2003) e Loconsole (2001, 2002, 2003, 2004). Porm, a grande maioria dos indicadores descritos pelas autoras apresentava somente a frmula, no entrando em detalhes necessrios para a sua implantao em um ambiente corporativo. Maiores detalhes a respeito de como utilizar a Tabela 8 podem ser visualizados no APNDICE A.

95

Com o intuito de detalhar cada indicador definido, o PGIGR apresenta um template (Tabela 23 do APNDICE 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 iro 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 nvel de detalhamento e minimizar ambigidade e falhas na descrio 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 usurios do processo atravs da visualizao de um exemplo j preenchido. No APNDICE B so apresentados mais dois exemplos de indicadores detalhados utilizando o template. Esses dois indicadores so anexos dos PGIGR. Os dois indicadores so da categoria Entendimento, sendo um da dimenso foco tempo e o outro de custo. 3.5.3.6. Aprimorar o Processo de Software da Organizao de TI

O Aprimoramento do Processo de Software no um subprocesso do PGIGR e por isso ele encontra-se destacado na Figura 12. Porm, ele elemento necessrio dentro do ciclo proposto pelo PGIGR para que a organizao de TI possa evoluir entre as quatro categorias propostas (Inicial, Entendimento, Controle e Aprimoramento), permitindo assim a gerao de indicadores mais robustos ao longo do tempo. O PGIGR destaca esta etapa do processo devido sua importncia dentro da estrutura proposta pelo processo. Para que a organizao possa criar novos indicadores, quase sempre necessrio avaliar se o seu processo de desenvolvimento de software e infra-estrutura esto aptos a suportar as novas necessidades. Grande parte das medidas bsicas e derivadas necessrias na formao dos indicadores derivam de atividades e ferramentas utilizadas no processo de desenvolvimento de software, conforme as caractersticas apresentadas na Figura 13. importante ressaltar que a evoluo entre as diferentes categorias fica a critrio da organizao de TI. Sugere-se a evoluo entre as categorias de Entendimento, Controle e Aprimoramento de acordo com a evoluo das necessidades da organizao, no sendo ela

96

obrigada a evoluir, caso suas necessidades estejam sendo atendidas pelos indicadores da categoria na qual ela se encontra. 3.6. Avaliao do Processo Proposto Nesta seo descreve-se como foi avaliado o processo proposto e no captulo 4 so apresentados os resultados dessa avaliao. 3.6.1. Propsito da Avaliao e Delimitao A avaliao do processo torna-se necessria para que seja possvel aferir o atendimento das caractersticas traadas para o processo, conforme apresentado no Quadro 4. Para isso, optou-se por uma avaliao atravs de questionrio, onde foi definido um conjunto de perguntas que pudessem avaliar se todas as caractersticas foram ou no atendidas. O questionrio no teve como escopo avaliar os resultados da aplicao do PGIGR na prtica, pois no haveria tempo hbil para a sua aplicao e coleta dos resultados obtidos. 3.6.2. Elaborao do Questionrio de Avaliao O questionrio de avaliao foi subdividido em trs sees distintas, visando facilitar o seu preenchimento e segmentar as informaes coletadas. A primeira seo apresenta um conjunto de questes que visa coletar algumas caractersticas a respeito do avaliador e da organizao onde o mesmo trabalha. Essa seo foi respondida durante a apresentao do questionrio e antes do incio da avaliao do processo PGIGR. A segunda seo do questionrio apresenta as questes que avaliam cada um dos subprocessos e as atividades do PGIGR. Os avaliadores foram orientados a responder as questes desta seo medida que fossem lendo o processo PGIGR. A terceira e ltima seo do questionrio composta de questes que deveriam ser respondidas aps a avaliao do processo. Elas tm um carter mais abrangente e visam avaliar o processo como um todo. O questionrio composto de perguntas de mltipla escolha e perguntas onde as respostas so descritivas. O questionrio pode ser visualizado no APNDICE C.

97

3.6.3.

Identificao e Amostragem da Populao Para a aplicao do questionrio foram selecionados cinco avaliadores de trs diferentes

organizaes. Os profissionais selecionados possuem diferentes perfis, porm todos possuem formao superior, so atuantes na rea de desenvolvimento de software e possuem perfis e experincias 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 viso mais precisa do processo a partir de diferentes pontos de vista. O nmero mpar de avaliadores deve-se ao fato de se buscar um resultado que no gerasse um empate ao final da avaliao, o que dificultaria na aferio do atendimento das caractersticas definidas para o processo. Como um dos objetivos do PGIGR de ser um processo intuitivo, de fcil compreenso e utilizao, optou-se por no selecionar um especialista de mtricas como avaliador, pois trata-se de um profissional que j possui conhecimentos a respeito do assunto e poderia gerar uma avaliao destoante a respeito da facilidade em se utilizar o PGIGR. 3.6.4. Aplicao do Questionrio O processo de aplicao do questionrio seguiu os seguintes passos: I. Entrega de uma cpia impressa do PGIGR para cada avaliador. Tambm foi enviada a verso digital do processo por e-mail, caso o avaliador optasse pela sua utilizao em meio digital. II. Apresentao individual de 30 minutos para cada avaliador para dar uma viso geral do PGIGR, assim como descrever os objetivos da avaliao. III. Entrega de uma cpia impressa do questionrio de avaliao para cada avaliador. Tambm foi enviada a verso digital do questionrio por e-mail, caso o avaliador optasse pelo seu preenchimento em meio digital. IV. Apresentao de 15 minutos para cada avaliador visando esclarecer o questionrio e forma de preenchimento. V. O avaliador foi orientado a responder a primeira seo do questionrio antes de iniciar a avaliao do processo. A primeira seo do questionrio visa apenas coletar algumas caractersticas da organizao 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 sees 2 e 3 do questionrio. O avaliador foi orientado a responder a seo 2 do questionrio medida que fosse lendo o processo, e a seo 3 aps a concluso da leitura. VII. Aps a concluso do prazo de avaliao, foram coletados os questionrios e as cpias impressas dos processos contendo comentrios e sugestes. Eventuais sugestes verbais tambm foram consideradas e registradas. VIII. Foi feita uma consolidao e tabulao das respostas apresentadas nos questionrios. IX. A partir das observaes, comentrios e sugestes feitas pelos avaliadores do processo, ajustes foram feitos no PGIGR, gerando-se assim a verso final do processo apresentado no APNDICE A. X. Por fim, foi feito um mapeamento entre as caractersticas traadas para o PGIGR e as evidncias coletadas atravs dos questionrios, com o intuito de aferir se todas as caractersticas traadas foram atendidas ou no. Observaes a respeito do processo de avaliao do PGIGR: no houve qualquer interveno durante o perodo de avaliao; caso o avaliador tivesse algum tipo de dvida a respeito do processo, eles foram instrudos a descrever as dificuldades no questionrio de avaliao, no havendo qualquer tipo de contato para retirada de dvidas aps a apresentao inicial, realizada pelo pesquisador. Essa abordagem teve como objetivo avaliar a clareza e facilidade de entendimento do processo, assim como proporcionar um cenrio de avaliao igualitrio para todos os avaliadores. 3.6.5. Etapa de Anlise dos Dados Aps a avaliao do processo realizada pelos cinco Avaliadores, os dados dos questionrios, comentrios e sugestes foram consolidados, tabulados e processados. Para cada uma das trs sees contidas no questionrio de avaliao foi gerada uma matriz. Cada linha da matriz representa uma das perguntas objetivas do questionrio e as colunas representam as respostas de cada um dos cinco avaliadores. Para aferio dos resultados, na ltima coluna foi utilizado o calculo da moda, que representa a resposta de maior ocorrncia. Aps anlise das respostas objetivas, os comentrios, crticas e sugestes feitas pelos avaliadores foram analisados individualmente. Foram descritos, principalmente, os comentrios e sugestes de aprimoramento que abordavam aspectos mais estruturais do processo, assim como

99

as alteraes sofridas pelo processo PGIGR a partir das sugestes feitas. Correes e sugestes mais pontuais, como correes ortogrficas e estruturao frasal foram analisadas e incorporadas ao processo, porm no foram detalhadas. Com o intuito de avaliar se as caractersticas traadas para o processo no Quadro 4 foram ou no atendidas, foram utilizadas as respostas dos avaliadores, assim como o contedo detalhado no processo. Para cada uma das caractersticas foram mapeadas as evidncias que apontavam para o seu atendimento. Posteriormente, o processo foi comparado com os principais modelos de criao de indicadores j existentes na literatura. O objetivo da comparao foi apresentar os benefcios trazidos pelo PGIGR, quando contrastado com os demais. Como critrio de comparao foi criada uma matriz contendo nas linhas as caractersticas traadas para o PGIGR e nas colunas os modelos que foram utilizados na comparao. Posteriormente foi feita uma consolidao e anlise crtica dos principais benefcios trazidos pelo PGIGR. Os detalhes dos resultados obtidos pela avaliao do processo podem ser visualizados no captulo 4.

100

4. RESULTADOS E DISCUSSES

Este captulo 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 anlise crtica do processo proposto. As respostas objetivas foram organizadas e tabuladas para serem apresentadas no formato de tabelas. 4.1. Contextualizao dos Avaliadores e das Organizaes onde Trabalham. As duas primeiras questes do questionrio, por serem descritivas e coletarem informaes a respeito dos avaliadores e suas organizaes, esto consolidadas abaixo. Optou-se por no revelar os nomes dos avaliadores e das organizaes ou empresas onde trabalham. O Avaliador 1 um Analista de Sistemas e possui sete anos de experincia na rea de desenvolvimento de sistemas. Ele trabalha em uma empresa privada especializada em servios de TI. A empresa possui nvel 5 de maturidade no CMMI e nvel A no MPS.BR. Trata-se de uma empresa de grande porte, com mais de quatro mil funcionrios. Porm, atualmente o Avaliador presta servios lotado em uma instituio governamental do Distrito Federal que possui seu prprio processo de desenvolvimento de software. A rea de desenvolvimento de software dessa instituio constituda por aproximadamente setenta profissionais de variados perfis. O Avaliador 2 um Analista de Requisitos e possui quinze anos de experincia na rea de desenvolvimento de software. Os Avaliadores 1 e 2 trabalham para a mesma empresa e prestam servio para o mesmo cliente. O Avaliador 3 um funcionrio pblico, especialista em gerncia de projetos e trabalha em um banco governamental federal. Ele possui vinte e seis anos de experincia na rea de TI. mestre em cincia da computao pela Universidade de Braslia (UNB) e aluno especial no curso de doutorado da UNB em Cincia da Informao. 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 pblico com especialidade em desenvolvimento de software e trabalha para um rgo governamental federal. Ele possui cinco anos de experincia na rea de desenvolvimento de software e mestrando em Cincia da Computao pela Universidade Federal de Gois UFG. O rgo para o qual o avaliador trabalha presta servios eleitorais para o estado de Gois e possui aproximadamente trinta pessoas na rea de desenvolvimento de software. Apesar do rgo no possuir um processo formal de desenvolvimento de software, grande parte dos projetos utiliza tcnicas de desenvolvimento gil. O Avaliador 5 um servidor pblico que atualmente coordena a rea de desenvolvimento de sistemas de um rgo governamental federal. Ele possui seis anos de experincia na rea de desenvolvimento de sistemas e ps-graduado em Gesto de Sistemas pela Universidade Federal de Gois UFG. Os Avaliadores 4 e 5 trabalham para o mesmo rgo. 4.2. Consolidao dos dados da Primeira Etapa do Questionrio Nesta seo, os dados da primeira etapa do questionrio de avaliao do processo PGIGR foram consolidados em uma tabela, visando identificar as respostas objetivas com maior ocorrncia (moda). Esta etapa do questionrio tem como objetivo coletar algumas informaes a respeito dos avaliadores e sobre as organizaes onde trabalham ou prestam servios.

102

Tabela 9 - Consolidao dos dados da Primeira Etapa do Questionrio Legenda: PAR Parcialmente, NSI No soube informar Avaliador 1 Avaliador 2 Avaliador 3 Avaliador 4 Avaliador 5

Perguntas
3. Voc possui experincia prtica quanto a utilizao de medies e indicadores em desenvolvimento de software? 4. Voc acredita que a gesto de requisito um dos fundamentos mais crticos para o sucesso dos projetos na organizao onde trabalha? 5. A organizao onde trabalha enfrenta dificuldades no que tange a gesto de requisitos? 6. A organizao onde trabalha possui um processo para a gesto de requisitos? 7. A organizao onde trabalha possui prticas de gerncia de projetos? 8. A organizao onde trabalha possui ferramenta gerencial para controle de atividades de projetos? 9. A organizao onde trabalha possui ferramenta e processo para controle de versionamento dos artefatos de requisitos? 10. A organizao onde trabalha possui prticas de mensurao do tamanho de software? 11. Atualmente a organizao onde trabalha utiliza indicadores para gerenciar requisitos? 12. A organizao onde trabalha possui um processo de desenvolvimento de software?

Moda

NO

SIM

SIM

NO

NO

NO

NO

SIM

PAR

PAR

SIM

SIM/PAR

SIM

PAR

SIM

SIM

SIM

SIM

PAR

SIM

SIM

NO

NO

SIM/NO

PAR

SIM

SIM

PAR

SIM

SIM

PAR

PAR

SIM

PAR

SIM

PAR

SIM

SIM

SIM

PAR

SIM

SIM

SIM

SIM

SIM

NO

NO

SIM

NO

PAR

PAR

NO

NO

NO

PAR

SIM

SIM

NO

NO

SIM/NO

Os resultados obtidos com as respostas dos avaliadores na primeira etapa do questionrio demonstram que a maioria dos avaliadores no possui experincia quanto ao uso de medies e indicadores em projetos de desenvolvimento de software. Os dados tambm mostram que apenas um avaliador no concordou que a gesto de requisitos um dos fatores mais crticos para o sucesso em projetos de software nas organizaes onde trabalham.

103

Praticamente todas as organizaes onde os avaliadores trabalham apresentam dificuldades no que tange a gesto de requisitos, apesar da maioria delas possuir prticas de gerncia de requisitos. Grande parte das organizaes tambm possui prticas de gerncia de projetos, possuem ferramentas de controle de verso e prticas de mensurao de software. As questes de nmero seis a dez tinham como intuito representar as caractersticas exigidas para que uma organizao ingresse na categoria de Entendimento. Pelos resultados obtidos, foi constatado que apenas a organizao do Avaliador 3 apresentou todos os critrios exigidos para ingressar na categoria Entendimento. J a organizao dos Avaliadores 1 e 2 apresentou alguns resultados parciais, sendo que a organizao dos Avaliadores 4 e 5 no possui alguns dos critrios exigidos, como um processo para gesto de requisitos e prticas de mensurao 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 rgo governamental, as respostas a respeito das caractersticas da organizao onde trabalham no foram necessariamente iguais. Isso ressalta a importncia do processo de categorizao da organizao ser feito por um grupo de pessoas da organizao que chegue a um consenso a respeito do assunto, pois essa deciso fundamental para a correta utilizao do processo. 4.3. Consolidao dos dados da Segunda Etapa do Questionrio Nesta seo, os dados da segunda etapa do questionrio de avaliao do processo PGIGR foram consolidados em uma tabela, visando identificar as respostas objetivas com maior ocorrncia (moda). Esta etapa do questionrio foi respondida pelos avaliadores medida que eles foram lendo o processo, visando obter uma impresso precisa a respeito de cada um dos subprocessos e atividades avaliadas.

104

Tabela 10 Consolidao dos dados da Segunda Etapa do Questionrio Legenda: PAR Parcialmente, NSI No soube informar
Avaliador 1 Avaliador 2 Avaliador 3 Avaliador 4 Avaliador 5

Perguntas
13. Em sua opinio, a parte introdutria do PGIGR, que apresenta uma viso geral do processo, de fcil entendimento? 14. Em sua opinio, a introduo do subprocesso Categorizar o Processo de Software de fcil entendimento? 15. Em sua opinio, a atividade Definir Envolvidos de fcil entendimento? 16. Em sua opinio, a atividade Definir Categoria de fcil entendimento? 17. Em sua opinio, a introduo do subprocesso Definir Dimenso Foco de fcil entendimento? 18. Em sua opinio, a atividade Priorizar Dimenso Foco de fcil entendimento? 19. Em sua opinio, a atividade Definir Dimenso Foco para a Gerao de Indicadores de fcil entendimento? 20. Em sua opinio, a introduo do subprocesso Definir Objetivos de fcil entendimento? 21. Em sua opinio, a atividade Selecionar os Objetivos prdefinidos para Gerncia de Requisitos de fcil entendimento? 22. Em sua opinio, a atividade Criar Objetivos de fcil entendimento? 23. Em sua opinio, a introduo do subprocesso Definir Perguntas de fcil entendimento? 24. Em sua opinio, a atividade Selecionar Perguntas Pr-Definidas de fcil entendimento? 25. Em sua opinio, a atividade Criar Perguntas de fcil entendimento? 26. Em sua opinio, a introduo do subprocesso Definir Indicadores de fcil entendimento? 27. Em sua opinio, a atividade Selecionar Indicadores PrDefinidos de fcil entendimento? 28. Em sua opinio, a atividade Descrever o Indicador de fcil entendimento? 29. Em sua opinio, a atividade Estruturar o Indicador de fcil entendimento? 30. Em sua opinio, a atividade Divulgar/Aprimorar o Indicador de fcil entendimento?

Moda

SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM

SIM SIM PAR PAR SIM SIM SIM PAR SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM

SIM SIM SIM SIM SIM SIM SIM PAR SIM SIM SIM SIM PAR PAR SIM SIM SIM SIM

SIM SIM SIM SIM SIM PAR PAR SIM PAR SIM SIM PAR PAR SIM SIM SIM SIM SIM

SIM SIM SIM SIM SIM SIM PAR SIM SIM SIM SIM SIM SIM PAR SIM SIM SIM SIM

SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM

105

Os resultados obtidos com as respostas dos avaliadores na segunda etapa do questionrio demonstram que todos os avaliadores consideraram os 17 itens avaliados do processo como sendo de fcil compreenso e entendimento, no havendo nenhum item que apresentasse moda diferente de SIM. Essa informao muito importante devido ao fato de caracterizar um consenso no que diz respeito a facilidade para entender o processo e os passos que ele prope a criao dos indicadores para a gerncia de requisitos. 4.4. Consolidao dos dados da Terceira Etapa do Questionrio Nesta seo, os dados da terceira etapa do questionrio de avaliao do processo PGIGR foram consolidados em uma tabela, visando identificar as respostas objetivas com maior ocorrncia (moda). Esta etapa do questionrio foi respondida pelos avaliadores aps a concluso da leitura do processo.
Tabela 11 - Consolidao dos dados da Terceira Etapa do Questionrio Legenda: PAR Parcialmente, NSI No soube informar Avaliador 1 Avaliador 2 Avaliador 3 Avaliador 4 Avaliador 5

Perguntas
31. Quanto tempo voc levou para avaliar o processo PGIGR? 32. Em sua opinio, qual o nvel de dificuldade para compreender PGIGR? 33. Em sua opinio, qual o nvel de dificuldade para utilizar o PGIGR? 34. Voc acredita que o PGIGR poderia ser aplicado na organizao onde trabalha? 35. Voc acredita ser necessrio um especialista em mtricas para utilizar o PGIGR? 36. Voc conseguiria criar um indicador seguindo o processo?

Mdia / Moda

5h

4h

2h30

5h

2h

3h45

BAIXO

MDIO

BAIXO

BAIXO

BAIXO

BAIXO

MDIO

BAIXO

MDIO

MDIO

MDIO

MDIO

SIM

PAR

SIM

PAR

SIM

SIM

NO

SIM

NO

NSI

NO

NO

SIM

SIM

SIM

PAR

SIM

SIM

Os resultados obtidos com as respostas dos avaliadores na terceira etapa do questionrio demonstram que necessrio, em mdia, 3 horas e 45 minutos para ler e compreender o processo. Esse tempo considerado satisfatrio, tendo em vista a grande quantidade de detalhes

106

apresentados pelo processo e o fato da maioria dos avaliadores no possuir experincia no assunto. O processo foi considerado como sendo de baixa complexidade. Apesar da maioria dos avaliadores acreditar que o PGIGR pode ser implantado na organizao onde trabalham, alguns acreditam tambm que dificuldades seriam enfrentadas devido a questes estruturais das organizaes e, por isso, a maioria considerou que a sua utilizao (ou implantao) seria de mdia complexidade. Para que o processo fosse acessvel maioria das organizaes, uma das principais caractersticas que ele deveria ter era a simplicidade, no sendo necessrio especialistas na rea de mtricas para a sua utilizao. De acordo com os avaliadores, essa caracterstica tambm foi atendida, pois, segundo eles, no necessrio um especialista em mtricas para utilizar o processo e todos conseguiriam criar um indicador seguindo os passos apresentados pelo PGIGR. 4.5. Consolidao dos Comentrios e Observaes Feitas pelos Avaliadores do Processo PGIGR Nesta seo so relatadas as principais observaes e sugestes feitas pelos cinco avaliadores do processo. Foram descritos, principalmente, os comentrios que abordam aspectos mais estruturais do processo, assim como as alteraes sofridas pelo processo PGIGR a partir das sugestes feitas pelos avaliadores. Correes e sugestes mais pontuais, como correes ortogrficas e estruturao frasal foram analisadas e incorporadas ao processo, porm no foram detalhadas abaixo. 4.5.1. Comentrios e Sugestes do Avaliador 1 O Avaliador fez algumas observaes e comentrios a respeito da parte introdutria do processo. Segundo ele, era necessrio maior detalhamento a respeito das diferentes categorias de classificao de uma organizao. Tendo isso em vista, foi feito uma alterao no processo, em que um breve relato no incio do processo descreve o objetivo de cada uma das quatro categorias propostas: Inicial, Controle, Entendimento e Aprimoramento. O Avaliador sugeriu que na descrio da etapa de Aprimorar o Processo de Desenvolvimento de Software fossem descritos os principais problemas encontrados em organizaes, assim como sugestes de possveis solues. Essa sugesto no foi incorporada ao processo, pois para isso seria necessrio aplicar o processo em diferentes organizaes para que

107

fosse possvel ter um histrico com esse tipo de informao. Mas, nada impede que uma organizao que adote o processo possa vir a adaptar o processo, incluindo esse tipo de informao. O Avaliador sugeriu a insero de um resumo logo aps a concluso da descrio de cada um dos subprocessos e suas atividades. Essa sugesto no foi acatada devido ao volume de pginas j existentes no processo. Ao invs de se inserir um resumo, o que acarretaria em repetio de informaes, optou-se por reorganizar o contedo previamente existente no processo, assim como adequar a escrita, deixando-a mais clara e objetiva. O Avaliador fez o seguinte comentrio: ... ficou muito bom! Claro, elegante, conciso, bem embasado e inovador... Uma observao final feita pelo Avaliador foi a respeito da aplicabilidade do PGIGR em um ambiente que utiliza tcnicas de Extreme Programming (XP) para desenvolvimento de software. Segundo ele, talvez alguns aspectos do PGIGR tivessem que ser adaptados para que organizaes que utilizam esse tipo de metodologia possam utilizar o PGIGR. Esse fator teria que ser melhor estudado e eventuais limitaes poderiam ser apontadas para organizaes que tm interesse em utilizar o PGIGR, porm utilizam tcnicas de desenvolvimento gil. 4.5.2. Comentrios e Sugestes do Avaliador 2 O Avaliador fez observaes mais pontuais no que tange s sugestes de melhoria. Assim como o Avaliador 1, ele tambm achou que a parte introdutria 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 relao ao termo Dimenso Foco. Por conta disso, o nome original do Subprocesso Definir Dimenso 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 pginas do processo. O Avaliador fez o seguinte comentrio: ... o processo aborda um tema de extrema relevncia e pode melhor direcionar organizaes que pretendem ingressar em um processo de medio de software, porm no possuem profissionais com larga experincia no assunto. O Avaliador considerou como sendo as maiores contribuies do processo a matriz contendo os objetivos para a gerncia de requisitos e os indicadores propostos pelo processo.

108

4.5.3.

Comentrios e Sugestes do Avaliador 3 Grande parte das observaes feitas pelo Avaliador no texto do processo so referentes a

ajustes ortogrficos e estrutura textual. No houve qualquer sugesto de ajuste estrutural do processo, apenas sugestes de ajustes textuais com o intuito de deixar a compreenso do processo mais clara e objetiva. Em conversa com o Avaliador, notou-se que houve certa confuso a respeito do que seria um subprocesso e uma atividade. Por conta disso, na parte introdutria do processo PGIGR foram inseridos trechos de texto visando deixar clara a funo e composio dos subprocessos e suas atividades. O Avaliador fez o seguinte comentrio: ... o template de criao 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 experincia provavelmente ainda teriam um pouco de dificuldade para compreender o processo rapidamente, devido ao volume de contedo apresentado pelo mesmo. 4.5.4. Comentrios e Sugestes do Avaliador 4 O Avaliador fez vrias observaes a respeito do processo. No que diz respeito parte introdutria do processo, o Avaliador achou que seria interessante melhor descrever a respeito dos papis 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 papis e suas atribuies. Tambm foi melhor descrito os papis envolvidos dentro de cada uma das atividades do processo. O Avaliador achou que as atividades de Priorizao da Dimenso Foco e Definio da Dimenso Foco poderiam ser fundidas em uma s. Como este Avaliador e o Avaliador 5 tambm fizeram a mesma observao, optou-se por fundir as duas atividades em uma s, deixando o processo mais objetivo e claro. O Avaliador tambm levantou dvidas a respeito do porqu em se escolher apenas uma dimenso foco para a definio de indicadores. Como se trata de uma recomendao do processo e no de uma imposio, tal explanao foi refinada e uma observao foi inserida na atividade Definio da Dimenso Foco para a Gerao de Indicadores. No subprocesso Definir Objetivos (Metas), o Avaliador entendeu que os objetivos sugeridos pelo processo estavam muito genricos e em pouca quantidade. Como o objetivo do

109

PGIGR no foi exaurir todas as possibilidades de objetivos que uma organizao possa vir a ter para a gerncia de requisitos, foram sugeridos objetivos mais genricos, visando abranger o maior nmero possvel de organizaes. Porm, a forma como o processo est estruturado prov meios para que uma organizao crie seus prprios objetivos, de acordo com suas necessidades. Para isso, existe a atividade de criao de objetivos, na qual a organizao 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 (Questes), o Avaliador fez comentrios similares aos feitos no subprocesso Definir Objetivos. Ele achou importante ressaltar que o usurio 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 prdefinidos um pouco reduzida, com exceo dos indicadores de risco na categoria Entender. Como o objetivo do PGIGR no exaurir todos os indicadores possveis para uma correta gesto de requisitos, mas apresentar os passos que devem ser seguidos para se criar um indicador, foi feita essa ressalva na descrio 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 fcil de entender devido ao fato dele estar bem exemplificado, facilitando o entendimento de leigos no assunto. Como observao final, o Avaliador fez o seguinte comentrio: Apesar de o PGIGR ser de fcil compreenso, creio que ele no facilmente aplicvel por profissionais sem (ou com pouca) experincia em mtricas e/ou gerncia de projetos. Tambm no acho que o processo seja difcil de ser implantado por esses mesmos profissionais, mas acho que o esforo demandado por eles ser razovel, pois, por mais claro e bem explicado que esteja o processo, no h como fugir de alguns aspectos tericos e prticos da engenharia de software que demandaro estudo e/ou treinamento por parte de uma equipe inexperiente. As observaes feitas por este Avaliador evidenciam uma possvel necessidade de o PGIGR definir um mnimo de experincia do(s) profissional(is) que venha(m) a utilizar o processo.

110

4.5.5.

Comentrios e Sugestes do Avaliador 5 O Avaliador fez vrias observaes a respeito do processo. No subprocesso Categorizar o

Processo de Software da Organizao de TI, o Avaliador achou que a quantidade de caractersticas 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 difcil para uma organizao de menor porte atender todas as caractersticas exigidas pela categoria Entendimento. A ideia apresentada pelo avaliador bastante vlida, pois de acordo com as informaes coletadas na parte inicial do questionrio (questes 6 a 10 da Tabela 9), apenas a organizao do Avaliador 3 apresentou todas as caractersticas exigidas para ingressar na categoria Entendimento. Porm, a sugesto do avaliador no foi acatada para esta verso do processo, pois a proposta tem que ser melhor avaliada medida que organizaes forem utilizando o processo. Como trabalho futuro, pode-se avaliar a possibilidade de criar novas categorias, gerando maior segmentao, conforme foi feito pelo MPS.BR, quando comparado com o CMMI. Assim como o Avaliador 4, o Avaliador 5 tambm achou que as atividades de Priorizao da Dimenso Foco e Definio da Dimenso foco poderiam ser fundidas em uma s. Conforme mencionado anteriormente, aps anlise da sugesto, optou-se por fundir as duas atividades em uma s, deixando o processo mais objetivo e claro. O Avaliador apresentou dvidas com relao figura que mostra o relacionamento entre os objetivos, perguntas, indicadores, medidas derivadas e medidas bsicas. Por isso o texto que explica a Figura 29 do APNDICE A foi modificado, visando deixar mais claro o propsito da figura. Como observao final, o avaliador ressaltou: ... foi simples compreender o processo, porm para utiliz-lo na organizao onde trabalho seria um pouco difcil, principalmente pelo fato de no utilizarmos tcnicas de contagem do tamanho do software. Talvez fosse interessante criar um nvel onde essa caracterstica no fosse exigida, permitindo a gerao de alguns indicadores. Conforme mencionado anteriormente, a sugesto do Avaliador no foi acatada para esta verso devido a quantidade de alteraes que seria necessrio nesse momento e tambm pelo fato de ser necessrio avaliar se outras organizaes tero a mesma impresso (ou dificuldade). Foi ressaltado no texto do processo que o fato da organizao no possuir todas as caractersticas exigidas pela categoria Entendimento no significa que ela no conseguir utilizar alguns dos indicadores propostos. Talvez seja possvel gerar alguns indicadores, porm a

111

organizao corre o risco de despender um esforo muito grande para ger-los e/ou mant-los, alm de correr o risco de gerar informaes inconsistentes e ambguas. 4.6. Avaliao do PGIGR Quanto ao Atendimento s Caractersticas Traadas para o Processo Esta etapa da pesquisa visa avaliar se todas as caractersticas traadas para o PGIGR no Quadro 4 foram ou no atendidas. Para realizar essa avaliao foram utilizadas as respostas dos profissionais que avaliaram o processo, assim como o contedo detalhado no processo. Para cada uma das caracterstica foram mapeadas as evidncias que apontam para o seu atendimento, conforme apresentado na Tabela 12.

Tabela 12 - Avaliao do PGIGR Quanto ao Atendimento s Caractersticas Traadas para o Processo Legenda: PAR Parcialmente, NSI No soube informar

Caracterstica
O processo de fcil compreenso. (CRC01)

Atendida
SIM

Evidncia
Essa caracterstica foi considerada atendida, pois a maioria dos avaliadores considerou como BAIXA a dificuldade para compreender o processo (Questo 32 da Tabela 11). Essa caracterstica foi considerada parcialmente atendida, pois a maioria dos avaliadores considerou o processo como sendo de dificuldade MDIA, quanto a utilizao (Questo 33 da Tabela 11). A maioria dos avaliadores considerou que

O processo de fcil utilizao. (CRC02)

PAR

apesar do processo ser de simples compreenso, a sua implantao dentro de um contexto organizacional seria um pouco mais complicado, apesar de factvel. Essa resposta est de certa forma relacionada com a Questo 34 da Tabela 11, em que a maioria considerou que seria possvel implantar o processo na organizao onde trabalha. A mdia de tempo utilizado pelos respondentes para ler todo o processo foi de 3 horas e 45 minutos, conforme

O processo agiliza a criao de indicadores para a gerncia de requisitos. (CRC03) SIM

apresentado na questo 31 da Tabela 11. Tambm podemos utilizar como evidncia do atendimento desta caracterstica o fato da maioria dos avaliadores considerar possvel a criao de um indicador seguindo o processo (Questo 36 da Tabela 11).

112

Caracterstica
O processo apresenta caractersticas mnimas necessrias para a gerao de indicadores consistentes para a gerncia de requisitos. (CRC04)

Atendida
SIM

Evidncia
Essa caracterstica pode ser considerada atendida atravs da matriz de categorizao do processo de software de organizao de TI (Tabela 18 do APNDICE A). Nela so definidas as caractersticas mnimas para que a organizao crie indicadores na categoria de Entendimento, Controle e Aprimoramento. Essas caractersticas externalizam critrios necessrios que uma organizao deve possuir para que consiga criar seus indicadores de forma correta. Como evidncia quantitativa, pode-se utilizar as respostas 14 a 16 da Tabela 10, em que a maioria dos avaliadores considerou como simples o processo de Categorizao da Organizao de TI. Essa caracterstica pode ser considera atendida, pois o subprocesso Definir Foco dos Indicadores permite esse direcionamento. A matriz que possibilita o direcionamento

O processo permite que organizaes criem indicadores para a gerncia de requisitos com o foco em suas necessidades. (CRC05) SIM

dos indicadores de acordo com a dimenso foco (Tabela 19 do APNDICE A) permite que a organizao direcione a criao dos indicadores de acordo com as suas necessidades. Como evidncia quantitativa, pode-se utilizar as respostas da Questo 17 a 19 da Tabela 10, em que a maioria considerou o referido subprocesso e suas atividades como de fcil entendimento. Essa caracterstica pode ser considerada atendida, pois o PGIGR apresenta uma matriz com um conjunto de objetivos

O processo apresenta um conjunto prvio dos principais objetivos da gerncia de requisitos. (CRC06) SIM

que podem ser selecionados pelos usurios do processo. (Tabela 20 do APNDICE A). Como evidncia quantitativa, pode-se utilizar as respostas da Questo 20 a 22 da Tabela 10, em que a maioria considerou o referido subprocesso e suas atividades como de fcil entendimento.

O processo apresenta uma forma de rastrear um objetivo at os indicadores, facilitando assim a visibilidade e anlise de aferio de resultados. (CRC07) O processo apresenta sugestes de indicadores especficos para a gerncia de requisitos, visando facilitar a compreenso de seus usurios. (CRC08) SIM SIM

Conforme apresentado na matriz de indicadores (Tabela 22 do APNDICE A), cada indicador identificado de forma que possa ser rastreado o objetivo e a pergunta. Essa identificao permite uma correta rastreabilidade.

Conforme apresentado na matriz de indicadores (Tabela 22 do APNDICE A), so apresentados vrios indicadores para a gerncia de requisitos. Esses indicadores podem ser selecionados ou adaptados pelos usurios do processo.

113

Caracterstica

Atendida

Evidncia
Conforme apresentado na Tabela 23 do APNDICE A, o PGIGR apresenta um template que serve como guia para a

O processo apresenta template que possa ser utilizado para facilitar a criao de um indicador, apresentando todas as informaes necessrias. (CRC09) SIM

criao e detalhamento de um indicador. Para facilitar o seu entendimento, 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 APNDICE 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 no requerer que sua utilizao necessite de um especialista em mtricas (CRC10) SIM

Esta caracterstica foi atendida, conforme pode ser evidenciado na questo 35 da Tabela 11. A maioria dos avaliadores considerou que no seria necessrio um especialista em mtricas para utilizar o processo. Conforme pode ser visto na Figura 22 e Figura 24 do

O processo proporciona uma evoluo incremental no que tange a utilizao de indicadores para a gerncia de requisitos (CRC11) SIM

APNDICE A, o processo apresenta critrios objetivos para implantar de forma incremental novos indicadores. Essa evoluo est diretamente relacionada s necessidades da organizao e s caractersticas de seu processo de desenvolvimento de software.

Os resultados obtidos demonstram que somente uma das caractersticas no foi atendida em sua completude (CRC02). Isso demonstra que o processo atendeu de forma satisfatria os objetivos que foram inicialmente traados, conforme as evidncias apresentadas na Tabela 12. 4.7. Comparativo do PGIGR com os Demais Modelos de Criao de Indicadores e Anlise dos Principais Benefcios Obtidos A Tabela 13 a seguir apresenta um comparativo entre o PGIGR e os demais modelos de criao de indicadores utilizados no referencial terico deste trabalho, so eles: GQM, GQ(I)M e PSM. O objetivo da comparao apresentar os principais benefcios trazidos pelo PGIGR, quando contrastado com os demais modelos existentes. Como critrio de comparao foram utilizadas as caractersticas traadas para o PGIGR. Todas as respostas utilizadas na coluna do PGIGR foram baseadas nas respostas e comentrios dos avaliadores do processo, de acordo com as evidncias apresentadas na Tabela 12. J as respostas dos demais modelos foram embasadas na literatura pesquisada e nas caractersticas apresentadas no referencial terico deste trabalho.

114

Tabela 13 - Comparativo do PGIGR com os Demais Modelos de Criao de Indicadores Legenda: PAR Parcialmente

Processos/Modelos

Caractersticas do processo
O processo de fcil compreenso. (CRC01) O processo de fcil utilizao. (CRC02) O processo agiliza a criao de indicadores para a gerncia de requisitos. (CRC03) O processo apresenta caractersticas mnimas necessrias para a gerao de indicadores consistentes para a gerncia de requisitos. (CRC04) O processo permite que organizaes criem indicadores para a gerncia de requisitos com o foco em suas necessidades. (CRC05) O processo apresenta um conjunto prvio dos principais objetivos da gerncia de requisitos. (CRC06) O processo apresenta uma forma de rastrear um objetivo at os indicadores, facilitando assim a visibilidade e anlise de aferio de resultados. (CRC07) O processo apresenta sugestes de indicadores especficos para a gerncia de requisitos, visando facilitar a compreenso de seus usurios. (CRC08) O processo apresenta template que possa ser utilizado para facilitar a criao de um indicador, apresentando todas as informaes necessrias. (CRC09) O processo simples o suficiente ao ponto de no requerer que sua utilizao necessite de um especialista em mtricas (CRC10) O processo proporciona uma evoluo incremental no que tange a utilizao de indicadores para a gerncia de requisitos (CRC11)

PGIGR

GQM

PSM

GQ(I)M

SIM PAR SIM

SIM NO PAR

PAR NO PAR

SIM NO PAR

SIM

NO

NO

NO

SIM

PAR

PAR

PAR

SIM

NO

NO

NO

SIM

PAR

PAR

PAR

SIM

NO

NO

NO

SIM

NO

PAR

NO

SIM

NO

NO

NO

SIM

PAR

PAR

PAR

115

A tabela acima demonstra os benefcios trazidos pelo PGIGR, quando comparado com os demais modelos existentes na literatura. Como o PGIGR possui foco na gesto de requisitos, ele acaba se sobressaindo quando comparado com os demais modelos, principalmente pelo fato deles serem genricos. Um diferencial importante o fato de o PGIGR apresentar, no subprocesso de Categorizao do Processo de Software da Organizao de TI, critrios objetivos que avaliam a existncia de caractersticas importantes para uma correta gerao de indicadores para a gerncia de requisitos. Essas caractersticas so fontes de medidas bsicas e derivadas que so geradas a partir do processo de desenvolvimento de software. Isso acaba criando um importante diferencial, pois muitas organizaes que utilizam os demais processos acabam gerando indicadores ambguos ou incorretos devido ao fato de utilizarem fontes de dados inconsistentes, informaes inapropriadas ou simplesmente no estarem preparadas para ingressar em um processo de medio. O processo tambm guia a criao de indicadores com foco em necessidades prdefinidas: risco, tempo, custo e qualidade. Isso faz com que os usurios do processo possam focar a criao dos indicadores nas reas que so consideradas como prioritrias para a organizao. Por ser especfico para a gesto de requisitos, o processo j trs objetivos, perguntas e indicadores pr-definidos, o que agiliza, facilita e minimiza as chances de erro durante a criao de indicadores, uma vez que os modelos existentes deixam essas definies e decises a critrio dos usurios do processo. Por apresentar alta granularidade de detalhes, passos bem definidos e informaes prdefinidas, o processo foi considerado pelos avaliadores como simples de ser compreendido, no sendo necessrio ser um especialista em mtricas para compreend-lo. O PGIGR tambm se destaca por apresentar um template que contempla um conjunto bem completo de informaes para detalhar e manter um indicador, minimizando as chances de definio de um indicador inconsistente. O template tambm foi construdo de forma que possa guiar os usurios do processo durante o detalhamento do indicador. Os demais processos no apresentam templates, o que acarreta muitas vezes na definio de indicadores que so difceis de serem interpretados ou mantidos. Outro aspecto relevante o fato do PGIGR possibilitar uma evoluo gradual quanto a utilizao dos indicadores, baseando-se em critrios objetivos e importantes para uma correta gesto de requisitos. Isso permite determinar onde uma organizao se encontra e onde ela

116

pode chegar, de acordo com suas necessidades e expectativas no que tange a gesto de requisitos.

117

5. CONCLUSO
Vrias atividades foram realizadas no desenvolvimento desta pesquisa, com o objetivo principal de se criar um processo de gerao de indicadores para a gesto de requisitos PGIGR. Primeiramente foi feita uma ampla reviso da literatura para identificar as principais causas de fracasso em projetos de desenvolvimento de software. A partir da literatura pesquisada e apresentada no captulo de reviso bibliogrfica deste trabalho, a gerncia de requisitos foi selecionada como foco da pesquisa. A razo da gerncia 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 relatrio do Caos do Standish Group foi utilizado como principal referncia devido sua abrangncia e reconhecimento. Nele foram mapeadas as dez principais causas de fracasso em projetos de software em vrios pases, estando as trs principais causas diretamente relacionadas gesto de requisitos: falta de envolvimento dos usurios, requisitos incompletos e constante alterao nos requisitos. O histrico de falhas e a complexidade da gesto de projetos de desenvolvimento de software requerem que gerentes utilizem tcnicas de gesto quantitativa para que sejam aplicadas de forma a possibilitar uma melhor tomada de deciso e possibilitar maior previsibilidade para atender os objetivos traados. Indicadores podem promover a visibilidade de diversos aspectos relacionados s atividades de gesto de desenvolvimento. Uma vez contextualizada a necessidade e importncia da utilizao de mtricas e indicadores em projetos de desenvolvimento de software, foram analisados os principais modelos de gerao de mtricas e indicadores existentes na literatura. Foram identificados e detalhados os trs principais modelos: GQM, GQ(i)M e PSM. Cada um dos modelos foi analisado visando identificar suas caractersticas e eventuais limitaes. Os modelos para a definio de medidas e indicadores supracitados so genricos e muitas vezes necessitam que especialistas em mtricas ou pessoas com larga experincia estejam envolvidos para que interpretaes e adaptaes sejam feitas de forma correta para cada organizao, o que acaba dificultado para organizaes que no possuem esses profissionais. Tambm foram analisados trabalhos acadmicos que abordam aspectos relacionados gerao de medies e indicadores especificamente para a gerncia de requisitos. Alguns autores

118

pesquisados apresentam indicadores especficos para a gerncia 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 construo dos indicadores ou o contexto no qual os mesmos foram gerados ou aplicados, tornando-se muitas vezes difcil a sua replicao em outro contexto organizacional. O foco principal dos autores foi na validao dos indicadores propostos. Isso demonstra a necessidade da anlise de algumas caractersticas da organizao de TI antes que sejam definidos e utilizados indicadores. Para que organizaes possam criar indicadores consistentes, com maior facilidade e assertividade preciso um processo em que a gerao de indicadores tenha como foco a gesto de requisitos, trilhando assim um caminho que minimize as chances de erros na execuo do processo atravs do foco, clareza e facilidade para sua compreenso e utilizao. Um processo que apresente um conjunto de passos bem definidos para que diferentes organizaes de TI possam utiliz-lo de acordo com suas caractersticas e necessidades. Com esta motivao em mente, o objetivo desta pesquisa foi definir um processo de gerao de indicadores especficos para a gerncia de requisitos PGIGR, que permitisse a criao 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 especficos: i. Definir um conjunto de caractersticas desejadas para um processo de definio de indicadores para gesto de requisitos; ii. Elaborar um processo para criao de indicadores para gesto de requisitos, atendendo s caractersticas previamente traadas; iii. iv. Avaliar o processo proposto; Aprimorar o processo aps avaliao;

Aps anlise das pesquisas realizadas, para o objetivo (i) foi definido um conjunto de caractersticas desejadas para o PGIGR, conforme apresentado no Quadro 4. Essas caractersticas foram definidas a partir dos principais dificuldades e limitaes identificadas nos modelos avaliados, limitaes nos trabalhos acadmicos existentes e nas necessidades para uma correta gerao de indicadores para a gerncia de requisitos. A partir das caractersticas traadas para o processo PGIGR, o objetivo (ii) foi atendido atravs da criao do processo. Esta etapa do trabalho foi a que envolveu maior quantidade de esforo, pois foram consolidados conceitos apresentados pelo GQM, GQ(I)M e PSM; assim como tambm foram mapeadas as principais limitaes nos trabalhos apresentados por Hazan e

119

Loconsole, visando criar um processo mais completo e coeso, conforme apresentado no APNDICE A. Uma vez concluda a elaborao do processo, o objetivo (iii) encarregou-se de submet-lo a avaliao de profissionais da rea de desenvolvimento de software. A avaliao do processo foi feita atravs de questionrio, visando evidenciar se as caractersticas traadas originalmente para o processo, conforme apresentado no Quadro 4, foram ou no atendidas. Esta etapa foi bastante trabalhosa, porm a mais enriquecedora. Ela permitiu que o processo fosse avaliado por cinco profissionais com diferentes perfis, o que contribuiu para evidenciar o atendimento das caractersticas traadas para o processo, alm de ter gerado insumos para o aprimoramento do mesmo. Foi atravs dela que foi possvel ter uma viso mais realista a respeito das possibilidades de implantao do processo em um ambiente coorporativo, assim como evidenciar os principais benefcios e limitaes existentes no processo. Para avaliar o atendimento das caractersticas traadas para o processo PGIGR (Quadro 4), foram mapeadas as evidncias, atravs das respostas e comentrios 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 satisfatrios, pois das onze caractersticas traadas 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 forma satisfatria os objetivos que foram inicialmente traados. Uma vez concluda a avaliao do processo, o objetivo (iv) foi aprimor-lo a partir das sugestes e comentrios feitos pelos Avaliadores. Esta etapa da pesquisa foi muito importante, pois os feedbacks dos Avaliadores permitiram a identificao de pontos importantes de aprimoramento, o que possibilitou deixar o processo ainda mais alinhado s caractersticas previamente traadas no Quadro 4. Grande parte das crticas e sugestes feitas ajudaram a aprimorar principalmente aspectos relacionados ao seu entendimento e aplicabilidade. Este trabalho gerou as seguintes contribuies para a gesto de requisitos em projetos de desenvolvimento de software: Criou-se um processo para gerao de indicadores especficos para a gerncia de requisitos (PGIGR), rpido de ser compreendido, de fcil entendimento e factvel de ser implanto em diferentes organizaes. O processo proposto apresenta um nvel de detalhes que permite com que profissionais tpicos de desenvolvimento de software consigam entend-lo e utiliz-lo, no sendo necessrio ser um especialista na rea de mtricas. Isso acaba

120

evidenciando o atendimento da suposio previamente estabelecida para esta pesquisa. O processo proposto apresenta caractersticas mnimas necessrias que uma organizao deve possuir em seu processo de desenvolvimento de software para que possa ingressar, de forma gradual e eficiente, em um processo de definio de indicadores para a gerncia de requisitos. O processo proposto permite focar a gerao de indicadores para a gerncia de requisitos de acordo com as caractersticas e necessidades da organizao, minimizando as chances de definio de indicadores ambguos ou que no atendam as suas necessidades. O processo proposto apresenta objetivos, perguntas e indicadores pr-definidos e especficos para a gerncia de requisitos, possibilitando aos usurios do processo ter um ponto de partida. Isso faz com que organizaes consigam de forma mais rpida, objetiva e direcionada definir seus indicadores, o que minimiza as chances de erro durante a utilizao do processo. O processo proposto apresenta um template de indicador que pode ser utilizado para facilitar a criao e detalhamento dos indicadores, apresentando as informaes consideradas como necessrias para a sua correta criao e manuteno. apresentada uma forma simples de se manter uma rastreabilidade entre os objetivos, perguntas e indicadores, possibilitando assim avaliar o atendimento dos objetivos traados. O processo proporciona uma evoluo gradual e incremental no que tange a utilizao de indicadores para a gerncia de requisitos. Por fim, este trabalho procura auxiliar organizaes que no possuem muitos recursos ou profissionais especialistas em mtricas, ma que tm interesse em implantar prticas de medio em projetos de desenvolvimento de software. O PGIGR permite que organizaes implantem indicadores para a gerncia de requisitos de forma mais objetiva, pois um processo focado em requisitos, no necessitando de grande investimento de tempo para o seu entendimento ou adaptao. No entanto, entende-se que outros trabalhos podem ser realizados com as seguintes perspectivas de pesquisas futuras:

121

Aplicar o PGIGR em diferentes organizaes e mapear as principais dificuldades e ganhos obtidos. Verificar a possibilidade de criar novas categorias de classificao da organizao de TI. Aumentar a quantidade de indicadores propostos pelo processo. Avaliar a aplicabilidade do PGIGR em organizaes 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: implementao, gerncia de configurao, testes, etc.

122

REFERNCIAS BIBLIOGRFICAS

ARAJO, A. EDUARDO. Diretrizes para o estabelecimento de indicadores para aquisio de software. Monografia de Especializao. Universidade de So Paulo, p-12, 2004. BERANDER, P.; JNSSON, 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 eletrnico. Disponvel 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. Technical Report 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), 456473. 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). Gerncia 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. Disponvel 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 Project Management. Prentice Hall PTR Upper Saddle River, NJ, USA. FPNQ. Critrios de Excelncia: Planejamento do Sistema de Medio do Desempenho Global. Fundao para o Prmio Nacional da Qualidade, 2001. FPNQ. Critrios de Excelncia: O estado da arte da gesto para excelncia do desempenho. Fundao para o Prmio Nacional da Qualidade, www.fpnq.org.br, 2003. GARCA, 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 Using the 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 2025. 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), 405410. HAZAN, C. Metodologia para o Uso de Indicadores na Gerncia de Projetos de Desenvolvimento de Software. Tese de Mestrado, IME, Maio 1999. HAZAN, C., Introduo da Gerncia pela Qualidade Total em Organizaes de Desenvolvimento de Software. WQS, 1999. HAZAN, C., Implantao de um Processo de Medies de Software. CITS:QS, Junho 2001. HAZAN, C., Definio de Indicadores Utilizando o Modelo Practical Software Management (PSM). 2002 HAZAN, C., Indicadores para a Gerncia de Requisitos. Workshop em Engenharia de Requisitos, 2003. HOLANDA, A. B. Novo Dicionrio Aurlio da Lngua 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 Productivity Research (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. Gesto Estratgica e Avaliao do Desempenho. Qualitymark, 2002. KELVIN, L. Popular Lectures and Addresses, 1989 http://www-history.mcs.standrews.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, Maro - 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. 0411, 2000). ACM Press, New York, NY, 519. LEITE, J.C.S.P, Qualidade de Software: Teoria e Prtica, 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., Brstler 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, 2002 http://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. Administrao de Projetos: como transformar idias em resultados. 2. Edio. Atlas, So Paulo (SP), 2002.

128

MCGARRY, J.; et al. Practical Software Measurement: objective information for decision makers. 1. ed. Boston: Addison-Wesley, 2002. MONTEIRO, L. Definio de um Catlogo de Medidas para a Anlise de Desempenho de Processo de Software. Tese de Mestrado, UCB, 2008. MORESI, E. Metodologia da Pesquisa. Universidade Catlica De Braslia, 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, 1999 http://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), 4553. 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/SEI93-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 Practitioners Approach, Fifth Edition, McGraw Hill College, 2004

129

PSM. Practical Software Measurement. Disponvel 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 Administrao de Instituies Financeiras, traduo de Antnio Zoratto Sanvicente, So Paulo:Atlas, 2000. SEI Software Engineering Institute. Applications of the Indicator Template for Measurement and Analysis. Pittsburgh, PA, EUA 2004. Disponvel 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. Disponvel 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 - Associao para Promoo da Excelncia do Software Brasileiro. MPS.Br Melhoria de Processo do Software Brasileiro Guia Geral (Verso 1.2). Braslia, DF, 2007. Disponvel em: < http://www.softex.br/mpsbr/_guias/MPS.BR_Guia_Geral_V1.2.pdf>. Acesso em: 27/10/2008.

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. Disponvel 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 estabelecer metas e medir resultados, Qualitymark Editora, 1996. WIEGERS, K. Introduo a Mtricas de Software. Newsletter BFPUG www.bfpug.com.br, Janeiro 2001.

131

APNDICE A - PROCESSO DE GERAO DE INDICADORES PARA A GESTO DE REQUISITOS - PGIGR

Propsito do processo:

O propsito do processo sistematizar a gerao de indicadores para a gesto de requisitos de projetos de desenvolvimento de software. Essa sistematizao define todas as atividades necessrias para a execuo do PGIGR. A Tabela 14 demonstra uma sntese dos objetivos do PGIGR no formato do GQM1.
Tabela 14 - Objetivo do PGIGR formato GQM Analisar: Com o propsito de: Com respeito a: Do ponto de vista: No contexto: As atividades de gesto de requisitos Entender, controlar e aprimorar Qualidade, custo, tempo e risco Dos patrocinadores e gerentes de projetos Do desenvolvimento e manuteno 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.

GQM Goal Question Metric um tipo de abordagem para definio de indicadores.

132

Figura 21 - Subprocessos do PGIGR

A seguir feita uma breve descrio sobre cada um dos subprocesso. Cada um deles ser detalhado posteriormente. 1. Categorizar o Processo de Software Este subprocesso executado no incio do ciclo do processo. Ele tem como objetivo categorizar o processo de software da organizao de TI de acordo com caractersticas definidas como relevantes para uma correta gesto de indicadores de requisitos. Nesta etapa as caractersticas definidas visam classificar a organizao para se ter um correto direcionamento na definio de indicadores. Para isso o PGIGR prope quatro categorias de classificao: Inicial, Entendimento, Controle e Aprimoramento. Inicial: A organizao no possui os requisitos bsicos necessrios para se enquadrar na categoria Entendimento. Ela deve amadurecer alguns aspectos do seu processo de desenvolvimento de software antes de passar para a prxima categoria. Os aspectos que devem ser amadurecidos so detalhados

posteriormente.

133

Entendimento: Nesta categoria a organizao possui um conjunto uma organizao que permite a gerao de indicadores que daro maior visibilidade e entendimento da situao atual dos projetos de desenvolvimento de software da organizao no que tange a gesto de requisitos. Controle: Os indicadores gerados nesta categoria tm o intuito de serem utilizados durante a execuo do projeto, permitindo que o gerente tenha maior controle do projeto comparando os resultados obtidos com os resultados histricos, podendo assim tomar aes corretivas durante a execuo dos projetos. Aprimoramento: O objetivo da categoria Aprimoramento permitir que uma organizao avalie a evoluo da gesto de requisitos a partir dos aprimoramentos realizados no seu processo de desenvolvimento de software. Os indicadores gerados nesta categoria daro uma viso do comportamento do processo antes e depois das medidas de aprimoramento. Isso indica que esses indicadores devero ser avaliados aps a concluso dos projetos.

2. Definir Foco dos Indicadores Este subprocesso tem como objetivo definir o foco da organizao para a gerao de indicadores. As opes de foco propostas pelo PGIGR para serem selecionadas pela organizao visando direcionar a gerao de indicadores so: tempo, custo, qualidade e risco. A escolha de um foco visa direcionar os indicadores para aquilo que mais relevante para organizao. 3. Definir Objetivos (Metas) Este subprocesso visa definir os objetivos da organizao de TI no que tange a gerncia de requisitos, de acordo com a sua categorizao e dimenso foco previamente selecionadas. 4. Definir Perguntas Este subprocesso visa definir perguntas que estejam alinhadas com o atendimento dos objetivos previamente traados. Ao responder as perguntas deve ser possvel concluir se o objetivo foi ou no atingido.

134

5. Definir Indicadores Este subprocesso tem como objetivo definir indicadores que iro responder as perguntas. Ao interpretar os indicadores deve ser possvel avaliar se as perguntas foram respondidas e os objetivos alcanados. Para auxiliar na gerao de indicadores, o PGIGR apresenta um guia para construo e manuteno de indicadores.

O Aprimoramento do Processo de Software no um subprocesso do PGIGR, mas torna-se necessrio dentro do ciclo proposto pelo PGIGR, para que a organizao de TI possa evoluir entre as diferentes categorias propostas (Inicial, Entendimento, Controle e Aprimoramento), permitindo assim a gerao de indicadores mais robustos de acordo com a evoluo das necessidades da organizao.

Cada um dos subprocessos do PGIGR composto por um conjunto de atividades. Os subprocessos e suas atividades esto identificados na Tabela 15 e detalhadas no detalhadas no corpo do processo.

135

Tabela 15 - Subprocessos e Atividades do PGIGR

Processo PGIGR Subprocessos Definir os Envolvidos Categorizar o processo de software Definir Categoria da Organizao de TI Definir a Dimenso Foco para a gerao de Definir Foco dos Indicadores indicadores. Selecionar objetivos pr-definidos para Gesto Definir Objetivos (Metas) de Requisitos. Criar Objetivo(s) Selecionar perguntas pr-definidas Definir Perguntas (Questes) Criar Pergunta(s) Selecionar Indicadores pr-definidos Descrever o Indicador Definir Indicadores Estruturar o Indicador Divulgar/aprimorar o Indicador Atividades

As diferentes atividades listadas acima so executadas por diferentes papis. Os papis utilizados no PGIGR para executar cada uma das atividades, assim como suas principais atribuies, esto listados na Tabela 16 a seguir. Os papis apresentados foram extrados do RUP2. Os papis apresentados no implicam que a organizao necessariamente precisa ter indivduos especficos para exerc-los. Um papel pode ser exercido por um ou mais indivduos em um determinado perodo de tempo e um indivduo pode exercer mais de um papel. O importante que o indivduo ou grupo de indivduos que exera um determinado papel tenha as habilidades necessrias para executar as atividades que lhe foram atribudas. Na Tabela 16 so descritas as habilidades necessrias para cada papel.

RUP - Abreviao de Rational Unified Process (ou Processo Unificado da Rational, fornece tcnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade

136

Tabela 16 Definio de Papis e Habilidades necessrias para o PGIGR

Papel Gerente de Projetos Analista de Mtricas Engenheiro de Processo

Analista de Requisitos

Descrio de Habilidades Recomendadas Experincia em projetos de desenvolvimento de software. Boa comunicao escrita e verbal. Capacidade para anlise de riscos e tomada de decises. Liderana e construo de times. Boa comunicao escrita e verbal. Conhecer de forma satisfatria o negcio que abrange o sistema. Conhecer a tecnologia envolvida na soluo do sistema. Conhecimento bsico em processos e metodologias de mtricas e indicadores. Conhecimento de tcnicas de medio de tamanho de software. Conhecimentos aprofundados em engenharia de software. Adaptar processo de software de acordo com as necessidades da instituio. Apoiar a equipe de desenvolvimento no que tange a engenharia de software.

137

Descrio 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 Descrio Pr-atividade Critrio de Entrada Critrio de Sada Responsvel Participantes Produtos Requeridos Produtos Gerados Ps-atividade Identifica a atividade atravs de um nome Descreve a atividade Atividade que deve ser executada antes da atividade em questo Critrios necessrios a serem atendidos para que a atividade seja iniciada Critrios necessrios a serem atendidos para que a atividade seja considerada finalizada Quem responde pela execuo da atividade Quem so os envolvidos na execuo da atividade Relaciona os insumos necessrios para executar a atividade Relaciona os produtos que foram produzidos na execuo da atividade Relaciona a atividade que deve ser executada, aps esta ser finalizada

A estrutura de detalhamento de atividades baseada no processo MPS.Br Melhoria de Processo do Software Brasileiro Guia Geral (Verso 1.2).

138

Processo de Gerao de Indicadores para a Gesto de Requisitos (PGIGR)

Subprocesso: Categorizar o Processo de Software da Organizao de TI

1. Categorizar o processo de software da Organizao de TI

A P R I M O R A R P R O C E S S O D E S O F T W A R E

2. Definir Foco dos Indicadores

5. Definir Indicadores

3. Definir Objetivos (Metas)

4. Definir Perguntas

O propsito do subprocesso Categorizar o Processo de Software da Organizao de TI avaliar algumas caractersticas do processo de software da organizao visando classific-la. Neste subprocesso a organizao avalia a existncia de caractersticas definidas como relevantes pelo PGIGR para uma correta gerao de indicadores para a gesto de requisitos. O intuito final categorizar (classificar) a organizao.

O objetivo melhor direcionar a gerao de indicadores para a gesto de requisitos, de acordo com as caractersticas e necessidades atuais da organizao de TI. Para isso o PGIGR prope uma hierarquia contendo quatro categorias, conforme Figura 22

139

Figura 22 Categorias de Classificao do Processo de Software da Organizao de TI

Essa hierarquia demonstra que preciso, antes de definir indicadores para uma organizao de TI, categorizar (classificar) o seu processo de desenvolvimento de software de acordo com algumas caractersticas importantes para a definio e manuteno de indicadores de gesto de requisitos. Isso tem como objetivo evitar que organizaes definam indicadores que esto alm do que o seu processo atual e/ou infra-estrutura pode suportar.

Isso permitir um melhor entendimento do processo de desenvolvimento de software para ento direcionar a gerao de indicadores consistentes. Como exemplo, pode-se dizer que no adianta uma organizao querer definir indicadores para aprimorar o seu processo de gerncia de requisitos se ela no possui uma infra-estrutura necessria para tal. Isso provavelmente acarretaria na gerao de informaes ambguas e inconsistentes.

Os indicadores propostos na categoria Entendimento tm o intuito de dar uma visibilidade e maior entendimento da situao atual dos projetos de desenvolvimento de software da organizao no que tange a gesto de requisitos. J os indicadores propostos na categoria Controle tm o intuito de serem utilizados durante a execuo do projeto, permitindo que o gerente tenha maior controle do projeto e possa tomar medidas corretivas durante a execuo do

140

mesmo. Os indicadores propostos para a categoria Aprimoramento daro uma viso do comportamento do processo antes e depois das medidas de aprimoramento. Isso sugere que esses indicadores devero ser avaliados aps a concluso dos projetos. Este subprocesso composto por duas atividades: Definir os Envolvidos, e Definir categoria. Na Figura 23 apresentado o diagrama do subprocesso com as atividades, artefatos e responsabilidades.

Figura 23 - Subprocesso para Categorizar a Organizao de TI

A seguir segue o detalhamento das duas atividades contidas no subprocesso Categorizar o Processo de Software da Organizao de TI.

141

Atividade: Descrio:

Definir os Envolvidos O engenheiro de processo da organizao de TI (ou grupo de indivduos que esteja exercendo esse papel) faz uma reunio com os gerentes de projetos para definir o indivduo (ou indivduos) que ir categorizar o processo de desenvolvimento de software da organizao de TI. Observao: Caso o(s) gerente(s) e o grupo de melhoria de processos da organizao tenham conhecimento sobre o processo de software, eles mesmos podem realizar a categorizao da organizao.

Pr-atividade: Critrio de Entrada:

-Ter o patrocnio da organizao em investir esforos adicionais para gerar informaes com o intuito de aprimorar seus projetos no que tange a gerncia de requisitos. Identificao do(s) indivduo(s) que ir(o) categorizar o processo de desenvolvimento de software da organizao de TI. Engenheiro de Processo (EP) Engenheiro de Processo (EP) e Gerentes de Projetos (GP) -Responsvel(eis) pela categorizao da Organizao Definido(s) e divulgado. Email e Editor de textos. Definir Categoria

Critrio de Sada:

Responsvel: Participantes: Produtos Requeridos: Produtos Gerados: Ferramentas: Ps-atividade:

Atividade: Descrio:

Definir Categoria Categorizar o processo de desenvolvimento de software da organizao de TI utilizando a matriz contida na Tabela 18 a seguir. Uma vez feito isso necessrio que os envolvidos se renam e cheguem a um consenso em qual das quatro categorias se enquadra a organizao avaliada. de extrema importncia que essa classificao esteja correta, pois ela ir direcionar todos os demais passos do PGIGR.

142

Atividade: Pr-atividade: Critrio de Entrada: Critrio de Sada:

Definir Categoria Definir os envolvidos Ter os envolvidos na categorizao identificados Organizao categorizada (classificada) em um dos quatro nveis propostos (Inicial, Entendimento, Controle ou Aprimoramento). Responsvel(is) pela categorizao da organizao (RP) Responsvel(is) pela categorizao da organizao (RP) Matriz de Categorizao da Organizao de TI (Tabela 18) Organizao de TI categorizada em um dos quatro nveis: Inicial, Entendimento, Controle ou Aprimoramento. Email e Editor de textos. Definir Foco dos Indicadores

Responsvel: Participantes: Produtos Requeridos: Produtos Gerados:

Ferramentas: Ps-atividade:

143

Consideraes sobre a atividade Definir Categoria

Tabela 18 - Matriz de Categorizao do processo de software da Organizao de TI

CATEGORIZAR O PROCESSO DE SOFTWARE DA ORGANIZAO DE TI

1 - INICIAL A organizao no possui os requisitos necessrios para se enquadrar a categoria Entendimento

2 - ENTENDIMENTO A organizao possui prticas de gerncia de projetos de desenvolvimento de software; e A organizao possui ferramenta para controle de atividades dos projetos. (Ex.: Microsoft Project); e A organizao possui prticas de gerncia de requisitos; e A organizao utiliza prticas e ferramentas de controle de verso para os artefatos de requisitos; e A organizao possui prticas de medio de tamanho de software.

3 - CONTROLE A organizao possui uma base histrica de mtricas e indicadores; e A organizao possui um processo padronizado de gerncia de requisitos; e A organizao possui um processo padronizado de gerncia de projetos

4 - APRIMORAMENTO A organizao possui uma baseline de desempenho do processo de requisitos;

Caso a organizao no possua as caractersticas necessrias para ingressar na categoria Entendimento, sugere-se que ela primeiro adque os aspectos do seu processo de desenvolvimento de software antes de ingressar no processo, ficando, a princpio, na categoria Inicial, conforme representado na Figura 22 acima. Isso porque o PGIGR identificou um conjunto mnimo de organizao e infra-estrutura necessria para que os indicadores de requisitos possam ser gerados de forma consistente e, para isso, faz-se necessrio adequar o processo de desenvolvimento de software da organizao para atender as caractersticas propostas na categoria Entendimento.

Para que a organizao enquadre-se na categoria Entendimento importante que haja um consenso entre os envolvidos na avaliao de que todas as caractersticas esto presentes no processo de software da organizao. Caso alguma das caractersticas no seja constatada e a

144

organizao mesmo assim decida ingressar nessa categoria, ela corre o risco de: no conseguir gerar determinados indicadores, gerar informaes inconsistentes e despender um esforo muito grande para conseguir gerar e manter os indicadores. Para que isso no ocorra, o PGIGR sugere que a organizao fique na categoria Inicial at que o seu processo de software esteja de acordo com as caractersticas apresentadas na Tabela 18.

Vale ressaltar que o fato da organizao no possuir todas as caractersticas exigidas pela categoria Entendimento no significa que ela no conseguir utilizar alguns indicadores propostos. Talvez seja possvel gerar alguns indicadores, porm a organizao corre o risco de despender um esforo muito grande para ger-los e mant-los, alm de correr o risco de gerar informaes inconsistentes e ambguas.

Observaes: importante ressaltar que as caractersticas apresentadas na Matriz de Categorizao da Organizao Tabela 18 so acumulativas, isto , para que uma organizao passe de uma categoria para a outra necessrio que as caractersticas das categorias anteriores estejam todas presentes, caso contrrio, ela estar impossibilitada, ou ter dificuldades, em gerar os indicadores propostos nas categorias superiores.

Para se enquadrar na categoria de Controle importante que a organizao tenha um conjunto satisfatrio de dados histricos (repositrio de medidas 4) coletados na categoria de Entendimento. Dessa forma o PGIGR sugere que a organizao possua um conjunto mnimo de indicadores coletados de pelo menos trs projetos similares j concludos. O intuito que haja um conjunto de informaes para gerar dados comparativos entre projetos que apresentam semelhanas, visando gerar indicadores que permitam a tomada de aes corretivas durante a execuo dos projetos. Tambm necessrio ter um processo de gerncia de requisitos e de gerncia de projetos padronizados para que a coleta e comparao dos indicadores sejam feitas a partir de projetos que seguiram processos equivalentes.

Um repositrio de medidas para a organizao deve conter medidas dos processos e

produtos relacionados ao conjunto de processos padro da organizao, alm de informaes necessrias 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 gerncia de requisitos aps a implantao de melhorias no processo. Esses indicadores visam aferir se determinada ao corretiva no processo gerou ou no resultados positivos. Para que isso seja possvel sugerido que a organizao j tenha um conjunto de 20 medies de um determinado indicador (baseline) coletado na categoria de Controle. Os indicadores gerados nesta categoria daro uma viso do comportamento do processo antes e depois das medidas de aprimoramento. Isso indica que esses indicadores devero ser avaliados aps a concluso dos projetos.

Consideraes finais sobre o subprocesso Categorizar o Processo de Software da Organizao de TI importante que a organizao identifique com clareza onde ela se encontra, pois os demais passos do PGIGR dependem da correta classificao executada neste subprocesso. Uma falha de classificao pode acarretar na tentativa de gerar indicadores que esto alm da capacidade atual da organizao de TI, o que acarretaria na gerao de informaes inconsistentes.

Outra visualizao das etapas de categorizao do processo de desenvolvimento de software da organizao de TI pode ser feita atravs da Figura 24 a seguir.

146

Figura 24 - Viso Macro do Processo de Categorizao da Organizao de TI

As setas pontilhadas na figura acima demonstram que uma organizao pode ter vrios ciclos de definio de indicadores em uma mesma categoria, no sendo necessrio passar para categorias superiores para que novos indicadores sejam gerados. Porm vale lembrar que indicadores das categorias de Controle e Aprimoramento necessitam de dados histricos e de

147

certo grau de padronizao para que possam ser criados. Para isso so necessrios ajustes no processo de desenvolvimento de software da organizao.

Processo de Gerao de Indicadores para a Gesto de Requisitos (PGIGR)

1. Categorizar o processo de software da Organizao de TI

A P R I M O R A R P R O C E S S O D E S O F T W A R E

Subprocesso: Definir Foco dos Indicadores

2. Definir Foco dos Indicadores

5. Definir Indicadores

3. Definir Objetivos (Metas)

4. Definir Perguntas

Uma vez concluda a categorizao do processo de desenvolvimento de software da organizao de TI, necessrio definir qual o foco da gerao de indicadores para a gesto de requisitos. O PGIGR prope quatro focos, que foram denominados dimenses foco. Eles tem o intuito de direcionar a gerao de indicadores que a organizao considera mais relevantes, de acordo com seu contexto e necessidades. So eles:

1. 2. 3. 4.

Tempo Custo Qualidade Riscos O relacionamento entre as quatro dimenses focos pode ser visualizado conforme Figura

25.

148

Figura 25 - Quatro Dimenses Focos para a gerao de indicadores

Este subprocesso composto por uma atividade: Definir Dimenso Foco para Gerao de Indicadores. Na Figura 26 apresentado o diagrama do subprocesso com as atividades, artefatos e responsabilidades.

149

Figura 26 - Subprocesso para Definir Foco para Definio de Indicadores

A seguir detalhada a atividade contida no subprocesso Definir Dimenso Foco.

Atividade: Descrio:

Definir Dimenso Foco para a criao de Indicadores O engenheiro de processo da organizao de TI (ou grupo de indivduos que esteja exercendo esse papel), assim como o Analista de Requisitos e Gerentes de Projetos da organizao devem discutir em conjunto e priorizar as quatro dimenses foco (tempo, custo, qualidade e risco) de acordo com as principais necessidades identificadas na organizao de TI no que tange a gerncia de requisitos.

150

Atividade:

Definir Dimenso Foco para a criao de Indicadores sugerido, preferencialmente, escolher apenas uma das quatro dimenses foco, principalmente aquelas organizaes que foram classificadas em Entendimento. Esse direcionamento tem como objetivo principal no dispersar os esforos ou gerar inconsistncias na gerao das informaes e nas interpretaes das mesmas. A escolha de mais de uma dimenso foco, visando a gerao de indicadores, pode influenciar umas nas outras, o que pode dificultar na interpretao e nos resultados obtidos atravs dos indicadores. Sugere-se que, medida que a organizao vai amadurecendo no processo, ela, eventualmente, poder definir mais de uma dimenso foco por ciclo. Ao final desta atividade deve ser o foco da gerao dos indicadores definido. Para auxiliar nesta tarefa, o PGIGR sugere a utilizao da Matriz contendo as dimenses foco e descrio para cada uma das categorias (Tabela 19). Observao: As dimenses foco esto relacionadas umas s outras. Um exemplo disso um indicador de qualidade, que medida que for sendo utilizado na tomada de deciso, indiretamente pode impactar nos indicadores de risco, custo e tempo.

Pr-atividade: Critrio de Entrada:

Categorizao do processo de software da Organizao de TI. Ter o correto entendimento da classificao em que o processo de desenvolvimento de software da organizao de TI de acordo com os quatro categorias Consenso entre os envolvidos de que a dimenso foco selecionada a mais prioritria para a organizao naquele determinado momento. Engenheiro de Processo (EP) Engenheiro de Processo (EP), Analistas de Requisitos (AR) e Gerentes de Projetos (GP) Informaes de problemas e riscos enfrentados em projetos antigos (se existentes). Categorizao da organizao de TI. Matriz contendo as dimenses foco e descrio para cada uma das categorias.

Critrio de Sada:

Responsvel: Participantes: Produtos Requeridos:

151

Atividade: Produtos Gerados: Ferramentas: Ps-atividade:

Definir Dimenso Foco para a criao de Indicadores Dimenso foco selecionada Email e Editor de textos. Definir Objetivos (Metas) para a dimenso foco selecionada.

Consideraes sobre a atividade Definir Dimenso Foco para a criao de Indicadores O PGIGR prope que a organizao deve avaliar suas caractersticas, necessidades e questionar o que mais prioritrio para ela no que tange a gesto de requisitos, de acordo com sua categorizao previamente definida. Nesse sentido as dimenses foco devem ser avaliadas utilizando-se a Tabela 19.

Tabela 19 Matriz contendo as dimenses foco e descrio para cada uma das categorias Dimenso Foco

Categoria Entendimento

Descrio A organizao necessita melhor entender os riscos relacionados gerncia de requisitos nos projetos de software. A organizao necessita melhor monitorar os riscos relacionados gerncia de requisitos nos projetos de software. A organizao deseja minimizar os riscos relacionados gerncia de requisitos nos projetos de software. A organizao necessita melhor entender o tempo/esforo despendido nas atividades de requisitos em projetos de software. A organizao necessita melhor monitorar o tempo/esforo despendido nas atividades de requisitos em projetos de software. A organizao deseja reduzir o tempo/esforo despendido nas atividades de requisitos em projetos de software. A organizao necessita melhor entender os custos despendidos nas atividades de requisitos em projetos de software. A organizao necessita melhor monitorar os custos despendidos nas atividades de requisitos em projetos de software. A organizao deseja reduzir os custos despendidos nas atividades de requisitos em projetos de software. A organizao necessita melhor entender a qualidade dos produtos gerados pelas atividades de requisitos em projetos de software. A organizao necessita melhor monitorar a qualidade dos produtos gerados pelas atividades de requisitos em projetos de software. A organizao deseja aprimorar a qualidade dos produtos gerados pelas atividades de requisitos em projetos de software.

RISCO

Controle Aprimoramento Entendimento

TEMPO

Controle Aprimoramento Entendimento

CUSTO

Controle Aprimoramento

QUALIDADE

Entendimento Controle Aprimoramento

152

Processo de Gerao de Indicadores para a Gesto de Requisitos (PGIGR)

1. Categorizar o processo de software da Organizao de TI

Subprocesso: Definir Objetivos (Metas)

A P R I M O R A R P R O C E S S O D E S O F T W A R E

2. Definir Foco dos Indicadores

5. Definir Indicadores

3. Definir Objetivos (Metas)

4. Definir Perguntas

Uma vez definida a dimenso foco necessrio definir os objetivos (metas) para ela. Este subprocesso composto por duas atividades: Selecionar o(s) objetivo(s) pr-definidos para a Gerncia 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)

Legenda Definir Objetivos (Meta)

Papis:zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz GP Gerentes de Projetos AM Analista de Mtricas EP Engenheiro de Processo AR Analista de Requisitos

Dimenso Foco Definida

OBJ
GP AM EP AR

Selecionar Objetivo(s) pr-definido(s) para a Gesto de Requisitos

Artefatos: zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz MTO Matriz contendo os objetivos para cada categoria e dimenso foco OBJ - Objetivo(s) DMF - Dimenso Foco

MTO DMF Objetivo no selecionado OBJ

GP AM EP AR

Criar Objetivo(s)

Objetivo Selecionado

Smbolos Incio ou fim do processo Atividades do processo Papel Produto requerido Produto gerado

MTO

Objetivo(s) Definido(s)

Figura 27 Subprocesso para Definir Objetivos (Metas)

153

A seguir so detalhadas as duas atividades contidas no subprocesso Definir Objetivos. Atividade: Descrio: Selecionar objetivo(s) pr-definidos para a Gesto de Requisitos O engenheiro de processo da organizao de TI, assim como o analista de mtricas, gerentes de projetos e analistas de requisitos devem discutir a matriz contendo os objetivos pr-definidos pelo PGIGR (Tabela 20 a seguir). Deve-se analisar se os objetivos apresentados atendem s necessidades da organizao para a categoria e dimenso foco previamente definidos. A Figura 27 indica que, caso todos os objetivo almejados pela organizao estejam na matriz de Objetivos (metas) propostas pelo PGIGR na Tabela 20, deve-se pular a atividade Criar Objetivos. Se for necessrio definir ou refinar algum dos objetivos, deve-se seguir para a prxima atividade. Pr-atividade: Critrio de Entrada: Definir Dimenso Foco. Ter o processo de software da organizao categorizado Ter a dimenso foco selecionada. Critrio de Sada: Consenso entre os participantes de que os objetivo selecionado est aderente s necessidades da organizao e de acordo com a dimenso foco previamente selecionada. Analista de Mtricas (AM) Engenheiro de processo da organizao de TI (EP), analista de mtricas (AM), gerentes de projetos (GP) e analistas de requisitos (AR). Matriz contendo os objetivos para cada dimenso foco (Tabela 20). Lista contendo os objetivos traados pela organizao de TI para a gerncia de requisitos, de acordo com a dimenso foco selecionada. Email e Editor de textos. Criar Objetivo(s).

Responsvel: Participantes:

Produtos Requeridos: Produtos Gerados:

Ferramentas: Ps-atividade:

154

Consideraes sobre a atividade Selecionar os objetivos da Organizao de TI para a Gerncia de Requisitos O PGIGR apresenta uma matriz (Tabela 20 a seguir) onde cada uma das categorias (Entendimento, Controle e Aprimoramento) foi cruzada com cada uma das dimenses foco (Tempo, Custo, Qualidade e Risco). Para cada categoria/dimenso foco foi definido um objetivo, que a organizao pode selecionar.

Tabela 20 Matriz contendo sugestes de objetivos (metas) para cada categoria e dimenso foco

OBJETIVOS (Metas)
Categoria

Dimenso Foco

ENTENDIMENTO

CONTROLE Monitorar e controlar se o esforo e/ou prazo das atividades de requisitos esto dentro dos valores estipulados. (Meta T2) Monitorar e controlar se os custos das atividades de requisitos esto dentro dos valores estipulados. (Meta C2) Monitorar e controlar se a qualidade dos artefatos de requisitos est dentro dos valores estipulados. (Meta Q2) Monitorar e controlar os riscos relacionados ao gerenciamento dos requisitos (Meta R2)

APRIMORAMENTO

TEMPO (T)

Conhecer o esforo e/ou prazo necessrio para executar as atividades de requisitos. (Meta T1) Conhecer o custo despendido para executar as atividades de requisitos. (Meta C1) Conhecer a qualidade dos artefatos de requisitos. (Meta Q1) Entender os riscos relacionados ao gerenciamento de requisitos (Meta R1)

Reduzir o esforo e/ou prazo para executar as atividades de requisitos. (Meta T3)

CUSTO (C)

Reduzir os custos das atividades de requisitos. (Meta C3)

QUALIDADE (Q)

Aprimorar a qualidade dos artefatos de requisitos e minimizar retrabalho. (Meta Q3) Reduzir os riscos relacionados ao gerenciamento dos requisitos (Meta R3)

RISCO (R)

O contedo contido entre parnteses aps cada objetivo para permitir a correta identificao e posterior rastreabilidade entre os objetivos e os indicadores. Cada objetivo inicia com a primeira letra da dimenso foco e tem um seqencial numrico, de acordo com o quantitativo de objetivos criados para cada categoria/dimenso foco.

155

Atividade: Descrio:

Criar Objetivos Caso o objetivo traado pela organizao de TI no esteja presente na Tabela 20, o engenheiro de processo da organizao de TI, assim como o analista de mtricas, gerentes de projetos e analistas de requisitos, devem criar um ou mais objetivos, de acordo com as necessidades. Nesta atividade importante que o grupo faa um brainstorm de todos os objetivos que podem ser traados, de acordo com a categoria da organizao e dimenso foco previamente selecionados. importante que o grupo estabelea objetivos factveis de serem atingidos, de acordo com a categorizao da organizao e aderente dimenso foco previamente selecionada. Observao: Sugere-se que a organizao trabalhe com um conjunto limitado de objetivos, com o intuito de manter o foco.

Pr-atividade: Critrio de Entrada:

Selecionar os objetivos pr-definidos para a Gerncia de Requisitos Matriz contendo os objetivos para cada categoria e dimenso foco. Consenso entre os participantes de que os objetivos definidos esto claros e so factveis de serem atingidos pela organizao. Analista de Mtricas (AM) Engenheiro de processo da organizao de TI (EP), analista de mtricas (AM), gerentes de projetos (GP) e analistas de requisitos (AR). Matriz contendo os objetivos para cada categoria e dimenso foco. Lista contendo o(s) objetivo(s) da organizao de TI para a gerncia de requisitos, de acordo com a dimenso foco e categoria previamente definidas. Email e Editor de textos. Criar Perguntas.

Critrio de Sada:

Responsvel: Participantes:

Produtos Requeridos: Produtos Gerados:

Ferramentas: Ps-atividade:

156

Processo de Gerao de Indicadores para a Gerncia de Requisitos (PGIGR)

1. Categorizar o processo de software da Organizao de TI

A P R I M O R A R P R O C E S S O D E S O F T W A R E

Subprocesso: Definir Perguntas (Questes)

2. Definir Dimenso Foco

5. Definir Indicadores

3. Definir Objetivos (Metas)

4. Definir Perguntas

Uma vez definidos os objetivos (metas), devem ser definidas as perguntas que precisam ser respondidas para determinar se o objetivo foi ou no alcanado. 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 (Questes)

Legenda Definir Perguntas (Questes)

Papis:zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz GP Gerentes de Projetos AM Analista de mtricas AR Analista de Requisitos

Objetivos Definidos

PGT
AM GP AR

Selecionar pergunta(s) prdefinida(s)

Artefatos: zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz MTP Matriz contendo as perguntas para cada categoria e dimenso foco OBJ - Objetivo(s) PGT - Pergunta(s)

OBJ MTP Pergunta no selecionada PGT

GM GP AR

Criar Perguntas(s)

Pergunta Selecionada

Smbolos Incio ou fim do processo Atividades do processo Papel Produto requerido Produto gerado

MTP

Perguntas Definidas

Figura 28 - Subprocesso para Definir Perguntas (Questes)

A seguir so detalhadas as duas atividades contidas no subprocesso Definir Perguntas.

157

Atividade: Descrio:

Selecionar perguntas pr-definidas. O Analista de mtricas, gerentes de projetos e analistas de requisitos devem discutir em conjunto a matriz contendo as perguntas pr-definidas pelo PGIGR (Tabela 21 a seguir). Deve-se analisar se as perguntas esto alinhadas com os objetivos traados previamente e se atendem s necessidades da organizao de TI. A Figura 28 indica que caso a pergunta necessria para avaliar o atendimento do objetivo esteja na matriz de Perguntas proposta pelo PGIGR (Tabela 21), deve-se pular a atividade Criar Perguntas. importante ter em mente que atravs das respostas s perguntas que ser possvel definir se o objetivo foi ou no atingido, sendo as perguntas o elo de conexo entre os objetivos e indicadores. Se for necessrio definir ou refinar alguma das perguntas, deve-se seguir para a prxima atividade.

Pr-atividade: Critrio de Entrada:

Criar Objetivos. Ter os objetivos definidos.

Critrio de Sada:

Consenso entre os participantes de que as perguntas definidas esto aderentes aos objetivos traados e de acordo com a dimenso foco previamente selecionada. Analista de Mtricas (AM) Analista de Mtricas (AM), Gerentes de Projetos (GP) e Analistas de Requisitos (AR) Objetivo(s) definido(s). Matriz de Perguntas

Responsvel: Participantes: Produtos Requeridos:

Produtos Gerados:

Lista contendo todas as perguntas da organizao de TI para os objetivos traados, de acordo com a dimenso foco e categoria previamente definidos. Email e Editor de textos. Definir as Perguntas.

Ferramentas: Ps-atividade:

Consideraes 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 dimenses foco (Tempo, Custo, Qualidade e Risco). Para cada categoria/dimenso foco foram definidas perguntas que a organizao pode utilizar, adequar ou criar novas, conforme as suas necessidades. Cada pergunta deve estar necessariamente relacionada a um objetivo.

Tabela 21 - Matriz contendo sugesto de Perguntas (Questes) para cada categoria e dimenso foco

PERGUNTAS (Questes)
Categorias

Dimenso Foco

ENTENDIMENTO

CONTROLE O esforo ou produtividade das atividades de requisitos est de acordo com os valores (faixa) esperados? (T2.P1) Os custos das atividades de requisitos esto de acordo com os valores (faixas) esperados? (C2.P1) A qualidade dos artefatos de requisitos j concludos est dentro dos valores estimados de qualidade? (Q2.P1) Qual o ndice de retrabalho das atividades de requisitos? (Q2.P2)

APRIMORAMENTO

TEMPO (T)

Qual o esforo ou produtividade nas atividades de requisitos? (T1.P1)

O esforo e/ou produtividade das atividades de requisitos foi aprimorado aps aes de melhoria? (T3.P1) Os custos de execuo das atividades de requisitos foram reduzidos aps as aes de melhoria? (C3.P1)

CUSTO (C)

Quanto custa para levantar, analisar e documentar os requisitos? (C1.P1)

QUALIDADE (Q)

Qual a quantidade de defeitos nos artefatos de requisitos? (Q1.P1) Qual o custo de correo de defeitos nos artefatos de requisitos? (Q1.P2) Quais os principais riscos associados s atividades de requisitos? (R1.P1) Quais riscos associados s atividades de requisitos esto se concretizando durante o projeto? (R1.P2)

A densidade de defeitos nos artefatos de requisitos foi reduzida aps as aes de melhoria? (Q3.P1)

RISCO (R)

Os riscos do projeto, relacionados s atividades de requisitos, esto dentro das faixas estabelecidas no planejamento? (R2.P1)

Qual o ndice de aprimoramento das atividades da gerncia de requisitos aps implantao dos controles de risco em gerncia de requisitos? (R3.P1)

O contedo contido entre parnteses aps cada pergunta para permitir a identificao e rastreabilidade entre os objetivos traados anteriormente e as perguntas definidas. Cada pergunta inicia com a primeira letra da dimenso foco e tem um sequencial numrico, de acordo com o quantitativo de perguntas criadas. Para gerar um relacionamento entre cada objetivo (meta) e as

159

perguntas (questes), foi definido um padro 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: Descrio: Criar Perguntas Caso as perguntas necessrias para avaliar se o objetivo foi atendido no estejam presentes na Tabela 21, ou caso precisem de ajustes, o Analista de Mtricas, Gerentes de Projetos e Analistas de Requisitos da organizao de TI devem definir as perguntas necessrias para que essa verificao possa ser feita. importante que o grupo faa uma brainstorm para levantar todas as perguntas que precisam ser respondidas para aferir o atendimento dos objetivos. Deve-se estabelecer perguntas aderentes aos objetivos previamente definidos. Deve ser feita a rastreabilidade entre as perguntas elaboradas e os objetivos traados, relacionando cada pergunta ao seu objetivo, conforme demonstrado no contedo entre parnteses na Tabela 21. Cabe uma discusso entre o grupo para avaliar se todas as perguntas so factveis de serem respondidas e se esto aderentes aos objetivos e dimenso foco previamente definidos. Aquelas perguntas que no estiverem de acordo devem ser adequadas. Pr-atividade: Critrio de Entrada: Critrio de Sada: Selecionar perguntas pr-definidas Matriz contendo as perguntas para cada categoria e dimenso foco. Consenso entre os participantes de que as perguntas definidas esto claras, so factveis de serem respondidas e esto rastreadas at os objetivos. Analista de Mtricas (AM) Analista de Mtricas (AM), Gerentes de Projetos (GP) e Analistas de Requisitos (AR) Matriz contendo as perguntas para cada categoria e dimenso foco. Lista contendo a(s) perguntas da organizao de TI e a rastreabilidade das mesmas com os objetivos traados, de acordo com a dimenso foco selecionada e categoria da organizao. Email e Editor de textos. Definir Indicadores.

Responsvel: Participantes: Produtos Requeridos: Produtos Gerados:

Ferramentas: Ps-atividade:

160

Processo de Gerao de Indicadores para a Gerncia de Requisitos (PGIGR)

1. Categorizar o processo de software da Organizao de TI

A P R I M O R A R P R O C E S S O D E S O F T W A R E

Subprocesso: Definir Indicadores

2. Definir Dimenso Foco

5. Definir Indicadores

3. Definir Objetivos (Metas)

4. Definir Perguntas

Uma vez definidas as perguntas, devem ser definidos os indicadores que iro dar sustentao para que seja possvel respond-las. Este subprocesso tem como objetivo final definir e detalhar os indicadores necessrios para atendimento dos objetivos e perguntas estabelecidas previamente. Para isso sugere-se que todos indicadores sejam definidos seguindo a sequncia de estruturao sugerida no template proposto pelo PGIGR adiante (Tabela 23). Neste subprocesso o PGIGR mescla conceitos do GQM e PSM5 para definir a formao dos indicadores, que so compostos por cinco elementos:

6. Objetivo 7. Pergunta 8. Indicador 9. Medida derivada6 10. Medida bsica7 (ou base) O relacionamento e multiplicidade entre cada um dos cinco elementos acima pode ser melhor visualizado na Figura 29 a seguir.

5 6

O PSM (Practical Software Measurement) um modelo para a mensurao de projetos de software. Medidas Derivadas so valores resultantes de um algoritmo que combina uma ou mais medidas bsicas. 7 Medias Bsicas so insumos para as medidas derivadas. Um exemplo de medida bsica o somatrio de horas de trabalho de um analista.

161

Figura 29 - Relacionamento entre Objetivos, Perguntas, Indicadores, Medidas Derivadas e Medidas bsicas (base)

A figura acima mostra que a verificao do atendimento de um objetivo feita atravs de uma pergunta, que por sua vez respondida por um indicador. Um indicador formado por um conjunto de medidas derivadas, onde medidas derivadas so compostas de medidas bsicas (ou base). O exemplo mostrado na Figura 29 meramente ilustrativo, onde o objetivo mostrar os possveis relacionamento entre os objetos que compem 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 criao do indicador, conforme agrupador apresentado na Figura 30.

162

Figura 30 - Subprocesso para Definir Indicadores

A seguir so detalhadas as quatro atividades contidas no subprocesso Definir Indicadores.

163

Atividade: Descrio:

Selecionar Indicadores pr-definidos. O Analista de Mtricas, Gerentes de Projetos e Analistas de Requisitos devem discutir em conjunto a matriz contendo os indicadores propostos pelo PGIGR (Tabela 22 a seguir). Deve-se analisar se os indicadores esto alinhados com os objetivos, perguntas e se atendem as necessidades da organizao de TI. Caso os indicadores necessrios no sejam encontrados, o grupo pode criar novos indicadores medida que for necessrio. atravs dos indicadores que ser possvel responder as perguntas e consequentemente aferir se os objetivos foram ou no atingidos. Nesta atividade importante que o grupo faa uma brainstrom para identificar e gerar uma breve descrio de todos os indicadores que precisam ser gerados para responder as perguntas. Observao: O envolvimento participativo dos Analistas de Requisitos muito importante, pois eles precisam apontar eventuais dificuldades na coleta de informaes que compem a estrutura do indicador (medidas bsicas e derivadas). Eles tambm precisam estar convencidos de que este trabalho ir agregar na gerao de conhecimento a respeito da gerncia de requisitos, visando aprimor-la, caso contrrio possvel que informaes sejam coletadas de forma equivocada e gerem indicadores inconsistentes.

Pr-atividade: Critrio de Entrada:

Criar Perguntas. Ter a dimenso foco selecionada, os objetivos traados e perguntas definidas. Consenso entre os participantes de que os indicadores selecionados ou descritos esto aderentes aos objetivos, perguntas e dimenso foco previamente definidos. Analista de Mtricas (AM) Analista de Mtricas (AM), Gerentes de Projetos (GP) e Analistas de Requisitos (AR) Perguntas definidas. Matriz contendo os Indicadores para a Gerncia de Requisitos (Tabela 22)

Critrio de Sada:

Responsvel: Participantes: Produtos Requeridos:

Produtos Gerados:

Breve detalhamento dos indicadores necessrios para

164

Atividade:

Selecionar Indicadores pr-definidos. responder as perguntas levantadas, de acordo com os objetivos e dimenso foco selecionados. Exemplo: Custos
das Atividades de Requisitos = (Somatrio dos custos com atividades de requisitos) / (Tamanho do software)

Ferramentas: Ps-atividade:

Email e Editor de textos. Descrever o Indicador.

Consideraes 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 dimenses foco (Tempo, Custo, Qualidade e Risco). Para cada categoria/dimenso foco foram definidos indicadores que a organizao pode utilizar, adaptar ou criar novos, conforme as suas necessidades e caractersticas. Cada indicador deve estar necessariamente relacionado a pelo menos uma pergunta.

Tabela 22 - Matriz contendo os Indicadores Sugeridos para cada categoria e dimenso foco

INDICADORES SUGERIDOS
Categoria

Dimenso Foco

ENTENDIMENTO

CONTROLE

APRIMORAMENTO

TEMPO (T)

PAR Produtividade nas Atividades de Requisitos = (Somatrio de horas despendidas em atividades de requisitos) / (Tamanho do software) (T1.P1.I1)

PVE Percentual de Variao do Esforo = (Esforo realizado at o presente momento / Esforo Estimado) * 100 (T2.P1.I1)

IVP - ndice de Variao de Produtividade = (percentual do esforo gasto em atividades de requisitos por ponto de funo) / (mdia histrica de esforo por ponto de funo) * 100 (T3.P1.I1) IVC - ndice de Variao dos Custos = (percentual dos custos de requisitos por ponto de funo) / (mdia histrica dos custos por ponto

CUSTO (C)

CAR Custos das Atividades de Requisitos = (Somatrio dos custos com atividades de requisitos) / (Tamanho do software) (C1.P1.I1)

PVC - Percentual de Variao dos Custos = (Somatrio dos custos at o presente momento / Custos Estimados) * 100 (C2.P1.I1)

165

INDICADORES SUGERIDOS
Categoria

Dimenso Foco

ENTENDIMENTO

CONTROLE

APRIMORAMENTO
de funo) * 100 (C3.P1.I1)

QUALIDADE (Q)

RISCO (R)

QDR Quantidade de Defeitos em Requisitos = (Somatrio dos erros identificados em requisitos) / (Tamanho do Software) (Q1.P1.I1) CTD Custo Total de Defeito em Requisitos = (somatrio dos custos de correo de erros identificados em requisitos) / (Tamanho do software) (Q1.P1.I2) QRI Quantidade de Requisitos Incorporados ao escopo = (Quantidade de Requisitos aps o fechamento da linha de base) / (Quantidade de Requisitos ao final do projeto) *100. (R1.P1.I1) PPU - Percentual de Participao do Usurio = (nmero de reunies que representantes dos usurios participaram / nmero de reunies realizadas) * 100 (R1.P1.I2) PVR - Percentual de Validao de Requisitos pelo Cliente = (nmero de documentos de requisitos validados / nmero total de documentos de requisitos) * 100 (R1.P1.I3) PAR - Percentual de Alterao dos Requisitos j aprovados = (nmero de solicitaes de mudanas de requisitos / nmero total de requisitos j aprovados) * 100 (R1.P1.I4) PMT - Quantitativo de Mudanas nos Requisitos de acordo com o Tamanho do Software = (nmero de

PRR - Percentual de Requisitos Rejeitados = (percentual de requisitos rejeitados / percentual estimado de rejeio) *100 (Q2.P1.I1)

IVQ ndice de variao da qualidade = [(porcentagem de requisitos rejeitados por ponto de funo) / (porcentagem histrica de requisitos rejeitados por ponto de funo)] * 100 (Q3.P1.I1)

PSM - Percentual de solicitaes de mudana = (percentual de solicitaes de mudana de escopo / percentual estimado de alteraes no escopo) *100 (R2.P1.I1)

IVR - ndice de Variao de Risco = (porcentagem de requisitos concludos na release / porcentagem histrica de requisitos concludos) * 100 (R3.P1.I1)

166

INDICADORES SUGERIDOS
Categoria

Dimenso Foco

ENTENDIMENTO
requisitos alterados / Tamanho do Software) * 100 (R1.P1.I5)

CONTROLE

APRIMORAMENTO

O contedo contido entre parnteses aps cada indicador na Matriz de Indicadores para permitir sua identificao e rastreabilidade entre os objetivos, perguntas e indicadores. Cada objetivo inicia com a primeira letra da dimenso foco e tem um seqencial numrico, de acordo com o quantitativo de perguntas e indicadores criados. Para gerar um relacionamento entre cada objetivo (meta), perguntas (questes) e indicadores, foi definido um padro 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 so apenas sugestes e no abrangem todas as necessidades de todas as organizaes. Os indicadores sugeridos podem e devem ser adaptados de acordo com as necessidades e caractersticas de cada organizao de TI. No intuito de orientar a criao e detalhamento de um indicador, o PGIGR apresenta um template (Tabela 23) que serve como guia para a criao, detalhamento e manuteno 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 sequncia sugerida de preenchimento do mesmo.

167

Tabela 23 Exemplo do Template para Especificar Indicadores

TEMPLATE PARA ESPECIFICAO DE INDICADORES

1. Nome do Indicador Percentual e Variao dos Custos 4. Categoria Controlar 6. Objetivo/Meta Monitorar e Controlar se os custos das atividades de requisitos esto dentro dos valores estipulados. (Meta C2) 9. Unidades de Medida Porcentual (%)

2. Sigla PVC

3. Data da Reviso 20/07/2009

5. Dimenso Foco Custo (C) 7. Pergunta Os custos das atividades de requisitos esto de acordo com os valores (faixas) esperados? (C2.P1) 10. Periodicidade Aps a concluso de uma iterao ou fase ou projeto. O indicador de variao dos custos de requisitos afere o grau de assertividade entre os 8. Identificador

C2.P1.I1

11. Definio

custos despendidos e os custos estimados para as atividades de requisitos, visando identificar desvios. Esforo despendido nas atividades de requisitos Valor homem/hora Pontos de funo (ou pontos por caso de uso) CE = Custo Estimado (mdia histrica de custo da organizao de TI com a gerncia de requisitos por pontos de funo)

12. Medidas base

13. Medidas derivadas

CR = Custo Real (multiplicao das horas gastas em atividades de requisitos pelo valor homem/hora dos recursos envolvidos nas atividades, dividido pela quantidade de pontos de funo do software)

14. Frmula de clculo

PVC = (CR/CE) * 100

Cronograma do Projeto contendo as atividades de requisitos. O esforo real de trabalho 15. Sugesto de fonte de dados pode ser multiplicado pelo custo dos recursos e adicionado aos custos fixos do projeto (infra-estrutura, por exemplo). Ao planejar as atividades do cronograma, salvar uma linha de base do planejamento proposto e acordado. Uma vez feito isso, registrar a variao de esforo das atividades e 16. Mtodos de medio inserir novas atividades que venham a ser necessrias, representando todo o esforo de levantamento, anlise, documentao, validao e correo dos requisitos. CE = R$ 350,00 por ponto de funo 17. Exemplo CR = R$ 535,00 por ponto de funo PVC = (CR/CE) * 100

168

TEMPLATE PARA ESPECIFICAO DE INDICADORES

PVC = (535,00/350,00) * 100 PVC = 53% Quando interpretando o exemplo acima, vemos que se gastou 53% a mais com atividades de requisitos do que o estimado inicialmente pela organizao para cada ponto de funo.
600 500 400 300 Custo Real

Custo Estimado

18. Grfico:
200 100 0 jan/09 fev/09 mar/09 abr/09 mai/09

O resultado do indicador deve ser analisado nos marcos definidos no projeto (ex.: A cada fim de iterao ou fase ou projeto). Caso o resultado do indicador seja igual a 1, os custos despendidos com requisitos esto exatamente iguais aos custos mdios histricos. Caso o indicador seja maior que 1, os custos de requisitos foram acima do 19. Mtodo de anlise que os gastos mdios, caso contrrio (abaixo de 1), os custos foram abaixo do previsto. O indicador ir apresentar a variao para mais ou para menos em percentual. Caso o indicador esteja muito acima dos limites estipulados pela organizao, deve-se tomar aes corretivas. 20. Mtodo de melhoria ou uso 21. Referncias de comparao 22. Coleta de dados 23. Responsvel (eis) pela medio e anlise 24. Responsvel (eis) pela melhoria do uso 25. Armazenamento O indicador deve ser revisto a cada fim de projeto, visando a verificao de sua aderncia com os objetivos relacionados aos custos de requisitos. Projetos antigos similares Outras unidades da organizao Benchmark externo A coleta dos dados para o indicador inicia-se no comeo do projeto e depende, necessariamente, da identificao e coleta dos custos das atividades de requisitos. Gerente de projetos Grupo de mtricas Ferramenta de controle de atividades; e Ferramenta de controle de verso

169

TEMPLATE PARA ESPECIFICAO DE INDICADORES

Utilizao de ferramenta de controle de atividades onde possam ser definidas as atividades 26. Premissas: e custos das atividades de requisitos.

Repositrio contendo os custos mdios organizacionais para as atividades de requisitos por pontos de funo.

27. Divulgao das Informaes:

A divulgao do indicador dever ser feita pelo gerente de projetos atravs de relatrio disponibilizado na intranet e acessvel a todos os envolvidos no projeto.

As prximas trs atividades orientam como preencher cada um dos campos apresentados no template acima.

Atividade: Descrio:

Descrever o Indicador Esta atividade representa a primeira das trs subatividades de concepo de um indicador. Nela o grupo de mtricas, gerentes de projetos e analistas de requisitos da organizao de TI devem iniciar a concepo do indicador. Sugere-se que as atividades que compem a criao do indicador sejam feitas utilizando-se como referncia o template apresentado na Tabela 23. Para esta atividade os onze primeiros campos do template devero ser preenchidos. Esses campos tm o intuito de permitir a correta identificao e descrio do indicador. A seguir feita uma descrio das tarefas envolvidas para preenchimento de cada campo: 1. Nome do Indicador: Definir conjuntamente um nome para o indicador que seja claro, sucinto e que possa ser compreendido por terceiros. 2. Sigla: Definir uma abreviao para o nome do indicador. 3. Data de Reviso: A data de reviso dever ser preenchida na criao 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 categorizao do processo de software (Figura 23), e dever ser descrito neste campo.

170

Atividade:

Descrever o Indicador 5. Dimenso Foco: Neste ponto uma das quatro dimenses foco j ter sido definida no subprocesso de definio da dimenso foco (Figura 26), e dever ser descrito neste campo 6. Objetivo/Meta: Neste ponto um objetivo j ter sido definido no subprocesso de definio de objetivos (Figura 27), e dever ser descrito neste campo. 7. Pergunta (ou Questo): Neste ponto a pergunta que precisa ser respondida para avaliar o atendimento do objetivo traado j ter sido definida no subprocesso de definio de perguntas (Figura 28), e dever ser descrita neste campo. Ao responder a pergunta deve ser possvel concluir se o objetivo foi ou no atingido. 8. Identificador: O identificador do indicador visa

possibilitar a rastreabilidade entre objetivos, perguntas e indicadores. Sugere-se que seja utilizada uma letra e nmero para identificar cada objetivo, pergunta e indicador, conforme demonstrado na Tabela 22 contendo as sugestes de indicadores. 9. Unidade de Medida: Descrio da unidade de medida utilizada no indicador. Alguns exemplos de unidades de medida so: porcentagem, somatria, mdia, unidade de tempo, etc. 10. Periodicidade: Neste campo deve ser definida a periodicidade que o indicador dever ser gerado/reportado. Essa informao tem que ser acordada com os indivduos que iro utilizar (consumir) as informaes geradas pelo indicador. 11. Definio: Breve descrio a respeito do propsito do indicador. Essa descrio no deve entrar em detalhes a

171

Atividade:

Descrever o Indicador respeito da composio do indicador, devendo permitir que uma pessoa leiga compreenda a sua finalidade.

Pr-atividade: Critrio de Entrada:

Selecionar os indicadores pr-definidos Ter uma lista contendo uma breve descrio dos indicadores traados para os objetivos e perguntas previamente elencadas. Ter os onze primeiros campos do template de indicador preenchidos, possibilitando o seu entendimento e rastreabilidade. Analista de Mtricas (AM) Analista de Mtricas (AM), Gerentes de Projetos (GP) e Analistas de Requisitos (AR) Lista de Indicadores. Template para gerao de Indicadores.

Critrio de Sada:

Responsvel: Participantes: Produtos Requeridos:

Produtos Gerados: Ferramentas: Ps-atividade:

Indicador detalhado at o campo onze do template. (Tabela 23). Email e Editor de textos. Estruturar Indicador

Atividade: Descrio:

Estruturar o Indicador Esta atividade representa a segunda das trs subatividades de concepo do indicador. Nela devem ser descritos os campos de nmero doze at o dezenove do template de indicador (Tabela 23). Esses campos tm o intuito de detalhar a formao e estruturao do indicador. A seguir feita uma descrio das tarefas envolvidas para preenchimento de cada campo: 12. Medidas bsicas: Descrever as medidas bsicas que iro compor as medidas derivadas e posteriormente o indicador. Uma medio bsica funcionalmente independente de todas as outras medidas e captura informao sobre um nico atributo. Exemplos de medidas bsicas so: horas de trabalho e data prevista de trmino. 13. Medidas Derivadas: Descrever as medidas derivadas que

172

Atividade:

Estruturar o Indicador iro compor os indicadores. Medidas derivadas capturam informao de mais de uma medida bsica. Um exemplo de medida derivada o clculo de produtividade atravs da diviso do nmero de horas de esforo pela quantidade de pontos de funo gerados, onde o nmero de horas de esforo e a quantidade de pontos de funo so exemplos de medidas bsicas. 14. Frmula de Clculo: Definir o algoritmo que combina medidas bsicas e/ou derivadas para se criar o indicador. 15. Sugesto de fonte de dados: Descrever as fontes para coletar as medidas bsicas e/ou derivadas. (Exemplos: cronogramas, ferramenta de controle de verses) 16. Mtodo de Medio: Descrever os procedimentos de coleta das informaes necessrias para se criar o indicador. 17. Exemplo: Demonstrar como se gera o indicador,

representando as medidas bsicas, medidas derivadas e algoritmo utilizado para se chegar ao indicador. 18. Grfico: um display grfico do indicador conforme as caractersticas do indicador. O PGIGR apresenta algumas sugestes de grficos no Quadro 5 a seguir. 19. Mtodo de Anlise: Neste campo deve ser descrito como os resultados apresentados pelo indicador devero ser

interpretados. O mtodo de anlise tem que estar bem claro para os indivduos que iro utilizar as informaes geradas pelos indicadores para que no haja dvidas ou interpretaes equivocadas.

Pr-atividade: Critrio de Entrada:

Descrever o indicador Ter os onze primeiros campos do template de indicador preenchidos.

173

Atividade: Critrio de Sada:

Estruturar o Indicador Ter os dezenove primeiros campos do template de indicador preenchidos, possibilitando o seu entendimento, rastreabilidade e detalhamento da estrutura para gerao do indicador. Analista de Mtricas (AM) Analista de Mtricas (AM), Gerentes de Projetos (GP) e Analistas de Requisitos (AR) Lista prvia contendo breve descrio de Indicadores Template para gerao de Indicadores preenchido at o campo de nmero onze.

Responsvel: Participantes: Produtos Requeridos:

Produtos Gerados: Ferramentas: Ps-atividade:

Ao final da atividade o template de gerao de indicador tem que estar detalhado at o campo de nmero dezenove. Email e Editor de textos. Divulgar/aprimorar o indicador

Consideraes Finais Sobre a Atividade Estruturar o Indicador O Quadro 5 a seguir apresenta um conjunto de tipos de grficos que podem ser utilizados para melhor demonstrar graficamente as informaes geradas pelos indicadores (campo 18 do template).

Quadro 5 Exemplos de Grficos para Gerao de Indicadores Um histograma exibe os dados coletados do processo por freqncia. Os valores observados do processo so distribudos em determinados intervalos de mesmo tamanho (colunas). A Histograma altura das barras de um histograma
Histograma
6 5 4 3 2 1 0

proporcional ao nmero de observaes dentro do intervalo. Os histogramas so teis, pois permitem analisam a taxa de variao de um processo.

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

174

Da mesma forma que um histograma, um grfico de barras utilizado para investigar o

35,00

Defeitos x Disciplinas x Builds

Build 1 30,00
25,00

perfil de um processo. Porm, os grficos de Grfico de barras barras podem conter quaisquer valores, no somente freqncias 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 grfico. Um Diagrama de Pareto simplesmente a exibio de freqncias de determinado dado em ordem decrescente. Esta ferramenta pode utilizada para analisar

Build 2 Build 3
Build 4

20,00 15,00
10,00

5,00 -

diagrama de Pareto

priorizar as aes a serem tomadas no tratamento do processo. Diagramas de Pareto so conceitualmente relacionados com a Lei de Pareto, que defende que um nmero relativamente pequeno de causas responsvel pela produo da grande maioria dos problemas ou defeitos. Um grfico ou carta de execuo exibe observaes individuais de um processo no decorrer do tempo.

Densidade de defeitos

Grfico ou

as ocorrncias mais comuns de um evento e

0,350 0,300 0,250 0,200 0,150 0,100 0,050 -

Densidade de defeitos (Pareto)

0,325

0,055 0,046

0,014 0,010 0,009 0,003

100,00% 80,00% 60,00% 40,00% 20,00% 0,00%

IDC
0,600
0,500 0,400

Grfico ou carta de execuo

Esta ferramenta pode ser utilizada para identificar tendncias ou mudanas no

0,300 0,200

desempenho do processo. Um risco de utilizar simplesmente grficos de execuo a tendncia de reagir s variaes naturais do processo. Um grfico de controle basicamente um grfico de execuo com o acrscimo de uma linha central e limites de controle inferior e

0,100 0,000 nov/05 dez/05 jan/06 fev/06 mar/06 abr/06 mai/06 jun/06 jul/06 ago/06 set/06

IDC (X)
0,700 0,600 0,500 0,400

Grfico ou carta de controle

superior associados. Os limites de controle, definidos de acordo com cada tipo de grfico, permitem a organizao acompanhar o desempenho do processo e identificar as causas normais e especiais de variao.

0,300 0,200 0,100 0,000

nov/05 dez/05 jan/06 fev/06 mar/06 abr/06 mai/06 jun/06 jul/06 ago/06 set/06

IDC (X)
+ 1 sigma

LC
LCI (- 3 sigmas)

LCS (+3 sigmas)

- 2 sigmas

+ 2 sigmas
- 1 sigma

175

Atividade: Descrio:

Divulgar/aprimorar o indicador Esta atividade representa a terceira e ltima atividade que compe a concepo do indicador. Nela devem ser descritos os campos de nmero vinte at o vinte sete do template. Esses campos englobam informaes a respeito da divulgao das informaes geradas pelo indicador, assim como o seu aprimoramento e manuteno no decorrer do tempo. A seguir so descritas as tarefas envolvidas para preenchimento de cada campo: 20. Mtodo de Melhoria ou uso: Neste campo dever ser definida a periodicidade que o indicador dever ser revisto visando o seu aprimoramento. 21. Referncias de comparao: Neste campo devero ser definidas fontes de dados que podero ser utilizadas para comparar os dados gerados pelo indicador. Exemplos de fontes de comparao: projetos antigos, outras unidades da organizao e benchmark externo. 22. Coleta de dados: Descrever informaes a respeito de como, quando e com qual freqncia as medidas bsicas e derivadas requeridas para a construo do indicador devero ser coletadas. Esses dados so fundamentais para que as informaes geradas pelos indicadores estejam sempre atualizadas de acordo com as necessidades. 23. Responsvel (eis) pela Medio e Anlise: Definir o papel ou indivduo que ficar responsvel pelo indicador. 24. Responsvel (eis) pela melhoria do uso: Definir o papel ou indivduo que ficar responsvel por revisar/aprimorar o indicador. 25. Armazenamento: Definir onde as informaes

necessrias para compor o indicador sero armazenadas, visando segurar a integridade dos dados. 26. Premissas: Listar as premissas a respeito da organizao,

176

Atividade:

Divulgar/aprimorar o indicador seus processos e ferramentas que sejam relevantes para a coleta de dados e utilizao do indicador. 27. Divulgao das informaes: Definir o papel ou indivduo responsvel por divulgar as informaes geradas pelo indicador, assim como definir claramente os

stakeholders que necessitam receber as informaes geradas. Tambm importante definir o local onde as informaes sero publicadas (Ex.: E-mail, Intranet, apresentao PowerPoint, Internet). Uma vez o indicador detalhado atravs do preenchimento do template (Tabela 23), sugere-se que o mesmo seja submetido validao dos stakeholders que iro utilizar as informaes geradas. Isso possibilitar que eventuais falhas na estruturao do indicador sejam corrigidas e ir garantir o alinhamento entre os indicadores e objetivos organizacionais. Pr-atividade: Critrio de Entrada: Estruturar o Indicador Ter os dezenove primeiros campos do template de indicador (Tabela 23) preenchidos. Ter todos os campos do template preenchidos e a estrutura do indicador validada pelos stakeholders que iro utilizar os indicadores para tomar decises. Analista de Mtricas (AM) Analista de Mtricas (AM), Gerentes de Projetos (GP) e Analistas de Requisitos (AR) Lista prvia contendo breve descrio de Indicadores Template para gerao de indicadores preenchido at o campo dezenove. Produtos Gerados: Ferramentas: Ps-atividade: Detalhamento de todos os campos do template de definio de indicadores preenchidos e validados pelos stakeholders. Email e Editor de textos. --

Critrio de Sada:

Responsvel: Participantes: Produtos Requeridos:

177

Processo de Gerao de Indicadores para a Gerncia de Requisitos (PGIGR)

1. Categorizar o processo de software da Organizao de TI

Aprimorar o Processo de Desenvolvimento de Software

A P R I M O R A R P R O C E S S O D E S O F T W A R E

2. Definir Dimenso Foco

5. Definir Indicadores

3. Definir Objetivos (Metas)

4. Definir Perguntas

Conforme mencionado anteriormente, o Aprimoramento do Processo de Software no um subprocesso do PGIGR, mas torna-se elemento necessria dentro do ciclo proposto pelo PGIGR para que a organizao de TI possa evoluir entre as quatro categorias propostos (Inicial, Entendimento, Controle e Aprimoramento), permitindo assim a gerao de indicadores mais robustos ao longo do tempo. Esse aprimoramento est diretamente relacionado s caractersticas definidas na Tabela 18 - Matriz de Categorizao do processo de software da Organizao de TI. As iteraes entre o aprimoramento do processo de software e o processo de categorizao da organizao podem ser melhor visualizadas na Figura 24 apresentada anteriormente. importante ressaltar que a evoluo entre as diferentes categorias fica a critrio da organizao de TI. Sugere-se a evoluo entre as categorias de Entendimento, Controle e Aprimoramento de acordo com a evoluo das necessidades da organizao.

178

APNDICE B - EXEMPLOS DE INDICADORES DETALHADOS

Tabela 24 Detalhamento do Indicador de Horas Gastas em Atividades de Requisitos (EGR)

Detalhamento do Indicador de Esforo Gasto em Atividades de Requisitos (EGR)

1. Nome do Indicador 2. Sigla Esforo Gasto em Atividades de EGR Requisitos 4. Categoria Entendimento 6. Objetivo/Meta Conhecer o esforo e/ou 3. Data da Reviso 20/07/2009

5. Dimenso Foco Tempo (T) 7. Pergunta Qual o esforo e/ou produtividade nas atividades de requisitos? (T1.P1) 8. Identificador T1.P1.I1

produtividade para executar as atividades de requisitos. (Meta T1) 9. Unidades de Medida Somatrio 11. Definio

10. Periodicidade Aps a concluso de uma iterao, fase ou do projeto. O indicador serve para identificar o quantitativo de horas gastas com atividades relacionadas a requisitos de acordo com o tamanho do software. Somatrio de horas gastas em atividades de requisitos Pontos de funo ou pontos por caso de uso do software documentado SHG = Somatrio de horas gastas com atividades de requisitos TMS = Tamanho do software ou da parte do software que foi documentada pelas atividades de requisitos.

12. Medidas base

13. Medidas derivadas 14. Frmula de clculo 15. Sugesto de fonte de dados

EGR = (SHG/TMS) Cronograma do Projeto contendo as atividades de requisitos. O esforo registrado nas atividades de requisitos pode ser coletado do cronograma. O quantitativo de pontos de funo ou use case points pode ser definido a partir de caractersticas e documentao do software. Aps a concluso de uma iterao, fase ou do projeto, coletar do cronograma todo o esforo despendido em atividades relacionadas a requisitos. Deve ser feita uma contagem do software utilizando a tcnica de APF ou UCP para definir o tamanho do software documentado. SHG = 355 horas

16. Mtodos de medio

17. Exemplo

TMS = 36 pontos de funo EGR = (SHG/TMS)

179

Detalhamento do Indicador de Esforo Gasto em Atividades de Requisitos (EGR)

EGR = (355/36) EGR = 9,86 horas por ponto de funo Quando interpretando o exemplo acima, vemos que se gastou 9,86 horas em atividades de requisitos para cada ponto de funo do software.

18. Grfico:

O resultado do indicador deve ser analisado nos marcos definidos no projeto (ex.: A cada fim de iterao, fase ou do projeto). Como o objetivo na categoria Entendimento conhecer o esforo despendido em atividades de requisitos, a organizao deve armazenar os dados registrados para que faam 19. Mtodo de anlise parte de uma base histrica. Os mesmos podero ser comparados com novas iteraes ou fases do projeto, servindo como base de futuras comparaes e apoio ao planejamento. importante ressaltar que pode haver variao nos valores de acordo com a tecnologia e linguagem utilizada para codificar o sistema. O indicador deve ser revisto a cada fim de projeto visando a verificao de 20. Mtodo de melhoria ou uso sua aderncia com os objetivos relacionados aos esforos em atividades de requisitos. Iteraes mais antigas Projetos antigos similares Outras unidades da organizao Benchmark externo A coleta dos dados para o indicador inicia no comeo do projeto e depende, necessariamente, do planejamento das atividades de requisitos, assim como a coleta rotineira do esforo despendido com as atividades de requisitos. Tambm necessrio a mensurao do software documentado. Para isso

21. Referncias de comparao 22. Coleta de dados

180

Detalhamento do Indicador de Esforo Gasto em Atividades de Requisitos (EGR)

preciso descrever as funcionalidades do sistema e dar uma viso de escopo. 23. Responsvel (eis) pela medio e anlise 24. Responsvel (eis) pela melhoria do uso 25. Armazenamento Gerente de projetos

Analista de Mtricas Ferramenta de controle de atividades; e Ferramenta de controle de verso Utilizao de ferramenta de controle de atividades onde possa ser registrado o esforo gasto com as atividades de requisitos. Utilizao de tcnicas que possibilitem definir o tamanho do software (APF ou UCP so exemplos de tcnicas que podem ser utilizadas) Documentao das funcionalidades do software A divulgao do indicador dever ser feita pelo gerente de projetos atravs do site do projeto.

26. Premissas:

27. Divulgao das Informaes:

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 Custo Total de Defeitos Requisitos. 4. Categoria Entendimento 6. Objetivo/Meta 2. Sigla em CTD 3. Data da Reviso 20/07/2009

5. Dimenso Foco Qualidade (Q) 7. Pergunta 8. Identificado r Q1.P2.I2

Conhecer a qualidade dos artefatos Qual o custo de correo de defeitos nos de requisitos. (Meta Q1) 9. Unidades de Medida Somatrio 11. Definio artefatos de requisitos (Q1.P2)

10. Periodicidade Aps a concluso de uma iterao, fase ou do projeto. O indicador serve para identificar o custo de retrabalho em artefatos de requisitos de acordo com o tamanho do software. Somatrio de horas gastas em atividades de retrabalho em requisitos Custo homem/hora de cada indivduo que participou das atividades de correo dos artefatos Pontos de funo ou pontos por caso de uso do software documentado SHR = Somatrio de horas gastas com atividades de retrabalho em requisitos

12. Medidas base

13. Medidas derivadas

181

Detalhamento do Indicador de Custo Total de Defeitos em Requisitos (CTD)

CHH = Custo Homem-Hora dos recursos envolvidos nas atividades de correo dos requisitos TMS = Tamanho do software ou da parte do software que foi documentada pelas atividades de requisitos. 14. Frmula de clculo CTD = ((SHR*CHH)/TMS) Cronograma do Projeto contendo as atividades de requisitos. O esforo registrado nas atividades de retrabalho em requisitos pode ser coletado do cronograma. Cronograma do Projeto contendo o custo Homem-Hora de cada recurso do projeto. Esse custo tambm pode ser acrescido do custo de infra-estrutura. O quantitativo de pontos de funo ou use case points pode ser definido a partir de caractersticas e documentao do software. Aps a concluso de uma iterao, fase ou do projeto, coletar do cronograma todo o esforo despendido em atividades de retrabalho em atividades de requisitos, assim como o custo dos recursos envolvidos nas atividades. Deve ser feita uma contagem do software utilizando a tcnica de APF ou UCP para definir o tamanho do software documentado. SHR = 35 horas SHH = 50 reais custo homem-hora TMS = 23 pontos de funo CTD = ((SHR*CHH)/TMS) 17. Exemplo CTD = ((35*50)/23) CTD = R$ 76,08 por ponto de funo Quando interpretando o exemplo acima, vemos que se gastou 76,09 reais por ponto de funo somente em atividades de correo de defeitos em requisitos.

15. Sugesto de fonte de dados

16. Mtodos de medio

182

Detalhamento do Indicador de Custo Total de Defeitos em Requisitos (CTD)

18. Grfico:

O resultado do indicador deve ser analisado nos marcos definidos no projeto (ex.: A cada fim de iterao, fase ou do projeto). Como o objetivo na categoria Entendimento conhecer os custos de retrabalho em atividades de requisitos, a organizao deve armazenar os dados 19. Mtodo de anlise registrados para que faam parte de uma base histrica. Os mesmos podero ser comparados com novas iteraes ou fases do projeto, servindo como base de futuras comparaes e apoio ao planejamento. importante ressaltar que pode haver variao nos valores de acordo com a metodologia e linguagem de programao utilizada para codificar o sistema. O indicador deve ser revisto a cada fim de projeto, visando a verificao de 20. Mtodo de melhoria ou uso sua aderncia com os objetivos relacionados aos esforos em atividades de requisitos. Iteraes mais antigas Projetos antigos similares Outras unidades da organizao Benchmark externo A coleta dos dados para o indicador se da no incio do projeto e depende, necessariamente, de um marco para que seja salva a linha de base inicial, contendo um planejamento de atividades de requisitos, assim como a coleta rotineira do esforo despendido com as atividades e seus custos, de acordo com a alocao dos recursos em cada uma das atividades. Tambm necessrio a mensurao do software documentado, o que far necessrio a utilizao de documentos que descrevem as funcionalidades do sistema e dem uma viso de escopo. Gerente de projetos Analista de mtricas

21. Referncias de comparao

22. Coleta de dados

23. Responsvel (eis) pela medio e anlise 24. Responsvel (eis) pela melhoria do

183

Detalhamento do Indicador de Custo Total de Defeitos em Requisitos (CTD)

uso 25. Armazenamento Ferramenta de controle de atividades; e Ferramenta de controle de verso Utilizao de ferramenta de controle de atividades onde possa ser registrado o esforo gasto com as atividades de requisitos e os custos das mesmas. Utilizao de tcnicas que possibilitem definir o tamanho do software (APF ou UCP so exemplos de tcnicas que podem ser utilizadas) Controle das atividades de retrabalho A divulgao do indicador dever ser feita pelo gerente de projetos atravs de e-mail para todos os stakeholders envolvidos no projeto.

26. Premissas:

27. Divulgao das Informaes:

184

APNDICE C - QUESTIONRIO DE AVALIAO DO PROCESSO PGIGR

Quadro 6 - Questionrio de avaliao do PGIGR Legenda: PAR Parcialmente; NSI No Soube Informar

1 ETAPA Contextualizao a respeito de caractersticas do Avaliador e da Organizao de TI

1. Atualmente qual o cargo que voc ocupa na empresa onde trabalha? 2. Quantos anos de experincia voc possui em desenvolvimento de software? 3. Voc possui experincia prtica quanto a utilizao de medies e indicadores em desenvolvimento de software? 4. Voc acredita que a gesto de requisito um dos fundamentos mais crticos para o sucesso dos projetos na organizao onde trabalha? 5. A organizao onde trabalha enfrenta dificuldades no que tange a gesto de requisitos? 6. A organizao onde trabalha possui um processo para a gesto de requisitos? 7. A organizao onde trabalha possui prticas de gerncia de projetos? 8. A organizao onde trabalha possui ferramenta gerencial para controle de atividades de projetos? 9. A organizao onde trabalha possui ferramenta e processo para controle de versionamento dos artefatos de requisitos? 10. A organizao onde trabalha possui prticas de mensurao do tamanho de software? 11. Atualmente a organizao onde trabalha utiliza indicadores para gerenciar requisitos? 12. A organizao onde trabalha possui um processo de desenvolvimento de software? ( ) SIM ( ) PAR ( ) NO ( ) SIM ( ) NO ( ) NSI

( ) SIM

( ) PAR

( ) NO

( ) SIM

( ) PAR

( ) NO

( ) SIM

( ) PAR

( ) NO

( ) SIM

( ) PAR

( ) NO

( ) SIM

( ) PAR

( ) NO

( ) SIM

( ) PAR

( ) NO

( ) SIM

( ) PAR

( ) NO

( ) SIM

( ) PAR

( ) NO

2 ETAPA Avaliao do PGIGR

13. Em sua opinio, a parte introdutria do PGIGR, que apresenta uma viso geral do processo, de fcil entendimento? 13.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades encontradas. ( ) SIM ( ) PAR ( ) NO

Avaliao do Subprocesso Categorizar o Processo de Software da Organizao de TI

185

14. Em sua opinio, a introduo do subprocesso Categorizar o Processo de Software de fcil entendimento? 14.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades encontradas. 15. Em sua opinio, a atividade Definir Envolvidos de fcil entendimento? 15.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades encontradas. 16. Em sua opinio, a atividade Definir Categoria de fcil entendimento? 16.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades encontradas. Descreva nesse item eventuais observaes ou sugesto a respeito do subprocesso Categorizar o Processo de Software da Organizao de TI. Avaliao do Subprocesso Definir Dimenso Foco 17. Em sua opinio, a introduo do subprocesso Definir Dimenso Foco de fcil entendimento? 17.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades encontradas. 18. Em sua opinio, a atividade Priorizar Dimenso Foco de fcil entendimento? 18.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades encontradas. 19. Em sua opinio, a atividade Definir Dimenso Foco para a Gerao de Indicadores de fcil entendimento? 19.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades encontradas. Descreva nesse item eventuais observaes ou sugesto a respeito do subprocesso Definir Dimenso Foco. Avaliao do Subprocesso Definir Objetivos 20. Em sua opinio, a introduo do subprocesso Definir Objetivos de fcil entendimento? 20.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades encontradas. 21. Em sua opinio, a atividade Selecionar os Objetivos prdefinidos para Gerncia de Requisitos de fcil entendimento? 21.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades encontradas. 22. Em sua opinio, a atividade Criar Objetivos de fcil ( ) SIM ( ) PAR ( ) NO ( ) SIM ( ) PAR ( ) NO ( ) SIM ( ) PAR ( ) NO ( ) SIM ( ) PAR ( ) NO ( ) SIM ( ) PAR ( ) NO ( ) SIM ( ) PAR ( ) NO ( ) SIM ( ) PAR ( ) NO

( ) SIM

( ) PAR

( ) NO

( ) SIM

( ) PAR

( ) NO

186

entendimento? 22.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades encontradas. Descreva nesse item eventuais observaes ou sugesto a respeito do subprocesso Definir Objetivos. Avaliao do Subprocesso Definir Perguntas 23. Em sua opinio, a introduo do subprocesso Definir Perguntas de fcil entendimento? 23.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades encontradas. 24. Em sua opinio, a atividade Selecionar Perguntas Pr-Definidas de fcil entendimento? 24.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades encontradas. 25. Em sua opinio, a atividade Criar Perguntas de fcil entendimento? 25.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades encontradas. Descreva nesse item eventuais observaes ou sugesto a respeito do subprocesso Definir Perguntas. Avaliao do Subprocesso Definir Indicadores 26. Em sua opinio, a introduo do subprocesso Definir Indicadores de fcil entendimento? 26.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades encontradas. 27. Em sua opinio, a atividade Selecionar Indicadores PrDefinidos de fcil entendimento? 27.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades encontradas. 28. Em sua opinio, a atividade Descrever o Indicador de fcil entendimento? 28.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades encontradas. 29. Em sua opinio, a atividade Estruturar o Indicador de fcil entendimento? 29.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades encontradas. 30. Em sua opinio, a atividade Divulgar/Aprimorar o Indicador de fcil entendimento? 30.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades encontradas. Descreva nesse item eventuais observaes ou sugesto a respeito do subprocesso Definir Indicadores. ( ) SIM ( ) PAR ( ) NO ( ) SIM ( ) PAR ( ) NO ( ) SIM ( ) PAR ( ) NO ( ) SIM ( ) PAR ( ) NO ( ) SIM ( ) PAR ( ) NO ( ) SIM ( ) PAR ( ) NO ( ) SIM ( ) PAR ( ) NO ( ) SIM ( ) PAR ( ) NO

3 ETAPA Avaliao Final do PGIGR

187

31. Quanto tempo voc levou para avaliar o processo PGIGR?

32. Voc acredita que o PGIGR poderia ser aplicado na organizao onde trabalha? 32.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades. 33. Em sua opinio, qual o nvel de dificuldade para compreender o PGIGR? 34. Em sua opinio, qual o nvel de dificuldade para utilizar o PGIGR? 35. Voc acredita ser necessrio um especialista em mtricas para utilizar o PGIGR? 36. Voc conseguiria criar um indicador seguindo o processo? ( ) SIM 36.1. Se a resposta anterior for NO ou PARCIALMENTE, favor relatar as principais dificuldades encontradas. ( ) PAR ( ) NO ( ) SIM ( ) NO ( ) NSI ( ) Baixo ( ) Mdio ( ) Alto ( ) SIM ( ) PAR ( ) NO

( ) Baixo

( ) Mdio

( ) Alto