UM PROGRAMA DE MELHORIA DE ESTIMATIVAS EM UMA ORGANIZAO DESENVOLVEDORA DE SOFTWARE

Vitor Alcntara Batista

Orientador: Wilson de Pdua Paula Filho

Um programa de melhoria de estimativas em uma organizao desenvolvedora de software

Dissertao apresentada ao Departamento de Cincia da Computao do Instituto de Cincias Exatas da Universidade Federal de Minas Gerais como requisito parcial para a obteno do grau de Mestre em Cincia da Computao.

Belo Horizonte

Junho de 2009

V333p

Batista, Vitor Alcntara Um programa de melhoriaa de estimativas em uma organizao desenvolvedora de software / Vitor Alcntara Batista. Belo Horizonte, 2009. xviii, 112 f. : il. ; 29cm Dissertao (mestrado) Universidade Federal de Minas Gerais Orientador: Prof. Wilson de Pdua Paula Filho 1.Software - aplicao. 2. Software projetos 3. Sottware - Desenvolvimento. I. Orientador II Ttulo CDU519.6*32

vii

Dedico este trabalho minha famlia que sempre me apoiou nessa

empreitada.

viii

ix

Agradecimentos
Em primeiro lugar, minha esposa Natlia que foi a grande incentivadora e apoiadora deste trabalho. Agradeo tambm aos meus familiares, principalmente meu Pai e minha Me que me deram suporte nessa jornada. Ao meu grande orientador, o Prof. Wilson de Pdua, pelas excelentes contribuies e direcionamento que deu ao trabalho, alm dos rpidos retornos e revises. Ao Synergia, pela oportunidade de realizar um trabalho em uma organizao real, o que aumentou muito a contribuio que pude oferecer. Aos meus grandes amigos do Synergia, Daniela Cascini, Eduardo Pereira, Fabiana Trindade, Bruno Pimentel pela fora, revises e timas contribuies ao texto. Por fim, Pity, minha cachorra que fez companhia enquanto escrevia o texto pelas madrugadas a fora.

xi

Resumo
O crescente aumento no tamanho e complexidade dos produtos de software atualmente demandados, fora as organizaes desenvolvedoras a tambm melhorarem continuamente seus processos de gesto dos projetos. Nesse contexto, realizar boas estimativas crucial para um bom planejamento e respectivo sucesso dos projetos em termos do cumprimento de seus compromissos. O trabalho relatado aqui apresenta um programa de melhoria de estimativas realizado em uma organizao desenvolvedora de software. O programa foi executado dentro de um processo bem definido e abrange estimativas em todas as fases de seu processo de desenvolvimento. As melhorias de processo propostas utilizam mtodos baseados nas melhores prticas de estimativas relatadas na literatura e foram validadas em projetos piloto para, ento, serem incorporadas nos processos da organizao. Os resultados desse programa serviro como base para outras organizaes que desejam investir em melhoria de suas estimativas.

xii

xiii

Abstract
The constant growth in size and complexity of todays software products forces software development organizations to continuously improve their project management processes. In this context, performing good estimation is vital to good project planning and successful schedule and cost commitments. The work reported here presents an estimation improvement program, performed inside a software development organization. This program used a well defined process, covering estimation for all phases of the software development life-cycle. The improvements proposed in this work are based on best practices found in the literature, and were validated using pilot projects, before being incorporated in the organizations software development processes. The results of this program will hopefully be useful to other organizations interested in improving their estimation processes.

xiv

xv

Sumrio
INTRODUO ....................................................................................................................... 1 1.1 1.2 1.3 1.4 MOTIVAO ............................................................................................................. 2 OBJETIVOS DO TRABALHO ......................................................................................... 4 LIMITES DO TRABALHO ............................................................................................. 5 ORGANIZAO DESTE DOCUMENTO ........................................................................... 5

TRABALHOS RELACIONADOS .......................................................................................... 7 2.1 2.2 2.3 2.4 2.5 PROCESSOS DE MELHORIA ......................................................................................... 7 MTODOS DE ESTIMATIVA ......................................................................................... 9 INDICADORES DE ACURCIA ................................................................................... 11 MEDIDAS DE TAMANHO ........................................................................................... 13 CALIBRAO E VALIDAO DE MTODOS DE ESTIMATIVA ....................................... 14

O PROGRAMA DE MELHORIA DE ESTIMATIVAS ....................................................... 17 3.1 3.2 3.3 O PROMOTE ........................................................................................................... 17 O SYNERGIA ........................................................................................................... 20 A APLICAO DO PROMOTE NO SYNERGIA ............................................................. 22

RELATRIO DE DIAGNSTICO ...................................................................................... 24 4.1 4.2 ASPECTOS CONTEMPLADOS NO DIAGNSTICO .......................................................... 24 SITUAO ANTERIOR .............................................................................................. 25 4.2.1 4.2.2 4.2.3 4.2.4 4.3 Aspecto Processo e registro de informaes de propostas e oramentos ........ 25 Aspecto Registro e anlise de informaes de execuo de projetos............... 26 Aspecto Processo de planejamento macro (iteraes) dos projetos ................ 27 Aspecto Processo de estimativa para tarefas individuais nos projetos............ 27

SITUAO DESEJADA .............................................................................................. 28 4.3.1 4.3.2 4.3.3 4.3.4 Aspecto Processo e registro de informaes de propostas e oramentos ........ 28 Aspecto Registro e anlise de informaes de execuo de projetos............... 28 Aspecto Processo de planejamento macro (iteraes) dos projetos ................ 30 Aspecto Processo de estimativa para tarefas individuais nos projetos............ 30

4.4

AES PROPOSTAS .................................................................................................. 30

DESENVOLVIMENTO DAS AES .................................................................................. 32 5.1 O PROCESSO PARA ESTIMATIVA DE ORAMENTOS .................................................... 33

xvi

5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.2

O COCOMO II .............................................................................................. 33 Tamanho do produto ..................................................................................... 36 Calibrao e validao do COCOMO II ........................................................ 38 A adoo do COCOMO II na Organizao .................................................... 41 O processo de estimativa para oramento de projetos ................................... 43

O PROCESSO DE CONTAGEM DE PONTOS DE FUNO ................................................ 45 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 O modelo do problema .................................................................................. 46 Introduo contagem de pontos de funo do IFPUG ................................. 48 A contagem de pontos de funo a partir do modelo do problema .................. 50 A integrao com o cadastro de requisitos .................................................... 57 O processo de contagem de Pontos de funo de alterao ............................ 58

5.3 5.4 5.5

O PROCESSO DE PLANEJAMENTO MACRO DOS PROJETOS .......................................... 62 ESTIMATIVAS PARA O PLANEJAMENTO DETALHADO DAS ITERAES DE UM PROJETO 67 O REPOSITRIO CENTRALIZADO DE DADOS DOS PROJETOS ....................................... 70 5.5.1 5.5.2 Data Warehouses e a modelagem dimensional ............................................... 72 O modelo dimensional da Organizao ......................................................... 75

CONCLUSO ....................................................................................................................... 83 6.1 TRABALHOS FUTUROS ............................................................................................. 84

REFERNCIAS BIBLIOGRFICAS .................................................................................. 86 APNDICES .......................................................................................................................... 92 A.1 A.2 LISTA DE CONFERNCIA DE DEFINIO DE CONTAGEM DE LINHAS DE CDIGO ......... 92 DESCRIO DOS ATRIBUTOS DO REPOSITRIO CENTRALIZADO DE MEDIDAS DA

ORGANIZAO ....................................................................................................................... 95

xvii

Lista de figuras
Figura 1-1 - Dados do CHAOS Report do Standish Group. Adaptado de [McConnell, 2006] ........ 2 Figura 1-2 - O cone da incerteza. Adaptado de [Boehm et al., 2000]. ........................................... 3 Figura 2-1 - As fases do modelo IDEAL (adaptado de [Gremba & Myers, 1997]) ........................ 8 Figura 2-2 Produtividade de projetos de sistemas financeiros escritos em Visual Basic (ISBSG) ........................................................................................................................................... 15 Figura 3-1 - Organograma dos papis definidos no ProMOTe, extrado de seu manual. .............. 18 Figura 3-2 - Ciclo de vida de entrega evolutiva do Praxis 2.1. .................................................... 22 Figura 5-1 - Exemplo de vetor de dados utilizado na lista de conferncia de contagem de linhas de cdigo ................................................................................................................................ 36 Figura 5-2 - Configurao de vetor de dados da ferramenta de contagem de linhas de cdigo ..... 37 Figura 5-3 - Comparao do modelo cascata do COCOMO II com o Praxis-Synergia. ................ 39 Figura 5-4 - Planilha para anlise qualitativa de riscos das estimativas. ...................................... 43 Figura 5-5 - Processo para oramento de projetos. ..................................................................... 44 Figura 5-6 - Modelo do problema: viso de requisitos. Extrado do exemplo do Praxis 3.0 [Pdua, 2008] .................................................................................................................................. 47 Figura 5-7 - Realizao de um caso de uso por uma colaborao. Extrado do exemplo do Praxis 3.0. ..................................................................................................................................... 47 Figura 5-8 - Realizao de um fluxo de caso de uso. Extrado do exemplo do Praxis 3.0 ............ 48 Figura 5-9 - Procedimento de contagem de pontos de funo. Elaborado com base no manual do IFPUG. ............................................................................................................................... 49 Figura 5-10 - Esteretipos para contagem de funes de dados................................................... 51 Figura 5-11 - Exemplo de identificao de funes de dados em diagrama de classes. ................ 53 Figura 5-12 - Preenchimento das informaes de contagem de funo de dados no plugin. ......... 54 Figura 5-13 - Restrio OCL aplicada ao esteretipo utilizado na contagem de PF. .................... 55 Figura 5-14 - Esteretipos para contagem de funes de transao. ............................................ 56 Figura 5-15 - Mapeamento entre elementos do Modelo do Problema e Cadastro de Requisitos. .. 57 Figura 5-16 - Relatrio de contagem de PF gerado automaticamente. ......................................... 58 Figura 5-17 - Mquina de estados do sistema de gesto de alteraes existente. ......................... 59 Figura 5-18 - Exemplo de contagem de Pontos de funo de alterao. ...................................... 60 Figura 5-19 - Exemplo de contagem de PF de alterao pelo mtodo do NESMA. ...................... 62 Figura 5-20 - Planilha para apoio ao planejamento de tarefas de codificao de caso de uso ....... 68 Figura 5-21 - Comparao do erro total por caso de uso e da mdia dos erros. ............................ 69

xviii

Figura 5-22 - Componentes de um DW. Adaptado de [Kimball & Ross, 2002]. .......................... 73 Figura 5-23 - Exemplo de modelo dimensional para uma rede de lojas. ...................................... 74 Figura 5-24 - Fato Trabalho e Dimenses relacionadas............................................................... 79 Figura 5-25 Fatos de Tamanho (PF e LOC) e Dimenses relacionadas. ................................... 80 Figura 5-26 - Fato Defeito e Dimenses relacionadas. ................................................................ 80 Figura 5-27 - Fato Alterao e Dimenses relacionadas. ............................................................ 81 Figura 5-28 - Fato Progresso e Dimenses relacionadas. ............................................................ 81 Figura 5-29 - Distribuio de esforo de trabalho e retrabalho entre as Disciplinas ..................... 82 Figura 5-30 - Distribuio de esforo entre Disciplinas e Estados............................................... 82

xix

Lista de tabelas
Tabela 2-1 - Indicadores de acurcia ......................................................................................... 12 Tabela 3-1 - Descrio das fases do ProMOTe, extrado de seu manual. ..................................... 19 Tabela 4-1 - Aspectos considerados no diagnstico .................................................................... 25 Tabela 4-2 Aes propostas no Relatrio de Diagnstico ........................................................ 31 Tabela 5-1 - Valores dos nveis dos multiplicadores de esforos do modelo Post-Architecture ... 35 Tabela 5-2 - Exemplo de relatrio de contagem de linhas de cdigo ........................................... 38 Tabela 5-3 - Resultados da avaliao de estimativa de esforo do COCOMO II com o modelo padro ................................................................................................................................ 40 Tabela 5-4 - Resultados da avaliao de estimativa de esforo do COCOMO II com modelo calibrado ............................................................................................................................ 41 Tabela 5-5 - Resultados da avaliao de estimativa de prazo do COCOMO II com modelo calibrado ............................................................................................................................ 41 Tabela 5-6 - Detalhamento das atividades do processo de oramento proposto. .......................... 44 Tabela 5-7 - Pontos de funo de cada funo dada sua complexidade. Extrada do manual de contagem. ........................................................................................................................... 50 Tabela 5-8 - Atributos para contagem de funes de dados......................................................... 52 Tabela 5-9 - Clculo do fator de impacto para contagem de PF de alterao do mtodo NESMA.61 Tabela 5-10 - Exemplo de tabela utilizada no planejamento macro. ............................................ 63 Tabela 5-11 - Erros medidos no planejamento macro. ................................................................ 64 Tabela 5-12 - Exemplo de planejamento macro. Distribuio do esforo por iterao. ................ 65 Tabela 5-13 - Exemplo de planejamento macro. Distribuio de esforo por disciplina. ............. 66 Tabela 5-14 - Exemplo de distribuio de esforo por estado e por disciplina. ............................ 67 Tabela 5-15 - Coleta de dados para anlise de erros de estimativas realizadas pelos implementadores ................................................................................................................ 69 Tabela 5-16 - Melhora das estimativas dos implementadores. ..................................................... 70 Tabela 5-17 - Necessidades de informao da Organizao e indicadores propostos. .................. 75 Tabela 5-18 - Fatos identificados durante a modelagem dimensional. ......................................... 77

Captulo 1 Introduo

A indstria mundial de software, a cada dia que passa, depara-se com o desafio de construir produtos cada vez maiores, mais complexos e mais confiveis. Nesse cenrio, o papel de boas estimativas torna-se crucial para o sucesso nos negcios. Uma estimativa mal feita pode levar a organizao a prejuzos em seus projetos ou a perder boas oportunidades de negcio por apresentar propostas com valores muito altos. Alm do efeito negativo para a organizao prestadora do servio, os clientes tambm acabam prejudicados por verem seus projetos entregues fora do prazo ou, em casos mais graves, cancelados. Diversas pesquisas tm sido realizadas para acompanhar o resultado de projetos de desenvolvimento de software em relao ao cumprimento de suas metas. Entre elas, uma das mais conhecidas, o CHAOS Report, elaborado pelo Standish Group1 a cada dois anos. Nesse relatrio, ilustrado na Figura 1-1, podemos observar que a maior parte dos projetos de desenvolvimento de software sofreu algum atraso ou foram cancelados. Alm disso, a evoluo ao longo do tempo no mostra melhora significativa nesses resultados. Embora seja muito conhecido, o CHAOS Report tambm alvo de crticas, como discutido por Jrgensen e Molkken-stvold [Jrgensen & Molkken-stvold, 2006] que questionam a validade estatstica da amostra pesquisada. Um levantamento bibliogrfico realizado por Yang e outros [Yang et al., 2008] mostra nmeros no menos preocupantes. Segundo eles, entre 59% a 76% dos projetos apresentam esforo superior ao estimado e de 35% a 80% apresentam estouro do prazo. Alm disso, dentre os projetos com esforo superior ao estimado, o erro varia entre 18% a 41%, enquanto nos projetos com prazo superior ao estimado, o erro varia entre 22% a 25%.

http://www.standishgroup.com/

Figura 1-1 - Dados do CHAOS Report do Standish Group. Adaptado de [McConnell, 2006]

Diante desse panorama, uma organizao que consegue realizar boas estimativas em seus projetos ganha um diferencial competitivo em relao ao restante do mercado, pois ser capaz de oferecer servios com o compromisso do cumprimento de prazos sem incorrer em prejuzos financeiros. Alm do benefcio da competitividade no mercado, outros aspectos acabam sendo impactados positivamente dentro da organizao capaz de fazer boas estimativas, como por exemplo, como, o melhor planejamento e controle de seus projetos, desenvolvimento de produtos com melhor qualidade e menor presso sobre a sua equipe. Um estudo realizado por Nan e Harter [Nan & Harter, 2009] mostra os malefcios da presso por prazos e custos em projetos. Eles demonstraram um rpido crescimento do custo e prazo de execuo do projeto quando a presso excessiva.

1.1 Motivao
Embora estejam claros os benefcios de uma organizao realizar bo estimativas, essa boas uma tarefa rdua e complexa. Vrios de estudos foram realizados sobre o tema, mas ainda assim, parece estar longe de ser um problema bem resolvido. Laird especula em seu artigo The limitations of estimation [Laird, 2006] sobre possveis causas. Entre elas, o planejamento baseado na esperana, confuso entre metas e estimativas, requisitos incompletos e instveis e falta de treinamento dos responsveis pelas estimativas. , dedicado McConnell, em seu livro dedicado ao tema de estimativas em projetos de software [McConnell, 2006], tambm sugere algumas fontes dos erros de estimativas, como falta de

informao do projeto sendo estimado, falta de informao da organizao sobre sua prpria capacidade produtiva, incerteza no projeto (acertar um alvo que se move) e falta de acurcia no processo de estimativa em si. Como se pode observar acima, uma causa comum citada por ambos os autores a falta de informao (requisitos incompletos) sobre o projeto sendo estimado. Nessa mesma linha, Boehm, durante seus trabalhos com o COCOMO [Boehm et al., 2000] (um dos mtodos de estimativa mais conhecidos), props um conceito do Cone da incerteza, que mostra o erro potencial nas estimativas em relao fase em que um projeto se encontra. Na Figura 1-2, que ilustra o Cone da incerteza, possvel observar que a cada fase que avanamos no projeto, a incerteza das estimativas diminui. Durante a concepo inicial, por exemplo, h um potencial de erro de 400%.

10

4 2 1 ,5 1 ,2 5 1 ,1 1 1

Erro potencial das estimativas

0 ,6 7 0 ,5 0 ,2 5
0 ,1
C o n ce p o i n ic i a l A p ro va o da d e f i n i o d o p ro d u to R e q u is i t o s c o m p le t o s

0 ,8

0 ,9

De s e n h o d e in t e r f a c e s c o m p le t o

De s e n h o d e t a lh a d o c o m p le t o

P ro du to c o m p le t o

Fase do projeto

Figura 1-2 - O cone da incerteza. Adaptado de [Boehm et al., 2000].

Como veremos ao longo desse trabalho, no h um consenso sobre quais so os melhores mtodos de estimativa para cada situao, e cada organizao deve avaliar os mtodos disponveis e escolher os que melhor se adaptam sua realidade. Alm da dificuldade inerente na realizao de boas estimativas, as organizaes ainda devem lidar com a mudana de seus processos para aplicao dos mtodos avaliados e escolhidos. Mudanas de processos nas organizaes, por si s, j apresentam outro grande desafio e devem ser realizados dentro de um formato bem definido.

1.2 Objetivos do trabalho

O objetivo primrio desse trabalho realizar, dentro de uma organizao desenvolvedora de software, um programa para melhoria de suas estimativas em projetos de desenvolvimento de novos produtos de software. Ao longo deste texto ser mostrado como essas melhorias, que envolvem a mudana de processos da organizao, foram realizadas dentro de um processo bem definido. Antes de prosseguir, necessrio esclarecer os conceitos de projetos, programas e portflios. Segundo o Project Management Institute (PMI), um projeto um esforo temporrio empreendido para criar um produto, servio ou resultado exclusivo" [PMI, 2004]. Tipicamente, em empresas que seguem processos, um projeto uma instncia de uma execuo de um processo. Os programas so conjuntos de projetos relacionados entre si coordenados de maneira articulada, onde os objetivos de cada projeto contribuem para um objetivo maior em comum [PMI, 2008]. J os portflios so conjuntos de programas e/ou projetos que so agrupados de forma a facilitar o seu gerenciamento efetivo a fim de alcanar os objetivos estratgicos de uma organizao [PMI, 2008]. Neste trabalho, decidiu-se chamar o conjunto de aes de melhoria nas estimativas da organizao de um programa, pois j era notrio que seriam necessrios vrios projetos distintos, mas correlatos, para alcanar esse objetivo maior. Os motivos da escolha do termo ficaro mais claros no decorrer deste texto. O escopo do programa de melhoria envolve as estimativas realizadas em diversas fases do projeto: durante a concepo inicial do projeto, com o objetivo de elaborar um oramento que servir de base para confeco da proposta que ser apresentada aos clientes; aps a contratao do projeto, para estimar o perfil de equipe necessria e estabelecer os marcos do projeto em termos do seu escopo. Essa etapa denominada planejamento macro; no incio de cada iterao do projeto, para o planejamento detalhado da alocao dos colaboradores; nos replanejamentos do projeto, quando ocorrem alteraes ou problemas em seu escopo durante a execuo. Alm de propor melhorias nos processos da organizao, esse trabalho tem tambm o objetivo de executar projetos piloto com as propostas, com a finalidade de valid-las.

Embora o programa seja realizado em uma organizao especfica (da qual o autor deste trabalho colaborador), os resultados do programa podero servir como fonte de conhecimento para outras organizaes que tambm desejem melhorar suas estimativas, valendo-se dos mtodos propostos e das dificuldades encontradas.

1.3 Limites do trabalho

Assim como importante definir o escopo e objetivos de um trabalho, tambm importante explicar suas limitaes. Primeiramente, o programa de melhoria de estimativas a ser executado tem como alvo projetos de desenvolvimento de novos produtos de software. No sero contempladas melhorias nas estimativas de projetos de manuteno, evoluo, modelagem de negcio ou consultoria, que tambm so servios oferecidos na organizao do autor. Em segundo lugar, no esperado que os resultados alcanados sejam aplicveis a qualquer organizao. Cada empresa tem suas caractersticas e particularidades, e propor processos que tenham validade para todas elas invivel no estado atual do conhecimento. Entretanto, isso no impede que outras organizaes com caractersticas semelhantes, como por exemplo, as que possuem processo de desenvolvimento com mesma arquitetura de processo da organizao, no possam se valer dos resultados apresentados aqui. Mesmo organizaes com caractersticas bem diferentes podero aproveitar alguns mtodos propostos nesse trabalho ou, ainda, como realizar um programa de melhoria dentro de um processo bem estruturado.

1.4 Organizao deste documento

O restante deste trabalho est organizado na mesma seqncia de passos que o prprio programa de melhoria ocorreu. Em primeiro lugar, foi realizado um levantamento bibliogrfico sobre os temas relacionados a esse trabalho, que est resumido no Captulo 2. No Captulo 3 so apresentados o processo adotado para realizar o programa de melhoria, a organizao alvo do programa e como se deu esse processo.

O passo seguinte aps a escolha do processo para execuo das melhorias e sua iniciao foi a realizao de um diagnstico, que consistiu em identificar a situao atual, definir a situao desejada e apresentar propostas que levassem de uma situao a outra. Um resumo do relatrio desse diagnstico apresentado no Captulo 4. De posse das propostas de melhoria, cada uma foi executada dentro de um plano de ao que originou diversas modificaes nos processos da organizao. No Captulo 5 descrito como cada uma das aes ocorreu e apresentando um resumo das tcnicas avaliadas, sua aplicao e os resultados coletados nos projetos piloto. Finalmente, no Captulo 6, realizado um registro dos benefcios alcanados e dos trabalhos futuros.

