Your SlideShare is downloading. ×

Plano de Projeto SGS

812
views

Published on

Published in: Education

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
812
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
33
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. UNIVERSIDADE FEDERAL DO AMAZONAS INSTITUTO DE COMPUTAÇÃO PLANO DE PROJETO DE SOFTWARETÍTULO: SISTEMA DE GERENCIAMENTO DE SERVIÇOS – SGS VERSÃO 1.0 Equipe: Rafael do Nascimento Almeida Rodrigo Azevedo da Costa Tiago Lahan da Silva Professor Orientador: Rogério P. C. do Nascimento Manaus – AM 2011
  • 2. Sumário1. INTRODUÇÃO ....................................................................................................................... 3 1.1 Âmbito do Projeto.......................................................................................................... 3 1.2 Funções principais do produto de software .......................................................... 3 1.3 Requisitos comportamentais ou de performance ................................................ 4 1.4 Gestão e Restrições Técnicas.................................................................................... 42. ESTIMAÇÕES DO PROJETO ............................................................................................. 5 2.1 Dados históricos utilizados para as estimativas .................................................. 5 2.2 Técnicas de estimativas e resultados ...................................................................... 5 2.2.1 Técnicas de estimativa ............................................................................................. 5 2.3 Resultados....................................................................................................................... 6 2.4 Recursos do Projeto ..................................................................................................... 73. ANÁLISE E GESTÃO DE RISCOS ..................................................................................... 8 3.1 Riscos do Projeto .......................................................................................................... 8 3.2 Tabela de Riscos ........................................................................................................... 9 3.3 Estratégias para Gestão de Riscos ........................................................................ 104. PLANEJAMENTO TEMPORAL ......................................................................................... 13 4.1 Conjunto de Tarefas do Projeto ............................................................................... 13 4.2 Diagrama de Gantt....................................................................................................... 135. ORGANIZAÇÃO DO PESSOAL ........................................................................................ 14 5.1 Estrutura da equipe..................................................................................................... 14 5.2 Mecanismos de comunicação .................................................................................. 14 5.3 Uso do Edu-blog como ferramenta de apoio ....................................................... 15Plano de Projeto de Software Página 2
  • 3. 1. INTRODUÇÃO1.1 Âmbito do Projeto Atualmente na Universidade Federal do Amazonas - UFAM, as requisições deserviços são solicitadas por meio de uma requisição em papel, o que muitas vezespode causar perda, esquecimento ou até extravio de alguma requisição importante. Aprefeitura então, recebe a requisição, envia para a divisão responsável que executa asatividades necessárias. Existe um controle das requisições solicitadas mas, sem umacompanhamento das atividades realizadas por parte do usuário nem controle sobreos gastos com tais atividades. Dessa forma, o Sistema de Gestão de Serviços - SGS, visa disponibilizar ummelhor controle estatístico e financeiro dos serviços realizados assim como,possibilitar o acompanhamento das atividades de um serviço pelo requisitante. O SGSproporcionará também um controle da requisição desde a sua criação até o seuarquivamento ou descarte.1.2 Funções principais do produto de software O escopo do sistema SGS é composto das principais funções: • Cadastro de requisições de serviço; • Consulta eletrônica da situação das atividades do serviço; • Controle estatístico e financeiro de requisições cadastradas; • Categorização de acesso de acordo com cada usuário; • Emissão de relatórios para consulta por: Divisão, Unidade Solicitante, Situação e Data; O sistema deve permitir as seguintes funcionalidades para os usuários; Administrador o Manter usuários do sistema; o Gerir requisições; o Cancelar requisições em andamento; o Emissão de relatórios estatísticos e financeiros.Plano de Projeto de Software Página 3
  • 4. Requisitante o Solicitar requisição; o Acompanhar as atividades de um serviço;1.3 Requisitos comportamentais ou de performance Sobre os requisitos comportamentais, as funcionalidades não são consideradascríticas, porém, devem atender o máximo possível as funcionalidades já existentes emversões anteriores ao SGS, pois, a cultural comportamental dos servidores afeta nodesempenho e na utilização do software. Em termos de performance, o software terá que responder adequadamente acertos critérios, sendo fundamentais, a interface e a acessibilidade. Dessa forma, énecessário que a interface seja agradável para o utilizador do sistema. Deve atender apessoas que possuem pouco ou nenhum conhecimento em informática ou utilizaçãode ambiente web.1.4 Gestão e Restrições Técnicas Esta seção lista os itens que trazem restrição para o desenvolvimento dosistema e, delimita o escopo em que o sistema deverá ser produzido. • O sistema deverá importar a base de dados do SIE. • O sistema deverá ser construído utilizando a tecnologia Grails. • Falta de experiência prática com as ferramentas e métodos utilizados para o desenvolvimento.Plano de Projeto de Software Página 4
  • 5. 2. ESTIMAÇÕES DO PROJETO Estimativas de projeto são realizadas com o intuito de acompanhar todo o fluxode atividades de um determinado projeto de software. Assim, temos uma visão geraldos prazos e cronogramas a serem obedecidos. As estimações levam emconsideração uma série de fatores tais como: número de pessoas envolvidas,complexidade do projeto, material disponível para execução das atividades,conhecimento técnico dos envolvidos entre outros que influenciam diretamente nosucesso da aplicação. As estimativas mostram ao gerente de projeto o que tem que ser feito em cadaetapa da longevidade do processo de desenvolvimento, mostrando ainda se o projetoestá em dia, em atraso ou, adiantado. Dessa forma, o gerente pode cobrar resultadosdos responsáveis e, acompanhar de perto cada fase que está sendo realizada,possuindo embasamento teórico para isso.2.1 Dados históricos utilizados para as estimativas É nosso primeiro trabalho de projeto levando em consideração cálculos paraestimativas e, nenhum membro possui experiência em gerência projeto de software.2.2 Técnicas de estimativas e resultados Para estimar o prazo total do projeto, foi utilizada a métrica de Lorenz & Kidd(orientado a classes), apresentada pela Lacertae Software. Aqui, demonstramos ocálculo realizado e os fatores envolvidos. 2.2.1 Técnicas de estimativa Utilização da técnica Lorenz & Kidd: a. Definição do número de Classes-chave; b. Definição do número de Classes de suporte. Consiste em classificar o tipo de Interface do Produto e determinar um valor Multiplicador para as Classes de suporte; c. Multiplicar a quantidade de Classes-chave pelo valor Multiplicador, obtendo o número de Classes de suporte;Plano de Projeto de Software Página 5
  • 6. d. Cálculo da quantidade total de classes (Classes-chave + Classes de suporte); e. Multiplicar o total de classes pelo número médio de unidades de trabalho (dias- pessoa); f. Determinar a quantidade de esforço estimada; g. Cálculo do tempo previsto para a realização do projeto. A Tabela 1, abaixo, mostra os fatores de multiplicação utilizados para encontrara quantidade de classes de suporte: Interface Valor multiplicador Não gráfica 2 Baseada em texto 2,25 GUI 2,5 GUI Complexa 3 Tabela 1. Fator de multiplicação2.3 Resultados De acordo com a métrica descrita acima se obteve os seguintes resultados: 1. Número de classes chaves = 10; 2. Sistema em ambiente web. Então, interface gráfica GUI = 2,5; 3. Classes chaves x multiplicador (10 x 2,5) = 25 classes de suporte; 4. Número total de classes: Classes chaves + classes de suporte (10 + 25) = 35; 5. Por falta de experiência da equipe em trabalhos do gênero, consideramos o máximo de dias indicado pela métrica (20 dias-pessoa); 6. Para calcular a quantidade de esforço estimada: 35 x 20 = 700 dias de trabalho; No melhor caso, considerando três pessoas envolvidas no projeto, temos:700 dias ÷ 3 pessoas = 233,33 dias-pessoa o que dividindo por 30 (dias/mês) resultano tempo total de aproximadamente 8 meses. Para este cálculo, utilizou-se aquantidade total de dias no mês (30) e não apenas os dias úteis (22).Plano de Projeto de Software Página 6
  • 7. 2.4 Recursos do Projeto 2.4.1 Recursos Humanos O projeto contará com três pessoas que exercerão os diversos papéisnecessários para a execução do projeto de desenvolvimento do software, Na Tabela 2,abaixo, verificamos os envolvidos de acordo com os seus respectivos papéis. Papel Responsável Gerente do Projeto Tiago Lahan Analista de Sistemas Rafael Almeida Projetista de Software Rodrigo Azevedo Codificador Tiago Lahan, Rafael Almeida Testador Rodrigo Azevedo Tabela 2. Recursos Humanos 2.4.2 Recursos do ambiente de desenvolvimento Para o desenvolvimento deste projeto foram utilizados os seguintes recursosde software: • Netbeans: Ambiente gráfico que suporta desenvolvimento em Grails; • Grails: Framework de desenvolvimento • Groovy: Linguagem de programação com recursos para Web; • Mysql: Banco de dados free com suporte a múltiplas linguagens; • MsProject 2010: Ferramenta case que auxilia na gerência das atividades do projeto; • Editor de texto Word: Realizar a documentação do projeto; • Subversion: Ferramenta para controlar as versões de software produzidas. Para a composição física do projeto, utilizaremos dois microcomputadores emrede local com todos os recursos de software descritos para o desenvolvimento doprojeto.Plano de Projeto de Software Página 7
  • 8. 3. ANÁLISE E GESTÃO DE RISCOS Esta etapa consiste em uma série de passos que permitem compreender egerir as incertezas que podem ocorrer. Dessa forma, quanto aos riscos, precisamosidentificá-los, avaliar sua probabilidade de ocorrência e estimar o seu impacto noprojeto de software para que possamos estar preparados para administrá-los.3.1 Riscos do Projeto Relacionamos os riscos envolvidos no projeto de acordo com a sua categoria.Na Tabela 3 podemos visualizar esta ligação. Riscos Projeto Técnico Negócio Comum EspecialRequisitos incompletos x xTreinamento xMudança no cronograma para entrega x xRotatividade da equipe xMudança da tecnologia adotada x xRegras de negócio não foram definidas x Tabela 3. Riscos Gerais do Projeto Avaliação global dos riscos: 1. O Gerente de software dá suporte ao projeto? Sim, o gerente é um dos participantes diretos no desenvolvimento do projeto 2. Os clientes estão entusiasmados com o projeto e o produto? Sim, eles buscam sempre saber mais informações e ficam no desejo de veralgo pronto o quanto antes. 3. A equipe de desenvolvimento compreende bem os requisitos? Sim, uma vez que, todos participaram do processo de elicitação e análise dosrequisitos definidos 4. Os clientes estiveram envolvidos na definição dos requisitos? Sim, esta etapa foi realizada com todos os membros da equipe dedesenvolvimento, os clientes da Prefeitura e contou com a presença do mediadorEdson.Plano de Projeto de Software Página 8
  • 9. 5. Os requisitos do projeto são estáveis? Sim, e também são baseados em uma versão anterior do sistema chamadoSistema de Controle de Serviços – SisCon, haverá apenas a modificação de ambiente,usabilidade e performance do sistema. 6. A equipe de desenvolvimento tem experiência na tecnologia a implementar? Os membros já trabalharam juntos em projetos anteriores, mas, com outrastecnologias. 7. É adequado o número de pessoas da equipa de trabalho? De acordo com as métricas utilizadas não, pois, precisaríamos de mais um oudois membros, mas, a equipe já se conhece e sabe o quê e como pode realizar asatividades do projeto.3.2 Tabela de Riscos Para a elaboração da Tabela de Riscos, durante a reunião de brainstorming,cada membro do grupo relacionou os possíveis riscos existentes no projeto. Na faseseguinte atribuímos uma probabilidade de ocorrência e o grau de impacto para cadarisco catalogado. Feito isto, juntamos as listas e realizamos uma análise circular dos riscos o quegerou a Tabela 4, abaixo.Nº Riscos Categoria Prob. Impacto Razoabilidade do prazo de entrega 1 Negócio 75% Catastrófico Dúvidas sobre o que a 2 funcionalidade solicitada é capaz de fazer Tecnológico 75% Catastrófico Ferramentas são integradas com o outro 3 sistema Processo 75% Catastrófico Tamanho estimado do produto em número 4 de programas Tamanho 50% Critico Você já trabalhou com o cliente no passado 5 Cliente 90% Marginal Utilização de novos métodos de 6 engenharia de software Tecnológico 75% Marginal Quadro de processo comum estabelecido 7 Processo 30% Marginal Número de mudanças projetadas para as 8 exigências do produto Tamanho 25% Marginal Tabela 4. Riscos do ProjetoPlano de Projeto de Software Página 9
  • 10. 3.3 Estratégias para Gestão de Riscos Para as estratégias de redução, supervisão e gestão dos riscos (RSGR)identificados, foram selecionados os principais. São eles: 1. Razoabilidade do prazo de entrega; 2. Dúvidas sobre o que a funcionalidade solicitada é capaz de fazer; 3. Ferramentas são integradas com outros sistemas; 4. Tamanho estimado do produto em número de programas; 5. Você já trabalhou com o cliente no passado; 6. Utilização de novos métodos de engenharia de software. 1. Razoabilidade do prazo de entrega Risco: 2 Probabilidade: 75% Impacto: Catastrófico Descrição: Este risco se refere ao prazo estimado que foi calculado, através das métricas, e o prazo real de entrega do produto para o cliente. Estratégia de redução: Realizar reuniões semanais com o Professor Edson e reuniões mensais com o cliente afim de possibilitar a detecção de erros o quanto antes para a devida correção. Plano de contingência: Alterar planejamento e negociar novos prazos Responsável: Tiago Lahan Status: Em Andamento Tabela 5. Gestão de Riscos 1 2. Dúvidas sobre o que a funcionalidade solicitada é capaz de fazer Risco: 7 Probabilidade: 75% Impacto: Catastrófico Descrição: Este risco reflete sobre as dúvidas existentes ao longo do desenvolvimento, tais como funcionalidades do sistema, perfis de usuários e modos de acesso. Estratégia de redução: Minimizar ao máximo as incertezas de projeto através de reuniões de brainstorming e entrevistas com o cliente final e documentar tais atividades. Plano de contingência: Realizar novas reuniões só para tirar dúvidas e manter contato através de email e telefone. Responsável: Tiago Lahan Status: Concluído Tabela 6. Gestão de Riscos 2Plano de Projeto de Software Página 10
  • 11. 3. Ferramentas são integradas com outros sistemas Risco: 3 Probabilidade: 75% Impacto: Catastrófico Descrição: Este risco se refere ao fato do SGS se integrar ao sistema SIE, já existente, a outras ferramentas e como essa integração será realizada. Estratégia de redução: Contatar os responsáveis pelo sistema SIE para reuniões sobre integração para tirar as dúvidas existentes. Plano de contingência: Pesquisar modos de integração e ferramentas para realizar estas atividades. Responsável: Rafael Almeida Status: Em Andamento Tabela 7. Gestão de Riscos 3 4. Tamanho estimado do produto em número de programas Risco: 4 Probabilidade: 50% Impacto: Crítico Descrição: Este risco se refere a quantidade de módulos necessários ao desenvolvimento do sistema. Estratégia de redução: Determinar o escopo do projeto na fase de Análise e, segui-lo prontamente ao longo do desenvolvimento Plano de contingência: Limitar as funcionalidades extras, sem perder o escopo proposto Responsável: Tiago Lahan, Rafael Almeida Status: Concluído Tabela 8. Gestão de Riscos 4 5. Você já trabalhou com o cliente no passado Risco: 5 Probabilidade: 90% Impacto: Marginal Descrição: Este risco se refere a falta de conhecimento da equipe de desenvolvimento com relação ao cliente Estratégia de redução: Realizar reuniões periódicas para tirar dúvidas e conhecer o cliente através de técnicas de engenharia de software Plano de contingência: Manter contato com o cliente através de telefone, email e reuniões periódicas Responsável: Tiago Lahan Status: Concluído Tabela 9. Gestão de Riscos 5Plano de Projeto de Software Página 11
  • 12. 6. Utilização de novos métodos de engenharia de software Risco: 5 Probabilidade: 75% Impacto: Marginal Descrição: Este risco se refere a utilização de novos métodos para o desenvolvimento do projeto, desde ferramentas case à linguagem de programação Estratégia de redução: Estudar a linguagem proposta através de cursos, vídeos-aula e leitura em tutoriais próprios Plano de contingência: Utilização de plugins que facilitem o desenvolvimento Responsável: Rafael Almeida Status: Em Andamento Tabela 10. Gestão de Riscos 6Plano de Projeto de Software Página 12
  • 13. 4. PLANEJAMENTO TEMPORAL No Planejamento Temporal são definidas as datas de execução das tarefasassim como, os responsáveis por cada uma delas através do Diagrama de Ganttelaborado pelo Gerente do Projeto.4.1 Conjunto de Tarefas do Projeto Tarefas Porcentagem Dias de trabalho Planejamento 3% 21 Análise de Requisitos e Modelagem 40 % 280 Codificação 20 % 140 Testes 37 % 259 Tabela 11. Dias por Tarefa4.2 Diagrama de Gantt Na Tabela 12, visualizamos o Diagrama de Gantt com as atividades de acordocom o processo de software. Para este projeto utilizamos metodologia dedesenvolvimento ágil por ter sido desenvolvido no framework Grails. Figura 11. Diagrama de GanttPlano de Projeto de Software Página 13
  • 14. 5. ORGANIZAÇÃO DO PESSOAL Cada membro da equipe possui as suas atribuições e deveres bem definidos,assim, cada um sabe qual tarefa deve ser realizada e até onde ele pode fazer. Asdecisões serão tomadas em conjunto com todos os stakeholders do projeto.5.1 Estrutura da equipe • Gerente de Projeto: Sua função é gerenciar o progresso do empreendimento e através das variáveis (qualidade, custo, prazo e âmbito) verificar seus desvios. Desta forma, seu objetivo geral é minimizar as falhas inerentes aos processos. Responsável: Tiago Lahan • Analista de Sistema: estudam os diversos sistemas existentes entre hardwares (equipamentos), softwares (programas) e o usuário final. Responsável: Rafael Almeida • Projetista de software: mapear as estruturas e funcionalidades identificadas na análise de requerimentos dentro do contexto e das restrições da arquitetura. Responsável: Rodrigo Azevedo • Testador: Faz a investigação do software a fim de fornecer informações sobre sua qualidade em relação ao contexto em que ele deve operar. Isso inclui o processo de utilizar o produto para encontrar seus defeitos. Responsável: Rodrigo Azevedo5.2 Mecanismos de comunicação Para um melhor gerenciamento do projeto como um todo, a equipe estabelececomunicação direta entre seus membros e, cliente. Dessa forma, além do contatointerpessoal ser fortificado a relação existente aumenta a facilidade com que oproblema é entendido. A monitorização do projeto se dará por reuniões periódicas entre os membrosda equipe e, a cada etapa do processo de desenvolvimento (Planejamento, Análise dePlano de Projeto de Software Página 14
  • 15. Requisitos, Codificação, Testes) é feita uma avaliação dos resultados obtidos parapossíveis correções e adequação das etapas em cada nível do projeto.5.3 Uso do Edu-blog como ferramenta de apoio Achamos o Edu-blog uma excelente ferramenta de apoio à disciplina, pois éfácil e agradável de utilizar. Permite ao professor disponibilizar todo o materialreferente à 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. A utilização do Edu-blog como ferramenta que auxilie no compartilhamento deinformações é importante, pois cria um canal fixo de comunicação entre todas asequipes, permitindo um local onde todos possam acessar e pesquisar assuntos quepossam enriquecer o trabalho individual.Plano de Projeto de Software Página 15

×