Plano de Projeto - UFPEfocus/documentos/gerencia/Plano... · 2010. 4. 22. · Plano de Projeto 2010 7 FOCUS! o Gerente de Projeto (Ícaro Valgueiro): Responsável pela coordenação

Plano de Projeto

Versão 1.2

22/04/2010

Plano de Projeto 2010

2 FOCUS!

Sumá rio

1. Histórico de revisões ............................................................................................................3

2. Introdução ............................................................................................................................4

2.1. Objetivos do documento ..............................................................................................4

2.2. Escopo ..........................................................................................................................4

2.3. Referências ...................................................................................................................5

2.3.1. Informações de sites da web ................................................................................5

2.3.2. Artigos ..................................................................................................................5

2.3.3. Exemplos e concorrentes .....................................................................................5

3. Processo ...............................................................................................................................6

3.1. Plano de recursos .........................................................................................................6

3.1.1. Recursos Humanos ...............................................................................................6

3.1.2. Recursos de Software ...........................................................................................7

3.1.3. Recursos de Hardware ..........................................................................................8

3.2. Ciclo de vida do produto ............................................................................................10

3.2.1. Fase 1: Concepção ..............................................................................................10

3.2.2. Fase 2: Elaboração ..............................................................................................12

3.2.3. Fase 3: Construção .............................................................................................13

3.2.4. Fase 4: Transição ................................................................................................15

4. Cronograma........................................................................................................................16

4.1. Análise de riscos .........................................................................................................19

4.1.1. Descrição ............................................................................................................19

4.1.2. Tipos de Risco .....................................................................................................19

4.2. Controle e monitoramento.........................................................................................27

4.3. Custo ..........................................................................................................................28


3 FOCUS!

1. HISTÓRICO DE REVISÕES

Data Versão Descrição Autor

03/04/2010 1.0 Definição inicial

do plano de projeto

Amora Cristina Anália Lima Átila Malta Caio César Ícaro Malta

Irineu Martins Laís Sousa

Leonardo Vieira Ricardo Queiroz

09/04/2010 1.1 Revisão do plano

de projeto Átila Malta Caio César

22/04/2010 1.2 Mudança no Cronograma

Ícaro Malta


4 FOCUS!

2. INTRODUÇÃO

2.1. OBJETIVOS DO DOCUMENTO

Este documento tem o objetivo de explicitar as principais características do Projeto

Arcadea e auxiliar na coordenação das atividades inerentes no desenvolvimento do mesmo.

Para facilitar a visualização de todas as etapas de elaboração da aplicação e gerenciamento

dos recursos envolvidos, são apresentadas, neste documento, informações relevantes, tais

como cronograma de atividades, estimativa de custo e previsão de riscos.

Dessa forma, fica disponível aos clientes e desenvolvedores uma visão clara do

processo de criação do projeto, possibilitando um maior acompanhamento e controle de seu

progresso.

2.2. ESCOPO

Atualmente o processo de desenvolvimento de software vem se tornando cada vez

mais multidisciplinar, a fim de proporcionar ao usuário um produto que alcance qualidade em

todos os aspectos. No entanto, o processo de formação de equipes que trabalham na

produção de software com tal característica, ainda não é realizado de maneira prática (em

especial quando se trata de equipes formadas a distância).

Além da formação, outros dois pilares que dão base à elaboração do produto, são a

organização e a motivação das equipes ao longo do projeto. Apesar da existência de

alternativas para prover esses dois valores, as mesmas têm sido praticadas de forma isolada

umas das outras na maioria dos casos.

Foi com base na análise desse contexto atual, que a Focus!, nossa empresa, decidiu

produzir o Arcadea, o qual consiste numa plataforma que dará suporte à formação e

organização de equipes multidisciplinares que trabalham com o desenvolvimento de software.

Além desta funcionalidade principal, o Arcadea proverá: compartilhamento de conhecimento

por meio de sistema de fórum e wiki; socialização entre desenvolvedores por meio de rede

social no sistema; divulgação de trabalhos através de suporte a portfólios dos usuários e

exibição dos projetos realizados pelas equipes.

O diferencial do Arcadea consistirá principalmente na inserção de elementos lúdicos

no sistema, os quais são provenientes de MMORPGs (Massive Multi-player Online Role-Playing

Game: jogos de interpretação massivos, online para múltiplos jogadores). Tal diferencial tem

como objetivo investir fortemente na motivação das equipes durante todo o desenvolvimento


5 FOCUS!

do projeto, e fazer com que esse ocorra de maneira tão divertida e motivante quanto jogar um

MMORPG.

2.3. REFERÊNCIAS

2.3.1. Informações de sites da web

http://itnews.com.au/News/169862,employers-look-to-gaming-to-motivate-staff.aspx http://www.cracked.com/article_18461_5-creepy-ways-video-games-are-trying-to-

get-you-addicted.html http://www.ted.com/talks/jane_mcgonigal_gaming_can_make_a_better_world.html

