UNIVERSIDADE FEDERAL DO CEAR UFC DEPARTAMENTO DE COMPUTAO CURSO DE PS-GRADUAO EM TECNOLOGIAS DA INFORMAO

MIRLA RAFAELA RAFAEL BRAGA

UMA LINGUAGEM DE PADRES PARA A REA DE MEDIO E ANLISE APLICADA EM PROCESSOS GEIS

FORTALEZA - CEAR 2011

B R A G A M O N O G R A F I A D E E S P E C I A L I Z A O

2011

MIRLA RAFAELA RAFAEL BRAGA

UMA LINGUAGEM DE PADRES PARA A REA DE MEDIO E ANLISE APLICADA EM PROCESSOS GEIS

Monografia submetida Coordenao do Curso de Ps-Graduao Em Tecnologia da Informao, da Universidade Federal do Cear, como requisito parcial para obteno do grau de Especialista em Tecnologia da Informao. rea de concentrao: Departamento de

Computao Orientador: Prof. Dr. Jos Maria da Silva Monteiro Filho Co-orientadora: Prof. MSc. Carla Ilane Moreira Bezerra

FORTALEZA- CEAR 2011

9999

BRAGA, Mirla Rafaela Rafael Braga. Uma Linguagem de padres para a rea de medio e anlise aplicada em processos geis/Mirla Rafaela Rafael Braga. Fortaleza, 2011 77 f. Orientador: Prof. Dr. Jos Maria da Silva Monteiro Filho Co-orientadora: Prof. MSc. Carla Ilane Moreira Bezerra

1. Padres 2.Medio de Software 3.Mtodos geis 4. Estimativas 5.Linguagens de padres Uma linguagem de padres para a rea de medio e anlise aplicada em processos geis.

CDD 9999.9 CDU 999.999

MIRLA RAFAELA RAFAEL BRAGA

UMA LINGUAGEM DE PADRES PARA A REA DE MEDIO E ANLISE APLICADA EM PROCESSOS GEIS

Monografia submetida Coordenao do Curso de Ps-Graduao em Tecnologia da Informao, da Universidade Federal do Cear, como requisito parcial para a obteno do grau de Especialista em Tecnologias da Informao com nfase no desenvolvimento de Software para a Web rea de concentrao Cincia da Computao.

Aprovada em ___/___/______.

BANCA EXAMINADORA

___________________________________________ Prof. Dr. Jos Maria da Silva Monteiro Filho (Orientador) Universidade Federal do Cear - UFC

___________________________________________ Prof. MSc. Carla Ilane Moreira Bezerra (Co-Orientadora) Universidade Federal do Cear - UFC

Dedico

A Deus por me dar perseverana e discernimento em todos os momentos. minha famlia pelo total apoio, carinho e companheirismo sempre presente.

AGRADECIMENTOS
Ao meu estimado orientador Prof. Jos Maria Monteiro e Co-Orientadora Prof. Carla Moreira, pela dedicao, ateno, motivao, orientao, pacincia e por acreditar em mim e em meu trabalho. Aos meus professores da ps-graduao por oferecer conhecimento necessrio para exercer o trabalho que realizo e a construo dessa monografia. Aos meus colegas de especializao pela a troca de informaes e proporcionar aulas mais dinmicas. Ivia por me dar oportunidade de trabalhar com algumas tecnologias envolvidas nesse trabalho e me ceder tempo para a elaborao do mesmo.

Todos os nossos sonhos podem se realizar, se tivermos a coragem de persegui-los Walt Disney

RESUMO
As metodologias geis propem diversas abordagens para estimar um projeto de software. No entanto, difcil para a equipe identificar qual o melhor mtodo ou tcnica para realizar estimativas de um projeto de software que utiliza metodologia gil. Este trabalho tem como objetivo descrever a padronizao de algumas estimativas no contexto gil, a partir de uma linguagem de padres. A linguagem proposta constituda por oito padres e seus relacionamentos, os quais foram identificados por meio de uma extensa pesquisa bibliogrfica e de entrevistas realizadas com diversas empresas que utilizam metodologias geis, destacando padres comuns de estimativas como: tamanho, esforo e prazo. A linguagem de padres desenvolvida tem o intuito de orientar equipes de desenvolvimento de software sobre os principais mtodos utilizados para estimativas de um projeto de software que adota processos geis. Palavras-chave: Padres, Medio de Software, Mtodos geis, Estimativas, Linguagens de padres.

ABSTRACT
Agile methodologies offer different approaches to estimate a software project. However, it is difficult for the team identify the best method or technique to make estimates of a software project using agile methodologies. This paper aims to describe the standardization of some estimates in the agile context, by a pattern language. The proposed language is composed of eight standards and their relationships, which were

identified through an extensive literature research and interviews with several companies that use agile methodologies, highlighting language common patterns of estimates as: size, effort guide software development

and time. The pattern

developed is

intended to

teams on the main methods used for estimating a software project that adopts agile processes. Key-words: Pattern, Measurement Software, Agile Methods, Estimates, Patterns Languages.

LISTA DE ILUSTRAES
Figura1 Pgina principal do manifesto gil. .......................................................................... 22 Figura 2 Relao entre os padres identificados ................................................................... 39 Figura 3 - Planning Poker deck ................................................................................................ 44 Figura 4 Baralho de cartas. .................................................................................................... 45 Figura 5 - Product Owner ......................................................................................................... 45 Figura 6 O Time pensa sobre o valor da estimativa .............................................................. 45 Figura 7 O Time mostra suas cartas ...................................................................................... 46 Figura 8 O Time mostra suas cartas, aps discusso ............................................................. 46 Figura 9 Quadro de tarefas (Taskboard) do primeiro Sprint ................................................. 51 Figura 10 Burndown do projeto ............................................................................................. 57

LISTA DE TABELAS
Tabela I Diviso do MPS. BR ............................................................................................... 25 Tabela II Resumo dos Padres............................................................................................... 39 Tabela III Product Backlog .................................................................................................... 41 Tabela IV Product Backlog com estimativa de tamanho ....................................................... 46 Tabela V Product Backlog com Sprint e esforo ................................................................... 50 Tabela VI Papel por custo mensal ......................................................................................... 60

LISTA DE ABREVIATURAS E SIGLAS

CMM Capability Maturity Model CMMI Capability Maturity Model Integration ISO International Organization for Standardization MA-MPS Mtodo de Avaliao do MPS MN-MPS Modelo de Negocio do MPS MPS. BR Melhoria de Processos do Software Brasileiro MR-MPS Modelo de Referncia do MPS RUP Rational Unified Process SEI Software Engineering Institute TDD Test Driven Development XP Extreme Programming

SUMRIO CAPTULO 1 INTRODUO ............................................................. 16

1.1 1.2 1.3 Trabalhos Relacionados ......................................................................................... 18 Objetivo do Trabalho .............................................................................................. 19 Estrutura do Trabalho ............................................................................................. 19

CAPTULO 2 CONCEITOS BSICOS ............................................... 20

2.1 2.2 2.3 2.3.2 2.4 2.5 2.6 2.7 2.8 2.9 Mtodos geis........................................................................................................ 20 O Manifesto gil .................................................................................................... 20 Modelos de Maturidade de Software ..................................................................... 23 CMMI ................................................................................................................. 26 Estimativas de Software ......................................................................................... 27 Estimativas de Esforo e Prazo .............................................................................. 28 Estimativas de Tamanho ......................................................................................... 29 Padres de Software ............................................................................................... 30 Descrevendo os Padres de Projeto ....................................................................... 32 Linguagem de Padres ........................................................................................... 34

2.3.1 MPS. BR .................................................................................................................. 24

CAPTULO 3 UMA LINGUAGEM DE PADRES PARA ESTIMATIVAS DE SOFTWARE EM METODOLOGIAS GEIS.................................... 36

3.1 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7 3.1.8 Running Example ................................................................................................... 41 Estimativas de tamanho total .............................................................................. 42 Estimativa do esforo ......................................................................................... 48 Estimativa de velocidade do time ....................................................................... 52 Estimativa de durao ......................................................................................... 55 Estimativa de custo ............................................................................................. 58 Negociao das estimativas ................................................................................ 61 Coleta das medidas reais..................................................................................... 64 Obteno de dados histricos ............................................................................. 66

CONCLUSES .................................................................................... 68 REFERNCIAS .................................................................................... 69 GLOSSRIO ........................................................................................ 72 APNDICE A PESQUISA DE CAMPO .............................................. 73

CAPTULO 1 INTRODUO
Estimar algo abstrato sempre foi um problema. No poderia ser diferente no contexto tecnolgico, especificamente no desenvolvimento de um produto de software. Nas vrias esferas de aplicabilidade de um software, contexto pblico ou privado, estimar tornouse importante, pois atravs das estimativas podemos ter uma idia do escopo, do esforo, do prazo e do custo de um projeto. A realizao das estimativas de software considerada uma das primeiras atividades da fase de planejamento do projeto e parte essencial da melhoria do processo de software. Estimativas eficientes permitem verificao da viabilidade do projeto, a elaborao de propostas tcnicas e comerciais, a confeco de planos e cronogramas detalhados e o acompanhamento efetivo do projeto [Monteiro 2005], [Andrade 2008]. O gerente de projeto, ento, confronta-se com um dilema logo no incio projeto: produzir estimativas quantitativas, como mensurar custo, tempo e esforo e desenvolvimento do projeto. Para isto, ele deve conhecer a capacidade de sua equipe e os recursos com os quais pode contar para executar as atividades. Desta forma, adequando-se ao custo disponvel e qualidade desejada, o gerente poder estabelecer prioridades para a realizao dessas atividades [Andrade 2008]. Ao elaborar uma estimativa para o desenvolvimento de um projeto de software, desejvel que haja um conhecimento sobre tcnicas de estimativas e uma viso global do escopo do projeto a ser gerenciado, o que capacita o gerente a quantificar, administrar e planejar mais efetivamente o projeto a ser produzido. Planejar o projeto baseando-se no feeling (sentimento; capacidade de percepo) ou em experincias anteriores gera, na maioria das vezes, estouro de prazos e elevado custo de desenvolvimento [Andrade 2008]. Existem, atualmente, inmeras tcnicas para estimativas de software [Albrecht 1979], [Abran et al 2000], [Karner 1993], [FPA 1998], [Boehm et al 2000], [Symons 1991] todas elas na busca constante de realizar estimativas mais prximas do valor real do software.

As empresas de software de forma geral buscam estimativas exatas que retratem a eficincia do desenvolvimento e minimizem os fracassos do projeto. As grandes empresas (segundo [MCT 2005] empresa com acima de 100 empregados), em particular, tm facilidade na implantao de tcnicas que oferecem maior preciso, em virtude, principalmente, da disponibilidade de recursos financeiros e conseqente leque de possibilidades de investimento em tais tcnicas. Para essas empresas, o foco principal minimizar a margem de erro das estimativas. As tcnicas robustas e precisas necessitam de maior esforo para contabilizao das medidas, onde na maioria das vezes a medio feita por fase do projeto, para posterior contagem do todo [Andrade 2008]. Atualmente, devido ao ritmo acelerado das mudanas e s presses de mercado, existe uma forte tendncia em se construir sistemas de forma mais flexvel. Neste contexto, os mtodos geis representam uma estratgia para atender dinmica dos projetos atuais. As metodologias geis surgiram com a preocupao de acomodar melhor as modificaes, possibilitando s equipes reagir rapidamente quando mudanas so necessrias. Nos ltimos anos, mtodos geis como o XP (eXtreme Programming) [Beck 2009], Scrum [Schwaber 2002] e Crystal [Cochburn 2002] ganharam grande destaque[Goldmand 2004]. Esses mtodos empregam princpios geis, tais como ciclos iterativos, entrega rpida de software funcionando e simplicidade, como defendido no Manifesto para o Desenvolvimento gil [Ma]. A essncia desse movimento a definio de um novo enfoque para o desenvolvimento de software, calcado na agilidade, na flexibilidade, nas habilidades de comunicao e na capacidade de oferecer novos produtos e servios de valor ao mercado, em curtos perodos de tempo [Glazer 2008]. Alm disso, os mtodos geis optam por uma documentao apropriada para evitar redundncias e excessos, de modo que a documentao auxilie efetivamente o desenvolvimento do software. Neste contexto, as empresas que utilizam metodologias geis possuem dificuldades relacionadas a estimativas, pois algumas das caractersticas geis tais como: equipes pequenas, ciclos so curtos (o tempo para se dedicar as estimativas reduzido), o prprio time faz as estimativas (no uma equipe especializada) dificultam a obteno de dados de estimao. Diante destas dificuldades, as empresas que utilizam mtodos geis necessitam realizar estimativas de software de forma rpida e simples e que reproduzam significadamente os valores totais de tamanho, esforo, prazo e custo do desenvolvimento do software.

Neste sentido, esta monografia est voltada para lderes de equipes geis que necessitam realizar estimativas e apresenta uma linguagem de padres para estimativa de software, que tem como objetivo guiar as empresas que adotam os mtodos geis atravs de um processo simplificado de boas prticas de como estimar o software, desde o tamanho at o custo, atravs da unificao das semelhanas entre as tcnicas de estimativas de software largamente utilizadas em projetos acadmicos e empresariais. A linguagem de padres proposta tem por objetivo especificar as principais estimativas que podemos encontrar em processos geis. Linguagem de padres nada mais uma coleo estruturada de padres que se apiam uns nos outros para transformar requisitos e restries numa arquitetura [Coplien 2004] e uma forma de subdividir um problema geral e sua soluo complexa em problemas menores relacionados e suas respectivas solues. Uma linguagem de padres possui um contexto comum compartilhado entre todos os padres pertencentes a ela. Os padres podem ser usados isoladamente ou com demais padres relacionados na linguagem, porm, cada um deles resolve seu prprio problema [Andrade 2008].

