Risk Rum

UNIVERSIDADE FEDERAL DOS VALES DO JEQUITINHONHA E MUCURI
FACULDADE DE CINCIAS EXATAS E TECNOLGICAS

BACHARELADO EM SISTEMAS DE INFORMAO
RISKRUM: uma ferramenta para gerenciamento de riscos na metodologia gil de

desenvolvimento de software SCRUM
Srgio Oliveira Godinho
Diamantina
2011
UNIVERSIDADE FEDERAL DOS VALES DO JEQUITINHONHA E MUCURI

FACULDADE DE CINCIAS EXATAS E TECNOLGICAS
BACHARELADO EM SISTEMAS DE INFORMAO

Orientador(a):
Prof. Msc. Caroline Queiroz Santos
Monografia apresentada como requisito parcial

para obteno do diploma de Bacharel em Sistemas de Informao pela Universidade Federal dos
Vales do Jequitinhonha e Mucuri - UFVJM.
Diamantina
2011

Orientador(a):
Prof. Msc. Caroline Queiroz Santos
Monografia apresentada como requisito parcial

para obteno do diploma de Bacharel em Sistemas de Informao pela Universidade Federal dos
Vales do Jequitinhonha e Mucuri - UFVJM.
APROVADO em ..... / ..... /............
_________________________________________
Prof. Msc. thila Rocha Trindade - UFVJM
_________________________________________
Prof. Msc. Maria Lcia Bento Villela - UFVJM
_________________________________________
Prof. Msc. Caroline Queiroz Santos - UFVJM
Agradecimentos
Agradeo a Deus,
Aos meus pais(Denzia da Piedade Godinho Oliveira e Eloso Mrcio de Oliveira),
Aos meus irmos(Mrcia Oliveira Godinho e Marcelo Oliveira Godinho),
minha famlia,
UFVJM e Departamento de Computao,
Aos professores e funcionrios do curso,
minha orientadora(Caroline Queiroz Santos),
Ao irmo Joo Pedro Campos que ganhei durante o curso,
Aos meus amigos de turma(Cassiano Raimar, Jnia Gonalves, Gustavo Marques, Luanna
Azevedo, Marcelo Pedras, Marco Pires, Patrick Aurlio),
Aos meus amigos de repblica(Adriano Ribeiro, Cristiano Matheus, Felipe Rosa, Felipe
Santos, Leonardo Gonalves, Matheus Chamone),
Aos meus chefes e colegas de estgios,
e s pessoas que no foram citadas, mas que direta ou indiretamente, contriburam para a
construo de meu conhecimento.
iv
Resumo
Altos ndices de insucessos em projetos de software esto diretamente relacionados com a dificuldade que as metodologias tradicionais tm em se adaptar s constantes mudanas e incertezas
do ambiente de desenvolvimento de software. As metodologias geis, como a Scrum tm uma
maior capacidade de lidar com as incertezas e as mudanas que o mercado de desenvolvimento
de software tm exigido. A adoo de prticas de gerenciamento de riscos pode, alm de prevenir prejuzos, potencializar as oportunidades encontradas no decorrer de um projeto. Neste
sentido, este trabalho busca propor e desenvolver uma ferramenta que permita metodologia
gil Scrum se adequar ao gerenciamento de riscos, sem que perca sua agilidade. Foram analisados aspectos das metodologias de desenvolvimento de software, explorando as metodologias
tradicionais e geis, focando principalmente na metodologia gil Scrum. So apresentadas as
prticas de gerncia de projeto, sugeridas pelo Project Management Institute, e as caractersticas do Agile Project Management. A disciplina de gerncia de riscos foi estudada a partir de
trabalhos que permitiram mostrar como tem-se olhado para o gerenciamento de riscos. Para
o desenvolvimento da ferramenta proposta foi elaborado uma especificao e o desenho da
mesma, e ainda foi preparado um ambiente para desenvolvimento. A ferramenta foi desenvolvida conforme a especificao e desenho elaborado, tendo atendido as necessidades levantadas,
e atingido os objetivos almejados neste trabalho.
Palavras-chave: Gerenciamento de Riscos, Scrum, Metodologias geis, Gerenciamento
de Projetos.
Abstract
The high indices of failures in software projects, are relacionated with the difficulty of the traditional methodologies have to adapt to the changes e uncertainties of the software development
environment. The agile methodologies as soon as the Scrum one,have a greatest capacity to deal
with the uncertainties and changes of development software market is demanding. The adoption
of risks management pratices can,besides preventing prejudices,potentiates the opportunities
found during the project. In this purport, the labor,searches to propose and develop a tool that
allows the agile methodologie Scrum adapt to the risk management,without the methodologie
miss the agility.The development methodologies aspects were analyzed,exploring traditional
and agile methodologies,focusing on agile methodologie Scrum.The management project pratices are presented by the Project Management Institute and Alile Project Managemant features.
The risks management discipline was study from works that allows to show how risks management is important. To the tool development,was elaborate a specification, the tool draw,and an
development environment. The tool was developed as soon as the specification and elaborate
draw. The developed tool comply with the needs, and reached the desired goals in this work.
Keywords: Risk Management, Scrum, Agile, Project Management.
vi
Lista de Figuras
2.1
Diagrama de atividades do trabalho. . . . . . . . . . . . . . . . . . . . . . . .
3.1
Metodologia Cascata. Fonte: (PAULA, 2009) . . . . . . . . . . . . . . . . . .
12
3.2
Metodologia Cascata com realimentao. Fonte: (PAULA, 2009) . . . . . . . .
13
3.3
Prototipao. Fonte: (PAULA, 2009) . . . . . . . . . . . . . . . . . . . . . . .
14
3.4
Metodologia Espiral. Fonte: (PAULA, 2009) . . . . . . . . . . . . . . . . . . .
15
3.5
Metodologia Entrega Evolutiva. Fonte: (PAULA, 2009) . . . . . . . . . . . . .
16
3.6
Scrum - uma jogada do jogo Rugby . . . . . . . . . . . . . . . . . . . . . . .
20
3.7
Metodologia Scrum. Fonte: (SANTOS, 2009) . . . . . . . . . . . . . . . . . .
21
3.8
Burndown da Sprint (SANTOS, 2009) . . . . . . . . . . . . . . . . . . . . . .
28
3.9
Formato de Processos. Fonte: Araujo (2009) . . . . . . . . . . . . . . . . . . .
31
3.10 Grupo de Processos de Gerenciamento de Projetos. Fonte: Adaptado (PMI, 2008) 31

3.11 Os grupos de processos interagem em uma fase ou em um projeto. Fonte: (PMI,
2008) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.12 Fases do Agile Project Management. Fonte: Lopes (2008) Dias e Soler (2005) .
35
3.13 Relacionamento entre clientes e a equipe de desenvolvimento. Fonte: Adaptado

Lopes (2008) apud Martins (2007). . . . . . . . . . . . . . . . . . . . . . . . .
36
3.14 Seis princpios da Gesto de Projetos geis. Fonte: Adaptado Franco (2006)
apud HIGHSMITH (2004). . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.15 Software Risk Management. Fonte Boehm (1991) . . . . . . . . . . . . . . . .
38
3.16 Resumo dos processos de gerenciamento dos riscos do projeto. Fonte: PMI (2008) 41
4.1
Cobertura da Scrum em relao rea de Gerenciamento de Riscos do CMMI.