2.3.2. Artigos

Gama, A. T. da S. et al. O jogo como facilitador da aprendizagem. Coelho, F.C. P., Cabral Filho, A. V. Realidades sintéticas e MMORPG para a

comunicação. Yee, N. Motivations of play in MMORPGs. Oliveira, A. P., Veloso, A. I. Clãs e Guilda- dinâmicas, expectativas e motivações do

jogar em equipe. Filho, C. N. L. , Augusto Massive Multiplayer Online RPG - Impactos sociais. Buss O., Carla, Cunha D. Gilberto, Luce B., Fernando , Coordenação de equipes

multidiciplinares no desenvolvimento integrado de produtos. W. Bosseau Murray, MD, Patrick A. Foster, MB. ChB.Crisis Resource Management

Among Strangers: Principles of Organizing a Multidisciplinary Group for Crisis Resource Management.

2.3.3. Exemplos e concorrentes

http://www.deviantart.com/ http://www.igda.org/recife/ http://www.gamedev.com.br/ http://www.topcoder.com/ http://code.google.com/intl/pt-BR/ http://freela.com.br/ http://www.mantisbt.org/

http://www.cracked.com/article_18461_5-creepy-ways-video-games-are-trying-to-get-you-addicted.html

http://www.cracked.com/article_18461_5-creepy-ways-video-games-are-trying-to-get-you-addicted.html

http://www.ted.com/talks/jane_mcgonigal_gaming_can_make_a_better_world.html

http://www.igda.org/recife/

http://www.igda.org/recife/


6 FOCUS!

3. PROCESSO

O processo definido para a o desenvolvimento do projeto está baseado em outros

processos já existentes: o Rational Unified Process (RUP) e algumas características básicas das

metodologias de desenvolvimento ágil.

O desenvolvimento será dividido em quatro fases: concepção, elaboração, construção

e transição, semelhantes às do RUP. Para a execução de cada uma, teremos um

desenvolvimento feito em iterações, cada uma bem definida no contexto do ciclo de vida do

produto e do cronograma do projeto.

As principais características do processo adotado são:

o Iterativo e incremental; o Iterações curtas; o Fechamento de Builds semanais na fase de construção; o Reuniões gerais para planejamento da próxima iteração; o Integração contínua; o Definição de padrões de codificação; o Código coletivo; o Sistema de revisão de código

Os documentos principais que deverão ser definidos neste projeto são:

o Plano de Projeto o Plano de Testes o Game Design o Documento de Requisitos o Documento de Análise

3.1. PLANO DE RECURSOS

3.1.1. Recursos Humanos

Os membros do Projeto Arcadea foram distribuídos de acordo com suas experiências

técnicas, habilidades e preferências, a fim de que o projeto seja concluído da melhor forma, no

tempo esperado e com as funcionalidades previstas.

A equipe será distribuída da seguinte forma:


7 FOCUS!

o Gerente de Projeto (Ícaro Valgueiro): Responsável pela coordenação do grupo,

definição do cronograma, acompanhamento e tomada decisões referente ao projeto;

o Gerente de Arquitetura e Tecnologia (Caio César): Irá definir e fornecer as tecnologias

necessárias à implementação do projeto, gerenciar o processo de treinamento da

equipe, definir e atualizar a arquitetura do sistema.

o Gerente de Usabilidade (Denise Tenório): Tem como responsabilidade a gestão dos

projetos de design e direção de arte das plataformas de comunicação e software,

cuidando principalmente da usabilidade da interface gráfica do produto;

o Gerente de Banco de dados (Laís Andrade): Tem o papel de planejar a estrutura do

banco de dados assim como gerenciar qualquer alteração no mesmo.

o Gerente de Testes (Anália Lima): Irá elaborar o plano de testes e ficará responsável

pela sua execução, reportanto os erros encontrados e garantindo a máxima corretude

do sistema;

o Game Designer (Matheus Luck): Irá gerenciar e validar os elementos e a ambientação

dos elementos de jogo incluído no projeto, definindo e balanceando regras e

elementos de jogabilidade. Co-orientará a usabilidade e a arte sob o ângulo de um

jogo e para um jogador, ao invés de um software para um usuário;

o Designer (Alice Araújo): Responsável pela produção artística do produto;

o Desenvolvedores (Amora Cristina, Átila Valgueiro, Cleivson Siqueira, Irineu Martins,

Ivan França, Ivson Diniz, Leonardo Vieira, Pedro Augusto e Ricardo Jorge):

Responsáveis pela implementação do sistema e pela correção dos erros reportados

nas etapas de testes;

3.1.2. Recursos de Software

O desenvolvimento do Arcadea utilizará um conjunto bem definido de ferramentas e

tecnologias. Abaixo segue uma lista de tais recursos categorizados por sua área de aplicação:

o Gerenciamento de projeto e configuração

MS Project 2010 Beta

Mantis