Captulo 2 Trabalhos relacionados

Esse captulo apresenta uma reviso bibliogrfica dos diversos temas relacionados a este trabalho, incluindo publicaes com contribuies relevantes que serviram de base para o seu desenvolvimento. No o objetivo aqui explicar com detalhes o contedo desses trabalhos, pois isso ser feito nos captulos subseqentes onde eles foram usados. O restante desse captulo est organizado da seguinte forma: A seo 2.1 trata de processos de melhoria, utilizados para aprimorar os processos nas organizaes; A seo 2.2 apresenta um resumo e uma classificao de mtodos de estimativa em projetos de desenvolvimento de software; A seo 2.3 lista os indicadores de acurcia mais usados para avaliar qualidade de estimativas, discutindo as suas aplicaes; Na seo 2.4 apresentada uma discusso sobre medidas de tamanho de produtos de software; Por fim, na seo 2.5, a calibrao e validao dos mtodos so discutidas.

2.1 Processos de melhoria

A melhoria de processos em organizaes no uma tarefa simples e por isso deve ser planejada e executada com cuidado. A mudana dos processos envolve saber onde estamos e onde desejamos chegar, para a definir o como chegar. Toda a organizao deve ser envolvida nesse

processo e por isso fundamental o apoio da alta direo, para disponibilizar os recursos necessrios e motivar toda a equipe. Alm disso, a prpria mudana deve ser feita dentro de um processo prprio, com fases e papis bem definidos. Dentre as especificaes de processos de melhoria existentes, uma das mais conhecidas na indstria de software modelo IDEAL [Gremba & Myers, 1997] do Software Engineering Institute2 (SEI). O modelo fornece uma arquitetura de processo e orientaes para que as organizaes executem suas melhorias. Ele constitudo de 5 fases que do nome ao modelo: Iniciao, Diagnstico, Estabelecimento, Ao e Lies. A Figura 2-1 ilustra essas fases e suas etapas.

Figura 2-1 - As fases do modelo IDEAL (adaptado de [Gremba & Myers, 1997])

No entanto, o modelo IDEAL um processo abstrato, definido apenas em alto nvel. Ele no define, por exemplo, gabaritos e exemplos dos artefatos, como processos concretos o fazem. Cada organizao deve adequar a arquitetura proposta dentro de suas necessidades. Os prprios autores do modelo sugerem que atividades podem ser suprimidas ou executadas em paralelo dependendo dos recursos disponveis na organizao. O trabalho de Kautz [Kautz et al., 2000] mostra a aplicao com sucesso do modelo aps uma srie de adaptaes. O INTRo (IDEAL-Based New Technology Rollout)3 um exemplo de processo concreto

http://www.sei.cmu.edu/ http://www.sei.cmu.edu/intro/

baseado no modelo IDEAL e tambm proposto pelo SEI, em parceria com a Computer Associates4. Ele apresenta um elevado nvel de detalhamento, com artefatos, papis e exemplos bem documentados. O foco desse processo melhoria de tecnologias e ferramentas e no em processos especificamente. Outra instncia concreta do modelo IDEAL o ProMOTe (Processo de Melhoria de Organizaes Tcnicas), desenvolvido pelo Synergia (ver Captulo 3). Esse processo foi aplicado anteriormente para diagnstico dos problemas de uma organizao, como relatado no trabalho de Pdua e outros [Pdua et al., 2003]. Tambm baseado no modelo IDEAL, o Praxis 3.0 prope um processo subsidirio da disciplina de Engenharia de Processos que trata da Inovao Tcnica em organizaes [Pdua, 2008]. Um ponto importante de ressaltar que modelos de maturidade de processos, como o CMMI [CMMI, 2006], muitas vezes so chamados de processos de melhoria. No entanto, esses modelos fornecem apenas o o qu deve ser feito e no o como, como o caso do modelo IDEAL e suas instncias. Ento, o CMMI pode ser usado como referncia para as melhorias propostas na organizao, mas no para o processo de execuo das melhorias em si.

2.2 Mtodos de estimativa

Os mtodos de estimativa so alvo de pesquisas h algum tempo. Um levantamento bibliogrfico concludo em 2004 e publicado em 2007, com foco em peridicos de lngua inglesa cujo tema do trabalho era apenas de estimativa de esforo ou custo, identifica 304 estudos relevantes em 76 dos principais peridicos do mundo [Jorgensen & Shepperd, 2007]. Mesmo com centenas de trabalhos publicados com o objetivo de avaliar mtodos de estimativa, parece no haver uma convergncia quanto aos melhores mtodos para cada situao especfica. Como levantado por

Myrtveit e outros [Myrtveit et al., 2005], alguns resultados so contraditrios, onde um estudo mostra que o mtodo A melhor que B e outro mostra justamente o oposto. Os autores no afirmam o motivo da falta de convergncia, mas especulam que poderia ser em funo da falta de qualidade na execuo dos experimentos, pela falta de proficincia em um mtodo especfico o que levaria dois estudos sobre um mesmo mtodo obterem resultados diferentes e tambm pela falta de um

http://www.ca.com/us/

10

indicador realmente confivel para comparar os mtodos (esse ltimo ponto ser tratado na seo 2.3). Mesmo no havendo uma classificao oficial para os tipos de mtodos de estimativa, Myrtveit e outros [Myrtveit et al., 2005] propuseram uma taxonomia para classific-los. A diviso principal feita entre mtodos com dados esparsos (Sparce-data methods) e mtodos com muitos dados (Many-data methods), ou seja, entre mtodos que requerem poucos ou nenhum dado histrico e os que requerem muitos dados histricos. No primeiro grupo, encontram-se os baseados em julgamento de especialistas, como Wideband Delphi [Boehm, 1981] e RBC (Raciocnio Baseado em Casos) [Mukhopadhyay et al., 1992]. No segundo grupo, onde dados histricos so necessrios, encontram-se os mtodos de aproximao de funo arbitrria (AFA) e os baseados em funes matemticas. Os AFAs assumem que a relao entre as variveis de entrada (ex: tamanho, equipe, tipo de produto) e as variveis de resposta (ex: esforo, custo e prazo) no conhecida e, portanto, possuem forma arbitrria. As Redes Neurais Artificiais [Aggarwal et al., 2005] e Redes Neuro-fuzzy [Lopez-Martin et al., 2006] enquadram-se nesse grupo. No grupo dos mtodos baseados em funes matemticas, esto os que assumem uma relao conhecida entre as variveis de entrada e de resposta, tomando a forma de uma equao, como y=AxB, e so alvo de tcnicas de anlise de regresso. Representantes populares dessa categoria so o COCOMO [Boehm et al., 2000] e o modelo e Putnam [Putnam, 1978] (atualmente comercializado como uma ferramenta denominada SLIM). A classificao proposta acima no precisa. Como os prprios autores alertam, h uma interseo entre alguns mtodos. O RBC, por exemplo, pode ser considerado uma AFA. Alm disso, h mtodos que combinam com outros de mais de um grupo, como o trabalho de Ryder [Ryder, 1998], que combina a utilizao do COCOMO com o uso de redes neuro-fuzzy, embasado pela tese de que a escolha de alguns parmetros do modelo COCOMO mais bem representada por conjuntos nebulosos [Zadeh et al., 1977] que por faixas de valores. Dentre os tipos de mtodos citados acima, o estudo de Jrgensen e Shepperd [Jorgensen & Shepperd, 2007] mostra uma predominncia do interesse em funes matemticas e regresso (49%) dentre os 13 tipos identificados pela pesquisa. Vale notar que esse trabalho no classifica os tipos de mtodos na ontologia proposta por Myrtveit e outros.

11

2.3 Indicadores de Acurcia

Antes de iniciar a discusso sobre indicadores de acurcia fundamental definir o conceito de acurcia e de indicador. Acurcia, como definido em dicionrio da lngua portuguesa, trata da proximidade entre uma medida obtida experimentalmente e o seu valor real. No caso de estimativas, a acurcia mede a distncia entre a estimativa de alguma grandeza (ex: estimativa de esforo total de um projeto) e o valor real (ex: total de esforo ao final do projeto). O termo indicador se refere ao sumrio de vrias medidas, nos mesmos moldes das definies de medida e de indicador do Practical Software & System Measurement (PSM) [McGarry et al., 2001]. No caso de estimativas, um indicador tipicamente calculado pela mdia ou mediana de vrias medidas de acurcia. Alguns trabalhos relatam que o Mean Magnitude of Relative Error (MMRE) o indicador de acurcia mais utilizado para avaliao de mtodos de estimativa, como nos trabalhos de Myrtveit e outros [Myrtveit et al., 2005] e de Nguyen e outros [Nguyen et al., 2008]. Mesmo sendo o indicador mais utilizado em trabalhos de comparao ou validao de mtodos de estimativa, o prprio Myrtveit reconhece que o MMRE d resultados incorretos dependendo da amostra. Outro trabalho que corrobora com o de Myrtveit o de Foss e outros [Foss et al., 2003], que utiliza simulaes para mostrar que esse indicador leva a concluses incorretas. Ambos os trabalhos sugerem o uso de outros indicadores de acurcia alm do MMRE. Alguns desses indicadores e suas frmulas de clculo esto listados na Tabela 2-1, onde representa o valor estimado, y o valor real e n o nmero de medidas. Dos indicadores listados na Tabela 2-1, o RSD limitado a modelos onde h apenas uma varivel de predio, o que no o caso da maioria dos mtodos de estimativa citados na seo anterior. Outro indicador que aparece com muita frequncia nos estudos de acurcia de mtodos de estimativa o PRED(x) [Chen et al., 2005] [Clark et al., 1998], que mostra a porcentagem de medidas cujo MRE menor que x. Ele apropriado para aplicao da definio de McConnell [McConnell, 2006] para avaliar se uma organizao faz boas estimativas: errar em at 25% em 75% dos casos, ou seja, PRED(25%) 75%.

12

Tabela 2-1 - Indicadores de acurcia

Sigla do indicador

Nome indicador

Frmula de clculo

=
MMRE Mean Magnitude of Relative Error

= | |

=
MMER Mean Magnitude of Error Relative of estimate

= )

MBRE

Mean of the Balanced Relative Error

MIBRE

Mean of Inverted Balanced Relative Error

)0

)<0

SD

Standard Deviation

= =

1 (

)<0

)0

RSD

Relative Standard Deviation

onde xi o tamanho do projeto

Embora o MMRE e PRED sejam indicadores comumente usados para avaliar os mtodos de estimativa, Kitchenham e outros [Kitchenham et al., 2001] defendem que esses indicadores no

13

devem ser usados com o propsito de avaliar a acurcia de estimativas, mas sim para avaliar a adequao de um modelo aos pontos avaliados. A justificativa que estimativas devem ser dadas como distribuio de probabilidade no lugar de um valor, viso essa, compartilhada por McConnell [McConnell, 2006]. Considerando o fato de no desenvolvimento de software ser importante a organizao saber o sinal do erro da estimativa, ou seja, se ela foi subestimada ou superestimada, o Praxis 3.0 [Pdua, 2008] prope uma medida de acurcia da estimativa de um projeto dada pela frmula (y )/y, semelhante ao MRE, mas sem a operao mdulo. Variantes de alguns indicadores apresentados na Tabela 2-1 utilizam a mediana em vez da mdia, como no trabalho de Mendes e Mosley [Mendes & Mosley, 2008]. Triola explica que a mediana um indicador de centro preferencial para amostras muito espalhadas ou com muitos outliers [Triola, 2008].

2.4 Medidas de tamanho

O tamanho de um produto de software uma informao crucial para se estimar esforo, prazo e custos do projeto de seu desenvolvimento. Todos os mtodos de estimativa citados na seo 2.2 utilizam-no como entrada, mesmo que informalmente, como nos mtodos baseados em julgamento de especialistas. Isso acontece, obviamente, por acreditar-se que h alguma correlao entre o tamanho do produto e o esforo para desenvolv-lo. Medidas de tamanho podem ser classificadas em dois tipos: funcional e fsico [Pdua, 2008]. A primeira est relacionada com os requisitos funcionais do produto e a segunda com seu tamanho real aps a sua construo. Um bom retrospecto das medidas de tamanho funcional pode ser encontrado no trabalho de Gencel e Demirors [Gencel & Demirors, 2008], onde se destacam os pontos de funo e suas variaes e derivaes. Outra medida encontrada na literatura so os Pontos de caso de uso [Arnold & Pedross, 1998], mas trata-se de um mtodo ainda sem um padro bem definido e adotado amplamente [Pdua, 2008]. Quanto s medidas de tamanho fsico, a mais comumente utilizada a linha de cdigo. Ela pode ser expressa tanto em linhas fsicas quanto lgicas. A primeira, como o prprio nome diz, conta as linhas fsicas de um arquivo de cdigo-fonte de um produto e a segunda a quantidade de

14

instrues executveis desse mesmo arquivo. No h um padro nico que defina a forma de contagem dessas linhas, mas um relatrio tcnico apresentado pelo SEI [Park et al., 1992] detalha um framework para cada organizao definir seu processo de contagem, que faz extenso uso de listas de conferncia. Embora parea um contra-senso, no caso especfico de linhas de cdigo fsicas, Rosenberg [Rosenberg, 1997] mostra que a formatao (ou padro de codificao) irrelevante para a contagem, contando que sejam feitas comparaes que utilizem a mesma formatao.

2.5 Calibrao e validao de mtodos de estimativa

Os mtodos de estimativa que utilizam muitos dados histricos, como os AFAs e os baseados em equaes matemticas, devem utilizar preferencialmente dados da organizao onde um projeto est sendo estimado, aumentando assim a acurcia das estimativas [McConnell, 2006]. Uma possvel justificativa para isso a enorme diferena de produtividade entre organizaes, mesmo quando lidamos com projetos similares. Analisando o banco de dados do International Software Benchmarking Standards Group (ISBSG), verso 10, pode-se ver uma variao muito grande da produtividade expressa em pontos de funo(PF)/Pessoa-ms(PM) entre os projetos. A Figura 2-2, mostra o resumo estatstico da produtividade para projetos cujo tipo do produto sistema financeiro, a linguagem o Visual Basic e a qualidade da coleta dos dados foi declarada como Muito boa ou Boa. A escolha desses filtros foi feita de forma a obter um nmero razovel de projetos com dados confiveis que tivessem caractersticas semelhantes, para que a anlise tivesse alguma validade. Pode-se ver que mesmo em projetos semelhantes observamos uma variao grande da produtividade, onde a mdia da produtividade 23,8 PF/PM e no primeiro e terceiro quartis temos produtividade de 4,3 e 30,7 PF/PM respectivamente. Anda e outros [Anda et al., 2009] realizaram um estudo com quatro empresas desenvolvedoras de software que executaram um projeto para construir o mesmo produto. Nos resultados apresentados pelas organizaes pode-se notar no s uma grande variao nos resultados de esforo e prazo como tambm na qualidade. Curiosamente, a organizao que ofereceu o projeto pelo menor valor foi a que incorreu nos maiores estouros de custo e prazo, alm de apresentar a pior qualidade.

15

Produtividade em sistemas financeiros em VB

A nderson-D arling Normality Test A -S quared P -V alue < M ean S tD ev V ariance S kew ness Kurtosis N M inimum 1st Q uartile M edian 3rd Q uartile M aximum 13,271 7,420 25,845 3,54 0,005 23,867 31,781 1010,028 3,2314 13,0775 37 1,034 4,343 15,215 30,720 172,101 34,463 21,164 41,282

40

80

120

160

95% C onfidence Interv al for M ean 95% C onfidence Interv al for M edian

Intervalos de confiana de 95%

Mean

95% C onfidence Interv al for S tD ev

Median 10 15 20 25 30 35

Figura 2-2 Produtividade de projetos de sistemas financeiros escritos em Visual Basic (ISBSG)

Outros relatos de grande variao de produtividade podem ser encontrados nos trabalhos de Pdua [Pdua, 2007] e [Pdua, 2009], que mostra resultados em projetos executados em cursos de Especializao que utilizam mesma tecnologia e processo. A utilizao de dados histricos nos mtodos permite calibr-los, ajustando seus parmetros para melhor representar os projetos da organizao. Relatos da calibrao de modelos matemticos podem ser encontrados em [Clark et al., 1998] e [Barry et al., 2002]. A calibrao tipicamente envolve a utilizao de tcnicas de regresso para ajustar o modelo. No entanto, alguns autores vo alm, propondo formas diferentes de escolher os dados histricos a serem utilizados, como Chen e outros [Chen et al., 2005] que combinam a escolha dos projetos (estratificao) e de apenas alguns parmetros do COCOMO mostrando resultados melhores do que a calibrao convencional. Alm da calibrao com dados da prpria organizao, deve-se validar o modelo calibrado para ver seu grau de acurcia ao realizar estimativas. Entre os mtodos de validao, podemos citar: Holdout: separa-se o conjunto de dados histricos em 2 conjuntos disjuntos. O primeiro usado para calibrar o modelo e o segundo usado para avaliar os erros do modelo calibrado;

16

K-fold cross-validaton: tambm conhecido como v-fold cross-validation, os dados histricos so divididos em k conjuntos de tamanho n. Um dos conjuntos retido para validao e os demais k-1 so utilizados na calibrao. O procedimento repetido k vezes, escolhendo um conjunto diferente a cada iterao, para se computar a mdia dos erros, utilizando um dos indicadores da seo 2.3;

Leave-one-out cross validation: tambm conhecido como n-fold, uma variante do kfold onde os k conjuntos so de tamanho 1, ou seja a cada iterao, apenas 1 dado da amostra fica de fora do conjunto de calibrao.

Um estudo detalhado desses mtodos pode ser obtido em [Kohavi, 1995]. Pelo fato de que o mtodo Leave-one-out cross validation se parece mais com a situao real nas organizaes, quando temos um conjunto de dados histricos e queremos estimar o prximo projeto, Myrtveit e outros [Myrtveit et al., 2005] defendem seu uso na avaliao da calibrao. Acreditamos tambm que esse o melhor mtodo pelo fato dele exercitar todas as combinaes de conjuntos de calibrao e de validao possveis, ao passo que nos outros mtodos, dois ou mais projetos podem nunca ficar separados entre esses os conjuntos de calibrao e validao. Para exemplificar, suponha a utilizao do k-fold em um conjunto de 6 projetos (nomeados de A a F), com conjuntos de tamanho 2 (k=3, n=2). Os conjuntos seriam (AB) (CD) (EF). Assim, os projetos A e B estariam sempre juntos, ou no conjunto de calibrao ou no conjunto de validao, mas nunca separados entre os dois, o que poderia causar alguma distoro na avaliao da calibrao.

17

Captulo 3 O Programa de melhoria de estimativas

Esse trabalho optou pela utilizao do ProMOTe para melhoria dos processos de estimativa da Organizao alvo desse programa. O motivo a familiaridade da equipe com ele e a sua aplicao anterior com sucesso em outros projetos. Esse captulo apresenta sua estrutura, a organizao na qual ele foi utilizado e as personalizaes na sua aplicao. A seo 3.1 descreve o ProMOTe, suas fases, papis e artefatos; A seo 3.2 apresenta o Synergia, organizao alvo desse programa de melhoria de estimativas; A seo 3.3 detalha como ocorreu a execuo do ProMOTe dentro do Synergia, mostrando os papis (incluindo o do autor deste trabalho) e responsabilidades, a durao, entre outros detalhes.

3.1 O ProMOTe
O ProMOTe [Pdua et al., 2003], Processo para Melhoria de Organizaes Tcnicas, , como o prprio nome sugere, um processo de melhoria de processos. O ProMOTe foi elaborado no Synergia (ver seo 3.2) e baseado no modelo IDEAL, sendo constitudo nas mesmas 5 fases e define alguns papis a serem desempenhados dentro do programa de melhoria. Na Figura 3-1 h um organograma desses papis. O Comit Executivo o grupo formado pelas pessoas de maior poder de deciso, representa o nvel hierrquico e estratgico mais alto da organizao. responsvel pelas decises

18

estratgicas da organizao. O Grupo Diretor o responsvel pela coordenao das atividades do programa de melhoria, pela gesto da infra-estrutura que ir facilitar e permitir a sua execuo, pela manuteno da motivao e entusiasmo de todos os nveis da organizao e pela definio das informaes que devem ser divulgadas sobre o programa. Alm disso, detalha as metas e objetivos do programa; direciona e prioriza as atividades; fornece diretrizes e aes corretivas, quando necessrio, para manter o programa em sintonia com a misso e viso da organizao. Os artefatos produzidos durante o programa de melhoria devem ser aprovados pelo Grupo Diretor.

Figura 3-1 - Organograma dos papis definidos no ProMOTe, extrado de seu manual.

A responsabilidade pelo planejamento e controle do programa do Grupo Gestor. Tambm responsvel pela criao dos Grupos Tcnicos, alm de dar suporte e aprovar o trabalho destes grupos. Outra responsabilidade desse grupo a criao, caso necessrio, de equipes de avaliao para caracterizar o estado atual de determinados aspectos da organizao. O Grupo de Suporte ao Programa mantm o apoio ao programa de melhoria em um ambiente de mudanas, norteando e sustentando as atividades de melhoria individuais. Esse grupo no o responsvel pela implantao da melhoria e sim um facilitador das atividades, ajudando em qualquer dificuldade encontrada no projeto. Os Grupos Tcnicos so os responsveis pelo desenvolvimento das solues para o programa. Para isso, seus membros devem ser pessoas que integram as equipes de trabalho que utilizam, rotineiramente, o objeto alvo da melhoria, tendo bastante conhecimento sobre os pontos

19

fortes a serem mantidos e os pontos fracos a serem melhorados. A Equipe de Explorao um grupo transitrio - s existe durante as primeiras atividades do programa. Uma vez que a execuo da fase de Incio tenha sido aprovada, os demais grupos do programa (Diretor, Gestor e Suporte) devem ser formados e a Equipe de Explorao imediatamente desfeita. Os Outros Grupos de Suporte e a Equipe de Avaliao so grupos temporrios e opcionais durante o programa. A Equipe de Avaliao criada durante o Diagnstico, caso o Grupo Gestor detecte a necessidade de formar grupos especficos para diagnosticar a situao atual de determinados aspectos. A Tabela 3-1 abaixo descreve de forma resumida as atividades executadas em cada uma das 5 fases do processo, a responsabilidade de cada papel definido acima e os artefatos produzidos.

Tabela 3-1 - Descrio das fases do ProMOTe, extrado de seu manual.

Fase

Descrio A fase de Incio deixa claras as necessidades da organizao, os benefcios e o escopo do programa, alm de estabelecer a infra-estrutura necessria para continuidade do programa. Nele so recrutadas as pessoas que iro compor o Grupo Gestor e o Grupo Diretor, definindo seus papis e responsabilidades. Nessa fase, devem ser definidas as metas da organizao, em termos de prazos e custos para o

Incio

