GERENCIAMENTO DE PROJETO COM BASE NA ADAPTAÇÃO DE RISCOS Pedro Henrique Maia da Silva Teixeira

(1)

DCC/NPPG

GERENCIAMENTO DE PROJETO COM BASE

NA ADAPTAÇÃO DE RISCOS

Pedro Henrique Maia da Silva Teixeira

(2)

Pedro Henrique Maia da Silva Teixeira

Monografia apresentada ao Curso de Pós-Graduação em Gerenciamento de Projetos, da Escola Poli técnica, da Universidade Federal do Rio de Janeiro.

Orientador:

Ricardo Maia Cister

(3)

ii

Pedro Henrique Maia da Silva Teixeira

Orientador:

Ricardo Maia Cister

Monografia submetida ao Curso de Pós-Graduação em Gestão e Gerenciamento de Projetos, da Escola Politécnica, da Universidade Federal do Rio de Janeiro - UFRJ, como parte dos requisitos necessários à obtenção do título de Especialista em Gestão e Gerenciamento de Projetos.

Aprovada por:

_______________________________

Eduardo Linhares Qualharini

_______________________________

Isabeth da Silva Mello

_______________________________

Ricardo Maia Cister

(4)

iii

TEIXEIRA, Pedro Henrique Maia da Silva

Gerenciamento de Projeto com base na adaptação de riscos / TEIXEIRA, P. H. M. da S. – Rio de Janeiro: UFRJ, EP, 2009.

XX, 43 f.: il.; 29,7 cm.

Orientador: Ricardo Maia Cister

Monografia (especialização) – UFRJ / Escola Politécnica / Curso de Especialização em Gestão e Gerenciamento de Projetos, NPPG – UFRJ, 2009. Referências Bibliográficas: f XX-YY.

(5)

iv

GERENCIAMENTO DE PROJETO COM BASE NA ADAPTAÇÃO DE RISCOS

Pedro Henrique Maia da Silva Teixeira

Orientador: Ricardo Maia Cister

Resumo da Monografia submetida ao corpo docente do curso de Pós-Graduação em Gestão e Gerenciamento de Projetos – Universidade Federal do Rio de Janeiro – UFRJ, como parte dos requisitos necessários à obtenção do título de Especialista em Gestão e Gerenciamento de Projetos.

Este trabalho propõe um método de adaptação do modelo de gerenciamento de projetos baseados nos resultados da análise de risco, tendo como principal objetivo diminuir o esforço do gerenciamento de projetos direcionados à Tecnologia da Informação. O método sugere um ciclo interativo do planejamento e fornece um conjunto de formulários adaptáveis. Através da análise de risco, busca-se identificar as áreas de conhecimento as quais se pode agregar mais valor, diminuindo custo e efetuando um planejamento melhor dimensionado para as áreas que oferecem mais riscos ao projeto. Para as áreas menos impactadas, deve-se realizar uma revisão e adequação em interações futuras.

Palavras-chaves: Gerenciamento de Projetos, Risco e Adaptação

(6)

v

1. INTRODUÇÃO ... 1

1.1. Objetivo ... 1

1.2. Justificativa ... 1

1.3. Limitações da pesquisa ... 1

1.4. Metodo empregado ... 2

2. ESTADO DA ARTE ... 3

2.1. Gerenciamento de projetos ... 3

2.2. Sequenciamento das atividades ... 4

2.3. Análise de riscos ... 8

2.3.1. Modelos de avaliação de riscos ... 9

2.3.1.1. Moynihan ... 9

2.3.1.2. Karolak ... 12

2.3.2. GUT (Gravidade, Urgência e Tendência) ... 15

2.4. Modelos ageis para gerenciamento de software ... 16

A - Agile Project Management (APM) ... 16

B - unified process (UP) ... 17

C - scrum ... 18

D - extreme programming (XP)... 19

E - feature drivem development (FDD) ... 20

F - modelagem ágil (agile modeling AM) ... 21

3. TRABALHO REALIZADO ... 23

3.1. Seqüenciamento das atividades ... 23

3.2. Processo de adaptação ... 26

3.3. Formulários para planejamento do projeto ... 31

4. CONSIDERAÇÕES FINAIS ... 39

4.1. Resultado adicional do trabalho ... 39

4.2. Dificuldades encontradas ... 39

4.3. Sugestão para trabalhos futuros ... 40

REFERÊNCIA BIBLIOGRAFICA ... 41

REFERÊNCIA ELETRÔNICA ... 42

(7)

vi

LISTA DE FIGURAS

Figura 01 - Sequenciamento das atividades proposto pelo Projectlab ... 05 Figura 02 - Sequenciamento das atividades proposto pela Kim Heldman ... 06 Figura 03 - Sequenciamento das atividades proposta pela Rita Mulcahy ... 07 Figura 04 - Desdobramento do modelo SERIM ... Erro! Indicador não definido. Figura 05 - Sequenciamento das atividades de planejamento para o gerenciamento de

projetos ... Erro! Indicador não definido. Figura 06 - Atividades necessárias para o processo de adaptaçãoErro! Indicador não definido.

Figura 07 - Processo de criação dos formulários ... Erro! Indicador não definido. Figura 08 - Tabelas de tendência (t) x probabilidade (p) e t x p x impacto ... Erro! Indicador não definido.

(8)

vii

LISTA DE TABELAS

Tabela 1 – Fatores de riscos ... Erro! Indicador não definido. Tabela 2 - Avaliação do risco por área de conhecimento impactadaErro! Indicador não definido.

Tabela 3 - Modelo para qualificação do risco ... 28

Tabela 4 - Modelo para qualificação do risco ... 29

Tabela 5 - Valor para Tendência ... 29

Tabela 6 - Valor para Impacto ... 29 Tabela 7 - Valor para conhecimento sobre o risco ... Erro! Indicador não definido. Tabela 8 - Quantidade de fatores de riscos que impacta cada área de conhecimento

(9)

Este trabalho propõe um método de adaptação do planejamento de gerenciamento de projetos, baseando-se em critérios, a partir da identificação e classificação dos riscos. Será sugerido um sequenciamento das atividades de planejamento e apresentado um conjunto de formulários que suporta o processo de adaptação.

1.2. Justificativa

Durante a revisão bibliográfica que trata de Gerenciamento de Projetos, foi possível identificar que o Planejamento de Riscos é realizado após o planejamento da maioria das áreas de conhecimento utilizadas pelo PMI. Este planejamento tardio pode ocasionar um esforço posterior para adequação das novas necessidades ou de riscos identificados.

A necessidade de se ter um processo maleável às mudanças e ao tamanho dos projetos foi outro fator determinante para a elaboração deste trabalho, pois é possível observar que o esforço gasto no planejamento de todas as áreas de conhecimento pode ser melhor dimensionado e direcionado mediante as incertezas peculiar a cada projeto.

O sequenciamento das atividades teve como percussor a necessidade de um fluxo que melhor aderisse ao processo de adaptação, pois, durante o desenvolvimento do método de adaptação, observou-se a falta de um sequenciamento aderente ao método proposto.

Os formulários adaptáveis foram desenvolvidos para suportar o processo de adaptação, sendo realizada pesquisa no intuito de identificar a classificação de cada uma das informações contidas nos formulários. A utilização destes formulários deverá auxiliar o Gerente de Projetos a mensurar a quantidade de detalhes necessária para cada uma das áreas de conhecimento, atendendo o processo de adaptação.

1.3. Limitações da Pesquisa

Neste trabalho não será efetuado o acompanhamento do método em um projeto, sendo que será utilizado o embasamento teórico e uma pesquisa para auxiliar no seu desenvolvimento.

(10)

Serão utilizadas as boas práticas e os documentos indicados pelo Project Manager Institute (PMI), sendo os mesmos adaptados para atender a proposta deste trabalho.

1.4. Método Empregado

A monografia foi desenvolvida a partir de pesquisas bibliográficas envolvendo artigos científicos, revistas especializadas, dissertação de mestrado, livros e páginas na Internet de instituições de renome nos meios comercial e acadêmico.

