Plano de projeto de software

9.337 visualizações

Publicada em

Projeto Modulo Extensão

Publicada em: Tecnologia
2 comentários
2 gostaram
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
9.337
No SlideShare
0
A partir de incorporações
0
Número de incorporações
12
Ações
Compartilhamentos
0
Downloads
340
Comentários
2
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Plano de projeto de software

  1. 1. 1
  2. 2. 2 SUMÁRIO 1.0 INTRODUÇÃO.............................................................................................................. 3 1.1 DESCRIÇÃO DO PROJETO.................................................................................... 3 1.2 PRINCIPAISFUNÇÕESDO SISTEMA..................................................................... 3 1.3 RESTRIÇÕES....................................................................................................... 3 2.0 ESTIMATIVA DO PROJETO........................................................................................... 4 2.1 DADOS HISTÓRICOS........................................................................................... 4 2.2 DADOS DE ESTIMATIVAS E RESULTADOS............................................................ 4 2.2.1 TECNICAS DE ESTIMATIVA........................................................................ 4 2.3 RESULTADOS..................................................................................................... 5 2.4 RECURSOS DO PROJETO..................................................................................... 5 2.5 DIAGRAMA DE GANTT....................................................................................... 7 3.0 ANALISE E GESTÃODE RISCOS..................................................................................... 8 3.1 RISCOS DO PROJETO.......................................................................................... 8 3.2 TABELA DE RISCOS............................................................................................. 9 3.3 REDUÇÃO E GESTÃO DE RISCOS.................................................................... 10 4.0 ORGANIZAÇÃODO PESSOAL....................................................................................... 11 4.1 ESTRUTURA DA EQUIPE..................................................................................... 11 4.2 MECANISMOSDE COMUNICAÇÃO..................................................................... 12 4.3 USO DO EDU-BLOG COMO FERRAMENTA DE APOIO.......................................... 12
  3. 3. 3 1.0 INTRODUÇÃO Esta seção descreve uma visão geral sobre o projeto de software, mostrando suas principais funcionalidades e algumas restrições na implantação na UFS. 1.1 DESCRIÇÃO DO PROJETO Este Módulo de extensão é parte de um sistema maior de Administração acadêmica, pois na UFS administração acadêmica abrange Ensino, Pesquisa e Extensão, ficando esse último com parte social da atividade fim da UFS. A atividade de extensão na UFS passa por uma aprovação de resolução pelo conselho de ensinoe pesquisa(CONEP).Sendo assim, uma atividade de extensão segundo a resolução da UFS pode ser: projetos, cursos, eventos, produtos e prestação de serviços. Com isso um professor ou um técnico administrativo de nível superior poderá solicitar aprovação de qualquer uma dessas atividades ao setor gestor (PROEX) dessa modalidade. O gestorentracom os editais e oscalendáriosde execuçãodosprojetos,issodeve serdefinido nos perfisde cada usuário que faz login no sistema. Os professores e técnicos entram com as solicitaçõesde suasatividadesde extensãoe osestudantesfazem os relatórios das atividades propostas a eles junto com os técnicos administrativos e professores. As atividades podem ser financiadas ou não por órgãos conveniados com a UFS. Os professoresou técnicos podem solicitar mais de uma atividade de extensão, sendo que o conjunto dessas atividades em numero de 5 torna-se um programa de atividades. 1.2 PRINCIPAIS FUNÇÕES DO SISTEMA As principais funções são: O sistema deve ser capaz de prover papeis de usuários para quando os mesmos fizerem o login, apenas os módulos autorizados possam ser acessados por eles; Deve prover relatórios mensais, semestrais e anuais para os gestores das atividades; Deve ser capaz de inabilitar um professor ou técnico em uma próxima temporada de solicitaçãode atividadescasoestes não tenham cumprido as metas das atividades solicitadas anteriormente. 1.3 RESTRIÇÕES A principal restrição encontrada até o momento está na configuração de mudanças, pois muitasfuncionalidadesestãosendomudadastantonaUFS quantona UFRN e os merges estão sendo difíceis de administrar. Merge refere-se a integração dos sistemas tanto na UFS quanto na UFRN.
  4. 4. 4 2.0 ESTIMATIVAS DO PROJETO Esta seçãomostrará as estimativasde custo,esforçose tempo. Sabendo o prazo para cumprir o projeto, o gestor poderá planejar melhor as questões de recursos que abrange pessoas e custos. 2.1 DADOS HISTÓRICOS Como se trata da primeira vez que faço esse tipo de calculo para gerência de projeto de software, não tenho dados históricos para apresentar. 2.2 TECNICAS DE ESTIMATIVAS E RESULTADOS É demonstrado aqui como efetuar o cálculo para encontrar o prazo total de duração do projeto(emdias).Foi utilizadaamétricade Lorenz& Kidd,aconselhadapelaLacertae Software para estimar o prazo total deste projeto. 2.2.1 TECNICAS DE ESTIMATIVA Foi utilizadaatécnicade estimativadoCPDUFS Produçãode Software Ltdaque é uma métrica orientada a classes onde se destaca por ser simples e fácil de utilizar e segue as regras da métrica de Lorenz & Kidd. Para usar esta métrica devemos seguir alguns passos: 1. Definironúmerode classeschave; 2. Encontrar o número de classes de suporte, que para isso temos que classificar o tipo de Interface do Produto e desenvolver um Multiplicador para as Classes de Suporte; 3. Multiplicara quantidade de classes-chavepeloMultiplicadorparaobteruma estimativadonúmerode classesde suporte; 4. Logo após,calcula-se aquantidade total de Classes,somandoonºde Classes-Chave com o nº de Classesde Suporte; 5. Multiplicaraquantidade total de Classes(classes-chave +classesde suporte) pelo “númeromédiode unidadesde trabalho(dias-pessoa) porclasse”.Lorenz&Kidd sugere entre 15 e 20 dias-pessoaporclasse.Escolherumnúmeroentre 15-20 dias- pessoae justificaraescolha. 6. Determinaraquantidade de esforçoestimada; 7. Calculo do tempo previsto para a elaboração do projeto. A tabelaabaixomostraosfatores de multiplicação para encontrar a quantidade de classes de suporte: Interface Multiplicador Não gráfica 2 Baseada em texto 2,25 GUI 2,5 GUI complexa 3 Tabela de fator de multiplicação
  5. 5. 5 2.3 RESULTADOS De acordo com a métrica descrita acima obtivemos os seguintes resultados: 1. Quantidade de classes chaves = 10; 2. Este sistema rodará na WEB então utilizarei a interface gráfica GUI = 2,5; 3. Classes chaves x multiplicador (10 x 2,5) = 25 classes de suporte; 4. Classes chaves + classes de suporte (10 + 25) = 35 classes projetada para o sistema; 5. Comona empresanãotenhoexperiênciaparasaberexatamente aquantidadede dias- pessoa, escolherei o valor mínimo sugerido por Lorenz & Kidd. Neste caso 15 dias- pessoa; 6. Posso agora calcular a quantidade de esforço estimada: (35 x 15) = 525 dias de trabalho; 7. Agora vou calcular os dias corridos para construir o sistema, incluindo os fins de semana,fazendoamultiplicaçãodosdiasde trabalhocom os 30 diasdo mêse dividirei por 22 dias uteis: (525 x 30) = 15.750 ÷ 22 = 715,90 ≈ 716 dias corridos. Para saber os meses corridos basta dividir o resultado por 30. (716 ÷ 30) = 23,86 ≈ 24 meses corridos. A equipe para desenvolvimento deste projeto contem 4 membros, posso então calcular a distribuição dos dias de trabalho por pessoa. Com isso tenho 525 ÷ 4 = 131,25 ≈ 131 dias por pessoa. Aplicando a distribuição dos dias de trabalho aos percentuais de cada fase tenho a seguinte situação: Modelo % modelo % projeto Cálculo Dias trabalho Planejamento 2 – 3% 3% 525 x 3% ≈ 16 Requisito-Analise-Desenho 40% 40% 525 x 40% 210 Geração de código 20% 20% 525 x 20% 105 Testes 37-38% 37% 525 x 37% ≈194 Resultado 525 Tabela dos dias para termino do projeto 2.4 RECURSOS DO PROJETO Os recursosusadospara elaboraçãodeste projetoserão:humanos,de software,hardware e bibliográficos. Em relaçãoaos recursoshumanos,comoesse sistema na UFS trata-se muito mais de gerencia de configuração e mudanças, a fase que trata do planejamento: modelagem do negócio, requisitos, analise e design, implementação, teste e implantação que é a principal fase de construção do sistema, está a cargo dos profissionais da instituição UFRN, então esta instituiçãoserácolocadacomo um dosprofissionaisresponsáveispelo sistema e aparecerá no diagrama de Gantt.
  6. 6. 6 Recursos humanos: A equipe de desenvolvimentodoprojetoé formadapor quatromembros,sãoeles: UFRN · Gestorde Projeto · Analistade sistemas SigelmanAraujo · Gestorde Projeto · Analistade sistemas DiegoCortes · Analistade Sistemas · Programadorde Software · Engenheirode Software Vinicius · Programadorde Software Carla Cássia · Testadorade Software Recursos de Software: Para o desenvolvimentodeste projetoforamutilizadasas seguintes ferramentas de software: · Eclipse, software que dá apoio ao desenvolvimento em Linguagem de programação JAVA. · Java, linguagem de programação orientada a objetos, para a construção e manutenção dos softwares com recursos para WEB. · Postgres,sistemade gerênciade bancode dados relacional muito usado em empresas e por grandes sistema corporativos. · Pgadmin, software para facilitar os acessos ao banco de dados para uma melhor administração visual do mesmo. · MsProject, utilizado para facilitar a administração do projeto. · Microsoft word, para fazer documentações simples. · Internet Explorer, browser de Internet. · Mozila Firefox, browser de Internet. . Linux Ubuntu ou Debian, sistemas operacionais. . Windows 7, sistema operacional. . Hibernate, Software utilizado para fazer relação objeto-relacional. . Struts, software utilizado para relacionar regras de negócio. Recursos Hardware: Os hardwaresutilizadosparaelaboraçãodoprojetosão: · ComputadoresPessoaisPCdaHP · Impressoraparatestesde impressão Recursos Bibliográficos: O recursobibliográficoutilizadofoi oque segue: PRESSMAN,RogerS. Engenhariade Software,6ªedição,SãoPaulo,McGraw-Hill,2006
  7. 7. 7 2.5 DIAGRAMA DE GANTT O diagramade Gantt é ilustrado a seguir,trata-se de umgráficoque mostra todasas tarefas planejadascomsuasdatas de inicioe fime os recursosutilizados. Imagem do diagrama de Gantt parte 1 Imagem do diagrama de Gantt parte 2
  8. 8. 8 3.0 ANÁLISE E GESTÃODE RISCOS A análise de riscos é importante para um projeto, pois assim o gestor pode se prevenir para saber administrá-los. 3.1 RISCOS DO PROJETO Existe umsubconjuntode riscosque estãopresentesem qualquer projeto de software, riscos gerais, que são indicados na tabela seguinte: Risco Projeto Técnico Negócio Comum Especial Equipamento não disponivel X Requisitos incompletos X X Uso de metodologias especiais X X Problemas na busca da confiabilidade requerida X X Retenção de pessoas chave X X Sub-estimativa do esforço X X Tabela de subconjunto de riscos Avaliação global dos riscos: 1. O Gestor de Software dá suporte ao projecto? Sim, os gestores do software tanto na UFRN quanto na UFS, principalmente o primeiro, que tem uma gestão de solicitações e demandas, para dar total suporte ao projeto como um todo. 2. Os Clientes estão entusiasmados com o projecto e o produto? Sim,os clientesaofazeremtreinamentosnasversõescolocadas para este fim, ficaram entusiasmados com a possibilidade de implantação do sistema no ambito da UFS. 3. Os Engenheiros de Software compreenderam bem os requisitos? De acordo com as resoluções da UFRN, os requisitos foram bem compreendidos, faltandoapenasanalisarse haverá alguma mudança em relação as resoluções da UFS, porém as mudanças serão minimas, pois se tratam de dois orgão afins. 4. Os Clientes estiveram envolvidos na definição dos requisitos? Não possoafirmaremrelaçãoa UFRN,porémemrelação a UFS, os clientes estão bem envolvidos, participando de todos os treinamentos e discutindo as possibilidades de mudanças e querendo saber o que tem e o que não tem implantado no sistema para satisfazer suas necessidades. 5. O âmbito do projeto é estável? Por enquanto o projeto ainda não está estável na UFS, pois as configurações e mudanças,principalmente nastabelas de banco de dados de dominio, ainda estamos trabalhando muito com elas. 6. Os engenheiros de Software têm as competências requeridas? Sim, os engenheiros são bem capacitados para gerir as configurações e mudanças no sistema.
  9. 9. 9 7. Os requisitos do projeto são estáveis? Sim, de acordo com os treinamentos, os requisitos implantados, parece não precisar de mudanças, se alguma mudança for feita, será mais para acrescentar do que para tirar ou alterar. 8. A Equipe de Desenvolvimento tem experiência na tecnologia a implementar? Todos na UFS foram capacitados com cursos nas tecnologias, principalmente de software, para a implantação do sistema. 9. É adequado o número de pessoas da equipa de trabalho? Não. Mas como as dificuldades de contratação de pessoal é grande, exigirá muito esforço por parte da equipe. 3.2 TABELA DE RISCOS Segue abaixo a lista dos riscos identificados no projeto: Risco Categoria Probabilidade Impacto Insuficiência de pessoas na equipe Pessoal 80% Crítico Prazo para entrega curto Tecnico 80% Crítico Treinamento Usuários Docente e Discentes Características do Cliente 30% Marginal Mudanças nos requisitos Projeto 10% Crítico Falta de Motivação Pessoal 70% Marginal Rotatividade de pessoal Pessoal 20% Catastrófico Conflitos Pessoal 20% Marginal Tecnologia e infraestrutura (danos) Tecnico 10% Catastrófico Capacidade da equipe Pessoal 10% Crítico Perda de dados na Integração dos sistemas Técnico 80% Catastrófico Tabela dos riscos encontrados no projeto
  10. 10. 10 3.3 REDUÇÃO E GESTÃO DE RISCOS Dos itens elencados foram escolhidos dois com impacto critico e um com impacto catastrófico para descrevermos as suas atividades de redução, supervisão e gestão do risco. Na instituição existe um numero pequeno de profissionais de TI, até mesmo pela dificuldade na contratação dos mesmos, pois para isso deve-se abrir concurso publico ou licitação para contratação de terceirizados e deve existir verba para aprovação. Insuficiência de pessoas na equipe Risco:001 Probabilidade: 80% Impacto: Crítico Descrição: O numero de profissionais efetivos no CPD da UFS é reduzido. Estratégia de redução: Como o CPD da UFS não tem autonomia para contratação de pessoal, deve-se buscar com setores superiores formas de contratação de pessoal. Plano de contingência: havendo dificuldades de abertura de concursos públicos, abrir processo de licitação para contratação de terceirizados. Pessoa responsável: Sigelman Araujo Status: Simulação completada Muitas perdas de dados nos códigos ocorrem quando se faz a integração dos dados entre a UFRN e a UFS. Perda de dados na integração dos sistemas Risco:002 Probabilidade: 80% Impacto: Catastrófico Descrição: Ao efetuar a integração dos repositórios UFS e UFRN, perdas de dados existem. Estratégia de redução: Quando desenvolvemos em paralelo com o pessoal da UFRN, ainda está prevalecendo o repositório deles, sobrepondo as nossas mudanças no momento da integração, então devemos trabalhar para o mais rápido possível para ficarmos independente do desenvolvimento da UFRN e trabalharmos as nossas demandas locais sem precisar fazer a integração com eles. Plano de contingência: Fazer todo estudo necessário com a UFRN para que a parte essencial dos requisitos do sistema esteja de acordo com as necessidades da UFS e assim eles liberarem o módulo, deixando os profissionais deles livres para outras tarefas e nós de cá a vontade com as nossas demandas locais. Pessoa responsável: Diego Cortes Status: Simulação Incompleta
  11. 11. 11 Algumas mudanças de requisitos podem ocorrer, pois apesar de as instituições parecerem devido as suas atividades fins, algumas mudanças locais podem acontecer. Mudanças nos requisitos Risco:003 Probabilidade: 10% Impacto: Crítico Descrição: Os requisitos da UFRN forem diferentes dos da UFS. Estratégia de redução: sabendo que a fase de construção do software cabe a UFRN, devemos alertá-los o mais rápido possível para que haja um novo versionamento do sistema para a UFS. Plano de contingência: o Gestor deve trabalhar com a equipe da UFRN mostrando para eles como devem ser o comportamento dos nossos requisitos. Pessoa responsável: UFRN e Sigelman Araujo Status: Simulação Incompleta 4.0 ORGANIZAÇÃO DO PESSOAL A nossaequipe segue umaestruturadescentralizada democrática, pois, apesar de termos um gestorcompetente responsável pela organização dos trabalhos, as decisões são tomadas em conjuntoe com o consensode todose a comunicaçãoé horizontal.Alémdisso,estaé a melhor estrutura para problemas complexos e que requerem muita comunicação, além de ser a que produz melhores ambientes e satisfação no trabalho. 4.1 ESTRUTURA DA EQUIPE A equipe é formadaporcincoelementose logo no inicio dos trabalhos definimos claramente as funções de cada um, sendo: UFRN - Gestor de Projeto e Analista de sistemas; Sigelman Araujo - Gestor de Projeto e Analista de sistemas; Diego Cortes - Analista de Sistemas, Programador de Software e Engenheiro de Software; Vinicius - Programador de Software e Carla Cássia - Testadora de Software. O gestor tem a responsabilidade de coordenar todo o desenvolvimento do projeto, combinando reuniões, distribuindo tarefas, resolver conflitos e manter a motivação e bom ambiente noseiodogrupo,alem de ser responsável pelo planejamento temporal do projeto compondo o diagrama de Gantt. O analista de sistema tem a função de analisar o software e desenhar os vários diagramas do sistema e criar as classes e interfaces a implementar. O engenheirode software estudae selecionatantoasferramentasutilizadascomoohardware e plataformas onde o software será utilizado. Os programadores recebem o trabalho do analista e programam o código do novo sistema. O testador no fim testa exaustivamente todo o sistema de forma a detectar erros na implementação.
  12. 12. 12 4.2 MECANISMOS DE COMUNICAÇÃO A comunicaçãoentre todososelementosdaequipeé feitaprincipalmenteatravésde reuniões periódicas, resolvem-se problemas em conjunto e distribuem-se tarefas. Além disso, são tambémutilizadososmeios de comunicação eletrônica, através de correio eletrônico e MSN Messenger, e meios de comunicação telefônica. 4.3 USO DO EDU-BLOG COMO FERRAMENTA DE APOIO Achamoso Edu-bloguma excelente ferramenta de apoio à disciplina, pois é fácil e agradável de utilizar, permite ao professor disponibilizar todo o material referente à disciplina e possibilita a comunicação entre o docente e todos os alunos, sendo muito útil para cada um apresentar as suas dúvidas e sugestões. Em relaçãoaos blogsde cada equipe,achamosque é tambéminteressante na medida em que permite a cada grupo partilhar com a comunidade o desenvolvimento do seu trabalho, disponibilizando arquivos, bem como receber sugestões e criticas de qualquer pessoa. No entanto para comunicação entre os membros da equipe, utilizamos o MSN Messenger.

×