programa de melhoria, sendo feito um planejamento em alto nvel das prximas fases. As atividades da fase de Incio so crticas e, se forem bem executadas, podem garantir o prosseguimento das atividades subseqentes com menos dificuldades. Os principais artefatos confeccionados na fase de Incio so a Descrio do Programa (DP) e o Plano do Programa (PP). No fim dessa fase, a continuidade do programa de melhoria deve ser aprovada pelo Comit Executivo. Caso contrrio, o programa ser cancelado. O objetivo da fase de Diagnstico obter um entendimento mais detalhado do programa de melhoria. Para isso, deve ser realizada uma caracterizao do estado atual e desejado da organizao, atravs de

Diagnstico

atividades de avaliao. Com base nessas avaliaes, deve ser proposto um conjunto de recomendaes para que o estado desejado seja atingido. Os resultados das avaliaes, bem como as recomendaes derivadas, so compatibilizados com os esforos de melhoria existentes ou planejados. A definio do estado atual, do estado desejado e a lista de recomendaes compem o Relatrio do Diagnstico (RD).

20

Durante o Estabelecimento, as questes que a organizao decidiu focar no programa de melhoria so priorizadas e as estratgias para alcanar as solues so formuladas. Nessa fase, o Plano Estratgico de Ao (PEA) ser produzido. Esse plano ir guiar os trabalhos durante a fase de Ao. Os projetos necessrios para o desenvolvimento das solues so identificados e priorizados. Essa priorizao deve considerar as prioridades das recomendaes propostas na fase de Diagnstico que so atendidas pelos projetos e tambm as prioridades gerenciais da organizao. Alm Estabelecimento disso, os Grupos Tcnicos responsveis por cada um dos projetos devem ser selecionados e treinados. Para cada projeto identificado cria-se um documento chamado Plano Ttico de Ao (PTA) que, em um primeiro momento, mantm a descrio do projeto e a composio de seu Grupo Tcnico. Alm disso, nessa fase deve ser criado um plano de execuo dos projetos, demonstrando a possibilidade de paralelismo existente e as dependncias identificadas. Uma agenda para o programa, com detalhes dos perodos dedicados a cada projeto criada. Sempre que o Grupo Gestor considerar necessrio, o programa de melhoria pode ser replanejado. Durante a fase de Ao as solues necessrias so propostas, produzidas e colocadas em produo. As atividades dessa fase tipicamente consomem mais tempo e recursos que as atividades de todas as outras fases. Ao Projetos-piloto so definidos e executados com o objetivo de testar e avaliar as solues que foram propostas. Aps a sua execuo, as solues devem ser aperfeioadas para refletir o que foi aprendido. Aps a validao da soluo, ela ser implantada na organizao. O principal objetivo dessa fase fazer com que uma prxima execuo do programa de melhoria, caso ocorra, seja mais efetiva. Nesse momento, as solues j foram desenvolvidas e lies foram aprendidas. Essas informaes so coletadas e registradas de forma a garantir que elas sejam fonte de informao futura. Lies De posse das informaes coletadas, sero feitas avaliaes da estratgia, dos mtodos e da infraestrutura utilizados no programa de melhoria. Se aes futuras forem propostas, correes e ajustes na estratgia, mtodos ou infra-estrutura devem ser sugeridos e o prximo ciclo deve ser definido e planejado.

3.2 O Synergia
O Synergia, organizao alvo desse programa de melhoria, um laboratrio de pesquisas em Engenharia de Software e Sistemas do Departamento de Cincia da Computao (DCC) da UFMG, que oferece servios de desenvolvimento de software para empresas pblicas e privadas. O surgimento do laboratrio tem sua origem em um convnio entre o DCC e uma das maiores empresas de telefonia do Brasil assinado na dcada de 90 para desenvolvimento de um sistema de grande porte para essa empresa. Diante da complexidade desse desafio, surgiu a necessidade de criao de um

21

processo bem definido para execuo do projeto, e com essa necessidade surgiu o processo PROSE. Mais tarde, com a experincia do PROSE e pesquisas realizadas pelo professor do DCC e um dos coordenadores do laboratrio, Wilson de Pdua, foi desenvolvido o Praxis (PRocesso para Aplicativos eXtensveis InterativoS), baseado em processos como MBase, desenvolvido pela equipe de Barry Boehm na USC, e o UP (Unified Process). O Praxis atualmente se encontra em sua terceira verso [Pdua, 2008]. Atualmente, o laboratrio conta com cerca de 80 colaboradores entre doutores, mestres e vrios especialistas que em sua maioria tm formao em Cincia da Computao. O principal servio prestado pelo Synergia o desenvolvimento de produtos de software. O laboratrio j desenvolveu produtos de 300 at 5000 pontos de funo. Alm do desenvolvimento de produtos de software, tambm so oferecidos os servios: Modelagem de negcio: fornecendo uma documentao abrangente dos processos de negcio executados em um cliente; Especificao de sistema: levantando os requisitos e elaborando o projeto conceitual de uma famlia de produtos de software que visam automatizar os processos do cliente; Treinamento e consultoria: em processos, melhoria de processos e tcnicas de desenvolvimento de software. O Synergia adota uma verso personalizada do Praxis, denominada Praxis-Synergia, adequada s necessidades encontradas durante a execuo de projetos reais. A proximidade do autor do processo com o laboratrio cria um ambiente de troca de experincias entre as pesquisas realizadas no ambiente acadmico e a execuo de projetos reais, fazendo com que ambos os processos evoluam em paralelo. Mais detalhes do Praxis-Synergia sero apresentados na prxima seo. At o fim de 2008, a verso do Praxis-Synergia era baseada na verso 2.1 do Praxis padro, que possua ciclo de vida de entrega evolutiva. Todos os projetos da Organizao utilizados para coleta e anlise de dados nesse trabalho, utilizaram esse tipo de ciclo de vida da verso 2.1 do Praxis. Entretanto, por imposio do mercado, esses projetos foram todos divididos em dois: Projeto de Especificao, que inclui o levantamento e anlise dos requisitos e Projeto de Construo, que inclui as atividades de desenho em diante. O Projeto de construo no deve ser confundido com a Fase de construo do Praxis. A Figura 3-2 ilustra as atividades contempladas em cada um dos projetos.

22

Especificao

Construo

Figura 3-2 - Ciclo de vida de entrega evolutiva do Praxis 2.1.

No fim de 2008, houve o lanamento da terceira verso do Praxis [Pdua, 2008] e a Organizao prontamente iniciou o processo de atualizao de sua verso personalizada para se adequar aos novos conceitos do Praxis 3.0. Essa nova verso, que traz mudanas significativas em relao anterior, possui ciclo de vida quase-espiral, onde, a cada iterao das fases de Elaborao e Construo, uma verso parcial do produto completada. Atualmente (Maio de 2009), um grande projeto est sendo desenvolvido utilizando esta nova verso e diversas aes propostas neste programa de melhoria encontram-se em utilizao nesse projeto. Voltaremos a essas questes de tipos de ciclo de vida na seo 5.1. Outras informaes sobre o laboratrio podem ser encontradas no trabalho de Pimentel e outros [Pimentel et al., 2006].

3.3 A aplicao do ProMOTe no Synergia

Nessa seo sero apresentados os detalhes de como ocorreu a aplicao do ProMOTe no Synergia. Como j foi mencionado anteriormente, o autor deste trabalho membro da equipe da Organizao, mais especificamente, membro da equipe de Engenharia de Processos. Boa parte do

23

esforo do autor nesse programa fez parte do escopo de suas atividades como funcionrio da Organizao, principalmente as atividades relacionadas com a execuo das melhorias propostas. A parcela de dedicao como aluno de ps-graduao foi concentrado na confeco do Relatrio de Diagnstico e na elaborao deste texto. O primeiro passo seguido foi a definio dos papis. Por se tratar de um programa de porte relativamente pequeno, em uma Organizao tambm de pequeno porte, alguns dos papis do ProMOTe foram agrupados. O Comit Executivo foi composto pela Diretoria da Organizao e se responsabilizou pela definio dos objetivos do programa e da aprovao e priorizao de todas as aes propostas. O Grupo Diretor era representado pelo gerente da equipe de Engenharia de Processos e agiu como um facilitador, dentro da Organizao para a execuo do programa. O Grupo de Suporte ao Programa consistia de representantes da equipe de Administrao de Recursos Computacionais, fornecendo equipamentos e ferramentas que seriam utilizados. Os demais grupos permanentes, Grupo Tcnico e Grupo Gestor, foram assumidos pelo autor do trabalho. Por ltimo, o Grupo de Explorao, responsvel pela confeco do Relatrio de Diagnstico foi composto pelos membros da equipe de Engenharia de Processos e pelos Gerentes de Projetos da Organizao. A seguir, dados os objetivos gerais do programa, estabelecidos pelo Comit Executivo, o Grupo Diretor e Grupo de Explorao elaboraram os documentos de Definio do Programa e Plano do Programa. Essa atividade durou 2 semanas. Na seqncia os documentos foram apresentados ao Comit Executivo para aprovao e reviso. Aprovados esses documentos, a Equipe de Explorao iniciou o diagnstico da situao atual e da situao desejada. Essa atividade foi realizada, principalmente, atravs de reunies internas na Organizao. O resultado desse trabalho, que durou aproximadamente 2 meses, o Relatrio de Diagnstico, apresentado em detalhes, no Captulo 4. Definidas as aes para levar situao desejada, cada uma delas tornou-se um pequeno projeto que foi executado, essencialmente, pela equipe de Engenharia de Processos. Para cada projeto foram definidos os objetivos, tecnologias que seriam avaliadas, alm de oramento (esforo dos colaboradores da Organizao) e metas de prazo. Em aproximadamente 16 meses esses projetos foram concludos e seus detalhes e resultados alcanados so apresentados no Captulo 5. A fase de Lies, ltima fase do ciclo de melhorias, no foi executada na Organizao por limites de prazo imposto para confeco deste texto, mas j foi possvel coletar informaes valiosas durante a execuo das aes que permitiro tornar mais eficientes novas instncias de programas como este.

24

Captulo 4 Relatrio de diagnstico

Nesse captulo ser apresentado um resumo do Relatrio de Diagnstico (RD) confeccionado durante o Programa de melhoria de estimativas. O RD do ProMOTe tem o objetivo de levantar o estado atual e desejado da organizao em relao ao objetivo do programa de melhoria, no caso, melhoria de estimativas. O relatrio mostra tambm quais aes devem ser realizadas para se alcanar o estado desejado a partir do atual, levando em considerao os pontos fortes e fracos da organizao. As sees a seguir detalham o RD e esto organizadas da seguinte forma: A seo 4.1 enumera os aspectos contemplados no diagnstico; Na seo 4.2, a situao atual da organizao em relao a esses aspectos apresentada; Na seo 4.3, a situao desejada em relao aos mesmos aspectos descrita; Por fim, na seo 4.4, as aes propostas, para levar da situao atual para a desejada, so enumeradas.

4.1 Aspectos contemplados no diagnstico

O Comit Executivo do programa definiu duas necessidades importantes para o diagnstico do programa de melhoria de estimativas da Organizao: Ter estimativas de esforo, prazo e custo confiveis para elaborao de propostas

25

comerciais de projetos de desenvolvimento de software. Conseguir elaborar planejamento mais confivel dos projetos com menor variao entre planejado e realizado, evitando replanejamentos do projeto. Esse planejamento envolve tanto o planejamento macro (esforo, custo e prazo totais das iteraes) quanto o micro-gerenciamento (atribuio de tarefas aos colaboradores). Diante dessas necessidades, foram derivados os aspectos a serem considerados no diagnstico. A Tabela 4-1 apresenta esses aspectos.
Tabela 4-1 - Aspectos considerados no diagnstico
Necessidade 1 Aspectos Derivados Processo para as estimativas e para o registro de informaes de propostas e oramentos Registro e anlise de informaes de execuo dos projetos. 2 Processo de planejamento macro (iteraes) dos projetos. Processo de estimativa para tarefas individuais nos projetos.

Esses quatro aspectos foram avaliados pela Equipe de Explorao do programa, composta por membros da Equipe de Engenharia de Processos da Organizao, que, por meio de reunies e entrevistas com colaboradores internos, fez o levantamento da situao atual (apresentada na prxima seo). De posse do relatrio da situao atual, essa equipe se reuniu novamente com o Comit Executivo e chegou-se a uma proposta de situao desejada, tambm para cada um dos 5 aspectos identificados na Tabela 4-1.

4.2 Situao anterior

Nessa seo faremos um resumo do diagnstico da situao da Organizao com relao aos aspectos discutidos na seo anterior na poca em que foi realizado o diagnstico.

4.2.1 Aspecto Processo e registro de informaes de propostas e oramentos

Na Organizao, o oramento era feito sem processo definido. Usualmente utilizava-se o

26

Microsoft Project para elaborar a estrutura analtica do projeto, dividindo-o em iteraes. Para se estimar o esforo das iteraes era utilizado um clculo simples com base na produtividade dos outros projetos j executados e no tamanho estimado (ou medido) do produto que seria executado em cada iterao. O prazo era derivado da equipe que se imaginava estar disponvel. A elaborao desse oramento dependia exclusivamente da experincia do profissional que o estava fazendo. As propostas so separadas em tcnicas e comerciais. A primeira possui a descrio do escopo com detalhes e um resumo do oramento de esforo e prazo. A segunda, que baseada na proposta tcnica, contm o preo de venda do projeto, formado sobre o perfil da equipe imaginada para a sua execuo. Ambas eram armazenadas apenas como documentos, o que dificultava a coleta de dados. Um levantamento realizado com dados de projetos passados mostrou um erro mdio (MMRE) na estimativa do esforo de 45,9% total dos projetos.

4.2.2 Aspecto Registro e anlise de informaes de execuo de projetos

O registro de informaes de tamanho, esforo, prazo, qualidade e custo de execuo dos projetos so essenciais para embasar estimativas para novos projetos. Um ponto forte observado na Organizao, que os esforos so armazenados em um sistema de ponto eletrnico, chamado Apropriao de Horas (AH) o que d uma confiabilidade muito alta dessa informao. Ao iniciar suas atividades o colaborador dispara um comando que comea a marcar o tempo de trabalho e a cada vez que est saindo do local de trabalho, informa em quais tarefas de quais projetos trabalhou desde que iniciou o sistema. Essas tarefas armazenam informaes importantes, como o requisito associado, a disciplina (ou fluxo) a que se refere e a iterao em que foi executada. No havia registro formal de prazo dos projetos. No entanto, ele podia ser inferido a partir dos registros do AH, utilizando a menor e maior data registradas, mas era preciso alguma anlise manual para excluir atividades que ocorreram antes e depois do prazo real de execuo (exemplo: algumas tarefas de pequeno esforo realizadas bem aps o trmino do projeto, para organizar documentao para envio ao cliente so apropriadas no projeto, distorcendo o prazo). O custo podia ser obtido tambm a partir do AH, mas um trabalho manual e moroso, j que envolve buscar o valor-hora de um colaborador na poca da apropriao e multiplicar pelo esforo deste colaborador no perodo desejado. Todos os valores do custo por hora dos colaboradores eram armazenados em planilhas eletrnicas e de acesso restrito.

27

O tamanho dos produtos medido em pontos de funo no ajustados utilizando o padro do International Function Point User Group (IFPUG). Ao final da especificao dos requisitos dos projetos, era feita uma contagem dos pontos de funo do produto e registrado em planilhas eletrnicas. Durante a construo do produto, esses registros no eram mantidos. Os pontos de funo de alterao no eram integrados ltima contagem de tamanho. Isto impossibilitou determinar de forma direta o tamanho do produto final, necessitando nova contagem, caso a Organizao ache necessrio recuperar essa informao. As informaes de qualidade (defeitos) ficam armazenadas em um sistema informatizado. A coleta dos dados parcialmente automatizada, o que permite evitar os erros decorrentes de consolidao manual das informaes.

4.2.3 Aspecto Processo de planejamento macro (iteraes) dos projetos

Assim que o projeto iniciava, o seu gerente elaborava um planejamento macro de suas iteraes. Para cada iterao era elaborada a estrutura analtica do projeto, com todas as tarefas e perfis de recurso necessrio e uma estimava do esforo para execut-las. Com isso era possvel saber o esforo e durao total de cada iterao. Para se estimar o esforo, no havia um procedimento definido. O gerente usualmente utilizava planilhas auxiliares que fornecem um esforo padro para cada tipo de tarefa baseado numa classificao da complexidade do escopo. Essa classificao era feita por um colaborador experiente. Mais detalhes desse procedimento sero apresentados na seo 5.3. Ao fim do planejamento macro, o gerente confrontava o esforo total com o oramento e caso o ultrapasse, ele procurava a diretoria da Organizao e o cliente para negociaes.

4.2.4 Aspecto Processo de estimativa para tarefas individuais nos projetos

No incio de cada iterao, o planejamento detalhado era realizado pelo gerente do projeto, alocando o recurso (colaborador) que executaria cada uma das tarefas. Nesse momento o esforo planejado durante o planejamento macro era revisado. Em alguns casos o gerente arbitrava o esforo que concederia ao colaborador. Esse esforo era definido sem um procedimento definido. Em alguns casos consultavam-se dados de execuo de outros projetos, em outros apenas o sentimento e experincia do gerente eram usados. As tarefas no planejadas, que surgiam no decorrer do projeto,

28

tambm eram estimadas das duas formas sem um critrio definido. Em entrevista com os gerentes de projeto foi possvel perceber que havia um sentimento de que os procedimentos usados no levavam a boas estimativas, principalmente para tarefas relacionadas codificao de casos de uso. Essas tarefas so de esforo grande: comum terem esforo maior que 200h, como relatado por eles. Erros grandes nessas tarefas ocasionam tambm em grande impacto no projeto. Um levantamento realizado em 2 mdulos (num total de 39 casos de uso) de um dos projetos executado na Organizao, mostra um esforo mdio de 100,2h para codificao de cada um dos casos de uso. Analisando as estimativas feitas para as 39 tarefas nos projetos, observou-se um erro mdio (MMRE) relativamente alto: 52,8% 20,1%, confirmando as impresses dos gerentes. Esse levantamento foi feito apenas no projeto cujas informaes foram armazenadas de forma a ser possvel a coleta automatizada.

4.3 Situao desejada

Nessa seo ser apresentado o resumo da situao desejada pela Organizao com relao aos aspectos discutidos na seo 4.1.

4.3.1 Aspecto Processo e registro de informaes de propostas e oramentos

Em relao ao aspecto Processo e registro de informaes de propostas e oramentos, a Organizao deseja ter definido um processo que faa uso de seus dados histricos e que se baseie em anlise dos riscos envolvidos. Esse processo deve utilizar de mtodos consagrados como o COCOMO II. Tambm deseja-se criar um repositrio centralizado de oramento e propostas, armazenando no s os arquivos enviados para clientes (e suas vrias verses), mas as informaes de custo, tamanho, esforos, prazos e riscos de forma estruturada. Espera-se com isso ser mais fcil a comparao dos oramentos com os valores reais de execuo dos projetos.

4.3.2 Aspecto Registro e anlise de informaes de execuo de

29

projetos
Nesse aspecto, a Organizao quer ter um processo de fechamento do projeto que inclua o registro de esforo, prazo, custo, tamanho, qualidade e personalizaes de processo utilizadas, armazenando em um repositrio unificado e estruturado, permitindo anlises futuras e comparaes entre os projetos. Algumas medidas/informaes a serem coletadas: Tamanho em PF e a evoluo dessa contagem. Tamanho em LOC (separando aplicao, testes de unidade, scripts de testes, camada de reuso). Riscos identificados e concretizados.

Para a coleta da contagem dos pontos de funo necessrio ter um processo de atualizao da contagem para todas as alteraes de escopo do produto, deixando registrados os PF includos, excludos e alterados em cada solicitao de alterao do cliente ou da equipe interna. Tambm deve-se possuir uma classificao dos projetos quanto s suas caractersticas: tamanho, complexidade, tecnologias, requisitos no-funcionais, equipe e outros, permitindo a comparao entre projetos e possibilitando um oramento com critrios mais consistentes. Para essa caracterizao pode-se utilizar como base os parmetros de classificao do COCOMO II ou parmetros de outros mtodos que venham a ser adotados. Outro ponto importante desse aspecto melhorar o acompanhamento atual dos projetos, fornecendo diretoria e aos gerentes informaes de melhor qualidade para tomada de deciso. Algumas informaes solicitadas que no so produzidas e acompanhadas atualmente e que devem integrar a gesto dos projetos: Escopo planejado versus adquirido ao longo do tempo. Evoluo do tamanho fsico do cdigo fonte, do cdigo dos testes de desenvolvimento e do cdigo dos scripts de teste automatizados, comparado ao progresso em PF. Essas medidas daro uma indicao do grau de reutilizao de cdigo. Evoluo do custo por PF. Comparao do oramento de custo do projeto com o custo real. Evoluo do nmero de defeitos por PF ao longo do tempo.

30

4.3.3 Aspecto Processo de planejamento macro (iteraes) dos projetos

Atualmente o planejamento macro dos projetos feito, principalmente, com base em tabelas de esforos padro para cada atividade por complexidade do requisito. Essa complexidade no definida de forma objetiva. Outro ponto levantado que as atividades que no esto ligadas diretamente aos casos de uso so estimadas por pura intuio. A Organizao deseja definir um processo de planejamento macro que seja mais racional e que produza o bsico: qual o escopo, prazo e perfil de equipe necessria para cada iterao do projeto.

4.3.4 Aspecto Processo de estimativa para tarefas individuais nos projetos

Deseja-se formalizar um processo para estimativas de tarefas individuais do projeto, preferencialmente feitas pelos prprios colaboradores que as executaro no projeto. Essa estimativa ocorre no incio de cada iterao, quando o gerente faz o planejamento detalhado de todas as suas tarefas. Para dar suporte a essas estimativas necessrio que o cadastro de requisitos permita rastrear o impacto de alteraes nos artefatos produzidos, facilitando a estimativa de esforos para alteraes. O Gerente deve ter sua disposio esforos padres de cada atividade do processo normalizados por pontos de funo ou outra medida, dependendo do tipo da atividade. Esse repositrio facilitar as estimativas dos colaboradores inexperientes e servir como balizador quando houver divergncias entre a opinio do Gerente e do colaborador que fizer a estimativa para a tarefa.

4.4 Aes propostas

De posse do levantamento da situao atual e desejada em relao aos aspectos levantados nas sees anteriores desse captulo, a Equipe de Explorao, juntamente com o Comit Executivo, propuseram uma srie de aes e definiram suas prioridades. Essas aes esto listadas na

31

Tabela 4-2 com suas respectivas prioridades, onde prioridade 1 maior. Cada uma dessas aes se transformou em um Projeto Ttico de Ao (PTA) e seus resultados sero apresentados nas sees do captulo seguinte.
Tabela 4-2 Aes propostas no Relatrio de Diagnstico
No. de ordem 1 2 3 Descrio Definir um processo de estimativa para oramentos Aperfeioar o processo de estimativa para o planejamento das iteraes Definir o processo de contagem de pontos de funo de alteraes e integrar ao processo de controle de mudanas existente Definir um processo de estimativa para o planejamento de tarefas, revises e alteraes nos projetos Criar repositrio centralizado de registro de dados de propostas, projetos e dados sumarizados de casos de uso desenvolvidos no projeto Definir uma categorizao dos recursos e criar um repositrio centralizado de seus custos Aperfeioar o Cadastro de Requisitos Prioridade 1 2 3