(11)

2. ESTADO DA ARTE

2.1. Gerenciamento de Projetos

O gerenciamento de projetos tem como proposta principal entender a necessidade e cumprir o que foi planejado, com o custo aprovado e no tempo determinado sempre buscando a satisfação de todos os envolvidos.

No artigo “Certificação de Gerentes de Projetos de Software”, Lira apresenta um conjunto de métodos ou modelos pelos quais o Gerente de Projetos pode se certificar, com exceção da ISO 10006:2006, que não é passível de certificação.

Desses modelos, apenas o modelo ISO 10006:2006 e o PMBoK tem similaridades em seus processos. Sendo ambos divididos em nove áreas. Segue abaixo a descrição desses modelos citados acima:

ICB (International Competence Baseline) – Foi desenvolvida pela IPMA (Associação Internacional de Gerenciamento de Projetos) e opera em todo o mundo através de filiais. No Brasil, é representada pela ABGP (Associação Brasileira de Gerenciamento de Projetos). (O modelo é dividido em vinte e oito elementos básicos, seis adicionais e três adicionais específicos para o Brasil). Para cada um destes elementos são descritos os conceitos, o nível de experiência necessário e os níveis de conhecimento. A ICB não é exatamente um modelo, mas sim uma classificação de conhecimentos necessários para o gerente de projetos.

Prince2 (Projects in Controlled Environments)– É uma metodologia para gerenciamento de projetos que foi desenvolvida em 1989 pela CCTA (Center Computer and Telecommunications Agency). Este modelo é muito difundido entre os que já utilizam o ITIL (IT Infrastructure Library), que foi produzido pela mesma empresa. O Prince2 define os processos e formulários que são necessários implantar na empresa para que seja obtido sucesso nos projetos. Esta metodologia é aplicada apenas para projetos de TI.

APM BoK (APM Project Management Body of Knowledge) – Este modelo foi criado por Peter W. Morris com o objetivo de fazer uma crítica ao PMBoK. O APM BoK foi desenvolvido em uma parceria entre a University of Manchester e CRMP (Center for Research in the Management of Projects) com o intuito de indicar todos os conhecimentos necessários para um projeto ser bem sucedido.

(12)

Aplica-se a projetos de diversas complexidades, portes e tamanhos, sendo que as suas diretrizes podem ser aplicadas a projetos gerenciados por um indivíduo ou por uma equipe.

A ISO 10006 é composta por diretrizes e não pode ser usada para fins de certificação. Seu objetivo é criar e manter a qualidade em projetos, através de um processo sistemático que atenda as seguintes metas:

- Que as necessidades explícitas e implícitas dos clientes sejam entendidas e atingidas;

- Que as necessidades das partes interessadas sejam entendidas e avaliadas;

- Que as políticas da qualidade da organização sejam incorporadas no gerenciamento de projeto.

V Modell XT – Este modelo foi criado em 1997 pelas empresas Siemens, EADS, EABG e 4Soft e se tornou obrigatório para todos os projetos de TI efetuados para o Governo Alemão. O V Modell XT tem como característica principal a sua superioridade em relação aos modelos em cascata e espiral comumente utilizados nos projetos de TI. Para utilizá-lo em projetos de pequeno porte, é necessário efetuar uma adaptação, a qual necessita que se tenha conhecimento específico para isso.

PMBoK – Criado pelo PMI (Project Management Institute), o PMBoK é um guia de orientação para os profissionais de Gerenciamento de Projetos. Este documento tem o objetivo de ser bibliografia de referência, cujo propósito seja identificar e descrever os conceitos e práticas do gerenciamento de projetos, padronizando a terminologia e os processos utilizados.

2.2. Sequenciamento das Atividades

Neste capítulo será apresentada uma sugestão para o sequenciamento de atividades de planejamento. Para isso é necessário se compreender as diversas propostas que utilizam as boas práticas sugeridas pelo PMBoK.

A seguir, serão apresentados os sequenciamentos das atividades propostas por Kim Heldman, Rita Mulcahy e pelo Projectlab.

Na figura 1 é apresentado o diagrama utilizado pela empresa Projetclab. A atividade

“Planejar Integração” inicia a fase de planejamento do gerenciamento de projetos. Tem-se com atividade subsequente o “Planejamento do Escopo”. Após planejar o escopo, as sete

(13)

Figura 1 - Sequenciamento das atividades proposto pelo Projectlab Fonte: O autor

Este modelo tem como principal vantagem estabelecer o sequenciamento mais próximo do processo executado, pois após o planejamento da integração e do escopo, todas as áreas são executadas em paralelo. Em contrapartida, sequenciamento este não se adéqua a proposta de adaptação, proposta neste trabalho.

(14)

(Recursos Humanos, Tempo e Custo). Com a conclusão destas atividades em paralelo, iniciam-se mais um conjunto de atividades de planejamento em paralelo (Aquisição, Risco e Qualidade) e o processo de planejamento é concluído com a integração.

Figura 2 - Sequenciamento das atividades proposto pela Kim Heldman Fonte: O autor

O sequenciamento proposto por Heldman (2005) demonstra a necessidade da comunicação nos projetos, antecipando esta atividade e criando dois grupos que tem seu planejamento sendo executado em paralelo. Para a proposta do processo de adaptação, este modelo é mais aderente ao processo que será proposto neste trabalho.

(15)

sequenciado das áreas de Qualidade, comunicação, risco e aquisições, conforme demonstrado na figura 3.

Figura 3 - Sequenciamento das atividades proposta pela Rita Mulcahy Fonte: O autor

(16)

2.3. Análise de Riscos

A análise de riscos nasceu nos projetos devido à quantidade de incertezas que devem ser geridas. Ao ser efetuado o gerenciamento dos riscos, o objetivo é a identificação de oportunidades ou problemas que podem comprometer o projeto.

Juarez (2006) diz que o Gerenciamento de Riscos define uma forma previsível para tratar as incertezas do projeto, garantindo que os futuros cenários estarão em uma faixa de variabilidade aceitável.

O gerenciamento de riscos, conforme a definição do PMBok 3ª edição, deve aumentar a probabilidade e o impacto dos eventos positivos, bem como, diminuir a probabilidade e o impacto dos eventos adversos no projeto. Ou seja, a gestão de riscos visa prever e aproveitar todas as oportunidades que venham a beneficiar o projeto e mitigar os riscos que podem causar algum impacto negativo.

Os riscos positivos são aqueles que geram oportunidades ao projeto, trazendo benefícios de forma direta ou indireta. A visão positiva de um fator de risco é pouco explorada, sendo associada aos fatores de risco uma visão de impactos negativos no projeto.

Deve-se levar em conta que o limite de recursos financeiros utilizados para mitigar um risco deve ser inferior ao custo do impacto deste risco ao projeto.

Segundo o PMBok - 3ª edição, o gerenciamento de riscos é dividido em seis processos que são:

a) Planejamento do gerenciamento de riscos – decisão de como abordar, planejar e executar as atividades de gerenciamento de riscos de um projeto.

b) Identificação de riscos _– determinação dos riscos que podem afetar o projeto e documentação de suas características.

c) Análise qualitativa de riscos _– priorização dos riscos para análise ou ação adicional subsequente através de avaliação e combinação de sua probabilidade de ocorrência e impacto.

d) Análise quantitativa de riscos – análise numérica do efeito dos riscos identificados nos objetivos gerais do projeto.

(17)

f) Monitoramento e controle de riscos _– acompanhamento dos riscos identificados, monitoramento dos riscos residuais, identificação dos novos riscos, execução de planos de respostas a riscos e avaliação da sua eficácia durante todo o ciclo de vida do projeto.

2.3.1. Modelos de Avaliação de Riscos

Os fatores de risco podem ser classificados de duas formas: qualitativo ou quantitativo. Os riscos qualitativos são oriundos de incertezas que assumem escala ordinal, ou seja, recebe uma classificação textual (alto, médio ou baixo). Já os fatores de riscos quantitativos assumem uma escala de razão, ou seja, são expressos de forma numérica.

