Plano de projeto cafis

490 visualizações

Publicada em

0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
490
No SlideShare
0
A partir de incorporações
0
Número de incorporações
33
Ações
Compartilhamentos
0
Downloads
20
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Plano de projeto cafis

  1. 1. Universidade Federal do Amazonas – UFAMInstituto de Computação – ICOMPCurso de Sistemas de Informação – SIIEC921 - Gerência de Projetos – Prof. Rogério Nascimento Plano de Projeto CAFIS Lacertae SoftwareEquipe de Desenvolvimento:  Édipo Maciel  Jonathas Silva  Leonardo Alexandre Manaus - 2011
  2. 2. 1.0 INTRODUÇÃO Este documento foi elaborado para a disciplina de Gerência de Projetos, paraalunos do curso de Sistemas de Informação da Universidade Federal do Amazonas. Omesmo relata um projeto que foi desenvolvido junto a Prefeitura do CampusUniversitário e a Empresa fictícia Lacertae Software. Esta seção descreve uma visãogeral sobre o projeto de software, mostrando suas principais funcionalidades e algumasrestrições da implantação do produto na UFAM. Depois mostra como foi feitoplanejamento das estimativas, de tempo do projeto e esforço dos participantes. Emseguida são listados os riscos do projeto com suas respectivas soluções. Logo depois oprojeto é planejado temporalmente, tendo detalhado o modelo de ciclo de vida usado e oDiagrama de Gannt. Para finalizar, a seção 5 mostra melhor a equipe, e a função de cadaum no projeto.
  3. 3. 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 esopolistado 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.
  4. 4. 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.
  5. 5. 2.0 ESTIMATIVAS DO PROJETONesse 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.
  6. 6. 2.3 Resultados Com base na métrica de Lorenz & Kidd descrita acima, obtivemos osseguintes 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%
  7. 7. 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 trabalhoTendo isso dividido em três membros da equipe, temos o seguinte número:546/3 = 186 para cada membro da equipe;
  8. 8. 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.
  9. 9. 3.0 ANÁLISE E GESTÃO DE RISCONessa 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;
  10. 10. Risco: R1 Prob.: 95% Impacto: CatastróficoDescriçã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. notempo de uma quinzena, será levado uma versão estável do software ao clientepara uma avaliação. com isso as chances de o sistema chegar ao prazo corretoaumentam.Pessoa Responsável: Jonathas, Édipo e LeonardoRisco: R4 Prob.: 75% Impacto: CríticoDescriçã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 dosintegrantes do CPD para amenizar o impacto gerado pelo aprendizado por esforçode uma nova tecnologia.Pessoa Responsável: Jonathas, Édipo e Leonardo.Risco: R5 Prob.: 99% Impacto: CríticoDescrição: Equipe com um número de integrantes muito inferiores ao normalpara um projeto desse porte.Estratégias de Redução: Contratar novos colaboradores.Elaborar umcronograma que envolva os feriados existentes até o final do projeto. Dividir asatividades 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 decolaboradores do CPD.Pessoa Responsável: Jonathas, Édipo e Leonardo.Risco: R6 Prob.: 75% Impacto: CríticoDescrição: Possibilidade do sistema se integrar ao SIE (Sistema de Informaçãopara o Ensino), que é o sistema mantido pelo CPD
  11. 11. Estratégias de Redução: Ler a documentação do sistema SIE, no intuito dediminuir o impacto da integração;Plano de Contingência: Marcar reuniões mensais com os analistas do CPD, nointuito de entender o módulo que irá receber a integração com o SIE.Pessoa Responsável: Jonathas.
  12. 12. 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.
  13. 13. 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.

×