Universidade Federal de Pernambuco Centro de Informtica

RENATA ENDRISS CARNEIRO CAMPELO

XP-CMM2: Um Guia para Utilizao de Extreme Programming em um Ambiente Nvel 2 do CMM

ORIENTADOR Prof. Hermano Perrelli de Moura

Recife, novembro de 2003

UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMTICA PS-GRADUAO EM CINCIA DA COMPUTAO

RENATA ENDRISS CARNEIRO CAMPELO

XP-CMM2: Um Guia para Utilizao de Extreme Programming em um Ambiente Nvel 2 do CMM

ESTE TRABALHO FOI APRESENTADO PSGRADUAO EM CINCIA DA COMPUTAO DO CENTRO DE INFORMTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENO DO GRAU DE MESTRE EM CINCIA DA COMPUTAO. ORIENTADOR(A): HERMANO PERRELLI DE MOURA

RECIFE, NOVEMBRO/2003

Agradecimentos
Agradeo aos meus pais por tudo. Talvez por coisas que eu nem mesma reconhea neste momento. Mas, em especial, pelo amor, incentivo, por me darem tudo o que eu sempre precisei. Pela nossa linda famlia. Por serem meu porto seguro. Ao meu amor Z, companheiro e incentivador. Pelos finais de semana em casa comigo, para que eu pudesse estudar. Por escutar minhas angstias nos momentos em que eu achava que nunca ia chegar l. Por me incentivar nestes momentos. Por se mostrar orgulhoso a cada vitria ou captulo concludo ou artigo publicado. Por dividir minhas alegrias e tristezas nesta longa caminhada. s minhas queridssimas irms, que preenchem a minha vida de alegria. A todos os que fazem o C.E.S.A.R, local em que trabalho, que me proporciona crescimento e conhecimento. Sem meu trabalho, provavelmente no teria chegado l. Em especial, a duas pessoas importantssimas: Valena e Teresa. Por sempre terem me incentivado a concluir meu trabalho, por terem me proporcionado atividades relacionados minha pesquisa, por terem sido flexveis quando precisei de tempo para estudar, de projeto para realizar estudo de caso, de frias para descansar. Divido esta vitria com vocs tambm. Muito obrigada. A Hermano, por ter contribudo neste trabalho, pelas dicas valiosas, pelos trabalhos realizados de ltima hora (como as revises dos artigos perto da meia noite). Principalmente por me transmitir confiana, por diminuir minhas angstias e medos, por me colocar para cima nos momentos difceis. Aos professores Alexandre e Jones, por avaliarem este trabalho. Aos amigos e a todos que contriburam direta ou indiretamente neste trabalho. No daria para listar todos os nomes aqui. Obrigada a todos que torcem por mim.

Resumo

Recentemente a comunidade de software vem se deparando com um grupo de novas metodologias de desenvolvimento de software, classificadas como metodologias geis. Algumas das metodologias que fazem parte deste grupo so Extreme Programming (XP) e SCRUM, sendo XP a mais conhecida e utilizada. Estas metodologias possuem em comum um conjunto de valores para o desenvolvimento de software, priorizando: indivduos e iteraes sobre processos e ferramentas; software funcionando sobre documentao compreensiva; colaborao do cliente sobre negociao de contrato; resposta mudana sobre seguir um plano. Em paralelo disseminao das metodologias geis, os investimentos em qualidade de software vm aumentando a cada ano. Pesquisas realizadas sobre o setor de software, indicam um crescimento na adoo de modelos de qualidade como ISO 9000 e Capability Maturity Model for Software (CMM). Modelos de qualidade e metodologias geis possuem fundamentos opostos, como possvel notar nos valores definidos por essas metodologias. Autores de metodologias geis freqentemente criticam modelos como o CMM. Em contra partida, alguns trabalhos indicam que possvel utilizar as duas abordagens em um mesmo ambiente. Este trabalho apresenta o Guia XP-CMM2, que tem como objetivo apoiar as organizaes no uso da metodologia gil XP em um ambiente nvel 2 do CMM. Com o uso do Guia XP-CMM2, as organizaes devero se beneficiar da agilidade proposta por XP e da maturidade adquirida com o nvel 2 do modelo de qualidade de software mais respeitado do mundo, o CMM. Para a elaborao do Guia XP-CMM2, foi realizado inicialmente um diagnstico da satisfao de XP ao nvel 2 do CMM e, depois, para cada problema identificado, uma soluo foi proposta. Finalmente o Guia XP-CMM2 foi aplicado em dois ambientes distintos visando avaliao dos resultados obtidos. Palavras-chave: Capability Maturity Model (CMM), Extreme Programming, XP, Metodologias geis, Guia XP-CMM2.

Abstract
Software community has recently been faced to a group of new methodologies on software development, named "agile methodologies". Some of these methodologies are Extreme Programming (XP) and SCRUM, being XP the most known and used. These methodologies share some values for software development: individuals and iteractions over processes and tools; software working over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. Along with the spread of agile methodologies, the investiments on software quality have been increasing each year. Researches on software indicates an increase on using quality models like ISO 9000 and CMM. Quality models and agile methodologies have opposite fundamentals, as one can figure out with the values defined by each methodology. Agile methodologies' authors frequently criticize models like CMM. In contrast, some papers indicate that it is possible to use both in the same environment. This study presents the XP-CMM2 Guide, wich has the objective of supporting the organizations on using XP in a CMM level 2 environment. Using the XP-CMM2 Guide, the organizations should have benefits on both the agility proposed by XP and the maturity acquired by the level 2 of the most respectful software quality model, CMM. In order to create the XP-CMM2 Guide, it was initially done a diagnosis on the satisfaction of XP through level 2, and after, for each problem recognized, one solutions was proposed. Finally, the XP-CMM2 Guide was applied in two different environments aiming the evaluation of the obtained results.

Keywords: Capability Maturity Model (CMM), Extreme Programming, XP, Agile Methodologies, XP-CMM2 Guide.

10

ndice
1 1.1 1.1.1 1.1.2 1.2 1.3 2 2.1 2.2 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.5 3 3.1 3.1.1 3.1.2 3.2 3.3 3.3.1 3.4 INTRODUO ................................................................................................ 21 MOTIVAO ........................................................................................................ 21 Metodologias geis........................................................................................ 24 O Problema ..................................................................................................... 26 OBJETIVOS DO TRABALHO ................................................................................... 28 ESTRUTURA DA DISSERTAO ............................................................................ 29 EXTREME PROGRAMMING ...................................................................... 31 INTRODUO ....................................................................................................... 31 A ESTRUTURA DE XP .......................................................................................... 33 UM PROJETO XP.................................................................................................. 37 Papis.............................................................................................................. 37 Planejamento .................................................................................................. 38 Desenvolvimento ............................................................................................ 41 Acompanhamento........................................................................................... 45 Consideraes Importantes............................................................................. 46 CRTICAS A EXTREME PROGRAMMING ................................................................ 46 Dificuldade em manuteno ........................................................................... 46 Questes associadas efetividade da programao em pares ........................ 46 Experincia da equipe..................................................................................... 47 Dificuldade associada ao cliente on site ......................................................... 48 Dificuldade para estabelecer contrato de custo e tempo fixo e escopo varivel 48 RESUMO .............................................................................................................. 49 CAPABILITY MATURITY MODEL FOR SOFTWARE ........................ 180 O MODELO CAPABILITY MATURITY MODEL FOR SOFTWARE ............................ 180 A Estrutura do CMM.................................................................................... 181 Os Nveis de Maturidade do CMM .............................................................. 185 CMMI ............................................................................................................... 188 AVALIAO CMM ............................................................................................ 188 Software Capability Evaluation (SCE)......................................................... 189 RESUMO ............................................................................................................ 196
11

4 4.1 4.1.1 4.1.2 4.1.3 4.2 4.2.1 4.2.2 4.3 4.3.1 4.3.2 4.4 4.4.1 4.4.2 4.5 4.5.1 4.5.2 4.6 4.6.1 4.7 4.7.1 4.7.2 4.8 5 5.1 5.2 5.2.1 5.2.2 5.2.3 5.3 5.3.1 5.3.2 5.3.3 5.3.4

DIAGNSTICO XP-CMM2 ......................................................................... 197 O DIAGNSTICO ................................................................................................ 198 Escopo do Diagnstico ................................................................................. 198 Metodologia para Realizao do Diagnstico.............................................. 200 Nomenclatura Utilizada no Diagnstico....................................................... 200 MAPEAMENTO DE XP NO CMM ........................................................................ 202 Mapeamento dos Papis ............................................................................... 202 Mapeamento de Termos ............................................................................... 203 DIAGNSTICO DA KPA GERENCIAMENTO DE REQUISITOS ................................ 203 Diagnstico de Satisfao das Prticas-chave.............................................. 203 Sumrio do Diagnstico de Satisfao das Prticas-chave .......................... 206 DIAGNSTICO DA KPA PLANEJAMENTO DE PROJETOS DE SOFTWARE............... 206 Diagnstico de Satisfao das Prticas-chave.............................................. 207 Sumrio do Diagnstico de Satisfao das Prticas-chave .......................... 216 DIAGNSTICO DA KPA ACOMPANHAMENTO DE PROJETOS DE SOFTWARE ........ 217 Diagnstico de Satisfao das Prticas-chave.............................................. 218 Sumrio do Diagnstico de Satisfao das Prticas-chave .......................... 223 DIAGNSTICO DA KPA GARANTIA DA QUALIDADE DE SOFTWARE ................... 224 Diagnstico de Satisfao das Prticas-chave.............................................. 224 DIAGNSTICO DA KPA GERNCIA DE CONFIGURAO DE SOFTWARE ............. 226 Diagnstico de Satisfao das Prticas-chave.............................................. 226 Sumrio do Diagnstico de Satisfao das Prticas-chave .......................... 229 RESUMO ............................................................................................................ 230 GUIA XP-CMM2............................................................................................ 231 A ABORDAGEM UTILIZADA ............................................................................... 232 SOLUO PARA A KPA GERENCIAMENTO DE REQUISITOS ................................ 233 RM.Ac2 ........................................................................................................ 233 RM.Ac3 ........................................................................................................ 235 Sumrio do Guia para Implementao da KPA............................................ 236 SOLUO PARA A KPA PLANEJAMENTO DE PROJETOS DE SOFTWARE .............. 237 SPP.Ac4........................................................................................................ 237 SPP.Ac6........................................................................................................ 237 SPP.Ac7........................................................................................................ 238 SPP.Ac9........................................................................................................ 239
12

5.3.5 5.3.6 5.3.7 5.3.8 5.3.9 5.3.10 5.4 5.4.1 5.4.2 5.4.3 5.4.4 5.4.5 5.4.6 5.4.7 5.4.8 5.5 5.6 5.6.1 5.6.2 5.6.3 5.6.4 5.6.5 5.6.6 5.6.7 5.6.8 5.7 5.7.1 5.7.2 5.7.3 5.7.4 5.7.5 5.7.6 5.8 5.8.1

SPP.Ac10...................................................................................................... 240 SPP.Ac11...................................................................................................... 240 SPP.Ac13...................................................................................................... 241 SPP.Ac14...................................................................................................... 241 SPP.Ac15...................................................................................................... 241 Sumrio do Guia para Implementao da KPA............................................ 242 SOLUO PARA A KPA ACOMPANHAMENTO DE PROJETOS DE SOFTWARE ........ 244 SPTO.Ac3..................................................................................................... 244 SPTO.Ac5..................................................................................................... 245 SPTO.Ac6..................................................................................................... 245 SPTO.Ac7..................................................................................................... 245 SPTO.Ac10................................................................................................... 246 SPTO.Ac11................................................................................................... 246 SPTO.Ac13................................................................................................... 247 Sumrio do Guia para Implementao da KPA............................................ 247 SOLUO PARA A KPA GARANTIA DA QUALIDADE DE SOFTWARE ................... 249 SOLUO PARA A KPA GERENCIAMENTO DE CONFIGURAO DE SOFTWARE .. 250 SCM.Ac1 ...................................................................................................... 251 SCM.Ac2 ...................................................................................................... 252 SCM.Ac3 ...................................................................................................... 252 SCM.Ac4 ...................................................................................................... 253 SCM.Ac8 ...................................................................................................... 253 SCM.Ac9 ...................................................................................................... 254 SCM.Ac10 .................................................................................................... 254 Sumrio do Guia para Implementao da KPA............................................ 255 VISO GERAL DA SOLUO .............................................................................. 256 Planejamento de Projeto de Software........................................................... 256 Gerenciamento da Configurao de Software.............................................. 257 Garantia da Qualidade de Software .............................................................. 258 Acompanhamento de Projeto de Software ................................................... 258 Gerenciamento de Requisitos ....................................................................... 258 Ferramentas e Templates .............................................................................. 259 ANLISE DA SOLUO ...................................................................................... 260 Impacto do Guia XP-CMM2 s Prticas de XP ........................................... 260
13

5.8.2 5.8.3 6 6.1 6.2 6.3 6.4 6.5 6.5.1 6.5.2 6.5.3 6.6 6.7 6.7.1 6.7.2 6.7.3 6.7.4 6.8 6.9 7 7.1 7.2 7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 7.3 7.4 7.5

Impacto do Guia XP-CMM2 aos Valores e Princpios de XP ..................... 261 Aderncia ao Nvel 2 do CMM .................................................................... 261 APLICAO DO GUIA XP-CMM2 ........................................................... 263 OBJETIVOS DA APLICAO DO GUIA XP-CMM2 .............................................. 264 O AMBIENTE...................................................................................................... 264 SELEO DE UM PROJETO PARA ESTUDO DE CASO ............................................ 265 O PROJETO SELECIONADO ................................................................................. 266 A METODOLOGIA UTILIZADA ............................................................................ 267 O ProSCes .................................................................................................... 269 O Procedimento de Garantia da Qualidade do ProSCes............................... 270 Resultados Esperados ................................................................................... 273 CRONOGRAMA ................................................................................................... 274 O EXPERIMENTO................................................................................................ 276 Uso de XP no Projeto ................................................................................... 276 O Planejamento de Garantia da Qualidade no Projeto ................................. 279 As Auditorias Realizadas.............................................................................. 279 Implementao das KPAs no Projeto ........................................................... 288 APLICAO DO GUIA XP-CMM2 EM UMA EMPRESA INCUBADA ...................... 293 CONSIDERAES FINAIS .................................................................................... 295 CONCLUSES E TRABALHOS FUTUROS............................................. 297 PRINCIPAIS CONTRIBUIES .............................................................................. 298 DIFICULDADES ENCONTRADAS.......................................................................... 298 Falta de Rigor de XP .................................................................................... 299 Trabalho Interpretativo ................................................................................. 299 Descaracterizao de XP .............................................................................. 300 Aplicao em um Projeto Real ..................................................................... 301 Trabalhos Relacionados................................................................................ 301 ARTIGOS PUBLICADOS ....................................................................................... 302 TRABALHOS FUTUROS ....................................................................................... 303 CONSIDERAES FINAIS .................................................................................... 304 RELATRIO DE AUDITORIA DA UNIDADE DE 310 - TEMPLATE DO PLANO DO PROJETO ................................ 317
14

REFERNCIAS ......................................................................................................... 305 APNDICE A NEGCIO

APNDICE B

APNDICE C
APNDICE D

- TEMPLATE DO DOCUMENTO DE REQUISITOS .......... 326 - TEMPLATE DO PLANO DE GERNCIA DE

CONFIGURAO..................................................................................................... 329

15

16

Lista de Figuras
FIGURA 1-1 - METODOLOGIA APLICADA PARA DESENVOLVIMENTO DESTE TRABALHO .. 29 FIGURA 2-1 CURVA DO CUSTO DA MUDANA .............................................................. 42 FIGURA 2-2 CUSTO DA MUDANA NO TEMPO DE DESENVOLVIMENTO ......................... 43 FIGURA 2-3 CUSTO DA MUDANA SEGUNDO XP.......................................................... 43 FIGURA 3-1 - ESTRUTURA DO CMM.............................................................................. 181 FIGURA 3-2 O CMM EM NMEROS ............................................................................. 184 FIGURA 3-3 - NVEIS DE MATURIDADE DO CMM .......................................................... 185 FIGURA 6-1 - ORGANOGRAMA NO CONTEXTO DO GRUPO DE SQA ................................. 268 FIGURA 6-2 CICLO DE VIDA DO RUP .......................................................................... 269 FIGURA 6-3 - O JOGO DO PLANEJAMENTO NO XPLANNER .............................................. 277 FIGURA 4 - CAPA DO TEMPLATE DO DOCUMENTO DE REQUISITOS ................................ 326 FIGURA 5 - PLANILHA ESTRIAS DO TEMPLATE DO DOCUMENTO DE REQUISITOS ........ 327 FIGURA 6 - PLANILHA RECURSOS CRTICOS DO TEMPLATE DO DOCUMENTO DE REQUISITOS ........................................................................................................... 328

17

18

Lista de Tabelas
TABELA 1-1 - RESULTADOS DOS PROJETOS DE SOFTWARE SEGUNDO O CHAOS REPORT [20] ......................................................................................................................... 22 TABELA 3-1 - KPAS POR NVEL DE MATURIDADE ......................................................... 183 TABELA 3-2 - PRINCIPAIS CARACTERSTICAS DOS NVEIS DE MATURIDADE ................... 187 TABELA 4-1 - SIGLAS UTILIZADAS PARA AS KPAS DO CMM NVEL 2 ........................... 201 TABELA 4-2 - SIGLAS UTILIZADAS PARA AS CARACTERSTICAS COMUNS DO CMM ....... 201 TABELA 4-3 - MAPEAMENTO DE PAPIS CMM E XP ..................................................... 202 TABELA 4-4 - MAPEAMENTO DE CONCEITOS CMM E XP .............................................. 203 TABELA 4-5 - SATISFAO DAS PRTICAS DE RM POR XP............................................ 206 TABELA 4-6 - BIG PLAN ................................................................................................. 210 TABELA 4-7 - PLANEJAMENTO DE RELEASE ................................................................... 210 TABELA 4-8 - DATAS DE RELEASES ................................................................................ 210 TABELA 4-9 - SATISFAO DAS PRTICAS DE SPP POR XP ........................................... 217 TABELA 4-10 - SATISFAO DAS PRTICAS DE SPTO POR XP ...................................... 224 TABELA 4-11 - SATISFAO DAS PRTICAS DE SCM POR XP ....................................... 230 TABELA 5-1 - SUMRIO DO GUIA PARA IMPLEMENTAO DA KPA RM ....................... 237 TABELA 5-2 - SUMRIO DO GUIA PARA IMPLEMENTAO DA KPA SPP ....................... 244 TABELA 5-3 - SUMRIO DO GUIA PARA IMPLEMENTAO DA KPA SPTO.................... 249 TABELA 5-4 - SUMRIO DO GUIA PARA IMPLEMENTAO DA KPA SCM ..................... 256 TABELA 5-5 - FERRAMENTAS SUGERIDAS PELO GUIA XP-CMM2 ................................ 259 TABELA 5-6 - TEMPLATES SUGERIDOS PELO GUIA XP-CMM2 ..................................... 259 TABELA 6-1 AUDITORIAS REALIZADAS ....................................................................... 275 TABELA 6-2 - DESVIOS E RECOMENDAES DA AUDITORIA DE DEZEMBRO DE 2002 .... 281 TABELA 6-3 - DESVIOS E RECOMENDAES DA AUDITORIA DE FEVEREIRO DE 2003 .... 284 TABELA 6-4 - DESVIOS E RECOMENDAES DA AUDITORIA DE MAIO DE 2003............. 286

19

20

1 Introduo

Este captulo introduz conceitos e apresenta a motivao para este trabalho conforme descrito abaixo: Seo 1.1 Motivao: descreve a motivao para realizao deste trabalho, incluindo aspectos sobre engenharia de software, qualidade de software, metodologias geis e o problema ao qual este trabalho se prope a resolver; Seo 1.2 Objetivos do Trabalho: descreve os objetivos do trabalho e como o mesmo ser conduzido; Seo 1.3 Estrutura da Dissertao: descreve como este documento est organizado.

1.1 Motivao
Um dos fatores que mais tem influenciado a mudana de vida das pessoas a produo de software. Software est atualmente, especialmente com o advento da Internet, em todos os locais e atividades da sociedade: hospitais, empresas, controle de trfego areo, educao, etc. H muito tempo, o software deixou de apenas automatizar as tarefas realizadas pelas pessoas para tambm mudar a forma destas realizaes. Nos anos 60 e 70 a produo de software se dava de forma desorganizada e sem nenhuma sistematizao. Isto gerou uma grande insatisfao por parte dos consumidores dos softwares produzidos. Esta insatisfao surgiu em decorrncia de atrasos em cronogramas, oramentos estourados e da baixa qualidade do produto final. Todos estes problemas ficaram conhecidos mundialmente como a Crise do Software [14]. O termo Engenharia de Software surgiu no final de 1960 motivado pela crise do software [14]. Buscava-se a elaborao de teorias, mtodos e ferramentas
21

relacionadas produo de software, visando obteno de maior qualidade, custo e prazo previsveis para o produto de software gerado [14]. A partir de ento, produzir software passou a ser mais do que programar, mas tambm documentar, produzir modelos, realizar tarefas [14]. O IEEE [54] define Engenharia de Software da seguinte forma [15]: Engenharia de Software: (1) A aplicao de uma abordagem sistemtica, disciplinada, confivel para desenvolvimento, operao e manuteno de software; isto aplicao de engenharia de software. (2) O estudo das abordagens descritas em (1). Segundo Sommerville, o objetivo da Engenharia de software produzir produtos de software [14]. A Engenharia de Software trata de processos, mtodos e ferramentas [40]. Processos estabelecem o que deve ser feito para entrega efetiva de software; mtodos descrevem informaes tcnicas de como deve ser feito para construir software; ferramentas automatizam parcialmente ou completamente os mtodos e processos [40]. Apesar da Engenharia de Software j ter evoludo bastante ao longo dos seus 40 anos de existncia, projetos de software continuam sendo cancelados ou entregues com qualidade baixa, atrasados, acima do custo acordado. O Standish Group [61] realiza pesquisas, chamadas CHAOS [42], a respeito de projetos de software e publica relatrios a respeito. A Tabela 1-1 exibe os resultados dos projetos de software segundo o CHAOS para os anos de 1994, 1996, 1998 e 2000 [20].
Resultados dos projetos Sucesso Falha Finalizado 1994 16% 31% 53% 1996 27% 40% 33% 1998 26% 28% 46% 2000 28% 23% 49%

Tabela 1-1 - Resultados dos projetos de software segundo o CHAOS Report [20] Os resultados dos projetos so classificados em trs tipos [20]: 1. Sucesso: o projeto finalizado dentro do prazo e oramento estabelecido, com todas as caractersticas e funcionalidades originalmente especificadas; 2. Finalizado: O projeto finalizado e operacional, mas estourou o oramento, o prazo e possui menos caractersticas e funcionalidades que as especificadas inicialmente;

22

3. Falha: O projeto cancelado antes de ser finalizado ou nunca implementado. Para a pesquisa do ano 2000, mais de 30.000 projetos foram pesquisados. Os resultados mostram que grande parte dos projetos finalizada com problemas (os projetos classificados como finalizados), outra grande parte considerada como falha. A quantidade de projetos que obtm sucesso vem aumentando ao longo dos anos, mas o percentual ainda considerado baixo. O foco na qualidade suporta a evoluo e aprimoramento da Engenharia de Software. Segundo Pressman [40], o gerenciamento da qualidade total e filosofias similares fomentam uma cultura de melhoria contnua de processos, e esta cultura leva ao desenvolvimento de abordagens mais maduras de engenharia de software. Qualidade um termo amplo, mesmo analisando-o apenas sob o ponto de vista da produo de software. Diferentes estudiosos no assunto definiram qualidade de diferentes formas [11]: W. Edwards Deming define qualidade em termos de preciso do esforo. Neste sentido, a qualidade maior quando planos e especificaes so feitos de acordo com a capacidade da organizao; Para Philip Crosby qualidade est relacionada com a conformidade s especificaes. Um produto de qualidade obtido a partir de especificaes bem escritas que descrevam as necessidades do cliente; Joseph M. Juran define qualidade em termos de adequao ao uso. Um produto deve atender s necessidades dos usurios, mesmo que no atenda s suas especificaes; Tom Peters define qualidade como atingir s expectativas dos clientes. A qualidade do produto medida a partir da conformidade das especificaes s reais necessidades dos clientes. Apesar de ser difcil de definir, os benefcios da qualidade de software so amplamente discutidos na comunidade, dentre eles, importante ressaltar: reduo do nmero de defeitos, confiabilidade, diminuio de re-trabalho, diminuio do ciclo de vida de produo do software, reduo de custos, maior valor agregado, satisfao do cliente, maior motivao da equipe de produo. No intuito de aumentar, medir e garantir a qualidade do software produzido, surgiram alguns modelos de qualidade de software. Dentre os modelos de qualidade

23

propostos, os mais comentados atualmente so as normas da srie ISO 9000 [5], a futura norma ISO/IEC 15504 (SPICE Software Process Improvement and Capability dEtermination) [45], Capability Maturity Model for Software (CMM-SW) [30] e, recentemente, o Capability Maturity Model Integrated (CMM-I) [47]. Metodologias e processos descrevem como deve ser realizado os requisitos dos modelos de qualidade. Um processo de desenvolvimento de software possui os seguintes papis [12]: Guiar as atividades da equipe; Especificar quais e quando artefatos devem ser desenvolvidos; Dirigir as atividades individuais dos desenvolvedores e da equipe como um todo; Oferecer critrios para monitorar e medir as atividades e produtos do projeto. Dentre as metodologias de desenvolvimento de software mais conhecidas atualmente est o RUP Rational Unified Process [35], desenvolvido pela Rational Software [59].

1.1.1 Metodologias geis

Recentemente a comunidade de software vem se deparando com um grupo de novas metodologias de desenvolvimento de software, classificadas como Metodologias geis. Em fevereiro de 2001 um grupo de dezessete pessoas se reuniu no estado de Utah, Estados Unidos, e assinou o Manifesto para o Desenvolvimento gil de Software. Deste grupo de pessoas faziam parte representantes de metodologias como Extreme Programming (XP) [25] e Crystal [48] e simpatizantes da necessidade de uma alternativa aos processos tradicionais de desenvolvimento de software dirigidos documentao [19]. Este grupo se intitulou Aliana gil de Desenvolvimento [44]. Os envolvidos com este movimento, alegam que as regras e procedimentos criados em torno da Engenharia de Software tornaram a produo muito complexa e dispendiosa e que a comunidade perdeu o controle sobre os vrios documentos e modelos tidos como necessrios em qualquer desenvolvimento [53]. O Manifesto para o Desenvolvimento gil de Software definiu os seguintes valores para o desenvolvimento de software [19]: 1. Indivduos e iteraes sobre processos e ferramentas. 2. Software funcionando sobre documentao compreensiva.
24

3. Colaborao do cliente sobre negociao de contrato. 4. Resposta mudana sobre seguir um plano. Estes valores devem ser compreendidos da seguinte forma: a parte em negrito das sentenas refletem o corao das metodologias geis, o que realmente valioso nestas metodologias. A parte em itlico da sentena no possui status de no importante, mas de menos importante que a parte da esquerda, ou de menor prioridade [19]. O primeiro valor sugere que processos e ferramentas so importantes, mas que iteraes e o talento das pessoas so muito mais. A Aliana gil alega que as metodologias, em geral, do mais nfase ao processo usado do que s pessoas que realizaro o trabalho. Da mesma forma, apesar de documentao apoiar o desenvolvimento de software, o foco do projeto deve estar no produto final: o software apto a ser executado, conforme sugere o segundo valor. O terceiro valor expressa que apesar de um contrato ser importante para estabelecer limites e responsabilidades de um projeto de software, uma equipe s pode entender e entregar o que o cliente deseja atravs de colaborao do cliente. Alm disto, segundo o quarto valor, um plano importante para um projeto, mas aceitar as mudanas ao que nele est contido de forma normal gil ainda mais importante. [19]. Alm dos valores, o Manifesto para o Desenvolvimento gil de Software tambm relaciona os princpios que a Aliana gil espera de um processo de desenvolvimento de software. Dentre eles, importante ressaltar [28]: Satisfazer o cliente atravs de entrega contnua e rpida de software de valor; Mudanas em requisitos devem ser bem vindas, mesmo que em momentos tardios do desenvolvimento; Cliente e desenvolvedores devem trabalhar juntos, diariamente no projeto; Deve-se utilizar a comunicao face-a-face como o mtodo mais eficiente e efetivo de fluxo de informaes; Deve-se utilizar como medida principal de progresso do projeto o software funcionando; Deve-se assumir simplicidade para todos os aspectos do projeto.

25

Dentre as metodologias geis mais comentadas atualmente esto [27]: Extreme Programming (XP), Adaptive Software Development (ASD), Crystal, Dynamic Systems Development Method (DSDM), Feature Driven Development (FDD) e Scrum, sendo XP a mais conhecida e utilizada.

1.1.2 O Problema
Os objetivos das metodologias geis so, indiscutivelmente, de interesse de todos os que trabalham com a produo de software: todos querem desenvolver de forma mais rpida, barata, com menos burocracia, exatamente o que o cliente deseja, com qualidade. No entanto, surgem algumas crticas relacionadas garantia da qualidade do produto final. Um dos valores da Aliana gil Indivduos e iteraes ao invs de processos e ferramentas [19]. E se os indivduos no forem bons tecnicamente? E se os indivduos sarem do projeto durante o seu andamento? Ainda assim possvel produzir software de qualidade? Alm disto, os relatos de sucesso publicados se devem ao emprego sistemtico destas metodologias ou a esforos dos indivduos envolvidos ou situao favorvel de desenvolvimento? Nawrocki et al, relatam [21] um experimento realizado em uma universidade em que uma equipe produziu software segundo a abordagem do CMM nvel 2 e outra segundo XP. Como concluso, relata sobre o uso de XP: Provou ser no trivial para equipes formadas com pessoas novas, onde os membros so inexperientes e no se conhecem muito bem. Alm disto, conclui que A comparao entre os processos mostrou que a abordagem CMM menos suscetvel a falhas, pois coloca a responsabilidade sobre o processo da organizao, enquanto o processo XP coloca a responsabilidade sobre o envolvimento e experincia dos membros da equipe. Algumas questes emergem ao tentar relacionar modelos de qualidade de software e metodologias geis de desenvolvimento de software: 1. possvel conviver em uma mesma organizao com os formalismos requeridos por estes modelos de qualidade e o no formalismo pregado pelas metodologias geis? 2. Os dois mundos, o mundo dos modelos de qualidade e o mundo das metodologias geis, podem coexistir em um mesmo ambiente? 3. possvel obter os benefcios propostos pelos modelos de qualidade e pelas metodologias geis?
26

4. Empresas que buscam ou que so certificadas e/ou avaliadas segundo modelos de qualidade existentes, como ISO e CMM, podem optar pelo uso de uma metodologia gil de forma que no comprometa a avaliao e/ou certificao alcanada? Um artigo publicado por Mark Paulk, um dos elaboradores do modelo CMM, inicia uma discusso visando responder algumas das perguntas citadas [31]. Este artigo relaciona a metodologia gil mais difundida atualmente, XP e o modelo para melhoria de processos CMM, analisando como XP se comporta em relao ao modelo Paulk relata que XP um processo documentado e disciplinado e que atende a vrios processos definidos pelo modelo CMM. Como concluso, Paulk ressalta que: XP foca no trabalho tcnico e o CMM nas questes de gerenciamento; XP no aborda questes relacionadas institucionalizao das prticas em uma organizao, o que considerado crucial para o CMM; XP aborda at um determinado limite questes de gerenciamento e acompanhamento de projetos. Apesar de relacionar algumas diferenas entre XP e CMM, Paulk sugere que ambos podem conviver em um mesmo ambiente: XP possui boas prticas de engenharia que podem funcionar bem com o CMM e outros mtodos altamente estruturados. A chave considerar, cuidadosamente, as prticas de XP e implement-las no ambiente correto. Alm disto: As prticas de XP podem ser compatveis com as prticas do CMM (metas ou reas-chave de processo), mesmo que elas no contemplem completamente o modelo. A anlise de Paulk foi feita sobre as KPAs e metas do CMM, componentes de mais alto nvel do modelo. Uma avaliao para determinar o nvel de maturidade de uma organizao realizada tendo como base, componentes mais detalhados: as prticas e subprticas prescritas no modelo. O Captulo 3 detalhar um dos mtodos para determinao de nvel de maturidade. Apesar da concluso favorvel de Paulk a respeito do uso da metodologia gil XP, o mesmo nem sempre acontece com anlises dos envolvidos com metodologias geis sobre modelos de qualidade, em especial, sobre o CMM. Segundo Jim Higsmith, os nveis do CMM no so baseados em resultados, mas na implementao de um conjunto de prticas. A premissa bsica bons processos levam a bons resultados questionvel e leva a muita introspeco sobre processos e
27

pouco foco nos resultados [19]. Alm disto, ...minha reao que muito das atividades do CMM simplesmente no adicionam valor ao cliente [19]. Bob Charette, criador da metodologia gil Lean Development (LD) e chairman do comit do IEEE para o Padro IEEE para Processos de Ciclo de Vida de Software Gerenciamento de Riscos considera que LD nunca se adequar ao CMM e tambm que algumas pessoas no SEI esto preocupadas que as abordagens geis tornem o CMM largamente irrelevante [19]. Em [39], Ron Jeffries et al, considera o CMM da seguinte forma: sim, o CMM pode ser, est sendo, e ser mal utilizado.

1.2 Objetivos do Trabalho

Este trabalho tem como objetivo responder atravs de um estudo aprofundado e de resultados obtidos em um estudo de caso s quatro perguntas da Seo 1.1.2 em relao ao modelo de qualidade CMM nvel 2, e a metodologia gil XP. Desta forma: possvel conviver em uma mesma organizao com os formalismos requeridos pelo CMM nvel 2 e o no formalismo pregado por XP? Empresas que buscam ou que so consideradas CMM nvel 2, podem optar pelo uso de XP de forma que no comprometa a avaliao e/ou certificao alcanada? Primeiramente ser realizado um diagnstico de satisfao do CMM nvel 2 por XP (referenciado de Diagnstico XP-CMM2 neste trabalho). Como j citado anteriormente, a anlise realizada por Paulk e publicada no artigo Extreme Programming from a CMM Perspective [31] foi feita sobre as metas das KPAs do modelo. O diagnstico proposto ir realizar esta anlise sobre as prticas e subprticas do modelo, conforme o mtodo de avaliao Software Capability Evaluation (SCE), utilizado para atribuir nvel de maturidade s organizaes, detalhado no Captulo 3. Este diagnstico ir relacionar as prticas do CMM nvel 2 atendidas e no atendidas por XP. A pesquisa considera que se todas as prticas do CMM nvel 2 forem atendidas por XP, ento os formalismos requeridos pelo CMM e no requeridos por XP so completamente compatveis. Os dois mundos, o mundo do CMM nvel 2 e o mundo XP, podem coexistir em um mesmo ambiente?

28

Da mesma forma, se todas as prticas do CMM nvel 2 forem atendidas por XP, ento XP e CMM nvel 2 podem funcionar ao mesmo tempo em uma mesma organizao. Caso o diagnstico indique que algumas prticas do CMM nvel 2 no so atendidas por XP, o trabalho indicar as alteraes necessrias a XP de forma que seu uso no comprometa o nvel 2 de maturidade de uma organizao. Estas indicaes correspondem ao Guia XP-CMM2, um guia de uso de XP em uma organizao nvel 2. possvel obter os benefcios propostos pelo CMM nvel 2 e por XP? Para avaliar os benefcios da adoo das duas abordagens XP e CMM um estudo de caso ser realizado. Este estudo de caso dever implantar o Guia XP-CMM2. A Figura 1-1 ilustra a metodologia deste trabalho. Inicialmente elaborado um diagnstico de conformidade de XP ao nvel 2 do CMM. Este diagnstico utilizado como base para elaborao de um guia, que dever propor solues para as no conformidades identificadas. Este guia, quando aplicado a XP possibilita que uma organizao nvel 2 do CMM utilize XP e obtenha os benefcios de ambas as abordagens.

Figura 1-1 - Metodologia Aplicada para Desenvolvimento deste Trabalho

1.3 Estrutura da Dissertao

Este trabalho organizado da seguinte forma:
29

O Captulo 2 descreve XP em detalhes; O Captulo 3 detalha o modelo CMM: sua estrutura, requisitos, implantao e como as avaliaes para aferir nvel de maturidade s organizaes so realizadas;

O Captulo 4 realiza um diagnstico detalhado sobre a satisfao do CMM nvel 2 pela metodologia XP;

O Captulo 5 prope uma soluo de uso de XP em uma organizao CMM nvel 2. Para cada item no atendido por XP no diagnstico, proposta uma alterao metodologia;

O Captulo 6 apresenta um estudo de caso da soluo proposta no Captulo 5. Um projeto real utilizou a proposta e os resultados so apresentados;

O Captulo 7 apresenta a concluso final deste trabalho.

30

2 Extreme Programming

Este captulo aborda a metodologia gil Extreme Programming. O captulo est organizado como descrito abaixo: Seo 2.1 Introduo: descreve o que XP e restries para us-la; Seo 2.2 A Estrutura de XP: descreve a estrutura de XP em termos de valores, princpios e prticas; Seo 2.3 Um Projeto XP: descreve como funciona um projeto XP atravs da aplicao das prticas, valores e princpios; Seo 2.4 Crticas a Extreme Programming: relata algumas crticas a XP; Seo 2.5 Resumo: apresenta um breve resumo do Captulo.

2.1 Introduo
Extreme Programming considerada uma metodologia leve de desenvolvimento de software [25]. Beck e Fowler [24] classificam XP como um sistema de prticas que a comunidade de desenvolvedores de software vem evoluindo para resolver os problemas de entregar software de qualidade rapidamente, e ento alcanar as necessidades de negcio que sempre mudam . XP surgiu a partir de idias de Kent Beck e Ward Cunningham. A primeira vez que ela foi utilizada foi em um projeto piloto em maro de 1996, do qual o prprio Beck fazia parte. Em 2000, Beck publicou o primeiro livro sobre XP, o Exteme Programming Explained: Embrace Change [25]. O Extreme do nome da metodologia se deve ao fato de ela empregar ao extremo boas prticas da engenharia de software [25]. Como exemplo, importante ressaltar: Para implementar a boa prtica da reviso de cdigo, XP define que todo o cdigo desenvolvido por pares de programadores trabalhando juntos em uma mesma mquina;
31

Para implementar a boa prtica de testes, XP define que todos os testes so automatizados e executados vrias vezes ao dia;

Para implementar a boa prtica de envolvimento do cliente, o cliente dever estar no local de desenvolvimento, fazendo parte da equipe de um projeto XP. XP no se aplica a todos os tipos de projetos, indica-se que seja utilizado em