Entre os modelos de análise de risco qualitativos se destacam os modelos de Moynihan e Karolak, sendo estes modelos baseados em questionários com fatores de riscos pré-definidos [Juarez (2007, p. 40)]. Nestes modelos, destacam-se a aplicabilidade antes do inicio do projeto, ou seja, existe uma lista de fatores de riscos comuns aos projetos que podem ser exploradas, antecipando futuros riscos.

2.3.1.1. Moynihan

O modelo foi desenvolvido por Tony Moynihan no projeto de intercâmbio europeu ESPIRIT.

Conforme explica Juarez (2007), este modelo avalia o risco de um projeto de TI pela estimativa da intensidade de vinte e três fatores de risco sobre quatro fatores de sucesso, ou seja, o modelo procura determinar a probabilidade dos quatro fatores de sucesso serem alcançados utilizando-se dos vinte e três fatores de risco.

Fatores de Sucesso

Os fatores de sucesso são requisitos que os projetos devem atender para ter êxito. A análise de risco deve ocorrer para que não haja influência interna ou externa que afete algum desses fatores. Eles são:

FS1. Custo de acordo com o valor esperado;

FS2. Projeto deve ser finalizado sem problemas;

FS3. Produto atende as especificações;

(18)

Fatores de Risco

FR1. Percepção do cliente sobre os requisitos do seu sistema.

FR2. Competência da equipe.

FR3. Exemplos de software semelhantes.

FR4. Experiência da equipe na área de aplicação.

FR5. Grau de dificuldade técnica ou intelectual do projeto.

FR6. Facilidade de teste.

FR7. Tamanho do projeto.

FR8. Complexidade dos requisitos.

FR9. Volatilidade dos requisitos.

FR10. Volatilidade das interfaces.

FR11. Flexibilidade dos requisitos.

FR12. Tamanho da equipe.

FR13. Duração do projeto.

FR14. Maturidade do ambiente de desenvolvimento.

FR15. Experiência da equipe com o ambiente de desenvolvimento.

FR16. Maturidade do ambiente de produção.

FR17. Experiência da equipe no ambiente de produção.

FR18. Canal de comunicação entre a equipe e fornecedores.

FR19. Canal de comunicação entre a equipe e o cliente.

FR20. Volatilidade da equipe.

FR21. Chance de perda de pessoas críticas.

FR22. Conhecimento da equipe pelo gerente.

FR23. Dependência de componentes importados.

Para avaliar o risco ao qual cada um dos fatores está sujeito, Moynihan propõe:

(19)

2. Cada fator é multiplicado por um peso na matriz de pesos dos fatores de risco. A matriz associa os fatores de risco às diversas áreas gerenciais do projeto.

3. A soma dos fatores de influência indica o risco total, a administração do custo, o desenvolvimento, os possíveis erros e falhas técnicas.

Este modelo relaciona os fatores de sucesso a serem afetados pelos fatores de risco, utiliza para isso uma matriz com 23 linhas e quatro colunas. Onde alguns fatores de risco afetam diretamente determinados fatores de sucesso, e outros não. Conforme apresentado na tabela 1.

Tabela 1– Fatores de riscos

Fator de risco Fatores de Sucesso

FS1 FS2 FS3 FS4

FR1 Percepção do cliente sobre os dados do seu sistema.

FR2 Competência da equipe.

FR3 Exemplos de casos semelhantes.

FR4 Experiência da equipe com a área de aplicação.

Fonte: O autor

A partir dos valores estimados para os 23 fatores de risco, o modelo indica qual a perspectiva para atingir os fatores de sucesso. Este resultado é dado através de uma equação matemática, aonde a probabilidade do fator de sucesso ocorrer é dado por 1–P(k).

Onde,

I: Número do fator de risco;

K: Índice do critério de sucesso em consideração; W[i.k]: Impacto do fator de risco I no fator K; N[i]: Intensidade do fator I;

(20)

2.3.1.2. Karolak

Conforme explica Juarez (2007), o modelo Karolak foi desenvolvido por Dale Walter Karolak (Juarez apud Karoloak, 2007) com o objetivo de minimizar ou contingências os impactos causados pelos riscos do processo de desenvolvimento de software. Para isso o gerenciamento de risco deve ser feito o mais cedo possível. Assim, aumentam-se as chances de atingir as metas de custo e prazo, além de reduzir o tempo do projeto.

Segundo Karolak (Juarez apub Karoloak, 2007), os fatores de risco podem ser vistos sob duas óticas: tecnológica e de negócios.

Dentre os fatores de risco técnico estão: os algoritmos, a disponibilidade da tecnologia, a maturidade do software e hardware utilizados para a construção de um software.

Dentre os riscos de negócio estão: a disponibilidade de recursos, orçamento e metas de prazo.

Esse método de gerenciamento utiliza um modelo de estimativa de risco qualitativo chamado SERIM (Software Engineering Risk Model).

O SERIM utiliza três fatores de sucesso, dez categorias e oitenta e um fatores de risco. A cada fator de risco é dada uma nota de 0 a 1. Em seguida, estes fatores são agrupados em 10 categorias de risco, onde cada fator de risco pertence a somente uma categoria. A figura 4 demonstra este desdobramento.

Figura 4 - Desdobramento do modelo SERIM

Fonte: Juarez, 2007

(21)

Critérios de Sucesso

Os critérios de sucesso para o modelo Karolak (JUAREZ, 2007) são 3: técnico, custo e prazo.

Os riscos técnicos são aqueles que, de alguma maneira, irão afetar a performance do produto final. A performance do produto é entendida como a presença de atributos relacionados com as seguintes qualidades de software:

Funcionalidade: A habilidade de executar as funções planejadas. Qualidade: A habilidade de atender às expectativas dos clientes.

Confiabilidade: A habilidade de executar por longos períodos sem erros.

Usabilidade: A habilidade do software e sua documentação proverem a implementação fácil dos requisitos dos usuários.

Temporal: A habilidade de executar as funções no tempo desejado.

Manutenibilidade: A habilidade do software e sua documentação serem facilmente mantidos.

Reusabilidade: A habilidade de um software poder ser utilizado novamente em aplicações similares.

Os fatores de risco de custo são aqueles que impactam no orçamento do desenvolvimento do produto, incluindo sua entrega. O sucesso de custo depende de:

Orçamento: Desenvolver o produto, sua documentação e serviços dentro dos limites financeiros estabelecidos.

Custos não recorrentes: Identificar e gerenciar custos como trabalho inicial de desenvolvimento, aquisição de equipamentos.

Custos recorrentes: Identificar e gerenciar custos associados com o suporte do desenvolvimento do produto como instalações físicas, suporte e manutenção de ferramentas.

Custos fixos: Identificar e gerenciar custos que não variam com a reprodução do produto e sua documentação.

(22)

Margem de lucro: Prever e controlar a margem de lucro esperada na venda do produto.

Realismo: A habilidade de projetar o custo de forma precisa baseado nas afirmações dadas.

Os fatores de risco de prazo impactam o cronograma do projeto e estão relacionados às seguintes questões:

Flexibilidade: A habilidade de o cronograma ser compactado ou estendido com base no desenrolar do desenvolvimento.

Atingir metas: A habilidade dos recursos técnicos atingirem as metas estabelecidas no cronograma.

Realismo: A habilidade de o cronograma refletir as expectativas dos clientes, gerentes e desenvolvedores com realismo.

Categorias de Risco

Organização: A maturidade da estrutura, da comunicação, das funções e a liderança dentro da organização.

Estimativa: A acurácia das estimativas de recursos e de cronograma necessários durante o desenvolvimento de software e de seus custos

Monitoramento: A habilidade de identificar problemas.

Metodologia de desenvolvimento: Conjunto de métodos utilizados para o desenvolvimento de software.

Ferramentas: As ferramentas utilizadas no processo de desenvolvimento de software.

