plano de projeto cafis
TRANSCRIPT
Universidade Federal do Amazonas – UFAM
Instituto de Computação – ICOMP
Curso de Sistemas de Informação – SI
IEC921 - Gerência de Projetos – Prof. Rogério Nascimento
Plano de Projeto CAFIS Lacertae Software
Equipe de Desenvolvimento:
Édipo Maciel
Jonathas Silva
Leonardo Alexandre
Manaus - 2011
1.0 INTRODUÇÃO
Este documento foi elaborado para a disciplina de Gerência de Projetos, para
alunos do curso de Sistemas de Informação da Universidade Federal do Amazonas. O
mesmo relata um projeto que foi desenvolvido junto a Prefeitura do Campus
Universitário e a Empresa fictícia Lacertae Software. Esta seção descreve uma visão
geral sobre o projeto de software, mostrando suas principais funcionalidades e algumas
restrições da implantação do produto na UFAM. Depois mostra como foi feito
planejamento das estimativas, de tempo do projeto e esforço dos participantes. Em
seguida são listados os riscos do projeto com suas respectivas soluções. Logo depois o
projeto é planejado temporalmente, tendo detalhado o modelo de ciclo de vida usado e o
Diagrama de Gannt. Para finalizar, a seção 5 mostra melhor a equipe, e a função de cada
um no projeto.
1.1 Escopo do Projeto
O sistema CAFIS será reformulado para suprir a necessidade dos
profissionais de engenharia e responsáveis pelas edificações da UFAM, a ter um
controle total sobre as diversas áreas construídas e pertencentes à Instituição. Esse
sistema foi designado aos alunos
A cada nova construção de uma edificação sendo ela prédio ou ambiente,
passará pelo departamento de engenharia que deve cadastrar a nova edificação no
sistema, com seus atributos e dimensões.
As edificações se estruturam em: campus, prédios, unidades, ambientes e
terrenos. Campus seria mais abrangente, unidades pertenceriam a um campus,
prédios às unidades e os ambientes aos prédios, nessa hierarquia.
O sistema abrangerá as áreas construídas da Universidade, controlando os
prédios, blocos em geral, e oferecendo ao interessado um controle sobre os
atributos dos prédios e sendo aberta a consulta para todo aquele que procurar.
1.2 Funções principais do Produto de Software
Abaixo estão listadas as funcionalidades do sistema CAFIS. Segundo o esopo
listado acima, o sistema deve:
Permitir a consulta das informações de prédios, plantas e ambientes
disponibilizadas pelo sistema por qualquer usuário, pela Web;
Ser capaz de prover papéis de usuários para quando os mesmos fizerem
o login, apenas os módulos autorizados possam ser acessados por eles;
Gerar relatórios diários (caso o usuário autorizado requisitar este caso de
uso), mensais, anuais das edificações construídas e reformadas;
Cadastrar as edificações recém-construídas e/ou edificações que ainda
não estejam cadastradas no sistema;
Ter a disponibilidade de o cliente acessar plantas não detalhadas dos
prédios e ambientes;
1.3 Requisitos comportamentais ou de desempenho
Para os requisitos de desempenho, tem se que o sistema, pelo fato de ser
um sistema Web, deve possuir características fáceis de serem compreendidos,
como ícones e sinais confiáveis e funcionais. Deve ser o mais simples e usual
possível para um cliente que não conheça o escopo do sistema. Deve ser eficiente
computacionalmente e não oferecer demais riscos de desempenho ao servidor do
CPD – UFAM, onde ficará alocado.
1.4 Gestão e Restrições Técnicas
O sistema será desenvolvido em um framework (Grails) que foi escolhido pelo
cliente e pela empresa, que não é uma tecnologia conhecida por todos os
integrantes da equipe, o que demandará mais custos de tempo e recursos;
O sistema será desenvolvido usando o ciclo de vida tradicional, onde o cliente irá
receber o produto acabado no final do cronograma, sendo esse já todo planejado
antes do início do projeto;
O sistema será desenvolvido em parceria de uma empresa privada fictícia
(Lacertae Software) e o IComp, sendo a mão de obra completa cedida pelo
Instituto de Computação da Universidade Federal do Amazonas.
2.0 ESTIMATIVAS DO PROJETO
Nesse ponto está descrita a estimativa feita para o projeto CAFIS.
2.1 Dados históricos utilizados para as estimações
Não existem dados históricos para esse projeto.
2.2 Técnicas de estimação e resultados
Para fazer a estimativa do projeto, foi usada a técnica proposta por Lorenz &
Kidd, que foi proposta pela empresa fictícia Lacertae Software.
2.2.1 Técnica de estimação
A técnica de Lorenz & Kidd é uma métrica orientada a classes
onde se destaca por ser simples e fácil de utilizar. Podemos então
mencionar a definição de métrica para que não restem duvidas do que é
uma métrica: “Medida quantitativa do grau de posse de um atributo dado
por parte de um sistema, componente ou processo”. Para usar a métrica de
Lorenz & Kidd temos que: Definir o número de classes chave. Encontrar o
número de classes de suporte, para isso temos que classificar o tipo de
Interface do Produto e desenvolver um Multiplicador para as Classes de
Suporte.
Essas classes de suporte basicamente seriam as interfaces e as
classes de controle. Seguem abaixo as classes listadas e o fator de
multiplicação que foi atribuído para elas:
Interface não gráfica – 2;
GUI – 2,5;
GUI – 3;
Logo em seguida, multiplicamos a quantidade de classes-chave pelo
multiplicador que foi sugerido para obter uma estimativa do número de
classes de suporte.
Em seguida, foi calculado o número de classes total, somando as classes
de suporte e as classes de domínio do sistema.
2.3 Resultados
Com base na métrica de Lorenz & Kidd descrita acima, obtivemos os
seguintes resultados:
1. Nº classes de domínio = 15
2. Escolhemos a interface com base na aplicação gráfica que irá ter o
produto final. Multiplicador da GUI = 3;
3. 15 X 3 = 45. Logo teremos 45 Classes de Suporte;
4. O número total de classes é igual a: Nº Classes de Domínio + Nº
Classes de Controle = 15 + 45 = 60;
5. Em seguida, escolhe-se o número médio de unidades de trabalho (dias-
pessoa) por classe onde a métrica Lorenz & Kidd sugere entre 15 e 20
dias-pessoa por classe. Devido a tudo que foi imposto a equipe pela
Universidade, optamos por escolher 20 dias-pessoa devido ao fato não de
estarmos familiarizados com as nossas ferramentas de trabalho, como por
exemplo o “NetBeans”, e o “Oracle”, E também porque a equipe, estando
em período letivo ativo, tinha outras atividades em paralelo.
6. Sendo assim o cálculo da quantidade do esforço estimada é: 60 X 20 =
1200 dias-pessoa de trabalho. Poderemos calcular agora os dias de
trabalho por pessoa, e como temos três elementos na equipe, para dividir
os 1200 dias de trabalho ficarão com aproximadamente 400 dias de
trabalho para cada elemento de equipe.
7. Agora se pretendemos ter os dias e meses corridos (incluindo os fins de
semana), temos que multiplicar os dias de trabalho com os 30 dias
corridos e em seguida dividir pelos os 22 dias úteis. 400 X 30 = 12000 / 22
= 545,45 ~ 546 dias corridos 546 / 30 = 18,2 ~ 18 meses corridos
Sabendo-se os dias de trabalho totais (546 dias), estes dias são agora
distribuídos de acordo com as seguintes percentagens de distribuição dos
componentes essenciais num projeto:
Requisitos – Análise – Projeto: 40%
Codificação: 20%
Testes: 40%
Os valores calculados são:
Requisitos – Análise – Projeto: 546 * 40% = 218 dias de
trabalho;
Codificação: 546 * 20% = 109 dias de trabalho;
Testes: 546 * 40% = 218 dias de trabalho;
Total: 546 dias de trabalho
Tendo isso dividido em três membros da equipe, temos o seguinte número:
546/3 = 186 para cada membro da equipe;
2.3 Recursos do projeto
Recursos humanos: Para cumprir o que foi estimado no item acima, pelo
prazo que nos foi estipulado, nossa equipe deveria ter no mínimo seis
integrantes e no máximo dez. Sendo de três competências diferentes:
analistas desenvolvedores e testadores. Porém, na realidade temos,
disponibilizados pelo Curso de Sistemas de Informação do IComp. , uma
equipe com três alunos: dois desenvolvedores, e uma analista. A parte de
testes do projeto foi desenvolvida pelos três integrantes de um modo
integrado.
Software: Na parte de software, para o projeto foi designado a IDE
Netbeans, o banco de dados PostgreSQL, o MS Project para o
acompanhamento e controle do projeto, o Microsoft Office 2007, para a
elaboração de alguns artefatos durante o desenvolvimento.
Hardware: Para o projeto foram disponibilizados apenas três notebooks, um
HP, um SONY e um ACER, além dos laboratórios da do IComp.
3.0 ANÁLISE E GESTÃO DE RISCO
Nessa seção estão listados os riscos que foram avaliados para esse projeto.
3.1 Riscos do projeto
Nesta seção estão listados os riscos do projeto, construídos com base no método
de identificação dos riscos proposto para a empresa fictícia Lacertae Software.
Prazo de entrega do produto é relativamente baixo;
Usuários do sistema não podem ser mensuráveis;
Alto custo na entrega tardia do produto;
Equipe com tamanho reduzido;
Integração com software desconhecido;
Tecnologia desconhecida pela equipe;
3.2 Tabela de riscos
A tabela a seguir mostra os riscos que foram avaliados, com a sua probabilidade
de ocorrência dita em porcentagem e o impacto que eles irão causar no projeto
caso eles ocorram.
N. Riscos Listados Prob. Ocorrência Impacto
1 Prazo de entrega baixo 95,00% Catastrófico
2 Usuários do sistema não mensuráveis 75,00% Marginal
3 Alto custo na entrega do produto 50,00% Marginal
4 Tecnologia desconhecida pela equipe. 75,00% Crítico
5 Equipe com tamanho reduzido 99,00% Crítico
6 Integração com software desconhecido 75,00% Crítico
3.3 Redução e Gestão do Risco
Para os riscos levantados acima, temos o seguinte plano para reduzir em
no mínimo 50% em cada um deles. Vale resaltar que o Ponto de Corte foi
idealizado para riscos com mais de 75% de probabilidade de ocorrências e com
impacto crítico e catastrófico;
Risco: R1 Prob.: 95% Impacto: Catastrófico
Descrição: Prazo de entrega muito baixo.
Estratégias de Redução: Trabalhar aos sábados, domingos e feriados.
Plano de Contingência: Na etapa de desenvolvimento, será modificada. no
tempo de uma quinzena, será levado uma versão estável do software ao cliente
para uma avaliação. com isso as chances de o sistema chegar ao prazo correto
aumentam.
Pessoa Responsável: Jonathas, Édipo e Leonardo
Risco: R4 Prob.: 75% Impacto: Crítico
Descrição: Tecnologia de desenvolvimento é desconhecida pela equipe.
Estratégias de Redução: Esforço individual no aprendizado da equipe.
Plano de Contingência: Realização de um minicurso de dois dias por parte dos
integrantes do CPD para amenizar o impacto gerado pelo aprendizado por esforço
de uma nova tecnologia.
Pessoa Responsável: Jonathas, Édipo e Leonardo.
Risco: R5 Prob.: 99% Impacto: Crítico
Descrição: Equipe com um número de integrantes muito inferiores ao normal
para um projeto desse porte.
Estratégias de Redução: Contratar novos colaboradores.Elaborar um
cronograma que envolva os feriados existentes até o final do projeto. Dividir as
atividades de acordo com o grau de experiência de cada membro da equipe.
Plano de Contingência: Dedicação dos colaboradores em tempo semi-integral
(12 horas) a fim de cumprir o que foi acordado no cronograma. Auxílio de
colaboradores do CPD.
Pessoa Responsável: Jonathas, Édipo e Leonardo.
Risco: R6 Prob.: 75% Impacto: Crítico
Descrição: Possibilidade do sistema se integrar ao SIE (Sistema de Informação
para o Ensino), que é o sistema mantido pelo CPD
Estratégias de Redução: Ler a documentação do sistema SIE, no intuito de
diminuir o impacto da integração;
Plano de Contingência: Marcar reuniões mensais com os analistas do CPD, no
intuito de entender o módulo que irá receber a integração com o SIE.
Pessoa Responsável: Jonathas.
4.0 PLANEJAMENTO TEMPORAL
4.1 Conjunto de Tarefas do Projeto
O modelo de processo de desenvolvimento foi o modelo Clássico, ou em
cascata, tendo todas as funcionalidades implementadas, para só então apresentar o
produto ao cliente e obter uma opinião necessária para as melhorias e correções.
Este modelo foi o que se mostrou mais adequado às circunstâncias, devido a este
projeto ser uma continuação de um anterior, no qual a maioria das
funcionalidades já haviam sido implementadas, parcial ou completamente. De
qualquer forma, é importante ser mencionado que o ciclo de vida cascata não é o
ideal para um desenvolvimento com prazo tão curto, porém a situação exposta
pelo projeto obrigou a equipe a usar o mesmo, com uma pequena modificação: as
atividades de implementação e teste foram feitas em paralelo.
4.2 Diagrama de Gantt
O diagrama de Gannt está no ultimo post desse Edu blog.
5.0 ORGANIZAÇÃO DO PESSOAL
5.1 Estrutura da Equipe de Desenvolvimento
Jonathas Silva dos Santos – Gerente e Analista;
Édipo Maciel – Desenvolvedor e Testador;
Leonardo Alexandre - Desenvolvedor e Testador;
O Gerente de Projeto tem a responsabilidade de coordenar todo o
desenvolvimento do projeto, combinando reuniões, distribuindo tarefas.
Ele é responsável pelo planejamento temporal do projeto, elaborando o
diagrama de Gantt e auxiliando no controle das atividades.
O Analista de Sistema deve fazer o levantamento de requisitos e a análise
do software, assim como elaborar diagramas do sistema e estabelecer
quais classes e interfaces devem ser implementadas.
O Programador recebe o trabalho do analista e constrói o código do
sistema.
O Testador verifica exaustivamente se o sistema funciona da maneira
esperada e planejada, de forma a detectar erros na implementação.
5.2 Mecanismos de comunicação
Uma ferramenta eletrônica largamente usada para comunicação durante o
projeto foi o Windows Live Messenger, mas ela foi usada para o momento onde a
equipe não estava reunida. Como toda a equipe possuiu atividades no IComp
durante o período vespertino/noturno, as reuniões presenciais se tornaram o meio
de comunicação mais usado e o mais eficaz no momento de desenvolvimento e de
resolução de problemas.
5.3 Uso do Edu-blog como ferramenta de apoio
O Edu-blog mostrou-se uma ferramenta de fácil utilização e eficiente no
propósito de disponibilizar os documentos produzidos durante o projeto. Ela
também foi importante porque a equipe de desenvolvimento foi responsável por
explorar o assunto de “Sistemas de Controle de Versão”, onde houve também
uma interação muito interessante com os demais alunos da disciplina.