equipes de tamanho pequeno a mdio, com no mnimo duas pessoas e no mximo dez [25]. No entanto, algumas pessoas defendem o uso de Extreme Programming em grandes projetos desde que eles sejam divididos em subprojetos independentes. Segundo Beck e Fowler, XP enderea projetos longos quebrando-os em uma seqncia de mini projetos auto contidos, com durao de uma a trs semanas [24]. Outras restries ao uso da metodologia so [25]: Cultura da documentao ambientes em que a cultura, o gerente ou o cliente exigem especificaes detalhadas e documentadas antes do incio do desenvolvimento; Cultura de horas de trabalho para comprovar comprometimento XP considera que duas semanas consecutivas de trabalho alm das horas planejadas no deve ser visto como comprometimento, mas como problemas no projeto; Dificuldade para mudanas se o software no pode ser mantido o mais simples possvel e mudanas no podem ser realizadas freqentemente (porque poder impactar vrias outras aplicaes, por exemplo). Isto geraria a perda de flexibilidade, to importante para um projeto XP; Ambiente onde necessrio muito tempo para obteno de feedback tecnologias que requerem bastante tempo para realizar a integrao do software, por exemplo, ir ocasionar na demora para realizao de testes e obteno de feedback pela equipe; Ambiente em que no possvel realizar testes automticos a falta de testes sendo executados vrias vezes ao dia dificulta a evoluo do projeto de software e diminui a confiana da equipe no cdigo produzido; Ambiente no propcio a um projeto XP pares de programadores devem trabalhar em conjunto em uma mesma mquina, a comunicao deve ser facilitada.

32

A metodologia Extreme Programming de domnio pblico, o que facilita bastante a sua disseminao. Livros ([25], [39]), web sites ([53], [62]) e vrios artigos ([4]) podem ser utilizados como fonte para entender e implantar XP.

2.2 A Estrutura de XP
Extreme Programming definida atravs de valores, princpios e prticas [24], [25]. Os valores descrevem os objetivos de longo prazo de quem aplica XP e definem critrios para se obter sucesso. Os quatro valores de XP so [25]: 1. Comunicao Parte do insucesso de alguns projetos de software atribudo falta de comunicao. Por isto, a metodologia emprega algumas prticas que foram uma maior comunicao por parte da equipe, como programao em pares, por exemplo; 2. Simplicidade Um dos lemas de XP fazer o mais simples possvel que possa funcionar, ou the simplest thing that could possibly work como conhecido entre os praticantes da metodologia. Para isto, deve-se desenvolver pensando apenas no presente. Um exemplo que futuras funcionalidades a serem implementadas no devem ser utilizadas para determinar a arquitetura do software; 3. Feedback Assim como o valor comunicao, XP estabelece vrias prticas para que o feedback seja alto e ocorra o mais cedo possvel. A equipe do projeto deve ter feedback a todo instante do cliente, do andamento do projeto, da qualidade do software. Feedback do cdigo obtido atravs de testes unitrios e automticos, que rodam todo o tempo. O feedback do cliente estimulado atravs de releases curtos e entrega contnua de software de valor. O andamento do projeto reportado a todos atravs de reunies dirias e mtricas simples, coletadas e reportadas freqentemente; 4. Coragem Coragem uma virtude que os praticantes da metodologia devem ter. XP prega que pode acontecer e a probabilidade no baixa momentos em que um programador dever jogar fora todo o cdigo trabalhado durante alguns dias porque o resultado final no foi o esperado. Outra situao naturalmente aceita deparar-se com diferentes possibilidades de implementao e ento implementar um pouco de cada para ento escolher uma

33

dentre elas e passar a desenvolver a soluo. Para estas situaes preciso coragem, segundo Kent Beck, em [25]. Para sustentar os valores e torn-los mais concretos, a metodologia define princpios que devem ser seguidos por todos os praticantes da metodologia. Eles devem guiar escolhas durante o andamento do projeto. Nestes casos, deve-se optar pela alternativa que mais fielmente atende aos princpios estabelecidos. Abaixo so listados os princpios bsicos definidos por XP [25]: Feedback rpido Alm de se buscar feedback de tudo o que se produz, este feedback deve ser rpido; Assumir simplicidade Os problemas devem ser tratados da forma mais simples possvel. No se deve buscar resolver um problema pensando no futuro ou na possibilidade de reuso. XP prega que o tempo ganho pensando desta forma, compensa o retrabalho que poder surgir no futuro por no ter pensado em reuso inicialmente; Mudana incremental Mudanas devem ser feitas pouco a pouco. Desta forma, mudanas no projeto do software ou no planejamento do projeto devem ser feitas de forma incremental e contnua; Aceitar mudana Mudanas devero ser sempre bem vindas, em qualquer momento do projeto; Trabalho de qualidade Deve-se sempre buscar produzir um trabalho de qualidade, de outra forma a equipe perder a motivao necessria ao projeto. Outros princpios, considerados menos crticos, tambm so definidos por Extreme Programming [25]: Ensinar aprendendo XP objetiva ensinar estratgias para que os praticantes da metodologia aprendam as prprias medidas do que projetar, de o quanto testar, de como fazer refactoring1; Investimento inicial pequeno Um projeto deve iniciar com poucos recursos e no decorrer, com o sucesso do projeto e feedback do cliente, ir aumentando estes recursos. bastante citada durante a descrio da metodologia que um projeto
1

Refactoring a prtica de alterao do cdigo sem alterar sua funcionalidade, com o objetivo

de melhor-lo 34

pode ser cancelado ou ter o escopo diminudo, por exemplo. Nestes casos, mais simples encerrar um projeto ou alter-lo se a sua estrutura e investimentos ainda so pequenos; Jogar para vencer A equipe deve ter o esprito de vencer, ou seja, de obter sucesso ao final do projeto; Experimentos concretos Decises abstratas devem ser testadas em forma de experimentos. Um exemplo de como isto deve acontecer em um projeto aps uma etapa de projeto de software, buscar implementar experimentalmente o modelo definido; Comunicao aberta e honesta Problemas como atrasos, m qualidade do cdigo produzido ou insegurana dos indivduos, por exemplo, devem ser tratados abertamente pelo grupo do projeto; Trabalhar a favor do instinto das pessoas e no contra Trabalhar com o instinto das pessoas, visto que estes so baseados em seus interesses de curto prazo, como vontade de vencer, aprender e interagir com outras pessoas; Aceitar responsabilidades Responsabilidade deve ser aceita e no imposta. Assim, as pessoas realizam as atividades que mais gostam, as que acreditam poder realizar, tornando-se mais comprometidas com o projeto; Adaptao ao local XP deve ser adaptada ao ambiente de trabalho em que ser empregada, de acordo com a cultura e condies existentes; Viajar leve O desenvolvimento deve gerar poucos e valiosos artefatos. A equipe estar a todo o tempo se adaptando s mudanas necessrias, como mudanas no escopo, nos requisitos, no projeto do software, a uma nova tecnologia e tantas outras. Por isto, deve estar leve de artefatos, documentaes e especificaes. De outra forma, seria requerido um esforo muito grande para manter as atualizaes necessrias. O que h de valioso para o cliente e, conseqentemente, para o projeto o cdigo e os testes. Outros documentos devem ser agregados se realmente forem importante ao projeto; Medidas honestas As mtricas a serem utilizadas devem ser o mais honestas possvel e refletir as necessidades do projeto.

35

Extreme Programming define quatro atividades bsicas de desenvolvimento de software, depois define as prticas para estruturar estas atividades de forma que as mesmas sigam os princpios, que sustentam os valores da metodologia. As atividades bsicas de XP so: codificar, testar, escutar (o cliente e a equipe) e projetar. Abaixo so listadas as prticas definidas pela metodologia. O jogo do planejamento Deve ser elaborado de forma fcil, rpida e simples o plano para o prximo release, que consiste basicamente em determinar o escopo baseado nas prioridades do negcio, nas possibilidades e estimativas tcnicas; Releases pequenos Os releases devem ocorrer em um espao pequeno de tempo e devem conter sempre software de valor; Metforas Guiam o desenvolvimento do projeto atravs de uma estria que explique como o sistema funciona. Segundo Jeffries metfora uma integridade conceitual baseada em uma simples metfora que todos entendam, que explique a essncia de como o programa funciona [39]; Projeto de software simples O sistema deve ser projetado da forma mais simples que possa solucionar o problema; Teste H dois estgios de testes definidos: testes unitrios e testes de aceitao. Ambos devem ser automatizados. Os testes unitrios so feitos pelo programador durante o desenvolvimento. Os testes de aceitao so especificados pelo cliente e dita o que deve funcionar para que o software seja aceito; Refactoring Reestruturao de parte do cdigo, sem alterar o seu comportamento, visando simplific-lo, torn-lo mais fcil de entender, remover duplicaes; Programao em pares Todo o cdigo produzido em pares de programadores trabalhando em uma mesma mquina; Propriedade coletiva Todos os integrantes da equipe so donos e responsveis pelo cdigo produzido. Desta forma, todos podem alterar qualquer parte do cdigo, a qualquer momento;

36

Integrao contnua O cdigo integrado, o build do software gerado e os testes so executados vrias vezes ao dia, sempre que uma tarefa completada;

40 horas semanais Os membros da equipe no devem trabalhar mais do que 40 horas semanais;

Cliente no local O cliente integrante da equipe e dever estar presente no local do desenvolvimento junto com todos os outros integrantes. Desta forma, ele estar sempre disponvel para esclarecer dvidas, escrever e priorizar estrias, especificar testes;

Padro de codificao O cdigo utilizado como fonte de informao para comunicao e discusso entre os membros da equipe. Assim, ele deve estar bem escrito e estruturado, o que requer a conformidade a um padro de codificao estabelecido para todo o projeto.

2.3 Um Projeto XP
Esta seo ir abordar como um projeto XP funciona: como e de que forma as prticas e valores definidos pela metodologia so empregados no dia-a-dia de um projeto. Inicialmente, definido o escopo do projeto. Depois disto h atividades para planejar o prximo release e a prxima iterao. A equipe parte, ento, para a produo do software estabelecido para a iterao corrente. Antes de detalhar o funcionamento destas atividades, so listados os papis e responsabilidades definidos por XP para o projeto.

2.3.1 Papis
XP relaciona papis, com responsabilidades explcitas, a serem desempenhados em um projeto. Os mais importantes so [25]: Programador Segundo Beck o corao de XP. Responsvel por projetar o software, codificar, implementar testes, estimar as suas tarefas; Cliente Representante do cliente, responsvel por estabelecer prioridades e escopo, escrever estrias, escrever os testes funcionais. Deve estar disponvel no local do desenvolvimento para esclarecimentos de dvidas dos programadores;

37

Testador O testador responsvel por apoiar o cliente a escolher e escrever os testes funcionais, alm de assegurar a execuo e reportagem dos problemas identificados nos testes funcionais;

Acompanhador (tracker) Segundo Beck a conscincia da equipe. Responsvel por reportar as mtricas do projeto promovendo visibilidade sobre a acuidade das estimativas e progresso do projeto;

Tcnico (coach) Este papel assimila grande parte das responsabilidades de um gerente de projeto de software. responsvel por identificar problemas e resolv-los para que a equipe possa trabalhar da melhor forma. No requer conhecimento tcnico profundo.

2.3.2 Planejamento
Definio de viabilidade e escopo O primeiro passo de um projeto XP determinar se o mesmo vivel e, neste caso, fechar o seu escopo. Neste momento, o pessoal tcnico ainda no foi alocado ao projeto, o trabalho de responsabilidade do gerente do projeto (o coach). [24]. Um plano inicial, chamado Big Plan elaborado para determinar a viabilidade do projeto. Para isto, o gerente do projeto, em conjunto com o cliente, dever identificar macro funcionalidades do projeto e estim-las em termos de poucos meses. Poucas horas ou um dia necessrio para elaborar este plano que ir guiar o planejamento detalhado do projeto [24]. Planejando o release XP contra a definio inicial de um plano detalhado, para todo o projeto. Como entende que vrios fatores mudam durante o andamento do projeto, ento, deve-se planejar para um perodo curto de tempo, e este planejamento deve ser alterado sempre que se mostrar inadequado. Desta forma, o planejamento deve ser feito apenas para o prximo release. Planejamento para todo o projeto pode ser feito desde que no inclua muitos detalhes e que todos tenham em mente que poder ser bastante alterado [25]. Durante o planejamento do prximo release, se aplica a prtica O jogo do planejamento. O planejamento ocorre em reunies onde os participantes so o cliente para responder por questes do negcio e os desenvolvedores para responder pelas questes tcnicas.

38

O cliente leva para a reunio os requisitos do sistema, que XP chama de estrias, escritos em cartes de papis, pois permitem facilidade de manipulao e armazenamento. Estes cartes, chamados de Story Cards pela metodologia, descreverem os requisitos de forma sucinta em poucas sentenas. Os desenvolvedores devem ento estimar a complexidade de cada estria. Para isto, durante a reunio, as estrias so apresentadas pelos clientes; os desenvolvedores fazem perguntas para melhor entend-las. Os desenvolvedores acordam uma complexidade de desenvolvimento para cada estria. Esta complexidade est relacionada ao esforo para implementar cada estria. O projeto dever definir em que unidade realizar a estimativa das estrias: pode ser atravs de pontos de complexidade ou atravs de Ideal Weeks (bastante utilizado pela comunidade XP) quantidade de semanas para implementar uma estria, considerando uma semana ideal de trabalho [24], [39]. Para estas estimativas, alguns conselhos so dados [39]: Estimar em grupos no adequado que destas reunies participem apenas um representante do desenvolvimento. As estimativas so mais prximas da realidade se feitas em grupo; Spike Solution quando no se tem idia da complexidade de uma estria, deve-se realizar alguns experimentos atravs de implementao para s ento realizar a estimativa; Estimar baseado em estrias j implementadas utilizar o conhecimento passado para realizar as estimativas; Estimar inicialmente as estrias mais simples deve-se dar pontos s estrias mais simples e estimar as outras atravs de comparao (se uma estria considerada duas vezes mais complexa que uma simples, ento deve possuir o dobro de pontos da mais simples). Depois de estimada a complexidade de cada estria, ento o cliente define o que dever ser implementado para o prximo release, ou seja, o escopo do prximo release. Este escopo baseado na velocidade da equipe, ou seja, na quantidade de pontos que a equipe consegue implementar em um intervalo de tempo. Esta velocidade determinada pela quantidade de pontos que a equipe conseguiu implementar no passado. Se no h dados para determinar esta velocidade, ento um nmero inicial deve ser considerado.

39

Assim, se a equipe possui uma velocidade de x pontos por release, ento o cliente selecionar estrias, de forma que a soma de pontos de complexidade delas seja menor ou igual a x. O planejamento do release estruturado para que cada grupo de interessados interfira apenas sobre o que possui conhecimento. O cliente interfere fortemente sobre os requisitos e suas importncias atravs da escrita das estrias e definio do escopo. Os desenvolvedores interferem sobre as questes tcnicas definindo a complexidade das estrias e quanto possvel produzir em um intervalo de tempo. Utilizando a prtica Releases pequenos, XP sugere como prazo ideal para liberao de releases, dois meses [39]. Neste prazo, deve ser entregue um software de valor, de forma que os usurios possam utiliz-lo diariamente. Mesmo sistemas grandes e complexos, podem ter partes independentes, importantes e de valor a serem entregues em um curto intervalo de tempo. Esta prtica traz uma srie de benefcios ao projeto devido ao feedback do cliente. Em pouco tempo (alguns meses) o cliente j poder utilizar o software o qual est investindo dinheiro e com isto poder informar a equipe de desenvolvimento sobre os aspectos positivos e negativos do software. Esta prtica mostra a importncia do valor Feedback definido pela metodologia. Planejando a iterao Para facilitar o gerenciamento, guiar mais facilmente o projeto e diminuir riscos, o perodo at a data do release dividido em iteraes de poucas semanas no mximo quatro, idealmente duas. Todas as iteraes produzem software de valor. O cliente novamente responsvel por definir as estrias de cada iterao, no entanto aspectos tcnicos podem ser considerados para priorizar a implementao das estrias que mais afetam a arquitetura do software. A seleo das estrias para uma iterao possui a mesma lgica da seleo para o release: o cliente dever selecionar estrias onde a soma dos pontos de complexidade menor ou igual velocidade da iterao. Para planejar uma iterao, deve ser realizada uma reunio onde o cliente comparece com as estrias. O cliente novamente apresenta as estrias e para cada uma delas os desenvolvedores listam, em conjunto, as tarefas que devem ser realizadas para implement-las. As tarefas so as atividades de desenvolvimento propriamente ditas e so definidas em detalhes suficientes para prover o conhecimento necessrio a sua implementao.

40

Os desenvolvedores, ento, escolhem as tarefas que querem realizar e as estimam em termos de dias ou perfect days dias ideais de programao. Assim, Extreme Programming permite que o responsvel por realizar uma tarefa seja responsvel tambm por estimar o tempo necessrio para cumpr-la. Isto gera um maior comprometimento por parte dos desenvolvedores no cumprimento dos prazos. Outro resultado importante desta prtica a motivao obtida pela equipe aps os prprios desenvolvedores escolherem o que desejam implementar. A forma como os releases e as iteraes so planejados colocam em prtica outro valor: a Comunicao. Os requisitos (as estrias) no so descritos em muitos detalhes e nem formal ou estruturadamente, so descritos pelo prprio cliente, em cartes de papel, em algumas sentenas ( possvel fazer referncia a uma especificao em uma estria, se necessrio), o suficiente para dar uma idia do que se deseja obter do sistema. No momento de implementar as estrias, os programadores estaro comunicando-se entre si e com o cliente, que dever estar disponvel a todo o momento no local do desenvolvimento, conforme a prtica Cliente no local.

2.3.3 Desenvolvimento
Aps o planejamento do release e da iterao, a equipe passa a implementar as estrias selecionadas para a iterao corrente. neste momento que a maioria das prticas definidas por XP utilizada. Algumas vezes, quando as pessoas ainda esto muito confusas sobre o que implementar, aconselha-se uma sesso rpida de design [39]. Nesta sesso, alguns integrantes da equipe se renem para acordar sobre um modelo de projeto. Devem ser sesses curtas, de dez a trinta minutos. O uso de CRC Cards [8] ou diagramas UML [29] sugerido como facilitador para a reunio. Se realizadas, estas sesses de design devem ser guiadas pela prtica Projeto de software simples, ou seja, deve-se projetar visando sempre um projeto de software o mais simples que possa resolver o problema atual, sem mtodos, funes ou estruturas que no sero utilizadas no momento. Esta tida como uma das prticas mais difceis de serem utilizadas pela equipe. Isto porque, os programadores, especialmente os mais bem preparados, tendem a escrever pensando em reuso, em cdigo elegante e nas vrias prticas disseminadas pela Engenharia de Software ao longo dos anos. A prtica Metforas auxilia no projeto de software simples. Apesar de no focar em um projeto de software elaborado, Extreme Programming no aprecia cdigo e solues deselegantes. Para evitar isto, insiste na
41

prtica Refactoring. Em vrios momentos do desenvolvimento, a equipe deve analisar o cdigo produzido visando melhor-lo. Neste momento, a equipe altera a estrutura do cdigo, sem alterar a sua funcionalidade para remover duplicidade, melhorar performance, torn-lo mais simples. Esta forma de trabalho pouca nfase na fase de projetar o software e alter-lo sempre que necessrio, baseada em algumas premissas da metodologia. Primeiramente, Extreme Programming parte do princpio que requisitos podem mudar a qualquer momento, seja por melhor entendimento do cliente em relao ao produto a ser construdo, por mudanas inerentes ao negcio do cliente, pelo feedback dos usurios aps uso inicial do sistema. Por isto, no se deve gastar muito tempo projetando um software que pode ser completamente modificado. Deve-se projetar para o que foi estabelecido, para o que o cliente acordou e espera receber em alguns meses. Outra premissa utilizada para sustentar as prticas Projeto de software simples e Refactoring como prticas a serem seguidas durante todo o desenvolvimento do software a de que no to caro realizar mudanas no cdigo como a Engenharia de Software tradicional prega. H muitos anos se tem como consenso na comunidade de software de que quanto mais se demora a alterar uma parte de cdigo, mais cara esta alterao. A Figura 2-1 ilustra o consenso da Engenharia de Software, adotada tambm por Summerville [14].

Figura 2-1 Curva do Custo da Mudana Pressman [40], sugere valores para a realizao da mudana de acordo com a fase de desenvolvimento do software, como mostra a Figura 2-2.

42

Figura 2-2 Custo da Mudana no Tempo de Desenvolvimento Para Extreme Programming [25], a mesma curva se comporta como sugerido pela Figura 2-3.

Figura 2-3 Custo da Mudana Segundo XP Os integrantes devem selecionar um par para trabalhar, pois todo o cdigo produzido deve ser feito por duas pessoas trabalhando em conjunto em uma mesma mquina, desta forma se aplica a prtica Programao em pares [25]. Os pares em XP no so fixos durante todo o projeto, eles devem mudar vrias vezes, mesmo durante um dia de trabalho. Extreme Programming define um pequeno processo para que o trabalho em pares seja efetivo. Nos pares, dever sempre haver um driver que est com o teclado e um partner que acompanha a produo do driver. O partner atua como inspetor analisando o que est sendo produzido em relao ao todo. O driver est mais focado com o que est programando no momento.

43

Algumas dicas podem ser levadas em considerao para se obter melhores resultados da programao em pares: O programador com menos certeza a respeito do que ser produzido dever ser o driver. Isto porque se o mesmo atuasse como partner a participao seria menor; Os pares devem trocar de papis durante o trabalho. Todo o trabalho de codificao dos pares deve ser feito utilizando um padro de codificao estabelecido, conforme a prtica Padro de codificao. A prtica Teste define a realizao dos testes unitrios e de aceitao. Testes unitrios so testes caixa-branca, onde se busca testar o software linha a linha. Os testes unitrios devem ser automticos e desenvolvidos em conjunto com o software. XP fala de testar primeiro, ou seja, implementar os testes antes mesmo de implementar o software. A todo o momento, os testes devem estar funcionando com sucesso em sua totalidade. Esta forma de tratar os testes, motiva e gera mais confiana a respeito do cdigo desenvolvido nos programadores. Os testes de aceitao devem ser especificados pelo cliente, assim ele assume a responsabilidade de afirmar de que forma aceitar o produto que est sendo desenvolvido aceitar se passar pelos testes especificados por ele. Assim como os testes unitrios, os testes de aceitao devem ser automatizados e a equipe responsvel por implement-los. Algumas vezes pode-se usar uma ou mais pessoas para apoiar o cliente na especificao dos testes e implement-los. Estas pessoas assumem o papel de Tester. Assim que um programador finaliza uma tarefa, dever integrar o cdigo produzido ao software j pronto. Desta forma, durante um dia, h vrios builds do software sendo construdo, conforme determina a prtica Integrao contnua. Sempre que um novo build preparado, todos os testes devem ser executados. Se algum teste falhou, ento o responsvel pela integrao (o programador que acabou a tarefa) tambm o responsvel por corrigir o problema, o qual pode estar localizado em um cdigo produzido por ele ou por outro integrante da equipe. Ainda que o problema esteja em uma parte do software no produzida pelo responsvel da integrao, ele ser o responsvel por corrigi-lo, colocando em prtica a Propriedade coletiva. Para apoiar este processo de gerar vrios builds diariamente, rodar os testes, controlar as alteraes para a prtica da Propriedade coletiva, XP sugere fortemente o uso de ferramentas para tornar o uso destas prticas mais consistente e efetivo.
44

Ferramentas podem ser configuradas para gerar builds automticos de tempos em tempos ou a cada novo cdigo em um repositrio, rodar testes e gerar relatrios a respeito dos testes. As prticas utilizadas em conjunto direcionam para um desenvolvimento efetivo de software. As mudanas so mais baratas de implementar porque mais fcil alterar cdigo se este segue um padro de codificao e os testes so automatizados e rodam vrias vezes ao dia a cada novo cdigo produzido, possvel graas integrao contnua. Outro aspecto que deve ser salientado que testes e integrao contnua no dariam muito retorno efetivo se no houvesse a propriedade coletiva, pois se erros fossem sendo descobertos, mas s pudessem ser resolvidos quando o responsvel estivesse disponvel, possivelmente haveria um acmulo de erros, o que poderia gerar, no mnimo, desorganizao ao resto do desenvolvimento.

2.3.4 Acompanhamento
Para acompanhar o progresso da iterao e compar-lo ao planejamento, o Acompanhador (tracker) do projeto deve, algumas vezes por semana, perguntar a cada programador Quantos dias ideais o programador trabalhou na tarefa que est realizando? e Quantos dias ideais o programador considera necessrio para cumprir a tarefa? [24]. Apesar de dias ideais no ter uma relao direta com os dias do calendrio, o Acompanhador dever considerar que algum problema est acontecendo se houver mais dias ideais a ser cumprido que os dias de calendrio para completar a iterao ou se eles diferirem bastante. Se uma destas situaes for detectada, ento o Tcnico (coach) dever ajustar o problema dentro da equipe e, caso no seja possvel, envolver o cliente para inform-lo. Um outro apoio ao acompanhamento da equipe se d atravs das chamadas Stand-up Meetings, ou seja, reunio em p. Nesta reunio, que deve ocorrer diariamente, toda a equipe permanece em p, de forma que contribua para que ela seja curta. Cada pessoa informa rapidamente o que fez no dia anterior e o que tem programado para realizar no dia de hoje. O objetivo desta reunio comunicar os problemas e encaminhar as solues. [24]. XP sugere o uso de grficos visveis para apoiar o acompanhamento do progresso do projeto, das estimativas e de problemas identificados. Os grficos selecionados devem estar vista de todos, preferencialmente colados nas paredes. Apesar de salientar que cada projeto deve medir o que poder auxiliar a resolver problemas, alguns grficos so sugeridos: Testes de aceitao definidos versus
45

executados, Densidade de Bugs, Progresso de estrias, Performance do sistema, entre outros [24].

2.3.5 Consideraes Importantes

Extreme Programming relaciona alguns aspectos que, apesar de no fazer parte diretamente de um ciclo de vida de um projeto XP, so considerados crticos para seu sucesso. Um destes aspectos o ambiente do projeto. Segundo Beck Se voc no tem um lugar para trabalho rezovel, seu projeto no ter sucesso [25]. O ambiente para um projeto XP deve: ser amplo, com pequenos espaos privados e uma rea de programao no centro. As mesas devem promover a programao em pares [25]. As comemoraes planejadas por XP tambm contribuem para o sucesso do projeto. Beck cita em [25] um projeto XP atrai brinquedos e Projetos XP sempre possuem comida em volta. Para Beck dever do Tcnico promover a aquisio de comidas e brinquedos. Em [39], Jeffries sugere comemorar a concluso de tarefas e estrias com toda a equipe, pizza para comemorar o final de uma iterao e champagne para a entrega de um release, pois o trabalho divertido e gostoso quando h um sentimento de realizao, de finalizao. Estes momentos devem ser promovidos.

2.4 Crticas a Extreme Programming

2.4.1 Dificuldade em manuteno
A questo da manuteno de sistemas produzidos a partir de um projeto XP bastante questionada quanto sua eficcia devido falta de documentao pregada pela metodologia. Em [21] relatada a dificuldade de prestar manuteno a um projeto XP. O cdigo fonte e casos de testes no foram considerados suficientes para prestar manuteno. Alm disto, percebeu-se que aps trs meses de trabalho vrios detalhes, especialmente questes associadas aos requisitos do usurio, do projeto foram esquecidos pelos programadores.

2.4.2 Questes associadas efetividade da programao em pares

H vrias questes associadas efetividade da programao em pares: possvel realizar 100% da codificao de um projeto em pares, conforme sugerido por XP?

46

A programao em pares de 100% do cdigo produzido questionada por algumas equipes que adotaram a tcnica. Em [36], Schuh afirma que a programao em pares tomou apenas 30% do tempo de desenvolvimento de um experimento realizado. Qual o custo associado programao em pares? H alguns experimentos relacionados ao custo associado programao em pares, em que diferentes concluses so elaboradas. Em [22] Nosek relata que a programao em pares consumiu 43% a mais do esforo total da programao individual. Nawrocki, em [21], afirma que nos experimentos realizados, a programao em pares exigiu um esforo 50% maior que a programao individual. J Williams relata em [26] que os pares completaram o trabalho de 40% a 50% mais rpidos que se realizado individualmente. Devido a falta de informaes e embasamento cientfico e prtico, muitas vezes, h resistncia da gerncia snior das organizaes em implantar programao em pares nos projetos [16]. O benefcio da programao em pares o mesmo da inspeo? Em [21] Nawrocki relata o uso de inspees em um projeto XP. Esta prtica foi utilizada pela dificuldade em produzir 100% do cdigo atravs da programao em pares e tambm pelos ganhos de uma reunio de inspeo em que os erros encontrados so facilmente focados em relao a como corrig-los, sem que culpas sejam atribudas s pessoas. Como a equipe enfrenta programao em pares? H relatos de restries quanto programao em pares por parte dos programadores. H pessoas que no desejam trabalhar em pares e h pares que no conseguem trabalhar em conjunto, seja por diferenas pessoais ou tcnicas. Estes problemas foram enfrentados pela experincia realizada pela Poznam University of Technology [57], em um projeto XP [21].

2.4.3 Experincia da equipe

XP, assim como as metodologias consideradas geis, segue o princpio relatado pela Aliana gil de Indivduos e iteraes ao invs de processos e ferramentas [28]. Assim, grande parte das responsabilidades e aes colocada para as pessoas dos projetos, ao invs de determinadas pelo processo.
47

Uma das questes que surgem em relao XP se o sucesso completamente dependente da grande competncia das pessoas que formam a equipe do projeto. Em [21] relatado o uso de XP em um projeto de desenvolvimento de software para um mdulo acadmico de dois anos da universidade Poznam University of Technology [57]. A equipe do projeto foi formada por estudantes do curso. O relato ressalta a dificuldade em implementar XP com equipes tecnicamente pouco experientes resultando em problemas relacionados manuteno e comunicao da equipe.

2.4.4 Dificuldade associada ao cliente on site

Uma das prticas de XP Cliente no local, que coloca o cliente como integrante da equipe, presente no local do desenvolvimento durante todo o projeto [25]. O cliente no local um dos pilares de sustentao das prticas de no detalhar requisitos (pois o cliente poder tirar dvidas a qualquer momento) e de no documentar decises (pois o cliente estar tomando decises durante o desenvolvimento do software). A aplicao desta prtica no depende apenas e diretamente da equipe do projeto, preciso que o cliente disponibilize representantes dedicados a trabalhar no projeto, no local do desenvolvimento do mesmo. Alm disto, algumas requisies a estes representantes so feitas, como: deve ser uma pessoa que realmente ir usar o sistema quando o mesmo entrar em produo, que possa estabelecer prioridades para o projeto e tomar decises relacionadas ao escopo [25]. Nem sempre possvel atender a esta prtica, por isto h diversos relatos de uso de XP onde o cliente no participa da equipe do projeto como sugerido [21]. O prprio Beck, relata em [25] um projeto em que ele participou onde, inicialmente, o cliente disponibilizado para o projeto no havia dedicao exclusiva. Somente aps entrega com sucesso de uma parte do software, o cliente disponibilizou trs representantes para atuar no projeto.

2.4.5 Dificuldade para estabelecer contrato de custo e tempo fixo e escopo varivel
Segundo Beck [24], contratos que fixam as variveis escopo, tempo e custo do projeto tendem a ter a qualidade comprometida. Uma abordagem melhor estabelecer um contrato de custo e prazo fixos e escopo varivel [24]. Um contrato como este firma que o projeto ser desenvolvido com x recursos humanos, durante y meses a um preo z. Como exemplo, Beck cita em [25] pelo valor de X, achamos que conseguimos produzir as seguintes estrias em Y meses. A equipe se compromete a trabalhar em
48

alta performance e o cliente tem a possibilidade de mudar a direo do projeto no incio de cada iterao (atravs da adio ou remoo de estrias). Devido aos releases curtos, realizados em poucos meses, o cliente tem a possibilidade de cancelar o contrato se considerar a performance do projeto insuficiente ou se a projeto no fizer mais sentido para o negcio [25] . Apesar das vantagens citadas por XP no estabelecimento de contratos deste tipo, nem sempre isto possvel de ser realizado. Mesmo sendo software uma entidade abstrata, o mercado, na maioria das vezes, define o preo para o produto que ir receber. Por isto, h uma expectativa natural de se tentar definir o escopo do projeto em conjunto com o valor a ser pago por ele. Este tipo de contrato requer uma grande colaborao entre a equipe do projeto e o cliente. Se problemas ocorrerem e no puderem ser resolvidos dentro da equipe, devese recorrer ao cliente para que novo escopo seja definido. Exemplo disto se d quando identificado que no ser possvel implementar todas as estrias da iterao. Neste caso, o cliente chamado para retirar alguma parte de uma estria planejada. O mesmo se d se as estrias planejadas para o release no puderem ser cumpridas. A velocidade assumida pela equipe durante o planejamento do release tambm deve ser revista e repassada ao cliente, caso seja de fato menor.

2.5 Resumo
XP baseada na aplicao de prticas, as quais promovem alguns valores considerados essenciais para um projeto de software. Os principais valores de XP so: comunicao, simplicidade, feedback e coragem. As doze prticas definidas por XP so: O jogo do planejamento, Releases pequenos, Metforas, Projeto de software simples, Teste, Refactoring, Programao em pares, Propriedade coletiva, Integrao Contnua, 40 horas semanais, Cliente no local, Padro de codificao. O planejamento de um projeto XP simples, mas de fundamental importncia para o sucesso do projeto e se d para os releases e iteraes. O desenvolvimento de software feito de forma bastante dinmica favorecendo a comunicao entre a equipe e o feedback contnuo do funcionamento do sistema e da satisfao do cliente. O acompanhamento em um projeto XP realizado em curtos intervalos de tempos: mtricas so constantemente colhidas e tornadas visveis para todos os membros da equipe, reunies curtas ocorrem diariamente, h um responsvel para acompanhar o progresso das atividades de cada programador.
49

Apesar de vrios relatos de sucesso no emprego de XP [4], [16], algumas crticas so relacionadas e ainda no completamente respondidas.

50

179

3 Capability Maturity Model for Software

Este captulo descreve o Capability Maturity Model (CMM), utilizado como um dos fundamentos deste trabalho. O captulo est organizado da seguinte forma: Seo 3.1 Capability Maturity Model for Software: descreve como o CMM est estruturado e os aspectos mais relevantes do modelo; Seo 3.3 Avaliao CMM: descreve como uma avaliao de maturidade com base no CMM realizada; Seo 3.2 CMMI: descreve em linhas gerais a evoluo do modelo CMM, o CMMI; Seo 3.4 Resumo: apresenta algumas consideraes sobre este captulo.

3.1 O Modelo Capability Maturity Model for Software

O Capability Maturity Model for Software (CMM) foi desenvolvido pelo Software Engineering Institute (SEI) [60], criado em 1984 pelo Departamento de Defesa dos Estados Unidos. O CMM considerado um framework para melhoria dos processos de desenvolvimento de software das organizaes [30]. O modelo descrito de forma a relacionar atributos essenciais aos processos das organizaes em determinados nveis de maturidade. Descreve o que esperado, de forma genrica o suficiente para que as organizaes definam o como, por isto diferentes solues podem ser adotadas para atender o modelo [30]. Atualmente O CMM se encontra na verso 1.1 e possvel encontr-lo em livros ou at mesmo gratuitamente a partir da pgina do SEI na Internet [60]. 180

3.1.1 A Estrutura do CMM

O CMM define um caminho a ser seguido para que as empresas saiam de um desenvolvimento de software ad-hoc e evoluam para um desenvolvimento maduro e efetivo. Este caminho engloba cinco nveis de maturidade. A Figura 3-1 ilustra a estrutura do CMM.

Figura 3-1 - Estrutura do CMM

Conforme a Figura 3-1, os nveis de maturidade indicam a capacidade do processo do software. Capacidade do processo defina como sendo os resultados mais provveis de serem obtidos pelos prximos projetos de uma organizao [30]. Assim, quanto maior o nvel de maturidade de uma organizao, mais capaz ela na produo de software. Os nveis de maturidade, exceto o nvel 1, possuem reas-chave de Processo ou Key Process reas (KPAs), que indicam onde uma organizao deve se concentrar para

181

melhorar seu processo de desenvolvimento [30]. Para uma organizao alcanar um nvel de maturidade, ela dever satisfazer todas as KPAs deste nvel e dos nveis abaixo dele. Para satisfazer uma KPA as metas definidas para ela devem ser alcanadas, o que implica que os processos definidos devem estar institucionalizados [30]. A definio destes processos pode variar entre empresas ou mesmo projetos, no entanto, as metas devem ser alcanadas. Cada KPA s ocorre em um nvel, ou seja, no h repetio de rea-chave para nveis diferentes de CMM. A Tabela 3-1 lista as KPAs por nvel de maturidade do CMM.
Nvel de Maturidade 1 KPAs No h reas-chave de processo definidas para o nvel 1. 2 3 4 5 Gerenciamento de requisitos Planejamento de projeto de software Acompanhamento de projeto de software Gerenciamento de subcontrato de software Garantia da qualidade de software Gerenciamento de configurao de software Foco no processo da organizao Definio do processo da organizao Programa de treinamento Gerenciamento de software integrado Engenharia de produto de software Coordenao de intergrupo Revises em pares Gerenciamento de processo quantitativo Gerenciamento da qualidade de software Preveno de defeito Gerenciamento de troca de tecnologia Gerenciamento de troca de processo

182

Tabela 3-1 - KPAs por Nvel de Maturidade O CMM no um modelo exaustivo, ou seja, no trata de todos os processos relacionados ao desenvolvimento de software. Os processos tratados pelo modelo, so os que foram considerados determinantes para a capacidade ou maturidade do desenvolvimento de software [30]. Desta forma, outros fatores que agreguem valor e possam facilitar o desenvolvimento podem ser utilizados pelas organizaes, mas no sero considerados para ditar a sua maturidade. A Figura 3-1 mostra que cada KPA organizada por caractersticas comuns que descrevem como institucionaliz-la ou implement-la. As caractersticas so atributos que indicam quando a implementao ou institucionalizao de uma KPA efetiva, repetvel e duradoura [30]. Estas caractersticas so: Compromisso para Realizar descreve aes que a organizao deve tomar para assegurar que o processo estabelecido e ir durar. Tipicamente envolve definio de polticas, funes e responsabilidades para execut-las; Habilidade para Realizar Pr-condies que devem existir para implementar o processo de forma efetiva. Tipicamente relaciona recursos, treinamentos e infraestrutura; Atividades Realizadas Atividades, papis e procedimentos necessrios para implementar a KPA. Envolve tipicamente o desenvolvimento de planos, procedimentos, realizao de trabalhos, acompanhamento de atividades; Medio e Anlise Medidas para avaliar o status relacionado ao processo. So usadas para controlar e melhorar o processo. Tipicamente inclui exemplos de possveis medidas que podem ser realizadas para a KPA. Verificar Implementao Descreve passos para assegurar que as atividades da KPA esto sendo realizadas conforme definido. Incluem, em geral, revises e auditoria de qualidade. As caractersticas comuns agrupam prticas chave, que descrevem as atividades e infra-estrutura que mais contribuem para a efetiva implementao e institucionalizao da KPA [30]. Estas prticas descrevem o que pode ser feito objetivando a conquista das 183