1.1 Trabalhos Relacionados Para o desenvolvimento deste trabalho foram pesquisadas diversas referncias bibliogrficas e artigos de relatos de empresas de desenvolvimento de software que adotam metodologias geis com o intuito de identificar um conjunto de padres para estimativas de software que fossem adequados para equipes que utilizam metodologias geis [Andrade 2008], [Sato 2007], [Ma 2001], [Meirelles 2008], [Monteiro 2005], [Soares 2004], [Coplien 1998], [Cohn 2006], [Yoshima 2007]. Alguns trabalhos possuem iniciativas similares de identificao de mtricas para estimativas de software. No trabalho apresentado em Andrade (2008) proposta uma linguagem de padres para estimativa de software voltada para micro e pequenas empresas. Ao longo do trabalho so apresentados os padres que compem a linguagem e as relaes entre eles. A linguagem proposta tem por finalidade auxiliar o gerente de projeto na realizao das estimativas na fase de planejamento do projeto. No entanto, os padres identificados no esto direcionados a equipes que utilizam metodologias geis. Em Meirelles (2008), identificado um conjunto de mtricas para avaliao da qualidade de projetos de software livre. Essas mtricas envolvem aspectos como cdigo-fonte, testes, manutenibilidade, comunidade, dentre outros capazes de determinar caractersticas da

qualidade do software, ajudando na escolha e adoo de um software livre. J Sato (2007), prope um estudo sobre mtricas para auxiliar o acompanhamento de projetos utilizando mtodos geis de desenvolvimento de software, e utiliza um estudo de caso emprico com um conjunto de projetos para avaliar a eficcia das mtricas selecionadas. No entanto, mtricas de planejamento para estimar projetos de software geis no so identificadas neste trabalho. Em Buglione (2007) os autores propem a utilizao de uma abordagem mista para a estimativa de software em projetos geis, a qual combina um mtodo de estimativa rpida com a anlise de pontos de funo.

1.2 Objetivo do Trabalho Dessa forma, o objetivo desse trabalho mostrar a padronizao de algumas estimativas no contexto gil, as principais apresentadas foram: tamanho; esforo e prazo. Outros padres foram encontrados tais como: velocidade do time; negociao das estimativas; estimativa de custo; obteno de dados histricos e coleta das medidas reais. Sero definidos alguns conceitos envolvidos para a concepo da escrita dos padres geis. O objetivo iniciar um trabalho sobre as estimativas geis, promovendo, ento, uma maior popularizao do assunto. 1.3 Estrutura do Trabalho Este trabalho est organizado da seguinte forma: no Captulo 2, so apresentadas algumas definies de pontos importantes para a discusso do tema, um captulo de conceituaes, fundamentaes de termos utilizados ao longo do trabalho. No Captulo 3, uma linguagem de padres para o processo de medies em mtodos geis prope uma linguagem com as principais estimativas encontras em metodologias geis.

CAPTULO 2 CONCEITOS BSICOS

Neste captulo discutiremos os principais conceitos que sero necessrios para o entendimento da abordagem proposta nesta monografia. Inicialmente, iremos apresentar as idias das metodologias geis e dos modelos de maturidade de software. Em seguida, as definies de estimativas de software, padres de software e linguagens de padres sero apresentadas e discutidas.

2.1 Mtodos geis Os Mtodos geis surgiram, em meados de 2001, como uma alternativa aos mtodos tradicionais de desenvolvimento de software. Eles propem uma nova abordagem para o desenvolvimento, eliminando gastos com documentao excessiva e burocrtica, enfatizando a comunicao, colaborao com o cliente e as atividades que trazem valor imediato na produo de software com qualidade. Por meio de um processo emprico, com ciclos constantes de inspeo e adaptao, a equipe trabalha sempre num ambiente de contnua melhoria.

Segundo Sato (2007) nos ltimos anos, os Mtodos geis de desenvolvimento de software ganharam importncia em diversos segmentos da indstria de software. Assim como os mtodos tradicionais, os Mtodos geis tm por objetivo construir sistemas de alta qualidade que atendam s necessidades dos usurios, alm de oferecer maior agilidade na entrega do produto. A principal diferena est nos princpios utilizados para atingir tal objetivo.

Os Mtodos geis apresentam uma abordagem bastante pragmtica para o desenvolvimento de software. Planos detalhados so feitos apenas para a fase atual do projeto. Para fases futuras, os planos so considerados apenas rascunhos que podem se adaptar a mudanas conforme o time aprende e passa a conhecer melhor o sistema e as tecnologias utilizadas [Sato 2007].

2.2 O Manifesto gil Em fevereiro de 2001, um grupo formado por 17 desenvolvedores experientes,

consultores e lderes da comunidade de software e liderada por Kent Beck1, se reuniu na cidade de Salt Lake City no estado de Utah (Estado localizado nas Montanhas Rochosas do EUA) para discutir idias e procurar uma alternativa aos processos burocrticos e s prticas rgidas e complicadas adotadas nas abordagens tradicionais da Engenharia de Software e gerncia de projetos, principalmente o modelo em cascata. Dessa reunio surgiu o Manifesto do Desenvolvimento gil de Software, que destaca as diferenas com relao s abordagens tradicionais e define seus valores:

Segundo o MANIFESTO GIL, os quatros valores para o desenvolvimento de software esto descritos da seguinte forma:
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o ns mesmos e ajudando outros a faz-lo. Atravs deste trabalho, passamos a valorizar: 1. Indivduos e interao entre eles mais que processos e ferramentas;

2.

Software em funcionamento mais que documentao abrangente;

3.

Colaborao com o cliente mais que negociao de contratos;

4.

Responder a mudanas mais que seguir um plano.

Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os itens esquerda. (grifo do autor) [Ma 2001].

Kent Beck: engenheiro de software americano que foi um dos 17 signatrios originais do Manifesto gil em 2001. Foi o fundador da XP e TDD.

Figura1 Pgina principal do manifesto gil. (http://agilemanifesto.org/) Alm dos quatro valores bsicos, o Manifesto gil tambm apresenta 12 princpios que auxiliam a difuso de suas idias. Para se alcanar agilidade imprescindvel que empresas utilizem-nos de forma eficiente. Os princpios do desenvolvimento gil de software, segundo o MANIFESTO GIL, so:
Nossa maior prioridade satisfazer o cliente, atravs da entrega adiantada e

contnua de software de valor. Aceitar mudanas de requisitos, mesmo no fim do desenvolvimento. Processos geis

se adquam a mudanas, para que o cliente possa tirar vantagens competitivas. Entregar software funcionando com freqncia, na escala de semanas at meses,

com preferncia aos perodos mais curtos. Pessoas relacionadas a negcios e desenvolvedores devem trabalhar em conjunto e

diariamente, durante todo o curso do projeto.

Construir projetos ao redor de indivduos motivados. Dando a eles o ambiente e

suporte necessrio, e confiar que faro seu trabalho. O Mtodo mais eficiente e eficaz de transmitir informaes para, e por dentro de um

time de desenvolvimento, atravs de uma conversa cara a cara. Software funcional a medida primria de progresso. Processos geis promovem um ambiente sustentvel. Os patrocinadores,

desenvolvedores e usurios, devem ser capazes de manter indefinidamente, passos constantes. feito. As melhores arquiteturas, requisitos e designs emergem de times auto-organizveis. Em intervalos regulares, o time reflete em como ficar mais efetivo, ento, se ajustam Contnua ateno excelncia tcnica e bom design, aumenta a agilidade. Simplicidade: a arte de maximizar a quantidade de trabalho que no precisou ser

e otimizam seu comportamento de acordo.

Essas caractersticas trazem dinamismo para o desenvolvimento, motivao para o time e informaes mais precisas sobre a verdadeira situao do projeto para o cliente. Enquanto as abordagens tradicionais tm um enfoque mais preditivo, os Mtodos geis so adaptativos. O Manifesto gil apresenta uma nova filosofia para o desenvolvimento de software. Sob seus valores e princpios aparecem diversas abordagens mais especficas, com diferentes idias, comunidades e lderes. Cada comunidade forma um grupo distinto, porm todas seguindo os mesmos princpios. comum inclusive a troca de conhecimento e prticas entre membros de diferentes comunidades, formando um ecossistema em torno de diversos mtodos, detalhado [Sato 2007]. Vale ressaltar que desenvolver um software, a necessidade do cliente deve ser tomada como foco principal. E, alm desse foco existente durante todo o processo de desenvolvimento, ela deve tambm atentar-se para as manutenes futuras, que so definidas como segunda parte do desenvolvimento.

2.3 Modelos de Maturidade de Software A indstria de software possui um processo de desenvolvimento no uniforme, muitas variaes podem acontecer no decorrer do processo. As organizaes devem

institucionalizar um processo de desenvolvimento, o qual seja bem definido e documentado para garantir a qualidade do produto desenvolvido. Caso profissionais sejam desligados no decorrer do desenvolvimento do produto, a organizao poder contratar novos profissionais e oferecer condies para estes continuarem o processo de forma gil e eficaz sem dificuldades. Para obter a qualidade do processo e consequentemente a qualidade do produto, as organizaes precisam optar por uma das normas de qualidade disponveis no mercado, porm poucas delas tm aceitao. As mais usadas no mercado so o CMMI, MPS. BR e a ISO [Silva 1999]. O interesse das empresas por mensurar a produo de um Software aumenta exponencialmente, adquirir uma qualificao de um modelo de maturidade torna-se um diferencial no meio tecnolgico de desenvolvimento de software. 2.3.1 MPS. BR O MPS. BR um programa mobilizador, de longo prazo, criado em dezembro de 2003, coordenado pela Associao para Promoo da Excelncia do Software Brasileiro (SOFTEX), que conta com apoio do Ministrio da Cincia e Tecnologia (MCT), Financiadora de Estudos e Projetos (FINEP), Servio Brasileiro de Apoio s Micro e Pequenas Empresas (SEBRAE) e Banco Interamericano de Desenvolvimento (BID). O objetivo do programa MPS. BR (acrnimo) a Melhoria de Processo do Software Brasileiro, com duas metas a alcanar a mdios e longos prazos: [Mps. Br. Guia Geral 2009]. a) meta tcnica, visando criao e aprimoramento do modelo MPS, com resultados esperados tais como: (i) guias do modelo MPS; (ii) Instituies Implementadoras (II) credenciadas para prestar servios de consultoria de implementao do modelo de referncia MR-MPS; (iii) Instituies Avaliadoras (IA) credenciadas para prestar servios de avaliao seguindo o mtodo de avaliao MA-MPS; (iv) Consultores de Aquisio (CA) certificados para prestar servios de consultoria de aquisio de software e servios relacionados [Mps. Br. Guia Geral 2009]. b) meta de mercado, visando disseminao e adoo do modelo MPS, em todas as regies do pas, em um intervalo de tempo justo, a um custo razovel, tanto em PME (foco principal) quanto em grandes organizaes pblicas e privadas, com resultados esperados tais como: (i) criao e aprimoramento do modelo de negcio MN-MPS; (ii) cursos, provas e

workshops; (iii) organizaes que implementaram o modelo MPS; (iv) organizaes com avaliao MPS publicada (prazo de validade de trs anos) [Mps. Br. Guia Geral 2009]. A base tcnica para a construo e aprimoramento deste modelo de melhoria e avaliao de processo de software composta pelas normas ISO/IEC 12207:2008 e ISO/IEC 15504-2 [Mps. Br. Guia Geral 2009]. Uma avaliao MPS realizada utilizando o processo e o mtodo de avaliao MA-MPS descritos no guia de avaliao. Uma avaliao MPS verifica a conformidade de uma organizao/unidade organizacional aos processos do MR-MPS. O modelo MPS definido em consonncia com a Norma Internacional ISO/IEC 12207:2008 [Mps. Br. Guia Geral 2009], adaptando-a as necessidades da comunidade de interesse. No Brasil, uma das principais vantagens do modelo seu custo reduzido de certificao em relao s normas estrangeiras, sendo ideal para micros, pequenas e mdias empresas. O modelo brasileiro divido em trs partes: Modelo de Referncia (MR-MPS), Mtodo de Avaliao (MA-MPS) e Modelo de Negcio (MNMPS). Cada componente descrito por meio de guias e/ou documentos do modelo MPS. Tabela I Diviso do MPS. BR Diviso MR-MPS MA-MPS MN-MPS Definio Modelo de referncia para melhoria do processo de software Mtodo de avaliao para melhoria do processo de software Modelo de negcio para melhoria do processo de software

O MPS. BR apresenta sete nveis de maturidade, o que um diferencial em relao aos outros padres de processo, como o CMMI que somente apresentam-se cinco nveis de maturidade. Que so: A - Em Otimizao; B - Gerenciado quantitativamente; C - Definido; D - Largamente Definido; E - Parcialmente Definido; F - Gerenciado; G - Parcialmente Gerenciado.

A capacidade do processo a caracterizao da habilidade do processo para alcanar os objetivos de negcio, atuais e futuros; estando relacionada com o atendimento aos atributos de processo associados aos processos de cada nvel de maturidade. [Mps. Br. Guia Geral 2009]. Os nveis de maturidade estabelecem patamares de evoluo de processos, caracterizando estgios de melhoria da implementao de processos na organizao. O nvel de maturidade em que se encontra uma organizao permite prever o seu desempenho futuro ao executar um ou mais processos. A escala de maturidade se inicia no nvel G e progride at o nvel A. Para cada um destes sete nveis de maturidade atribudo um perfil de processos que indicam onde a organizao deve colocar o esforo de melhoria. O progresso e o alcance de um determinado nvel de maturidade do MR-MPS se obtm quando so atendidos os propsitos e todos os resultados esperados dos respectivos processos e os resultados esperados dos atributos de processo estabelecidos para aquele nvel. A diviso em 7 estgios tem o objetivo de possibilitar uma implementao e avaliao adequada s micros, pequenas e mdias empresas. A possibilidade de se realizar avaliaes considerando mais nveis tambm permite uma visibilidade dos resultados de melhoria de processos em prazos mais curtos. [Mps. Br. Guia Geral 2009]. 2.3.2 CMMI

