19
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.

Plano deprojeto grupo1

Embed Size (px)

Citation preview

Page 1: 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.

Page 2: Plano deprojeto grupo1

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

Page 3: Plano deprojeto grupo1

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:

Page 4: Plano deprojeto grupo1

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

Page 5: Plano deprojeto grupo1

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)

Page 6: Plano deprojeto grupo1

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

Page 7: Plano deprojeto grupo1

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:

Page 8: Plano deprojeto grupo1

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

Page 9: Plano deprojeto grupo1

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

Page 10: Plano deprojeto grupo1

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

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

Page 11: Plano deprojeto grupo1

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

Risco: 02 Probabilidade: 90% Impacto: 4

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.

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 os requisitos.

Plano de contingência: Validação dos requisitos com o usuário antes de iniciar o

desenvolvimento.

Page 12: Plano deprojeto grupo1

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: 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.

Status: Em andamento.

Risco: 05 Probabilidade: 30% Impacto: 4

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.

Pessoa responsável: Helder Filho.

Status: Monitorando.

Risco: 06 Probabilidade: 20% Impacto: 4

Descrição: Seguimento das diretrizes.

Estratégia de redução: Marcar reuniões para acompanhar esse seguimento.

Page 13: Plano deprojeto grupo1

Plano de contingência: Reestabelecer novas diretrizes de forma clara e objetiva,

juntamente com um acompanhamento para que elas sejam seguidas.

Pessoa responsável: Helder Filho.

Status: Em andamento.

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.

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.

Page 14: Plano deprojeto grupo1

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: 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.

Pessoa responsável: Jéssica Silveira.

Status: Efetuando pesquisa de mercado por recursos humanos especializados.

Risco: 12 Probabilidade: 30% Impacto: Moderado

Page 15: Plano deprojeto grupo1

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.

Pessoa responsável: Jéssica Silveira.

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

Page 16: Plano deprojeto grupo1

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.

Page 17: Plano deprojeto grupo1

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.

Page 18: Plano deprojeto grupo1

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.

Page 19: Plano deprojeto grupo1

Anexo A - Diagramas de Classes de Domínio