metas da KPA. As prticas so relacionadas s metas atravs de tabelas na descrio do modelo [30], assim, descrito que prticas devem ser implementadas para conquistar cada meta de cada KPA. possvel no implementar todas as prticas relacionadas pelo modelo ou implementar prticas alternativas. Nestes casos, experincia e julgamento devem ser aplicados para verificar se as prticas alternativas realmente contribuem para o alcance das metas da KPA [30]. As prticas chave possuem, geralmente, subprticas mais detalhadas que podem ser utilizadas como guia na interpretao a implementao adequada. Os componentes do modelo que pontuam a capacidade de uma organizao em produzir software so os nveis de maturidade, as reas-chave de processo e as metas [30]. Isto porque se diz que uma organizao possui um nvel de maturidade se ela satisfaz todas as reas-chave de processo daquele nvel e dos nveis abaixo. A satisfao de uma rea-chave se d se todas as suas metas so satisfeitas. Os outros componentes do CMM, como prticas chave e subprticas, so componentes informativos e tm como objetivo guiar a implementao do modelo [30]. O CMM descrito atravs de 500 pginas, definindo de forma hierrquica seus componentes como exibido na Figura 3-2:
5 Nveis de Maturidade reas18 chave de Processo 52 316 Metas Prticas Chave Subprticas e exemplo

Vrios

Figura 3-2 O CMM em nmeros

184

3.1.2 Os Nveis de Maturidade do CMM

A Figura 3-3 exibe os nveis de maturidade definidos pelo CMM.

Figura 3-3 - Nveis de Maturidade do CMM

A Tabela 3-2 relaciona as principais caractersticas de cada nvel de maturidade [30]:

Nvel de Maturidade Principais Caractersticas

185

Poucos (ou nenhum) processos definidos Processos definidos no so seguidos em momentos de grande presso

1 (Inicial)

Geralmente projetos no cumprem prazo e oramento Equipes desestimuladas Sucesso dos projetos fortemente dependente das pessoas Comumente as pessoas trabalham mais do que a carga horria acordada

H polticas para o desenvolvimento de software definidas e utilizadas por todos os projetos

Processo

disciplinado:

definido,

documentado,

praticado,

treinado e medido Processo pode variar entre projetos, mas obedecem as polticas da organizao 2 (Repetvel) Planejamento e acompanhamento de projetos se d baseado em experincias passadas Cronogramas, custos e riscos so planejados e acompanhados de forma efetiva Os requisitos so gerenciados Os produtos possuem controle de verses Se h subcontrato associado ao projeto, este gerenciado de forma a no comprometer o resultado final Maior probabilidade de repetio de sucesso entre projetos sem dependncia forte das pessoas

186

Processo padro para toda a organizao completamente definido, documentado

O processo padro utilizado por todos os projetos, no entanto adaptaes so realizadas segundo critrios estabelecidos para satisfazer necessidades e restries especficas

3 (Definido)

Um grupo de pessoas possui a responsabilidade de desempenhar as atividades relacionadas criao, manuteno, melhoria e institucionalizao deste processo padro

A organizao possui um programa de treinamento H um entendimento comum por toda a organizao das atividades, papis e responsabilidades definidas no processo padro

A organizao define objetivos quantitativos de qualidade para produto e processo

Projetos cumprem metas para atingir o padro de qualidade definido pela organizao

4 (Gerenciado)

H um banco de dados com informaes extradas de projetos que auxiliam na deteco e preveno de problemas e no apoio a deciso.

Os projetos possuem resultados previsveis Devido s medidas realizadas nos projetos, possvel detectar e agir preventivamente para resolver problemas

5 (Otimizando)

Foco na otimizao de processos Mudanas na tecnologia e processos so realizadas sem comprometer a qualidade do produto final Problemas j resolvidos so disseminados para que no se repita

Tabela 3-2 - Principais caractersticas dos nveis de maturidade O nvel 2 de maturidade ser detalhado no Captulo 4, onde suas metas e prticas sero analisadas.

187

3.2 CMMI
Desde 1991, vrios modelos CMM foram produzidos para reas especficas como engenharia de sistemas, engenharia de software, aquisio de software, desenvolvimento integrado de produto e processo e outros. A melhoria dos processos das organizaes foi afetada negativamente com a adoo de diferentes modelos, pois gera um aumento de complexidade e custos, devido a diferentes abordagens e arquiteturas destes modelos, necessidade de vrios treinamentos, e diferentes avaliaes [6]. Motivado por isto, o Departamento de Defesa dos Estados Unidos patrocinou o projeto de desenvolvimento do Capability Maturity Model Integration (CMMI) Framework, conjunto de modelos, mtodos de avaliao e produtos de apoio, elaborado pelo SEI, representantes da indstria e do governo. O CMMI teve como objetivo combinar os modelos Capability Maturity Model for Software (CMM) v2.0 draft C, Electronic Industries Alliance nterim Standard (EIA/IS) 731 e Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98 em um nico framework a ser utilizado por toda a organizao [6]. O CMMI foi lanado recentemente e dever substituir o CMM dentro de alguns anos [60]. A arquitetura do CMMI parecida com a do CMM, no entanto, existem pequenas mudanas. O CMMI possui duas representaes: contnua e por estgios. A representao por estgios mede a melhoria de processos atravs de nveis de maturidade [60], assim como o CMM. J a representao contnua mede a melhoria atravs de nveis de capacidade aplicadas a reas de processo individuais [60].

3.3 Avaliao CMM

Para que uma organizao seja avaliada a respeito da conformidade ao CMM, o SEI definiu um framework para documentar os requisitos necessrios e caractersticas desejveis a um mtodo de avaliao baseado no CMM, chamado CMM Appraisal Framework (CAF) [34]. O CAF serve como base para comparao dos resultados de diferentes mtodos de avaliao aumentando a consistncia e confiabilidade entre eles [34]. Mtodos de avaliao do modelo CMM so reconhecidos pelo SEI se forem compatveis com o CAF, ou seja, implementarem todos os requisitos determinados por ele. 188

O SEI possui atualmente dois mtodos de avaliao compatveis com o CAF [34]: 1. Software Capability Evaluation (SCE): utilizado para selecionar fornecedores, monitorar contratos e para avaliar o processo interno da organizao. Encontra-se atualmente na verso 3.0; 2. CMM-Based Appraisal for Internal Process Improvement (CBA IPI): o CBA IPI mais especfico em seus objetivos: utilizado apenas para avaliao do processo interno da organizao. Os resultados de avaliaes utilizando o CBA IPI e o SCE, conduzidas sobre as mesmas reas de processo em uma organizao, devem ser consistentes entre si [34]. Este trabalho ir apresentar o mtodo de avaliao SCE, pois alm de ser equivalente ao CBA IPI, mais genrico. Alguns fundamentos do SCE sero utilizados no Captulo 4 para realizar o Diagnstico de satisfao de XP ao CMM nvel 2.

3.3.1 Software Capability Evaluation (SCE)

Como objetivos, o mtodo SCE deve ser confivel, repetvel, treinvel, consistente e alinhado ao CBA IPI [34]. O SCE foi elaborado para avaliar o processo da organizao visando determinar a sua capacidade. O mtodo SCE composto por trs fases: planejar e preparar a avaliao, conduzir a avaliao e reportar resultados da avaliao, conforme descrito nas prximas subsees. 3.3.1.1 Planejar e preparar a avaliao Inicialmente, os requisitos da avaliao so identificados e a organizao que contratou a avaliao define seus objetivos: selecionar fornecedor, avaliar subcontrato ou avaliar o processo interno. Alm disto, outras decises so tomadas, como: Escopo CMM da avaliao: parte do modelo que ser usado como referncia na avaliao: se a avaliao cobrir apenas alguns processos do CMM (tipo de avaliao que no atribui nvel de maturidade), ou todos os processos de um determinado nvel de maturidade, selecionado para ser avaliado. Escopo organizacional: projetos da organizao que sero avaliados. A partir destas definies, um plano de avaliao elaborado para guiar a sua execuo. Este plano inclui: propsito, escopo, atividades, cronograma, membros da 189

equipe de avaliao, recursos, financiamento, logstica (aspectos como viagens, hospedagens, local da avaliao) e riscos. O plano ento revisado pela alta gerncia da organizao. Para conduzir uma avaliao SCE, uma equipe avaliadora deve ser selecionada, a qual composta, em geral, por cinco ou seis avaliadores, sendo um deles, o lder [34]. Algumas restries so impostas a esta equipe [34]: A equipe deve possuir somados, no mnimo, 25 anos de experincia tcnica e 10 anos de experincia em gerenciamento; Pelo menos duas pessoas da equipe deve ter participado de avaliaes SCE; Nenhum membro deve ter menos de 5 anos de experincia profissional; O lder deve ter participado em no mnimo duas avaliaes SCE; Todos os avaliadores devem ter sido treinados no mtodo SCE. Para que uma organizao receba um laudo do SEI [60] reconhecendo seu nvel de maturidade, a avaliao deve ser conduzida por um avaliador lder credenciado pelo prprio SEI. Atualmente, no Brasil, duas pessoas possuem esta credencial e ambos so consultores da empresa ISD Brasil [55]. Alguns instrumentos podem ser utilizados para se obter informaes prvias a respeito da organizao. Um exemplo destes instrumentos o questionrio de maturidade [9], elaborado pelo SEI. Este questionrio enviado e a organizao a ser avaliada responde-o e o envia para que a equipe avaliadora o utilize como fonte para detalhamento do planejamento da avaliao. Uma outra atividade desta fase a seleo e preparao das localidades, projetos e participantes [34]. preciso selecionar as localidades (unidades) e projetos da organizao, pois dependendo do tamanho da organizao, no possvel avaliar todos os seus projetos e localidades. Esta seleo deve ser feita considerando a representatividade dentro da organizao: se os projetos e/ou localidades selecionados representam bem, por exemplo, o negcio, o tamanho, o faturamento. As pessoas a participarem da avaliao tambm devero ser selecionadas de acordo com o tamanho da organizao, caractersticas das pessoas da organizao e atividades desempenhadas [34].

190

A equipe de avaliao ento conduz uma explanao aos participantes selecionados a respeito da avaliao, visando assegurar que eles saibam o que o processo de avaliao e porque ele ser realizado [34]. Alm disto, se preparam para a coleta de dados realizando os seguintes passos: organizam as entrevistas a serem realizadas, relacionam os documentos a serem revisados, definem papis e responsabilidades da equipe avaliadora (lder, monitor para cada KPA, bibliotecrio, entre outros). 3.3.1.2 Conduzir a avaliao A conduo da avaliao iniciada com uma apresentao da prpria organizao sobre: o que ela faz, sua estrutura organizacional, documentos da organizao (polticas e procedimentos e outros) e como os grupos envolvidos com o desenvolvimento so gerenciados e integrados [34]. A equipe avaliadora deve escutar, questionar e tomar nota de aspectos importantes desta apresentao [34]. Trs atividades so realizadas repetitivamente durante a conduo da avaliao: reviso de documentos, conduo de entrevistas e consolidao dos dados. Elas so realizadas em diferentes sesses, devidamente planejadas e comunicadas aos envolvidos: Atividade reviso de documentos Na reviso de documentos, a equipe avaliadora analisa trs nveis de documentao: documentos no nvel da organizao, nvel do projeto e nvel de implementao em dois tipos de revises: inicial e detalhada. Uma reviso inicial realizada sobre os documentos do nvel da organizao (polticas, processos da organizao) e do projeto (processos especficos dos projetos) visando identificar como eles definem e suportam o processo da organizao e as KPAs que esto sendo investigadas [34]. Uma reviso detalhada realizada sobre os documentos do nvel do projeto e de implementao (registros gerados pelo projeto, como planos, atas de reunies, estimativas) para validar as informaes levantadas nas entrevistas e em outras revises de documentos. O objetivo encontrar evidncias de como os processos so realmente implementados e se esto de acordo com o que foi dito em entrevistas [34].

191

Atividade conduo de entrevistas A equipe de avaliao ir conduzir entrevistas para coletar dados a respeito

do processo definido e seu uso pela organizao [34]. Estas entrevistas podem ser individuais ou em grupo, conduzidas em diferentes sesses, onde: entrevistas com gerentes, em geral, so realizadas individualmente e com praticantes (pessoas que no atuam no nvel gerencial) so realizadas em grupo, sem a presena de gerentes para evitar constrangimentos e cobranas no pertinentes avaliao [34]. O mtodo SCE considera dois tipos de entrevistas: exploratrias e de consolidao. A entrevista exploratria tem como objetivo prover conhecimento sobre como as KPAs esto sendo realmente implementadas pelos projetos. A entrevista de consolidao tem como principal objetivo confirmar ou esclarecer alguma informao ainda no obtida seguramente pela equipe de avaliao. Esta ltima pode ser conduzida por um subconjunto de avaliadores e utiliza perguntas mais especficas para esclarecer as questes pendentes. Durante as entrevistas toda a equipe avaliadora dever anotar todas as informaes obtidas. Estas notas no devem conter julgamento do avaliador, mas informaes obtidas nas entrevistas [34]. Atividade consolidao de dados Os dados coletados devero ser consolidados para gerar observaes formais da equipe de avaliao, que identificam pontos fortes, fracos e oportunidades de melhoria em relao ao CMM [34]. Estes dados so provenientes dos registros feitos pela equipe de avaliao a partir da anlise de instrumentos, apresentaes da organizao, reviso de documentos e entrevistas [34]. As observaes elaboradas so realizadas em relao s prticas chave definidas pelo modelo. Para transformar a anlise de documento e registros de entrevistas em observaes formais sobre a conformidade ao modelo, algumas vezes preciso julgar com base nas informaes coletadas. O mtodo SCE define algumas regras para que este julgamento seja o mais objetivo possvel e para que no dependa de opinies individuais. 192

Primeiramente, todas as observaes devem ser realizadas sobre informaes corroboradas, segundo as seguintes regras [34]: Uma observao deve ser baseada em uma evidncia objetiva na forma de documento, a no ser se define um ponto fraco, onde a falta de documentao considerada evidncia objetiva; Quando a evidncia provm de entrevistas, apresentaes e anlise de documentos esta deve ser observada em duas sesses independentes; As observaes formais devem ser geradas atravs de consenso da equipe avaliadora. Se a equipe no entrar em consenso sobre algum tpico, ento dever relacionar informaes adicionais necessrias para resolver a questo e elaborar um plano para capturar estas informaes adicionais. O mtodo no define regras definitivas a respeito da corroborao e sugere que quanto mais crtica for a observao, maior a necessidade de corroborar as informaes com outras fontes. Segundo o mtodo, se houver qualquer dvida a respeito da observao, ento uma nova coleta de dados dever ser promovida [34]. Alm disto, considera importncias diferentes para diferentes tipos de coleta de dados. Como exemplo, sugere que se h uma observao que pode comprometer uma KPA, vinda de anlise de instrumento, ento a mesma deve ser melhor investigada atravs de outras fontes [34]. Para cada observao gerada, a equipe de avaliao dever julgar se est clara; se baseada em fatos ou fortes inferncias; se foi suficientemente corroborada; se categorizada contra o CMM (se est relacionada a alguma prtica chave); se est classificada como sendo um ponto forte, fraco ou oportunidade de melhoria; se relevante e significativa; se no redundante nem contraditria em relao s outras observaes; se as observaes cobrem tudo o que est sendo pesquisado [34]. Depois que as atividades de reviso de documentos, conduo de entrevistas e consolidao de dados foram realizadas repetidamente conforme planejado, duas outras atividades ainda so realizadas: Apresentar resultados iniciais e realizar julgamento de pontuao. 193

Atividade apresentar resultados iniciais O mtodo SCE busca assegurar que injustias no sejam feitas

organizao que est passando pela avaliao. A atividade de apresentar resultados iniciais comprova esta afirmao. Nesta atividade, a equipe de avaliao apresenta os pontos fracos aos participantes da organizao em diferentes sesses. Nesta apresentao, a organizao tem a oportunidade de refutar o resultado, apresentando informaes e evidncias. A equipe de avaliao anota todas as novas informaes obtidas para validar o que foi apresentado e/ou rever os pontos fracos [34]. Atividade realizar julgamento de pontuao Finalmente, a equipe de avaliao ir pontuar os componentes selecionados durante o planejamento da avaliao [34]. A pontuao feita de baixo para cima, ou seja, os componentes de mais baixo nvel na estrutura do CMM so pontuados primeiro e utilizados na pontuao dos componentes de mais nvel [34]. Desta forma, para que uma organizao seja classificada em um nvel de maturidade, a equipe dever pontuar inicialmente as metas, depois as KPAs e depois o nvel de maturidade. Os valores aplicados na pontuao aos componentes so [34]: Satisfeito: se o componente foi implementado e institucionalizado como requerido pelo modelo ou atravs de uma alternativa que atenda a inteno do componente; No satisfeito: se h pontos fracos significativos associados ao componente comprometendo a sua implementao e/ou institucionalizao; No aplicvel: se o componente no se aplica realizada da organizao. Um exemplo de quando um componente pontuado como no aplicvel a KPA Gerncia de Subcontrato do nvel 2, quando a organizao no subcontrata;

194

 No pontuado: um componente no pontuado se a avaliao no cobriu os requisitos para pontuao ou se no est no escopo da avaliao. Para pontuar as metas a equipe de avaliao ir julgar se a meta foi implementada e institucionalizada pela organizao [34]. Para verificar isto, as observaes registradas e j validadas com a organizao so utilizadas. Se todas as prticas relacionadas a uma meta possuem apenas pontos fortes associados, a meta alcanada. No entanto, possvel que uma meta seja atingida mesmo tendo pontos fracos associados, desde que eles no sejam crticos [34], apesar de o mtodo no determinar objetivamente o que considerado crtico, este julgamento fica a cargo da equipe avaliadora. possvel que metas sejam alcanadas atravs da implementao de prticas alternativas [34], ou seja, prticas implementadas pela organizao, diferentes de prticas chave descritas no CMM. Tambm fica a critrio da equipe avaliar se a prtica alternativa atinge a inteno por trs da prtica chave no implementada, no comprometendo neste caso, a meta relacionada. Assim, a pontuao das metas uma das atividades mais subjetivas do mtodo. A pontuao das KPAs e do nvel mais objetiva e segue o critrio j citado anteriormente: uma KPA satisfeita se todas as suas metas so satisfeitas; um nvel alcanado se todas as KPAs aplicveis do seu nvel e de nveis inferiores so satisfeitas [34]. 3.3.1.3 Reportar resultados da avaliao A avaliao finalizada aps apresentao do resultado final e entrega de relatrios. Primeiramente a equipe apresenta para a organizao os resultados obtidos: pontos fortes, fracos, oportunidades de melhoria, problemas encontrados (mesmo os no relacionados com o modelo de referncia) [34]. O mtodo encoraja a participao de todos os interessados da organizao e no apenas dos que participaram diretamente [34]. Nesta apresentao a equipe de avaliao dever estar preparada para responder a eventuais questionamentos, respeitando os princpios de no atribuio e confidencialidade [34] definidos pelo mtodo, ou seja, os problemas encontrados no podem ser divulgados para a organizao e no so atribudos a pessoas e/ou projetos. 195

A equipe de avaliao ainda responsvel por elaborar e entregar relatrios formais do trabalho realizado. Eles incluem: pontos fracos, pontuao, riscos associados valiao, recomendaes ao uso dos resultados, informaes a respeito da avaliao e outros [34]. Templates para os relatrios so disponibilizados no curso oficial do SCE do SEI [41].

3.4 Resumo
Este captulo apresentou o CMM, sua estrututra, nveis de maturidade, reaschave de processo e caractersticas comuns. Alm disto, abordou os principais aspectos de um dos mtodos de avaliao do CMM elaborado pelo SEI, O SCE. Os fundamentos do SCE foram utilizados como base para elaborao do Diagnstico XP-CMM2, descrito no Captulo 4. O CMM dever ser substitudo no mdio prazo pelo CMMI. A representao por estgios do CMMI promove uma fcil transio do CMM para o CMMI.

196

4 Diagnstico XP-CMM2

Este captulo ir determinar a aderncia de XP ao CMM nvel 2. O objetivo identificar as prticas definidas pelo modelo que so e as que no so satisfeitas por XP. Este captulo est organizado da seguinte forma: Seo 4.1 O Diagnstico: descreve os objetivos, escopo, metodologia e nomenclatura utilizada neste diagnstico; Seo 4.2 Mapeamento de XP no CMM: mapeia termos utilizados em XP no CMM; Seo 4.3 Diagnstico da KPA Gerenciamento de Requisitos: realiza o diagnstico para a KPA Gerenciamento de Requisitos; Seo 4.4 Diagnstico da KPA Planejamento de Projetos de Software: realiza o diagnstico para a KPA Planejamento de Projetos; Seo 4.5 Diagnstico da KPA Acompanhamento de Projetos de Software: realiza o diagnstico para a KPA Planejamento de Projetos; Seo 4.6 Diagnstico da KPA Garantia da Qualidade de Software: realiza o diagnstico para a KPA Planejamento de Projetos; Seo 4.7 Diagnstico da KPA Gerncia de Configurao de Software: realiza o diagnstico para a KPA Planejamento de Projetos; Seo Erro! Fonte de referncia no encontrada. Erro! Fonte de referncia no encontrada.: apresenta uma breve concluso deste captulo.

197

4.1 O Diagnstico
Como j apresentado no Captulo 3, os componentes normativos do CMM so os nveis, KPAs e metas. Estes componentes contribuem na definio da capacidade de uma organizao. Prticas e sub-prticas so componentes informativos que auxiliam no entendimento do CMM. Cada prtica est relacionada a uma ou mais metas, de forma que elas ajudam a alcan-las. Apesar de sua implementao no ser considerada obrigatria para alcance de um nvel, as prticas so, em geral, aplicveis. Avaliaes, como o SCE, fazem observaes relacionadas s prticas e sub-prticas (o Captulo 3 fornece maiores detalhes). Prticas no implementadas, se aplicveis, devem dispor de alternativas de implementao para satisfazer s metas relacionadas. Em avaliaes, tipicamente de 3 a 5 prticas alternativas so utilizadas para atingir a meta [33], ou seja, considerando o maior nmero, apenas 1,59% das 316 prticas do CMM so consideradas alternativas; todas as outras so consideradas aplicveis. Segundo Paulk, Prticas-chave no so requeridas e deve existir implementaes alternativas, mas isto no tira a responsabilidade de realizar julgamentos profissionais sobre cada prtica e meta associada [33]. Devido importncia das prticas para entendimento do CMM e alcance das metas, um diagnstico de satisfao ser realizado contra as prticas do nvel 2, pois se as prticas forem satisfeitas, ento as metas tambm sero.

4.1.1 Escopo do Diagnstico

Este diagnstico ir focar apenas no Nvel 2 do CMM, que inclui as reas-chave de processo: Gerenciamento de Requisitos, Planejamento de Projeto de Software, Acompanhamento de Projeto de Software, Gerenciamento de Subcontrato de Software, Garantia da Qualidade de Software e Gerenciamento da Configurao de Software. Dentre estas KPAs, o objetivo da Gerenciamento de Subcontrato de Software selecionar subcontratados qualificados e gerenci-los de forma eficaz [30]. Esta KPA no ser considerada neste trabalho, pois foge ao escopo de uma metodologia de desenvolvimento de software, que foca no ciclo de desenvolvimento do software. O CMM um modelo para construir capacidade organizacional na produo de software e foca em questes de gerenciamento envolvidas na implementao de

198

processos efetivos e eficientes e na melhoria de processos sistemtica [31]. O CMM diz o que, em termos gerais, deve ser feito. O como fazer de responsabilidade da organizao, que deve definir ou utilizar um processo para isto [31]. Alm de abordar aspectos tcnicos do desenvolvimento de software, o CMM aborda tambm aspectos organizacionais visando institucionalizao [31], como j mencionado no Captulo 3. Metodologias de desenvolvimento de software podero complementar o CMM para estabelecer o como fazer dos aspectos tcnicos relacionados pelo modelo, que ditam o que deve fazer. Os aspectos relacionados institucionalizao ou organizao, muitas vezes fogem ao escopo destas. Um exemplo de aspecto tcnico definido pelo CMM a prtica O plano para o projeto de software documentado, referente rea chave de processo Planejamento de Projeto de Software. Metodologias de desenvolvimento de software, em geral, definem como se d o planejamento e a documentao do mesmo para projetos de software. Desta forma, o processo utilizado ir definir o como fazer o plano do projeto e document-lo, contemplando a prtica citada. Um exemplo de prtica definida pelo CMM relacionada a aspectos de institucionalizao O projeto segue uma poltica organizacional escrita para planejar um projeto de software, tambm referente rea chave de processo Planejamento de Projeto de Software. Esta uma atividade relacionada organizao, no possuindo relao direta com o desenvolvimento de um projeto de software. Em geral, atividades como esta no so mencionadas pelas metodologias de desenvolvimento de software. No CMM, as caractersticas comuns Compromisso para Realizar, Habilidade para Realizar, Medio e Anlise e Verificar Implementao agrupam prticaschave relacionadas institucionalizao. As prticas de implementao, relacionadas caracterstica comum Atividades Realizadas, descrevem o que deve ser feito para estabelecer a capacidade do processo de software adotado [30]. Desta forma, este diagnstico ir considerar apenas as prticas da caracterstica comum Atividades Realizadas, analisando para cada uma, se a metodologia Extreme Programming a atende e, neste caso, como isto feito. Caso no atenda, o risco associado ao problema detectado ser identificado. 199

4.1.2 Metodologia para Realizao do Diagnstico

Para realizar o diagnstico a seguinte abordagem foi utilizada: cada prtica de implementao do CMM nvel 2 foi analisada e uma pontuao lhe foi atribuda, a qual representa a satisfao da prtica pela metodologia XP. Os valores desta pontuao foram baseados nos valores determinados pelo mtodo de avaliao de capacidade SCE (o Captulo 3 fornece maiores detalhes), no entanto, algumas alteraes foram realizadas para atender ao objetivo deste diagnstico. Estes valores so: Satisfeito: se a prtica foi completamente satisfeita por XP conforme requerido pelo modelo ou atravs de uma alternativa que atenda a inteno da prtica. No satisfeito: se h pontos fracos significativos associados prtica comprometendo a sua implementao. Parcialmente satisfeito: se h pontos fracos no significativos associados prtica. No aplicvel: se o componente no se aplica ao escopo deste trabalho. Determinar a satisfao de cada prtica requer a realizao de julgamento. Em avaliaes, este julgamento realizado por profissionais competentes, treinados e experientes que definem processos [33]. De 10 a 15% das prticas do CMM exigem interpretao, ou seja, a equipe de avaliao deve discutir a implementao da prtica at que se chegue a um consenso [33]. Devido a este fator de interpretao, Paulk reconhece que verdade que um julgamento pode diferir e algumas vezes isto acontece [33]. Assim como avaliaes oficiais, este diagnstico resultado de algumas interpretaes e julgamentos, de forma que pode diferir de outros diagnsticos se forem realizados por outras pessoas. As premissas utilizadas para determinar a satisfao das prticas sero documentadas para justificar o resultado.

4.1.3 Nomenclatura Utilizada no Diagnstico

Algumas siglas so comumente utilizadas para referenciar o CMM e tambm sero utilizadas neste trabalho. A Tabela 4-1 relaciona as siglas utilizadas para as reaschave de processo do CMM nvel 2. A Tabela 4-2 lista as siglas utilizadas para referenciar as caractersticas comuns do modelo.

200

Sigla RM SCM SPP SPTO SQA SSM Requisitos.

Descrio Do ingls Requirements Management, referente KPA Gerenciamento de Do ingls Software Configuration Management, referente KPA Gerenciamento de Configurao de Software. Do ingls Software Project Planning, referente KPA Planejamento de Projeto de Software. Do ingls Software Project Tracking and Oversight, referente KPA Acompanhamento de Projeto de Software. Do ingls Software Quality Assurance, referente KPA Garantia da Qualidade de Software. Do ingls Software Subcontract Management, referente KPA Gerenciamento de Subcontrato de Software.

Tabela 4-1 - Siglas utilizadas para as KPAs do CMM nvel 2

Sigla Ab Ac Co Me Ve Descrio Do ingls Ability, referente caracterstica comum Habilidade para Realizar. Do ingls Activity, referente caracterstica comum Atividades Realizadas. Do ingls Commitment, referente caracterstica comum Compromisso para Realizar. Do ingls Measurement, referente caracterstica comum Medio e Anlise. Do ingls Verification, referente caracterstica comum Verificar Implementao.

Tabela 4-2 - Siglas utilizadas para as caractersticas comuns do CMM Para referenciar uma prtica especfica do modelo, a nomenclatura X.YZ utilizada, onde: X corresponde sigla da KPA que possui a prtica Y corresponde sigla da caracterstica comum que agrupa a prtica Z corresponde ao nmero da prtica Como exemplo, SQA.Ac1 est referenciando a prtica atividade 1 da KPA garantia da qualidade de software. 201

Algumas vezes preciso citar sub-prticas. Nestes casos, o nmero da sub-prtica adicionado referncia aps .. Desta forma, SQA.Ac1.1 est referenciando a subprtica 1 da prtica atividade 1 da KPA garantia da qualidade de software.

4.2 Mapeamento de XP no CMM

Antes de iniciar o diagnstico importante definir como conceitos, termos e papis citados pelo CMM sero interpretados em XP. Apesar de ser um modelo para medir a capacidade de desenvolvimento de software das organizaes, CMM faz referncia a projetos de sistemas, os quais contemplam atividades relacionadas a software, hardware e outros componentes. Devido a isto, cita prticas para separar requisitos de software dos requisitos do sistema, cita o gerente do projeto e o gerente do projeto de software, por exemplo. XP um processo para desenvolvimento de software e no aborda possveis intersees com outros tipos de projetos (hardware, por exemplo) associados. Desta forma, o diagnstico levar em considerao projetos apenas de software, assim o gerente do projeto do CMM ser considerado como o prprio gerente de projeto de software.

4.2.1 Mapeamento dos Papis

A Tabela 4-3 faz um mapeamento entre os papis citados pelo CMM e os papis definidos por XP, que sero utilizados por todo o diagnstico.
Papis no CMM Gerncia Snior Grupo de engenharia de software Gerente de Projeto Gerente de Projeto de Software Grupo de Garantia da Qualidade Grupo de Gerncia de Configurao Equipe de XP. Mesmo que o Gerente de Projeto de Software. Tcnico (Coach). XP no define papis para atuar como o grupo de garantia da qualidade. XP no define papis para atuar como o grupo de gerncia da configurao. Papis em XP XP no define papis para a gerncia snior.

Tabela 4-3 - Mapeamento de papis CMM e XP

202

4.2.2 Mapeamento de Termos

A Tabela 4-4 faz um mapeamento entre conceitos citados pelo CMM e conceitos definidos por XP, que sero utilizados por todo o diagnstico.
Conceitos no CMM Requisitos alocados ao software Procedimento documentado Plano de desenvolvimento Estrias A descrio de XP, obtida em livros e artigos. Planos de XP: Big Plan, Plano do Release, Plano da Iterao. Conceitos em XP

Tabela 4-4 - Mapeamento de conceitos CMM e XP

4.3 Diagnstico da KPA Gerenciamento de Requisitos

O objetivo desta KPA estabelecer um entendimento comum, um acordo, entre o cliente e o projeto de software a respeito dos requisitos deste cliente [30]. Este cliente pode ser externo ou interno organizao. Um projeto que envolve desenvolvimento de software poder muitas vezes conter requisitos de hardware, padres e outros alm dos requisitos de software propriamente ditos. A KPA RM utiliza o termo "requisitos alocados ao software" para se referir especificamente aos requisitos de software de um sistema. Os requisitos alocados, devidamente acordados entre cliente e projeto, devem servir de base para a criao de planos, documentos tcnicos e do andamento do projeto como um todo. Tudo isto dever ser alterado para refletir mudanas que por ventura sejam realizadas aos requisitos.

4.3.1 Diagnstico de Satisfao das Prticas-chave

Atividade 1 O grupo de engenharia de software revisa os requisitos alocados antes de eles serem incorporados ao projeto de software. Diagnstico. O planejamento inicial do projeto - o Big Plan contm as funcionalidades de alto nvel do negcio (os requisitos alocados a software) e desenvolvido pelo cliente e por um integrante do projeto, que faz parte e representativo do grupo de engenharia de software do projeto. Alm disto, durante as reunies de

203

planejamento do release e iterao toda a equipe do projeto revisa as estrias (requisitos) visando entend-las e estim-las. Desta forma, as estrias so sempre revisadas pela equipe tcnica antes de serem incorporados, como requer a prtica. Esta prtica considerada satisfeita. O grupo de engenharia de software usa os requisitos alocados como base para planos de software, produtos de trabalho e atividades. Diagnstico. As estrias so base para todas as atividades de XP: Big Plan, Plano de Release, Plano de Iterao, desenvolvimento, testes. No entanto, as estrias constituem basicamente os requisitos funcionais do software. Para XP o sistema completamente especificado atravs de estrias e as define como sendo uma pequena descrio do comportamento do sistema do ponto de vista do usurio [39]. Um problema associado a esta prtica que para o CMM os requisitos alocados incluem critrios de aceitao de requisitos, requisitos tcnicos de software (funcionais, de performance, de restrio de linguagem de programao, entre outros) e no tcnicos, que afetam e determinam as atividades de software do projeto (produtos a serem entregues, marcos do projeto, datas de entregas, entre outros) [30]. XP no enfatiza e no descreve como nem onde documentar os requisitos no tcnicos e tcnicos no funcionais. O risco associado a este problema de os projetos no documentarem e acordarem requisitos crticos para o sucesso do projeto. Esta falta de documentao e acordo pode levar ao no atendimento das necessidades do cliente. Segundo Paulk, Sempre documente compromissos e os requisitos para o trabalho a ser realizado estes documentos so cruciais para esclarecimento e resoluo de conflitos durante o progresso do projeto [33]. Um outro problema associado a esta prtica que os requisitos no so gerenciados e controlados conforme sugere a sub-prtica RM.Ac2.1. As estrias so documentadas em cartes de papis e XP no faz meno de controlar a verso de cada estria ou mesmo

Atividade 2

204

do conjunto de estrias que define o release e iterao correntes, o que pode levar a futuras inconsistncias nestes mesmos planos, produtos de trabalho e atividades. Esta prtica considerada parcialmente satisfeita, pois XP utiliza as estrias para guiar o andamento do projeto, mas no menciona a documentao e uso dos requisitos no tcnicos e o controle das verses dos requisitos documentados. Atividade 3 Mudanas aos requisitos alocados so revisadas e incorporadas ao projeto de software. Diagnstico. As mudanas aos requisitos de um projeto XP so identificadas (em geral pelo cliente), avaliadas nas reunies de planejamento de release e/ou iterao, discutidas e entendidas pela equipe de desenvolvimento, documentadas em cartes atravs de uma nova estria e planejadas para fazerem parte de um release e iterao. Apesar disto, alguns problemas foram identificados quanto satisfao desta prtica. Primeiramente, a sub-prtica RM.Ac3.1 descreve que mudanas a compromissos feitos a indivduos e grupos externos organizao sejam revisadas com a gerncia snior e que mudanas aos compromissos internos organizao sejam negociadas com grupos afetados. XP no menciona o envolvimento da alta gerncia em seus projetos e da relao com grupos internos. Em [18], Rasmusson relata a dificuldade em cumprir os prazos estabelecidos em um projeto XP devido falta de compromisso firmado com grupos internos da organizao, como o grupo de administrao de dados. Alm disto, da forma como implementado, XP no possui um registro de histrico das mudanas, conforme requerido pela sub-prtica RM.Ac3.2, que menciona a documentao das mudanas. As mudanas geram novas estrias que so incorporadas ao projeto. No h visibilidade sobre: motivo, premissas utilizadas, responsvel pelas mudanas. O risco de no haver registro sobre isto o de avanar no projeto e no ter dados para responder questes como: por que a estria X no foi implementada?, por que o Big Plan inicial no foi cumprido?. Em [33], enquanto comenta sobre mudanas evolutivas aos requisitos em um desenvolvimento usando prototipagem, Paulk afirma que isto aceitvel se o histrico for mantido e os requisitos consolidados.

205

Esta prtica considerada parcialmente satisfeita, pois, apesar de a equipe revisar as mudanas antes de incorpor-las, esta reviso no inclui a alta gerncia, os grupos afetados e no so documentadas de forma a manter um histrico das mudanas.

4.3.2 Sumrio do Diagnstico de Satisfao das Prticas-chave

Prtica Satisfao Atividade 1 Satisfaz Resumo O grupo de engenharia de software revisa e documenta os requisitos de software em conjunto com o cliente durante o planejamento inicial do projeto (elaborao do Big Plan). Atividade 2 Satisfaz Parcialmente XP utiliza as estrias para guiar o andamento do projeto, mas no menciona a documentao e uso dos requisitos no tcnicos e o controle das verses dos requisitos documentados. Atividade 3 Satisfaz Parcialmente Apesar de a equipe revisar as mudanas antes de incorpor-las, esta reviso no inclui a alta gerncia, os grupos afetados e no so documentadas de forma a manter um histrico das mudanas.

Tabela 4-5 - Satisfao das Prticas de RM por XP

4.4 Diagnstico da KPA Planejamento de Projetos de Software

O propsito do Planejamento do Projeto de Software o de estabelecer planos factveis para realizar a engenharia de software e gerenciar o projeto de software [30]. Este processo aborda aspectos como: estimativa, cronograma, riscos, recursos computacionais crticos, compromissos estabelecidos entre outros. O planejamento do projeto inicia com um Plano de Trabalho, restries e metas que definem o projeto de software [30]. O planejamento do projeto dever abordar o que deve ser feito e de que forma [43]. Se bem documentado, permitir a comparao com o que foi efetivamente realizado no projeto.

206

4.4.1 Diagnstico de Satisfao das Prticas-chave

Atividade 1 O grupo de engenharia de software participa da equipe de proposta do projeto. Diagnstico. O CMM define atravs das sub-prticas desta prtica chave que o grupo de engenharia de software deve estar envolvido na preparao da proposta e submisso, discusses de esclarecimentos e negociaes de mudanas aos compromissos que afetam o projeto de software. Alm disto, o grupo revisa os compromissos do projeto (exemplos de compromissos revisados: cronograma, oramento, recursos, padres e procedimentos de software). [30]. Esta prtica foi considerada satisfeita, pois o contrato (proposta) elaborado a partir do Big Plan, desenvolvido pelo cliente e por um integrante do projeto, que faz parte e representativo do grupo de engenharia de software do projeto. Atividade 2 O planejamento do projeto de software iniciado nos estgios iniciais e em paralelo com o planejamento do projeto completo. Diagnstico. O planejamento de um projeto XP iniciado nos estgios iniciais do projeto. Quanto a ser iniciado em paralelo com o planejamento do projeto completo, foi considerado no aplicvel. Com esta frase o CMM espera que o planejamento do projeto de software ocorra em paralelo com o planejamento do projeto como um todo, considerando um projeto que possui desenvolvimento de hardware e outros componentes. Como j mencionado, este diagnstico considera apenas projeto de software. Atividade 3 O grupo de engenharia de software participa com outros grupos afetados do planejamento do projeto completo durante a vida do projeto. Diagnstico. Esta atividade do CMM, bem como a Atividade 2, se referem a projetos de sistema (hardware, software e outros componentes) para que o grupo de engenharia de software participe e revise o Plano do Projeto como um todo.

207