Cultura de risco: O gerenciamento do processo de tomada de decisão no qual os riscos são considerados.

Usabilidade: A funcionalidade do produto após ser entregue ao usuário final ou ao consumidor.

Correção: Quanto o produto atende as necessidades dos usuários.

(23)

Pessoal: A quantidade de pessoas utilizadas durante o desenvolvimento e suas habilidades.

Fatores de Risco

Cada fator de risco associa-se a apenas uma categoria de risco.

Os fatores de risco são baseados na tendência da indústria, em dados históricos, publicações e em observações de projetos de software (bem sucedidos ou não).

Os fatores de risco são valores numéricos subjetivos para respostas de um questionário com 81 perguntas. As respostas são valores entre 0 e 1, interpretados como probabilidades. Quanto menor o valor, maior o risco.

O modelo SERIM utiliza uma forma de avaliação dos fatores de risco sobre o projeto. Karolak sugere a seguinte escala:

0,0 – Nenhum

0,2 – Um pouco

0,5 – Algum

0,8 – Maioria

1,0 – Todos

2.3.2. GUT (Gravidade, Urgência e Tendência)

O livro Ferramentas Administrativas para Identificar, Observar e Analisar Problemas - Organizações com foco no cliente (MEIRELES, 2001) cita:

“A ferramenta GUT aplica-se sempre que precisamos priorizar ações dentre um leque de algumas que dispomos. O objetivo desta ferramenta é ordenar a importância das ações, pela sua GRAVIDADE, pela sua URGÊNCIA e pela sua TENDÊNCIA de forma, a racionalmente escolher a tomada de ação menos prejudicial.”

(24)

2.4. Modelos ágeis para Gerenciamento de Software A - Agile Project Management (APM)

O Gerenciamento Ágil de Projetos (APM) consiste em um conjunto de práticas e princípios, cuja finalidade é guiar o gerenciamento do projeto. Sua principal aplicação é na criação de novos produtos e serviços.

O APM possui cinco objetivos chaves de negócios:

a) Inovação contínua

b) Adaptabilidade do produto

c) Entregas com cronograma reduzido

d) Adaptabilidade do processo e das pessoas

e) Resultados confiáveis.

Pela inovação contínua, busca-se atender as necessidades mais atuais do cliente, necessidades estas que podem variar no decorrer do projeto. O que impulsiona essa inovação é a busca para entregar ao cliente o que ele espera de uma forma completa e satisfatória.

No APM a adaptabilidade do produto é medida pela forma com a qual o produto será entregue ao cliente, criando um produto que possa ser adaptado futuramente sem custos elevados.

Entregas com cronograma reduzido, na qual se trata de entregar cada versão no prazo mais reduzido possível. O APM contribui para agilizar os prazos de entrega de três maneiras: Foco, agilidade e desenvolvimento de perfil.

a) O foco é a atenção constante, a priorização dos requisitos funcionais do produto. b) O APM agiliza o processo de desenvolvimento, atento as atividades que contribuem para a satisfação do cliente, eliminando a carga extra e atividades burocráticas.

c) O desenvolvimento de perfil busca os indivíduos que dispõem de qualificações profissionais que atendam da melhor forma as necessidades do projeto.

A adaptabilidade do processo e das pessoas é usada para atender rapidamente às mudanças no negócio e no produto. Construindo equipes adaptáveis.

(25)

No desenvolvimento do APM encontram-se cinco fases: Visão, especulação, exploração, adaptação e fechamento.

Uma visão bem articulada do negócio ou produto mantém coesas as próximas fases. Na especulação são criadas hipóteses quanto à especificação do produto, sabendo que à medida que o projeto evolui as especificações do cliente e a tecnologia tendem a mudar de acordo com novos conhecimentos forem sendo adquiridos. Na fase de exploração serão implementados os elementos da especificação preliminar. Na fase de adaptação são avaliados os resultados da exploração quanto aos critérios técnicos e de negócio. Depois ações adaptativas são deflagradas e incorporadas na interação seguinte.

Resumidamente, o APM trata-se de um método baseado na agilidade e habilidade de criar e responder a mudanças no decorrer de um projeto, sempre atendendo as expectativas do cliente, com equipe ágil e preparada.

B - UNIFIED PROCESS (UP)

O Unified Process (UP) é composto por um conjunto de disciplinas que fornecem diretrizes para definição de tarefas e para atribuição das responsabilidades. Seu principal objetivo é garantir a criação de softwares de alta qualidade, atendendo às necessidades do cliente, e às restrições de prazo e custo.

Para resolver os problemas que causam os fracassos da maioria dos projetos de desenvolvimento de software o UP utiliza as seguintes ferramentas:

a ) Desenvolvimento iterativo;

b ) Gerenciamento de requisitos;

c ) Arquitetura baseada em componentes;

d ) Organização da especificação em “modelos”;

e ) Verificação constante da qualidade;

f ) Controle de mudanças;

g ) Organização do sistema com estrutura estática e dinâmica;

h ) Trabalho com processos focados na arquitetura e nos Casos de Uso.

O gerenciamento de projetos de desenvolvimento de software pode falhar por diversos motivos e muitos têm sintomas em comum:

(26)

b ) Gerenciamento de requisitos de forma informal e amadora;

c ) Arquitetura frágil;

d ) Complexidade excessiva que cresce fora de controle;

e ) Inconsistências não detectadas nos requisitos, na especificação técnica e na implementação;

f ) Testes insuficientes ou inadequados;

g ) Propagação descontrolada das mudanças de projeto;

h ) Incompetência na mitigação dos riscos.

O UP procura amparar a equipe de projetos com ferramentas e processos para minimizar estes tipos de problemas.

Inicialmente o roteiro do UP pode sugerir que o projeto é desenvolvido de forma sequencial, mas na realidade muitas destas atividades são executadas ao mesmo tempo, outras repetidamente, até que os objetivos sejam atingidos.

O UP deve ser ajustado para cada projeto específico e tanto pode ser formal e predeterminista, como pode ser informal e fluído. Pode ser utilizado com outras metodologias, como o XP, o Scrum e o PMI, por exemplo.

C - SCRUM

O Scrum é um projeto bastante leve. Utiliza uma metodologia ágil que desfruta de filosofias iterativas e incrementais. Concentra-se em gerenciar o projeto e criar um produto que acrescente valor ao negócio.

O Scrum é adaptativo e empírico.

Nesta abordagem, trabalha-se um pedaço pequeno de cada vez e cada iteração consiste na captura de requisitos, um pouco de análise, um pouco de design, mais alguma programação e testes, culminando num ciclo iterativo com várias entregas.

O projeto Scrum começa com uma visão que pode ser expressa em termos técnicos ou de marketing, termos que vão se fundamentando e ficando mais claros de acordo com a evolução do projeto. A partir dessa visão, é definida uma lista de itens priorizados, composta por requisitos e funcionalidades que precisam ser construídos, essa lista é chamada de Backlog de produto.

(27)

ao cliente e a outros stakeholders, que vão inspecionar e sugerir ou solicitar adaptações. Estas adaptações poderão vir a adicionar novos itens ao Backlog de Produto e, assim, a prioridade dos itens será revisada. Antes de iniciar a próxima ação, a equipe analisa as ações, tanto as positivas quanto as negativas e, de acordo com esta análise, propõe mudanças. Quando o projeto atingir os objetivos, ele é então encerrado.

O Scrum efetua um controle dos entregáveis gerados a cada Sprint. Com isso, é possível definir intervalos regulares para a distribuição do produto. Estes intervalos regulares são denominados timebox.

No Scrum, uma infraestrutura básica é implementada e depois pedaços de funcionalidades são entregues, de modo que o cliente possa usufruir do produto o mais cedo possível. À medida que o cliente experimente o produto, ele pode sugerir alterações, sendo que este processo de alterações solicitadas pelo cliente no decorrer do desenvolvimento da solução é conhecido como welcome changes.