Tortoise SVN

Subclipse

Rapid SVN

Microsoft Office 2010 beta

Google Docs

Star UML

o Desenvolvimento web/cliente

Flex SDK Plugin


8 FOCUS!

Paint.NET

BlazeDS

o Desenvolvimento web/servidor

J2EE

Struts

Spring Framework

Apache TomCat 6

o Comunicação e Gerencimaneto de Banco de Dados

MySQL

Hibernate

o Prototipagem

Wix

o Implementação e execução de testes

Junit

o Desenvolvimento em geral

Eclipse SDK

Notepad++

3.1.3. Recursos de Hardware

Os recursos de hardware para o desenvolvimento do projeto serão compostos de

computadores do centro e notebooks pessoais. Quanto aos recursos necessários para o

servidor da aplicação, faz-se necessário um serviço de hospedagem com os seguintes

requisitos de hardware:

o Alta capacidade de armazenamento: isso se deve ao fato de o banco de dados da

aplicação armazenar muita informação. Prefere-se que o serviço de hospedagem

dê espaço ilimitado, mas o mínimo necessário para as versões iniciais é 100 GB.

o Alta capacidade de processamento: isso se deve ao fato de o sistema ser utilizado

por uma enorme quantidade de usuários. O processador deve utilizar quatro ou

mais núcleos nas versões inicias.

o Alta capacidade de transferência de dados: o tráfego de dados no sistema deve

ser elevado, portanto é necessário que o serviço de hospedagem tenha uma

capacidade de transferência elevada (inicialmente a no mínimo 100 Mbps).

o Alta estabilidade: é necessário que o servidor esteja disponível 24 horas por dia.


9 FOCUS!


10 FOCUS!

3.2. CICLO DE VIDA DO PRODUTO

O ciclo de vida do produto será dividido em fases, semelhantes em nome e em

significado com as fases definidas pelo RUP (Rational Unified Process). Estas fases definem a

ênfase dada no projeto e são compostas de iterações, e estas últimas divididas em etapas de

execução. No total, o ciclo de vida do Arcadea é composto de 12 iterações, distribuídas entre

as 4 fases principais. Segue abaixo a descrição detalhada das fases que formam o processo de

desenvolvimento:

3.2.1. Fase 1: Concepção

Descrição: Esta fase contém os fluxos de trabalho necessários para que as partes interessadas

(stakeholders) concordem com os objetivos, arquitetura e o planejamento do projeto.

o Iteração 1: Concepção do tema

Descrição: Visa buscar e definir o tema que será adotado pela equipe para

desenvolvimento desse projeto.

Etapas:

Etapa 1: Prospecção

Descrição: Esta etapa inicia-se com a busca inicial do tema do projeto e

definição da idéia, e se finaliza com a definição formal do que está sendo

proposto pela equipe. Nela teremos discussões de idéias entre a equipe,

pesquisa e fundamentação das melhores idéias para enfim obter uma proposta

e construir a defesa do projeto.

Atividades:

o Concepção da Idéia - A equipe realiza reuniões para levantamento de

idéias e discute sobre as mesmas, levantando o que esta idéia irá resolver,

quem será o público alvo e como nossa proposta irá se diferenciar daquilo

que já existe. Através dessas reuniões será possível formar a idéia de

produto concreto que venha a trazer inovação ao mercado e de

preferência um mercado inexplorado.

o Pesquisa - Serão realizadas pesquisas sobre as idéias discutidas na etapa

de concepção com o objetivo de analisar os concorrentes e informações do


11 FOCUS!

público-alvo. Nessa etapa será feita a análise de literatura, buscando

artigos, pesquisas, publicações que venham a solidificar a idéia. Serão

entrevistados profissionais que tenham conhecimento sobre o que nos

propomos a solucionar, com o intuito de promover uma troca de

conhecimento que venha a nos auxiliar e também direcionar durante essas

pesquisas.

o Desenvolvimento da proposta - Nessa etapa já se tem uma idéia

fundamentada e agora serão feitas discussões sobre como a proposta será

apresentada para os financiadores.

Milestone: Definição da defesa do tema, com fundamentação para o tema

escolhido.

o Iteração 2: Concepção do projeto

Descrição: iteração inicial do projeto, que definirá os artefatos iniciais para a

organização da equipe e para a defesa do projeto.

Etapas:

Etapa 1: Planejamento

Descrição: Esta etapa definirá a defesa formal do projeto que está sendo

proposto pela equipe. Nela são avaliados os componentes e funcionalidades

do produto e definiremos a nossa organização para o seu desenvolvimento.

Após a análise de fatores relacionados ao processo de desenvolvimento, é

possível determinar a viabilidade do projeto.

Atividades:

o Definição do escopo do produto - Define-se junto aos stakeholders de

forma clara e não ambígua, o que irá incorporar o software.

o Definição do cronograma - Através escopo definido, o gerente irá definir o

cronograma do projeto.

