SACIn – Sistema de Automatização do Centro de Informática

Versão 1.1

Informações do Documento

Título do Documento	Plano de Projeto
Autores	Bruno José Torres Fernandes

Emílio Georges Saad Neto

Felipe Guedes da Fonte Andrade

Fernando Henrique Calheiros Lopes

Henrique Borges Alencar Siqueira

Renato Viana Ferreira
Nome do Arquivo	SACInPlanoProjeto.doc
Histórico de Revisões
Data	Versão	Descrição	Autor (es)
22/10/2004	1.0	Versão Base do documento	Renato
26/10/2004	1.1	Atualização e complementação do documento	Equipe Sítio do Desenvolvedor Amarelo

Índice

1. Objetivos

2. Escopo

3. Referências

4. Plano de Fases

5. Cronograma	5

6. Plano de Recursos	6

7. Riscos	6

8. Custos	9

Plano de Projeto

Objetivos

Este plano de projeto tem por objetivo apresentar uma proposta de solução ao problema da automação da graduação do Centro de Informática da Universidade Federal de Pernambuco. Também visa detalhar as atividades a serem realizadas para especificação e implementação da solução, assim como custos e riscos associados a este projeto. O software solução buscará otimizar os processos da graduação, melhorando o tempo de execução e reduzindo a complexidade dos mesmos para os usuários do sistema, garantindo assim, uma melhor utilização de recursos humanos e físicos.

As informações e estimativas contidas nesse documento visam dar parâmetros para acompanhamento do andamento do projeto, reduzir riscos e auxiliar na conclusão do projeto dentro de prazo e custos.

Escopo

Este documento visa tornar a produção da solução em software desejada uma atividade gerenciável e programada. Indicaremos as fases do projeto de desenvolvimento e traçaremos metas e prazos para o cumprimento das tarefas necessárias. Descreveremos, também, um cronograma estimado, assim como estimativas de custos atrelados ao projeto, análise de riscos e possíveis tratamentos para estes, caso ocorram.

O plano será atualizado durante todo o projeto e novas estimativas de custos, riscos e prazos serão feitas em virtude do andamento do projeto.

Referências

Para desenvolver este plano obtivemos informações através dos slides e template disponibilizados pelo professor Alexandre Cabral Mota no site www.cin.ufpe.br/~if682, assim como alunos da graduação.

O site do projeto estará brevemente em www.cin.ufpe.br/~rvf/sacin

A planilha do cronograma se encontra em www.cin.ufpe.br/~rvf/sacin/cronograma.xls [1].

Plano de Fases

O projeto será desenvolvido seguindo o modelo cascata, que é composto de uma única iteração, porém esta é dividida em várias etapas, modularizando o processo. Cada etapa possui diferentes focos de atividades nos diferentes momentos do ciclo de vida do projeto. Cada etapa tem importância fundamental para o andamento do projeto e cada uma delas tem objetivos próprios e bem definidos.

Etapa de Planejamento:

Na etapa de planejamento, que finaliza com este documento, porém atividades relativas a esta fase continuarão a ser realizadas durante todo o projeto, buscamos estabelecer o escopo e as limitações do projeto, assim como custos e riscos. Confrontamos idéias de solução com o cenário real, estabelecemos estratégias de suavização e contenção dos riscos e desenvolvemos um cronograma a ser seguido durante todo o projeto. Este cronograma, e também riscos e custos, serão revisados e atualizados nas próximas etapas do projeto.

Etapa de Elicitação de Requisitos:

É a coleta e especificação dos requisitos para levantar e documentar quais as funcionalidades desejadas pelo cliente, evitando dúvidas e ambigüidades. No final desta etapa elaboraremos um documento com todos os requisitos e também com casos de uso em UML.

Etapa de Análise:

Aqui analisaremos o domínio do problema (classes, pacotes, módulos...) e devido ao detalhamento da análise, este plano de projeto pode sofrer alterações para se adaptar melhor ao problema. Também será definida a base da arquitetura e modelo do sistema em UML, assim como sua documentação e validação com o documento de requisitos. Um plano para a etapa de projeto será feito com alocação de pessoal para tarefas, escolha das ferramentas e linguagens. Caso surjam novos requisitos durante a análise, atualizaremos o documento de requisitos para atender a nova realidade. Nesta etapa é fundamental a eliminação de riscos elevados.

Etapa de Projeto e Codificação:

Minimizar custos de implementação, tendo a análise e os requisitos concluídos e bem definidos. Nesta etapa as atividades chaves são, a documentação do sistema sob um modelo concreto e a codificação para gerar o sistema desejado de forma rápida e prática. Desenvolvimento do sistema da forma mais modularizada possível.

Etapa de Testes:

Realização de testes dos módulos e do sistema como um todo e validação do sistema comparando a documentação gerada nesta fase com o documento de análise e também as saídas geradas pelo sistema com as saídas esperadas e desejadas pelo cliente.

Etapa do Projeto	Outubro	Novembro	Dezembro	Janeiro	Fevereiro	Março
Planejameto
Elicitação de Requisitos
Análise
Projeto e Codificação
Testes
Apresentação

Cronograma

Considerando os prazos estipulados pela disciplina de Engenharia de Software e Sistemas, assim como as atividades relacionadas às atividades acadêmicas e extra-acadêmicas dos membros da equipe, chegamos ao seguinte cronograma para o projeto (Deliverables em negrito e Milestones em itálico):

Data	Hora	Atividade
22/10/2004	12:00	Reunião de delegação de Tarefas para Plano de Projeto
25/10/2004	10:00	Reunião de Conclusão do Plano de Projeto e definição do nome da empresa e do produto
27/10/2004	8:00	Entrega do Plano de Projeto – Plano de Projeto concluído.
27/10/2004	12:00	Reunião de alocação e definição de tarefas para documento de requisitos
03/11/2004	12:00	Reunião de monitoramento e reorganização das tarefas para documento de requisitos
08/11/2004	12:00	Reunião de conclusão do documento de requisitos
10/11/2004	8:00	Entrega do documento de Requisitos – Elicitação de Requisitos concluída .
10/11/2004	12:00	Reunião revisão de prazos, metas e riscos – Plano de Projeto atualizado.
17/11/2004	12:00	Reunião de alocação e definição das tarefas para Análise
03/12/2004	12:00	Reunião de para monitoramento da Análise
21/12/2004	12:00	Reunião de alocação de tarefas para Projeto – Plano para desenvolvimento do projeto concluído.
22/01/2005	12:00	Reunião de conclusão e validação da Análise de Projeto – Estudo de casos de uso completo.
24/01/2005	8:00	Entrega do documento de Análise – Análise concluída.
25/01/2005	12:00	Reunião de monitoramento e alocação de tarefas do Projeto e do documento de projeto
10/02/2005	12:00	Reunião de monitoramento do projeto – Plano de Projeto atualizado.
18/02/2005	12:00	Reunião de conclusão do documento de projeto e alocação de tarefas para testes e documento de testes
21/02/2005	8:00	Entrega do documento de Projeto
25/02/2005	12:00	Reunião de conclusão do documento de testes
02/03/2005	8:00	Entrega do documento de Testes
02/03/2005	12:00	Reunião de alocação de tarefas para apresentação do sistema – Sistema finalizado.
04/03/2005	12:00	Reunião de definição da apresentação do sistema
07/03/2005	8:00	Apresentação do Sistema
Ver [1] para maiores informações.

Plano de Recursos

A equipe de desenvolvimento será formada por seis componentes. A estruturação da equipe será revista a cada fase do projeto, onde as funções de cada membro serão avaliadas e atualizadas. Os membros são:

Bruno José Torres Fernandes

Emílio Georges Saad Neto