O Scrum é um método de gerenciamento, melhoria e manutenção para um sistema novo ou que já existe. Para projetos de desenvolvimento de softwares, o Scrum assume que já existe um projeto técnico e um código fonte, que é o caso da maioria dos sistemas orientados a objeto que utilizam API ou bibliotecas de terceiros.

O método Scrum é simples e objetivo e oferece um conjunto de praticas que mantém todos os envolvidos com a visão atual do projeto. Isto permite que a equipe e outros interessados tomem decisões e direcionem o projeto.

D - EXTREME PROGRAMMING (XP)

Segundo Kent Beck (MARTINS apub BECK, 2007) o foco do XP está na excelência das técnicas de programação, na comunicação clara e no trabalho em equipe.

Sua filosofia de desenvolvimento de software baseia-se nos valores da comunicação, feedback, simplicidade, coragem e respeito mútuo.

De acordo com Beck, o XP distingue-se das outras técnicas pelas seguintes características:

a ) Trabalha com iterações de duração bastante curta, resultando em feedbacks rápidos, concretos e contínuos.

(28)

c ) Tem a possibilidade de planejar melhor a implementação das funcionalidades do software, permitindo respostas mais rápidas às necessidades de mudanças dos negócios.

d ) Usa mecanismos automatizados para realizar testes, que podem ser desenvolvidos pelos programadores, clientes ou pessoal de qualidade para monitorar o progresso do desenvolvimento, permitindo que o sistema evolua e que os defeitos sejam identificados o mais cedo possível.

e ) Confia na comunicação oral nos testes e nos programas-fontes para comunicar a estrutura dos seus intentos.

f ) Trabalha com um processo evolutivo de design que persiste durante a vida do projeto.

g ) Confia na colaboração entre indivíduos ativamente engajados e com talentos específicos.

h ) Usa práticas que atendem às necessidades imediatas dos membros da equipe e de longo prazo do projeto.

No desenvolvimento de software tudo muda: os requisitos, a forma como o sistema foi projetado, o negócio, a tecnologia, a equipe, os membros da equipe. Se por ventura houver dificuldades em lidar com a mudança, o XP possui recursos que podem amenizar esses casos.

O XP tem como característica marcante a ênfase nos testes. Os cenários de testes são escritos pelos desenvolvedores durante o processo de desenvolvimento de software, que será entregue para produção. Estes testes são inseridos em um processo de integração continua e de construção, o que leva a uma plataforma estável para futuros desenvolvimentos.

O XP é um método que aplica design evolutivo, que se baseia em refactoring (processo de alteração do código, sem alterar as funcionalidades externas, ou seja, não muda o que o cliente visualiza) de uma base de código simples a cada iteração. Todo design é centrado na iteração atual, sem que nada cause efeito para necessidades futuras antecipadas. O resultado é um processo de design disciplinado, combinando disciplina com facilidade de adaptação.

E - FEATURE DRIVEM DEVELOPMENT (FDD)

O FDD foi concebido por Jeff De Luca (1999), com as seguintes características:

(29)

b ) Enfatiza a qualidade;

c ) Entrega resultados tangíveis e frequentes;

d ) Provê relatórios de progresso precisos e significativos, requerendo pouca sobrecarga de trabalho por parte dos programadores;

e ) É apreciado pelos clientes, gerentes e desenvolvedores.

De acordo com De Luca (1999), os clientes apreciam o FDD porque com ele é possível obter resultados significativos mais cedo e o FDD possui meios para acompanhar a evolução do projeto com segurança, através dos relatórios de progresso. Os gerentes se adaptam bem ao FDD porque conseguem ter um status preciso do progresso do projeto. E aos desenvolvedores é permitido finalizar o trabalho em pequenos incrementos, melhorando a sensação de produtividade.

O FDD pode ser utilizado tanto em projetos para desenvolvimento de novos softwares como em projetos para evoluir um software existente.

Inicia-se o projeto com a definição de uma lista de requisitos funcionais, considerando somente aqueles que podem ser entendidos pelos usuários e clientes. Estes requisitos são chamados features que depois de identificados são utilizados para planejar e gerenciar o projeto. Os clientes podem priorizar as features de acordo com sua importância para o negócio.

O FDD é definido para fazer repetidamente entregas constantes, tangíveis e funcionais. É um método simples, objetivo e fácil de seguir.

Possui técnicas objetivas para lidar com os problemas de desenvolvimento de software, técnicas para informar o progresso e permitir que as decisões possam ser tomadas em tempo oportuno.

Os clientes são beneficiados por terem seu negócio automatizado desde o início do projeto. O feedback antecipado sobre os resultados entregues permite que os clientes direcionem o projeto conforme as necessidades do negócio.

F - MODELAGEM ÁGIL (AGILE MODELING AM)

Trata-se de uma abordagem para a modelagem e não uma metodologia para desenvolvimento de software. Normalmente, é utilizada para complementar algumas metodologias como XP, UP entre outras.

Resume-se em ”modelar somente o necessário e nada mais”, usando as ferramentas

necessárias, simples e apropriadas para cada caso.

(30)

Às vezes, a ferramenta de modelagem não é suficiente para expressar toda informação necessária para a especificação de um software. O modelo deve mostrar como será o software, como suas partes serão montadas e integradas e como elas funcionarão.

Alguns sistemas utilizam uma arquitetura centrada nos dados e tem o banco de dados como sua parte central. No entanto, mesmo nestes casos, o modelo de dados é apenas uma parte. Outros aspectos também precisam ser modelados.

Os modelos devem ser utilizados apenas quando necessário. Se depois de algum tempo um modelo precisar ser utilizado novamente, somente neste momento ele deverá ser atualizado. Algumas vezes os modelos precisam ser modificados porque os requisitos do sistema mudam.

A modelagem ágil não tem um ciclo de vida ou processos que precisam ser seguidos. Trata-se de um conjunto de orientações e princípios para ajudar o desenvolvedor a abordar a modelagem de sistemas de forma objetiva.

(31)

3. TRABALHO REALIZADO

A proposta deste trabalho é a realização do processo de adaptação baseando-se em riscos. Para uma melhor compreensão do processo de adaptação, serão apresentadas três atividades:

- Sequenciamento das atividades de planejamento;

- Processo de adaptação;

- Formulários adaptáveis.

Cada uma destas atividades será apresentada no decorrer deste capítulo.

3.1. Sequenciamento das Atividades

A primeira atividade é a sugestão de sequenciamento, devido ao mesmo ser pré-requisito para o processo de adaptação.

O processo de adaptação do planejamento é dividido em nove etapas sequenciadas. Os aspectos que desencadearam a necessidade de sequenciar as atividades de planejamento são iniciados pelo agrupamento das atividades do Gerenciamento de Integração, criar Termo de Abertura, com as atividades de elaboração de documentação do Gerenciamento de projetos (Declaração de Escopo, Plano de Gerenciamento de Escopo, EAP e Dicionário da EAP). A razão disso é que a principal atividade que é relacionada ao processo de adaptação deste trabalho é a análise de risco e, por este motivo, os documentos que antecedem esta análise podem ser agrupados como documentos pré-requisitos. Neste trabalho estes documentos e suas respectivas atividades foram agrupadas

em uma única atividade “Iniciar Projeto”.

Após definir a atividade que corresponde a todas as necessidades que antecedem a Análise de risco, observamos as atividades posteriores a esta atividade. A primeira é Planejar Qualidade, sendo que esta escolha ocorre pela necessidade de definir os critérios de aceitação do produto e como será medido. Só após esta definição que poderemos continuar o planejamento.

(32)

Planejar Integração ocupa a última das atividades de planejamento, pois dela nasce o plano que geram todos os outros, integrando todo o processo de gestão de projetos.

A figura 5 demonstra o sequenciamento das atividades do processo de adaptação do planejamento, que foram divididos em nove atividades, sendo que duas atividades ocorrem em paralelo, conforme descrito.

Figura 5 - Sequenciamento das atividades de planejamento para o gerenciamento de projetos Fonte: O autor, 2009

(33)

abertura e toda a descrição do projeto. Eles deverão ter o máximo de informações possível, pois a partir de tais informações é que serão desenvolvidas as próximas atividades.