o Definição do plano de projeto.

Milestone: Obtenção da defesa do projeto e do documento de plano de

projeto.


12 FOCUS!

3.2.2. Fase 2: Elaboração

Descrição: Nesta fase será feito o projeto do sistema, buscando complementar o

levantamento e a documentação dos casos de uso, voltado para a arquitetura do sistema,

revisa a modelagem do negócio para os projetos e inicia a versão do manual do usuário.

o Iteração 3: Elaboração inicial dos requisitos

Descrição: definição de artefatos relacionados com a elicitação de requisitos.

Etapas:

Etapa 1: Levantamento

Descrição: Nesta etapa, os últimos preparos devem ser feitos antes do início

do desenvolvimento. Os requisitos devem ser levantados e os casos de uso e

testes devem ser definidos.

Atividades:

o Levantamento da lógica do meta-jogo - nesta etapa uma visão mais

concreta deve ser apresentada de como será a lógica do jogo que guiará

todo o processo de interação do usuário com o produto.

o Levantamento de Requisitos - os requisitos, depois de claramente

elicitados, serão formalmente descritos no Documento de Requisitos, para

servirem de guia durante todo o processo de desenvolvimento.

o Definição do plano de testes - em paralelo com a definição dos casos de

uso, o documento de testes deverá ser definido, para início da

implementação do código de testes.

Milestone: Definição da versão inicial dos documentos de requisitos, Game

Design e testes.

o Iteração 4: Elaboração da arquitetura inicial

Descrição: definição de artefatos relacionados com a arquitetura do sistema.

Etapas:

Etapa 1: Elaboração inicial


13 FOCUS!

Descrição: Questões mais técnicas devem ser definidas e analisadas nesta

etapa, de modo que os documentos sejam mais técnicos e possam servir de

base para a implementação do produto.

Atividades:

o Definição da arquitetura - depois de definidos os requisitos e a lógica do

meta-jogo, a arquitetura do sistema será elaborada, e a mesma deverá ser

seguida em todas as futuras etapas de desenvolvimento.

o Definição do documento de análise - com a arquitetura definida, o

documento de análise será construído.

o Definição das tecnologias - deve-se definir quais tecnologias são mais

adequadas para implementação das funcionalidades sobre a arquitetura

definida.

o Treinamento da equipe - a equipe deverá ser treinada nas tecnologias

definidas na etapa anterior.

Milestone: Definição da versão inicial dos documentos de análise do projeto.

3.2.3. Fase 3: Construção

Descrição: Na fase de construção, começa-se o desenvolvimento do software propriamente

dito, produção de códigos, testes alfa e beta. Serão feitas “baselines” de versões que tenham

passado pela rodada de teste satisfatoriamente.

o Iteração 5-11

Descrição: as iterações desde a quinta até a décima primeira possuem a mesma

estrutura, e ao final de cada uma deverá existir uma versão estável do produto,

mesmo que não definitiva.

Etapas:

Etapa 1: Reavaliação

Descrição: nesta etapa deve ser realizado o planejamento da iteração,

podendo ocorrer aqui negociação de escopo, mudança no cronograma ou na

arquitetura, por exemplo.

Atividades:


14 FOCUS!

o Planejamento da iteração - planejamento do que vai ser realizado nesta

iteração, levando em conta o que foi feito até o momento e o que resta a

ser feito para a conclusão do projeto. Pode ser feita aqui a negociação do

escopo ou mudança de cronograma.

o Replanejamento da Arquitetura - realizado para avaliar a necessidade de

mudança na arquitetura.

Milestone: Versão atualizada dos documentos definidos inicialmente na

segunda iteração e plano da iteração.

Etapa 2: Desenvolvimento

Descrição: nesta etapa será implementado o código propriamente dito do

produto.

Atividades:

o Desenvolvimento - o código referente aos casos de uso planejados para

esta iteração são implementados, e os erros do código da iteração

passada, que vão sendo reportados pela equipe de testes, são corrigidos.

o Testes - o código de testes referentes a build final desta iteração é

implementado pela equipe de testes, enquanto o código da iteração

passada é testado e os erros são reportados.

Milestone: Build estável do sistema, referente ao que estava previsto para esta

iteração.

Etapa 3: Validação

Descrição: ao final da iteração o build gerado, caso já atinja um bom nível de

maturidade e estabilidade, deve ser validado e, em caso de release, deve ser

implantado para o usuário. A iteração também deve ser avaliada.

Atividades:

o Validação do sistema - o sistema como está no momento deve ser

validado com usuários que representem o público alvo.

o Implantação do sistema - em caso de release, o sistema deve ser

disponibilizado ao usuário final.

o Avaliação da iteração - a iteração deve ser avaliada para determinar a

necessidade de refinamento/correção nas próximas.

Milestone: Build validada e implantada.


15 FOCUS!

3.2.4. Fase 4: Transição

Descrição: Nesta fase ocorre a entrega do software, é realizado o plano de implantação e

