Embed Size (px)
Citation preview
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 PLANEJAMENTO TEMPORAL.............................................................................................. 15
5.0 ORGANIZAÇÃO DO PESSOAL .............................................................................................. 15
5.1 Estrutura da equipe ....................................................................................................... 15
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 ................................................................................................... 16
5.2 Mecanismos de comunicação ........................................................................................ 16
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 .......................................................................................................................................... 17
Anexo A - Diagramas de Classes de Domínio ........................................................................... 18
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á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 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 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
professor será responsável por criar o jogo e definir tempo para jogada com relação aos dados
da Anamnese e dos Exames. 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.
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 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 que é Orientado a Objetos. 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 à 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
análise 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 aproximadamente 200 dias para o seu desenvolvimento.
Levado em consideração 22 dias úteis 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
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:
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ômicas
3.0 ANÁLISE E GESTÃO DE RISCOS
O risco é um problema em potencial, podendo ocorrer ou não. É sempre aconselhável
que haja uma identificação deles, além de uma avaliação das suas probabilidades de acontecer
e dos seus impactos. Também se deve estabelecer um plano 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
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 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
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 dos componentes desenvolvidos.
Estratégia de redução: Estabelecer uma arquitetura de software e adotar padrões para o
desenvolvimento.
Plano de contingência: Analisar e melhorar os componentes, verificando a estrutura do
código.
Pessoa responsável: Gilcley Silva.
Status: Em análise
Risco: 02 Probabilidade: 90% Impacto: 4
Descrição: Mais utilizadores do que o previsto.
Estratégia de redução: Analisar probabilidade de aumentar o número de servidores.
Plano de contingência: Buscar soluções distribuídas.
Pessoa responsável: Gilcley Silva.
Status: Em Análise.
Risco: 03 Probabilidade: 80% Impacto: 4
Descrição: Mudança dos Requisitos.
Estratégia de redução: Agendar reuniões para definir ou atualizar os requisitos.
Plano de contingência: Documentar e homologar os requisitos com o usuário, antes de
iniciar o desenvolvimento.
Pessoa responsável: Gilcley Silva.
Status: Em andamento.
Risco: 04 Probabilidade: 50% Impacto: 4
Descrição: Não atender aos prazos especificados.
Estratégia de redução: Monitorar o andamento do projeto verificando se os prazos estão
sendo respeitados.
Plano de contingência: Definir prioridades de entregas do que deveria obrigatoriamente
ter sido entregue até o final do próximo prazo.
Pessoa responsável: Helder Filho.
Status: Em andamento.
Risco: 05 Probabilidade: 30% Impacto: 4
Descrição: Servidor de aplicação estar indisponível.
Estratégia de redução: Utilizar um servidor com uma alta taxa de disponibilidade, além
de monitorar o estado do servidor de aplicação.
Plano de contingência: Utilizar de replicação do servidor.
Pessoa responsável: Helder Filho.
Status: Monitorando.
Risco: 06 Probabilidade: 20% Impacto: 4
Descrição: Seguimento das regras de negócio.
Estratégia de redução: Acompanhar o andamento do projeto para verificar se as regras
de negócio estão sendo seguidas.
Plano de contingência: Reunir os integrantes do projeto para que haja esclarecimentos
sobre as regras de negócio, mostrando os erros já cometidos e exemplificando como o
processo deve ser executado para que os erros não mais ocorram.
Pessoa responsável: Helder Filho.
Status: Em andamento.
Risco: 07 Probabilidade: 70% Impacto: Moderado
Descrição: Quadro comum de processos de.
Estratégia de redução: Desenvolver padrões de processos de negócio
Plano de contingência: Criação de organogramas e modelagem de processos de negócio.
Pessoa responsável: Iúri Batista Teles.
Status: Em andamento.
Risco: 08 Probabilidade: 70% Impacto: Moderado
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.
Pessoa responsável: Iúri Batista Teles.
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ê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.
Risco: 11 Probabilidade: 50% Impacto: Moderado
Descrição: Quantidade insuficiente de pessoas de pessoas na equipe.
Estratégia de redução: Aumentar os prazos de entrega do produto.
Plano de contingência: Contratar estagiários e programadores para equipe.
Pessoa responsável: Jéssica Silveira.
Status: Efetuando pesquisa de mercado por recursos humanos especializados.
Risco: 12 Probabilidade: 30% Impacto: Moderado
Descrição: Ausência 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 à qualidade da documentação, e como fazê-
la de forma eficiente, de acordo com a metodologia de projeto a ser seguida.
Incluir políticas de documentação.
Pessoa responsável: Jéssica Silveira.
Status: Monitorando o 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.
5.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.
5.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
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.
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çã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.
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
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á 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