O CMMI (Capability Maturity Model Integration) um modelo de referncia que contm prticas (Genricas ou Especficas) necessrias maturidade em disciplinas especficas (Software Engineering (SW), por exemplo). Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI uma evoluo do CMM e procura estabelecer um modelo nico para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas [Glazer 2008]. A verso atual do CMMI (verso 1.2) apresenta dois modelos: CMMI for Development (CMMI-DEV) publicada em agosto de 2006. Dirige-se ao processo de desenvolvimento de produtos e servios. CMMI for Acquisition (CMMI-ACQ) publicada em novembro de 2007. Dirige-se aos processos de aquisio e terceirizao de bens e servios. O modelo CMMI v1.2 (CMMI-DEV) est estruturado em 5 nveis de maturidade, contendo 22 reas de processo (Process Area - PAs), as quais so divididas em 4 categorias: Gerenciamento de projetos, Gerenciamento de processos, Engenharia e Suporte. O CMMI um modelo de referncia que busca orientar as organizaes de software na implementao de

melhorias contnuas em seu processo de desenvolvimento. Contudo, este modelo define o que fazer, e no como fazer [Glazer 2008]. 2.4 Estimativas de Software Para discutir o papel das estimativas no estudo do nosso trabalho, primeiro preciso definir alguns conceitos que nem sempre so usados da forma correta, com uma troca freqente de significados. A indstria de software continua sentindo os efeitos da crise do software da dcada 80. Isto pode ser observado quando analisamos os trs principais sintomas da crise do software apresentados por [Pressman 2002], a saber: A produtividade no tem acompanhado a demanda por servios; A qualidade do software, em alguns sistemas, no adequada; As estimativas de prazo e custo so freqentemente imprecisas.

Este ltimo sintoma, que est associado a um dos principais problemas que a indstria de software tem enfrentado (a falta de previsibilidade de custo e prazo de projetos de software), pode levar a conseqncias desastrosas, tais como: conflitos entre o gerente do projeto e a equipe, entrega de software de baixa qualidade, perda de imagem da organizao e at mesmo o cancelamento do projeto. Assim, torna-se importante o investimento na implantao de um processo de estimativa efetivo, visando melhoria da previsibilidade de custo, prazo e esforo [Hazan 2007]. Segundo Pressman (2002) uma das atividades fundamentais do processo de gerenciamento de projetos de software o planejamento. Quando o projeto de software planejado, estimativas do esforo humano exigido, durao cronolgica do projeto e custo, como foi mencionado anteriormente, devem ser derivadas. Em muitos casos, estimativas so feitas usando-se a experincia passada como nico guia. Se um novo projeto for muito semelhante, em termos de tamanho e funo, a um projeto passado, provavelmente esse novo projeto exigir aproximadamente a mesma quantidade de esforo, tomar o mesmo tempo de calendrio e custar o mesmo valor em reais que o trabalho mais antigo. Mas, se o projeto romper novos horizontes? Ento, somente a experincia passada poder no ser suficiente. Outro fator relevante nas estimativas a qualidade de software ao final do desenvolvimento. A qualidade um item complexo e difcil de ser alcanado. Ela envolve um conjunto de fatores tcnicos, ambientais e humanos, que esto presentes em todas as etapas do

desenvolvimento de software, desde o incio at a concluso das atividades relacionadas [Davis 1994]. A relao entre esses fatores e o processo de desenvolvimento de software intrnseca, pois a qualidade de um produto est diretamente relacionada qualidade de seu processo de desenvolvimento, Davis (1994) afirma que a qualidade de um produto de software somente to boa, quanto o processo que o criou. E neste contexto, um dos fatores responsveis pela qualidade no processo de desenvolvimento de software mais uma vez o planejamento, que engloba um conjunto de atividades coletivas. Sendo a primeira atividade desse conjunto a estimativa. A estimativa de tempo e custo de desenvolvimento so atividades que exigem ateno e que exercem grande influncia no processo de desenvolvimento de software, principalmente, para organizaes privadas. A realizao de uma estimativa correta e precisa fundamental para a sobrevivncia e para a viabilidade das atividades da organizao [Monteiro 2005], [Pereira et. al 2005]. Isto torna a realizao das estimativas, um fator extremamente crtico e de crucial importncia no processo de desenvolvimento. O problema de se estimar um projeto de software envolve em sua grande maioria a previso de quatro variveis: o tamanho, o esforo, os prazos e a qualidade [Andrade 2008], [McGarry 2002], [Tait & Huzita 2006]. O esforo normalmente obtido atravs do clculo do tamanho; o prazo e o custo so obtidos a partir do esforo; a qualidade obtida por meio de um conjunto de fatores que vai muito alm do tamanho, do esforo e dos prazos e custos. Nesta seo sero abordadas algumas tcnicas de estimativas de software, que buscam auxiliar nesse processo. 2.5 Estimativas de Esforo e Prazo Para estimar esforo e prazo necessrio que uma abordagem para obteno da estimativa seja selecionada. As abordagens existentes podem ser divididas em [McGarry 2002]: Modelos paramtricos: assumem a existncia de uma relao matemtica entre tamanho, esforo e prazo. Tal relao afetada por parmetros de desempenho. Os relacionamentos so baseados em situaes tericas ou fatos histricos. Exemplos de modelos paramtricos so COCOMO (COnstructiveCOst Model) e Slim (Software lifeCycle Model). [Aguiar 2002].

Modelos baseados em atividades: tambm chamada de estimativa botton-up, esta modalidade consiste em enumerar atividades e estimar esforo e prazo para cada uma delas. Analogia: esta tcnica baseia-se na comparao das caractersticas do projeto com a de outros projetos concludos. As diferenas so identificadas e as mudanas necessrias so introduzidas no processo. Relaes simples de estimativas: uma simplificao dos modelos paramtricos. Neste caso, utilizam-se relaes matemticas simples baseadas em fatos histricos, ao invs de relaes matemticas abrangentes. De uma forma geral, os relacionamentos deste tipo no so aplicveis a organizaes e contextos diferentes dos originalmente utilizados para a coleta dos dados. Exemplo: Estimar o esforo a partir de um modelo linear do tipo Esforo = Tamanho x Produtividade. 2.6 Estimativas de Tamanho Mtricas de software orientadas ao tamanho so medidas diretas do software e do processo por meio do qual ele desenvolvido. Se uma organizao de software mantiver registros simples, uma tabela de dados orientada ao tamanho poder ser criada. A tabela relaciona cada projeto de desenvolvimento de software que foi includo no decorrer dos ltimos anos aos correspondentes dados orientados ao tamanho deste projeto. A partir dos dados brutos contidos na tabela, um conjunto de mtricas de qualidade e de produtividade orientadas ao tamanho pode ser desenvolvido para cada projeto. Mdias podem ser computadas levando-se em considerao todos os projetos. As medidas de tamanho de software surgiram com o objetivo de estimar esforo (nmero de pessoas/hora) e o prazo associado ao desenvolvimento de sistemas [Andrade 2004], [Tait & Huzita 2006]. A seguir sero descritas algumas tcnicas existentes na literatura [Andrade 2004], [Davis 1994], [Karner 1993], [McGarry 2002], [Schneider 2001], [Pressman 2002]. Linhas de Cdigo: A tcnica de mensurao por linhas de cdigo (LOC Lines of Code) uma das medidas mais antigas para se determinar o tamanho, esforo e, conseqentemente, produtividade no desenvolvimento de software [Pressman 2002]. Ela consiste basicamente na contagem da quantidade do nmero de linhas de cdigo de um programa de software.

Anlise de Pontos de Funo (APF): A tcnica de Anlise de Pontos de Funo APF a tcnica mais utilizada no mercado para mensurao do tamanho de projetos de desenvolvimento e melhoria de sistemas. Esta tcnica consiste na determinao do tamanho funcional do sistema atravs da viso do usurio, independentemente da tecnologia utilizada. A unidade de medida utilizada na determinao do tamanho do sistema o Ponto de Funo. Mark II (ou MK II): Tcnica que visa melhorar a escala de tamanho funcional, contando mais apuradamente a complexidade de processamento interno de Sistemas de Informaes Gerenciais. Uma das principais diferenas entre APF e MK II que a primeira tcnica conta arquivos lgicos uma vez para cada parte de software sendo mensurada, enquanto que a MK II conta tipos de entidade toda vez que elas so referenciadas em cada transao lgica. Segundo o manual do MK II, as duas mtricas pontuam similarmente os projetos com at 400 pontos de funo. Ultrapassando esse valor, a tendncia que a mtrica MK II pontue valores maiores que a APF. Feature Points: Nessa tcnica, alm das funes de dados e funes de transao, existe um item de anlise de algoritmos. Ela se prope resolver as dificuldades que a tcnica de Anlise de Pontos de Funo apresenta quando conta sistemas em tempo real de controle de processos, e outros que apresentam alta complexidade algortmica. Use Case Points (UCP): Tcnica proposta para medir o tamanho de projetos de software orientados a objeto o Use Case Points (ou Pontos por Caso de Uso) explora o modelo e a descrio do caso de uso, substitui algumas caractersticas tcnicas propostas pela APF, cria os fatores ambientais e prope uma estimativa de produtividade. A desvantagem que s pode ser utilizado por empresas que adotem os casos de uso como forma de expresso dos requisitos. 2.7 Padres de Software

Padres so solues bem sucedidas para um determinado problema [Alexander 1979], [Coplien 2004]. Ao documentarmos um padro estamos garantindo que ele : i) largamente utilizado e ii) considerado uma boa soluo para um problema especfico [Andrade 2008].

A origem dos padres de projeto deu-se com o trabalho feito pelo arquiteto Christopher Alexander 2 no final dos anos 70. Ele escreveu dois livros: A Pattern Language e A Timeless Way of Building que, alm de exemplificarem, descrevem seu mtodo para documentao de padres. O trabalho de Alexander, apesar de ser voltado para a arquitetura, possui uma fundamentao bsica que pode ser abstrada para a rea de software. Christopher Alexander afirma: cada padro descreve um problema no nosso ambiente e o cerne da sua soluo, de tal forma que voc possa usar essa soluo mais de um milho de vezes, sem nunca faz-lo da mesma maneira. Muito embora Alexander estivesse falando acerca de padres em construes e cidades, o que ele diz verdadeiro em relao aos padres de projeto orientados a objeto. Nossas solues so expressas em termos de objetos e interfaces em vez de paredes e portas, mas no cerne de ambos os tipos de padres est a soluo para um problema num determinado contexto [Gamma 2000]. Em geral, um padro tem quatro elementos essenciais: 1. O nome do padro uma referncia que podemos usar para descrever um problema de projeto, suas solues e conseqncias em uma ou duas palavras. Dar nome a um padro aumenta imediatamente nosso vocabulrio de projeto. Isso nos permite projetar em um nvel mais alto de abstrao. Ter um vocabulrio para padres permite-nos conversar sobre eles projetos e a comunic-los, bem como os custos e benefcios envolvidos, a outras pessoas. Encontrar bons nomes foi uma das partes mais difceis do desenvolvimento do nosso catlogo. 2. O problema descreve em que situao aplicar o padro. Ele explica o problema e seu contexto. Pode descrever problemas de projeto especficos, tais como representar algoritmos como objetos. Pode descrever estruturaras de classe ou objeto sintomtico de um projeto inflexvel. Algumas vezes, o problema incluir uma lista de condies que devem ser satisfeitas para que faa sentido aplicar o padro. 3. A soluo descreve os elementos que compem o padro de projeto, seus relacionamentos, suas responsabilidade e colaboraes. A soluo no descreve
2

Arquiteto e matemtico e urbanista da ustria. professor-emeritus da Universidade da Califrnia em Berkeley. Foi um dos crticos da arquitetura moderna apontando a desagregao social causada por ela. Seus estudos contriburam para a utilizao de padres geomtricos e matemticos no urbanismo e arquitetura

um projeto e de como um arranjo geral de elementos (classes e objetos, no nosso caso) o resolve. 4. As conseqncias so os resultados e anlise das vantagens e desvantagens (trade-offs) da aplicao do padro. Embora as conseqncias sejam raramente mencionadas quando descrevemos decises de projeto, elas so crticas para a avaliao de alternativas de projetos e para a compreenso dos custos e benefcios da aplicao do padro. As conseqncias para o software frequentemente envolvem balanceamento entre espao e tempo. Elas tambm podem abordar aspectos sobre linguagens e implementao. Uma vez que a reutilizao frequentemente um fator no projeto orientado a objetos, as conseqncias de um padro incluem o seu impacto sobre a flexibilidade, a extensibilidade ou a portabilidade de um sistema. Relacionar essas conseqncias explicitamente ajuda a compreend-las e avali-las. Dependendo do ponto de vista de algum um padro pode ter vrias interpretaes, ou seja, um determinado padro para um pessoa pode ser para outra um algo simplrio para outra. No nosso caso, o que abordaremos os padres tem certo nvel de abstrao. Padres de projeto no so projetos, como um determinado cdigo reutilizvel, mas descries de objetos e classes comunicantes que precisam ser personalizadas para resolver um problema geral de projeto num contexto particular. [Gamma 2000]. 2.8 Descrevendo os Padres de Projeto No faria sentido escrever padres sem uma forma definida para o entendimento geral, dessa forma como descrev-los? Notaes grficas, embora sejam importantes e teis, no so suficientes. Registrar decises, alternativas e anlise de custos e benefcios que levaram a ele, tais como exemplos concretos, ajudando a ver o projeto em ao relevante. Na literatura [Gamma 2000] usa-se um formato consistente. Cada padro dividido em sees de acordo com o gabarito a seguir. O gabarito fornece uma estrutura uniforme s informaes, tornando os padres de projeto mais fceis de aprender, comparar e usar.