entrega, acompanhamento e qualidade do software.

o Iteração 12

Descrição: Esta última iteração deve implantar o sistema final, deixando-o aberto para

novos usuários.

Etapas:

Etapa 1: Implantação

Descrição: o sistema produzido deve ser implantado ao usuário final.

Atividades:

o Implantação do sistema - em caso de release, o sistema deve ser

disponibilizado ao usuário final.

Milestone: Sistema entregue e implantado.


16 FOCUS!

4. CRONOGRAMA

Tendo em vista o modelo de processo adotado e os prazos de entrega estabelecidos, o

cronograma foi estruturado como descrito abaixo:

Arcadea 85 days Mon 3/15/10 Sat 6/19/10

1. Fase de Concepção 19 days Mon 3/15/10 Wed 4/7/10

1.1. Iteração 1 11 days Mon 3/15/10 Mon 3/29/10

1.1.1 Definição do Tema 6 days Mon 3/15/10 Mon 3/22/10

1.1.2. Construção da defesa do tema 6 days Mon 3/22/10 Mon 3/29/10

1.1.3. Defesa do Tema 1 day Mon 3/29/10 Mon 3/29/10

1.2. Iteração 2 9 days Mon 3/29/10 Wed 4/7/10

1.2.1. Construção da defesa do projeto 7 days Mon 3/29/10 Mon 4/5/10

1.2.2. Defesa do projeto 1 day Wed 4/7/10 Wed 4/7/10

1.2.3. Construção do plano de projeto 6 days Mon 3/29/10 Sun 4/4/10

2. Fase de Elaboração 17 days Wed 4/7/10 Sat 4/24/10

2.1. Iteração 3 5 days Wed 4/7/10 Mon 4/12/10

2.1.1. Levantamento inicial dos requisitos 3 days Wed 4/7/10 Fri 4/9/10

2.1.2. Criação de questionário com intuito de levantar opinião do usuário sobre os requisitos

1 day Sat 4/10/10 Sat 4/10/10

2.1.3. Elicitação dos requisitos 1 day Sat 4/10/10 Sat 4/10/10

2.1.4. Definição dos casos de uso 2 days Sat 4/10/10 Mon 4/12/10

2.1.5. Construção do documento de requisitos 5 days Wed 4/7/10 Mon 4/12/10

2.1.6. Capacitação das Tecnologias Utilizadas 1º Parte 5 days Wed 4/7/10 Mon 4/12/10

2.2. Iteração 4 13 days Mon 4/12/10 Sat 4/24/10

2.2.1. Definição da arquitetura do sistema 12 days Mon 4/12/10 Fri 4/23/10

2.2.2. Construção do documento de análise e projeto 13 days Mon 4/12/10 Sat 4/24/10

2.2.3. Construção do plano de testes 6 days Mon 4/12/10 Sat 4/17/10

2.2.4. Definição das tecnologias a serem utilizadas 3 days Mon 4/12/10 Wed 4/14/10

2.2.5. Capacitação das Tecnologias Utilizadas 2º Parte 13 days Mon 4/12/10 Sat 4/24/10

3. Fase de Construção 51 days Sat 4/24/10 Sat 6/19/10

3.1. Iteração 5 7 days Sat 4/24/10 Sat 5/1/10

3.1.2. Elaboração da Iteração 1 day Sat 4/24/10 Sat 4/24/10

3.1.4. Construção 5 days Mon 4/26/10 Fri 4/30/10

3.1.5. Fechamento da Build 0.1 1 day Sat 5/1/10 Sat 5/1/10


17 FOCUS!


3.2.1. Reavaliação da Arquitetura do Sistema 1 day Sat 5/1/10 Sat 5/1/10


3.2.3. Execução da Rodada de Testes da versão 0.1 6 days Mon 5/3/10 Sat 5/8/10



3.2.6. Status Report da versão 0.2 1 day Sat 5/8/10 Sat 5/8/10







3.4. Iteração 8 8 days Sat 5/15/10 Mon 5/24/10



3.4.3. Execução da Rodada de Testes da versão 0.3 7 days Mon 5/17/10 Mon 5/24/10

3.4.4. Construção 3 days Mon 5/17/10 Wed 5/19/10


3.4.7. Construção da Apresentação do Release 1 5 days Wed 5/19/10 Mon 5/24/10

3.4.8. Apresentação da versão 1.0 1 day Mon 5/24/10 Mon 5/24/10

3.5. Iteração 9 6 days Mon 5/24/10 Sat 5/29/10

3.5.1. Reavaliação da Arquitetura do Sistema 1 day Mon 5/24/10 Mon 5/24/10

3.5.2. Elaboração da Iteração 1 day Mon 5/24/10 Mon 5/24/10







3.6.3. Execução da Rodada de Testes da versão 1.3 5 days Tue 6/1/10 Sat 6/5/10

3.6.4. Construção 4 days Tue 6/1/10 Fri 6/4/10