Este item tambm considerado no aplicvel a este diagnstico, pois vai alm do escopo de projetos de software. Atividade 4 Compromissos do projeto de software feitos para indivduos e grupos externos organizao so revisados com a gerncia snior de acordo com um procedimento documentado. Diagnstico. No satisfaz. XP no define o relacionamento entre a gerncia snior e o projeto. Atividade 5 Um ciclo de vida de software com estgios pr-definidos de tamanho gerenciado identificado ou definido. Diagnstico. Esta prtica considerada satisfeita, pois as iteraes de um projeto XP so vistas como os estgios pr-definidos no projeto e possuem tamanho pequeno visando facilitar o gerenciamento. O propsito destas iteraes justamente promover ciclos menores de desenvolvimento que os ciclos de entrega (release) para realizar correes necessrias durante o andamento do projeto [24]. Atividade 6 O plano de desenvolvimento do projeto de software desenvolvido de acordo com um procedimento documentado. Diagnstico. Interpretando o plano de desenvolvimento de um projeto XP como os planos Big Plan, Plano de Release e Plano de Iterao, XP descreve como documentlos. Apesar disto, o CMM ressalta aspectos importantes que tipicamente so descritos no procedimento para elaborao do plano de desenvolvimento e que XP no menciona, como: Planejamento a partir de padres estabelecidos (SPP.Ac6.1) XP no descreve como e nem onde documentar os padres adotados. O planejamento sobre estes padres no descrito pela metodologia. O risco associado o no seguimento de padres estabelecidos para o projeto;

208

Envolvimento dos grupos afetados (SPP.Ac6.3 e SPP.Ac6.2) Como j mencionado, XP no cita como deve se dar o envolvimento de grupos externos equipe do projeto, o que pode acarretar no no cumprimento de compromissos do projeto relacionados a prazo, custo e at mesmo funcionalidades;

Reviso do plano por parte de grupos afetados e cliente (SPP.Ac6.4) A reviso do plano por parte de grupos afetados objetiva obter acordo sobre os compromissos firmados. Em XP o acordo estabelecido nas reunies de planejamento de release e iterao. XP no descreve como obter acordo dos grupos afetados que no participam destas reunies;

Gerenciamento e controle dos planos (SPP.Ac6.5) Objetiva saber a verso do plano de desenvolvimento e as mudanas incorporadas. XP no define como obter estas informaes dos planos citados. Esta prtica considera parcialmente satisfeita, pois a descrio de XP deve ser

considerada um procedimento documentado para o planejamento do projeto, no entanto, ela no aborda aspectos importantes do planejamento, como: planejamento a partir de padres estabelecidos, envolvimento dos grupos afetados, reviso do plano por parte de grupos afetados e cliente, gerenciamento e controle dos planos. Atividade 7 O plano para o projeto de software documentado.

Diagnstico. O plano do projeto para o CMM o mesmo que o plano de desenvolvimento citado nas prticas anteriores [30]. O CMM relaciona o que coberto por este plano nas sub-prticas desta atividade. Exemplos do que deve estar contido no plano para o projeto so: propsito, escopo, metas e objetivos do projeto de software; ciclo de vida do software; procedimentos, mtodos e padres para desenvolvimento e/ou manuteno do software; produtos de trabalho a serem desenvolvidos; estimativas de tamanho dos produtos de trabalho e mudanas aos produtos de trabalho; estimativa de custo e esforo do projeto de software; estimativas de uso dos recursos crticos computacionais; cronograma do projeto de software, incluindo identificao de marcos e revises; avaliaes dos riscos de software do projeto; planos para ferramentas de suporte para a engenharia de software do projeto.

209

Os planos contemplados por XP (Big Plan, Plano do Release e Plano da Iterao) no abordam todos os aspectos esperados pelo CMM. Para realizar o planejamento inicial, o que dar subsdios para determinar o escopo (alto nvel), prazo e custo do projeto, informaes detalhadas no so conhecidas. A Tabela 4-6 mostra como organizado o Big Plan de um projeto XP [24].
Estria Nome da estria Estimativa Quantidade de meses para implement-la

Tabela 4-6 - Big Plan Beck sugere que a forma mais apropriada do Plano de Release o conjunto de cartes de estrias que fazem parte dele [24]. Um tpico possui as seguintes informaes: data, tipo da atividade (nova, correo, melhoria ou teste funcional), nmero da estria, descrio, notas, estimativa tcnica, prioridade, entre outras [25]. Esta forma de armazenar o Plano de Release no deixa claro onde foram documentadas a data do release e velocidade da equipe assumida, informaes importantes para este plano. Uma outra forma de registrar o Plano do Release utilizar uma planilha eletrnica simples [24]. Como exemplo, Beck exibe em [24] duas tabelas como as Tabela 4-7 e Tabela 4-8.
Estria Estimativa de Tempo (Semanas Ideais) Quantidade de semanas ideais Iterao Atribuda Nmero da Nome da estria iterao atribuda para a estria Release Atribudo Nmero do release atribudo para a estria

Tabela 4-7 - Planejamento de Release

Evento Release X completo Data Data em que o release X deve ser completado.

Tabela 4-8 - Datas de Releases

210

O planejamento da iterao ir gerar cartes de tarefas com as seguintes informaes: data, nmero da estria, descrio da tarefa, notas, estimativa da tarefa, engenheiro de software, entre outras [25]. O conjunto dos cartes de tarefas de uma iterao constitui o Plano da Iterao. Em [24], um exemplo de Plano de Iterao exibido, o qual contm as seguintes informaes: estria, tarefas da estria, estimativa e responsvel por implementar cada estria. Os trs planos definidos por XP no contemplam todas as informaes importantes e esperadas pelo CMM como propsito, escopo, metas e objetivos do projeto de software, procedimentos, mtodos e padres para desenvolvimento e/ou manuteno do software, entre outros. Por isto, esta prtica considerada parcialmente satisfeita. Atividade 8 Produtos de trabalho de software necessrios para estabelecer e manter controle do projeto de software so identificados. Diagnstico. Se o cliente requer a elaborao de algum produto de trabalho (como o manual do usurio, por exemplo), ento uma estria para isto dever ser escrita, associada a um release, detalhada para ser realizada em iteraes. Desta forma, apesar de XP no relacionar atividades especficas para identificao de produtos de trabalho a serem construdos, isto feito durante as reunies de planejamento de release e/ou iteraes. Portanto, esta prtica considerada satisfeita. Atividade 9 Estimativas para o tamanho dos produtos de trabalho de software (ou mudanas aos tamanhos dos produtos de trabalho de software) so derivadas de acordo com um procedimento documentado. Diagnstico. O CMM exemplifica como tipo de estimativas de tamanho: pontos de funo, quantidade de linhas de cdigo, quantidade de requisitos e quantidade de pginas. Em um projeto XP so estimadas estrias e tarefas. Beck afirma em [24], que a unidade para estimar estrias e tarefas uma deciso do projeto e no importa qual seja,

211

o que importa a equipe acordar uma unidade e todos utiliz-la. Apesar disto, ele sugere que a unidade mais simples para estimar e acompanhar o Tempo Ideal. Tempo Ideal o tempo sem interrupes onde voc pode se concentrar no seu trabalho e voc se sente completamente produtivo [24]. Apesar de usar a palavra tempo, esta uma unidade de esforo. A noo de tempo ideal tem pouco haver com o tempo ou ns usamos o termo tempo ideal, mas na realidade esforo ideal, afirma Beck [24]. Quando um integrante da equipe afirma que a tarefa que ele desprender x dias ideais em uma tarefa, ele estar considerando a quantidade de dias de trabalho sem interrupes, nem mesmo para ajudar um outro integrante atuando como seu par de programao, o que acontece freqentemente. Este diagnstico considera que XP no define como estimar tamanho para os principais produtos de trabalho e atividades, mas apenas define como estimar esforo para todas as atividades (estrias e tarefas). Desta forma, esta prtica considerada no satisfeita. Em relao a possibilidade de se estimar tamanho em um projeto XP, Beck [24], considera afirma que ineficaz o processo de estimar quantidade de linhas de cdigo com o objetivo de se prever o esforo necessrio. Atividade 10 Estimativas para esforo e custo do projeto de software so derivadas de acordo com procedimento documentado. Diagnstico. Como j mencionado, XP determina como estimar esforo. Alm disto, XP atende vrias das sub-prticas relacionadas pelo CMM, como: Dados de produtividade so usados para as estimativas quando disponveis a velocidade de uma iterao definida por XP a produtividade da equipe, que deve sempre ser atualizada [24]; Esforo, alocao de pessoal, e estimativas de custo so baseadas em experincias passadas XP sempre refora a necessidade de usar o Yesterday Weather, que significa olhar dados passados para realizar as estimativas [24]; Estimativas e premissas feitas para derivar as estimativas so documentadas, revisadas e acordadas Em XP, as estimativas e premissas so documentadas 212

nos cartes de papel e revisadas por todos da equipe, j que so realizadas em conjunto [24]. Quanto s estimativas de custo, XP considera que devem ser derivadas da quantidade de pessoas e dedicao de esforo ao projeto [24]. Apesar de, em geral, esforo necessrio ser o principal custo de um projeto de software, outros custos em geral so envolvidos, como viagens, estrutura fsica e treinamentos. Desta forma, XP no define como estimar outros custos relacionados ao projeto, nem mesmo menciona que deve ser feito. Esta prtica considerada parcialmente satisfeita, pois apesar de estimar esforo, no atende sub-prtica de relacion-las s estimativas de esforo e custo. Alm disto, no define de forma satisfatria como estimar custos. Atividade 11 Estimativas para os recursos computacionais crticos do projeto so derivadas de acordo com um procedimento documentado. Diagnstico. CMM exemplifica os recursos computacionais crticos como recursos no ambiente de desenvolvimento, no ambiente de teste e integrao, no ambiente de implantao ou em qualquer combinao destes [30]. XP em nenhum momento aborda a questo de planejar e estimar os recursos computacionais crticos, portanto, esta prtica considerada no satisfeita. Atividade 12 O cronograma de software do projeto derivado de acordo com um procedimento documentado. Diagnstico. Para Sommerville, realizar um cronograma envolve separar o trabalho total em atividades e julgar o tempo requerido para complet-las [14]. Alm disto, coordenar as atividades que ocorrem em paralelo evitando que o projeto seja atrasado porque uma atividade crtica no foi finalizada ou foi atrasada. Em geral, cronogramas so representados por grficos que mostram dependncias entre atividades, alocao de recursos, caminho crtico de atividades, como o grfico PERT [14].

213

XP no possui um cronograma convencional para o controle das atividades. Para cada release XP define datas de incio e fim e estrias, para cada iterao define datas de incio e fim e tarefas. As estrias no possuem responsveis, as tarefas sim. Dentro dos releases e iteraes no h datas intermedirias para encerrar estrias e tarefas respectivamente, isto deve ocorrer at o final do release e iterao. No h controle das dependncias entre as estrias e tarefas. Um conselho de Beck ignore dependncia entre partes planeje como se as partes do desenvolvimento pudessem ser trocadas entre si [25]. Durante a reunio de planejamento do release estas partes so as estrias e na de planejamento da iterao, as tarefas [25]. Apesar de no ter o controle das dependncias das tarefas e trabalho paralelo, o cronograma de XP considerado por este diagnstico satisfatrio para a forma como os projetos so conduzidos. Segundo Sommerville, no til subdividir atividades em unidades menores que uma semana ou duas para executar [14]. Em XP as iteraes so tipicamente de duas a trs semanas de durao e tarefas possuem durao menor do que isto. Apesar de XP no citar tudo o que, do ponto de vista do CMM, tipicamente um procedimento documentado para elaborao de cronograma deve conter, esta prtica considerada satisfeita, pois XP define de forma objetiva todos os aspectos importantes de como elaborar o cronograma em um projeto XP. Atividade 13 Os riscos de software associados com custo, recursos, cronograma e aspectos tcnicos do projeto so identificados, avaliados e documentados. Diagnstico. Esta prtica considerada no satisfeita, pois XP no aborda a questo de riscos do projeto de software. Atividade 14 Planos para as instalaes e ferramentas de apoio para a engenharia de software do projeto so preparados.

214

Diagnstico. O CMM cita exemplos destas instalaes e ferramentas de suporte: computadores de desenvolvimento de software, perifricos, computadores de teste de software e software de suporte [30]. Os planos de XP no abordam estes aspectos. Em relao s instalaes necessrias, XP aborda apenas o local de desenvolvimento e cita algumas caractersticas para que ele seja efetivo: O ambiente deve ser montado de forma que as pessoas possam trabalhar perto uma das outras para que vejam umas s outras e escutarem questes levantadas entre si; O ambiente deve prover algum lugar com a privacidade necessria para realizao de telefonemas e reunies. Desta forma, esta prtica considerada no satisfeita, j que no h planos explcitos em XP para as instalaes e ferramentas de apoio necessrias. Atividade 15 Dados do planejamento de software so registrados.

Diagnstico. Atravs das sub-prticas, o CMM aborda o que espera do registro do planejamento: SPP.Ac15.1: Informao registrada inclui as estimativas e informaes associadas necessrias para reconstruir as estimativas e avaliar a sua sensatez; SPP.Ac15.2: Os dados de planejamento de software so gerenciados e controlados. Como j mencionado, XP armazena os dados de estimativas e premissas associados nos prprios cartes de estrias e tarefas, no entanto, no menciona o controle das verses dos produtos de trabalho associados ao planejamento. Por isto, esta prtica considerada parcialmente satisfeita. A falta de controle de verso nos planos de release e iterao pode levar falta de histrico sobre as mudanas realizadas no planejamento, o que pode ser bastante prejudicial num projeto XP, onde mudanas podem ser realizadas a qualquer momento do projeto, de forma flexvel. Manter o histrico destas mudanas contribui para o entendimento do progresso do projeto e renegociao de compromissos.

215

4.4.2 Sumrio do Diagnstico de Satisfao das Prticas-chave

Prtica Diagnstico Atividade 1 Satisfaz Resumo O contrato elaborado com a participao de um integrante do projeto, representante do grupo de engenharia de software. Atividade 2 No Aplicvel XP foca em projetos de software. Esta prtica aplicvel para projetos que envolvem outros componentes alm de software. Atividade 3 No Aplicvel XP foca em projetos de software. Esta prtica aplicvel para projetos que envolvem outros componentes alm de software. Atividade 4 No Satisfaz XP no define o relacionamento entre a gerncia snior e o projeto. As iteraes de um projeto XP so vistas como estgios predefinidos de tamanho gerenciado. A descrio de XP deve ser considerada um procedimento documentado para o planejamento do projeto, no entanto, ela no aborda aspectos Atividade 6 Satisfaz Parcialmente importantes do planejamento, como: planejamento a partir de padres estabelecidos, envolvimento dos grupos afetados, reviso do plano por parte de grupos afetados e cliente, gerenciamento e controle dos planos. Os trs planos definidos por XP no contemplam todas as informaes importantes e esperadas pelo CMM como propsito, escopo, Atividade 7 Satisfaz Parcialmente metas e objetivos do projeto de software, procedimentos, mtodos e padres para desenvolvimento e/ou manuteno do software, entre outros.

Atividade 5

Satisfaz

216

 Atividade 8 Satisfaz

Os produtos de trabalho so identificados durante o Planejamento do Release e/ou da Iterao.

Atividade 9

No Satisfaz

XP no contempla estimativa de tamanho dos produtos de trabalho.

Atividade 10 Satisfaz Parcialmente

XP define como estimar esforo, mas no relaciona estas estimativas com as estimativas de tamanho. Alm disto, no define de forma satisfatria como estimar custos.

Atividade 11

No Satisfaz

XP no aborda a questo de planejar e estimar os recursos computacionais crticos.

Atividade 12 Satisfaz

XP define de forma objetiva todos os aspectos importantes de como elaborar o cronograma em um projeto.

Atividade 13

No Satisfaz

XP no aborda a questo de riscos do projeto de software.

Atividade 14 No Satisfaz

XP no contempla planos explcitos para as instalaes e ferramentas de apoio do projeto de software.

Atividade 15 Satisfaz Parcialmente

XP armazena os dados de estimativas e premissas associados nos prprios cartes de estrias e tarefas, no entanto, no menciona o controle das verses dos produtos de trabalho associados ao planejamento.

Tabela 4-9 - Satisfao das Prticas de SPP por XP

4.5 Diagnstico da KPA Acompanhamento de Projetos de Software

O propsito do Acompanhamento de Projeto de Software prover visibilidade adequada no progresso real de forma que o gerenciamento possa tomar aes efetivas 217

quando a performance do projeto de software desvia significativamente dos planos de software [30]. O Plano do Projeto utilizado como base para o acompanhamento do projeto. Os resultados obtidos so comparados com o planejado para o projeto.

4.5.1 Diagnstico de Satisfao das Prticas-chave

Atividade 1 Um plano de desenvolvimento de software documentado usado para acompanhamento das atividades de software e comunicao do status. Diagnstico. Esta prtica considerada satisfeita, pois os planos de Release e iterao guiam as atividades da equipe e esto sempre disponveis para todos os envolvidos no projeto. Atividade 2 O plano de desenvolvimento de software do projeto atualizado de acordo com um procedimento documentado. Diagnstico. Num projeto XP, os planos mudam [24]: Se a velocidade da equipe assumida para a iterao e/ou release diferir do planejado. Neste caso, se a velocidade da equipe menor, ento a mesma dever requisitar ao cliente que selecione estrias para serem retiradas da iterao e/ou release; Se a velocidade da equipe maior, ento a mesma dever requisitar ao cliente que selecione estrias para serem inseridas na iterao e/ou release; A qualquer momento, se o cliente desejar inserir novas estrias ao release ou retirar outras. Planejamento de release acontece todo o tempo. Todas as vezes que o cliente muda de idia sobre os requisitos ou de prioridades, o plano muda [24]. Para isto, uma reunio de planejamento de release realizada para que o cliente selecione uma estria de mesma ou mais baixa complexidade para ser retirada do release. Feito isto, o cliente ir prioriz-la para ser implementada em alguma iterao. Em ambos os casos, os planos de release e iterao so alterados. Os planos so apenas um atalho para a viso corrente das coisas que sero feitas. Ele ser alterado todo 218

o tempo. Todos desenvolvedores, clientes, e gerente precisam aceitar mudanas constantes [24]. Desta forma, esta prtica considerada satisfeita. Atividade 3 Compromissos e mudanas aos compromissos do projeto de software feitos a indivduos e grupos externos organizao so revisados com a gerncia snior de acordo com um procedimento documentado. Diagnstico. No satisfaz. XP no define o relacionamento entre a gerncia snior e o projeto. Atividade 4 Mudanas aprovadas aos compromissos que afetam o projeto de software so comunicadas aos membros do grupo de engenharia de software e outros grupos relacionados a software. Diagnstico. Num projeto XP, os compromissos que afetam o projeto de software so relacionados com datas de release e fim de iterao, velocidade da equipe assumida, estimativas, estrias do release e iterao, entre outros. Todos estes compromissos so acordados em reunies onde participam clientes e equipe, portanto, esta prtica considerada satisfeita. Atividade 5 Os tamanhos dos produtos de trabalho de software (ou tamanhos das mudanas aos produtos de trabalho de software) so acompanhadas, e aes corretivas so tomadas quando necessrio. Diagnstico. Esta prtica considerada no satisfeita, pois XP no aborda estimativa de tamanho de produto de trabalho, to pouco seu acompanhamento. Atividade 6 Esforo e custo de software do projeto so

acompanhados, e aes corretivas so tomadas quando

219

necessrio. Diagnstico. O acompanhamento do esforo realizado pelo tracker, que deve questionar pessoalmente cada programador quanto j foi realizado de cada tarefa atribuda e quanto ainda resta [24]. A periodicidade sugerida para este acompanhamento de duas vezes por semana [24]. A partir deste acompanhamento, XP sugere aes a serem tomadas caso desvios sejam identificados [24]: Se identificado que algum programador no poder cumprir uma tarefa a ele atribuda, ento deve-se procurar outro que possua tempo disponvel para implement-la. Caso no encontre, ento deve-se levar o problema para que o cliente selecione o que poder sair da iterao; Se identificado que h tempo sobrando na iterao, ento o cliente dever ser informado para incluir uma outra estria. Apesar de acompanhar esforo e promover a tomada de ao corretiva, XP no menciona o acompanhamento de custos. Assim, esta prtica considerada parcialmente satisfeita. Atividade 7 Recursos computacionais crticos do projeto so acompanhados e aes corretivas so tomadas quando necessrio. Diagnstico. Esta prtica no satisfeita, pois XP no aborda de forma explcita o planejamento e acompanhamento de recursos crticos computacionais. Atividade 8 O cronograma de software do projeto acompanhado, e aes corretivas so tomadas quando necessrio. Diagnstico. Como j citado anteriormente, XP no possui um cronograma convencional para o controle das atividades: datas e atividades so definidas para cada release e iterao do projeto.

220

A realizao das atividades verificada pelo tracker durante e no incio das iteraes. Num projeto XP, uma estria considerada finalizada quando demonstrada para o cliente e ele concorda que ela atende s expectativas [24]. Para isto, os testes funcionais devem ser executados e os problemas encontrados sero julgados pelo cliente se so grandes o suficiente para impactar a aceitao (finalizao) da estria [24]. O acompanhamento das datas das iteraes muito simples em um projeto XP: a iterao finalizada na data acordada no incio. Uma iterao de duas semanas encerra-se em duas semanas, sem mais [24]. Se uma estria planejada para uma iterao no foi finalizada a tempo, ela dever ser replanejada para a prxima iterao, com o conhecimento do cliente, nas reunies de incio da iterao. Esta prtica considerada ento satisfeita, pois em um projeto XP o cronograma acompanhado e aes corretivas so tomadas quando necessrio. Atividade 9 Atividades tcnicas de engenharia de software so acompanhadas, e aes corretivas so tomadas quando necessrio. Diagnstico. As atividades do grupo de engenharia so acompanhadas diariamente atravs das reunies Stand Up Meetings, que tem como objetivo comunicar os problemas, o que cada um est e o que no est fazendo [24]. Os problemas identificados so, ento, encaminhados para serem resolvidos. Portanto, esta prtica considerada satisfeita. Atividade 10 Os riscos de software associados a custo, recursos, cronograma e aspectos tcnicos do projeto so acompanhados. Diagnstico. Esta prtica considerada no satisfeita, pois XP no aborda a identificao e acompanhamento dos riscos do projeto. Atividade 11 Dados de medida e dados de replanejamento reais para o projeto de software so registrados.

221

Diagnstico. Assim como a atividade SPP.Ac15, esta atividade considerada parcialmente satisfeita, pois XP no menciona o controle das verses dos produtos de trabalho associados ao planejamento, conforme sugerido pelas sub-prticas desta prtica (consultar SPP.Ac15 para maiores detalhes). Atividade 12 O grupo de engenharia de software conduz revises internas peridicas para acompanhar progresso tcnico, planos, performance, e outros itens contra o plano de desenvolvimento de software. Diagnstico. Esta prtica satisfeita atravs das reunies de planejamento de iterao. Estas reunies so peridicas e, para se planejar a prxima iterao, o progresso tcnico, planos e performance so utilizados. Atividade 13 Revises formais para enderear realizaes e

resultados do projeto de software so conduzidas nos marcos selecionados do projeto de acordo com procedimento documentado. Diagnstico. As reunies de planejamento de release podem ser mapeadas para estas revises formais. Estas reunies satisfazem algumas das sub-prticas do CMM, como: SPTO.Ac13.1: so planejadas para ocorrer em pontos significativos do cronograma do projeto de software, como o comeo ou finalizao de estgios selecionados; SPTO.Ac13.2: So conduzidas com o cliente, usurio final, e grupos afetados da organizao, conforme apropriado. No entanto, esta prtica no considerada completamente satisfeita, pois XP no menciona a sub-prtica citadas pelo CMM: SPTO.Ac13.6: Relaciona os riscos do projeto de software.

222

4.5.2 Sumrio do Diagnstico de Satisfao das Prticas-chave

Prtica Diagnstico Atividade 1 Satisfaz Resumo Os planos de Release e iterao guiam as atividades da equipe e esto sempre disponveis para todos os envolvidos no projeto. Atividade 2 Satisfaz Os planos de release e iterao so atualizados para refletir o andamento do projeto. XP no define o relacionamento entre a gerncia snior e o projeto. Atividade 4 Satisfaz Todos os compromissos de um projeto XP so acordados em reunies onde participam clientes e equipe. Atividade 5 No Satisfaz XP no aborda estimativa de tamanho de produto de trabalho, to pouco seu acompanhamento. Atividade 6 Satisfaz Parcialmente Apesar de acompanhar esforo e promover a tomada de ao corretiva, XP no menciona o acompanhamento de custos. Atividade 7 No Satisfaz XP no aborda de forma explcita o planejamento e acompanhamento de recursos crticos computacionais. Atividade 8 Satisfaz Em um projeto XP o cronograma acompanhado e aes corretivas so tomadas quando necessrio. Atividade 9 Satisfaz As atividades do grupo de engenharia so acompanhadas diariamente atravs das reunies Stand Up Meetings. Atividade 10 No Satisfaz XP no aborda a identificao e acompanhamento dos riscos do projeto.

Atividade 3

No Satisfaz

223

 Atividade 11 Satisfaz Parcialmente

XP armazena os dados de estimativas e premissas associados nos prprios cartes de estrias e tarefas, no entanto, no menciona o controle das verses dos produtos de trabalho associados a replanejamento.

Atividade 12 Satisfaz

As reunies de planejamento de iterao ocorrem periodicamente, onde informaes sobre progresso tcnico, planos e performance so utilizados.

Atividade 13 Satisfaz Parcialmente

As reunies de planejamento de release ocorrem em pontos significativos do projeto, contam com a participao de cliente e equipe, relaciona planos, mas no aborda riscos do projeto.

Tabela 4-10 - Satisfao das Prticas de SPTO por XP

4.6 Diagnstico da KPA Garantia da Qualidade de Software

O objetivo da garantia da qualidade prover visibilidade sobre o processo utilizado e o projeto construdo. Para isto, esta KPA menciona um grupo de garantia da qualidade, o qual deve possuir um canal direto de comunicao com a gerncia snior independente da equipe do projeto. O grupo de garantia da qualidade cumpre seu objetivo atravs de auditorias e revises do processo e dos produtos. Os problemas identificados devem ser resolvidos pela equipe do projeto e documentados e acompanhados at fechamento pelo grupo de garantia da qualidade. Problemas no resolvidos pela equipe devem ser escalados para a alta gerncia. [30]. Alm das revises e auditorias, o grupo de garantia da qualidade deve reportar suas atividades para a equipe, grupo de garantia da qualidade do cliente e alta gerncia. As atividades de garantia da qualidade devem ser planejadas no incio do projeto [30].

4.6.1 Diagnstico de Satisfao das Prticas-chave

XP no define um grupo de garantia da qualidade, to pouco atividades para reviso e/ou auditoria de processos.

224

Paulk v a programao em pares como uma atividade de garantia da qualidade, pois ela contribui para a aderncia a padres adotados pelo projeto [31]. Apesar disto, Paulk tambm alega que esta atividade no prov visibilidade para a alta gerncia e pode no ser eficaz para projetos grandes e para situaes de grande presso externa [31]. O diagnstico considera que nenhuma das atividades descritas pelo CMM para esta KPA atendida, pois no h um pr-requisito necessrio para as atividades: um grupo de garantia da qualidade, independente do projeto. Por isto, o diagnstico desta KPA no foi detalhado como nas KPAs RM, SPP e SPTO. As atividades desta KPA so [30]: SQA.Ac1: Um plano de SQA preparado para o projeto de software de acordo com um procedimento documentado; SQA.Ac2: As atividades do grupo de SQA so realizadas de acordo com o plano de SQA; SQA.Ac3: O grupo de SQA participa na preparao e reviso do plano de desenvolvimento de software, padres e procedimentos; SQA.Ac4: O grupo de SQA revisa as atividades da engenharia de software para verificar conformidade; SQA.Ac5: O grupo de SQA audita os produtos de trabalho designados para verificar conformidade; SQA.Ac6: O grupo de SQA periodicamente reporta os resultados de suas atividades ao grupo de engenharia de software; SQA.Ac7: Desvios identificados nas atividades e produtos de trabalho de software so documentados e tratados de acordo com procedimento documentado; SQA.Ac8: O grupo de SQA conduz revises peridicas das suas atividades e problemas encontrados com o pessoal de SQA do cliente, como apropriado.

225

4.7 Diagnstico da KPA Gerncia de Configurao de Software

A gerncia da configurao de software tem como objetivo estabelecer e manter a integridade dos produtos de software do projeto. Uma das prticas da caracterstica comum Habilidade para Realizar desta KPA, descreve que um grupo responsvel por coordenar e implementar SCM para o projeto existe. Dentre as principais atividades de gerncia de configurao esto: planejar como a gerncia de configurao ser tratada no projeto, identificar a configurao de software, identificar itens de configurao, estabelecer baselines, controlar mudanas, registrar o status da configurao e realizar auditorias de configurao [3].

4.7.1 Diagnstico de Satisfao das Prticas-chave

Atividade 1 Um plano de SCM preparado para cada projeto de software de acordo com um procedimento documentado. Diagnstico. Esta prtica considerada no satisfeita, pois XP no menciona plano para o gerenciamento de configurao. Atividade 2 Um plano de SCM documentado e aprovado utilizado como base para a realizao das atividades de SCM. Diagnstico. Esta prtica considerada no satisfeita, pois, como citado no diagnstico da prtica SCM.Ac1, XP no menciona plano para o gerenciamento de configurao. Atividade 3 Um sistema de biblioteca de gerenciamento de configurao estabelecido como um repositrio para as baselines de software. Diagnstico. No satisfeita. XP no menciona o estabelecimento de um sistema de gerenciamento da configurao. Sub-prticas e exemplos citados pelo CMM para este sistema inclui: possuir nveis de controle, prover armazenamento e recuperar itens de configurao, apoiar a criao correta de produtos a partir da baseline de software. 226

Atividade 4

Os produtos de trabalho de software a serem colocados sob gerncia de configurao so identificados.

Diagnstico. O principal produto de trabalho em um projeto XP o cdigo. Outros produtos de trabalho que precisem ser desenvolvidos no projeto so identificados nas reunies de planejamento de release e/ou iteraes. Esta prtica considerada parcialmente satisfeita, pois se o projeto precisar possuir outros itens de configurao alm de cdigo, o que bastante comum, vrias das sub-prticas no so atendidas, como: SCM.Ac4.1: Os itens de configurao so selecionados com base em um critrio documentado. XP no define critrios para selecionar itens de configurao; SCM.Ac4.4: As baselines a que cada item/unidade de configurao pertence so especificadas. XP no determina baselines para itens de configurao alm de cdigo; SCM.Ac4.5: O ponto no desenvolvimento em que cada item/unidade de configurao colocado sob gerncia de configurao especificado. XP no menciona o momento para iniciar a gerncia de configurao para itens que no sejam cdigo.

Atividade 5

Requisies de mudana e reportagens de problema para todos os itens de configurao so iniciados, registrados, revisados, aprovados e acompanhados de acordo com um procedimento documentado.

Diagnstico. Para o cdigo, depois de seu release, problemas ou melhorias devem ser identificadas, documentadas e tratadas como uma estria [24]. Uma estria registrada em cartes de papel, revisada e aprovada pela equipe, quando tambm estimada e acompanhada durante a iterao, conforme sugere a prtica. Desta forma, esta prtica considerada satisfeita.

227

Atividade 6

Mudanas s baselines so controladas de acordo com um procedimento documentado.

Diagnstico. Considerando o build integrado como a baseline de software, esta prtica considerada satisfeita. Em sub-prticas, o CMM relaciona atividades tpicas realizadas para o controle das baselines: SCM.Ac6.1: Revises e/ou testes de regresso so realizados para assegurar que mudanas no causaram efeitos indesejados baseline; SCM.Ac6.3: Itens/unidades de configurao so colocadas e retiradas de maneira a manter a corretude e integridade da baseline. A prtica de XP integrao contnua descreve que o cdigo integrado e testado aps poucas horas um dia de desenvolvimento no mximo [25]. Para mudar um cdigo na baseline, um par de desenvolvedores deve integrar seu cdigo com as mudanas efetuadas ao cdigo da baseline e rodar os testes at que 100% deles passem [25]. XP tambm sugere que o projeto possua uma mquina dedicada realizar esta integrao [25]. Atividade 7 Produtos da biblioteca de baseline de software so criados e seus releases so controlados de acordo com procedimento documentado. Diagnstico. XP determina que o produto (software) criado a partir da baseline de software (build integrado, com 100% dos testes rodando), conforme o planejamento de releases. Esta prtica considerada satisfeita. Atividade 8 O status dos itens/unidades de configurao

registrado de acordo com um procedimento documentado. Diagnstico. No satisfaz: XP no menciona o registro do status dos itens de configurao. Segundo a sub-prtica SCM.Ac8.1, este registro deve ser feito em detalhe suficiente para que o contedo e status de cada item/unidade de configurao sejam conhecidos e verses anteriores possam ser recuperadas [30]. 228

Atividade 9

Relatrios padres documentando as atividades e SCM e contedo das baselines so desenvolvidos e tornados disponveis para os grupos e indivduos afetados.

Diagnstico. No satisfaz, pois XP no menciona o uso de relatrios de gerncia de configurao e disponibilizao aos grupos afetados. Atividade 10 Auditorias nas baselines de software so conduzidas de acordo com um procedimento documentado. Diagnstico. XP no menciona auditorias nas baselines de software, portanto esta prtica no considerada satisfeita.

4.7.2 Sumrio do Diagnstico de Satisfao das Prticas-chave

Prtica Atividade 1 Diagnstico No Satisfaz Resumo XP no menciona plano para o gerenciamento de configurao. XP no menciona plano para o gerenciamento de configurao. XP no menciona o estabelecimento de um sistema de gerenciamento da configurao. Atividade 4 Satisfaz Parcialmente Se o projeto possuir outros itens de configurao alm de cdigo, vrias das sub-prticas no so atendidas. Atividade 5 Satisfaz Problemas ou melhorias devem ser identificados, documentados e tratados como uma estria, que so registradas em cartes de papel, revisadas e aprovadas pela equipe e acompanhadas durante a iterao. Atividade 6 Satisfaz Para mudar um cdigo na baseline, um par de desenvolvedores deve integrar seu cdigo com

Atividade 2

No Satisfaz

Atividade 3

No Satisfaz

229

as mudanas efetuadas ao cdigo da baseline e rodar os testes at que 100% deles passem. Atividade 7 Satisfaz XP determina que o produto (software) criado a partir da baseline de software (build integrado, com 100% dos testes rodando), conforme o planejamento de releases. Atividade 8 No Satisfaz XP no menciona o registro do status dos itens de configurao. Atividade 9 No Satisfaz XP no menciona o uso de relatrios de gerncia de configurao e disponibilizao aos grupos afetados. Atividade 10 No Satisfaz XP no menciona auditorias nas baselines de software.

Tabela 4-11 - Satisfao das Prticas de SCM por XP

4.8 Resumo
O objetivo deste diagnstico foi identificar os problemas de no aderncia de XP s prticas da caracterstica comum Atividades para Realizar das KPAs do nvel 2 do CMM. A KPA Gerenciamento do Subcontrato de Software no foi analisada, pois foge ao escopo da metodologia de desenvolvimento de software XP. XP implementa grande parte das prticas das KPAs Gerenciamento de Requisitos, Planejamento de Projetos, Acompanhamento de Projetos e Gerenciamento de Configurao, no entanto foi identificado que algumas prticas no so implementadas e outras no so completamente implementadas.

230

5 Guia XP-CMM2

Este Captulo ir propor uma soluo, ou seja, uma forma de atender o CMM, para cada prtica classificada como no satisfeita ou parcialmente satisfeita pelo Diagnstico XP-CMM2. A organizao do Captulo descrita abaixo: Seo 5.1 A Abordagem Utilizada: descreve a abordagem utilizada para a seleo das solues propostas; Seo 5.2 Soluo para a KPA Gerenciamento de Requisitos: descreve as solues selecionadas para as prticas classificadas como no satisfeita ou parcialmente satisfeita pelo Diagnstico XP-CMM2 para a KPA Gerenciamento de Requisitos; Seo 5.3 Soluo para a KPA Planejamento de Projetos de Software: descreve as solues selecionadas para as prticas classificadas como no satisfeita ou parcialmente satisfeita pelo Diagnstico XP-CMM2 para a KPA Planejamento de Projetos de Software; Seo 5.4 Soluo para a KPA Acompanhamento de Projetos de Software: descreve as solues selecionadas para as prticas classificadas como no satisfeita ou parcialmente satisfeita pelo Diagnstico XP-CMM2 para a KPA Acompanhamento de Projetos de Software; Seo 5.5 Soluo para a KPA Garantia da Qualidade de Software: descreve a soluo selecionada para a KPA Garantia da Qualidade de Software; Seo 5.6 Soluo para a KPA Gerenciamento de Configurao de Software: descreve as solues selecionadas para as prticas classificadas como no satisfeita ou parcialmente satisfeita pelo Diagnstico XP-CMM2 para a KPA Gerenciamento de Configurao de Software; 231

Seo 5.7 Viso Geral da Soluo: apresenta um breve resumo da soluo por KPA;

Seo 5.8 Anlise da Soluo: analisa o impacto da soluo proposta na metodologia XP.

5.1 A Abordagem Utilizada

Para cada problema identificado no Diagnstico XP-CMM2, ser proposta aqui uma soluo. As solues propostas utilizaram como base os seguintes fundamentos: Atender s prticas Todas as prticas do nvel 2 de maturidade do CMM devero ser satisfeitas. Vale ressaltar mais uma vez que possvel alcanar um nvel de maturidade sem implementar rigorosamente todas as prticas relacionadas (para mais detalhes, consultar o Captulo 2). Apesar disto, o fato de atender a todas as prticas de um nvel, traz mais segurana em atingir o nvel desejado e diminui a quantidade de julgamento em uma avaliao oficial; Estar alinhada cultura XP As solues devero estar alinhadas filosofia XP, de forma a no descaracteriz-la e a realizar o menor impacto possvel na metodologia. Aspectos sero inseridos em XP para contemplar todas as prticas do nvel 2 do CMM, no entanto, isto dever ser feito de forma que a metodologia continue sendo XP. Os valores e princpios de XP sero levados como base para apontar uma soluo para os problemas; Ser genrica Este trabalho no tem como objetivo definir uma nova metodologia, mas propor uma Guia de Uso. Assim, para utilizar XP numa organizao nvel 2 do CMM, o interessado poder utilizar o Guia XP-CMM2 para identificar o que necessrio complementar em XP. Este trabalho prope solues visando facilitar o uso de XP por organizaes nvel 2, mas estas solues so genricas para que sejam adotadas de acordo com a cultura e estilo das organizaes. Templates, ferramentas e mtodos podero ser sugeridos no intuito de contribuir e facilitar a utilizao do guia;

232

Utilizar as boas prticas da engenharia de software amplamente difundidas [40], [14]. Este trabalho ir propor uma soluo para cada problema, mas vrias outras

alternativas poderiam ser adotadas. Assim como o CMM e XP requerem bom senso ao serem aplicados, se uma organizao desejar adotar a soluo proposta por este trabalho, dever avaliar a aderncia sua cultura e necessidades. Alm de apontar solues para os problemas identificados no diagnstico, este trabalho inclui aspectos visando enriquecer e facilitar o uso do Guia, como templates e ferramentas. Apesar disto, este trabalho no inclui os procedimentos documentados requeridos pelo CMM nvel 2 para algumas prticas. O motivo disto que um procedimento documentado deve ser elaborado de acordo com cultura e diretrizes das organizaes. Estas devero adaptar as diretrizes de XP e sugestes do Guia XP-CMM2 visando atender suas necessidades. Algumas sugestes podero impactar o Diagnstico XP-CMM2 realizado. Assim, este trabalho poder se tornar um pouco mais amplo que sugerir solues apenas para os problemas detectados pelo diagnstico.