Felipe Guedes da Fonte Andrade

Fernando Henrique Calheiros Lopes

Henrique Borges Alencar Siqueira

Renato Viana Ferreira – Gerente de Projeto.

Não haverá, salvo fatalidades, saída nem entrada de membros na equipe e todos participarão de todas as fases do processo desenvolvimento da solução.

Riscos

Baixo rendimento de um membro, fazendo com que deixe de fazer o que lhe foi destinado

Magnitude:	Alta

Probabilidade de ocorrer:	70%

Identificação:	Durante a realização de determinada tarefa algum integrante não consegue realizá-la, isso acaba comprometendo a harmonia do grupo e ainda sobrecarregando os demais membros, podendo chegar a atrasar a entrega do projeto.

Planos de Mitigação:	O gerente durante o processo de seleção da equipe deve se informar a respeito das habilidades e defeitos de cada integrante da equipe e possíveis problemas familiares. A partir dessas informações o gerente deve fazer a sua seleção, e colocar possíveis substitutos na lista também. A avaliação dos membros da equipe deve continuar sendo feita durante todo o projeto para que o projeto não caia de rendimento. O gerente deve também saber dosar as tarefas que incubir a cada membro e analisar se existem integrantes suficientes para cada tarefa.

Prazo de entrega extrapolado

Magnitude:	Catastrófica

Probabilidade de ocorrer:	65%

Identificação:	O atraso no cumprimento de tarefas começará a comprometer a entrega do projeto. Podendo acarretar aumento dos custos do software e criando desgaste com o cliente.

Planos de Mitigação:	Planejar a conclusão do projeto com uma certa folga do prazo de entrega e acompanhar o progresso de cada fase do projeto durante a execução do mesmo

Planos de Contingência:	Verificar quanto tempo foi perdido e tentar aumentar o rendimento ou as horas de trabalho, para que, apesar de ultrapassado o prazo de entrega, evitar-se um atraso ainda maior. Além disso, tentar conversar com o cliente para prorrogar o tempo de entrega.

Planos de Contingência:	Substituição interna de tarefas, reavaliado as tarefas que cada um iria executar e designar tarefas mais simples para este membro e realizar algumas tarefas em grupo para que este membro seja re-introduzido a realidade da equipe

Ocorrência de um bug difícil de ser identificado

Magnitude:	Alta

Probabilidade de ocorrer: 60%

Identificação:	Durante os testes é encontrado alguma falha na realização de determinada função, a correção desse erro pode ser que dure mais que o esperado, ocasionando o desvio do rumo do projeto e um atraso na entrega do projeto.

Planos de Mitigação:	Na fase de ‘projeto’ deve ser tomado um cuidado especial para evitar que os códigos a serem implementados gerem resultados com erros, testando-os incrementalmente. A mesma atenção deve ser dada na hora da implementação, evitando erros, em geral comuns, na programação. Além disso, deve-se seguir um padrão definido de codificação, possibilitando uma mais fácil compreensão do código.

Planos de Contingência:	Uma vez que se torne difícil descobrir o erro e o tempo gasto tenha se tornado excessivo, deve-se seguir outros caminhos, à procura de uma nova abordagem para resolver o mesmo problema. No entanto, esta nova solução deve manter a consistência do projeto e seguir o planejado em fases anteriores.

Perda de dados e documentos referentes ao projeto

Magnitude:	Significante

Probabilidade de ocorrer:	50%

Identificação:	A perda de algum documento ou dado referente ao projeto poderá acarretar num possível atraso do mesmo.

Planos de Mitigação:	A medida que o projeto for avançando os integrantes devem fazer cópias do projeto e dos dados, repassando-as para o restante do grupo.

Planos de Contingência:	Havendo a perda dos dados, códigos ou documentação, será necessário observar nas versões anteriores quais objetivos já foram feitos e complementar com os que faltam para a realização da tarefa.

Mudança de interesse do cliente, ocasionando reformulação do projeto