18 FOCUS!












4. Fase de transição 12 days Sat 6/19/10 Mon 7/5/10

4.1. Iteração 13 12 days Sat 6/19/10 Mon 7/5/10

4.1.1. Validação final do sistema 1 day Sat 6/19/10 Sat 6/19/10

4.1.2. Implantação do produto 11 days Sat 6/19/10 Fri 7/2/10

4.1.3. Preparação da Apresentação para a Feira 12 days Sat 6/19/10 Sat 7/3/10

4.1.3. Feira de Projetos 1 day Mon 7/5/10 Mon 7/5/10


19 FOCUS!

4.1. ANÁLISE DE RISCOS

4.1.1. Descrição

Esta parte do documento consiste do estudo, durante a fase de concepção ou

desenvolvimento preliminar de um novo projeto ou sistema, com a finalidade de se

determinar os possíveis riscos que poderão ocorrer na sua fase operacional.

Para facilitar este processo utilizaremos a seguinte tabela para construirmos a

avaliação dos impactos:

Probabilidade

Muito frequente

Ocasional

Raro

Perigo

Muito perigoso

Normal

Pouco perigoso

Cada cor refere a uma gravidade diferente do impacto:

Impacto

Alto

Médio

Baixo

4.1.2. Tipos de Risco

o Risco de infra-estrutura

Falta de máquinas para todos os componentes da equipe

Probabilidade Ocasional

Perigo Normal

Impacto Médio

Indicadores Ociosidade de alguns integrantes no ambiente de trabalho

Estratégias de Mitigação Levar máquinas quando possível

Plano de contingência Utilizar prática de Pair-programming


20 FOCUS!

Dificuldade para ter acesso às ferramentas necessárias

Probabilidade Muito frequente

Perigo Muito perigoso

Impacto Alto

Indicadores Produção comprometida

Estratégias de Mitigação Entrar em contato com o suporte para adquirir licença de administrador

Plano de contingência Dar prioridade às atividades que não necessitam da ferramenta

Ambiente de trabalho coletivo com problemas técnicos



Impacto Alto


Estratégias de Mitigação Levar máquinas quando possível

Plano de contingência Pedir ajuda ao suporte

Falta de ambiente fixo para trabalhar ou fazer reuniões



Impacto Alto


Estratégias de Mitigação Tentar reservar laboratórios

Plano de contingência Compensar o tempo perdido alocando tarefas individuais e remotas

o Risco de tecnologia

Processo longo de aprendizagem das novas tecnologias pelos membros do grupo



Impacto Alto

Indicadores Demora na entrega dos artefatos

Estratégias de Mitigação Investir em cursos, workshops e treinamentos internos

Plano de contingência Alocar horários extras de estudo e treino, além de procurar um especialista da área que possa auxiliar


21 FOCUS!

Super estimar soluções



Impacto Alto

Indicadores Atraso muito grande no cronograma

Estratégias de Mitigação Conhecer bem cada tecnologia para então começar a usar

Plano de contingência A depender do caso, investir em treinamento ou mudar a tecnologia

o Risco de documentação

Erro na estimativa de custos


Perigo Normal

Impacto Baixo

Indicadores Valor arrecadado inicialmente não condiz com o necessário para os pagamentos

Estratégias de Mitigação Acrescentar uma pequena porcentagem ao custo inicial, relativa ao planejamento inicial de pagamento

Plano de contingência O membro responsável pelos pagamentos convoca uma reunião de caráter emergencial

Alteração dos requisitos



Impacto Alto

Indicadores Sistema inconsistente, ou sem propósito

Estratégias de Mitigação Analisar com muito cuidado todos os documentos

Plano de contingência Remodelar de forma a minimizar os impactos das alterações


22 FOCUS!

Erro na coleta de requisitos



Impacto Alto

Indicadores Funcionalidades que deveriam estar presentes como requisitos não são implementadas

Estratégias de Mitigação Verificar inicialmente se ao seguir todo o planejamento o sistema possui todas as funcionalidades

Plano de contingência Inserir a funcionalidade de forma a minimizar o impacto no sistema

Mudança no modelo do banco



Impacto Alto

Indicadores Algumas funcionalidades estão paradas porque não têm a informação necessária para funcionar

Estratégias de Mitigação Tentar fazer todos os levantamentos possíveis ainda no começo do projeto

Plano de contingência Remodelar e inserir toda a informação necessária do modo menos danoso possível

Critério de aceitação não previsto



Impacto Alto

Indicadores Baixa aceitação do produto

Estratégias de Mitigação Fazer o levantamento de usabilidade de forma detalhada

Plano de contingência Mudar o mínimo da estrutura básica do programa de forma a atender ao cliente


23 FOCUS!

o Risco de implementação

Baixa qualidade de um componente do sistema

Probabilidade Raro


Impacto Médio

Indicadores Uma funcionalidade do sistema se comporta de maneira inesperada ou é de difícil integração

