Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Plano deprojeto grupo1

480 views

Published on

Planejamento para desenvolvimento de um jogo de simulação para casos emergenciais que ocorrem no HU,

Published in: Technology
  • Login to see the comments

  • Be the first to like this

Plano deprojeto grupo1

  1. 1. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO GERENCIA DE PROJETOS 2015.2 Plano de Projeto de Software para produtos Lacertae SW Grupo 1: Gilcley de Carvalho Silva Helder Araújo Filho Iúri Batista Teles Jessica Profeta da Silveira 11 de fevereiro de 2016, São Cristóvão.
  2. 2. Conteúdo 1.0 INTRODUÇÃO............................................................................................................3 1.1 Âmbitos do Projeto................................................................................................3 1.2 Funções principais do produto de software.............................................................3 1.3 Requisitos comportamentais ou de performance ....................................................3 1.4 Gestão e Restrições Técnicas .......................................................................................4 2.0 ESTIMAÇÕES DO PROJETO...............................................................................................4 2.1 Dados históricos utilizados para as estimações .............................................................5 2.2 Técnicas de estimação e resultados..............................................................................5 2.2.1 Técnica de estimação............................................................................................5 2.4 Recursos do projeto....................................................................................................7 3.1 Riscos do projetoidentificados durante o Brainstorm em sala de aula............................9 3.2 Tabelas de riscos.......................................................................................................10 3.3 Redução e Gestão do Risco........................................................................................11 4.0 PLANEJAMENTO TEMPORAL..........................................................................................15 5.0 ORGANIZAÇÃO DO PESSOAL..........................................................................................16 5.1 Estrutura da equipe...................................................................................................16 5.1.1 Gerente de Projetos............................................................................................16 5.1.2 Analista de Sistemas ...........................................................................................16 5.1.3 Administrador de Banco de Dados.......................................................................16 5.1.4 Analista de Testes...............................................................................................17 5.2 Mecanismos de comunicação ....................................................................................17 5.3 Usos do Edu blog como ferramenta de apoio..............................................................17 6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SW ....................................................................................................................................18 AnexoA - Diagramas de Classes de Domínio ........................................................................20
  3. 3. 1.0 INTRODUÇÃO 1.1 Âmbitos do Projeto O Diagnosticus Action é um jogo de simulações de casos emergenciais que ocorre no Hospital Universitárioda Universidade Federal de Sergipe. Este software tem como objetivo treinar e avaliar os alunos sem colocar em risco a vida dos pacientes. Desta forma, ter uma forma lúdica de ensino-aprendizagem. O cerne do software consiste em como diagnosticar e tratar um paciente. Para realizar um diagnósticoé necessáriodaAnamnese (técnicade entrevista realizada pelos profissionais da saúde),Exame Clinicoe Exame Laboratorial. Dessa forma, esses elementos servirão como dados de entrada e o diagnóstico será o dado de saída. Existem dois perfis para acesso ao sistema: o perfil aluno e o perfil professor. O perfil professorseráresponsávelporcriaro jogoe definirtempopara jogada com relação aos dados da Anamnese e dosExames.Jáo perfil aluno deverá resolver o problema proposto dando um diagnóstico e um tratamento para o paciente através dos dados que foram parametrizados pelo professor. 1.2 Funções principais do produto de software As funcionalidades e seus respectivos usuários serão listados na tabela 1 abaixo: Funcionalidade Usuário Cadastrar Usuário Professor Cadastrar Caso Emergencial Professor Cadastrar Diagnóstico Professor Cadastrar uma Simulação Professor Cadastrar uma Turma Professor Jogar Simulação Aluno Gerar Relatório dos Resultados Professor Editar perfil de Usuário Professor e Aluno Tabela 1- Principais Funcionalidades 1.3 Requisitos comportamentais ou de performance Para melhoratenderaosseususuárioso DiagnosticusAction dispõe dosseguintes requisitos:
  4. 4. a. Usabilidade:  Usuáriospoderãooperaro sistema e conseguir atingir os objetivos do jogo sem dificuldades no uso. b. Confiabilidade:  O sistema deverá operar sem falhas durante o tempo de execução. c. Segurança:  O sistema não deve permitir o acesso de pessoas não autorizadas. d. Disponibilidade:  O sistema deverá estar disponível 24horas por dia, todos os dias da semana. 1.4 Gestão e Restrições Técnicas Temos as seguintes restrições Técnicas: a. A linguagem de programação deverá ser Java. b. O Sistema de Gerenciamento de Banco de Dados deverá ser o PostgreSQL. c. Para ter acesso ao sistema o computador deverá estar conectado à Internet. d. O framework utilizado para o desenvolvimento do sistema deverá ser o Hibernate. 2.0 ESTIMAÇÕES DO PROJETO O projetoDiagnosticusAction apresentamumametrificação e rastreamento proposto pela Lacertae SW, que foram analisados a partir de estudo e histórico de caso apresentado anteriormente. Para o desenvolvimento do sistema foi feita uma metrificação a partir do conceitodefinidoporLorenz& Kiddoqual apresentaumaperspectivaque maisse adeque aos recursos, e necessidades do projeto que é Orientado a Objetos. Tendo em vista uma análise
  5. 5. baseada no esforço que cada componente irá desempenhar no projeto. Nessa seção, iremos explanar o resultado visando à estimação temporal do projeto. 2.1 Dados históricos utilizados para as estimações A equipe predefinida para execução do projeto apresenta experiência passada em desenvolvimentode sistemas.Desse modoé possível aproveitar tais experiências, bem como análise de casode projetossemelhantes.Umexemplo é o caso do projeto Paciente Virtual ao qual um dosparticipantesdoplanejamentodoprojetoteve aoportunidade de participar. Fato esse que ajudou no norteamento das métricas temporais do projeto em si. 2.2 Técnicas de estimação e resultados A técnica de estimação utilizada foi a Lorenz & Kidd que têm como base o cálculo quantitativo de alguns aspectos fundamentais da Orientação a Objetos, como os atributos e serviços, herança, coesão e acoplamento. 2.2.1 Técnica de estimação A técnica de estimação de Lorenz & Kidd é apresentada da seguinte forma: Uma classificação dos tipos de interface e assim é atribuído um valor correspondente para as classes chave do projeto. Os tipos são: Não gráfica, baseada em texto, GUI e GUI complexa. Após a categorização das classes, os pesos irão definir de acordo com a seguir, o qual irá caracterizar o fator multiplicador. Interface Multiplicador Não gráfica 2 Baseada em texto 2,25 GUI 2,5 GUI complexa 3,0 Tabela 2 - Pesos de cada categoria de classe Desse modo conseguimos definir uma margem para as classes de suporte o qual o projeto poderá necessitar. O qual irá ser o somatório das classes chave vezes o seu multiplicador. Ficando definido com a equação final a seguir: Classes de suporte = ∑(número de classes chave X peso)
  6. 6. Uma vez definida as classes que irão dar suporte as classes chave temos a oportunidade de estimar a quantidade de dias necessários para o desenvolvimento da aplicação, considerando que cada classe irá ter um fator multiplicador de 15 a 20, o qual irá dependerde fatorescomo:experiênciadaequipe e objetos reutilizáveis da biblioteca. O que define uma media empírica por pessoa/dia para o desenvolvimento de cada classe. Total dias = Classes de suporte X (15~20) Foram identificadas 15 classes chave, como mostrado no Anexo A, das quais:  14 são GUI (multiplicador 2,5)  1 é GUI complexa (multiplicador 3,0) Após a estimação do projeto, dividido o tempo com a seguinte perspectiva: Etapa Estimativa Planejamento 2-3% Requisito-Análise-Desenho 40% Geração de código 20% Testes 40% Tabela 3 – Perspectiva de estimação temporal Assim temos: Classes de suporte = (14 * 2,5) + (1 * 3,0) + 15 Classes de suporte = 53 Obtendo assim, um total de 53 classes (chave e suporte), e considerando o nível de experiênciadaequipe utilizamosumamétricamultiplicadorade 15 por classe, uma vez que os componentes possuem familiaridade sobre as ferramentas a serem utilizadas no projeto. O que terminamos por identificar: Total de dias = 53 * 15 Total de dias = 795
  7. 7. Considerando que a equipe é composta por 4 componentes podemos definir que o projeto irá ter aproximadamente 200 dias para o seu desenvolvimento. Levado em consideração 22 dias úteis por mês e a quantidade de componentes envolvidosnoprojeto,podemosconsiderarumtempoprevistode 9meses para finalização do projeto. Tempo previsto = dias por pessoa / dias uteis no mês Tempo previsto = 200 / 22 Tempo previsto = 9 meses De acordo com a distribuição de esforços podemos definir os seguintes dados: Etapa Estimativa Dias de trabalho Planejamento 3% (200 * 3%) = 6 dias Requisito-Análise-Desenho 40% (200 * 40%) = 80 dias Geração de código 20% (200 * 20%) = 40 dias Testes 37% (200 * 37%) = 74 dias Tabelas 4 - Estimativas de cada etapa do projeto 2.4 Recursos do projeto 2.4.1 Recursos humanos  1 Gerente de projetos  1 Analista de sistemas  1 Administrador de Banco de Dados  1 Analista de teste  2 Stackholders 2.4.2 Recursos de software O conjunto de software irá se basear em ambiente de desenvolvimento Web. Necessitando assim de integração e instalação dos seguintes recursos de software:
  8. 8.  Ambiente para desenvolvimento Java (Eclipse IDE)  Software de Banco de Dados (PostgreSQL)  Framework Hibernate  Apache Tomcat 7.0  StarUML  Trello  SVN 2.4.3 Recursos hardware O projeto irá ter uma estrutura base de 4 estações de trabalho com as seguintes configurações:  Processador core i5 2 gen. de 2.8 GHz ou superior  4 GB de memória RAMou superior  250 GB de armazenamento ou superior  Monitor de 15.5” ou superior 2.4.4 Ferramentas de apoio  Sala climatizada  Suprimentos de suporte (lanches, agua)  Conexão estável com internet 2 MB ou superior  Mesas e cadeiras Ergonômicas
  9. 9. 3.0 ANÁLISE E GESTÃO DE RISCOS O risco é um problemaempotencial, podendoocorrer ou não. É sempre aconselhável que haja umaidentificação deles,alémde umaavaliaçãodas suasprobabilidadesde acontecer e dosseusimpactos.Tambémse deve estabelecerumplano de contingência caso o problema realmente ocorra. 3.1 Riscos do projeto identificados durante o Brainstorm em sala de aula. Número Risco Tipo 01 Má qualidade dos componentes desenvolvidos Gerais 02 Mais utilizadores do que o previsto Únicos 03 Mudança dos Requisitos Gerais 04 Não atender aos prazos especificados Gerais 05 Servidor de aplicação estar indisponível Únicos 06 Seguimento das regras de negócio Gerais 07 Processo comum de utilização Gerais 08 Ter um controle de qualidade Gerais 09 Testes não efetivos Gerais 10 Inexperiência dos integrantes da equipe Únicos 11 Numero de pessoas na equipe Gerais 12 Quantidade e Qualidade da documentação do produto que deve ser produzido e entregue Gerais 13 Participação do cliente na revisão dos requisitos Gerais 14 Proativa técnica de revisão Gerais 15 Documentação sem muitas informações sobre o sistema. Gerais 16 Cliente entusiasmado com o produto Gerais 17 Ferramenta para integrar o time Gerais Tabela 5- Tabela de riscos encontrados
  10. 10. 3.2 Tabelas de riscos Número Risco Categoria Probabilidade Impacto 01 Má qualidade doscomponentes desenvolvidos Desenvolvimento 20% 5 02 Mais utilizadores do que o previsto Pessoal 90% 4 03 Mudança dos Requisitos Desenvolvimento 80% 4 04 Não atender aos prazos especificados Especial 50% 4 05 Servidor de aplicação estar indisponível Desenvolvimento 30% 4 06 Seguimento das regras de negócio Especial 20% 4 07 Processo comum de utilização Especial 70% 3 08 Ter um controle de qualidade Especial 70% 3 09 Testes não efetivos Desenvolvimento 50% 3 10 Inexperiência dos integrantes da equipe Pessoal 50% 3 11 Numero de pessoas na equipe Pessoal 50% 3 12 Quantidade e Qualidade da documentação do produto que deve ser produzido e entregue Desenvolvimento 30% 3 Linha de Corte 13 Participação do cliente na revisão dos requisitos Cliente 10% 3 14 Proativa técnica de revisão Desenvolvimento 70% 2 15 Documentação sem muitas informações sobre o sistema. Desenvolvimento 30% 2 16 Cliente entusiasmado com o produto Cliente 30% 2 17 Ferramenta para integrar o time Pessoal 10% 1
  11. 11. 3.3 Redução e Gestão do Risco Neste tópico demonstraremos ações que devem ser tomadas para prever, reduzir ou gerir os riscos identificados. Risco: 01 Probabilidade:20% Impacto: 5 Descrição: Má qualidade doscomponentesdesenvolvidos. Estratégia de redução: Estabelecerumaarquiteturade software e adotarpadrõesparao desenvolvimento. Plano de contingência:Analisare melhoraroscomponentes, verificandoaestruturado código. Pessoaresponsável:GilcleySilva. Status: Em análise Risco: 02 Probabilidade: 90% Impacto: 4 Descrição: Mais utilizadores do que o previsto. Estratégia de redução: Analisarprobabilidade de aumentaronúmerode servidores. Plano de contingência: Buscar soluções distribuídas. Pessoaresponsável:GilcleySilva. Status: Em Análise. Risco: 03 Probabilidade:80% Impacto: 4 Descrição: Mudança dos Requisitos.
  12. 12. Estratégia de redução: Agendarreuniõesparadefinir ouatualizarosrequisitos. Plano de contingência:Documentare homologarosrequisitoscomousuário,antesde iniciaro desenvolvimento. Pessoaresponsável:GilcleySilva. Status: Em andamento. Risco: 04 Probabilidade:50% Impacto: 4 Descrição: Não atenderaosprazosespecificados. Estratégia de redução: Monitoraro andamentodoprojetoverificandose osprazosestão sendorespeitados. Plano de contingência:Definirprioridades de entregas doque deveriaobrigatoriamente ter sidoentregue até ofinal dopróximoprazo. Pessoaresponsável:HelderFilho. Status: Em andamento. Risco: 05 Probabilidade:30% Impacto: 4 Descrição: Servidorde aplicação estarindisponível. Estratégia de redução: Utilizarumservidorcomuma altataxa de disponibilidade,além de monitoraro estadodo servidorde aplicação. Plano de contingência:Utilizarde replicaçãodoservidor. Pessoaresponsável:HelderFilho. Status: Monitorando.
  13. 13. Risco: 06 Probabilidade:20% Impacto: 4 Descrição: Seguimentodas regrasde negócio. Estratégia de redução: Acompanharoandamentodoprojetopara verificarse asregras de negócioestãosendoseguidas. Plano de contingência:Reuniros integrantesdoprojetoparaque hajaesclarecimentos sobre as regras de negócio,mostrandooserrosjá cometidose exemplificandocomoo processodeve serexecutado paraque oserrosnão maisocorram. Pessoaresponsável:HelderFilho. Status: Em andamento. Risco: 07 Probabilidade:70% Impacto: Moderado Descrição: Quadrocomum de processosde. Estratégia de redução: Desenvolverpadrõesde processosde negócio Plano de contingência:Criação de organogramase modelagemde processosde negócio. Pessoaresponsável:Iúri BatistaTeles. Status: Em andamento. Risco: 08 Probabilidade:70% Impacto: Moderado Descrição: Ter um controle de qualidade. Estratégia de redução: Analise docódigo,revisão,e validação. Plano de contingência:Criar rotinasde testes,validaçãode implementaçãoe adiçãode funcionalidades. Pessoaresponsável:Iúri BatistaTeles.
  14. 14. Status: Monitorando. Risco: 09 Probabilidade: 50% Impacto: Moderado Descrição: Testes não serem efetivos. Estratégia de redução: Identificar novas estratégias de processos de testes e treinamentos. Plano de contingência: Qualificar testadores. Pessoa responsável: Iúri Batista Teles. Status: Em análise. Risco: 10 Probabilidade:50% Impacto: Moderado Descrição: Inexperiênciadosintegrantesdaequipe comatecnologiautilizada. Estratégia de redução: Solicitarque desenvolvedoresexperientesajudemaoscolegas inexperientes. Plano de contingência:Disponibilizarparaequipe cursos,treinamentos,semináriosdas tecnologiasutilizadas. Pessoaresponsável:JéssicaSilveira. Status: Buscandomaterial. Risco: 11 Probabilidade:50% Impacto: Moderado Descrição: Quantidade insuficientede pessoas de pessoasnaequipe. Estratégia de redução: Aumentarosprazosde entregado produto. Plano de contingência:Contratar estagiáriose programadoresparaequipe.
  15. 15. Pessoaresponsável:JéssicaSilveira. Status: Efetuandopesquisade mercadoporrecursoshumanosespecializados. Risco: 12 Probabilidade:30% Impacto: Moderado Descrição: Ausênciaquantidadee qualidadedadocumentaçãodoprodutoque deve ser produzidoe entregue. Estratégia de redução: Solicitar aos engenheiros de software que revisem a documentação já produzida e decidam se a mesma está seguindo as convenções da metodologia de desenvolvimento daquele projeto (ágil, cascata, etc.). Plano de contingência: Realizar treinamentos direcionados a equipe de desenvolvimento,visandoeducá-losquanto àqualidadedadocumentação, e como fazê- la de forma eficiente, de acordo com a metodologia de projeto a ser seguida. Incluir políticas de documentação. Pessoaresponsável:JéssicaSilveira. Status: Monitorandoo projeto. 4.0 PLANEJAMENTO TEMPORAL Este item foi trocado por uma prospecção tecnológica para apoiar o planejamento do SAP DCOMP/PROCC 2015-2020.
  16. 16. 5.0 ORGANIZAÇÃO DO PESSOAL Nestaseçãoiremos apresentaradistribuiçãodosrecursoshumanose afunção de cada papel dentro deste projeto. 5.1 Estrutura da equipe A equipe é estruturada da seguinte maneira: Papel Responsável Gerente de Projetos JessicaProfetadaSilveira Analista de Sistemas Iúri Batista Teles Administrador de Banco de Dados Gilcleyde CarvalhoSilva Analista de Testes HelderAraújoFilho Tabela 6- Estrutura da Equipe 5.1.1 Gerente de Projetos Responsável pelo planejamento do projeto, controle da execução e supervisão do projeto. 5.1.2 Analista de Sistemas Responsável por analisar e desenvolver sistemas, mapear processos, fazer a modelagem de dados e levantar os requisitos para desenvolvimento do Diagnosticus. 5.1.3 Administrador de Banco de Dados Responsável por gerenciar, instalar, configurar, atualizar e monitorar o sistema de banco de dados do Diagnosticus.
  17. 17. 5.1.4 Analista de Testes Responsável por planejar e executar casos de testes com intuito de garantir a qualidade do Diagnosticus. 5.2 Mecanismos de comunicação Para manter o controle e a comunicação da equipe nós utilizamos o Slack. O Slack é um software de comunicaçãode equipescomsuporte acanais,conversasprivadas,integração com serviçosexternos.Alémdisso,ele possuium botde comunicação:o slackbot.Ele funciona como um usuário programado com auto mensagens para proporcionar maior interação na plataforma e também para lembrar as metas periodicamente, podendo ser configurado para efetuar as perguntas clássicas de alguma metodologia. Já para monitoração do avanço do projeto nos utilizaremos dois artifícios: reuniões periódicase acompanhamentodostatusdo projeto através da ferramenta de gerenciamento de projeto:Trello.Asreuniõesperiódicasservemparatrocar informaçõessobre oque foi feito, do que está sendo feito e do que será feito, com a finalidade de melhoria contínua do andamento do projeto. Iremosadotaro Trellocomo ferramenta de gerenciamento de projetos. Com ela será possível acompanhar em tempo real as mudanças no status do projeto, verificar o avanço da equipe no projeto e equiparar se as metas estão sendo atingidas de acordo com os prazos estabelecidos. 5.3 Usos do Edu blog como ferramenta de apoio Com o Edu Blog como ferramenta de apoio o ensino não ficou limitado apenas á sala de aula. Graças a esta ferramenta foi possível promover um maior aprofundamento do que deveria ser estudado e uma maior interação não só com a turma, mas também com todo o mundo e desta forma quebrar todas as barreiras regionais. As trocas de informações e discussões geradas enriqueceram o nosso conhecimento. Além disso, foi possível ajudar á comunidade uma vez que fizemos várias analises e alguns
  18. 18. comparativos e assim facilitar a vida das pessoas que pesquisaram sobre alguma de nossas postagens. 6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SW Assegurar e controlar a qualidade do produto de software necessita que sejam tomadas precauções. Desta forma, definiremos abaixo as medidas que devem ser seguidas para garantir a qualidade do produto. Acompanhamento das atividades desenvolvidas Será realizadoumacompanhamentoconstantedasatividadesdesenvolvidas por parte de todos os envolvidos no projeto. Produção de documentação Serãoproduzidosdocumentosaodecorrer de todo o ciclo de vida do software, sendo atualizados sempre que houver alguma alteração no produto. Testes Durante todo o ciclo de vida do software ocorrerão testes, desde o levantamento de requisitos até possíveis manutenções no produto depois de ele ter sido entregue, serão efetuados testes de caráter abrangente e/ou específicos, sejam eles de caixa preta ou caixa branca. Revisões Técnicas Formais
  19. 19. As revisões são realizadas na etapa de Análise e Projeto, visando à identificação de erros nas fases iniciais do projeto, onde o custo para a manutenção é menor. Medições Métricas serão adotadas para identificar características do software e ter noção se os requisitos estão consistentes e completos.
  20. 20. Anexo A - Diagramas de Classes de Domínio

×