Nome e classificao do padro

O nome do padro expressa a sua prpria essncia de forma sucinta. Um bom nome vital, porque ele se tornar parte do seu vocabulrio de projeto. Inteno e objetivo uma curta declarao que responde s seguintes questes: o que faz o padro de projeto? Quais os seus princpios e sua inteno? Que tpico ou problema particular de projeto ele trata? Tambm conhecido como Outros nomes bem conhecidos para o padro, se existirem.

Motivao Um cenrio que ilustra um problema de projeto e como as estruturas de classes e

objetos no padro soluciona o problema. O cenrio ajudar a compreender as descries mais abstratas do padro que vm a seguir. Aplicabilidade Quais so as situaes nas quais o padro de projeto pode ser aplicado? Que exemplos de maus projetos ele pode tratar? Como voc pode reconhecer essas situaes? Estrutura Uma representao grfica das classes do padro usando uma notao baseada na Object Modeling Techique (OMT) [Rumbaugh et al 1991]. Usam-se tambm diagramas de interao [Jacobson et al 1992], [Booch 1994] para ilustrar sequncias de solicitaes e colaboraes entre objetos. Participantes As classes e/ou objetos que participam do padro de projeto e suas responsabilidades. Colaboraes Como as classes participantes colaboram para executar suas responsabilidades.

Conseqncias Como o padro suporta a realizao de seus objetivos? Quais so os seus custos e

benefcios e os resultados da sua utilizao? Que aspectos da estrutura de um sistema ele permite variar independentemente? Implementao Que armadilhas, sugestes ou tcnicas voc precisa conhecer quando da implementao do padro? Existem consideraes especficas de linguagem? Exemplo de cdigo Fragmentos ou bloco de cdigo que ilustram como voc pode programar o padro. Usos conhecidos Exemplos do padro encontrados em sistemas reais.

2.9 Linguagem de Padres Diversos autores tm proposto centenas de padres nas mais diversas reas de aplicao, na construo civil, no desenvolvimento de software, como foi anteriormente mencionado. Esses padres so descobertos aps a abstrao de fatores comuns em diversos pares problema-soluo, podendo-se situar em vrias faixas de escala e abstrao. Existem padres de domnio especfico, como por exemplo, para sistemas multimdia educativos e tambm padres independentes de domnio, como por exemplo, padres para projeto de interface. H padres que ajudam a estruturar um sistema de software em subsistemas e outros que ajudam a programar aspectos de projeto particulares. Uma linguagem de padres uma coleo estruturada de padres que se apoiam uns nos outros para transformar requisitos e restries numa arquitetura [Coplien 2004] e uma forma de subdividir um problema geral e sua soluo complexa em problemas menores relacionados e suas respectivas solues. Uma linguagem de padres possui um contexto comum compartilhado entre todos os padres pertencentes a ela. Os padres podem ser usados isoladamente ou com demais padres relacionados na linguagem. Porm, cada um deles resolve seu prprio problema [Andrade 2008].

Analisando de formada detalhada os padres, percebe-se que um padro resolve um problema, mas quando realizamos a aplicabilidade pode gerar outros problemas, que podem ser resolvidos por outros padres. Geralmente, no encontramos padres isolados: um padro pode depender de outro no qual esteja contido, ou das partes que ele contm, ou ser uma variao de outro, ou ser uma combinao de outros. De maneira geral, um padro e seus variantes descrevem solues para problemas muito similares, que variam em algumas das influncias envolvidas. Dessa forma, pensa-se em uma forma de agrupar os padres existentes segundo algum critrio, de forma a facilitar sua recuperao e reuso. Isso pode ser feito por meio de colees de padres, catlogos de padres ou linguagem de padres. No nosso caso focaremos no agrupamento no caso de linguagem de padres. Uma linguagem de padres uma coleo estruturada de padres que se apiam uns nos outros para transformar requisitos e restries numa arquitetura [Coplien 1998]. Assim, os padres que esto contidos em uma linguagem de padres cobrem os aspectos importantes em um determinado domnio. Pelo menos um padro deve estar disponvel para aspecto da construo e implementao de um sistema de software: no pode haver vazios ou brancos. Segundo Maldonado uma linguagem de padres uma forma de subdividir um problema geral e sua soluo complexa em um nmero de problema especifica no contexto comum compartilhado pela linguagem. importante notar que cada padro pode ser usado separadamente ou com certo nmero de padres da linguagem. Isso significa que um padro sozinho considerado til mesmo se a linguagem no for ser usada em sua plenitude.

CAPTULO 3 UMA LINGUAGEM DE PADRES PARA ESTIMATIVAS DE SOFTWARE EM METODOLOGIAS GEIS

No processo de desenvolvimento de Software considera-se uma das atividades de maior responsabilidade realizar estimativas quantitativas do software tais como de tamanho, esforo, custo e prazo, entre outras, com forma de controlar, analisar e melhorar o processo de desenvolvimento de software, alm de auxiliar nas tomadas de decises organizacionais [Andrade 2008]. Equipes geis so caracterizadas por lder da equipe, normalmente no lugar do gerente de projeto, um proprietrio do produto, que representa o stakeholders e o negcio e uma equipe pequena, um grupo multifuncional com cerca de sete pessoas e que fazem a anlise, projeto, implementao, teste, etc. A realizao das estimativas de software considerada uma das primeiras atividades do processo de desenvolvimento de software e parte essencial da melhoria do processo de software. Estimativas eficientes permitem verificao da viabilidade do projeto, a elaborao de propostas tcnicas e comerciais, a confeco de planos e cronogramas e o acompanhamento efetivo do projeto [Monteiro 2005], [Andrade 2008]. A equipe de desenvolvimento, ento, confronta-se com um dilema logo no incio do projeto: produzir estimativas quantitativas, como mensurar custo, tempo e esforo de desenvolvimento do projeto mais prximo realidade e assim, minimizar possveis prejuzos financeiros. Para isso, ele deve conhecer a capacidade de sua equipe e os recursos com os quais pode contar para executar as atividades [Andrade 2008]. Ao elaborar uma estimativa para o desenvolvimento de um projeto de software, desejvel que haja um conhecimento sobre tcnicas de estimativas e uma viso global do escopo do projeto a ser gerenciado e um histrico de estimativas de outros projetos semelhantes o que capacita equipe quantificar, administrar e planejar mais experincias anteriores gera, na maioria das vezes, estouro de prazos e elevado custo de desenvolvimento [Andrade 2008]. Existem atualmente inmeras tcnicas para estimativas de software [Albrecht 1979], [Abran et al 2000], [Karner 1993], [FPA 1998], [Boehm et al 2000], [Symons 1991], todas elas na busca constante de realizar estimativas mais prximas do custo real do software [Andrade 2008]. As empresas de software de uma forma geral buscam estimativas exatas que retratem a eficincia do desenvolvimento e minimizem os fracassos do projeto. As grandes empresas (segundo [Mct 2005]), empresa com acima de 100 empregados, em particular, tm

facilidade na implantao de tcnicas que oferecem mais preciso, em virtude, principalmente, da disponibilidade de recursos financeiros e possibilidade de investimento em tais tcnicas. Para essas empresas, o foco principal minimizar a margem de erro das estimativas. As tcnicas robustas e precisas necessitam de maior esforo para contabilizao das medidas, onde na maioria das vezes a medio feita por fase do projeto, para posterior contagem do todo [Andrade 2008]. Nesse sentido, este trabalho est voltado para equipes geis que necessitam medir quantitativamente o software e apresenta uma linguagem de padres para estimativa de software, que tem como objetivo guiar tais equipes geis atravs de um processo simplificado de boas prticas de como estimar o software, desde o tamanho at o custo. O objetivo da linguagem de padres proposta auxiliar os times de desenvolvimento gil, ao longo de um projeto, a realizar estimativas de tamanho, esforo, prazo e custo. Boehm & Turner (2004) afirmam que em projetos que usam mtodos geis as estimativas so feitas de maneira diferente das realizadas em projetos tradicionais por suas caractersticas diferenciadas, como rpido feedback (opinio de retorno) e interaes curtas [Santana 2009], [Andrade 2008]. Vale lembrar que a linguagem aqui apresentada no possui o intuito de estimar o software com a menor margem de erro possvel, maior preciso, sendo isto deixado para as diversas tcnicas de estimativa de software existentes e que primam para minimizar esta margem. Este trabalho est voltado para oferecer aos times que utilizam mtodos geis um guia padro, simples e preciso o suficiente para o processo de obteno e calibragem das estimativas de software, como forma de atender realidade da empresa e auxili-los juntamente com o cliente nas tomadas de decises [Andrade 2008]. O formato dos padres apresentados, a linguagem, bem como a descrio geral do problema e soluo abordados por cada um deles, est descritos abaixo: Nome: nome do padro; Contexto: situao em que o padro deve ser aplicado; Problema: problema que o padro resolve; Foras: aspectos que influenciam na escolha da soluo do padro; Soluo: apresenta a soluo para o problema, no contexto definido; Exemplo: exemplo da aplicao do padro; Contexto Resultante: cenrio posterior aplicao do padro;

Racional: mostra porque a soluo resolve o problema, e como as foras foram priorizadas; Usos Conhecidos: descreve situaes existentes onde o padro utilizado; Padres Relacionados: identificam e relacionam outros padres que so importantes para o padro descrito.

Para se identificar o conjunto de padres que compem a linguagem proposta, bem como os relacionamentos entre eles utilizamos duas abordagens complementares. Inicialmente, realizamos um amplo estudo bibliogrfico, o qual envolveu: artigos [Andrade 2008], [Sato 2007], [Ma 2001], [Meirelles 2008], [Monteiro 2005], [Soares 2004], livros [Coplien 1998], [Cohn 2006], [Yoshima 2007] e revistas [Engenharia de Software 2009] sobre estimativas de software e metodologias geis. Em seguida, entrevistamos diversas empresas que utilizam metodologias geis com a finalidade de verificar quais as principais tcnicas adotadas para a obteno de valores de estimativas e se tais tcnicas eram fundamentadas. A linguagem composta por oito padres, os quais so amplamente utilizados no contexto gil para a obteno das principais estimativas. Primeiramente, os padres foram relacionados de acordo com o momento em que so utilizados em um processo de desenvolvimento gil, com a finalidade de esquematizar o grafo (ou mapa) da linguagem. A Figura 2 ilustra a relao entre os padres identificados no contexto da realizao de estimativas por equipes geis. Os retngulos representam os padres. O nome de cada padro informado dentro do seu retngulo. As setas de entrada representam as dependncias entre padres. Assim, uma seta saindo do retngulo referente ao padro estimativa do tamanho e entrando no retngulo do padro estimativa do esforo indica que a execuo deste ltimo depende (de alguma forma) da execuo do primeiro. A descrio de cada padro nas sees a seguir indica como e por que estas dependncias ocorrem.

Figura 2 Relao entre os padres identificados. Na tabela 2, tem-se um resumo dos padres encontrado de estimativas em metodologias geis, a primeira tem-se a nome do padro definido, a segunda coluna o problema para esse padro e na terceira a soluo encontrada. Tabela II Resumo dos Padres Nome do padro Problema 1. Estim Como elaborar ativa do tamanho estimativas do tamanho total de um escopo de desenvolvimento utilizando tcnicas simples e a um custo satisfatrio em projetos que so desenvolvidos com metodologias geis? Soluo Atribui-se um valor para cada Estria/Funcionalidade/Caso de Uso. Esta pontuao deve ser realizada pelo time. A pontuao obtida utilizando a tcnica Planning Poker.

2. Estim ativa do esforo

Como estimar o esforo necessrio para realizar uma determinada tarefa?

As Estrias definidas para o Sprint so divididas em tarefas. O esforo necessrio para a concluso de cada tarefa estimado em horas ideais. Esta estimativa pode basear-se em experincias anteriores. Estima com a frmula:

3. Estimativa velocidade time

Como estimar a de velocidade de um do time no desenvolvimento de um projeto de software? 4. Estim Como elaborar ativa de durao estimativas de prazo de desenvolvimento em projetos de software que utilizam metodologias geis? 5. Estimativa custo Como elaborar de estimativas de custo do desenvolvimento de software em equipes que adotam metodologias geis? 6. Nego Como convencer o ciao das cliente a aprovar as estimativas estimativas? 7. Colet Como coletar as a das medidas medidas reais de reais tamanho, esforo, velocidade, durao e custo em projetos que adotam metodologias geis? 8. Obten Como obter os o dos dados dados de medies histricos anteriores com o intuito de melhor a preciso das

A durao do projeto estimada com base na velocidade do time e no tamanho do projeto. Dada a velocidade do time, estimada em pontos por iterao, e o tamanho do projeto dado, estimado em pontos, projeta-se a quantidade de iteraes necessrias para a concluso do projeto. Dada a quantidade de iteraes necessrias e a durao de uma iterao projeta-se a durao total do projeto em dias ou meses. Atravs da frmula: EC = ED * CT (Papel) ou EC = ED * CT (S + R)

Marque uma reunio com o cliente. Apresente os valores de custo e prazo do software. Apresente ao cliente como os valores foram calculados. Atravs do Report das horas efetivamente gastas na execuo de cada uma das tarefas que compem uma estria e da velocidade real do time em cada Sprint. Com a coleta pode verificar erros de estimativas e auxiliares futuras estimativas.

Realize consultas na base de dados para obteno de dados histricos de projetos anteriores. Auxilia nas estimativas do projeto.

estimativas?