Magnitude:	Significante

Probabilidade de ocorrer:	40%

Identificação:	A mudança do interesse do cliente irá acarretar numa reformulação do projeto.

Planos de Mitigação:	Manter os cliente ciente das versões parciais.

Planos de Contingência:	Verificar a necessidade do cliente e implementá-la.

O cliente não gostar ou não entender as funções implementadas no projeto

Magnitude:	Significante

Probabilidade de ocorrer:	40%

Identificação:	A comunicação do cliente dizendo que não gostou ou não entendeu alguma característica das funções poderá acarretar numa reformulação do sistema.

Planos de Mitigação:	Manter os cliente ciente das versões parciais.

Planos de Contingência:	Tentar mostrar ao cliente a usabilidade de softwares com caracteristicas similares, documentando suas observações a procura do que ele deseja no sistema. Se necessário, refazer o sistema para adequar-se ao pedido do cliente.

Falta de recursos para continuação do projeto

Magnitude:	Alta

Probabilidade de ocorrer:	40%

Identificação:	Indisponibilidade de recursos financeiros acarretando numa possível parada do andamento do projeto e num possível desgaste com o cliente.

Planos de Mitigação:	Tentar obter uma boa estimativa na quantidade de recursos necessários a partir de experiência prévia, estar sempre listando os recursos necessários para a continuação do projeto e trabalhar com uma margem de erro.

Planos de Contingência:	Tentar obter novas fontes para a continuação do projeto, se possível solicitando recursos do cliente, além de realizar um contenção de despesas afim de aproveitar melhor os recursos disponíveis.

Ocorrência de ambigüidade, ocasionando a implementação de funções indesejadas

Magnitude:	Significante

Probabilidade de ocorrer:	20%

Identificação:	A comunicação do cliente alertando que tais funções não foram implementadas da forma desejada acarretando numa reimplementação.

Planos de Mitigação:	Entrevistar o cliente sempre que existir qualquer possibilidade de ambigüidade, garantindo o correto entendimento do problema. Além disso, expor o que foi entendido, para manter a clareza e a coerência.

Planos de Contingência:	Retirar o que for desnecessário e implementar o que o cliente deseja, solucionando as ambigüidades descobertas.

Saída de algum membro importante da equipe

Magnitude:	Alta

Probabilidade de ocorrer:	10%

Identificação:	Decisão de um membro de se retirar da equipe, ocasionando um provável atraso no andamento do projeto.

Planos de Mitigação:	Deverá haver reuniões regularmente para discutir como está o andamento do projeto, onde cada integrante irá expor o que vem fazendo, garantindo que todo o grupo esteja informado de cada parte do trabalho. Além disso, nessas reuniões, o gerente deve prestar atenção em cada membro para saber se ele está satisfeito com o que vem desempenhando. Se necessário, o gerente deverá redistribuir as tarefas.

Planos de Contingência:	Substituir o membro que saiu por um novo se o tempo gasto para adicionar o novo membro ao projeto ainda possibilitar o rendimento deste novo integrante. Caso contrário, redistribuir as tarefas entre os membros participantes.

Falha na aquisição dos documentos pertencentes ao cliente constituintes do projeto

Magnitude:	Baixa

Probabilidade de ocorrer:	10%

Identificação:	Falta de algum documento ou choque entre documentos, podendo acarretar numa curta pausa no andamento do projeto.

Planos de Mitigação:	Certificar-se de não pegar documentos desatualizados para que não haja choque dos mesmos com os mais atuais e verificar todas as fonte disponíveis de documentos. A colocação de datas em cada documento poderá evitar a ocorrência do problema.

Planos de Contingência:	Em caso da falha ser um choque, descartar o documento mais desatualizado. No caso da falta de um documento, contatar o cliente para disponibilizar o mesmo ou ignorar a falta caso o cliente afirme que o documento não tem muita significância.

.

Custos

