Plano deprojeto grupo1

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.

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 projeto................................................................................................................. 9
3.2 Tabelas de riscos ............................................................................................................... 10
3.3 Redução e Gestão do Risco............................................................................................... 11
4.0 ORGANIZAÇÃO DO PESSOAL ................................................................................................. 15
4.1 Estrutura da equipe........................................................................................................... 15
4.1.1 Gerente de Projetos ................................................................................................... 16
4.1.2 Analista de Sistemas................................................................................................... 16
4.1.3 Administrador de Banco de Dados............................................................................. 16
4.1.4 Analista de Testes....................................................................................................... 16
4.2 Mecanismos de comunicação........................................................................................... 16
4.3 Usos do Edu blog como ferramenta de apoio................................................................... 17
5.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE
SW ............................................................................................................................................... 17
Anexo A - Diagramas de Classes de Domínio.............................................................................. 19

1.0 INTRODUÇÃO
1.1 Âmbitos do Projeto
O Diagnosticus Action é um jogo de simulações de casos emergenciais que ocorrem no
Hospital Universitário da 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íamos 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ário da anamnese (técnica de entrevista realizada pelos profissionais da
saúde), exame clinico e exame laboratorial. Dessa forma esses elementos servirão como dados
de entrada e diagnostico será o dado de saída.
Existem dois perfis para acesso ao sistema: o perfil aluno e o perfil professor. O perfil
professor será responsável por criar o jogo e definir tempo para jogada com relação aos dados
da anamnese. 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 melhor atender aos seus usuários o Diagnosticus Action dispõe dos seguintes requisitos:

a. Usabilidade:
 Usuários poderão operar o sistema e conseguir atingir os objetivos do
jogo sem dificuldades no uso.
 O sistema deve disponibilizar somente informações necessárias para o
usuário, possibilitando o usuário atingir seus objetivos.
b. Confiabilidade:
 O sistema deve 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 projeto Diagnosticus Action apresentam uma metrificaçã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
conceito definido por Lorenz & Kidd o qual apresenta uma perspectiva que mais se adeque aos
recursos, e necessidades do projeto. Tendo em vista uma análise baseada no esforço que cada

componente irá desempenhar no projeto. Nessa seção iremos explanar o resultado visando a
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
desenvolvimento de sistemas. Desse modo é possível aproveitar tais experiências, bem como
analise de caso de projetos semelhantes. Um exemplo é o caso do projeto Paciente Virtual ao
qual um dos participantes do planejamento do projeto teve a oportunidade 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)

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á depender de fatores como:
experiência da equipe 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ência da equipe utilizamos uma métrica multiplicadora de 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

Considerando que a equipe é composta por 4 componentes podemos definir que o
projeto irá ter empiricamente 200 dias para o seu desenvolvimento.
Levado em consideração 22 dias uteis por mês e a quantidade de componentes
envolvidos no projeto, podemos considerar um tempo previsto de 9 meses 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
Tabela 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:

 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 RAM ou 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ômica

3.0 ANÁLISE E GESTÃO DE RISCOS
O risco é um problema em potencial, podendo ocorrer ou não, sendo sempre
aconselhável que haja uma identificação destes, além de uma avaliação de suas probabilidades
de acontecer, o impacto e também se deve estabelecer um plano de contingência caso o erro
realmente ocorra.
3.1 Riscos do projeto
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 estar indisponível Únicos
06 Seguimento das diretrizes 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 risco

3.2 Tabelas de riscos
Número Risco Categoria Probabilidade Impacto
01 Má qualidade dos componentes
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 estar indisponível Desenvolvimento 30% 4
06 Seguimento das diretrizes 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
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.
16 Cliente entusiasmado com o
produto
Cliente 30% 2
17 Ferramenta para integrar o
time
Pessoal 10% 1

3.3 Redução e Gestão do Risco
Risco: 01 Probabilidade: 20% Impacto: 5
Descrição: Má qualidade dos componentes desenvolvidos.
Estratégia de redução: Analisar e melhorar os componentes.
Plano de contingência: Estabelecer uma arquitetura de software e adotar padrões para o
desenvolvimento.
Pessoa responsável: Gilcley Silva.
Status: Em análise
Descrição: Mais utilizadores do que o previsto.
Estratégia de redução: Limitar o número de acessos simultâneos.
Plano de contingência: Aumentar o número de servidores.
Status: Em Análise.
Descrição: Mudança dos Requisitos.
Estratégia de redução: Agendar reuniões para definir os requisitos.
Plano de contingência: Validação dos requisitos com o usuário antes de iniciar o
desenvolvimento.