3.1 Running Example Considere uma empresa de Software, aqui nomeada de EMP. Considere ainda um projeto dessa empresa desenvolvido com metodologia gil, onde contm cerca de cinco profissionais entre analista, projetista, programadores, DBAs e testadores. Depois de algumas visitas ao cliente e pesquisas de requisitos, define o escopo do projeto. O software ser um sistema Web de gerenciamento de documentos pblicos, que permitir usurios na Internet mandem seus documentos, que sero armazenados no sistema e podero ser gerenciados por seus donos e vistos pelo resto do mundo atravs das visitas ao site. O sistema ter como funcionalidades principais cadastro de usurios; interface de gerenciamento de documentos; comentrios para os documentos e usurios; notas para documentos; sistema de busca; canais (grupos) de documentos e usurios. Com as funcionalidades levantadas, o Product Owner monta o Product Backlog, com as prioridades definidas de acordo com o valor de mercado/importncia para o cliente. Em nosso exemplo, usaremos a notao de quanto maior o nmero de prioridade, menor prioridade ele tem (1 prioridade mxima, 2 prioridade menor,, 99 prioridades quase inexistentes): Tabela III Product Backlog Funcionalidade Modelagem de dados Manter usurio Manter documentos pelos usurios Layout (Aparncia) da pgina Comentrios para os documentos e usurios Notas para documentos (ranking) Canais (grupos) de documentos e usurios Prioridade 1 2 3 4 5 6 7

3.1.1 Contexto:

Estimativas de tamanho total

Empresas que adotam metodologias geis necessitam estimar o tamanho de um determinado projeto de software (escopo) de forma rpida, simples e eficiente. Problema: Como elaborar estimativas do tamanho total de um escopo de desenvolvimento utilizando tcnicas simples e a um custo satisfatrio em projetos que so desenvolvidos com metodologias geis? Fora: 1) O facilitador, que no Scrum chamado de Scrum Master [Schwaber & Beedle 2002] [Schwaber 2004] e no XP de XP Coach, baseado em experincias anteriores prprias, pode simplesmente, estimar o tamanho de funcionalidades do software sem realizar nenhum clculo, porm tal estimativa pode acarretar um valor totalmente fora da realidade da funcionalidade do projeto, podendo causar prejuzo financeiro empresa; 2) O facilitador do time pode optar por estimar o tamanho de uma funcionalidade de acordo com a quantidade de linhas de cdigo por funcionalidade, porm tal tcnica depende da linguagem de programao utilizada, tornando-a instvel; 3) Estimativas de alto nvel em fases iniciais do projeto podem ser imprecisas, porm estimativas detalhadas demais podem despender tempo e custo s empresas que utilizam metodologias geis;

4) Estimativas baseadas na anlise do projeto quanto s suas funcionalidades e quantificao delas em relao complexidade podem ser simples e a um custo satisfatrio s empresas que adotam o modelo de metodologias geis; 5) Dados histricos de estimativas podem ajudar na preciso, uma vez que auxiliam na contabilizao das funcionalidades;

6) Especialistas externos e o uso de componentes prontos do mercado facilitam a elaborao de estimativas de forma rpida e precisa, porm as pequenas e mdias empresas no possuem recursos financeiros para investir em tal soluo. Soluo: A soluo mais largamente utilizada para a estimativa de tamanho por equipes geis conhecida como Pontos por Estria (Story Points) [Cohn 2006]. Para estimar o tamanho do projeto, atribui-se valores a funcionalidades (estrias) do projeto, utilizando-se comparaes que indicam o quanto uma estria mais complexa do que outra (tcnica denominada triangulao). O padro de comparao definido pelo o time. Contudo, a tcnica mais comum para a obteno do valor do tamanho das estrias o Planning Poker [Grenning 2002]. Planning Poker uma tcnica de estimativa baseada no consenso de toda a equipe (programadores, testadores, analistas etc), onde utilizado um conjunto de cartas (baralho) com valores especficos para representar tamanho. A distribuio desses valores comumente segue a srie de Fibonacci ou similar (1, 2, 3, 5, 8, 13, 40, 80, 100, ?). Pode-se pensar nesses valores como dias, horas, ou simplesmente pontos (que a medida mais comum) [Cohn 2006]. Frequentemente, utilizam-se tambm algumas cartas especiais, com os seguintes significados: 0 = Estria j realizada ou A estria to pequena que leva somente alguns minutos; ? = O participante no faz ideia alguma; Xcara de caf = Estou cansado demais para pensar. Vamos fazer uma pequena pausa. Durante a Reunio de Planejamento apresenta-se uma estria para toda a equipe. Cada membro possui um baralho (conjunto de cartas). Aps todos terem entendido claramente o objetivo da estria, cada membro da equipe escolhe uma carta e coloca na mesa virada para baixo. Quando todas as cartas estiverem lanadas, elas so viradas. Se por algum motivo aparece uma carta com um valor bem diferente ou caso no haja consenso esse o momento da equipe discutir de forma breve sobre a divergncia, e uma nova rodada acontece. Este

procedimento prossegue at que os valores das cartas convirjam para um valor ou um valor aproximado. Esse valor representa o tamanho da estria em pontos, unidade de medida da Estria [Cohn 2006]. Alm de essa tcnica ser divertida para a equipe, gozar de grande popularidade e reputao, ela melhora a comunicao entre os membros da equipe (as estrias ficaro mais clara para todos, dvidas so sanadas, etc.). ela reuni opinies de especialistas, analogias e discordncias.

Figura 3 - Planning Poker deck. (http://planningpoker.crisp.se) Aps verificar a pontuao das funcionalidades total, o somatrio de cada funcionalidade, possui-se, ento, o tamanho do projeto. Exemplo: Considerando o Sistema de Documentos descrito na seo 3.1 Uma boa mtrica deve levar em considerao a opinio de todo o time. Quando aplicamos uma mtrica deste tipo precisamos de mecanismos para que realmente a opinio da equipe seja sincera. Considerando ainda que cada membro da equipe contm um conjunto de cartas, tais como:

Figura 4 Baralho de cartas. (http://www.crisp.se/planningpoker) 1. Para cada funcionalidade o moderador da reunio ler a descrio, geralmente o Product Owner. Ordenada por prioridade ele ler a descrio detalhada de Modelagem de dados, como mostrado na tabela III.

Figura 5 - Product Owner. (http://www.crisp.se/planningpoker) 2. Cada membro da equipe atribui uma estimativa a Modelagem de dados. Nesse perodo ningum fala nada.

Figura 6 O Time pensa sobre o valor da estimativa. (http://www.crisp.se/planningpoker) 3. Quando todos j tiverem feito suas estimativas, ento as cartas sero viradas ao mesmo tempo revelando o que cada um estimou.

Figura 7 O Time mostra suas cartas. (http://www.crisp.se/planningpoker) Opa! Grande divergncia aqui. O time em particular o Senhor A e o Senhor C, precisam conversar sobre a tarefa e os porqus de suas estimativas sero to diferentes. Depois de alguma conversa Senhor A percebe que tinha esquecido algum item importante que deveria ser includo nessa tarefa. Senhor C percebe que com o modelo de dados apresentado, a tarefa deveria ser menor que 20. Depois da conversa (3 minutos no total) eles fazem outra rodada de estimativa para a mesma tarefa.

Figura 8 O Time mostra suas cartas, aps discusso. (http://www.crisp.se/planningpoker) Convergncia! Ok, no uma total convergncia. Mas eles concordam que uma estimativa de 5 deveria estar prximo do suficiente. E a vem a prxima tarefa, Manter usurio e assim sucessivamente. Tabela IV Product Backlog com estimativa de tamanho Estria/Funcionalidade Modelagem de dados Prioridade 1 Estimativa 5

Manter usurio Manter documentos pelos usurios Layout (Aparncia) da pgina Comentrios para os documentos e usurios Notas para documentos (ranking) Canais (grupos) de documentos e usurios Total de pontos do projeto Contexto Resultante: Vantagem

2 3 4 5 6 7

5 8 3 2 20 13 56

Para o ser humano, muito mais intuitivo fazer estimativas relativas do que absolutas. Por exemplo, no trivial responder a perguntas como: qual o peso de um cavalo ou qual o peso de um elefante? Mas fcil responder: quem pesa mais, o cavalo ou o elefante? Por isso, pontuar por comparao relativa mais efetivo do que elucubrar valores absolutos. o que ocorre no uso de Planning Poker. Desvantagem No existem valores genricos de comparao, no uma medida universal, podem-se criar relaes de descrio/valor, por exemplo, na sequncia de Fibonacci, que quanto maior o valor, maior sua complexidade e esforo de desenvolvido a funcionalidade tem. Racional: No contexto gil, a utilizao de Planning Poker evita que a estimativa seja manipulada. Segundo estudo de Haugen (2006) mostra que a melhor tcnica na eficincia das estimativas.

Usos Conhecidos: O mtodo de estimativa Story Points utilizado nas metodologias Scrum [Schwaber 2004], XP (eXtreme Programming) [Beck 1999] e Kanban [Vale 2008], alm de ser suportada pelas ferramentas FireScrum [Cavalcanti 2009] e Icescrum (2011). O uso de Story Points tambm pode ser encontrado em [Cohn 2006].

O Scrum e o XP utilizam a tcnica de pontuao Planning Poker [Schwaber 2004], [Beck 1999], a qual pode ser encontrada tambm na ferramenta de acompanhamento de equipes geis Open Source FireScrum [Cavalcanti 2009]. H tambm alguns mtodos geis que simplificam ainda mais o sistema de pontuao, como o caso do sistema Kanban [Vale 2008], onde existem apenas trs tamanhos possveis para uma estria (Story): pequeno, mdio e grande.

Padres relacionados: A partir dos dados estimados do tamanho do software pode-se obter a Estimativa do Esforo e Estimativa de velocidade do time. Com o padro Obteno de Dados Histricos possvel obter informaes sobre medies anteriores e auxiliar na classificao das funcionalidades e caractersticas do software a ser desenvolvido.

3.1.2 Contexto:

Estimativa do esforo

Durante o planejamento de uma iterao (Sprint) um subconjunto das estrias pertencentes ao Product Backlog selecionado para ser implementado. As estrias selecionadas iro compor o Sprint Backlog. Em seguida, essas estrias so divididas em tarefas, as quais sero alocadas aos desenvolvedores. Assim, as equipes geis necessitam estimar o esforo necessrio para realizar cada tarefa. Problema: Como estimar o esforo necessrio para realizar uma determinada tarefa? Fora: 1) Estimativas de esforo podem ser obtidas atravs de relatos de experincia dos especialistas da empresa, porm tais relatos podem remeter a dados discrepantes e fora da realidade, podendo causar prejuzos financeiros empresa, risco que as equipes geis no podem se submeter;

2) O cliente do projeto pode exigir um valor limite de esforo para a construo do Software, induzindo o facilitador da equipe gil a elaborar estimativas de esforo prximas a esse valor e fora da realidade da empresa; 3) O clculo de estimativas mais elaboradas ao considerar o tamanho do Software, alm de outros fatores, como por exemplo, o nvel de desenvolvimento exigido, coeso da equipe e maturidade do processo tornam a estimativa mais precisa, porm necessitam de tempo para serem planejadas e calculadas; 4) O clculo de estimativas de esforo baseadas no tamanho total do Software e de acordo com as funcionalidades do Software torna a estimativa mais precisa. Dados histricos de estimativas podem reforar a preciso do clculo do esforo, alm de fornecer dados como a Produtividade da Equipe gil. 5) Como a equipe em projeto gil que responsvel pelo o desenvolvimento das funcionalidades, sendo essa equipe pequena, multidisciplinar e capaz de desenvolver todos os requisitos. Caso um membro da equipe se ausente, por um motivo qualquer, como estimar esforo da equipe (faltando ou no um membro). Soluo: As tarefas tem granularidade de implementao e so estimadas em Horas Ideais. A escala para estimar tarefas discreta. Isto significa que apenas alguns nmeros podem ser usados. As tarefas podem ser estimadas em mltiplos de 1 hora e no mais que 16 horas. Se uma tarefa estimada em mais de 16 horas isso significa que a tarefa precisa ser dividida em tarefas menores [Cohn 2006]. A cada reunio de planejamento do Sprint criado um Sprint Backlog, o qual consiste no conjunto das estrias, potencialmente implantveis, que sero realizadas durante o Sprint. Em seguida, a equipe quebra cada uma dessas estrias em tarefas menores que podem ser cumpridas em um dia [Schwaber 2004]. Uma ferramenta bastante utilizada para auxiliar essa tarefa denominada Quadro de Tarefas (Taskboard), a qual consiste em um quadro que exibe todo o trabalho que o time est desenvolvendo durante um Sprint. Cada linha no Quadro de Tarefas um item do Product Backlog (estrias). Cada item do Product Backlog desdobrado em vrios itens (tarefas) de Sprint Backlog. Cada um desses itens menores representado por um carto de tarefa que colocado no Quadro de Tarefas, inicialmente na coluna "A fazer". O quadro atualizado continuamente no decorrer do Sprint. Se algum pensa em alguma nova tarefa, eles a escrevem em um novo carto e colocam-no no quadro.

Antes ou durante um Daily Meeting, as estimativas, em horas ideais, so alteradas (para mais ou menos) e os cartes so movidos no quadro. Exemplo: Considerando o Sistema de Documentos descrito na seo 3.1 Considerando que a equipe ir iniciar o primeiro Sprint. 1 2 A equipe pega a estria Modelagem de dados; Quebra em tarefas menores, que juntas podem fechar a resoluo da estria, tais como escolher ferramenta de modelagem, escolher banco de dados, criar modelo de dados, testar modelo. 3 Cada tarefa estimada em horas, no ultrapassando 16 horas por cada tarefa. 4 Sucessivamente realiza a quebra de tarefas e as estimativas de esforos para as demais estrias nos demais Sprints. Tabela V Product Backlog com Sprint e esforo

Estria/Funcionalidade Modelagem de dados Escolher ferramenta de modelagem Escolher banco de dados Criar modelo de dados Testar modelo

Prioridade 1

Estimativa 5

Sprint 1 1 1 1 1

Horas 6 10 16 4

Manter usurio Implementar funcionalidade Testar funcionalidade

2 2 2 10 4

3 4 5 6 7

Manter documentos pelos usurios Layout (Aparncia) da pgina Comentrios para os documentos e usurios Notas para documentos (ranking) Canais (grupos) de documentos e usurios

3 4 5 6 7

8 3 2 20 13

Aps a estimativa de esforo ser posta na planilha do Product Backlog coloca-se os valores de esforos no Quadro de Tarefas (Taskboard). Desta forma, o time pode visualizar

ao longo do Sprint os valores atribudos.

Figura 9 Quadro de tarefas (Taskboard) do primeiro Sprint. Contexto Resultante: Vantagem O lder do time gil ter o valor do esforo de desenvolvimento do projeto em horas. De posse desse valor, podero contabilizar outras medidas de estimativas como velocidade e durao total do projeto para auxiliar nas decises estratgicas do projeto; Desvantagem Umas desvantagens que temos com mtricas em software a expectativa com o comprimento dessas estimativas. Como no inicio do projeto, ou seja, nas primeiras iteraes as estimativas so muitas incertas, podem-se subestimar esforos iniciais, o que pode comprometer prazos iniciais [Yoshima 2007]. Racional: No contexto gil, projetos so desenvolvidos em interao (Sprint) teremos que estimar o esforo de funcionalidade e calibragem no Sprint. No existe uma frmula para atribuir um esforo a uma estria. A pontuao atribuda a cada tarefa de uma estria de acordo com experincias anteriores, onde o resultado em horas. Usos Conhecidos:

O mtodo de estimativa de esforo baseado em Tarefas e Horas Ideais utilizado nas metodologias Scrum [Schwaber 2004], XP (eXtreme Programming) [Beck 1999] e Kanban [Vale 2008], alm de ser suportado pelas ferramentas FireScrum [Cavalcanti 2009] e Icescrum (2011). O uso deste mtodo tambm pode ser encontrado em [Cohn 2006]. No XP, durante o planejamento de uma iterao, as estrias selecionadas para essa iterao so transformadas em tarefas. Em geral, as tarefas so menores do que uma estria inteira, uma vez que no se consegue implementar uma estria inteira em alguns poucos dias, e so estimadas em dias ideais. Algumas vezes, uma tarefa dar suporte para diversas estrias. Outras vezes, uma tarefa no estar relacionada diretamente com nenhuma estria em particular [Beck 1999]. J o mtodo Kanban registra apenas as atividades com durao significativa, ou seja, cuja estimativa seja maior que um ou dois dias ideais, de forma a no burocratizar o processo com registros de pequenas atividades executadas em minutos ou horas. Padres relacionados: A partir dos dados do padro de Estimativa de Tamanho do projeto pode-se realizar a o calculo do padro de Estimativa de esforo e com o auxilio do padro da Obteno dos dados histricos o time pode tem uma base de opinies. 3.1.3 Contexto: Equipes geis necessitam acompanhar o andamento do projeto ao longo do seu ciclo de desenvolvimento (Sprints). Neste sentido, um dos principais aspectos que precisam ser acompanhados a velocidade com que o projeto est sendo executado. Problema: Como estimar a velocidade de um time no desenvolvimento de um projeto de software? Foras: Estimativa de velocidade do time

1) Estimativa de velocidade pode ser obtida atravs de relatos de experincia da equipe, porm os relatos podem causar discrepncias o que pode prejudicar estimativas mostradas ao cliente do projeto; 2) O cliente do projeto pode exigir um valor da Produtividade por Sprint da equipe para a construo do Software, para conferir estimativas, induzindo o facilitador da equipe gil a elaborar estimativas de velocidade; 3) O clculo de estimativas da velocidade auxilia no clculo de estimativa da durao apresentado ao cliente do projeto;