Os custos foram estimados de duas maneiras. Primeiramente, vendo a equipe desenvolvedora como uma empresa no mercado e finalmente, olhando para a equipe como alunos do CIn cursando a disciplina de Engenharia de Software e Sistemas:

8.1. Versão empresa

Investimentos Iniciais

Na tabela abaixo encontram-se os investimentos iniciais com infra-estrutura de hardware necessária para o desenvolvimento do sistema. O item infra-estrutura física corresponde aos gastos com a compra de mesas, da instalação elétrica, telefônica, etc.

ITEM	QTD	Valor Unitário	Valor Total
Workstations de desenvolvimento	6	R$ 2.000,00	R$ 12.000,00
Impressora multifuncional	1	R$ 999,00	R$ 999,00
Infra-estrutura física	-	R$ 1.000,00	R$ 1.000,00
TOTAL	R$ 13.999,00

Despesas Mensais

CARGO	QTD	Valor Unitário	Valor Total
Programador	5	R$ 1.200,00	R$ 6.000,00
Gerente de Projeto	1	R$ 2.000,00	R$ 2.000,00
Faxineiro	1	R$ 240,00	R$ 240,00
TOTAL	R$ 8.240,00
Tabela com gastos com recursos humanos

Material de Escritório	QTD	Valor Unitário	Valor Total
Resma A4 500 folhas	1	R$ 5,40	R$ 5,40
Tinta para impressora	1	R$ 160,00	R$ 160,00
Caneta/lápis/borracha/post-it	Vários	-	R$ 10,00
Biscoitos	5	R$ 5,00	R$ 25,00
Material de Limpeza	-	-	R$ 50,00
CDs virgens para backup	20	R$ 2,00	R$ 40,00
TOTAL	R$ 290,40
Tabela com gastos com material de escritório

Software	QTD	Valor Unitário	Valor Total
Sistema Operacional: Linux	6	R$ 0,00	R$ 0,00
IDE: Eclipse	6	R$ 0,00	R$ 0,00
CASE Tool: Poseidon UML	6	R$ 0,00	R$ 0,00
TOTAL	R$ 0,00
Tabela com gastos de software

Estrutura Física	Valor Total
Eletricidade	R$ 300,00
Aluguel	R$ 500,00
Condomínio	R$ 200,00
IPTU	R$ 60,00
Água Mineral	R$ 15,00
Telefone fixo	R$ 50,00
Velox 512kbps empresarial	R$ 199,00
Modem ADSL	R$ 21,19
TOTAL	R$ 1345,19
Tabela com gastos com a estrutura física da empresa

Somando o total parcial de cada tabela teremos um gasto mensal de aproximadamente R$ 10.000,00.

8.2. Versão aluno do CIn

Como os alunos do CIn dispõem de toda a infra-estrutura de hardware e de software necessária para o desenvolvimento do projeto nos próprios laboratórios do Centro de Informática, e como também não são pagos para o desenvolvimento dos projetos da cadeira de Engenharia de Software não há gastos com pessoal nem com infra-estrutura de software, hardware e física. Os únicos gastos seriam com cota de impressão, para impressão dos documentos necessários para o desenvolvimento do projeto e com passagens de ônibus para as 16 reuniões planejadas. O gasto com cota será de R$ 50,00 mensais e com transporte para as reuniões será de R$ 9,00 para cada reunião, totalizando R$ 144,00 para todas as reuniões. Como o desenvolvimento do projeto levará aproximadamente 3 meses haverá um gasto de R$ 150,00 com cota de impressão, totalizando o custo do projeto em R$ 294,00.

Sítio do Desenvolvedor Amarelo

SACIn – Sistema de Automatização do Centro de Informática	Versão: 1.1
Plano de Projeto	Data: 26/10/2004

(Sítio do Desenvolvedor Amarelo, 2004	Página 3 of 10

Project Plan

Project Name

Company Name

2004-10-26

Renato