Os documentos a serem elaborados são: Termo de abertura, Declaração do Escopo, Plano de Gerenciamento do Escopo, EAP (Estrutura Analítica do Projeto) e o dicionário da EAP. Estes documentos são utilizados para efetuar a análise de risco.

2 _– Efetuar análise de risco: Será realizada a avaliação de riscos, com base no modelo proposto ao longo deste trabalho. A análise de risco tem como objetivo identificar os fatores (internos ou externos) que de alguma forma podem beneficiar ou prejudicar o projeto. Após a identificação dos fatores de risco, deve-se efetuar a classificação, conforme o proposto neste trabalho.

Esta atividade será efetuada após a realização dos documentos da atividade “Iniciar Projeto” e será revisitada após qualquer mudança aprovada.

3 - Realizar adaptação: A realização desta atividade depende da análise de risco, pois é com base na identificação e classificação que obteremos os dados necessários para o processo de adaptação. Esta atividade será alvo do trabalho aqui apresentado, bem como as demais atividades ligadas diretamente ao processo de adaptação.

4 – Planejar Qualidade: Nesta atividade são definidos os critérios para a avaliação do(s) produto(s) que deverão ser entregues ao Cliente. Deverão ser definidas as métricas, a lista de Controle de Qualidade, bem como o Plano de Gestão da Qualidade.

5a _– Planejar Custo: A atividade Planejar Custo tem por definição realizar toda a gestão dos custos do projeto. Tendo como documentação a Estimativa de Custo, Orçamento e Plano de Gerenciamento de Custo, este trabalho sugere que a estimativa de custo seja realizada através da ferramenta Bottom Up.

5b - Planejar Tempo: Atividade responsável pela Gestão do Tempo do projeto. Esta gestão é realizada através do Cronograma e do Plano de Gerenciamento de Tempo. Assim como a atividade Planejar Custo, deve-se utilizar a EAP para listar todas as atividades do projeto e suas interdependências.

6a – Planejar Aquisição: Esta atividade corresponde à Gestão de Aquisições, sendo responsável por atender todas as necessidades de material ou de serviço de terceiros. Em Planejar Aquisições teremos os seguintes documentos de gestão: Contrato, Lista de Fornecedores, Orçamentos, Plano de Gestão de Aquisições, Planejamento de Aquisições e Serviços.

(34)

atividade, tem-se como documentos o Organograma, a Matriz de Funções e Responsabilidades e o Plano de Gerenciamento de Recursos Humanos.

7 _– Planejar a Comunicação: Após a definição da equipe de projeto e identificação dos demais envolvidos, decide-se como será realizada a comunicação. Esta atividade depende diretamente da quantidade de envolvidos e da localização geográfica ou física dos mesmos.

8 _– Planejar Integração: Esta atividade é responsável por estruturar todo o projeto de forma a garantir a integração entre as áreas de conhecimento e os envolvidos no projeto.

9 – Gerir o projeto: A atividade de Gerir Projeto é composta por efetuar controle de todas as modificações no projeto. O controle tem como função a identificação de possíveis problemas que possam gerar mudanças ou alterações provindas de identificação futura de necessidades. Todas as solicitações de mudança do projeto deverão ser avaliadas e aprovadas, conforme os critérios estabelecidos anteriormente para o mesmo. Após aprovadas as mudanças, se faz necessária uma avaliação da mudança, ou seja, se a mesma pode impactar o projeto. Caso o resultado da avaliação do impacto da mudança no projeto tenha um resultado negativo, a mesma deverá ser apenas documentada, sem reavaliação de riscos e atualização no processo e adaptação.

Quando uma mudança gera impacto, os riscos ocorridos (direta ou indiretamente) deverão ser avaliados e se necessário os modelos devem ser atualizados, tornando-os mais complexos ou mais simples.

3.2. Processo de Adaptação

Após ser definido o sequenciamento das atividades de planejamento do projeto, é necessário efetuar o processo de adaptação. Este processo de adaptação do Gerenciamento de Projetos tem início na análise de risco. Neste momento, é necessário já estar de posse dos documentos que definem o escopo.

(35)

Figura 6 - Atividades necessárias para o processo de adaptação Fonte: O autor, 2009

A - Identificar os fatores de riscos do projeto

Nesta atividade, devem-se efetuar reuniões com os membros chaves do projeto e, através destas reuniões, serem identificados o conjunto de FR (fatores de riscos). Estes FR devem ser listados e agrupados por fase do projeto (iniciação, planejamento, execução, controle e finalização), no intuito de evitar redundâncias e identificar em quais momentos os riscos podem vir a impactar. O trabalho propõe que a identificação dos FR seja efetuada através da realização de um brainstorm.

Este trabalho disponibilizará uma lista de FR baseados no modelo de Moyninhan.

B - Avaliar áreas impactadas

(36)

Tabela 2 - Avaliação do risco por área de conhecimento impactada

Neste trabalho foi efetuada uma pesquisa para avaliar quais áreas de conhecimento são impactadas por quais dos FR sugeridos. O formulário usado para efetuar a pesquisa encontra-se no Apêndice.

C - Estimar impacto dos fatores de riscos do projeto

Tendo em vista que nesta atividade os FR foram identificados, deve-se qualificar o risco no âmbito do projeto. Isso significa analisar o impacto em cada área de conhecimento, a tendência e a probabilidade de ocorrer o risco no projeto. Este mapeamento deve ser efetuado de forma qualitativa, ou seja, são determinados valores e pesos para ocorrer o risco.

Sugere-se que seja feito um brainstorm com um grupo de pessoas envolvidas no projeto e que cada um dos participantes preencha um modelo contendo os FR. Este modelo deve conter o FR, a probabilidade de ele acontecer, o impacto no projeto e o nível de conhecimento sobre o assunto. A figura 6 demonstra como deverá ser o modelo a ser preenchido por cada participante.

Tabela 3 - Modelo para qualificação do risco

Fonte: O autor

Risco Custo Tempo Escopo Recursos

Humanos Qualidade Comunicação Aquisições Integração

Experiência da equipe neste tipo de projeto

(37)

A probabilidade deverá obedecer a seguinte escala:

Tabela 4 - Modelo para qualificação do risco

Valor Probabilidade Descrição

1 Muito baixo _{A chance de ocorrer é menor que 19%}

2 Baixo _{A chance de ocorrer varia entre 20% e 39%}

3 Médio _{A chance de ocorrer varia entre 40% e 69%}

4 Alto _{O FR poderá ocorrer com uma frequência superior a 70%}

5 Muito Alto _{Pode ocorrer muitas vezes ou o FR tem chance superior a 90%}

Fonte: O autor

Para a tendência, devem ser obedecidos os seguintes parâmetros:

Tabela 5 - Valor para Tendência

Valor Tendência Descrição

1 _{Muito baixo Permanece no mesmo estágio}

2 Baixo _{Deve piorar em longo prazo}

3 Médio _{Deve piorar em médio prazo}

4 Alto _{Deve piorar em curto prazo}

5 _{Muito Alto Vai piorar rapidamente}

Fonte: O autor

O impacto deverá ser classificado da seguinte forma:

Tabela 6 - Valor para Impacto

Valor Impacto Descrição

1 _{Muito baixo Não gera impacto ao projeto}

2 Baixo _{Gera impacto e tem fácil resolução}

3 Médio _{Gera impacto e a resolução causa custo a mais ou tempo.}

4 Alto Causa um grande impacto ao projeto, podendo comprometer a qualidade do produto ou do projeto

5 Muito Alto Causa desgaste da imagem da empresa e/ou o projeto pode ser cancelado

(38)

O “Nível de conhecimento” é uma auto-avaliação, na qual cada um dos participantes deverá informar qual o conhecimento que ele detém naquela área ou no FR, mais especificamente. O campo deve obedecer o seguinte critério.

Tabela 7 - Valor para conhecimento sobre o risco

Valor Conhec. Descrição