5.2 Soluo para a KPA Gerenciamento de Requisitos

Para cada problema identificado pelo Diagnstico XP-CMM2 em relao KPA Gerenciamento de Requisitos uma soluo ser proposta.

5.2.1 RM.Ac2
Prtica Atividade 2 Descrio O grupo de engenharia de software usa os requisitos alocados como base para planos de software, produtos de trabalho e atividades Diagnstico Satisfaz Parcialmente Problema XP utiliza as estrias para guiar o andamento do projeto, mas no menciona a documentao e uso dos requisitos no tcnicos e o controle das verses dos requisitos documentados.

Soluo. Para atender completamente esta prtica, necessrio:

233

Documentar todos os requisitos do projeto, incluindo requisitos no tcnicos, tcnicos funcionais e no funcionais e critrios de aceitao;

Controlar a verso dos requisitos. O Plano do Projeto dever conter uma breve descrio do escopo do projeto,

incluindo requisitos tcnicos, no tcnicos e critrios de aceitao. Este Plano dever ser criado especialmente para atender a prtica SPP.AC7. Este trabalho sugere um template para Plano do Projeto (Erro! Fonte de referncia no encontrada.). Os requisitos sero detalhados em estrias, conforme sugere XP, em um documento chamado Documento de Requisitos. Este Documento de Requisitos conter as estrias agrupadas por release (o Plano de Release de XP). Para os releases ainda no planejados, o detalhamento das estrias dever estar alinhado ao detalhamento do Big Plan sugerido por XP, ou seja, os requisitos estaro documentados num nvel macro, sem muitos detalhes. As mudanas aos requisitos sero gerenciadas neste nvel. Segundo Beck et al, a forma mais simples de registrar um plano de release em um computador em uma planilha simples [24]. Este trabalho sugere um Template do Documento de Requisitos (Apndice C). O Plano do Projeto dever apontar para o Documento de Requisitos. Os motivos para separar os documentos Plano do Projeto e Documento de Requisitos so: O Plano do Projeto possui informaes gerais pertinentes a todo o projeto, enquanto o Documento de Requisitos foca nos requisitos do produto; O Documento de Requisitos ser utilizado primordialmente para o planejamento e acompanhamento dos releases e iteraes, enquanto o Plano do Projeto como documento base para acompanhamento do projeto como um todo; O Plano do Projeto e o Documento de Requisitos podero possuir distintos controle das mudanas; O Documento de Requisitos poder ser extenso, de acordo com o produto a ser desenvolvido. Um documento a parte torna o acesso descrio do produto mais usual pela equipe.

234

O CMM sugere que os requisitos sejam gerenciados e controlados, ou seja, que a verso dos requisitos em um dado momento conhecida (controle de verso), e que mudanas so incorporadas de uma maneira controlada (controle de mudanas). Isto mais simples do que colocar sob gerncia de configurao, pois a gerncia de configurao envolve, entre outras coisas, entrada em baselines e controle formal das mudanas. Para controlar a verso dos requisitos, este trabalho sugere diferentes abordagens para os documentos citados: Plano do Projeto: fazer parte de um repositrio de uma ferramenta de controle de verso adotada pelo projeto. As alteraes realizadas ao Plano devem ser descritas na ferramenta; Documento de Requisitos: estar sob gerncia de configurao. O maior rigor sobre o Documento de Requisitos se deve ao fato de que a grande maioria das mudanas a este documento impactam diretamente o trabalho de toda a equipe. Desta forma, estas mudanas devem ser realizadas de forma controlada e serem comunicadas.

5.2.2 RM.Ac3
Prtica Atividade 3 de software Diagnstico Satisfaz Parcialmente Problema Apesar de a equipe revisar as mudanas antes de incorpor-las, esta reviso no inclui a alta gerncia, os grupos afetados e no so documentadas de forma a manter um histrico das mudanas. Descrio Mudanas aos requisitos alocados so revisadas e incorporadas ao projeto

Soluo. O Plano do Projeto e o Documento de Requisitos devero ser revisados/aprovados pela alta gerncia da organizao (gerncia snior), representantes dos grupos afetados, se houverem, e representantes do cliente. Como j mencionado, mudanas ao Plano do Projeto devero ser realizadas pelo Gerente do Projeto e documentadas na ferramenta de controle de verso que o plano estar submetido. Mudanas crticas, devero ser submetidas nova reviso/aprovao da 235

gerncia snior da organizao, representantes dos grupos afetados, se houverem, e representantes do cliente. O Plano do Projeto dever conter critrios para determinar o que considerada uma mudana crtica. Exemplos de critrios so: mudanas que impactem o Documento de Requisitos, variao de custo e cronograma em mais ou menos um percentual definido. Como o Documento de Requisitos estar sob gerncia de configurao, as mudanas devem seguir o rigor do processo de gerncia de configurao estabelecido. Assim, solicitaes formais de mudana devem ser registradas, revisadas, aprovadas, e acompanhadas.

5.2.3 Sumrio do Guia para Implementao da KPA

A Tabela 5-1 relaciona resumidamente os problemas identificados pelo Diagnstico XP-CMM2 e respectiva soluo sugerida pelo Guia XP-CMM2 para a KPA Gerenciamento de Requisitos.
Prtica Atividade 2 Problema XP utiliza as estrias para guiar o andamento do projeto, mas no menciona a documentao e uso dos requisitos no tcnicos e o controle das verses dos requisitos documentados. Soluo Requisitos tcnicos e no tcnicos devero ser documentados no Plano do Projeto e o detalhamento funcional no Documento de Requisitos. O Documento de Requisitos dever estar sob gerncia de configurao. O Plano do Projeto dever estar num repositrio em uma ferramenta de controle de verso. Mudanas devem ser documentadas nesta ferramenta. Atividade 3 Mudanas aos requisitos so revisadas com a equipe, no entanto, mudanas aos compromissos estabelecidos com O Plano do Projeto e o Documento de Requisitos devero ser revisados/aprovados pelos responsveis.

236

grupos externos organizao no so levadas gerncia snior.

Mudanas aos requisitos documentados no Plano do Projeto devero gerar atualizaes no Plano, realizadas pelo gerente do projeto. Quando crticas, estas mudanas levaro o Plano aprovao pela gerncia snior.

Mudanas aos requisitos documentados no Documento de Requisitos devero seguir o sistema de gerncia de configurao instalado.

Tabela 5-1 - Sumrio do Guia para Implementao da KPA RM

5.3 Soluo para a KPA Planejamento de Projetos de Software

Para cada problema identificado pelo Diagnstico XP-CMM2 em relao KPA Planejamento de Projeto de Software uma soluo ser proposta.

5.3.1 SPP.Ac4
Prtica Atividade 4 Descrio Compromissos do projeto de software feitos para indivduos e grupos externos organizao so revisados com a gerncia snior de acordo com um procedimento documentado Diagnstico No Satisfaz Problema XP no define o relacionamento entre a gerncia snior e o projeto.

Soluo. Os compromissos externos organizao e ao projeto (compromissos com outros grupos da organizao) devero estar documentados no Plano do Projeto, o qual dever ser revisado e aprovado pela gerncia snior, como j citado.

5.3.2 SPP.Ac6
Prtica Descrio

237

Atividade 6

O plano de desenvolvimento do projeto de software desenvolvido de acordo com um procedimento documentado

Diagnstico Satisfaz Parcialmente

Problema A descrio de XP deve ser considerada um procedimento documentado para o planejamento do projeto, no entanto, ela no aborda aspectos importantes do planejamento, como: planejamento a partir de padres estabelecidos, envolvimento dos grupos afetados, reviso do plano por parte de grupos afetados e cliente, gerenciamento e controle dos planos.

Soluo. De acordo com a soluo j citada, o Plano do Projeto dever descrever compromissos com grupos afetados externos ao projeto, dever ser aprovado pela gerncia snior e representantes destes grupos e dever fazer parte de um repositrio de controle de verso, onde ser gerenciado e controlado. Alm disto, o Plano do Projeto dever descrever os padres adotados para o projeto.

5.3.3 SPP.Ac7
Prtica Atividade 7 Diagnstico Satisfaz Parcialmente Descrio O plano para o projeto de software documentado Problema Os trs planos definidos por XP no contemplam todas as informaes importantes e esperadas pelo CMM como propsito, escopo, metas e objetivos do projeto de software, procedimentos, mtodos e padres para desenvolvimento e/ou manuteno do software, entre outros.

Soluo. Este trabalho sugere que os documentos Plano do Projeto e Documento de Requisitos substituam os planos Big Plan e Plano de Release. O Plano do Projeto dever conter informaes sobre todo o projeto, conforme sugerido pelo CMM. Exemplos destas informaes so: propsito; meta e objetivos do projeto; ciclo de vida utilizado (o ciclo definido por XP), procedimentos, padres e mtodos a serem adotados para o projeto; estimativas de custo; riscos; planejamento das instalaes; equipe; recursos crticos computacionais; compromissos com grupos externos; requisitos no tcnicos e critrios de aceitao de requisitos; referncia para o Documento de Requisitos.

238

O Documento de Requisitos dever conter o Plano de Releases. Inicialmente conter as informaes do Big Plan: breve descrio das estrias e estimativas preliminares. medida que o projeto progride, conter o detalhamento do prximo release: estrias mais detalhadas e estimativas mais confiveis.

5.3.4 SPP.Ac9
Prtica Atividade 9 Descrio Estimativas para o tamanho dos produtos de trabalho de software (ou mudanas aos tamanhos dos produtos de trabalho de software) so derivados de acordo com um procedimento documentado Diagnstico No Satisfaz Problema XP no contempla estimativa de tamanho dos produtos de trabalho.

Soluo. XP no realiza estimativas de tamanho, mas de esforo para as tarefas e estrias, no entanto, a forma como XP estruturada facilita a eficcia das estimativas e seu aprimoramento. Como tarefas so unidades de estrias que devem caber em uma iterao, elas tm uma durao, no pior caso, de no mximo a durao da iterao. Como as iteraes devem durar de duas a trs semanas, esta a durao mxima de uma tarefa. Se a estimativa no couber neste prazo, a estria deve ser quebrada em outras estrias. Desta forma, projetos XP sempre estimam unidades pequenas de atividades. Paulk afirma em [33] que no nvel de iteraes de duas semanas, estas estimativas so tipicamente exatas. Alm disto, o responsvel por realizar a tarefa responsvel por estim-la. O que, provavelmente, contribui para o acerto das prximas estimativas. Um outro fator de XP que contribui bastante na melhoria das estimativas que os projetos so divididos em unidades muito pequenas de trabalho: as iteraes. A cada iterao completada, dados histricos e experincia so acumulados para apoiar as estimativas futuras. Paulk, em [33], afirma que para pequenos projetos, esforo e cronograma podem ser estimados diretamente do work breakdown structure, e as conseqncias de o projeto falhar sero relativamente menores. Esta afirmao ocorre num projeto XP, onde esforo estimado diretamente a partir da lista de tarefas identificadas. Por tudo isto, apesar de XP no atender a prtica SPP.Ac9, este trabalho no ir sugerir nenhuma alterao quanto ao problema da no realizao de estimativa de 239

tamanho. Em uma avaliao oficial, esta prtica deveria ser considerada como Prtica Alternativa.

5.3.5 SPP.Ac10
Prtica Atividade 10 Descrio Estimativas para esforo e custo do projeto de software so derivadas de acordo com procedimento documentado Diagnstico Satisfaz Parcialmente Problema XP define como estimar esforo, mas no relaciona estas estimativas com as estimativas de tamanho. Alm disto, no define de forma satisfatria como estimar custos.

Soluo. Um dos problemas identificados nesta prtica foi o de XP no associar as estimativas de esforo s estimativas de tamanho. Este trabalho sugere adotar o procedimento de XP na ntegra, mesmo que no estimando tamanho como requerido pela prtica SPP.Ac9. Desta forma, este trabalho tambm no ir propor uma soluo para o problema da falta de relao entre as estimativas de tamanho e esforo. Para a estimativa de custo, este trabalho sugere que uma planilha simples seja utilizada para estimar os custos relacionados a categorias como: treinamentos, pessoal, instalaes, viagens, consultoria.

5.3.6 SPP.Ac11
Prtica Atividade 11 Descrio Estimativas para os recursos computacionais crticos do projeto so derivadas de acordo com um procedimento documentado Diagnstico No Satisfaz crticos. Problema XP no aborda a questo de planejar e estimar os recursos computacionais

Soluo. O Plano do Projeto dever possuir uma seo para identificao e estimativa dos recursos crticos computacionais. Como a estimativa de recurso crtico computacional bastante dependente do tipo de recurso crtico e este do projeto, este trabalho tambm sugere que o prprio Plano do Projeto descreva ou faa referncia ao procedimento utilizado para estimar o recurso crtico. 240

5.3.7 SPP.Ac13
Prtica Atividade 13 Descrio Os riscos de software associados com custo, recursos, cronograma e aspectos tcnicos do projeto so identificados, avaliados e documentados Diagnstico No Satisfaz Problema XP no aborda a questo de riscos do projeto de software.

Soluo. Riscos do projeto devero ser identificados, priorizados e planos de contingncia devero ser elaborados para cada risco identificado. Este trabalho sugere que tudo isto seja feito no prprio Plano do Projeto para que os grupos afetados sejam informados a respeito.

5.3.8 SPP.Ac14
Prtica Atividade 14 Descrio Planos para as instalaes e ferramentas de apoio para a engenharia de software do projeto so preparados Diagnstico No Satisfaz do projeto de software. Problema XP no contempla planos explcitos para as instalaes e ferramentas de apoio

Soluo. O Plano do Projeto dever conter sees para planejamento das instalaes.

5.3.9 SPP.Ac15
Prtica Atividade 15 Diagnstico Satisfaz Parcialmente Descrio Dados do planejamento de software so registrados Problema XP armazena os dados de estimativas e premissas associados nos prprios cartes de estrias e tarefas, no entanto, no menciona o controle das verses dos produtos de trabalho associados ao planejamento.

Soluo. Como j citado, o Plano do Projeto dever estar num repositrio de uma ferramenta de controle de verso e mudanas a ele devero ser registradas. As estimativas das estrias estaro registradas no Documento de Requisitos, que estar sob gerncia de configurao. 241

5.3.10 Sumrio do Guia para Implementao da KPA

A Tabela 5-2 relaciona resumidamente os problemas identificados pelo Diagnstico XP-CMM2 e respectiva soluo sugerida pelo Guia XP-CMM2 para a KPA Planejamento de Projeto de Software.
Prtica Atividade 4 Problema XP no define o relacionamento entre a gerncia snior e o projeto. Soluo Como j citado, os compromissos externos devero estar documentados no Plano do Projeto, o qual dever ser revisado e aprovado pela gerncia snior. Atividade 6 XP no aborda aspectos importantes do planejamento, como: planejamento a partir de padres estabelecidos, envolvimento dos grupos afetados, reviso do plano por parte de grupos afetados e cliente, gerenciamento e controle dos planos. Atividade 7 Os trs planos definidos por XP no contemplam todas as informaes importantes e esperadas pelo CMM. O Plano do Projeto e Documento de Requisitos substituiro os planos Big Plan e Plano de Release. O Plano do Projeto dever conter informaes sobre todo o projeto, conforme sugerido pelo CMM.

Como j citado, o Plano do

Projeto dever descrever padres adotados, compromissos com grupos externos afetados, dever ser aprovado pela gerncia snior e representantes destes grupos e dever fazer parte de um repositrio de controle de verso.

O Documento de Requisitos
dever conter o Plano de Releases. Atividade 9 XP no contempla estimativa de tamanho dos produtos de trabalho. Este trabalho no ir sugerir nenhuma alterao quanto ao problema da no realizao de

242

estimativa de tamanho. Em uma avaliao oficial, esta prtica deveria ser considerada como Prtica Alternativa. Atividade 10 XP no relaciona as estimativas de esforo e custo com as estimativas de tamanho. Como este trabalho no ir sugerir realizao de estimativa de tamanho, a estimativa de esforo no poder ser relacionada de tamanho. Assim, este trabalho no prope soluo para este problema. Os custos devero ser estimados em categorias e registrados em planilhas. Atividade 11 XP no aborda a questo de planejar e estimar os recursos computacionais crticos.

O Plano do Projeto dever possuir

uma seo para identificao, procedimento de estimativa e estimativa realizada para os recursos crticos computacionais.

Atividade 13

XP no aborda a questo de riscos do projeto de software.

O Plano do Projeto dever relacionar os riscos do projeto, priorizados e respectivos planos de contingncia.

Atividade 14

XP no contempla planos explcitos para as instalaes e ferramentas de apoio do projeto de software.

O Plano do Projeto dever conter sees para planejamento das instalaes.

Atividade 15

XP armazena os dados de estimativas e premissas associados nos prprios cartes de estrias e tarefas, no entanto, no

Como j citado, o Plano do Projeto dever estar num repositrio de uma ferramenta de controle de verso e mudanas a

243

menciona o controle das verses dos produtos de trabalho associados ao planejamento.

ele devero ser registradas. As estimativas das estrias estaro registradas no Documento de Requisitos, que estar sob gerncia de configurao.

Tabela 5-2 - Sumrio do Guia para Implementao da KPA SPP

5.4 Soluo para a KPA Acompanhamento de Projetos de Software

Para cada problema identificado pelo Diagnstico XP-CMM2 em relao KPA Acompanhamento de Projeto de Software uma soluo ser proposta.

5.4.1 SPTO.Ac3
Prtica Atividade 3 Descrio Compromissos e mudanas aos compromissos do projeto de software feitos a indivduos e grupos externos organizao so revisados com a gerncia snior de acordo com um procedimento documentado Diagnstico No Satisfaz Problema XP no define o relacionamento entre a gerncia snior e o projeto.

Soluo. Como j citado, os compromissos externos devero estar documentados no Plano do Projeto, que ao sofrer alteraes crticas, passar a ser novamente revisado/aprovado pela gerncia snior da organizao. Novamente, importante que o Plano defina critrios para definir o que mudana crtica. Alm disto, este trabalho sugere que o Plano do Projeto e Documento de Requisitos sejam atualizados e novamente revisados/aprovados durante a reunio e planejamento do release, pois o planejamento do prximo release ir ocasionar mudanas no Documento de Requisitos (detalhamento das estrias e estimativas do prximo release) e poder gerar mudanas no Plano do Projeto, como a identificao de novos riscos, novos compromissos externos, mudanas em cronograma (data do prximo release) e outros.

244

5.4.2 SPTO.Ac5
Prtica Atividade 5 Descrio Os tamanhos dos produtos de trabalho de software (ou tamanhos das mudanas aos produtos de trabalho de software) so acompanhadas, e aes corretivas so tomadas quando necessrio Diagnstico No Satisfaz acompanhamento. Problema XP no aborda estimativa de tamanho de produto de trabalho, to pouco seu

Soluo. Como este trabalho sugere no estimar tamanho (prtica SPP.Ac9), esta prtica torna-se no aplicvel, j que no possvel acompanhar uma estimativa que no realizada.

5.4.3 SPTO.Ac6
Prtica Atividade 6 Descrio Esforo e custo de software do projeto so acompanhados, e aes corretivas so tomadas quando necessrio. Diagnstico Satisfaz Parcialmente Problema Apesar de acompanhar esforo e promover a tomada de ao corretiva, XP no menciona o acompanhamento de custos.

Soluo. Apesar de o CMM no requerer acompanhamento peridico, este trabalho sugere que os custos sejam acompanhados periodicamente, ao final de cada iterao, por categoria (pessoal, viagens, treinamentos e outros) e que este acompanhamento seja registrado.

5.4.4 SPTO.Ac7
Prtica Atividade 7 Descrio Recursos computacionais crticos do projeto so acompanhados e aes corretivas so tomadas quando necessrio Diagnstico No Satisfaz recursos crticos computacionais. Problema XP no aborda de forma explcita o planejamento e acompanhamento de

245

Soluo. O gerente do projeto dever acompanhar os recursos crticos computacionais estimados e atualizar a seo no Documento de Requisitos, pois este documento contm as estimativas do projeto e respectivo acompanhamento. Como as iteraes so curtas, este trabalho sugere que esta atividade seja feita ao final de cada iterao, no entanto, de acordo com a criticidade do recurso crtico, este intervalo pode ser menor. Vale ressaltar, que no necessrio que o acompanhamento seja peridico, apesar de que faz-lo periodicamente contribui na institucionalizao.

5.4.5 SPTO.Ac10
Prtica Atividade 10 Descrio Os riscos de software associados a custo, recursos, cronograma e aspectos tcnicos do projeto so acompanhados Diagnstico No Satisfaz Problema XP no aborda a identificao e acompanhamento dos riscos do projeto.

Soluo. O gerente do projeto dever acompanhar os riscos e atualizar a seo de riscos do Plano do Projeto. Este trabalho sugere que esta atividade seja feita na reunio de planejamento da prxima iterao e release e sempre que um novo risco surgir e uma situao que modifique o status dos riscos identificados ocorra. O fato de os riscos serem tratados na reunio de planejamento da iterao contribui para que toda a equipe se envolva no gerenciamento de riscos: identificando novos riscos, formas de contingenci-los e informando o status.

5.4.6 SPTO.Ac11
Prtica Atividade 11 software so registrados Diagnstico Satisfaz Parcialmente Problema XP armazena os dados de estimativas e premissas associados nos prprios cartes de estrias e tarefas, no entanto, no menciona o controle das verses dos produtos de trabalho associados a replanejamento. Descrio Dados de medida e dados de replanejamento reais para o projeto de

Soluo. Este problema possui a mesma soluo empregada para SPP.Ac15.

246

5.4.7 SPTO.Ac13
Prtica Atividade 13 Descrio Revises formais para enderear realizaes e resultados do projeto de software so conduzidas nos marcos selecionados do projeto de acordo com procedimento documentado Diagnstico Satisfaz Parcialmente Problema As reunies de planejamento de release ocorrem em pontos significativos do projeto, contam com a participao de cliente e equipe, relaciona planos, mas no aborda riscos do projeto.

Soluo. Como o Plano do Projeto ser revisado/aprovado durante a reunio de planejamento do release e ele contempla os riscos do projeto, ento os riscos sero revisados nas revises formais, no caso, as reunies de planejamento do prximo release.

5.4.8 Sumrio do Guia para Implementao da KPA

A Tabela 5-3 relaciona resumidamente os problemas identificados pelo Diagnstico XP-CMM2 e respectiva soluo sugerida pelo Guia XP-CMM2 para a KPA Acompanhamento de Projeto de Software.
Prtica Atividade 3 Problema XP no define o relacionamento entre a gerncia snior e o projeto. Soluo

Como j citado, os compromissos

externos devero estar documentados no Plano do Projeto, que ao sofrer alteraes crticas, passar a ser novamente revisado/aprovado pela gerncia snior da organizao. O Plano do Projeto e Documento de Requisitos devem ser atualizados e novamente revisados/aprovados durante a reunio e planejamento do release.

Atividade 5

XP no aborda estimativa de tamanho de produto de trabalho,

Como este trabalho sugere no estimar tamanho (prtica

247

to pouco seu acompanhamento.

SPP.Ac9), esta prtica torna-se no aplicvel.

Atividade 6

Apesar de acompanhar esforo e promover a tomada de ao corretiva, XP no menciona o acompanhamento de custos.

Este trabalho sugere que os custos sejam acompanhados periodicamente, ao final de cada iterao, por categoria e que este acompanhamento seja registrado.

Atividade 7

XP no aborda estimativa de tamanho de produto de trabalho, to pouco seu acompanhamento.

O gerente do projeto dever acompanhar os recursos crticos computacionais estimados e atualizar a seo no Plano do Projeto.

Atividade 10

XP no aborda a identificao e acompanhamento dos riscos do projeto.

O gerente do projeto dever acompanhar os riscos e atualizar a seo de riscos do Plano do Projeto.

Atividade 11

XP armazena os dados de estimativas e premissas associados nos prprios cartes de estrias e tarefas, no entanto, no menciona o controle das verses dos produtos de trabalho associados a replanejamento.

Como j citado, o Plano do

Projeto dever estar num repositrio de uma ferramenta de controle de verso e mudanas a ele devero ser registradas. As estimativas das estrias estaro registradas no Documento de Requisitos, que estar sob gerncia de configurao.

Atividade 13

As reunies de planejamento de release ocorrem em pontos significativos do projeto, contam com a participao de cliente e equipe, relaciona planos, mas no aborda riscos do projeto.

Como o Plano do Projeto ser revisado/aprovado durante a reunio de planejamento do release e ele contempla os riscos do projeto, ento os riscos sero revisados nas revises formais.

248

Tabela 5-3 - Sumrio do Guia para Implementao da KPA SPTO

5.5 Soluo para a KPA Garantia da Qualidade de Software

Segundo Paulk, um grupo independente de garantia da qualidade inpensvel na cultura de XP [33]. Reifer relata o caso de um projeto XP numa organizao nvel 3 do CMM [10]. Nesta organizao, alguns problemas emergiram entre a equipe do projeto e o grupo de garantia da qualidade, que no trabalhavam de forma cooperativa. Como concluso, Reifer afirma que ningum parecia aplicar XP dentro de um contexto SWCMM racionalmente e de forma proveitosa... e eles poderiam ter modificado o processo de garantia da qualidade para que tivesse um papel mais til no projeto, especialmente em assegurar aderncia s prticas de testes de XP. Como no h intercesso entre XP e a KPA Garantia da Qualidade de Software, este trabalho no ir sugerir implementaes para as prticas desta KPA. As organizaes devem implementar o sistema de garantia de qualidade de acordo com suas necessidades e cultura. Apesar disto, algumas consideraes sero feitas para que o sistema de garantia da qualidade definido pelas organizaes no impactem negativamente um projeto XP. Para atender as prticas da KPA, preciso montar um sistema de garantia da qualidade aderente ao CMM, com plano de garantia da qualidade, revises e/ou auditorias de processo e produto. Os processos de planejamento, acompanhamento, controle dos requisitos e gerncia de configurao devem ser verificados e os problemas levantados, corrigidos. O grupo de garantia da qualidade tambm deve atuar sobre os padres adotados pelo projeto, verificando o processo de testes e padres adotados pelo projeto. A ateno que se deve ter que um projeto XP essencialmente colaborativo e assim deve agir o grupo de garantia da qualidade. O grupo deve estar atento ao que realmente necessrio seguir num projeto XP para que a equipe do projeto no dedique esforo a corrigir problemas que no agreguem valor ao projeto. Uma sugesto para reforar esta atitude o grupo de garantia da qualidade levantar o risco associado a cada problema identificado nas auditorias e/ou revises. Paulk sugere em [33] que, para pequenos projetos e organizaes, a funo de SQA pode estar inserida no processo atravs de checklists e ferramentas, por exemplo. 249

Mesmo utilizando esta abordagem, Paulk ressalta que importante definir um mecanismo de escalao para resolver conflitos a respeito dos problemas encontrados [33]. Num projeto XP, interessante explorar esta sugesto, para que o grupo de SQA trabalhe de forma mais dedicada ao que realmente importante do ponto de vista de processo e padres e agregue mais valor ao projeto.

5.6 Soluo para a KPA Gerenciamento de Configurao de Software

Como j citado, num projeto XP, problemas ou melhorias ao software (item de configurao de um projeto XP) so identificadas, documentadas e tratadas como uma estria, registrada em cartes de papel, revisadas e aprovadas pela equipe [25]. O diagnstico considerou que esta prtica de XP atende a prtica SCM.Ac5 do CMM (Requisio de mudana e reportagem de problema para todos os itens de configurao so iniciados, registrados, revisados, aprovados e acompanhados de acordo com um procedimento documentado.). Apesar disto, esta abordagem pode acarretar em problemas devido falta de registro do histrico das mudanas ocorridas, pois elas so tratadas da mesma forma que novas estrias. Mudanas podem ocorrer, a todo o momento, por requisio do cliente (ele muda a prioridade das estrias de um release, por exemplo) ou por necessidade da equipe (quando ela no consegue, por exemplo, implementar todas as estrias de uma iterao). No h como saber em um release do projeto o porqu da no implementao de estrias acordadas inicialmente: se a responsabilidade foi da indefinio do cliente ou de ms estimativas realizadas pela equipe do projeto. Como j citado no Captulo 2, uma das crticas XP que muitas vezes no possvel contar com representantes do cliente na equipe. Outras, quando possvel, este representante no tem autoridade para determinar o escopo do sistema, selecionando o que ser e o que no ser desenvolvido. Mesmo quando h este cliente com autoridade, possvel que o resultado final de um release no atenda s expectativas do cliente porque estrias no foram implementadas e o Big Plan (a expectativa) inicial no foi cumprido. Neste caso, a falta de registro das mudanas: o porque foram realizadas, quem as

250

solicitou e quem as aprovou, por exemplo, poder comprometer a aceitao do produto final e a satisfao do cliente. Para diminuir estes riscos, este trabalho sugere o uso de uma ferramenta de controle de mudanas. Como exemplo, a ferramenta Bugzilla [46] um ferramenta freeware utilizada para reportagem de bugs que pode tambm ser usada para registro de mudanas. O objetivo que qualquer pessoa da equipe ou externa (inclusive cliente) solicite mudanas aos itens de configurao atravs da ferramenta de controle de mudanas. Estas mudanas, se aprovadas pelo SCBB, viram estrias e entram no fluxo de um projeto XP. Este SCCB, para ser o mais flexvel possvel, pode ser composto apenas pelo gerente do projeto (desde que ele seja da rea de software, para responder a questes tcnicas), pois ele quem responde pelo sucesso do projeto. Requisies de mudanas no urgentes podem ser avaliadas em conjunto com toda a equipe nas reunies de incio da iterao. importante ressaltar que solicitaes de mudana s devem ser abertas para itens de configurao nas baselines, ou seja, no que considerado estvel. Desta forma, de extrema importncia definir quando as baselines sero estabelecidas.

5.6.1 SCM.Ac1
Prtica Atividade 1 Descrio Um plano de SCM preparado para cada projeto de software de acordo com um procedimento documentado Diagnstico No Satisfaz Problema XP no menciona plano para o gerenciamento de configurao.

Soluo. Um plano de gerncia de configurao dever ser elaborado contendo: itens de configurao, critrio para selecion-los, baselines, contedo das baselines, momento de entrada dos itens de configurao nas baselines, comit que aprova as mudanas e estabelecimento das baselines, planejamento de releases, planejamento de auditorias, padres de gerncia de configurao a serem seguidos, relatrios a serem gerados. Quanto menor a equipe do projeto, mais simples poder ser este plano. Este trabalho sugere um Template para o Plano de Gerncia de Configurao (Apndice D).

251

 muito importante que este plano contemple uma gerncia de configurao simples para no quebrar a dinmica de um projeto XP. Para Beck, um dos benefcios da prtica propriedade coletiva que se algum precisa de uma mudana, ela mesma pode fazer, no precisa requisitar e esperar que o responsvel pelo produto realize a alterao necessria [25], pois, segundo ele, sem a propriedade coletiva, o cdigo permanece estvel, mas no evolui rpido como deveria [25]. Por este motivo, o controle das mudanas aos itens de configurao deve ser planejado de forma a no comprometer sua evoluo.

5.6.2 SCM.Ac2
Prtica Atividade 2 Descrio Um plano de SCM documentado e aprovado utilizado como base para a realizao das atividades de SCM Diagnstico No Satisfaz Problema XP no menciona plano para o gerenciamento de configurao.

Soluo. O plano de gerncia de configurao dever ser aprovado pelo gerente do projeto. Assim como o plano do projeto, em mudanas crticas, este plano dever ser reaprovado. O plano dever descrever as mudanas que requerem reaprovao.

5.6.3 SCM.Ac3
Prtica Atividade 3 Descrio Um sistema de biblioteca de gerenciamento de configurao estabelecido como um repositrio para as baselines de software Diagnstico No Satisfaz configurao. Problema XP no menciona o estabelecimento de um sistema de gerenciamento da

Soluo. Esta prtica facilmente atendida quando adotada uma ferramenta de controle de verso. Ao selecionar uma ferramenta, deve-se verificar se ela atende s subprticas desta prtiva. Caso no atenda, deve-se verificar a possibilidade de adotar uma outra ferramenta ou elaborar scripts para complement-la. Uma sugesto o CVS [49], que uma ferramenta freeware, largamente utilizada mundo afora. 252

5.6.4 SCM.Ac4
Prtica Atividade 4 configurao so identificados Diagnstico Satisfaz Parcialmente subprticas no so atendidas. Problema Se o projeto possuir outros itens de configurao alm de cdigo, vrias das Descrio Os produtos de trabalho de software a serem colocados sob gerncia de

Soluo. O plano de gerncia de configurao dever listar os itens de configurao do projeto. De acordo com a proposta deste trabalho minimamente o cdigo e o Documento de Requisitos devero ser itens de configurao. Critrios sugeridos para identificar os itens de configurao do projeto so [3]: Produtos entregues ao cliente ou a outra organizao; Produtos considerados crticos para o projeto; Artefatos utilizados por mais de um grupo; Artefatos produzidos por terceiros, que sero incorporados ao projeto; Artefatos que, ao serem alterados, podem causar mudanas em outros artefatos associados.

5.6.5 SCM.Ac8
Prtica Atividade 8 um procedimento documentado Diagnstico No Satisfaz Problema XP no menciona o registro do status dos itens de configurao. Descrio O status dos itens/unidades de configurao registrado de acordo com

Soluo. As mudanas aos itens de configurao devero ser registradas na ferramenta de controle de verso adotada sempre que o item for submetido ao sistema de biblioteca de gerncia de configurao. Os projetos podero estabelecer padres para estes registros no Plano de Gerncia de Configurao.

253

5.6.6 SCM.Ac9
Prtica Atividade 9 Descrio Relatrios padres documentando as atividades e SCM e contedo das baselines so desenvolvidos e tornados disponveis para os grupos e indivduos afetados Diagnstico No Satisfaz Problema XP no menciona o uso de relatrios de gerncia de configurao e disponibilizao aos grupos afetados.

Soluo. Com a utilizao de ferramentas, facilmente so obtidos relatrios de gerncia de configurao. As seguintes informaes, sugeridas pelo CMM, podem ser coletadas a partir da implementao do Guia XP-CMM2: Solicitaes de mudana e respectivos status obtidos a partir de consultas ferramenta de controle de mudana adotada; Mudanas as baselines obtidas a partir de consultas ferramenta de controle de mudana adotada; Histrico de alterao dos itens de configurao obtido a partir de consultas ferramenta de controle de verso adotada; Status da baseline o contedo das baselines pode ser obtido a partir de consultas ferramenta de controle de verso adotada; Relatrios de auditoria nas baselines a serem gerados pelo gerente de configurao do projeto (ver Seo 5.6.7). Mesmo ferramentas simples de controle de verso e mudanas oferecem consultas como as citadas.

5.6.7 SCM.Ac10
Prtica Atividade 10 procedimento documentado Diagnstico No Satisfaz Problema XP no menciona auditorias nas baselines de software. Descrio Auditorias nas baselines de software so conduzidas de acordo com um

254

Soluo. Segundo o CMM, estas auditorias tipicamente checam: a integridade das baselines, estrutura e instalaes do sistema de biblioteca de gerncia de configurao, conformidade aos padres e outros. Estas auditorias podem ser automatizadas facilmente, de acordo com as ferramentas e padres de gerncia de configurao adotados. Este trabalho sugere a criao de scripts para realizao das auditorias, com gerao automtica de relatrios descrevendo os problemas. Estes relatrios devero ser enviados para toda a equipe. O gerente de configurao, gerente do projeto ou grupo de garantia da qualidade poder ser responsvel por acompanhar a resoluo dos problemas.

5.6.8 Sumrio do Guia para Implementao da KPA

A Tabela 5-4 relaciona resumidamente os problemas identificados pelo Diagnstico XP-CMM2 e respectiva soluo sugerida pelo Guia XP-CMM2 para a KPA Gerenciamento de Configurao de Software. Alm destes itens, este trabalho sugere a adoo de uma ferramenta de controle de mudana, registro e avaliao formal das solicitaes de mudanas s baselines do projeto.
Prtica Atividade 1 Problema XP no menciona plano para o gerenciamento de configurao. Soluo Um plano de gerncia de configurao dever ser elaborado. Atividade 2 XP no menciona plano para o gerenciamento de configurao. O plano de gerncia de configurao dever ser aprovado pelo gerente do projeto. Atividade 3 XP no menciona o estabelecimento de um sistema de gerenciamento da configurao. Atividade 4 Se o projeto possuir outros itens de configurao alm de cdigo, vrias das subprticas no so atendidas. O plano de gerncia de configurao dever listar os itens de configurao do projeto e o critrio utilizado para selecionlos. Adotar ferramenta de controle de verso.

255

Atividade 8

XP no menciona o registro do status dos itens de configurao.

As mudanas aos itens de configurao devero ser registradas na ferramenta de controle de verso adotada.

Atividade 9

XP no menciona o uso de relatrios de gerncia de configurao e disponibilizao aos grupos afetados.

Relatrios sero obtidos a partir das ferramentas adotadas para gerncia de configurao.

Atividade 10

XP no menciona auditorias nas baselines de software.

Auditorias nas baselines devero ser realizadas preferencialmente atravs de scripts e gerao automtica de relatrio.

Tabela 5-4 - Sumrio do Guia para Implementao da KPA SCM

5.7 Viso Geral da Soluo

Esta seo descreve resumidamente o tratamento a cada KPA contemplando todas as sugestes propostas pelo Guia XP-CMM2.

5.7.1 Planejamento de Projeto de Software

Um projeto XP dever elaborar dois documentos em seu incio: o Plano do Projeto e o Documento de Requisitos, que devero ser refinados no decorrer do projeto. O Plano do Projeto dever contemplar: propsito; meta e objetivos do projeto; ciclo de vida utilizado (o ciclo definido por XP), procedimentos, padres e mtodos a serem adotados para o projeto; estimativas de custo; riscos; planejamento das instalaes; equipe; recursos crticos computacionais e procedimento para estim-los; compromissos com grupos externos organizao e ao projeto; requisitos tcnicos e no tcnicos e critrios de aceitao de requisitos; referncia para o Documento de Requisitos. O Plano do Projeto dever ser elaborado pelo Gerente do Projeto e submetido reviso e aprovao do gerente snior da organizao, representantes de grupos externos ao projeto afetados pelo projeto e representantes do cliente. A reviso/aprovao um mecanismo para promover o acordo entre as partes envolvidas, os compromissos firmados. 256

O Documento de Requisitos contemplar, inicialmente, os requisitos no funcionais (estrias) e o contedo do Big Plan: breve descrio das estrias e estimativas preliminares. Aps a reunio de planejamento de cada release, este documento ser refinado com as informaes da reunio. O planejamento do release continuar a ser conduzido como descrito por XP, iniciando com a reunio de planejamento de release, onde se seleciona as estrias do prximo release e as estima. As estrias podero ser documentadas em cartes de papel como sugere XP, no entanto, ao final da reunio, o Documento de Requisitos dever ser atualizado com o resultado do planejamento: as estrias do release e suas estimativas. Os cartes de estrias devero ser descartados para no gerar inconsistncias com o Documento de Requisitos. O plano do release no mais o conjunto de cartes, mas o Documento de Requisitos. O Documento de Requisitos tambm dever ser submetido reviso e aprovao do gerente snior da organizao, representantes de grupos externos ao projeto afetados pelo projeto e representantes do cliente, junto com o Plano do Projeto. Esta proposta segue a linha XP de no criar um planejamento detalhado para todo o projeto em seu incio. A reunio de planejamento da iterao no necessitou de nenhum ajuste. Os requisitos identificados/documentados nesta reunio continuam sendo tratados exatamente como descrito por XP, pois so bastante detalhados e focados na engenharia do produto. As mudanas s tarefas e estrias que no afetarem o Plano de Release (o Documento de Requisitos) seguem o fluxo definido por XP. Apesar de que, este trabalho sugere que as tarefas sejam registradas em meio digital para facilitar registro de dados histricos para outros projetos, acompanhamento mais fcil das estimativas das tarefas, segurana da informao atravs de backups. Este registro pode ser to simples como o registro do plano de release em planilhas.