6 7

3 3

32

Captulo 5 Desenvolvimento das aes

Nesse captulo os resultados das aes propostas pelo Programa de Melhoria de Estimativas sero apresentados. Cada seo desse captulo trata de uma ou mais aes da Tabela 4-2. O restante desse captulo est organizado da seguinte forma: A seo 5.1 apresenta o mtodo escolhido para estimativas realizadas durante a elaborao das propostas, juntamente com a sua validao e adaptaes para adoo na Organizao; Na seo 5.2, apresentada uma proposta para contagem de Pontos de funo diretamente nos modelos UML, garantindo consistncia da contagem e de sua atualizao. Tambm endereada a questo de contagem de Pontos de funo de alterao; Na seo 5.3, o planejamento macro dos projetos tratado, onde apresentamos uma simplificao do processo atualmente adotado na Organizao; J na seo 5.4, abordado o planejamento detalhado dos projetos, apresentando a tcnica escolhida e os resultados obtidos; Por fim, na seo 5.5, apresentado o repositrio centralizado de medidas proposto para a Organizao.

33

5.1 O processo para estimativa de oramentos

Como relatado na seo 4.2.1, a Organizao apresenta um erro relativamente alto MMRE de 45,9% quando se compara o oramento de esforo utilizado para suas propostas e os resultados dos projetos quando concludos. Embora seja um valor alto para desvios nos projetos, h de se levar em considerao que boa parte desses projetos sofreu alterao de escopo durante sua execuo, o que certamente impactou o esforo e prazo total desses projetos. Infelizmente, as alteraes e as renegociaes decorrentes delas no foram registradas de forma estruturada, inviabilizando uma avaliao precisa desses erros. A ao proposta na seo 5.2 visa sanar esses problemas em projetos futuros. O primeiro passo para definir o processo para estimativa dos oramentos foi a escolha do mtodo de estimativa. A tcnica de estimativa bottom-up, definida pelo PMBoK [PMI, 2004] j era usada e no apresentou bons resultados. Nessa tcnica, uma estrutura analtica do projeto era elaborada at um nvel de detalhamento possvel com a informao que se possua aps entrevistas com o cliente. Os pacotes de trabalho eram estimados individualmente baseados na experincia dos profissionais e os totais de esforos, prazo e custos eram agrupados at se chegar ao oramento. Resolveu-se ento, avaliar o COCOMO (Construtive COst MOdel) II [Boehm et al., 2000] como mtodo para estimativas dos oramentos, j que essa a tcnica indicada pelo Praxis 3.0, processo no qual a Organizao baseia o seu, alm de vrios relatos indicando seu uso com sucesso: [Boehm & Valerdi, 2008], [Helm, 1992]. Os resultados da utilizao do COCOMO II foram promissores. Nas sees seguintes esse mtodo ser detalhado, e a forma de adoo e calibrao explicada, alm da apresentao dos seus resultados nos projetos da base histrica. O processo de estimativa para oramento de projetos proposto apresentado na seqncia.

5.1.1 O COCOMO II
O COCOMO um mtodo enquadrado na categoria de funes matemticas, como descrito na seo 2.2. Ele se baseia em um conjunto de parmetros de entrada utilizados em equaes matemticas que produzem as estimativas de esforo e prazo para um projeto. O mtodo suporta estimativas tanto para projetos executados em ciclo de vida em espiral como MBASE e processos similares (ex: RUP e Praxis 3.0) quanto para ciclos de vida em cascata. No primeiro caso, o esforo medido em Pessoas-ms (PM) corresponde s fases de elaborao e construo. J no caso de projetos executados no modelo em cascata, o esforo corresponde s fases de desenho em diante

34

(inclusive). Alm disso, dois modelos so suportados: o Early design e o Post-architecture. O primeiro deve ser usado quando ainda se sabe pouco sobre o projeto e o segundo quando ao menos o desenho arquitetnico do produto j foi definido. Os parmetros do modelo consistem de seu tamanho estimado, em milhares de linhas de cdigo (KLOC), os multiplicadores de esforos (EM) e os fatores de escala (SF). As equaes abaixo so usadas no clculo do esforo do projeto em PM, que correspondem a 152 h. = = + 0,01

Equao 5-1 - Frmula para estimativa de esforo do COCOMO II

= 2,94

= 0,91

A diferena do modelo Early design para o Post-architecture nas equaes acima est relacionada com os multiplicadores de esforos EM. No primeiro modelo so usados apenas 7 multiplicadores e no segundo 17. Cada um desses multiplicadores de esforos definido em nveis que variam de Muito Baixo at Extra Alto, sendo que cada nvel possui um valor associado que aumentar, no impactar ou diminuir o esforo estimado do projeto. A Tabela 5-1 mostra os multiplicadores utilizados no modelo Post-Architecture. Pela tabela, pode-se perceber que parmetros definidos no nvel Nominal no aumentam e nem diminuem a estimativa de esforo, j que multiplicam por 1 a equao. O detalhamento de cada um dos parmetros pode ser obtido no manual do COCOMO II, que tambm fornece diretrizes para a escolha dos nveis. Note que nem todos os parmetros possuem todos os nveis. Os fatores de escala possuem tabela semelhante, mas como eles esto localizados no expoente da equao, o impacto no linear. A justificativa a deseconomia de escala existente no desenvolvimento de software, onde usualmente percebemos um crescimento no linear do esforo em relao ao tamanho, como explicado no manual do mtodo.

35

Tabela 5-1 - Valores dos nveis dos multiplicadores de esforos do modelo Post-Architecture

Nvel Smbolo Nome Muito baixo RELY DATA DOCU CPLX RUSE TIME STOR PVOL ACAP APEX PLEX PCAP LTEX PCON TOOL SCED SITE Confiabilidade requerida Volume de dados Documentao requerida Complexidade do produto Reusabilidade requerida Restries de tempo de execuo Restries de memria Volatilidade da plataforma Capacitao dos analistas Experincia com a aplicao Experincia com a plataforma Capacitao dos programadores Experincia com a linguagem e ferramentas Continuidade de pessoal Adequao das ferramentas Folga em relao ao prazo Co-localizao da equipe 1,42 1,22 1,19 1,34 1,20 1,29 1,17 1,43 1,22 0,87 1,19 1,10 1,09 1,15 1,09 1,12 1,09 1,14 1,09 0,81 0,73 0,82 Baixo 0,92 0,90 0,91 0,87 0,95 Nominal 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 Alto 1,10 1,14 1,10 1,17 1,07 1,11 1,05 1,15 0,85 0,88 0,91 0,88 0,91 0,90 0,90 1,00 0,93 Muito Alto 1,26 1,28 1,23 1,34 1,15 1,29 1,17 1,30 0,71 0,81 0,85 0,76 0,84 0,81 0,78 1,00 0,86 0,80 1,74 1,24 1,63 1,46 Extra alto

Para o clculo do tempo de desenvolvimento (TDEV) em meses, so utilizados o esforo dado pela Equao 5-1 (PM) e o somatrio dos fatores de escala (SF) como apresentado na equao abaixo. =

Equao 5-2 - Frmula para estimativa de prazo do COCOMO II

= 3,67

+ 0,002

= 0,28

36

5.1.2 Tamanho do produto

Como mostrado na Equao 5-1, O COCOMO II utiliza linhas de cdigo para medir o tamanho do produto que est sendo estimado. Ele faz uso de uma lista de conferncia, como recomendado pelo relatrio do SEI [Park et al., 1992] para formalizar essa contagem. Na lista de conferncia utilizada para formalizao da contagem h dois tipos principais de definies: o que e o que no considerado como linha de cdigo na contagem sob os diversos aspectos: tipo de instruo, como foi produzida, propsito de uso, estado do desenvolvimento, origem, entre outros; vetores de dados, que consiste em classificar cada linha considerada na contagem conforme opes dentro de cada vetor. Para melhorar o entendimento, a Figura 5-1 exemplifica a definio de um vetor de dados. Por esse exemplo, cada linha de cdigo deve ser enquadrada em exatamente uma opo de Tipo de arquivo. Uma lista de conferncia pode ter vrios desses vetores e fica a critrio de cada organizao definilos.

Tipo de arquivo

Definio

Vetor de dados

Inclui

Exclui

1 Java (arquivos com extenso .java, exceto com o padro de nome *Helper.java) 2 Web Esttica (.html, .htm, .css, .xsl) 3 Web Dinmica (.jsp, .js) 4 Configurao (.xml, .config, .properties) 5 Robot (.rec, .sbl, .sbh)

X X X X X

Figura 5-1 - Exemplo de vetor de dados utilizado na lista de conferncia de contagem de linhas de cdigo

Nesse trabalho, utilizam-se as linhas de cdigo fsicas como medida de tamanho para utilizao no modelo, embora o manual do COCOMO II defina a utilizao das linhas lgicas (ver seo 2.4 para detalhes sobre tipos de linhas de cdigo). A escolha de linhas fsicas sobre as lgicas vem da sua facilidade de obteno e da crena que ambas representam igualmente o tamanho fsico do produto, desde que haja padronizao de codificao entre os produtos medidos e a linguagem de programao seja a mesma. Esse justamente o caso da Organizao alvo desse programa, cujo processo executado possui inspees de cdigo para garantir a padronizao. O estudo de Rosenberg [Rosenberg, 1997] corrobora essa hiptese. Para definio formal da contagem de linhas de cdigo fsicas, utilizaram-se as

37

recomendaes do mesmo relatrio do SEI, definindo-se uma lista de conferncia, que pode ser vista em detalhes no Apndice A.1. Alm da formalizao da definio da contagem, foi desenvolvida uma ferramenta de contagem de linhas de cdigo que aderente ao padro definido pelo SEI. A ferramenta totalmente personalizvel, atravs de arquivo XML, com qualquer definio que utilize o formato de lista de conferncia proposto. A Figura 5-2 mostra um exemplo de configurao do vetor de dados mostrado na Figura 5-1, que avalia expresses regulares [Friedl, 2006] comparando-as ao caminho completo de cada arquivo analisado para enquadrar cada linha contada em uma das opes do vetor. A ferramenta no garante que dada uma configurao feita pelo usurio, uma linha contada receba exatamente um rtulo do vetor, mas ao final o usurio poder verificar se alguma linha foi rotulada com mais de uma ou nenhuma opo do vetor e fazer as devidas correes na configurao.

<tag nome="Tipo de arquivo"> <item valor="Java"> <padrao valor="\.java" tipo="inclui" /> </item> <item valor="Web"> <padrao valor="\.css" tipo="inclui" /> <padrao valor="\.htm?" tipo="inclui" /> <padrao valor="\.xsl" tipo="inclui" /> </item> <item valor="Web dinmica"> <padrao valor="\.js" tipo="inclui" /> <padrao valor="\.jsp" tipo="inclui" /> <padrao valor="\.tdl" tipo="inclui" /> </item> <item valor="Config"> <padrao valor="\.xml|\.config|\.properties" tipo="inclui" /> </item> <item valor="Robot"> <padrao valor="\.rec|\.sbl|\.sbh" tipo="inclui" /> </item> </tag>

Figura 5-2 - Configurao de vetor de dados da ferramenta de contagem de linhas de cdigo

O relatrio de contagem emitido pela ferramenta est no formato CSV (comma separated values), que permite a importao por diversas ferramentas para anlise dos dados. O relatrio apresentado na Tabela 5-2 foi elaborado com o recurso de tabela dinmica do Microsoft Excel, mostrando a contagem de um projeto incluindo os 3 vetores de dados definidos no apndice A.1. Vale ressaltar que esse relatrio apresentado na tabela inclui linhas de cdigo que no deveriam ter sido contadas conforme a lista de conferncia da Organizao, que, por exemplo, exclui a contagem das linhas de cdigo de testes de desenvolvimento e de sistema. Essas linhas no foram consideradas para

38

formar o tamanho do produto, mas a ferramenta de contagem foi configurada para coletar esses dados extras que fornecem informaes importantes do projeto, como a relao entre linhas de cdigo de testes e as do produto. No exemplo apresentado na Tabela 5-2, basta remover os valores das clulas sombreadas na tabela da contagem final.
Tabela 5-2 - Exemplo de relatrio de contagem de linhas de cdigo
Origem do Cdigo Controle Entidade Fronteira Cdigo Novo Outros Povoadores Testes de desenvolvimento Testes de sistema Total Cdigo Novo Fronteira Outros Reuso Povoadores Testes de desenvolvimento Total Reuso Total geral 690 1.768 16.170 28 2.108 10.883 821.487 1.215 4.260 15.032 8.051 15.989 242.940 28 12.064 32.900 1.095.629 14.402 60 1.018 896 7.845 5.600 Camada Config 61 Java 34.966 147.217 114.135 31.044 156.757 245.253 81.232 810.604 7.214 1.533 10.772 2.932 113 226.951 3.318 4.620 181 11 10.591 153 102.234 124.553 Web Web dinmica Total geral 35.027 147.370 234.805 161.197 156.757 246.341 81.232 1.062.729 13.524 7.284

5.1.3 Calibrao e validao do COCOMO II

Como apresentado na seo 2.3, no h um consenso sobre um indicador de acurcia que avalie de forma conclusiva a qualidade das estimativas de um mtodo. Portanto, nesse trabalho, foram utilizados vrios deles para chegarmos s nossas concluses. J para a escolha do mtodo de avaliao, foi escolhida a tcnica Leave-one-out cross validation, que como explicado na seo 2.5, reflete melhor a situao real nas organizaes, quando se possui dados histricos de um conjunto de projetos j executados e deseja-se estimar o prximo. Para validar a escolha do COCOMO II como mtodo para estimar os oramentos de novos projetos, aplicou-se as frmulas do modelo Post-Architecture aos 8 projetos j concludos pela Organizao, cujos dados coletados, principalmente os de esforo e de tamanho so confiveis. So todos projetos de produtos para web desenvolvidos em linguagem Java, com tamanho em Pontos de funo, variando entre 200 e 4500 e esforos reais variando entre 7,5 e 955,2 Pessoas-ms.

39

Conforme explicado na seo 3.2, que fala da Organizao alvo desse programa, esses projetos foram executados no ciclo de vida de entrega evolutiva (verso 2.1 do processo) e os dados analisados nessa seo dizem respeito ao Projeto de Construo dos produtos (a Especificao deles foi feita em projeto anterior). Comparando-se as etapas do Projeto de Construo executado em ciclo de vida de Entrega evolutiva com as fases do modelo Cascata suportado pelo COCOMO II, observamos uma correspondncia do esforo estimado pelo modelo com as etapas do Projeto de Construo, como mostrado na Figura 5-3.

Ciclo de vida em Cascata do COCOMO II

Ciclo de vida em Entrega evolutiva do Praxis-Synergia

Fases contempladas na estimativa do COCOMO II

Fases do Projeto de Construo

Figura 5-3 - Comparao do modelo cascata do COCOMO II com o Praxis-Synergia.

Como se pode ver na Tabela 5-3, os resultados da utilizao do mtodo foram muito ruins, mesmo em indicadores que no utilizam o operador mdulo, como no MBRE e MIBRE, quando erros em projetos subestimados tendem a se cancelar com erros nos superestimados5. A principal justificativa encontrada, que as particularidades da Organizao tornam seus projetos muito diferentes dos projetos que constituem a base do modelo padro. Um exemplo a relao de

Os resultados do MMER e MMER ficaram iguais aos do MBRE e MIBRE porque os projetos

foram todos superestimados pelo modelo padro.

40

linhas de cdigo por ponto de funo. Na Organizao, a mdia dessa relao entre os 8 projetos analisados de 170 LOC/PF para a linguagem Java, enquanto o modelo padro sugere uma relao de 53 LOC/PF.
Tabela 5-3 - Resultados da avaliao de estimativa de esforo do COCOMO II com o modelo padro
MMRE 319,50% MMER 71,97% MBRE 319,50% MIBRE 71,97% PRED(0,25) 0,00%

Com essa magnitude de erro na estimativa, torna-se necessrio calibrar o COCOMO II, como seus prprios autores sugerem fazer. Essa calibrao envolve utilizar regresso linear mltipla pelo mtodo Ordinary Least Squares (OLS) (ver [Jain, 1991] para maiores detalhes). Entretanto, como o prprio nome sugere, o OLS pode ser utilizado apenas em modelos lineares, o que no o caso, j que temos variveis no expoente das frmulas. A sada, nesse caso, linearizar a frmula por manipulao algbrica, utilizando Logaritmo. ( )= ( ) + ( + 0,01 ) ( )+ ( )

Equao 5-3 - Frmula de estimativa de esforo linearizada

A partir da Equao 5-3, o passo seguinte isolar as constantes A e B que devem ser calibradas, o que resulta na Equao 5-4. Em seguida, aplica-se a regresso linear mltipla para ajustar as constantes A e B. ( ) 0,01 ( ) ( )= ( )+ ( )

Equao 5-4 - Manipulao da Equao 5-3 para isolar as constantes A e B

Aps a calibrao das constantes, reavaliamos os mesmos indicadores para as estimativas feitas nos 8 projetos e os resultados so apresentados na Tabela 5-4. Port e Korte [Port & Korte, 2008] sugerem que um MMRE menor que 25% e PRED(0,3) maior que 75% so considerados valores aceitveis como boas estimativas, o que nos leva a crer que os resultados da calibrao foram muito bons. Quando se considera o sinal dos erros (superestimativa compensando subestimativa), como no caso dos indicadores MBRE e MIBRE, observamos desvios mdios muito pequenos, prximos de zero.

41

Tabela 5-4 - Resultados da avaliao de estimativa de esforo do COCOMO II com modelo calibrado
MMRE 15,63% MMER 14,44% MBRE -0,31% MIBRE -1,51% PRED(0,25) 87,50%

O mesmo procedimento de calibrao foi realizado para as equaes de estimativa de prazo para obter novas constantes C e D e os resultados da avaliao encontram-se na Tabela 5-5.
Tabela 5-5 - Resultados da avaliao de estimativa de prazo do COCOMO II com modelo calibrado
MMRE 43,34% MMER 44,68% MBRE 0,17% MIBRE 1,51% PRED(0,25) 37,50%

Esses resultados no foram to bons quanto os de esforos. Uma possvel justificativa a presena de alguns projetos que tiveram sua execuo paralisada e no foi possvel recuperar o tempo de paralisao para os mesmos, tornando a calibrao menos precisa. Outro motivo o provvel aumento do escopo durante a construo do produto, mas como no h registro do tamanho das alteraes, fica invivel tirar concluses definitivas a respeito. De posse dos indicadores acima, pode-se dizer que o COCOMO II apresentou-se como um mtodo promissor para ser introduzido no processo de estimativa dos oramentos de novos projetos da Organizao. Entretanto, essa anlise deve ser refeita periodicamente a medida que novos projetos compuserem os dados histricos, j que, 8 projetos so uma massa de dados pequena para se obter concluses realmente precisas.

5.1.4 A adoo do COCOMO II na Organizao

Embora os resultados apresentados na seo anterior sejam promissores, um ponto muito importante de se salientar, que a validao foi feita com o tamanho real final dos produtos. Quando se est estimando um novo projeto com o COCOMO II, necessrio estimar tambm o seu tamanho em linhas de cdigo, que uma tarefa difcil. Uma sada proposta pelos autores do mtodo a utilizao de Pontos de funo no-ajustados (UFP) do IFPUG [IFPUG, 2005] como medida alternativa de tamanho do produto. A explicao a facilidade de obteno dessa informao logo nas etapas iniciais do projeto. A Organizao j utiliza a estimativa de tamanho em Pontos de funo no-ajustados em seus projetos. Para isso, identifica-se junto aos usurios a lista das funes de transao e dados do

42

produto. No melhor caso, quando h modelagem de sistema que inclui o produto sendo estimado, essa lista carrega um grau de incerteza baixo. Quando no h essa modelagem, a lista de funes normalmente sofre um grau maior de variao entre a estimativa e o que vir a ser o produto, j que ela ser obtida por meio de poucas reunies durante a iterao de Ativao do projeto. A partir da lista de funes, os analistas de requisitos mais experientes estimam a complexidade de cada funo, obtendo assim, o total de Pontos de funo no-ajustado do produto (ver resumo do processo de contagem na seo 5.2.2). Outra forma de estimativa de Pontos de funo no-ajustados utilizada pela Organizao descrita por McConnell [McConnell, 2006] como o Mtodo Holands (pois definido pelo Netherlands Software Metrics Association NESMA). Nesse mtodo, a contagem indicativa de Pontos de funo no-ajustados dada por (35 x nmero de Arquivos Lgicos Internos) + (15 x nmero de Arquivos de Interface Externa). O resultado dessa equao confrontado com a estimativa obtida a partir da lista de funes como verificao de sanidade. De posse da estimativa em Pontos de funo no-ajustados, deve-se obter a mdia de linhas de cdigo por Ponto de funo (LOC/PF) da base histrica dos projetos, para obter o nmero de linhas de cdigo que servem como medida de tamanho do COCOMO II. Entretanto, utilizar a mdia s faz sentido se a variao das medidas no for grande. No foi possvel realizar essa anlise nos dados histricos da Organizao pela ausncia da contagem final de Pontos de funo dos produtos e essa questo deve ser observada no futuro para validar a utilizao do COCOMO II como mtodo de estimativa. Como se pode inferir a partir da Tabela 5-1, na seo 5.1.1, a escolha de um nvel para cada multiplicador de esforo uma tarefa delicada, j que uma escolha errada pode levar a uma grande variao no esforo estimado. Para ilustrar, a escolha do nvel Muito baixo para a Capacitao dos analistas (ACAP), multiplicaria o esforo total estimado por 1,42, ou seja, aumentaria o esforo em 42% considerando os demais multiplicadores como constantes. Se a escolha que melhor refletisse a realidade do projeto fosse o nvel Baixo, o esforo seria multiplicado por 1,19. Com isso, a diferena entre a escolha feita e a melhor escolha influenciaria a estimativa final de esforo em 23%. No trabalho de Clark e outros [Clark et al., 1998] so apresentados possveis efeitos de m interpretao desses parmetros, que podem levar a comportamento inverso ao previsto no mtodo. Com o intuito de minimizar esse problema, foi elaborado um documento para auxiliar a interpretao de cada parmetro, que inclui diretrizes que complementam a documentao do mtodo [Boehm et al., 2000] sob o ponto de vista das especificidades da Organizao. O documento proposto acima diminui o risco de m interpretao na escolha dos

43

parmetros, mas no elimina os riscos inerentes de todo projeto de desenvolvimento. Foi elaborada uma planilha para avaliar qualitativamente os diversos riscos dos cenrios possveis para o projeto e quais parmetros seriam impactados em cada um deles. Dessa forma, os gestores da Organizao podero tomar melhores decises na formao de seus preos a partir do custo estimado pelo COCOMO II. A Figura 5-4 exemplifica a utilizao dessa planilha.

Cenrios
Cenrio Esperado Pessimista Parmetros/Fatores variado (informar novo valor) ACAP: de Muito Alto para Alto PCAP: de Alto para Nominal Riscos envolvidos Sada dos colaboradores mais experientes da equipe do projeto Complexidade do produto pode ser menor que o levantado inicialmente

