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

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. 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. 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. 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. 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. 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. 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.  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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Anexo A - Diagramas de Classes de Domínio