Dissertacao BB Digital

Um modelo de referncia para o desenvolvimento gil
de software
Gustavo Vaz Nascimento
Orientadora: Profa. Dra. Rosely Sanches
Dissertao apresentada ao Instituto de Cincias Matem-
ticas e de Computao ICMC/USP, como parte dos re-
quisitos para obteno do ttulo de Mestre em Cincias de
Computao e Matemtica Computacional.
VERSO REVISADA APS A DEFESA
Data da Defesa: 13 de fevereiro de 2008
Visto do Orientador:
USP - So Carlos
Fevereiro/2008
Um modelo de referncia para o
desenvolvimento gil de software
Gustavo Vaz Nascimento
Agradecimentos
Agradecimentos iniciais a Deus, por me dar fora e sade para superar
as diculdades encontradas.
Agradecimentos a professora Rosely Sanches, por sua constante dispo-
sio, pacincia, sensatez, orientao e incentivo, em todos os momentos.
Agradecimentos a Wesley Peron Seno, por ter me dado a primeira opor-
tunidade prossional, pelo incentivo ao ingresso no mestrado e na vida aca-
dmica, e pela compreenso e apoio indispensveis para a realizao deste
trabalho.
Agradecimentos ao Instituto de Cincias Matemticas e de Computao
e a USP, pela excelncia em seus cursos de graduao e ps-graduao.
Agradecimentos imensurveis a meus pais Nelson e Luzia e a meus
irmos Elby e Samuel, que em todos os momentos me incentivaram e me
apoiaram nessa realizao.
Agradecimentos especiais e com muito carinho a minha amada esposa
Vivian. Agradeo-a pela pacincia, pela compreenso, pela dedicao e por
todo amor dispensado.
Agradecimentos nais a todos que, direta ou indiretamente, participaram
ou torceram pela nalizao de mais essa etapa.
i
Resumo
A crescente procura por software de qualidade vem causando grande
presso sobre as empresas que trabalham com desenvolvimento de software.
As entregas de produtos de software dentro do prazo e custo previstos vm
se tornando, a cada dia, um diferencial importante nesse ramo de atividade.
Nesse sentido, as empresas procuram por metodologias que propiciem o de-
senvolvimento de produtos com qualidade, e que respeitem o custo e prazo
previstos. Em resposta a essas necessidades, surgiu uma nova classe de me-
todologias de desenvolvimento de software, conhecidas como metodologias
geis.
Este trabalho apresenta um estudo realizado sobre as principais carac-
tersticas existentes nessa nova classe de metodologias. Uma anlise permi-
tiu a identicao de semelhanas e diferenas existentes entre elas, o que
possibilitou a criao de um modelo de referncia para o desenvolvimento
gil de software. O modelo foi utilizado em uma avaliao de processo ba-
seada no modelo de avaliao da ISO/IEC 15504. A avaliao permitiu a
identicao de foras e fraquezas no processo avaliado e possibilitou a de-
nio de aes de melhoria para que o processo avaliado se assemelhasse
um processo de desenvolvimento gil.
Palavra-chave: Metodologia gil de desenvolvimento. Modelo de refe-
rncia. Processo de desenvolvimento de software. Avaliao de processo de
software.
ii
Abstract
The vast demand for software with quality is causing a great pressure
on the companies which work with software development. The delivery of
software products within the schedule and cost is becoming, every day, an
important issue in this area. Therefore, companies are seeking for metho-
dologies to develop products with quality, within the timetable and the cost.
Considering these needs, it became a new class of software development
methodologies, known as agile methodologies.
This research shows a work done upon the main existing characteristics
in this new class of methodologies. An analysis allowed the identication
of the existing similarities and differences among them, which it made pos-
sible to create a new reference model for agile software development. The
agile model was used in process assessment based on assessment model from
ISO/IEC 15504. The assessment alowed a identication of power and weak-
ness on the process and alowed a denition of improvement action to the
process with the intention of to approach the agile development process.
Palavra-chave: Agile Methodology. Reference Model. Software Deve-
lopment Process. Software Process Assessment.
iii
Sumrio
Agradecimentos i
Resumo ii
Abstract iii
1 Introduo 1
1.1 Contextualizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Organizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Metodologias geis de desenvolvimento de software 4
2.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Conceitos envolvidos com as metodologias geis de desenvolvimento . . . . . . . 5
2.3 Metodologia Extreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Metodologia SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Metodologia Feature Driven Development . . . . . . . . . . . . . . . . . . . . . . 12
2.6 Metodologia Dynamic System Development Method . . . . . . . . . . . . . . . . . 14
2.7 Metodologia Adaptive Software Development . . . . . . . . . . . . . . . . . . . . 17
2.8 Metodologia Crystal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.9 Produzindo documentao de forma gil . . . . . . . . . . . . . . . . . . . . . . . 22
2.10 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3 Gerncia e planejamento de projetos 25
3.2 Tcnicas de auxlio gesto de projetos . . . . . . . . . . . . . . . . . . . . . . . 25
4 O norma ISO/IEC 15504 30
4.2 Introduo ao modelo de referncia ISO/IEC 15504 . . . . . . . . . . . . . . . . . 30
4.3 As cinco partes do modelo de referncia ISO/IEC 15504 . . . . . . . . . . . . . . 31
4.4 Consideraes nais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
iv
5 Uma proposta de um modelo de referncia para o desenvolvimento gil de software 38
5.2 Categorizao das metodologias geis . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3 Requisitos para um modelo de referncia de processo . . . . . . . . . . . . . . . . 41
5.4 Um modelo de referncia para o desenvolvimento gil de software . . . . . . . . . 42
5.4.1 Declarao do domnio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.4.2 Processos do modelo de referncia . . . . . . . . . . . . . . . . . . . . . . 42
5.4.3 Grupo de Processos de Inicializao (INI) . . . . . . . . . . . . . . . . . . 44
5.4.4 Grupo de Processos de Desenvolvimento Iterativo (DES) . . . . . . . . . . 54
5.4.5 Grupo de Processos de Operao (OPE) . . . . . . . . . . . . . . . . . . . 62
5.4.6 Grupo de Processos de Apoio (APO) . . . . . . . . . . . . . . . . . . . . 66
5.4.7 Relacionamentos entre os processos . . . . . . . . . . . . . . . . . . . . . 73
6 Estudo de caso 83
6.1 Consideraes iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.2 O processo de avaliao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.2.1 O processo de avaliao segundo a norma ISO/IEC 15504 . . . . . . . . . 84
6.3 Avaliao do processo de desenvolvimento do Centro de Informtica . . . . . . . . 85
6.3.1 Descrio do processo de desenvolvimento do Centro de Informtica . . . 85
6.3.2 O processo de avaliao documentado . . . . . . . . . . . . . . . . . . . . 86
6.3.3 Resultados da avaliao . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.4 Consideraes nais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7 Concluses e trabalhos futuros 96
7.1 Sntese do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.2 Contribuies do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
7.3 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
A Caractersticas chave dos produtos de trabalho 105
B Framework de medidas 112
B.1 Nveis de Capacidade de Processo . . . . . . . . . . . . . . . . . . . . . . . . . . 112
B.1.1 Nvel 0: Processo Incompleto . . . . . . . . . . . . . . . . . . . . . . . . 112
B.1.2 Nvel 1: Processo Executado . . . . . . . . . . . . . . . . . . . . . . . . . 113
B.1.3 Nvel 2: Processo Gerenciado . . . . . . . . . . . . . . . . . . . . . . . . 113
B.2 Avaliao dos Atributos de Processo . . . . . . . . . . . . . . . . . . . . . . . . . 113
B.2.1 Indcios de Atributos de Processo (IAP) . . . . . . . . . . . . . . . . . . . 113
B.2.2 Escala de classicao dos atributos de processo . . . . . . . . . . . . . . 114
B.3 Classicao dos atributos de processo . . . . . . . . . . . . . . . . . . . . . . . . 115
B.4 Modelo de nvel de capacidade de processo . . . . . . . . . . . . . . . . . . . . . 115
v
Lista de Figuras
2.1 Ciclo de vida de Extreme Programming (Abrahamsson et al., 2002) . . . . . . . . 8
2.2 Ciclo de vida de Scrum (Abrahamsson et al., 2002) . . . . . . . . . . . . . . . . . 11
2.3 Ciclo de vida de Feature Driven Development (Abrahamsson et al., 2002) . . . . . 12
2.4 Parte iterativa de Feature Driven Development (Abrahamsson et al., 2002) . . . . . 14
2.5 Ciclo de vida de Dynamic System Development Method (Abrahamsson et al., 2002) 15
2.6 Ciclo de vida Adaptive (Highsmith, 2000) . . . . . . . . . . . . . . . . . . . . . . 17
2.7 Atividades do ciclo de vida Adaptive (Highsmith, 2000) . . . . . . . . . . . . . . . 18
2.8 Categorias de projeto da metodologia Crystal (Abrahamsson et al., 2002). . . . . . 20
2.9 Um incremento de Crystal para equipes com mais de quarenta membros (Keith
Everette, 2006). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1 Exemplo de uma EAP para um projeto (Project Management Institute, 2004) . . . 26
3.2 Exemplo de um MDP que representa o sequenciamento de atividades (Project Ma-
nagement Institute, 2004) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Exemplo de um MDS que representa o sequenciamento de atividades (Project Ma-
4.1 Partes que compem a norma ISO/IEC 15504 . . . . . . . . . . . . . . . . . . . . 31
4.2 Nveis de capacidade e respectivos atributos de processo . . . . . . . . . . . . . . 32
4.3 Nveis de capacidade e respectivos signicados . . . . . . . . . . . . . . . . . . . 33
4.4 Dimenses do modelo de avaliao de processo . . . . . . . . . . . . . . . . . . . 33
4.5 Pontuaes sugeridas para os atributos de processo e seus respectivos signicados . 34
4.6 Pontuaes dos atributos de processo e respectivos nveis de capacidade . . . . . . 35
4.7 Estrutura do processo de avaliao . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1 Categorizao das metodologias geis de desenvolvimento. . . . . . . . . . . . . . 41
5.2 Grupos de processos do modelo de referncia gil e as interaes entre eles. . . . . 43
5.3 Grupos de processos do modelo de referncia gil e seus respectivos processos. . . 44
5.4 Template para um modelo de avaliao de processos (ISO/IEC, 2003d). . . . . . . 45
5.5 Exemplo de uma Lista de Estrias e de Requisitos No-funcionais j priorizada. . . 46
5.6 Template para a elaborao de um Plano Global para um projeto gil. . . . . . . . . 54
5.7 Template para a elaborao de um Plano para a Iterao. . . . . . . . . . . . . . . 56
5.8 Exemplo de um checklist para a padronizao e documentao do cdigo-fonte
(Microsoft, 2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.9 Template de um Plano de Implantao de Gerncia de Congurao. . . . . . . . . 67
vi
5.10 Conjunto mnimo de itens de congurao em um projeto gil e os respectivos
processos que os produzem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.11 Exemplo de um esquema de identicao com o conjunto mnimo de itens de
congurao exigidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.12 Conjunto mnimo de documentos que devem ser produzidos em um projeto gil e
os respectivos processos que os produzem. . . . . . . . . . . . . . . . . . . . . . . 69
5.13 Fatores de qualidade para as metodologias de desenvolvimento gil (Mnkandla e
Dwolatzky, 2006). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.14 Template para o plano de qualidade. . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.15 Representao das dependncias existentes entre os processos do modelo. . . . . . 73
5.16 EAP criada para o modelo de referncia gil. . . . . . . . . . . . . . . . . . . . . 74
5.17 Exemplo de um MDS que representa o sequenciamento de atividades (Project Ma-
5.18 MDS que representa o sequenciamento das atividades que ocorrem nos processos
do modelo de referncia gil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.1 Cronograma para a realizao da avaliao. . . . . . . . . . . . . . . . . . . . . . 89
6.2 EAP que representa o estado no qual o processo de desenvolvimento realizado pelo
CI foi encontrado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.3 Plano de implantao de gerncia de congurao. . . . . . . . . . . . . . . . . . 94
6.4 Relatrio de Apresentao de Resultados. . . . . . . . . . . . . . . . . . . . . . . 95
vii
Lista de Tabelas
5.17 Atividades necessrias para a produo dos produtos de trabalho . . . . . . . . . . 75
6.1 Mapeamento da dimenso de processos do Modelo de Avaliao para os processos
realizados pelo CI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.2 Processos avaliados e pontuaes dos atributos de processo. . . . . . . . . . . . . . 91
B.1 Modelo de nvel de capacidade de processo. . . . . . . . . . . . . . . . . . . . . . 116
viii
CAPTULO
1
Introduo
1.1 Contextualizao
A engenharia de software pode ser vista como um processo, composto de atividades e tarefas,
que abrange todos os aspectos da produo de software. Ela auxilia no desenvolvimento/evoluo
do software, fazendo com que sua construo seja realizada dentro de determinado custo, tempo,
escopo e qualidade (da Rocha et al., 2001).
Os processos de construo de software tradicionalmente utilizados, conhecidos como meto-
dologias tradicionais ou pesadas, so geralmente aplicados em situaes onde os requisitos do
sistema so estveis e requisitos futuros so previsveis. Tais processos possuem, como uma de
suas caractersticas, o alto custo para realizar alteraes e correes. Nessa forma de desenvolvi-
mento, o software todo planejado e documentado antes de ser implementado (Fowler, 2005).
Como alternativa s metodologias tradicionais, surgem as metodologias geis. Essa nova forma
de desenvolvimento visa a construo de software de forma rpida e consistente. Entre outros
aspectos, essa abordagem sugere a existncia de equipes pequenas e multidisciplinares, prazos
de entrega curtos e freqentes e ambientes de desenvolvimento dinmicos, onde a criatividade
e inovao so caractersticas imprescindveis. Tais metodologias possibilitam a realizao de
alteraes e correes dos requisitos de forma rpida e com baixo custo (Rodrigues et al., 2005;
dos Santos Soares, 2004).
Alguns conceitos envolvidos com metodologias geis diferem das metodologias tradicionais.
Segundo Rising (Rising, 2002):
1
CAPTULO 1. INTRODUO 2
[..] Algumas caractersticas das metodologias tradicionais entram em conito
com as atitudes geis. Por exemplo, a idia de que a maior qualidade do processo
acarreta a maior qualidade do produto no bem aceita pela comunidade gil. A
controvrsia est, na verdade, na importncia do processo.
Nas metodologias tradicionais, o foco est voltado para os processos. Segundo Pressman, em
(Pressman, 2006), um processo de software pode ser denido como
[..] uma seqncia coerente de prticas que objetiva o desenvolvimento ou evo-
luo de sistemas de software. Estas prticas englobam as atividades de espe-
cicao de requisitos, projeto, implementao e testes e caracterizam-se pela
interao de ferramentas, pessoas e metodologias.
Os adeptos das metodologias tradicionais acreditam que a melhoria e a denio do processo
utilizado tem inuncia direta no aumento da qualidade dos produtos (Corra et al., 2004; lawrence
Peeger, 2004).
Por outro lado, nas metodologias geis, o enfoque deixa de ser os processos e passa a ser as
pessoas. Essa mudana de enfoque aumenta a importncia das pessoas no processo de desenvol-
vimento, porm, os processos continuam a existir. Um aspecto importante que a interao entre
os membros da equipe de desenvolvimento e a atitude deles de suma importncia para essas
metodologias. Segundo Rodrigues, em (Rodrigues et al., 2005), esses aspectos so os maiores
determinantes do grau de sucesso de um projeto.
Para um processo ser considerado gil, ele deve realizar um conjunto de tarefas e seguir dis-
ciplinadamente um conjunto de regras, denidas pela metodologia. O no cumprimento dessas
premissas, muitas vezes, fazem com que um processo deixe de ser gil para tornar-se catico.
Portanto, o termo ser gil no signica negligenciar as atividades de engenharia de software, e
sim pratic-las de forma diferente da tradicional.
Em resumo, as metodologias de desenvolvimento, geis e tradicionais, visam organizar o pro-
cesso de desenvolvimento e evitar que o mesmo torne-se catico. O fato que no existe metodo-
logia perfeita. A cada situao preciso analisar qual a metodologia mais adequada e que trar
maiores benefcios ao projeto. Nesse sentido, as organizaes que trabalham com desenvolvimento
de software tendem a procurar a metodologia que mais se adeque s suas necessidades. O objetivo
principal das empresas a realizao de um processo com qualidade, para que possam produzir
software de qualidade.
Nesse ponto entram os modelos de referncia. Os modelos de referncia so importantes por
auxiliarem no direcionamento do processo a ser realizado e, com isso, podem assegurar a produo
de software de qualidade, atravs de um processo de qualidade.
Um modelo de referncia bastante conceituado o modelo contido na norma ISO/IEC 15504.
Esse modelo utilizado para avaliar processos de software, com o intuito de orientar um processo
de melhoria ou determinar sua capacidade. A norma permite a identicao de fraquezas e riscos
do projeto, possibilitando um direcionamento para a melhoria (ISO/IEC, 2003a).
CAPTULO 1. INTRODUO 3
A aplicao do processo de avaliao especicado pela norma ISO/IEC 15504, basendo-se em
caractersticas das metodologias geis de desenvolvimento, pode tornar possvel a denio do que
um processo de desenvolvimento gil e direcionar um processo de desenvolvimento para torn-lo
gil.
1.2 Objetivos
O objetivo deste trabalho apresentar uma proposta de um modelo de referncia para o desen-
volvimento gil de software. O modelo objetiva servir para direcionar um processo de desenvolvi-
mento de software, com o intuito de torn-lo gil.
Para atingir os objetivos pretendidos, foram analisadas seis das principais metodologias geis
de desenvolvimento presentes no manifesto gil, alm de tcnicas de documentao, gerncia e
planejamento. A anlise permitiu a identicao de caractersticas existentes nas metodologias e
direcionou a criao do modelo referncia.
O modelo criado composto por dezesseis processos que descrevem todo o ciclo de desen-
volvimento. Os processos so descritos segundo seus objetivos, atividades, tarefas e resultados
esperados.
1.3 Organizao
Este trabalho encontra-se dividido da seguinte forma. No Captulo 2 so introduzidos os
conceitos que envolvem as metodologias geis, suas origens, contexto e algumas metodologias
geis existentes so descritas. Alm disso, algumas caractersticas que envolvem a documenta-
o gil so apresentadas. No Captulo 3 so abordadas algumas tcnicas e trabalhos existentes
sobre gerncia e planejamento de projetos. No Captulo 4 descrita a estrutura de uma avalia-
o de processos proposta pela norma ISO/IEC 15504. No Captulo 5 so apresentadas algumas
caractersticas encontradas nos estudos realizados sobre as metodologias geis e um modelo de
referncia para o desenvolvimento gil de software proposto. No Captulo 6 apresentada a
avaliao de um processo de desenvolvimento de software, baseada na norma ISO/IEC 15504. A
avaliao realizada teve o intuito de determinar a capacidade do processo avaliado e direcion-lo
para torn-lo gil. Por m, no Captulo 7 so apresentadas algumas concluses deste trabalho e
sugestes de trabalhos futuros.
CAPTULO
2
Metodologias geis de
desenvolvimento de software
2.1 Consideraes Iniciais
As empresas desenvolvedoras de software procuram, cada vez mais, uma forma eciente de
fazer software com qualidade. As metodologias tradicionais de desenvolvimento propem-se a
realizar essa tarefa, porm, so mais adequados a sistemas onde os requisitos so relativamente
previsveis. Para sistemas onde os requisitos so variveis, diz-se que as metodologias geis pro-
duzem um melhor resultado, j que as mudanas de requisitos, dentro dessas metodologias, so
mais bem aceitas (dos Santos Soares, 2004).
As metodologias geis propem formas de desenvolvimento iterativo, disciplinado e criativo,
visando entregas rpidas e freqentes de verses. Isso possibilita ao cliente ter e fornecer feedback
com freqncia, permitindo o aumento de sua satisfao, j que ele passa a ter melhor viso do
andamento do projeto e do sistema em desenvolvimento (Williams e Cockburn, 2003).
Este captulo tem o objetivo de descrever os conceitos envolvidos nessa nova forma de desen-
volvimento, citando algumas das principais metodologias geis existentes atualmente. Na Seo
2.2 so descritos os principais conceitos que envolvem as metodologias geis. Na Seo 2.3 a
metodologia Extreme Programming descrita. Na Seo 2.4 a metodologia Scrum descrita. Na
Seo 2.5 a metodologia Feature Driven Development descrita. Na Seo 2.6 a metodologia
Dynamic System Development Method descrita. Na Seo 2.7 a metodologia Adaptive Software
Development descrita e na Seo 2.8 a metodologia Crystal descrita. Na Seo 2.9 so apre-
4
CAPTULO 2. METODOLOGIAS GEIS DE DESENVOLVIMENTO DE SOFTWARE 5
sentadas algumas informaes que envolvem a produo de documentao de forma gil. Por m,
na Seo 2.10 so apresentadas algumas consideraes nais sobre este captulo.
2.2 Conceitos envolvidos com as metodologias geis de
desenvolvimento
O desenvolvimento de software realizado, muitas vezes, de forma descontrolada. Para orien-
tar o processo de desenvolvimento, surgiram os conceitos da engenharia de software. Essa dis-
ciplina objetiva possibilitar maior controle e planejamento da construo de software, permitindo
que os produtos de software sejam construdos com qualidade.
As metodologias de desenvolvimento tradicionais possibilitam a produo de software ecien-
temente e com qualidade, tornando o processo de desenvolvimento mais previsvel (Fowler, 2005).
No entanto, essas metodologias geralmente so burocrticas e exigem, na maioria das vezes, pra-
zos longos para a entrega de uma primeira verso do software em construo. Tais caractersticas
tm sido alvo de crticas em relao a essas metodologias.
Esse fato incentivou pesquisadores a elaborarem alternativas a essa forma de desenvolvimento.
Em 2001, alguns pesquisadores reuniram-se em uma conferncia para discutirem semelhanas e
diferenas existentes entre suas abordagens para o desenvolvimento de software. Como resultado
dessa conferncia surgiu o Manifesto para desenvolvimento gil de software. O manifesto dene,
alm de outras coisas, quatro valores chave de toda metodologia gil, descritos como segue em
(Beck et al., 2001a):
[...] Atravs deste trabalho, ns valorizamos:
Indivduos e interaes sobre processos e ferramentas.
Software funcional sobre documentao abrangente.
Colaborao do cliente sobre negociao de contratos.
Responder a mudanas sobre seguir um plano.
Ou seja, apesar dos itens da direita serem importantes, ns valorizamos mais os
da esquerda.
Uma das caractersticas comuns encontradas nas abordagens dos diversos pesquisadores, e que
faz parte do manifesto gil, a priorizao da satisfao do cliente. Para alcan-la, necessrio
que produtos de software intermedirios sejam entregues em prazos curtos e de forma contnua.
Tais produtos devem ser funcionais, permitindo que os clientes aprendam com sua utilizao. Isso
possibilita a identicao de necessidades no especicadas e resulta em requisitos mais clara-
mente denidos e em um produto de software nal mais prximo das necessidades reais do cliente.
Os produtos de software podem tambm ser utilizados como a primeira medida do progresso de
projeto (Beck et al., 2001b; Highsmith, 1999).
Para aumentar ainda mais a satisfao do cliente, necessrio que pessoas com domnio do
negcio sejamparte integrante da equipe de desenvolvimento. Aexistncia desse elo entre o cliente
e os desenvolvedores imprescindvel para o sucesso do projeto. A troca de informaes precisa
ser intensa. Nessa troca de informaes, importante que os clientes identiquem e denam
necessidades e prioridades e passem essas informaes para os desenvolvedores; os quais devem
apontar riscos, alternativas, etc. Quanto mais rpida essa troca for realizada, mais rpido ser o
processo de construo e mais prximo da satisfao do cliente o projeto estar.
Essa proximidade do cliente ao ambiente de desenvolvimento geralmente estimula a mudana
de requisitos. Mudanas de requisitos ocorrem em qualquer projeto, independente da metodologia
utilizada. Os custos dessas mudanas podem variar, de acordo com a metodologia utilizada e
situao corrente do projeto.
Nas metodologias tradicionais, o custo referente a essas mudanas pode variar, dependendo da
etapa de desenvolvimento que ela ocorre. Quanto mais tarde a mudana for identicada, maior
ser o custo de sua realizao. Uma das causas o fato do cliente poder observar o funcionamento
do produto apenas na verso nal do software (ou no caso de metodologias evolutivas, na primeira
verso, que pode ser demorada). Ao testar a verso, o cliente passa a ter uma viso mais clara de
suas necessidades. Uma alterao de requisitos nessa etapa de desenvolvimento pode ser invivel.
Nas metodologias geis, a mudana de requisitos no gera grandes transtornos, pois a proximi-
dade do cliente equipe de desenvolvimento, as entregas contnuas e em perodos curtos de tempo,
possibilitam que requisitos sejam identicados de forma dinmica, permitindo mudanas rpidas
e sem grandes custos (Martin Fowler, 2006).
As alteraes so fatos freqentes nessas metodologias e a equipe de desenvolvimento deve
estar preparada para realiz-las. A resposta rpida a essas mudanas importante nesse tipo de
desenvolvimento.
A equipe de desenvolvimento tambm deve estar apta auto-organizao. A equipe res-
ponsvel por denir arquitetura, estrutura e projeto do software a ser desenvolvido. A melhor
combinao dos elementos da equipe, e suas funes dentro da mesma, deve ser denida e respei-
tada pela prpria equipe. Quando o processo de construo possui essas caractersticas, diz-se que
um processo adaptativo (Martin Fowler, 2006).
A equipe de desenvolvimento ainda deve promover reunies regulares, a m de acompanhar
o andamento do projeto e manter todos os membros da equipe cientes dos problemas encontrados
e das tarefas realizadas. Em intervalos de tempo pr-determinados, os envolvidos renem-se e
discutem as diculdades encontradas, as tarefas realizadas e as tarefas previstas at a prxima
reunio. Segundo Rising (Rising, 2002), as reunies devem ser curtas e devem servir apenas
para levantar problemas, no para resolv-los. A resoluo deve ser discutida mais tarde, com a
participao apenas dos envolvidos.
As caractersticas existentes nas metodologias geis ressaltam a importncia das pessoas envol-
vidas em um processo de desenvolvimento, que utiliza os princpios geis. Como j mencionado,
as metodologias geis enfocam as pessoas e no os processos. Contudo, importante que os
indivduos envolvidos sejam capacitados o suciente para exercer as diversas funes existentes
nessas metodologias. Alm disso, os indivduos devem estar motivados, com ambiente e apoio
necessrios para realizarem seus papis com a qualidade e a agilidade necessrias.
No projeto a ser desenvolvido, o trabalho deve ser feito de forma simples e objetiva. O de-
senvolvedor deve implementar exatamente o que o cliente deseja, nem mais nem menos, da forma
mais simples possvel (Kuhn e Pamplona, 2004). A simplicidade um dos princpios dessas meto-
dologias, pois agiliza o processo de desenvolvimento, fazendo com que o desenvolvedor produza
somente o que foi solicitado.
Para que uma metodologia possa ser considerada gil, ela precisa aplicar os princpios descritos
no manifesto gil (Beck et al., 2001b). As metodologias que aplicam esses princpios, de diferentes
formas, visam a produo de software de forma eciente e que satisfaa o cliente, possibilitando a
entrega dentro do prazo e custo previstos.
Nas sees seguintes so apresentadas algumas metodologias geis que compem o manifesto
gil e so descritas algumas tcnicas e trabalhos realizados sobre a documentao gil.
2.3 Metodologia Extreme Programming
A metodologia Extreme Programming, mais conhecida como XP, uma metodologia gil que
prima pela qualidade do software construdo e pela satisfao do cliente. Criado por Kent Beck e
Ward Cunningham, o XP um renamento de prticas aplicadas em numerosos projetos nos anos
80 e evoludas, nos anos 90, para uma abordagem de desenvolvimento adaptativo e orientado a
pessoas (Fowler, 2005; Goldman et al., 2004). Alguns praticantes denem XP como a prtica e a
perseguio da simplicidade, aplicada ao desenvolvimento de software (Kuhn e Pamplona, 2004).
Esta metodologia composta por seis etapas: Explorao, Planejamento, Iteraes para verses,
Produo, Manuteno e Morte (Paulk, 2001; da Silva et al., 2005). O ciclo de vida de XP apre-
sentado na Figura 2.1.
Na fase de Explorao os clientes descrevem as estrias (recursos) que precisam ser desen-
volvidas. Em paralelo, iniciam-se atividades de familiarizao da equipe de desenvolvimento com
ferramentas, tecnologias e prticas a serem utilizadas durante o projeto. So realizados testes com
a tecnologia escolhida e possibilidades de arquitetura do sistema so exploradas atravs de prot-
tipos. Essa fase pode durar de semanas a alguns meses, dependendo do grau de familiaridade dos
desenvolvedores com a tecnologia.
Aps essa fase, inicia-se a fase de Planejamento, onde as estrias descritas so priorizadas
e as estrias que faro parte da primeira pequena verso do software so denidas. Para isso,
os desenvolvedores fazem uma previso do esforo necessrio para desenvolver cada estria e
denem um plano para a construo da primeira verso. Geralmente o tempo de construo da
primeira verso menor do que dois meses.
A construo das verses do software acontece na fase de Iteraes para as verses. Nessa
fase so realizadas vrias iteraes antes da primeira verso. A primeira iterao cria uma arquite-
Figura 2.1: Ciclo de vida de Extreme Programming (Abrahamsson et al., 2002)
tura para o sistema. Em seguida, os clientes selecionam as estrias a serem desenvolvidas durante
a prxima iterao. Ao nal de cada iterao so realizados os testes funcionais criados pelos
clientes e, aps a ltima, o sistema colocado em produo (Tijman, 2003).
Antes que a verso seja entregue para o cliente, so realizados testes extras e a performance do
sistema checada. Essa a fase de Produo, quando podem ser encontradas novas necessidades
de alterao e, nesses casos, decidi-se se as necessidades faro parte da verso corrente ou de uma
futura verso. Durante essa fase, as iteraes podem ter a necessidade de serem realizadas em
perodos mais curtos (de uma a trs semanas). As sugestes e idias adiadas so documentadas
para uma posterior implementao, ou seja, para a fase de manuteno.
A fase de Manuteno inicia-se depois da entrega da primeira verso. Nessa fase preciso dar
manuteno ao software que est em funcionamento e prosseguir com as vrias iteraes que pro-
movem o desenvolvimento de novas verses. Por esse motivo, essa fase pode reduzir a velocidade
de desenvolvimento e introduzir novas pessoas a equipe, podendo inclusive, mudar a estrutura da
mesma.
O ciclo de vida de XP termina com a fase de Morte. Essa fase inicia-se quando restam poucas
estrias a serem implementadas e a ateno volta-se para a documentao. Quando no existem
mais alteraes na arquitetura, projeto e cdigo do software, a documentao do software nal-
mente produzida, encerrando-se o ciclo de vida.
As cinco fases do ciclo de vida XP foram concebidas em conjunto com quatro valores e doze
prticas. Os valores so as diretrizes de XP. Eles denem as atitudes que devem ser seguidas por
todos os integrantes da equipe e as principais prioridades da metodologia. As prticas denem o
conjunto de atividades que devem ser realizadas pela equipe.
Um dos valores de XP envolve o conceito de troca de informaes intensa entre o cliente e
o desenvolvedor. Conhecido como feedback, esse valor baseia-se no aprendizado do cliente e do
desenvolvedor, por meio da utilizao do produto de software.
O feedback possibilita que o cliente conduza o desenvolvimento do produto, estabelea priori-
dades e informe o que realmente importante. Do lado do desenvolvedor, o feedback permite que
ele aprenda o que o cliente deseja, possibilitando que ele aponte riscos, alternativas, estimativas,
etc. Com isso, a metodologia pretende proporcionar uma minimizao de falhas na interpretao
das necessidades e prioridades estabelecidas pelos clientes.
Para que o feedback seja efetivo, necessrio que haja um mecanismo ecaz de comunicao
entre os envolvidos. A comunicao outro valor empregado por XP. De acordo com a metodo-
logia, esse valor deve ser empregado da forma mais direta possvel, preferivelmente face-a-face.
Aliada ao feedback e a comunicao esto a simplicidade e a coragem. Os desenvolvedores
devem produzir o que o cliente precisa da forma mais simples possvel e devem ter coragem para
cumprir as premissas denidas pela metodologia. Algumas dessas premissas so: permitir que o
cliente dena prioridades, expor cdigo a todos os membros da equipe, propor contratos de escopo
varivel, fazer os desenvolvedores trabalharem em pares, integrar o sistema diversas vezes ao dia,
entre outros.
Os valores de XP, somados as suas prticas, formamumconjunto de boas atitudes que compem
sua losoa (Kuhn e Pamplona, 2004).
Dentro dessa losoa destacam-se as reunies regulares e a programao em pares. As reu-
nies propiciam o entendimento de problemas enfrentados por elementos da equipe e a disse-
minao de informaes sobre o andamento do projeto. A programao em pares possui uma
produtividade semelhante a da programao sozinha, porm, a maior qualidade do cdigo que ela
produz gera facilidades na manuteno e outros ganhos a mdio e longo prazo (Kuhn e Pamplona,
2004; Williams et al., 2000).
Em resumo, a metodologia XP trabalha em funo de estrias, que so descritas e priorizadas
pelo cliente. No momento de sua implementao, a equipe pode fazer estimativas de custo de cada
estria e planejar as release
1
e as iteraes. Ao nal de cada iterao obtido um feedback do
cliente e, com isso, pode-se planejar a prxima iterao. Ao nal de cada ciclo entregue uma
verso funcional do software e o planejamento para o prximo release realizado.
A metodologia d grande importncia para testes e integrao. Antes de qualquer implemen-
tao, um teste automatizado deve ser codicado, para que imediatamente aps a codicao de
1
Um realease um conjunto de iteraes responsvel pela produo de uma verso do software
alguma funcionalidade, ela possa ser validada (Tijman, 2003). Alm disso, XP sugere que a in-
tegrao do sistema seja feita vrias vezes ao dia, evitando complicaes na hora de integrar as
novas estrias desenvolvidas.
2.4 Metodologia SCRUM
A metodologia Scrum foi aplicada pela primeira vez, por Ikujiro Nonaka e Hirotaka Takeuchi,
no desenvolvimento de um jogo, em 1986. Aps a experincia da primeira aplicao e baseados
em suas idias e pesquisas na rea de teoria de processos, realizadas em colaborao com a Du-
Pont Advanced Research Facility, Nonaka e Takeuchi formularam e apresentaram a metodologia
Scrum, pela primeira vez, para o grupo de gerenciamento de objetos (Object Management Group)
em 1995. Em 2001, Ken Schwaber e Mike Beedle lanaram um livro intitulado Agile Software
Development with Scrum, que descreve a metodologia Scrum por completo (Schwaber e Beedle,
2004).
A metodologia segue o princpio de que o processo de desenvolvimento imprevisvel. Ela de-
ne que o processo um conjunto solto de atividades que combinam conhecimento, ferramentas e
tcnicas, com o melhor que a equipe de desenvolvimento pode oferecer. Dentro do conjunto de ati-
vidades esto algumas atividades de gerncia de riscos e do prprio processo, que so necessrias
para um desenvolvimento satisfatrio (Scrum Web Site, 2005).
Scrum utiliza algumas prticas que so importantes para o controle e planejamento do projeto,
o Backlog e Sprint. O Backlog uma lista de atividades, j priorizadas e estimadas, a serem reali-
zadas durante o projeto. Dentre essas atividades, algumas so selecionadas para serem realizadas
dentro de um perodo de tempo determinado. Tal perodo chamado de Sprint e o conjunto de
atividades selecionadas denominado Backlog do Sprint. A cada Sprint, todas as atividades per-
tencentes ao Backlog do Sprint so realizadas, resultando em uma nova verso do produto, que
deve ser entregue ao cliente.
Um Sprint inicia com uma reunio de planejamento, onde denido o Backlog do Sprint.
Nenhuma atividade pode ser adicionada durante um Sprint, exceto atividades originadas de uma
previamente selecionada. Quando alguma atividade externa identicada, ela adicionada ao
Backlog. Ao nal de cada Sprint, uma reunio de reviso realizada. Qualquer modicao ou
novidade adicionada ao Backlog e poder ser includa em futuros Sprints.
Com os termos Backlog e Sprint j denidos, possvel entender o ciclo de vida de Scrum, que
composto de Pr-jogo, Desenvolvimento e Ps-jogo. O ciclo de vida de Scrum apresentado
na Figura 2.2.
As atividades realizadas na fase Pr-jogo podem ser divididas em duas outras fases. Na fase de
Planejamento so realizadas denies sobre o sistema que ser desenvolvido. Uma Lista de Ba-
cklog do Produto criada contendo todos os requisitos conhecidos. Os requisitos so priorizados
e uma estimativa de custo de desenvolvimento feita para cada um. A lista de Backlog do produto
Figura 2.2: Ciclo de vida de Scrum (Abrahamsson et al., 2002)
constantemente atualizada com novos requisitos, novo detalhamento de requisitos pr-existentes,
novas prioridades, novas estimativas. Ainda na fase de planejamento feita a denio da equipe,
de ferramentas e de outros recursos. A avaliao e controle de riscos tambm so realizadas nessa
etapa, que dene tambm as necessidades de treinamento. Em todos os Sprints, o Backlog do
produto revisto pela equipe de desenvolvimento para planejar o prximo Sprint.
Na outra fase do pr-jogo, a fase de Arquitetura, um projeto de alto nvel, incluindo a arqui-
tetura, concebido basendo-se no Backlog do produto. Esse projeto revisto frente aos objetivos
de implementao e decises so tomadas basendo-se nessa reviso. Alm disso, so realizados
planos preliminares sobre o contedo das verses a serem produzidas.
Terminada a fase de pr-jogo, inicia-se o desenvolvimento das verses. Nessa fase, chamada
de Desenvolvimento ou Fase de jogo, inicia-se a parte gil de Scrum. Tambm conhecida como
caixa-preta, essa fase caracterizada por diferentes aspectos tcnicos e ambientais, que podem
ser alterados durante o processo e so observados e controlados atravs de vrias prticas durante
o Sprint.
Por m, a fase do Ps-jogo concentra-se no encerramento do projeto. Essa fase inicia-se
quando acredita-se que no existam mais requisitos a serem desenvolvidos. O sistema preparado
para ser entregue e so realizadas as tarefas de integrao, testes do sistema e documentao.
A metodologia Scrum sugere a existncia de equipes multidisciplinares e auto-organizveis.
Para isso, os indivduos que compem as equipes no possuem funes xas. Todos os membros
devem ter uma viso global do projeto e a equipe deve ser capaz de auto-organizar-se para atingir
os objetivos pretendidos (Figueiredo e Sanches, 2005).
Aliado a isso, Scrum dene alguns papis e prticas que garantem o controle e a visibilidade
do projeto, sem deixar de lado a liberdade dos desenvolvedores. Os papis e prticas ajudam a
identicar o que ser desenvolvido e quais sero os responsveis por quais atividades. Isso auxilia
no controle e planejamento das iteraes e no controle do andamento do projeto.
Em resumo, a metodologia Scrum pode ser denida como sendo iterativa, incremental e adap-
tativa e focada no gerenciamento e controle de projetos. Um aspecto importante dessa metodologia
a estabilidade dos requisitos durante uma iterao. Isso signica que novos requisitos no so
includos em uma iterao em andamento. Nesses casos, eles so registrados e adicionados em
futuras iteraes.
2.5 Metodologia Feature Driven Development
A metodologia Feature Driven Development (FDD) foi criada por Jeff De Luca e Peter Code e
obteve o reconhecimento de seu nome em 1997 (Khramtchenko, 2004). FDD uma metodologia
gil voltada entregas freqentes de verses do software. Para isso, utiliza-se de um processo
de desenvolvimento incremental e enfatiza mecanismos de controle e divulgao de informaes
sobre o projeto (Feature-driven Development Web Site, 2006).
O que diferencia FDD da maioria das metodologias geis o fato de ser altamente escalvel.
FDD pode ser aplicada a projetos com equipes numerosas, podendo chegar a centenas de indiv-
duos. Para suportar a escalabilidade, a metodologia enfatiza a criao inicial de um modelo global
do projeto e de uma lista de funcionalidades.
FDD consiste de cinco processos sequenciais, durante os quais o sistema projetado e cons-
trudo. Os processos que compem a parte iterativa de FDD so: Projetar por funcionalidade
e Construir por funcionalidade. So esses processos que apiam o desenvolvimento gil, pois
proporcionam uma adaptao rpida s alteraes tardias dos requisitos e das necessidades de
negcio. O ciclo de vida de FDD apresentado na Figura 2.3 (Abrahamsson et al., 2002).
Figura 2.3: Ciclo de vida de Feature Driven Development (Abrahamsson et al., 2002)
Um projeto FDD inicia-se com o Desenvolvimento de um modelo global. Nessa fase, os
especialistas do domnio direcionam a ateno para o escopo, o contexto e os requisitos do sistema
a ser desenvolvido. Alguns documentos podem ser produzidos, alm da viso global do projeto,
para auxiliar a elicitao dos requisitos.
A viso global pode ser dividida em pequenas reas, separadas por domnio, que so analisadas
por pequenas equipes, tambm divididas por domnio, que propem um modelo para cada pequena
rea. Ao nal dessa fase, um modelo global do projeto produzido.
Os documentos produzidos nessa fase e o modelo global do projeto possibilitam o incio da
fase Construir uma lista de funcionalidades. As funcionalidades descobertas so agrupadas em
pacotes de trabalho, que so implementados durante as iteraes. A etapa de descoberta um
processo crtico. A qualidade de realizao dessa etapa dene a preciso na qual o progresso do
processo ser rastreado e o grau de manutenibilidade do cdigo (Khramtchenko, 2004).
Aps a etapa de descoberta das funcionalidades, inicia-se o planejamento. Nessa fase, chamada
Planejar por funcionalidades, so criados planos de alto-nvel, nos quais os pacotes de trabalho
criados nas fases anteriores so priorizados e, em seguida, so associados a desenvolvedores indi-
viduais, que passam a ser chamados de proprietrios da classe.
O proprietrio da classe o criador da funcionalidade. Em FDD, cada funcionalidade im-
plementada tem um nico criador. Isso signica que caso alguma funcionalidade precise sofrer
alguma alterao, esta deve ter, necessariamente, a participao de seu criador. Acredita-se que
essa prtica identica, de forma mais precisa, as consequncias das alteraes (Khramtchenko,
2004).
Ao nal do planejamento, inicia-se a parte iterativa de FDD, composta pelas fases Projetar
por funcionalidades e Construir por funcionalidades. A partir desse ponto, um pacote de tra-
balho selecionado a cada iterao e o proprietrio da classe escolhe os membros da equipe que
iro desenvolv-los. Em FDD, uma iterao pode variar de poucos dias a at duas semanas e em
cada iterao podem existir vrias equipes projetando e construindo suas funcionalidades concor-
rentemente.
O processo iterativo inclui atividades como: inspeo do projeto, codicao, testes unitrios,
integrao e inspeo do cdigo. Ao nal das iteraes, as funcionalidades produzidas so promo-
vidas a Produto Principal, enquanto iniciam-se novas iteraes com novos pacotes de trabalho
selecionados. A parte iterativa de FDD apresentada na Figura 2.4.
Emfuno do desenvolvimento por funcionalidades, necessrio que haja uma forte integrao
do sistema. O FDD sugere que haja sempre uma verso com qualidade de produo disponvel.
Para isso, mecanismos ecientes de gerncia de congurao e de integrao constante devem
permitir que verses anteriores do software sejam recuperadas facilmente, possibilitando que uma
verso funcional esteja sempre disponvel.
Figura 2.4: Parte iterativa de Feature Driven Development (Abrahamsson et al., 2002)
A ltima verso funcional serve como demonstrao do estado do projeto. Para complementar
esse indicador, a metodologia considera a utilizao de tcnicas que apresentem o progresso e
planejamento do projeto, basendo-se nas funcionalidades produzidas.
2.6 Metodologia Dynamic System Development Method
A metodologia Dynamic System Development Method (DSDM) teve incio em um consrcio,
iniciado em janeiro de 1994, formado por dezesseis organizaes. O objetivo do consrcio era criar
ummodelo independente para o desenvolvimento rpido de aplicaes. Comos estudos realizados,
chegou-se ao modelo de desenvolvimento chamado Dynamic System Development Method. Desde
ento, o modelo vem sendo desenvolvido e renado, mas os conceitos bsicos tm permanecido
(Dynamic System Development Method Web Site, 2006a).
O modelo criado tem como objetivo principal as entregas rpidas de solues de qualidade,
dentro do prazo e oramento previstos. As entregas rpidas e o trabalho em equipe compem
sua losoa. Os autores da metodologia acreditam que o conhecimento do cliente em relao ao
negcio, aliado ao conhecimento tcnico da equipe de desenvolvimento e s entregas rpidas de
verses de software, aumentam a satisfao do cliente e resultam no desenvolvimento de produtos
de qualidade. O modelo segue o princpio de que nenhum sistema construdo perfeitamente na
primeira tentativa (Dynamic System Development Method Web Site, 2006b).
A idia principal por traz de DSDM que ao invs de denir um conjunto de funcionalidades e
ento ajustar tempo e recursos para desenvolv-la, a metodologia dene tempo e recurso dispon-
veis e ento ajustam o conjunto de funcionalidades a serem desenvolvidas. A tcnica sugerida para
implementar essa idia denominada Timeboxing.
Para que o desenvolvimento siga o uxo proposto pela metodologia, DSDM divide o ciclo
de desenvolvimento em cinco fases: Estudo de viabilidade, Estudo do negcio, Iterao para um
modelo funcional, Iterao para o projeto e construo e Implementao. Ociclo de vida de DSDM
apresentado na Figura 2.5.
Figura 2.5: Ciclo de vida de Dynamic System Development Method (Abrahamsson et al., 2002)
Antes de iniciar um projeto utilizando essa metodologia, importante realizar um Estudo de
viabilidade, que a fase inicial de DSDM. O estudo avalia se o tipo de projeto e, principalmente,
se as pessoas envolvidas e as caractersticas organizacionais so adequadas ao uso da metodologia.
Em paralelo, so realizadas anlises tcnicas e de riscos, podendo ser utilizados prottipos para
validar requisitos tcnicos. Essa fase dura poucas semanas e produz um relatrio de viabilidade e
um plano resumido de desenvolvimento.
O prximo passo a realizao de um Estudo do negcio. Essa fase analisa os aspectos
tecnolgicos e de negcio. Especialistas de domnio ajudam a denir as prioridades de desenvol-
vimento e as pessoas chave para o negcio, as quais podem auxiliar o esclarecimento de possveis
dvidas sobre os requisitos de negcio. Nesse ponto, pode-se produzir alguns documentos como
Diagrama de Entidades e Relacionamento, Modelo de Objetos, Arquitetura do Sistema, Plano de
Prototipao e Plano para a Gerncia de Congurao.
Aps essa etapa, inicia-se a primeira fase iterativa e incremental de DSDM, a fase Iterao
para o modelo funcional. Em todas as iteraes realizado um planejamento do contedo a ser
desenvolvido e os resultados so analisados para a prxima iterao. Nesse passo so analisados
cdigos, so produzidos prottipos e so realizados testes continuamente. A experincia adquirida
utilizada para avaliar o modelo de anlise, que junto com o prottipo, forma o modelo funcional,
produzido nessa etapa.
Alm do modelo funcional, essa fase produz uma lista priorizadas das funcionalidades que
sero entregue ao nal da iterao (a tcnica de priorizao das funcionalidades conhecida como
Moscow), um documento contendo informaes referentes a revises feitas sobre os prottipos,
uma lista de requisitos no-funcionais e um documento descrevendo os riscos envolvidos no pro-
jeto.
Na prxima fase, chamada de Iterao para o projeto e construo, onde o sistema
essencialmente construdo. Ao nal dessa fase tem-se uma verso funcional, com o conjunto de
requisitos estipulados, testados e funcionando.
Por m, o software passa do ambiente de desenvolvimento para o ambiente de produo. Nessa
fase, denominada Implementao, realizado um treinamento dos usurios e a verso do software
entregue. A fase de implementao produz ainda um manual do usurio e um relatrio de reviso
do projeto, que pode servir como orientao para as prximas iteraes.
Alm das cinco fases de desenvolvimento, DSDM descreve alguns princpios e atitudes que
so esperadas dos envolvidos no processo de desenvolvimento e onze papis que descrevem as
funes existentes dentro do mesmo (Dynamic SystemDevelopment Method Web Site, 2006b). Os
princpios baseiam-se no trabalho em equipe, nas entregas freqentes, na colaborao e cooperao
dos envolvidos e nas alteraes de requisitos.
Um dos princpios diz que todas as alteraes, durante o desenvolvimento, devem ser revers-
veis. Isso leva a necessidade de um controle de verses eciente. Outro princpio aponta para
a coragem dos usurios em tomar decises, incentivada por tcnicas sugeridas pela metodologia.
Esse princpio possibilita a adaptao rpida a novos requisitos e, consequentemente, leva a um
desenvolvimento rpido e eciente.
Em resumo, DSDM visa o desenvolvimento de software de forma incremental e iterativa, onde
a cada iterao uma nova verso do software produzida. Aliado a isso, a metodologia foca
o desenvolvimento no trabalho em equipe e em usurios motivados. Cada indivduo dentro da
equipe tem uma ou vrias funes a desempenhar, o que faz com que a cooperao e a colaborao
sejam essenciais para que um projeto obtenha sucesso (Dynamic System Development Method
Web Site, 2006b).
2.7 Metodologia Adaptive Software Development
Adaptive Software Development (ASD) uma metodologia de desenvolvimento de software,
criada por Jim Highsmith, que d grande importncia s pessoas, aos resultados e mxima co-
laborao entre cliente e equipe de desenvolvimento. Para criar essa metodologia, Highsmith
baseou-se na teoria Complex Adaptive System (CAS), que defende a idia de que o desenvolvi-
mento de software semelhante ao mercado econmico. De acordo com a teoria CAS, a economia
caracterizada pela alta velocidade e alto grau de mudanas, e pela maior importncia do aumento
dos resultados sobre a otimizao (Highsmith, 1999; Dirk Riehle, 2006).
Semelhantemente a economia, a ASD uma metodologia direcionada para o desenvolvimento
rpido e com alto grau de mudanas, e caracteriza-se por dar maior importncia aos resultados
sobre processos. Alm disso, a ASD prioriza o entendimento sobre a documentao, a colaborao
sobre o controle e a adaptao sobre a otimizao (Highsmith, 2000; Jim Highsmith, 2006).
Essa metodologia abandona o ciclo de vida esttico Planejar-Projetar-Construir para dar lugar
ao ciclo de vida Adaptive (umciclo dinmico), que compreende as fases Especulao-Colaborao-
Aprendizagem. O ciclo de vida Adaptive, apresentado na Figura 2.6, um ciclo dedicado a apren-
dizagem contnua e direcionado a aceitar mudanas constantes, a executar reavaliaes e a estimu-
lar intensa colaborao entre desenvolvedores, testadores e clientes.
Figura 2.6: Ciclo de vida Adaptive (Highsmith, 2000)
Dentro do ciclo, a fase de Especulao reconhece a incerteza natural dos problemas e encoraja
a explorao e experimentao; a fase de Colaborao refora a necessidade do alto nvel de troca
de informaes e ajuda a elucidar requisitos e reduzir ou solucionar problemas tcnicos; a fase de
Aprendizagem fora a realizao de atividades de reavaliao, possibilitando uma melhoria para
a prxima iterao.
O ciclo Adaptive tem seis caractersticas bsicas: foco na misso, desenvolvimento baseado
em componentes (resultados), iteraes, timebox, anlise de riscos e tolerncia a mudanas. Essas
caractersticas ajudam a direcionar todo o processo de desenvolvimento, incluindo o planejamento
para cada iterao, os resultados esperados em cada iterao e a anlise de riscos e previso de
mudanas para o prximo ciclo.
As trs fases (Especulao-Colaborao-Aprendizagem) servem para proporcionar uma viso
geral do ciclo de desenvolvimento. Cada fase pode ser dividida em pores menores, o que pos-
sibilita um melhor entendimento do ciclo e das atividades envolvidas em cada uma das fases. Na
Figura 2.7 so apresentadas as fases do ciclo Adaptive e as atividades que as compem.
Figura 2.7: Atividades do ciclo de vida Adaptive (Highsmith, 2000)
A atividade de iniciao determina os objetivos e misses do projeto. Para isso, essa fase
procura entender e documentar restries, estabelecer a organizao e os responsveis pelo projeto,
identicar e esboar os requisitos, realizar uma estimativa inicial do escopo e tamanho do projeto e
identicar os principais riscos. Feito isso, determina-se as funcionalidades que sero desenvolvidas
durante o projeto. As funcionalidades denidas so baseadas nos resultados obtidos nas atividades
anteriores.
O prximo passo determinar o nmero total de ciclos do projeto e associar um timebox a cada
um deles. O tamanho dos ciclos determinado pelo cronograma geral e pelo grau de incerteza do
projeto.
Cada ciclo denido com um tema (ou objetivo) e possui marcos que ajudam a manter a
visibilidade do projeto e a identicar defeitos e falhas.
Os passos nais dessa fase associam componentes aos ciclos, permitindo que ao nal de cada
ciclo sejam entregues produtos tangveis. Alm disso, dene-se a lista de tarefas a serem realiza-
das. Nesse ponto, um componente denido pode vir a ser um objetivo de uma determinada tarefa.
Atividades que no puderam ser denidas como componentes tambm so listadas nesse passo,
completando assim a fase de Especulao.
A fase Colaborao composta pela etapa Engenharia Concorrente de Componentes. Essa
etapa trata de assuntos que envolvem os relacionamentos existentes entre os membros da equipe.
As diferentes opinies existentes devemser gerenciadas da melhor forma possvel. Emprojetos
de pequeno porte, especialmente onde os membros da equipe encontram-se prximos sicamente,
as diferenas de opinies podemser controladas informalmente. No entanto, emprojetos de grande
porte, necessrio um maior controle sobre esse aspecto. Para minimizar esses problemas, a fase
Colaborao sugere a aplicao de algumas tcnicas, como a programao em pares, a proprie-
dade coletiva do cdigo, entre outras.
A terceira fase, Aprendizagem, composta pelas etapas Reviso de qualidade e Reviso de
qualidade tcnica. De uma forma geral, a aprendizagem resultado da aplicao de tcnicas de
reviso de qualidade, que devem ser aplicadas ao nal de cada ciclo de desenvolvimento. Existem
quatro categorias bsicas que devem ser observadas: a qualidade do produto na viso do usurio
nal; a qualidade do produto na viso tcnica; a performance da equipe responsvel pelas entregas
e as prticas que a equipe utiliza; o estado do projeto.
Obter esse tipo de retorno fundamental para o sucesso do projeto. importante destacar que
nessa etapa de desenvolvimento, a reviso feita para possibilitar a aprendizagem para o prximo
ciclo, no para descobrir falhas. Falhas so descobertas com a realizao de revises de cdigo,
revises de casos de teste, entre outros, durante o ciclo.
Em resumo, Adaptive Software Development uma metodologia adaptativa, que prioriza a
resposta rpida mudanas, a entrega de verses, a colaborao e a aprendizagem. Acredita-se
que essas caractersticas possibilitam o desenvolvimento de software de forma gil, controlada e
com qualidade.
2.8 Metodologia Crystal
Crystal uma famlia de processos aplicveis a diferentes tipos de projetos. A idia de ter
mltiplos processos origina-se do fato de existir projetos que exigem diferentes nveis de controle.
Projetos pequenos e no crticos podemser desenvolvidos utilizando-se os processos menos rigoro-
sos de Crystal, enquanto que projetos grandes e mais crticos demandam a utilizao de processos
mais rigorosos.
Cockburn, em seu livro entitulado Agile Software Development (Cockburn, 2002), compara a
famlia de processos Crystal com um cristal prpriamente dito. A base para a comparao est
no fato de que um cristal, sob a inuncia da luz, pode mudar de cor conforme a intensidade. A
metodologia Crystal funciona semelhantemente, pois pode adequar-se a criticalidade e tamanho
de um projeto, caso esses aspectos variem. Se um projeto aumenta de tamanho ou de nvel crtico,
mais processos Crystal podem ser adicionados a ele, e vice-versa.
Cada membro da famlia de processos marcado com uma cor. Crystal sugere que seja escol-
hida uma cor apropriada da metodologia para um determinado projeto, de acordo com o nvel de
criticalidade e o tamanho da equipe. Os quatro nveis de criticalidade denidas na metodologia
so:
1. Conforto (C)
2. Arbitrrio (A)
3. Imprescindvel (I)
4. Vital (V)
Uma falha em um projeto do primeiro nvel (nvel C) pode gerar um desconforto, mas no traz
consequncias graves. Uma falha em um projeto do quarto nvel (nvel V) pode ser vital. Desse
modo, pode-se dizer que para projetos que exigem menos rigor podem ser aplicados os primeiros
nveis e para projetos mais rigorosos, aplica-se os ltimos nveis.
Os nveis de criticalidade e os tamanhos de projeto so representados por categorias de projeto,
apresentadas na Figura 2.8. Como exemplo, na Figura 2.8, a categoria A6 representa uma equipe
de no mximo 6 pessoas que desenvolve um projeto com o nvel de criticalidade A (Arbitrrio).
Figura 2.8: Categorias de projeto da metodologia Crystal (Abrahamsson et al., 2002).
Os processos da famlia Crystal seguem os princpios do desenvolvimento gil. Eles priorizam
a entrega incremental, medem o progresso do projeto atravs das verses do software, sugerem
a existncia de testes de regresso de funcionalidades automatizados, direcionam o ambiente de
desenvolvimento para a cooperao, sugerem a realizao de workshops
2
para o renamento de
produtos e da metodologia utilizada (realizados no incio e no meio de cada incremento).
2
Reunies regulares realizadas com os envolvidos no projeto. Os envolvidos podem ser clientes, pessoas inte-
grantes da equipe de desenvolvimento, facilitadores.
Um exemplo de um incremento de um projeto que utiliza essa metodologia apresentado na
Figura 2.9. O exemplo considera um projeto com uma equipe formada por mais de 40 membros.
Figura 2.9: Um incremento de Crystal para equipes com mais de quarenta membros (Keith
Everette, 2006).
Para auxiliar o desenvolvimento gil, Crystal sugere a padronizao de alguns itens, como as
notaes, as formataes, as convenes de projeto, as interfaces do usurio, entre outros. A pro-
duo de alguns produtos de trabalho tambm ressaltada. Alguns exemplos desses produtos so:
sequncias de verses, modelos comuns de objetos, manual de usurio, casos de teste e migrao
do cdigo. Segundo Abrahamsson, em (Abrahamsson et al., 2002), a produo do documento de
requisitos necessria em projetos com o nvel de criticalidade mais elevado. Em outros casos,
uma anotao informal dos requisitos suciente.
A metodologia sugere ainda a utilizao de ferramentas que auxiliem no controle de verses,
na comunicao, na medio do andamento do projeto, na realizao de testes e na medio da
performance.
Para suportar sua losoca, a metodologia dene um conjunto de prticas que auxiliam no
desenvolvimento, porm, permite a utilizao de prticas sugeridas por outras metodologias.
Algumas prticas sugeridas por Crystal para aumentar o controle e monitoramento do anda-
mento do projeto so: Staging (dene quais requisitos sero desenvolvidos no prximo incre-
mento), Monitoramento do progresso (monitora o progresso do projeto), Reviso e Inspeo (veri-
ca se os requisitos foramdesenvolvidos satisfatoriamente), Fluxo e Paralelismo (garante que ativi-
dades realizadas durante o ciclo possam ocorrer em paralelo), Holistic Diversity Strategy (permite
a criao de estratgias para que grandes equipes tornem-se equipes multifuncionais), Tcnica para
Renamento da Metodologia (permite a aprendizagem referente a um incremento, possibilitando
um renamento do processo para o prximo incremento), Parecer do usurio (usurios examinam
o que est sendo produzido para garantir que os requisitos foram desenvolvidos corretamente),
Workshops de Reexo (workshops realizados antes e depois de cada incremento, com o intuito de
identicar possveis problemas e solues), entre outras.
Alm das prticas, Crystal dene diversos papis que podem ser assumidos pelos membros da
equipe. Pode-se citar o patrocinador, o projetista-programador snior, o projetista-programador e
o usurio. Esses quatro papis podem ser divididos em diversos outros papis que podem variar
de acordo com o projeto. Por exemplo, o projetista-programador pode ser dividido em projetista
das classes de negcio, programador, documentador do software e testador unitrio. Outros papis
importantes que podem ser atribudos a alguns dos quatro j citados so: coordenador, especialista
do negcio e analista de requisitos.
Em resumo, a famlia de processos Crystal pode ser classicada como uma metodologia gil
que possui um ciclo de desenvolvimento incremental, altamente adaptvel, podendo adequar-se
a diversos tipos e tamanhos de projetos, e altamente escalvel, podendo trabalhar com equipes
grandes ou pequenas.
2.9 Produzindo documentao de forma gil
Todo processo de desenvolvimento de software precisa, em algum momento, produzir docu-
mentos que auxiliem no controle, gerncia ou construo do software. A documentao bastante
recomendada para permitir que o processo seja controlado e gerenciado de forma efetiva. No en-
tanto, a falta de controle sobre sua produo pode tornar o processo oneroso. (Forward, 2002;
Ambler, 2002).
Uma pesquisa realizada sobre a produo e o uso de documentao durante o processo de
desenvolvimennto revelou informaes importantes.
Sobre a produo de documentos, a pesquisa constatou que os documentos produzidos rara-
mente so atualizados como deveriam, com exceo dos documentos referentes a testes e quali-
dade. Alm disso, a pesquisa revelou que os engenheiros de software (ES) s mantm os documen-
tos atualizados quando esses esto amarrados, de alguma forma, aos processos utilizados durante o
desenvolvimento e que eles utilizam e conam nos documentos que descrevem recursos referentes
a projeto e arquitetura do sistema (Elrad et al., 2003).
Sobre a utilizao de documentos, os dados obtidos mostraram que apenas 6% dos entrevista-
dos perdem tempo considervel lendo documentao e 50% perdem tempo considervel consul-
tando o cdigo fonte. Esses dados ressaltam a importncia da boa estruturao, padronizao e
documentao dos cdigos-fonte.
A pesquisa mostrou ainda que a documentao, mesmo desatualizada, tem grande importncia
no desenvolvimento e que os ES preferem a criao e utilizao de documentao simples e po-
derosas e tendem a ignorar documentaes complexas e custosas (custosas referem-se ao tempo
necessrio para criar e atualizar a documentao).
Por m, a pesquisa concluiu que os ES procuram encontrar um caminho para expressar infor-
maes em um menor espao e de forma que permita uma fcil atualizao, alm de atualizarem
somente certos tipos de documentao, os que entendem ser os mais teis para o desenvolvimento.
Os dados apresentados na pesquisa reforam a idia de que a comunicao essencial para o
desenvolvimento e que a documentao pode ter uma importncia secundria frente mecanismos
de comunicao ecientes.
De acordo com o artigo Agile Documentation (Agile Modeling Web Site, 2006), a impor-
tncia da documentao secundria frente a importncia da comunicao. Os autores do artigo
acreditam que deve-se produzir apenas os documentos sucientes para o andamento do projeto
e que uma documentao abrangente no garante o sucesso do projeto, pelo contrrio, pode au-
mentar as chances dele falhar. Outro aspecto destacado pelos autores que antes de criar um
documento preciso analisar se seus benefcios so maiores do que os custos para sua criao e
manuteno.
Para a realizao de um processo de documentao gil deve-se considerar quatro razes bsi-
cas para a criao de um documento (Agile Modeling Web Site, 2006):
1. Quando os envolvidos no projeto desejam que ele seja criado: A criao de um documento
fundamentalmente uma deciso de negcio.
2. Para denir o modelo contratado. Esses modelos denem a interao do sistema com outros
sistemas, ou com sistemas externos. Interaes as vezes so bi-direcionais.
3. Para auxiliar na documentao com grupos externos. Esses documentos so geralmente
combinados com reunies peridicas, teleconferncias, emails, ferramentas colaborativas,
etc.
4. Para processos de auditoria. Nessas situaes importante criar apenas os documentos su-
ciente para mostrar o trabalho realizado.
Considerando-se essas razes, acredita-se que os documentos que devemser produzidos emum
projeto gil referem-se a contratos, decises de projeto, vises de negcio, operaes, requisitos
e documentos de apoio ao desenvolvimento, ao sistema e ao usurio (Agile Modeling Web Site,
2006): .
Alm disso, uma documentao gil pode ser caracterizada por seis aspectos principais (Agile
Modeling Web Site, 2006):
1. Os documentos so produzidos para maximizar o investimento dos envolvidos no projeto
2. Os documentos geis so enxutos e sucientes
3. Os documentos so coesos e satisfazem o simples propsito denido pelo projeto. Sempre
que a criao do documento for duvidosa deve-se parar e repensar sua criao.
4. Os documentos geis descrevem coisas importantes a serem sabidas
5. Os documentos geis tm um destinatrio especco e facilitam o esforo de trabalho do
mesmo.
6. Os documentos geis so sucientemente corretos, consistentes e detalhados.
Somando-se a esses aspectos, um processo de documentao gil precisa possuir estratgias
para identicar qual o momento de atualizar os documentos. Sugere-se que os contratos sejam
atualizados antes do incio do desenvolvimento e que os documentos referentes as partes do sistema
(documentos de operaes, manual de usurios) devem estar atualizados e prontos para publicao
antes ou junto com o prprio sistema. Outra sugesto que todo documento produzido deve
ser atualizado quando o consumidor do documento comea a reduzir signicativamente sua
produtividade por causa da desatualizao (Agile Modeling Web Site, 2006).
Outro ponto importante sobre o processo de documentao gil saber como aumentar a do-
cumentao que produzida. Uma estratgia para realizar essa tarefa deve vericar quem so os
potenciais consumidores, identicar o que eles desejam e negociar qual o mnimo de informa-
es que eles necessitam. Alm disso, preciso manter nos documentos apenas o suciente e da
forma mais simples possvel. A utilizao de ferramentas e a produo de contedos e modelos
simples ajudam nessa tarefa (Agile Modeling Web Site, 2006).
Concluindo, um bom processo de documentao deve sempre priorizar a comunicao frente
a documentao. Quando no for possvel satisfazer as necessidades atravs de mecanismos de
comunicao, deve-se produzir documentao. No entanto, a documentao deve ser produzida
em local adequado (ex: no cdigo fonte, notas em diagramas, etc) e sua criao deve ser adiada o
mximo possvel. Sempre que possvel, os documentos criados devem ser publicados, aumentando
o poder da comunicao e reduzindo a necessidade de documentao.
2.10 Consideraes Finais
Neste captulo foram abordados os conceitos envolvidos com as metodologias geis de desen-
volvimento. Os estudos realizados permitiram identicar algumas caractersticas presentes nas
metodologias geis estudadas. Tais caractersticas possibilitaram a realizao de uma anlise que
destacou semelhanas e diferenas existentes entre elas.
Os resultados da anlise foram teis para identicar algumas caractersticas que so impor-
tantes em uma metodologia gil e, com isso, serviram como base para a criao do Modelo de
Referncia gil. As caractersticas, os resultados da anlise e o modelo de referncia esto apre-
sentados no Captulo 5.
CAPTULO
3
Gerncia e planejamento de projetos
A gesto de projetos , atualmente, alvo de importantes discusses na rea de engenharia de
software. Existe um consenso, entre os pesquisadores da rea, de que a gesto eciente de projetos
imperativa na busca pela qualidade de resultados (de Castro Magalhes et al., 2005; Darci, 2003).
Dessa forma, realizou-se umestudo sobre as tcnicas de auxlio a gesto e planejamento de projetos
e alguns assuntos estudados so apresentados neste captulo.
O captulo est organizado da seguinte forma. Na Seo 3.2 so apresentadas algumas das
tcnicas estudadas que acredita-se que podem ser teis para planejar e gerenciar projetos geis e
na Seo 3.3 so apresentadas algumas consideraes nais sobre este captulo.
3.2 Tcnicas de auxlio gesto de projetos
Com o intuito de padronizar a gesto de projetos, o PMI (Project Management Institute) criou
um guia, denominado de PMBOK (Projetc Management Body of knowledge), que objetiva iden-
ticar o subconjunto do conjunto de conhecimentos em gerenciamento de projetos que ampla-
mente reconhecido como boa prtica (Project Management Institute, 2004). Em outras palavras,
o PMBOK visa servir como guia para a gesto de projetos, fornecendo uma viso geral de prticas
que, reconhecidamente, trazem bons resultados.
Dentre as diversas tcnicas sugeridas pelo guia, destaca-se a Estrutura Analtica de Projetos
(EAP). Uma EAP, do Ingls Work Breakdown Structure (WBS), subdivide o trabalho do projeto
25
CAPTULO 3. GERNCIA E PLANEJAMENTO DE PROJETOS 26
em partes menores e mais facilmente gerenciveis. O trabalho planejado dividido em nveis, cada
vez mais detalhados, que possibilitam agend-lo, estim-lo, monitor-lo e control-lo, alm de
possibilitar a visualizao das entregas do projeto (Kerzner, 2006; Project Management Institute,
2004; Sliger, 2006). Um exemplo de uma EAP apresentado na Figura 3.1
Figura 3.1: Exemplo de uma EAP para um projeto (Project Management Institute, 2004)
Algumas outras tcnicas sugeridas pelo PMBOK que merecem destaque referem-se a repre-
sentao de sequenciamento de atividades. O Mtodo de Diagrama de Precedncia (MDP) um
exemplo dessas tcnicas. O MDP um mtodo de construo de um diagrama de rede que usa
caixas ou retngulos, chamados de ns, para representar atividades e os conecta por setas que
mostram as dependncias (Project Management Institute, 2004). Um exemplo de uma MDP
apresentada na Figura 3.2
Outro mtodo bastante utilizado para representar o sequenciamento de atividades o Mtodo
de Diagrama de Setas (MDS). O MDS um mtodo de construo de um diagrama de rede do
cronograma do projeto que usa setas para representar atividades e as conecta nos ns para mostrar
suas dependncias (Project Management Institute, 2004). Um exemplo de uma MDS apresentado
na Figura 3.3
Essas e outras tcnicas fazem o PMBOK ser um guia amplamente reconhecido pelos gerentes
de projeto. No entanto, acredita-se que o PMBOK mais adequado a projetos de grande porte,
pois o gerenciamento desses tipos de projetos so geralmente mais complexos e burocrticos. Para
outros tipos de projetos, a gesto informal pode ser mais adequada (Kerzner, 2006; de Castro Ma-
galhes et al., 2005).
A gesto informal uma forma de gerenciamento menos burocrtica. Ela reduz a necessidade
de documentao e substitui diretrizes formais por listas de vericao menos detalhadas e mais
Figura 3.2: Exemplo de um MDP que representa o sequenciamento de atividades (Project
Management Institute, 2004)
genricas. Kerzner, em (Kerzner, 2006), aponta quatro elementos chave para a implementao da
gesto informal de projetos: conana, comunicao, cooperao e trabalho em equipe.
Para Kerzner, a conana leva os gerentes a acreditarem que os encarregados cumprem suas
tarefas de forma adequada, reduzindo a necessidade de documentao; a comunicao, que pode
ocorrer vertical ou lateralmente, evita a emisso de relatrios e reunies longas, os dois grandes
obstculos da gesto informal; a cooperao est relacionada com a atitude dos envolvidos no
projeto, geralmente voluntria e acontece em benefcio de todos os envolvidos; o trabalho em
equipe permite a troca de idias, o alto ndice de inovaes e criatividade, o aumento da conana
e a lealdade entre os membros da equipe.
As caractersticas da gesto informal fazem acreditar que esse tipo de gerenciamento pode ser
adequado s metodologias geis. No entanto, surgiram alguns modelos de gerenciamento direta-
mente direcionados pelo paradigma gil.
Um exemplo desses modelos o Extreme Project Mangement (XPM), que surgiu com o intuito
de orientar a gerncia e o planejamento de projetos geis, atravs de facilitaes mudanas r-
pidas e de um planejamento orientado pelos resultados (Catrine Jacobsen, 2001; Charles Ludwig,
2003). Focado, principalmente, na metodologia XP, o XPM guia a gesto de projetos atravs de
um processo de gerenciamento criativo e voltado para os resultados. Segundo Catrine, em (Catrine
Jacobsen, 2001; Boehm e Turner, 2005), O XPM abrange o planejamento e o replanejamento di-
rios. Todas as alteraes referentes a contexto, externas e internas (risco, escopo, objetivos, etc),
so identicadas e avaliadas diariamente..
Outra abordagempara o gerenciamento de projetos geis a Agile Project Management (APM),
que caracteriza-se por uma superposio de ordem, pela auto-organizao, pela inteligncia cole-
Figura 3.3: Exemplo de um MDS que representa o sequenciamento de atividades (Project
tiva e pela habilidade notvel de adaptar-se a ambientes dinmicos e complexos (de Castro Ma-
galhes et al., 2005).
Os criadores da APM destacam as habilidades de liderana. Eles acreditam que a liderana
deve combinar viso de negcio, habilidades de comunicao, gerncia exvel e compreenso
tcnica com a habilidade para planejar, coordenar e executar.
Como nas metodologias geis os clientes denem as prioridades e as equipes auto-organizam-
se para atingir os objetivos denidos pelos clientes, os gerentes cam mais livres para agirem como
lderes. O principal papel do gerente, nessa abordagem, direcionar o desenvolvimento, facilitar
a colaborao e o trabalho em equipe, denir regras simples, certicar-se de que as regras esto
sendo cumpridas e aplicar apenas o controle suciente para manter a ordem, sem interferir muito
na liberdade e criatividade da equipe.
Neste captulo foram abordadas algumas propostas e tcnicas utilizadas atualmente para o ge-
renciamento de projetos. Apesar do PMBOK ser caracterizado por um gerenciamento mais buro-
crtico, as tcnicas apresentadas no adicionam muita burocracia ao processo e podem auxiliar no
planejamento do projeto.
O conhecimento adquirido com o estudo das metodologias geis e das tcnicas de gerencia-
mento serviu como base para a criao de um modelo de referncia para o desenvolvimento gil
de software. O modelo criado aborda as caractersticas das metodologias geis atravs de proces-
sos de desenvolvimento e de diagramas que auxiliam no planejamento de projetos. O modelo de
referncia est apresentado no Captulo 5.
CAPTULO
4
O norma ISO/IEC 15504
A norma ou modelo ISO/IEC 15504 contm um guia para a avaliao de processos de software.
Coma avaliao de umprocesso, pretende-se determinar foras e fraquezas e, comisso, possibilitar
um processo de melhoria.
Atravs das cinco partes que o compem, o modelo pretende orientar um processo de avaliao
completo, inclusive orientando a apresentao de resultados obtidos.
Este captulo tem o objetivo de descrever o processo completo de avaliao ou determinao
da capacidade de processos, conforme especicado na ISO/IEC 15504. Na Seo 4.2 so descritos
os objetivos do modelo. Na Seo 4.3 so descritas as cinco partes que compem o modelo e na
Seo 4.4 so apresentadas algumas consideraes sobre este captulo.
4.2 Introduo ao modelo de referncia ISO/IEC 15504
A busca por qualidade de software cresce a cada dia. Segundo a norma de qualidade ISO/IEC
9126, a qualidade de software pode denida como A totalidade de caractersticas de um produto
de software que lhe confere a capacidade de satisfazer necessidades explcitas e implcitas.
Empresas do setor buscam, cada vez mais, formas de garantir que seus produtos de software
sejam produzidos com qualidade. Para isso, procuram adequar seus processos de desenvolvimento
a modelos de referncia reconhecidos, visando uma melhora nos processos e nos produtos de
software.
30
CAPTULO 4. O NORMA ISO/IEC 15504 31
Para auxiliar a melhoria dos processos de desenvolvimento, a International Organization for
Standardization (ISO) e a International Electrotechnical Comission (IEC), orgos normalizadores
com importncia internacionalmente reconhecida no setor de software, uniram-se atravs do pro-
jeto denominado Software Process Improvement and Capability dEterminations (SPICE) e criaram
o modelo de referncia para avaliao de processos chamado ISO/IEC 15504 (ou norma ISO/IEC
15504).
A norma tem por objetivo avaliar processos de software, visando a melhoria contnua e a de-
terminao da capacidade de processos. Para alcanar os objetivos do primeiro enfoque, melhorar
continuamente um processo, preciso caracteriz-lo. Isso feito com a especicao de quais
processos devem ser avaliados e com a determinao da capacidade de cada um deles. Tais in-
formaes possibilitam identicar foras e fraquezas do processo, permitindo um direcionamento
para a melhoria. O outro enfoque, determinar a capacidade dos processos, permite avaliar um
processo frente a um nvel de capacidade desejado, a m de identicar riscos envolvidos no em-
preendimento de um projeto (ISO/IEC, 2003a).
A norma divide-se em cinco partes que orientam o processo de avaliao. As cinco partes da
norma so descritas na Seo 4.3.
4.3 As cinco partes do modelo de referncia ISO/IEC15504
O modelo de referncia ISO/IEC 15504 composto por cinco partes que orientam todo o
processo de avaliao. As cinco partes so apresentadas na Figura 4.1.
Figura 4.1: Partes que compem a norma ISO/IEC 15504
A Parte 1 (Conceitos e vocabulrio) o ponto de entrada do modelo. Nela esto descritos os
termos e denies utilizados nas outras partes. Alm disso, descreve como as partes integram-se
e fornece orientao para selecion-las e us-las.
Na Parte 2 (Execuo de uma avaliao) so especicados os requisitos para avaliao de
processos. Os requisitos aumentam as chances dos resultados serem objetivos, imparciais, consis-
tentes, repetveis e representativos.
Alm disso, nessa parte denida uma estrutura de medidas para avaliao da capacidade do
processo. A estrutura de medidas composta por nove atributos de processo, agrupados em seis
nveis de capacidade, que denem uma escala ordinal de capacidade. A escala indica o nvel de
capacidade de um processo e aplicvel aos processos a serem avaliados. A estrutura de medidas
apresentada na Figura 4.2.
Figura 4.2: Nveis de capacidade e respectivos atributos de processo
Os nveis de capacidade podem variar de 0 a 5. Um nvel de capacidade determina a situao no
qual o processo se encaixa. Em outras palavras, um nvel de capacidade dene o grau de aderncia
do processo avaliado ao processo que est servindo de referncia para a avaliao. Na Figura 4.3
so apresentados os nveis de capacidade denidos pela norma ISO/IEC 15504 e as respectivas
situaes que representam.
Para o entendimento da capacidade do processo, tanto no contexto de melhoria como no
contexto de determinao da capacidade, algumas informaes referentes ao processo avaliado
so coletadas. Essas informaes permitem determinar a extenso com que o processo atinge seus
objetivos.
Para atingir os objetivos de uma avaliao, a ISO/IEC 15504 baseia-se em um modelo denomi-
nado Modelo de Avaliao de Processo. Esse modelo, bi-dimensional, formado pela dimenso
de processos e pela dimenso da capacidade.
A dimenso de processos fornecida por um ou mais modelos de referncia de processo, ex-
ternos a norma. Esses modelos denem um conjunto de processos devidamente caracterizados por
propsitos e sadas de processo. A dimenso da capacidade formada pela estrutura de medidas,
j descrita anteriormente e apresentada na Figura 4.2.
Figura 4.3: Nveis de capacidade e respectivos signicados
A estrutura do Modelo de Avaliao de Processos e seu aspecto bi-dimensional apresentado
na Figura 4.4.
Figura 4.4: Dimenses do modelo de avaliao de processo
De um modo geral, o Modelo de Avaliao de Processo relaciona-se com um ou mais modelos
de referncia e a base para o estabelecimento da capacidade do processo e para a coleta de
evidncias que justicam os nveis de capacidade estabelecidos.
Para determinar a capacidade de um processo preciso coletar evidncias que auxiliem nessa
tarefa. A coleta de evidncias deve ser feita de forma convel e repetvel e deve atender as
especicaes da norma ISO/IEC 15504.
Para que a coleta siga tais especicaes, preciso que o Modelo de Avaliao de Processos
atenda a alguns requisitos, tanto na dimenso da capacidade como na dimenso de processos. Os
requisitos ajudam a estabelecer um mecanismo formal e vericvel que representa os resultados
de uma avaliao como um conjunto de atributos de processo pontuados. Tais pontuaes so
atribudas de forma independente, para cada processo selecionado do modelo de referncia.
As pontuaes dos atributos de processo so atribudas de acordo com as evidncias de reali-
zao dos mesmos. As pontuaes so especicadas no modelo de medidas e, juntamente com os
atributos de processo, determinam o nvel de capacidade do processo. A Figura 4.5 apresenta as
pontuaes sugeridas pela norma ISO/IEC 15504.
Figura 4.5: Pontuaes sugeridas para os atributos de processo e seus respectivos signicados
Um nvel X de capacidade atribudo a um processo quando, para o processo avaliado,
todos os atributos de processo dos nveis anteriores a X recebem a pontuao F e todos os
atributos de processo do nvel X recebem as pontuaes L ou F. As pontuaes dos atributos
de processo e os respectivos nveis de capacidade que representam so apresentadas na Figura 4.6.
Em resumo, o Modelo de Medidas e o Modelo de Referncia de Processo formam o Modelo
de Avaliao de Processos, que serve como base para todo o processo de avaliao. Um forte rela-
cionamento entre esses trs elementos (Modelo de Medidas, Modelo de Referncia de Processo e
Modelo de Avaliao de Processo) pode ser observado. Na Figura 4.7 apresentada a estrutura do
processo de avaliao proposto pela norma ISO/IEC 15504. Nela possvel observar os relacio-
namentos existentes entre os elementos do processo, alm de algumas atividades essenciais para a
realizao efetiva de uma avaliao.
Figura 4.6: Pontuaes dos atributos de processo e respectivos nveis de capacidade
Uma das atividades da avaliao o planejamento. Acriao e documentao de um plano para
a avaliao fundamental. O plano deve conter as entradas e atividades que devem ser realizadas
durante a avaliao; os recursos e prazos requeridos para a realizao das atividades; a denio
dos envolvidos e suas responsabilidades no processo; os critrios de vericao de realizao dos
requisitos e as descries das sadas da avaliao.
Alm disso, o plano deve garantir a pertinncia da coleta e validao dos dados aos objetivos da
avaliao. Ao realizar tais atividades, preciso demonstrar explicitamente quais tcnicas e estrat-
gias foram utilizadas. Os resultados obtidos com a validao servem como base para a pontuao
dos atributos de processo e, com isso, subsidiam a caracterizao do processo em relao a sua
capacidade.
De um modo geral, a Parte 2 da norma ISO/IEC 15504 abrange todo o processo de avaliao.
Ela dene os elementos necessrios para a realizao de uma avaliao e descreve as atividades
que devem ser realizadas para a conduo da mesma. Desta forma, pode-se dizer que as outras
partes da norma servem para auxiliar e/ou guiar o processo de avaliao descrito na Parte 2.
Figura 4.7: Estrutura do processo de avaliao
A Parte 3 (Guia para executar uma Avaliao) fornece orientao no atendimento dos requisitos
mnimos para realizar uma avaliao, conforme especicada na Parte 2. Uma viso geral da avalia-
o do processo fornecida, alm de orientao para o processo. Tais orientaes so relacionadas
a ferramentas de apoio, a competncia da equipe envolvida e a alguns fatores que contribuem para
o sucesso do processo. Comprometimento, motivao, condencialidade das fontes de informa-
o so exemplos de fatores positivos (ISO/IEC, 2003b). Um exemplo de processo de avaliao
documentado pode ser encontrado no Anexo A da Parte 3 da norma.
A Parte 4 (Guia para usar no processo de melhoria e determinao da capacidade) orienta como
utilizar a avaliao de processo em um programa de melhoria ou determinao da capacidade do
processo. A Parte 4 ajuda a entender os resultados obtidos e, com isso, direciona os responsveis
para uma possvel melhoria dos processos que apresentam fraquezas (ISO/IEC, 2003c).
A Parte 5 dene um Modelo de Avaliao de Processo, compatvel com a Parte 2. O modelo
denido utiliza na dimenso de processos o modelo de referncia ISO/IEC 12207 Amd 1 e Amd 2
e na dimenso de capacidade a estrutura de medidas denida na Parte 2 (ISO/IEC, 2003d).
4.4 Consideraes nais
Este captulo apresentou o processo de avaliao especicado pela norma ISO/IEC 15504. De
uma forma geral, a norma orienta a avaliao de um processo, possibilitando a determinao de
sua capacidade e a orientao para um processo de melhoria.
Conforme descrito, a norma ISO/IEC 15504 possibilita que a partir de um modelo de refern-
cia de processos seja possvel determinar a capacidade de um processo. Isso signica dizer que
um processo de avaliao pode determinar o grau de aderncia de um processo a um modelo de
processo.
Essas consideraes levam a crer que uma avaliao de processo que baseia-se na norma
ISO/IEC 15504 e que utiliza como modelo de referncia um modelo que respeite as caracters-
ticas denidas pelas metodologias geis de desenvolvimento, pode determinar o quanto gil o
processo avaliado. Isso pode ser o mesmo que dizer que um processo de desenvolvimento ou no
um processo gil.
Baseando-se nos estudos realizados, no Captulo 5 apresentada uma proposta de um modelo
de referncia para o desenvolvimento gil de software. Presumi-se que o modelo proposto possa
ser utilizado em uma avaliao de processo, com o intuito de determinar se o processo avaliado
um processo de desenvolvimento gil.
CAPTULO
5
Uma proposta de um modelo de
referncia para o desenvolvimento gil
de software
Um modelo de referncia de processo serve para orientar a implantao de um processo em
um organizao, com o intuito de torn-lo repetvel e possvel de ser medido. Nesse contexto, o
modelo de referncia apresentado neste captulo tem o objetivo de orientar a implantao de um
processo de desenvolvimento de software, a m de torn-lo gil.
Na Seo 5.2 so apresentadas as caractersticas encontradas nas metodologias geis de desen-
volvimento estudadas. Na Seo 5.3 so apresentados os requisitos para um modelo de referncia
de processo. Na Seo 5.4 apresentada uma proposta de um modelo de referncia de processo
para o desenvolvimento gil de software. Por m, na Seo 5.5 so apresentadas algumas consi-
deraes nais sobre este captulo.
5.2 Categorizao das metodologias geis
As metodologias geis existentes atualmente realizam, de diferentes formas, atividades para
desenvolver software com qualidade e de forma gil. Nesse sentido, realizou-se um estudo com al-
38
CAPTULO 5. UMA PROPOSTA DE UM MODELO DE REFERNCIA PARA O
DESENVOLVIMENTO GIL DE SOFTWARE 39
gumas das metodologias geis mais conhecidas atualmente e pertencentes a Agile Alliance
1
(Agile
Alliance Web site, 2007).
As seis metodologias geis apresentadas no Captulo 2 so descritas em funo de valores,
prticas e papis que ditam o comportamento das pessoas envolvidas no desenvolvimento e as
diretrizes para a correta realizao do processo de desenvolvimento sugerido por elas. Uma an-
lise sobre as caractersticas, processos, ciclos de vida propostos por essas metodologias permitiu
observar semelhanas e diferenas.
Com relao aos processos e ciclos de vida, identicou-se alguns aspectos comuns, dentre os
quais:
Planejamento inicial do projeto
Entregas de verses
Desenvolvimento iterativo
Testes de software
Integrao contnua
O estudo proporcionou ainda a identicao de 37 caractersticas. Na Figura 5.1 so apresen-
tadas as caractersticas encontradas, o mapeamento para os processos da ISO/IEC 12207
2
e para o
modelo de referncia gil e as respectivas metodologias que as possuem.
Na Figura 5.1, a coluna Proc. Modelo gil indica o processo do modelo de referncia gil
que tem relao com a caracterstica. A coluna Proc. ISO/IEC 12207 indica o nome do processo,
no modelo de referncia de processos ISO/IEC 12207, que descreve atividades que assemelham-se
com a caracterstica. As colunas Caractersticas e as colunas com os nomes das metodologias
(XP, Scrum, FDD, DSDM, ASD e Crystal) representam as caractersticas encontra-
das e as metodologias analisadas, respectivamente.
As colunas referentes as metodologias so preenchidas com X quando elas possuem a carac-
terstica relacionada, com N quando no possuem a caracterstica relacionada e no so preen-
chidas quando nenhuma referncia caracterstica foi encontrada na metodologia.
Uma breve anlise sobre os dados obtidos permite observar que 27% das caractersticas so
encontradas nas 6 metodologias estudadas e 37,8% so encontradas em pelo menos 4 delas. Esses
nmeros conrmam o alto grau de semelhana existente entre essas metodologias.
1
uma organizao no lucrativa que promove o desenvolvimento gil (Agile Alliance Web site, 2007)
2
A norma ISO/IEC 12207 um modelo de referncia de processos de desenvolvimento de software. Ela divide
o ciclo de vida do desenvolvimento do software em cinco grupos de processos (Fundamentais, Apoio, Organizacio-
nais e Adaptao), que so subdivididos em dezenove macro processos de desenvolvimento. Os processos descritos
na ISO/IEC 12207 englobam todo o ciclo de desenvolvimento do software e podem servir como referncia para a
implantao de um processo de desenvolvimento em uma empresa (ISO/IEC, 1999)
Figura 5.1: Categorizao das metodologias geis de desenvolvimento.
Alm disso, 13,5% so encontradas, no mximo, em 2 metodologias e 16,2% so encontradas
em exatamente 3 delas. Somando-se esses percentuais chega-se ao ndice de 29,7% de caractersti-
cas que esto presentes em, no mximo, 3 metodologias. O baixo percentual indica o baixo ndice
de diferenas existentes entre as metodologias. Esse fato refora a idia de que as metodologias
geis existentes atualmente so bastante semelhantes.
O alto grau de semelhana aumenta as chances de criao de um modelo de referncia gil que
no contrarie as premissas das metodologias geis existentes atualmente e que respeite o manifesto
gil.
Dessa forma, o modelo de referncia gil foi dividido em quatro grupos de processos que, por
sua vez, foramsubdivididos emdezesseis processos. Adiviso emquatro grupos de processos e em
dezesseis processos foi baseada nas caractersticas semelhantes dos ciclos de vida utilizados pelas
metodologias estudadas e visaram a concepo de um ciclo de vida prprio para o modelo. Alm
de inuenciarem a diviso, os estudos e anlises realizados tambm inuenciaram a elaborao
dos processos.
5.3 Requisitos para ummodelo de referncia de processo
Um modelo de referncia de processos serve como guia para a implantao de processos. Para
que um processo seja considerado um modelo de referncia, ele deve conter uma declarao do
domnio do modelo, uma descrio dos processos que o compe e uma descrio do relaciona-
mento entre os processos denidos por ele (ISO/IEC, 2003e).
O elemento fundamental dentro do modelo a descrio dos processos. A descrio deve
incorporar uma declarao do propsito do processo, a qual descreve em alto nvel os objetivos da
execuo do processo, e o conjunto de sadas que demonstram sucesso na realizao do propsito
do processo. Uma declarao de sada pode descrever a produo de um artefato, uma signicante
alterao de estado e/ou o atendimento das restries especicadas (requisitos, objetivos, etc).
Na Seo 5.4 apresentado um modelo de referncia que objetiva orientar a implantao de
processos de desenvolvimento geis.
5.4 Um modelo de referncia para o desenvolvimento
gil de software
Esta seo descreve uma proposta de um modelo de referncia para o desenvolvimento gil
de software. O modelo apresentado direcionado a desenvolvedores de software e gerentes de
projetos de software que desejam aplicar tcnicas que tornem o processo de desenvolvimento gil.
5.4.1 Declarao do domnio
O modelo de referncia gil de software fornece um conjunto de processos, atividades e tarefas
que orienta o processo de desenvolvimento de software para que possa ser realizado de forma gil.
O modelo pode ser utilizado para o construo de software, independentemente do ambiente de
operao do mesmo.
5.4.2 Processos do modelo de referncia
O modelo de referncia composto por 16 processos, distribudos dentro de quatro grupos
de processos - Processos de Inicializao (INI), Processos de Desenvolvimento Iterativo (DES),
Processos de Operao (OPE) e Processos de Apoio (APO) - que abrangem todo o ciclo de desen-
volvimento.
O Grupo de Processos de Inicializao responsvel por iniciar o projeto e preparar o ambiente
para o incio das iteraes. Os processos desse grupo so responsveis por iniciar as negociaes
do projeto com o cliente e, em paralelo, iniciar atividades para recrutar e organizar as equipes
que integraro o projeto e preparar o ambiente de desenvolvimento, inclusive realizando testes
com possveis arquiteturas. Um planejamento global para o projeto tambm deve ser realizado,
considerando-se as estrias
3
denidas at o momento.
Passada a fase de inicializao, inicia-se a fase de desenvolvimento. O Grupo de Processos
de Desenvolvimento Iterativo responsvel pelo desenvolvimento do software e pelo renamento
3
Funcionalidades identicadas pelos clientes que devem ser produzidas pelo projeto.
dos produtos e processos. Os processos desse grupo formam o ciclo iterativo do modelo, uma das
caracterstica fortemente aplicadas pelas metodologias geis.
O ciclo inicia-se com o planejamento das iteraes. Aps planejar a iterao, iniciam-se ati-
vidades para a produo das estrias e testes automatizados e para o tratamento dos riscos. Aps
serem produzidas, as estrias so integradas e, ao nal de cada iterao, os produtos e os processos
passam por atividades de renamento, visando uma melhoria para a prxima iterao. Os proces-
sos do ciclo de desenvolvimento podem ocorrer diversas vezes dentro do projeto, possibilitando a
construo de diversas verses do software.
Aps a construo de uma primeira verso, inicia-se a fase que trata da operao do software.
O Grupo de Processos de Operao abrange as atividades referentes a instalao de verses, manu-
teno e encerramento do projeto. Dentro do processo de encerramento est previsto a realizao
de atividades para produzir e/ou atualizar os documentos necessrios ao projeto e a entrega de um
produto nal.
Por m, e no menos importante, est o Grupo de Apoio. Os processos que compem esse
grupo ajudam a assegurar a qualidade dos produtos intermedirios e nais, garantem a padroni-
zao dos processos e produtos e auxiliam no controle de verses de software. Esses processos
auxiliam no desenvolvimento do projeto durante todo o projeto.
Na Figura 5.2 so apresentados os grupos de processo que compem o modelo de referncia
gil e as interaes entre eles.
Figura 5.2: Grupos de processos do modelo de referncia gil e as interaes entre eles.
Como j citado, o modelo de referncia composto por 16 processos. Na Figura 5.3 esto
apresentados os 16 processos, e seus respectivos grupos, que compem o modelo de referncia
gil.
Os processos so detalhados em propsito, prticas bsicas, resultados e produtos de trabalho
de entrada e sada. O propsito descreve os objetivos do processo, os resultados descrevem os
Figura 5.3: Grupos de processos do modelo de referncia gil e seus respectivos processos.
resultados esperados com a correta realizao do processo, as prticas bsicas descrevem as ati-
vidades que devem ser realizadas para alcanar os resultados e os propsitos do processo e os
produtos de trabalho descrevem os artefatos que so consumidos (produtos de trabalho de entrada)
e produzidos (produtos de trabalho de sada) pelo processo.
Essa forma de detalhamento foi baseada no template para um modelo de avaliao de proces-
sos, da norma ISO/IEC 15504 (ISO/IEC, 2003d). O template ainda apresenta, para cada prtica
bsica, uma ou mais referncias para os resultados que a prtica produz. O template apresentado
na Figura 5.4.
Os processos do Modelo de Referncia gil, e o respectivo grupo ao qual pertencem, so
apresentados a seguir.
5.4.3 Grupo de Processos de Inicializao (INI)
INI.01 Denio e evoluo das estrias e requisitos
Propsito: O propsito deste processo identicar, de forma gil, as necessidades do software
a ser desenvolvido.
Figura 5.4: Template para um modelo de avaliao de processos (ISO/IEC, 2003d).
Prticas bsicas: Para que os resultados esperados sejam atingidos, algumas prticas bsicas
devem ser realizadas. As prticas bsicas necessrias a este processo so:
INI.01.PB01. Estabelecer mecanismos de comunicao. Denir quais mecanismos de
comunicao sero utilizados para monitorar as necessidades e o nvel de satisfao do
cliente. Os mecanismos escolhidos devempermitir uma comunicao direta e eciente
entre cliente e desenvolvedor. [Resultado: 1]
Nota 1: Exemplos de mecanismos que podem facilitar essa tarefa so os
workshops e as reunies regulares com a participao de clientes e desen-
volvedores.
INI.01.PB02. Obter estrias e requisitos no-funcionais. Auxiliar o cliente a denir
as estrias e os requisitos no-funcionais que faro parte do projeto. Um especialista
do domnio deve integrar a equipe de desenvolvimento e permanecer no mesmo local
de trabalho da mesma (Cockburn, 2002). [Resultado: 2]
Nota 1: O especialista do domnio responsvel por esclarecer eventuais
dvidas sobre os requisitos e sobre as interfaces de usurio e por direcio-
nar o desenvolvimento. A proximidade entre especialista e desenvolvedor
possibilita um feedback visual e funcional rpido, aumentando as chances
de maximizar a qualidade de fatores de qualidade, como a usabilidade, a
corretitude e a facilidade de adaptar-se a novas situaes (extendibilidade).
INI.01.PB03. Avaliar as requisies de evoluo de requisitos e incorpor-las ao pro-
jeto. Avaliar o impacto das evolues, aprov-las quando for conveniente e atualizar a
lista de estrias e requisitos no-funcionais. [Resultado: 2]
INI.01.PB04. Divulgar. Realizar a divulgao dos requisitos atravs de mecanismos
de comunicao ecientes. A divulgao dos requisitos aumenta o entendimento dos
desenvolvedores sobre as necessidades do cliente e pode aumentar a produtividade da
equipe (Highsmith, 2002).[Resultado: 3]
INI.01.PB05. Produzir a lista de estrias e de requisitos no-funcionais. Produzir um
documento que contenha a especicao das estrias e dos requisitos no-funcionais
de forma clara, concisa, consistente e no ambgua. [Resultado: 4]
Nota 2: A Lista de Estrias e de Requisitos No-funcionais deve ser de-
nida e priorizada pelo cliente (Highsmith, 2002). As estrias devem ser
descritas de forma resumida, sem muito detalhes, pois o detalhamento
obtido antes do incio da implementao. Na Figura 5.5 apresentado um
exemplo de uma Lista de Estrias e de Requisitos No-funcionais j priori-
zada.
Figura 5.5: Exemplo de uma Lista de Estrias e de Requisitos No-funcionais j priorizada.
INI.01.PB06. Produzir o modelo de negcios do sistema. Produzir um modelo de
negcios que represente como as estrias descritas na Lista de Estrias e de Requisitos
No-funcionais sero produzidas e sob quais regras funcionaro. [Resultado: 5]
Resultados: Para que este processo possa ser considerado um processo implementado, deve
haver indcios da realizao de algumas atividades e/ou a produo de alguns artefatos. Tais ativi-
dades e artefatos referem-se a(o):
1. Existncia de mecanismos de comunicao ecientes entre cliente e desenvolve-
dor;
2. Existncia de mecanismos que identiquemas necessidades do cliente e incorporem-
nas ao projeto;
3. Existncia de um mecanismo para divulgao dos requisitos e/ou das alteraes
de requisitos;
4. Produo da lista de estrias e de requisitos no-funcionais;
5. Produo de um modelo de negcios do sistema;
Produtos de trabalho: Os processos produzem ou consomem produtos de trabalho. Os produtos
de trabalho necessrios a este processo so:
Produtos de trabalho de entrada Produtos de trabalho de sada
- Requisio de evoluo - Lista de estrias e de requisitos no-
funcionais
- Modelo de negcios do sistema
INI.02 Recrutamento e treinamento de pessoal
Propsito: O propsito deste processo fornecer indivduos com habilidades e conhecimentos
sucientes para realizar efetivamente as tarefas referentes ao projeto.
INI.02.PB01. Identicar habilidades e competncias necessrias ao projeto. Identi-
car quais caractersticas so desejadas em um indivduo que ir compor a equipe de
desenvolvimento do projeto. As caractersticas so obtidas baseando-se nas particula-
ridades do projeto. [Resultado: 1]
Nota 1: Algumas caractersticas que devem ser includas so: habilidades
tcnicas, habilidades de trabalho em equipe, facilidade de adaptao a no-
vas realidades, facilidade de realizar diversas funes dentro do projeto.
Essas caractersticas compem um perl adequado para um indivduo que
ir trabalhar em um projeto gil (Cockburn e Highsmith, 2001).
INI.02.PB02. Recrutar indivduos qualicados. Realizar atividades de recrutamento
que identiquem indivduos com as habilidades e competncias desejadas. [Resulta-
dos: 2, 3]
INI.02.PB03. Denir uma estratgia para treinar os indivduos recrutados. Produzir
um plano para capacitar os indivduos a agirem conforme necessidades do projeto e
de acordo com a losoa gil implantada. [Resultados: 2, 3]
Nota 1: O plano para capacitar os indivduos deve almejar a excelncia
tcnica de todos. A excelncia tcnica um dos fatores que maximiza as
possibilidades das metodologias geis adaptarem-se a novas situaes. A
facilidade de adaptar-se a novas situaes (Extendibilidade) um fator de
qualidade que deve ser considerado em um processo de garantia de quali-
dade (Mnkandla e Dwolatzky, 2006).
INI.02.PB04. Treinar indivduos. Prover indivduos capacitados a agirem conforme
necessidades do projeto e de acordo com a losoa gil implantada. [Resultados: 2,
3, 4]
1. Denio das habilidades e competncias desejadas nos indivduos envolvidos
no projeto.
2. Existncia de indivduos capazes de seguir a losoa gil implantada.
3. Existncia de indivduos capazes de realizar diversas funes dentro do projeto.
de trabalho referentes a este processo so:
- Descrio do projeto - Plano de treinamento
- Indivduos capacitados e treinados
INI.03 Preparao do ambiente de desenvolvimento
Propsito: O propsito deste processo manter um ambiente de desenvolvimento estvel e
convel para a realizao dos processos.
INI.03.PB01. Identicar as necessidades referentes ao ambiente de desenvolvimento.
[Resultado: 1]
Nota 1: Os requisitos para o ambiente de desenvolvimento devem incluir
necessidades referentes a hardware, software, mtodos, ferramentas, tcni-
cas, padres, facilidades de desenvolvimento, operao e manuteno.
INI.03.PB02. Adquirir elementos necessrios ao ambiente e disponibiliz-los. Adqui-
rir os elementos necessrios, prepar-los e disponibiliz-los para utilizao. [Resul-
tado: 2]
INI.03.PB03. Realizar testes no ambiente de desenvolvimento. Garantir que a a tecno-
logia e arquitetura escolhidas para o projeto funcionam satisfatriamente no ambiente
de desenvolvimento e, possivelmente, em ambiente operacional. [Resultado: 3, 4]
INI.03.PB04. Fornecer auxlio aos usurios do ambiente de desenvolvimento. Pro-
ver auxlio, aos usurios do ambiente, na utilizao e na manuteno dos elementos
disponibilizados. [Resultado: 5]
INI.03.PB05. Manter e prover melhorias ao ambiente de desenvolvimento. Manter
o ambiente de desenvolvimento em bom funcionamento, corrigir problemas e prover
melhorias. [Resultado: 4]
1. Identicao e especicao dos requisitos necessrios ao ambiente de desenvol-
vimento para a realizao dos outros processos;
2. Aquisio dos elementos necessrios ao ambiente de desenvolvimento.
3. Realizao de testes, no ambiente de desenvolvimento, com a tecnologia e arqui-
tetura escolhidas para o projeto.
4. Existncia de um ambiente de desenvolvimento estvel e convel.
5. Existncia de indivduos aptos a utilizarem o ambiente de desenvolvimento de
forma efetiva.
- Descrio do processo - Ambiente de desenvolvimento
INI.04 Projeto arquitetural do software e do sistema
Propsito: O propsito deste processo fornecer um projeto arquitetural para o software e
para o sistema, que represente os requisitos especicados e que descreva como os elementos do
software e do sistema se integram em um sistema nal completo.
INI.04.PB01. Denir a arquitetura do sistema. Interpretar os requisitos do sistema e
denir uma arquitetura que identique elementos de hardware, software e manuais de
operao, inclusive a base de dados. [Resultado: 1]
Nota 1: Aarquitetura do sistema deve ser projetada para operar independen-
temente de plataforma. Essa deciso auxilia a garantir a compatibilidade e
portabilidade do sistema. A compatibilidade e portabilidade so fatores de
qualidade que devem ser considerados em um processo de garantia de qua-
lidade (Mnkandla e Dwolatzky, 2006).
INI.04.PB02. Especicar interfaces. Especicar interfaces internas e externas entre os
elementos do software e do sistema. [Resultado: 3]
Nota 1: Uma boa especicao das interfaces entre os elementos do soft-
ware e do sistema aumenta a manutenibilidade. A manutenibilidade um
fator de qualidade que deve ser considerado em um processo de garantia de
qualidade (Mnkandla e Dwolatzky, 2006).
INI.04.PB03. Denir projeto de banco de dados. Denir a estrutura do banco de
dados. [Resultado: 4]
INI.04.PB04. Denir a arquitetura do software. Interpretar os requisitos do software e
denir uma arquitetura que descreva a estrutura geral do software e de seus elementos
e as interaes existentes entre eles. [Resultado: 2]
Nota 1: Um bom projeto arquitetural do software pode aumentar a reusabi-
lidade de seus componentes. A reusabilidade um fator de qualidade que
deve ser considerado em um processo de garantia de qualidade (Mnkandla
e Dwolatzky, 2006).
INI.04.PB05. Vericar consistncia com os requisitos. O cliente deve auxiliar os
desenvolvedores a garantir a consistncia do projeto arquitetural do software e do sis-
tema com os requisitos do software e do sistema. A proximidade do cliente equipe
de desenvolvimento minimiza inconsistncias com os requisitos, j que o feedback do
cliente pode ser obtido rapidamente (Cockburn e Highsmith, 2001). [Resultado: 5]
INI.04.PB06. Divulgar resultados s partes envolvidas. Divulgar s partes envolvidas
o projeto arquitetural do sistema, o projeto arquitetural do software e as interfaces
especicadas. Adivulgao deve ser realizada atravs de mecanismos de comunicao
ecientes. Um exemplo de um mecanismo de divulgao eciente a impresso do
projeto arquitetural do sistema e do software em um banner e a disponibilizao do
banner em local visvel e de fcil acesso aos desenvolvedores. [Resultado: 6]
1. Existncia de um projeto arquitetural do sistema;
2. Existncia de um projeto arquitetural do software;
3. Denio de interfaces internas e externas de cada elemento do sistema e do
software;
4. Denio do projeto de banco de dados
5. Existncia de um mecanismo que permita ao cliente e aos desenvolvedores veri-
car a consistncia do projeto com os requisitos do software e do sistema;
6. Existncia de um mecanismo de divulgao do projeto arquitetural do sistema e
do software e de seus relacionamentos.
- Modelo de negcios de sistema - Projeto arquitetural do sistema
- Lista de estrias e de requisitos no-
funcionais
- Projeto arquitetural do software
- Projeto de banco de dados
INI.05 Planejamento global do projeto
Propsito: O propsito deste processo planejar atividades e realizar estimativas iniciais refe-
rentes ao processo de desenvolvimento.
INI.05.PB01. Denir o escopo do software. Produzir uma declarao inicial, clara
e no abgua do escopo do software. O escopo deve conter uma declarao explcita
de dados quantitativos (ex.: nmero de usurios simultneos, tempo de respostas),
restries e/ou limitaes de qualquer espcie, estrias e verses, lista de tarefas, e
deve estar preparado para sofrer modicaes (Crocker, 2003). [Resultado: 1]
INI.05.PB02. Realizar estimativas. Estimar, supercialmente, os recursos, custos e
atividades necessrios para o desenvolvimento do projeto. As estimativas, nesse ponto
do projeto, devem ser feitas de forma supercial, pois ainda no se conhece as estrias
com detalhes. As estimativas devem ser melhoradas no planejamento das iteraes.
[Resultado: 2]
INI.05.PB03. Estabelecer um cronograma de utilizao dos recursos. Denir quais re-
cursos sero alocados para o projeto e quando sero utilizados e liberados. [Resultado:
3]
INI.05.PB04. Denir uma estratgia para a integrao contnua das estrias. Uma es-
tratgia para a integrao contnua deve denir o local (hardware, software e ferramen-
tas) de integrao e as atividades que devem ser realizadas para realizar a integrao.
[Resultado: 4]
INI.05.PB05. Estabelecer um mecanismo de monitoramento do feedback do cliente.
Estabelecer mecanismos que auxiliem na captao do feedback do cliente, identi-
cando pontos positivos e negativos dos produtos intermedirios e nais. A realizao
de workshops ao nal das iteraes auxiliam nessa tarefa. [Resultado: 1]
Nota 1: O feedback do cliente importante para maximizar a corretitude
e a usabilidade do sistema e, com isso, aumentar a satisfao do prprio
cliente.
INI.05.PB06. Estabelecer um plano global para o projeto. Produzir um plano global
para o projeto que descreva os objetivos do projeto, as principais estrias e as poss-
veis verses do software, a estrutura inicial das equipes e suas responsabilidades, os
especialistas do domnio (pessoa relacionada ao cliente) que faro parte da equipe de
desenvolvimento, as reunies regulares, o tempo de durao de cada iterao, o crono-
grama de utilizao dos recursos, as estimativas, a estratgia de integrao contnua,
os mecanismos de monitoramento do feedback. Um template para um plano global do
projeto apresentado na Figura 5.6. [Resultado: 5]
Nota 1: As equipes devem possuir papis e responsabilidades bem deni-
dos. Os membros de uma equipe podem acumular funes e responsabili-
dades durante um projeto ou iterao.
Nota 2: Em uma equipe devem existir, no mnimo, trs funes: Res-
ponsvel pelo priorizao das estrias (pessoa responsvel por determinar a
prioridade das estrias e divulgar aos interessados), Especialista do Dom-
nio (pessoa com conhecimento aprofundado do domnio do problema) e
Gerente de Projeto (pessoa que gerencia o projeto, auxilia a equipe em
momentos de caos, resolve problemas polticos e externos ao desenvolvi-
mento).
1. Existncia de uma declarao inicial do escopo do software;
2. Existncia de estimativas superciais para o desenvolvimento do projeto;
3. Existncia de um cronograma de utilizao dos recursos;
4. Existncia de uma estratgia para a integrao contnua;
5. Estabelecimento de mecanismos de monitoramento do feedback do cliente;
6. Existncia de um plano global para o projeto;
funcionais
- Plano global do projeto
Figura 5.6: Template para a elaborao de um Plano Global para um projeto gil.
5.4.4 Grupo de Processos de Desenvolvimento Iterativo (DES)
DES.01 Planejamento das iteraes
Propsito: O propsito deste processo priorizar, detalhar e estimar (nesse ponto feita uma
estimativa melhorada) as estrias e denir quais delas faro parte da prxima iterao.
DES.01.PB01. Priorizar estrias. Priorizar as estrias denidas pelo cliente. Oprprio
cliente o responsvel por denir e priorizar as estrias. [Resultado: 1]
DES.01.PB02. Detalhar e estimar estrias. Detalhar cada estria e estimar os esforos
necessrios para produz-las. As estimativas so realizadas pela equipe de desenvolvi-
mento. [Resultado: 1]
DES.01.PB03. Denir estrias para a prxima iterao. Denir quais estrias sero
desenvolvidas na prxima iterao. O cliente o responsvel por denir quais estrias
devem ser desenvolvidas na prxima iterao. [Resultado: 2]
DES.01.PB04. Criar casos de teste de integrao e denir os resultados esperados.
Criar ou adaptar casos de teste, e os respectivos resultados esperados, para integrar as
estrias a serem desenvolvidas na prxima iterao. A criao de casos de teste de
integrao, nesse ponto do processo, possibilita que as estrias sejam integradas as-
sim que forem implementadas, adicionando agilidade ao processo de desenvolvimento
(Schwaber e Beedle, 2004). [Resultado: 1]
DES.01.PB05. Estabelecer mecanismos para detectar novas estrias e inclu-las ao
projeto. As novas estrias podem ser desenvolvidas durante a iterao corrente, se
forem originadas de uma estria pertencente a iterao, ou podem ser adicionadas na
lista de estrias a serem desenvolvidas nas prximas iteraes. [Resultado: 3, 1]
Nota 1: A qualidade de realizao dessa tarefa garante a gerncia do escopo
do projeto e da iterao, e possibilita ao cliente obter feedback freqente dos
custos do projeto (Mnkandla e Dwolatzky, 2006).
DES.01.PB06. Criar um plano para a iterao. Criar um plano para a iterao que
contenha os objetivos da iterao, as estrias a serem desenvolvidas, as estimativas de
cada estria, os casos de teste de integrao, as equipes e suas responsabilidades. O
plano para a iterao deve ser concebido em conjunto com o cliente. Na Figura 5.7
apresentado um template para um Plano para a Iterao. [Resultado: 4]
1. Existncia de uma lista de estrias priorizadas e estimadas pelo cliente.
2. Existncia de uma lista contendo as estrias que sero desenvolvidas na prxima
iterao.
3. Existncia de casos de teste de integrao, para as estrias a serem desenvolvidas
durante a iterao.
4. Existncia de uma estratgia para detectar novas estrias e adicion-las ao projeto
ou a iterao.
5. Existncia de um plano para a prxima iterao.
Figura 5.7: Template para a elaborao de um Plano para a Iterao.
- Projeto arquitetural do sistema - Plano para a iterao
- Projeto arquitetural do software - Casos de teste de integrao
funcionais
- Plano global do projeto
DES.02 Produo de estrias
Propsito: O propsito deste processo codicar e documentar estrias atravs da utilizao
de tcnicas de implementao que produzam cdigos mais ecientes, mais simples e com menos
erros.
DES.02.PB01. Criar casos de teste de unidade e resultados esperados. Criar ou adaptar
casos de testes unitrios, e respectivos resultados esperados, para as estrias a serem
produzidas. Os casos de teste devem ser criados antes do incio da codicao das
estrias. Essa prtica permite que as estrias implementadas possam ser validadas
assim que a implementao for concluda. [Resultado: 1]
DES.02.PB02. Produzir cdigo de software que implemente as estrias. Os cdigos
devem ser produzidos com o auxlio de ferramentas de desenvolvimento. O cdigo
deve ser padronizado, documentado, simples e devem implementar os requisitos mi-
nimamente, ou seja, somente o que o cliente quer, sem nenhum recurso adicional
(Williams, 2003). [Resultado: 2, 5]
Nota 1: A produo de cdigo simples e de requisitos mnimos, aliada
comunicao intensa com o cliente, resposta rpida s alteraes de
requisitos e criao de casos de teste antes da codicao, aumenta as
chances do sistema ser construdo de forma correta. A corretitude um
fator de qualidade que deve ser considerado em um processo de garantia de
qualidade (Mnkandla e Dwolatzky, 2006).
Nota 2: A padronizao e documentao do cdigo aumentam a manuteni-
bilidade, a reusabilidade e a ecincia. A manutenibilidade, a reusabilidade
e a ecincia so fatores de qualidade que devem ser considerados em um
processo de garantia de qualidade (Mnkandla e Dwolatzky, 2006). Na Fi-
gura 5.8 apresentado um exemplo de um checklist que orienta a criao
de um cdigo-fonte padronizado e documentado.
Nota 3: Uma prtica denominada refactoring bastante til para a produ-
o de cdio padronizado e documentado. A prtica, aplicada por diver-
sas metodologias geis, encoraja os desenvolvedores a alterarem o cdigo
para torn-lo mais claro e eciente (Highsmith e Cockburn, 2001; Boehm,
2002).
DES.02.PB03. Realizar testes unitrios. Executar os casos de teste pr-denidos. Os
testes unitrios devem ser realizados de forma automatizada ou semi-automatizada
(Highsmith, 2002). [Resultado: 3]
Nota 1: A execuo dos testes unitrios ajuda na validao e vericao do
software. As atividades de validao e vericao devem ser consideradas
em um processo de garantia de qualidade (Mnkandla e Dwolatzky, 2006).
DES.02.PB04. Armazenar os resultados dos testes unitrios realizados. Os resultados
dos testes podem ser utilizados para serem comparados a resultados de testes poste-
riores. [Resultado: 4]
1. Existncia de casos de teste unitrio para validar as estrias;
Figura 5.8: Exemplo de um checklist para a padronizao e documentao do cdigo-fonte
(Microsoft, 2007).
2. Existncia de estrias implementadas satisfatriamente;
3. Realizao de testes unitrios;
4. Registro dos resultados dos testes realizados;
5. Existncia de cdigo de software padronizado e documentado;
funcionais
- Casos de teste unitrio
- Modelo de negcios do sistema - Estria implementada
- Projeto arquitetural do sistema - Resultados dos testes unitrios
- Projeto arquitetural do software
- Plano para a iterao
- Ferramentas de desenvolvimento
- Padres de codicao
DES.03 Tratamento de riscos
Propsito: O propsito deste processo identicar, analisar, tratar e monitorar os riscos do
projeto de forma contnua e iterativa.
DES.03.PB01. Identicar riscos. Identicar os riscos do projeto durante a realizao
das iteraes. Os riscos devem ser identicados iterativamente e devem ser registrados
em locais visveis (quadro, lousa, ferramenta) e de fcil acesso aos desenvolvedores.
Aps identicados, os riscos devem ser colocados na pauta da reunio do dia, para
serem analisados (Highsmith, 2000). [Resultado: 1]
Nota 1: Exemplos de riscos que podem ser identicados so: custos, cro-
nogramas, recursos, etc.
DES.03.PB02. Analisar riscos. Analisar os riscos qualitativamente, produzindo uma
lista priorizada, indicando quais podero ser eliminados e quais sero monitorados. Os
resultados da anlise podem inuenciar o trabalho planejado para a iterao corrente.
[Resultado: 1]
Nota 1: O resultado da anlise deve ser mantido em local visvel e de fcil
acesso aos desenvolvedores. Lousas e quadros podem ser utilizados para
esse m (Highsmith, 2000).
DES.03.PB04. Denir/realizar aes para gerenciar os riscos. Denir/realizar ativi-
dades para gerenciar o risco, eliminar o risco ou reduzir seu impacto. Essa tarefa
realizada por todos os membros da equipe e as decises tomadas devem estar em
locais visveis e de fcil acesso aos desenvolvedores. Lousas e quadros podem ser
utilizados para esse m. [Resultado: 2]
Nota 1: As reunies regulares, as mtricas de performance, os workshops
ao nal de cada iterao, entre outras prticas, auxiliam o gerenciamento
dos riscos.
1. Existncia de atividades que identiquem, analisem e priorizem os riscos;
2. Realizao de aes para a eliminao e/ou gerenciamento do risco.
- Plano para a iterao - Lista de riscos identicados
- Atividades para o gerenciamento de riscos
DES.04 Integrao contnua
Propsito: O propsito deste processo combinar as unidades do software e do sistema (itens
de software, de hardware, outros sistemas) produzindo itens integrados, consistentes com o projeto
e que demonstrem que as estrias e os requisitos no-funcionais esto satisfatoriamente implanta-
dos em uma plataforma operacional completa.
DES.04.PB01. Executar os procedimentos de integrao. Integrar as unidades de
software produzidas em uma plataforma operacional, de acordo com a estratgia de
integrao denida no planejamento global do projeto. [Resultado: 1, 2]
DES.04.PB02. Realizar testes de integrao. Executar os casos de teste de integrao,
denidos no planejamento das iteraes, com cada item integrado, de acordo com a
estratgia de integrao denida. [Resultado: 1, 2]
Nota 1: A realizao dos testes de integrao ajudam a validao e veri-
cao do software. As atividades de validao e vericao devem ser
consideradas em um processo de garantia de qualidade (Mnkandla e Dwo-
latzky, 2006).
DES.04.PB03. Armazenar os resultados dos testes de integrao. [Resultado: 3]
1. Execuo de procedimentos de integrao;
2. Existncia de uma verso do software com qualidade de produo;
3. Registro dos resultados dos testes de integrao realizados.
- Casos de teste de integrao - Verso integrada da estria
- Plano global do projeto - Resultados dos testes de integrao
- Estria implementada
DES.05 Renamento de produtos e processos
Propsito: O propsito deste processo renar (melhorar) continuamente a qualidade dos pro-
cessos e produtos a cada iterao.
DES.05.PB01. Identicar falhas ou problemas durante o desenvolvimento. Identicar
falhas ou problemas que ocorrem nos processos ou nos produtos de trabalho produzi-
dos durante o desenvolvimento. A realizao de workshops ao nal de cada iterao
auxilia nessa tarefa. [Resultado: 1]
DES.05.PB02 Armazenar falhas ou problemas encontrados pelo cliente ou desenvol-
vedores. As falhas e problemas encontrados so armazenadas para posterior consulta.
[Resultado: 3]
DES.05.PB03. Denir atividades de renamento (melhoria). Denir atividades para
renar (melhorar) os produtos e os processos na prxima iterao. Os produtos e
processos devem ser renados a cada iterao, proporcionando uma melhora na qua-
lidade dos produtos intermedirios e, consequentemente, do produto nal (Mnkandla
e Dwolatzky, 2006). [Resultado: 2]
DES.05.PB04 Realizar atividades de renamento (melhoria). Executar as atividades
de renamento (melhoria) pr-denidas. [Resultado: 4]
1. Identicao de falhas ou problemas em um ciclo de desenvolvimento.
2. Denio de atividades para renar os produtos e melhorar o desempenho dos
processos na prxima iterao.
3. Existncia de registros de falhas ou problemas encontrados durante o ciclo de
desenvolvimento.
4. Existncia de atividades de renamento das falhas ou problemas detectados.
- Plano global do projeto - Falhas e problemas encontrados
- Plano da iterao - Atividades de renamento (melhoria)
- Descrio do processo - Nova verso do produto e/ou do processo
- Produto de trabalho
5.4.5 Grupo de Processos de Operao (OPE)
OPE.01 Colocar verso em produo
Propsito: O propsito deste processo colocar em produo uma verso do software que
atende aos requisitos pretendidos.
OPE.01.PB01. Criar um guia de instalao que oriente a instalao de uma nova
verso do software. [Resultado: 1]
OPE.01.PB02. Denir critrios de instalao. Denir critrios que ajudem a demons-
trar que a instalao foi bem sucedida. [Resultado: 2]
OPE.01.PB03. Instalar a verso do software. Seguir os critrios e o guia de intalao
denidos e colocar a verso do software em ambiente operacional. Uma instalao
bem sucedida percebida quando os critrios de instalao so alcanados. [Resul-
tado: 3]
OPE.01.PB04. Armazenar os eventos e/ou resultados relevantes. [Resultado: 4]
OPE.01.PB05. Auxiliar o usurio na operao do software. Auxiliar os usurios a
operarem a nova verso do software de forma satisfatria. [Resultado: 5]
1. Existncia de um guia para colocar verses de software em ambiente de opera-
o;
2. Existncia de critrios a serem utilizados para demonstrar que a verso posta
em ambiente operacional est em conformidade com osrequisitos de instalao
denidos;
3. Existncia de uma verso de software instalada e operando no ambiente ao qual
se destina;
4. Registro de eventos e/ou resultados relevantes ocorridos durante a instalao;
5. Existncia de auxilio ao usurio na operao inicial da nova verso;
- Projeto arquitetural do sistema - Guia de instalao
- Projeto arquitetural do software - Relatrio de incidentes
- Verso do software - Plano de treinamento dos usurios
OPE.02 Manuteno
Propsito: O propsito deste processo gerenciar modicaes, na verso do software em
ambiente de operao, referentes a correo de defeitos, a adaptaes, ao desenvolvimento de
novas estrias e a facilidades de realizar os outros propsitos (correo de defeitos, adaptaes e
desenvolvimento de novas estrias).
OPE.02.PB01. Estabelecer estratgia para gerenciar modicaes. Produzir um plano
para gerenciar correes, adaptaes e/ou incluso de novas estrias verso de soft-
ware em operao. [Resultado: 1]
Nota 1: Frequentemente, uma equipe designada para realizar a manuten-
o do sistema. Essa prtica permite manter uma equipe desenvolvendo
novas estrias, enquanto outra realiza as correes necessrias. Para que
essa prtica adicione agilidade ao processo, preciso que a equipe de ma-
nuteno seja denida no planejamento global do projeto.
OPE.02.PB02. Receber solicitaes de modicao. Receber solicitaes de modi-
cao do cliente, atravs de um mecanismo de comunicao eciente. [Resultado:
2]
OPE.02.PB03. Analisar impacto das solicitaes. Determinar o impacto que as so-
licitaes solicitadas podem causar na verso de software em operao. [Resultado:
2]
OPE.02.PB04. Avaliar as solicitaes de modicao. Avaliar as solicitaes e deter-
minar se so viveis, aprovando ou reprovando a solicitao. O resultado da avaliao
deve ser armazenado para futuras consultas. [Resultado: 2]
OPE.02.PB05. Atualizar documentao. Atualizar os documentos que sero afetados
com as modicaes. [Resultado: 3]
OPE.02.PB06. Implementar e testar modicaes. Implementar e testar as modi-
caes, demonstrando que os requisitos e a integridade do sistema e do software no
foram compremetidos. [Resultado: 4]
OPE.02.PB07. Atualizar o sistema em operao. Transportar a verso modicada
do software para um ambiente operacional. A nova verso deve manter um grau de
funcionamento que deve ser aprovado pelo cliente. A aprovao do cliente deve ser
registrada. [Resultado: 5]
OPE.02.PB08. Divulgar modicaes. Divulgar as modicaes realizadas aos inter-
essados. [Resultado: 6]
1. Existncia de uma estratgia para gerenciar as modicaes necessrias e/ou re-
queridas pelo usurio.
2. Existncia de um mecanismo para receber solicitaes, analisar o impacto das
mesmas no projeto e aprovar ou reprovar as solicitaes.
3. Existncia de uma estratgia para atualizar os documentos afetados pelas modi-
caes.
4. Existncia de mecanismos que demonstrem que as estrias e requisitos imple-
mentados no foram comprometidos.
5. Existncia de um sistema com grau de funcionamento aceitvel em ambiente
operacional.
6. Divulgao das modicaes realizadas a todas as partes interessadas.
- Requisio de evoluo - Verso modicada do software
- Verso do software - Relatrio de modicaes
- Modelo de negcios do sistema - Registro de aceitao
- Projeto arquitetural do software - Plano de gerenciamento de manuteno
- Projeto arquitetural do sistema
OPE.03 Encerramento
Propsito: O propsito deste processo entregar ao cliente uma verso nal do sistema que
satisfaa os requisitos desejados.
OPE.03.PB01. Produzir e/ou atualizar documentos. Produzir e/ou atualizar os docu-
mentos que devem ser produzidos ou mantidos pelo projeto. [Resultado: 1]
Nota 1: Os documentos que no so necessrios, durante o desenvolvi-
mento, aos desenvolvedores e clientes, mas que devem ser produzidos pelo
projeto (de acordo com a lista de documentos a serem mantidos), so cria-
dos no processo de encerramento. Essa prtica adiciona agilidade ao pro-
cesso, pois evita que documentos sejam produzidos antes de serem necess-
rios e, com isso, economiza-se tempo de produao e atualizao (Schwaber
e Beedle, 2004).
OPE.03.PB02. Entregar verso completa do sistema ao cliente. Colocar a verso com-
pleta do sistema em operao e entregar para o cliente toda a documentao produzida.
[Resultado: 1, 2]
OPE.03.PB03. Treinar usurios. Capacitar os usurios do sistema a utilizarem-no de
forma adequada e eciente. [Resultado: 3]
1. Produzir documentao completa e atualizada do sistema.
2. Existncia de uma verso completa do software operando em local denido pelo
cliente.
3. Existncia de usurios capacitados a utilizar o sistema desenvolvido.
- Lista de documentos a serem mantidos - Verso completa do sistema
- Verso do software
5.4.6 Grupo de Processos de Apoio (APO)
APO.01 Gerncia de congurao de software
Propsito: O propsito deste processo identicar os itens de software que devem possuir
vrias verses e gerenciar as verses desses itens. O processo deve armazenar um histrico das
verses dos itens e permitir que as verses sejam recuperadas e/ou evoludas, compondo, no se-
gundo caso, uma nova verso.
APO.01.PB01. Estabelecer uma estratgia para a implantao de gerncia de con-
gurao. Produzir um plano de implantao de gerncia de congurao que inclua
a ferramenta de controle de verses, o esquema de identicao dos itens de con-
gurao, atividades para relatar o estado dos itens de congurao e o cronograma de
implantao da gerncia de congurao (Koskela, 2003). Na Figura 5.9 apresentado
um template para um plano de implantao de gerncia de congurao. [Resultado:
1, 2, 3, 4, 5]
APO.01.PB02. Selecionar os itens de congurao. Selecionar os itens que devem
ser identicados, armazenados, testados, utilizados, alterados, disponibilizados e/ou
mantidos no repositrio. O conjunto mnimo de itens de congurao exigidos em um
projeto gil apresentado na Figura 5.10. [Resultado: 2]
APO.01.PB03. Estabelecer um esquema de identicao para os itens de congura-
o. Denir um esquema de identicao que descreva a maneira como cada item
ser denominado. O esquema deve permitir conhecer a evoluo das verses de cada
item. Na Figura 5.11 apresentado um exemplo de um esquema de identicao com
o conjunto mnimo de itens de congurao exigidos em um projeto gil. [Resultado:
3]
APO.01.PB04. Controlar verses. Utilizar ferramentas para auxiliar no controle das
verses dos itens de congurao. A ferramenta deve bloquear o acesso a um item
Figura 5.9: Template de um Plano de Implantao de Gerncia de Congurao.
de congurao quando esse j estiver sendo acessado por algum usurio. Algumas
ferramentas que podem ser utilizadas para esse m so: Concurrent Versions System
(CVS) (Bar e Fogel, 2003), Subversion (Collins-Sussman et al., 2004). [Resultado: 4]
APO.01.PB05. Relatar situao dos itens de congurao. Relatar informaes atua-
lizadas sobre os itens de congurao. [Resultado: 5]
1. Existncia de um plano de implantao de gerncia de congurao;
2. Existncia de uma lista de itens de informao e/ou produtos de trabalho que
devem ser colocados sob controle de congurao;
3. Existncia de um esquema de identicao para os itens de congurao;
4. Existncia de uma ferramenta para auxiliar o controle de verses dos itens de
congurao;
5. Relato do estado dos itens de congurao.
Figura 5.10: Conjunto mnimo de itens de congurao em um projeto gil e os respectivos
processos que os produzem.
Figura 5.11: Exemplo de um esquema de identicao com o conjunto mnimo de itens de
congurao exigidos.
- Ferramenta para o controle de verses - Plano de implantao de gerncia de con-
gurao
- Lista de itens de informao - Repositrio de itens de congurao
APO.02 Preparao / Evoluo da documentao
Propsito: O propsito deste processo identicar quais informaes, produzidas pelos proces-
sos, precisam ser registradas para aumentar a produtividade e a qualidade dos processos e registrar
essas informaes de forma simples e padronizada.
APO.02.PB01: Identicar quais documentos precisam ser produzidos. Um novo do-
cumento deve ser produzido quando for percebido que sua ausncia est provocando
lentido ao processo e quando no houver um mecanismo de comunicao que sub-
stitua, ecientemente, a necessidade de sua criao (Agile Modeling Web Site, 2006;
Elrad et al., 2003). Essa atividade produz uma lista de documentos que devem ser pro-
duzidos. A Lista deve incluir informaes de quando o documento deve ser produzido
e/ou atualizado. Na Figura 5.12 apresentada uma sugesto de um conjunto mnimo
de documentos que deve ser produzido em um projeto gil. [Resultado: 1]
Figura 5.12: Conjunto mnimo de documentos que devem ser produzidos em um projeto gil e os
respectivos processos que os produzem.
Nota 1: Exemplo: Uma lousa (um mecanismo de comunicao) pode ser
utilizada para a apresentao das estrias adicionadas iterao, suprindo
a necessidade de criao de um documento que contenha tais estrias.
APO.02.PB02: Denir a linguagem e os padres para os documentos. Denir a lin-
guagem que deve ser utilizada e os padres que devem ser seguidos na produo dos
documentos. [Resultado: 3]
APO.02.PB03: Estabelecer a organizao, manuteno e localizao dos documentos.
Produzir um esquema para organizar os documentos, facilitar a localizao e denir
um mecanismo para armazenar, manter e/ou eliminar os documentos obsoletos. [Re-
sultado: 2, 4]
APO.02.PB04: Produzir e manter documentos. Produzir e manter os documentos
sempre padronizados e simples. [Resultado: 4]
Nota 1: Os documentos devem ter o detalhamento suciente para atingir
seus objetivo, devem ser de fcil manuteno e devem estar devidamente
identicados (Agile Modeling Web Site, 2006; Elrad et al., 2003).
APO.02.PB05: Divulgar a criao de documentos. Divulgar aos interessados que um
novo documento foi produzido, informando qual o seu contedo. [Resultado: 5]
1. Existncia de uma lista mnima de documentos que devem ser produzidos;
2. Estabelecimento da organizao dos documentos;
3. Denio de linguagem e padres a serem utilizados nos documentos;
4. Existncia de atividades que produzam e mantenham os documentos;
5. Existncia de atividades de divulgao.
- Requisitos do documento - Padres de documentao
- Lista de documentos a serem mantidos
APO.03 Reviso e garantia de qualidade
Propsito: O propsito deste processo assegurar que os produtos de software tenham quali-
dade (de acordo com os requisitos de qualidade especicados) e sejam produzidos de acordo com
os planos estabelecidos.
APO.03.PB01. Denir um modelo de qualidade. Estabelecer um modelo de qualidade
que contenha os fatores de qualidade que devem ser considerados e as mtricas a
serem utilizadas para avaliar os fatores estabelecidos. Os fatores de qualidade para as
metodologias geis so apresentados na Figura 5.13 (Mnkandla e Dwolatzky, 2006).
[Resultado: 1]
APO.03.PB02. Identicar as prticas de desenvolvimento que devem ser utilizadas
para garantir a qualidade. Identicar quais prticas geis sero teis para atingir os
Figura 5.13: Fatores de qualidade para as metodologias de desenvolvimento gil (Mnkandla e
Dwolatzky, 2006).
fatores de qualidade denidos no modelo de qualidade, relacionando as prticas aos
respectivos fatores. [Resultado: 2]
Nota 1: As prticas podem ser escolhidas dentre as diversas prticas geis
sugeridas pelas diversas metodologias geis existentes atualmente. Por
exemplo, a prtica Sprint da metodologia Scrum pode ser til para maxi-
mizar a qualidade do fator de qualidade denominado Custo-efetividade,
pois controla o escopo das iteraes e, com isso, pode auxiliar no controle
do oramento (Mnkandla e Dwolatzky, 2006).
APO.03.PB03. Denir uma estratgia para garantir que as prticas esto sendo exe-
cutadas corretamente. A estratgia deve descrever como a prtica deve ser aplicada e
como detectar problemas na forma com que a prtica est sendo executada. [Resul-
tado: 3]
APO.03.PB04. Produzir um plano de qualidade. Criar um plano que inclua o modelo
de qualidade, as prticas geis a serem utilizadas e a estratgia para garantir a correta
execuo das prticas. Na Figura 5.14 apresentado um template para um plano de
qualidade. [Resultado: 4]
APO.03.PB04. Revisar a execuo das prticas. Revisar a execuo das prticas para
garantir que esto sendo executadas corretamente. [Resultado: 5]
Figura 5.14: Template para o plano de qualidade.
APO.03.PB06. Denir aes de correo para as falhas encontradas na execuo das
prticas. Denir e priorizar aes a serem tomadas para solucionar problemas identi-
cados durante a reviso. [Resultado: 6]
1. Existncia de um modelo de qualidade;
2. Existncia de uma lista de prticas geis a serem utilizadas e os respectivos fa-
tores de qualidade que objetivam atender;
3. Existncia de uma estratgia para garantir a qualidade de execuo das prticas;
4. Existncia de um plano de qualidade;
5. Existncia de atividades de reviso das prticas geis identicadas;
6. Existncia de aes de melhoria.
- Fatores de qualidade - Plano de qualidade
5.4.7 Relacionamentos entre os processos
Independentemente dos grupos, os processos relacionam-se e criam uma certa dependncia
entre eles. Essas dependncias acabam por apontar a sequncia na qual os processos devem ocorrer
dentro de um projeto.
As depncias podem ser representadas atravs de um dos diversos mtodos aplicados para re-
presentar o sequenciamento de atividades. O Mtodo de Diagrama de Precedncia (MDP) tem esse
objetivo e representa as atividades atravs de retngulos e as dependncias atravs de setas (Project
Management Institute, 2004). Na Figura 5.15 so apresentadas, utilizando-se uma representao
adaptada do MDP, as dependncias existentes entre os processos do modelo. Na gura, os proces-
sos so representados por retngulos de cantos arredondados e as depend encias so representadas
atravs de setas contnuas. As setas tracejadas representam um relacionamento/dependncia no
obrigatria. Pode-se considerar como processos iniciais aqueles que no dependendem de nenhum
outro (no destino de nenhuma seta) e pode-se considerar como processos nais aqueles que no
so pr-requisitos de nenhum outro (no origem de nenhuma seta).
Figura 5.15: Representao das dependncias existentes entre os processos do modelo.
A representao dos relacionamentos permite entender melhor o ciclo de vida proposto pelo
modelo, inclusive permite visualizar o ciclo iterativo existente (o ciclo percorre os processos
DES.01, DES.02, DES.04, DES.05 e volta ao DES.01).
Para complementar essa representao, criou-se uma EAP com o intuito de dividir o trabalho
do projeto em partes menores e mais detalhadas (Project Management Institute, 2004).
Uma EAP permite visualizar os produtos de trabalho que devem ser produzidos pelos proces-
sos. Na EAP criada para o modelo de referncia so apresentados os processos, em segundo nvel,
e os produtos de trabalho (pacotes de trabalho), em terceiro nvel. A EAP apresentada na Figura
5.16.
Figura 5.16: EAP criada para o modelo de referncia gil.
Uma EAP pode ser complementada com a denio das atividades necessrias para a produo
dos produtos de trabalho. Para a EAP apresentada na Figura 5.16, foram identicadas as atividades
necessria para produzir os produtos de trabalho especicados. As atividades so relacionadas aos
respectivos produtos de trabalho que produzem e processo que pertencem e so identicadas por
uma numerao. Na Tabela 5.17 so apresentadas as atividades.
Tabela 5.17: Atividades necessrias para a produo dos pro-
dutos de trabalho
Processos do Modelo de
Referncia gil
Produtos de tra-
balho produzidos
pelo processo
Atividades necessrias para pro-
duzir os produtos de trabalho
INI.01 Denio e evolu-
o das estrias e requisi-
tos
Lista de estrias e re-
quisitos no funcio-
nais
1. Estabelecer mecanismo de comu-
nicao entre cliente e desenvolve-
dor
2. Obter estrias e requisitos no-
funcionais com o cliente
3. Produzir a lista de estrias e dos
requisitos no-funcionais.
Modelo de negcios
do sistema
4. Interpretar a lista de estrias e re-
quisitos no-funcionais
5. Produzir o modelo de negcios do
sistema
INI.02 Recrutamento e
treinamento de pessoal
Plano de treinamento 6. Identicar habilidades e compe-
tncias necessrias ao projeto
7. Traar um plano de treinamento.
Indivduos capacita-
dos e treinados
8. Recrutar indivduos com as habi-
lidades e competncias requeridas.
9. Treinar os indivduos recrutados
INI.03 Preparao do am-
biente de desenvolvimento
Ambiente de desen-
volvimento
10. Identicar as necessidades de re-
cursos dos processos de desenvolvi-
mento
11. Adquirir os recursos necessrios
aos processos
12. Realizar testes com os recursos
adquiridos no ambiente de desenvol-
vimento
13. Disponibilizar o ambiente de de-
senvolvimento
INI.04 Projeto arquitetural
do software e do sistema
Projeto arquitetural
do sistema
14. Interpretar a lista de estrias e
requisitos no-funcionais
15. Denir interfaces internas e ex-
ternas entre os elementos do sistema
16. Criar o projeto arquitetural do
sistema
Projeto arquitetural
do software
18. Denir interfaces internas e ex-
ternas entre os elementos do soft-
ware
19. Criar o projeto arquitetural do
software
Projeto de banco de
dados
21. Denir o sistema gerenciador de
banco de dados
22. Denir os tipos e estruturas de
dados
23. Criar o projeto de banco de da-
dos.
INI.05 Planejamento glo-
bal do projeto
Plano global do pro-
jeto
24. Denir o escopo do software
25. Realizar estimativas superciais
26. Denir cronograma de utiliza-
o dos recursos
27. Denir uma estratgia para a in-
tegrao contnua
28. Estabelecer mecanismo de mo-
nitoramento do feedback
29. Criar um plano global para o
projeto.
DES.01 Planejamento das
iteraes
Plano para a iterao 30. Priorizar estrias
31. Realizar estimativas melhoradas
das estrias
32. Denir quais estrias sero de-
senvolvidas na prxima iterao
33. Criar um plano para a prxima
iterao
Casos de teste de inte-
grao
34. Criar casos de teste para a in-
tegrao das estrias a serem desen-
volvidas
DES.02 Produo de est-
rias
Casos de teste unit-
rio
35. Obter descrio detalhada das
estrias a serem produzidas
36. Criar casos de teste unitrios
Estria implementada 37. Produzir cdigo de software que
represente as estrias
Resultados dos testes
unitrios
38. Executar procedimento de testes
unitrios
39. Armazenar os resultados dos
testes unitrios realizados
DES.03 Tratamento de ris-
cos
Lista de riscos identi-
cados
40. Identicar riscos do projeto
41. Registrar os riscos identicados
Atividades de geren-
ciamento de riscos
42. Analisar qualitativamente os ris-
cos identicados
43. Priorizar os riscos
44. Denir atividades de gerencia-
mento de riscos
DES.04 Integrao cont-
nua
Verso integrada da
estria
45. Executar procedimentos de inte-
grao
Resultados dos testes
de integrao
46. Realizar testes de integrao
47. Armazenar os resultados dos
testes de integrao
DES.05 Renamento de
produtos e processos
Falhas e problemas
encontrados
48. Identicar falhas ou problemas
durante o desenvolvimento
49. Armazenar falhas ou problemas
identicados
Atividades de rena-
mento (melhoria)
50. Denir atividades para renar
(melhorar) os processos ou produtos
Nova verso do pro-
duto e/ou do processo
51. Realizar atividades de rena-
mento (melhoria)
OPE.01 Colocar verso
em produo
Guia de instalao 52. Denir critrios de instalao
53. Criar um guia de instalao
Relatrio de inci-
dentes
54. Instalar a verso do software
55. Vericar conformidade com cri-
trios de instalao
56. Registrar os eventos e/ou resul-
tados relevantes
Plano de treinamento
dos usurios
57. Denir um plano para o treinar
os usurios
OPE.02 Manuteno
Plano de gerencia-
mento de manuteno
58. Denir atividades necessrias
para o gerenciamento da manuten-
o
59. Denir responsabilidades para
as atividades de manuteno
60. Criar um plano para o gerencia-
mento de manuteno
Verso modicada do
software
61. Receber solicitao de modi-
cao do cliente
62. Analisar impacto das solicita-
es de modicao
63. Avaliar as solicitaes de
modicao, aprovando-a ou
reprovando-a
64. Atualizar documentos afetados
pelas solicitaes aprovadas
65. Implementar e testar as solicita-
es de modicao aprovadas
66. Atualizar o sistema em operao
com as modicaes implementa-
das
Relatrio de modi-
caes
67. Relatar as modicaes imple-
mentadas
Registro de aceitao 68. Apresentar as modicaes im-
plementadas ao cliente
69. Registrar aceitao do cliente
OPE.03 Encerramento
Verso completa do
sistema
70. Produzir/Atualizar documentos
a serem entregues ao cliente
71. Apresentar ao cliente a verso
completa do sistema
APO.01 Gerncia de
congurao de software
Repositrio de itens
de congurao
72. Estabelecer um esquema para
identicar os itens de congurao
73. Selecionar os itens de congura-
o
Plano de implantao
de gerncia de con-
gurao
74. Denir uma estratgia de gern-
cia de congurao
APO.02 Preparao / Evo-
luo da documentao
Lista de documentos
a serem mantidos
75. Identicar quais documentos
precisam ser produzidos
76. Criar uma lista de documentos a
serem mantidos
Padres de documen-
tao
77. Denir uma linguagem para os
documentos.
78. Denir padres para os docu-
mentos.
79. Criar padro de documentao.
APO.03 Reviso e garan-
tia de qualidade
Plano de qualidade 80. Denir um modelo de qualidade
81. Denir as prticas geis para ga-
rantir a qualidade
82. Denir estratgia para garantir a
correta execuo das prticas
83. Criar um plano de qualidade
Entre as atividades existem dependncias que devem ser consideradas para a elaborao de um
cronograma. Essas dependncias podem ser representadas atravs de um dos mtodos de sequen-
ciamento de atividades, o Mtodo de Diagrama de Setas (MDS). Esse mtodo utiliza setas para
representar as atividades, as quais conectam-se a outras atividades atravs de ns, que representam
as dependncias (Project Management Institute, 2004).
Na Figura 5.17 apresentado um exemplo de um MDS que representa duas atividades, repre-
sentadas pelas setas numeradas, e as dependncias existentes entre elas, representadas atravs dos
ns.
Figura 5.17: Exemplo de um MDS que representa o sequenciamento de atividades (Project
A representao utilizada na Figura 5.18, que representa as atividades referentes ao modelo
de referncia gil, refere-se a uma maneira adaptada de utilizar o Mtodo de Diagrama de Setas
(MDS), descrito em (Project Management Institute, 2004). A gura utiliza-se de setas para repre-
sentar as atividades, as quais conectam-se a outras atravs de ns, que representam as dependn-
cias. As setas tracejadas representam movimentos vazios. Pode-se considerar como atividades de
incio aquelas que no dependendem de nenhuma outra (no destino de nenhuma seta) e pode-
se considerar com atividades nais aquelas que no so pr-requisitos de nenhuma outra (no
origem de nenhuma seta).
O Modelo de Referncia gil apresentado neste captulo fruto dos estudos realizados sobre
as metodologias geis de desenvolvimento. O modelo resume as caractersticas encontradas nas
metodologias geis em dezesseis processos que orientam todo o ciclo de desenvolvimento de soft-
ware.
Espera-se que este modelo sirva como um primeiro passo em busca de uma padronizao dos
processos de desenvolvimento geis. Espera-se ainda, que o Modelo de Referncia gil sirva como
referncia para a implantao de processos de desenvolvimento geis e para o direcionamento de
processos de melhoria.
O Modelo de Referncia gil foi utilizado como referncia em uma avaliao de processo que
seguiu as especicaes contidas no Modelo de Avaliao de Processos da norma ISO/IEC 15504.
A avaliao descrita em detalhes no Captulo 6
Figura 5.18: MDS que representa o sequenciamento das atividades que ocorrem nos processos
do modelo de referncia gil
CAPTULO
6
Estudo de caso
6.1 Consideraes iniciais
No Captulo 5 foi descrito o principal produto deste trabalho, o Modelo de Referncia para o
Desenvolvimento gil de Software. Esse modelo, desde sua concepo inicial, vem sendo renado
e a verso apresentada concretiza as evolues do modelo at o presente momento.
Neste captulo descrito um estudo de caso onde o modelo de referncia foi utilizado como
base para a avaliao de um processo de desenvolvimento. O estudo de caso teve o intuito de
utilizar o modelo de referncia para identicar fragilidades no processo avaliado e, com isso,
direcionar melhorias para o processo, visando torn-lo um processo gil. vlido ressaltar que
a avaliao realizada seguiu as especicao do modelo para avaliao de processo da ISO/IEC
15504.
Este captulo est organizado da seguinte forma. Na Seo 6.2 so apresentadas algumas in-
formaes sobre o processo de avaliao. Na Seo 6.3 so apresentadas a descrio do processo
avaliado, o processo de avaliao documentado e os resultados da avaliao. Finalmente, na Seo
6.4 so apresentadas algumas consideraes nais sobre este captulo.
6.2 O processo de avaliao
Uma avaliao de processo serve para entender a capacidade dos processos realizados em uma
organizao. O modelo de referncia para avaliao de processos da ISO/IEC 15504 (parte 2 da
83
CAPTULO 6. ESTUDO DE CASO 84
ISO/IEC 15504) um modelo de avaliao amplamente reconhecido e permite avaliar um processo
de desenvolvimento e determinar sua capacidade, com relao a um padro fornecido.
Acredita-se que um processo de desenvolvimento avaliado com o Nvel 2 de capacidade, atra-
vs de uma avaliao que segue os requisitos da ISO/IEC 15504 e que utiliza o Modelo de Refe-
rncia gil como padro, sucientemente gerencivel e aplica de forma efetiva e suciente as
prticas sugeridas pelas metodologias geis.
Na Seo 6.2.1 apresentada uma viso geral do processo de avaliao proposto pela ISO/IEC
15504.
6.2.1 O processo de avaliao segundo a norma ISO/IEC 15504
De acordo com o modelo ISO/IEC 15504, uma avaliao de processo deve ser conduzida de
acordo com um processo de avaliao documentado
1
e capaz de atender ao propsito da avaliao.
Um processo de avaliao documentado compreende um conjunto de instrues para conduzir
uma avaliao. As instrues devem agregar os seguintes aspectos (ISO/IEC, 2003e):
Denio das entradas de uma avaliao, tais como: propsito, escopo, restries e o modelo
de avaliao de processo a ser utilizado;
Denio dos papis chave e responsabilidades;
Orientaes referentes ao planejamento, coleta de dados, validao de dados, pontuaes
de atributos de processo e relato de resultados da avaliao. As pontuaes de atributos
de processo so especicadas no modelo ISO/IEC 15504-2 e auxiliam na determinao da
capacidade do processo, permitindo a classicao do processo em seis nveis de capacidade
(nveis que variam de 0 a 5);
Orientaes para o armazenamento dos resultados da avaliao.
Alm das instrues, um processo de avaliao documentado deve possuir a distino de alguns
papis, dentre os quais destacam-se o patrocinador, o lder da equipe, os assessores e o coordenador
local.
O patrocinador o indivduo que deseja que um processo de avaliao seja realizado. Ele
deve prover todas as condies para que os assessores realizem a avaliao de forma e-
ciente.
O lder da equipe a pessoa que lidera a execuo de uma avaliao e garante que a mesma
est conforme as especicaes do modelo ISO/IEC 15504. O lder tambm responsvel
pela organizao da equipe de avaliao e pela distribuio das responsabilidades.
1
Um processo de avaliao documentado descreve as atividades que devem ser realizadas durante um processo de
avaliao e dene as responsabilidades dos envolvidos no processo
Os assessores so os responsveis pela execuo da avaliao e so supervisionados por um
lder.
O coordenador local responsvel por gerenciar a logstica e a comunicao dos avaliadores
com a unidade organizacional. O coordenador, junto com o lder, tem a responsabilidade
de garantir a compatibilidade e disponibilidade de equipamento tcnico necessrios para a
avaliao e conrmar que o espao de trabalho e os requisitos de cronograma sero encon-
trados.
6.3 Avaliao do processo de desenvolvimento do Cen-
tro de Informtica
6.3.1 Descrio do processo de desenvolvimento do Centro de In-
formtica
O Centro de Informtica (CI) um departamento de uma Instituio de Ensino Superior (IES).
A IES uma instituio bem conceituada, situada na regio central paulista, mais precisamente
na cidade de So Carlos. A IES, que uma instituio particular, oferece, atualmente, cursos de
graduao, ps-graduao latu-sensu e capacitao gerencial nas reas de Exatas, de Humanas e
da Sade.
O CI produz software para consumo da prpria IES. Ele possui um produto principal, deno-
minado neste trabalho de Software de Gesto Educacional (SGE), que engloba diversos mdulos
direcionados aos diversos setores da IES. Os mdulos Acadmico, Financeiro e Vestibular so
exemplos de mdulos que, integrados, compem o SGE.
O CI composto, atualmente, por uma equipe de desenvolvimento formada por quatro pessoas.
Um coordenador, responsvel por direcionar o desenvolvimento e, junto com os diretores da IES,
denir as prioridades, e trs desenvolvedores, responsveis pela construo do software propria-
mente dita. Os desenvolvedores participam de todas as fases do desenvolvimento (planejamento,
anlise, codicao, testes e manuteno).
O processo atual de desenvolvimento do CI um processo evolutivo que adiciona funciona-
lidades ao sistema com o passar do tempo. Segundo os membros da equipe, o software evolui
conforme as funcionalidades vo sendo solicitadas e implementadas. No existe o conceito de
verses e, consequentemente, no existe um controle sobre elas. Isso signica que o SGE s
possui a verso atual, no sendo possvel recuperar verses anteriores.
No processo, as modicaes e solicitaes so realizadas informalmente e, dependendo da
criticalidade, precisam de uma autorizao dos diretores, que tambm feita informalmente. No
existe nenhum controle formal sobre as modicaes. Ao realizar alteraes, o desenvolvedor
realiza testes para valid-las e integr-las com a verso atual, e ento disponibiliza para o usurio.
Sempre que se inicia a concepo de um novo mdulo, os desenvolvedores, o coordenador e
os diretores reunem-se para realizar um planejamento. O planejamento feito supercialmente
e serve para dar um direcionamento ao processo, denir prazos de entrega (baseando-se nos re-
quisitos conhecidos at o momento) e denir o responsvel pelo mdulo. O responsvel pelo
mdulo um desenvolvedor que tem a funo de receber as solicitaes referentes quele mdulo
e implement-las (ou indicar algum para implement-las).
Sempre que a construo de um mdulo completada, um treinamento com os usurios envol-
vidos ministrado pelo responsvel pelo mdulo antes de disponibiliz-lo. A partir desse ponto,
as modicaes e evolues vo sendo implementadas conforme descrito anteriormente.
Observa-se que o processo do CI realizado de forma incremental, sem considerar o conceito
de verses. Outro aspecto importante que ao CI no se aplica um processo de encerramento, pois
o fato dos projetos estarem em contnua evoluo descarta essa possibilidade.
6.3.2 O processo de avaliao documentado
Fase inicial do processo de avaliao
Ao iniciar um processo de avaliao, necessrio denir alguns papis e realizar algumas
tarefas para que o processo seja condizente com o modelo ISO/IEC 15504. Os papis e tarefas
necessrios so apresentados a seguir:
Lder da equipe: Gustavo Vaz Nascimento. O lder tem a funo de liderar a equipe de desen-
volvimento e garantir que as pessoas integrantes da equipe possuam competncia e habilidades
necessrias.
Propsito da avaliao: Este processo de avaliao tem o objetivo de determinar a capacidade
do processo de desenvolvimento executado pelo CI. A avaliao deve identicar pontos fortes e
fracos do desenvolvimento e direcion-lo por um processo de melhoria, visando tornar o processo
de desenvolvimento gil.
Modelo de avaliao: O modelo de avaliao a ser utilizado um modelo bi-dimensional, se-
melhante ao sugerido pela norma ISO/IEC 15504. Na dimenso de capacidade est o framework
de medidas, apresentado no Apndice B, e na dimenso de processos est o Modelo de Referncia
gil, apresentado no Captulo 5.
Equipe de avaliao:
Elby Vaz Nascimento: mestrando em Engenharia de Produo e analista de sistemas com
5 anos de experincia. Sua funo de Assessor e Coordenador Local da Avaliao.
Gustavo Vaz Nascimento: mestrando em Engenharia de Software e analista de sistemas
com 4,5 anos de experincia. Sua funo de Assessor e Lder da Equipe.
Contexto da avaliao: A avaliao ser realizada no ambiente de desenvolvimento do Centro
de Informtica.
Escopo da avaliao: Esta avaliao visa investigar todos os processos denidos na dimenso
de processos do Modelo de Avaliao, que composto pelo Modelo de Referncia gil. A ava-
liao deve considerar os nveis 1 e 2 de capacidade, de acordo com o framework de medidas
apresentado no Apndice B. Um mapeamento dos processos da dimenso de processos do Modelo
de Avaliao para os processos executados pelo CI apresentado na Tabela 6.1.
Dimenso de processos do Modelo de
Avaliao
Mapeamento para os Proc. do CI
INI.01 Denio e evoluo das estrias
e requisitos
Denio de requisitos
INI.02 Recrutamento e treinamento de
pessoal
Recrutamento e treinamento de pessoal
INI.03 Preparao do ambiente de desen-
volvimento
Preparao do ambiente de desenvolvimento
INI.04 Projeto arquitetural do software e
do sistema
Projeto do software
INI.05 Planejamento global do sistema Planejamento do projeto
DES.01 Planejamento das iteraes No realizado
DES.02 Produo de estrias Codicao
DES.03 Tratamento de riscos No realizado
DES.04 Integrao contnua Testes de integrao
DES.05 Renamento de produtos e pro-
cessos
No realizado
OPE.01 Colocar verso em produo Instalao
OPE.02 Manuteno Manuteno
OPE.03 Encerramento No se aplica
APO.01 Gerncia de congurao de
software
No realizado
APO.02 Preparao / Evoluo da docu-
mentao
Documentao
APO.03 Reviso e garantia de qualidade Garantia de qualidade
Tabela 6.1: Mapeamento da dimenso de processos do Modelo de Avaliao para os processos
realizados pelo CI.
Restries: O processo OPE.03 Encerramento, descrito no Modelo de Avaliao, no
aplicvel a realidade do CI. Dessa forma, o processo OPE.03 Encerramento foi excludo da
avaliao.
Responsabilidades dos participantes da avaliao:
Gustavo Vaz Nascimento: Tem a responsabilidade de coletar e validar os dados para a exe-
cuo da avaliao, apresentar os resultados da avaliao aos interesados e liderar a equipe
durante a avaliao;
Elby Vaz Nascimento: Tem a responsabilidade de coletar e validar os dados para a exe-
cuo da avaliao e gerenciar a logstica e a comunicao dos avaliadores com a unidade
organizacional.
A realizao dessas atividades iniciais formam a base para a execuo de uma avaliao consis-
tente e convel. Alm das atividades, preciso traar um planejamento para a realizao da
avaliao. O plano de avaliao apresentado a seguir.
Plano de avaliao
Um plano de avaliao que descreve todas as atividades a serem realizadas na execuo de uma
avaliao precisa ser produzido e documentado junto com um cronograma. Para isso, preciso
identicar os recursos necessrios para a execuo da avaliao e garantir a disponibilidade dos
mesmos. Alm disso, preciso denir o mtodo que ser utilizado para coletar, rever, validar e
documentar todas as informaes requeridas.
As atividades do plano de avaliao orientam os avaliadores a executarem a avaliao de forma
organizada e disciplinada, tornando o processo de avaliao repetvel. A seguir esto apresentadas
as atividades previstas para a avaliao do processo realizado pelo CI.
1. Comunicado ocial: A unidade organizacional deve ser comunicada sobre os propsitos,
escopo, restries e modelos que sero utilizados na avaliao. O comunicado deve focar a
importncia dos benefcios que podem ser trazidos pelos resultados da avaliao. O lder da
equipe o responsvel por realizar o comunicado ocial.
2. Coleta dos dados: A coleta dos dados deve ser realizada pelos assessores, principalmente,
atravs da observao dos produtos de trabalho produzidos pelo processo e do comporta-
mento dos desenvolvedores. A observao da infra-estrutura do local de desenvolvimento e
os testemunhos dos envolvidos tambm devem ser considerados.
3. Validao dos dados: A validao dos dados deve ser feita em conjunto com a coleta dos
dados. Os assessores devem coletar os dados e valid-los, vericando se os dados coletados
tm relao com os indicadores de processo, denidos na dimenso de processos do Modelo
de Avaliao de Processo.
4. Avaliao dos atributos de processo: A avaliao dos atributos de processo consiste da atri-
buio de pontuao para os atributos de processo, de cada processo avaliado. As pontuaes
devem ser atribudas atravs de consenso entre a equipe de avaliao e devem respeitar o
framework de medidas, apresentado no Apndice B. Os processos de tomada de deciso, as
pontuaes dos atributos de processo e os clculos dos nveis de capacidade de cada processo
avaliado devem ser documentados. Os assessores e o lder da equipe so os responsveis por
julgar os dados coletados e atribuir as pontuaes.
5. Apresentao dos resultados da avaliao: Older da equipe deve preparar umrelatrio contendo
os resultados da avaliao, os pers dos processos, os pontos fortes e fracos, os fatores de
risco encontrados e as potenciais aes de melhoria. Os resultados da avaliao devem ser
apresentados aos envolvidos e devem ser documentados junto com uma descrio que ga-
rante que a avaliao satisfaz os requisitos especicados pela norma ISO/IEC 15504.
Cronograma: Na Figura 6.1 apresentado o cronograma para a realizao das atividades da
avaliao.
Figura 6.1: Cronograma para a realizao da avaliao.
6.3.3 Resultados da avaliao
A avaliao permitiu identicar pontos fortes e fracos no processo realizado pelo CI. Os pontos
fortes indicam caractersticas que aumentam as chances do processo ser um processo gil, j os
pontos fracos apontam aspectos a serem melhorados para que o processo possa ser considerado
um processo gil.
Ao nal da avaliao foi criada uma Estrutura Analtica de Projetos (EAP) (Figura 6.2), que
representa o estado no qual o processo de desenvolvimento realizado pelo CI foi encontrado. A
EAP permite observar os processos e produtos de trabalho sugeridos pelo Modelo de Referncia
gil e os processos e produtos de trabalho que so, de alguma forma, executados ou produzidos
pelo processo avaliado.
Na EAP, os produtos de trabalho produzidos e os processos realizados total ou parcial-
mente indicam, respectivamente, os produtos de trabalho sugeridos pelo modelo de referncia
e produzidos pelo processo do CI, e os processos de desenvolvimento sugeridos pelo modelo de
referncia e realizados pelo processo do CI. Essas indicaes auxiliam na diferenciao do que
sugerido pelo modelo de referncia e do que realmente produzido ou executado pelo processo do
CI.
Ainda na EAP, observa-se que o processo denominado OPE.03 Encerramento foi classicado
como Processo no aplicvel. Essa classicao indica que o processo no se aplica a realidade
do CI e, portanto, o processo foi desconsiderado na avaliao. Na Figura 6.2 apresentada a EAP.
Figura 6.2: EAP que representa o estado no qual o processo de desenvolvimento realizado pelo
CI foi encontrado.
Durante a avaliao, percebeu-se que para alguns processos no foram encontrados indcios
de realizao de processo. Para esses casos, foi atribudo a pontuao N para o Atributo de
Realizao do Processo e, consequentemente, os processos foram classicados com o Nvel 0 de
capacidade (ou Processo no realizado na EAP). Como complemento da avaliao, um plano de
implantao para cada um desses processos foi elaborado e sugerido ao CI. O processo denomi-
nado APO.01 Gerncia de congurao de software um exemplo de processo para o qual no
foram encontrados indcios de realizao. O Plano de Implantao sugerido para esse processo
apresentado na Figura 6.3.
Para todos os processos, com exceo do processo OPE.03 Encerramento, a avaliao seguiu
os passos denidos no plano de avaliao. Foram realizadas as tarefas de coleta e validao de
dados atravs da observao dos produtos de trabalho, do comportamento dos desenvolvedores, da
infra-estrutura e dos testemunhos dos desenvolvedores. Os dados coletados foram avaliados pelo
assessor e pelo lder da equipe. O consenso entre ambos possibilitou a atribuio das pontuaes
aos atributos de processo de cada processo avaliado e, consequentemente, permitiu a atribuio de
nveis de capacidade aos processos. Na Tabela 6.2 so apresentadas as pontuaes atribudas aos
atributos de processo de cada processo e o respectivo nvel de capacidade.
Tabela 6.2: Processos avaliados e pontuaes dos atributos
de processo.
Nome do processo Pontuao dos
Atributos de
Processo (AP)
Nvel de capaci-
dade
INI.01 Denio e evoluo das estrias
e requisitos
AP 1.1: P
AP 2.1: L
AP 2.2: P
Nvel 0
INI.02 Recrutamento e treinamento de
pessoal
AP 1.1: F
AP 2.1: L
AP 2.2: F
Nvel 2
INI.03 Preparao do ambiente de desen-
volvimento
AP 1.1: F
AP 2.1: F
AP 2.2: L
Nvel 2
INI.04 Projeto arquitetural do software e
do sistema
AP 1.1: L
AP 2.1: L
AP 2.2: F
Nvel 1
INI.05 Planejamento global do projeto AP 1.1: L
AP 2.1: F
AP 2.2: N
Nvel 1
DES.01 Planejamento das iteraes AP 1.1: N
AP 2.1: N
AP 2.2: N
Nvel 0
DES.02 Produo de estrias AP 1.1: P
AP 2.1: L
AP 2.2: N
Nvel 0
DES.03 Tratamento de riscos AP 1.1: N
AP 2.1: N
AP 2.2: N
Nvel 0
DES.04 Integrao contnua AP 1.1: L
AP 2.1: F
AP 2.2: L
Nvel 1
DES.05 Renamento de produtos e pro-
cessos
AP 1.1: P
AP 2.1: N
AP 2.2: N
Nvel 0
OPE.01 Colocar verso em produo AP 1.1: P
AP 2.1: L
AP 2.2: N
Nvel 0
OPE.02 Manuteno AP 1.1: P
AP 2.1: P
AP 2.2: N
Nvel 0
APO.01 Gerncia de congurao de
software
AP 1.1: N
AP 2.1: N
AP 2.2: N
Nvel 0
APO.02 Preparao / Evoluo da docu-
mentao
AP 1.1: L
AP 2.1: F
AP 2.2: L
Nvel 1
APO.03 Reviso e garantia de qualidade AP 1.1: N
AP 2.1: N
AP 2.2: N
Nvel 0
A classicao dos processos em nveis de capacidade revela possveis fragilidades exis-
tentes na execuo dos mesmos. Essas fragilidades indicam a necessidade de melhoria na reali-
zao do processo, visando uma realizao sucientemente gerenciada e gil.
Os processos classicados com Nvel 0 e Nvel 1 possuem, segundo o Modelo de Referncia
gil, alguns aspectos a serem melhorados em sua execuo. Para esses processos, algumas aes
de melhoria foram denidas e sugeridas ao CI.
As aes de melhoria tendema minimizar as falhas detectadas no processo avaliado e, comisso,
aumentar sua capacidade. Dessa forma, na Figura 6.4 apresentado um Relatrio de Apresenta-
o de Resultados, referente ao processo DES.04 Integrao contnua, contendo pontos fortes
e fracos encontrados durante a avaliao, as pontuaes de cada item que compe os atributos de
processo e algumas sugestes de aes de melhoria.
Acredita-se que os planos de implantao, elaborados para os processos no realizados
(APO.01, APO.03, DES.01, DES.03), e as aes de melhoria denidas nos relatrios de apresen-
tao dos resultados, elaborados para os processos com Nvel 0 e Nvel 1 de capacidade (INI.01,
INI.04, INI.05, DES.02, DES.04, DES.05, OPE.01, OPE.02, APO.02), podem proporcionar uma
melhora substancial na qualidade do processo de desenvolvimento do CI e, mais do que isso, pode
tornar o processo gil.
6.4 Consideraes nais
A avaliao apresentada neste captulo permitiu destacar aspectos positivos e negativos do
processo de desenvolvimento realizado pelo CI. Esses aspectos possibilitaram avaliao apontar
um caminho para uma melhoria.
Espera-se, como resultado de um processo de melhoria, que o processo a ser melhorado
assemelhe-se ao modelo de processo utilizado como referncia. Portanto, os resultados da ava-
liao do processo de desenvolvimento do CI possibilitaram direcionar um processo de melhoria,
visando tornar o processo avaliado semelhante ao Modelo de Referncia gil, utilizado como
referncia na avaliao. Acredita-se que um processo semelhante ao Modelo de Referncia gil
pode ser considerado um processo de desenvolvimento gil.
Dessa forma, espera-se que o Modelo de Referncia gil sirva como referncia para proces-
sos de melhoria, com o objetivo de transformar processos de desenvolvimento em processos de
desenvolvimento geis. Mais do que isso, espera-se que o Modelo de Referncia gil sirva como
referncia para a implantao de processo de desenvolvimento gil.
Figura 6.3: Plano de implantao de gerncia de congurao.
Figura 6.4: Relatrio de Apresentao de Resultados.
CAPTULO
7
Concluses e trabalhos futuros
7.1 Sntese do trabalho
H algum tempo as metodologias tradicionais de desenvolvimento de software vm ajudando
as empresas do setor a produzirem software com qualidade. O alto nvel de controle sobre os
processos de desenvolvimento, proporcionado por essas metodologias, e o forte embasamento nos
conceitos da engenharia de software so os responsveis pelo sucesso dessas metodologias.
Mesmo com o alto nvel de aceitao, algumas empresas de desenvolvimento esto optando
por metodologias alternativas as tradicionais ou, mais especicamente, por metodologias geis. A
busca por alternativas baseia-se no fato das metodologias geis serem menos burocrticas do que
as tradicionais e por proporcionarem um desenvolvimento altamente adaptvel e com respostas
rpidas mudanas. Essas caractersticas permitem um desenvolvimento gil que prima por en-
tregas rpidas de pequenas verses do software, pela satisfao do cliente, pela cooperao e pela
comunicao.
Este trabalho apresentou os principais conceitos sobre as metodologias geis de desenvolvi-
mento e uma anlise sobre seis das principais metodologias geis existentes atualmente, desta-
cando suas caractersticas e apontando semelhanas e diferenas entre elas.
Os assuntos abordados embasaram a concepo de um Modelo de Referncia para o Desen-
volvimento gil de Software, o principal resultado deste trabalho. O modelo rene as principais
caractersticas encontradas nas metodologias geis em dezesseis processos de desenvolvimento
que visam servir como guia para a implantao de um processo de desenvolvimento gil.
A partir dos resultados apresentados pela utilizao do Modelo de Referncia em um processo
de melhoria, pode-se notar que as metodologias geis em geral, e o Modelo de Referncia gil em
96
CAPTULO 7. CONCLUSES E TRABALHOS FUTUROS 97
particular, puderam ser considerados como alternativas implantao de um processo de desen-
volvimento que proporcione qualidade e controle ao processo a ser melhorado.
7.2 Contribuies do trabalho
As principais contribuies deste trabalho so:
A denio de um Modelo de Referncia para o Desenvolvimento gil de Software. O
modelo, composto de dezesseis processos, visa orientar a implantao de processos de de-
senvolvimento geis.
Uma anlise comparativa das caractersticas existentes nas principais metodologias geis
existentes atualmente. A anlise permitiu identicar semelhanas e diferenas existentes nas
metodologias analisadas.
A possibilidade de utilizao do Modelo de Referncia para a Avaliao de Processos da
ISO/IEC 15504 como guia para a avaliao de processos de desenvolvimento geis e, conse-
quentemente, para a orientao de um processo de melhoria focado no paradigma gil.
Orientaes para o planejamento e gerncia de projetos de desenvolvimento geis, atravs
das dependncias existentes entre os processos e suas atividades e da Estrutura Analtica de
Projetos, apresentados na Seo 5.4.7 do Captulo 5.
7.3 Trabalhos futuros
Os processos de desenvolvimento em geral, e as metodologias geis em particular, so campos
de pesquisas bastante frteis. As pesquisas realizadas nessas reas crescem continuamente e, cada
vez mais, aumentam as possibilidades de assuntos a serem abordados.
Dessa forma, os estudos realizados sobre processos de desenvolvimento e, especicamente,
sobre as metodologias geis, permitiram a determinao de possveis melhorias e desdobramentos
do trabalho aqui apresentado. Dentre as possibilidades de trabalhos futuros, destacam-se:
Desenvolvimento de ferramentas de suporte ao processo: O desenvolvimento de ferra-
mentas de suporte ao Modelo de Referncia gil um campo frtil para trabalhos futuros.
As possibilidades englobam ferramentas para o planejamento e gerenciamento das verses
e das iteraes, ferramentas para alocaes de recursos, entre outras.
Buscar o reconhecimento do Modelo de Referncia gil dentro da comunidade: Em-
bora o Modelo de Referncia gil seja um modelo exvel, podendo ser adaptado a diversas
situaes, ele ainda no reconhecido pela comunidade de interesse. A busca por um recon-
hecimento dentro da comunidade da engenharia de software, mais especicamente dentro da
CAPTULO 7. CONCLUSES E TRABALHOS FUTUROS 98
comunidade gil, pode agregar aspectos ainda no contemplados pelo modelo, tornando-o
um modelo mais maduro e convel.
Estudos especcos sobre gerncia de projetos geis: OModelo de Referncia gil utiliza-
se de prticas geis para auxiliar a gerncia de projetos. No entanto, um estudo especco
sobre gerncia de projetos com caractersticas geis um assunto com grandes possibili-
dades de trabalhos futuros, embora j existam alguns trabalhos nesse campo.
Aplicao de um controle de mudanas adequado s metodologias geis: No Modelo de
Referncia gil no descrita a necessidade de controle sobre as mudanas que ocorrem du-
rante o processo, por acreditar-se que esse tipo de controle pode causar lentido ao processo.
Um controle de mudanas adequado s metodologias geis poderia aumentar as chances
do Modelo de Referncia gil ser aplicado com sucesso para projetos onde as equipes so
numerosas e/ou esto separadas geogracamente.
Referncias Bibliogrcas
ABRAHAMSSON, P.; SALO, O.; RONKAINEN, J.; WARSTA, J. Agile software development
methods. Review and analysis. Espoo 2002, v. VTT Publications 478, p. 107, 2002.
AGILE ALLIANCE WEB SITE Agile Alliance. [On-line].
Disponvel em: http://www.agilealliance.org (Acessado em 10/02/2007)
AGILE MODELING WEB SITE Agile Documentation. [On-line].
Disponvel em: http://www.agilemodeling.com/essays/
agileDocumentation.htm (Acessado em 04/07/2006)
AMBLER, S. W. Modelagem gil (AM) : Um apanhado geral. Ronin International, v. , 2002.
BAR, M.; FOGEL, K. Open Source Development with CVS. 3 ed. Paraglyph Press, 2003.
BECK, K.; BEEDLE, M.; BENNEKUM, A.; COCKBURN, A.; CUNNINGHAM, W.; FOWLER, M.;
GRENNING, J.; HIGHSMITH, J.; HUNT, A.; JEFFRIES, R.; KERN, J.; MARICK, B.; MARTIN,
R. C.; MELLOR, S.; SCHWABER, K.; SUTHERLAND, J.; THOMAS, D. Manifesto for agile
software development. [On-line].
Disponvel em: http://www.agilemanifesto.org (Acessado em 17/10/2005)
BECK, K.; BEEDLE, M.; BENNEKUM, A.; COCKBURN, A.; CUNNINGHAM, W.; FOWLER, M.;
GRENNING, J.; HIGHSMITH, J.; HUNT, A.; JEFFRIES, R.; KERN, J.; MARICK, B.; MARTIN,
R. C.; MELLOR, S.; SCHWABER, K.; SUTHERLAND, J.; THOMAS, D. Principles behind the
agile manifesto. [On-line].
Disponvel em: http://www.agilemanifesto.org/principles.html (Acessado
em 17/10/2005)
BOEHM, B. Get Ready for Agile Methods, with Care. IEEE Computer, v. , p. 6469, 2002.
BOEHM, B.; TURNER, R. Management Challenges to Implementing Agile Processes in Tradi-
tional Development Organizations. IEEE Software, , n. 0740-7459, p. 3039, 2005.
99
REFERNCIAS BIBLIOGRFICAS 100
CASTRO MAGALHES, A. L. C.; ROUILLER, A. C.; VASCONCELOS, A. M. L. O gerencia-
mento de projetos de software desenvolvidos luz das metodologias geis: Uma viso compa-
rativa. PROQUALITY - Qualidade na Produo de Software, v. 1, n. 1, p. 2946, 2005.
CATRINE JACOBSEN XPM - from idea to realization - critical approach to the concept of XPM.
[On-line].
Disponvel em: http://www.glyn.dk/download/synopsisXPM.pdf (Acessado em
25/03/2007)
CHARLES LUDWIG Extreme Project Management. [On-line].
Disponvel em: http://www.stickyminds.com/sitewide.asp?Function=
edetail&ObjectType=ART&ObjectId=6661 (Acessado em 10/03/2007)
COCKBURN, A. Agile Software Development. 2 ed. Addison Wesley, 2002.
COCKBURN, A.; HIGHSMITH, J. Agile Software Development: The People Factor. IEEE
Computer, v. , p. 131133, 2001.
COLLINS-SUSSMAN, B.; FITZPATRICK, B. W.; PILATO, C. M. Version Control with Subver-
sion: For Subversion 1.4: (Compiled from r2777). Paraglyph Press, 2004.
CORRA, G. M.; COSTA FIGUEIREDO, R. M.; OLIVEIRA, K. M.; ARAUJO, J. M. P. Diretrizes
para a melhoria da gerncia e desenvolvimento de requisitos em uma empresa de software. In:
VI Simpsio Internacional de Melhoria de Processos de Software, So Paulo, SP, Brasil, 2004,
p. 95106.
CROCKER, R. Large-Scale Agile Software Development. 1 ed. Addison-Wesley, 2003.
DARCI, P. S. Gerenciamento de projetos nas organizaes. Editora de desenvolvimento geren-
cial, 2003.
DIRK RIEHLE A comparison of the value systems of adaptive software development and extreme
programming: How methodologies may learn from each other. [On-line].
Disponvel em: http://www.riehle.org (Acessado em 10/05/2006)
DYNAMIC SYSTEM DEVELOPMENT METHOD WEB SITE Dsdm introduction. [On-line].
Disponvel em: http://www.dsdm.org (Acessado em 16/01/2006)
DYNAMIC SYSTEM DEVELOPMENT METHOD WEB SITE Quick overview. [On-line].
Disponvel em: http://www.dsdm.org (Acessado em 16/01/2006)
ELRAD, T.; KICZALES, G.; AKSIT, M.; LIEBERHER, K.; OSSHER, H. HowSoftware Engineers
Use Documentation: The State of the Practice. IEEE Computer, p. 3539, 2003.
FEATURE-DRIVEN DEVELOPMENT WEB SITE Fdd process. [On-line].
Disponvel em: http://www.featuredrivendevelopment.com (Acessado em
20/02/2006)
FIGUEIREDO, A. L. G.; SANCHES, R. ECO

U Um ecossistema para desenvolvimento gil de
sistemas web. Dissertao de Mestrado, Instituto de Cincias Matemticas e de Computao
Universidade de So Paulo, So Carlos, SP, 2005.
FORWARD, A. Software Documentation

U Building and Maintaining Artefacts of Communica-
tion. Dissertao de Mestrado, Ottawa-Carleton Institute for Computer Science University of
Ottawa, Ottawa, Ontario, Canad, 2002.
FOWLER, M. The new methodology. [On-line].
Disponvel em: http://martinfowler.com/articles/newMethodology.html
(Acessado em 23/12/2005)
GOLDMAN, A.; KON, F.; SILVA, P. J. S.; YODER, J. W. Being Extreme in the Classroom:
Experiences Teaching XP. Journal of the Brazilian Computer Society, p. 117, 2004.
HIGHSMITH, J. Adaptive Management: Patterns For The E-Business Era. Cutter IT Journal,
v. XII, n. 9, 1999.
HIGHSMITH, J. Lifecycle Dinosaurs. Using Adaptive Software Development to meet the chal-
lenges of a high-speed, high-change environment. Software Testing & Quality Engineering,
p. 2228, 2000.
HIGHSMITH, J. Agile Software Development Ecosystems. 1 ed. Addison-Wesley, 2002.
HIGHSMITH, J.; COCKBURN, A. Agile Software Development: The Business of Innovation.
IEEE Computer, v. , p. 120122, 2001.
ISO/IEC 12207/PDAM 1 - Software Engineering - Life Cycle Processes. Relatrio Tcnico, In-
ternational Organization for Standardization / International Electrotechnical Commission, 1999.
ISO/IEC Information Technology

U Process Assessment

U Part 1: Concepts and Vocabulary.
Relatrio Tcnico, International Organization for Standardization / International Electrotechni-
cal Commission, 2003a.
ISO/IEC Information technology


U Part 3: Guidance on performing an
assessment. Relatrio Tcnico, International Organization for Standardization / International
Electrotechnical Commission, 2003b.


U Part 4: Guidance on use for Process
Improvement and Process Capability Determination. Relatrio Tcnico, International Organi-
zation for Standardization / International Electrotechnical Commission, 2003c.


U Part 5: An exemplar Process Assess-
ment Model. Relatrio Tcnico, International Organization for Standardization / International
Electrotechnical Commission, 2003d.
ISO/IEC Software Engineering - Process Assessment - Part 2: Performing An Assessment. Re-
latrio Tcnico, International Organization for Standardization / International Electrotechnical
Commission, 2003e.
JIM HIGHSMITH Messy, Exciting, and anxiety-ridden: Adaptive Software Development. [On-
line].
Disponvel em: http://www.jimhighsmith.com/articles/messy.htm (Aces-
sado em 21/05/2006)
KEITH EVERETTE Agile Software Development Processes - A difference approach to software
design. [On-line].
Disponvel em: http://www.asd.com (Acessado em 21/05/2006)
KERZNER, H. Gesto de projetos: as melhores prticas. 2 ed. Bookman, 2006.
KHRAMTCHENKO, S. Comparing eXtreme Programming and Feature Driven Development in
academic and regulated environments. In: , Harvard University, EUA, 2004.
KOSKELA, J. Software conguration management in agile methods. VTT Publications, v. , n.
514, p. 54, 2003.
KUHN, G. R.; PAMPLONA, V. F. Apresentando xp: Encante seus clientes com extreme program-
ming. [On-line].
Disponvel em: http://www.javafree.org/content/view.jf?idContent=5
MARTIN FOWLER Continuous Integration. [On-line].
Disponvel em: http://www.martinfowler.com (Acessado em 10/01/2007)
MICROSOFT Checklist: Managed Code Performance. [On-line].
Disponvel em: http://msdn2.microsoft.com/en-us/library/ms979052.
aspx (Acessado em 02/06/2007)
MNKANDLA, E.; DWOLATZKY, B. Dening Agile Software Quality Assurance. In: Internatio-
nal Conference on Software Engineering Advances (ICSEA06), IEEE Computer, 2006.
PAULK, M. Extreme Programming from a CMM Perspective. IEEE Software, v. , p. 1926,
2001.
PFLEEGER, S. Engenharia de Software. Teoria e Prtica. 2 ed. Prentice Hall, 2004.
PRESSMAN, R. S. Software Engineering: A Practitionerts Approach . 6 ed. McGraw-Hill
Science Engineering, 2006.
PROJECT MANAGEMENT INSTITUTE PMBOK. In: Um guia do conjunto de conhecimentos
em gerenciamento de projetos (Guia PMBOK), http://www.pmi.org. Last access: 01/03/2007:
Project Management Institute, p. 405, 2004.
RISING, L. Agile Meetings: Putting frequent, short meetings to work for your team. STQE
Magazine- The Software Testing and Quality Engineering , v. 4, 2002.
ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C. Qualidade de Software. Teoria e
Prtica. 1 ed. Prentice Hall, 2001.
RODRIGUES, A. G.; SANCHES, R.; FERRARI, F. C.; OLIVEIRA, J. L. Um Modelo de Maturi-
dade para a Avaliao de Processos geis, a ser submetido, 2005.
SANTOS SOARES, M. Comparao entre Metodologias geis e Tradicionais para o Desenvolvi-
mento de Software. Dissertao de Mestrado, Faculdade de Tecnologia e Cincias de Consel-
heiro Lafaiete Universidade Presidente Antnio Carlos, Conselheiro Lafaiete, MG, 2004.
SCHWABER, K. Scrum musing. a collection of thoughts on scrum and agile processes from ken
schwaber during 2003 and 2004. [On-line].
Disponvel em: http://www.controlchaos.com/download/ScrumMusings.
pdf (Acessado em 20/02/2006)
SCHWABER, K.; BEEDLE, M. Agile software development with scrum. [On-line].
Disponvel em: http://www.controlchaos.com/download/BookExcerpt.pdf
SCRUM WEB SITE The philosophy of scrum. [On-line].
Disponvel em: http://www.controlchaos.com (Acessado em 31/10/2005)
SILVA, A. F.; KON, F.; TORTELI, C. XP South of the Equator: An Experience Implementing
XP in Brazil. In: Proceedings of th 6th International Conference on eXtreme programming and
Agile Processes in Software Engineering (XP2005), Shefeld, England, 2005, p. 1018.
SLIGER, M. Relating PMBOK Practices to Agile Practices. StickyMinds.com, 2006.
SOMMERVILLE, I. Software Engineering. 8 ed. Addison Wesley, 2003.
THE STANDISH GROUP The CHAOS Report. [On-line].
Disponvel em: http://standishgroup.com (Acessado em 04/01/2007)
TIJMAN, A. Tester Introduction to agile software development. Eurostar 2003, v. , 2003.
WILLIAMS, L. Agile Software Development: The People Factor. IEEE Software, v. , p. 1620,
2003.
WILLIAMS, L.; COCKBURN, A. Agile Software Development: Its about Feedback and Change.
IEEE Computer, v. , n. 0018-9162/03, p. 3942, 2003.
WILLIAMS, L.; KESSLER, R. R.; CUNNINGHAM, W.; JEFFRIES, R. Strengthening the Case for
Pair Programming. IEEE Software, , n. 0740-7459, p. 1925, 2000.
APNDICE
A
Caractersticas chave dos produtos de
trabalho
Produto de trabalho Caractersticas
Ambiente de desenvolvi-
mento
- Atende os requisitos necessrios para a realizao de um
processo
- Alguns requisitos que devem ser considerados so:
- aspectos de segurana
- backup e recuperao
- equipamentos e espao fsico
- requisitos de apoio ao usurio
- facilidade de acesso remoto
Atividades de renamento
(melhoria)
- Indicam o caminho para melhorar um produto ou processo
Atividades para o gerencia-
mento de riscos
- Indicam o caminho para gerenciar os riscos.
- As atividades devem incluir tarefas para gerenciar, elimi-
nar ou reduzir o impacto dos riscos identicados
105
APNDICE A. CARACTERSTICAS CHAVE DOS PRODUTOS DE TRABALHO 106
Casos de teste de integrao - Denem os procedimentos que devem ser seguidos para a
realizao dos testes de integrao
- Denem entradas e sadas para os casos de teste
- Identicam circunstncias necessrias para a realizao
dos casos de teste
- Identicam procedimentos especiais
- Descobrem erros no software ou demonstra que as estrias
esto, aparentemente, trabalhando de acordo com as espe-
cicaes
Casos de teste unitrio - Denem os procedimentos que devem ser seguidos para a
realizao dos testes unitrios
- Denem entradas e sadas para os casos de teste
- Descobremerros na unidade de software ou demonstra que
est, aparentemente, trabalhando de acordo com as especi-
caes
Descrio do processo - Descreve o processo de forma detalhada
- A descrio detalhada do processo deve incluir:
- propsitos do processo
- resultados esperados
- tarefas e atividades que devem ser realizadas
- produtos de trabalho de entrada e de sada
Estria implementada

U A estria foi codicada em conformidade com os padres
estipulados
- Utiliza estruturas de dados ecientes
U Utiliza algoritmos ecientes e de fcil entendimento
U Possui interfaces funcionais ecientes

- Atende aos requisitos especicados
Falhas e problemas encontra-
dos
- Descreve as falhas e problemas encontrados nos processos
ou produtos de trabalho
Fatores de qualidade - Descreve quais fatores de qualidade podem ser considera-
dos em um processo de garantia de qualidade
- Exemplos de fatores de qualidade so: correti-
tude, manutenibilidade, extendibilidade, etc.
Ferramentas de desenvolvi-
mento
- As ferramentas de desenvolvimento auxiliam o desenvol-
vedor a produzir o cdigo-fonte
- As ferramentas de desenvolvimento devem incluir recur-
sos como:
- depurao do cdigo
- formatao do cdigo
- facilidade de visualizao de palavras-chave da
linguagem de programao utilizada
Ferramenta para o controle de
verses
- A ferramenta para o controle de verses deve atender aos
seguintes aspectos:
- permitir que as verses do software sejam recu-
peradas rapidamente
- bloquear o acesso concorrente a umitemde con-
gurao
- utilizar um esquema de identicao dos itens de
congurao que permita conhecer a verso de um determi-
nado item de congurao
Guia de instalao - Dene tarefas para colocar uma verso do software em
produo
- As tarefas so dendas sequencialmente e devem incluir:
- arquivos que devem ser carregados para a insta-
lao
- instrues para a instalao
- procedimentos de instalao
- procedimentos de congurao
- procedimentos de vericao
- instrues de backup e recuperao
- parmetros de congurao
Indivduos capacitados e trei-
nados
- Possuem as habilidades e competncias necessris ao pro-
jeto
- Possuem conhecimento suciente para aplicarem os
conhecimentos referentes ao paradigma gil
Lista de documentos a serem
mantidos
- Identica quais documentos devem ser produzidos
- Dene quando os documentos devem ser produzidos
- Dene o momento em que os documentos devem ser atua-
lizados
Lista de estrias e de requisi-
tos no-funcionais
- Descreve caractersticas funcionais e no-funcionais dese-
jadas para o software e para o sistema - As caractersticas
funcionais e no-funcionais referem-se a:
- Performance do sistema
- Interfaces
- Segurana
- Restries ou consideraes importantes
- Dene propsitos e objetivos das estrias
Lista de itens de informao - Conjunto de itens de informao que so produzidos pelos
processos
- Uma lista de itens de informao pode incluir cdigo, do-
cumentos, modelos, etc.
Lista de riscos identicados - Identica os riscos envolvidos com o projeto
- Descreve as possveis causas do risco
- Descreve os impactos que o risco pode causar ao projeto
Modelo de negcios do sis-
tema
- Descreve os relacionamentos e dependncias existentes
entre os componentes do sistema - Pode ser representado
atravs de modelos de dados, diagramas, etc.
Nova verso do produto e/ou
do processo
- Constitui-se de uma verso melhorada do produto e/ou do
processo
Padres de codicao - Dene padres para serem aplicados aos cdigos-fonte
- Dene a maneira como os identicadores sero denomi-
nados e organizados
- Dene a estrutura global do cdigo-fonte
- Dene a maneira como o cdigo-fonte ser visualmente
organizado
- Dene a maneira como os comentrios sero inseridos no
cdigo-fonte
- Pode ser concebido em forma de um checklist
Padres de documentao - Dene padres para a produo de documentos
- Os padres devem conter informaes de:
- formato, contedo, descrio, numerao de p-
ginas, linguagem, localizao de guras e tabelas, etc.
- organizao e localizao dos documentos
Plano de gerenciamento de
manuteno
- Dene atividades para modicar verses do software
- Dene atividades para gerenciar as modicaes
- Dene atividades para incluir novas estrias verso do
software
Plano de implantao de ge-
rncia de congurao
- Dene a ferramenta que ser utilizada para controlar as
verses
- Dene o gerente de congurao
- Dene as atividades e um cronograma para implantar a
gerncia de congurao
- Dene o esquema de identicao dos itens de congura-
o
- Dene a maneira como o status dos itens de congurao
sero divulgados
Plano de qualidade - Dene os objetivos de qualidade
- Dene tarefas para garantir a qualidade
- Dene o modelo de qualidade
Plano de treinamento - Dene os usurios a serem treinados
- Dene as habilidades requeridas para o treinamento
- Dene atividades de treinamento para atingir os objetivos
pretendidos
Plano global do projeto - Dene o objetivo e escopo do software
- Dene um cronograma geral para o projeto
- Dene uma estratgia para a integrao contnua
- Dene mecanismos para monitorar o feedback do cliente
- Dene as equipes que integraro o projeto
- Dene o tempo de durao das iteraes
Plano para a iterao - Identica as estrias a serem implementadas na prxima
iterao
- Estima as estrias a serem implementadas
- Dene os objetivos da iterao
- Dene os casos de teste de integrao
- Dene as equipes e as responsabilidades durante a iterao
Produto de trabalho - Um produto de trabalho algum artefato produzido por
algum processo.
Projeto arquitetural do sis-
tema
- Fornece uma viso da arquitetura do sistema
- Descreve os relacionamentos entre os componentes do sis-
tema
- Especica um projeto para cada componente do sistema
Projeto arquitetural do soft-
ware
- Descreve a estrutura do software
- Identica os componentes de software
- Identica os relacionamentos entre os componentes do
software
- Dene formatos de entrada e sada de dados
- Dene formatos de estrutura de dados
Projeto de banco de dados - Dene o sistema gerenciador de banco de dados
- Dene o formato dos registros, tabelas e objetos
- Dene o modo de acesso
- Dene vises lgicas e fsicas para o modelo de dados
- Identica restries
Registro de aceitao - Armazena a aceitao do cliente
- Identica a data da aceitao
- Identica os elementos entregues
- Identica o responsvel pela aceitao
Relatrio de incidentes - Descreve o evento ocorrido
- Dene a gravidade do evento (grave, mdio, pouco grave)
- Identica os produtos ou verses de software afetados
Relatrio de modicaes - Descreve as modicaes realizadas
- Inclui referncia para a solicitao de modicao de ori-
gem
- Inclui informaes sobre o status da modicao
Repositrio de itens de con-
gurao
- Conjunto de itens de informao que esto sob controle de
congurao
Requisio de evoluo - Identica o propsito da evoluo
- Identica o status da requisio (nova, aprovada, repro-
vada)
- Identica qual requisito a requisio se refere
- Identica o impacto na evluo no sistema
- Identica a criticalidade da evoluo
Requisitos do documento - Identica os pontos chave para o documento atingir seus
objetivos
Resultados dos testes de inte-
grao
- Identica a data de realizao do teste
- Identica o responsvel pela realizao do teste
- Identica os resultados da realizao do teste
Resultados dos testes unit-
rios
- Identica a data de realizao do teste
- Identica o responsvel pela realizao do teste
- Identica os resultados da realizao do teste
Verso completa do sistema - Possui todas as estrias e requisitos no-funcionais previs-
tos para o sistema
- Possui produtos de software j integrados e possveis da-
dos associados
- Possui toda a documentao prevista para o sistema
- Considera todos os hardwares necessrios para a execuo
adequada do sistema
Verso do software - Possui todas as estrias e requisitos no-funcionais previs-
tos para a verso do software
dos associados
- Possui documentao prevista para a verso
Verso integrada do software - Possui um conjunto de estrias implementadas, procedi-
mentos e possveis documentos e dados associados
Verso modicada do soft-
ware
- Possui todas as estrias e requisitos no-funcionais previs-
tos para a verso do software
- Possui as modicaes implementadas e integradas com a
verso do software
dos associados
- Possui documentao prevista para a verso
APNDICE
B
Framework de medidas
A capacidade de processo avaliada numa escala ordinal de trs pontos, permitindo que o
processo seja avaliado como Incompleto, Executado ou Gerenciado. A escala representa incre-
mento de capacidade na implementao do processo, de no realizao at a execuo efetiva e
gerenciada dos propsitos do processo.
OFramework de Medidas prov umesquema para ser utilizado na caracterizao da capacidade
na implementao de um processo com respeito ao Modelo de Avaliao de Processo. Cada nvel
de capacidade corresponde a um conjunto de atributos de processo que trabalham juntos para
prover uma melhora na capacidade para executar um processo. Em outras palavras, os atributos
de processo constituem uma maneira racional de progredir por meio da melhoria de capacidade de
qualquer processo.
Dentro do Framework de Medidas, a medida da capacidade baseada em um conjunto de
Atributos de Processo (AP). Cada atributo dene um aspecto particular da capacidade de processo.
A extenso da realizao do atributo de processo caracterizada em uma escala de classicao
denida e determina o nvel de capacidade do processo. A seguir so apresentados os nveis de
capacidade e os AP correspondentes.
B.1 Nveis de Capacidade de Processo
B.1.1 Nvel 0: Processo Incompleto
O processo no implementado, ou falha, em alcanar seus resultados de processo. Neste nvel
existe pouca ou nenhuma evidncia da realizao sistemtica de qualquer atributo denido.
112
APNDICE B. FRAMEWORK DE MEDIDAS 113
B.1.2 Nvel 1: Processo Executado
O processo implementado alcana os resultados do processo. Atributo que demonstra a obten-
o deste nvel:
AP 1.1 Atributo de Execuo de Processo: uma medida da extenso na qual o propsito do
processo obtido. Como resultado do atendimento total deste atributo:
a) O processo realiza as sadas denidas
B.1.3 Nvel 2: Processo Gerenciado
O processo implementado de uma maneira gerenciada e seus produtos de trabalho so apro-
priadamente estabelecidos, controlados e mantidos. Atributo que demonstra a obteno deste nvel:
AP 2.1 Atributo de Gerncia de Execuo: uma medida da extenso na qual a realizao do
processo gerenciada. Como resultado do atendimento total deste atributo:
a) os objetivos de realizao do processo so identicados;
b) a realizao do processo planejada e monitorada;
c) a realizao do processo ajustada para seguir os planos;
d) as responsabilidades e autoridades para realizao do processo so denidas, nomeadas e co-
municadas;
e) recursos e informaes necessrias para realizar o processo so identicados, disponibilizados,
alocados e utilizados;
f) interfaces entre as partes envolvidas so gerenciadas para garantir uma comunicao efetiva e
ainda desobstruir a nomeao de responsabilidades.
AP 2.2 Atributo de Gerncia dos Produtos de Trabalho: uma medida da extenso na qual
os produtos de trabalho produzidos por um processo so apropriadamente gerenciados. Como
resultado do atendimento total deste atributo:
a) os requisitos dos produtos de trabalho so denidos;
b) os requisitos para documentao e controle dos produtos de trabalho so denidos;
c) os produtos de trabalho so apropriadamente identicados, documentados e controlados;
d) os produtos de trabalho so revistos de acordo com os planos estabelecidos e ajustados quando
necessrios para satisfazer os requisitos.
B.2 Avaliao dos Atributos de Processo
B.2.1 Indcios de Atributos de Processo (IAP)
Os atributos de processo possuem associados a eles um conjunto de Indcios de Atributos de
Processo (IAP), que indicam a extenso da execuo do atributo na instanciao do processo.
Esses indcios relacionam-se atividades, recursos e resultados associados com a execuo dos
propsitos dos atributos.
Os Indcios de Atributos de Processo so:
Indcios de Prticas Genricas (PG): os indcios de PG so atividades genricas que guiam a
implementao de caractersticas dos atributos;
Indcios de Recursos Genricos (RG): os indcios de RG so associados aos recursos que
podem ser utilizados pelo processo para alcanar o atributo;
Indcios de Produtos de Trabalho Genricos (PTG): os indcios de PTG so conjuntos de
caractersticas que espera-se que sejam evidentes nos produtos de trabalho resultantes da
realizao de um processo. Eles formam a base para a classicao dos produtos de trabalho
denidos nos Indcios de Execuo de Processo.
Os trs tipos de IAP auxiliam a estabelecer as evidncias da extenso da execuo de um
atributo de processo. Como um indcio adicional para apoiar a avaliao do Nvel 1, cada processo
possui associado um conjunto de Indcios de Execuo de Processo, que so utilizados para medir
o grau de execuo do Atributo de Execuo de Processo.
Os Indcios de Execuo de Processo (IEP) so:
Prticas Bsicas (PB): A execuo das PB prov um indcio da extenso da execuo dos
propsitos do processo e sua aproximao com os resultados esperados do processo;
Produtos de Trabalho (PT): Os Produtos de Trabalho (PT) so utilizados e/ou produzidos
quando o processo executado. Cada produto de trabalho tem denido um conjunto de
caractersticas que deve ser utilizado para avaliar a implementao efetiva de um processo.
Uma lista com as caractersticas chave de cada produto de trabalho apresentada no Apn-
dice A.
Os indcios IAP e IEP fornecem as evidncias que um avaliador pode obter, ou observar, na
execuo de uma avaliao. Um indcio denido como uma caracterstica objetiva, de uma pr-
tica ou produto de trabalho, que apia o julgamento da capacidade de um processo implementado.
Em outras palavras, os indcios so utilizados para conrmar que certas prticas so executadas,
alm de auxiliarem na coleta de evidncias de objetivos da avaliao.
As evidncias a serem coletadas e validadas, juntamente com as caractersticas denidas no
modelo de referncia, devem servir como guia para a pontuao dos atributos de processo.
B.2.2 Escala de classicao dos atributos de processo
A extenso da realizao dos atributos de processo medida utilizando uma escala ordinal de
medidas. A escala ordinal denida a seguir deve ser utilizada para expressar os nveis de realizao
dos atributos de processo.
N (No Realizada): Acontece quando h pouca ou nenhuma evidncia da realizao do
atributo denido na avaliao de processo.
P (Parcialmente Realizada): H algumas evidncias de uma abordagem e de alguma reali-
zao dos atributos denidos no processo de avaliao. Alguns aspectos da realizao do
atributo podem ser imprevisveis.
L (Amplamente Realizada): H evidncias de uma abordagem sistemtica e signicante
realizao do atributo denido na avaliao do processo. Alguns pontos fracos relacionados
a esses atributos podem existir no processo de avaliao.
F (Completamente Realizada): H evidncias da completa e sistemtica abordagem e com-
pleta realizao dos atributos denidos na avaliao de processo.
A escala ordinal denida deve ser compreendida em termos de uma escala de porcentagem,
representando a extenso da sua realizao. Os valores correspondentes a escala ordinal so apre-
sentados a seguir:
N: 0 at 15% de realizao
P: 15% at 50% de realizao
L: 50% at 85% de realizao
F: 85% at 100% de realizao.
B.3 Classicao dos atributos de processo
Cada atributo de processo deve ser classicado utilizando a escala de classicao ordinal
denida. Um processo deve ser avaliado at o maior nvel de capacidade denido no escopo da
avaliao.
B.4 Modelo de nvel de capacidade de processo
O nvel de capacidade alcanado por um processo deve ser derivado da classicao dos atri-
butos de processo realizada para esse processo, de acordo com o modelo de nvel de capacidade de
processo apresentado na Tabela B.1:
Escala Atributos de processo Classicao
Nvel 0 AP 1.1 Execuo do processo N
Nvel 1 AP 1.1 Execuo do processo L ou F
Nvel 2 AP 1.1 Execuo do processo
AP 2.1 Gerncia da execuo
AP 2.2 Gerncia dos produtos de trabalho
F
L ou F
L ou F
Tabela B.1: Modelo de nvel de capacidade de processo.

Dissertacao BB Digital

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Dissertacao BB Digital

Transféré par

Droits d'auteur :

Formats disponibles

Um modelo de referncia para o desenvolvimento gil

U Utiliza algoritmos ecientes e de fcil entendimento

U Possui interfaces funcionais ecientes

Vous aimerez peut-être aussi