Estimativas
Esforo (PM) 323,4 439,9 Prazo (ms) 8,7 9,4

Otimista

CPLX: de Alto para Nominal

276,4

8,4

Figura 5-4 - Planilha para anlise qualitativa de riscos das estimativas.

5.1.5 O processo de estimativa para oramento de projetos

Com base na avaliao positiva do COCOMO II e nas propostas da seo anterior, foi definido um processo para orar os novos projetos da Organizao. Esse processo, que ser apresentado a seguir, foi documentado utilizando o Eclipse Process Framework (EPF)6, ferramenta de cdigo livre aderente ao Software & Systems Process Engineering Metamodel 2.0 (SPEM) [OMG, 2008], que o padro definido pelo OMG (Object Modeling Group)7 para documentao de processos de desenvolvimento de software e sistemas. O processo proposto com base nas tcnicas e melhorias apresentadas nas sees anteriores,, cujas atividades so ilustradas na Figura 5-5, foi incorporado fase de Iniciao do Praxis-Synergia.

www.eclipse.org/epf www.omg.org

44

Figura 5-5 - Processo para oramento de projetos.

Na Tabela 5-6 cada uma das atividades detalhada, bem como os seus insumos e resultados. Esse processo foi incorporado iterao de ativao na personalizao do Praxis adotado pela Organizao.
Tabela 5-6 - Detalhamento das atividades do processo de oramento proposto.
Atividade Descrio A viso geral do projeto consiste na produo de dois artefatos: Documento de viso e Diagrama de contexto, ambos levantados junto a reunies com o cliente potencial. No Documento de viso constam Desenvolver viso do projeto os objetivos do projeto, a lista de requisitos funcionais e no-funcionais, produtos que devem ser integrados ou ter seus dados migrados, metas gerenciais, limitaes e premissas do projeto. No Diagrama de contexto, est o modelo UML com os casos de uso e atores identificados durante as reunies. Identificar riscos Nessa atividade os riscos e oportunidades do projeto so identificados de forma preliminar, j que um novo levantamento detalhado realizado no incio do projeto quando ele for contratado. Essa lista serve como insumo para as atividades de estimativa de tamanho, esforo e prazo.

45

A estimativa de tamanho consiste em estimar o tamanho do produto em Pontos de funo no-ajustados, Estimar tamanho como descrito na seo 5.1.4. As funes de dados e transaes so obtidas em reunies de levantamento de requisitos junto ao cliente e a complexidade delas estimada para se chegar ao total de Pontos de funo. Nessa atividade utiliza-se o COCOMO II para estimar o esforo e prazo do projeto. O primeiro passo calibrar o COCOMO II com os dados histricos dos projetos. Ento, utiliza-se a estimativa de tamanho e a planilha de interpretao dos parmetros (ver seo 5.1.4) para estimar o esforo e o prazo. Essas estimativas so realizadas com um perfil de equipe disponvel em mente, j que esse perfil impacta Estimar esforo e prazo diversos fatores do mtodo. A lista de riscos identificados tambm utilizada aqui para avaliar o impacto de cada risco e oportunidade nos parmetros do mtodo e criar possveis cenrios, com as estimativas correspondentes, como ilustrado na Figura 5-4 da seo anterior. O resultado dessa atividade produz um relatrio com os parmetros informados, o perfil de equipe assumido e a anlise qualitativa dos riscos. A validao das estimativas consiste numa reviso gerencial dos artefatos produzidos, verificando a Validar estimativas validade das premissas assumidas e a consistncia entre os artefatos. Essa reviso feita por uma pessoa externa equipe de produo, que no possui compromisso com a venda do projeto. Isso diminui a tendncia ao otimismo na imputao dos parmetros do COCOMO II. Elaborar proposta comercial A partir dos resultados produzidos pelas estimativas, a direo da Organizao toma decises sobre o preo de venda, incluindo (ou no) a margem de lucro desejada.

5.2 O processo de contagem de pontos de funo

Nessa seo as melhorias relacionadas contagem de Pontos de funo dos projetos sero tratadas. A Organizao j utiliza o padro de contagem do International Function Point User Group (IFPUG) [IFPUG, 2005] formalmente para medir o tamanho de seus produtos, mas o registro realizado em planilhas eletrnicas. Os principais problemas associados a essa forma de registro so: No h uma amarrao com a modelagem do produto. Com isso, alteraes feitas no modelo no so refletidas automaticamente na contagem, tornando-se um risco da contagem ficar inconsistente; Esforo grande para o registro da contagem, pois a descrio dos itens considerados feito de forma textual e manual. Para solucionar esses problemas foi proposta uma nova maneira de registro da contagem, realizada diretamente sobre os modelos UML do produto sendo modelado e uma integrao com o Cadastro de Requisitos do projeto. Na verso padro (ou educacional) do Praxis, j h uma

46

proposta de mapeamento de elementos do Modelo do Problema para funes da contagem de Pontos de funo. Essa proposta inova apenas na forma de identificar, mapear e registrar a contagem em modelos UML, mas continua totalmente aderente ao manual de prticas de contagem do IFPUG e ao Praxis padro. Alm da forma de registro de contagem proposta, um processo de gesto das alteraes e respectiva atualizao da contagem tambm foram desenvolvidos. Nas sees seguintes apresentamse os detalhes dessas propostas. Vale aqui destacar que a nossa proposta restrita a projetos de desenvolvimento de software que adotem a UML como notao de modelagem para expressar os requisitos.

5.2.1 O modelo do problema

Nessa seo apresentaremos de forma resumida o artefato denominado Modelo do Problema, que utilizado na Organizao, que adota o mesmo padro proposto no Praxis 3.0. A ferramenta utilizada nessa modelagem o Rational Software Architect8 e as figuras de diagramas UML [OMG, 2005b] apresentadas aqui so extrados dela. Ser dado enfoque nos pontos importantes para a contagem de pontos de funo que ser apresentada na seo seguinte. Detalhes do artefato podem ser obtidos no Captulo 16 do livro do processo [Pdua, 2008]. A modelagem do problema consiste em desenvolver um modelo UML que represente os requisitos do cliente em relao ao produto sendo desenvolvido e o entendimento dos desenvolvedores de como esse sistema ir funcionar. Essa modelagem independente de tecnologia e da soluo que ser proposta para o problema, o que a torna mais prxima da Viso do Usurio descrita no manual de contagem do IFPUG. O modelo segue as recomendaes do padro IEEE-830 [IEEE, 1998] e dividido em duas vises principais: Viso de requisitos e Viso de anlise. Na primeira esto as funes do produto do ponto de vista do usurio, mostrando os casos de uso (com seus fluxos), os atores e a interao entre eles documentadas com diagramas de atividade, como ilustra a Figura 5-6. Em cada fluxo dos casos de uso aplicado um esteretipo para representar seu tipo: principal, subfluxo ou fluxo alternativo (mainFlow, subFlow e altFlow respectivamente).

http://www-01.ibm.com/software/awdtools/swarchitect/websphere/

47

Caso de uso

Fluxo do caso de uso

Figura 5-6 - Modelo do problema: viso de requisitos. Extrado do exemplo do Praxis 3.0 [Pdua, 2008]

Na Viso de anlise, encontram-se as colaboraes que realizam os fluxos dos casos de uso. Cada caso de uso realizado por uma colaborao das classes modeladas pelo analista. A Figura 5-7 mostra a associao de realizao entre uma colaborao e o caso de uso.

Classes participantes

Figura 5-7 - Realizao de um caso de uso por uma colaborao. Extrado do exemplo do Praxis 3.0.

Cada um dos fluxos dos casos de uso descritos na Viso de requisitos realizado por uma interao entre as classes identificadas, modeladas em diagramas de seqncia. Essas classes so estereotipadas como entidade, entidade persistente, controle e fronteira (entity, persistentEntity, control e boundary respectivamente). A Figura 5-8 mostra a realizao do fluxo ilustrado na Figura 5-6.

48

Figura 5-8 - Realizao de um fluxo de caso de uso. Extrado do exemplo do Praxis 3.0

5.2.2 Introduo contagem de pontos de funo do IFPUG

Nessa seo apresentaremos um breve resumo dos conceitos e procedimentos de contagem de pontos de funo conforme especificao do IFPUG [IFPUG, 2005]. A Figura 5-9 mostra as atividades que compem o processo de contagem do manual. Na primeira atividade, devemos definir o tipo de contagem que est sendo feito. Podem ser de 3 tipos: contagem de Pontos de funo de projeto de desenvolvimento, que mede o tamanho de um novo produto sendo desenvolvido; contagem de Pontos de funo de aplicao, que engloba a contagem anterior mais os pontos de funo para migrao e converso de dados para que o produto entre em operao; e a contagem de Pontos de funo de projeto de melhoria, que mede o tamanho de uma evoluo/manuteno em um produto j desenvolvido. A seguir deve-se identificar o escopo da contagem e a fronteira da aplicao. Esse um passo importante, que cria os limites entre o produto e o(s) usurio(s) dele. Definido e o escopo e a fronteira, deve-se ento contar os pontos de funo de dados e os pontos de funo de transao.

49

Figura 5-9 - Procedimento de contagem de pontos de funo. Elaborado com base no manual do IFPUG.

As funes de dados podem ser de dois tipos: Arquivo Lgico Interno (ALI) e Arquivo de Interface Externa (AIE). O primeiro trata dos requisitos de dados que sero mantidos e consultados pela aplicao sendo contada e o segundo representa dados apenas consultados pela aplicao, mas mantidos por outro produto. As funes de transao representam funcionalidades que o produto fornece ao usurio para processar os dados. Elas podem ser de trs tipos: Consulta Externa (CE): so funes que consultam dados da aplicao e os envia para o usurio. Nessas funes nenhuma funo de dados alterada e no h nenhum clculo ou aplicao de frmulas sobre elas; Sada Externa (SE): similares s Consultas Externas, mas possuem frmulas de clculo ou dados derivados das funes de dados. Podem atualizar uma ou mais ALIs e alterar o comportamento do sistema; Entrada Externa (EE): so funes que partem de fora da fronteira da aplicao (normalmente disparadas pelo usurio) e que alteram uma ou mais ALIs. Dada a contagem de funes de dados e transaes, utilizam-se tabelas que, a partir de caractersticas dessas funes, identificam a complexidade delas em Baixa, Mdia e Alta. A partir da complexidade, outra tabela fornece o tamanho em pontos de funo no ajustados para cada funo dada sua complexidade (ver Tabela 5-7).

50

Tabela 5-7 - Pontos de funo de cada funo dada sua complexidade. Extrada do manual de contagem.
Complexidade Funo Baixa ALI AIE CE SE EE 7 5 3 4 3 Mdia 10 7 4 5 4 Alta 15 10 6 7 6

Em seguida, o padro do IFPUG determina o clculo de um fator de ajuste, que visa ajustar o tamanho do produto conforme caractersticas no funcionais que impactam a sua produtividade. No entanto, como a Organizao utiliza Pontos de funo no-ajustados, essa etapa no ser detalhada aqui.

5.2.3 A contagem de pontos de funo a partir do modelo do problema

De posse dos conceitos apresentados nas sees anteriores, descreve-se aqui a proposta para contagem dos pontos de funo diretamente no Modelo do Problema. A base dessa proposta a extensa utilizao de mecanismos de extenso da UML [OMG, 2005b], com utilizao de esteretipos e restries formais escritas em OCL [OMG, 2005a]. Foram criados diversos esteretipos, com propriedades para guardar informaes de contagem de Pontos de funo, e restries OCL associadas a eles. Os esteretipos e restries foram encapsulados em um Perfil UML que implantado na ferramenta de modelagem (Rational Software Architect) atravs de um plugin, que o mecanismo de extenso dessa ferramenta. Propostas semelhantes de contagem de pontos de funo sobre modelos UML j foram apresentadas anteriormente: [Caldiera et al., 1998], [Cantone et al., 2004], [Harput et al., 2005], [Uemura et al., 1999]. No entanto, essas propostas tentam automatizar parte ou toda a contagem de Pontos de funo a partir do modelo. A diferena para o que ser proposto aqui que a contagem no automatizada em nenhum momento, mas sim integrada ao Modelo do Problema. O analista deve tomar todas as decises de modelagem e mapeamento do modelo para as funes de dados e transao, como mostraremos na prxima seo. A proposta apresentada aqui se restringe contagem de Pontos de funo no ajustados. A utilizao do fator de ajuste vem sendo questionada em alguns trabalhos. Lokan [Lokan, 2000], por exemplo, mostra que a utilizao do fator no melhora em nada a correlao do tamanho com o

51

esforo. Outro motivo a adoo do COCOMO II (como descrito na seo 5.1), que utiliza Pontos de funo no-ajustados como entrada. Por ltimo, o fator de ajuste tambm no utilizado em normas como a IEEE Std 1045-1992 [IEEE, 1992] que define mtricas de produtividade em software.

5.2.3.1 Contagem das funes de dados

No Modelo do Problema, os dados mantidos pela aplicao so modelados como classes da UML, com esteretipo persistentEntity. Para contar os pontos de funo de dados diretamente no modelo, foram acrescentados atributos ao esteretipo persistentEntity, que tornou-se abstrato. Criou-se tambm 2 novos esteretipos: internalPersistentEntity e externalPersistentEntity, onde o primeiro representa as classes do produto sendo modelado e o segundo representa as classes de outros sistemas. A Figura 5-10 mostra o diagrama desses esteretipos.

Figura 5-10 - Esteretipos para contagem de funes de dados.

Na Tabela 5-8 feita uma descrio de cada atributo para contagem dos pontos de funo de dados. O mapeamento de classes de entidade para as funes de dados no direto e nem passvel de automao, cabendo ao analista especializado em contagem fazer os mapeamentos. Alm dos atributos nos esteretipos, o plugin para o Rational Software Architect facilita o preenchimento das informaes e o clculo da complexidade e do total de pontos de funo conforme o padro do IFPUG. A seguir, apresentaremos um exemplo da utilizao desse plugin num problema simples.

52

Tabela 5-8 - Atributos para contagem de funes de dados.

Atributo fpFunctionType fpComplexity fpNumRLR fpNumDER fpTotal fpDER Descrio Tipo de funo de dados: ALI, AIE ou nenhum. Complexidade da funo de dados: Alta, Mdia, Baixa. calculada por comando do usurio, a partir das demais informaes. Contagem de RLR9 (Registros Lgicos Referenciados). Contagem de DER (Dados Elementares Referenciados). Total de pontos de funo, calculado a partir da complexidade e do tipo. Lista de DERs considerados na contagem. Contm uma lista de atributos de classes (Property da UML). No aparece na Figura 5-10 por limitaes da ferramenta.

fpDERObservations Texto com observaes para contagem de DER. Utilizado para informar DERs que eventualmente no estejam modelados como atributos das classes, fpDEROther no estando, portanto includos no atributo fpDER. utilizado, por exemplo, para contar DERs referentes a relacionamentos. fpDERDescription fpRLR fpRLRObservations Documentao descritiva dos itens informados no campo fpDEROther. Lista de RLR considerados na contagem. Contm uma lista de classes. No aparece na Figura 5-10 por limitaes da ferramenta. Observaes para a contagem de RLR.

Um dos aspectos importantes da contagem das funes de dados, segundo as regras do IFPUG, que a identificao das funes deve ser sempre feita sob a perspectiva do usurio, independentemente de como isso se reflete na modelagem ou na soluo dada para o requisito. Como conseqncia, seria incorreto assumir que cada classe persistente corresponde a uma funo de dado (ALI ou AIE), j que a modelagem das classes reflete as decises de modelagem do analista de requisitos. Diversas classes podem compor uma nica funo de dado, e pode haver classes que sequer sejam consideradas para a contagem ( o caso dos code data, tratados no manual do IFPUG). Por isso, na abordagem aqui proposta, o analista quem deve avaliar quais classes devem ser agrupadas, e quais devem ser desconsideradas. Dado o diagrama de classes da Figura 5-11, extrado do exemplo do Praxis 3.0, o analista deve decidir quais classes sero agrupadas em cada funo de dados. Podemos ver na figura a identificao de 2 funes ALI. Nas funes que agrupam mais de uma classe, como o caso do grupo Pedido de compra e Item de compra, deve-se escolher uma delas como sendo a principal, cujo nome representa melhor o agrupamento. Nesse caso, foi escolhida a classe Pedido de compra.

Notar que a terminologia usada aqui a mesma do manual de contagem do IFPUG em

portugus, mas diferente da adotada no Praxis padro, que utiliza TAR e TER no lugar de RLR e DER.

53

Figura 5-11 - Exemplo de identificao de funes de dados em diagrama de classes.

Decididos os agrupamentos das funes de dados, seleciona-se a classe principal do grupo e so preenchidas as informaes de contagem. A lista de classes agrupadas (RLR Registros Lgicos Referenciados) montada selecionando-se quaisquer classes do modelo que possuem esteretipo de entidade (internalPersistentEntity e externalPersistentEntity). A lista de DER (Dados Elementares Referenciados) montada a partir dos atributos das classes selecionadas como RLR. Aps o preenchimento dos dados, o analista dispara o comando que calcula a complexidade e o total de pontos de funo daquela funo. Cabe explicitar que o total contado de DER e RLR no simplesmente a lista de classes e atributos selecionados, j que o analista pode alterar a contagem desses itens acrescentando, por exemplo, DERs adicionais como os que representam associao entre classes ou desconsiderar algum item que no atenda aos requisitos de contagem. A Figura 5-12 mostra o preenchimento das informaes da funo de dados Pedido de Compra no plugin desenvolvido.

54

Figura 5-12 - Preenchimento das informaes de contagem de funo de dados no plugin.

Para complementar o plugin, utilizou-se o arcabouo da UML 2.0 para prevenir alguns tipos de erros no processo de contagem. Foram criadas restries escritas em OCL (Object Constraint Laguange) [OMG, 2005a] associadas aos esteretipos das classes. Essas restries so checadas durante a validao disparada na ferramenta (Rational Software Architect) e automatizam vrias verificaes que antes eram feitas manualmente, durante os procedimentos de inspeo do modelo do problema. A Figura 5-13 ilustra uma dessas restries aplicadas contagem de funo de dados. Nessa restrio, quando uma classe com esteretipo internalPersistentEntity ou

externalPersistentEntity tem o atributo fpFunctionType com valor diferente de nenhum, ou seja, a classe principal de um agrupamento que representa uma funo de dados da contagem, ento o atributo fpNumRLR deve ser diferente de zero. Outro exemplo a verificao da consistncia da contagem. Se porventura um atributo includo na lista de DER de alguma funo de dados excludo, isso causar um erro na validao do modelo.

55

Esteretipo

Cdigo OCL da restrio

Restrio aplicada ao esteretipo

Figura 5-13 - Restrio OCL aplicada ao esteretipo utilizado na contagem de PF.

Os benefcios das restries em termos de reduo do retrabalho ainda no puderam ser medidos, j que sua primeira aplicao ainda est em progresso em um projeto executado pela Organizao.

5.2.3.2 Contagem das funes de transao

Para a contagem das funes de transao, o mesmo arcabouo proposto na seo anterior foi desenvolvido. As funes de transao so mapeadas nos fluxos dos casos de uso do produto. Aqui, assim como na contagem de funes de dados, o mapeamento manual e depende da interpretao de analista especializado. Nem todos os fluxos so mapeados em funes de transao. Foi criado um esteretipo abstrato chamado eventFlow do qual os esteretipos para fluxos do Praxis 3.0 passam a ser filhos, como ilustrado na Figura 5-14.

56

Figura 5-14 - Esteretipos para contagem de funes de transao.

No apresentaremos aqui o detalhamento completo como feito para as funes de dados por ser extremamente semelhante, mas ressaltaremos as diferenas. A primeira delas com relao seleo dos itens que comporo a lista de ALR (Arquivos Lgicos Referenciados). Enquanto para funes de dados pode-se escolher quaisquer classes de entidade do modelo para compor a lista de RLR, nas funes de transao, quando o usurio abre a tela de seleo da lista de ALR, o plugin exibe apenas as funes de dados que participam da colaborao que realiza o caso de uso (ver seo 5.2.1 que detalha o modelo do problema). Isso garante que a lista de classes da colaborao se mantenha ntegra. A segunda diferena na seleo dos DER (Dados Elementares Referenciados). Nas funes de dados, escolhem-se atributos das classes agrupadas na lista de RLR. Aqui, a ferramenta permite ao usurio selecionar apenas atributos de classes de fronteira (que possuem esteretipos prprios) que participam da colaborao, que representam os campos das telas que participaro da transao. O analista tambm dispe dos recursos necessrios para contar ALRs e DERs que no sejam mapeados diretamente para classes e atributos, como por exemplo, a emisso de mensagens pela aplicao, que conta como 1 DER. Da mesma forma como foi feito para a contagem de funes de dados, vrias restries OCL foram criadas para garantir a integridade da contagem e prevenir erros no preenchimento das informaes.

57

5.2.4 A integrao com o cadastro de requisitos

Na seo anterior foi apresentada a proposta para contagem de pontos de funo diretamente no Modelo do Problema. A partir das informaes preenchidas no modelo, a contagem de pontos de funo atualizada automaticamente no Cadastro de Requisitos do projeto, que o artefato oficial da contagem. Para isso, o analista faz um mapeamento dos requisitos aos elementos de modelagem, como ilustrado na Figura 5-15. O mapeamento de funes de dados e de transao para os elementos do Modelo do Problema no cobre todos os itens que so considerados em uma contagem. Para tratar esse problema, foi criado no Cadastro de Requisitos um tipo especial de requisito denominado Requisito no-mapeado, onde o analista poder complementar a contagem de Pontos de funo diretamente no Cadastro de requisitos para os itens que no puderam ser mapeados.

Figura 5-15 - Mapeamento entre elementos do Modelo do Problema e Cadastro de Requisitos.

Finalizado o procedimento de contagem, um relatrio final com o seu detalhamento emitido automaticamente a partir do Cadastro de Requisitos para ser consumido por clientes em um formato mais amigvel e sem necessidade de instalao das ferramentas utilizadas pela Organizao. Um trecho do relatrio desenvolvido pode ser visto na Figura 5-16. Alm da integrao entre o Modelo do Problema e Cadastro de Requisitos para fins de contagem de Pontos de funo, o plug-in mencionado nas sees anteriores, cria, automaticamente, rastreabilidade entre os requisitos do Cadastro de Requisitos a partir de informaes disponveis no Modelo do Problema. Por exemplo, se uma determinada entidade persistente participa da colaborao que realiza um caso de uso, o plug-in cria a rastreabilidade desse caso de uso para a

58

entidade. Diversas regras como essa foram includas no plug-in. Com isso, a anlise de impacto de alteraes de requisitos torna-se mais fcil para os colaboradores.

Figura 5-16 - Relatrio de contagem de PF gerado automaticamente.

5.2.5 O processo de contagem de Pontos de funo de alterao