5.7.2 Gerenciamento da Configurao de Software

O projeto dever planejar como se dar a gerncia de configurao no projeto, identificado itens de configurao, baselines, SCCBs, entre outros em um Plano de Gerncia de Configurao.

257

Ferramentas de controle de verso e de mudanas devero ser adotadas pelo projeto para facilitar a gerncia de configurao. Informaes sobre as mudanas e verses dos itens de configurao devero ser registradas nas ferramentas adotadas. Auditorias devero ser realizadas periodicamente, preferencialmente atravs de scripts automatizados. O Documento de Requisitos dever ser um item de configurao do projeto. O Plano do Projeto no ser um item de configurao do projeto, mas dever estar na ferramenta de controle de verso adotada para o projeto e todas as alteraes realizadas sobre eles devero ser registradas na prpria ferramenta.

5.7.3 Garantia da Qualidade de Software

Um sistema de garantia da qualidade dever ser definido e implantado num projeto XP.

5.7.4 Acompanhamento de Projeto de Software

O Plano do Projeto e o Documento de Requisitos devero ser revisados ao final de cada release e incio de planejamento do prximo release pela gerncia snior, representantes do cliente e grupos afetados. Alm disto, o Plano dever conter critrios para determinar quando mudanas realizadas antes do fim de um release precisam ser revisadas. Recursos crticos computacionais e riscos devero ser acompanhados pelo gerente do projeto e este acompanhamento registrado no Documento de Requisitos e Plano do Projeto respectivamente. Os riscos devero ser tratados com toda a equipe na reunio de planejamento da iterao e de release. Sugere-se que o acompanhamento dos recursos crticos computacionais seja feito ao final de cada iterao. Custos devero ser acompanhados e este acompanhamento registrado.

5.7.5 Gerenciamento de Requisitos

Para realizar mudanas como: Incluir/remover uma estria no projeto ou em um release; alterar a data de release; incluir/remover requisitos no funcionais.

258

Ser preciso abrir uma solicitao de mudana na ferramenta de controle de mudana. Esta solicitao dever ser aprovada pelo SCCB do projeto, documentado no Plano de Gerncia de Configurao. Esta avaliao do SCCB dever ser realizada, preferencialmente (caso a solicitao de mudana no seja urgente) na reunio de planejamento da iterao. Caso a mudana seja aprovada, o Documento de Requisitos dever ser alterado e a mudana gerar uma estria como outra qualquer. O controle das mudanas no tem como objetivo impedir que as mudanas ocorram, mas que elas ocorram de forma controlada, que sejam analisadas e registradas.

5.7.6 Ferramentas e Templates

O Guia XP-CMM2 sugere ferramentas e templates para apoiar a sua implantao, conforme descrito nas tabelas Tabela 5-5 e Tabela 5-6.
Ferramenta Controle de verso Controle de mudana Descrio Ferramenta para apoiar a gerncia de configurao no controle das verses. Ferramenta para apoiar a gerncia de configurao no controle das mudanas. Ferramenta freeware Bugzilla [46] Exemplo Ferramenta freeware CVS [49]

Tabela 5-5 - Ferramentas Sugeridas pelo Guia XP-CMM2

Template Plano do Projeto Documento de Requisitos Descrio Plano do projeto, descreve o planejamento macro do projeto. Descreve o planejamento de releases e registra seu acompanhamento, bem como acompanhamento de recursos crticos computacionais. Plano de Gerncia de Configurao Descreve o planejamento da configurao do projeto. Apndice D Localizao Erro! Fonte de referncia no encontrada. Apndice C

Tabela 5-6 - Templates Sugeridos pelo Guia XP-CMM2

259

5.8 Anlise da Soluo

Esta seo descrever uma anlise a respeito do impacto do Guia XP-CMM2 a XP, considerando prticas, prncipios e valores adotados pela metodologia.

5.8.1 Impacto do Guia XP-CMM2 s Prticas de XP

A soluo proposta acarreta em: Mais atividades para o gerente do projeto, como: planejar e acompanhar recursos crticos computacionais, ferramentas e instalaes, riscos e custos, elaborar um plano de projeto; Mais formalismos no gerenciamento: documentos formais e no apenas cartes de papis que podem ser perdidos e/ou rasgados. Reviso e aprovao de alguns documentos por parte dos interessados/afetados com o projeto; Maior controle: planejamento da configurao do software, controle e manuteno do histrico das mudanas, garantia da qualidade. A nica prtica de XP afetada pela soluo o Jogo do Planejamento, que define o planejamento do projeto. As outras prticas no foram afetadas e podem ser implementadas conforme definido por XP. So elas: releases pequenos, Metforas, Projeto de software simples, Teste, Refactoring, Programao em pares, Propriedade coletiva, Integrao contnua, 40 horas semanais, Cliente no local e Padro de codificao. Em relao prtica Jogo do Planejamento a sua essncia no alterada: o planejamento continua a ser orientado a pequenas entregas, detalhando-se o que ser a prxima entrega e no realizando um planejamento detalhado no incio do projeto. A esta prtica foram adicionados documentos formais (Plano do Projeto e Documento de Requisitos) e formalismo de aprovao. Apesar de parecer que esta sugesto vai de encontro filosofia de um projeto XP (que defende a informalidade e as mudanas sempre bem vindas, a qualquer momento), ela dever ser aplicada apenas ao gerenciamento de mais alto nvel do projeto, de forma que a dinmica de desenvolvimento do projeto XP no seja alterada.

260

5.8.2 Impacto do Guia XP-CMM2 aos Valores e Princpios de XP

O valor Comunicao melhorado com a reviso/aprovao de documentos formais, pois as altas gerncias da organizao e do cliente possuem informaes consolidadas a respeito do projeto. Em um projeto XP tradicional a comunicao forte dentro da equipe, mas no para os grupos afetados externos ao projeto. Os outros valores no so influenciados pelo Guia XP-CMM2. So eles [25]: Simplicidade fazer o mais simples que possa funcionar; Feedback resposta sobre o produto, satisfao, qualidade e outros fatores do projeto devem ser providos a todo o momento, rapidamente; Coragem virtude para realizar refactorings, implementar a soluo mais simples e outras aes necessrias em um projeto XP. Dentre os princpios relacionados por XP, o mais afetado o Aceitar Mudanas. Num projeto XP, mudanas so bem vindas a qualquer momento do projeto [25]. O Guia XP-CMM2 prope o controle formal das mudanas atravs de solicitaes formais registradas e avaliadas por um SCCB. O formalismo no deve ser visto como resistncia mudana, mas como controle. A qualquer momento, mudanas devem ser solicitadas, como sugere XP. No entanto, estas mudanas devem ter seu impacto avaliado e a integridade entre os produtos produzidos deve ser mantida. Isto o que sugere o Guia XP-CMM2.

5.8.3 Aderncia ao Nvel 2 do CMM

Duas prticas foram consideradas no satisfeitas pelo Diagnstico XP-CMM2, mas no tiveram solues propostas pelo Guia XP-CMM2. Ambas as prticas esto relacionadas estimativa de tamanho requerida pelo CMM, mas no sugerida pelo Guia XP-CMM2. SPP.Ac9: Estimativas para o tamanho dos produtos de trabalho de software (ou mudanas aos tamanhos dos produtos de trabalho de software) so derivados de acordo com um procedimento documentado. Esta prtica foi considerada no satisfeita, pois XP no contempla estimativa de tamanho dos produtos de trabalho e o Guia XP-CMM2 no sugere faz-la; 261

SPP.Ac10: Estimativas para esforo e custo do projeto de software so derivadas de acordo com procedimento documentado. Esta prtica foi considerada no satisfeita, pois XP define como estimar esforo, mas no relaciona estas estimativas com as estimativas de tamanho. Como o Guia XP-CMM2 no sugere estimar tamanho, este problema ficou sem soluo.

As prticas de SPP no atendidas esto relacionadas seguinte meta 1: Estimativas de software so documentadas para uso no planejamento e acompanhamento do projeto de software. Conforme sugerido pelo Guia XP-CMM2, as estimativas so documentadas no Documento de Requisitos para uso no planejamento dos releases e iteraes. Assim, esta meta considerada atingida por este trabalho, mesmo sem ter as prticas SPP.Ac9 e SPP.Ac10 completamente satisfeitas.

262

6 Aplicao do Guia XP-CMM2

O Guia XP-CMM2 foi aplicado a um projeto real de desenvolvimento e manuteno de software, com o objetivo de avaliar o impacto da soluo proposta. Esta aplicao se deu na forma de um experimento e de um estudo de caso. Experimento porque no decorrer da aplicao do Guia a um projeto, resultados foram colhidos e melhorias foram sendo adicionadas ao Guia, de forma que no final da aplicao, o Guia pde ser considerado mais maduro. Alm disto, a aplicao a um projeto deve ser vista como um estudo de caso, pois resultados e anlises foram feitas sobre a soluo proposta. Este captulo ir descrever a aplicao do Guia XP-CMM2 a um projeto real, ressaltando: Seo 6.1 Objetivos da Aplicao do Guia XP-CMM2: relaciona os objetivos de aplicar o Guia XP-CMM2 a um projeto real; Seo 6.2 O Ambiente: descreve onde o estudo foi realizado; Seo 6.3 Seleo de um Projeto para Estudo de Caso: descreve como um projeto real foi selecionado, relacionando os aspectos envolvidos para esta seleo; Seo 6.4 O Projeto Selecionado: descreve as caractersticas do projeto selecionado; Seo 6.5 A Metodologia Utilizada: descreve a abordagem utilizada para realizao deste estudo; Seo 6.6 Cronograma: descreve o cronograma real do estudo realizado; Seo 6.7 O Experimento: relata como se deu o estudo: dificuldades enfrentadas, aspectos do Guia XP-CMM2 implementados, aspectos no implementados.

263

Alm disto, o Guia XP-CMM2 foi aplicado a uma unidade de negcios, ou seja, uma empresa incubada, visando concretizao de um possvel investimento. Esta aplicao tambm descrita de forma resumida na Seo 6.8. Finalmente, a Seo Erro! Fonte de referncia no encontrada. apresenta algumas consideraes sobre o estudo realizado.

6.1 Objetivos da Aplicao do Guia XP-CMM2

A aplicao do Guia XP-CMM2 a um projeto real, tem como principais objetivos: Verificar se o Guia utilizvel no mundo real; Verificar se os benefcios declarados do uso de XP podem ser alcanados com as modificaes sugeridas pelo Guia; Verificar se possvel conviver em um mesmo ambiente com XP e com o nvel 2 do CMM; Benefcios de aplicar a abordagem do nvel 2 do CMM em um projeto XP; Verificar se um projeto XP perde a agilidade esperada se inserir prticas do CMM nvel 2; Averiguar a dificuldade em assimilar prticas do nvel 2 do CMM em um projeto com cultura XP.

6.2 O Ambiente
A aplicao do Guia XP-CMM2 foi realizada no C.E.S.A.R Centro de Estudos e Sistemas Avanados do Recife. O C.E.S.A.R uma organizao sem fins lucrativos, associada Universidade Federal de Pernambuco, que tem como misso a transferncia auto sustentada de tecnologia entre a universidade e a sociedade. Para cumprir sua misso o C.E.S.A.R desenvolve projetos de software e cria empresas. O C.E.S.A.R possui um processo padro para desenvolvimento e manuteno de software, chamado ProSCes, que foi modificado para estar aderente ao nvel 2 do CMM. Em Junho de 2003 o C.E.S.A.R foi reconhecido como nvel 2 do CMM para uma rea de projetos que desenvolve software para o mercado de telefonia celular.

264

6.3 Seleo de um Projeto para Estudo de Caso

Para iniciar a aplicao, um projeto deveria ser escolhido. Havia duas possibilidades para seleo do projeto: Abordagem 1: selecionar um projeto que seguisse o ProSCes, estando mais prximo do nvel 2 do CMM, j que o ProSCes, conforme citado anteriormente, foi modificado para estar aderente ao nvel 2; Abordagem 2: selecionar um projeto que utilizasse XP. No havia a possibilidade de selecionar um projeto do escopo da avaliao CMM, pois o risco de comprometer a avaliao seria alto para a organizao, j que o Guia no havia sido utilizado por nenhum projeto e no tinha sido trabalhado pela consultoria especializada, como todos os outros projetos do escopo. Era sabido que para qualquer escolha haveria uma forte resistncia. Projetos acostumados com a cultura do nvel 2 do CMM dificilmente gostariam de abrir mo dos seus processos para aderir a qualquer configurao de XP, conforme constatado por uma sondagem informal para a seleo de projetos para este estudo de casos. Por outro lado, os projetos que seguiam XP no aceitavam bem aspectos do CMM, com o receio de burocratizar o projeto. Alm da resistncia por cultura adquirida de projeto cultura CMM ou XP notou-se uma aceitao diferente de XP de acordo com funes exercidas. Os gerentes de projeto muitas vezes encaram XP com receio pelo fato de a metodologia no abordar aspectos clssicos da gerncia de projetos, como: riscos, cronograma convencional e planos. Provavelmente esta resistncia ainda maior no C.E.S.A.R, onde parte dos gerente so certificados PMP [58]. Arquitetos de software, por sua vez, valorizam a elaborao de uma arquitetura estvel para o sistema, o que vai de encontro prtica o mais simples possvel de XP. Desenvolvedores, em geral, aceitam bem XP devido valorizao de suas atividades. O uso da abordagem 1 acarretaria, principalmente, em uma anlise de impacto das metodologias geis, pois, neste caso, projetos j seriam acostumados com a cultura do nvel 2 (apesar de nem todas as prticas do nvel 2 serem implementadas em todos os projeto do C.E.S.A.R) e aspectos das metodologias geis seriam inseridos no decorrer dos

265

projetos. A introduo do Guia traria prticas de XP. A abordagem 2 favoreceria a anlise de impacto do uso do CMM. A abordagem selecionada foi a segunda: a de implantar o Guia num ambiente mais prximo de XP. Com isto, seria mais fcil averiguar se o CMM traria diminuio da agilidade no projeto. Alm disto, esta abordagem utiliza a lgica empregada pelo Diagnstico XP-CMM2, que partiu de XP para verificar aderncia ao nvel 2 do CMM.

6.4 O Projeto Selecionado

O projeto selecionado para aplicao do Guia XP-CMM2 foi firmado sobre um contrato de 36 meses, iniciado em junho de 2001, e envolve atualmente 19 pessoas. Ele engloba desenvolvimento de novas funcionalidades e manuteno, utilizando a linguagem de programao Java. O cliente um rgo pblico do governo federal. O projeto enfrenta algumas dificuldades devido a caractersticas prprias. Primeiramente, o projeto enfrenta a falta de um gestor do projeto no lado cliente, o que acarreta no no estabelecimento de um ponto focal, com responsabilidade e autoridade para tomar decises em nome do cliente. O problema gerado por este fato que as decises no podem ser tomadas na velocidade necessria, mudanas so difceis de serem negociadas e compromissos difceis de serem estabelecidos. Esta situao foi agravada em 2003 devido troca de presidentes, o que provocou mudanas significativas nas camadas gerenciais do cliente, que interagiam com o projeto. Alm disto, os usurios do sistema so representantes de diferentes reas da empresa contratante, que possuem interesses divergentes. Estes usurios, responsveis por definir requisitos e prioridades, e validar os produtos gerados pelo projeto, entram em conflitos que muitas vezes, comprometem o progresso do projeto. Outro fator que torna o gerenciamento do projeto no trivial se deve ao fato de o projeto ser de desenvolvimento e manuteno ao mesmo tempo. Por um lado, os usurios cobram que todos os defeitos sejam corrigidos com a mxima urgncia, por outro, o Patrocinador do projeto cobra que as novas funcionalidades sejam entregues nas datas acordadas.

266

Alm disto, a equipe do projeto trabalha de forma distribuda: parte alocada no cliente, em Braslia e parte no C.E.S.A.R, em Recife. As equipes so comumente chamadas de equipe Braslia e equipe Recife. A equipe Braslia tem a responsabilidade de elicitar e documentar os requisitos detalhados do cliente, os quais devem estar coerentes com os requisitos contratados, cronograma, metas e objetivos do projeto. Alm disto, a equipe Braslia responsvel por registrar bugs e realizar testes de aceitao nos produtos que so implantados. A equipe Recife trabalha sobre os requisitos repassados pela equipe Braslia. XP foi empregado inicialmente na equipe Recife, que tratava a equipe Braslia como o cliente. A deciso de utilizar XP no projeto se deu objetivando aumentar a satisfao do cliente, a produtividade, comprometimento e motivao da equipe, aumentar a eficcia das estimativas, alm de diminuir os grandes riscos do projeto e facilitar o planejamento. Os aspectos de XP que mais contriburam para apoiar a deciso de utiliz-lo visando o alcance destes objetivos foram os releases curtos de software de valor, as iteraes curtas de tamanho fixo, as reunies dirias e as estimativas realizadas pelos prprios desenvolvedores.

6.5 A Metodologia Utilizada

A metodologia empregada para a realizao dos resultados foi o de executar o papel de garantia da qualidade (SQA) no projeto, conforme definido pela KPA Software Quality Assurance do CMM. Segundo o CMM, o objetivo da KPA SQA prover o gerenciamento com visibilidade apropriada no processo que est sendo usado pelo projeto de software e o produto que est sendo construdo[58]. O grupo de SQA cumpre este objetivo atravs da realizao de revises e auditorias. Uma caracterstica importante do SQA que ele deve ser independente do projeto, como sugere o CMM na prtica SQA.Co1.2 O grupo de SQA tem um canal de reportagem para a gerncia snior que independente de: gerente do projeto, grupo de engenharia de software do projeto e outros grupos relacionados a software [58].

267

No C.E.S.A.R, o grupo de garantia da qualidade responde gerncia de qualidade, que responde gerncia de tecnologia. A gerncia de tecnologia possui o mesmo nvel da gerncia de consultoria, que gerencia os projetos. Desta forma, o grupo completamente independente do gerente de projeto e de outros grupos relacionados a software. A Figura 6-1 exibe o organograma do C.E.S.A.R no contexto de garantia da qualidade e projetos.

Figura 6-1 - Organograma no contexto do grupo de SQA A independncia de SQA garante que auditorias e revises podero ser realizadas e os desvios encontrados cobrados de acordo com as prioridades da organizao quanto qualidade de software. Assim, um desvio encontrado no poder ser preterido pelo gerente do projeto devido a problemas de estouro de prazos, por exemplo. Dificuldades no foram encontradas para desempenhar o papel do grupo de qualidade em um projeto visando aplicao do Guia XP-CMM2. A autora faz parte do grupo de garantia da qualidade do C.E.S.A.R, sendo lder do grupo e, como tal, tendo as seguintes atribuies: definio e melhoria do processo de garantia da qualidade, alocao do grupo nos projetos, acompanhamento peridico do grupo. O processo seguido para execuo da garantia da qualidade no projeto foi o Procedimento de Garantia da Qualidade do ProSCes o processo padro do C.E.S.A.R. Para melhor entender o trabalho conduzido e o contexto do projeto importante descrever o ProSCes e o Procedimento de Garantia da Qualidade do ProSCes, descritos nas prximas sees.

268

6.5.1 O ProSCes
O ProSCes foi elaborado em 2000, com base no RUP e, com isto, possui suas principais caractersticas: modelo de ciclo de vida iterativo e incremental, centrado em casos de uso, uso de UML como linguagem de modelagem, orientao a objetos, arquitetura baseada em componentes, gerenciamento de requisitos, entre outros [35]. O ciclo de vida do RUP composto de quatro fases realizadas em zero ou mais iteraes, sendo cada iterao realizada por zero ou mais disciplinas [35]. A Figura 6-2 exibe o ciclo de vida do RUP.

Figura 6-2 Ciclo de vida do RUP Para cada disciplina do RUP, o ProSCes definiu procedimentos, guias, ferramentas e templates para apoiar a equipe de desenvolvimento. Esta definio foi elaborada a partir de customizaes sobre os artefatos e procedimentos do RUP. Alm das disciplinas do RUP, o ProSCes adicionou duas disciplinas ao ciclo de vida: Fornecimento: determina processos para venda de servio e acompanhamento de contrato; Garantia da qualidade de software: determina processos para realizao das atividades de garantia da qualidade nos projetos.

269

O ProSCes define o ProSCes Core que o processo mnimo necessrio, a ser seguido por todos os projetos. Este ProSCes Core est completamente aderente ao nvel 2. Assim, todos os artefatos obrigatrios do ProSCes, que implementam alguma prtica do nvel 2 fazem parte do ProSCes Core. Por outro lado, a grande maioria dos artefatos que no implementam o nvel 2, como por exemplo, modelo de classes ou projeto de testes, no fazem parte do ProSCes Core. Ainda assim, um projeto poder no utilizar o ProSCes Core caso deva utilizar o processo do cliente por questes contratuais. Nestes casos, uma anlise deve ser feita pelo gerente do projeto em conjunto com o grupo de garantia da qualidade, no incio do projeto, para identificar se o processo do cliente est alinhado ao nvel 2 do CMM e poltica de desenvolvimento do C.E.S.A.R. O ProSCes Core genrico e ainda passvel de adaptao, desde que aprovada pelo grupo de garantia da qualidade no projeto. Assim, um template definido pelo ProSCes Core poder sofrer ajustes para atender s necessidades do projeto, desde que atenda ao nvel 2 do CMM, poltica de desenvolvimento do C.E.S.A.R e s restries do cliente.

6.5.2 O Procedimento de Garantia da Qualidade do ProSCes

Conforme poltica de desenvolvimento publicada, o Procedimento de Garantia da Qualidade deveria ser seguido pelo grupo de garantia da qualidade, em todos os projetos do C.E.S.A.R. Este procedimento foi utilizado como base para a aplicao do Guia XPCMM2. As atividades do procedimento de garantia da qualidade do ProSCes so descritas resumidamente abaixo. Planejar garantia da qualidade do projeto O planejamento de garantia da qualidade deve ser realizado em conjunto com o gerente do projeto, no incio do projeto. Esta atividade gera um Plano de Garantia da Qualidade que, no ProSCes, inserido dentro do Plano do Projeto. Informaes contidas neste plano so: processos e padres adotados para o projeto, adequaes (tailors) aplicados ao processo, planejamento das auditorias, mtricas selecionadas, planejamento de revises. Realizar reunio de incio do projeto

270

No incio do projeto, o grupo de garantia da qualidade responsvel por orientar toda a equipe sobre papel, responsabilidades, autoridade e valor do grupo. Isto feito atravs de uma reunio chamada Kickoff. O ProSCes dispe de uma apresentao padro contendo as informaes necessrias, dentre elas, importante ressaltar: a independncia do grupo de SQA, objetivos de auditoria, papel da equipe em relao aos desvios encontrados. Realizar auditoria de processo As auditorias de processo devem ser realizadas periodicamente, conforme planejado na seo relacionada garantia da qualidade do Plano do Projeto. As auditorias de processo tm como objetivo: Verificar conformidade e efetividade do processo de desenvolvimento utilizado pela equipe aos padres e procedimentos estabelecidos; Reportar problemas e oportunidades de melhoria do processo utilizado pela equipe para os grupos interessados. O ProSCes dispe de um checklist padro para a realizao das auditorias de processo, contemplando o que tpica e minimamente deve ser checado em auditorias. Este checklist deve ser acrescido de padres e procedimentos especficos do projeto a cada auditoria. As auditorias de processo so realizadas atravs de entrevistas e anlise de documentos. As entrevistas podem ser realizadas em grupos ou individualmente, desde que gerentes e subordinados no sejam entrevistados ao mesmo tempo, para garantir conforto e confidencialidade aos entrevistados. O grupo de garantia da qualidade deve ter total liberdade para analisar os arquivos do projeto. Ao final da auditoria, um relatrio consolidando as informaes obtidas deve ser produzido pelo grupo de garantia da qualidade e enviado alta gerncia e equipe do projeto. Para cada desvio encontrado na auditoria, aes para correo devero ser identificadas e prazos e responsveis por execut-las, devem ser estabelecidos pelo grupo de garantia da qualidade em conjunto com o gerente do projeto. Realizao de auditorias de produto

271

O objetivo desta auditoria verificar a conformidade dos produtos (artefatos) gerados pelo projeto aos padres estabelecidos. Para isto, o grupo de garantia da qualidade dever selecionar os produtos a serem auditados. Auditorias de produto devem ser realizadas de forma amostral, segundo um critrio documentado no plano de garantia da qualidade. As auditorias de produto ocorrem durante as auditorias de processo e medida que os artefatos vo sendo construdos. Em geral, os problemas encontrados nas auditorias de produto so de menor criticidade que os problemas encontrados nas auditorias de processo. Assim, no h um relatrio de consolidao dos resultados. Os problemas identificados, assim como na auditoria de processo, devero gerar aes para correo com prazos e responsveis por execut-las, acordados em conjunto com o gerente do projeto. Os problemas devem ser comunicados equipe atravs dos relatrios peridicos emitidos pelo grupo de garantia da qualidade. Acompanhamento dos desvios encontrados O grupo de garantia da qualidade deve garantir que os desvios encontrados nas auditorias sero corrigidos. Isto feito atravs da verificao, junto ao responsvel, da realizao das aes planejadas para correes dos desvios nas datas acordadas. Se a equipe no realizar as aes acordadas, o grupo de garantia da qualidade poder escalar o problema para a alta gerncia de qualidade, que dever intervir junto alta gerncia dos projetos. Problemas escalados devero ser acompanhados pelo grupo de garantia da qualidade at resoluo. Apoiar a equipe no uso do processo O grupo de garantia da qualidade deve apoiar a equipe no uso do processo atravs de esclarecimentos de dvidas, identificao de necessidades de treinamentos, consultoria de processo visando garantir que a equipe utilize o processo adotado de forma apropriada. Reportagem dos resultados O grupo de garantia da qualidade deve reportar equipe do projeto, ao grupo de garantia da qualidade do cliente e gerncia snior do C.E.S.A.R o status das atividades de garantia de qualidade de software no projeto. Para isto deve elaborar um relatrio mensal, seguindo um template disponvel no ProSCes e o revisa com os interessados em reunies peridicas. 272

Receber auditoria de garantia de qualidade O grupo de garantia da qualidade deve disponibilizar materiais e informaes

necessrias para realizao efetiva de auditorias externas ao grupo. O objetivo destas auditorias garantir que as atividades de garantia da qualidade nos projetos do C.E.S.A.R esto sendo realizadas conforme o procedimento do ProSCes. Assim como nas auditorias de processo e produto, os desvios identificados sero reportados e prazo e responsveis pela soluo do problema identificados em conjunto com a gerncia de qualidade, que responsvel por acompanh-los. Realizar fechamento de garantia da qualidade Ao final do projeto, o grupo de garantia da qualidade responsvel por consolidar as informaes relacionadas garantia da qualidade do projeto e comunic-las equipe e ao grupo de garantia da qualidade do cliente.

6.5.3 Resultados Esperados

Atravs da execuo do papel de garantia da qualidade, a anlise da aplicao do Guia XP-CMM2 foi realizada de forma sistemtica e independente. O trabalho de garantia da qualidade em especial as auditorias trouxe dois tipos de resultado, como previsto: o Resultado concreto: baseado em informaes concretas a respeito da adequao metodologia proposta para o projeto (XP aplicado ao Guia). Estes resultados so capturados, por exemplo, quando um documento no produzido ou no atualizado ou quando atividades do processo no so cumpridas; o Resultado abstrato: sentimentos da equipe quanto ao processo e produto criado. Este tipo de resultado capturado tipicamente em entrevistas de auditoria de processo. Nestas entrevistas, as pessoas costumam emitir gestos, opinies e extravasar sentimentos, motivados justamente pela independncia de garantia da qualidade em relao ao gerente do entrevistado. Um resultado abstrato deve ser utilizado para investigao e identificao de resultados concretos. Como exemplo, se um entrevistado relatar que o gerente do projeto no acompanha o cronograma, o grupo de garantia da qualidade deve buscar evidncias deste no acompanhamento como um cronograma desatualizado. 273

No entanto, algumas vezes, um resultado abstrato pode no levar identificao de um resultado concreto. Um exemplo quando uma pessoa passa impresses como de o processo ser burocrtico ou testes no serem efetivos. Mesmo nestes casos, este tipo de resultado importante para anlise do uso do processo. Estes dois tipos de resultados sero relatados neste trabalho sempre que contribuir para o alcance dos objetivos da aplicao do Guia.

6.6 Cronograma
Um engenheiro de qualidade, representante do grupo de garantia da qualidade, foi alocado ao projeto em novembro de 2002. Durante o ms de novembro foi envolvido nas atividades de planejamento da garantia da qualidade. Em dezembro de 2002 as atividades passaram da fase de planejamento para execuo, quando as auditorias passaram a ser realizadas e a resoluo dos desvios identificados acompanhados. Como o projeto j estava em andamento quando o engenheiro de qualidade foi alocado ao projeto, o planejamento da garantia da qualidade no foi iniciado no incio do projeto, conforme Procedimento de Garantia da Qualidade do ProSCes. As principais dificuldades enfrentadas pelo grupo de garantia da qualidade a partir da alocao ao projeto foram: No incio do projeto no houve planejamento para implementao de garantia da qualidade e to pouco aderncia aos processos do nvel 2 do CMM. Em junho de 2001, quando o projeto iniciou, o ProSCes j existia, mas no possua ainda todos os elementos e prticas do nvel 2; O projeto j estava em execuo h um ano e cinco meses. J possua uma cultura assimilada e equipe organizada. Dificuldades foram encontradas para definir um novo processo e cobrar desvios de processos identificados em auditorias, aps todo este tempo sem atuao de garantia da qualidade. As auditorias de processo foram planejadas para serem realizadas bimestralmente. Cada auditoria foi focada em uma disciplina do desenvolvimento de projetos, sendo tipicamente em disciplinas do nvel 2 do CMM: gerncia de requisitos, planejamento e acompanhamento de projetos e gerncia de configurao. No foram realizadas auditorias de SSM, pois o projeto no subcontratava. A cada auditoria, os produtos associados 274

tambm eram auditados. A Tabela 6-1 relaciona as auditorias realizadas e o foco de cada uma.
Ms Dezembro/2002 Fevereiro/2003 Maio/2003 Foco Gesto de projetos, KPAs SPP, SPTO e RM Gerncia de Configurao, KPA SCM Gesto de projetos, KPAs SPP, SPTO e RM

Tabela 6-1 Auditorias realizadas A auditoria de Abril foi postergada para Maio devido a problemas internos do projeto, ocorridos aps troca de gerentes. As auditorias tomavam como base: ProSCes Core; Nvel 2 do CMM; Diagnstico XP-CMM2. O Diagnstico XP-CMM2 foi utilizado para apoiar na interpretao da satisfao das prticas do projeto em relao ao ProSCes Core. Um exemplo desta interpretao, que o ProSCes Core define que um cronograma deve ser elaborado e acompanhado periodicamente. O diagnstico aponta se h cronograma e se este acompanhado em XP. De acordo com a interpretao do diagnstico as evidncias de institucionalizao seriam procuradas na equipe. Para cada desvio encontrado, uma recomendao, um responsvel e data para implement-la foram definidos. As recomendaes seriam baseadas no Guia XP-CMM2. Desta forma, o Guia seria introduzido aos poucos no projeto, conforme capacidade de assimilao da equipe e disponibilidade de treinamento. Os templates sugeridos pelo Guia XP-CMM2 no foram adotados pelo projeto, j que ele deveria seguir os templates do C.E.S.A.R. Em julho de 2003 o estudo foi considerado encerrado visando consolidao dos dados obtidos. No entanto, a autora continua atuando como garantia da qualidade no projeto.

275

6.7 O Experimento
Esta seo descrever como foi realizado o estudo de caso e os resultados obtidos. Para isto, abordar inicialmente como a equipe utilizava XP inicialmente, sem a interferncia do Guia XP-CMM2. Depois apresentar a fase de planejamento da garantia da qualidade no projeto e ento a fase de execuo da garantia da qualidade, descrevendo os desvios encontrados nas auditorias e as aes tomadas para correo. Finalmente, realizada uma breve anlise de cada KPA em relao ao que foi implementado do Guia XP-CMM2.

6.7.1 Uso de XP no Projeto

Esta seo descrever como XP era usado no projeto antes de qualquer interferncia do Guia XP-CMM2. Nem todas as prticas de XP foram implementadas risca. Alm disto, algumas customizaes, como a adoo de ferramentas, foram realizadas. 6.7.1.1 Prticas Implementadas Dentre as prticas de XP adotadas pelo projeto, esto: Jogo do planejamento O planejamento detalhado do projeto segue esta prtica de XP: h um planejamento macro dos releases, os quais so detalhados em termos de estrias antes de iniciar. Cada release composto de iteraes de duas semanas, as quais tambm so detalhadas apenas antes de iniciar, em termos de tarefas para realizar as estrias. Estrias e tarefas so selecionadas para os releases e iteraes de acordo com a prioridade do cliente e o esforo necessrio para realiz-las estimado pela equipe de desenvolvimento e registradas na ferramenta XPlanner [51]. A Figura 6-3 exibe o planejamento de uma das iteraes do projeto no XPlanner;

276

Figura 6-3 - O jogo do planejamento no XPlanner Releases pequenos A entrega do software foi planejada para ocorrer incrementalmente, sendo cada pedao do sistema entregue em um prazo mdio de um ms e meio; Refactoring Mesmo tendo uma arquitetura estabilizada para todo o projeto, ao receberem tarefas de desenvolvimento, os desenvolvedores analisam se possvel melhorar a forma como o software foi implementado. Recentemente uma grande reestruturao na arquitetura do software foi realizada para aumentar a performance do sistema; Padro de codificao O projeto segue o padro de codificao definido pelo C.E.S.A.R para desenvolvimento em Java; Propriedade coletiva Todos da equipe podem alterar qualquer arquivo que compe o software; 40 horas por semana O C.E.S.A.R possui um banco de horas para que as horas trabalhadas a mais possam ser compensadas com descanso, conforme acordado com o gerente do projeto e poltica da organizao. Mesmo com o banco de horas, a equipe trabalha usualmente 40 horas por semana; Programao em pares Esta prtica no adotada como sugere XP: toda a equipe trabalhar todo o tempo em pares. No projeto, a programao em pares 277

adotada para novatos e pessoas pouco experientes na tecnologia adotada, os quais devem trabalhar com um membro mais experiente da equipe at que estejam aptos a realizar suas atividades plenamente. Atualmente, a possibilidade de estender esta prtica para outras situaes est sendo avaliada; Integrao contnua Diariamente o build do software gerado automaticamente pela ferramenta Ant [50], adotada pelo projeto. Quando acionada, a ferramenta gera o buid do sistema, um arquivo informando os arquivos alterados e as requisies de mudana (CRs) fechadas na ferramenta de controle de mudana do projeto (o Bugzilla [46]). 6.7.1.2 Prticas No Implementadas As prticas de XP no adotadas so: Testes automticos Apesar de acreditar nos benefcios dos testes automticos, esta prtica ainda no foi adotada no projeto. Esta deciso se deu pelo fato de a adoo de XP ter ocorrido quando grande parte do cdigo j estava implementada. Para obter todos os benefcios dos testes automticos, todo o cdigo deveria possuir testes, inclusive este cdigo anteriormente produzido. Implementar todos estes testes traria um overhead muito grande para a equipe; Cliente no local O cliente no se localiza no mesmo estado em que o projeto foi desenvolvido. Para representar o cliente dentro do projeto e para que o trabalho de entendimento dos requisitos e validao dos artefatos gerados fosse efetivo, parte da equipe passou a trabalhar no local do cliente. Esta equipe responsvel por especificar os requisitos, valid-los e conduzir testes de aceitao; Metforas O projeto utiliza o paradigma de programao orientado a objetos, o que torna o projeto de software perto da realidade do cliente. Devido a isto, o uso de metforas no foi adotado no projeto; Projeto simples Pelo fato de a equipe e o software a ser construdo serem relativamente grandes, optou-se, no incio do projeto, por definir uma arquitetura estvel, que facilitasse a insero de novas funcionalidades, manuteno, componentizao e independncia entre as regras de negcio e dados.

278

6.7.2 O Planejamento de Garantia da Qualidade no Projeto

Por j estar em andamento, o projeto j possua uma cultura de desenvolvimento assimilada e um processo adotado. O projeto seguia algumas prticas de XP, mas, contrariando a poltica de desenvolvimento do C.E.S.A.R, no seguia risca nem mesmo o ProSCes Core. Esta foi uma dificuldade inicial enfrentada neste estudo de caso: projeto j iniciado sem garantia da qualidade, sem seleo do processo adequado para o projeto, sem que o processo colocado em prtica estivesse documentado e ainda sem o seguimento do ProSCes Core. Durante o planejamento da qualidade, realizado em novembro, optou-se por documentar o processo a ser seguido em um plano do projeto, j inserindo alguns aspectos do ProSCes Core e do Guia XP-CMM2, como a elaborao do prprio plano do projeto e garantia da qualidade, plano de gerncia de configurao, entre outros. Este plano foi revisado pela alta gerncia do C.E.S.A.R e representantes do projeto. O cliente seria convidado a revisar e aprovar o plano em um segundo momento, quando todos concordassem sobre o contedo do plano. No entanto, devido a problemas internos do cliente, o plano no pde ser submetido aprovao. Mesmo assim, foi considerado como base para acompanhamento e auditorias de garantia da qualidade.

6.7.3 As Auditorias Realizadas

Esta seo ir descrever os principais problemas encontrados nas auditorias realizadas no projeto e respectivas recomendaes sugeridas pelo grupo de garantia da qualidade. Conforme j citado, a identificao dos problemas foi apoiada pelo Diagnstico XP-CMM2, que realizou a interpretao de XP em relao ao CMM nvel 2. Alm destes aspectos de interpretao de processos, as auditorias checavam institucionalizao, ou seja, se os processos definidos estavam sendo seguidos pela equipe. As recomendaes sugeridas para resoluo dos problemas identificados tomaram como base o Guia XP-CMM2, com pequenas alteraes visando contemplar as especificidades do projeto. Vale ressaltar que uma mesma recomendao pode resolver a vrios desvios. Os problemas descritos nesta seo so um subconjunto dos problemas identificados nas auditorias, caracterizado pelo escopo deste trabalho. Assim, problemas 279