Estratégias de Mitigação Garantir a corretude do componente durante a implementação usando boas práticas de programação

Plano de contingência Relatar tal comportamento como um bug de alta prioridade

Falha na integração de diversos subsistemas em uma conta única (Wiki, Fórum, Arcadea)

Probabilidade Raro


Impacto Médio

Indicadores Contas inconsistentes

Estratégias de Mitigação Planejar bem antes de implementar a integração

Plano de contingência Relatar tal comportamento como um bug de alta prioridade

Erros no balanceamento do jogo


Perigo Normal

Impacto Médio

Indicadores Ações no jogo não trazem a recompensa esperada, o que pode significar beneficiar demais por pouco esforço ou não dar recompensa o suficiente por trabalhos grandes

Estratégias de Mitigação Realizar testes internos para avaliar como se daria o progresso de um jogador

Plano de contingência Relatar o componente a ser balanceado como um bug


24 FOCUS!

o Risco de grupo

Dificuldade de divisão de atividades


Perigo Pouco perigoso

Impacto Baixo

Indicadores Pessoas sem atividade

Estratégias de Mitigação Tentar sempre dividir o máximo possível as atividades

Plano de contingência Antecipar atividades

Falta de interesse de um ou mais membros da equipe

Probabilidade Raro

Perigo Normal

Impacto Baixo

Indicadores Queda de produtividade sem motivo justificado

Estratégias de Mitigação O gerente mantém contato constante com toda a equipe de forma a observar o estado de cada um

Plano de contingência Realocação das atividades deste membro para um membro menos ocupado e reunião do membro desinteressado com o gerente para entender a fonte do problema

Conflito de horários disponíveis entre os membros do grupo



Impacto Médio

Indicadores Reuniões com muitas faltas justificadas

Estratégias de Mitigação Marcar atividades durante finais de semana e/ou à noite.

Plano de contingência Tentar fazer o máximo para que os que estão com horário disponível trabalhem


25 FOCUS!

Ausência imprevisível de um ou mais membros do grupo por um longo período de tempo


Perigo Normal

Impacto Médio

Indicadores Falta de um modulo ou parte de um artefato

Estratégias de Mitigação Utilizar sistema de controle de atividades

Plano de contingência Realocar equipe para diminuir a carência

Conflito interno na equipe



Impacto Alto

Indicadores Falta de diálogo entre integrantes do grupo

Estratégias de Mitigação Estabelecer dinâmicas de grupos

Plano de contingência Promover o entendimento entre os integrantes

Sobrecarga dos membros da equipe


Perigo Normal

Impacto Alto

Indicadores Ocorrência de provas e projetos

Estratégias de Mitigação Considerar os horários de atividades extras ou acadêmicas de todos os integrantes antes de definir o cronograma do projeto

Plano de contingência Aumentar a produtividade de cada integrante, e, consequentemente, da equipe como um todo


26 FOCUS!

o Risco de complexidade e tempo

Complexidade da interface gráfica

Probabilidade Muito freqüente


Impacto Médio

Indicadores Camada de negócio feita, porém a interface está atrasando o build

Estratégias de Mitigação Alocar pessoas permanentemente com as interfaces

Plano de contingência Alocar mais pessoas com interfaces

Curto prazo para a entrega de artefatos



Impacto Alto

Indicadores Atraso na disponibilização de funcionalidades e entrega de documentos

Estratégias de Mitigação Planejar bem o cronograma e distribuir bem as atividades

Plano de contingência Alocar mais membros no desenvolvimento dos artefatos em questão e subdividi-lo em partes menores quando possível

Sobrecarga de membros associados à produção de artefatos artísticos



Impacto Alto

Indicadores Atraso nas entregas dos artefatos artísticos

Estratégias de Mitigação Antecipar o máximo possível os requisitos artísticos e o documento de Game Design

Plano de contingência Tentar alocar mais pessoas para construir artefatos artísticos


27 FOCUS!

4.2. CONTROLE E MONITORAMENTO

Descrição

O controle e monitoramento do cronograma bem como de todas as atividades da

equipe serão de responsabilidade do gerente de projeto. Ao final de toda semana, mais

precisamente na sexta-feira, haverá um encontro onde o gerente cobra resultados das

atividades da semana e atribui tarefas a cada integrante da equipe para a próxima. Através

desses resultados, poderá ser feita uma comparação com o cronograma a fim de se estimar o

andamento do projeto e certificar-se de que os prazos foram estimados corretamente e

antecipar riscos. A partir de cada reunião, o gerente estará incumbido de comunicar os prazos

a serem atingidos. Havendo atrasos, as estratégias de desenvolvimento deverão ser revistas.

Detalhamento

o Políticas

Política de controle de atividades

o Pretendem-se entregar os releases com prazo um pouco de

antecipação.

o Documentação de código é obrigatória e deve ser feita à medida

que é implementado e não na conclusão do projeto.