Como relatado na seo 4.2.2, um dos problemas diagnosticados na Organizao a manuteno da contagem de pontos de funo dos produtos. Quando ocorrem alteraes de requisitos durante o projeto, a respectiva contagem da alterao no registrada e nem o tamanho atual do produto mantido. Essa falha na coleta ocasionou algumas limitaes nesse trabalho, como, por exemplo, o problema para obter a mdia de PF/LOC dos projetos da Organizao, como descrito na seo 5.1.4. A soluo apresentada nas sees anteriores, para contagem de Pontos de funo diretamente no Modelo do problema resolve parte do problema, que manter a contagem final do produto atualizada. Essa contagem atualizada equivale contagem de Pontos de funo de aplicao do manual do IFPUG. No entanto, persiste o problema de contar os Pontos de funo de alteraes (procedimento de contagem para projeto de melhoria) que normalmente tm seu custo repassado ao cliente. Para ilustrar e melhorar a compreenso, um produto cujo Modelo do problema tenha registrado 100 PF sofreu alteraes em seus requisitos e o levaram a uma nova contagem final de 110

59

PF. Entretanto, contando-se os Pontos de funo de alterao, calcula-se 20 PF de alteraes. Essa ltima contagem a que deve ser cobrada do cliente e no os 10 PF da diferena entre as contagens finais. A Organizao j conta com um sistema de gesto de alteraes, integrado com as demais ferramentas utilizadas na gesto de seus projetos. Ele foi implementado utilizando a ferramenta IBM Rational ClearQuest. O fluxo de trabalho para a gesto das alteraes de requisitos segue uma mquina de estados, como mostrado no diagrama de estados da UML na Figura 5-17, onde os eventos que causam as transies de estado so comandos disparados no aplicativo. Resumidamente, quando uma alterao registrada, ela recebida pelo gerente do projeto que pode rejeit-la ou designar algum para anlise. A pessoa designada inicia a anlise do impacto, associando os requisitos que sero afetados e realizando estimativa de esforo para as alteraes. Finalizada a anlise, o Gerente aprova ou rejeita a alterao. Caso aprovada, ela segue para execuo das alteraes, que quando finalizadas, so verificadas por outro colaborador, que pode aceitar ou reenviar para correo de problemas. Esse aplicativo funciona bem e traz informaes importantes para a Organizao (por exemplo, o esforo total gasto em alteraes), mas tem a deficincia de no lidar com a contagem dos Pontos de funo de alterao.

Figura 5-17 - Mquina de estados do sistema de gesto de alteraes existente.

60

A soluo proposta para contar os Pontos de funo de alterao implicou em duas mudanas no aplicativo. A primeira , no ato de finalizao da anlise, uma cpia dos requisitos associados e de todas as suas informaes de contagem de Pontos de funo, armazenada junto ao registro da alterao. Essa cpia das informaes realizada antes da execuo da alterao, quando ocorre a transio para o estado Analisada. A segunda mudana foi a criao de um novo estado na mquina: Contagem de PF realizada. Nesse ponto do fluxo de trabalho, o Modelo do problema e o Cadastro de requisitos j tiveram a contagem final de Pontos de funo atualizadas, alm dos demais artefatos impactados j terem sido alterados, como por exemplo, Modelo da soluo, Especificao de testes e Cdigo fonte. Na transio para esse novo estado final, o especialista em contagem monta uma nova lista de requisitos associados alterao, baseada na lista inicial, removendo os requisitos que foram excludos, mantendo os que foram alterados e incluindo os novos. Comparando as duas listas, o aplicativo calcula automaticamente, conforme as regras do IFPUG, o total de Pontos de funo de alterao e faz o registro dessa contagem no aplicativo. A Figura 5-18 exemplifica, de forma simplificada, como a contagem de Pontos de funo de alterao pode ser obtida atravs da comparao das duas listas. Note que a contagem final no foi alterada, mantendo-se em 21 PF, mas a contagem da alterao registrou 28 PF.

Pontos de funo de alterao

Figura 5-18 - Exemplo de contagem de Pontos de funo de alterao.

A contagem de Pontos de funo de alterao definida pelo IFPUG sujeita a questionamento, j que qualquer alterao em uma funo de dados ou transao implica em contar a funcionalidade inteira novamente. A incluso de um simples campo em uma tela faz com que a contagem dos Pontos de funo de alterao equivalha ao desenvolvimento da funcionalidade do zero. Como exemplo, a funo de dado Cotao Eletrnica, mostrada na Figura 5-18, teve um novo atributo includo, mas o procedimento de contagem determina que sejam contados como se fosse uma

61

nova funo de dados. Por esse motivo, a Organizao adota o procedimento do The Netherlands Software Metrics Users Association (NESMA) [NESMA, 2001] para contar os Pontos de funo de alterao. O mtodo do NESMA tenta corrigir essa distoro aplicando um fator de impacto na contagem final. Esse fator de impacto, que varia entre 0,25 a 1 para funes de dados e de 0,25 a 1,5 para funes de transao, multiplicado pela contagem final de Pontos de funo aps as alteraes. A contagem final obtida pelo mesmo procedimento do IFPUG. Na Tabela 5-9 apresentado um resumo do clculo do fator de impacto para cada tipo de alterao nos requisitos. Note que no mtodo do NESMA contam-se Pontos de funo para alteraes cosmticas, como a troca de um rtulo de um campo, ao contrrio do procedimento do IFPUG que as ignora. Na Figura 5-19 o exemplo de alterao apresentado na Figura 5-18 refeito utilizando o mtodo do NESMA. O procedimento de contagem pelo mtodo do NESMA foi tambm incorporado no aplicativo de Gesto das alteraes. A diferena que o especialista em contagem deve informar dados adicionais para cada funo alterada para a sim, o aplicativo fazer o clculo do nmero de Pontos de funo de alterao.
Tabela 5-9 - Clculo do fator de impacto para contagem de PF de alterao do mtodo NESMA.
Tipo de funo Tipo de alterao Incluso Excluso Dados Alterao 1 0,4 Calcula-se a porcentagem de DERs alterados (includos + excludos + modificados). Com base na porcentagem, consulta-se uma tabela que define o fator entre 0,25 at 1. Incluso Excluso 1 0,4 Calcula-se a porcentagem de DERs e ALRs alterados Transao Alterao (includos + excludos + modificados). Com base nas duas porcentagens, consulta-se uma tabela que define o fator entre 0,25 at 1,5. Alterao cosmtica 0,25

Fator de impacto

62

Pontos de funo de alterao

Figura 5-19 - Exemplo de contagem de PF de alterao pelo mtodo do NESMA.

Com a proposta acima, a Organizao resolveu as questes de registro da contagem de Pontos de funo de alterao em seus projetos. Esse aplicativo est sendo testado j em um projeto atualmente em execuo. A utilizao do mtodo do IFPUG ou do NESMA para contagem definida junto ao cliente na contratao do projeto, mas o registro realizado das duas formas para estudos futuros de correlao do tamanho da manuteno e o seu esforo, que atualmente estimado pelo responsvel na anlise da alterao com base apenas em sua opinio.

5.3 O processo de planejamento macro dos projetos

Nessa seo sero endereadas as questes relacionadas ao planejamento macro dos projetos, que consiste em estimar o perfil de equipe, esforo e durao total de cada iterao e fase do projeto, conforme o escopo previsto em cada uma. O Planejamento macro realizado no incio de cada fase do projeto. Aps o planejamento macro, ao iniciar uma iterao, ocorre o planejamento detalhado, que ser discutido na seo 5.4. Durante a fase de diagnstico deste programa de melhoria, foi identificado que o Planejamento macro dos projetos no segue um procedimento bem definido. Cada gerente planejava da forma que lhe era mais conveniente, mas foi identificado que a prtica mais comum era a utilizao de dados histricos para extrair a mdia de esforo para cada atividade do processo dada a complexidade do escopo, que era definido de forma qualitativa em baixa, mdia e alta. Para ilustrar os dados consultados, a Tabela 5-10 mostra um exemplo fictcio. A partir dos dados histricos, o gerente elaborava uma Estrutura Analtica do Projeto (EAP) baseada no processo documentado, j com o ltimo nvel de detalhamento das atividades, e

63

preenchia o esforo estimado para cada uma e o perfil de profissional que a executaria. As atividades que no estavam diretamente ligadas ao escopo do projeto, como a prpria gesto do projeto, eram estimadas separadamente apenas na opinio do gerente. Esse procedimento era realizado utilizando a ferramenta Microsoft Project. Assim, eram obtidos o esforo total, equipe necessria e prazo de cada iterao e fase.
Tabela 5-10 - Exemplo de tabela utilizada no planejamento macro.
Complexidade Tarefa Elaborar desenho externo Apoiar elaborao do desenho externo Inspecionar usabilidade Corrigir e verificar (usabilidade) Inspecionar modelagem Corrigir e verificar (modelagem) Inspecionar mapeamento de anlise Corrigir e verificar (mapeamento) Inspecionar testabilidade Corrigir e verificar (testabilidade) Especificar testes Inspecionar especificao de testes Corrigir e verificar Alta 40 h 8h 6h 8h 8h 10 h 8h 10 h 6h 8h 32 h 16 h 12 h Mdia 32 h 6h 4h 6h 6h 8h 6h 6h 6h 6h 32 h 16 h 12 h Baixa 24 h 6h 4h 6h 4h 6h 4h 6h 4h 6h 16 h 8h 8h

Esse procedimento foi executado em vrios projetos no s para o planejamento macro das iteraes, mas tambm para o planejamento detalhado, como relatado na seo 5.4. A diferena que no planejamento macro so usados recursos genricos, como: Programador Jnior, Analista de requisitos Snior, etc., enquanto no planejamento detalhado, os colaboradores reais so utilizados. Outra diferena que no planejamento detalhado os recursos devem ser nivelados para evitar superalocao, ou seja, planejar mais horas do que a quantidade que o colaborador trabalha. Para avaliar a acurcia desse procedimento, foi coletado de um grande projeto, o esforo estimado e o realizado das 4 atividades do processo de desenvolvimento que mais consomem esforo (dentre as planejadas com o procedimento descrito acima). Nessa coleta foram consideradas somente as atividades executadas sem alteraes de escopo durante sua execuo. Alm disso, foram excludas tarefas com esforo real pequeno: menor que 20h. O motivo que em tarefas de pequeno esforo, as variaes implicam em erros muito grandes. Por exemplo, se um esforo planejado de 3h realizado em 2h, o MRE calculado 50%. O resultado dessa anlise apresentado na Tabela 5-11.

64

Tabela 5-11 - Erros medidos no planejamento macro.

Tarefa Codificar unidade Elaborar desenho externo Especificar testes de integrao Executar testes de integrao PRED(0,25) 36,8% 44,6% 48,8% 66,7% MMRE 52,82% 34,79% 29,16% 21,10% Int. Conf (95%) 20,1% 3,8% 4,5% 5,3% Amostra 39 92 84 48

Pelos dados coletados podemos observar que o procedimento adotado para o planejamento macro apresenta uma acurcia baixa (embora no seja desastrosa). Um dos motivos provveis a classificao subjetiva da complexidade dos casos de uso. Outro problema identificado que o procedimento cobre apenas as atividades ligadas diretamente produo do escopo do produto, ou seja, no considera atividades como reunies, gesto do projeto e treinamentos. Talvez essa seja uma explicao para a grande variao no esforo total dos projetos identificada na seo 4.2.1, que indicou um MMRE de 45,9% na base histrica da Organizao, j que esse procedimento adotado para o planejamento macro similar ao procedimento usado para o oramento de esforo dos projetos para elaborao das propostas. No foi possvel, no escopo desse trabalho, realizar coletas para os erros da estimativa total das iteraes. A Organizao mantm um repositrio detalhado no nvel de Tarefas, mas informaes consolidadas de iteraes ficam armazenadas apenas nos cronogramas dos projetos. Isso dificulta a coleta automtica via consultas ao banco de dados e implica em recuperar as vrias verses do artefato para identificar qual foi realmente a primeira linha de base do planejamento macro das iteraes. Esse problema ser endereado na seo 5.5. Na tentativa de diminuir os problemas encontrados no procedimento adotado para o planejamento macro, sero utilizados os bons resultados colhidos na adoo do COCOMO (ver seo 5.1.3). Tambm ser proposta uma simplificao no procedimento inacurado adotado atualmente, baseada no processo de planejamento macro do Praxis 3 padro10. Por ltimo, a proposta visa o planejamento macro para a utilizao em projetos executados em ciclo de vida espiral, que passou a ser adotado pela Organizao na atualizao de seu processo de desenvolvimento para a verso 3 do Praxis. A nova forma de realizar o planejamento macro consiste de quatro passos:

10

O planejamento macro da Organizao corresponde ao Planejamento Geral do Projeto no

Praxis 3 padro.

65

1. Obter o esforo total estimado para o projeto, utilizando o COCOMO. 2. A partir da lista de requisitos (casos de uso) identificados do produto, distribu-los entre as iteraes do projeto. O percentual de escopo em cada iterao, medido em Pontos de funo no ajustados, indicar o percentual do esforo naquela iterao. 3. Coletar da base histrica o perfil de equipe necessrio para o projeto. Essa informao obtida pela distribuio do esforo do projeto para cada tipo de atividade. Cada atividade pertence a uma disciplina (ou fluxo) e executada por um papel especfico. 4. De acordo com a disponibilidade da equipe e pelas metas de prazo do cliente, estimar o prazo para cada iterao. importante o gerente ter em mente os efeitos da deseconomia de escala existente em software [Boehm et al., 2000]. Para melhorar o entendimento da proposta ser apresentado um exemplo, com algumas informaes extradas do prprio exemplo do Praxis 3 padro. Supondo um esforo total estimado pelo COCOMO de 11,9 Pessoas-ms (1.808,8 h), distribumos esse esforo conforme a proporo do escopo (em Pontos de funo no-ajustados) em cada iterao, como mostra a Tabela 5-12.
Tabela 5-12 - Exemplo de planejamento macro. Distribuio do esforo por iterao.
Tamanho Iterao Funo (Caso de uso) (PF noajustados) E1 E2 C1 Gesto de Usurios Gesto de Mercadorias Gesto Manual de Estoque, Gesto de Fornecedores Operao de Venda, Abertura do Caixa, Fechamento do Caixa Gesto de Pedidos de Compra Emisso de Relatrios, Emisso de Nota Fiscal 26 30 8 + 30

Frao do escopo 13,6% 15,7% 19,9%

Esforo (h)

246,2 284,1 359,9

C2 C3 C4 Total

14 + 14 + 4 35 20 + 10

16,8% 18,3% 15,7% 100,0%

303,0 331,5 284,1 1808,8

A seguir recupera-se dos dados histricos a distribuio do esforo dos seus projetos nas disciplinas, que esto intimamente ligadas s equipes da Organizao. A Tabela 5-13 ilustra como os dados devem ser recuperados. A partir desse ponto, essa proposta difere do procedimento apresentado no Praxis 3 padro.

66

Tabela 5-13 - Exemplo de planejamento macro. Distribuio de esforo por disciplina.

Disciplina Desenho & Impl. Eng. Processos Gesto de Alteraes Gesto de projeto Qualidade Req. & Anlise Testes Usabilidade Total geral Distribuio do esforo 56,1% 0,1% 0,3% 11,4% 0,2% 2,9% 23,7% 5,4% 100,0%

A partir da Tabela 5-12 e da Tabela 5-13 o gerente ser capaz de estimar os recursos necessrios. Por exemplo, na iterao C1, ser necessrio um esforo de 85,3h (23,7% x 359,9h) de um analista de testes (papel responsvel pelas atividades da disciplina de Testes). A partir da, o prazo da iterao pode ser calculado conforme a disponibilidade/necessidade dos recursos. No caso de o prazo ser uma restrio do problema, a lgica inversa deve ser usada, estimando-se a quantidade de recursos necessrios a partir do prazo fixado pelo cliente e do esforo estimado. A proposta apresentada acima para o planejamento macro, baseada no Praxis 3 padro, relativamente mais simples que o procedimento atual adotado pelos gerentes. Acreditamos que ela mais racional e sujeita a menos subjetividade (como a classificao da complexidade do escopo realizada sem critrios objetivos), j que baseada apenas em dados histricos coletados durante a execuo dos projetos da Organizao. No entanto, necessrio valid-la durante a execuo de um projeto real. Como no foi possvel avaliar o erro total nas estimativas por iterao do procedimento atual, ser realizado um piloto no prximo projeto executado pela organizao utilizando os dois mtodos e posteriormente comparando a acurcia de cada um para decidir pela mudana ou no no procedimento. A proposta apresentada acima leva em considerao que todos os casos de uso de uma iterao sero levados ao estado 100 (Completo). Entretanto, para casos em que seja necessrio realizar apenas parte do escopo de alguns casos de uso dentro de uma iterao, como lev-los do estado 20 (Detalhado) para o 40 (Desenhado), o mesmo raciocnio pode ser seguido. A informao extra necessria a distribuio do esforo por estado do caso de uso e por disciplina, como ilustrado com dados fictcios na Tabela 5-14.

67

Tabela 5-14 - Exemplo de distribuio de esforo por estado e por disciplina.

Estado Disciplina (Fluxo) 10 Requisitos Anlise Desenho Testes Implementao Gesto do Projeto Usabilidade Gesto da Qualidade Eng. de Processos Total % 0,9% 0,0% 0,0% 0,0% 0,0% 0,8% 0,1% 0,0% 0,0% 1,8% 20 5,5% 1,4% 0,5% 0,0% 0,0% 0,8% 0,2% 0,0% 0,0% 8,4% 30 2,6% 6,9% 0,7% 0,3% 0,0% 0,8% 0,3% 0,0% 0,1% 11,6% 40 0,1% 0,2% 4,7% 1,9% 5,9% 0,8% 0,4% 0,0% 0,3% 14,3% 50 0,1% 0,1% 4,4% 2,4% 5,4% 0,8% 0,1% 0,1% 0,0% 13,4% 60 0,1% 0,1% 4,4% 2,4% 5,4% 0,8% 0,1% 0,1% 0,0% 13,4% 70 0,1% 0,1% 4,4% 2,4% 5,4% 0,8% 0,1% 0,1% 0,0% 13,4% 80 0,1% 0,1% 4,4% 2,4% 5,4% 0,8% 0,1% 0,1% 0,0% 13,4% 90 0,1% 0,0% 0,5% 2,3% 1,0% 0,8% 0,2% 0,3% 0,1% 5,2% 100 0,0% 0,0% 0,2% 2,9% 0,3% 0,8% 0,1% 0,8% 0,0% 5,0% 9,4% 8,8% 24,3% 17,1% 28,7% 8,0% 1,6% 1,6% 0,5% 100,0% Total %

5.4 Estimativas para o planejamento detalhado das iteraes de um projeto

Nessa seo trataremos dos problemas apresentados na seo 4.2.4, que levanta os problemas relacionados com o planejamento detalhado das iteraes. Conforme j dito anteriormente, a atividade de codificao dos casos de uso a que consome mais esforo do volume total do projeto (aproximadamente 35%). O estudo apresentado na seo 5.3 mostra um MMRE de 52,8% quando se compara o esforo planejado e realizado. Essas estimativas eram realizadas predominantemente pelos gerentes do projeto, com base no histrico de outros projetos. O gerente se valia do procedimento descrito na seo 5.3, utilizando uma tabela similar ilustrada pela Tabela 5-10. A partir da o gerente cria uma nica tarefa de codificao para um determinado implementador. Para tentar diminuir os erros das estimativas foi proposto um novo processo para o planejamento dessas tarefas. A primeira alterao foi com relao a ter uma nica tarefa de codificao para cada caso de uso. Resolveu-se utilizar a tcnica de decomposio e recomposio, como proposto pelo PMBoK [PMI, 2004]. Segundo McConnell [McConnell, 2006], essa tcnica tira

68

proveito da Lei dos grandes nmeros, onde os erros das estimativas das partes pequenas tendem a se anular (superestimativas cancelam subestimativas), produzindo erros totais menores. Dessa forma, o implementador designado para a codificao passou a propor uma diviso dessa tarefa em tarefas menores, com no mximo 40h. Para cada uma das tarefas deve ser informado uma srie de itens que sero implementados: componentes de interface, regras de negcio e classes de entidade. A segunda alterao foi o responsvel pela estimativa, que passou a ser feita pelo prprio implementador que executar a codificao. McConnell [McConnell, 2006] afirma que essa deve ser a tcnica preferida para estimativas no nvel de tarefas de um projeto. Para facilitar o lanamento dos dados foi criada uma planilha, ilustrada na Figura 5-20, que preenchida pelo implementador. Aps o preenchimento, a planilha encaminhada ao gerente que criar as tarefas no cronograma do projeto.

Figura 5-20 - Planilha para apoio ao planejamento de tarefas de codificao de caso de uso

Para validar essa proposta, o novo processo foi aplicado como projeto piloto em um mdulo de um dos projetos que estava em execuo na Organizao. Os resultados foram coletados para a codificao de 23 casos de uso. Para cada um deles foi montada uma planilha, ilustrada pela Tabela 5-15, que analisa os erros entre os esforos estimados e realizados. Os erros foram calculados utilizando-se o indicador MRE (ver seo 2.3, que trata dos indicadores de acurcia).

69

Tabela 5-15 - Coleta de dados para anlise de erros de estimativas realizadas pelos implementadores
Caso de uso Tarefas Revisar entidades e seus relacionamentos Criar regras de validao e testes unitrios Codificar controle e gestores CUD108 - Gesto de supresses de valorquantidade em item de processo Codificar povoador Codificar camada de fronteira Integrar internamente ao CUD Gesto de alteraes contratuais Executar testes de implementao Mdia dos erros (MMRE) Total 140 160,97 Estimado 16 30 20 30 28 8 8 Realizado 4,92 7,98 23 20,29 83,98 8,69 12,11 MRE 225,2% 275,9% 13,0% 47,9% 66,7% 7,9% 33,9% 95,8% 13,0%

No grfico da Figura 5-21 mostramos os resultados para os 23 casos de uso que utilizaram a nova proposta. Pode-se observar que em quase todos os casos, o erro total foi menor do que a mdia da magnitude dos erros relativos (MMRE) das tarefas individuais. Apenas para melhorar o entendimento, o ponto 6 do grfico corresponde aos dados coletados na Tabela 5-15. Note tambm que a escala do eixo y do grfico foi ajustada para mostrar no mximo at 150%, pois 3 casos de uso tiveram valores da mdia muito acima disso, o que distorceria a exibio.

Erros nas estimativas

140,0% 120,0% 100,0% 80,0% 60,0% 40,0% 20,0% 0,0% 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Total Mdia

Figura 5-21 - Comparao do erro total por caso de uso e da mdia dos erros.

Calculando-se a mdia dos erros totais (barra da esquerda, mais clara, em cada ponto), chega-se a um MMRE de 21,8% 5,7% (com 95% de confiana). Esse resultado significativamente

70

melhor do que o observado nos outros mdulos do projeto, cujo MMRE foi de 52,8% para as tarefas de codificao dos casos de uso. Utilizando o indicador PRED(0,25) para avaliar esses dados, chegase a 69,6%, em comparao com 36,8% medido nos outros mdulos. Outro fenmeno observado nesse projeto piloto foi a melhora das estimativas de implementadores que passaram por esse procedimento por mais de uma vez. Na Tabela 5-16 pode-se observar a reduo do erro total das estimativas de dois implementadores que codificaram 3 casos de uso cada (dentre os 23 da amostra). Esse fato indica um potencial de melhora nos nmeros apresentados no pargrafo anterior.
Tabela 5-16 - Melhora das estimativas dos implementadores.
Erro total (MRE) Implementador 1 estimativa 2 estimativa 3 estimativa 1 2 46,30% 44,80% 15,50% 37,50% 13,50% 28,80%