identificados relacionados instituio ou uso de ferramentas especficas no relacionadas com XP ou com o nvel 2 do CMM no foram citados. O resultado das auditorias relatado nas prximas sees poder indicar um mesmo problema em mais de uma auditoria. Isto significa que ou o problema no foi resolvido entre uma auditoria e outra ou foi resolvido, mas h uma reincidncia. Este resultado esperado por qualquer projeto de software. Por isto to importante o trabalho de garantia da qualidade, para que problemas no sejam apenas identificados, mas tambm, acompanhados at fechamento. 6.7.3.1 Dezembro de 2002 Esta auditoria foi realizada com foco em planejamento e acompanhamento. Entrevistas foram realizadas com integrantes da equipe do projeto e a verso draft do Plano do Projeto foi analisada. A Tabela 6-2 relaciona os principais desvios e recomendaes identificados relacionados ao escopo deste trabalho.
Prtica RM.Ac2 Desvio como artefato do projeto no draft do Plano do Projeto, no foi elaborado e nem documentado. Desta forma, o baseline de requisitos no est claro para o projeto. RM.Ac3, SPP.Ac4 O projeto no possui um Plano de Projeto aprovado pelos responsveis. Aprovar Plano do Projeto inserindo planejamento de recursos crticos do projeto, revises formais, reunies peridicas com toda a equipe do projeto. SPP.Ac13 SPP.Ac11 O Plano de Riscos no foi elaborado para o projeto. Recursos crticos no foram planejados e estimados para o projeto. Elaborar e acompanhar Plano de Riscos do projeto. Aprovar Plano do Projeto inserindo planejamento de recursos crticos do projeto, revises formais, reunies peridicas com toda a equipe do projeto. SPTO.Ac13 Revises formais no foram planejadas para o projeto. Aprovar Plano do Projeto inserindo planejamento de recursos crticos do Recomendao requisitos do projeto.

O documento de requisitos, estabelecido Elaborar e aprovar o documento de

280

projeto, revises formais, reunies peridicas com toda a equipe do projeto. SCM.Ac4 SCM.Ac10 No est estabelecido SCCB para itens de configurao que no cdigo. Auditorias nas baselines do projeto no esto sendo realizadas. Estabelecer SCCB para itens de configurao que no cdigo. Realizar periodicamente auditorias nas baselines do projeto.

Tabela 6-2 - Desvios e Recomendaes da Auditoria de Dezembro de 2002 Durante o planejamento da garantia da qualidade, iniciado quando o grupo de garantia da qualidade foi alocado ao projeto, foi elaborado um plano do projeto, que deveria ter sido elaborado no incio do projeto, conforme o ProSCes. Este plano passou a documentar requisitos no tcnicos do projeto, como marcos, prazos, a requisio de prestao de contas para o cliente, entre outros. No entanto, este plano no foi aprovado pelo cliente at o momento desta auditoria. Sem a aprovao do plano, os compromissos e requisitos no tcnicos do projeto no possuem concordncia das partes envolvidas. Neste momento, no havia sido elaborado um documento que descrevesse os requisitos tcnicos do projeto. Os requisitos tcnicos estavam documentados apenas na proposta tcnica, ou contrato do projeto. O problema, que este documento esttico e no atualizado com mudanas realizadas no projeto. Este documento sofre alteraes, apenas em alteraes muito crticas nos compromissos acordados, como no escopo, prazo e custos. Como parte da equipe se encontrava dentro do cliente para especificar os resultados, o trabalho realizado pela equipe se concentrava em atender demandas especificadas pelos usurios do sistema, de acordo com suas prioridades. No entanto, estas prioridades poderiam no estar contratadas, ou seja, no fazer parte do escopo do projeto. Este problema impactava diretamente a KPA de gerncia de requisitos, pois j que no existia uma baseline de requisitos, as mudanas tambm no poderiam ser controladas (desvio na atividade RM.Ac2, no formalizado na auditoria, pois a atividade RM.Ac1 precisaria ser tratada primeiro).

281

Vele considerar, que a forma como XP trata os requisitos era utilizada como base pela equipe: trabalhar sobre prioridade do cliente. No entanto, o contrato estabelecido pregava que um escopo determinado deveria ser cumprido at o final do projeto. A auditoria recomendou que um Documento de Requisitos fosse elaborado, aprovado pelo cliente e gerenciado. Assim, a equipe deveria implementar os requisitos descritos no Documento de Requisitos, detalhando-os, conforme sugerido por XP. Riscos no haviam sido identificados. Recursos crticos no haviam sido identificados e estimados. Revises formais no haviam sido planejadas: medida que os produtos ficavam prontos, estes eram colocados em produo, sem reviso formal por parte do cliente. importante ressaltar, que esta prtica foi considerada um ponto fraco na auditoria por no estar aderente ao CMM, mas a equipe tambm no estava seguindo XP, que determina o envolvimento do cliente e testes de aceitao. Inicialmente o projeto possua muitos problemas de gerncia de configurao, como: no saber a verso que se encontrava instalada no cliente, no saber o que constava em cada verso, retrabalho para soluo de problemas j resolvidos, entre outros. Um gerente de configurao foi alocado part time ao projeto. Neste momento, um plano de gerncia de configurao acabava de ser elaborado e aprovado por representantes do projeto. A princpio, o plano considerava apenas como item de configurao o cdigo fonte e o build do sistema. Auditorias nas baselines no eram realizadas. 6.7.3.2 Fevereiro de 2003 Esta auditoria foi realizada com foco em gerncia de configurao. Entrevistas foram realizadas com integrantes da equipe do projeto e foram analisados em detalhes o plano de gerncia de configurao, anlise do repositrio e da ferramenta de controle de mudanas do projeto. A Tabela 6-3 relaciona os principais desvios e recomendaes identificados relacionados ao escopo deste trabalho.
Prtica RM.Ac2 Desvio O baseline de requisitos no est definido para o projeto: no h um documento de requisitos do projeto, Recomendao Definir o baseline de requisitos. Lig-lo s especificaes passadas equipe de desenvolvimento.

282

mudanas aos requisitos no so controladas, a especificao das funcionalidades do projeto no esto relacionadas com os requisitos da proposta tcnica aceita pelo cliente. SPTO.Ac10 Os riscos do projeto esto sendo reportados gerncia snior do C.E.S.A.R, no entanto, no esto sendo acompanhados: a planilha de riscos no alterada desde o momento em que foi colocada no repositrio do projeto. SCM.Ac2 O plano de gerncia de configurao tem sido alterado constantemente, no submetidas reviso. SCM.Ac2 O plano de gerncia de configurao no est atualizado (h definies que esto em desuso no projeto) e muitos dos padres estabelecidos no esto sendo seguidos pela equipe. SCM.Ac10 Uma auditoria foi realizada pelo grupo esta auditoria no foi eficaz, pois no identificou problemas como: nomeao incorreta dos itens de configurao e das baselines, falta de estabelecimento de baselines, falta de controle de mudanas de itens de configurao, no seguimento do padro estabelecido para a estrutura do repositrio e ferramenta de controle de mudanas. SCM.Ac10 A auditoria realizada no teve os problemas identificados acompanhados Registrar os desvios de auditoria encontrados e acompanh-los at Elaborar checklist para auditoria nas de gerncia de configurao, no entanto, baselines do projeto. Atualizar o plano de gerncia de configurao com as prticas e padres adotados pelo projeto e permitidos pelo ProSCes. Elaborar critrio para submisso dos planos reviso e submeter o plano de Acompanhar periodicamente os riscos do projeto.

entanto, estas mudanas no esto sendo gerncia de configurao reviso.

283

pelo gerente de configurao. SCM.Ac4 o desenvolvimento do projeto foram identificados como itens de configurao, dentre eles: manual do usurio, documento de requisitos, especificao de casos de uso. Alm disto, Itens de Configurao selecionados no PGC no esto no repositrio do projeto.

fechamento. baselines do projeto.

Nem todos os artefatos importantes para Rever os itens de configurao e as

Tabela 6-3 - Desvios e Recomendaes da Auditoria de Fevereiro de 2003 Neste momento, um sistema para gerenciar o escopo do projeto ainda no havia sido implantado. Uma verso inicial do Documento de Requisitos, proposta na auditoria de Dezembro de 2002 foi elaborada, no entanto, ainda no havia sido finalizada, aprovada e acompanhada em relao ao que se estava desenvolvendo no projeto. Vale ressaltar que todo o trabalho realizado pela equipe Recife passava por um fluxo bem definido: a equipe Braslia registrava uma solicitao de mudana na ferramenta de controle de mudana para um bug, novo requisito ou alterao de um requisito j solicitado. A equipe Recife avaliava esta solicitao na reunio de planejamento da iterao, estimando-a e atribuindo-a equipe. O problema estava em gerenciar se as solicitaes de mudana solicitadas e implementadas estavam realizando o escopo contratado do projeto. A equipe trabalhava sobre as prioridades do cliente, no entanto, conforme mencionado anteriormente, o projeto possua um contrato firmado, que especificava diversas funcionalidades, e que deveria ser cumprido at o final do projeto. Riscos foram identificados, mas no estavam sendo acompanhados. O planejamento da gerncia de configurao no projeto foi realizado pensando-se apenas no contexto da fbrica de software e no do projeto como um todo. A opo de no controlar os produtos elaborados pela parte do projeto que trabalha em Braslia foi acordada em reunio com o gerente do projeto e grupo de garantia da qualidade, visando facilitar a institucionalizao do processo de gerncia de configurao. Devido a isto, 284

poucos itens de configurao foram identificados no plano de gerncia de configurao. Apenas os produtos relacionados ao build (cdigo fonte, arquivos de interface e outros) estavam sendo gerenciados e controlados. Alm disto, apesar de bastante alterado, o plano de gerncia de configurao possua prticas no assimiladas pela equipe e no possua um critrio para ser submetido nova aprovao. Assim, novos controles relacionados gerncia de configurao foram documentados e colocados em prtica no projeto sem a devida aprovao do gerente do projeto e lderes. Neste momento j foi possvel identificar prejuzos pela no identificao de itens de configurao dos produtos criados pela equipe de Braslia. Assim, a auditoria sugeriu que os itens de configurao do projeto fossem replanejados. As auditorias nas baselines realizadas pelo grupo de gerncia de configurao no estavam sendo eficazes: poucos problemas foram identificados e estes no foram acompanhados. 6.7.3.3 Maio de 2003 A auditoria realizada teve como objetivo avaliar o entendimento da equipe e uso dos processos adotados pelo projeto, especialmente, o processo de planejamento e acompanhamento de projetos. A auditoria se deu atravs de entrevistas e anlise dos produtos de software gerados pela equipe. Trs sees independentes de entrevistas foram realizadas, cada uma contando com a participao de integrantes da equipe. A primeira seo foi realizada com o gerente do projeto, a segunda com lderes das equipes de Braslia e Recife e a terceira com engenheiros de software e analistas de negcio. Os produtos analisados nesta auditoria foram: draft do Plano do Projeto, XPlanner Desenvolvimento e Repositrio do projeto. A Tabela 6-4 relaciona os principais desvios e recomendaes identificados relacionados ao escopo deste trabalho.
Prtica RM.Ac2 Desvio do projeto e define o escopo no est aprovado. RM.Ac3 Atualmente no h um processo para Documentar o processo para alterao Recomendao

O documento que descreve os requisitos Aprovar o documento de requisitos.

285

registrar, avaliar e aprovar as mudanas de requisitos no Plano do Projeto, seo aos requisitos do projeto. RM.Ac2, SPP.Ac4 O projeto no possui um plano do projeto aprovado e atualizado. Os no esto na ferramenta de controle de verso do projeto. de garantia da qualidade. Elaborar o plano do projeto e coloc-lo sobre gerncia de configurao. O plano Mtricas a serem coletadas; Processo de desenvolvimento do projeto; Escopo do projeto; Processo de alterao de requisitos; Cronograma do projeto; Riscos do projeto; Revises formais em marcos; Acompanhamento peridico da equipe; Aprovar o plano do projeto. SPP.Ac13, SPTO.Ac10 Riscos no foram identificados pela nova gerncia do projeto. Os riscos j levantados no esto sendo acompanhados. SCM.Ac2 O plano de gerncia de configurao possui vrias alteraes ainda no Aprovar o plano de gerncia de configurao, contemplando o configurao dos produtos gerados por Braslia. SCM.Ac4 No h controle de configurao dos produtos gerados pela equipe de Braslia. Aprovar o plano de gerncia de configurao, contemplando o planejamento do controle da configurao dos produtos gerados por Braslia. Identificar novos riscos e acompanhlos.

documentos de planejamento existentes deve conter:

aprovadas pelo atual gerente do projeto. planejamento do controle da

Tabela 6-4 - Desvios e Recomendaes da Auditoria de Maio de 2003

286

No momento desta auditoria, o projeto estava em fase de replanejamento. O gerente do projeto foi substitudo e o atual passou a exercer esta funo em 02/04/2003. Alm disto, sendo o cliente pblico, da esfera federal, aps a posse do novo presidente, vrias pessoas que atuavam no projeto do lado do cliente foram substitudas. Desta forma, a comunicao com o cliente piorou, dificultando a aprovao do Plano do Projeto e Documento de Requisitos. A auditoria recomendou que, minimamente, o plano fosse fechado para as atividades que estivessem sendo executadas, enquanto no havia uma definio sobre o envolvimento por parte do cliente. O contrato estava sendo revisto. O gerente do projeto estava trabalhando intensamente na repactuao do contrato para, ento, fechar o planejamento do projeto. A repactuao do contrato significa redefinir o escopo do projeto, a partir do que foi contratado. Para isto, foi realizado um levantamento do escopo implementado, o que ainda faltava ser implementado e uma nova proposta do que ser feito at final do projeto. Com a repactuao, o projeto deveria produzir um documento de requisitos com o ltimo escopo contratado. Sobre estes requisitos, um sistema para controlar as mudanas deveria ser implementado. A recomendao do grupo de garantia da qualidade que solicitaes fossem registradas, avaliadas e acompanhadas at fechamento atravs da ferramenta de controle de mudanas adota. O plano do projeto ainda se encontrava em verso no oficial, ou seja, no havia ainda sido passado por aprovao dos responsveis. Como j citado, ainda assim, o plano foi considerado documento oficial do projeto pela equipe e grupo de garantia da qualidade. Devido ao fato de o projeto ser de desenvolvimento de novas funcionalidades e manuteno, apesar da fase de replanejamento, a equipe continuava trabalhando normalmente, sobre os requisitos prioritrios do cliente. Mesmo sem haver definio sobre o novo escopo, como o trabalho da equipe no parou, a auditoria recomendou que o documento de requisitos fosse aprovado o quanto antes, pelo menos sobre o escopo atual de trabalho. O acompanhamento de riscos ainda no havia sido sistematizado pela equipe.

287

O plano de gerncia de configurao deveria contemplar a gesto da configurao dos produtos gerados pela equipe Braslia e ser submetido nova aprovao.

6.7.4 Implementao das KPAs no Projeto

Esta seo abordar as adaptaes realizadas no processo do projeto, por KPA. Aqui so descritos os problemas encontrados e solues empregadas durante todo o estudo de caso, sem explicitar a evoluo obtida com o tempo. Isto facilitar o entendimento e a anlise dos resultados finais obtidos. Para cada KPA do nvel 2, exceto gerncia de subcontrato, so descritos: Prticas Adotadas: descreve brevemente as prticas adotadas pelo projeto para atender a KPA em questo. Estas prticas incluem as prticas de XP e as sugeridas pelo Guia XP-CMM2; Pendncias: descreve pendncias, ou seja, o que no foi ainda implementado no processo, segundo o Guia XP-CMM2; Anlise: realiza uma anlise das principais dificuldades e oportunidades para a implementao do Guia XP-CMM2 em relao a KPA em questo. Alm disto, descreve brevemente ganhos e perdas obtidos pelo projeto com esta implementao. 6.7.4.1 Gerncia de Requisitos Prticas Adotadas Um documento contendo os requisitos de alto nvel do projeto foi elaborado. Sobre estes requisitos, deveria ser implementada a gerncia de escopo. Mudanas a estes requisitos deveriam ser controladas formalmente. As estrias e tarefas de XP detalhavam os requisitos de alto nvel e eram documentadas na ferramenta XPlanner [51], durante o planejamento da iterao, conforme XP. Requisitos no tcnicos e critrios de aceitao foram documentados no Plano do Projeto. Desde a verso inicial, o Documento de Requisitos e Plano de Projeto foram colocados num repositrio para gerenciamento das verses. Pendncias

288

O Documento de Requisitos deveria ser aprovado, mas no foi devido a problemas do projeto j mencionados. Esta atividade est planejada para ser realizada. Mudanas aos requisitos de alto nvel do Documento de Requisitos deveriam passar por um controle formal. Isto no pde ser testado no projeto, pois mudanas no ocorreram, j que a baseline de requisitos no estava estabelecida. Anlise O projeto apresentou grande dificuldade para estabelecer um ambiente de gesto de escopo. Esta dificuldade foi apresentada em decorrncia de vrios fatores: falta de representante do lado do cliente, troca de gerentes, replanejamento do escopo, cultura da equipe. Desconsiderando os fatores externos, a cultura XP do projeto, pode ter contribudo para tornar mais difcil o gerenciamento do escopo. A equipe e o cliente estavam acostumados a trabalhar sobre as prioridades do cliente, vislumbrando o curto prazo do prximo release e no do contrato firmado. Apesar disto, toda a equipe identificava a possibilidade de no cumprimento do contrato como um fator de alto risco para o projeto. Por outro lado, a forma de trabalho sugerida por XP para documentar requisitos e prioriz-los foi de grande ajuda para o projeto. Especialmente por se tratar de desenvolvimento e manuteno. Toda a equipe julgava junta a prioridade de um bug e de uma nova implementao. A documentao na ferramenta XPlanner era realizada por todos. Todos entendiam todos os requisitos. Os controles criados at o momento no impactaram o trabalho do dia a dia da equipe. O controle formal proposto para o escopo do projeto, apesar de ainda no completamente implementado, foi bem recebido pela equipe e organizao. 6.7.4.2 Planejamento do Projeto Prticas Adotadas Um plano do projeto foi elaborado contemplando o contedo de um plano XP, de um plano CMM e necessidades do C.E.S.A.R. Desta forma, o plano do projeto passou a definir: propsito, escopo, objetivos, descrio do cliente, organograma do projeto (com papis da equipe e do cliente), responsabilidades, procedimentos, padres e mtodos, artefatos a serem entregues, instalaes e ferramentas, treinamentos, planejamento de 289

releases, referencia a ferramenta XPlanner (que define o planejamento das prximas iteraes), estimativas e planilha de riscos. Uma planilha de riscos foi adotada. Nesta planilha os riscos so identificados, priorizados e planos de contingncia e mitigao so definidos. O plano do projeto foi submetido anlise e aprovao de lderes e alta gerncia do C.E.S.A.R, para que os compromissos do projeto fossem acordados e firmados. O processo de estimativa adotado para o projeto continuou a ser o sugerido por XP, que no aderente ao nvel 2 do CMM, conforme mencionado no Diagnstico XPCMM2. Pendncias O Plano do Projeto deveria ser aprovado formalmente, inclusive por representantes do cliente, mas no foi devido problemas do projeto. Esta atividade est planejada para ser realizada. Recursos crticos no foram estimados para o projeto. Vislumbrou-se identificar a massa de dados como um recurso crtico, j que o projeto trabalha com uma base muito grande de dados e consultas no devem ser lentas. Por passar por tantas prioridades, a identificao de recursos crticos foi preterida num primeiro momento. Anlise O plano do projeto contribuiu para melhorar a comunicao do projeto com a equipe e grupos externos ao projeto, como alta gerncia, cliente e garantia da qualidade. Apesar de no haver aprovado formalmente o plano do projeto, representantes do cliente tiveram acesso ao plano. Informaes que antes estavam na cabea das pessoas, passaram a ser documentadas, como: planejamento das instalaes, organograma, equipe, papis e responsabilidades. O plano passou a ser base para acompanhamento do projeto e auditoria do grupo de garantia da qualidade. O plano do projeto no alterou o dia a dia da equipe. A sua elaborao foi uma atividade a mais para o gerente do projeto, apenas. 6.7.4.3 Acompanhamento do Projeto Prticas Adotadas O acompanhamento do projeto era bastante forte devido aos releases e iteraes curtas e s reunies dirias com toda a equipe. Esta KPA era implementada com a 290

atualizao dos planos de release e iterao de acordo com mudanas no projeto, reunies dirias para a comunicao das mudanas aos grupos afetados e acompanhamento das atividades tcnicas. Alm disto, o projeto possua acompanhamento das estimativas e do cronograma de atividades, onde a cada reunio de iterao se verificava o que foi cumprido na iterao passada e se planeja as atividades para a prxima iterao. Um relatrio mensal de progresso do projeto era enviado para a alta gerncia do C.E.S.A.R e para o cliente. Este relatrio contempla: dependncias, riscos, atividades planejadas e realizadas, mtricas. Desta forma, a alta gerncia participa das mudanas aos compromissos com grupos externos e os riscos so acompanhados e reportados. Revises formais foram agendadas para serem conduzidas com representantes do cliente a cada release. Pendncias A cada mudana crtica o plano deveria ser alterado e submetido a uma nova reviso pelo cliente e alta gerncia. Isto no ocorreu, j que nem mesmo a primeira verso do plano foi aprovada. O relatrio mensal do projeto no constituiu uma prtica sistemtica do projeto, pois em alguns meses no foi elaborado. Nenhuma reviso formal ocorreu conforme planejado, apesar de que, em algumas implantaes, o cliente era envolvido e tratava de aspectos do projeto com a equipe Braslia. Os riscos no estavam sendo acompanhados sistematicamente. Recursos crticos no foram acompanhados j que no foram nem identificados e estimados. Anlise Da mesma forma que as KPAs gerncia de requisitos e planejamento de projetos, as mudanas propostas para o acompanhamento trariam mais benefcios para grupos externos ao projeto que para o dia a dia da equipe. O relatrio de progresso deveria ser elaborado pelo gerente do projeto, em conjunto com informaes passadas pela equipe nas reunies de planejamento. Os grupos de garantia da qualidade e gerncia de configurao tambm eram responsveis por elaborar partes do relatrio. 291

O cliente e alta gerncia passaram a receber informaes consolidadas e importantes sobre o progresso do projeto. O relatrio tambm servia como informaes para a equipe sobre riscos e progresso. Os grupos de garantia da qualidade e gerncia de configurao reportavam seus resultados e eram acompanhados por estes relatrios. Alm do relatrio, as revises formais aumentariam a eficcia do acompanhamento por parte do cliente. 6.7.4.4 Garantia da Qualidade Prticas Adotadas As atividades do Procedimento de Garantia da Qualidade do ProSCes, descrito na Seo 6.5.2 foram seguidas no projeto. Pendncias Apesar de comunicar os problemas do projeto, nenhum desvio identificado em auditoria foi oficialmente escalado para a alta gerncia do C.E.S.A.R. Isto porque, foi acordado com a alta gerncia, que o projeto precisaria de um tempo maior para se estruturar e organizar mediante todos os problemas enfrentados. Anlise As auditorias e revises realizadas pelo grupo de garantia da qualidade foram bem recebidas pela equipe. O grupo contribuiu tambm para estabelecer padres entre as equipes Braslia e Recife. Alm disto, o grupo de garantia da qualidade atuou fortemente como consultor de processos do projeto, acompanhando e sugerindo aes para resoluo dos problemas. A presena do grupo contribuiu de forma decisiva para que planos fossem elaborados e atualizados, visibilidade do projeto aumentasse para grupos externos ao projeto e equipe e problemas fossem, seno resolvidos imediatamente, tivessem a resoluo planejada. 6.7.4.5 Gerncia de Configurao Prticas Adotadas Devido natureza de desenvolvimento de novas funcionalidades e manuteno, o projeto enfrentava vrios problemas no controle de verso do sistema. Uma pessoa foi alocada para atuar em tempo parcial como gerente de configurao do projeto. Um plano de gerncia da configurao foi elaborado para o 292

projeto descrevendo as baselines, itens de configurao, CCB (comit que avalia as mudanas), entre outros. O plano foi aprovado pelo gerente do projeto e lderes e reaprovado quando mudanas impactantes eram realizadas. Para no tornar custoso o processo de gerncia de configurao dentro do projeto, foram adotadas ferramentas freeware para controle de verso (CVS [49]) e de mudanas (Bugzilla [46]). O plano foi utilizado como base para controle das verses e mudanas dos itens de configurao do projeto. Auditorias nas baselines passaram a ser realizadas, mas no de forma sistemtica. Pendncias No foi definido um critrio para reaprovao do plano de gerncia de configurao. Algumas vezes o plano apresentava diversas alteraes, mas s era submetido reaprovao, aps identificao do problema pelo grupo de garantia da qualidade. Inicialmente apenas o cdigo foi tratado como item de configurao. No final deste experimento, o projeto estava em fase de planejamento para estender os itens de configurao do projeto. Anlise A KPA que obteve mais ganhos objetivos com a aplicao do Guia XP-CMM2 foi a gerncia de configurao. Os problemas diminuram consideravelmente. Toda a equipe considera, hoje, a gerncia de configurao como um ponto forte do projeto. No entanto, esta foi a KPA que mais impactou o dia a dia da equipe de desenvolvimento, que deveriam trabalhar sobre baselines estabelecidas, seguir padres documentados no plano de gerncia de configurao, realizar mudanas de forma controlada.

6.8 Aplicao do Guia XP-CMM2 em uma Empresa Incubada

Como j citado anteriormente, o C.E.S.A.R desenvolve projetos de software e cria empresas. A criao de empresas passa por um processo chamado incubao, onde o C.E.S.A.R prov recursos empresa incubada. Esta empresa passar a ser uma empresa

293

do mercado, quando houver condies para se sustentar e gerar lucros. Isto, em geral, acontece com o aporte financeiro de um investidor. No primeiro semestre de 2003, um investidor contratou um consultor para realizar um diagnstico em uma das empresas incubadas do C.E.S.A.R para atestar a viabilidade de um possvel investimento. Uma das concluses do consultor foi que a empresa no possua um processo de desenvolvimento de software estabelecido. No entanto, a empresa utilizava como base de desenvolvimento a metodologia XP. Para solucionar o problema, o C.E.S.A.R solicitou que um diagnstico do processo fosse realizado na empresa e que recomendaes para os problemas identificados fossem propostas. O diagnstico solicitado utilizou como base o nvel 2 do CMM. Esta deciso foi tomada porque alm de ser um modelo reconhecido mundialmente, o CMM foi utilizado na anlise realizada pelo consultor do investidor. Assim como no experimento relatado, o Diagnstico XP-CMM2 contribuiu para a interpretao das prticas de XP quanto aderncia ao nvel 2 do CMM. O Guia XPCMM2 foi utilizado para propor solues aos problemas identificados. Como era de se esperar, a empresa possua algumas peculiaridades, de forma que nem todos os problemas e solues estavam contemplados no Diagnstico e Guia XP-CMM2. Como empresa incubada do C.E.S.A.R, ela poderia adotar o ProSCes como processo de desenvolvimento, visando ter um processo mais estabelecido e formal. No entanto, um dos pr-requisitos para o trabalho era que a empresa continuasse a utilizar XP, pois j vinha obtendo bons resultados com a metodologia h um tempo. Alm disto, os integrantes da empresa colocaram que a metodologia atendia s expectativas e cultura da empresa. Ao final do diagnstico realizado, um relatrio foi elaborado, descrevendo o contexto do diagnstico, mtodo utilizado, pontos fortes, fracos e recomendaes. Este relatrio foi inicialmente validado pela empresa, que apontou pequenos problemas de entendimento e depois foi formalmente aceito com as recomendaes propostas. A partir de ento, o relatrio foi enviado para a alta gerncia do C.E.S.A.R. O Apndice A, exibe o relatrio final deste trabalho, excluindo detalhes da empresa, visando manter o sigilo requerido das informaes.

294

A empresa passou a implementar as recomendaes. O grupo de garantia da qualidade no acompanhou a implementao das recomendaes, pois esta atividade no fazia parte do escopo do trabalho, no entanto, o grupo atuou esclarecendo dvidas e propondo solues. Dentre as atividades j implementadas pela empresa esto: a elaborao de planos de projeto, garantia da qualidade e configurao; identificao e acompanhamento de riscos e recursos crticos computacionais; adoo de ferramentas para a gerncia de verso e mudanas, entre outras. Em reunies, a empresa declarou que considera que as recomendaes iro contribuir para seu trabalho e que no iro impactar negativamente a dinmica de trabalho. O resultado final foi entregue ao investidor para avaliao e continuidade dos trabalhos.

6.9 Consideraes Finais

O Guia XP-CMM2 foi aplicado de forma sistemtica em um projeto real. A implementao do Guia e anlise de resultados foram realizados atravs da abordagem de uso de um procedimento de garantia da qualidade aderente ao nvel 2 do CMM. A principal ferramenta para viabilidade da implantao e anlise de resultados foram as auditorias do grupo de garantia da qualidade, realizadas atravs de anlise de documentos e entrevistas aos membros da equipe do projeto. Os objetivos deste estudo declarados na Seo 6.1, foram considerados atendidos: Verificar se o Guia utilizvel no mundo real O guia foi aplicado a um projeto real e a uma empresa incubada. Nem todos os aspectos do Guia puderam ser testados devido a problema dos projetos, no entanto, a grande maioria foi adotada. Verificar se os benefcios declarados do uso de XP podem ser alcanados com as modificaes sugeridas pelo Guia e Verificar se um projeto XP perde a agilidade esperada se inserir prticas do CMM nvel 2

295

Como j mencionado, para as duas aplicaes do Guia XP-CMM2, as concluses obtidas, tanto pelo grupo de garantia da qualidade, quanto pela equipe do projeto que o Guia no afetou negativamente a dinmica de trabalho. O formalismo adicionado ao projeto se deu essencialmente no nvel gerencial e em pouco impactou o trabalho da equipe como um todo. O projeto no perdeu a dinmica proposta por XP: as iteraes curtas, releases freqentes, reunies dirias, integrao contnua, programao em pares contribui para a comunicao e motivao da equipe. As mudanas s iteraes no sofreram nenhum impacto. Mudanas aos releases, considerados escopo do projeto, passaram a ser feitas atravs de solicitao de mudanas, tratadas nas reunies de planejamento das iteraes. A KPA que mais alterou o trabalho da equipe foi a de gerncia de configurao. No entanto, o resultado positivo obtido com a aplicao das prticas sugeridas pelo Guia XP-CMM2 indicou que as mudanas realizadas foram consideradas necessrias e benficas pela equipe. Verificar se possvel conviver em um mesmo ambiente com XP e com o nvel 2 do CMM e Benefcios de aplicar a abordagem do nvel 2 do CMM em um projeto XP O Guia XP-CMM2, com prticas do CMM e de XP, propiciou vrios benefcios ao projeto. O gerenciamento passou a ser mais eficaz e visvel atravs da identificao de riscos, maior envolvimento da alta gerncia, plano contemplando todos os principais aspectos do projeto e planejamento de revises formais. Os problemas de gerenciamento de configurao foram consideravelmente diminudos e o processo se tornou mais visvel para toda a equipe. A gesto de escopo passou a ser uma preocupao da equipe. Averiguar a dificuldade em assimilar prticas do nvel 2 do CMM em um projeto com cultura XP A maior dificuldade na implantao do Guia XP-CMM2 foi a implementao de um sistema de gesto de escopo. Este problema foi aumentado por problemas internos do projeto, como a substituio do gerente do projeto, e relao com o cliente do governo. A elaborao e uso de planos no caracterizaram overhead para a equipe. As prticas de gesto, apesar de nem todas implementadas, foram consideradas necessrias por todos os envolvidos no estudo. 296

7 Concluses e Trabalhos Futuros

Este trabalho foi motivado especialmente pela busca de respostas em relao aos mundos das metodologias geis e dos modelos de qualidade: se eles poderiam conviver num mesmo ambiente e, em especial, se seria possvel obter benefcios destes dois mundos. Para isto foram estudados a fundo a metodologia gil mais conhecida e utilizada atualmente, XP, e o nvel 2 do CMM. Um Diagnstico XP-CMM2 foi realizado, para identificar a aderncia de XP ao nvel 2 do CMM. Depois, para os problemas identificados, solues foram propostas, resultando no Guia XP-CMM2. Finalmente, o Diagnstico XP-CMM2 e o Guia XPCMM2 foram utilizados em projetos reais. O uso do Diagnstico XP-CMM2 e do Guia XP-CMM2 em projetos reais mostrou que possvel se beneficiar dos mundos XP e nvel 2 do CMM, que eles podem conviver em um mesmo ambiente, desde que ajustes sejam realizados, e que eles realmente se complementam. As concluses deste trabalho esto descritas neste captulo, que est organizado da seguinte forma: Seo 7.1 Principais Contribuies: relaciona as principais contribuies resultantes deste trabalho; Seo 7.2 Dificuldades Encontradas: relata quais foram as principais dificuldades encontradas para a realizao do trabalho; Seo 7.2.5 Trabalhos Relacionados: descreve trabalhos relacionados a este; Seo 7.3 Artigos Publicados: descreve os artigos publicados, frutos deste trabalho; Seo 7.4 Trabalhos Futuros: descreve trabalhos que podem ser realizados tendo como base o presente trabalho.

297

7.1 Principais Contribuies

A primeira grande contribuio deste trabalho se deu na interpretao do atendimento de XP ao nvel 2 do CMM, o que resultou no Diagnstico XP-CMM2. O Diagnstico XP-CMM2 foi realizado de forma aprofundada, objetivando seguir o mesmo rigor aplicado em uma avaliao oficial do SEI para determinar o nvel de maturidade de uma organizao. Assim, o Diagnstico XP-CMM2 considerou os elementos de mais baixo nvel do CMM, que so as prticas e subprticas. Em relao a XP, o estudo tambm se deu de forma aprofundada. O diagnstico considerou alm das prticas, princpios e valores de XP, aspectos inseridos no dia-a-dia de projetos como as reunies dirias. O Diagnstico XP-CMM2 contribuiu para definir a distncia entre o nvel 2 do CMM e XP, at ento somente comparados em nveis mais altos do CMM e de XP [31]. Outra contribuio foi o Guia XP-CMM2, que define um caminho para utilizar XP de forma a estar aderente ao nvel 2 do CMM. Com este guia, empresas que possuem foco na entrega rpida de software e em produtividade, e que comumente possuem interesse em utilizar metodologias geis como XP, podem selecionar as prticas do nvel 2 do CMM que desejam implementar, contribuindo para aumentar a confiana na metodologia utilizada. Empresas que possuem o interesse primordial de seguir modelos de qualidade amplamente reconhecidos mundialmente, como o CMM, podero utilizar XP em projetos menores, menos crticos, ou em projetos que se espera uma agilidade maior. Juntamente com a diretriz para utilizar XP e CMM nvel 2 em um mesmo ambiente, o Guia XP-CMM2 sugere templates e ferramentas para facilitar seu uso. A aplicao do Diagnstico XP-CMM2 e do Guia XP-CMM2 a projetos reais ofereceu a possibilidade de avaliar os resultados de se empregar as abordagens de desenvolvimento gil sendo representado por XP e de modelos de qualidade representado pelo nvel 2 do CMM em um mesmo ambiente. Esta aplicao mostrou os ganhos, as perdas e as dificuldades em se trabalhar com estes dois fundamentos.

7.2 Dificuldades Encontradas

Vrias dificuldades foram encontradas e enfrentadas durante o desenvolvimento deste trabalho. As prximas sub-sees iro detalhar estas dificuldades.

298

7.2.1 Falta de Rigor de XP

XP defende a informalidade para o processo de desenvolvimento e tambm o aplica na sua prpria definio. No h a baseline XP, ou a verso mais atual de XP, como no RUP, por exemplo. XP definida em livros, que muitas vezes se contradizem. Para citar um exemplo, Beck et al afirma que em materiais velhos de XP2 costumava-se utilizar um fator de carga para apoiar o planejamento e estimativa, mas que isto no deve mais ser utilizado [24]. De fato, os materiais velhos de XP que citam este fator de carga so os primeiros livros de XP (como [25], [39]). Para saber que este fator de carga no mais utilizado nas estimativas deve-se ler o ltimo livro de XP publicado por Beck, no entanto este ltimo livro no se prope a descrever uma nova verso de XP, mas abordar de forma mais especfica o planejamento num projeto XP. As contradies, ou interpretaes, de XP dificultaram a realizao do Diagnstico XP-CMM2, que foi elaborado de forma sistemtica e o mais fiel possvel ao CMM e a XP.

7.2.2 Trabalho Interpretativo

A elaborao do Diagnstico XP-CMM2 e as solues propostas pelo Guia XPCMM2 so baseadas fundamentalmente em interpretao. O modelo CMM um guia para melhoria de processos das organizaes, elaborado de forma a ser aplicado em organizaes de diferentes tamanhos e culturas [32]. Portanto, foi elaborado visando ser abrangente e genrico. Alm disto, o que se estava comparando XP e CMM possuem essncias diferentes. As premissas so diferentes. Como exemplo, o CMM considera que qualidade do produto obtida a partir da qualidade no processo. XP, em vrios momentos refuta esta idia. Alm disto, o CMM e a engenharia de software de uma forma geral, consideram que o custo para realizar uma mudana aumenta consideravelmente com o passar do tempo. XP parte do princpio que isto no verdade (conforme detalhado no Captulo 2, na Seo 2.3.3, Figura 2-1 Curva do Custo da Mudana).

Do ingls old stuff

299

Os vocabulrios de XP e CMM so diferentes, assim, para citar alguns exemplos, gerente do projeto para o CMM tracker para XP, plano para XP completamente diferente de plano para o CMM, XP no menciona alta gerncia em seus projetos. Decises baseadas em interpretao so mais difceis de serem realizadas que decises baseadas em fatos. O embasamento deve ser maior, as consideraes devem ser abrangentes, a argumentao deve ser documentada, para que justifique as decises, conforme realizado nos Captulos 4 e 5 deste trabalho. Interpretao de produtos essencialmente diferentes como XP e CMM so ainda mais difceis. Neste contexto, importante ressaltar a experincia e base utilizada pela aluna para realizar os julgamentos necessrios: treinamento no mtodo oficial do SCE [34], participao da equipe de implementao do nvel 2 na empresa C.E.S.A.R [52], participao da equipe de avaliao oficial que reconheceu o nvel 2 do C.E.S.A.R em Junho de 2003.

7.2.3 Descaracterizao de XP
Um dos objetivos do Guia XP-CMM2 era propor solues que no descaracterizassem XP. Caso contrrio, provavelmente os benefcios da adoo da metodologia gil XP no seriam obtidos. H bastante literatura disponvel [10] a respeito de solues empregadas para atender o CMM, no entanto, grande parte delas poderiam ferir os objetivos e a essncia de XP. Um exemplo a prtica de estimativa de tamanho para os principais produtos de trabalho e atividades requerida pelo CMM (SPP.Ac9). Apesar de o Diagnstico XPCMM2 considerar que esta prtica no atendida por XP, o Guia XP-CMM2 no recomendou alteraes. Isto porque a forma como as estimativas so realizadas em XP agregam diversos valores e princpios da metodologia, como assumir responsabilidade, coragem, fundamentada no feedback, opo pela simplicidade e outras. Alm disto, o estudo de caso demonstrou a efetividade das estimativas como so propostas por XP. A deciso de no sugerir uma soluo para a no satisfao da prtica SPP.Ac9 foi a mais difcil, demorada e estudada deste trabalho, j que iria ferir uma das prticas do CMM. No entanto, a identificao de outras solues tambm constituram um grau elevado de dificuldade.

300

7.2.4 Aplicao em um Projeto Real

