UNIVERSIDADE DO VALE DO ITAJAÍ
MÔNICA PIERINI DE MATOS
RISCOS EM PROJETOS DE SOFTWARE: UMA ANÁLISE
COMPARATIVA DE MODELOS DE PROCESSOS DE
REFERÊNCIA E PROPOSTA DE UM MODELO DE PRÁTICA
São José
2006
MÔNICA PIERINI DE MATOS
RISCOS EM PROJETOS DE SOFTWARE: UMA ANÁLISE
COMPARATIVA DE MODELOS DE PROCESSOS DE
REFERÊNCIA E PROPOSTA DE UM MODELO DE PRÁTICA
Trabalho de Conclusão de Curso apresentado
como requisito parcial para obtenção do título de
Bacharel em Ciência da Computação na
Universidade do Vale do Itajaí, Centro de
Educação São José.
Orientador: Prof. M. Eng. José Francisco Salm
Junior
São José
2006
MÔNICA PIERINI DE MATOS
RISCOS EM PROJETOS DE SOFTWARE: UMA ANÁLISE
COMPARATIVA DE MODELOS DE PROCESSOS DE
REFERÊNCIA E PROPOSTA DE UM MODELO DE PRÁTICA
Este trabalho de Conclusão de Curso foi julgado adequado para obtenção do título de Bacharel
em Ciência da Computação e aprovado pelo Curso de Ciência da Computação, da Universidade
do Vale do Itajaí (SC), Centro de Educação São José.
São José, 15 de dezembro de 2006.
Apresentada à Banca Examinadora formada pelos professores:
Prof. José Francisco Salm Junior, M. Eng.
UNIVALI – Centro de Educação São José
Professor orientador
Prof. Alecir Pedro da Cunha, membro da banca examinadora, Esp.
Prof. Adhemar Maria do Valle Filho, membro da banca examinadora, Dr.
DEDICATÓRIA
Dedico em especial a minha mãe, Lúcia que sempre serviu como exemplo de dedicação para toda
a família.
Dedico aos meus irmãos, Gabriel e João.
Dedico in memoriam ao meu pai, João.
Dedico ao meu querido esposo Sandro pelo amor correspondido e por fazer-me feliz.
A Deus que me proporcionou principalmente saúde.
AGRADECIMENTOS
A Deus pela vida, saúde, paz, proteção, família e pelos bons amigos.
Agradeço minha mãe, Lúcia Pierini de Matos, ao meu esposo amigo Sandro José Longen, e aos
meus irmãos, Gabriel Pierini de Matos e João Pierini de Matos pela compreensão, paciência,
amor e apoio que tornaram esta trajetória possível.
Aos demais familiares que cada um com pequenos gestos também têm participado na elaboração
deste trabalho.
Ao professor Paulo Henrique de Souza Bermejo pela amizade, acompanhamento e incentivo.
Ao professor José Francisco Salm Junior pela amizade, apoio e orientação.
Aos professores que acompanharam esta trajetória e a todos os outros amigos que conquistei.
Não posso deixar de agradecer àqueles que me acompanharam desde o início do curso.
RESUMO
A gerência de projetos de software vem recebendo maior atenção por parte das organizações,
mostrando um crescimento daquelas que aprovam a gestão focada em projetos, e que vêm se
tornando maiores e mais complexos. Uma das áreas que têm demandado atenção e ganhado muita
importância, especialmente em projetos de desenvolvimento de software, muitas vezes por
motivos relacionados à complexidade e a fatores tecnológicos, é a gerência de riscos. Modelos e
processos têm sido desenvolvidos para estabelecer as atividades envolvidas na gerência de riscos
em projetos. Como exemplos desses tipos de modelos e processos estão a Integração do Modelo
de Maturidade e de Capacidade (CMMI) para Desenvolvimento, a Melhoria de Processo do
Software Brasileiro (MPS-BR), a International Organization for Standardization (NBR ISO/IEC
12207), o TenStep Processo de Gerenciamento de Projetos® e o AS/NZS 4360:2004 Australian
Standard for Risk Management. Atualmente os projetos de desenvolvimento de software, em
geral, apresentam atrasos de cronograma, custos além do planejado e não alcançam todas as
funcionalidades planejadas. Esses problemas podem ser minimizados pelo contínuo
gerenciamento dos riscos do projeto. Para contribuir com essas atividades relacionadas a riscos,
propõe-se realizar uma análise comparativa de modelos de processos segmentados no mercado e
que são relacionados às áreas de riscos em projetos de software, como CMMI para
desenvolvimento (CMMI for development), MPS-BR, NBR ISO/IEC 12207, TenStep e AS/NZS
4360:2004. Essa análise objetiva permitir a identificação de um conjunto de práticas que estejam
definidas nesses processos e possam ser citadas a fim de incorporar um modelo específico para
software. Tal modelo visa agregar as práticas encontradas, as contribuições das áreas de
engenharia de software e o gerenciamento de projetos, esta última tomando por base as práticas
descritas no Guia do Conjunto de Conhecimentos em Gerenciamento de Projeto (Project
Management Body of Knowledge - PMBOK®), criado e mantido pelo Instituto de Gerenciamento
de Projeto (Project Management Institute – PMI®). Para avaliação do modelo proposto, propõese aplica-lo nas atividades de identificação e gerência de riscos em um projeto de software.
Espera-se que o fruto de estudo e aplicação deste trabalho venha a oferecer condições para o
alcance de melhorias nas atividades relacionadas ao gerenciamento de riscos em projetos de
software.
Palavras-chave: Gerência de riscos; Engenharia de software; Gerenciamento de projeto; Modelo
de Referência para melhoria do Processo de Software.
ABSTRACT
The project management of software is attracting major attention by organizations showing that
those organizations are growing which adapt management focused in projects and for this
reason turn themselves into even bigger and more complex ones. One field which attracted
attention and gained much importance, especially in projects of software development is risk
management which is often related to complexity and technological factors.Models and processes
have been developed in order to support activities involved in risk management of projects.
Examples for this kind of models and processes are: Capability Maturity Model Integration for
development (CMMI), Improvement of Brazilian Software Processes (MPS-BR), International
Organization for Standardization (NBR ISO/IEC 12207), TenStep Process of Management of
Projects® and AS/NZS 4360:2004 Australian Standard for Risk Management Today projects for
software development in general present delays in chronograms, costs above the planned and not
fulfilled planned functionalities. These problems can be minimized by the continuation of project
risk management.Aiming for a contribution to activities related to risks a comparative analysis of
process models is proposed divided in markets and related to risk areas in software projects like:
CMMI for development, MPS-BR, NBR ISO/IEC 12207, TenStep e AS/NZS 4360:2004.This
objective analysis allows the identification of a set of practices which may be defined in these
processes and can be used in the end to corporate a specific model for software.Such a model
aims to aggregate found practices, the contributions of the areas of software engineering and
project management, this last one taking for base practical the described ones in the Guide of the
Set of Knowledge in Management of Project (Project Management Body of Knowledge PMBOK®), created and kept for the Institute of Management of Project (Project Management
Institute - PMI®). For the evaluation of the proposed model its application for the identification
of activities and risk management in one software project is realized. The outcome and the
application of this study may offer conditions for improvements in the activities related to risk
management in software projects.
Keywords: Risk Management; Software Engineering; Project Managemen, Process Improvement
Reference Model.
LISTA DE SIGLAS
ANSI
Instituto Nacional Americano de Padronização (American National Standartd
Institute)
ASC
Corporação Americana de Sistemas (American System Corporation)
CMM
Modelo de Maturidade e de Capacidade (Capability Maturity Model)
CMMI
Integração do Modelo de Maturidade e de Capacidade (Capability Maturity Model
Integration)
CTQs
Crítico à Qualidade (Critical to Quality)
DMAIC
Definição, Mensuração, Análise, Melhoria e Controle (Define, Measure, Analyse,
Improve e Control)
DSDM
Método dinâmico de desenvolvimento de sistemas (Dynamic Systems Development
Method)
FDD
Desenvolvimento Dirigido por Funcionalidade (Feature-Driven Development)
GG
Objetivos Genéricos (Generic Goals)
GRI
Gerenciamento de riscos
HTML
Linguagem de Formatação de Hipertexto (HyperText Markup Language)
ICE
Engenharia de Computação Integrada (Integrated Computer Engineering)
IEC
Comissão eletro técnica internacional (International Electrotechnical Commission)
ISO
Organização
Internacional
de
Padrões
(International
Organization
for
Standardization)
KPIs
Indicadores chaves de desempenho (Key Performance Indicators)
MA-MPS
Método de Avaliação de Melhoria de Processo de Software
MN-MPS
Modelo de Negócio de Melhoria de Processo de Software
MPS-BR
Melhoria de Processo do Software Brasileiro
MR-MPS
Modelo de Referência de Melhoria de Processo de Software
NBR
Norma Brasileira
PMBOK
Guia de Conhecimento em Gerenciamento de Projeto (A Guide to the Project
Management Body of Knowledge)
PMI
Instituto da gerência de projeto (Project Management Institute)
RAD
Desenvolvimento rápido da aplicação (Rapid Application Development)
RUP
Processo Unificado da Racional (Rational Unified Process)
SEI
Instituto de engenharia de software (Software Engineering Institute)
SG
Objetivo específico (Specific Goals)
SOFTEX
Sociedade para Promoção da Excelência do Software Brasileiro
XP
Programação extrema (Extreme Programming)
LISTA DE FIGURAS
Figura 1: Método do trabalho............................................................................................................18
Figura 2: Utilização de recursos ao longo do ciclo de vida do projeto...........................................23
Figura 3: Interação de grupos de processos em um projeto. ...........................................................24
Figura 4: Modelo de representação por contínuo.............................................................................25
Figura 5: Representação por estágio.................................................................................................25
Figura 6: Níveis de maturidade do CMMI. ......................................................................................26
Figura 7: Componentes do Modelo CMMI......................................................................................27
Figura 8: Estrutura do modelo de referência MPS.BR....................................................................30
Figura 9: Processos da NBR ISO/IEC 12207...................................................................................32
Figura 10: Processos do TenStep......................................................................................................37
Figura 11: Modelo de desenvolvimento em espiral de Barry Boehm. ...........................................40
Figura 12: Ciclo de vida do RUP......................................................................................................43
Figura 13: Visão geral do gerenciamento de riscos do projeto.......................................................52
Figura 14: Estrutura AS/NZS 4360...................................................................................................60
Figura 15: Principais etapas AS/NZS 4360:2004. ...........................................................................61
Figura 16: Processo de gerência de riscos........................................................................................74
Figura 17: Equivalência entre os processos de gerência de riscos do PMBOK® Guide e da
ferramenta Risk Free...........................................................................................................................77
SUMÁRIO
1. INTRODUÇÃO........................................................................................................................ 10
1.1
CONTEXTUALIZAÇÃO..................................................................................................... 10
1.2
PROBLEMA.......................................................................................................................... 11
1.3
OBJETIVO............................................................................................................................. 13
1.3.1
Objetivo geral .................................................................................................................... 13
1.3.2
Objetivos específicos......................................................................................................... 13
1.3
ESCOPO E DELIMITAÇÃO ............................................................................................... 14
1.4
RESULTADOS ESPERADOS............................................................................................. 15
1.5
JUSTIFICATIVA .................................................................................................................. 15
1.6
ASPECTOS METODOLÓGICOS ....................................................................................... 16
1.7
ESTRUTURA DO TCC ........................................................................................................ 17
2. GERENCIAMENTO DE PROJETOS, MODELOS DE REFERÊNCIA PARA
MELHORIA DO PROCESSO DE SOFTWARE, E RISCOS EM PROJETOS DE
SOFTWARE ..................................................................................................................................... 20
2.1
GERENCIAMENTO DE PROJETOS ................................................................................. 20
2.2
METODOLOGIAS PARA GERENCIAMENTO DE PROJETOS ................................... 21
2.2.1
Integração do Modelo de Maturidade e de Capacidade (Capability Maturity Model
Integration - CMMI).......................................................................................................................... 24
2.2.2
Melhoria de Processo do Software Brasileiro (MPS-BR) .............................................. 29
2.2.3
International Organization for Standardization (NBR ISO/IEC 12207) – Tecnologia de
informação – Processos do Ciclo de Vida de Software ................................................................... 30
2.2.4
TenStep Processo de Gerenciamento de Projetos® ........................................................ 35
2.2.5
AS/NZS 4360:2004 Australian Standard for Risk Management.................................... 38
2.3
GERÊNCIA DE PROJETOS APLICADA EM PROJETOS DE SOFTWARE................. 38
2.4
METODOLOGIAS PARA DESENVOLVIMENTO DE PROJETO E METODOLOGIAS
ÁGEIS ............................................................................................................................................42
2.4.1
Metodologias prescritivas ou clássicas ............................................................................ 42
2.4.2
Metodologias ágeis............................................................................................................ 44
2.5
RISCOS EM PROJETOS DE SOFTWARE ........................................................................ 48
3. PROCESSOS DOS MODELOS DE REFERÊNCIA COM ÊNFASE EM RISCOS.... 51
3.1
PROCESSOS PMBOK® GUIDE......................................................................................... 51
3.2
PROCESSOS DA NORMATIVA NBR ISO/IEC 12207 COM ÊNFASE EM RISCOS... 53
3.3
PROCESSOS DO MODELO DE REFERÊNCIA CMMI COM ÊNFASE EM RISCOS . 56
3.4
PROCESSOS DO MODELO DE REFERÊNCIA MPS-BR COM ÊNFASE EM RISCOS
............................................................................................................................................57
3.5
3.6
3.7
3.7.1
PROCESSOS DO TEN STEP COM ÊNFASE EM RISCOS ............................................. 58
PROCESSOS DA NORMATIVA AS/NZS 4360:2004 COM ÊNFASE EM RISCOS..... 60
ANÁLISE COMPARATIVA DAS PRÁTICAS ................................................................. 62
Resultados .......................................................................................................................... 62
4 MODELO PARA GERÊNCIA DE ATIVIDADES COM ÊNFASE EM RISCOS DE
PROJETOS DE SOFTWARE ....................................................................................................... 64
4.1
ATIVIDADES PRELIMINARES ........................................................................................ 64
4.2
PREPARAÇÃO DO ESTUDO............................................................................................. 65
4.3
IDENTIFICAÇÃO DAS INFORMAÇÕES SOBRE A ORGANIZAÇÃO/PROJETO.... 65
4.4
INÍCIO FORMAL DO ESTUDO ......................................................................................... 65
4.5
REALIZAÇÃO DAS ENTREVISTAS DE LEVANTAMENTO ...................................... 66
4.6
PLANEJAR A GERÊNCIA DE RISCO............................................................................... 66
4.7
IDENTIFICAR RISCOS ....................................................................................................... 67
4.8
ANALISAR RISCOS ............................................................................................................ 67
4.9
PLANEJAR RESPOSTAS AOS RISCOS ........................................................................... 68
4.10 MONITORAR RISCOS........................................................................................................ 69
4.11 CONTROLAR RISCOS........................................................................................................ 70
4.12 COMUNICAR OS RISCOS.................................................................................................. 70
4.13 DESENVOLVIMENTO E RECOMENDAÇÕES .............................................................. 70
4.14 DOCUMENTAÇÃO E COMUNICAÇÃO DE RESULTADOS ....................................... 71
5 ESTUDO DE FERRAMENTAS DE GERÊNCIA DE RISCO ........................................ 75
5.1
RISK RADAR........................................................................................................................ 75
5.2
RISKTRAK............................................................................................................................ 76
5.3
@RISK ................................................................................................................................... 76
5.4
RISKFREE............................................................................................................................. 76
5.5
ANÁLISE COMPARATIVA ............................................................................................... 77
6 CONCLUSÕES E FUTUROS TRABALHOS .................................................................... 79
6.1
CONCLUSÕES ..................................................................................................................... 79
6.2
FUTUROS TRABALHOS.................................................................................................... 79
7
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 81
10
1.
INTRODUÇÃO
1.1 CONTEXTUALIZAÇÃO
O Gerenciamento de Riscos de Software consiste em avaliar e controlar os riscos que afetam o
projeto, processo ou produto de software. A melhor maneira de descobrir os riscos é definir,
inicialmente, os objetivos e as metas do projeto. O objetivo do Gerenciamento de Riscos é
identificar problemas antes que eles ocorram de forma que as atividades de tratamento de riscos
possam ser planejadas e invocadas, conforme necessário, durante a vida do produto ou do projeto
para mitigar os impactos adversos no atendimento dos objetivos (UNISINOS, 2005, p.413).
O risco em um projeto de software é uma medida da probabilidade e da perda relacionadas à
ocorrência de um evento negativo ou positivo que afete o próprio projeto, seu processo ou
produto. Em outras palavras, qualquer coisa que possa acontecer e ameaçar o bom andamento do
projeto é um risco.
Os projetos de desenvolvimento de software estão expostos a perdas ou ganhos e demandam
planejamento, controle e acompanhamento das suas influências no projeto. Pela gerência é
possível maximizar os resultados decorrentes de fatos positivos e minimizar as conseqüências
decorrentes de fatos negativos. Em engenharia de software, a área de estudo que enfoca o
planejamento e o acompanhamento dessas perdas ou desses ganhos é a gerência de riscos.
De modo a contribuir com as atividades relacionadas aos riscos, propõe-se realizar uma análise
comparativa de modelos de processos segmentados no mercado e fornecer contribuições para
atividades relacionadas aos riscos em projetos de software como o Capability Maturity Model
Integration for development – CMMI para desenvolvimento, a Melhoria de Processo do Software
11
Brasileiro - MPS-BR, a norma NBR ISO/IEC 12207, o TenStep Processo de Gerenciamento de
Projetos® e a norma AS/NZS 4360:2004:
•
CMMI é uma evolução do Capability Maturity Model - CMM, que é uma estrutura de modelo
de maturidade, desenvolvida com o propósito de auxiliar empresas de software a melhorar os
seus processos;
•
MPS-BR é uma iniciativa envolvendo universidades, grupos de pesquisa e empresas sob a
coordenação da Sociedade para Promoção da Excelência do Software Brasileiro - SOFTEX.
O projeto visa à definição e à disseminação de um modelo de referência e um modelo de
negócio para a melhoria de processo de software;
•
NBR ISO/IEC 12207 é uma norma definida pela International Organization for
Standardization - ISO aplicada em engenharia de software. Esta estabelece um processo de
ciclo de vida do software;
•
TenStep Processo de Gerenciamento de Projetos® é uma metodologia prática e eficaz para o
planejamento e a gerência de projetos de qualquer tamanho e complexidade; e
•
AS/NZS 4360:2004 Padrão Australiano para a gerência de riscos (Australian Standard for
Risk Management) é uma norma australiana / neozelandesa para gerenciamento de riscos que
foi elaborada pela Standards Austrália e Standards New Zealand por meio do Comitê de
Gestão de Riscos (OB-007). É uma norma genérica que fornece orientações para o
gerenciamento de riscos de qualquer natureza.
1.2 PROBLEMA
Riscos não identificados significam que se pode investir em uma arquitetura falha ou em um
conjunto não otimizado de requisitos. Além disto, a totalidade dos riscos envolvidos está
diretamente relacionada à diferença entre a estimativa de quanto tempo vai demorar para que o
projeto seja concluído. Para se obterem estimativas acuradas, é necessário identificar e tratar os
riscos antecipadamente.
12
O risco é uma parte integral da boa gerência, sendo fundamental para conseguir bons resultados
do negócio, do projeto e dos bens e serviços. É algo que muitos já gerentes fazem em um
formulário ou outros meios, avaliando a permissão de contingência em uma estimativa de custo,
negociando o contrato ou desenvolvendo contingência (COOPER, et al., 2005, p.19). Segundo
Schwalbe (2004, p. 49), a gerência de riscos deve ser feita durante o ciclo de vida inteiro do
projeto. Apesar de freqüentemente ser um fator decisivo para que o projeto seja bem- sucedido, a
gerência de riscos é ainda um aspecto ignorado dentro da gerência de projetos.
As vantagens resultantes da aplicação de práticas de gerência de riscos citadas por Schwalbe
(2004, p.49) são:
•
auxilia a seleção de projetos;
•
ajuda a determinar o escopo de projetos;
•
ajuda a desenvolver cronogramas e estimativas de custos realistas;
•
ajuda aos interessados do projeto a entenderem a natureza do projeto;
•
faz com que a equipe do projeto se envolva na definição de pontos fortes e fracos; e
•
ajuda a integrar as demais áreas de conhecimento da gerência de projetos.
Demarco, Lister e Schwalbe (apud Silveira; Knob, 2005, p. 32) ressaltam que as organizações
não devem fugir dos riscos, pois podem estar deixando de aproveitar grandes oportunidades.
Dado que todos os projetos envolvem riscos e oportunidades, a questão é saber como os riscos
inerentes ao projeto serão gerenciados ao longo do seu ciclo de vida.
Existe grande quantidade de materiais sobre riscos. Para este trabalho, foram selecionados os
modelos CMMI, MPS-BR, NBR ISO/IEC 12207, TenStep Processo de Gerenciamento de
Projetos®, e a norma AS/NZS 4360:2004 por serem considerados apropriados e relacionados às
áreas de riscos em projetos de software, apresentando contribuições relevantes para o problema
em estudo. Também devido a relevância e reconhecimento de mercado relacionado a destaque na
literatura utilizada como referência na pesquisa para desenvolvimento desse trabalho.
13
Um dos fatores de contribuição deste trabalho é que as empresas acabam tendo custos financeiros
para implantação desses modelos de referência incluindo serviços de consultoria, treinamentos e
avaliação que normalmente são realizados unicamente por um modelo de referência. Com esse
método proposto no trabalho, além das práticas serem extraídas desses modelos, elas são
comparadas com os demais que estabelecem as contribuições no mesmo tipo de prática.
Por outro lado, a quantidade de modelos e diferentes práticas podem resultar em dificuldades para
a realização das atividades de gerência de riscos, e isso pode levar até a realização de atividades
que não estejam fundamentadas nesses modelos de referência.
A busca por um modelo que alcance todas as áreas do gerenciamento de riscos faz-se necessária
para que o gerenciamento de projetos de software melhore.
1.3
OBJETIVO
1.3.1 Objetivo geral
Este trabalho tem como objetivo principal realizar uma análise comparativa de modelos de
processos segmentados no mercado que apresentam contribuições para a área de riscos em
projetos de software como CMMI, MPS-BR, NBR ISO/IEC 12207, TenStep e AS/NZS
4360:2004.
1.3.2 Objetivos específicos
Para alcançar o objetivo principal deste trabalho, serão considerados os seguintes objetivos
específicos:
1. consolidação da identificação dos modelos de referência, normas e procedimentos que
ofereçam contribuições especificamente para a área de riscos, que possam ser utilizáveis em
projetos de software;
2. identificação das práticas relacionadas a riscos dos modelos e das normas consolidados no
estudo deste projeto;
3. análise comparativa entre as práticas identificadas;
14
4. seleção de um conjunto de práticas para serem executadas na gerência de riscos em projetos
de software;
5. fundamentação das práticas selecionadas a partir de conceitos da área de engenharia de
software e gerência de projetos com o PMBOK® Guide; e
6. definição de um modelo para avaliação das atividades de gerenciamento de riscos em projetos
de software por meio das práticas selecionadas e fundamentadas.
1.3 ESCOPO E DELIMITAÇÃO
Neste trabalho é feita uma análise com o objetivo de identificar um conjunto de práticas
específicas para a gerência de riscos que estejam definidas nos processos1 e que possam ser
utilizadas a fim de incorporar um modelo específico de gerência de riscos em projetos de
software.
Com base no Guia de Conhecimento em Gerenciamento de Projeto do Instituto de
Gerenciamento de Projeto (PMI - PMBOK® Guide), foi abordado o “como” podem ser
realizadas as práticas que foram selecionadas nos modelos de maturidade e processos analisados.
Visando oferecer contribuições às atividades relacionadas aos riscos, propõe-se realizar uma
análise comparativa dos modelos selecionados: CMMI, MPS-BR, NBR ISO/IEC 12207, TenStep
e AS/NZS 4360:2004.
Essa análise tem como objetivo permitir a identificação de um conjunto de práticas que estejam
definidas nos processos e possam ser citadas a fim de incorporar um modelo específico para
software. Tal modelo agrega um conjunto de práticas selecionadas dos modelos de referência
utilizadas como base para a análise comparativa dos modelos as contribuições das áreas de
engenharia de software e gerenciamento de projetos. A aplicação do modelo proposto em um
projeto de software para avaliação de riscos será realizada em uma oportunidade futura.
1
É uma seqüência coerente de práticas que objetiva o desenvolvimento ou a evolução de sistemas de software.
15
É feito um estudo de ferramentas de gerência de riscos, na qual as ferramentas estudadas não
abordam especificamente a gerência de riscos em projetos de software, mas sim a gerência de
riscos como um todo.
1.4 RESULTADOS ESPERADOS
O resultado principal é um modelo formado pelas práticas de processos e conceitos de riscos,
gerenciamento de projetos e engenharia de software que ofereçam contribuições para a área de
gerenciamento de riscos. Com base nas práticas selecionadas a partir dos modelos e normas
identificadas, será efetuada uma análise comparativa, levantando um conjunto de práticas para
serem incorporadas no modelo de gerência de riscos em projetos de software.
O gerenciamento de projetos exige dos responsáveis uma carga horária para a avaliação e o
gerenciamento dos riscos envolvidos, além do próprio andamento do projeto. Isto porque as
atividades relacionadas ao gerenciamento de riscos em projetos de software são funções de
grande importância para que se alcance sucesso. Com isto, objetiva-se conseguir um melhor
aproveitamento dos projetos, com significativa redução dos riscos envolvidos e do esforço
necessário para o seu gerenciamento.
1.5 JUSTIFICATIVA
Um projeto do software tem duas dimensões principais de atividade: gerência da engenharia e de
projeto. A dimensão da engenharia trata de construir o sistema e os focos em edições tais como
projetar, testar, codificar etc. A dimensão da gerência de projeto trata de planejar e de controlar as
atividades da engenharia com o objetivo de projeto para custo, programação e qualidade
(JALOTE, 2002, np).
O risco do projeto é um evento ou uma condição incerta que, quando ocorre tem efeito positivo
ou negativo em um ou mais objetivos do projeto. Um risco tem uma causa e, quando ocorre, uma
conseqüência. Segundo Howes (2001, p. 241), o risco é uma realidade em cada empreendimento.
Se soubéssemos o resultado antecipadamente, não haveria nenhum risco. Sabe-se que se pode
terminar, mas não se sabe precisamente quanto custará ou quanto tempo levará.
Conseqüentemente, é necessário reconhecer os riscos e controlá-los.
16
A gerência de projetos de software vem recebendo maior atenção por parte das organizações,
mostrando um crescimento de organizações que aprovam a gestão focada em projetos, e, por sua
vez, estes, a cada dia, tornam-se maiores e mais complexos. Uma das áreas que têm demandado
atenção e ganhado muita importância, especialmente em projetos de desenvolvimento de
software, é a gerência de riscos.
Os modelos e os processos de referência, conforme o próprio nome diz, têm sido desenvolvidos
para dirimir ou servir como referência para as atividades envolvidas na gerência de riscos em
projetos. Como exemplos têm-se os modelos e processos CMMI, MPS-BR, NBR ISO/IEC
12207, TenStep e AS/NZS 4360:2004. Dessa forma, este projeto propõe uma análise comparativa
das práticas que são abordadas nesses modelos.
Com base nessa análise comparativa para gerenciamento de riscos em projetos de software,
pretende-se selecionar um conjunto de práticas e pesquisar como as áreas de engenharia de
software e de gerência de projetos (considerando o Guia de Conhecimento em Gerenciamento de
Projeto) do Instituto de Gerenciamento de Projeto (PMI- PMBOK® Guide) sugerem a realização
de tais práticas abordadas nos modelos e nos processos analisados. Para isto, objetiva-se
conseguir melhor aproveitamento dos projetos, amenizando as dificuldades para orientar os
interessados nessa área por meio do modelo proposto.
1.6 ASPECTOS METODOLÓGICOS
Existem várias formas de classificar uma pesquisa. As mais tradicionais salientam os seguintes
pontos: natureza da pesquisa, forma de abordagem do problema, seus objetivos e procedimentos
técnicos (SILVA; MENEZES, 2005, p. 21).
Com relação à natureza, a pesquisa pode ser classificada como aplicada. Esse tipo de
classificação é descrito por Silva e Menezes (2005, p.20) como uma pesquisa cujo objetivo é
gerar conhecimentos para aplicação prática dirigidos à solução de problemas específicos,
envolvendo verdades e interesses locais. Considerando-se o objetivo proposto neste trabalho,
pressupõe-se o enquadramento nesse tipo de pesquisa.
O método proposto neste trabalho visa abordar as etapas a fim de possibilitar uma seqüência de
procedimentos que poderão ser seguidos para definição de uma unidade de informação. Com
17
isso, no tocante à forma de abordagem do problema, pode-se enquadrar a pesquisa como pesquisa
descritiva, classificada também como pesquisa qualitativa. Silva e Menezes (2005) definem que
nesse tipo de pesquisa o processo e seus significados são os focos principais da abordagem.
No que diz respeito aos objetivos, a pesquisa pode ser classificada como exploratória. A pesquisa
exploratória assume, em geral, as formas de pesquisa bibliográfica e estudo de caso (SILVA;
MENEZES, 2005, p. 21).
As etapas do trabalho constituem-se na gerência de projetos em riscos, envolvendo as atividades
de identificação dos modelos de referência, normas e suas variações que ofereçam contribuições
para a área e o gerenciamento de riscos. Da identificação das práticas a partir dos modelos e das
normas fazer uma análise comparativa entre as práticas, selecionando um conjunto de práticas
para serem executadas na gerência de riscos em projetos de software.
A próxima etapa é a de fundamentação das práticas selecionadas a partir de conceitos na
engenharia de software e gerência de projetos com o PMBOK® Guide e em seguida a avaliação
das atividades de riscos em um projeto de software.
A figura 1 ilustra uma visão esquemática do método de construção do trabalho:
1.7 ESTRUTURA DO TCC
O presente trabalho encontra-se dividido em seis capítulos que visam abordar questões
relacionadas à gerência de riscos, ou seja:
Capítulo 1: introdutório, no qual se encontram delimitados as idéias e os objetivos que se
pretende discutir e alcançar;
Capítulo 2: gerenciamento de projetos e de riscos em projetos de software – são apresentados
conceitos fundamentais de gerência de projetos e algumas de suas metodologias como PMBOK®
Guide, CMMI, MPS-BR, NBR ISO/IEC 12207, TenStep e AS/NZS 4360:2004, que são
referenciados ao longo do documento. Também descreve como a gerência de projetos é aplicada
em projetos de software;
18
Estudo e identificação dos
modelos de referência
Análise comparativa
Estudo e identificação das
práticas
Estudo do conjunto de práticas selecionadas
Fundamentação das práticas selecionadas
Definição de um modelo para avaliação das
atividades de gerenciamento de riscos em projetos de
software
Figura 1: Método do trabalho.
Capítulo 3: processos dos modelos de referência com ênfase em riscos – trata-se das
metodologias estudadas neste trabalho e de como cada uma delas aborda a gerência de riscos;
Capítulo 4: modelo para gerência de atividades com ênfase em riscos de projetos de software –
definição de um modelo para avaliação das atividades de gerenciamento de riscos em projetos de
software através das práticas selecionadas e fundamentadas;
Capítulo 5: estudo de ferramentas de gerência de risco – para complementar o estudo das
metodologias, foi realizado um estudo em ferramentas de gerência de riscos. Foram estudadas as
características de quatro ferramentas de gerência de riscos disponíveis no mercado; e
19
Capítulo 6: conclusões e futuros trabalhos – nesse capítulo discutem-se os resultados do trabalho
de conclusão de curso. Fala sobre as conclusões alcançadas e finaliza com propostas de trabalhos
futuros envolvendo gerência de riscos.
20
2.
GERENCIAMENTO DE PROJETOS, MODELOS DE REFERÊNCIA PARA
MELHORIA DO PROCESSO DE SOFTWARE, E RISCOS EM PROJETOS DE
SOFTWARE
Neste capítulo são apresentados os conceitos fundamentais de gerência de projetos com base no
Guia de Referência em Gerenciamento de Projeto PMBOK® Guide e em modelos de processos
da área de engenharia de software. Também são contextualizados os modelos de referência
abordados nesse trabalho, que serão utilizados como primícias para a identificação e a
fundamentação das atividades de gerenciamento de riscos, realizadas posteriormente.
2.1 GERENCIAMENTO DE PROJETOS
O gerenciamento de projetos de software é uma tarefa de fundamental importância no processo
de desenvolvimento de um produto. Segundo Pressman (1995, p. 55), a gerência de projetos é a
primeira camada do processo de engenharia de software, sendo chamada de camada em vez de
etapa ou atividade porque abrange todo o processo de desenvolvimento, do início ao fim.
A gerência de projetos consiste na aplicação de conhecimentos, habilidades, ferramentas e
técnicas nas atividades do projeto de maneira a atingir os objetivos estabelecidos. A gerência de
projetos é implementada por meio da execução de processos de iniciação, planejamento,
execução, controle e encerramento. Esses processos são, por natureza, iterativos, devido à
característica de elaboração progressiva atribuída ao ciclo de vida dos projetos (PMI, 2004, p.
365).
O Gerenciamento de Projetos surgiu como ciência no início da década de sessenta, mas foi a
partir da criação do PMI (Project Management Institute), em 1969, que a sua disseminação
ocorreu com mais intensidade. O PMI é uma associação sem fins lucrativos, cujo principal
21
objetivo é difundir a gestão de projetos no mundo de forma a promover a ética e o
profissionalismo no exercício dessa atividade (VIEIRA, 2006, p. 2).
2.2 METODOLOGIAS PARA GERENCIAMENTO DE PROJETOS
Entre as metodologias de gerência de projetos existentes, escolheu-se, para guiar este trabalho, o
conjunto de conhecimentos em gerência de projetos (PMBOK® Guide).
Em 1987, o PMI produziu a primeira versão do PMBOK® Guide (Project Management Body of
Knowledge), o qual fornece uma referência básica em nível de conhecimentos e de boas práticas
do gerenciamento de projetos, constituindo-se em um padrão mundial, aceito inclusive pela ANSI
(American National Standartd Institute) (VIEIRA, 2006, p. 2).
O PMBOK® Guide apresenta as práticas de gerenciamento de projetos, divididas pelas seguintes
áreas de conhecimento: escopo, prazo, custo, recursos humanos, comunicação, qualidade,
contratação, riscos e integração. Assim, os processos ocorrem dentro de cinco grupos básicos –
iniciação, planejamento, execução, controle e finalização, os quais podem se sobrepor ou
interagir entre si, conforme a fase do projeto.
Desde sua publicação, o PMBOK® Guide passou por duas revisões que geraram as versões 2000
e 2004. O principal propósito do PMBOK® Guide é identificar e descrever um conjunto de
conhecimentos em gerência de projetos, ou seja, os conhecimentos e as práticas descritas são
aplicados em grande parte dos projetos na maior parte do tempo e existe um consenso sobre o seu
valor e a sua usabilidade. A versão 2004 do guia PMBOK® Guide contempla as áreas de
conhecimento apresentadas a seguir.
a) Gerenciamento de Integração do Projeto: inclui os processos requeridos para assegurar que
diversos elementos do projeto estão adequadamente coordenados.
b) Gerenciamento do Escopo do Projeto: abrange os processos requeridos para assegurar que o
projeto inclua todo o trabalho necessário para complementar de forma bem-sucedida o
projeto.
c) Gerenciamento de Tempo do Projeto: inclui os processos necessários para assegurar que o
projeto será implementado no prazo previsto.
22
d) Gerenciamento dos Custos do Projeto: inclui os processos necessários para assegurar que o
projeto será concluído dentro do orçamento previsto.
e) Gerenciamento da Qualidade do Projeto: inclui os processos necessários para assegurar que o
projeto irá satisfazer as necessidades para as quais foi empreendido.
f) Gerenciamento de Recursos Humanos do Projeto: inclui os processos necessários para tornar
mais efetivo o uso dos recursos humanos empreendidos no projeto.
g) Gerenciamento das Comunicações do Projeto: inclui os processos necessários para garantir a
regular e apropriada geração, a coleta, a disseminação, a armazenagem e o descarte final das
informações do projeto.
h) Gerenciamento de Riscos do Projeto: é um processo sistemático de identificar, analisar e
responder os riscos do projeto.
i) Gerenciamento de Aquisições do Projeto: inclui os processos necessários para a obtenção de
bens e serviços externos à organização.
Para facilitar o controle gerencial, os projetos geralmente são divididos em diversas fases. O ciclo
de vida de um projeto é o conjunto das diversas fases do projeto. Ao final de uma fase, eles são
analisados, e, a partir do resultado, é decidido se o projeto deve prosseguir para a fase seguinte e
se as correções e os ajustes serão necessários, ou mesmo se o projeto deverá ser cancelado.
Ciclos de vida definem o início e o fim de um projeto. O número de fases e o nome de cada fase
varia de projeto para projeto, mesmo dentro de uma mesma área de aplicação. Em geral, o custo e
a quantidade de pessoas integrantes da equipe variam ao longo do ciclo de vida do projeto,
conforme apresentado na Figura 2.
Os processos de gerenciamento de projetos podem ser organizados em cinco grupos de um ou
mais processo(s):
a) Processos de iniciação: autorização do projeto ou fase;
23
b) Processos de planejamento: são processos iterativos de definição e refinamento de objetivos e
seleção dos melhores caminhos para atingir os objetivos;
Figura 2: Utilização de recursos ao longo do ciclo de vida do projeto.
Fonte: (Traduzido de: PMI, 2004, p. 21)
c) Processos de execução: execução dos planos do projeto – coordenação de pessoas e outros
recursos para executar o plano;
d) Processos de controle: medição e monitoramento do desempenho do projeto. Garantem que
os objetivos do projeto são alcançados pelo monitoramento e pela medição regular do
progresso de modo que ações corretivas possam ser tomadas quando necessário; e
e) Processos de encerramento: aceitação formal do projeto (com verificação de escopo) ou da
fase para a sua finalização.
Os grupos de processos da gerência de projetos não ocorrem de maneira isolada ou descontínua.
Esses grupos são formados por atividades que se sobrepõem e ocorrem com intensidade variável
durante as fases do projeto. A Figura 3 apresenta a sobreposição e interação de grupos de
processos ao longo do ciclo de vida do projeto.
24
Figura 3: Interação de grupos de processos em um projeto.
Fonte: (Traduzido de: PMI, 2000, p. 68)
2.2.1 Integração do Modelo de Maturidade e de Capacidade (Capability Maturity Model
Integration - CMMI)
Em 25 de agosto de 2006, o SEI - Software Engineering Institute, instituto de pesquisa norteamericano e administrador do CMMI, anunciou oficialmente a chegada ao mercado da versão 1.2
do CMMI®.
A release 1.1 do CMMI é utilizada desde 2002, quando da sua publicação. No entanto, o SEI
vem trabalhando desde então na estruturação de um framework de melhoria que pudesse ser
aplicado também em outras áreas de interesse. Desta forma, nasceram as chamadas
"constelações", onde componentes do CMMI são usados para construir modelos, materiais de
treinamento e documentos de avaliações são agrupados, gerando assim uma constelação. O
modelo CMMI chega à sua versão 1.2 compondo a constelação CMMI for Development, que
inclui definições quanto ao método de avaliação e materiais de treinamento. Ainda estão em
desenvolvimento duas outras constelações que irão compor a nova arquitetura de modelos:
CMMI for Services e CMMI for Acquisition (SEI, 2006, np).
25
Criado pelo Software Engineering Institute (SEI), o CMMI (Integração do Modelo de Maturidade
e de Capacidade) surgiu da necessidade de integrar os diversos modelos de maturidades
disponíveis e compatibilizar o SW-CMM com a norma ISO/IEC 15504. A utilização de diversos
modelos de maturidade mostrou-se problemática nas organizações. O CMMI foi idealizado com
o objetivo de resolver esse problema de integração.
Este guia é constituído de dois modelos de representação: contínua e por estágios.
Figura 4: Modelo de representação por contínuo.
Fonte: (SEI, 2006, p. 30)
Figura 5: Representação por estágio.
Fonte: (SEI, 2006, p. 30)
Modelo de representação contínua – Para uma única área de processos ou conjunto de áreas de
processos. Avalia os processos de zero (0) a cinco (5) níveis de capacidade (sendo zero (0)
incompleto, um (1) executado, dois (2) gerenciado, três (3) definido, quatro (4) gerenciado
26
quantitativamente e cinco (5) otimizado). Permite que a organização escolha a ordem das
melhorias de acordo com os objetivos de negócio ou ainda com as suas áreas de risco.
Modelo por estágios – Para um conjunto estabelecido de áreas de processos pela organização.
Avalia os processos de um (1) a cinco (5) níveis de maturidade (sendo um (1) inicial, dois (2)
gerenciado, três (3) definido, quatro (4) gerenciado quantitativamente e cinco (5) otimizado).
Em sua representação por estágios, o CMMI possui cinco níveis de maturidade. São eles:
Figura 6: Níveis de maturidade do CMMI.
Fonte: (Traduzido de: SEI, 2006, p. 36)
1. Inicial - satisfaz metas específicas da área de processo. O processo é caracterizado como
sendo imprevisível e ocasionalmente caótico. Poucos processos são definidos, e o sucesso
depende de esforços individuais e, muitas vezes, heróicos.
2. Gerenciado - planejado, executado, monitorado e controlado. Processos básicos de
gerenciamento de projeto são estabelecidos para o controle de custos, prazos e escopo. A
disciplina de processo permite repetir sucessos de projetos anteriores em aplicações similares.
3. Definido - processo é adaptado de um conjunto de processos padrão. Um processo composto
de atividades de gerenciamento e engenharia é documentado, padronizado e integrado em um
processo padrão da organização. Todos os projetos utilizam uma versão aprovada e adaptada
27
do processo organizacional para o desenvolvimento e a manutenção de produtos e serviços
tecnológicos.
4. Quantitativamente Gerenciado – utiliza-se de métodos estatísticos. Métricas detalhadas dos
processos e dos projetos são coletadas. Tanto os processos como os projetos são
quantitativamente compreendidos e controlados.
5. Otimizado - foco na melhoria contínua do processo. A melhoria contínua do processo é
estabelecida por meio de sua avaliação quantitativa e da implantação planejada e controlada
de tecnologias e idéias inovadoras.
Cada nível de maturidade é formado por áreas de processo, cada uma contemplando diversas
práticas. Cada área de processo possui objetivos a serem alcançados e práticas que auxiliam na
busca por esses objetivos.
Para melhor compreensão do CMMI, faz-se necessária a apresentação dos elementos que
compõem o modelo, conforme a Figura 7.
Figura 7: Componentes do Modelo CMMI.
Fonte: (SEI, 2006, p. 17)
Nas áreas de processos estão as metas genéricas e específicas, bem como as práticas genéricas e
específicas, as quais são descritas na seqüência.
28
1. Áreas de processos são um agrupamento de práticas em uma área. Quando essas práticas são
aplicadas de maneira conjunta, elas satisfazem as metas importantes para realizar melhorias
significativas na área a que pertencem. Todas as áreas de processos do CMMI são comuns
tanto para a representação contínua quanto para a representação por estágios.
2. Metas específicas se aplicam a cada área de processo específica e identificam características
únicas que descrevem o que precisa ser implementado para satisfazer esta área de processo.
Os SGs (objetivo específico – Specific Goals) também são usados em estimativas que podem
determinar se uma área de processo foi satisfeita ou não.
3. Práticas específicas são atividades consideradas essenciais para satisfazer o objetivo
específico correspondente.
4. Produtos de trabalho típicos são componentes informativos do modelo que oferecem
exemplos de saídas de uma prática específica ou genérica. Esses exemplos são chamados
“produtos de trabalho típicos” porque, muitas vezes, existem outros produtos de trabalho que
são tão eficientes quanto esses, mas que não estão listados.
5. Subpráticas são descrições detalhadas que fornecem um direcionamento para a interpretação
de práticas específicas ou genéricas. As subpráticas podem ser expressas como se fossem
exigidas, mas são, na verdade, componentes informativos dos modelos CMMI criados
somente para fornecer idéias que podem ser úteis na melhoria dos processos.
6. Metas genéricas são chamadas de “genéricas” porque a mesma declaração de meta aparece
em diversas áreas de processos. Na representação em estágios, cada área de processo tem
somente uma meta genérica. A satisfação de uma meta genérica em uma área de processo
significa um controle melhorado do planejamento e da implementação de processos
associados com aquela área de processo, indicando, portanto, se esses processos parecem ser
eficientes, repetíveis e duráveis. As metas genéricas são componentes exigidos do modelo e
são utilizadas em avaliações para determinar se uma área de processo está sendo satisfeita.
7. Práticas genéricas oferecem uma institucionalização que assegura que os processos
associados com a área de processo serão eficientes, repetíveis e duráveis. As práticas
genéricas são categorizadas pelas metas genéricas e características comuns, e são
componentes esperados em modelos CMMI.
29
8. Elaborações de práticas genéricas são componentes informativos do modelo que aparecem em
cada área de processo para fornecer instruções sobre como as práticas genéricas deverão ser
aplicadas de forma única naquela área de processo. Por exemplo, quando a prática genérica
“Treinar as pessoas para executar e dar suporte ao processo planejado, conforme necessário”,
é incorporada na área de processo de Gerenciamento de Configurações, e são descritos os
treinamentos específicos para a execução do gerenciamento de configurações.
2.2.2 Melhoria de Processo do Software Brasileiro (MPS-BR)
O MPS.BR está em desenvolvimento desde dezembro de 2003 e tem como objetivo definir um
modelo de melhoria e avaliação de processo de software, preferencialmente para as micro,
pequenas e médias empresas, de forma a atender às suas necessidades de negócio e a ser
reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software
(SOFTEX, 2005, p. 9).
A base utilizada para a construção do MPS.BR é composta das normas NBR ISO/IEC 12207 Processo de Ciclo de Vida de Software e suas emendas um (1) e dois (2) e ISO/IEC 15504 Avaliação de Processo e seu Modelo de Avaliação de Processo de Software ISO/IEC 15504-5.
Portanto, o modelo está de acordo com essas normas. O MPS.BR também cobre o conteúdo do
CMMI-SE/SWSM pela inclusão de processos e resultados de processos em relação aos processos
da Norma NBR ISO/IEC 12207, conforme a Figura 8 (SOFTEX, 2005, p. 9).
O MPS.BR está dividido em três componentes: o Modelo de Referência de Melhoria de Processo
de Software (MR-MPS) contém os requisitos aos quais as organizações deverão atender para
estar em conformidade com o MR-MPS. Ele contém as definições dos níveis de maturidade, da
capacidade de processos e dos processos em si.
Adicionalmente, foi escrito o Guia de Aquisição, que é um documento complementar para
organizações que pretendam adquirir software e serviços correlatos. O Guia de Aquisição não
contém requisitos do MR-MPS, mas boas práticas de aquisição de software e serviços correlatos.
•
O Modelo de Referência de Melhoria de Processo de Software (MR-MPS) tem sete (7) níveis
de maturidade, os quais possibilitam uma implantação mais gradual e adequada à micro,
pequena e média empresa, além disto, as avaliações considerando mais níveis permitem
30
maior visibilidade dos resultados de melhoria de processo, com prazos mais curtos,
compatibilidade plena com CMMI.
Figura 8: Estrutura do modelo de referência MPS.BR.
Fonte: (SOFTEX, 2005, p. 10)
•
O Método de Avaliação (MA-MPS) contém o processo de avaliação, os requisitos para os
avaliadores e os requisitos para averiguação da conformidade ao modelo MR-MPS. Ele está
descrito de forma detalhada no Guia de Avaliação e foi baseado na norma ISO/IEC 15504.
•
O Modelo de Negócio (MN-MPS) contém uma descrição das regras para a implementação do
MR-MPS pelas empresas de consultoria, de software e de avaliação. O detalhamento dessas
regras está disponível na página do SOFTEX (<www.softex.br/mpsbr>) e não está descrito
em nenhum guia específico.
2.2.3 International Organization for Standardization (NBR ISO/IEC 12207) – Tecnologia de
informação – Processos do Ciclo de Vida de Software
A Norma NBR ISO/IEC 12207 - Processos do Ciclo de Vida do Software tem como principal
objetivo fornecer uma estrutura comum para que adquirente, fornecedor, desenvolvedor,
mantenedor, operador, gerentes e técnicos envolvidos com o desenvolvimento de software
utilizem uma linguagem comum. Essa linguagem comum é estabelecida na forma de processos
bem definidos (ROCHA; MALDONADO; WEBER, 2001, p. 10).
31
A estrutura da norma foi concebida de maneira flexível, modular e adaptável às necessidades de
quem a utiliza. Para isto, está fundamentada em dois princípios básicos: modularidade e
responsabilidade. Modularidade compreende processos com mínimo acoplamento e máxima
coesão. Responsabilidade estabelece um responsável único por processo, facilitando a aplicação
da norma em projetos nos quais várias pessoas podem estar legalmente envolvidas.
A norma é composta de um conjunto de processos2, atividades3 e tarefas4 que podem ser
adaptados de acordo com os projetos de software. Esses processos são classificados em três tipos:
fundamentais, de apoio e organizacionais, conforme ilustra a Figura 9. Os processos de apoio e
organizacionais devem existir independentemente da organização e do projeto que está sendo
executado. Os processos fundamentais são instanciados de acordo com a situação.
Os processos fundamentais são responsáveis pela geração dos produtos de software, constituindo
o ciclo de vida de software propriamente dito, e são representados pelos processos a seguir.
•
Processo de Aquisição: define as atividades do adquirente, organização que adquire um
sistema ou produto de software. Inicia-se com a definição da necessidade de adquirir um
sistema, um produto de software ou um serviço de software. O processo continua com a
preparação e a emissão de pedido de proposta, a seleção de fornecedor e a gerência do
processo de aquisição pela da aceitação do sistema, produto de software ou serviço de
software.
• Processo de Fornecimento: define as atividades do fornecedor e a organização que provê o
produto de software ao adquirente. O processo pode ser iniciado tanto por uma decisão de
preparar uma proposta para responder a um pedido de proposta de um adquirente quanto pela
assinatura e celebração de um contrato com o adquirente para fornecer o sistema, o produto de
software ou o serviço de software. O processo continua com a determinação dos procedimentos
e recursos necessários para gerenciar e garantir o projeto, incluindo o desenvolvimento e a
execução dos planos de projeto até a entrega do sistema, produto de software ou serviço de
software para o adquirente.
2
É um conjunto de ações para produzir um resultado. (PMI, 2004, p. 38)
É a execução de uma tarefa ou ação por um indivíduo. (PMI, 2004, p. 127)
4
Conjunto de atividades distintas realizadas em um posto de trabalho com o objetivo de cumprir uma função. Um
conjunto de tarefas constitui um processo. (PMI, 2004, p. 378)
3
32
Figura 9: Processos da NBR ISO/IEC 12207.
Fonte: (ROCHA et al., 2001, p. 10)
• Processo de Desenvolvimento: define as atividades do desenvolvedor, organização que define
e desenvolve o produto de software. O processo contém as atividades para a análise de
requisitos, projetos, codificação, integração, testes, instalação e aceitação relacionadas aos
produtos de software.
• Processo de Operação: define as atividades do operador, organização que provê serviço de
operação de um sistema computacional no seu ambiente de funcionamento para os seus
usuários. O processo cobre a operação do produto de software e o suporte operacional aos
usuários.
33
• Processo de Manutenção: define as atividades do mantenedor, organização que provê os
serviços de manutenção do software, isto é, gerenciamento de modificações no software para
mantê-lo atualizado e em perfeita operação. Este processo é ativado quando o produto de
software é submetido a modificações no código e na documentação associada devido a um
problema ou à necessidade de melhoria ou adaptação. O objetivo é modificar um produto de
software existente, preservando a sua integridade.
Os processos de apoio têm como objetivo auxiliar outros processos, visando principalmente à
qualidade e ao sucesso do projeto. São representados pelos processos a seguir.
• Processo de Documentação: define as atividades para registrar informações produzidas por
um processo ou uma atividade do ciclo de vida. O processo contém o conjunto de atividades
que planeja, projeta, desenvolve, produz, edita, distribui e mantém os documentos necessários a
todos os interessados, tais como gerentes, engenheiros e usuários do sistema ou produto de
software.
• Processo de Gerência de Configuração: define as atividades para a aplicação de
procedimentos administrativos e técnicos por todo o ciclo de vida de software, destinado a:
identificar e definir os itens de software em um sistema e estabelecer suas linhas-base
(baseline); controlar as modificações e liberações dos itens; registrar e apresentar a situação dos
itens e dos pedidos de modificação; garantir a completeza, a consistência e a correção dos itens;
e controlar a armazenagem, a manipulação e a distribuição dos itens.
• Processo de Garantia da Qualidade: define as atividades para fornecer a garantia adequada
de que os processos e produtos de software, no ciclo de vida do projeto, estejam em
conformidade com os seus requisitos especificados e sejam aderentes aos planos estabelecidos.
A abrangência do processo inclui questões como garantia de qualidade do produto (NBR 13596
que corresponde à ISO/IEC 9126), do processo e do sistema de qualidade.
• Processo de Verificação: define as atividades para verificação dos produtos de software. É um
processo para determinar se os produtos de software de uma atividade atendem completamente
aos requisitos ou às condições a eles impostas.
34
• Processo de Validação: define as atividades para validação dos produtos produzidos pelo
projeto de software. É um processo para determinar se os requisitos e o produto final (sistema
ou software) atendem ao uso específico proposto.
• Processo de Revisão Conjunta: define as atividades para avaliar a situação e os produtos de
uma atividade de um projeto, se apropriado. As revisões conjuntas são feitas tanto nos níveis de
gerenciamento do projeto como nos níveis técnicos, e são executadas durante a vigência do
contrato.
• Processo de Auditoria: definem as atividades para determinar adequação aos requisitos, aos
planos e ao contrato, quando apropriado.
• Processo de Resolução de Problemas: define um processo para analisar e resolver os
problemas (incluindo não-conformidades) de qualquer natureza ou fonte que são descobertos
durante a execução do desenvolvimento, da operação, da manutenção ou de outros processos. O
objetivo é prover os meios em tempo adequado e de forma responsável e documentado para
garantir que todos os problemas encontrados sejam analisados e resolvidos, e as tendências,
identificadas.
Os processos organizacionais têm como objetivo garantir e melhorar os processos dentro da
organização e representados por.
• Processo de Gerência: define as atividades genéricas que podem ser empregadas por quaisquer
das partes que têm que gerenciar seu(s) respectivo(s) processo(s). O gerente é responsável pelo
gerenciamento de produto, gerenciamento de projeto e gerenciamento de tarefa do(s)
processo(s) aplicável(eis), tais como a aquisição, o fornecimento, o desenvolvimento, a
operação, a manutenção ou os processos de apoio.
• Processo de Infra-estrutura: define as atividades para estabelecer e manter a infra-estrutura
necessária para qualquer outro processo. A infra-estrutura pode incluir hardware, software,
ferramentas, técnicas, padrões e recursos para o desenvolvimento, a operação ou a manutenção.
35
• Processo de Melhoria: define as atividades básicas que uma organização (isto é, o adquirente,
fornecedor, o desenvolvedor, o operador, o mantenedor ou o gerente de outro processo) executa
para estabelecer, avaliar, medir, controlar e melhorar um processo de ciclo de vida de software.
• Processo de Treinamento: define as atividades para prover e manter pessoal treinado. A
aquisição, o fornecimento, o desenvolvimento, a operação ou a manutenção de produtos de
software são extremamente dependentes de pessoal com conhecimento e qualificação. Portanto,
é essencial que o treinamento seja planejado e implementado com antecedência para que o
pessoal treinado esteja disponível quando o produto de software for adquirido, fornecido,
desenvolvido, operado ou mantido.
A norma também descreve o Processo de Adaptação, que contém as atividades básicas para
adaptar a norma a uma organização ou projeto específico.
2.2.4 TenStep Processo de Gerenciamento de Projetos®
TenStep de processos de Gerenciamento de Projetos refere-se à definição e ao planejamento,
subseqüentemente ao gerenciamento, ao controle e à conclusão do projeto. Isto é importante para
reconhecer que todos os projetos necessitam de algum nível de Gerenciamento de Projetos.
Quanto maior e mais complexo for o projeto, maior será a necessidade do processo formal,
estruturado e padronizado. Pequenos projetos necessitam de um processo estruturado, mas não
necessitam ser igualmente elaborados ou complexos. É evidente que haverá custo para o esforço
associado com os processos de Gerenciamento de Projetos, mas têm muitos benefícios que
excedem os custos.
O TenStep Processo de Gerenciamento de Projetos® é dividido em dez steps (passos) – os
primeiros dois para definição e planejamento, e os oitos seguintes para gerenciamento e controle
do trabalho. Esses passos são (TENSTEP, 2004, np):
1 definição de tarefas – o gerente de projetos define o trabalho para ter certeza que o time do
projeto, e o cliente tem a mesma percepção sobre o projeto, incluindo os deliverables (resultados
esperados) do projeto, prazo de término do projeto, quem fica responsável pelo quê, como os
trabalhos serão feitos, e quais os seus benefícios;
36
2 construção do workplan – o workplan do projeto será construído. O workplan é uma
ferramenta vital para assegurar que as equipes do projeto saibam, o que devem fazer;
3 gerenciamento do workplan – Agora é preciso gerenciar o workplan de modo que represente a
condição atual do projeto. O workplan deverá ser mantido atualizado lhe informando quanto
trabalho ainda resta para ser concluído;
4 gerenciamento das incidências – Muitos problemas aparecem e são resolvidos rapidamente.
Entretanto, uma “incidência” é quando um problema aparece e impede o progresso do projeto. O
gerente do projeto e sua equipe também não conseguem resolvê-lo sozinhos a não ser com ajuda
externa. Gerenciamento de incidências é um dos processos mais importantes da metodologia
TenStep, e é uma habilidade que todo gerente de projetos deveria possuir e saber a fundo;
5 gerenciamento do escopo – Escopo é a maneira como se descreve os limites de cada projeto.
O gerente de projetos e seu patrocinador devem concordar com o escopo do projeto antes de
começar o próprio projeto. O propósito do gerenciamento de mudanças do escopo é assegurar que
o patrocinador aprove qualquer mudança feita após a concordância do escopo inicial;
6 gerenciamento da comunicação – A Comunicação de forma efetiva é um fator crítico para o
sucesso do gerenciamento das expectativas dos clientes e dos stakeholders.
7 gerenciamento do risco – Risco refere-se a futuras condições ou circunstâncias que existem e
estão fora do controle da equipe do projeto, e que pode ter um impacto adverso no projeto se este
ocorrer. Gerentes de projetos de sucesso tentam resolver problemas potenciais antes que esses
ocorram. Essa é a arte do gerenciamento de risco.
8 gerenciamento dos documentos – lida com a armazenagem e o compartilhamento de
documentos eletrônicos ou papéis. Quanto maior for o projeto, maior rigor e estrutura são
precisos para o gerenciamento dos documentos. Se não houver um bom plano de gerenciamento
de documentos antes de começar um projeto, pode-se acabar tendo um grande problema para
achar e salvar esses documentos.
37
9 gerenciamento da qualidade – seu propósito é primeiramente entender quais são as
expectativas atuais do cliente em termos qualificativos. E essas expectativas devem ser colocadas
em plano proativo de processos que possam alcançar e supera-las.
Figura 10: Processos do TenStep.
Fonte: (TENSTEP, 2004, np)
10 gerenciamento das métricas – Métricas são usadas para coletar dados quantitativos para
auxiliar nas decisões e também para lhe informar se suas expectativas estão sendo superadas.
Métricas também são guardadas com o tempo para fornecer algumas indicações de tendência que
possam impedir que o projeto tenha o sucesso esperado.
38
O TenStep Processo de Gerenciamento de Projetos® (TenStep) é projetado para fornecer as
informações necessárias para um Gerente de Projetos, incluindo uma abordagem step-by-step
(passo a passo). O TenStep é uma metodologia flexível e escalável de gerenciamento de projetos.
Sua filosofia básica é "metodologia grande para projetos grandes, metodologia pequena para
projetos pequenos" (TENSTEP, 2004, np).
2.2.5 AS/NZS 4360:2004 Australian Standard for Risk Management
Publicada em 1995 e revisada em 1999, a AS/NZS 4360 é uma norma australiana/neozelandesa
para gerenciamento de riscos que foi elaborada pela Standards Austrália e Standards New
Zealand por meio do Comitê de Gestão de Riscos (OB-007). É uma norma genérica que fornece
orientações para gerenciamento de riscos de qualquer natureza.
A AS/NZS 4360:2004 dá ênfase à inserção da Gestão de Riscos na filosofia, nas práticas e nos
processos de negócio da organização, em vez de ser vista ou praticada como uma atividade
separada. Embora o conceito de risco seja freqüentemente interpretado em termos de perigo ou
impacto negativo, a norma vê os riscos como a exposição às conseqüências da incerteza ou como
potenciais desvios do que foi planejado ou do que é esperado, ou seja, a AS/NZS 4360:2004 parte
do princípio de que a gestão de riscos tem como finalidade o equilíbrio entre as oportunidades de
ganhos e a redução de perdas.
2.3 GERÊNCIA DE PROJETOS APLICADA EM PROJETOS DE SOFTWARE
Apesar de ser fácil chamar trabalho de projeto, um projeto deve representar um trabalho que não
é rotineiro. Ao contrário, um projeto deve ser inédito e deve ter produtos e metas claros. Embora
os projetos possam ter muitas formas e tamanhos, apresentam como características comuns
propósito e objetivos distintos, a duração limitada e a independência do empreendimento (PMA,
2006, np).
Para que um projeto de software seja bem-sucedido, é necessário que alguns parâmetros sejam
bem analisados, por exemplo, o escopo do software, os riscos envolvidos, os recursos
necessários, as tarefas a serem realizadas, os marcos de referência, os custos aplicados e a
sistemática a ser seguida. A análise de todos esses parâmetros é a função típica da gerência de
39
projetos, função esta que se inicia antes do trabalho técnico e que prossegue a medida que o
software vai se concretizando na forma de um produto.
Gerência de Projetos (ou Gestão de Projetos) é a aplicação de conhecimentos, habilidades e
técnicas na elaboração de atividades relacionadas para atingir um conjunto de objetivos prédefinidos. O conhecimento e as práticas da gerência de projetos são melhores descritos em termos
de seus processos componentes.
De acordo com o PMI esses processos podem ser classificados em cinco grupos de processo
(iniciação, planejamento, execução, controle e encerramento) e nove áreas de conhecimento
(gerência de integração de projetos, gerência de escopo de projetos, gerência de tempo de
projetos, gerência de custo de projetos, gerência de qualidade de projetos, gerência de recursos
humanos de projetos, gerência de comunicações de projetos, gerência de riscos de projetos e
gerência de aquisições de projetos).
A primeira proposta para incluir a gerência de riscos no ciclo de vida de desenvolvimento de
software foi feita no final dos anos 80, quando Barry Boehm propôs o modelo de
desenvolvimento em espiral. Este modelo, apresentado na Figura 11, tem como principais
características a iteratividade e o fato de ser dirigido aos riscos. Neste modelo, a análise dos
riscos do projeto é feita a cada iteração.
Tem-se também o processo unificado de desenvolvimento de software, que é um conjunto de
atividades necessárias para transformar requisitos do usuário em um sistema de software
(MARTINS, 2003, np). Ele é baseado em componentes, o que significa que o sistema é
construído a partir de componentes de software interconectados via interfaces muito bem
definidas. O processo unificado utiliza a Linguagem de Modelagem Unificada (Unified Modeling
Language – UML) no preparo de todos os artefatos do sistema.
Os aspectos que distinguem o processo unificado são capturados em três conceitos-chave:
direcionado a casos de uso; centrado na arquitetura e iterativo e incremental (MARTINS, 2003,
np).
40
Figura 11: Modelo de desenvolvimento em espiral de Barry Boehm.
Fonte: (SOMMERVILLE, 2003, p. 45)
Direcionado a casos de uso : os casos de uso dirigem o processo. Eles não são selecionados
isoladamente e desenvolvidos juntamente com a arquitetura do sistema, isto é, os casos de uso
direcionam a arquitetura do sistema, que por sua vez influencia a seleção dos casos de uso.
Portanto, ambos amadurecem no decorrer do ciclo de vida do sistema.
Centrado na arquitetura: O conceito de arquitetura de software incorpora os aspectos estáticos
e dinâmicos mais importantes do sistema. A arquitetura é influenciada por muitos fatores, tais
como a plataforma de software sobre a qual o sistema vai rodar (sistema operacional, sistema
gerenciador de banco de dados, protocolos para comunicação em rede etc.), blocos de construção
reusáveis disponíveis (por exemplo, um framework para construção de interface gráfica com o
usuário), considerações de distribuição, sistemas legado e requisitos não funcionais
(performance, confiabilidade etc.). Ela representa uma visão do projeto como um todo, na qual as
características mais importantes são colocadas em destaque, deixando os detalhes de lado.
41
Este processo continua até que a arquitetura seja considerada estável.
Iterativo e incremental: em cada iteração, os desenvolvedores identificam e especificam os
casos de uso relevantes, criam um projeto utilizando a arquitetura escolhida como guia,
implementam o projeto em componentes e verificam se esses componentes satisfazem os casos
de uso. Se uma iteração atinge os seus objetivos, e isso normalmente ocorre, o desenvolvimento
prossegue com a próxima iteração, caso contrário, os desenvolvedores devem rever suas decisões
e tentar uma nova abordagem.
Há vários benefícios em se adotar um processo iterativo controlado, tais como (MARTINS, 2003,
np).
•
Redução dos riscos envolvendo custos a um único incremento: se os desenvolvedores
precisarem repetir a iteração, a organização perde somente o esforço mal direcionado de uma
iteração, não o valor de um produto inteiro.
•
Redução do risco de lançar o projeto no mercado fora da data planejada: identificando os
riscos numa fase inicial, o esforço despendido para gerenciá-los ocorre cedo, quando as
pessoas estão sob menos pressão do que numa fase final de projeto.
•
Aceleração do tempo de desenvolvimento do projeto, porque os desenvolvedores trabalham
de maneira mais eficiente quando buscam resultados de escopo pequeno e claro.
•
Reconhecimento de uma realidade freqüentemente ignorada: as necessidades dos usuários e
os requisitos correspondentes não podem ser totalmente definidos no início do processo. Eles
são tipicamente refinados em sucessivas iterações. Este modelo de operação facilita a
adaptação a mudanças de requisitos.
Esses conceitos (dirigidos a casos de uso, centrado na arquitetura e iterativo e incremental) são
igualmente importantes. Remover um deles poderia reduzir o valor do processo unificado, e
agora que eles foram introduzidos, pode-se observar o processo, seu ciclo de vida, produtos,
tarefas, fases e iterações.
42
A princípio, as metodologias de gerência de projetos deixaram a gerência de riscos em segundo
plano, normalmente dentro de outra área de conhecimento. Essas mesmas metodologias,
atualmente, colocam a gerência de riscos em posição de destaque, dedicando capítulos exclusivos
para essa área de conhecimento.
2.4 METODOLOGIAS
PARA
DESENVOLVIMENTO
DE
PROJETO
E
METODOLOGIAS ÁGEIS
Antes de apresentar que tipos de metodologias podem ser úteis quando aplicadas em projetos de
engenharia para construção de softwares, considera-se importante contemplar primeiramente o
que são essas metodologias e quais são seus princípios.
Uma metodologia descreve um conjunto de orientações ou princípios que podem ser seguidos e
aplicados para uma situação específica. Em um ambiente de projeto, essas orientações poderiam
ser uma lista de coisas a fazer. No ambiente de desenvolvimento de software, uma metodologia
pode ser classificada de duas formas: (a) metodologias prescritivas ou clássicas, também
conhecidas como metodologias pesadas (do inglês heavyweight); e (b) metodologias ágeis ou
metodologias leves (do inglês lightweight). Para Charvat (2003, np) a escolha adequada do tipo
de metodologia a ser seguida para o desenvolvimento do projeto determinará o seu sucesso.
2.4.1 Metodologias prescritivas ou clássicas
As metodologias prescritivas ou clássicas de projeto, além de tradicionais, são também
consideradas burocráticas. Para Charvat (2003, np), elas têm resultado no insucesso de muitos
projetos e, por esse motivo, estão perdendo sua popularidade.
Para Charvat (2003, np), nesses tipos de metodologias os gerentes de projeto tendem a indicar
cada marco de projeto porque querem antecipar cada detalhe técnico (por exemplo, o código de
software ou o detalhe de engenharia). Isto leva os gerentes a iniciar demanda por muitos tipos de
especificações, planos, relatórios, checkpoints e agendas. Metodologias pesadas levam a planejar
grande parte de um projeto em grandes detalhes sobre um longo espaço de tempo. Esses trabalhos
continuam com dificuldades até que as coisas comecem a mudar, e o gerente de projeto
necessariamente tenta resistir às mudanças. Essas metodologias apresentam um bom nível de
formalismo e documentação, e podem ser ideais para projetos que possuem em sua equipe um
43
número de 10 a 20 (ou mais) colaboradores. Em projetos que possuem equipes situadas em
diversos ambientes, também pode ser interessante usar tais metodologias a fim de permitir o
controle na interação destas.
Como exemplo de metodologia prescritiva pode-se citar o Rational Unified Process – RUP.
O Rational Unified Process (RUP) foi lançado publicamente como produto em 1996, primeiro
como o Rational Objectory Process, que mais tarde, em 1998, foi renomeado para RUP, embora
suas raízes estejam no Objectory Process, que foi lançado em 1988 (EUP, 2006, np). O RUP é na
verdade um produto composto de material de referência na forma de páginas HTML,
descrevendo toda a metodologia.
A Figura 12 mostra o ciclo de vida do RUP, também conhecido como hump chart. Na parte de
baixo do diagrama, o ciclo de vida é organizado em iterações, havendo uma abordagem temporal
para o desenvolvimento.
Figura 12: Ciclo de vida do RUP.
Fonte: (EUP, 2006, np)
As tarefas são organizadas em disciplinas e realizadas de maneira iterativa.
44
Observa-se na figura 12 que o gerenciamento de projetos é uma atividade importante que
continua ao longo do projeto.
Durante a fase de construção, as equipes RUP implementam os requerimentos em ordem de
prioridade definida pelos stakeholders, o que reduzirá o risco de negócios do projeto, ou seja, o
RUP pega as melhores idéias do gerenciamento ágil de projeto, adiciona um pouco de disciplina
e reduz assim os riscos gerais do projeto (AMBLER, 2006, p. 15).
2.4.2 Metodologias ágeis
Um grupo interessado em metodologias e em métodos interativos e ágeis reuniu-se em 2001 para
encontrar e definir uma área de interesse comum. Embora houvesse uma resistência por parte dos
metodologistas “peso pesado” quanto à criação de metodologias ágeis (FOWLER, 2001, np), a
iniciativa desse grupo resultou na criação da Aliança Ágil (<www.agilealiance.com>), definida
por seu manifesto e declaração de princípios que possibilitaram a criação das metodologias ágeis
(LARMAN, 2003, np).
Para Chau (2002, np), essas metodologias têm atraído nos últimos anos muita atenção da
comunidade de desenvolvimento de software. Ainda que existam muitas variações dentre as
metodologias existentes, todas elas compartilham valores e princípios comuns definidos no Agile
Manifesto (AGILE, 2005, np). Esses valores e princípios apresentam um novo e não tradicional
caminho para a construção de produtos e sistemas complexos. Projetos que usam metodologias
ágeis estão agora começando a reportar seus resultados de utilização das metodologias ágeis, que
incluem redução para término de projetos e de custos, quando comparados à utilização de
metodologias da família das metodologias prescritivas.
Segundo Larman (2003, np), isso pode ser alcançado pelo fato de que as metodologias ágeis são
muito menos orientadas a documentos, e, geralmente enfatizam uma menor quantia de
documentação para um projeto – e, em casos de projeto de software, o código fonte chega a ser
considerado um artefato de documentação para o projeto. Como vantagens, uma metodologia
ágil: (a) trabalha bem com mudanças; (b) é mais orientada à pessoa do que ao processo (trabalha
mais com a pessoa do que contra ela); e (c) é complementada pelo uso de checklists dinâmicos.
45
Charvat (2003, np) afirma que a principal característica de uma metodologia ágil é que ela é uma
metodologia de aprendizado. Trabalhando com ciclos menores, quando comparados às
metodologias pesadas, as ágeis possibilitam que, a cada interação, a equipe aprenda a corrigir ou
lidar com os obstáculos ocorridos no ciclo anterior do projeto. Além disso, com as metodologias
ágeis, as equipes de projetos são menores e lidam com o trabalho mais fechadamente, atentando
para o compartilhamento do conhecimento e tendo um retorno das ações quase que instantâneo.
Dentre as metodologias ágeis existentes, as mais comuns são: (a) Extreme Programming (XP);
(b) Scrum; (c) Crystal Methodology; (d) Dynamic Systems Development Methodology (DSDM);
(e) Rapid Application Development (RAD); (f) Adaptive Software Development; (g) Lean
Development; e (h) Feature-Driven Development.
Foi escolhida nesse trabalho a metodologia ágil Scrum devido a alguns fatores essenciais. como o
fato de as características do Scrum oferecerem um bom suporte ao acompanhamento do projeto,
dividindo as atividades em ciclos menores.
Scrum é uma metodologia leve criada por Jeff Sutherland de forma a pertencer à Comunidade
Ágil. Charvat (2003, np) afirma que o nome Scrum veio do jogo rúgbi, e, de uma perspectiva
metodológica, Scrum refere-se ao mecanismo usado no rúgbi para pegar uma bola fora do jogo e
retorná-la à partida. Criada para ser uma metodologia ágil e leve, a Scrum é focada no
desenvolvimento de software. O criador da Scrum aponta que ela é formada basicamente por dois
pilares: (a) força de ação e (b) a adaptabilidade (CHARVAT, 2003, np), onde:
a) força de ação: quando as tarefas são distribuídas, e seus participantes são responsáveis por
dimensionar o que terá que ser feito. A equipe faz o que ela pode fazer de melhor em cada
incremento. Enquanto a equipe trabalha, ela somente interage com o gerente para tratar o que está
no caminho de suas atividades e o que precisa ser removido para o alcance da produtividade nas
tarefas; e
b) adaptabilidade: Scrum usa o termo “ponto de equilíbrio”. A equipe mantém o equilíbrio
durante cada interação, deixando do “lado de fora” as interrupções ou distúrbios.
Os incrementos são pontuados a cada 30 dias, e os integrantes podem evoluir o que pode ser feito
no próximo incremento.
46
De acordo com Schwaber e Beedle (2002, np), o ciclo de vida de um projeto baseado na
metodologia Scrum é formado basicamente por quatro fases: (1) Planejamento (Planning); (2)
Preparação (Staging); (3) Desenvolvimento (Development); e (4) Publicação (Release). A
execução de um ciclo contendo essas fases, forma o que é chamado na Scrum de Sprint (em
português, “correr uma curta distância o mais rápido que se pode”). A seguir, são apresentados
mais detalhes sobre essas fases.
A fase de planejamento tem como propósito o estabelecimento da visão, do conjunto de
expectativas e definição da margem de segurança da interação. Suas atividades basicamente são:
escrita da visão e definição dos recursos e do conjunto de artefatos do produto – também
chamado na definição original como “Product Backlog”.
A fase de preparação apresenta como propósito a identificação de mais requisitos e a priorização
suficiente para a primeira interação. Nas atividades ficam como essenciais: o planejamento, o
desenvolvimento exploratório e os protótipos.
Já a terceira fase, a de desenvolvimento, tem como essência a realização das atividades para a
entrega de versão pronta em séries de 30 dias. As atividades principais são: planejamento de cada
interação do Sprint, definição do Backlog do Sprint e estimativas. Além dessas, há reuniões
diárias, chamadas de “Scrum meetings”, e revisão do ciclo, chamada de “Scrum review”.
Por último, a fase de publicação aborda como fundamento a implantação da versão do software.
Suas principais atividades são: documentação, treinamento, marketing e vendas.
A execução desse conjunto de fases em um Sprint tem duração prevista de 30 dias. Antes de
qualquer Sprint ser iniciado, são definidas as funcionalidades requeridas para a interação a ser
iniciada, e, desta forma, oferecidas as condições para que a equipe do projeto desenvolva-os e
entregue-os. De acordo com Larman (2003, np), no final dos 30 dias, o gerente do projeto
inspeciona os resultados, avalia as mudanças no ambiente de negócios e determina os próximos
passos para o projeto. A meta é estabilizar os requisitos durante o Sprint em execução. Cada
Sprint, ou interação, opera sobre um número de itens de trabalho, identificado na metodologia
como Backlog . Os itens que formam o Backlog depois de definidos são priorizados juntamente
com os usuários. Nenhum item é externamente adicionado no Backlog de um Sprint em
47
execução. Itens internos, resultantes do Backlog original e previamente alocado, podem ser
adicionados para que o que foi estipulado para que o Sprint possa ser alcançado.
Durante a execução do Sprint, devem ocorrer, os “Scrum meetings”, que são reuniões diárias
rápidas, com duração máxima de 15 minutos, e que devem ter a participação de todos os
integrantes que formam a(s) equipe(s) (SCHWABER e BEEDLE, 2002, np). Nela são
identificados os obstáculos existentes nas atividades da equipe, além de um monitoramento mais
efetivo das atividades da equipe. Essas e outras medidas são definidas na metodologia com o
intuito de oferecer condições de completar o Sprint e o projeto com tanta qualidade quanto for
possível, mas na prática, essa qualidade tipicamente é inferior à estimada.
Segundo Charvat (2003, np) a Scrum é um processo criativo de conhecimento com alto nível de
compartilhamento de informação durante todo o ciclo e progresso do trabalho. Na Scrum, os
pontos chaves da Scrum são decidir a data de conclusão do produto e versão parcial, priorizar
funcionalidades e identificar recursos disponíveis, tendo como essencial a caracterização de uma
metodologia empírica.
Embora não seja uma metodologia que já exista há muitos anos, existem diversos relatos sobre os
resultados da aplicação da Scrum em projetos de construção de software. Schwaber e Beedle
(2002, np) relatam projetos que fizeram diferença com a Scrum. Eles foram categorizados em
aplicações ou sistemas de grande, médio e pequeno porte. Alguns desses relatos são:
a) aplicação de grande porte (projeto “IDX Web-enabled benefits suite"): a situação antes da
adoção da Scrum era de 300 pessoas exercendo suas funções em diversos projetos
relacionados. Um conjunto de 15 aplicações relacionadas foram desenvolvidas dentro de um
ano com a adoção da Scrum. Isso depois de três anos de luta para a entrega de uma aplicação,
quando a Scrum ainda não havia sido adotada;
b) aplicação de médio porte: desenvolvida durante 4 meses, com 20 pessoas atuando. Depois de
dois anos de luta, nos quais uma equipe com 160 colaboradores não tinha alcançado seu
objetivo, houve posteriormente a adoção da Scrum, resultando na redução na equipe, que
ficou com 20 desenvolvedores (e ainda com 10 novos). Em poucos meses, produziu-se com
sucesso um release para o produto; e
48
c) aplicação de pequeno porte (projeto da Individual Personal NewsPage): um mês, oito
pessoas. Depois de 9 meses sem entrega, a Scrum foi adaptada, e um release aproveitável
surgiu depois de 30 dias de iteração. Depois de 9 meses de releases, foram alcançados
objetivos além dos estabelecidos inicialmente.
2.5 RISCOS EM PROJETOS DE SOFTWARE
A Gestão de Risco é uma das principais disciplinas estabelecidas dentro de um Sistema de Gestão
de Segurança da Informação. É pela da identificação e parametrização do risco que a empresa
define quais são os controles que serão implementados em seu ambiente de negócio.
De acordo com a Metodologia de gerenciamento de projeto TenStep (2004, np) riscos se referem
às condições ou circunstâncias futuras que causarão impacto adverso no projeto e que estão fora
de controle da equipe do projeto. Em outras palavras, enquanto uma incidência problemática é
um problema que deve ser resolvido, um risco é um problema potencial que não ocorreu ainda.
Risco é uma característica comum para todos os projetos. Todos os projetos têm algum grau de
incerteza devido às suposições associadas a eles e ao ambiente no qual são executados. Os
projetos com um número elevado de riscos requerem gerenciamento de risco mais rigoroso, e a
gerência deverá estar mais focada neles. Embora os riscos não possam ser eliminados
completamente, muitos podem ser antecipados e controlados proativamente. A finalidade do
gerenciamento de riscos é identificar os fatores de riscos para o projeto e, então, estabelecer um
plano de gerenciamento dos riscos para minimizar a probabilidade de os riscos ocorrerem ou
minimizar os impactos no projeto.
O Gerenciamento de Riscos de Software consiste em avaliar e controlar os riscos que afetam o
projeto, processo ou produto de software. A análise de riscos é uma tarefa de grande importância
no gerenciamento de um projeto de software, embora, em muitos casos, essa atividade nem seja
considerada.
O seu objetivo é determinar um conjunto de passos a serem seguidos para determinar os riscos
envolvidos no projeto: identificação, avaliação, classificação, definição de estratégias para
administrar os riscos, resolução dos riscos etc.
49
Segundo Sommerville (2003, p. 70), pode-se pensar no risco como uma probabilidade de que
alguma circunstância adversa realmente venha a ocorrer. Os riscos podem ameaçar o projeto, o
software que está sendo desenvolvido ou a organização. Então, são relacionadas as categorias de
risco que podem ser definidas conforme descrição a seguir.
a. Riscos relacionados ao projeto : são riscos que afetam a programação ou os recursos do
projeto (exemplo: cronograma, planos para substituição de pessoal, planos para alocação de
pessoal alternativo, planos alternativos para equipamentos adicionais, insuficiente domínio de
uma tecnologia, se houver dependência com outros sistemas).
b. Riscos relacionados ao produto : são os riscos que afetam a qualidade ou o desempenho do
software que está em desenvolvimento (exemplo: levantamento de requisitos, requisitos
estarem insuficientemente especificados ou claros).
c. Riscos para os negócios: são os riscos que afetam a organização que está desenvolvendo ou
adquirindo o software (por exemplo: cronograma).
As pessoas e, por extensão, as organizações tomam atitudes em relação aos riscos que afetam a
exatidão da percepção dos riscos e a forma como respondem a eles. As atitudes em relação aos
riscos devem ser explicitadas sempre que possível. Uma abordagem consistente do risco que
atenda aos requisitos da organização deve ser desenvolvida para cada projeto, e a comunicação
do risco e o seu tratamento devem ser abertos e transparentes. As respostas a riscos refletem o
equilíbrio entre enfrentar riscos e evitar riscos considerados por uma organização (PMI, 2004, p.
256).
No entanto, não se pode esquecer que a complexidade dos estudos efetuados promove a
alavancagem dos procedimentos normalmente adotados.
O processo de gerenciamento de riscos, como todos os outros planejamentos
de projeto, é um processo iterativo, que continua ao longo do projeto. Uma vez
traçado um conjunto inicial de planos, a situação é monitorada. À medida que
mais informações sobre os riscos se tornam disponíveis, eles têm de ser
reavaliados e novas prioridades devem ser estabelecidas. Os planos para evitar
riscos e os planos de contingência podem ser modificados com o surgimento
de novas informações sobre os riscos (SOMMERVILLE, 2003, p. 71-72).
50
Os resultados do processo de gerenciamento de riscos devem ser documentados em um plano de
gerenciamento de riscos. Essa fase deve incluir uma discussão sobre os riscos apresentados pelo
projeto, uma análise desses riscos e os planos que são necessários para gerenciá-los. Quando for
apropriado o processo de gerenciamento, também pode incluir alguns resultados do
gerenciamento de riscos, isto é, planos específicos de contingência a serem ativados caso o risco
venha a ocorrer.
51
3.
PROCESSOS DOS MODELOS DE REFERÊNCIA COM ÊNFASE EM RISCOS
Neste capítulo será abordada a gerência de riscos de cada metodologias estudadas.
Sabendo-se que todos os riscos de um projeto não podem ser conhecidos quando do seu
planejamento, a identificação de riscos torna-se um fator crítico para o sucesso de uma equipe.
Cronogramas para as fases de desenvolvimento e estabilização devem considerar como fatores
fundamentais os pontos de risco de cada projeto.
3.1 PROCESSOS PMBOK® GUIDE
Em uma de suas revisões é que a gerência de riscos ganhou maior importância dentro do
PMBOK® Guide, tornando-se uma área de conhecimento. Até então a gerência de riscos era
abordada em segundo plano, dentro das demais áreas de conhecimento.
Desde então a gerência de riscos encontra-se no mesmo nível de importância de áreas mais
conhecidas da gerência de projetos, como, por exemplo, gerência de escopo, tempo, custo e
qualidade. A área de conhecimento Gerência de Riscos do Projeto tem como principal objetivo
“Aumentar a probabilidade e o impacto dos eventos positivos e diminuir a probabilidade e o
impacto dos eventos adversos ao projeto” (PMI, 2004, p. 237).
O PMBOK® Guide divide a gerência de riscos em seis processos. Cada um desses processos
ocorre pelo menos uma vez ao longo do ciclo de vida do projeto e se caracteriza por ter forte
integração com processos de outras áreas de conhecimento (PMI, 2004, p. 237). A seguir é
apresentada uma descrição de cada um dos seis processos de gerência de riscos do PMBOK®
Guide, numeradas de acordo com a Figura 13.
52
Figura 13: Visão geral do gerenciamento de riscos do projeto.
Fonte: (PMI, 2004, p. 239)
1 Planejamento da gerência de riscos: decisão sobre como abordar e planejar as atividades de
gerência de riscos do projeto.
53
2 Identificação dos riscos: identificação dos riscos que podem afetar o projeto e a documentação
de suas características.
3 Análise qualitativa dos riscos: realização de uma análise qualitativa dos riscos e das
condições para que se dê prioridade a seus efeitos sobre os objetivos do projeto.
4 Análise quantitativa dos riscos: medição da probabilidade e do impacto dos riscos, e
estimativa de suas implicações nos objetivos do projeto.
5 Planejamento de resposta aos riscos: desenvolvimento de procedimentos e técnicas para
destacar as oportunidades e reduzir as ameaças aos objetivos do projeto.
6 Monitoração e controle dos riscos: monitoração dos riscos residuais, identificação de novos
riscos, execução de planos de redução de riscos e avaliação da eficácia desses planos ao longo do
ciclo de vida do projeto.
Assim como os processos das demais áreas de conhecimento, os seis processos da gerência de
riscos do projeto são compostos de entradas, técnicas e saídas, conforme figura 13.
3.2 PROCESSOS DA NORMATIVA NBR ISO/IEC 12207 COM ÊNFASE EM RISCOS
A ISO/IEC 12207 formaliza os Processos do Ciclo de Vida do Software por meio de um
framework com terminologias de processos bem definidos, em vez de forçar a utilização de um
determinado modelo de ciclo de vida ou método de desenvolvimento de software.
A ISO/IEC 12207 é a primeira norma internacional que descreve em detalhes os processos, as
atividades e as tarefas que envolvem o fornecimento, o desenvolvimento, a operação e a
manutenção de produtos de software. A principal finalidade desta norma é servir de referência
para os demais padrões que venham a surgir. Lançada em agosto de 1995, ela é citada em quase
todos os trabalhos relacionados à engenharia de software desde então, inclusive aqueles relativos
à qualidade.
Esta norma divide os processos em três grandes classes: Processos fundamentais, Processos de
apoio e Processos organizacionais.
54
1) Processos fundamentais são compostos dos processos de manutenção, aquisição,
fornecimento, desenvolvimento e operação, responsáveis pelo início e pela execução do
desenvolvimento, da operação ou da manutenção do software durante o seu ciclo de vida.
2) Processos de apoio são compostos dos processos de documentação, gerência de
configuração, garantia da qualidade, verificação, validação, revisão conjunta, auditoria e
resolução dos problemas que têm o papel de auxiliar um outro processo.
3) Processos organizacionais são compostos dos processos de gerência, infra-estrutura,
melhoria e treinamento que implementam uma estrutura constituída de processos de ciclo de
vida e de pessoal associados, melhorando continuamente a estrutura e os processos.
A ISO/IEC 12207 apresenta um detalhamento de cada um dos processos acima. Define como
podem ser usados de diferentes maneiras por diferentes organizações (ou parte dessas),
representando diversos pontos de vista para essa utilização. Estas visões representam a forma
com que uma organização pode utilizar esses processos, agrupando-os de acordo com suas
finalidades e necessidades.
1) Visão de Contrato – dentro dos processos fundamentais, na visão do cliente e do fornecedor,
a integração dos processos de aquisição e fornecimento.
2) Visão Operacional – ainda dentro dos processos fundamentais, esta visão enfoca o operador
e os usuários, através do processo de operação.
3) Visão de Engenharia – esta visão proporciona a integração dos processos de manutenção e
desenvolvimento, favorecendo as equipes responsáveis por esses processos, dentro dos
processos fundamentais.
4) Visão de Equipe de Apoio – Integração dos processos de apoio.
A ISO/IEC 12207 está sendo alterada para ficar de acordo com a ISO/IEC 15504-5 (SPICE –
Software Process Improvement and Capability Determination ) – An Assessment Model and
Indicator Guindance [ISO/IEC 15504 1999]. Desta forma, a ISO/IEC 12207 substituirá os
processos da norma ISO/IEC 15504.
55
A melhoria de processos é realizada por meio de avaliações, que descrevem práticas usuais da
organização, de uma unidade organizacional ou de um projeto. A análise dos resultados é feita
em relação às necessidades do negócio da organização, levantando aspectos negativos e
positivos, como também os riscos envolvidos no processo em avaliação.
O processo de Gerência de Riscos, de acordo com a norma ISO 15504, é composto pelas
atividades:
1) definição do escopo da gerência de risco – determinar o escopo da gerência de risco que
será utilizada pelo projeto, de acordo com as políticas de gerência de risco organizacional.
2) Identificação de riscos – identificar riscos para o projeto, no início e durante a sua execução.
3) Análise e priorização de riscos – avaliar a probabilidade de ocorrência, o impacto, o tempo
de ocorrência, a causa e as relações entre os riscos para determinar a prioridade de aplicação
dos recursos para a redução desses riscos.
4) Definição da estratégia para gerir risco – definir uma estratégia apropriada para gerenciar
um risco ou um conjunto de riscos, em nível de projeto e em nível organizacional.
5) Definição das métricas – para cada risco ou conjunto de riscos, definir as métricas para
aferição da mudança na situação do risco e do progresso das atividades de redução.
6) Implementação da estratégia da gerência de risco – executar a estratégia definida para a
gerência de riscos, em nível de projeto e em nível organizacional.
7) Avaliação dos resultados – em pontos de controle predeterminados, aplicar as métricas
definidas para avaliar o progresso esperado e o nível de sucesso da estratégia da gerência de
risco.
8) Execução das ações corretivas – quando o progresso esperado na redução do risco não é
alcançado, executar ações corretivas para corrigir ou evitar o impacto do risco.
56
3.3 PROCESSOS DO MODELO DE REFERÊNCIA CMMI COM ÊNFASE EM RISCOS
A gerência de riscos em projetos é tratada pelo CMMI a partir do nível dois de maturidade em
que as áreas de processo Project Planning (planejamento do projeto) e Project Monitoring and
Control (monitoração e controle do projeto) já se incluem práticas de identificação, monitoração
e resposta aos riscos a medida que eles ocorram. Mas é a partir do nível três de maturidade que a
gerência de riscos ganha maior importância.
Para o CMMI, o objetivo do gerenciamento de riscos (Risk Management) é identificar problemas
antes que eles ocorram. Assim, atividades de tratamento para esses problemas (riscos) podem ser
planejadas e utilizadas quando necessário, mitigando impactos adversos sobre os objetivos a
serem atingidos (UNISINOS, 2005, p. 412).
A área de processo Risk Management é composta de três objetivos específicos (SEI, 2006, p.
421). São eles:
a) preparar para a gerência de riscos: é conduzida uma preparação para a gerência de riscos;
b) identificar e analisar os riscos: os riscos são identificados e analisados para determinar sua
importância; e
c) mitigar riscos: os riscos são tratados e mitigados, quando apropriado, para reduzir impactos
adversos nos objetivos a serem atingidos.
Além desses três objetivos específicos, a área de processo Risk Management possui também um
objetivo genérico: institucionalizar um processo definido.
Cada um desses objetivos é composto de um conjunto de práticas que servem como guia para
fazer com que o objetivo ao qual elas se relacionam seja atendido. Para satisfazer o modelo, todas
as práticas de todos os objetivos devem ser atendidas pelo processo. O quadro 1 apresenta as
práticas dos objetivos específicos e genéricos da área de processo de Risk Management.
57
Objetivos
SG 1 Preparar para o
gerenciamento de riscos
SG 2 Identificar e analisar riscos
SG 3 Mitigar riscos
GG 3 Institucionalizar um
processo definido
Práticas
SP 1.1 Determinar fontes e categorias de riscos
SP 1.2 Definir parâmentros de riscos
SP 1.3 Estabelecer uma estratégia de gerenciamento de riscos
SP 2.1 Identificar riscos
SP 2.2 Avaliar, categorizar e priorizar riscos
SP 3.1 Desenvolver planos de mitigação de riscos
SP 3.2 Implementar planos de mitigação de riscos
GP 2.1 Estabelecer uma política organizacional
GP 2.2 Planejar o processo
GP 2.3 Fornecer recursos
GP 2.4 atribuir responsabilidades
GP 2.5 Treinar as pessoas
GP 3.1 Estabelecer um processo definido
GP 2.6 Gerenciar configurações
GP 2.7 Identificar e envolver os Stakeholders relevantes
GP 2.8 Monitorar e controlar processo
GP 3.2 Coletar informações de melhorias
GP 2.9 Avaliar objetivamente a aderência
GP 2.10 Revisar o status com o nível mais alto de gerência
Quadro 1 - Relação das práticas referentes aos objetivos específicos e genéricos da área de processo Risk
Management do CMMI
FONTE: SEI, 2006, p. 328-437.
3.4 PROCESSOS DO MODELO DE REFERÊNCIA MPS-BR COM ÊNFASE EM
RISCOS
O processo de gerência de riscos no MPS-BR é definido no nível C, no qual se tem como
propósito identificar, gerenciar e reduzir continuamente os riscos nos níveis organizacionais e de
projeto (SOFTEX, 2005, p. 46).
Os passos a serem seguidos são:
GRI (Gerenciamento de riscos) 1. O escopo da Gerência de Riscos é determinado.
GRI 2. As origens e as categorias de riscos são determinadas, os parâmetros usados para
quantificação da probabilidade e severidade são definidos, e as ameaças e suas fronteiras para
cada categoria de risco são definidas.
GRI 3. As estratégias apropriadas para a Gerência de Riscos são definidas e implementadas.
58
GRI 4. Os riscos do projeto são identificados e documentados, incluindo seu contexto, as
condições e possíveis conseqüências para os riscos e as partes que serão afetadas.
GRI 5. Os riscos são priorizados, estimados e classificados de acordo com as categorias e os
parâmetros definidos.
GRI 6. Planos para a redução de riscos são desenvolvidos, podendo incluir níveis de risco e
ameaças, atividades para acompanhamento, responsáveis e análise de custo–benefício da
implementação dos planos.
GRI 7. Planos de contingência para riscos críticos são desenvolvidos.
GRI 8. Os riscos são analisados, e a prioridade de aplicação dos recursos para o monitoramento
desses riscos é determinada.
GRI 9. A situação de cada risco é periodicamente monitorada, e o plano de mitigação de risco é
implementado, e, quando este é apropriado, é estabelecido um cronograma e os recursos
necessários são comprometidos.
GRI 10. As medições de desempenho nas atividades de tratamento de risco são coletadas.
GRI 11. Ações apropriadas são executadas para corrigir ou evitar o impacto dos riscos.
3.5 PROCESSOS DO TEN STEP COM ÊNFASE EM RISCOS
Nesta metodologia a primeira vez que se executará uma avaliação dos riscos é no momento de
criar o documento de definição do projeto, em que são descritos uma visão geral do projeto, os
objetivos do projeto, o escopo, o impacto desse projeto, as estimativas de custos, as estimativas
de tempo e riscos. Essa avaliação é executada no passo 1 desta metodologia descrita a seguir
(TENSTEP, 2004, np).
Definir tarefas:
1) Determinar se o caso original do negócio ainda é válido.
2) Certificar-se de que os recursos necessários estarão disponíveis quando você necessitar deles.
59
3) Uma linha de partida de alto-nível a partir da qual o progresso possa ser comparado.
4) Validar os processos utilizados no projeto antecipadamente com o cliente.
Antes do início do ciclo de vida do projeto, uma série de itens deve ser definida no processo de
planejamento. Em projetos menores, muitas dessas condições são atendidas de maneira informal
ou implícita (TENSTEP, 2004, np), tais como:
1) O cliente aprova o início do planejamento. Normalmente, a aprovação implícita é
presumida para fazer com que o projeto seja iniciado. Contudo, se o projeto não tiver um caso
de negócios preparado e se não passar por um processo de priorização, a aprovação explícita
deverá ser obtida antes do início do planejamento do projeto.
2) O Projeto está definido. Isto é, documentado na Definição do Projeto, que contém objetivos,
escopo, hipóteses, orçamento etc. (para projetos médios ou pequenos, isto pode ser a
definição resumida do projeto ou uma solicitação de serviço).
3) O workplan do projeto é criado. Um workplan deve ser preparado e utilizado para gerenciar
o esforço. Isto inclui pontos de verificação sempre que o projeto puder ser avaliado para
assegurar a sua continuidade.
4) O cliente aprova o início do projeto. Isto significa uma Definição de Projeto assinada e
aprovada. O patrocinador deve assinar o documento para garantir a concordância.
5) Os procedimentos de gerenciamento do projeto são definidos e aprovados. Os
procedimentos devem estar definidos para que se possa descrever como o projeto gerenciará
incidências, comunicação, riscos, qualidade, escopo etc. Isto é especialmente verdadeiro para
grandes projetos, e menos importante quando um projeto se torna menor.
6) Os recursos da equipe do projeto são designados. Deve-se ter as pessoas certas para
contratar e para executar o projeto. Algumas vezes, projetos válidos e aprovados necessitam
ser atrasados porque as pessoas com as habilidades necessárias não estão disponíveis.
60
7) O processo de avaliação e identificação de riscos deve ocorrer durante todo o projeto em
uma base programada (mensal ou trimestral) ou na conclusão de um marco (milestone)
principal.
3.6 PROCESSOS DA NORMATIVA AS/NZS 4360:2004 COM ÊNFASE EM RISCOS
O padrão de AS/NZS 4360 foi desenvolvido para acomodar o setor público e as organizações na
gerência de risco. Sua aproximação da gerência de risco é muito genérica. Este padrão consiste
em processos como os ilustrados na figura 14.
Figura 14: Estrutura AS/NZS 4360.
Fonte: (YUSUFF, 2006, p. 7)
Para a AS/NZS 4360, a gestão de riscos envolve o estabelecimento de uma infra-estrutura e
cultura apropriadas e a aplicação de um método lógico e sistemático para estabelecer contextos,
bem como para identificar, analisar, avaliar, tratar, monitorar e comunicar os riscos associados a
qualquer atividade, função ou processo, de modo a minimizar perdas e maximizar ganhos para as
organizações.
61
As principais etapas do processo de gestão de riscos são (figura 15):
Figura 15: Principais etapas AS/NZS 4360:2004.
Fonte: (FERREIRA, 2006, np)
1) comunicação e consulta : comunicar e consultar as partes envolvidas internas e externas,
conforme apropriado, em cada etapa do processo de gestão de riscos e em relação ao
processo;
2) estabelecimento dos contextos: estabelecer os contextos externo, interno e da gestão de
riscos nos quais se desenvolverá o restante do processo. Devem ser estabelecidos os critérios
em relação aos quais os riscos serão avaliados, e deve ser definida a estrutura da análise;
3) identificação de riscos: identificar onde, quando, por que e como os eventos podem impedir,
atrapalhar, atrasar ou melhorar a consecução dos objetivos;
62
4) análise de riscos: identificar e avaliar os controles existentes. Determinar as conseqüências e
a probabilidade e, por conseguinte, o nível de risco. Tal análise deve considerar as diversas
conseqüências potenciais e como essas podem ocorrer;
5) avaliação de riscos: comparar os níveis de risco estimados com os critérios estabelecidos
previamente e considerar o balanço entre os benefícios potenciais e os resultados adversos.
Isso possibilita que sejam tomadas decisões quanto à extensão e à natureza dos tratamentos
necessários e quanto às prioridades;
6) tratamento de riscos: desenvolver e implementar estratégias e planos de ação específicos e
econômicos para aumentar os benefícios potenciais e reduzir os custos potenciais; e
7) monitoramento e análise crítica: é necessário monitorar a eficácia de todas as etapas do
processo de gestão de riscos. Isso é importante para a melhoria contínua.
3.7 ANÁLISE COMPARATIVA DAS PRÁTICAS
O Quadro 2 toma como base os processos que compõem a gerência de riscos do PMBOK®
Guide e apresenta uma comparação com as demais metodologias abordadas neste trabalho:
3.7.1 Resultados
Pode-se destacar que todas as metodologias comparadas possuem processos de planejamento,
identificação, análise e planejamento de resposta.
A atividade “Planejamento da gerência de risco” planeja e executa as atividades de
gerenciamento de riscos de um projeto.
A atividade “Identificar Riscos” aparece em todos os processos estudados, sua principal
finalidade é levantar os riscos associados ao projeto. Esta atividade é vital para o processo, pois
promove a identificação dos prováveis fatores e eventos associados a esses riscos, bem como o
impacto do risco no projeto.
A atividade “Análise de riscos” está dividida entre análise qualitativa e quantitativa de riscos. A
análise qualitativa de riscos é o processo para priorizar riscos para análise ou avaliação de sua
63
probabilidade de ocorrência e impacto. A análise quantitativa é o processo para analisar
numericamente o efeito dos riscos identificados.
Quadro 2 – Análise comparativa das práticas
A atividade “Planejar Respostas aos Riscos” tem o objetivo de definir os planos de ações
corretivas, preventivas e de contingência para o efetivo controle dos riscos. Esta atividade
aparece em todas as abordagens, com variações de nomenclatura. Ela apresenta a vantagem de
garantir a aplicação das definições do plano de gerência de riscos pelo monitoramento contínuo
do projeto.
A atividade “Monitoração e controle de riscos” é necessária para acompanhar os riscos
identificados, monitorar os riscos, identificar novos riscos, executar planos de respostas a riscos e
avaliar sua eficiência durante todo o ciclo de vida do projeto.
64
4
MODELO PARA GERÊNCIA DE ATIVIDADES COM ÊNFASE EM RISCOS DE
PROJETOS DE SOFTWARE
Risco é uma característica comum para todos os projetos. Todos os projetos têm algum grau de
incerteza devido às suposições associadas a eles e ao ambiente em que são executados. Os
projetos que têm um número elevado de riscos requerem gerenciamento de risco mais rigoroso, e
a gerência deverá ficar mais focada neles. Embora os riscos não possam ser eliminados
completamente, muitos podem ser antecipados. A finalidade do gerenciamento de riscos é
identificar os fatores de riscos para o projeto e então estabelecer um plano de gerenciamento dos
riscos para minimizar a probabilidade de eles ocorrerem ou minimizar os impactos no projeto.
4.1 ATIVIDADES PRELIMINARES
Este é o processo necessário para produzir uma definição preliminar de alto nível do projeto
usando o termo de abertura do projeto junto com outras entradas para os processos de iniciação.
Este processo aborda e documenta os requisitos do projeto e da entrega, os requisitos do produto,
os limites do projeto, os métodos de aceitação e o controle de alto nível do escopo. Em projetos
com várias fases, este processo valida ou refina o escopo do projeto para cada fase (PMI, 2004,
p.45). No PMI é feito no gerenciamento de integração do projeto.
Esta atividade preliminar é para orientação. Uma avaliação precisa deve ser executada caso a
caso, podendo haver um enquadramento diferente, dependendo de características e circunstâncias
específicas de cada risco.
Em função do resultado da atividade preliminar deve-se:
a) julgar o nível de profundidade do processo de Gerenciamento de Risco a ser aplicado;
65
b) dimensionar a equipe responsável pela revisão de segurança; e
c) elaborar as medidas mitigadoras preliminares.
Dada a análise, o planejador terá uma idéia do nível de risco preliminar e poderá passar para a
próxima ação: preparação do estudo.
4.2 PREPARAÇÃO DO ESTUDO
A preparação de uma declaração do escopo detalhada do projeto é essencial para o sucesso do
projeto e são desenvolvidas a partir das principais entregas, premissas e restrições, que são
documentadas durante a iniciação do projeto, na declaração do escopo preliminar do projeto.
Durante o planejamento, o escopo do projeto é definido e descrito mais especificamente porque
se conhecem mais informações sobre o projeto. Necessidades, desejos e expectativas das partes
interessadas são analisados e convertidos em requisitos. As premissas e restrições são analisadas
para garantir que estejam completas, adicionando-se mais premissas e restrições conforme
necessário. A equipe do projeto e outras partes interessadas, que possuem uma visão mais clara
da declaração do escopo preliminar do projeto, podem realizar e preparar as análises (PMI, 2004,
p. 109). No PMI é feito no gerenciamento do escopo do projeto.
Nesta atividade é feito um planejamento com antecedência, ou seja, um trabalho de preparação
para a gerência de risco.
4.3 IDENTIFICAÇÃO DAS INFORMAÇÕES SOBRE A ORGANIZAÇÃO/PROJETO
Nesta fase, trata-se de fazer os levantamentos de dados da organização/projeto. A obtenção das
informações específicas e gerais da empresas, bem como os seus objetivos, produtos, serviços,
clientes, fornecedores, processos e atividades internas, além das informações mercadológicas
sobre a organização.
4.4 INÍCIO FORMAL DO ESTUDO
Assim que for feito todo o levantamento do projeto, o próximo passo são os processos de início,
nos quais todos os membros da equipe têm uma visão clara do que desejam conseguir das
necessidades da empresa em relação ao projeto. Esta fase se concentra na identificação do
66
problema ou no gerenciamento de riscos. Todas as partes envolvidas no gerenciamento de riscos
precisam definir objetivos, suposições e restrições durante o processo.
4.5 REALIZAÇÃO DAS ENTREVISTAS DE LEVANTAMENTO
As entrevistas com participantes experientes do projeto, partes interessadas no projeto e
especialistas no assunto podem identificar os riscos. As entrevistas são uma das principais fontes
de coleta de dados sobre identificação de riscos (PMI, 2004, p. 248).
Esta etapa é fundamental para o desenvolvimento de trabalho, devendo contemplar todas as
informações objetivas e subjetivas, os condicionamentos e os limites do projeto.
O levantamento deve responder qual o objetivo do trabalho, e descrever os problemas que
indicam necessidade do projeto e os possíveis benefícios com a sua implantação.
4.6 PLANEJAR A GERÊNCIA DE RISCO
Um planejamento cuidadoso e explícito aumenta a possibilidade de sucesso dos outros processos
de gerenciamento de riscos. O planejamento do gerenciamento de riscos é o processo de decidir
como abordar e executar as atividades de gerenciamento de riscos de um projeto. O planejamento
dos processos de gerenciamento de riscos é importante para garantir que o nível, o tipo e a
visibilidade do gerenciamento de riscos estejam de acordo com o risco e a importância do projeto
em relação à organização para fornecer tempo e recursos suficientes para as atividades de
gerenciamento de riscos e para estabelecer uma base acordada de avaliação de riscos. O processo
de planejamento do gerenciamento de riscos deve ser terminado já no início do planejamento do
projeto, pois ele é essencial para executar com sucesso os outros processos (PMI, 2004, p. 242).
Os planos básicos para executar as atividades de gerenciamento de riscos são definidos nessas
reuniões. Serão desenvolvidos os elementos de custo de riscos e as atividades do cronograma de
riscos para serem incluídos no orçamento e no cronograma do projeto, respectivamente.
Nesta etapa as equipes de projeto realizam reuniões de planejamento para desenvolver o plano de
gerenciamento de riscos.
67
4.7 IDENTIFICAR RISCOS
A identificação de riscos determina os riscos que podem afetar o projeto e documenta suas
características. A identificação de riscos é um processo iterativo porque novos riscos podem ser
conhecidos conforme o projeto se desenvolve durante todo o seu ciclo de vida. Objetiva um
levantamento preliminar de todas as possibilidades de riscos existentes no projeto. O aspecto
mais importante da atividade de identificação de riscos é compor uma documentação
formalizando os dados coletados.
Listar os riscos do projeto de software por meio de reuniões com os técnicos envolvidos no
projeto, na qual são descritos os riscos identificados, incluindo suas causas-raiz e as premissas
incertas do projeto.
Listar respostas possíveis a um risco, as quais podem ser identificadas durante o processo de
identificação de riscos. Essas respostas, se identificadas, podem ser úteis como entradas do
processo de planejamento de respostas a riscos.
4.8 ANALISAR RISCOS
De acordo com o PMI, os riscos devem ser analisados qualitativamente e quantitativamente.
A análise qualitativa dos riscos é feita pela definição da probabilidade de ocorrência do risco e da
sua severidade. Para cada um dos riscos identificados, deverá ser feita essa análise.
Muitas vezes a análise quantitativa é feita junto com a análise qualitativa. O objetivo da primeira
é analisar numericamente a probabilidade de cada risco, de forma a poder, posteriormente, definir
o seu tratamento.
Segundo Bastos et al. (2006, p. 121), a análise de riscos é o processo de avaliar riscos, ameaças,
controles e vulnerabilidades.
Nesta atividade são caracterizados os aspectos mais importantes de cada risco com a finalidade
de explorar as melhores estratégias de mitigação. De forma geral, os riscos são categorizados e
priorizados, segundo critérios específicos estabelecidos, para tornar a gerência concentrada nos
riscos considerados prioritários, ou seja, consiste em um processo de identificação e avaliação
68
dos fatores de risco presentes e de forma antecipada, possibilitando uma visão do impacto
negativo causado.
1) Avaliar a probabilidade e as conseqüências desses riscos.
2) Avaliar a probabilidade e a seriedade do risco.
3) A probabilidade pode ser muito baixa, baixa, moderada, alta ou muito alta.
4) Os efeitos do risco podem ser catastróficos, sérios, toleráveis ou insignificantes.
4.9 PLANEJAR RESPOSTAS AOS RISCOS
O planejamento de respostas a riscos é o processo de desenvolver opções e determinar ações para
aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto. O planejamento dos
riscos envolve a escolha dos planos para responder aos riscos. Isso envolve a definição do
caminho mais realista, de melhor custo x benefício e também possível de ser executado. Outras
soluções poderão atrasar muito o projeto, caso venham a ser escolhidas. Tudo isto deverá ser
avaliado com muito cuidado.
O planejamento é uma atividade da gerência de risco que envolve, em geral, a determinação dos
riscos a serem gerenciados, dos planos de ação para os riscos sob controle da gerência e dos
planos de contingência para os riscos que se encontram além das capacidades de mitigação, ou
seja, esses planos devem ser elaborados.
Nesta abordagem, o gerente do projeto analisa o impacto do risco no projeto se caso ele ocorrer e
decide não fazer nada. Há três razões para um gerente de projeto tomar essa decisão (TENSTEP,
2004, np):
1. O gerente do projeto poderá decidir que o impacto potencial do risco no projeto não é
suficiente para requerer uma resposta ao risco. Tipicamente, essa decisão é tomada nos casos em
que o risco tem o impacto de nível baixo no projeto. Também, em muitos casos, essa decisão
pode ser tomada para os riscos que têm um impacto de nível médio no projeto.
2. O gerente do projeto poderá sentir que o risco deverá ser gerenciado, mas o impacto do risco
no projeto não é suficiente em comparação ao custo e ao esforço requerido para gerenciá-lo.
69
3. Poderá não haver maneiras práticas ou razoáveis disponíveis para gerenciar o risco. Essa razão
é diferente das outras razões em que o custo é maior que os benefícios. Neste caso, não há uma
maneira prática para gerenciar o risco, mesmo se o risco for identificado como de nível elevado.
4.10
MONITORAR RISCOS
As respostas a riscos planejadas incluídas no plano de gerenciamento do projeto são executadas
durante o ciclo de vida do projeto, mas o trabalho do projeto deve ser monitorado continuamente
para encontrar novos riscos e mudanças nos riscos.
O monitoramento dos riscos é a observação da efetividade dos planos de ação na execução do
desenvolvimento do projeto de software, ou seja, acompanhamento do risco. O objetivo é prover
informações precisas e contínuas para habilitar a gerência de risco a atuar de forma preventiva e
não reativa aos eventos adversos. Como benefício dessa atividade, tem-se a melhor compreensão
do andamento do projeto por parte dos membros das equipes de desenvolvimento.
Avaliar cada risco identificado regularmente para verificar se ele está se tornando mais ou menos
provável, avaliar se os efeitos do risco mudaram, e cada risco-chave deve ser discutido nas
reuniões.
Neste caso, o gerente do projeto não gerencia proativamente o risco, mas o monitora ao longo do
tempo para ver se há mudança na sua probabilidade de ocorrência. Se probabilidade de
ocorrência aumentar, então a equipe do projeto deverá formular uma resposta para minimizar o
impacto. Essa abordagem pode funcionar para os riscos que terão grande impacto negativo no
projeto, mas com pouca probabilidade de ocorrer. O gerente do projeto pode decidir não
desenvolver imediatamente um plano de resposta, mas cria um plano para responder ao risco
somente se ele ocorrer. A vantagem é que os recursos escassos são utilizados somente naqueles
riscos que têm uma probabilidade maior de ocorrência. A desvantagem é que a demora em
responder ao risco poderá tornar menos provável que o risco possa ser minimizado futuramente
com sucesso.
Também, essa é uma boa abordagem pra identificar um risco que deve ser gerenciado, mas os
eventos que o provocam somente acontecerão em uma data distante no projeto. Por exemplo, se
os eventos que provocam o risco acontecerão somente daqui a nove meses, poderá não fazer
70
sentido utilizar os recursos escassos para gerenciar o risco nesse momento. A melhor abordagem
poderá ser monitorar o risco em uma base mensal. É possível que, ao longo do tempo, o risco
possa desaparecer devido a outras circunstâncias. Entretanto, se o risco não desaparecer, a equipe
do projeto necessitará gerenciá-lo futuramente (TENSTEP, 2004, np).
4.11
CONTROLAR RISCOS
Segundo Bastos et al. (2006, p. 122), o controle é uma forma de tentar reduzir as causas dos
riscos, evitando desta maneira a sua ocorrência ou, pelo menos, reduzindo a freqüência de
ocorrência.
A atividade de controle dos riscos é uma tentativa de reduzir as causas dos riscos, evitando desta
maneira a sua ocorrência ou, pelo menos, reduzindo a freqüência de ocorrência. O controle dos
riscos envolve alteração das estratégias de mitigação, quando se fizer necessário, ou seja,
medidas para mitigar o risco. A utilização de cronogramas é essencial para a atividade de
controle em gerência de riscos, pois o agendamento explícito de tarefas de mitigação de riscos
facilita o acompanhamento do progresso e da eficácia desses planos.
Controlar os riscos é acompanhar a evolução dos riscos no desenvolvimento dos projetos, isso
envolve a avaliação permanente dos riscos e, caso algum já tenha ocorrido, como funcionou a
resposta definida com à sua ocorrência. Muitas vezes é preciso mudar de estratégia de resposta,
caso uma opção anteriormente escolhida no seu planejamento não tenha funcionado
corretamente. Outras vezes será preciso verificar e acompanhar o plano de contingência, caso o
risco já tenha virado um problema.
4.12
COMUNICAR OS RISCOS
A comunicação entre as equipes e os membros do projeto de software é um dos fatores mais
importantes para a realização bem-sucedida da gerência de riscos. Riscos, problemas e crises
podem aparecer quando a estrutura de comunicação é debilitada em uma organização.
4.13
DESENVOLVIMENTO E RECOMENDAÇÕES
Esta é uma necessidade de forma a obter resultados que tenham impacto imediato.
71
Recomendações que foram identificadas a partir de experiências na coordenação de projetos de
desenvolvimento de software, tendo-se todo cuidado e atenção para o gerenciamento de riscos.
4.14
DOCUMENTAÇÃO E COMUNICAÇÃO DE RESULTADOS
O simples fato de implementar o instrumento de comunicação entre as várias funções e níveis da
organização garante agilidade e confiabilidade do gerenciamento de riscos. O processo de
comunicação inclui o estabelecimento de planos das atividades de gerência de riscos.
A documentação em uma empresa é fundamental para garantir o controle de implantação do
Sistema de Gestão. Vem facilitar uma avaliação permanente e possíveis revisões, caso necessário,
além de reforçar a conscientização dos colaboradores sobre responsabilidades no cumprimento
dos objetivos e das metas previamente estabelecidos.
A Figura 16 apresenta o processo de gerência de riscos do modelo.
74
Figura 16: Processo de gerência de riscos.
75
5
ESTUDO DE FERRAMENTAS DE GERÊNCIA DE RISCO
Para complementar o estudo das metodologias, foi realizado um estudo em ferramentas de
gerência de riscos, especialmente as características de quatro ferramentas de gerência de
riscos disponíveis no mercado.
Todas as informações foram obtidas por meio dos sites dos desenvolvedores das ferramentas.
A veracidade das informações contidas nos sites não foi em nenhum momento questionada.
Em uma busca realizada na Internet, encontraram-se algumas ferramentas para gerência de
riscos de projetos. Para a análise, escolheram-se as ferramentas cujos sites apresentavam o
maior número de informações: Risk Radar, RiskTrak, @Risk e RiskFree.
5.1 RISK RADAR
A ferramenta Risk Radar foi desenvolvida sobre o Microsoft Access pela ICE (Integrated
Computer Engineering <http://www.iceincusa.com/SupportLibrary.aspx) da ASC (American
System Corporation).
O processo de gerência de riscos contempla os processos da gerência de riscos descritos pelo
CMM nível 3 do SEI, IEEE Standard 1540 for Software Life Cycle Processes e outros
padrões (ICE, 2006, np).
Esta ferramenta permite que gerentes de projeto controlem os riscos em todos os tipos do
projeto.
Ajuda os gerentes de projeto a categorizar, priorizar, mitigar o risco do projeto, manter os
riscos da prioridade mais elevada em vista da gerência. Isto permite que gerentes tomem
decisões do risco antes que tenham uma possibilidade à transição nos problemas que afetam o
76
custo, a programação ou o desempenho do projeto. O mais importante, Risk Radar®,
incentiva uma comunicação de risco aberta e honesta por todos os níveis do projeto.
Risk Radar® inclui 22 relatórios que permitem aos gerentes de projeto rapidamente e
facilmente verem e seguirem dados importantes do risco. Fornece a habilidade de estabelecer
valores padrão para categorizar os riscos do projeto, dar prioridade de acordo com a
probabilidade da ocorrência, do impacto do risco e da exposição do risco.
5.2 RISKTRAK
A
ferramenta
RiskTrak
foi
desenvolvida
pela
Risk
Services
&
Technology
(<http://www.risktrak.com>).
A ferramenta ajuda na identificação, definição, estimativa e nas análises de riscos em projetos
e/ou programa a fim de mitigar os riscos.
5.3 @RISK
A
ferramenta
@Risk
foi
desenvolvida
pela
empresa
americana
Palisade
(<http://www.palisade.com>). O foco da ferramenta é analisar e quantificar riscos de negócios
e auxiliar nas tomadas de decisão.
O @Risk lhe permite visualizar todos os resultados possíveis de uma decisão, indicando a
probabilidade de cada uma ocorrer. Assim, são disponibilizadas todas as informações
necessárias para optar pela melhor alternativa, calculando o risco existente e o que poderá ser
evitado (PALISADE, 2006, np).
O @Risk é completamente compatível com o MS-Excel. Os recursos do @Risk podem ser
integrados às suas planilhas, adicionando uma análise de risco para os seus modelos
existentes.
5.4 RISKFREE
O processo de gerência de riscos que foi implementado na ferramenta é semelhante ao
proposto pelo PMBOK® Guide. A única diferença é que, no processo que foi implementado
na ferramenta, as análises qualitativa e quantitativa foram unificadas em uma única atividade
de análise.
77
Figura 17: Equivalência entre os processos de gerência de riscos do PMBOK® Guide e da ferramenta Risk
Free.
Fonte: (SILVEIRA; KNOB, 2005, p. 54)
Além disso, a ferramenta contempla as práticas da área de processo de gerência de riscos
(Risk Management) do modelo CMMI (SEI, 2006). Qualquer organização que queira
implantar um processo de gerência de riscos baseado nessas práticas poderá utilizar a
ferramenta como um instrumento de auxílio para atender satisfatoriamente ao que é exigido
pelo CMMI no que diz respeito à gerência de riscos.
5.5 ANÁLISE COMPARATIVA
Tabela 1 – Tabela comparativa das ferramentas analisadas e modelo proposto de gerenciamento de riscos.
78
A Tabela 1 apresenta uma comparação das ferramentas analisadas e das atividades de
gerenciamento de riscos.
As ferramentas estudadas não abordam especificamente a gerência de riscos em projetos de
software, mas sim a gerência de riscos como um todo. Percebe-se também que nenhuma das
ferramentas é capaz de fazer um estudo detalhado de todo o projeto.
79
6
CONCLUSÕES E FUTUROS TRABALHOS
6.1 CONCLUSÕES
Este trabalho apresentou conceitos de gerência de riscos em projetos de software, em que
foram selecionados processos, como CMMI, MPS-BR, NBR ISO/IEC 12207, TenStep e
AS/NZS 4360:2004, e aplicado como estudo de caso um conjunto de práticas para avaliar
como foram desenvolvidas as atividades de gerência de riscos em projeto de software.
Muitas lições foram aprendidas ao longo da elaboração deste trabalho. Entre elas, destaca-se a
constatação prática da importância da utilização de um processo de desenvolvimento e da
gerência efetiva dos riscos durante todo o ciclo de vida do projeto.
A importância de uma metodologia e da utilização de modelos para o gerenciamento de riscos
é fundamental. Não se deve esquecer de que muitas vezes a conscientização, em geral, vem de
forma dolorosa, quando os serviços ou produtos não atendem satisfatoriamente à necessidade
dos clientes.
O conjunto de atividades voltadas para a gerência de riscos propicia ao gerente de projeto uma
ampla visão dos projetos em execução, focando diversos aspectos, tais como garantia da
qualidade, progresso, produtividade, acompanhamento de esforço e variação de tamanho do
software. A utilização de informações de projetos realizados e dos projetos já em andamento,
com certeza, facilitará a atuação e a decisão da gerência para a conclusão do projeto em
questão.
6.2 FUTUROS TRABALHOS
Alguns possíveis trabalhos futuros relacionados ao trabalho de conclusão de curso são
apresentados a seguir.
1. Implementar ferramentas que suporte o modelo;
80
2. Validar o modelo para diversas situações; e
3. Implantar o modelo para avaliação das atividades de gerenciamento de riscos em projetos
de software.
81
7
REFERÊNCIAS BIBLIOGRÁFICAS
AGILE, Manifesto. Agile Manifesto. Disponível em: <http://agilemanifesto.org>. Acesso em:
04 nov. 2005.
AMBLER, Scott W. Gerenciamento Ágil de Projetos – Colocando o desenvolvimento de
software em ordem. Revista MundoPM – Project Management, 11. ed. Mundo, out./nov.
2006.
BASTOS, Anderson et al. Base de Conhecimento em teste de Software. Niterói: Traço &
Photo, 2006.
CHARVAT, Jason. Project Management Methodologies – Selecting, Implementing, and
Supporting Methodologies and Processes for Projects. John Wiley & Sons: New Jersey, 2003.
CHAU, Thomas; MAURER, Frank; MELNIK, Grigori. Knowledge Sharing: Agile Methods
vs. Tayloristic Methods. 2002.
COOPER, Dale F. et al. Project Risk Management Guidelines - Managing Risk in Large
Projects and Complex Procurements. Broadleaf Capital International, 2005.
EUP - ENTERPRISE UNIFIED PROCESS. History of the Unified Process. Disponível em:
<http://www.enterpriseunifiedprocess.com/>. Acesso em: 1 nov. 2006.
FERREIRA, Geraldo. AS/NZS 4360:2004 Australian Standard for Risk Management.
Disponível em: <http://www.modulo.com.br/checkuptool/artigo_14.htm>. Acesso em: 6 set.
2006.
FOWLER, Martin. The New Methodology, Thought Works, 2003. Disponível em:
http://www.martinfowler.com/articles/newMethodology.html>. Acesso em: 09 de novembro
de 2006
HOWES, Norman R. Modern Project Management - Successfully Integrating Project
Management Knowledge Areas and Processes. AMACOM – American Management
Association, 2001.
82
ICE – Integrated Computer Engineering. Risk Radar – Risk Management Database.
Disponível
em:
<http://www.iceincusa.com/16CSP/content/software/tools/r_radar/risk_rad.htm>. Acesso em:
2 nov. 2006.
JALOTE, Pankaj. Software Project Management in Practice. Addison Wesley, 2002.
LARMAN, Craig. Agile and Iterative Development: A Manager's Guide. Addison Wesley,
2003.
MARTINS, Vidal. O Processo unificado de desenvolvimento de software. 2003.
Disponível em: http://www.pr.gov.br/batebyte/edicoes/1999/bb89/software.htm. Acesso em: 1
nov 2006.
PALISADE. Decisions With Vision. Disponível em: <http://www.palisade.com>. Acesso em:
2 nov. 2006.
PMA Professional Management. Metodologia para gerenciamento de projetos. Disponível
em: <http://www.pma.com.br>. Acesso em: 13 ago. 2006.
PMI Project Management Institute. Um Guia do Conjunto de Conhecimentos em
Gerenciamento de Projetos (Guia PMBOK®). 3 ed. Project Management Institute, Four
Campus Boulevard, Newtown Square, Pensylvannia, USA, 2004. Tradução oficial de: “A
Guide to the Project Management Body of Knowledge” (PMBOK® Guide).
PRESSMAN, Roger S. Engenharia de Software. Markron Books, 1995.
Project Risk Management Handbook. Office of Project Management Process Improvement.
5. ed. 2003.
ROCHA, Ana Regina Cavalcanti da; MALDONADO, José Carlos; WEBER, Kival Chaves.
Qualidade de software. São Paulo: Prentice Hall, 2001.
SCHWALBE, Kathy. Information Technology - Project Management. 3. ed., 2004.
SCHWABER, Ken; BEEDLE Mike. Agile Sofware Development with Scrum. 2002.
SEI – Software Engineering Institute. CMMI® for Development, Version 1.2. 2006.
Disponível em: <http://www.sei.cmu.edu>. Acesso em: 5 nov. 2006.
SILVA, Edna Lúcia; MENEZES, Estera Muszkat. Metodologia da pesquisa e elaboração de
dissertação. Florianópolis, 2005.
83
SILVEIRA, Filipi Pereira; KNOB, Flávio Franco. RiskFree - Uma ferramenta de apoio à
gerência de riscos em projetos de software. Porto Alegre, 2005.
SOFTEX. MPS.BR – Melhoria de Processo do Software Brasileiro – Guia geral. 2005.
Disponível em: <http://www.softex.br>. Acesso em 15 jun. 2006.
SOMMERVILLE, Ian. Engenharia de Software. Tradução de: André Maurício de Andrade
Ribeiro. Revisão técnica de: Kechi Himara. São Paulo: Addison Wesley, 2003.
TELES, Vinícius Manhães. Um Estudo de Caso da Adoção das Práticas e Valores do
Extreme
Programming.
2005.
Disponível
em:
<http://www.improveit.com.br/xp/dissertacaoXP.pdf>. Acesso em: 27 out. 2006.
TENSTEP. Processo de Gerenciamento de Projetos.
<http://www.tenstep.com.br>. Acesso em: 13 set. 2006.
2004.
Disponível
em:
UNISINOS. Visão Geral do CMMI. Traduzido de: O. Galarraga. São Leopoldo/RS, 2005.
SEI.
VALERIANO, Dalton L. Gerenciamento Estratégico e Administração por Projetos. São
Paulo/SP: Makron Books, 2001.
VIEIRA, Eduardo Newton Oliveira. Gerenciando Projetos na Era de Grandes Mudanças Uma
breve
abordagem
do
panorama
atual.
Disponível
em:
<http://www.pmisp.org.br/exe/artigos/EduardoNewton_ArtigoGProjetosI.pdf>. Acesso em: 8
maio 2006.
YUSUFF, Mohamed Noordin. Contemporary Approaches to Project Risk Management:
assessment & Recommendations. 2006.
84