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
Plano de Projeto 2010
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
Plano de Projeto 2010
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
Plano de Projeto 2010
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/
Plano de Projeto 2010
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:
Plano de Projeto 2010
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
Plano de Projeto 2010
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.
Plano de Projeto 2010
9 FOCUS!
Plano de Projeto 2010
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
Plano de Projeto 2010
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.
Plano de Projeto 2010
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
Plano de Projeto 2010
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:
Plano de Projeto 2010
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.
Plano de Projeto 2010
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.
Plano de Projeto 2010
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
Plano de Projeto 2010
17 FOCUS!
3.2. Iteração 6 7 days Sat 5/1/10 Sat 5/8/10
3.2.1. Reavaliação da Arquitetura do Sistema 1 day Sat 5/1/10 Sat 5/1/10
3.2.2. Elaboração da Iteração 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.4. Construção 5 days Mon 5/3/10 Fri 5/7/10
3.2.5. Fechamento da Build 0.2 1 day Sat 5/8/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.3. Iteração 7 8 days Sat 5/8/10 Sat 5/15/10
3.3.1. Reavaliação da Arquitetura do Sistema 1 day Sat 5/8/10 Sat 5/8/10
3.3.2. Elaboração da Iteração 1 day Sat 5/8/10 Sat 5/8/10
3.3.3. Execução da Rodada de Testes da versão 0.2 6 days Mon 5/10/10 Sat 5/15/10
3.3.4. Construção 5 days Mon 5/10/10 Fri 5/14/10
3.3.5. Fechamento da Build 0.3 1 day Sat 5/15/10 Sat 5/15/10
3.4. Iteração 8 8 days Sat 5/15/10 Mon 5/24/10
3.4.1. Reavaliação da Arquitetura do Sistema 1 day Sat 5/15/10 Sat 5/15/10
3.4.2. Elaboração da Iteração 1 day Sat 5/15/10 Sat 5/15/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.5. Fechamento da Build 1.0 1 day Sat 5/22/10 Sat 5/22/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.5.3. Execução da Rodada de Testes da versão 1.0 6 days Mon 5/24/10 Sat 5/29/10
3.5.4. Construção 5 days Mon 5/24/10 Fri 5/28/10
3.5.5. Fechamento da Build 1.1 1 day Sat 5/29/10 Sat 5/29/10
3.6. Iteração 10 8 days Sat 5/29/10 Sat 6/5/10
3.6.1. Reavaliação da Arquitetura do Sistema 1 day Sat 5/29/10 Sat 5/29/10
3.6.2. Elaboração da Iteração 1 day Sat 5/29/10 Sat 5/29/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
3.6.5. Fechamento da Build 1.4 1 day Sat 6/5/10 Sat 6/5/10
3.6.6. Status Report da versão 1.4 1 day Sat 6/5/10 Sat 6/5/10
3.7. Iteração 11 7 days Sat 6/5/10 Sat 6/12/10
3.7.1. Reavaliação da Arquitetura do Sistema 1 day Sat 6/5/10 Sat 6/5/10
Plano de Projeto 2010
18 FOCUS!
3.7.2. Elaboração da Iteração 1 day Sat 6/5/10 Sat 6/5/10
3.7.3. Execução da Rodada de Testes da versão 1.4 6 days Mon 6/7/10 Sat 6/12/10
3.7.4. Construção 5 days Mon 6/7/10 Fri 6/11/10
3.7.5. Fechamento da Build 2.0 1 day Sat 6/12/10 Sat 6/12/10
3.8. Iteração 12 7 days Sat 6/12/10 Sat 6/19/10
3.8.1. Reavaliação da Arquitetura do Sistema 1 day Sat 6/12/10 Sat 6/12/10
3.8.2. Elaboração da Iteração 1 day Sat 6/12/10 Sat 6/12/10
3.8.3. Execução da Rodada de Testes da versão 1.4 6 days Mon 6/14/10 Sat 6/19/10
3.8.4. Construção 5 days Mon 6/14/10 Fri 6/18/10
3.8.5. Fechamento da Build 2.0 1 day Sat 6/19/10 Sat 6/19/10
3.8.6. Status Report da versão 2.0 1 day Sat 6/19/10 Sat 6/19/10
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
Plano de Projeto 2010
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
Plano de Projeto 2010
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
Probabilidade Ocasional
Perigo Muito perigoso
Impacto Alto
Indicadores Produção comprometida
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
Probabilidade Ocasional
Perigo Muito perigoso
Impacto Alto
Indicadores Produção comprometida
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
Probabilidade Ocasional
Perigo Muito perigoso
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
Plano de Projeto 2010
21 FOCUS!
Super estimar soluções
Probabilidade Ocasional
Perigo Muito perigoso
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
Probabilidade Ocasional
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
Probabilidade Muito frequente
Perigo Muito perigoso
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
Plano de Projeto 2010
22 FOCUS!
Erro na coleta de requisitos
Probabilidade Ocasional
Perigo Muito perigoso
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
Probabilidade Ocasional
Perigo Muito perigoso
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
Probabilidade Ocasional
Perigo Muito perigoso
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
Plano de Projeto 2010
23 FOCUS!
o Risco de implementação
Baixa qualidade de um componente do sistema
Probabilidade Raro
Perigo Muito perigoso
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
Perigo Muito perigoso
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
Probabilidade Ocasional
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
Plano de Projeto 2010
24 FOCUS!
o Risco de grupo
Dificuldade de divisão de atividades
Probabilidade Ocasional
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
Probabilidade Muito frequente
Perigo Pouco perigoso
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
Plano de Projeto 2010
25 FOCUS!
Ausência imprevisível de um ou mais membros do grupo por um longo período de tempo
Probabilidade Ocasional
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
Probabilidade Ocasional
Perigo Muito perigoso
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
Probabilidade Muito frequente
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
Plano de Projeto 2010
26 FOCUS!
o Risco de complexidade e tempo
Complexidade da interface gráfica
Probabilidade Muito freqüente
Perigo Pouco perigoso
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
Probabilidade Ocasional
Perigo Muito perigoso
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
Probabilidade Ocasional
Perigo Muito perigoso
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
Plano de Projeto 2010
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.
Plano de Projeto 2010
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
Plano de Projeto 2010
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