1 Muito baixo Nenhum conhecimento

2 Baixo Já teve contato com o assunto

3 Médio Exerce a atividade há mais de 1 ano

4 Alto Exerce atividade há mais de 5 anos ou tem experiência na área

5 Muito Alto Especialista

Fonte: O autor

Com base no campo “Nível de conhecimento” (C), será efetuada uma média

aritmética dos resultados obtidos nos campos “Impacto” (I), “Probabilidade” (P) e

“Tendência” (T), ou seja, o resultado final para o risco será dado por C1.I1 + C2.I2 + Cn.In / n, onde n é o número de pessoas envolvidas. Esta fórmula se repetirá para cada um dos atributos (I, P e T).

D - Definir respostas aos fatores de riscos

Esta atividade é responsável por avaliar quais os FR que necessitam de mitigação e quais os riscos que serão assumidos pelo projeto. Ao ser definido o plano de respostas para os riscos, deve-se avaliar e aprovar o custo adicional e/ou as medidas adicionais que deverão ser tomadas a fim de minimizar o impacto do FR.

Os FR podem ser tratados de 3 formas:

Eliminados: São ações tomadas pela equipe de projeto ou pelo gerente de forma a eliminar a possibilidade do FR se concretizar. Neste caso, as ações serão adicionadas ao projeto e o FR é dado como eliminado, não interferindo no processo de adaptação.

(39)

Aceitos: São FR para as quais se optou por assumir as consequências, estes normalmente têm uma baixa frequência e um impacto baixo, podendo a Gerência de o projeto administrá-los sem qualquer dano ao projeto.

E - Priorização das áreas de conhecimento

Após os riscos terem sido devidamente identificados, qualificados e quantificados por área de conhecimento, bem como o calculado impacto causado no projeto, deve-se efetuar uma análise dos resultados obtidos. Para isso, utilizaremos uma adaptação do modelo GUT no intuito de identificar quais são as áreas mais impactadas, bem como os FR que podem comprometer o projeto.

O modelo GUT utiliza, conforme descrito anteriormente na seção Estado da Arte, utiliza-se dos seguintes parâmetros: o G para Gravidade, U para urgência e T para tendência. No caso deste trabalho adotaremos os seguintes valores:

G – A gravidade do risco por área de conhecimento;

U – Probabilidade de o risco ocorrer;

T – Tendência.

Desta forma um risco será identificado e classificado de forma diferente para cada área de conhecimento afetada.

3.3. Formulários para Planejamento do Projeto

Neste capítulo serão descritos os critérios utilizados para efetuar o processo de adaptação dos modelos para o Gerenciamento de Projetos.

Os formulários poderão assumir três status, cada um composto por um grupo de campos. Este agrupamento tem como objetivo atender a priorização dada às áreas de conhecimento, conforme o resultado obtido no PROCESSO DE ADAPTAÇÃO.

Os status dos formulários são:

(40)

Intermediário: O formulário intermediário é composto por campos essenciais e variáveis, posteriormente definidos. Este status de formulário tem como objetivo atender as áreas de conhecimento que tem um risco médio.

Completo: O status de formulário completo contém os campos classificados como essencial, variável e complementar. Este conjunto de campos deverá auxiliar o gerenciamento das áreas de conhecimento que obtiveram um risco alto.

A figura 7 demonstra o encadeamento das atividades utilizadas para a elaboração dos formulários.

Figura 7 - Processo de criação dos formulários

Fonte: O autor, 2009

A - Identificar os formulários

Esta atividade tem como objetivo a seleção dos documentos necessários para o gerenciamento de projetos. Foram utilizados os modelos sugeridos no livro “Gerenciamento de Projetos para Pequenas Empresas” e os modelos sugeridos no site do Ricardo Vargas para servir como base dos formulários a serem adaptados.

(41)

B _– Selecionar os riscos

Nesta atividade, foram analisados os riscos dos modelos de Karolak e Moynihan (JUAREZ, 2007). Identificou-se a necessidade de utilizar os riscos do modelo de Moynihan, porém desconsiderando a qualitativa do modelo.

A utilização destes riscos não inviabiliza a inclusão de novos riscos, porém deve-se atentar em redefinir os parâmetros necessários para cada estágio dos documentos.

C – Criar o modelo

Para efetuar a criação do modelo foi necessário transcrever os modelos de documentação, anteriormente identificados, para uma planilha. Separar quais seriam os documentos que sofreriam o processo de adaptação.

O primeiro documento inserido na planilha foi a matriz de riscos. Nesta planilha foram inseridos os riscos selecionados na atividade anterior e definidos os campos necessários para atender o processo de adaptação. Estes campos são:

a. Cód. – Este campo será preenchido com um código sequencial e único. Será responsável por identificar o FR e podendo futuramente ser utilizado no intuito de substituir a descrição do risco.

b. Fator de Risco– Neste campo será informado o FR, contendo uma breve descrição do risco. Para maiores informações deve-se inserir um comentário na célula. Desta forma as células não são deformadas pelo tamanho do texto.

c. Fase – Neste campo foram inseridas as seguintes opções: Iniciação, planejamento, execução, controle e finalização. Estas opções são utilizadas para definir em que etapa do projeto o risco pode ocorrer.

d. P – O campo P corresponde à probabilidade do FR ocorrer. Deve ser preenchido conforme os parâmetros estabelecidos neste trabalho.

e. T– O campo T atende ao atributo Tendência, ou seja, o comportamento do FR caso o mesmo não seja mitigado ou eliminado. O preenchimento deste campo segue os critérios descritos neste trabalho.

(42)

Após a matriz de riscos, foram adicionados os principais formulários para cada uma das sete áreas de conhecimento que sofreram o processo de adaptação (aquisições, comunicação, custo, integração, qualidade, recursos humanos e tempo). Vale ressaltar que, devido ao termo de abertura ser um formulário que antecede a declaração de escopo, o mesmo não foi desassociado do Gerenciamento de Integração, no âmbito de formulários adaptáveis. Os formulários adaptados são:

Aquisição: Plano de aquisições.

Comunicação: Plano de comunicação e Identificação dos envolvidos. Custo: Plano de Custo.

Integração: Plano de integração e Avança Físico e financeiro. Qualidade: Plano de Qualidade e Controle de Qualidade.

Recursos Humanos: Matriz de Responsabilidade e Plano de RH.

Tempo: Plano de Tempo (o cronograma não foi adicionado a estes formulários, pois se utiliza software para gerir o cronograma).

D _– Definir valores para os formulários

Como visto anteriormente, os formulários adaptáveis terão três status: simples, intermediário e completo. Para se definir as duas faixas de valores necessários para efetuar esta divisão é necessário avaliar o valor que cada área de conhecimento pode assumir. A figura 8 demonstra os valores assumidos por cada risco versus área de conhecimento.

Figura 8 - Tabelas de tendência (t) x probabilidade (p) e t x p x impacto

(43)

Como a tendência e a probabilidade de ocorrer são valores do FR e o impacto é individualizado por área de conhecimento. Utilizaram-se a figura 6 para demonstrar o menos e o maior valor que um FR pode assumir perante a uma área de conhecimento.

Foi realizada uma pesquisa com o intuito de definir quais as áreas impactadas por cada um dos vinte e três FR sugeridos neste trabalho. O resultado é demonstrado na figura 9.

Tabela 8 - Quantidade de fatores de riscos que impacta cada área de conhecimento adaptável

Fonte: O autor

Nesta pesquisa foram listados os 23 FR e colocadas 7 colunas com cada uma das áreas de conhecimento que terão seus formulários adaptados. Sendo preenchido cada

campo com as opções “Impacta” ou “não Impacta”.

(44)

Tabela 9 - Valores que cada área de conhecimento pode assumir

Fonte: O autor

Com base nos valores identificados, optou-se por usar a média entre o valor máximo de uma faixa e o mínimo da faixa seguinte.

A Faixa I representa os valores que devem ser alcançados para serem disponibilizados os campos classificados como variáveis e a Faixa II para os campos complementares.