Soluo: A velocidade expressa quantos pontos o time consegue vencer dentro de um perodo de tempo, tipicamente um Sprint. Assim, a velocidade, conforme possvel observar na Equao 1, medida em pontos por Sprint, isto , quantos pontos a equipe consegue entregar dentro de uma iterao. Este valor representa a velocidade que o time gil possui [Yoshima 2007]. (1)

A velocidade expressa quantos pontos o time consegue vencer dentro de um perodo de tempo, tipicamente um Sprint. Assim, a velocidade medida em pontos por Sprint, isto , quantos pontos a equipe consegue entregar dentro de uma iterao. Este valor representa a velocidade que o time gil possui [Yoshima 2007]. pode ser estimada de acordo com Cohn (2006): i) Baseando-se na velocidade do time em projetos anteriores, valores histricos; ii) Com base na velocidade do time nos primeiros Sprints, ou; iii) Atravs de uma previso, quando no se possui uma base histrica ou tempo para analise dos primeiros Sprints, baseado no esforo dos envolvidos e no tamanho do Sprint. Os valores histricos so super importantes, quando o projeto os tem. Porm, pode haver problemas de alteraes entre o os projetos antigos e os novos projetos e o time que pode impactar na estimativa da nova velocidade. Como por exemplo, atualizao de tecnologias. Ento, antes de utilizar os valores histricos importante fazer algumas A velocidade do time

perguntas. Tais como: As tecnologias so as mesmas? a mesma equipe? o mesmo cliente? So as mesmas ferramentas? O ambiente de trabalho o mesmo? Quem estimou foram as mesmas pessoas? As respostas de cada questo devem ser frequentemente sim, para garantir a transferncia das informaes da base histrica. Exemplo: Considerando o Sistema de Documentos descrito na seo 3.1 Considerando que a equipe finalizou dois Sprints. E onde ambos a equipe fez cinco pontos. 1. Clculo da estimativa da velocidade

Da, conclui-se que a estimativa da equipe para a velocidade do projeto 5 Point/Sprint. Racional Pelo o Apndice A observa-se que cerca de 90% das empresas que utilizam metodologias geis adotam o calculo da estimativa de velocidade apresentado. Uma formula que calcula a velocidade, com dados baseados no tamanho do projeto e no Sprint definido pela a equipe cria uma credibilidade de utilizao. Contexto Resultante: A estimativa de velocidade pode auxiliar diretamente na estimativa de durao, com esses valores o Product Owner poder confiar mais ao fechar a ordem de servio da Sprint com as estimativas de durao. Usos Conhecidos: O mtodo de estimativa da velocidade de uma equipe baseado na quantidade de pontos (tamanho das estrias) entregues por Sprint utilizado nas metodologias Scrum

[Schwaber 2004] e XP (eXtreme Programming) [Beck 1999], alm de ser suportado pelas ferramentas FireScrum [Cavalcanti 2009] e Icescrum (2011). O uso desta estratgia tambm discutido em [Cohn 2006]. No XP, trs ou quatro medidas mostram tipicamente o comportamento da equipe. Uma delas a velocidade do projeto o nmero de estrias (de determinado tamanho) que a equipe implementa por interao [Beck 1999]. J no Scrum o conceito de velocidade fundamental para realizar o Planejamento de Release, e mensurado como a quantidade de Story Points entregues no final de cada Sprint [Schwaber 2004]. Padres relacionados: A partir dos dados estimados do esforo do software pode-se obter a Estimativa de Velocidade do projeto. Com o valor do padro da Estimativa de tamanho agregado ao clculo da estimativa da velocidade. A estimativa de durao obtida com o auxlio da Estimativa de Velocidade do projeto. 3.1.4 Contexto: O lder do time, que no Scrum chamado de Scrum Master [Schwaber & Beedle 2002], [Schwaber 2004] e no XP de XP Coach, necessita quantificar ao cliente o prazo necessrio para a finalizao do projeto, uma vez que o cliente est interessado no retorno proporcionado pelo produto em desenvolvimento ou a ser construdo. Problema: Como elaborar estimativas de prazo de desenvolvimento em projetos de software que utilizam metodologias geis? Fora: Estimativa de durao

1. O cliente do projeto pode exigir um valor limite de prazo para entrega do produto, induzindo o lder da equipe gil a elaborar estimativas de prazo prximas a esse valor, fora da realidade da empresa e sem nenhum embasamento; 2. Estimativas de prazo podem ser obtidas atravs de relatos de experincias dos especialistas da empresa, porm tal valor ser subestimado ou sobreestimado, podendo causar, respectivamente, prejuzos financeiros empresa ou insatisfao ao cliente; 3. O lder da equipe gil pode obter o prazo total do projeto baseado em dados quantitativos de medio, como o esforo total e a quantidade de recursos disponveis, o que causa maior preciso estimativa; 4. O lder da equipe gil, o facilitador, pode estimar o prazo total atravs de tcnicas elaboradas que levam em considerao vrios fatores de ponderao, porm a utilizao de tais tcnicas despende tempo que os facilitadores geralmente no possuem. 5. Simplesmente pontuar o Product Backlog no traz grandes novidades para o projeto. O cliente, na figura do Product Owner, como responsvel primrio sobre o ROI (Return On Investment - Retorno sobre o Investimento) deseja mais mtricas. Basicamente as medidas importantes so custos e o prazo Soluo: A durao do projeto estimada com base na velocidade do time e no tamanho do projeto. Dada velocidade do time, estimada em pontos por Sprint (iterao), e o tamanho do projeto dado, estimado em pontos, projeta-se a quantidade de iteraes necessrias para a concluso do projeto. Dada quantidade de iteraes necessrias e a durao de uma iterao projeta-se a durao total do projeto em dias ou meses. Para representar o andamento do projeto, sua previsibilidade de durao, de uma maneira mais amigvel utiliza-se o grfico Burndown. Com o acompanhamento da linha principal do Burndown tem a previsibilidade de concluso do projeto, de acordo com a velocidade do time. Esse grfico possui uma linha secundaria que desenhada ao longo do desenvolvimento do projeto. Caso a linha secundria tenha grande discrepncia em relao linha principal isso tende h um erro no cumprimento do prazo, ou para mais ou para menos [Yoshima 2007]. Exemplo:

Sabendo-se que o Sistema de Documentos iniciou em 03/01/2011 e que dois Sprints j foram concludos com uma velocidade de 5 Point/Sprint, onde cada Sprint possui um Time Box de 1 semana. E que pela a Tabela III o projeto possui 56 pontos h serem vencidos. Ento, podemos projetar pelo o grfico de Burndown uma estimativa de fim do projeto.

Figura 10 Burndown do projeto.

Da, conclui-se que a previso de estima de durao do projeto de 11 Sprints, com cada Sprint sendo de uma semana. Como o projeto iniciou em 03/01/2011 observando o calendrio nota-se que o projeto poder ser finalizando em 11 semanas depois, ou seja, dia 18/03/2011. Contexto Resultante: A empresa obter o valor do prazo total de desenvolvimento do projeto em dias a partir de dados objetivos e racionais, podendo assim, negociar mais facilmente com o cliente ao fechar a Ordem de Servio. Racional: O responsvel pelo o time gil, necessitado agregar mais funcionalidade por Sprint, o que pode garantir maiores retornos do projeto para a empresa necessita quantificar

ao cliente o prazo necessrio para desenvolver o sistema solicitado, como forma de firmar um acordo e fechar o contrato. Usos Conhecidos: A estimativa da durao de um projeto de software a partir da velocidade e do tamanho do projeto encontrada nas metodologias Scrum [Schwaber 2004] e XP (eXtreme Programming) [Beck 1999]. O monitoramento do progresso do projeto realizado por meio de um grfico denominado Product Burndown Chart. Esse grfico mostra ao longo do tempo a quantidade de trabalho que ainda resta ser feito, sendo um excelente mecanismo para visualizar a correlao entre a quantidade de trabalho que falta ser realizada e a velocidade do time. Este grfico utilizado em diversas ferramentas de gerenciamento gil como o FireScrum [Cavalcanti 2011], Agilefant (2011), IceScrum (2011) e XPlanner (2011).

Padres relacionados: A partir dos dados estimados do tamanho do software pode-se obter a Estimativa do Esforo do desenvolvimento e da Estimativa de Prazo. Com o padro Obteno de Dados Histricos possvel obter informaes sobre medies anteriores e auxiliar na classificao das funcionalidades e caractersticas do software a ser desenvolvido. No caso descrito em contextos geis. Estimativa da velocidade o padro que trabalhada a favor do padro de prazo/durao citado de forma mais direta.

3.1.5

Estimativa de custo

Contexto: O lder do time (Scrum Master ou XP Coach) e o Product Owner necessitam obter o custo, ou seja, a despesa do projeto para a empresa como forma de negociar com o cliente o valor do desenvolvimento do software. Problema: Como elaborar estimativas de custo do desenvolvimento de software em equipes que adotam metodologias geis?

Fora: 1. O cliente do projeto pode exigir um valor de custo do produto, induzindo o lder da equipe gil a elaborar estimativas de custo, para apresentar ao cliente; 2. O custo do projeto vai alm do valor gasto com horas de desenvolvimento, deve-se levar em considerao: visitas realizadas ao cliente, eventuais treinamentos necessrios, reunies de planejamento e retrospectivas, entre outros; 3. O lder da equipe gil deve considerar dados histricos, Obteno de Dados Histricos, de projetos anteriores para considerar o esforo gasto durante o projeto;

Soluo: As metodologias geis ajustam as formas habituais de contrato. Em particular, os contratos de preo fixo/escopo fixo do lugar a contratos de preo fixo/data fixa/escopo razovel mente fixo [Beck 1999]. Dado que temos como premissas: i) A existncia de uma estimativa de durao, e;