Apesar de trabalhar em uma empresa que adota o CMM como fundamento para a realizao de projetos de software e que possui interessados em XP, a aplicao de todo o Guia XP-CMM2 em um projeto real constituiu uma dificuldade deste trabalho. Mesmo havendo um projeto selecionado para utilizar o Guia XP-CMM2, sua aplicao se deu com restries. Primeiramente restries polticas: templates e algumas prticas sugeridas no puderam ser utilizados, j que o projeto deveria seguir o processo padro da organizao. Alm disto, o projeto selecionado enfrentou diversas dificuldades ao longo do estudo (conforme descrito no Captulo 6), o que comprometeu seu poder de assimilar o Guia XP-CMM2. Alm disto, o objetivo de implementao de todo o Guia XP-CMM2 demandaria tempo para institucionalizao. Como se sabe, inserir novos processos, mudar cultura, transformar aes dispersas em sistematizao um trabalho rduo e duradouro. O tempo dedicado ao estudo, apesar de relativamente longo, no foi suficiente para implantar e institucionalizar todo o Guia XP-CMM2.

7.2.5 Trabalhos Relacionados

Conforme mencionado no Captulo 1, Mark Paulk publicou um artigo descrevendo como XP atenderia ao CMM [31]. Esta anlise foi realizada tomando como base as metas do CMM, para todos os nveis do CMM. As metas so um componente de mais alto nvel que as prticas e sub-prticas, utilizadas como base para a comparao do Diagnstico XP-CMM2. Apesar de as prticas e subprticas no serem elementos normativos do CMM (no so utilizados para determinar nvel de maturidade, por exemplo), este trabalho optou por utiliz-los, pois, como j citado, eles so a base para investigao de dados em uma avaliao oficial. Assim, a utilizao dos componentes prticas e subprticas, aprofunda o estudo de comparao entre XP e CMM, alm se assemelhar a uma avaliao oficial. Assim como Paulk, Antonio Bonato publicou um artigo comparando XP ao CMM, em seus diversos nveis [1], tomando como base o componente metas. Bonato conclui que XP atende a boa parte das KPAs do nvel 2 e 3 do CMM, isto quando se faz uma leitura menos rigorosa destas KPAs, usando-se o bom senso. Neste trabalho, a

301

essncia da anlise tambm se deu tomando como base as metas do CMM e no os elementos prticas e sub-prticas. Jonas Martinsson, elaborou um trabalho de dissertao com o objetivo de amadurecer XP (tornar XP mais prximo do CMM) sugerindo alteraes de forma a atender as metas das KPAs de todos os nveis do CMM [23]. Neste trabalho, Martinsson indica que apenas duas metas da KPA SQA deixam de ser atendidas no nvel 2. Por isto, sugere pequenas alteraes em XP, de forma a contemplar o papel de SQA. A diferena de resultados entre o trabalho de Martinsson e este trabalho pode ser justificada pela diferena entre os componentes utilizados para a comparao entre XP e CMM: no trabalho de Martinsson as metas e neste trabalho as prticas e sub-prticas. Nawrocki et al, relacionaram XP e CMM, mas no de forma a torn-los complementares, como este trabalho. O trabalho define um modelo de maturidade para XP [17], indicando como amadurecer seu uso.

7.3 Artigos Publicados

Como frutos deste trabalho, dois artigos foram publicados relatando experincias adquiridas a partir do uso de XP relacionadas a fundamentos da engenharia de software e CMM. O primeiro artigo, chamado O Impacto do Uso de Prticas de Metodologias geis de Desenvolvimento sobre a Gerncia de Projetos, escrito por Renata Endriss Carneiro Campelo, Cibele de Atade Feitosa e Teresa Maria de Medeiros Maciel, foi publicado no XIII Congresso Internacional de Tecnologia de Software, (CITS), realizado no ano de 2002, em Curitiba PR, Brasil. Este artigo relatou os benefcios obtidos pela gerncia de um projeto real atravs do uso de XP [37]. O artigo O Uso de Extreme Programming em uma Organizao CMM Nvel 2 descreveu resumidamente o estudo de caso relatado no Captulo 6. O artigo foi apresentado no II Simpsio Brasileiro de Qualidade de Software, realizado em Fortaleza CE, Brasil, em setembro de 2003 e foi escrito por Renata Endriss Carneiro Campelo, Fbio Gomes Silva (lder tcnico do projeto) e Hermano Perrelli de Moura [38].

302

7.4 Trabalhos Futuros

Este trabalho pode ser estendido de vrias formas visando aumentar a contribuio para as reas de engenharia de software e qualidade de software e para a comunidade de software, que deseja se beneficiar dos mundos das metodologias geis e dos modelos de qualidade. Alguns trabalhos sugeridos so: Realizar este trabalho utilizando o CMMI como modelo de referncia. Esta opo no foi considerada para este trabalho porque o framework do CMMI (com seus modelos e mtodo de avaliao) foi lanado aps o incio deste trabalho. Alm disto, o SEI indica que o SW-CMM um modelo que ainda ser utilizado durante cerca de dois anos; Implementar uma ferramenta que suporte o Guia XP-CMM2. O Guia XP-CMM2 sugere templates e ferramentas, no entanto uma ferramenta que implementasse todos, ou a maioria dos aspectos do guia facilitaria bastante a sua adoo e, provavelmente, aumentaria a produtividade da equipe. Uma possibilidade estender ferramentas j existentes, como a XPlanner [51]; Realizar este trabalho para a KPA Software Product Engineering (SPE), do nvel 3 do CMM. Esta KPA est diretamente relaciona ao desenvolvimento do produto final, o software. Assim, define prticas para elicitar, documentar e validar requisitos; realizar testes unitrios, de integrao de sistema e aceitao; projetar o software; implementar e outras. Esta KPA possui vrias intersees com XP. O trabalho de realizar um diagnstico e propor solues para os pontos falhos poderia ser bastante til para a comunidade XP identificar o que se espera das prticas de desenvolvimento do ponto de vista de um modelo de qualidade como o CMM; Da mesma forma que o item acima, a realizao deste trabalho para a prtica Peer Review (PR) do nvel 3 do CMM poderia apresentar um grande ganho para os interessados em adotar CMM e XP. A prtica programao em pares de XP muitas vezes apontada como suficiente para atender a KPA PR. No entanto, um

303

estudo detalhado poderia contribuir para a melhoria da sistemtica das revises em pares de XP e o entendimento do que se espera de revises em pares por modelos de qualidade como o CMM.

7.5 Consideraes Finais

Cada vez mais a comunidade de software vem aceitando, entendendo e aplicando metodologias geis. Elas se mostram uma alternativa vivel especialmente para grupos e organizaes pequenas, por serem muito fceis de implantar e de ter seus conceitos disseminados por toda a equipe. Apesar disto, notrio a falta de tratamento de aspectos relevantes do desenvolvimento de software por grande parte destas metodologias. A combinao das metodologias geis com estes aspectos, seja com base em um modelo de qualidade como o CMM, seja com base nos resultados difundidos da engenharia de software, se mostra uma soluo factvel e vivel para diversos ambientes de desenvolvimento.

304

Referncias

[1]

A. Bonato, Extreme Programming e Qualidade de Software, Congresso Brasileiro Extreme Programming Brasil (http://www.xispe.com.br/evento2002/index2.html, ltimo acesso em 13/10/2003), Dezembro de 2002.

[2] [3] [4] [5] [6]

A. Cockburn, Writing Effective Use Cases, Primeira Edio, Addison-Wesley, 2000. A. Leon, A Guide to Software Configuration Managemen, Artech House, Abril de 2000 A.W. Morales, Going to Extremes, Software Development Magazine, Janeiro de 2002. C.H.P. Mello et al, ISO 9001:2000: Sistema de Gesto da Qualidade para Operaes de Produo e Servios, So Paulo, Atlas, 2002. CMMI for Software Engineering, Version 1.1, Continuous Representation (CMMI-SW, V1.1, Continuous), Technical Report CMU/SEI-2002-TR-028, Agosto de 2002.

[7]

CMMI for Software Engineering, Version 1.1, Staged Representation (CMMISW, V1.1, Staged), Technical Report, CMU/SEI-2002-TR-029, Agosto de 2002.

[8] [9]

D. Bellin et al, The CRC Card Book, Addison-Wesley, Junho de 1997. D. Zubrow et al, Maturity Questionnaire, Technical Report, CMU/SEI-94-SR-7, Junho 1994.

[10] D.J. Reifer, XP and the CMM, IEEE Software, vol. 20, no. 3, Maio de 2003. [11] F. Paul Clipp III, Total Quality Management, The National Management Association, 1990.

305

[12] G. Booch, Object Solutions Managing the Object Oriented Project, AddisonWesley, 1995. [13] I. Graham, Requirements Engineering and Rapid Development: An ObjectOriented Approach, Addison-Wesley, Junho 1999 [14] I. Sommerville, Software Engineering, Fifth Edition, Addison-Wesley, 1995. [15] IEEE Standards Collection: Software Engineering, IEEE Standard 610.12-1990, IEEE, 1993. [16] J. Grenning, Launching Extreme Programming at a Process-Intensive Company, IEEE Software, vol. 18, No. 6, Novembro 2001. [17] J. Nawrocki et al, Toward Maturity Model for eXtreme Programming, Poznan University of Technology, 60-965 Poznan, Poland. [18] J. Rasmusson, Introducing XP into Greenfield Projects: Lessons Learned, IEEE Software, vol. 20, no. 3, Junho de 2003. [19] J.A. Highsmith, Agile Software Development Ecosystems, Addison-Wesley, 2002. [20] J.H. Johnson, Micro Projects Cause Constant Change, XP 2001 Conference, http://www.xp2003.org/conference/program.html (ltimo acesso em 14/10/2003). [21] J.R. Nawrocki et al, Comparison of CMM Level 2 and eXtreme Programming, Quality Connection - 7th European Conference on Software Quality, Helsinki (Finland), Junho de 2002. [22] J.T. Nosek, The case for collaborative programming, Communications of the ACM, vol. 41, No. 3, 1998. [23] Jonas Martinsson, Maturing Extreme Programming Through the CMM, Masters Thesis in Computer Science, Outubro de 2002, CODEN: LUNDFD6/NFCS/NFCS-5248/135/2002, Department of Computer Science, Lund University, Lund, Sweden. [24] K. Beck et al., Planning Extreme Programming, Addison-Wesley, 2000. [25] K. Beck, Exteme Programming Explained: Embrace change, Addison-Wesley, 1999.

306

[26] L. Williams et al., Strengthening the case for pair programming, IEEE Software, vol. 17, No. 4, 2000. [27] M. Fowler et al, Put Your Process on a Diet, Software Development Magazine, Dezembro de 2000. [28] M. Fowler et al., The Agile Manifesto, Software Development Magazine, Agosto de 2001. [29] M. Fowler, UML Destilled: A Brief Guide to the Standard Object Modeling Language, 2nd Edition, Addison-Wesley, 1999. [30] M.C. Paulk et al., The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, 1995. [31] M.C. Paulk, Extreme Programming from a CMM Perspective, IEEE, vol. 18, Novembro 2001. [32] M.C. Paulk, Using the Software CMM in Small Organizations, The Joint 1998 Proceedings of the Pacific Northwest Software Quality Conference and the Eighth International Conference on Software Quality, Portland, Oregon, 1314 Outubro de 1998, pp. 350-361. [33] M.C. Paulk, Using the Software CMM With Good Judgment, ASQ Software Quality Professional, vol. 1, no. 3, Junho de 1999. [34] P. Byrnes et al, Software Capability Evaluation, version 3.0, Technical Report, CMU/SEI-96-TR-002, ESC-TR-96-002, Abril de 1996. [35] P. Krunchten, The Rational Unified Process: an introduction, Addison-Wesley, 1998 [36] P. Schuh, Recovery, Redemption, and Extreme Programming, IEEE Software, vol. 18, No. 6, Novembro de 2001 [37] R. Endriss et al, O Impacto do Uso de Prticas de Metodologias geis de Desenvolvimento sobre a Gerncia de Projetos, II Simpsio Brasileiro de Qualidade de Software, Setembro de 2003, Fortaleza CEAR, Brasil. [38] R. Endriss et al, O Uso de Extreme Programming em uma Organizao CMM Nvel 2, Congresso Internacional de Tecnologia de Software 2002 (CITs 2002), Junho de 2002, Curitiba Paran, Brasil. [39] R. Jeffries et al, Extreme Programming Installed, Addison-Wesley, 2000. 307

[40] R.S. Pressman, Software Engineering: A Practitioners Approach, Fourth Edition, McGraw-Hill, 1997. [41] Software Engineering Institute, CMM-Based Appraisal, Software Capability Evaluation, V3.0, Team Training Reference Materials Notebook, presented by Integrated System Diagnostics. [42] The Standish Group, Extreme CHAOS 2001, February 2001. [43] W.S. Humphrey, Managing the Software Process, Addison-Wesley, 1989. [44] Web site Agile Alliance, http://www.agilealliance.org/ (ltimo acesso em 13/10/2003). [45] Web site An International Collaboration to Develop a Standard on Software Process Assessment, http://www.sei.cmu.edu/iso-15504/ (ltimo acesso em 13/10/2003). [46] Web site Bugzilla, http://bugzilla.mozilla.org/ (ltimo acesso em 13/10/2003). [47] Web site CMMI, http://www.sei.cmu.edu/cmmi/ (ltimo acesso em 13/10/2003). [48] Web site Crystal Methodologies, http://crystalmethodologies.org/ (ltimo acesso em 13/10/2003). [49] Web site CVS, , http://www.cvshome.org/ (ltimo acesso em 13/10/2003). [50] Web site da ferramenta Ant, http://ant.apache.org/ (ltimo acesso em 13/10/2003). [51] Web site da ferramenta XPlanner, http://www.xplanner.org/ (ltimo acesso em 13/10/2003). [52] Web site do C.E.S.A.R, http://www.cesar.org.br (ltimo acesso em 13/10/2003). [53] Web site Extreme Programming: A gentle introduction, http://www.extremeprogramming.org (ltimo acesso em 13/10/2003). [54] Web site IEEE, http://www.ieee.org/ (ltimo acesso em 13/10/2003). [55] Web site Integrated System Diagnostics Brasil, http://www.isdbrasil.com.br/ (ltimo acesso em 13/10/2003). [56] Web site ISO International Organization for Standardization, http://www.iso.ch/, (ltimo acesso em 13/10/2003).

308

[57] Web site Poznam University of Technology, http://www.cs.put.poznan.pl (ltimo acesso em 13/10/2003). [58] Web site Project Management Institute, http://www.pmi.org/ (ltimo acesso em 13/10/2003). [59] Web site Rational Software, http://www.rational.com/ (ltimo acesso em 13/10/2003). [60] Web site Software Engineering Institute, http://www.sei.cmu.edu (ltimo acesso em 13/10/2003). [61] Web site The Standish Group, http://www.standishgroup.com/ (ltimo acesso em 13/10/2003). [62] Web site XProgramming.com, http://www.xprogramming.com (ltimo acesso em 13/10/2003).

309

Apndice A Relatrio de Auditoria da Unidade de Negcio

Diagnstico de Processos
Tempest

Dados do Diagnstico Projetos Matrix e Piloto Ita Maio de 2003 Renata Endriss, Engenheira de Qualidade do C.E.S.A.R Antonio do Rego Valena, Gerente de Tecnologia do C.E.S.A.R Cristiano Lincoln Mattos, Gerente do Projeto Matrix Filipe Antnio Gensio Pessoa, Gerente de Cooperao do C.E.S.A.R Teresa Maria de Medeiros Maciel, Gerente de Qualidade do C.E.S.A.R

Escopo: Perodo: Auditor: Destinatrios:

1.

Objetivo O diagnstico realizado objetiva a avaliao da aderncia dos processos e prticas

adotados nos projetos Matrix e Piloto Ita, da Tempest, em relao s principais prticas

310

das seguintes reas chaves de processo do nvel 2 e 3 do CMM [30]: Gerenciamento de Requisitos, Planejamento de Projetos, Acompanhamento de Projetos, Gerncia de Configurao e Engenharia do Produto de Software. A rea chave Gerncia de Subcontrato no foi contemplada neste diagnstico, pois os projetos no realizam subcontratam produtos e/ou servios que impactem o desenvolvimento do software. 2. Contexto O projeto Matrix tem como objetivo apoiar a administrao de redes, automatizando processos que garantam a segurana do ambiente. A equipe composta de trs desenvolvedores, sendo um deles responsvel por assumir os papis de cliente (especificando os requisitos do sistema e realizando testes de aceitao), gerente do projeto e arquiteto. O projeto Matrix foi iniciado em setembro de 2002 e est planejado para encerrar em dezembro de 2003. O objetivo do subprojeto Piloto Ita foi desenvolver extenses ao Matrix que atendessem as necessidades do Banco Ita, e demonstrar o sistema no seu ambiente. O Piloto Ita iniciou em novembro de 2002 e foi encerrado em maro de 2003. O piloto foi aceito pela equipe do Ita, e esto sendo negociadas formas de extenso. Os projetos utilizam como base a metodologia de desenvolvimento de software Extreme Programming (XP) [25]. 3. Mtodo Este diagnstico foi conduzido por Renata Endriss atravs de entrevistas com representantes das equipes dos projetos, anlise de documentos produzidos pelo projeto e procedimentos documentados. Os seguintes documentos foram utilizados como base para realizao do diagnstico:
[1] M.C. Paulk et al., The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley Pub Co, 1995 [2] K. Beck, Exteme Programming Explained: Embrace change, Addison-Wesley Pub Co, 1999

Alguns produtos gerados pelos projetos foram analisados, dentre eles:

[3] Ferramenta XPlanner do projeto

311

[4] Planilha de Acompanhamento [5] Ferramenta Twiki do projeto [6] Documento Descrio Tecnolgica Matrix

2 2.1

Resultados Boas Prticas

Gerenciamento de Requisitos 2.1.1 Os requisitos so documentados atravs de estrias e tarefas, em cartes de papel (como prev a metodologia XP) e na ferramenta XPlanner [3]. Requisitos so revisados por toda a equipe nas reunies de planejamento de release e de iterao. 2.1.2 2.1.3 Mudanas aos requisitos no so implementadas sem controle: elas so avaliadas nas reunies de planejamento de release e de iterao, por todos da equipe. Planejamento do projeto e produtos gerados so elaborados sobre os requisitos do release e da iterao. Planejamento e Acompanhamento de Projetos 2.1.4 O planejamento dos projetos realizado atravs de um plano de releases, que contempla as datas dos releases, iteraes do prximo release, requisitos (estrias) de cada iterao e estimativas. Alm disto, em documentos diversos h descries sobre o que cada projeto. 2.1.5 Estimativas de esforo so realizadas por toda a equipe para cada tarefa da iterao, que possui uma granularidade de forma a maximizar a preciso das estimativas. As estimativas de esforo so acompanhadas diariamente e nas reunies de planejamento da iterao. 2.1.6 Um cronograma elaborado para as iteraes, que possuem tempo fixo: trs semanas. As atividades e responsveis por execut-las so discriminadas para cada iterao. 2.1.7 Os projetos possuem forte acompanhamento atravs de reunies dirias, iteraes e releases curtos. Gerncia da Configurao

312

2.1.8

Os projetos utilizam o CVS como repositrio para arquivos que compem o software (cdigo e arquivos XML).

Engenharia do Produto de Software 2.1.9 A arquitetura de alto nvel elaborada pelo arquiteto com o apoio dos demais membros da equipe. A arquitetura reflete os requisitos de alto nvel do sistema. 2.1.10 O cdigo atualizado e melhorado atravs de constantes refactorings, realizados sobre a arquitetura do sistema. 2.1.11 Testes unitrios so realizados pelo responsvel de cada estria. 2.2 Desvios de Processo de Software

Gerenciamento de Requisitos 2.2.1 O escopo completo do projeto no est documentado. Apenas os requisitos funcionais da prxima entrega so documentados. Risco: No haver visibilidade sobre o escopo do projeto como um todo. No haver entendimento comum e acordo entre os interessados no projeto sobre o escopo do projeto. Mudanas de mais alto nvel no podem ser controladas e ter seu impacto avaliado se o escopo no definido. 2.2.2 No h um documento de referncia para os requisitos no funcionais do sistema, critrios de aceitao dos requisitos, requisitos no tcnicos. Risco: O software final no contemplar os requisitos no funcionais do sistema. No haver clareza sobre o atendimento aos requisitos. 2.2.3 No h registro sobre as mudanas nos requisitos do projeto. Risco: No haver visibilidade sobre o progresso do projeto. Se o replanejamento e mudanas no so registradas, no h como ter visibilidade sobre os motivos que levam ao no cumprimento de compromissos estabelecidos, caso isto acontea. 2.2.4 Mudanas no so refletidas em todos os documentos dos projetos. Risco: Documentos desatualizados comprometem o acordo sobre compromissos do projeto, o controle sobre as mudanas, a linha de base para desenvolvimento, a integridade do sistema. Planejamento e Acompanhamento de Projetos

313

2.2.5

Os projetos possuem um plano de releases, que contempla as datas dos releases, iteraes do prximo release, requisitos (estrias) de cada iterao e estimativas de esforo. Este plano no contempla informaes importantes de planejamento de projetos, como: propsito, escopo, ciclo de vida, procedimentos adotados, artefatos a serem gerados, estimativas, riscos, equipe.

Risco: Falta de visibilidade dos principais interessados a respeito do projeto como um todo. Falta de base para acompanhar o projeto. Conhecimento das informaes do projeto apenas nas cabeas das pessoas, o que pode levar a falta de entendimento comum sobre o projeto. 2.2.6 2.2.7 Estimativas de esforo so realizadas, no entanto, estimativas de custo no so realizadas e acompanhadas. Recursos crticos computacionais no foram formalizadas e no so acompanhados nos projetos. Risco: O sistema no estar apto a entrar em execuo quando estiver pronto. 2.2.8 Premissas utilizadas nas estimativas no so documentadas. Risco: Impossibilidade de reconstruir as estimativas, caso seja necessrio realizar replanejamento. Gerncia da Configurao 2.2.9 Apesar de utilizar um repositrio para o cdigo, no h gerncia de configurao no projeto: no h plano de gerncia de configurao descrevendo itens de configurao, baselines, momento de entrada dos itens nas baselines, impacto das mudanas s baselines, entre outros. Risco: Falta de controle de mudanas, possibilidade de retrabalho, de falta de integridade entre os arquivos que compem o sistema. Engenharia do Produto de Software 2.2.10 A arquitetura do projeto est documentada em diversos documentos e no est sob gerncia de configurao. Risco: Inconsistncia entre cdigo e arquitetura, dificuldade para mant-la ntegra, caso precise ser alterada. 2.2.11 Casos de testes no so identificados e documentados. Risco: Testes no eficazes, produto que no atende aos requisitos. 314

2.2.12 No est formalizada a forma de registro e acompanhamento dos problemas encontrados nos testes de aceitao. Os problemas so registrados na ferramenta Twiki ou enviado por e-mail ao responsvel ou virar uma estria para a prxima iterao. Risco: Problemas identificados no serem corrigidos, no saber em que verso do produto o problema foi corrigido. 2.3 2.3.1 2.3.2 2.3.3 Oportunidades de Melhoria de Processo e Melhorias em Progresso Formalizar o padro de codificao utilizado no cdigo. Formalizar as revises em pares. Atualmente a equipe realiza inspees sobre cdigo de forma ad-hoc. Foi acordado recentemente que o membro da equipe que representa o cliente no projeto executa testes de aceitao no final das iteraes, no entanto, esta prtica ainda no est institucionalizada nos projetos. 4. Recomendaes
Item(ns) Atendido(s)

Recomendao

Elaborar um documento com o planejamento macro dos projetos, contendo: propsito, ciclo de vida, procedimentos adotados, artefatos a serem gerados, estimativas, riscos, recursos crticos computacionais, equipe e responsabilidades, planejamento de releases e iteraes, planejamento de testes, escopo, requisitos no funcionais, critrios de aceitao dos requisitos.

2.2.1, 2.2.7, 2.2.11, 2.2.2

Registrar as mudanas (motivo, impacto, histrico) realizadas 2.2.3, 2.2.4 no planejamento de releases, iteraes e requisitos. Definir um procedimento para isto e referenci-lo no Plano do Projeto. Definir procedimento para registro das mudanas e da realizao de testes de aceitao e referenci-lo no Plano do Projeto. Estimar e acompanhar custos dos projetos. Documentar as premissas das estimativas de esforo, custo e 2.2.6 2.2.8 315 2.2.3, 2.2.4, 2.2.12

recursos crticos computacionais. Planejar a gerncia de configurao nos projetos, definindo: Responsabilidades sobre a gerncia de configurao nos projetos Itens de configurao Baselines Momento de entrada dos itens de configurao nas baselines Procedimento para realizar mudanas aos itens de configurao e baselines SCCB (comit que avalia as mudanas) Documentar a arquitetura do sistema em um arquivo nico, que seja referncia para a equipe. Colocar este arquivo sob gerncia de configurao. Documentar como se daro os testes de aceitao, explicitando critrios de aceitao de testes e casos de testes. 2.2.11 2.2.10 2.2.9

316

Apndice B - Template do Plano do Projeto

Template do Plano do Projeto

Verso: <xx.xx> | Data: <xx/xx/xxxx>

317

Contedo
1. 1.1 1.2 2. 2.1 3. 4. 5. 6. 7. 7.1 7.2 8. 8.1 8.2 9. INTRODUO ..................................................................................................... 319 DEFINIES, ACRNIMOS E ABREVIATURAS ................................................... 319 REFERNCIAS ................................................................................................... 319 OBJETIVO , ESCOPO E METAS DO PROJETO ........................................... 319 CRITRIOS DE ACEITAO ............................................................................... 320 CICLO DE VIDA DO PROJETO ....................................................................... 320 PROCEDIMENTOS, MTODOS E PADRES ............................................... 320 PRODUTOS ........................................................................................................... 321 CUSTOS ................................................................................................................. 322 RECURSOS CRTICOS COMPUTACIONAIS................................................ 322 PROCEDIMENTO DE ESTIMATIVA DE RECURSOS CRTICOS COMPUTACIONAIS . 323 ESTIMATIVAS DE RECURSOS CRTICOS COMPUTACIONAIS ............................... 323 INSTALAES..................................................................................................... 323 HARDWARE ...................................................................................................... 323 SOFTWARE ....................................................................................................... 323 RISCOS DO PROJETO ....................................................................................... 325

318

Introduo <Descreva a introduo deste documento, o que o documento apresenta, seu

objetivo, escopo e metas. Alm disto, em que momentos dever ser aprovado. Exemplo abaixo> Este documento tem como objetivo definir os aspectos essenciais para acompanhamento do projeto. Dever ser aprovado por <incluir nomes dos responsveis e cargos - alta gerncia da organizao (gerncia snior), representantes dos grupos afetados, se houverem, e representantes do cliente > no incio do projeto e reaprovados nas seguintes situaes: 1.1 Desvio em 10% do cronograma ou custo do projeto A cada reunio de planejamento de release Definies, Acrnimos e Abreviaturas <Informe acrnimos, termos, abreviaes na tabela abaixo>
Acrnimo Descrio

1.2

Referncias [63] [64] [65] [66] Documento de Requisitos, verso <xx.yy>, <dd/mm/aaaa> XPlanner do Projeto, <site> Plano de Gerncia de Configurao, verso <xx.yy>, <dd/mm/aaaa> K. Beck et al., Planning Extreme Programming, Addison-Wesley, 2000.

Objetivo , Escopo e Metas do Projeto <Descreva o objetivo, escopo e metas do projeto. Alm disto, requisitos tcnicos e

no tcnicos do projeto> O objetivo deste projeto <informe o objetivo do projeto>.

319

2.1

Escopo Os requisitos detalhados do projeto e plano de entregas, esto descritos no

Documento de Requisitos [63]. Os macros requisitos funcionais deste projeto so: < descreva os requisitos funcionais macros do sistema> < descreva os requisitos no funcionais macros do sistema> <descreva o escopo negativo, ou seja, o que no est contemplado por este projeto> 2.2 Critrios de Aceitao <Descrever o critrio de aceitao que ser utilizado para validar que os produtos satisfazem os requisitos. Exemplos: Todos os testes de aceitao executados Todos os deliverables entregues Nenhum bug de severidade alta, que impede a execuo do projeto Nenhum bug, o qual a estimativa de resoluo seja de mais de 10 horas> Os macros requisitos no funcionais deste projeto so: No faz parte deste projeto:

Ciclo de Vida do Projeto O ciclo de vida do projeto definido como iterativo e incremental. O projeto

dividido em marcos, chamados releases. Cada release dividido em iteraes seqenciais, com <X> semanas de durao. O planejamento dos releases e iteraes est documentado no Documento de Requisitos [63].

Organizao do Projeto Esta seo descreve a organizao do projeto em termos de papis e

responsabilidades.

320

4.1

Organograma <Adicione o organograma do projeto, descrevendo tambm o organograma do

cliente, que ir interagir com o projeto> 4.2 Papis e Responsabilidades <Descreva os papis e responsabilidades dos envolvidos no projeto> 4.3 Equipe <Descreva a equipe do projeto e respectivos papis>

Procedimentos, Mtodos e Padres <Descreva todos os procedimentos, mtodos e padres adotados para desenvolver

e/ou manter o software. Apontar para livros XP, Guia XP-CMM2, ... Exemplo abaixo>
Procedimento/mtodo/padro Descrio Referncia

Padro de codificao

Padro utilizado para codificar software.

<indique qual o padro, aponte para uma referncia, ...>

Procedimento Estimativa

de

Procedimento realizar as estimativas estrias e tarefas.

para de

[66], cap. 12

Produtos Esta seo descreve os produtos a serem desenvolvidos pelo projeto, indicando os

produtos a serem entregues ao cliente. A gesto da configurao destes produtos descrita no Plano de Gerncia de Configurao do projeto [65]. <Insira outros produtos na tabela, conforme necessidades do projeto. Exemplo: manual do usurio, arquitetura, modelo de classes, modelo de dados, ... >

Produto

Descrio

Entregue

Plano do Projeto

Plano que descreve o planejamento 321

do

projeto

em

termos

de

recursos

computacionais crticos, equipe, objetivos do projeto, planejamento de instalaes, entre outros. Produzido no MS Word. Documento Requisitos de Descreve o planejamento de releases do projeto, indicando estrias (requisitos) a serem desenvolvidas por release e por iteraes. Build do Sistema Build do software rodando, com os requisitos Plano de Testes Cdigo fonte descritos no Documento de X X Requisitos implementados. Testes implementados na linguagem de desenvolvimento adotada. Cdigo fonte do sistema. X

Cronograma O cronograma de releases e iteraes est descrito no Documento de Requisitos

[63].

Custos <Referencie as estimativas de custos do projeto e planejamento de pagamento.

Alm disto, comunique quaisquer compromissos relevantes relacionados aos custos do projeto.>

Recursos Crticos Computacionais Esta seo descreve os recursos crticos computacionais identificados para o

projeto e as estimativas realizadas. Estes recursos sero acompanhados a cada iterao atravs do Documento de Requisitos [63]. 322

<Identifique os recursos crticos computacionais do projeto> 9.1 Procedimento de Estimativa de Recursos Crticos Computacionais <Descreva o procedimento utilizado para estimar os recursos crticos computacionais ou faa referncia ao documento que o descreva> 9.2 Estimativas de Recursos Crticos Computacionais <Descreva as estimativas e premissas utilizadas para estimar os recursos crticos computacionais>

10 Instalaes <Esta seo descreve as instalaes necessrias para execuo do projeto> 10.1 Hardware <Descreve o hardware necessrio para execuo do projeto>

Equipamento

Quantidade

Finalidade

10.2 Software <Descreve o software necessrio para execuo do projeto>

Software

Quantidade

Finalidade

11 Acompanhamento do Projeto <Esta seo descreve como o projeto ir ser acompanhado. A tabela abaixo sugere as reunies e contedo conforme o Guia XP-CMM2.> A tabela abaixo descreve as reunies a serem realizadas no projeto e respectivos participantes e contedo. 323

Reunio

Descrio

Pauta

Stand up meetings

Reunies desenvolvimento. A

dirias

Problemas de de e

tcnicos, implementao, configurao, andamento do

envolvendo toda a equipe de dificuldades ser problemas

realizada <informe horrio e pendncias de garantia da qualidade, local da reunio>. A reunio comunicao deve durar em mdia 15min. Reunio da iterao Reunio a ser realizada projeto. Da iterao passada: avalia estrias dos completadas, crticos gastos, recursos

de planejamento no primeiro dia da iterao para mtricas, planej-la. Participao de toda registro a equipe de desenvolvimento. avalia a iterao passada.

computacionais

Alm disto, esta reunio acompanhamento das estimativas. Da prxima iterao: estrias a serem implementadas, estimativas. Trata status das atividades de gerncia de configurao e garantia da qualidade. Acompanhamento de riscos. Reunio do release do Reunio a ser realizada prximo release Reavalia Plano do Projeto, de planejamento no incio do desenvolvimento riscos, Documento de Requisitos, para progresso do projeto, acompanha planej-lo. Participao de toda custos, compromissos. a equipe de desenvolvimento. Participao do gerente snior e representantes de alto nvel do cliente. Alm disto, esta reunio avalia o release passado.

324

12 Riscos do Projeto Esta seo referencia o documento que lista os riscos do projeto e descreve como eles sero acompanhados. A tabela abaixo relaciona os riscos identificados para o projeto.

Risco

Probabilidade3

Impacto4 Prioridade5 Aes de Contingncia

Status6

3 4 5 6

Probabilidade de o risco vir a ocorrer. Opes: Alta, Mdia ou Baixa Impacto do risco no projeto. Opes: Alta, Mdia ou Baixa Prioridade do risco. Deve ser baseado na probabilidade e impacto Status do risco e aes tomadas em relao a ele

325

Apndice C - Template do Documento de Requisitos

O template do Documento de Requisitos foi elaborado no MS Excel em trs planilhas. A Figura 4 exibe a planilha que a capa do Template do Documento de Requisitos.

Figura 4 - Capa do Template do Documento de Requisitos A Figura 5 exibe a planilha que lista as estrias do projeto e para cada uma uma breve descrio, estimativa inicial, o release e a iterao que a estria participa, o status da estria (Em andamento, No inicializada, Finalizada) e a estimativa final (complexidade da estria ao final da iterao). 326

Figura 5 - Planilha Estrias do Template do Documento de Requisitos A Figura 6 exibe o template para estimativa e acompanhamento dos recursos crticos computacionais. Para cada recurso crtico identificado, devem ser informados a estimativa inicial e o tamanho real ao final de cada iterao.

327

Figura 6 - Planilha Recursos Crticos do Template do Documento de Requisitos

328

Apndice D - Template do Plano de Gerncia de Configurao

Template do Plano de Gerncia de Configurao

Verso: <xx.xx> | Data: <xx/xx/xxxx>

329

Contedo
1. 1.1 1.2 2. 3. 4. 4.1 5. 6. 7. 8. INTRODUO ......................................................................................................331 DEFINIES, ACRNIMOS E ABREVIATURAS ....................................................331 REFERNCIAS ...................................................................................................331 FERRAMENTAS ...................................................................................................331 BASELINES ...........................................................................................................332 CONTROLE DE VERSO...................................................................................332 ORGANIZAO DA FERRAMENTA DE CONTROLE DE VERSO ...........................332 CONTROLE DE MUDANA ..............................................................................332 RELEASES..............................................................................................................333 AUDITORIAS DE GERNCIA DE CONFIGURAO ..................................333 RELATRIOS DE GERNCIA DE CONFIGURAO .................................333

Introduo <Descreva a introduo deste documento, o que o documento apresenta, seu

objetivo, escopo e metas. Alm disto, em que momentos dever ser aprovado. Exemplo abaixo> Este documento tem como objetivo definir os aspectos essenciais para a gerncia da configurao do projeto. Dever ser aprovado por <incluir nomes dos responsveis e cargos gerente do projeto> no incio do projeto e reaprovados a cada release e nas seguintes situaes: Mudana nos itens de configurao do projeto, ferramentas e baselines do projeto 1.1 Definies, Acrnimos e Abreviaturas <Informe acrnimos, termos, abreviaes na tabela abaixo>
Acrnimo Descrio

SCM CR SCCB

Gerncia de Configurao de Software, do ingls Software Configuration Management Solicitao de mudana, do ingls Change Request Comit de controle de mudanas de software, do ingls Software Change Control Board

1.2

Referncias [67] Plano do Projeto, verso <xx.yy>, <dd/mm/aaaa>

Ferramentas <Descreva as ferramentas de configurao adotadas no projeto. A tabela abaixo

sugere algumas ferramentas>

Ferramenta Descrio

CVS Concurrent Version System WinCVS Bugzilla

Servidor da ferramenta de controle de verso. Cliente da ferramenta de controle de verso. Ferramenta de controle de 331

mudanas.

Baselines <Descreva as baselines adotadas no projeto. Abaixo, uma sugesto> Os itens de configurao selecionados, fazem parte de um subconjunto dos

produtos relacionados no Plano do Projeto [65], que atendem a um ou mais dos seguintes critrios: Produtos entregues ao cliente ou a outra organizao; Produtos considerados crticos para o projeto; Artefatos utilizados por mais de um grupo; Artefatos produzidos por terceiros, que sero incorporados ao projeto; Artefatos que, ao serem alterados, podem causar mudanas em outros artefatos associados.
Baseline Label Contedo (ICs) SCCB

Iterao_X

ITERACAO_X

Documento requisitos Cdigo fonte

de

Cdigo de testes

Controle de Verso <Descreva as principais consideraes a respeito do controle de verso no

projeto e padres adotados, se houverem> 4.1 Organizao da Ferramenta de Controle de Verso <Informe como a ferramenta de Controle de Verso estar organizada em termos de diretrios e seus contedos>

Controle de Mudana <Descreva brevemente como solicitar mudanas utilizando a ferramenta de

controle de mudanas e os padres adotados, se houverem >

332

Releases <Descreva o planejamento de releases. Indique os procedimentos para

realizao do release. Exemplo: Os releases do projeto sero realizados atravs do envio por e-mail de um arquivo compactado, .zip. Abaixo, uma sugesto> Os releases do projeto sero realizados de acordo com a tabela abaixo:
Release Contedo

Release Nmero <X>

<Informe os itens de configurao que devero fazer parte do release>

Auditorias de Gerncia de Configurao <Descreva brevemente como as auditorias de gerncia de configurao sero

realizadas no projeto. Abaixo, uma sugesto> Auditorias em gerncia de configurao sero realizados no perodo de <informar o perodo das auditorias>. A cada auditoria um relatrio ser gerado e enviado para todos da equipe atravs de e-mail. Um plano de ao para resolver os problemas identificados ser elaborado em conjunto com o gerente do projeto. O acompanhamento do plano de ao de responsabilidade de <informar o responsvel>

Relatrios de Gerncia de Configurao <Descreva os relatrios providos pela gerncia de configurao. Indique

contedo, pblico alvo, periodicidade. Abaixo, uma sugesto>

Relatrio Descrio Periodicidade Pblico alvo

Status das CRs

Obtido quantidade de

partir CRs

de

A cada equipe

Todos da

consulta ao bugzilla, relaciona iterao abertas, A cada fechadas e pendentes Relatrios Relatrio descrevendo os problemas identificados gesto de configurao Plano de Relatrio descrevendo o

Todos da

de auditoria

na <informe perodo>

o equipe Todos da

A cada

333

ao de auditoria status das aes do Plano de iterao Ao das auditorias de gerncia de configurao

equipe

334

335