Deve-se rever as faixas de valores ao incluir novos riscos ou durante a aplicação deste modelo identificar que esta faixa está fora da necessidade da empresa.

E _– Definir campos necessários para cada estágio

Foi efetuada uma pesquisa com gerentes de projetos para definir quais os campos, de cada um dos formulários, são essenciais e quais podem ser suprimidos. Esta pesquisa

consta no apêndice “Formulário para pesquisa dos campos essencial”.

Este questionário foi elaborado em uma planilha eletrônica, na qual constam 2 abas.

(45)

Figura 9 - Descrição do preenchimento Fonte: Autor, 2009

Na segunda aba consta a lista de campos que compõem o questionário. Estes campos estão divididos por documento, ou seja, para cada um dos planos de gerenciamento existe uma sequência de campos pertencentes àquele formulário. A pesquisa está disposta da seguinte forma:

A - Código: é um campo que contem dois sequenciamentos, o primeiro é referente ao documento e o segundo referente ao campo naquele documento. Esta célula contém um comentário sobre as informações de preenchimento do campo no formulário. O comentário pode ser composto de três informações (descrição, forma e exemplo).

B - Título do campo: São os títulos de cada um dos campos do formulário.

C - Classificação: Este campo foi elaborado de forma a selecionar um dos 3 valores definidos. Estes valores são:

(46)

- Variável: Estes campos podem ser retirados do formulário. São campos que contem informações necessárias, porém a sua ausência não descaracteriza o formulário (dependendo da complexidade podem ser incluídos como opcionais).

- Complementar: Campos que complementam os formulários, sendo utilizados para um maior detalhamento do mesmo, sendo que a ausência deles não caracteriza falta de informação (utilizados para complementar ou atender necessidades específicas).

Ao selecionar uma das opções acima de classificação, a planilha marca a linha com uma cor específica. A figura 10 demonstra o comportamento da planilha eletrônica.

Figura 10 - Descrição do preenchimento Fonte: O autor, 2009

A definição de qual será a classificação final de cada um dos campos dos formulários adaptáveis será dada através de uma contagem da classificação do campo, ou seja, aquela classificação que se repetir mais vezes durante a pesquisa será pertencente àquele campo específico, conforme demonstrado no Apêndice – Resultado da pesquisa.

(47)

4. CONSIDERAÇÕES FINAIS

4.1. Resultado Adicional do Trabalho

Para uma melhor compreensão do modelo de adaptação baseada em riscos para projetos de TI foi proposto um sequenciamento das atividades de planejamento e sugerido um conjunto de formulários adaptáveis.

O sequenciamento das atividades foi desenvolvido com base nos modelos da Rita Mulcahy (2007) e da Kim Heldman (2005) e modificado de forma a atender a proposta do modelo. Para isso, foi necessário adiantar o planejamento de riscos, colocando-o logo após o planejamento do escopo. Com isso, pode-se efetuar a análise de risco antes das demais atividades de planejamento.

É pré-requisito do processo de adaptação a clareza e detalhamento dos documentos gerados pelo gerenciamento de escopo (declaração de escopo e plano de gerenciamento de escopo), pois é com base nestas informações que se dará inicio ao processo de adaptação, através da análise de risco.

O processo de adaptação utilizou a flexibilidade exposta pelos modelos ágeis, adequando os modelos de análise de risco para um melhor funcionamento no modelo. Estes modelos, juntamente com a utilização do PMBok como base do processo de adaptação, geraram um método que visa melhor dimensionar as áreas de conhecimento e minimizar o esforço do planejamento.

Os formulários adaptáveis foram elaborados a partir de outros existentes. Através da realização de uma pesquisa, identificou-se quais as áreas de conhecimentos seriam afetadas por cada fator de risco. O resultado desta pesquisa demonstra a necessidade de incluir ou suprimir determinadas informações dos formulários.

A cada inclusão de um novo fator de risco deve-se reavaliar os valores utilizados para adaptar os formulários.

Este conjunto de entregáveis completa a proposta deste trabalho.

4.2. Dificuldades Encontradas

(48)

4.3. Sugestão para Trabalhos Futuros

Sugere-se, para trabalhos futuros, endereçar as informações contidas nos formulários a cada fator de risco e identificar as interdependências entre estes campos, efetuando, assim, um processo de adaptação diretamente relacionado aos campos dos documentos.

(49)

REFERÊNCIA BIBLIOGRAFICA

FONTOURA, L. M.; PRICE R. T. Usando GQM para Gerenciar Riscos em Projetos de Software. In: 18º Simpósio Brasileiro de Engenharia de Software.

GRIMALDI, R.; MANCUSO, J.H. Qualidade Total. Folha de SP e Sebrae, 17/04/1994. 6º e 7º fascículos.

HELDMAN, K. Gerência de Projetos PMP Project Management Professional. 2º edição, 2005, Campos.

JUAREZ, A. A.; SCHITZ E. A. Análise de Risco em Gerência de Projetos. 1ª edição, 2006, Brasport.

JUAREZ, A. A.; SCHITZ E. A.; VILLAR, C. B. Modelos Qualitativos de Análise de Risco para Projetos de Tecnologia da Informação. 1ª edição, 2007, Brasport.

MARTINS, J. C. C. Técnicas Para Gerenciamento de Projetos de Software. 1º edição, 2007, Brasport.

MEIRELES, M. Ferramentas administrativas para identificar, observar e analisar problemas - organizações com foco no cliente. 1º edição, 2001, Arte & Ciência.

MOCCELLIN, J. V.; SACOMANO, J. B.; FUSCO, J. P. A.; GUERRINI, F. M.; SANTOS, M. T. S.. Administração de produção na construção civil o gerenciamento de obras baseado em critérios competitivos. 1º edição, 2004, Arte & Ciência.

MULCAHY, R. Preparatório para o Exame de PMP. 6º edição, 2007, RMC Publications.

PAIXÃO, L. C.; SCHMITZ, E. A. Antes de Propor: uma ferramenta de análise de risco e gerência de portfólio de projetos de sistemas de informação. Instituto de Matemática, UFRJ.

PASSOS, M. L. G. S. Gerenciamento de projetos para pequenas empresas: combinando boas práticas com simplicidade. 1º edição, 2008, Brasport

(50)

REFERÊNCIA ELETRÔNICA

http://www.pmi.org.br/ Acesso em 20 jan. 2009.

http://www.ricardovargas.com.br acessado 01 de jul. de 2008

http://www.qualidadeiso.com/qinews_noticia.jsp?id=339 acessado em 02 de abr. de 2009

Aguiar, M.; PSM - O CMM da Mensuração de Software? . Disponível em:

http://www.metricas.com.br/Downloads/PSM_CMM_Mensuracao_Software.pdf. Acesso em 20 jul. 2008.

Farias, T. M. M. Aplicação de padrões ao processo de desenvolvimento de software RUP. Brasil. Universidade Pernambuco. 2006. Disponível em:

http://www.wppf.uaivip.com.br/pesquisa/recentes/simpros2003-quantum.pdf

Sêmola, M. A nova abordagem de Governança, Gerenciamento de Risco e Conformidade. Disponível em: http://idgnow.uol.com.br/seguranca/firewall/idgcoluna.2008-06-30.9839068825/ Acesso em 20 jan. 2009.

Silva, J.; Viana, T.; Rodrigues, L.; Morais, F.; Zanata, G.; Leonardo, H.; Ageu, J.; Rangel, R.; Madruga, R. Bezerra, S. Aderência de um Processo Pesado(RUP) a um Modelo de Qualidade (MPS.BR). Disponível em:

http://www.unibratec.com.br/revistacientifica/n2_artigos/n2_silva_j.pdf. Acesso em 20 jul. 2008.

Diretrizes: Adaptação do Processo . Disponível em:

http://www.wthreex.com/rup/process/modguide/md_tailr.htm. Acesso em 20 nov. 2008.

CIPHER . GRC – Governança, Riscos e Compliance. Disponível em:

(51)

APÊNDICE