UNIVERSIDADE DO VALE DO ITAJAÍ MÔNICA PIERINI DE …siaibib01.univali.br/pdf/Monica Pierini de...

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





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





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õe-se 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 PA RA 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 PROCESSOS DO TEN STEP COM ÊNFASE EM RISCOS .............................................58

3.6 PROCESSOS DA NORMATIVA AS/NZS 4360:2004 COM ÊNFASE EM RISCOS..... 60

3.7 ANÁLISE COMPARATIVA DAS PRÁTICAS ................................................................. 62

3.7.1 Resultados .......................................................................................................................... 62

4 MODELO PARA GERÊNCIA DE ATIVIDADES COM ÊNFASE EM RI SCOS 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 dosmodelos de referência

Estudo e identificação daspráticas

Análise comparativa

Estudo do conjunto de práticas selecionadas

Fundamentação das práticas selecionadas

Definição de um modelo para avaliação dasatividades 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 PA RA

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 norte-

americano 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) 3 É 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)

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 SOFTWA RE

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 E M 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 Práticas SP 1.1 Determinar fontes e categorias de riscos SP 1.2 Definir parâmentros de riscos

SG 1 Preparar para o gerenciamento de riscos

SP 1.3 Estabelecer uma estratégia de gerenciamento de riscos SP 2.1 Identificar riscos

SG 2 Identificar e analisar riscos SP 2.2 Avaliar, categorizar e priorizar riscos SP 3.1 Desenvolver planos de mitigação de riscos

SG 3 Mitigar 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

GG 3 Institucionalizar um processo definido

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 RI SCOS 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/P ROJETO

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. 2004. Disponível em: <http://www.tenstep.com.br>. Acesso em: 13 set. 2006.

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.

UNIVERSIDADE DO VALE DO ITAJAÍ MÔNICA PIERINI DE …siaibib01.univali.br/pdf/Monica Pierini de...

Documents

Transcript of UNIVERSIDADE DO VALE DO ITAJAÍ MÔNICA PIERINI DE …siaibib01.univali.br/pdf/Monica Pierini de...