Status: Em andamento.
Descrição: Não atender aos prazos especificados.
Estratégia de redução: Marcar reuniões para que haja um acompanhamento do que está
sendo feito em relação ao tempo previsto.
Plano de contingência: Definir prioridades do que deve obrigatoriamente ser entregue
até o final do próximo prazo.
Pessoa responsável: Helder Filho.
Descrição: Servidor de o software estar indisponível.
Estratégia de redução: Utilizar um servidor que seja confiável.
Plano de contingência: Ter outros servidores online que assumam o serviço caso um
servidor fique indisponível.
Status: Monitorando.
Descrição: Seguimento das diretrizes.
Estratégia de redução: Marcar reuniões para acompanhar esse seguimento.

Plano de contingência: Reestabelecer novas diretrizes de forma clara e objetiva,
juntamente com um acompanhamento para que elas sejam seguidas.
Risco: 07 Probabilidade: 70% Impacto: Moderado
Descrição: Quadro comum de processos.
Estratégia de redução: Desenvolver padrões de processos.
Plano de contingência: Criação de organogramas, e modelagem de processos de
negócio.
Pessoa responsável: Iúri Batista Teles.
Descrição: Ter um controle de qualidade.
Estratégia de redução: Analise do código, revisão, e validação.
Plano de contingência: Criar rotinas de testes, validação de implementação e adição de
funcionalidades.
Status: Monitorando.
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.
Status: Em análise.
Descrição: Inexperiência dos integrantes da equipe com a tecnologia utilizada.
Estratégia de redução: Solicitar que desenvolvedores experientes ajudem aos colegas
inexperientes.
Plano de contingência: Disponibilizar para equipe cursos, treinamentos, seminários das
tecnologias utilizadas.
Pessoa responsável: Jéssica Silveira.
Status: Buscando material.
Descrição: Numero de pessoas na equipe.
Estratégia de redução: Aumentar os prazos de entrega do produto.
Plano de contingência: Contratar mais pessoas para equipe.
Status: Efetuando pesquisa de mercado por recursos humanos especializados.

Descrição: Quantidade e Qualidade da documentação do produto que deve ser
produzido e 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,
visando educá-los quanto a qualidade de documentação, e como fazê-la de forma
eficiente, de acordo com a metodologia de projeto a ser seguida.
Status: Monitorando o projeto.
4.0 ORGANIZAÇÃO DO PESSOAL
Nesta seção iremos apresentar a distribuição dos recursos humanos e a função de cada
papel dentro deste projeto.
4.1 Estrutura da equipe
A equipe é estruturada da seguinte maneira:
Papel Responsável
Gerente de Projetos Jessica Profeta da Silveira
Analista de Sistemas Iúri Batista Teles
Administrador de Banco de Dados Gilcley de Carvalho Silva
Analista de Testes Helder Araújo Filho
Tabela 6- Estrutura da Equipe

4.1.1 Gerente de Projetos
Responsável pelo planejamento do projeto, controle da execução e supervisão do
projeto.
4.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.
4.1.3 Administrador de Banco de Dados
Responsável por gerenciar, instalar, configurar, atualizar e monitorar o sistema de banco
de dados do Diagnosticus.
4.1.4 Analista de Testes
Responsável por planejar e executar casos de testes com intuito de garantir a qualidade
do Diagnosticus.
4.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ção de equipes com suporte a canais, conversas privadas, integração com
serviços externos. Além disso, ele possui um bot de 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ódicas e acompanhamento do status do projeto através da ferramenta de gerenciamento
de projeto: Trello. As reuniões periódicas servem para trocar informações sobre o que foi feito,
do que está sendo feito e do que será feito, com a finalidade de melhoria contínua do
andamento do projeto.
Iremos adotar o Trello como 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.

4.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
comparativos e assim facilitar a vida das pessoas que pesquisaram sobre alguma de nossas
postagens.
5.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á realizado um acompanhamento constante das atividades desenvolvidas por parte
de todos os envolvidos no projeto.
Produção de documentação
Serão produzidos documentos ao decorrer 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
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.

Anexo A - Diagramas de Classes de Domínio

Plano deprojeto grupo1

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Plano deprojeto grupo1

Plano deprojeto grupo1