Planode de Projeto - SIGEP

344 visualizações

Publicada em

Trabalho apresentado ao Prof. Dr. Rogério
Patrício Chagas do Nascimento como parte
avaliativa da disciplina Gerência de Projetos do
Curso de Graduação em Sistemas de
Informação da Universidade Federal de
Sergipe – UFS.

Publicada em: Educação
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
344
No SlideShare
0
A partir de incorporações
0
Número de incorporações
49
Ações
Compartilhamentos
0
Downloads
2
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Planode de Projeto - SIGEP

  1. 1. UNIVERSIDADE FEDERAL DE SERGIPE  CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA  DEPARTAMENTO DE COMPUTAÇÃO  Gerência de Projetos 2014.2                  PLANO DO PROJETO DE SOFTWARE      SISTEMA DE GERENCIAMENTO DE PROJETOS DE PESQUISA  SIGEP            GRUPO 1    Domenico Medeiros  Edson Fernando Poderoso Moreira  Eric Souza  Henrique Mandt Lima Figueiredo  Vanessa Menezes Oliveira         
  2. 2.   São Cristóvão – Sergipe  2015  Domenico Medeiros  Edson Fernando Poderoso Moreira  Eric Souza  Henrique Mandt Lima Figueiredo  Vanessa Menezes Oliveira                  PLANO DO PROJETO DE SOFTWARE    SISTEMA DE GERENCIAMENTO DE PROJETOS DE PESQUISA  SIGEP              Trabalho apresentado ao Prof. Dr. Rogério            Patrício Chagas do Nascimento como parte            avaliativa da disciplina Gerência de Projetos do              Curso de Graduação em Sistemas de            Informação da Universidade Federal de          Sergipe – UFS.                São Cristóvão – Sergipe  2015 
  3. 3. Sumário    1. INTRODUÇÃO................................................................................................................... 4  1.1​​Âmbito do Projeto....................................................................................................... 4  1.2​​Funções principais do produto de software.................................................................... 4  1.3​​Requisitos comportamentais ou de performance............................................................ 5  1.4​​Gestão e Restrições Técnicas..................................................................................... 6  2. ESTIMATIVAS DO PROJETO............................................................................................ 7  2.1 Dados históricos utilizados para as estimativas.............................................................. 7  2.2 Técnicas de estimação e resultados.............................................................................. 7  2.2.1 Técnica de estimativas........................................................................................ 7  2.3 Resultados.................................................................................................................. 8  2.4 Recursos do projeto................................................................................................... 10  2.4.1 Recursos Humanos........................................................................................... 10  2.4.2 Recursos de Software........................................................................................ 11  2.4.3 Recursos de Hardware....................................................................................... 12  3. ANÁLISE E GESTÃO DE RISCOS.................................................................................... 12  3.1 Riscos do projeto............................................................................................................. 13  3.2 Tabela de riscos............................................................................................................... 13  3.3 Redução e Gestão do Risco.............................................................................................. 14  4. PLANEJAMENTO TEMPORAL........................................................................................  17  4.1 Conjunto de Tarefas do Projeto.......................................................................................... 17  4.2 Diagrama de Gantt........................................................................................................... 19  5. ORGANIZAÇÃO DO PESSOAL........................................................................................ 20  5.1 Estrutura da equipe.......................................................................................................... 20  5.2 Mecanismos de comunicação........................................................................................... 21  5.3 Uso do Edu­blog como ferramenta de apoio........................................................................ 21  6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO  DE SOFTWARE………………………………………………………………………………………...22       
  4. 4. 1.  INTRODUÇÃO    1.1 Âmbito do Projeto    O Sistema de Gerenciamento dos Projetos de Pesquisas (SIGEP) foi                    desenvolvido para o Hospital Universitário da Universidade Federal de Sergipe, com o                        objetivo de automatizar o processo do controle dos Projetos de Pesquisas realizados                        pelo mesmo. Os professores poderão cadastrar novas pesquisas que futuramente                    poderão ser validadas pelo Diretor. O sistema permitirá ainda, gerar relatórios para uma                          melhor administração do controle das pesquisas do Hospital.  Antes da implementação do SIGEP, o processo era feito de forma manual. O                          que resultava muitas vezes em perdas de informação. Com a automação, todo o                          processo tornou­se mais agilizado e seguro.    1.2 Funções principais do produto de software    O diagrama da exposto na Figura 1 abaixo, refere­se ao diagrama de Casos de                            Uso e contém as principais funcionalidades do sistema SIGEP. Nele é apresentado as                          operações que serão possíveis através do sistema, como: fazer ​login​, cadastrar uma                        pesquisa, validar a pesquisa, gerar relatórios, manutenir cadastros e alterar ​status ​da                        pesquisa. As atividades que envolvem a manutenibilidade de determinado objeto estão                      relacionadas com as operações: incluir, alterar e inativar. 
  5. 5.   Figura 1 ­ Diagrama de Casos de Uso do SIGEP    1.3 Requisitos comportamentais ou de performance    ● Usabilidade:  ○ As mensagens devem ser claras e objetivas, favorecendo o bom                    entendimento do funcionamento do sistema.  ○ Todas as telas referentes à transição deverão possuir a mesma estrutura                      e padronização referente ao layout de cores.  ● Confiabilidade:  ○ O sistema deve realizar as transações exatamente de acordo com o que                        o usuário solicitar, sem excessos nem omissões.  ○ O sistema deverá permitir que sua confiabilidade seja medida e avaliada,                      principalmente através de testes, onde serão verificadas as transações                 
  6. 6. mais vulneráveis e que necessitam de maior atenção em correções e                      ajustes.   ● Desempenho:  ○ O sistema deverá retornar consultas gerais em no máximo 5s.   ○ Para transações de cadastros e alterações em geral, o sistema deverá                      retornar o sucesso ou insucesso da transação em no máximo 3s.   ● Segurança:  ○ O Acesso do sistema se dará através de ​login e senha, com isso, poderá                            acessar o sistema apenas pessoas habilitadas para este fim.   ○ Todas as informações a nível de memória e armazenamento do ​browser                      (​cookies​) serão sumariamente apagadas quando o usuário sair do                  sistema, com isso, evita­se o risco que informações possam de alguma                      forma ser manipuladas por pessoas não autorizadas.    1.4 Gestão e Restrições Técnicas    As restrições encontradas na descrição do sistema que poderão limitar o                      escopo podem ser:  ● É necessária a existência de uma estrutura de computadores ligados                    através de uma rede interna.   ● É necessária a existência de uma máquina que será utilizada como                      servidor com dedicação exclusiva que será responsável pelo controle de                    todas as atividades referentes à infraestrutura, como backups de                  informações e demais atividades controladas pela administração do                sistema.   ● O sistema atuará sobre a plataforma Windows XP SP3 ou superior.  ● O produto deve ser implementado como uma aplicação web e portável                      para as plataformas Internet Explorer 8.0.6001.18702 (Ou superior) ou                 
  7. 7. Google Chrome 33.0.1750.117m (Ou superior) ou Mozilla Firefox 27.0.1                  (Ou superior).  ● O produto deve utilizar Banco de Dados PostgreSql.  ● O produto deve ser implementado na linguagem de programação PHP.  ● Falta de capacitação técnica da equipe, sendo necessário um treinamento                    específico para alguns componentes da equipe com ferramentas que                  serão utilizadas.    2. ESTIMATIVAS DO PROJETO     2.1 Dados históricos utilizados para as estimações    Não serão utilizados dados históricos na avaliação do projeto, visto que este                        será o primeiro projeto da equipe.    2.2 Técnicas de estimação e resultados    Para estimar o tempo é necessária a utilização de uma técnica de estimativa, e a                              técnica escolhida foi a de Lorenz & Kidd, Orientada a Classes, adotada pela Lacertae                            Software.    2.2.1 Técnicas de estimação e resultados    A técnica de estimação escolhida para o SIGEP foi a adotada pela Lacertae                          Software. Trata­se de uma métrica orientada a classes que consiste em:  1. Determinar a quantidade de classes­chave do projeto;  2. Encontrar o número de classes de suporte, classificando o tipo de                      interface do produto e utilizando multiplicadores correspondentes para as                  classes de suporte; 
  8. 8. 3. Multiplicar a quantidade de classes­chave pelo multiplicador              correspondente para estimar o número de classes de suporte;  4. Multiplicar o total de classes (chave + suporte) pelo número médio de                        unidades de trabalho (dias­pessoa) por classe;  5. Calcular o tempo previsto para a realização do projeto.  A Tabela 1 com os Multiplicadores utilizados para encontrar a quantidade de                        classes de suporte:    INTERFACE  MULTIPLICADOR  Não Gráfica  2  Baseada em Texto  2,25  GUI Simples  2,5  GUI Complexa  3  Tabela 1 ­ Fatores Multiplicativos    2.3 Resultados    Com base no diagrama de classes de análise da Figura 2, fez­se a estimativa: 
  9. 9.     1. Número de classes­chave encontradas após a análise do diagrama de                    classes de domínio: ​10​;  2. Interface selecionada (De acordo com o modelo de arquitetura do                    sistema): ​GUI simples​;  3. Número de classes de suporte encontrado: 10 (classes­chave) x 2,5                    (valor multiplicador utilizado da Tabela 1)= ​25 classes de suporte​;  4. Número total de classes: 10 (chave) + 25 (suporte)= ​35 classes​;  5. Quantidade de dias que uma pessoa gastaria para desenvolver uma                    única classe: ​9 dias​;  No modelo Lacertae, é recomendado o uso de 15 a 20 dias porém,                          utilizamos a quantidade de 9 dias com base no tempo utilizado quando o SIGEP foi                              desenvolvido.  6. Quantidade total de dias que uma pessoa gastaria para construir todo o                        sistema: 9 (dias) * 35 (classes) = ​315 dias​;  7. Quantidade total de dias que a equipe gastaria para construir todo o                        sistema: 315 (dias) / 5 (quantidade de integrantes)= ​63 dias​.    Sendo assim, o tempo necessário para a construção do projeto deve ser de,                          aproximadamente, 63 dias, que dividindo por 22 (quantidade de dias úteis de um mês)                            resulta num tempo aproximado de 3 meses.    2.4 Recursos do projeto    2.4.1 Recursos Humanos    O projeto contará com cinco pessoas que exercerão os diversos papéis                      que serão necessários para a execução do projeto de desenvolvimento de software. Na                         
  10. 10. Tabela2 abaixo, podemos verificar os envolvidos de acordo os com seus respectivos                        papéis.      Papel  Responsável  Gerente de Projeto  Vanessa Menezes  Analista de Sistemas  Henrique Mandt  Arquiteto de Software  Edson Poderoso  Codificador  Domenico Medeiros, Edson Poderoso  Testador  Eric Souza, Henrique Mandt, Vanessa Menezes  Tabela 2 ­ Recursos Humanos    2.4.2 Recursos do Ambiente de Desenvolvimento    Para o bom desenvolvimento deste projeto, foram utilizados os seguintes                    recursos de software:  ● PostgreSql ­ Sistema de gerenciamento do banco de dados;  ● PHP ­ Linguagem de programação a ser utilizada no                  desenvolvimento do software;  ● Microsoft Office ­ Editor de texto, planilhas e apresentações usados                    na documentação e relativos;  ● Gmail ­ Sistema de e­mail utilizado para troca de informações;  ● Google Drive ­ Sistema de armazenamentos de dados em nuvem                    para compartilhamento de arquivos e alterações dos mesmos em                  tempo real;  ● GanttProject 2.7 ­ Utilizada para elaborar o Diagrama de Gantt;  ● NetBeans 7.2.1 ­ IDE que será utilizada na implementação do                    produto de software; 
  11. 11. ● MsProject 2010 ­ Auxilia na gerência das atividades do projeto.    2.4.3 Recursos de Hardware    Computador para Desenvolvimento:  Processador: Core i3 ou superior.  Memória RAM: 4 Gb de RAM.  HD: 250 Gb ou superior.    3. ANÁLISE E GESTÃO DE RISCOS    Nesta seção, serão analisados os possíveis riscos prejudiciais para o                    desenvolvimento do projeto de software. Por meio desta análise, visamos minimizar o                        máximo possível a sua ocorrência e, consecutivamente, o seu impacto caso venha a                          ocorrer.    3.1 Riscos do projeto    Segue abaixo a Tabela 3 com os riscos levantados para o referido projeto:    Risco  Projeto  Técnico  Negócio  Comum  Especial  Equipe não domina totalmente        a tecnologia adotada no        projeto      X      X  Equipe não possui o        treinamento necessário na      linguagem de desenvolvimento      adotada      X        X  Equipe pequena no      desenvolvimento do projeto  X        X 
  12. 12. Custos relacionados ao mal        uso da ferramenta    X      X  Ferramentas de teste com        baixo suporte à tecnologia        empregada no projeto      X        X  Período de desenvolvimento      do projeto relativamente curto  X    X      Equipe não disponível em        tempo integral  X      X    Constante necessidade de      aprimoramento do software  X      X    Tabela 3 ­ Riscos x Classificação    3.2 Tabela de riscos    Na Tabela 4 a seguir, foram definidos para cada risco, apresentado                      anteriormente na Tabela 3, uma probabilidade que determina a chance de ocorrência                        do mesmo, bem como o impacto após o acontecimento do risco.    Risco  Probabilidade (%)  Impacto  Ferramentas de teste com baixo suporte            à tecnologia empregada no projeto  90%  Catastrófico  Período de desenvolvimento do projeto          relativamente curto  80%  Crítico  Equipe não disponível em tempo integral  70%  Moderado  Equipe pequena no desenvolvimento do          projeto  70%  Marginal  Custos relacionados ao mal uso da            ferramenta  70%  Marginal  Equipe não domina totalmente a          tecnologia adotada no projeto  60%  Moderado 
  13. 13. Equipe não possui o treinamento          necessário na linguagem de        desenvolvimento adotada    60%    Moderado  Constante necessidade de      aprimoramento do software  40%  Moderado  Tabela 4 ­ Riscos do Projeto    3.3 Redução e Gestão do Risco    Visando garantir a redução e/ou gestão dos riscos apresentados, as estratégias                      de redução, supervisão e gestão dos riscos (RSGR) foram adotadas:    1. Equipe não domina totalmente a tecnologia adotada no projeto  Probabilidade: ​60%  Impacto: ​Moderado  Descrição: ​A equipe não possui o conhecimento mínimo suficiente sobre a  tecnologia utilizada no desenvolvimento do projeto.  Estratégia de Redução: ​Buscar métodos que visem expandir e aprimorar os  conhecimentos acerca da referida tecnologia.  Plano de Contingência: ​Planejar e definir em em equipe as estruturas de dados  utilizadas no SIGEP em oposição à prática do desenvolvimento individual com o  intuíto de evitar bloqueios por falta de domínio da tecnologia.  Responsável: ​Edson Poderoso  Status: ​Concluído  Tabela 5 ­ Análise do risco 1    2. Equipe não possui o treinamento necessário na linguagem de  desenvolvimento adotada  Probabilidade: ​60%  Impacto: ​Moderado  Descrição: ​Devido à escassez de cursos locais, o treinamento da equipe é baixo.  Estratégia de Redução: ​Cursos e apostilas de aprendizado online 
  14. 14. Plano de Contingência: ​Adotar uma linguagem de programação comum ao  conhecimento de todos os participantes.  Responsável: ​Domenico Medeiros  Status: ​Concluído  Tabela 6 ­ Análise do risco 2    3. Equipe pequena no desenvolvimento do projeto  Probabilidade: ​70%  Impacto: ​Marginal  Descrição: ​A equipe responsável pela construção do projeto é relativamente                    pequena.  Estratégia de Redução: ​Divisão das tarefas da equipe de acordo com um                        planejamento, evitando assim a sobrecarga de funções.  Plano de Contingência: ​Entregar o projeto em etapas incrementais.  Responsável: ​Vanessa Menezes Oliveira  Status: ​Concluído  Tabela 7 ­ Análise do risco 3    4. Custos relacionados ao mau uso do SIGEP  Probabilidade: ​70%  Impacto: ​Marginal  Descrição: ​Caso o software se comporte de forma não planejada, erros poderão  acontecer implicando em custos extras  Estratégia de Redução: ​Efetuar exaustivos testes no software antes da entrega.  Plano de Contingência: ​Capacitar pessoas a oferecer suporte ao SIGEP, bem como  fornecer manuais de uso para os usuários.  Responsável: ​Eric Souza  Status: ​Concluído  Tabela 8 ­ Análise do risco 4   
  15. 15. 5. Ferramentas de teste com baixo suporte à tecnologia empregada no                    projeto  Probabilidade: ​90%  Impacto: ​Catastrófico  Descrição: ​Ferramentas de teste automatizado acabam por oferecer pouco suporte                    à tecnologia usada na codificação do produto.  Estratégia de Redução: ​Diminuição gradativa do uso dessas ferramentas por meio                      da implantação de outros processos de teste, visando novas soluções.  Plano de Contingência: ​Divisão de testes complexos em outros menores, mais                      simplificados, de forma a facilitar o uso das ferramentas já utilizadas.  Responsável: ​Henrique Mandt  Status: ​Concluído  Tabela 9 ­ Análise do risco 5    6. Período de desenvolvimento do projeto relativamente curto  Probabilidade: ​80%  Impacto: ​Crítico  Descrição: ​O prazo para a completa construção do software é curto.  Estratégia de Redução: ​Divisão pertinente das atividades seguindo o planejamento.  Plano de Contingência: ​Efetuar entregas parciais do SIGEP ao usuário.  Responsável: ​Eric Souza  Status: ​Concluído  Tabela 10 ­ Análise do risco 6    7. Equipe não disponível em tempo integral  Probabilidade: ​70%  Impacto: ​Moderado  Descrição: ​Devido às atividades independentes dos membros da equipe, o tempo                      disponível para o projeto não é integral.  Estratégia de Redução: ​Divisão pertinente das atividades seguindo 0 planejamento                    à risca. 
  16. 16. Plano de Contingência: ​Revisar as atividades realizadas por cada integrante de                      forma a não haver uma sobrecarga de tarefas. Uma nova divisão de tarefas pode                            facilitar o processo.  Responsável: ​Vanessa Menezes  Status: ​Concluído  Tabela 11 ­ Análise do risco 7    8. Constante necessidade de aprimoramento do SIGEP  Probabilidade: ​40%  Impacto: ​Moderado  Descrição: ​As necessidades do usuário podem passar por diversas modificações                    mediante a evolução das atividades, levando a uma constante modificação do                      produto.  Estratégia de Redução: ​Disponibilizar versões ​alpha (versões de testes) para que                      os usuários conheçam o software e possam opinar no aprimoramento do mesmo,                        identificando precocemente as necessidades dos usuários, de forma a melhorar o                      produto.  Plano de Contingência: ​Buscar atender prioritariamente as obrigações definidas                  contratualmente, oferecendo o serviço de customização como uma opção posterior.  Responsável: ​Edson Poderoso  Status: ​Concluído  Tabela 12 ­ Análise do risco 8    4. PLANEJAMENTO TEMPORAL    Nesta seção serão apresentadas as tarefas realizadas no SIGEP e seu                      planejamento temporal do Diagrama de Gantt, onde será definido as datas de início e                            fim e o responsável por cada tarefa.     4.1 Conjunto de Tarefas do Projeto   
  17. 17. Aqui são apresentados o Modelo de Processo escolhido, suas atividades e                      algumas tarefas escolhidas para serem apresentadas nesta seção.  Com base nos cálculos descritos na seção 2 presente no item 2.3 (Resultados),                          o esforço estimado para a realização do projeto é de 63 dias trabalhados.  Abaixo é exibido o plano temporal das fases do SIGEP.    Fases  Porcentagem  Dias Trabalhados  Planejamento  18%  11,34  Análise de Requisitos  34%  21,42  Geração de Código  37%  23,31  Testes  11%  6,93  Tabela 13 ­ Dias por Tarefa  A porcentagem estabelecida para as fases do SIGEP diferenciam­se das                    sugeridas no modelo Lacertae. Visto que o SIGEP já foi desenvolvido posteriormente e                          a média de dias para desenvolvimento de uma classe (apresentada na secão 2, item                            2.3) também resultou nos valores de porcentagem apresentados na Tabela 13.  Diagrama de Gantt 
  18. 18.  
  19. 19.     5. ORGANIZAÇÃO DO PESSOAL    Cada membro da equipe possui seus papéis e atividades bem definidas, onde                        cada um sabe qual deverá ser a tarefa a ser realizada. As decisões são sempre                              tomadas em conjunto.    5.1 Estrutura da equipe    Analista de Sistemas ­ estudam os diversos sistemas existentes entre                    hardwares (equipamentos), softwares (programas) e o usuário final.  Responsável: Henrique Mandt  Analista de Testes ­ identificam e definem os testes necessários, monitorar a                        abrangência dos testes e avaliar a qualidade obtida ao realizar os testes. Responsável                          ainda por desenvolver e testar componentes de acordo com os padrões adotados para                          o projeto, para fins de integração com subsistemas maiores.  Responsável: Eric Souza  Arquiteto de Software ­ lideram e coordenam as atividades e os artefatos                        técnicos no decorrer do projeto. Estabelece também, a estrutura geral de cada visão de                            arquitetura: a decomposição da visão, o agrupamento dos elementos e as interfaces                        entre esses principais agrupamentos.   Responsável: Edson Poderoso  Gerente de Projetos ­ gerencia o progresso do empreendimento e por meio                        das variáveis (qualidade, custo, prazo e âmbito) verificam seus desvios, de forma a                          minimizar as falhas ligadas ao processo.  Responsável: Vanessa Menezes 
  20. 20. Product Owner ­ trata­se da única pessoa responsável pelo gerenciamento do                      Backlog do Produto e por garantir o valor do trabalho realizado pelo ​Time Scrum​,                            permitindo que todos os outros membros da equipe possam visualizá­lo.  Responsável: Domenico Medeiros.    5.2 Mecanismos de comunicação      As formas de comunicação utilizadas para o projeto foram:  ● E­mail ­ comunicação direta para os demais participantes do projeto com                      relatórios informando as evoluções e problemas encontrados ao longo do                    desenvolvimento.  ● Reuniões Diárias ­ permitiram a comunicação face­a­face e ajudaram a                    verificar o andamento do projeto.  ● Ferramentas Colaborativas ­ documentos importantes foram            compartilhados e editados em tempo real por meio do Google Drive,                      permitindo a participação de todos os envolvidos.  ● Aplicativos (Whatsapp) ­ interações rápidas e tomadas de decisões                  diretas foram realizadas em tempo hábil através da criação de um grupo                        no aplicativo para ​smatphones​.    5.3 Uso do Edu­blog como ferramenta de apoio    O Edu­blog é uma ferramenta bastante simples e possui acesso facilitado, apóia                        a colaboração entre pessoas como fonte de disseminação de conhecimentos.  A utilização do blog durante o desenvolvimento desse trabalho foi importante                      para o seu bom andamento. Um importante papel do blog foi compartilhar os                          conhecimentos por nós elencados, bem como compartilhar informações com outras                    equipes que serviram como base para a edição deste documento.   
  21. 21.     6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A  QUALIDADE DO PRODUTO DE SOFTWARE    Visando garantir a qualidade do software, algumas atividades foram  desenvolvidas durante o projeto, sendo elas:  ● Testes ­ ​Sucessivos testes foram realizados durante a fase de                    desenvolvimento do software, com a finalidade de evitar futuras ​releases                    de correção de eventuais erros que possam vir a ocorrer no software.  ● Reuniões Diárias ­ Por meio das reuniões diárias realizadas pelos                    membros da equipe, foi possível sanar eventuais dúvidas que vieram a                      surgir com relação ao desenvolvimento do projeto. Auxiliando evitar, de                    maneira ágil, desvios de má interpretação. Atividades de ​brainstorming                  foram essenciais para tomadas de decisão com relação a um melhor                      desenvolvimento do software.  ● Elaboração de Documentação ­ para um melhor controle do projeto,                    documentações foram elaboradas nas fases de análise, projeto e testes. 

×