Diante dos resultados obtidos, esse procedimento de estimativa foi oficializado e incorporado ao processo de planejamento detalhado das iteraes utilizado pela Organizao. Ele passar a ser utilizado no s para as atividades de codificao, mas para todas as outras atividades que sero executadas em uma iterao.

5.5 O repositrio centralizado de dados dos projetos

No relatrio de diagnstico apresentado no Captulo 4, um dos problemas relatado foi a dificuldade de obteno de informaes dos projetos executados anteriormente. A Organizao j utiliza o PSM [McGarry et al., 2001] como mtodo para definir, coletar e armazenar suas mtricas, atendendo assim, rea de processo Measurement and Analysis (MA) do nvel 2 do CMMI [CMMI, 2006]. Entretanto, os diversos dados coletados encontram-se em diversas fontes e formatos. Em alguns casos so mantidos em planilhas ou documentos texto, o que dificultou em muito a sua coleta, inclusive dos dados que serviram como base para as demais aes propostas neste trabalho. Uma das aes propostas nesse mesmo relatrio foi a construo de um repositrio centralizado dos dados dos projetos, que servir de base para as estimativas em projetos futuros. O grande desafio aqui definir um formato no qual esses dados sero armazenados e automatizar, na

71

medida do possvel, a coleta das informaes das diversas fontes, j que as informaes continuaro a estar disponveis em aplicativos, bancos de dados, planilhas e documentos diversos que esto em constante evoluo. Existem no mercado, vrias ferramentas que se propem a solucionar esse problema, mas acreditar que um nico produto ser a panacia para esse desafio no nos parece razovel, j que cada organizao tem suas prprias caractersticas e especificidades. Um estudo realizado por Auer e outros [Auer et al., 2003], que parece corroborar nossa hiptese, procurou avaliar diversas ferramentas de coleta e armazenamento de mtricas e chegaram concluso de que a utilizao de um aplicativo dessa natureza envolve um alto custo de personalizao, interveno manual do usurio e necessidade de converso de dados sujeita a erro humano. Olsina e outros [Olsina et al., 2002] propuseram um repositrio universal para mtricas de projetos de desenvolvimento de software. A idia apresentada consiste num banco de dados flexvel e aderente a qualquer processo de desenvolvimento, pois ele se baseia no prprio conceito de processo, onde uma atividade produz e consome artefatos, gasta recursos e as mtricas podem estar associadas a qualquer um desses elementos. Outra proposta de repositrio centralizado de mtricas foi apresentada por Harrison [Harrison, 2004]. Segundo ele, a sua proposta, que consiste num modelo de classes UML, flexvel bastante para armazenar mtricas de diversas naturezas. Embora as propostas de Olsina e Harrison sejam realmente flexveis para armazenamento dos dados, elas introduzem outro obstculo: a recuperao da informao armazenada. Em ambas as propostas, recuperar a informao requer um alto grau de entendimento de como os dados esto armazenados e na confeco de consultas extremamente complexas ao banco de dados. O esforo para obteno de uma informao nova, que no havia sido pensada previamente, implica na interveno de um especialista para elaborar uma nova consulta que atenda a essa nova necessidade. Em vista desses desafios, uma proposta que parece mais razovel, a construo de um Data Warehouse utilizando modelagem dimensional, cujos principais defensores, e usualmente chamados de pais do DW, so Kimball [Kimball & Ross, 2002] e Inmon [Inmon, 2005]. O grande diferencial da modelagem dimensional, segundo os autores, a facilidade da obteno de informaes, mesmo para perguntas que sequer tenham sido pensadas durante a modelagem do repositrio. Por essa razo, a Organizao decidiu adotar essa estratgia. Os dois autores divergem sobre alguns pontos relacionados ao projeto do DW, embora o conceito principal de um repositrio centralizado de fcil consumo seja a mesmo. A principal diferena entre as duas abordagens, como o prprio Inmon descreve em seu livro [Inmon, 2005] est

72

relacionada com o formato em que os dados ficam armazenados no DW. Inmon defende um modelo relacional normalizado enquanto Kimball defende um modelo multidimensional desnormalizado. A proposta de Inmon mais flexvel a mudanas dos requisitos de informao e torna o processo de extrao dos dados das diversas fontes mais fcil, enquanto a proposta de Kimball de mais fcil consumo pelos usurios e apresenta desempenho melhor para as consultas. Como o foco do resultado da ao que apresentaremos nessa seo o usurio final e pelo fato da Organizao possuir uma Equipe de Engenharia de Processos dedicada, que entre suas atribuies est a gesto das mtricas da Organizao, resolveu-se adotar a metodologia proposta por Kimball. Nas duas sees seguintes apresentaremos, respectivamente, uma introduo modelagem dimensional de Kimball e o modelo que a Organizao projetou para armazenar os dados de seus projetos, que futuramente fomentaro as estimativas. Vale ressaltar que a definio desse repositrio no o foco desse trabalho. O objetivo dessa ao fornecer um repositrio centralizado que atenda as principais demandas de informao para realizar as estimativas. Em um prximo ciclo de melhoria do ProMOTe a Organizao poder investir em melhores prticas para construo desse repositrio.

5.5.1 Data Warehouses e a modelagem dimensional

Um Data Warehouse (DW), como o prprio nome diz, consiste no armazm de dados de uma organizao, de onde a informao deve ser extrada. Ele se contrape aos sistemas transacionais, que so onde as informaes so imputadas. De acordo com Kimball e Ross [Kimball & Ross, 2002], alguns dos requisitos para um bom DW so:

tornar os dados da organizao de fcil acesso; apresentar a informao de forma consistente, ou seja, a informao recuperada deve ser confivel;

deve ser adaptvel e resiliente s mudanas dos processos da organizao, sem ter que ser refeito a cada nova demanda;

deve servir como base para melhores decises dos gestores;

73

Como pode-se observar, necessrio no s um bom especialista em banco de dados, que conhea bem os repositrios dos aplicativos da organizao, mas tambm uma boa estratgia para apresentao dos dados consolidados para os usurios, que no so, necessariamente, proficientes em informtica. Com isso em mente, um DW foi dividido em componentes, ilustrados na Figura 5-22. O primeiro componente consiste nas fontes de dados da organizao, armazenados em diversos repositrios e formatos diferentes, como bancos de dados relacionais, documentos texto e planilhas eletrnicas. Muitas vezes, algumas informaes esto duplicadas nos diversos aplicativos. Um exemplo tpico o cadastro dos funcionrios, onde cada aplicativo mantm sua prpria base de dados. Dessa forma, um especialista deve extrair as informaes das diversas fontes e lev-la para o segundo componente, onde as informaes so deduplicadas, padronizadas e organizadas. Essa rea de tratamento da informao de acesso restrito aos especialistas em banco de dados, ou seja, os usurios finais no acessam esse componente. Em seguida os dados so carregados no terceiro componente, que so os Data Marts, que armazenam a informao em formato dimensional. Esse processo de extrao, transformao e carga dos dados comumente chamado de ETL (Extration Transformation Load). A partir dos Data Marts, os usurios consultam as informaes desejadas utilizando o aplicativo de sua preferncia.

Fontes de dados: - Sistemas transacionais - Documentos - Planilhas

rea de tratamento e transformao de dados

rea de apresentao dos dados

Ferramentas de acesso aos dados

Extrao

Fonte 1

Extrao

Fonte 2

Limpeza, Deduplicao e padronizao dos dados que so armazenados em tabelas relacionais ou arquivos texto

Carga

Dados armazenados em formato dimensional aderente aos processos da organizao

Consultas

Ferramentas de consultas e gerao de relatrios analticos

Extrao

Fonte 3

Figura 5-22 - Componentes de um DW. Adaptado de [Kimball & Ross, 2002].

A modelagem dimensional difere significativamente da modelagem relacional na

74

Terceira Forma Normal (3NF), embora ambas sejam armazenadas em bancos de dados relacionais. O objetivo da modelagem 3NF eliminar a redundncia dos dados, criando diversas entidades que relacionam entre si. A modelagem 3NF extremamente til para aplicativos transacionais, onde as informaes so imputadas, pois a incluso, atualizao ou remoo de uma informao ocorre apenas em uma poro pequena dos dados, melhorando o desempenho dos aplicativos. Entretanto, modelos normalizados so tipicamente complicados demais para os usurios extrarem as informaes que necessitam. A entra a modelagem dimensional, que propem um armazenamento diferente para os dados, em poucas entidades, consistindo em um modelo extremamente desnormalizado, com a vantagem de apresentar os dados de forma mais compreensvel aos usurios finais. De forma simplificada, a modelagem dimensional divide a informao em dois tipos de tabela: Fato e Dimenso. As tabelas de fatos armazenam as medidas numricas de desempenho dos processos da organizao. Cada registro em uma tabela de Fato representa uma medida de algum fato que ocorreu durante a execuo de um processo. O fato ocorre na interseo de uma ou mais dimenses, que representam a descrio textual do processo. Os atributos das tabelas de dimenso so utilizados para definir os relatrios e consultas que se deseja realizar no DW. Para exemplificar, o processo de vendas de uma rede de lojas que vendem produtos quaisquer, poderia ser representado por um modelo dimensional como o da Figura 5-23. Note que o modelo desnormalizado. A Dimenso Data, por exemplo, que contm um registro para cada dia do ano, duplica informaes como Ano e Ms, que poderiam ser obtidas diretamente da data. A justificativa de Kimball que dessa forma os usurios conseguem realizar consultas mais facilmente e com melhor desempenho.

Figura 5-23 - Exemplo de modelo dimensional para uma rede de lojas.

75

5.5.2 O modelo dimensional da Organizao

Nessa seo ser apresentada a proposta de modelagem dimensional que suportar o armazenamento dos dados de projetos da organizao. Como dito anteriormente, a Organizao j havia construdo um Plano de Medio utilizando o PSM. O foco desse plano foi a coleta de informaes relacionadas ao retrabalho e qualidade da produo dos artefatos. Analisando o Relatrio de Diagnstico, pode-se observar que vrias necessidades de informao para fomentar as estimativas no esto cobertas no Plano de Medio anterior. Ento, foi realizada uma nova rodada do ciclo do PSM para identificar as medidas e indicadores que deveriam estar presentes no repositrio centralizado. Os resultados, consolidando os dois planos de medio, so apresentados na Tabela 5-17. Foram omitidas as construes mensurveis e medidas identificadas por limitao de espao.

Tabela 5-17 - Necessidades de informao da Organizao e indicadores propostos.

Necessidade de informao Indicadores Distribuio do Total de Horas de Trabalho e Retrabalho por Pacote de trabalho Distribuio do Retrabalho Retrabalho no projeto Evoluo do Percentual das Inspees Aceitas por Mdulo Evoluo Mensal do Retrabalho Retrabalho Total Acumulado Eficincia dos procedimentos de qualidade Nmero de defeitos encontrados por esforo de reviso Nmero de Defeitos no detectados por Inspeo Nmero de Defeitos Detectados por Inspeo e por Gravidade Qualidade dos artefatos produzidos pela equipe Evoluo do nmero de defeitos detectados por artefato Evoluo do nmero de defeitos abertos e corrigidos Nmero de defeitos detectados pelo Cliente Distribuio do esforo por estado do caso de uso Distribuio do esforo Distribuio do esforo por artefato Distribuio do esforo por atividade do processo Acompanhamento de custo do Valores adquirido, planejado e real do custo atual do projeto. projeto Valores adquirido, planejado e real do custo atual do projeto por iterao. Evoluo do tamanho do produto em Pontos de funo Evoluo do nmero de Pontos de funo de alterao Progresso do escopo Nmero de casos de uso por estado alcanado Evoluo do nmero de LOC por categoria (conforme padro de contagem).

76

Prazo planejado e realizado por iterao Cumprimento do prazo Prazo planejado e realizado por atividade Evoluo do nmero de alteraes por Pacote de trabalho Estabilidade do produto Nmero de requisitos includos, alterados e excludos MMRE por atividade do processo Acurcia das estimativas PRED(0,25) por atividade do processo Nmero de horas por Ponto de Funo Produtividade da equipe Nmero de horas por Ponto de Funo de alterao Custo por Ponto de Funo

De posse dos indicadores e medidas identificados, o desafio agora propor um modelo dimensional que comporte esses dados de forma a tornar sua recuperao simples e gil pelos interessados. Um trabalho similar ao que est sendo proposto aqui foi apresentado por Becker e outros [Becker et al., 2006]. Eles tambm partiram de uma lista de medidas bsicas e derivadas e propuseram um modelo dimensional para armazen-las. A diferena que os autores propuseram uma estrutura intermediria que representa um metamodelo de um processo de desenvolvimento de software. Porm, no detalhado como feita a transformao do metamodelo para o modelo dimensional que propuseram. A proposta que ser apresentada abaixo, se valeu da proposta de Becker e outros [Becker et al., 2006], mas foi necessrio realizar vrios ajustes para atender as necessidades de informao da Organizao, que so diferentes das necessidades apresentadas no trabalho deles. Kimball e Ross [Kimball & Ross, 2002] sugerem uma seqncia de quatro passos para auxiliar na modelagem dimensional: Escolher um processo da organizao para ser modelado. A partir do processo

podemos derivar os fatos que ocorrem durante a execuo do processo. Declarar a granularidade dos fatos identificados. Isso significa explicitar o que cada

um dos registros da Tabela Fato representa. Enumerar quais dimenses se aplicam a cada registro de cada fato. Corresponde a

identificar os atributos de caracterizao daquele fato. Identificar as medidas numricas que podem ser coletadas em cada registro do fato.

Embora os passos acima auxiliem na racionalizao da modelagem, o resultado est sempre sujeito criatividade do modelador frente aos requisitos dos usurios. Outra pessoa com os mesmos requisitos de informao em mente poderia produzir um modelo diferente.

77

O processo escolhido para modelagem foi o prprio processo de desenvolvimento da Organizao. Dividir esse processo em processos menores poderia levar a modelos difceis de integrar no futuro. Os fatos identificados durante a modelagem, j com a declarao de granularidade, so apresentados na Tabela 5-18.
Tabela 5-18 - Fatos identificados durante a modelagem dimensional.
Fato Trabalho Defeito Descrio/Granularidade Consiste na execuo de alguma atividade por um colaborador em uma determinada data. Representa uma transao realizada em relao a um defeito, como deteco, correo, verificao, etc. a medida de tamanho em Pontos de funo no-ajustados de um determinado requisito em um determinado dia. a medida de tamanho em Linhas de cdigo de um determinado pacote de trabalho de uma determinada classificao em um determinado dia. o registro de uma alterao de escopo do produto. Contm o registro dirio do progresso do projeto, analisando os indicadores BCWS, BCWP, ACWP sugeridos no padro do PMBoK [PMI, 2004] para acompanhamento do projeto.

Tamanho em PF

Tamanho em LOC Alterao Progresso

A partir da Tabela 5-18, extraiu-se o modelo dimensional apresentado nas Figuras abaixo, que mostram o modelo lgico do banco de dados. Os atributos das dimenses so apresentados apenas no primeiro modelo em que ela aparece, para facilitar a leitura. Nos modelos, j constam as medidas numricas relacionadas a cada fato. As tabelas cujo nome inicia com Dim representam as dimenses e as iniciadas por Fact representam os Fatos. Um detalhamento completo dos atributos de cada uma das dimenses pode ser visto no Apndice A.2. Uma das questes endereadas na modelagem dimensional proposta foi o fornecimento da informao de custo dos projetos. Como relatado no Captulo 4, os gerentes de projeto da Organizao no tinham acesso ao custo individual dos colaboradores por questes de confidencialidade. A soluo proposta foi criar uma classificao dos cargos da Organizao de acordo com a equipe em que trabalha e com a sua experincia (Implementador I, Implementador II, Testador I, Testador II, etc.). Para cada categoria foi calculada uma mdia do valor hora dos colaboradores dessa categoria. Essa mdia utilizada para calcular o custo de execuo das tarefas, que fica armazenado na tabela Fato Trabalho (FactTrabalho) como mostra a Figura 5-24. Dessa forma os gerentes passam a planejar e acompanhar o custo em seus projetos. Essas categorias e respectivo histrico de custo mdio so mantidos no banco de dados do aplicativo Apropriao de horas (ver

78

seo 4.2.2), com acesso restrito aos gerentes da Organizao. Outra ao proposta que tambm foi tratada durante a elaborao do modelo dimensional foi o armazenamento dos dados das propostas. Na Dimenso Projeto (DimProjeto) ficam armazenados o custo, esforo e prazo que foram considerados para a elaborao da proposta apresentada ao cliente. Entretanto, vale ressaltar que esses valores consistem no oramento interno, sem a margem de lucro aplicada na proposta comercial, j que essa uma informao confidencial e de acesso restrito diretoria da Organizao. O processo de recuperao, transformao e carga dos dados, como era esperado, foi uma tarefa complexa, devido s vrias origens, duplicidade e falta de padronizao dos dados. Vrias tabelas auxiliares tiveram que ser confeccionadas para mapear entidades entre sistemas diferentes. Apenas para ilustrar, a Organizao possui 2 sistemas para registro de defeitos, sendo que um deles usado apenas para defeitos encontrados no cdigo executvel. Cada um dos sistemas possui o registro de requisitos separado e pequenas variaes nos nomes digitados forou a criao de uma tabela que mapeasse os requisitos entre os dois sistemas. A quantidade de particularidades tais como essa foi enorme e por serem especficas da Organizao e seus sistemas, no ser relatado aqui todo o processo de carga do modelo dimensional proposto.

79

Figura 5-24 - Fato Trabalho e Dimenses relacionadas.

80

Figura 5-25 Fatos de Tamanho (PF e LOC) e Dimenses relacionadas. 11

Figura 5-26 - Fato Defeito e Dimenses relacionadas.

11

A Dimenso Classificao LOC, na verdade, consiste de uma dimenso para cada vetor de

dados definido pela Organizao. Ver o apndice A.1.

81

DimProjeto PK keyProjeto PK

DimAlteracao keyAlteracao

FactAlteracao DimPacoteDeTrabalho PK keyPacoteDeTrabalho PK,FK1 PK,FK2 PK,FK3 PK,FK4 PK,FK5 PK,FK6 keyAlteracao keyProjeto keyPacoteDeTrabalho keyRequisito keyData keyTipoAlteracao PontosDeFuno DimTipoAlteracao PK keyTipoAlteracao TipoAlterao DimData PK keyData DimRequisito PK keyRequisito

Figura 5-27 - Fato Alterao e Dimenses relacionadas.

Figura 5-28 - Fato Progresso e Dimenses relacionadas.

Para validar o modelo apresentado acima foi realizada uma carga com dados de um grande projeto da Organizao que j havia sido encerrado. Ento, tentou-se obter os indicadores enumerados na Tabela 5-17 e foi possvel emitir relatrios de quase todos eles, com exceo dos indicadores baseados na contagem de Pontos de funo de alterao, j que ainda no foram coletados em nenhum projeto. Alguns desses relatrios so apresentados nas figuras abaixo. Eles foram

82

elaborados atravs do recurso de tabela dinmica do Microsoft Excel, conectando diretamente no servidor do DW.

Figura 5-29 - Distribuio de esforo de trabalho e retrabalho entre as Disciplinas

Figura 5-30 - Distribuio de esforo entre Disciplinas e Estados

A proposta acima foi apresentada e aprovada pelos os diretores e gerentes da Organizao. Durante as apresentaes surgiram algumas novas demandas e melhorias. O modelo proposto mostrou-se altamente resiliente s solicitaes: com pouco esforo foi possvel atend-las.

83

Captulo 6 Concluso

O trabalho apresentado aqui relatou a execuo de um programa de melhoria nas estimativas dentro de uma organizao desenvolvedora de software. O programa foi realizado seguindo um processo bem definido, o ProMOTe, e abordou as estimativas realizadas em todas as fases do ciclo de vida dos projetos de desenvolvimento de novos produtos. A partir de um diagnstico e de um levantamento bibliogrfico sobre os temas relacionados aos problemas encontrados foi possvel definir vrias aes de melhoria dos processos da Organizao. Dentre as melhorias propostas, algumas foram validadas em projetos piloto e j foram incorporadas aos processos da Organizao, como a tcnica de estimativa para o planejamento detalhado das iteraes e a utilizao do COCOMO como mtodo de estimativa para elaborao das propostas. Outras melhorias foram colocadas em prtica, mas ainda no foi possvel medir seu benefcio quantitativamente, como a proposta para o planejamento macro e a contagem de Pontos de funo diretamente no Modelo do Problema. Entretanto, ambas as propostas tiveram feedback positivo dos colaboradores da Organizao. A contagem de Pontos de funo no-ajustados realizada diretamente no Modelo do problema mostrou trs benefcios: 1) a consistncia entre o modelo e a contagem, j que no h mais artefatos separados; 2) e informao do tamanho final do produto, informao muito importante para as propostas apresentadas ao longo desse trabalho; 3) a diminuio de erros no procedimento de contagem garantida pelas diversas verificaes realizadas pelas restries OCL criadas e pela preveno de erros na interface grfica do plugin desenvolvido. A criao de um repositrio centralizado de medidas dos projetos vai proporcionar, no s o embasamento dos processos de estimativas propostos nesse trabalho, mas tambm vai fornecer informaes gerenciais importantes para o acompanhamento dos projetos e para as decises de melhoria de processos da Organizao.

84

Alm dos benefcios medidos e esperados para a Organizao alvo desse programa, o trabalho apresentado aqui pode servir de base para outras organizaes que desejem melhorar suas estimativas. Elas podem se valer tanto das propostas e tcnicas apresentadas, quanto do formato do programa de melhoria descrito, que ajuda a racionalizar e melhorar as chances de sucesso da alterao de seus processos.

6.1 Trabalhos futuros

A ltima fase do ProMOTe, do registro de lies aprendidas, no foi executada no escopo deste trabalho e fica como trabalho futuro para a Organizao, para que tenha melhor proveito de novos ciclos de melhoria. As diversas aes de melhoria propostas nesse trabalho cobrem uma quantidade muito grande de aspectos relacionados s estimativas em projetos de desenvolvimento de software. Por limitao de tempo, no foi possvel explorar de forma detalhada cada um desses aspectos, j que cada um deles poderia por si s, render um trabalho do porte deste. Com relao s estimativas para elaborao das propostas, quando definido um esforo, prazo e custo globais para um projeto, diversas outras tcnicas podem ser avaliadas futuramente pela Organizao. Para cada tipo de mtodo definido pela ontologia proposta por Myrtveit e outros [Myrtveit et al., 2005] para classificar os mtodos de estimativa, h uma grande quantidade de trabalhos relacionados. No entanto, alguns desses trabalhos carecem de uma quantidade de dados maior do que a base de dados histrica da Organizao, principalmente os mtodos de Aproximao de Funo Arbitrria, onde se encaixam as tcnicas de inteligncia artificial, como redes neurais e redes neuro-fuzzy. Embora no haja trabalhos que mostrem a viabilidade de automatizar completamente a contagem de Pontos de funo a partir de um modelo UML, pode-se investir em alguma automao parcial. No entanto, deve-se avaliar se uma automao parcial acarretar em mais trabalho de conferncia dos resultados produzidos do que na prpria contagem manual. A proposta para o planejamento macro das iteraes do projeto apresentada no foi validada. preciso comparar a sua eficcia com o procedimento atual executado pela organizao para, a partir dessa anlise, tomar a deciso de qual mtodo deve ser utilizado. Em um novo ciclo do ProMOTe essa questo deve ser revisitada. Tambm devem ser investigadas outras formas de abordar