ii) A estabilidade das equipes geis: As equipes geis so pequenas, auto organizadas e com pouca necessidade de gerenciamento, apresentam baixa rotatividade, utilizam semana de 40 horas (ou seja, no se deve fazer horas extras constantemente) e so altamente valorizadas. A estimativa de custo de um projeto de software (EC) pode ser dada pela estimativa da durao em meses (ED) multiplicada pelo custo mensal (CT) de cada um dos papis presentes na equipe (por exemplo, Scrum Master, Desenvolvedor, etc). Conforme se pode observar na Equao 2: EC = ED * CT (Papel) (2) Contudo, em alguns mtodos geis como o Kanban, por exemplo, os membros da equipe de desenvolvimento no possuem papis definidos [Vale 2008]. Neste caso, a frmula de clculo da estimativa de custo de um projeto pode ser simplificada, conforme ilustra a Equao 3: EC = ED * CT (Equipe) (3)

Nas metodologias tradicionais o custo pode crescer exponencialmente na medida em que aumentam as alteraes de requisitos. J nas metodologias geis as mudanas de requisitos causam um impacto menor no custo do projeto, o qual permanece relativamente estvel em todas as fases do desenvolvimento gil [Beck 1999]. Exemplo: Considerando que a metodologia utilizada no sistema de Documentos seja o Scrum com uma equipe composta de cincos membros, um Scrum Master, dois desenvolvedores, um DBA e uma analista de teste e que seus valores meses sejam os descritos abaixo. Tabela VI Papel por custo mensal

Papel Scrum Master DBA Desevolvedor Analista de Teste

Custo Mensal 5 mil 4 mil 3 mil 2 mil

Considerando ainda que o projeto deva ser concludo em trs meses, aplicando a equao de custo, temos: EC = ED * CT (Papel) = 3 * (5 + 4 + 2*3 + 2) = 3 * 17 = 51 mil Racional: Cada empresa deve guardar estas informaes em dados histricos para avaliao dos projetos subseqentes. O resultado do custo total do software depende consideravelmente da porcentagem de contribuio de cada profissional ao longo do projeto, na maioria das empresas que adotam metodologias geis. Superfaturar um pouco o custo do software melhor do que a situao contrria [Andrade 2008]. Usos Conhecidos: Os principais mtodos geis, tais como Scrum e XP, no especificarem como estimar o custo do desenvolvimento de um projeto de software. Contudo, constatamos por meio de uma pesquisa (Ver Apndice A), realizada com quarenta empresas que utilizam

mtodos geis, que esta forma de clculo do custo do software utilizada por cerca de 70% das empresas entrevistadas. Entre as empresas entrevistadas 55% utilizam uma das formas de clculo ilustradas nas equaes 2 e 3, 5% utilizam Anlise de Pontos de Funo (APF), 5% no realizam estimativas de custo e 7% no souberam responder.

Padres relacionados: O valor da estimativa de custo derivado a partir do valor da Estimativa de Prazo, que influencia nos valores finais do custo. A estimativa de custo est relacionada ao padro de Negociao das estimativas, onde os valores so mostrados e discutidos. 3.1.6 Contexto: O lder do time (Scrum Master ou XP Coach) e o Product Owner necessitam negociar com o cliente as estimativas realizadas, principalmente o prazo e o custo necessrio para a finalizao do projeto. Uma questo importante na negociao das estimativas do projeto o tipo de contrato do projeto, geralmente projetos tradicionais fixam prazo, custo, escopo e qualidade do projeto. No entanto, para projetos que utilizem metodologias geis mais vantajoso realizar um contrato para o projeto com escopo varivel. Assim, o projeto possui prazo, custo e qualidade fixos, e negocivel durante a execuo do projeto o escopo. Problema: Como convencer o cliente a aprovar as estimativas? Fora: 1. Como o lder da equipe gil, no Scrum representado pelo o ScrumMaster, pode optar por convencer o cliente quanto s estimativas sem despender tempo, podendo realizar a negociao atravs de troca de emails ou contato telefnico. No entanto, tal forma de convencimento pode gerar ao cliente m impresso e desleixe por parte da empresa; 2. O lder pode tentar convencer o cliente atravs de reunies, o que pode transmitir maior grau de segurana, organizao e ateno ao cliente, deixando-o mais confiante; Negociao das estimativas

3. O lder tenta convencer o cliente ao explicar minuciosamente como obteve os valores de prazo e custo do software. Assim, pode aumentar a segurana do cliente em relao a essas estimativas, tornando mais fcil a sua aprovao; 4. O lder do time gil tenta convencer o cliente ao apresentar um prottipo do projeto, com algumas telas de funcionalidades, alm de fazer um bom marketing para a venda do projeto, sem se ater muito a explicar como obteve os valores estimados. 5. O lder pode simplesmente apresentar os valores ao cliente, sem entrar nos detalhes de como foram obtidos. No entanto, tal tcnica arriscada, pois o cliente pode no se convencer dos valores de prazo e custo e desistir da negociao; Soluo: A soluo para este problema envolve algumas iniciativas: i) ii) iii) Marque uma reunio com o cliente; Apresente os valores de prazo e custo do desenvolvimento ao cliente; Apresente ao cliente as informaes de como foram calculados os valores apresentados; iv) Transmita segurana ao cliente, que o clculo dos valores justo e de acordo com as funcionalidades e complexidades exigidas por ele; v) Aps a verificao das estimativas, cria-se e assina-se a OS (Ordem de Servio) com os pontos e funcionalidade que sero alvo na Sprint. Ao longo das Sprints, ao adotar um contrato de escopo varivel, sempre ao incio de planejamento de cada Sprint, so negociados com o Product Owner o escopo que ser priorizado na Sprint, inclusive mudanas de escopo que foram adicionadas ao longo do projeto. Variantes: Na reunio, aps a apresentao dos valores por parte do gerente e tentativa de convencer o cliente: i) O cliente no aceita os valores; ii) O representa da equipe gil marca outra reunio com o cliente para apresentao de novos valores;

iii) O representa da equipe gil refaz os clculos na tentativa de atender a expectativa do cliente; iv) O representa da equipe gil apresenta os novos valores ao cliente; v) O cliente aceita os valores e assina a OS ( Ordem de Servio)

Contexto Resultante: o Vantagens Como o clculo das estimativas foi baseado em valores extrados a partir das funcionalidades do software, o lder da equipe gil possui maior embasamento para justificar o custo e prazo do desenvolvimento do software. Caso o cliente imponha resistncia quanto ao prazo/custo, o lder da equipe gil poder renegociar tenho como base valores consistentes, sem colocar em risco o lucro da empresa. o Desvantagens O cliente pode aceitar ou no os termos de prazo e custo de desenvolvimento do software. Caso o cliente aceite, o lder da equipe gil deve iniciar o desenvolvimento do software. Caso no aceite, o gerente deve analisar em quais aspectos da negociao houve falha.

Racional:

O lder poder insistir e discordar de algumas informaes no intuito de reduzir o custo do software e/ou receb-lo em menos tempo. Com isso, o lder ter que refazer os clculos de prazo e custo do software, e apresentar novamente ao cliente em outra oportunidade. Cabe ao lder de projeto negociar o prazo com o cliente e convenc-lo que o prazo obtido foi baseado em clculos derivados a partir de tamanho e esforo do software. O cliente deve estar ciente que em uma equipe gil a quantidade de recursos disponveis para a alocao nos projetos sempre reduzida, o que pode influenciar no prazo do projeto. Usos Conhecidos:

Um dos quatro conceitos chave do Manifesto gil [Ma 2011] indica que a colaborao do cliente mais importante do que negociao de contratos. Neste sentido, os principais mtodos geis como Scrum [Schwaber 2004], XP [Beck 1999] e Crystal [Cockburn 2002] baseiam-se neste conceito. Esses mtodos estimulam a colaborao contnua com o cliente, envolvendo-o no processo de desenvolvimento e negociando a cada Sprint o conjunto das estrias que sero desenvolvidas, mudanas de escopo ou de prioridade, o custo e at a continuidade ou no do projeto.

3.1.7 Contexto:

Coleta das medidas reais

No decorrer do processo de desenvolvimento necessrio coletar informaes reais sobre o andamento do projeto. A equipe gil deve definir e realizar as medies. Problema: Como coletar as medidas reais de tamanho, esforo, velocidade, durao e custo em projetos que adotam metodologias geis? Fora: 1. Realizar medies em um ambiente sem cultura de medies pode provocar resistncias; 2. Para definio das medies a serem realizadas necessrio planejamento por parte o facilitador da equipe gil. O planejamento e definio de tais mtricas so realizadas apenas uma vez no processo de desenvolvimento e atende a todos os projetos da empresa; 3. A organizao precisa estar disposta a encarar as medies como um investimento em longo prazo, visto que para disponibilizar a realidade da organizao com base em mtricas, necessrio tempo; 4. Para realizar as medies, o facilitador da equipe gil pode obter pessoalmente as informaes com os membros do projeto. No entanto, tal coleta por parte do lder gil faz com ele deixe de executar atividades prprias do seu papel;

5. A compra de uma ferramenta que automatize o processo de coleta e obteno de medidas reais e que possa ser integrada com as ferramentas de analise e desenvolvimento dos projetos torna o processo rpido e simples; 6. A equipe pode definir o marcos no projeto para medio. Cada membro do projeto responsvel pela a coleta das medidas nas datas definidas; Soluo: Atravs do Report das horas efetivamente gastas na execuo de cada uma das tarefas que compem uma estria e da velocidade real do time em cada Sprint. Os dados coletados devem ser armazenados em uma base de dados. Vale ressaltar que importante armazenar a mtrica utilizada para representar um ponto, uma vez que os pontos so aplicados de forma relativa e, por este motivo, podem possuir valores diferentes entre equipes diferentes, ou seja, um ponto pode valer 8 horas de desenvolvimento em uma equipe A ou 4 horas em uma equipe B. Esse valor pode ser uma poltica da prpria equipe ou pode ser determinado para cada projeto. Contexto Resultante: A empresa ter base de dados com dados histricos reais por projeto, podendo melhorar as estimativas em projetos futuros. Racional: Apesar da resistncia das pessoas para realizar as medies, a definio de medidas simples no tomam tempo da equipe gil. Com o decorrer do tempo esse tipo de atividade se torna habitual, o essencial insistir na importncia da medio para o futuro da empresa. Usos Conhecidos: Uma das atividades propostas pelo XP para guiar a equipe em direo melhoria contnua conhecida como tracking. O papel do tracker consiste em coletar mtricas para auxiliar a equipe a entender o andamento do projeto [Sato 2007]. Kent Beck descreve o papel do tracker em uma equipe de XP como algum responsvel por coletar periodicamente mtricas, a partir de dados obtidos com a equipe, e assegurar que a equipe compreenda o que est sendo medido. Algumas ferramentas como o [XPlanner 2011] apresentam

funcionalidades capazes de auxiliar o tracker na coleta e armazenamento das mtricas, alm de gerar relatrios comparando o tempo estimado com o tempo efetivamente gasto em cada atividade. O CMMI (SEI 2009) na rea de processo Medio e Anlise especifica a necessidade da coleta de dados durante o processo de desenvolvimento do Software. O MPS.BR (SOFTEX 2006) no processo Medio especifica o propsito e os resultados esperados das atividades relacionadas este processo, tais como: coleta e armazenamento das medidas, alm da anlise e divulgao dos resultados. 3.1.8 Obteno de dados histricos

Os membros da equipe realizam a coleta de medies de dados reais dos projetos envolvidos e armazenam tais dados. Dados histricos de projetos anteriores devem estar disponveis para que sejam utilizados com a finalidade de melhorar a preciso das estimativas.

Problema: Como obter os dados de medies anteriores com o intuito de melhor a preciso das estimativas? Foras: 1) O lder to time gil pode obter dados histricos atravs da sua prpria experincia em projetos anteriores, dados estes puramente intuitivos, podendo comprometer as estimativas;

2) O lder to time gil pode obter dados histricos de outras empresas ou do mercado de forma geral, dados estes que no esto de acordo com a realidade da empresa;

3) O lder to time gil pode obter dados histricos a partir de uma base consolidada na empresa que guarde essas informaes;

Soluo: No incio do projeto deve ser realizada consulta na base de dados para obteno de dados histricos de projetos anteriores. A coleta de dados histricos em projetos geis realizada geralmente na reunio na reunio de retrospectiva da Sprint. Esses dados do projeto

coletados iro servir para refinamento das estimativas da prxima Sprint. Contexto Resultante: Vantagens A empresa ter dados consolidados de acordo com seu prprio perfil. Com base em dados de projetos anteriores, o gerente de projeto poder calcular as estimativas com maior preciso. Desvantagens A Possibilidade de dbia interpretao dos dados histricos, prejudicando o clculo das estimativas. Para tanto, a base dos dados histricos necessita estar consolidada e claramente interpretada.

Racional:

Simplesmente consultar a base de dados no suficiente para melhorar a preciso das estimativas. necessrio, alm disso, fazer uma anlise criteriosa dos dados que so realmente relevantes e podem ser considerados no clculo das estimativas. Usos Conhecidos: Ferramentas para suportar a gesto de projetos que utilizam metodologias geis como FireScrum [Cavalcanti 2011], Agilefant (2011), IceScrum (2011) e XPlanner (2011), armazenam ao longo das Sprints dados para medir a velocidade do time, estimativas de tamanho e esforo do projeto, e estes dados servem de entrada para refinamento das estimativas das prximas Sprints e de projetos futuros. Padres Relacionados: Os dados histricos so obtidos a partir da coleta prvia de medidas reais, Coleta de Medidas Reais. Obtenha dados histricos de projetos anteriores para auxiliar na classificao das funcionalidades da Estimativa do Tamanho do Software. Na Estimativa de Esforo Total os dados histricos auxiliam na obteno da produtividade mdia da equipe. Na Estimativa do Custo Total os dados histricos auxiliam na porcentagem de esforo por atividade.