Adaptado: (MARAL et al., 2007) . . . . . . . . . . . . . . . . . . . . . . . .
vii
48
LISTA DE FIGURAS
4.2
viii
Cobertura geral das reas do CMMI pela metodologia Scrum. Adaptado: Maral et al. (2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
5.1
Escopo da ferramenta Riskrum. Fonte: Dados de pesquisa. . . . . . . . . . . .
52
5.2
Caso de uso da ferramenta Riskrum. Fonte: Dados de pesquisa. . . . . . . . . .
56
5.3
Modelo da base dados da ferramenta Riskrum. Fonte: Dados de pesquisa. . . .
57
5.4
Arquitetura da Ferramenta Riskrum. Fonte: Dados de pesquisa. . . . . . . . . .
58
5.5
Ambiente de Desenvolvimento. Fonte: Dados de pesquisa. . . . . . . . . . . .
59
5.6
Tela de autenticao da Riskrum. Fonte: Dados de pesquisa. . . . . . . . . . .
62
5.7
Tela inicial da Riskrum. Fonte: Dados de pesquisa. . . . . . . . . . . . . . . .
63
5.8
Tela de gesto de Projetos na Riskrum. Fonte: Dados de pesquisa. . . . . . . .
63
5.9
Tela de edio de Projetos na Riskrum. Fonte: Dados de pesquisa. . . . . . . .
64
5.10 Tela de identificao de riscos da Riskrum. Fonte: Dados de pesquisa. . . . . .
65
5.11 Tela de checklist de riscos da Riskrum. Fonte: Dados de pesquisa. . . . . . . .
65
5.12 Tela com lista de riscos sem planejamento de respostas na Riskrum. Fonte: Dados de pesquisa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
5.13 Tela de emisso de relatrios. Fonte: Dados de pesquisa. . . . . . . . . . . . .
66
5.14 Tela de gesto de riscos da Riskrum. Fonte: Dados de pesquisa. . . . . . . . . .
67
Lista de Tabelas
3.1
Mtodos geis x mtodos dirigidos por planos. (PAULA, 2009) . . . . . . . . .
11
3.2
Mapeamento de grupos de processos de gerenciamento de projetos e reas de

conhecimento. Fonte: Adaptado (PMI, 2008) . . . . . . . . . . . . . . . . . .
33
Aderncia do Scrum ao processo de Gerncia de Riscos do MPS.BR. Fonte:

(TEIXEIRA, 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.1
ix
Sumrio
Agradecimentos
iv
Resumo
Abstract
vi
Lista de Figuras
viii
Lista de Tabelas
ix
Introduo
1.1
Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3
Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1
Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.2
Objetivos Especficos . . . . . . . . . . . . . . . . . . . . . . . . . . .
Organizao do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4
2
Metodologia
Fundamentao Terica
3.1
Metodologias de Desenvolvimento de Software . . . . . . . . . . . . . . . . .

3.1.1
Metodologias Tradicionais . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1.1.1
Cascata . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1.1.2
Cascata com realimentao . . . . . . . . . . . . . . . . . .
12
SUMRIO
3.2
3.3
3.4
xi
3.1.1.3
Prototipao . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.1.1.4
Espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.1.1.5
Entrega Evolutiva . . . . . . . . . . . . . . . . . . . . . . .
16
Metodologias geis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2.1
Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.2.1.1
Papis . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.2.1.2
O Scrum Master . . . . . . . . . . . . . . . . . . . . . . . .
20
3.2.1.3
O Product Owner . . . . . . . . . . . . . . . . . . . . . . .
22
3.2.1.4
O Scrum Team . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.2.1.5
Cerimnias . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.2.1.6
Reunio de Planejamento da Release . . . . . . . . . . . . .
23
3.2.1.7
Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.2.1.8
Reunio de Planejamento da Sprint . . . . . . . . . . . . . .
24
3.2.1.9
Reunio Diria . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.2.1.10 Reviso da Sprint . . . . . . . . . . . . . . . . . . . . . . .
26
3.2.1.11 Retrospectiva da Sprint . . . . . . . . . . . . . . . . . . . .
26
3.2.1.12 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.2.1.13 Backlog do Produto . . . . . . . . . . . . . . . . . . . . . .
27
3.2.1.14 Burndown da Release . . . . . . . . . . . . . . . . . . . . .
27
3.2.1.15 Backlog da Sprint . . . . . . . . . . . . . . . . . . . . . . .
28
3.2.1.16 Burndown da Sprint . . . . . . . . . . . . . . . . . . . . . .
28
Gerenciamento de Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.3.1
Gerenciamento de projetos com o PMBOK . . . . . . . . . . . . . .
30
3.3.2
Gerenciamento de Projetos geis . . . . . . . . . . . . . . . . . . . .
34
Gerenciamento de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.4.1
Gerenciamento de Riscos pelo PMBOK . . . . . . . . . . . . . . . .
40
3.4.1.1
Planejar o gerenciamento dos riscos . . . . . . . . . . . . . .
42
3.4.1.2
Identificar os riscos . . . . . . . . . . . . . . . . . . . . . .
42
SUMRIO
xii
3.4.1.3
Anlise qualitativa dos riscos . . . . . . . . . . . . . . . . .
42
3.4.1.4
Anlise quantitativa dos risos . . . . . . . . . . . . . . . . .
43
3.4.1.5
Planejar as respostas aos riscos . . . . . . . . . . . . . . . .
44
3.4.1.6
Monitorar e controlar os riscos . . . . . . . . . . . . . . . .
45
Estado da Arte
46
Desenvolvimento da Ferramenta Proposta
51
5.1
Especificao da Ferramenta . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.1.1
Misso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.1.2
Escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.1.3
Requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
5.1.4
Requisitos no funcionais . . . . . . . . . . . . . . . . . . . . . . . .
55
5.1.5
Limites da Ferramenta . . . . . . . . . . . . . . . . . . . . . . . . . .
55
5.1.6
Diagrama de caso de uso . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.1.7
Modelo da base de dados . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.1.8
Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
5.2.1
Ambiente de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . .
59
5.2.2
Ferramentas Utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . .
60
5.2.2.1
MySQL Workbench . . . . . . . . . . . . . . . . . . . . . .
60
5.2.2.2
Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
5.2.2.3
PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
5.2.2.4
Eclipse for PHP Developers . . . . . . . . . . . . . . . . . .
60
5.2.2.5
Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
5.2.2.6
MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
5.2.2.7
PHPMyAdmin . . . . . . . . . . . . . . . . . . . . . . . . .
61
5.2.2.8
IReport . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
Validao e Implantao . . . . . . . . . . . . . . . . . . . . . . . . .
62
5.2
5.2.3
SUMRIO
xiii
5.2.3.1
A ferramenta Riskrum . . . . . . . . . . . . . . . . . . . . .
62
5.2.3.2
Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
Concluso
68
6.1
69
Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Captulo 1
Introduo
1.1
Introduo
Gerenciar projetos de software um desafio, principalmente no tocante ao cumprimento do

prazo, gesto de custos, gesto da qualidade, gesto do escopo e, tambm, dos riscos que envolvem um projeto. O desafio torna-se maior ainda devido ao fato de que nenhum projeto igual
a outro. Um projeto de desenvolvimento de um software, por mais simples que seja, diferente
de outro projeto que tem por objetivo construir um software parecido. As variveis que rodeiam
cada projeto, o faz diferente de todos os outros.
Muitas so as aes e estudos voltados para melhoria dos processos de gesto e desenvolvimento de software, sendo estes estudos cada vez mais necessrios, visto que o ambiente de
desenvolvimento de software tm se tornado mais exigente, complexo, incerto e competitivo.
Segundo Rocha e Belchior (2004):
o desenvolvimento de software uma atividade complexa, envolvendo inmeros
fatores que no raro so imprevisveis e de difcil controle, como inovaes tecnolgicas e mudanas constantes nos requisitos do cliente, dentre muitos outros.
H muito tempo que os processos de desenvolvimento de software vm evoluindo, com
o intuito de controlar essa atividade complexa. O processo de desenvolvimento de software
passou por um perodo de muitos problemas no final dos anos 60 e incio dos anos 70, conhecido
como a crise do software, quando os computadores evoluram muito, as mquinas se tornaram
poderosas demais, o poder computacional aumentou mais que a capacidade de organizao
que as pessoas ligadas ao desenvolvimento de software tinham (DIJKSTRA, 1972). Muito se
perdeu nesse perodo, mas as perdas trouxeram a necessidade de estudar melhores mtodos para
desenvolvimento.
Nesse contexto, surgiu a Engenharia de Software, que definida pela IEEE Computer Soci1
CAPTULO 1. INTRODUO
ety1 , no Guia de Conhecimento em Engenharia de Software como, a aplicao de uma abordagem sistemtica, disciplinada e quantificvel para o desenvolvimento, operao e manuteno
de software (ABRAN; MOORE, 2004).
A engenharia de software contribui com estudos, mtodos e processos para que o desenvolvimento de software seja realizado com qualidade. Metodologias de desenvolvimento de
software foram propostas e adotadas para que se tivessem mais controle sobre os softwares que
eram desenvolvidos, sobre o ambiente que os influenciavam, sobre as pessoas e as tecnologias
que os envolviam(BOEHM, 2006).
As metodologias consideradas tradicionais, tambm chamadas de pesadas, tm como caracterstica marcante serem divididas em etapas e/ou fases. Essas fases so bem definidas e englobam atividades como Anlise, Modelagem, Desenvolvimento e Testes(NETO, 2004). Cada
etapa orientada principalmente a documentao. Nessas metodologias, os softwares costumam ser bastante documentados e planejados antes que sejam codificados. Isso no ruim, se
levarmos em considerao um contexto passado, onde o custo de fazer alteraes e correes
era muito alto, uma vez que o acesso aos computadores eram limitados e no existiam modernas ferramentas de apoio ao desenvolvimento do software, como depuradores e analisadores de
cdigo(SOARES, 2004).
Apesar dessas metodologias terem ajudado a melhorar o cenrio de desenvolvimento de
software, os resultados das entregas de projetos de software ainda so preocupantes (INTERNATIONAL, 2009). A adoo de metodologias tradicionais no suficiente para que projetos
sejam realizados com sucesso. Neste contexto, devemos almejar novos mtodos, prticas, estudos e solues, para tudo que rodeia o desenvolvimento de software.
A gerncia de projetos uma disciplina que vem sendo cada vez mais estudada, praticada e
uma aliada poderosa s metodologias de desenvolvimento de software. A gesto de projetos
a aplicao de conhecimento, habilidades, ferramentas e tcnicas s atividades do projeto a fim
de atender aos seus requisitos (PMI, 2008).
Segundo pesquisas do Standish Group International, apenas 32% dos projetos de softwares
foram considerados como sucesso. Os outros 68% considerados como insucessos, se dividem
em 24% que foram considerados como falhos e 44% que foram contestados (INTERNATIONAL, 2009).
Isso vem motivando as organizaes, alm de adotarem a gerncia de projetos de software,
adotarem tambm as metodologias geis como uma alternativa de gerenciamento de projetos
complexos (RIBEIRO; GUSMO, 2008). As metodologias geis so novos processos de desenvolvimento de software, que por essncia so conduzidos de forma leve (sem se prender
1 Institute
of Electrical and Electronics Engineers Computer Society - Com cerca de 85.000 membros, a maior
organizao mundial de profissionais da computao. Fundada em 1946, dedicada ao avano da teoria e aplicao
da informtica e tecnologia da informao.
CAPTULO 1. INTRODUO
muita documentao e muitos processos), cclica(o software construdo a cada interao), alta
colaborao do cliente, investimento em cada indivduo e resposta s mudanas.
Adotar as prticas das metodologias geis e as prticas da disciplina de gesto de projetos podese mostrar bastante eficaz em vrios contextos. Os projetos de software so bastante peculiares e
merecem esforos em seu gerenciamento, visto que muitos ainda so encerrados com insucesso.
Gusmo e Moura (2004) identificam que todos os projetos de software enfrentam problemas de qualidade, de cronograma, e de custo e esto sendo afetados por riscos que so inesperados, no planejados ou ignorados simplesmente. Assim, considerando que os riscos tem suas
origens nas incertezas existentes em todos os projetos (PMI, 2008), e que eles podem ser causadores de problemas, faz-se necessrio adotar medidas que tambm acolham o gerenciamento de
riscos dentro do processo de desenvolvimento de software abarcados por metodologias geis.
O gerenciamento de riscos trabalha justamente com a incerteza, visando a identificao
de problemas potenciais antes que ocorram, e de oportunidades, com o objetivo de eliminar ou
reduzir a probabilidade de ocorrncia e o impacto de eventos negativos para os objetivos do
projeto, alm de potencializar os efeitos da ocorrncia de eventos positivos(ROCHA; BELCHIOR, 2004).
A crescente adoo de metodologias geis em contextos cada vez mais complexos e incertos traz consigo a necessidade de estudar o gerenciamento de riscos em projetos de software
desenvolvidos de acordo com tais metodologias. Uma das metodologias geis que se encaixa
em ambientes complexos e incertos a Scrum. Segundo Guimares et al. (2009) e Siqueira
(2007), a Scrum no atende completamente o gerenciamento de riscos quando comparada ao
modelo de qualidade CMMI. Silva, Hoentsch e Silva (2009) tambm concluram que a Scrum
no atende aos processos de gerenciamento de riscos referentes ao modelo MPS.BR 2 .
O estudo combinado da gesto de projetos de software, da gesto de riscos, e da metodologia gil Scrum, pode ser um relevante instrumento para vrias empresas. Dessa forma esse
trabalho se prope a desenvolver uma ferramenta que atenda a gesto de riscos e os princpios
das metodologias geis de desenvolvimento de software, principalmente a Scrum.
1.2
Motivao
Segundo a Associao Brasileira de Empresas de Software, existe uma tendncia de crescimento

do mercado de software nacional e mundial. O mercado mundial de Software e Servios atingiu,
2 MPSBR
- Melhoria do Processo de Software Brasileiro. um programa de estruturao do processo de desenvolvimento de software com o objetivo de definir um modelo de melhoria e avaliao de processo de software,
preferencialmente para as micro, pequenas e mdias empresas, de forma a atender as suas necessidades de negcio
e a ser reconhecido nacional e internacionalmente como um modelo aplicvel indstria de software(TEIXEIRA,
2007).
CAPTULO 1. INTRODUO
em 2009, o valor de U$ 880 bilhes, e o Brasil se manteve no 12 lugar do ranking mundial com
um mercado interno de U$ 15 bilhes. Desse valor, Us$ 5,452 bilhes correspondem a softwares
e o restante a servios. A atividade de desenvolvimento de software corresponde em mdia a
24% da parcela desse mercado. Pequenas empresas correspondem em mdia a 55% da parcela
do mercado nacional (ABES, 2010).
Reconhecer esses nmeros notar a fora do mercado de desenvolvimento de software
no Brasil e saber que, se ainda existe uma tendncia de crescimento do mercado, com certeza
existir uma maior concorrncia entre as empresas. Assim, fica evidente a necessidade de que
os produtos sejam desenvolvidos dentro do prazo, dentro custo proposto e que minuciosamente
atendam as necessidades dos clientes com a qualidade esperada. S assim, as empresas obtero
sucessos em seus projetos e conseguiro se destacar perante seus concorrentes.
Segundo o PMBOK(Guia de Conhecimento em Gerenciamento de Projetos), o objetivo
do gerenciamento de riscos aumentar a probabilidade e o impacto de eventos positivos e
diminuir a probabilidade e impacto de eventos negativos (PMI, 2008).
Portanto, a adoo de prticas de gerenciamento de riscos pode, alm de prevenir prejuzos,
potencializar as oportunidades encontradas no decorrer de um projeto. Com a obteno de melhores resultados em relao aos prazos, custos, qualidade e satisfao dos clientes, as empresas
tambm obtero vantagem competitiva no mercado de software. Isso justifica a importncia
de empresas que gerenciam projetos em ambientes incertos e mutveis adotarem prticas de
gerenciamento de riscos.
Neto (2008) em seu trabalho define que:
as metodologias de gerenciamento geis surgiram como uma resposta s chamadas metodologias tradicionais, como uma alternativa para tratar com o cenrio organizacional atual, o qual exige resultados imediatos, sob condies de constantes
mudanas e incertezas.
Assim, o uso de uma metodologia de gerncia de riscos de forma gil surge como uma boa
opo para as organizaes que tem projetos de pequeno e mdio porte e desejam aplicar um
processo gil para gerir o desenvolvimento de seus produtos de software.
Em uma pesquisa sobre a adoo de mtodos geis, realizada por Ambler (2008) foi possvel notar que existe uma crescente adoo por metodologias geis, visto que apenas 13% das
organizaes no tiveram nenhuma melhoria em relao a produtividade, 14% no notaram melhora na qualidade e que 78% notaram que tiveram um pouco ou muita melhora em relao
satisfao dos stakeholders dos projetos.
Entender que a Scrum uma metodologia gil bastante aceita, que no satisfaz a gesto
de riscos, uma vez que trata um pouco os impedimentos sem dar nfase ao gerenciamento de
CAPTULO 1. INTRODUO
riscos (SIQUEIRA, 2007) (GUIMARES et al., 2009) (SILVA; HOENTSCH; SILVA, 2009), e
reconhecer que as ferramentas de gesto de projetos podem ser aliadas aos gerentes e demais
stakeholders so as justificativas para o esforo empenhado neste trabalho.
1.3
1.3.1
Objetivo
Objetivo Geral
O principal objetivo desse trabalho desenvolver uma ferramenta que permita metodologia
gil Scrum se adequar ao gerenciamento de riscos, sem que a mesma perca sua agilidade. Para
tanto necessrio que outros objetivos sejam realizados com a mesma importncia. Sendo assim, com este trabalho tambm objetiva-se:
1.3.2
Objetivos Especficos
1. entender os processos/metodologias tradicionais de desenvolvimento de software;

2. entender como funciona e quais so os princpios das metodologias geis de desenvolvimento, focando na metodologia Scrum;
3. entender como funciona a gesto de projetos, pelo PMBOK e em ambientes geis;
4. entender o gerenciamento de riscos, principalmente em ambientes geis;
5. levantar as necessidades de uma ferramenta para a implementao do gerenciamento de
riscos dentro da Scrum.
6. implementar uma ferramenta que atenda as necessidades especificadas.
1.4
Organizao do Trabalho
Os demais captulos esto organizados da seguinte forma:

O Captulo 2 - Metodologia apresenta a metodologia utilizada para o desenvolvimento
desse trabalho. Nele pode-se encontrar as etapas que foram seguidas e as principais atividades
realizadas dentro de cada etapa para se chegar ao resultado do trabalho.
O Captulo 3 - Fundamentao Terica apresenta os principais temas que so tratados
no trabalho. Nesse captulo apresentado as metodologias de desenvolvimento de software
separando-as em metodologias tradicionais e metodologias geis. E como a metodologia Scrum
CAPTULO 1. INTRODUO
objeto de estudo desse trabalho, nesse captulo apresentado mais detalhadamente o seu funcionamento. A metodologia Scrum foi apresentada atravs de seus principais pontos: Cerimnias,
Artefatos e Papis.
O captulo tambm traz os conceitos de Gerenciamento de Projetos, mais uma vez de forma
tradicional e gil, abordando as principais caractersticas de cada escola de gerenciamento de
projetos.
Como o gerenciamento de riscos uma das reas de gerenciamento de projetos e tambm
objeto de estudo desse trabalho, o tema tambm explorado nesse captulo. O Gerenciamento
de Riscos foi abordado atravs de suas principais definies, seus estgios, os benefcios em se
utiliz-lo, e ainda atravs das prticas recomendadas pelo Project Management Institute - PMI
atravs do PMBOK.
O Captulo 4 - Estado da Arte apresenta principalmente como tem evoludo o estudo sobre
o gerenciamento de riscos, atravs de trabalhos pesquisados que deram base para esse trabalho
e que certamente pode ajudar ao leitor contextualizar-se sobre o que foi proposto e realizado.
O Captulo 5 - Desenvolvimento da Ferramenta Proposta
Esse captulo apresenta como a ferramenta Riskrum foi desenvolvida, desde a sua especificao, desenho, desenvolvimento, testes e as ferramentas utilizadas. No captulo o leitor
encontra o escopo da ferramenta que foi desenvolvida, seus requisitos funcionais e no funcionais, o desenho da ferramenta, composto pelo diagrama de caso de uso, o modelo entidade
relacionamento, a arquitetura da ferramenta, e o ambiente de desenvolvimento utilizado.
O Captulo 6 - Concluso apresenta os resultados obtidos com a realizao deste trabalho,
trabalho futuros e limitaes encontradas na sua realizao.
Captulo 2
Metodologia
A Figura 2.1 apresenta os passos que foram adotados para a realizao desse trabalho. Foi
necessrio primeiramente estudar os temas que seriam abordados. Portanto, o primeiro passo
foi realizar o estudo da literatura dos principais temas: metodologias tradicionais e geis de
desenvolvimento de software, gesto de projetos e gerenciamento de riscos.
O estudo foi iniciado por uma investigao e busca por entendimento sobre o funcionamento
das metodologias/processos tradicionais de desenvolvimento de software. Foi importante comear por elas devido terem sido as primeiras metodologias criadas para guiar os profissionais de
software, por serem to difundidas, quanto utilizadas.
Seguindo o fluxo que foi planejado, dentro do estudo da literatura, muita nfase foi dada
s metodologias geis e seus princpios. Das vrias metodologias geis existentes, a Scrum foi
escolhida como objeto de estudo principalmente por ser uma das mais aceitas, e por conter em
suas prticas muito esforo de gerenciamento de projeto, o que a torna eficiente.
Posteriormente ao estudo das metodologias de desenvolvimento de software, foi realizado
um estudo sobre o gerenciamento de projetos. Nesse estudo foi dado nfase principalmente
gerncia de projetos pregada pelo PMI (Project Management Institute), atravs do PMBOK,
que considerado a bblia do gerenciamento de projetos. Alm disso, foi estudado o gerenciamento de projetos geis, conhecido pela sigla APM (Agile Project Management) com o intuito
de no se distanciar das prticas geis.
O tema seguinte de estudo foi o gerenciamento de riscos, que umas das reas do gerenciamento de projetos e o principal objeto de estudo para a proposta da ferramenta.
O estudo da literatura serviu como alimento para o estudo da ferramenta que foi desenvolvida. Atravs do estudo foram levantadas, em forma de especificao, as necessidades que
deveriam ser implementadas na ferramenta para que ela pudesse atingir os objetivos traados
para esse trabalho. Dentro do estudo da ferramenta, foi realizada a especificao, a anlise e
CAPTULO 2. METODOLOGIA
desenho da ferramenta.
Aps a especificao, anlise e desenho da ferramenta partiu-se para estudar as tecnologias
que seriam utilizadas e, posteriormente, preparar o ambiente de desenvolvimento seguindo o
que foi especificado e desenhado na etapa anterior.
A prxima etapa foi implementar a ferramenta, realizar os testes e public-la. O trabalho
foi finalizado com a anlise dos resultados obtidos e com a proposta de trabalhos posteriores.
Figura 2.1: Diagrama de atividades do trabalho.
Captulo 3
Fundamentao Terica
3.1
Metodologias de Desenvolvimento de Software
Desenvolver software no uma tarefa fcil. H tempos essa atividade tem sido estudada para
encontrar melhores maneiras de especificar, planejar, desenvolver, testar, implantar e prestar
manuteno aos softwares criados.
A engenharia de software abrange um conjunto de trs elementos fundamentais - mtodos,
ferramentas e procedimentos - que possibilita ao gerente o controle do processo de desenvolvimento do software e oferece ao profissional uma base para a construo de software de alta
qualidade produtivamente(PRESSMAN, 2007).
Desde a crise do software, no final da dcada de 60, processos tm sido propostos para
ajudar em vrias questes, incluindo o aumento da qualidade do produto, facilitando a compreenso e comunicao humana, melhoria de processos de apoio, apoio gesto do processo,
fornecendo orientao automatizada do processo e apoio execuo automatizada. (ABRAN;
MOORE, 2004).
Podemos tratar esses processos como metodologias que do apoio ao desenvolvimento de
software. Segundo Sommerville (2007), metodologia de desenvolvimento um conjunto de
prticas recomendadas para o Desenvolvimento de Softwares, sendo que essas prticas, geralmente, passam por fases ou passos, que so subdivises do processo para orden-lo e melhor
gerenci-lo.
No decorrer do tempo, vrias metodologias foram e continuam sendo propostas. O que
define qual a melhor metodologia a se adotar depende muito de fatores como o contexto do
projeto, a natureza do trabalho (se manuteno ou desenvolvimento), a maturidade da organizao, a equipe envolvida, o custo relacionado, o tempo, o conhecimento do escopo do projeto,
o risco envolvido, entre outros.
CAPTULO 3. FUNDAMENTAO TERICA
10
O que sabemos que as metodologias realmente fazem a diferena quando so utilizadas.

Uma lista no exaustiva de metodologias descrita em Abran e Moore (2004), Pressman (2007)
e Paula (2009), dentre as quais:
Cascata;
Prototipagem descartvel;
Desenvolvimento evolucionrio;
Entrega incremental / iterativa;
Espiral;
Tcnicas de 4 gerao;
Processo dirigido por prazo;
Processo dirigido por ferramenta;
Praxis;
Processo Unificado;
RUP (Rational Unified Process);
AUP (Agile Unified Process);
XP (Extreme Programming);
FDD (Feature Driven Development);
DSDM (Dynamic Systems Development Method);
Scrum;
Crystal Clear;
Adaptive Software Development.
Dentro dessa lista, existem metodologias tradicionais e geis. Elas se diferenciam em diversos pontos. Paula (2009) traz um estudo de Barry Boehm (2006), em que o autor comparou
as situaes favorveis aos mtodos geis e aos mtodos tradicionais (chamados por ele de
mtodos dirigidos por planos). A Tabela 3.1, apresenta essa comparao.
A seo seguinte descreve as principais metodologias tradicionais.

rea
Caracterstica
Desenvolvedores Cultura
Tamanho
da
Equipe
Experincia
Localizao
Clientes
Relacionamento
Localizao
Requisitos
Natureza
Variabilidade
Arquitetura
Foco
Refatoramento
Projeto
Tamanho
Objetivo
Mtodos geis
11
Mais Informal
Menor
Mtodos dirigidos
por planos
Mais formal
Maior
Maior
nica
Mais cooperativo
Prxima
Emergentes
Alta
Soluo Imediata
Fcil
Menor
Valor rpido
Menor
Espalhada
Mais formal
Distante
Bem conhecidos
Baixa
Expansibilidade
Difcil
Maior
Alta garantia
Tabela 3.1: Mtodos geis x mtodos dirigidos por planos. (PAULA, 2009)
3.1.1
Metodologias Tradicionais
3.1.1.1
Cascata
O modelo cascata possui subprocessos que so executados em estrita sequncia, o que permite
demarc-los com pontos de controle bem definidos (PAULA, 2009). Esses pontos de controle,
em uma primeira anlise um ponto muito forte dessa metodologia, porm, podemos notar que
essa estrita sequncia o torna muito rgido e burocrtico. Uma vez que no se tem volta em um
subprocesso, cada processo deve ser muito bem dominado pela equipe envolvida.
A Figura 3.1 apresenta o modelo Cascata e seus subprocessos.
Pressman (2007) identifica que apesar desse modelo ter sido amplamente utilizado, hoje
at mesmo seus fiis defensores questionam a sua aplicabilidade em todas as situaes. Tanto
Pressman (2007) quanto Paula (2009) apresentam alguns dos principais problemas que ocorrem
quando esse modelo aplicado. So eles:
Os projetos reais raramente seguem o fluxo sequencial que o modelo prope;
Muitas vezes difcil para o cliente declarar todas as exigncias explicitamente;
O cliente deve ter pacincia. Uma verso de trabalho do(s) programa(s) no estar disponvel at um ponto tardio do cronograma do projeto;
Difcil lidar com a mudana de requisitos;
Torna difcil a entrega parcial de produtos;
12
Figura 3.1: Metodologia Cascata. Fonte: (PAULA, 2009)

Adia a identificao de riscos, tornando extremamente caro corrigir algum erro cometido
nas fases iniciais.
3.1.1.2
Cascata com realimentao
O modelo Cascata com realimentao uma variante do modelo Cascata, onde possvel que
haja reviso e alterao de resultados das fases anteriores(PAULA, 2009). Assim, esse tornase um modelo mais realista, pois, muito difcil passar para para a prxima etapa sem que
haja alguma melhoria ou alterao a se fazer. Atravs da Figura 3.2 possvel ver como fica
a ordem de execuo dos subprocessos, identificando que a cada fase possvel realimentar a
fase anterior a fim de aprimorar os resultados.
Uma dificuldade que tem de ser enfrentada por quem utiliza essa metodologia a de lidar
com as realimentaes entre as fases, pois, isso deve ter um limite para que no impacte em
variveis do projeto, como custo, tempo e escopo.
3.1.1.3
Prototipao
Segundo Pressman (2007) a prototipao um processo que capacita o desenvolvedor a criar

um modelo do software que ser implementado. O modelo pode assumir as seguintes formas:
13
Figura 3.2: Metodologia Cascata com realimentao. Fonte: (PAULA, 2009)

1. Prottipo em papel ou modelo baseado em PC que retrata a interao homem-mquina de
uma forma que capacita o usurio a entender como a interao ocorrer;
2. Um prottipo de trabalho que implementa algum subconjunto da funo exigida do software desejado;
3. Um programa existente que executa parte ou toda a funo desejada, mas que tem outras
caractersticas que sero melhoradas em um novo esforo de desenvolvimento.
A Figura 3.3 apresenta a sequncia de eventos dessa metodologia. O processo inicia-se
com a coleta e refinamento de requisitos, feito um rpido projeto, parte-se para a construo
do prottipo, o cliente faz a avaliao do prottipo, a equipe de desenvolvimento realiza o
refinamento do prottipo, com esse refinamento as necessidades do cliente so satisfeitas, e a
equipe de desenvolvimento torna-se capaz de entender o produto que dever ser desenvolvido
na prxima etapa.
Pressman (2007) aponta algumas problemticas em adotar a prototipao como metodologia de desenvolvimento. So elas:
Aps o refinamento do prottipo, no momento que a equipe vai partir para o desenvolvimento do produto, o cliente grita improprios e exige que alguns acertos sejam aplica-
14
Figura 3.3: Prototipao. Fonte: (PAULA, 2009)

dos para tornar o prottipo um produto de trabalho. Muito frequentemente a gerncia de
desenvolvimento do software cede.
No momento de elaborar o prottipo, o desenvolvedor pode usar linguagens e algoritmos
no muito bons simplesmente por serem mais fceis de de utilizar. O problema ocorre
quando no momento de implementar o produto o desenvolvedor utiliza(por j estarem
prontos) essas linguagens e algoritmos. Isso traz inevitavelmente a baixa qualidade para
o produto.
Para minimizar/evitar essas potenciais problemticas na utilizao dessa metodologia, a
chave definir-se as regras do jogo logo no comeo; ou seja, o cliente e desenvolvedor devem
ambos concordar que o prottipo seja construdo para servir como um mecanismo a fim de
definir os requisitos. E que depois ele ser descartado(PRESSMAN, 2007).

3.1.1.4
15
Espiral
O modelo espiral radicalmente diferente dos modelos apresentados at agora. Nele o produto
desenvolvido em uma srie de iteraes. Cada nova iterao corresponde a uma volta na
espiral.(PAULA, 2009). A Figura 3.4 representa como funciona esse modelo.
Esse modelo permite que os requisitos sejam definidos progressivamente, e apresenta alta flexibilidade e visibilidade. Esse modelo permite que, em pontos bem
definidos, os usurios possam avaliar partes do produto e fornecer realimentao
quanto s decises tomadas. Facilita tambm o acompanhamento do progresso de
cada projeto, tanto por parte de seus gerentes como dos clientes.(PAULA, 2009)
Figura 3.4: Metodologia Espiral. Fonte: (PAULA, 2009)

Esse modelo, atualmente a abordagem mais realstica para o desenvolvimento de sistemas e de software em grande escala.(PRESSMAN, 2007). Paula (2009) identifica que esse
modelo aplicado em processos recentes que se dizem geis. Entretanto alguns itens so
encontrados como problemticos em sua utilizao Pressman (2007) Paula (2009), tais como:
Requer gesto sofisticada;
16
O desenho deve ser robusto, para que a estrutura do produto no se degenere ao longo das
iteraes;
Requer uma equipe muito disciplinada e experiente;
difcil convencer grandes clientes que a abordagem evolutiva controlvel;
Exige considervel experincia na avaliao de riscos.
3.1.1.5
Entrega Evolutiva
Tanto Pressman (2007) quanto Paula (2009) afirmam que podem existir metodologias hbridas,
onde existem uma combinao de duas ou mais metodologias de desenvolvimento. A Figura
3.5 mostra a metodologia Entrega Evolutiva, que uma variante de alguns modelos. Nessa
variante, as atividades de especificao do problema e de desenho arquitetnico(global) so
executadas em cascata, e as atividades restantes so executadas em espiral(PAULA, 2009).
Figura 3.5: Metodologia Entrega Evolutiva. Fonte: (PAULA, 2009)

Quando falamos de metodologias hbridas devemos nos atentar que, mesmo quando utilizadas de maneira correta, no temos s os ganhos somados das metodologias, mas acabamos
por herdar tambm seus problemas. Na metodologia Entrega Evolutiva, podemos notar que a
parte inicial executado como o modelo Cascata, isso faz com que principalmente a etapa de
17
Desenho Arquitetnico, deva ser executada com muito cuidado e ateno, visto que no existe
o processo de realimentao.
3.2
Metodologias geis
De acordo com Araujo (2009), as metodologias ou mtodos geis evoluram desde a metade
de 1990 como reao aos mtodos considerados pesados. Esses mtodos pesados so assim
considerados devido a existncia de uma grande regulamentao, documentao e consequentemente grande burocracia em seus modelos, como no modelo cascata, que composto por
atividades sequenciais.
Os mtodos pesados ou tradicionais, no se tornaram obsoletos, porm as caractersticas
dos novos mercados exigem que existam mtodos mais adaptveis s incertezas e que respondam mais rapidamente s mudanas. Tambm necessrio que os projetos de desenvolvimento
de software satisfaam mais os clientes. Os mtodos tradicionais tm mais dificuldade em lidar com contextos incertos e constantemente mutveis. Assim, os mtodos leves ou geis
surgiram como uma alternativa para o desenvolvimento de software.
As metodologias geis ganharam fora em 2001, quando especialistas em diversos processos de desenvolvimento de software se juntaram para estabelecer princpios comuns entre estes
processos, resultando na criao do Manifesto gil (ALLIANCE, 2001).
As metodologias geis de software possuem princpios que as tornam mais eficazes e eficientes em ambientes complexos, onde sempre surgem novos requisitos e os mesmos sofrem
alteraes constantemente. O gerenciamento gil surgiu a partir das necessidades do mercado
atual exigir resultados imediatos, sob condies de altas incertezas e constantes mudanas (RIBEIRO; GUSMO, 2008), e caracterizado por iteraes curtas e dirigidas a produtos, com
decises colaborativas, contnua integrao das novas funcionalidades e rpida incorporao de
alteraes (RIBEIRO; ARAKAKI, 2006).
Um grupo de profissionais, motivados pela observao de que equipes de desenvolvimento
de software em vrias organizaes estavam amarrados por processos burocrticos, reuniramse para traar valores e princpios que permitiriam s equipes de desenvolvimento de software
produzissem rapidamente e respondessem s mudanas de forma menos dolorosa (BANKI;
TANAKA, 2008).
O grupo era formado de 17 autores e representantes de metodologias geis que j eram
presentes no mercado como: Scrum, eXtreme Programming (XP), Feature Driven Development
(FDD) e outras. Araujo (2009) salienta que, embora cada participante tivesse suas prprias
convices de como produzir software, todos concordavam que, com suas experincias, um
pequeno conjunto de princpios sempre parecia ter sido respeitado quando os projetos foram
18
considerados de sucesso. Assim, trabalharam por dois dias para criar um conjunto de valores e
publicaram o documento que reunia esses valores e princpios, intitulado Manifesto gil.
Esse grupo chamou a si mesmos de Aliana gil. Banki e Tanaka (2008) afirmam que
embora as metodologias que compem o movimento gil j estivessem no mercado h alguns
anos, com a denominao de metodologias leves, o Manifesto gil considerado oficialmente
como o incio do movimento gil.
O manisfesto estabeleceu os seguintes valores:
Indivduos e interaes mais que processos e ferramentas
Software em funcionamento mais que documentao abrangente
Colaborao com o cliente mais que negociao de contratos
Responder a mudanas mais que seguir um plano(ALLIANCE, 2001).
Ficou claro com o manifesto que os itens esquerda, apesar de tambm serem valorizados,
eram os itens esquerda (destacados no texto) que seriam mais valorizados. Neto (2008) diz
que o Manifesto gil no rejeita os processos e ferramentas, a documentao, a negociao
de contratos ou o planejamento, mas simplesmente mostra que eles tm importncia secundria
quando comparado com os indivduos e interaes, com o software estar executvel, com a
colaborao do cliente e as respostas rpidas a mudanas e alteraes. Alm desses valores,
o manifesto tambm trouxe 12 princpios que deveriam ser seguidos por quem adotasse os
mtodos geis. So eles:
1. Nossa maior prioridade satisfazer o cliente atravs da entrega contnua e adiantada de
software com valor agregado.
2. Mudanas nos requisitos so bem-vindas, mesmo tardiamente no desenvolvimento. Processos geis tiram vantagem das mudanas visando vantagem competitiva para o cliente.
3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com
preferncia menor escala de tempo.
4. Pessoas de negcio e desenvolvedores devem trabalhar diariamente em conjunto por todo
o projeto.
5. Construa projetos em torno de indivduos motivados. D a eles o ambiente e o suporte
necessrio e confie neles para fazer o trabalho.
6. O mtodo mais eficiente e eficaz de transmitir informaes para e entre uma equipe de
desenvolvimento atravs de conversa face a face.
7. Software funcionando a medida primria de progresso.
19
8. Os processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante indefinidamente.
9. Contnua ateno excelncia tcnica e bom design aumenta a agilidade.
10. Simplicidadea arte de maximizar a quantidade de trabalho no realizado essencial.
11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizveis.
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e ento refina
e ajusta seu comportamento de acordo.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e ento refina
e ajusta seu comportamento de acordo.
Atravs desses princpios, Abrahamsson (2002), citado por Banki e Tanaka (2008), afirma
que uma metodologia pode ser dita gil quando efetua o desenvolvimento de software de forma
incremental (liberao de pequenas verses, em iteraes de curta durao), colaborativa (cliente e desenvolvedores trabalhando juntos, em constante comunicao), direta (o mtodo em
si simples de aprender e modificar) e adaptativa (capaz de responder s mudanas at o ltimo instante). Assim, tal autor inclui como metodologias geis: Extreme Programming (XP),
Scrum, Crystal, Feature Driven Development (FDD), Dynamic Systems Development Method
(DSDM), Open Source Software Development e, com certa ressalva, o Rational Unified Process
(RUP).
3.2.1
Scrum
As razes do Scrum esto no artigo de Takeuchi e Nonaka (1986) que sumarizam as 10 melhores
prticas em empresas japonesas. Esses autores introduziram o termo Scrum, que se refere ao
jogo de Rugby, quando os jogadores se organizam em crculo para planejar a prxima jogada.
A Figura 3.6 mostra a jogada chamada Scrum. A comparao uma forma de mostrar que
o projeto deve ser conduzido em pequenos ciclos, mas com uma viso de longo prazo, que
ganhar o jogo. visvel tambm a unio do time.
O Scrum um framework de processo gil utilizado para gerenciar e controlar o desenvolvimento de um produto de software atravs de prticas iterativas e incrementais (FONSECA;
CAMPOS, 2008). composto por um conjunto de boas prticas de gesto que admite ajustes
rpidos, acompanhamento e visibilidade constantes e planos realsticos.
Segundo (MACHADO; MEDINA, 2009)o Scrum bastante objetivo, possuindo metas
claras, equipe bem definida, flexibilidade, comprometimento, cooperao e sua curva de aprendizado relativamente baixa. Para entender como funciona a metodologia Scrum, vamos primeiro entender como ela formada. Podemos dizer que a Scrum formada por papis e suas
20
Figura 3.6: Scrum - uma jogada do jogo Rugby

respectivas responsabilidades, cerimnias de tempo fixo, artefatos que so produzidos durante
todo o projeto e as regras que so responsveis por fazer a ligao entre os papis, cerimnias e
artefatos da Scrum (SCHWABER, 2009). A Figura 3.7 ilustra o diagrama do Scrum.
A seguir, sero descritas as partes que compem a Scrum.
3.2.1.1
Papis
Uma equipe que desenvolve qualquer projeto sobre os princpios da Scrum pode ser chamada
de Time Scrum. Os Times Scrum so projetados para otimizar flexibilidade e produtividade.
Eles so auto-organizveis, interdisciplinares e trabalham em iteraes(SCHWABER, 2009).
Cada Time Scrum possui trs papis:
3.2.1.2
O Scrum Master
O Scrum Master o responsvel por garantir que o processo seja compreendido e seguido
por todos os participantes do projeto. O Scrum Master deve garantir que o Time Scrum esteja
aderindo aos valores, prticas e regras do Scrum(SCHWABER, 2009).
Ele o responsvel por fazer o ambiente Scrum funcionar. ele quem deve assegurar que
o projeto e a cultura organizacional estejam ajustados para que as metas e o retorno sobre os
investimentos desejados sejam alcanados a cada Sprint(MACHADO; MEDINA, 2009).
Ele deve garantir que o time esteja totalmente funcional e produtivo, protegendo a equipe
Figura 3.7: Metodologia Scrum. Fonte: (SANTOS, 2009)
21
22
de interferncias externas(PEREIRA; TORREO; MARAL, 2007). Tambm de responsabilidade do Scrum Master facilitar todo o processo, descobrindo e eliminando os impedimentos
do time(FONSECA; CAMPOS, 2008). Apesar dele auxiliar o time, o Scrum Master no gerencia o time, uma vez que o time auto-organizvel(SCHWABER, 2009). O Scrum Master deve
participar do planejamento e reviso das Sprints e das reunies dirias dentro das Sprints. Ele
pode at ser um dos membros do time, mas isso no muito recomendado. O Scrum Master o
responsvel por trabalhar junto gerncia e aos clientes a fim de identificar e nomear o Product
Owner. Assim, o Scrum Master nunca deve ser o Product Owner. O Scrum Master quem deve
reportar ao Product Owner e demais Stakeholders.
3.2.1.3
O Product Owner
O Product Owner o representante dos stakeholders e responsvel por definir os requisitos e

as prioridades, criando os itens do Product Backlog. O Product Owner a nica pessoa responsvel pelo gerenciamento dos Product Backlog e por garantir o valor do trabalho realizado
pelo Time(SCHWABER, 2009). Pode at existir um grupo por trs do Product Owner que o
influencie, mas ele o nico responsvel por criar e priorizar os itens do Product Backlog de
acordo com o valor de retorno para o cliente. A equipe de desenvolvimento, ou seja, o Time,
dever sempre obedecer e desenvolver o que foi priorizado pelo Product Owner.
O Product Owner pode mudar os requisitos e prioridades a cada Sprint, bem como pode
aceitar ou rejeitar os resultados de cada Sprint(PEREIRA; TORREO; MARAL, 2007).
Esse papel composto por um representante do cliente dentro da equipe ou por uma pessoa
capacitada a sanear dvidas sobre requisitos que surjam no dia-a-dia, pois ele faz parte da equipe
e dever ter todo o comprometimento com o projeto(MACHADO; MEDINA, 2009).
3.2.1.4
O Scrum Team
O Scrum Team ou simplesmente Time que executa o trabalho propriamente dito. O time o
responsvel por transformar os itens do Product Backlog em itens do Sprint Backlog (SCHWABER, 2009). O Time consiste em desenvolvedores multifuncionais que possuem habilidades
para pegar os Backlogs do Produto e transform-los em incrementos de funcionalidades entregveis em cada Sprint. Assim, cada membro do time deve possuir conhecimento suficiente para
produzir completamente um incremento para ser entregue.
Um Scrum Team no possui funes pr-definidas ou ttulos dados a algum membro. Tambm no existe um subtime que cuide particularmente de uma rea. Todos os membros do time
so auto-gerenciveis e auto-organizveis.
No existe necessariamente uma diviso funcional atravs de papis tradicionais, por exem-
23
plo: o programador programa, o testador testa, o designer faz a programao grfica, entre outros(MACHADO; MEDINA, 2009). O compartilhamento de habilidades vital para o bom
desempenho de todos do time(SCHWABER, 2009).
Cabe aos membros do Scrum Team, quando encontrar algum impedimento para realizar
uma tarefa, reportar o impedimento ao Scrum Master, para que o mesmo possa agir e ajudar o
time a se desvencilhar do impedimento.
O tamanho do time um fator sobre o qual deve-se tomar cuidado quando define-se uma
equipe Scrum. recomendado que fique entre 5 e 9 pessoas, sendo 7 uma quantidade considerada adequada (SCHWABER, 2009). Essa quantidade de membros permite que o ambiente
produza interao suficiente para aumentar a produtividade e ainda no necessite de processos
complexos para coordenar a equipe. Sobre o tamanho do time, duas coisas devem ser ditas,
primeiro que o Scrum Master e Product Owner devem ser excludos dessa contagem, e segundo
que existem exemplos de times que apesar de no respeitar os limites inferior e superior para o
tamanho do time, conseguiram obter sucesso(SCHWABER, 2009).
A cada Sprint, ou seja, a cada interao, o time pode mudar sua composio. Mas isso
deve ser feito com cuidado, pois, quando se altera a composio do time, o que foi ganho
de produtividade devido auto-organizao reduzido. Ao final de cada Sprint o time deve
apresentar o que foi produzido(SCHWABER, 2009).
3.2.1.5
Cerimnias
Os eventos com durao fixa (Time-Boxes) no Scrum, tambm conhecidos por cerimnias,
so a Reunio de Planejamento da Release, a Sprint, a Reunio de Planejamento da Sprint, a
Reviso da Sprint, a Retrospectiva da Sprint e a Reunio Diria (SCHWABER, 2009).
3.2.1.6
Reunio de Planejamento da Release
Segundo Schwaber (2009), o propsito da reunio de planejamento da release o de estabelecer

um plano e metas que o Time Scrum e o resto da organizao possam entender e comunicar.
Nessa reunio deve-se estabelecer quando sero entregues os incrementos do produto e o produto como todo. Nesse momento definido quais sero a ordem dos incrementos a serem entregues aos clientes de maneira a satisfazer suas necessidades(SCHWABER, 2009). Isso feito
priorizando os itens de maior ROI(Return of Investment) para o cliente.

3.2.1.7
24
Sprint
A Sprint na Scrum representa um ciclo, ou um iterao(SANTOS, 2009). A cada Sprint um

incremento do produto deve ser entregue. Todo o projeto realizado atravs de consecutivas
Sprints. Assim, uma Sprint realizada aps a outra, sem que haja intervalos entre elas. Segundo
Schwaber (2009), as Sprints so constitudas de Reunio de Planejamento da Sprint, o trabalho
de desenvolvimento do incremento do produto, a Reviso da Sprint e a Retrospectiva da Sprint.
E a cada dia da Sprint, deve ocorrer uma reunio diria.
As Sprints devem possuir durao fixa. Na Scrum recomendado que a durao da Sprint
no exceda um ms, pois, considera-se que com esse tempo o projeto tenha um horizonte que
ainda pode ser controlado. A Scrum considera que dentro desse perodo j h complexidade
suficiente, e em um horizonte maior o projeto poderia perder o controle e seria arriscado demais
(SCHWABER, 2009). Estabelecendo o tempo fixo das Sprints possvel conter os riscos para
que o projeto seja realizado com sucesso.
Dentro de uma Sprint, o Scrum Master deve garantir ao time que nenhuma mudana que
possa afetar a meta da Sprint ser feita. Assim, o Scrum Master deve garantir que a composio
do time quanto as metas de qualidade devem permanecer constantes durante a sprint.
Numa Sprint, o time est se comprometendo em desenvolver o que foi selecionado para
o Backlog da Sprint. Se o time sentir que se comprometeu com mais do que dar conta, dever se reunir com o Product Owner para remover ou reduzir o escopo do Backlog da Sprint
(SCHWABER, 2009).
3.2.1.8
Reunio de Planejamento da Sprint
O objetivo da reunio priorizar os itens que sero executados na Sprint, alm de dar ao time
informao suficiente para que o mesmo possa validar e estimar o esforo em horas para cada
item (PEREIRA; TORREO; MARAL, 2007). Schwaber (2009) prope que essa reunio seja
realizada em oito horas para Sprints de um ms e 5% do tempo de uma Sprint com durao
menor que um ms.
Segundo Pereira, Torreo e Maral (2007), para essa reunio acontecer necessrio que:
O Product Backlog exista e cada item esteja estimado;
Exista apenas um Product Backlog e um Product Owner;
Todos os itens tenham uma nota em funo de sua importncia. Essa nota serve apenas
para organizar os itens por importncia;
25
O Product Owner entenda todos os itens do Product Backlog. Normalmente ele o autor
do mesmo, mas em alguns casos outras pessoas podem ter colocado itens no Backlog.
Na primeira metade da reunio deve ser decidido o que ser feito na Sprint. Para fazer isso
o Time Scrum com a ajuda do Product Owner ir selecionar os itens do Backlog do Produto
que sero realizados naquela Sprint. Schwaber (2009) diz que cabe somente ao time decidir a
quantidade de itens do Backlog do Produto ser selecionado para a Sprint.
A segunda metade da reunio destinada ao time planejar como os itens selecionados do
Backlog do Produto sero transformados e implementados de forma a se tornar um incremento
do produto. Nesse planejamento o time vai projetando o que deve ser feito para conseguir desenvolver os itens do Backlog do Produto que foram selecionados. No decorrer do planejamento, o
time tem que ir identificando as tarefas e decompondo-as de forma que elas possam ser realizadas em menos de um dia (SCHWABER, 2009). Ao decompor os itens do Backlog do Produto
em tarefas, o time obtm uma lista de tarefas que so os Backlog da Sprint. O time se autoorganiza para se encarregar e se responsabilizar pelo trabalho contido no Backlog da Sprint,
tanto durante a Reunio de Planejamento da Sprint quanto no prprio momento da execuo da
Sprint (SCHWABER, 2009).
3.2.1.9
Reunio Diria
Dentro de uma interao que ir gerar um incremento do produto, ou seja, dentro de uma Sprint,
a cada dia deve-se realizar uma reunio de 15 minutos para que todo o time fique por dentro
do que est acontecendo (SCHWABER, 2009). Cabe lembrar que esta no uma reunio para
mostrar o status do trabalho para o Product Owner ou qualquer outra pessoa. Essa uma reunio
que diz respeito somente ao time. recomendado que a reunio proceda com os membros de
p, para que no exceda o tempo pr-determinado e os participantes foquem no que realmente
necessrio(SCHWABER, 2009). O Time deve conduzir a reunio, onde cada membro deve
responder a trs perguntas (FONSECA; CAMPOS, 2008):
1. O que voc fez hoje?
2. O que far amanh?
3. Que impedimentos surgiram e que atrapalharam sua produtividade?
As reunies dirias devem ser realizadas no mesmo horrio e mesmo local. Elas melhoram
a comunicao entre o time, elimina a necessidade de outras reunies, ajuda a identificar impedimentos que venham atrapalhando o trabalho do time e ajuda na tomada de decises para
melhorar o nvel de conhecimento de todos em relao ao projeto. Segundo Pereira, Torreo e
26
Maral (2007) visitantes so bem vindos, mas devem ser apenas ouvintes, pois a reunio diria
resume-se ao time.
Cabe ao Scrum Master garantir que o time realize e mantenha a reunio diria dentro das
regras da Scrum. Cabe a ele tambm evitar que membros externos atrapalhe o andamento da
reunio(SCHWABER, 2009). A reunio diria um instrumento primordial dentro da Scrum e
visa inspecionar o progresso do time para alcanar a meta estabelecida da Sprint(SCHWABER,
2009).
3.2.1.10
Reviso da Sprint
Ao final de cada ciclo de desenvolvimento, deve-se realizar uma reunio de Reviso da Sprint
(SCHWABER, 2009). Segundo Schwaber (2009) essa reunio deve reunir o Time Scrum e as
partes interessadas com o intuito de apresentar o que acabou de ser feito na Sprint. Essa uma
reunio informal que objetiva mostrar o que foi feito e, em cima das alteraes que foram feitas
no Backlog do Produto, j comear a pensar no que poder ser feito em seguida. Essa reunio
de reviso deve durar 4 horas quando a Sprint tiver durao de um ms e no deve exceder 5%
do tempo da Sprint quando a mesma possuir durao menor.
Na reunio, alm de outras coisas, o Product Owner deve identificar o que foi feito e o
que no foi feito, o time deve discutir sobre o que deu certo e sobre os problemas que encontraram e como foram resolvidos(PEREIRA; TORREO; MARAL, 2007). O time deve
demonstrar o que foi feito e deve responder aos questionamentos do Product Owner quando
necessrio(SCHWABER, 2009). Essa uma reunio importante que ajuda no aprendizado do
grupo e fornece informaes importantes para as prximas reunies de planejamento de Sprints.
3.2.1.11
Retrospectiva da Sprint
Aps a Reviso da Sprint e antes da prxima reunio de planejamento para a prxima sprint,
o Time Scrum deve realizar uma reunio chamada de Retrospectiva da Sprint (SCHWABER,
2009). Essa reunio deve ter uma durao de 3 horas. Nesse perodo o Scrum Master deve
encorajar o time a olhar para a sprint passada e avaliar o modelo que eles vem adotando dentro
das prticas da Scrum. O time deve avaliar o que est sendo feito e como est sendo feito, com
o propsito de tornar mais eficaz e tambm mais gratificante o processo que eles tem adotado
para conseguir atingir a meta de uma Sprint.
Segundo Santos (2009), o objetivo dessa reunio avaliar o que deu certo e que deu errado
durante a Sprint e fazer os ajustes possveis para a prxima Sprint, ou seja, o ciclo de melhoria
contnua. Nessa reunio o importante inspecionar como ocorreu a Sprint, mas olhando para
as relaes entre as pessoas do time, processos e ferramentas utilizadas(SCHWABER, 2009).
27
Schwaber (2009) chama a ateno para o fato do aprendizado gerado nessa reunio contribuir
fortemente para o amadurecimento da equipe e o aumento da produtividade, visto que os pontos
que deram certo sero frisados e os pontos que podem ser feitos de maneira melhor devem ser
discutidos.
3.2.1.12
Artefatos
3.2.1.13
Backlog do Produto
O product backlog o boto de start do Scrum. Segundo Pereira, Torreo e Maral (2007),
esse um dos conceitos mais importantes dentro da Scrum. atravs dele que todo o trabalho
ser organizado. O product backlog basicamente uma lista de requisitos, estrias, coisas que o
cliente deseja, descritas utilizando a terminologia do cliente(SCHWABER, 2009). Como j foi
dito, o Product Owner o responsvel por criar o contedo do backlog e por sua priorizao.
importante saber que o Backlog nunca est completo, pois, com o decorrer do trabalho que as
coisas vo ficando mais claras para o cliente e assim ele consegue ir definindo o que realmente
quer. A primeira seleo para comear o desenvolvimento s mostra os primeiros requisitos
do produto a ser desenvolvido. Pode-se dizer que o Backlog dinmico, no sentido de que ele
est constantemente mudando. Pode-se dizer tambm que enquanto existir Backlog do produto
tambm existir um produto a ser feito(SCHWABER, 2009). O Backlog uma lista de todas as
caractersticas, funes, tecnologias, melhorias e correes que devem ser efetuadas no produto
para as prximas verses(SANTOS, 2009).
A partir do momento que as partes do produto comeam a ser entregues ao final das Sprints,
o produto comea a tomar forma e assim o Product Owner tem condies de avaliar melhor o
que quer e mudar os requisitos(SCHWABER, 2009).
3.2.1.14
Burndown da Release
O Burndown da Release um grfico que registra a soma das estimativas dos esforos restantes
do Backlog do Produto ao longo do projeto(SCHWABER, 2009). O esforo estimado deve
estar em alguma unidade de trabalho que o time tenha decidido usar. Em relao as unidades
de tempo, geralmente so utilizadas as Sprints. As estimativas dos itens do Backlog do produto
so calculadas durante o planejamento da verso para entrega, e medida que itens forem sendo
criados. Quando se prepara os itens do Backlog do produto as estimativas dos itens podem ser
revisadas e alteradas a qualquer momento(SCHWABER, 2009). Apesar do Product Owner criar
os itens do Backlog, as estimativas so de responsabilidade do time.

3.2.1.15
28
Backlog da Sprint
O Backlog da Sprint so as tarefas que o time precisa executar para transformar os itens do
Backlog do Produto em um incremento do produto final. Pode-se dizer que o Backlog da Sprint
todo o trabalho que o time deve realizar para alcanar a meta da Sprint. Segundo Machado e
Medina (2009), uma lista de tarefas (histrias mais relevantes) com suas respectivas estimativas de durao, do presente momento at o fim do Sprint.
Segundo Schwaber (2009), no decorrer da Sprint o time pode decidir adicionar algumas
tarefas ao Backlog da Sprint por detectar que para a realizao de alguma tarefa necessita a realizao de uma no planejada. O time tambm pode remover tarefas do Backlog da Sprint, desde
que chegue-se ao entendimento que a tarefa no necessria. Quando as tarefas do Backlog da
Sprint vo sendo realizadas o time precisa atualizar as estimativas de horas para ir terminando
as tarefas. S o time tem o poder de mudar o Backlog da Sprint durante a Sprint e s ele pode
alterar a estimativa das tarefas(SCHWABER, 2009).
Figura 3.8: Burndown da Sprint (SANTOS, 2009)
3.2.1.16
Burndown da Sprint
Segundo Machado e Medina (2009) o burndown um dos principais recursos de medio do

processo de desenvolvimento e um diferencial para a metodologia SCRUM. O Burndown do
Backlog da Sprint um grfico da quantidade restante de trabalho do Backlog da Sprint pela
29
quantidade de dias restantes da Sprint(SCHWABER, 2009). A Figura 3.8 mostra um exemplo

de burndown.
Segundo Schwaber (2009), o grfico sempre relaciona a somente uma Sprint e para determinar o trabalho que resta deve-se somar as estimativas restantes do Backlog da Sprint a cada
dia. A quantidade de trabalho restante para uma Sprint a soma do trabalho restante para tudo
do Backlog da Sprint. Assim, necessrio acompanhar as somas diariamente, traando uma
linha atravs dos pontos no grfico. Com esse grfico o time pode gerenciar seu progresso em
completar o trabalho de uma Sprint(SANTOS, 2009).
3.3
Gerenciamento de Projetos
As pessoas tm planejado e gerenciado projetos desde o incio dos tempos (ARAUJO, 2009).
Mesmo sem possuir ferramentas e tcnicas to aprimoradas, os povos sempre que tinham que
construir alguma coisa, organizavam-se e planejavam para conseguir atingir o objetivo. E como
Sene, (2010) descreve em seu trabalho, um projeto pode ser definido como um empreendimento organizado para alcanar um objetivo especfico. O PMBOK, que um produto do
PMI(Project Management Institue), tambm traz que um projeto um esforo temporrio
empreendido para criar um produto, servio ou resultado exclusivo.
Segundo Sene (2010), a gerncia de projetos surgiu como um processo de gerenciamento
para lidar com a complexidade do trabalho em grupo baseado em conhecimento e pelas demandas de novos mtodos de gerenciamento. Araujo (2009) mostra que por diversos fatores as
organizaes modernas esto descobrindo que a utilizao do gerenciamento de projetos traz
muitas vantagens. O PMBOK tambm concorda que a crescente aceitao do gerenciamento
de projetos indica que a aplicao de conhecimentos, processos, habilidades, ferramentas e tcnicas adequadas pode ter um impacto significativo no sucesso de um projeto.
Em contextos complexos e cada vez mais competitivos, as empresas precisam obter sucesso
em seus projetos. Com isso, necessrio que tcnicas e ferramentas sejam adotadas para se
conseguir gerenciar a complexidade, que est relacionada a diversos fatores, como a quantidade
de recursos envolvidos, os custos, o tempo para se entregar o projeto, a prpria tcnica envolvida
no projeto, a dificuldade de controlar vrias pessoas, a necessidade de prever e tratar riscos, entre
outros fatores. Assim, podemos entender o porque das tcnicas de gerenciamento de projetos
estarem sendo procuradas e praticadas cada vez mais por empresas em diversas reas.
3.3.1
30
Gerenciamento de projetos com o PMBOK
O Project Management Body of Knowledge, conhecido pela sigla PMBOK, um guia de

conhecimentos em gerenciamentos de projetos, que serve como base para vrios profissionais
da rea. Esse guia contm conhecimento que evoluiu a partir das boas prticas reconhecidas de
profissionais de gerenciamento de projetos que contriburam para seu desenvolvimento(PMI,
2008).
Como o prprio guia descreve, seu objetivo
identificar o subconjunto do conjunto de conhecimentos em gerenciamento de projetos que amplamente reconhecido como boa prtica. Identificar significa fornecer uma viso geral, e no uma descrio completa. Amplamente reconhecido
significa que o conhecimento e as prticas descritas so aplicveis maioria dos
projetos na maior parte do tempo, e que existe um consenso geral em relao ao
seu valor e sua utilidade. Boa prtica significa que existe acordo geral de que
a aplicao correta dessas habilidades, ferramentas e tcnicas podem aumentar as
chances de sucesso em uma ampla srie de projetos diferentes. Uma boa prtica
no significa que o conhecimento descrito dever ser sempre aplicado uniformemente em todos os projetos; a equipe de gerenciamento de projetos responsvel
por determinar o que adequado para um projeto especfico(PMI, 2008).
Podemos ver que o PMBOK no uma norma completa sobre o gerenciamento de projetos, mas um guia que promove um vocabulrio comum dentro da profisso de gerenciamento
de projetos para se discutir, escrever e aplicar conceitos de gerenciamento de projetos (PMI,
2008).
O PMBOK elaborado pelo Project Management Institute PMI, que segundo o PMI
- So Paulo (2010) alm de ser a maior entidade mundial sem fins lucrativos voltada ao gerenciamento de projetos, hoje tem mais de 500.000 membros filiados em 185 pases.
O guia PMBOK trata o gerenciamento de projetos como a aplicao de conhecimentos,
habilidades, ferramentas e tcnicas s atividades do projeto, a fim de atender aos seus requisitos.
E para o gerenciamento de projetos, o guia traz 42 processos que devem ser aplicados de forma
integrada.
Nesse momento importante ressaltar que um processo um conjunto de aes e atividades
inter-relacionadas, que so executadas para alcanar um produto, resultado ou servio predefinido. O PMBOK caracteriza cada processo atravs de suas entradas, ferramentas e tcnicas
que podem ser utilizadas e suas sadas. A Figura 3.9 mostra como o formato dos processos
para o guia.
31
Figura 3.9: Formato de Processos. Fonte: Araujo (2009)

O PMBOK agrupa os 42 processos dentro de cinco categorias, conhecidas como grupos
de processos de gerenciamento de projetos. Os grupos so:
Processos de Iniciao
Processos de Planejamento
Processos de Execuo
Processos de Monitoramento e Controle
Processos de Encerramento
A Figura 3.10 exemplifica como a interao desses processos.
Figura 3.10: Grupo de Processos de Gerenciamento de Projetos. Fonte: Adaptado (PMI, 2008)
O PMBOK diz que apesar dos grupos de processo possurem interfaces bem definidas, na
prtica visto que eles se sobrepem. Isso pode ser elucidado pela Figura 3.11, onde podemos
ver como os grupos de processos se interagem durante um projeto e como, dependendo da fase
em que o projeto se encontra, o grupo de processos pode ser mais intenso.
32
Figura 3.11: Os grupos de processos interagem em uma fase ou em um projeto. Fonte: (PMI,
2008)
O PMBOK divide o conhecimento necessrio para gerenciar projetos em 9 reas:
1. Gerenciamento de Integrao do Projeto
2. Gerenciamento do Escopo do Projeto
3. Gerenciamento de Tempo do Projeto
4. Gerenciamento de Custos do Projeto
5. Gerenciamento da Qualidade do Projeto
6. Gerenciamento de Recursos Humanos do Projeto
7. Gerenciamento das Comunicaes do Projeto
8. Gerenciamento de Riscos do Projeto
9. Gerenciamento debook Aquisies do Projeto
A Tabela 3.2 a seguir ilustra os 42 processos mapeados dentro dos 5 grupos de processos e
suas respectivas reas de conhecimento. A partir dessa tabela possvel notar a importncia que
o guia PMBOK d ao grupo de processos de planejamento, visto que a maioria dos processos
esto nesse grupo. A quantidade de processos dentro das reas de conhecimento: Gerenciamento
de Tempo do Projeto e de Gerenciamento de Riscos do Projeto, maior que as outras reas, pode
indicar tambm a importncia que deve ser dada essas reas.
33
Tabela 3.2: Mapeamento de grupos de processos de gerenciamento de projetos e reas de conhecimento. Fonte: Adaptado (PMI, 2008)
reas de conhecimento
Gerenciamento
de Integrao
Projeto
do
Grupos de Processos de Gerenciamento de Projetos

Processos de Iniciao
Processos
de
Planejamento
Processos
Execuo
Desenvolver
o
termo de abertura
do projeto
Desenvolver
o
plano de gerenciamento do
projeto
Orientar e gerenciar a execuo

do projeto
Gerenciamento do
Escopo do Projeto
1-Coletar requisitos
2-Definir
Escopo
3Criar a estrutura
analtica do projeto
1Definir as atividades 2Sequenciar as
atividades 3Estimar
os recursos das atividades 4Estimar as
duraes das atividades 5Desenvolver o
cronograma
1-Estimar os custos 2-Determinar
o oramento
Planejar a Qualidade
Gerenciamento de
Tempo do Projeto
Gerenciamento de
Custos do Projeto
Gerenciamento
da Qualidade do
Projeto
Gerenciamento de
Recursos Humanos
do Projeto
Gerenciamento das
Comunicaes
do
Projeto
Gerenciamento de
Riscos do Projeto
Gerenciamento
de Aquisies
Projeto
do
Desenvolver
o
plano de recursos
humanos
Identificar as partes interessadas
Planejar as comunicaes
1-Planejar o gerenciamento de riscos 2Identificar os riscos

3-Realizar a anlise
qualitativa dos riscos
4-Realizar a anlise
quantitativa de riscos
5-Planejar respostas a
riscos
Planejar as aquisies
de
Processos
de
Monitoramento
e Controle
1-Monitorar
e
controlar o trabalho de projeto
2-Realizar o controle integrado de
mudanas
1-Verificar o escopo 2-Controlar
o escopo
Processos de Encerramento
Encerrar o projeto ou fase
Controlar o cronograma
Controlar os custos
Realizar a garantia da qualidade
1-Mobilizar
a
equipe do projeto
2-Desenvolver
a
equipe do projeto
3-Gerenciar a equipe
do projeto
1-Distribuir
as
informaes
2-Gerenciar
as
expectativas das partes
interessadas
Realizar o controle da qualidade
Reportar
desempenho
Monitorar e controlar os riscos
Realizar
es
aquisi-
Administrar
aquisies
as
Encerrar as aquisies
3.3.2
34
Gerenciamento de Projetos geis
O Agile Project Management (APM) teve sua origem em 2001, no movimento iniciado pela
comunidade internacional de desenvolvimento de sistemas, j mencionado nesse trabalho. Foi
no mesmo contexto da publicao do Manifesto for Agile Software Development (ALLIANCE,
2001). Este movimento foi uma reao s crescentes presses por constantes inovaes, concorrncia acirrada, necessidade de reduo dos ciclos de desenvolvimento de novos sistemas
e de adaptao a um ambiente de negcio bastante dinmico, contexto em que o gerenciamento
de projetos clssico no se mostrou plenamente efetivo (DIAS; SOLER, 2005).
O APM pode ser definido como uma nova plataforma de gerenciamento de projetos, aplicvel a ambientes instveis e desafiadores, sujeitos a freqentes mudanas, nos quais o processo
prescritivo e padronizado do gerenciamento de projetos clssico no mais se adequa (LOPES,
2008). O ambiente gerido pelo APM sempre muito flexvel e os mtodos clssicos para gerenciar projetos possuem dificuldades nesse contexto.
O APM traz um novo enfoque de desenvolvimento de sistemas, baseado na agilidade, flexibilidade, nas habilidades de comunicao e na capacidade de oferecer novos produtos de valor
ao mercado, em curtos perodos de tempo (DIAS; SOLER, 2005).
Um projeto guiado pelo APM possui basicamente uma etapa inicial seguida de iteraes.
A cada iterao realizado planejamento para controlar o escopo, prazo, custo e qualidade,
objetivando entregar os incrementos do produto conforme s necessidades dos clientes. Ao
final das iteraes tem-se o encerramento do projeto. A organizao do APM pode melhor ser
visualizado pela Figura 3.12, onde as fases Agile Project Management so ilustradas.
Viso - Nessa fase o momento para elaborar uma primeira viso do produto, escopo
do projeto, identificao dos stakeholders e definio de como a equipe do projeto ir
trabalhar;
Especulao - Nesse momento os requisitos iniciais do produto so levantados, as atividades de desenvolvimento so planejadas, so definidas as datas para os marcos, as
iteraes e os recursos alocados. So realizadas tambm as atividades responsveis por
estabelecer as estimativas de custos e demais informaes financeiras;
Explorao - Engloba a entrega dos produtos planejados, atravs do gerenciamento da
carga de trabalho e do emprego de prticas e estratgias de mitigao de risco apropriadas.
Essas entregas so feitas sob a forma de incrementos de funcionalidades e so divididas
entre os ciclos do projeto;
Adaptao - Nessa fase realizado a reviso de tudo que obteve at o momento, avaliao
da equipe de projeto e levantado as necessidades de adaptao. Esse o momento de
avaliar o trabalho realizado versus os requisitos atualizados do projeto.
35
Figura 3.12: Fases do Agile Project Management. Fonte: Lopes (2008) Dias e Soler (2005)
Encerramento - Essa fase o momento de encerrar as atividades do projeto, transferir o
que foi apreendido entre a equipe envolvida, e celebrar a entrega do projeto.
A Figura 3.13 apresenta de forma simples como o relacionamento entre clientes e desenvolvedores dentro de um projeto gerenciado pelo APM.
Alm das fases que moldam o fluxo de trabalho em um projeto gerido pelo APM, existem
os princpios que devem ser seguidos por todos que utilizam a gesto de projetos geis. Esses
princpios so divididos em duas categorias, segundo Franco (2006) apud HIGHSMITH (2004).
So elas:
1. Entrega do Produto
2. Liderana e Colaborao
Cada categoria composta por trs princpios que podem ser visualizados na Figura 3.14.
Esses princpios servem de base para a equipe do projeto determinar quais prticas so mais
adequadas a cada contexto, a criar outras prticas quando necessrio, a avaliar e implementar
as prticas com agilidade. E, segundo Dias e Soler (2005), embora cada princpio seja til se
aplicado isoladamente, o sistema formado por eles cria um ambiente que encoraja e produz
resultados mais efetivos.
36
Figura 3.13: Relacionamento entre clientes e a equipe de desenvolvimento. Fonte: Adaptado

Lopes (2008) apud Martins (2007).
Figura 3.14: Seis princpios da Gesto de Projetos geis. Fonte: Adaptado Franco (2006) apud
HIGHSMITH (2004).
3.4
37
Gerenciamento de Riscos
Riscos so possveis futuros eventos que podem trazer consequncias indesejveis(PAULA,

2009).
Segundo Boehm (1991), que foi um dos precursores do estudo de gesto de riscos, o estudo
dessa disciplina em projetos de software tem por objetivo identificar, enderear, e eliminar itens
de risco antes de se tornarem tanto ameaas para o sucesso de construo do software, quanto
principais fontes de retrabalho. A gerncia de risco associada com Engenharia de Software
tem como uma de suas finalidades a de aumentar a qualidade do produto e do processo de
desenvolvimento de software(DAIBERT, 2008). A gesto de riscos parte indispensvel das
tcnicas mais atuais de gesto de projetos(PAULA, 2009).
Pressman (2007) ainda avalia a importncia de se realizar a gesto de riscos em projetos
de software, por esses se tratarem de empreendimentos difceis, onde muitas coisas podem dar
errado. Por isso ele enxerga que ficar sempre alerta e tomar medidas proativas para entender e
administrar os riscos um elemento-chave da administrao de projetos de software (PRESSMAN, 2007).
Gesto de riscos uma srie de passos que ajudam uma equipe de software a entender e
administrar a incerteza. Muitos problemas podem perturbar um projeto de software. Um risco
um problema em potencial pode ou no ocorrer(PRESSMAN, 2007).
Boehm (1991) define que a prtica de gesto de risco envolve duas etapas principais cada
um com trs etapas complementares.
A primeira etapa, avaliao de riscos, envolve:
Identificao de Riscos
Anlise de Riscos
Priorizao de Riscos
A segunda etapa, controle de riscos, envolve:
Planejamento da Gesto de Riscos
Resoluo de Riscos
Monitoramento de Riscos
A Figura 3.15 apresenta o modelo apresentado por Boehm (1991) para a gesto de riscos.
Com ela possvel notar a diviso dos passos para se realizar a gesto de riscos e tambm as
atividades em que cada passo se desmembra.
Figura 3.15: Software Risk Management. Fonte Boehm (1991)
38
39
Gusmo (2008) enfatiza, que a gerncia de riscos no deve ser entendida e utilizada somente
como uma atividade para avaliar e resolver problemas adversos, mas que deve visualizar oportunidades: vantagens estratgicas e diferenciais competitivos atravs da execuo de atividades
preventivas.
A gesto de riscos traz os seguintes benefcios(PAULA, 2009):
permite aceitar riscos de forma mais agressiva e, com isso, explorar melhor as oportunidades;
torna a comunicao dos riscos mas aceitvel(por exemplo, a clientes e diretores);
esclarece os critrios pelos quais um projeto deva ser considerado bem sucedido;
delimita a incerteza em relao ao projeto;
prov mecanismos de limitao do prejuzo;
deixa mais claras as responsabilidades;
permite salvar parcialmente esforos atingidos por riscos concretizados;
ajuda a focalizar as atenes onde so mais necessrias;
d maior visibilidade do projeto a gerentes e diretores.
A gerncia de riscos um processo dentro da gerncia de projetos, que assim como outros,
deve ser amadurecido dentro das organizaes que a praticam. Devemos lembrar que o amadurecimento de processos que circundam o desenvolvimento de software traz consigo o aumento
da qualidade do produto desenvolvido. A equipe de desenvolvimento tambm torna-se mais
madura e apreende a lidar melhor com o gerenciamento de riscos como uma atividade normal
dentro do desenvolvimento de software.
Gusmo (2008) apud Hall (1998), explica os estgios que uma organizao pode passar no
que diz respeito ao amadurecimento das tcnicas e procedimentos da gerncia de riscos. So
eles:
Problemtico - Neste estgio a organizao caracterizada pela falta de comunicao,
no existe a preocupao de identificar riscos, a descoberta de riscos considerada uma
m notcia;
Atenuado - Neste estgio as organizaes passam a introduzir os conceitos relacionados
aos riscos, as pessoas passam a aceitar os processos iniciais para lidar com os riscos, mas
ainda no so to seguras para report-los aos gerentes;
40
Prevenido - Neste estgio a gerncia de riscos deixa de ser vista como uma atividade
de gerncia e passa a ser vista como uma atividade da equipe de desenvolvimento de
projetos de software. Passa-se a uma fase de transio da abordagem evitar os sintomas
dos riscos para identificar e eliminar as razes das causas de riscos.
Antecipado - Neste estgio as organizaes e clientes passam a utilizar mtricas para antecipar falhas e prever eventos futuros. As equipes apresentam habilidade para aprender,
adaptar e antecipar mudanas.
Criando Oportunidades - Neste estgio as pessoas j tem uma viso positiva da gerncia
de riscos e a utiliza para inovar e criar um novo futuro. O risco, assim como qualidade,
passa a ser encarado como responsabilidade de todos dentro da organizao.
3.4.1
Gerenciamento de Riscos pelo PMBOK
O PMBOK identifica que o risco do projeto sempre futuro. O risco um evento ou uma
condio incerta que se ocorrer, tem um efeito em pelo menos um objetivo do projeto (PMI,
2008). Considerando isso o guia, traz que as empresas sempre percebem o risco como uma
incerteza nos objetivos organizacionais e do projeto.
Nem todos os riscos devem ser eliminados ou tratados. Cada caso deve ser analisado. O
que deve acontecer a chamada tolerncia aos riscos. Que a aceitao de riscos perante as
recompensas que a causa do risco pode trazer, desde que o risco esteja dentro de uma tolerncia
aceitvel para o projeto.
O guia PMBOK indica que a abordagem dada ao gerenciamento de riscos deve ser desenvolvida e adaptada para cada projeto. Responder aos riscos reflete exatamente no equilbrio da
organizao em correr risco ou evit-los.
A gesto de riscos no PMBOK tratado por uma das nove reas do conhecimento para
gerenciar projetos. Dentro do Gerenciamento de Riscos, seis processos so necessrios para se
gerenciar os riscos em um projeto. Dos seis, cinco deles pertencem ao grupo de processos de
planejamento do projeto. Sendo eles:
1. Planejar o Gerenciamento de Riscos;
2. Identificar os Riscos;
3. Realizar a Anlise Qualitativa dos Riscos;
4. Realizar a Anlise Quantitativa de Riscos;
5. Planejar Respostas a Riscos.
41
O outro processo, pertence ao grupo de processos de monitoramento e controle do projeto:

Monitorar e Controlar os Riscos.
Figura 3.16: Resumo dos processos de gerenciamento dos riscos do projeto. Fonte: PMI (2008)
A Figura 3.16 apresenta o resumo dos processos de gerenciamento dos riscos do projeto,
apresentando para cada processo, quais so as entradas, ferramentas e tcnicas necessrias para
produzir suas sadas.
Cada um desses processos so definidos da seguinte forma(PMI, 2008) :

3.4.1.1
42
Planejar o gerenciamento dos riscos
o processo de definio de como conduzir as atividades de gerenciamento dos riscos de um

projeto. Esse processo deve ser realizado de maneira explcita e cuidadosa, visto que dessa
forma aumenta a probabilidade de sucesso dos demais processos. Esse processo deve comear
na concepo do projeto e ser concludo nas fases iniciais do planejamento do projeto.
Um plano de riscos de um projeto de software deve conter informaes referentes a: metodologia a ser adotada, papis e responsabilidades dos envolvidos no projeto, oramento, prazos,
categorias de riscos, definies de probabilidade e impacto, as tolerncias que devem ser aceitas,
relatrios que devem ser necessrios e acompanhamento do gerenciamento de riscos.
3.4.1.2
Identificar os riscos
Identificar riscos processo de determinao dos riscos que podem afetar o projeto e documentao de suas caractersticas. Todas as pessoas envolvidas no projeto devem ser encorajadas
a participar desse processo. Esse processo deve ser executado de maneira iterativa, podendo
ser eficaz no aparecimento de novos riscos(o que sempre ocorrer). A maneira de identificar e
registrar os riscos deve sempre ser consistente, para que seja possvel compar-lo aos demais
identificados no mesmo projeto, ou em projetos semelhantes.
A equipe do projeto tem que estar comprometida com a identificao de riscos, no sentido
de desenvolver e manter um sentimento de responsabilidade pelos riscos e pelas aes associadas de respostas aos riscos. Existem vrias tcnicas que podem ser utilizadas para ajudar no
momento de identificar os riscos, como, revises de documentos, Brainstorming1 , Delphi2 , entrevistas, checklist de verificao, anlise da matriz SWOT3 , opinio de especialistas e tcnicas
de diagramas(causa e efeito, fluxogramas, influncias).
3.4.1.3
Anlise qualitativa dos riscos
Realizar a anlise qualitativa dos riscos processo de priorizao dos riscos para anlise ou
ao adicional atravs da avaliao e combinao de sua probabilidade de ocorrncia e impacto(PMI, 2008). Nesse processo para cada risco deve-se realizar uma avaliao da probabilidade de ocorrncia e o impacto que ele poder causar nos objetivos do projeto. Com essa
avaliao possvel haver uma priorizao dos riscos, levando em considerao tambm outros
1
uma tcnica geral de coleta de dados e exerccio de criatividade que pode ser usada para identificar riscos,
idias ou solues para problemas usando um grupo de membros da equipe ou especialistas no assunto.(PMI,
2008)
2 uma tcnica de coleta de informaes utilizada como meio de alcanar um consenso de especialistas em um
assunto. Nesta tcnica, os especialistas participam anonimamente(PMI, 2008).
3 SWOT - Strengths, Weaknesses, Opportunities, Threats. Essa tcnica utiliza-se da coleta de informaes para
examinar o projeto do ponto de vista de seus pontos fortes e fracos, oportunidades e ameaas(PMI, 2008).
43
fatores como as aes de respostas. Essas maneiras de classificar os riscos em relao a probabilidade e impacto, ajudam a diminuir a influncia de parcialidade no momento de priorizar os
riscos.
Assim como o processo de identificao, a anlise qualitativa dos riscos deve ser revisada e
atualizada ao longo do ciclo de vida do projeto.
Com a anlise qualitativa dos riscos possvel obter uma lista de riscos que podem ser
priorizados. Essa priorizao muito importante dentro de um projeto, uma vez que nem todos
os riscos sero tratados. A filtragem dos riscos pode mostrar quais so os riscos que devem ser
tratados primeiro, quais deles merecem mais ou menos ateno e quais so as fontes de riscos
que mais podero impactar nos objetos do projeto.
3.4.1.4
Anlise quantitativa dos risos
Esse o processo de analisar numericamente o efeito dos riscos identificados, nos objetivos
gerais do projeto(PMI, 2008). A anlise quantitativa deve ser realizada sobre os riscos que foram identificados e posteriormente, priorizados pela anlise qualitativa. Deve-se tomar cuidado
com a anlise quantitativa pois, nem todos os riscos podem ser analisados quantitativamente,
ou nem todos so necessrios para que estabelea bons planos de respostas para cont-los ou
elimin-los.
Algumas tcnicas so utilizadas no processo de analisar quantitativamente os riscos, como:
Entrevistas - Essa tcnica depende da experincia e de dados histricos para quantificar
a probabilidade e o impacto dos riscos nos objetivos do projeto. Um exemplo que pode ser
utilizado a amostragem de um cenrio Otimista, Pessimista e Mais provvel, atribuindo
valores a cada cenrio. A esses cenrios podem ser atribudos custos dentro de cada etapa
do projeto, ou dentro da WBS4 do projeto.
Opinio especializada - Nessa tcnica pessoas com experincia, principalmente recente,
so consultadas para identificar os impactos potenciais no custo e no cronograma, avaliar
a probabilidade e definir entradas para as ferramentas de anlise. Os especialistas tem a
capacidade de identificar os pontos fracos das anlises feitas por ferramentas e os pontos
fortes, considerando sempre os recursos e a cultura da organizao.
Ao se realizar a anlise quantitativa dos riscos, possvel obter um lista priorizada de riscos
quantificados, que so as maiores ameaas ou as maiores oportunidades para o projeto. Como
as anlises devem ser feitas constantemente, possvel obter tendncias e agir rapidamente,
4 Work
Breakdown Structure ou Estrutura analtica do projeto - Uma decomposio hierrquica orientada

entrega do trabalho a ser executado pela equipe do projeto para atingir os objetivos do projeto e criar as entregas
necessrias. Ela organiza e define o escopo total do projeto.(PMI, 2008)
44
diminuindo o aparecimento de riscos que ameaam o projeto ou potencializando os riscos que

podem beneficiar o projeto.
Com esse processo, as chances de atingir os objetivos do projeto podem ser mensuradas.
Assim, melhores aes podem ser tomadas pela equipe.
3.4.1.5
Planejar as respostas aos riscos
Planejar as respostas aos riscos o processo de desenvolvimento de opes e aes para aumentar as oportunidades e reduzir as ameaas aos objetivos do projeto(PMI, 2008).
Esse processo realizado posteriormente aos processos de anlise qualitativa e quantitativa
dos riscos. importante que esse processo seja bem realista, para que no exceda os custos
e demais restries do projeto. Logo necessrio que as aes de respostas aos riscos, sejam
acordadas com todas as partes envolvidas no projeto.
No momento de planejar respostas aos riscos, necessrio que a priorizao dos riscos seja
respeitada de forma a evitar gastar recursos(tempo, dinheiro, pessoas, ...) alm dos necessrios.
O PMBOK traz algumas estratgias para responder aos riscos identificados e analisados
do projeto.
Uma das estratgias para lidar com riscos negativos ou ameaas. Nessa estratgia uma das
quatro aes devem tomadas em relao ao risco: Eliminar, Transferir, Mitigar ou Aceitar.
Eliminar - Essa ao consiste em modificar o plano de gerenciamento do projeto a fim
de remover totalmente a ameaa.
Transferir - Essa ao consiste em transferir o risco para outra parte externa. O que
no elimina o risco, e por isso quase sempre envolve algum pagamento parte que est
assumindo o risco.
Mitigar - Essa ao consiste em esforar-se para reduzir a probabilidade e/ou impacto do
risco para dentro de um limite aceitvel, o que em geral mais eficaz do que trabalhar
para reparar os danos depois que o evento j ocorreu.
Aceitar - Essa ao significa que a equipe do projeto decidiu no alterar o plano de
gerenciamento do projeto para lidar com um risco, ou no conseguiu identificar outra
estratgia de resposta adequada (PMI, 2008).
Essa ao segundo o PMBOK, pode ser passiva ou ativa. Passiva quando no requer
nenhuma ao exceto documentar a estratgia, e ativa quando a equipe estabelece uma
reserva para contingncias, incluindo tempo, dinheiro ou recursos para lidar com os riscos.
45
Uma segunda estratgia, volta-se para lidar com os riscos positivos ou oportunidades. Nesse
caso uma das seguintes aes podem ser tomadas:
Explorar - Essa ao consiste em garantir que o risco com impactos positivos realmente
acontea. Um exemplo trazido pelo PMBOK, seria designar os recursos mais talentosos
da organizao para o projeto a fim de reduzir o tempo de concluso ou para proporcionar
um custo mais baixo do que foi originalmente planejado.
Compartilhar - Envolve a alocao integral ou parcial da propriedade da oportunidade
a um terceiro que tenha mais capacidade de capturar a oportunidade para benefcio do
projeto (PMI, 2008).
Melhorar - Essa ao priva por identificar e maximizar os principais impulsionadores do
risco positivo, de maneira conseguir aumentar a propriedade de sua ocorrncia.
Aceitar - Aceitar uma oportunidade desejar aproveit-la caso ela ocorra, mas no
persegu-la ativamente.
Outra estratgia que pode ser aplicada em casos mais especficos solicitar a opinio de
especialistas, que a consulta a pessoas experientes com o processo de gerenciamento de riscos.
Nesse caso, a empresa pode contratar consultores no assunto.
Ao final do processo de planejamento de respostas aos riscos, os registros do projeto devem
ser atualizados, neste caso, tanto o plano de gerenciamento de riscos, quanto os outros planos
do gerenciamento do projeto(cronograma, custos, qualidade, aquisies, recursos humanos ...).
3.4.1.6
Monitorar e controlar os riscos
O processo de implementao de planos de respostas aos riscos, acompanhamento dos riscos

identificados, monitoramento dos riscos residuais, identificao de novos riscos e avaliao da
eficcia dos processos de tratamento dos riscos durante todo o projeto (PMI, 2008).
Captulo 4
Estado da Arte
Para melhor entender o propsito desse trabalho, as sees seguintes apresentam um pouco do
que se tem feito pela gesto de riscos em vrios contextos. Os trabalhos esto descritos em
sequncia cronolgica de publicao.
Boehm (1991) publicou o trabalho Software Risk Management: Principles and Practices
onde j preocupava-se com a quantidade de projetos de software que eram fracassados. O fracasso desses projetos poderiam ser evitados se houvessem uma preocupao inicial em resolver
os seus elementos de alto risco. Boehm (1991) constatou que ignorar ou negligenciar o tratamento de elementos de risco em um projeto certamente o levaria ao fracasso.
Assim, o autor sugere que a tentativa de se criar a disciplina de gerncia de riscos poderia
levar os projetos ao sucesso. Acreditando-se nisso, o autor apresenta uma srie de seis passos
que seriam necessrios para se realizar o gerenciamento de riscos: Risk Identification, Risk
Analysis, Risk Priorization, Risk Management-planning, Risk Resolution e Risk Monitoring. Esses seis passos so descritos pelo autor atravs do acompanhamento de um experimento
realizado por ele. O trabalho traz em detalhes alguns resultados da gesto de risco realizada no
projeto.
O trabalho de Nascimento (2003) faz uma explanao sobre diversos assuntos relacionados
aos riscos, como os principais conceitos e definies, a classificao dos riscos, o plano de
gerenciamento de riscos, os custos dos riscos, a necessidade de gerenciar os riscos de forma
conjunta e em equipe, vrias tcnicas para identificar riscos, a quantificao e a elaborao das
respostas aos riscos, o controle e as responsabilidades sobre os riscos.
Aps essa etapa de estudo, Nascimento (2003) apresenta sua maior contribuio para o
estudo de riscos, onde a autora constata que nem sempre os riscos so negativos, ou seja, existem
riscos positivos. No caso de riscos positivos, estes devero trazer benefcios ao projeto caso
deixe de ser uma incerteza e realmente acontea. Os riscos positivos podem fazer com que os
projetos melhorem sua qualidade, reduzam seus custos ou at reduzam seus prazos.
46
CAPTULO 4. ESTADO DA ARTE
47
Nascimento (2003) deixa claro a importncia de se tratar riscos negativos e positivos com a
mesma fora, visto que apesar dos gerentes se preocuparem mais com os riscos negativos, o tratamento de riscos positivos pode atingir o projeto na mesma proporo que os riscos negativos,
porm trazendo vantagem competitiva organizao que se beneficia do projeto.
Rocha e Belchior (2004) realizaram um trabalho de mapeamento do gerenciamento de riscos a partir do PMBOK, CMMI e RUP, objetivando investigar as similaridades e as divergncias
entre as abordagens dos mesmos para projetos de software, no sentido de melhorar o processo
de desenvolvimento software. Aps mapear cada prtica e processo do CMMI e RUP nas reas
de gerenciamento de riscos trazidas pelo PMBOK, os autores fizeram uma anlise para cada
rea do gerenciamento de riscos.
Rocha e Belchior (2004) verificaram que o gerenciamento de riscos nos modelos estudados
esto em consonncia em seus aspectos essenciais, no havendo nenhuma incompatibilidade
fundamental entre eles (ROCHA; BELCHIOR, 2004).
Hillson (2005), ciente da importncia do gerenciamento de riscos e da crescente adoo
de suas prticas pelas empresas, sumarizou as melhores prticas correntes para lidar com o gerenciamento de riscos em projetos, e posteriormente, apontou trs reas nas quais suas prticas
deveriam se desenvolver no curto/mdio prazo. Segundo o autor, a evoluo das trs reas, contribuiriam para aumentar a profundidade e amplitude na anlise da aplicao e a incluso dos
aspectos comportamentais no processo de risco.
No trabalho o autor apresentou de forma genrica as prticas que eram adotadas pela maioria das empresas como padres para o gerenciamento de riscos. O autor identificou que todos
os processos de riscos seguem os mesmos passos bsicos (embora a terminologia difere entre
eles), com os seguintes estgios(HILLSON, 2005):
Primeiro a fase de definio ou iniciao, garantindo que os objetivos do projeto esto de
acordo e entendido por todos os stakeholders e determinando o escopo e nvel de detalhe
requerido para o processo de risco.
a definio da identificao do risco, usando tcnicas tais como brainstorms, workshops,
checklists, prompt lists, entrevistas, questionrios, etc.
A avaliao dos riscos identificados, priorizando os riscos-chave para futura ateno e
ao.
A seguir vem o planejamento de resposta, quando a estratgia e as aes so determinadas
para negociar com o risco de modo que fi que apropriado, executvel e a preo acessvel.
O planejamento deve liderar a ao, isso torna importante implementar um plano de aes,
monitorar a efetividade e relatrio de resultados para os stakeholders.
48
Finalmente, qualquer processo de risco deve incluir reviso e atualizao. Risco est
sempre mudando no projeto, ento o processo deve ser iterativo, regularmente revisando
a exposio do risco, identificando e avaliando novos riscos e garantindo respostas apropriadas.
No estudo, o autor constata que at o momento a disciplina de gerenciamento de riscos
tem-se desenvolvido muito, muitos livros-texto tem dedicado sees exclusivas a ela, vrias
empresas incorporaram-l suas prticas. Mas o autor tambm constatou que esse crescimento
e evoluo pode fazer com que o gerenciamento de riscos em projetos possa parecer uma disciplina madura, apesar de ainda est em desenvolvimento.
Maral et al. (2007) realizaram um estudo sobre a extenso da metodologia Scrum sobre as
reas de gerenciamento de projetos do CMMI. Neste estudo realizou-se um mapeamento entre
o Scrum e o CMMI, avaliando-se o atendimento das prticas especficas do modelo restrito ao
escopo de gesto de projetos.
O estudo de Maral et al. (2007) trouxe bastante motivao para a realizao deste trabalho, pois todas as prticas especficas de gerenciamento de riscos foram consideradas no
satisfeitas pela Scrum, com exceo da rea Identificar os riscos, que foi classificada como
Parcialmente Satisfeita. Sobre a cobertura do gerenciamento de riscos por parte da Scrum,
os resultados do estudo realizado esto apresentados na Figura 4.1. Tambm ficou claro pela
Figura 4.2, a defasagem da metodologia Scrum em relao a rea de gerenciamento de riscos,
onde obteve os piores resultados.
Figura 4.1: Cobertura da Scrum em relao rea de Gerenciamento de Riscos do CMMI.

Adaptado: (MARAL et al., 2007)
.
Teixeira (2007) apresentou um estudo onde foram comparados os resultados esperados dos
vinte e um processos do modelo MPSBR com as prticas defendidas pela metodologia Scrum. O
trabalho semelhante ao publicado por Maral et al. (2007), porm tem como anlise o modelo
MPSBR.
Aps analisados os resultados esperados para o processo de Gerncia de Riscos do MPSBR,
conforme as abordagens da Scrum, Teixeira (2007) concluiu que dos dez resultados esperados
49
Figura 4.2: Cobertura geral das reas do CMMI pela metodologia Scrum. Adaptado: Maral et
al. (2007)
.
para esse processo, nenhum deles atendido pelo Scrum. O resultado dos dez resultados esperados para o processo de Gerncia de Riscos do MPSBR pode ser visto na Tabela 4.1.
Processo de Gerncia de Riscos MPSBR

O escopo da gerncia de riscos determinado
As origens e as categorias de riscos so determinadas, os parmetros
usados para quantificao da probabilidade e severidade so definidos e
as ameaas e suas fronteiras para cada categoria de risco so definidas
Estratgias apropriadas para a gerncia de riscos so definidas e implementadas
Os riscos do projeto so identificados e documentados incluindo seu
contexto, condies e possveis consequncias para o projeto e as partes
que sero afetadas
Os riscos so priorizados, estimados e classificados de acordo com as
categorias e os parmetros definidos
Planos para a mitigao de riscos so desenvolvidos
Os riscos so analisados e a prioridade de aplicao dos recursos para o
monitoramento desses riscos determinada
A situao de cada risco periodicamente monitorada e o plano de mitigao de riscos implementado quando apropriado
As medies de desempenho nas atividades de tratamento de risco so
coletadas
Aes apropriadas so executadas para corrigir ou evitar o impacto dos
riscos
50
Situao
No Atendido
No Atendido
No Atendido
No Atendido
No Atendido
No Atendido
No Atendido
No Atendido
No Atendido
No Atendido
Tabela 4.1: Aderncia do Scrum ao processo de Gerncia de Riscos do MPS.BR. Fonte: (TEIXEIRA, 2007)
Captulo 5
Desenvolvimento da Ferramenta Proposta
5.1
Especificao da Ferramenta
As sees seguintes apresentam a especificao, anlise e o desenho da ferramenta que est

sendo proposta nesse trabalho. A ferramenta proposta ter o nome de Riskrum. O nome devese juno das prticas de gesto de Riscos metodologia gil Scrum. Assim, a partir desse
momento a ferramenta proposta ser referida pelo seu nome.
5.1.1
Misso
A Riskrum tem como misso permitir que as prticas de gerenciamento de riscos sejam realizadas de forma integrada, por uma ou mais equipes de desenvolvimento de software que utilizam
a metodologia gil Scrum como metodologia de desenvolvimento.
5.1.2
Escopo
Vrias ferramentas apoiam diversos processos de desenvolvimento de software em diversos

ambientes. A ferramenta Riskrum tem como objetivo apoiar, no que diz respeito a gerncia
de riscos, equipes de desenvolvimento de software, gerentes de projetos geis e clientes que
utilizam ou vo utilizar a metodologia Scrum como processo de desenvolvimento de software.
Como mostrado em sees anteriores desse trabalho, existem vrias metodologias de desenvolvimento de software. Cada metodologia dessa pode ser adequada a um determinado ambiente, dependendo de suas caractersticas e das caractersticas demandadas pelo ambiente. Basicamente podemos dividir o ambiente de desenvolvimento de software em: ambiente tradicional
e ambiente gil.
51
CAPTULO 5. DESENVOLVIMENTO DA FERRAMENTA PROPOSTA
52
Figura 5.1: Escopo da ferramenta Riskrum. Fonte: Dados de pesquisa.

A Riskrum deve estar preparada para integrar os stakeholders do projeto. A Figura 5.1
apresenta o escopo da ferramenta Riskrum. Essa figura permite visualizar onde a ferramenta
Riskrum estar inserida. A utilizao da ferramenta Riskrum em outro ambiente no est vetado,
porm, ela dever ser preparada para o ambiente mostrado na Figura 5.1.
Tambm deve-se ficar claro que a proposta da Riskrum apoiar o processo de gesto de
projetos, no que se refere a rea de gesto de riscos. A metodologia Scrum no possui uma cerimnia nem um artefato que cuide explicitamente dos riscos. A importncia de se gerenciar os
riscos foi apresentada em diversos momentos deste trabalho. Assim, a Riskrum busca contribuir
com a metodologia Scrum, permitido-a abarcar as prticas de gerenciamento de riscos.
A seguinte seo apresenta os requisitos que foram levantados a partir dos estudos realizados.
5.1.3
Requisitos funcionais
REQFUN001 - Cadastro e Autenticao de Usurios

A ferramenta Riskrum dever permitir o cadastro de usurios atravs de um formulrio, que o novo usurio dever preencher com seus dados.
Para conseguir autenticar-se na ferramenta Riskrum, cada usurio dever possuir
uma senha e um identificador nico.
53
REQFUN002 - Gesto de Projetos

A ferramenta Riskrum dever permitir o cadastro, escolha, edio, excluso e finalizao de um projeto.
necessrio que a ferramenta Riskrum permita ao usurio cadastrar, editar e excluir
Status do Projeto.
A lista de status do projeto dever ser nica para todos os projetos.
REQFUN003 - Gesto de Participantes
A ferramenta Riskrum dever permitir papis de usurios, sejam cadastrados, editados e excludos.
A lista de papis de usurios dever ser nica para todos os projetos.
A ferramenta Riskrum dever permitir que um ou mais participantes sejam cadastrados em um projeto, atribuindo-lhes papis, dentro de cada projeto.
REQFUN004 - Identificao de Riscos
Para o processo de identificao de riscos a ferramenta Riskrum dever permitir
que o usurio crie e edite um risco, identificando: Nome, Fonte do Risco, Data de
Identificao, Descrio, Causa e Consequncia.
A lista de fontes de riscos dever ser gerenciada pelo usurio, assim, a ferramenta
Riskrum dever permitir o cadastro, edio e excluso de fontes de risco.
REQFUN005 - Gesto de Checklist de Riscos
A ferramenta Riskrum dever permitir a criao, edio e excluso de um checklist
de riscos.
O checklist de riscos dever ser nico para todos os projetos. Todos os usurios dos
projetos podero visualiz-lo.
O checklist de riscos dever poder ser aberto a qualquer momento pelo usurio.
A ferramenta Riskrum dever permitir a edio e excluso dos itens do checklist de
riscos.
REQFUN006 - Anlise de Riscos
A ferramenta Riskrum dever listar todos os riscos identificados e que ainda no
esto analisados para determinado projeto.
No momento que o usurio estiver realizando a anlise dos riscos, a ferramenta
dever exibir as informaes que identificam o risco na mesma tela, para facilitar o
processo de consultar as informaes do risco.
54
Para realizar a anlise de um risco o usurio dever escolher um item nas listas de:
Impacto; Probabilidade; e Tipo de Risco.
A ferramenta Riskrum dever permitir o usurio realizar o cadastro, edio e excluso de listas de: Impacto; Probabilidade; e Tipo de Risco.
REQFUN007 - Planejamento de Respostas aos Riscos
A ferramenta Riskrum dever listar todos os riscos que j possuem uma anlise e
que no possuem ainda um planejamento de respostas para um determinado projeto.
Ao planejar as respostas para um risco, as informaes que identificam o risco devero ser exibidas pela Riskrum, na mesma tela do formulrio de planejamento de
resposta, para facilitar o processo de consultar as informaes do risco.
A ferramenta Riskrum dever permitir o usurio atribuir um dos membros do projeto
como responsvel pela ao de resposta ao risco.
REQFUN008 - Monitoramento e Controle dos Riscos
A ferramenta Riskrum dever listar todos os riscos que j possuem um plano de
respostas e que ainda no foram monitorados, para um determinado projeto.
Ao monitorar um risco a ferramenta Riskrum dever exibir em mesma tela os dados
que identificam aquele risco.
A ferramenta Riskrum dever permitir que o usurio escolha uma Sprint, Status do
Risco e Status da Ao do Risco.
A ferramenta Riskrum dever permitir que o usurio realize o cadastro, edio e
excluso de listas de: Sprints, Status dos Riscos, Status da Ao do Risco.
REQFUN009 - Emisso de Relatrios
A ferramenta dever permitir ao usurio emitir relatrios sobre os riscos.
Os relatrios disponibilizados devero estar em formato: Portable Document Format(PDF).
REQFUN010 - Gesto de Riscos
A ferramenta Riskrum dever permitir que os usurios tenham acesso a todos os
riscos de um determinado projeto em uma mesma tela.
O usurio dever ter a possibilidade de ordenar a exibio dos riscos atravs de
critrios como: Fonte, Impacto, Probabilidade, Responsvel, Status do Risco.
Dever ser possvel o usurio finalizar, excluir ou editar o risco a partir da tela de
listagem de riscos.
A edio do risco dever ser possvel para os seguintes processos: Identificar Riscos,
Analisar Riscos, Planejar Respostas, Monitorar e Controlar os Riscos.
5.1.4
55
Requisitos no funcionais
A ferramenta Riskrum dever tambm atender aos seguintes requisitos no funcionais:

REQNF001 - Na tela inicial da Riskrum, devero ser exibidos as principais opes para
os usurios.
REQNF002 - A ferramenta Riskrum dever sempre manter na tela, a exibio do projeto
corrente, o usurio atualmente logado e a data/hora atual.
REQNF003 - A ferramenta Riskrum dever possuir um menu com as principais opes
para que os usurio tenham facilidade em acess-las.
REQNF004 - A ferramenta Riskrum dever ser acessvel via browser.
REQNF005 - A ferramenta Riskrum dever poder ser acessada por rede interna ou externa.
REQNF006 - A ferramenta Riskrum dever possuir um padro de layout, fazendo com
que os componentes de tela sejam semelhantes em todas as telas.
REQNF007 - A ferramenta Riskrum dever utilizar-se de tabelas de banco de dados para
armazenar opes de campos de lista suspensa, para que no seja preciso alterar o cdigo
fonte caso estas opes mudem com o tempo.
REQNF008 - A ferramenta deve ser acessvel da mesma maneira, pelo menos nos browsers, Firefox 3.5 e Internet Explorer 7.0.
REQNF009 - A ferramenta Riskrum dever disponibilizar dicas nas principais telas. As
dicas devero ser acessveis atravs de um cone que Exibe ou Esconde de acordo com
o clique.
5.1.5
Limites da Ferramenta
LIM001 - Os dados que trafegam entre o browser e o servidor no precisaro ser criptografados.
LIM002 - A Riskrum no ir gerar relatrios que necessitem de dados que no esto na
sua base de dados.
LIM003 - A Riskrum no prover backup e recuperao da base de dados, cabendo ao
administrador da ferramenta essas operaes.
5.1.6
56
Diagrama de caso de uso
Aps levantar os requisitos para a ferramenta Riskrum, as principais funcionalidades da ferramenta para gerenciar riscos em um ambiente gil que utiliza-se Scrum, foram modeladas atravs
do diagrama de casos de uso que mostrado na Figura 5.2.
Figura 5.2: Caso de uso da ferramenta Riskrum. Fonte: Dados de pesquisa.
5.1.7
Modelo da base de dados
A Figura 5.3 apresenta o modelo de dados da ferramenta Riskrum. O modelo foi elaborado
para contemplar todos requisitos levantados para a ferramenta. Atravs do modelo possvel
identificar cada rea da gerncia de riscos e os atributos que foram modelados para atender cada
rea.
5.1.8
Arquitetura
A arquitetura da ferramenta Riskrum, representada pela Figura 5.4 foi desenhada de maneira
simples. Utiliza-se de camadas para diminuir a complexidade de implementao, e o acoplamento, aumentar a sua flexibilidade, facilitar sua manuteno e prover padronizao.
A camada de negcios possui uma interface entre o SGBD e as classes de negcio da
Riskrum. Essa interface facilita a utilizao do banco de dados, pois, encapsula a comunicao
com o banco e implementa mtodos que tornam mais simples a interao entre as classe de
Figura 5.3: Modelo da base dados da ferramenta Riskrum. Fonte: Dados de pesquisa.
57
58
Figura 5.4: Arquitetura da Ferramenta Riskrum. Fonte: Dados de pesquisa.

negcio e o banco de dados. A interface tambm facilita se em algum momento a tecnologia do
banco de dados mudar, pois, seria necessrio apenas alterar a interface e manter todo o cdigo
das camadas acima.
A camada de apresentao possui vrios componentes web, que so facilitadores para se
construir as pginas da Riskrum. Os componentes encapsulam os tipos, estilos e comportamentos dos elementos que aparecem na tela para o usurio. O ganho de utilizar-se desses componentes muito grande, visto que eles trazem padro ao layout da ferramenta. Outo ganho que
se houver a necessidade de alterar o comportamento ou estilo de um componente, essa alterao
refletida em todas a pginas que utiliza-o, evitando muito retrabalho.
Na camada de apresentao tem-se vrias pginas que, utilizando-se dos componentes desenvolvidos, interagem entre si, e atravs de um browser o usurio pode acess-las.
O trabalho de mediar a camada de apresentao com a camada de negcios, de responsabilidade da camada controladora. Essa camada composta por classes controladoras. Cada
classe controladora responsvel pela interao de classes semanticamente semelhantes, tanto
de negcio, quanto de apresentao. Pode haver comunicao entre classes controladoras. A organizao da camada controladora muito importante. Uma classe controladora pode tornar-se
muito complexa se tentar controlar muitas outras classes. Assim, a distribuio de responsabilidades entre as classes controladoras essencial.
5.2
5.2.1
59
Desenvolvimento
Ambiente de Desenvolvimento
Figura 5.5: Ambiente de Desenvolvimento. Fonte: Dados de pesquisa.

A Figura 5.5 apresenta o ambiente de desenvolvimento que foi utilizado. De um lado temse o servidor onde a Riskrum est publicada para o acesso pela web. De um outro lado tem-se
a mquina onde foi desenvolvido a Riskrum. Pode-se notar que as plataformas so diferentes,
uma Unix/Linux e outra Microsoft Windows, o que no impede o perfeito funcionamento da
aplicao desenvolvida, pois, a mesma roda sobre o servidor apache.
Basicamente a nica diferena, alm das plataformas, que a mquina cliente possui a instalao de ferramentas utilizadas no desenvolvimento como o Eclipse PHP e o PHPMyAdmin.
No ambiente importante destacar a utilizao do SVN como tecnologia para o controle
de verso da Riskrum. Atravs da configurao do SVN, que o cdigo da Riskrum pode
ser desenvolvido em etapas na mquina cliente, e publicado tambm por etapas na mquina
servidora.
A utilizao de plataformas geograficamente distribudas e integradas pelo SVN, proporcionou a segurana do que estava sendo desenvolvido, visto que o servidor tambm servia como
um backup para a plataforma cliente.
Atravs do ambiente separado foi possvel submeter a ferramenta a diferentes contextos. De
um lado(servidor) a ferramenta era acessada via http a partir de um browser em qualquer lugar,
atravs da internet. Do outro lado a ferramenta Riskrum era acessada, tambm via browser,
porm localmente.
5.2.2
60
Ferramentas Utilizadas
Para o desenvolvimento da Riskrum algumas ferramentas foram escolhidas para compor o ambiente de desenvolvimento. Para a escolha das ferramentas a serem utilizadas, pesou o conhecimento j adquirido em trabalho anteriores, e o fato das ferramentas possurem a robustez suficiente para o que foi levantado para o desenvolvimento da Riskrum. As seguintes ferramentas
foram utilizadas:
5.2.2.1
MySQL Workbench
O MySQL Workbench uma ferramenta de modelagem e administrao de banco de dados

MySQL (MYSQL WORKBENCH, 2010). Para esse trabalho foi utilizada a verso 5.2.31, disponvel em http://wb.mysql.com.
Com a MySql Workbench foi possvel criar o modelo da base de dados, gerar os scripts de
criao da base de dados, e aplic-los ao MySql.
5.2.2.2
Apache
O Apache um servidor Web muito utilizado, que possui suporte a diversos recursos nativos.
Quando instalado, e devidamente configurado, funciona como um servidor onde seus recursos
podem ser disponibilizados em rede externa ou interna. Para o desenvolvimento desse trabalho
foi utilizado a verso 2.2.17 que pode ser encontrada em: http://www.apache.org.
5.2.2.3
PHP
PHP uma linguagem de programao de computadores interpretada, livre e muito utilizada

para gerar contedo dinmico na World Wide Web, tendo como principais caractersticas a velocidade e robustez, ser estruturado e orientado a objetos, alm de sua portabilidade. A linguagem surgiu por volta de 1994, como um pacote de programas CGI criados por Rasmus Lerdorf.
Para o trabalho foi utilizado a verso 5.3.5, disponvel em www.php.net.
5.2.2.4
Eclipse for PHP Developers
Essa uma personalizao para PHP da IDE Eclipse, que j uma IDE bem conceituada no
mercado de desenvolvimento. Este um projeto que abrange vrios componentes de desenvolvimento necessrios facilitar a extensibilidade do PHP. Alm disso, essa IDE aproveita ferramentas j existentes para o desenvolvimento, e inclui recursos especiais para o PHP.
61
No trabalho foi utilizado a verso PDT 2.1-SR2, disponvel em: www.eclipse.org/pdt/. Com
essa IDE foi possvel utilizar o Subversion j integrado com o projeto de desenvolvimento da
Riskrum.
5.2.2.5
Subversion
Subversion, ou SVN, um sistema de controle de verso open-source. Ele tem como funo gerenciar arquivos e diretrios cronologicamente, gravando cada modificao em um repositrio.
Permitindo a recuperao, analise e comparao entre diferentes verses dos arquivos.
5.2.2.6
MySQL
O MySQL um sistema de gerenciamento de banco de dados (SGBD), que utiliza a linguagem SQL (Linguagem de Consulta Estruturada, do ingls Structured Query Language) como
interface. O banco de dados MySQL tornou-se a base de dados de cdigo aberto mais popular
do mundo, por causa de seu alto desempenho, alta confiabilidade e facilidade de uso(MYSQL,
2011). A verso utilizada do MySQl foi a 5.5.8, disponvel em http://www.mysql.com.
5.2.2.7
PHPMyAdmin
O phpMyAdmin uma ferramenta de software livre escrito em PHP destinado a lidar com a
administrao do MySQL sobre o World Wide Web. O phpMyAdmin suporta uma ampla gama
de operaes com o MySQL. As operaes mais utilizadas so suportados pela interface do
utilizador (base de dados de gesto, tabelas, campos, relaes, ndices, usurios, permisses,
etc), enquanto tem a capacidade de executar diretamente qualquer comando SQL. A verso
utilizada nesse trabalho foi a 3.3.9 disponvel em http://www.phpmyadmin.net.
5.2.2.8
IReport
O iReport um software livre, para o designer de relatrios open source, para o JasperReports.
Com ele possvel criar layouts sofisticados com grficos, imagens, sub-relatrios, tabelas de
referncia cruzada e vrios outros recursos. O iReport pode se integrar com diversos SGBDs. A
verso utilizada no trabalho foi a 3.0 disponvel em http://jasperforge.org/projects/ireport.
No trabalho foi necessrio utilizar as classes FPDF e PHPJasperXML para criar uma interface entre o relatrio gerado pelo iReport e a aplicao Riskrum. Com essa interface foi possvel
criar modelos de relatrios no iReport e execut-los pela aplicao em PHP.
5.2.3
Validao e Implantao
5.2.3.1
A ferramenta Riskrum
62
Nesta subseo encontramos as principais telas da ferramenta Riskrum, responsveis por permitir que a mesma seja utilizada para o gerenciamento de riscos na metodologia Scrum.
A Figura 5.6 traz a tela de autenticao da Riskrum. Essa tela possibilita que os usurios
possam se autenticar e entrar na ferramenta para gerenciar os riscos. A partir dela tambm
possvel realizar o cadastro de novos usurios. Assim, essa tela atende o requisito REQFUN001
definido na seo Especificao. A tela inicial da Riskrum apresentada pela Figura 5.7, e traz
Figura 5.6: Tela de autenticao da Riskrum. Fonte: Dados de pesquisa.

o ponto de partida de suas principais funcionalidades, atendendo o requisito REQNF001. Nessa
tela, o usurio tem a possibilidade de acessar as funcionalidades da ferramenta atravs de cones.
A maneira como os cones esto dispostos, ajuda o usurio a seguir um fluxo considerado como
o caminho principal para se gerenciar os riscos, passando pela gesto de projetos, identificao
e anlise de riscos, planejamento de respostas, monitoramento e controle de riscos. O usurio
tem tambm a possibilidade de acessar diretamente as telas de Relatrios, Riscos e Checklist,
apresentadas nessa seo respectivamente pelas Figuras 5.13, 5.14 e 5.11. Dessa tela o usurio
tambm consegue desautenticar e sair da ferramenta.
Por essa tela podemos ver como ficou o Layout (desenho grfico e organizao dos componentes na ferramenta), e notar que possui um padro em todas as suas telas, atendendo ao
requisito REQNF006. A Riskrum exibe constantemente, atravs de uma tabela (canto superior
direito), o projeto atual, o usurio autenticado, o papel do usurio dentro do projeto, a data e hora
atual. Essas informaes ajudam os usurios a se localizarem dentro da ferramenta, sabendo por
63
exemplo exatamente qual projeto est sendo gerenciado, atendendo ao requisito REQNF002. A
Riskrum permite que o usurio sempre possa acessar as principais funcionalidades atravs do
menu superior (a baixo da logo) atendendo ao requisito REQNF003.
Ainda pela Figura 5.7 possvel identificar que a Riskrum atende ao requisito REQNF009,
atravs do cone de dica, representado pela figura com uma interrogao (lado direito, abaixo
do menu).
Figura 5.7: Tela inicial da Riskrum. Fonte: Dados de pesquisa.
Figura 5.8: Tela de gesto de Projetos na Riskrum. Fonte: Dados de pesquisa.

A Figura 5.8 apresenta a lista de projetos que esto cadastrados na Riskrum. Atravs da lista
de projetos possvel realizar a escolha, edio, excluso e finalizao de um projeto, atendendo
64
Figura 5.9: Tela de edio de Projetos na Riskrum. Fonte: Dados de pesquisa.

ao requisito REQFUN002. Por essa tela, tambm possvel acessar a tela de edio de projetos,
apresentada pela Figura 5.9.
Pela Figura 5.9, pode-se ver como a Riskrum atende ao requisito REQFUN003. Por essa
tela de edio de projetos possvel cadastrar um ou mais participantes em um projeto, atribuindolhes papis previamente cadastrados.
A Figura 5.10 apresenta como a Riskrum permite que seja realizado a identificao de
riscos, atendendo ao requisito REQFUN004. Essa tela utiliza uma lista suspensa de tipos de
riscos que so cadastrados em outra tela, no apresentada no trabalho.
A Figura 5.11 atende ao requisito REQFUN005, permitindo que todos os usurios da Riskrum possam ter acesso um checklist que ajuda a identificar riscos. O checklist pode ser aberto
e editado a qualquer momento.
A Figura 5.12 exibe os riscos que ainda esto sem planejamento de respostas. A tabela com
os riscos no planejados ajuda aos usurios da Riskrum identificar rapidamente esses riscos, e
os permite acess-los para planejar respostas aos riscos. Telas semelhantes a essa so utilizadas
para listar riscos que ainda no foram analisados e monitorados.
A Figura 5.13 apresenta a tela de emisso de relatrios da ferramenta Riskrum. Atravs
dessa tela a Riskrum oferece ao usurio vrias possibilidades de fazer consultas sobre os riscos
do projeto. Essa tela atende ao requisito REQFUN009.
A Figura 5.14 apresenta a tela onde todos os Riscos de um projeto so listados. Essa tela
permite que o usurio priorize os riscos por diversas formas, ordenando-os por diversos critrios. Pela figura possvel observar que as colunas finais tabela so exatamente os cones das
65
Figura 5.10: Tela de identificao de riscos da Riskrum. Fonte: Dados de pesquisa.
Figura 5.11: Tela de checklist de riscos da Riskrum. Fonte: Dados de pesquisa.

aes que levam o usurio devida tela de gerenciamento de riscos. A partir de um risco listado
nessa tela, possvel editar sua identificao, criar ou editar a anlise, planejamento de resposta
e monitoramento. Tambm possvel finalizar o gerenciamento de cada risco. A finalizao de
riscos um ponto muito importante, pois, nesse momento as lies apreendidas so registradas
66
Figura 5.12: Tela com lista de riscos sem planejamento de respostas na Riskrum. Fonte: Dados
de pesquisa.
Figura 5.13: Tela de emisso de relatrios. Fonte: Dados de pesquisa.

na ferramenta Riskrum, e posteriormente, serve como base histrica para outros projetos.
5.2.3.2
Testes
Apesar da Riskrum no ter sido submetida a testes em um ambiente real de gerenciamento de

projetos, foram realizados testes utilizando-se simulaes.
Depois que a ferramenta Riskrum foi desenvolvida, a mesma foi submetida a testes de caixa
preta, nos quais, cada tela foi testada de acordo com os comportamentos que eram esperados
delas. Tambm foram realizados testes de caixa branca, nos quais, cada parte implementada da
ferramenta foi investigada para garantir que os dados estavam sendo tratados como deviam, e
garantir que os mesmo estavam sendo registrados e recuperados da base de dados de maneira
correta.
67
Figura 5.14: Tela de gesto de riscos da Riskrum. Fonte: Dados de pesquisa.

Aps a realizao dos testes e das correes dos erros encontrados, o servidor utilizado no
desenvolvimento foi atualizado com a ltima verso da ferramenta. Posteriormente, o servidor
foi configurado para direcionar o domnio www.riskrum.com.br para a raiz da aplicao. O
domnio para a aplicao foi adquirido junto ao orgo Registro.Br, responsvel pela distribuio
de domnios aqui no Brasil.
Depois que a ferramenta j se encontrava publicada na internet, a mesma foi submetida
a testes automticos de acessibilidade. Para esses testes, utilizou-se o avaliador automtico de
acessibilidade DaSilva, disponvel em http://www.dasilva.org.br/. O avaliador automtico ajudou a encontrar erros de acessibilidade na ferramenta Riskrum. Atravs dos erros apontados
pelos testes automatizados, foi possvel atacar e corrigir os principais erros, tornando a Riskrum uma ferramenta mais acessvel e mais aderente aos padres web recomendados.
Captulo 6
Concluso
Sabendo que planejar e executar projetos para que se atinjam os resultados esperados uma
atividade complexa, principalmente quando trata-se de projetos de software, e ainda que o mercado brasileiro de desenvolvimento de software esteja aquecido, mais competitivo, exigente e
com menos espao para fracassos, faz-se necessrio estudar e aplicar as prticas de gerenciamento de riscos em projetos de software, pois elas podem ajudar a diminuir o impacto de riscos
negativos e potencializar o impacto de riscos positivos.
A Scrum uma metodologia de desenvolvimento de software muito aceita e adequada para
guiar o desenvolvimento de software em ambientes incertos, complexos e cheios de mudanas,
porm necessrio reconhecer que ela no atende s prticas de gerenciamento de riscos, que
so importantssimas para que projetos sejam executados com sucesso. Portanto, esse trabalho
buscou propor e implementar uma ferramenta que d suporte ao gerenciamento de riscos para
equipes e clientes que tenha ou que tero a Scrum como metodologia de desenvolvimento.
Para conseguir atingir o objetivo desse trabalho foi necessrio entender os processos de
desenvolvimento de software, e de gesto de projetos, mais especificamente o universo do desenvolvimento gil e s prticas de gesto de riscos. Atravs do estudo realizado foi possvel
especificar uma ferramenta que pudesse permitir o gerenciamento de riscos em um ambiente
gil que adote a Scrum como metodologia de desenvolvimento.
Diante das caractersticas da Scrum e dos princpios de processos geis, a ferramenta Riskrum foi planejada e construda de forma a no tornar burocrtico e consequentemente lento a
gesto de riscos nos projetos. A Riskrum possui uma forma muito clara e objetiva de gerenciar
riscos, onde cada equipe pode personalizar vrios atributos dos riscos a cada fase do gerenciamento. Isso permitido atravs das vrias listas suspensas que so de controle de quem utiliza
a ferramenta.
Apesar da Riskrum permitir que vrios atributos sejam personalizados para as fases do
gerenciamento de riscos, este processo foi muito bem delineado pela ferramenta, passando pelas
68
CAPTULO 6. CONCLUSO
69
fases de identificao, anlise, planejamento de respostas, monitoramento, controle e finalizao

de riscos.
A ferramenta desenvolvida permite que as equipes que utilizam a Scrum, possam comear
a praticar o gerenciamento de riscos aos poucos, e com o passar do tempo e ganho de experincia, irem tornando-se mais eficientes com esse processo. Atravs de funcionalidades como o
checklist de riscos, e das listas suspensas que so utilizadas, os membros da equipe so capazes
de identificar e lidar com os riscos de forma natural.
As equipes podero se beneficiar da base histrica que vai sendo criada a cada projeto. Os
relatrios oferecidos pela Riskrum, permitem consultar dados histricos, como lies apreendidas dos riscos e projetos. Alm disso, possvel consultar quais so os riscos sem planejamento
de respostas ou sem anlises, riscos por responsveis, entre outras informaes que podem ser
de grande serventia para os participantes de cada projeto.
A Riskrum baseia-se em melhores prticas para o gerenciamento de riscos, e tambm s
caractersticas da Scrum. A sua existncia, por si s, no garante que o gerenciamento de riscos
seja adequadamente praticado dentro de um processo que utilize a Scrum. Por ser uma ferramenta de apoio, necessrio que toda a equipe conhea e pratique atravs dela, as prticas de
gerenciamento de riscos.
O objetivo desejado no trabalho foi alcanado com sucesso, pois, a ferramenta Riskrum,
atravs das funcionalidades desenvolvidas, capaz de apoiar o processo de gerenciamento de
riscos em ambientes que utilizam a Scrum. Atravs da Riskrum, a metodologia Scrum passa a
se adequar ao gerenciamento de riscos sem que a mesma perca sua agilidade.
6.1
Trabalhos Futuros
O presente trabalho buscou propor e implementar uma ferramenta que pudesse apoiar o gerenciamento de riscos em projetos que utilizem a metodologia Scrum, porm existem alguns pontos
que devem ser estudados e trabalhados futuramente. So eles:
Realizar um estudo para tornar a Riskrum uma ferramenta aderente ao gerenciamento de
riscos sugerido pelo PMBOK e outros modelos, como o CMMI e MPS.br;
Realizar uma pesquisa com profissionais experientes em processos geis, focando as prticas de riscos, a fim de mapear os resultados com a ferramenta Riskrum e sugerir melhorias.
Realizar um estudo de caso em um ambiente organizacional utilizando a ferramenta Riskrum, para levantar pontos falhos e propor melhorias;
CAPTULO 6. CONCLUSO
70
Submeter a ferramenta Riskrum a um ambiente real de gerenciamento de projeto de software e analisar o seu uso.
Referncias Bibliogrficas
ABES, A. B. das Empresas de S. Mercado Brasileiro de Software: Panorama e Tendncias.
So Paulo - SP, Junho 2010. Ed 1. Disponvel em: <http://www.abes.org.br>.
ABRAN, A.; MOORE, J. W. Guide to the Software Engineering Body of Knowledge
(SWEBOK). 1. ed. Los Alamitos, California: IEEE Computer Society, 2004. 204 p. Verso
HTML. Disponvel em: <http://www.swebok.org/>.
ALLIANCE, A. Manifesto for agile software development. In: . [s.n.], 2001. Disponvel em:
<http://agilemanifesto.org/>.
AMBLER, S. W. Agile Adoption Survey 2008. [S.l.], 2008. Disponvel em:
<http://www.ambysoft.com/surveys/>.
ARAUJO, L. B. P. de. Estudo comparativo da compatibilidade entre as melhores prticas do
pmi e scrum. In: . [S.l.]: Faculdade de Informtica e Administrao Paulista. So Paulo,
2009. p. 89.
BANKI, A. L.; TANAKA, S. A. Metodologias geis: Uma viso prtica. Engenharia de
Software Magazine, Ano 1, 4 Edio, p. 8, 2008.
BOEHM, B. A view of 20th and 21st century software engineering. In: In Proc. ICSE06. [S.l.:
s.n.], 2006. p. 1229.
BOEHM, B. W. Software risk management: Principles and practices. p. 3241, 1991.
DAIBERT, M. S. Monitoramento de riscos em projetos de software: Uma abordagem baseada
em dinmica de sistemas. In: . Viosa - Minas Gerais: Universidade Federal de Viosa - UFV,
2008. p. 21.
DIAS, M. V. B.; SOLER, A. M. Agile project management - um novo enfoque para o
gerenciamento de projetos de desenvolvimento de sistemas de tecnologia de informao.
Mundo PM, n. 4, p. 6873, 2005.
DIJKSTRA, E. W. The humble programmer. Communications of the ACM, v. 15, p. 8, October
1972. Disponvel em: <http://doi.acm.org/10.1145/355604.361591>.
71
REFERNCIAS BIBLIOGRFICAS
72
FONSECA, I.; CAMPOS, A. Por que scrum? Engenharia de Software Magazine, Ano 1, 4
Edio, p. 3035, 2008.
FRANCO, E. Aplicando a gesto gil de projetos para o desenvolvimento de novos produtos
na indstria de software. XXVI Encontro Nacional de Engenharia de Produo - ENEGEP,
p. 9, Outubro 2006. Fortaleza, CE, Brasil.
GUIMARES, Y. R. et al. Mapeando o scrum em relao ao cmmi nveis 2 e 3. III EPAC Encontro Paranaense de Computao ISSN:1981-8653, p. 10, 2009.
GUSMO, C. Tendncias na rea de gesto de riscos em ambientes de desenvolvimento de
software. Engenharia de Software Magazine, Ano 1, 4 Edio, p. 3642, 2008.
GUSMO, C. M. G. de; MOURA, H. P. de. Gerncia de risco em processos de qualidade de
software: uma anlise comparativa. III Simpsio Brasileiro de Qualidade de Software, p. 14,
2004.
HILLSON, D. Gerenciamento de riscos em projeto - melhores prticas e desenvolvimentos
futuros. Mundo PM, v. 1, n. Ed 4, p. 3842, Agosto-Setembro 2005.
INTERNATIONAL, I. T. S. G. Chaos summary 2009. the 10 the chaos. In: . Boston, MA.:
[s.n.], 2009. p. 4. Disponvel em: <www.standishgroup.com>.
LOPES, P. L. S. Gerenciamento de projetos integrado - gpi: Uma integrao entre mtodos
clssicos e mtodos geis para gerenciamento de projetos de software. In: PELOTAS, U. F. de
(Ed.). Pelotas: [s.n.], 2008. p. 135.
MACHADO, M.; MEDINA, S. G. Scrum mtodo gil: uma mudana cultural na gesto de
projetos de desenvolvimento de software. Revista Cientfica Intracincia, v. 1, p. 5871, 2009.
MARAL, A. S. C. et al. Mapping cmmi project management process areas to scrum practices.
SEW 2007, 31st Annual Software Engineering Workshop, Loyola College, Baltimore, MD,
USA, p. 9, Maro 2007. Disponvel em: <http://www.cesar.org.br/mapping-cmmi-projectmanagement-process-areas-to-scrum-practices/>.
NASCIMENTO, V. M. Gerenciamento de risco em projetos: Como transformar riscos em
vantagem competitiva. In: . [S.l.]: Universidade Veiga de Almeida. Rio de Janeiro, 2003. p. 97.
NETO, E. I. Scrumming - ferramenta educacional para ensino de prticas do scrum. In:
PONTIFCIA UNIVERSIDADE CATLICA DO RIO GRANDE DO SUL. Porto Alegre - RS,
2008. p. 80.
NETO, O. N. de S. Anlise comparativa das metodologias de desenvolvimento de softwares
tradicionais e geis. In: . Belm - PA: Universidade da Amaznia., 2004.
73
NETO, V. B. de S. Aplicao de um processo gil com foco em gesto de riscos. In: . Recife:
Departamento de Sistemas e Computao - Universidade de Pernambuco, 2008. p. 62.
PAULA, W. de P. F. Engenharia de Software: Fundamentos, Mtodos e Padres. 3. ed. Rio de
Janeiro - RJ: [s.n.], 2009.
PEREIRA, P.; TORREO, P.; MARAL, A. S. Entendendo scrum para gerenciar projetos de
forma gil. Mundo PM, p. 11, Abril-Maio 2007.
PMI, P. M. I. I. Um Guia do Conhecimento Em Gerenciamento de Projetos (Guia PMBOK).
4. ed. Newtown Square, Pennsylvania, EUA: 14 Campus Boulevard, 2008. 336 p.
PRESSMAN, R. S. Engenharia de Software. [S.l.: s.n.], 2007.
RIBEIRO, A. L. D.; ARAKAKI, R. Gerenciamento de projetos tradicional x gerenciamento
de projetos gil: Uma anlise comparativa. 3rd CONTECSI - International Conference on
Information Systems and Technology Management, p. 10, 2006.
RIBEIRO, L.; GUSMO, C. Definio de um processo gil de gesto de riscos em ambientes
de mltiplos projetos. Hfen (Uruguaiana) - XIII Simpsio de Informtica, v. 32, p. 6774, II
Semestre 2008.
ROCHA, P. C.; BELCHIOR, A. D. Mapeamento do gerenciamento de riscos no pmbok,
cmmi-sw e rup. VI Simpsio Internacional de Melhoria de Processos de Software, p. 12, So
Paulo, SP 2004. Disponvel em: <www.simpros.com.br>.
SANTOS, R. F. Scrum Experience. [S.l.], 2009.
SCHWABER, K. Guia do scrum. In: ACRUMALIANCE. [S.l.]: Scrum Aliance, 2009. p. 22.
SILVA, F. G.; HOENTSCH, S. C. P.; SILVA, L. Uma anlise das metodologias geis fdd e
scrum sob a perspectiva do modelo de qualidade mps.br. Scientia Plena, v. 5, n. 12, p. 13,
Dezembro 2009.
SIQUEIRA, H. B. A. Mapeamento das prticas de scrum nas reas de processo do cmmi e
uma proposta para sua aderncia. In: . [S.l.]: Centro de Informtica - Universidade Federal de
Pernambuco, 2007. p. 57.
SOARES, M. dos S. Comparao entre metodologias geis e tradicionais para o
desenvolvimento de software. INFOCOMP - Revista de Cincia da Computao - UFLA, v. 3,
p. 813, novembro 2004.
SOMMERVILLE, I. Engenharia de Software. 8. ed. [S.l.]: Pearson - Addison Wesley, 2007.
TAKEUCHI, H.; NONAKA, I. The new new product development game. Harvard Bussiness
Review, n. Reprint 86116, p. 12, January-February 1986.
74
TEIXEIRA, M. Uma anlise do scrum sob a perspectiva do mpsbr. In: . [S.l.]: Universidade de
Passo Fundo. Passo Fundo, 2007. p. 158.

Risk Rum

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Risk Rum

Uploaded by

Copyright:

Available Formats

UNIVERSIDADE FEDERAL DOS VALES DO JEQUITINHONHA E MUCURI

FACULDADE DE CINCIAS EXATAS E TECNOLGICAS

RISKRUM: uma ferramenta para gerenciamento de riscos na metodologia gil de

Srgio Oliveira Godinho

UNIVERSIDADE FEDERAL DOS VALES DO JEQUITINHONHA E MUCURI

RISKRUM: uma ferramenta para gerenciamento de riscos na metodologia gil de

Srgio Oliveira Godinho

Monografia apresentada como requisito parcial

RISKRUM: uma ferramenta para gerenciamento de riscos na metodologia gil de

Srgio Oliveira Godinho

Monografia apresentada como requisito parcial

APROVADO em ..... / ..... /............

Diagrama de atividades do trabalho. . . . . . . . . . . . . . . . . . . . . . . .

Metodologia Cascata. Fonte: (PAULA, 2009) . . . . . . . . . . . . . . . . . .

Metodologia Cascata com realimentao. Fonte: (PAULA, 2009) . . . . . . . .

Prototipao. Fonte: (PAULA, 2009) . . . . . . . . . . . . . . . . . . . . . . .

Metodologia Espiral. Fonte: (PAULA, 2009) . . . . . . . . . . . . . . . . . . .

Metodologia Entrega Evolutiva. Fonte: (PAULA, 2009) . . . . . . . . . . . . .

Scrum - uma jogada do jogo Rugby . . . . . . . . . . . . . . . . . . . . . . .

Metodologia Scrum. Fonte: (SANTOS, 2009) . . . . . . . . . . . . . . . . . .

Burndown da Sprint (SANTOS, 2009) . . . . . . . . . . . . . . . . . . . . . .

Formato de Processos. Fonte: Araujo (2009) . . . . . . . . . . . . . . . . . . .

3.10 Grupo de Processos de Gerenciamento de Projetos. Fonte: Adaptado (PMI, 2008) 31

3.13 Relacionamento entre clientes e a equipe de desenvolvimento. Fonte: Adaptado

3.15 Software Risk Management. Fonte Boehm (1991) . . . . . . . . . . . . . . . .

Cobertura da Scrum em relao rea de Gerenciamento de Riscos do CMMI.

Escopo da ferramenta Riskrum. Fonte: Dados de pesquisa. . . . . . . . . . . .

Caso de uso da ferramenta Riskrum. Fonte: Dados de pesquisa. . . . . . . . . .

Modelo da base dados da ferramenta Riskrum. Fonte: Dados de pesquisa. . . .

Arquitetura da Ferramenta Riskrum. Fonte: Dados de pesquisa. . . . . . . . . .

Ambiente de Desenvolvimento. Fonte: Dados de pesquisa. . . . . . . . . . . .

Tela de autenticao da Riskrum. Fonte: Dados de pesquisa. . . . . . . . . . .

Tela inicial da Riskrum. Fonte: Dados de pesquisa. . . . . . . . . . . . . . . .

Tela de gesto de Projetos na Riskrum. Fonte: Dados de pesquisa. . . . . . . .

Tela de edio de Projetos na Riskrum. Fonte: Dados de pesquisa. . . . . . . .

5.10 Tela de identificao de riscos da Riskrum. Fonte: Dados de pesquisa. . . . . .

5.11 Tela de checklist de riscos da Riskrum. Fonte: Dados de pesquisa. . . . . . . .

5.13 Tela de emisso de relatrios. Fonte: Dados de pesquisa. . . . . . . . . . . . .

5.14 Tela de gesto de riscos da Riskrum. Fonte: Dados de pesquisa. . . . . . . . . .

Mtodos geis x mtodos dirigidos por planos. (PAULA, 2009) . . . . . . . . .

Mapeamento de grupos de processos de gerenciamento de projetos e reas de

Aderncia do Scrum ao processo de Gerncia de Riscos do MPS.BR. Fonte:

Metodologias de Desenvolvimento de Software . . . . . . . . . . . . . . . . .

Cascata com realimentao . . . . . . . . . . . . . . . . . .

Reunio de Planejamento da Release . . . . . . . . . . . . .

Reunio de Planejamento da Sprint . . . . . . . . . . . . . .

3.2.1.10 Reviso da Sprint . . . . . . . . . . . . . . . . . . . . . . .

3.2.1.11 Retrospectiva da Sprint . . . . . . . . . . . . . . . . . . . .

3.2.1.13 Backlog do Produto . . . . . . . . . . . . . . . . . . . . . .

3.2.1.14 Burndown da Release . . . . . . . . . . . . . . . . . . . . .

3.2.1.15 Backlog da Sprint . . . . . . . . . . . . . . . . . . . . . . .

3.2.1.16 Burndown da Sprint . . . . . . . . . . . . . . . . . . . . . .

Gerenciamento de projetos com o PMBOK . . . . . . . . . . . . . .

Gerenciamento de Projetos geis . . . . . . . . . . . . . . . . . . . .

Gerenciamento de Riscos pelo PMBOK . . . . . . . . . . . . . . . .

Planejar o gerenciamento dos riscos . . . . . . . . . . . . . .

Anlise qualitativa dos riscos . . . . . . . . . . . . . . . . .

Anlise quantitativa dos risos . . . . . . . . . . . . . . . . .

Planejar as respostas aos riscos . . . . . . . . . . . . . . . .

Monitorar e controlar os riscos . . . . . . . . . . . . . . . .

Desenvolvimento da Ferramenta Proposta

Diagrama de caso de uso . . . . . . . . . . . . . . . . . . . . . . . . .

Modelo da base de dados . . . . . . . . . . . . . . . . . . . . . . . . .

Eclipse for PHP Developers . . . . . . . . . . . . . . . . . .