85

o problema do planejamento das iteraes dos projetos e, alm disso, um trabalho interessante que pode ser realizado como integr-lo gesto do portflio de projetos da organizao e a alocao dos recursos nos diversos projetos. J na proposta de repositrio centralizado de medidas, pode-se investir em meios de facilitar a extrao e transformao dos dados dos diversos sistemas para carga no DW, atravs da utilizao de metamodelos e modelos mais genricos. Uma pesquisa bibliogrfica sobre o tema revelou poucos trabalhos nesse sentido. Por ltimo, a Organizao poder avaliar a aplicabilidade dos mtodos utilizados para estimativa em projetos de desenvolvimento de novos produtos para outros tipos de projetos, como modelagem de negcio, evoluo e manuteno de produtos.

86

Referncias bibliogrficas

[Aggarwal et al., 2005]

AGGARWAL, K. K., SINGH, YOGESH, CHANDRA, PRAVIN, & PURI,

MANIMALA. 2005. Evaluation of various training algorithms in a neural network model for software engineering applications. SIGSOFT Softw. Eng. Notes, 30(4), 14. [Anda et al., 2009] ANDA, BENTE C.D., SJBERG, DAG I.K., & MOCKUS, AUDRIS. 2009.

Variability and Reproducibility in Software Engineering: A Study of Four Companies that Developed the Same System. Software Engineering, IEEE Transactions on, 35. [Arnold & Pedross, 1998] ARNOLD, MARTIN, & PEDROSS, PETER. 1998. Software size

measurement and productivity rating in a large-scale software development department. Pages 490493 of: ICSE '98: Proceedings of the 20th international conference on Software engineering. Washington, DC, USA: IEEE Computer Society. [Auer et al., 2003] AUER, M., GRASER, B., & BIFFL, S. 2003 (Sept.). A survey on the fitness of

commercial software metric tools for service in heterogeneous environments: common pitfalls. [Barry et al., 2002] BARRY, E. J., MUKHOPADHYAY, T., & SLAUGHTER, S. A. 2002. Software

Project Duration and Effort: An Empirical Study. Information Technology and Managemen, 2002. [Becker et al., 2006] BECKER, KARIN, RUIZ, DUNCAN D., CUNHA, VIRGINIA S., NOVELLO,

T AISA C., & E SOUZA, FRANCO VIEIRA. 2006 (April). SPDW: A Software Development Process Performance Data Warehousing Environment. [Boehm, 1981] BOEHM, BARRY W. 1981. Software Engineering Economics. Prentice Hall PTR. [Boehm et al., 2000] BOEHM, BARRY W., ABTS, CHRIS, BROWN, A. WINSOR, CHULANI, SUNITA, CLARK, BRADFORD K., HOROWITZ, ELLIS, MADACHY, RAY, REIFER, DONALD J., & STEECE, BERT. 2000. Software Cost Estimation with COCOMO II. Prentice Hall PTR. [Boehm & Valerdi, 2008] BOEHM, B.W., & VALERDI, R. 2008. Achievements and Challenges in

Cocomo-Based Software Resource Estimation. Software, IEEE, 25(5), 7483. [Caldiera et al., 1998] CALDIERA, G., ANTONIOL, G., FIUTEM, R., & LOKAN, C. 1998 (Nov).

87

Definition and experimental evaluation of function points for object-oriented systems. Pages 167178 of: Proceedings. Fifth International Software Metrics Symposium, 1998. Metrics 1998. [Cantone et al., 2004] CANTONE, G., PACE, D., & CALAVARO, G. 2004 (Sept.). Applying function point to Unified Modeling Language: conversion model and pilot study. Pages 280291 of: 10th International Symposium on Software Metrics, 2004. Proceedings. [Chen et al., 2005] CHEN, Z., MENZIES, T., PORT, D., & BOEHM, D. 2005. Finding the right data

for software cost modeling. Software, IEEE, 22(6), 3846. [Clark et al., 1998] CLARK, B., DEVNANI-CHULANI, S., & BOEHM, B. 1998 (19-25 April).

Calibrating the COCOMO II Post-Architecture model. Pages 477480 of: Software Engineering, 1998. Proceedings of the 1998 (20th) International Conference on. [CMMI, 2006] CMMI. 2006. CMMI for Development, Version 1.2. Tech. rept. CMU/SEI-2006-TR008. Software Engineering Institute / Carnegie Mellon University. [Foss et al., 2003] FOSS, T., STENSRUD, E., KITCHENHAM, B., & MYRTVEIT, I. 2003. A

simulation study of the model evaluation criterion MMRE. Software Engineering, IEEE Transactions on, 29(11), 985995. [Friedl, 2006] FRIEDL, JEFFREY E. F. 2006. Mastering Regular Expressions. 3rd edition. O'Reilly. [Gencel & Demirors, 2008] GENCEL, CIGDEM, & DEMIRORS, ONUR. 2008. Functional size

measurement revisited. ACM Trans. Softw. Eng. Methodol., 17(3), 136. [Gremba & Myers, 1997] GREMBA, JENNIFER, & MYERS, CHUCK. 1997. The IDEAL(SM)

Model: A Practical Guide for Improvement. Software Engineering Institute (SEI). Tech Report SEL-95-102. [Harput et al., 2005] HARPUT, V., KAINDL, H., & KRAMER, S. 2005 (Sept.). Extending function

point analysis to object-oriented requirements specifications. Pages 10 pp.39 of: Software Metrics, 2005. 11th IEEE International Symposium. [Harrison, 2004] HARRISON, WARREN. 2004. A flexible method for maintaining software

metrics data: a universal metrics repository. Journal of Systems and Software, 72(2), 225 234. [Helm, 1992] HELM, J.E. 1992. The viability of using COCOMO in the special application software bidding and estimating process. Engineering Management, IEEE Transactions on, 39(1), 4258.

88

[IEEE, 1992] IEEE. 1992. IEEE Standard for Software Productivity Metrics. Tech. rept. IEEE Std 1045-1992. [IEEE, 1998] IEEE. 1998. IEEE Recommended Practice for Software Requirements Specifications. Tech. rept. IEEE Std 830-1998. [IFPUG, 2005] IFPUG. 2005. IFPUG Counting Practices Manual - Release. 4.2.1. International Function Point Users Group, Westerville, OH. [Inmon, 2005] INMON, WILLIAN H. 2005. Building the Data Warehouse. Fourth edn. Wiley Publishing, Inc. [Jain, 1991] J AIN, RAJ. 1991. Art of Computer Systems Performance Analysis Techniques For

Experimental Design Measurements Simulation And Modeling. Wiley Computer Publishing. [Jorgensen & Shepperd, 2007] JORGENSEN, M., & SHEPPERD, M. 2007. A Systematic Review of Software Development Cost Estimation Studies. Software Engineering, IEEE Transactions on, 33(1), 3353. [Jrgensen & Molkken-stvold, 2006] JRGENSEN, MAGNE, & MOLKKEN-STVOLD, KJETIL.

2006. How large are software cost overruns? A review of the 1994 CHAOS report. Information and Software Technology, 48(4), 297 301. [Kautz et al., 2000] KAUTZ, KARLHEINZ, HANSEN, HENRIK WESTERGAARD, & T HAYSEN, KIM.

2000. Applying and adjusting a software process improvement model in practice: the use of the IDEAL model in a small software enterprise. Pages 626633 of: ICSE '00: Proceedings of the 22nd International Conference on Software Engineering. New York, NY, USA: ACM Press. [Kimball & Ross, 2002] KIMBALL, RALPH, & ROSS, MARGY. 2002. The Data Warehouse

Toolkit. Second edition. Wiley Computer Publishing. [Kitchenham et al., 2001] KITCHENHAM, B.A., PICKARD, L.M., MACDONELL, S.G., & SHEPPERD,

M.J. 2001. What accuracy statistics really measure [software estimation]. Software, IEE Proceedings -, 148(3), 8185. [Kohavi, 1995] KOHAVI, RON. 1995. A study of cross-validation and bootstrap for accuracy estimation and model selection. Morgan Kaufmann. [Laird, 2006] LAIRD, L.M. 2006. The Limitations of Estimation. IT Professional, 8(6), 4045. [Lokan, 2000] LOKAN, C. J. 2000. An empirical analysis of function point adjustment factors. Information and Software Technology, 42(9), 649 659.

89

[Lopez-Martin et al., 2006]

LOPEZ-MARTIN, CUAUHTEMOC, YANEZ-MARQUEZ, CORNELIO, &

GUTIERREZ-TORNES, AGUSTIN. 2006. A Fuzzy Logic Model Based upon Reused and New & Changed Code for Software Development Effort Estimation at Personal Level. Computing, 2006. CIC '06. 15th International Conference on, Nov., 298303. [McConnell, 2006] MCCONNELL, STEVE. 2006. Software Estimation, Demystifying the Black Art.

Microsoft Press. [McGarry et al., 2001] MCGARRY, J OHN, CARD, DAVID, JONES, CHERYL, LAYMAN, BETH, CLARK, ELIZABETH, DEAN, JOSEPH, & HALL, FRED. 2001. Practical Software Measurement: Objective Information for Decision Makers. Addison-Wesley Professional. [Mendes & Mosley, 2008] MENDES, E., & MOSLEY, N. 2008. Bayesian Network Models for Web

Effort Prediction: A Comparative Study. Software Engineering, IEEE Transactions on, 34(6), 723737. [Mukhopadhyay et al., 1992] MUKHOPADHYAY, TRIDAS, VICINANZA, STEVEN S., & PRIETULA, MICHAEL J. 1992. Examining the feasibility of a case-based reasoning model for software effort estimation. MIS Q., 16(2), 155171. [Myrtveit et al., 2005] MYRTVEIT, I., STENSRUD, E., & SHEPPERD, M. 2005. Reliability and validity in comparative studies of software prediction models. Software Engineering, IEEE Transactions on, 31(5), 380391. [Nan & Harter, 2009] NAN, NING, & HARTER, DONALD E. 2009. Impact of Budget and Schedule Pressure on Software Development Cycle Time and Effort. Software Engineering, IEEE Transactions on, 35. [NESMA, 2001] NESMA. 2001 (August). Function Point Analysis for Software Enhancement.

The Netherlands Software Metrics Users Association. [Nguyen et al., 2008] NGUYEN, VU, STEECE, BERT, & BOEHM, BARRY. 2008. A constrained regression technique for COCOMO calibration. Pages 213222 of: ESEM '08: Proceedings of the Second ACM-IEEE international symposium on Empirical software engineering and measurement. New York, NY, USA: ACM. [Olsina et al., 2002] OLSINA, LUIS, LAFUENTE, GUILLERMO, & PASTOR, OSCAR. 2002. Towards a

reusable repository for Web metrics. Journal of Web Engineering, 1(1), 061073. [OMG, 2005a] OMG. 2005a. Object Constraint Language 2.0 Specification. Object Management Group (OMG).

90

[OMG, 2005b] OMG. 2005b. Unified Modeling Language Specification, version 2.0. Object Management Group (OMG). [OMG, 2008] OMG. 2008. Software & Systems Process Engineering Meta-Model Specification (SPEM) 2.0. Object Modeling Group. [Park et al., 1992] PARK, ROBERT E., PARK, ROBERT E., MILLER, T HOMAS R., & COL, LT. 1992.

Software size measurement: A framework for counting source statements. Tech. rept. CMU/SEI-92-TR-020. CMU/SEI. [Pdua, 2007] PDUA, WILSON. 2007 (July). Using Model-Driven Development in TimeConstrained Course Projects. CSEET '07. 20th Conference on Software Engineering Education and Training, 2007. [Pdua, 2008] PDUA, WILSON. 2008. Engenharia de Software: Fundamentos, Mtodos e Padres. 3a. edio. LTC. [Pdua, 2009] PDUA, WILSON. 2009. Using Quality Audits to Assess Software Course Projects. CSEET '09. 22th Conference on Software Engineering Education and Training, 2009. [Pdua et al., 2003] PDUA, WILSON, NOGUEIRA, MACHADO, FABIANA TRINDADE, &
DE

DRUMOND,

FERNANDA PAIVA,

MRCIA MNICA,

MESQUITA FERREIRA,

GISELE RODRIGUES. 2003 (Out.). Aplicao da fase de Diagnstico de um processo para melhoria de organizaes tcnicas. In: V Simpsio Internacional de Melhoria de Processos de Software (SIMPROS). [Pimentel et al., 2006] PIMENTEL, BRUNO, FILHO, WILSON P. PAULA, PDUA, CLARINDO, & MACHADO, FABIANA T. 2006. Synergia: a software engineering laboratory to bridge the gap between university and industry. Pages 2124 of: SSEE '06: Proceedings of the 2006 International Workshop on Summit on Software Engineering Education. [PMI, 2004] PMI. 2004. Project Management Body of Knowledge. 3rd edition. Project

Management Institute. [PMI, 2008] PMI. 2008. The Standard for Portfolio Management. 2nd edn. Project Management

Institute. [Port & Korte, 2008] PORT, DAN, & KORTE, MARCEL. 2008. Comparative studies of the model evaluation criterions mmre and pred in software cost estimation research. Pages 5160 of: ESEM '08: Proceedings of the Second ACM-IEEE international symposium on Empirical software engineering and measurement. New York, NY, USA: ACM.

91

[Putnam, 1978]

PUTNAM, L.H. 1978. A General Empirical Solution to the Macro Software

Sizing and Estimating Problem. Software Engineering, IEEE Transactions on, SE-4(4), 345361. [Rosenberg, 1997] ROSENBERG, J. 1997. Some misconceptions about lines of code. Software

Metrics Symposium, 1997. Proceedings., Fourth International, Nov, 137142. [Ryder, 1998] RYDER, J. 1998. Fuzzy modeling of software effort prediction. Information Technology Conference, 1998. IEEE, Sep, 5356. [Triola, 2008] TRIOLA, MARIO F. 2008. Introduo Estatstica. 10a. edio. LTC Editora. [Uemura et al., 1999] UEMURA, T., KUSUMOTO, S., & INOUE, K. 1999. Function point measurement tool for UML design specification. Proceedings., Sixth International Software Metrics Symposium, 1999. [Yang et al., 2008] YANG, DA, WANG, QING, LI, MINGSHU, YANG, YE, YE, KAI, & DU, J ING.

2008. A survey on software cost estimation in the chinese software industry. Pages 253262 of: ESEM '08: Proceedings of the Second ACM-IEEE International Symposium on Empirical Software Engineering and Measurement, 2008. [Zadeh et al., 1977] ZADEH, L. A., FU, K. S., T ANAKA, K., SHIMURA, M., & NEGOITA, C. V. 1977.

Fuzzy Sets and Their Applications to Cognition and Decision Processes. Systems, Man and Cybernetics, IEEE Transactions on, 7(2), 122123.

92

Apndices

A.1 Lista de conferncia de definio de contagem de linhas de cdigo

Nome da definio: Linhas de cdigo fsicas Data: 1/11/2008

Unidade de medida

Linhas de cdigo fsicas Instrues lgicas de cdigo

Tipo de instruo

Definio

Vetor de dados

Inclui

Exclui

1 Executvel 2 No-executvel 3 4 5 6 7 8 9 10 Declaraes Diretivas de compilao Comentrios Em linha prpria Em linha que contm cdigo-fonte Banners (ex: faixas de comentrio em cabealhos) Comentrios em branco Linhas em branco

Ordem de precedncia -->

2 3

X X

4 5 6 7 8

X X X X X

Obs: Quando uma linha se encaixa em mais de um tipo, classificar como o tipo de maior prioridade.

Como foi produzida

Definio

Vetor de dados

Inclui

Exclui

1 Programada 2 Gerada com geradores de cdigo 3 Convertida com tradutores de cdigo 4 Copiada ou reusada sem modificao 5 Modificada 6 Removida

X X X X X X

93

Origem

Definio

Vetor de dados

Inclui

Exclui

1 Projeto novo: no existia anteriormente 2 Cdigo j existente (fonte ou objeto), utilizado ou adaptado de: 3 4 5 6 Verso anterior de projetos do Synergia. Bibliotecas de reuso prprias, desenvolvidas fora do projeto. Bibliotecas ou produtos de terceiros, utilizados no projeto sem alterao Bibliotecas ou produtos de terceiros, utilizados com alguma alterao

X X X X

Propsito de uso

Definio

Vetor de dados

Inclui

Exclui

1 Dentro do produto primrio (cdigos de testes de desenvolvimento esto inclusos) 2 Externo ou de suporte ao produto primrio (simuladores, cotos, etc.)

X X

Entrega

Definio

Vetor de dados

Inclui

Exclui

1 Entregue 2 3 Entregue como cdigo-fonte Entregue como cdigo-objeto, mas no como cdigo-fonte X X

4 No entregue 5 6 Est sob controle de verso No est sob controle de verso X X

Funcionalidade do cdigo

Definio

Vetor de dados

Inclui

Exclui

1 Operante 2 Inoperante 3 4 Funcional (cdigo intencionalmente morto, contornado, que pode ser reativado) No funcional (presente, mas sem inteno)

X X

Estado do desenvolvimento

Definio

Vetor de dados

Inclui

Exclui

1 Antes de iniciar a codificao 2 Codificado 3 Testes de desenvolvimento codificados 4 Aprovado nas inspees de testes de desenvolvimento e implementao 5 Aprovado na reviso de implementao 6 Testes de integrao executados 7 Todos os defeitos de testes de integrao corrigidos X

X X X X X X

94

Tipo de arquivo

Definio

Vetor de dados

Inclui

Exclui

1 Java (arquivos com extenso .java, exceto com o padro de nome *Helper.java) 2 Web Esttica (.html, .htm, .css, .xsl) 3 Web Dinmica (.jsp, .js) 4 Configurao (.xml, .config, .properties) 5 Robot (.rec, .sbl, .sbh)

X X X X X

Camada

Definio

Vetor de dados

Inclui

Exclui

1 Fronteira 2 Controle 3 Entidade 4 Testes de desenvolvimento (unidade) 5 Povoadores de banco de dados 6 Testes de sistema (scripts do Rational Robot e Functional Tester)

X X X X X X

Origem do cdigo

Definio

Vetor de dados

Inclui

Exclui

1 Cdigo novo 2 Cdigo reusado sem modificao 3 Cdigo reusado com modificao

X X X

95

A.2 Descrio dos atributos do repositrio centralizado de medidas da Organizao

Dimenso Atributo Tipo de alterao Alterao Descrio Nome do Projeto Parmetros do COCOMO Projeto Esforo Orado Custo Orado Descrio Defeito detectado em artefato aprovado nas revises, Alterao de requisito, Alterao em soluo Texto descrevendo a alterao a ser executada Nome do projeto Consiste nos diversos fatores de escala e multiplicadores de esforo que caracterizam o projeto Esforo total orado para o projeto Custo total orado para o projeto. Utiliza as categorias dos colaboradores e portanto baseado na mdia do custo dos colaboradores dentro das categorias. Prazo total orado para o projeto em meses. Identificador do registro na ferramenta Rational ClearQuest. Pode ser usado para recuperar detalhes do registro quando necessrio. Tipo de registro no Rational ClearQuest: Tarefa, Reviso, Alterao, etc. Nome da atividade executada. consistente com a definio do processo PraxisSynergia. Artefato sendo modificado pela atividade ou 'Nenhum' quando for uma tarefa geral, como uma reunio. Estado associado do caso de uso associado atividade. Varia de 10 a 100 conforme definio do Praxis-Synergia. Descrio textual do estado. Ex: Identificado, Detalhado, etc. Refere-se disciplina associada atividade executada. Define se uma atividade considerada ou no retrabalho no projeto.

Prazo Orado

ID CQ Origem CQ Nome Atividade

Artefato Associado

Estado Associado Nome do estado associado Atividade Disciplina retrabalho Tipo de atividade Tipo de esforo Data de incio planejada Data de trmino planejada Data de incio real Data de trmino real Esforo planejado MRE

Definido em: Tarefa, reviso, correo, verificao, alterao Data de incio planejada pelo gerente. Armazena apenas o primeiro planejamento.

Data de trmino planejada pelo gerente. Armazena apenas o primeiro planejamento. Data de incio real da atividade. Data de trmino real da atividade. Esforo planejado pelo gerente. Armazena apenas o primeiro planejamento. Medida do erro de estimativa do esforo.

96

Dimenso Pacote de trabalho Nome

Atributo

Descrio Nome do pacote de trabalho. So subdivises do escopo do produto. Identificador do requisito na ferramenta Rational RequisitePro, utilizada para manter o cadastro de requisitos do projeto. Nome do requisito Texto concatenando a Tag e Nome do requisito Complexidade definida para o requisito. Pode ser Baixa, Mdia ou Alta. Total de pontos de funo no ajustados do requisito. Estado em que se encontra o requisito. Varia de 10 a 100 conforme definio do processo Praxis-Synergia. Data no calendrio. Texto representando a data formatada para exibio em relatrios. Texto representando o ms e ano da data. Texto representando o ms associado data. Texto representando o ano associado data. Data do Domingo anterior data. Representa a data do incio da semana. Login de rede do colaborador. considerado a chave primria dessa entidade. Nome do colaborador. Nome da iterao. Ex: E1, E2, C1, C2, etc. Data de incio planejada pelo gerente. Armazena apenas o primeiro planejamento.

Tag Nome Tag e nome Requisito Complexidade Total PF Estado Atual Data Data formatada MesAno Data MesPorExtenso Ano Semana Login Colaborador Nome Nome Data de incio planejada Iterao Data de trmino planejada Data de incio real Data de trmino real Tipo de arquivo Classificao LOC

Data de trmino planejada pelo gerente. Armazena apenas o primeiro planejamento. Data de incio real da atividade. Data de trmino real da atividade. Opes definidas na lista de conferncia de contagem de Linhas de Cdigo. Ver Apndice A.1. Opes definidas na lista de conferncia de contagem de Linhas de Cdigo. Ver Apndice A.1. Opes definidas na lista de conferncia de contagem de Linhas de Cdigo. Ver Apndice A.1.

Camada

Origem do Cdigo

97

Dimenso

Atributo Gravidade Natureza

Descrio Gravidade do defeito: Blocante, Crtico, Maior, Menor, Sugesto. Natureza do defeito: modelagem, impreciso, codificao, estilo, omisso, redundncia. Cdigo do item da lista de conferncia relacionado ao defeito. Situao do defeito: Novo, Corrigido, Verificado, Invlido, Fechado. Nome da transao realizada com o defeito. Est associado mquina de estados. Pode ser: Registrado, Invalidado, Reaberto, Corrigido, Verificado, Fechado.

Defeito Item Lista de Conferncia Estado Transao do defeito Nome