CONCLUSES
Atualmente, a obteno de estimativas de tamanho, prazo e custo, por exemplo, so de grande importncia para empresas que desenvolvem projetos de software. Essas estimativas iro influenciar a capacidade da organizao em cumprir prazos, desenvolver suas tarefas dentro do oramento e entregar produtos de qualidade. Porm, essa uma tarefa complexa, principalmente para equipes que adotam metodologias geis, as quais tm como caractersticas o feedback rpido e iteraes curtas. Este artigo apresentou uma linguagem de padres voltada para a estimativa de software em projetos que utilizam metodologias geis. A linguagem proposta constituda por oito padres e seus relacionamentos, os quais foram apresentados e discutidos. Acreditamos que os padres identificados podem ajudar as equipes geis na obteno das principais estimativas que precisam ser realizadas no decorrer de um projeto de software. Como trabalho futuro, pretende-se investigar os padres de estimativa de software em equipes geis que atuem em um ambiente de desenvolvimento distribudo de software (DDS) em escala mundial.

REFERNCIAS
Agilefant. The simplest solution that might work, <http://www.agilefant.org/>, Acessado em: 31 de julho de 2011. disponvel em:

Abran, A. et AL. Functional size measurement methods: Cosmicffp: Design and Fieltrials. In: Fesma-Aemes Software Measurements Conference, 2000. Aguiar, M. Estimando os projetos com COCOMO II. Developers Magazine Setembro. Disponvel em: http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ES_I_2010_2/COCOMO_II.pdf, Acessado em 27/10/2010, 2002. Albrecht, A.J. Measuring Applications Development Productivity. Proceedings of IBM Applic. Dev. Joint SHARE/GUIDE Symposium, Monterey, CA. 1979. Alexander, C. The Timeless Way of Building. Oxford University Press, New York, 1979. Aquiles, A. Acessado em Agosto http://alexandreaquiles.wordpress.com/2011/01/12/sobre-apf-e-agil/ 2011:

Andrade, E. L. P. Pontos de Caso de Uso e Pontos de Funo na Gesto de Estimativa de Tamanho de Projeto de Software Orientados a Objeto. Dissertao de Mestrado, Universidade Catlica de Braslia, Braslia, 2004 Andrade, T., Souza, J. Uma linguagem de Padres de Estimativa de Software para Micro e Pequena Empresas, 7 Conferncia Latino-Americana em Linguagens de Padres para Programao, 2008. Beck, K. Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999. Booch G. Object-Oriented Analysis and Design with Applications. Benjamin/Cummings, Redwood City, CA, 1994. Segunda edio. Boehm, B., Turner, R. Balancing agility and discipline: A guide for the perplexed 1 ed. Addison Wesley, 2004. Boehm, B. et al. Software Cost Estimation with COCOMOII. Prentice Hall, 2000. Grenning, James. Planning Poker, 2002. Acessado www.objectmentor.com/resources/articles/PlaninningPoker.zip em Julho 2011:

Buglione, L., Abran, A. Improving Estimations in Agile Projects: Issues and Avenues. In Proceedings of Software Measurement European Forum (SMEF), 2007. Cavalcanti, E. Firescrum: Ferramenta de Apoio Gesto gil de Projetos utilizando Scrum, Centro de Estudos e Sistemas Avanados do Recife (CESAR), Recife, 2009. Cockburn, A., Agile Software Development. Addison, Wesley, 2002 Cohn, M. Agile Estimating and Planning, Prentice Hall Professional Technical Reference, 2006. Coplien, J., Harrison, N. Organizational Patterns of Agile Software Development, Prentice Hall, 2004.

Coplien J. O. Software Design Patterns: Common Questions and Answers. The Patterns Handbook: Techniques, Strategies, and Applications, p. 311-320. Cambridge University Press, New York, USA, 1998. Davis, A., et al. Why is Requirements Engineering Underused? IEEE Computer Society Press, Volume 11, Issue 2, 1994. Gamma, E. Richard H., Ralph J. e Jonhson V. Padres de Projetos: Solues reutilizveis de software orientado a objeto.; Bookman; Porto Alegre 2000. Glazer, H., J. Dalton, D. Anderson, M. Konrad and S. Shrum. CMMI or Agile: Why not embrace both! Techinal Report, Software Engineering Institute (SEI), 2008. Goldman, A., Kon, F., Silva P. J. S., and J. W. Yoder. Being extreme in the classroom: Experiences in teaching XP. Journal of the Brazilian Computer Society, 10(2):1-17, 2004. Haugen, N. C. (2006). An Empirical Study of Using Planning Poker for User Story Estimation. Proceedings of the Conference on AGILE 2006 (pp. 23-34). Washington (DC): IEEE Computer Society. FPA. Function Point Analysis Counting Practices Manual. United Kingdom Software Metrics Association. Version 1.3.1, 1998. Grenning, James. Planning Poker, 2002. Acessado www.objectmentor.com/resources/articles/PlaninningPoker.zip em Julho 2011:

Grone, B. Conceptual Patterns. 13th Annual IEEE International Symposium and Workshop on Engineering of Computer Based Systems, 2006. Hazan, C. Anlise de pontos de funo, Engenharia de Software Magazine, DevMedia. Editorial, ano 1, 2 edio. Maio, 2008. Harrison, N. A Pattern Language for Shepherds and Sheep. Disponvel em: < http://www.mcs.vuw.ac.nz/~kplop/Shp.html>. Acessado em 29 de julho de 2011. Highsmith, J. Agile Software Development Ecosystems. Boston: Addison Wesley, 2002. Icescrum Your open source agile tool, disponvel em: <http://www.icescrum.org/>, Acessado em 31 de julho de 2011. Jacobson I.; Christerson M.; Jonsson P. e Overgaard G. Object-Oriented Software Enginnering - A Use Case Driven Approach. Addison-Wesley, Wokingham, England, 1992. Karner, G. Metrics for Objectory. Diploma Thesis. University of Linkping, Sucia. Dezembro, 1993. Ma, Manifesto para Desenvolvimento gil de Software, 2001. Disponvel em: <http://www.manifestoagil.com.br >. Acesso em: 24/04/2011. Meirelles P. R.M, Levantamento de Mtricas de Avaliao de Projetos de Software Livre, So Paulo, 2008. McGarry, J. Pratical Software Measurement. Addison Wesley. USA, 2002. MCT Ministrio de Cincia e Tecnologia. Pesquisa Nacional de Qualidade e Produtividade no Setor de Software Brasileiro. Brasil, 2005. Monteiro, T. C., Pires, C. G. S., Belchior, A. D. TUCP: Uma Extenso da Tcnica UCP, IV Simpsio Brasileiro de Qualidade de Software, Porto Alegre, 2005. Mps. Br. Guia Geral, Melhoria de Processo do Software Brasileiro, Maio de 2009.

Perreira, R; Motter; Nfrframework Priorizando a Usabilidade, UNISEP Trabalho de Concluso de Curso, Paran, 2005. Pressman, R. S. Engenharia de Software. 5 edio, So Paulo: McGraw-Hill, 2002. 567p. Rumbaugh L.; Blaha M.; Premerlani W.; Eddy F. Lorenson W. Object-Oriented Modeling and Design. Prentice Hall, Englewood Cliffs, NJ, 1991. Santana, Clio; Gusmo, Cristiane. Melhorias de Processo de Software no desenvolvimento gil. Revista Engenharia de Software. Ano 2, 14 ed. DevMedia, 2009 Sato, Danilo, Goldman, Alfredo. Uso eficaz de Mtricas em Mtodos geis de Desenvolvimento de Software. Dissertao (Mestrado) IME-USP. So Paulo, 2007. Schneider, G, Winters, J. Applying Use Cases: A Practical Guide, 2/e, Addison Wesley Professional, 2001. Schwaber, K. and M. Beedle, Agile Software Development with Scrum. Prentice Hall, 2002 Schwaber, K. Agile Project Management With Scrum, Microsoft Press, Redmond, Washington, USA, 2004.
S. E. I. (SEI). Cmmi for development. 2009. http://www.sei.cmu.edu/cmmi. Acessado em: 31 de julho de 2011. SOFTEX. MPS.BR Melhoria de Processo do Software Brasileiro, Guia Geral. Maio, 2006. Acessado em: 31 de julho de 2011.

Silva, E. M. M.e Nascimento, Rogrio P. C do. Modelo da Maturidade da Capacitao para Software. Pernambuco BRA Capes; Maro de 1999. Soares, M. S. Metodologias geis Extremem Programming e Scrum para o Desenvolvimento de Software. Revista Eletrnica de Sistemas de Informao. Vol. 3, p. 8-13, 2004. Symons, C. R. Software Sizing and Estimating. MKII FPA. JohnWiley and Sons, 1991. Tait, T. F. C. e Huzita, E. H. M. Gerncia de Projetos de Software. XIII Escola Regional de Informtica da SBC PR. Bandeirantes, 2006. Vale, A.A Histria de um Sistema Kanban, Agosto de 2008. Disponvel em: <http://www.phidelis.com.br/blogs/alissonvale/post/A-Historia-de-um-Sistema Kanban.aspx>. Acessado em: 31 de julho de 2011. XPlanner. Project planning and tracking tool for agile development teams, disponivel em: <http://www.xplanner.org/>, Acessado em: 31 de julho de 2011. Yoshima, R. Gerenciamento de projeto Scrum, Aspercom, 2007.

GLOSSRIO
Burndown Chart: Grfico que exibe o progresso dirio do time em funo do total de horas estabelecido. Daily Meeting: Reunio diria de 15 minutos para que o Scrum Master possa verificar que tarefas a sua equipe est desenvolvendo e identificar possveis impedimentos. Planning Meeting: Primeira reunio que acontece no projeto. uma reunio realizada para definir o Product Backlog e planejar o Sprint Backlog. Planning Poker: Mtodo, baseado na seqncia numrica de Fibonacci par a estimar o Product Backlog Product Backlog: Lista de itens definidos e priorizados pelo Product Owner, que incluem os requisitos funcionais e no funcionais de um sistema. Product Owner: Dono do projeto (cliente). Responsvel por definir o escopo do projeto junto ao Scrum Master. Scrum Master (Gerente do projeto): Sua responsabilidade desempenhar um papel de liderana, gerenciando os interesses do Product Owner mediante o time. Scrum Team: Time responsvel pelo desenvolvimento do projeto. Sprint: Iteraes que podem ter durao de 2 a 4 semanas. Sprint Backlog: Lista que contm as tarefas que o Scrum Team ir trabalhar durante o desenvolvimento da Sprint. Sprint Retrospective: A reunio de retrospectiva ocorre no final do projeto e seu objetivo entregar o produto e realizar uma demonstrao para que o Product Owner possa verificar se o produto produzido est de acordo com suas expectativas. Sprint Review: Reunio de reviso que ocorre no ltimo dia de desenvolvimento da Sprint com o objetivo de demonstrar as funcionalidades implantadas ao Scrum Master. Timer Box: Espao de tempo definido e cronometrado.

APNDICE A PESQUISA DE CAMPO

Uma pesquisa para verificar algumas informaes sobre as estimativas geis foi aplicada. Ao todo 43 empresas responderam entre os dias 29 de Julho e 08 de agosto de 2011. O questionrio foi composto das seguintes perguntas: 1. Qual sua experincia em projetos de desenvolvimento de software? 2. Qual o seu nvel de escolaridade? 3. Qual sua funo? 4. Voc possui alguma certificao? 5. H quanto tempo empresa utiliza mtodos geis? 6. Qual a quantidade de membros no seu time de desenvolvimento (Por equipe ou projeto)? 7. Quais mtodos geis a empresa utiliza? 8. Qual tcnica de estimativas de tamanho a empresa usa? 9. Qual tcnica de estimativas de esforo a empresa usa? 10. Qual a tcnica de velocidade a empresa usa?

11. Qual tcnica de estimativas de durao a empresa usa? 12. Qual tcnica de estimativas de custo empresa usa? 13. As tcnicas de estimativa usadas pela sua empresa baseiam-se em dados histricos? 14. Sua empresa realiza a coleta de medidas reais 15. Quais as medidas que sua empresa coleta? 16. Que tipo de contrato sua empresa utiliza? Alguns dados foram retirados da anlise dessa pesquisa. Pode-se verificar a seguir. Estimativa de tamanho

Ponto de funo 12%

Tcnica de estimativa de tamanho

Dias Ideais 12% Estimativa por experincia 2% Outros 5%

Ponto de caso de uso 9%

Planning Poker 60%

Estimativa de esforo
No sabe 2% No h 5% APF x velocidade, onde APF anlise por ponto de funo 2%

Tcnica de estimativa de esforo

Horas Ideais 70%

ETT PROD, onde ETT o tamanho do software e PROD a produtividade da equipe 21%

Estimativa de velocidade

Estimativa ajustada a cada sprint 3%

Tcnica de velocidade
No h 7%

Horas Planejadas / Horas Gastas 2%

No sabe 2%

PT/Sprint, onde PT so os pontos realmente feitos 86%

Estimativa de durao

Ponto de funo 7%

Tcnica de estimativa de durao

Atravs da velocidade, com a visualizao no Burndown 47%

Atravs da opinio da equipe 46%

Estimativa de custo

Ponto de funo 5%

Tcnica de estimativa de custo

Outros 12% No sabe 7%

ESF x P(Papel) x VlrHora(Papel), onde ESF estimativa de esforo e VlrHora valor da hora 30%

ESD * (CTEq + R), No h 5% onde ESD a estimativa de durao em meses, CTEq custo mensal da equipe e R demais recursos 25%

COCOMO 16%

Coleta das medidas reais

Realiza coleta de medidas

Sim, mas somente em alguns projetos 42%

No 26%

Sim 32%

Obteno dos dados histricos

Tcnica de estimativa baseiam-se em dados histricos

Sim, mas somente em alguns projetos 39% No 26%

Sim 35%