o O sistema obrigatoriamente terá uma interface amigável e

intuitiva.

Política de atividade

o Para melhorar a visualização do status de cada atividade

utilizaremos uma ferramenta para prover a gerência de atividades.

o Cada reunião terá como artefato gerado uma pauta e uma ata. Na

pauta estarão escrito todos os tópicos que serão discutidos na

reunião. Na ata, os pontos de pautas serão descritos com o

máximo de detalhamento possível de modo que as pessoas que

não puderem comparecer tenham uma boa idéia do que foi

decidido na reunião.

o Dificuldade de realização de tarefas deverá ser imediatamente

comunicada ao gerente de projeto.


28 FOCUS!

4.3. CUSTO

O principal intuito de levantarmos os custos nesta etapa é compreender quais serão as

principais despesas do grupo de modo que seja possível ter maior controle dos gastos para

minimizá-los. Faz-se necessário observar que boa parte da infra-estrutura será cedida pelo

Departamento de Informática da Universidade Federal de Pernambuco, deste modo custos

referentes ao ambiente de trabalho e de reuniões podem ser cortados (energia, ambiente

físico, computadores, periféricos). Além disso, todos os softwares que serão utilizados têm

licença de uso gratuita. Portanto, podemos dizer que o maior custo do projeto serão os

recursos humanos, já que temos uma equipe relativamente grande. Descrição mais detalhada

dos custos do projeto pode vista nas tabelas a seguir:

Recursos Humanos

Nome Função Preço/Hora Preço total

Alice Araujo Designer R$ 10,00/h R$ 1.250,00

Amora Albuquerque Desenvolvedor R$ 10,00/h R$ 1.250,00

Anália Lima Gerente de Testes R$ 15,00/h R$ 1.875,00

Átila Valgueiro Desenvolvedor R$ 10,00/h R$ 1.250,00

Caio César Gerente de Arquitetura e Tecnologia

R$ 15,00/h R$ 1.875,00

Cleivson Siqueira Desenvolvedor R$ 10,00/h R$ 1.250,00

Denise Tenório Gerente de Usabilidade R$ 15,00/h R$ 1.875,00

Ícaro Valgueiro Gerente de Projeto R$ 15,00/h R$ 1.875,00

Ivan França Desenvolvedor R$ 10,00/h R$ 1.250,00

Irineu Martins Desenvolvedor R$ 10,00/h R$ 1.250,00

Ivson Diniz Desenvolvedor R$ 10,00/h R$ 1.250,00

Lais Sousa Gerente de Banco de dados R$ 15,00/h R$ 1.875,00

Leonardo Vieira Tesoureiro / Desenvolvedor R$ 10,00/h R$ 1.250,00

Matheus Luck Game Designer R$ 15,00/h R$ 1.875,00

Pedro Augusto Desenvolvedor R$ 10,00/h R$ 1.250,00

Ricardo Jorge Desenvolvedor R$ 10,00/h R$ 1.250,00


29 FOCUS!

Orçamento tecnologias

Tipo do recurso Preço

Desenvolvimento em geral

Eclipse 3.4 R$ 0,00

Implementação e execução de testes

Junit R$ 0,00

Comunicação e gerenciamento de Banco de Dados

Hibernate R$ 0,00

MySQL R$ 0,00

Desenvolvimento web/servidor

Apache TomCat 6 R$ 0,00

J2EE R$ 0,00

Struts R$ 0,00

Spring Framework R$ 0,00

Desenvolvimento web/cliente

Ajax R$ 0,00

Flex SDK Plugin R$ 0,00

Notepad++ R$ 0,00

Paint.net R$ 0,00

BlazeDS R$ 0,00

Gerenciamento de projeto e configuração

MS Project 2010 Beta R$ 0,00

Mantis R$ 0,00

Tortoise SVN R$ 0,00

Subclipse R$ 0,00

Rapid SVN R$ 0,00

Microsoft Office 2010 Beta R$ 0,00

Google Docs R$ 0,00

Star UML R$ 0,00

Recurso de Divulgação

Nome do recurso

Preço/Unidade Preço

Camisa R$ 20,00 R$ 300,00

Banner R$ 40,00/m² R$ 50,00

Recurso de Infra-Estrutura

Nome do

recurso Preço/Tempo Preço

Hospedagem R$30,00/mês R$ 150,00

Domínio R$50,00/Ano R$ 50,00

TIPO CUSTO

ORÇAMENTO TECNOLÓGICO R$ 0,00

RECURSO DE DIVULGAÇÃO R$ 350,00

RECURSO DE INFRA-ESTRUTURA R$ 200,00

CUSTO TOTAL R$ 550,00

Documents

Plano de Projeto - UFPEfocus/documentos/gerencia/Plano... · 2010. 4. 22. · Plano de Projeto 2010 7 FOCUS! o Gerente de Projeto (Ícaro Valgueiro): Responsável pela coordenação