1. O documento apresenta o plano de projeto de software para o Sistema de Gerenciamento de Projetos de Pesquisa (SIGEP) para o Hospital Universitário da Universidade Federal de Sergipe. 2. As principais funcionalidades do SIGEP incluem fazer login, cadastrar pesquisas, validar pesquisas, gerar relatórios e manter cadastros. 3. O projeto foi estimado em 63 dias para ser concluído por uma equipe de 5 pessoas utilizando a técnica de estimativa de Lorenz & Kidd orientada a classes.

1. UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Gerência de Projetos 2014.2
PLANO DO PROJETO DE SOFTWARE
SISTEMA DE GERENCIAMENTO DE PROJETOS DE PESQUISA
SIGEP
GRUPO 1
Domenico Medeiros
Edson Fernando Poderoso Moreira
Eric Souza
Henrique Mandt Lima Figueiredo
Vanessa Menezes Oliveira

2.
São Cristóvão – Sergipe
2015
Domenico Medeiros
Edson Fernando Poderoso Moreira
Eric Souza
Henrique Mandt Lima Figueiredo
Vanessa Menezes Oliveira
PLANO DO PROJETO DE SOFTWARE
SISTEMA DE GERENCIAMENTO DE PROJETOS DE PESQUISA
SIGEP
Trabalho apresentado ao Prof. Dr. Rogério
Patrício Chagas do Nascimento como parte
avaliativa da disciplina Gerência de Projetos do
Curso de Graduação em Sistemas de
Informação da Universidade Federal de
Sergipe – UFS.
São Cristóvão – Sergipe
2015

3. Sumário
1. INTRODUÇÃO................................................................................................................... 4
1.1​​Âmbito do Projeto....................................................................................................... 4
1.2​​Funções principais do produto de software.................................................................... 4
1.3​​Requisitos comportamentais ou de performance............................................................ 5
1.4​​Gestão e Restrições Técnicas..................................................................................... 6
2. ESTIMATIVAS DO PROJETO............................................................................................ 7
2.1 Dados históricos utilizados para as estimativas.............................................................. 7
2.2 Técnicas de estimação e resultados.............................................................................. 7
2.2.1 Técnica de estimativas........................................................................................ 7
2.3 Resultados.................................................................................................................. 8
2.4 Recursos do projeto................................................................................................... 10
2.4.1 Recursos Humanos........................................................................................... 10
2.4.2 Recursos de Software........................................................................................ 11
2.4.3 Recursos de Hardware....................................................................................... 12
3. ANÁLISE E GESTÃO DE RISCOS.................................................................................... 12
3.1 Riscos do projeto............................................................................................................. 13
3.2 Tabela de riscos............................................................................................................... 13
3.3 Redução e Gestão do Risco.............................................................................................. 14
4. PLANEJAMENTO TEMPORAL........................................................................................ 17
4.1 Conjunto de Tarefas do Projeto.......................................................................................... 17
4.2 Diagrama de Gantt........................................................................................................... 19
5. ORGANIZAÇÃO DO PESSOAL........................................................................................ 20
5.1 Estrutura da equipe.......................................................................................................... 20
5.2 Mecanismos de comunicação........................................................................................... 21
5.3 Uso do Edu­blog como ferramenta de apoio........................................................................ 21
6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO
DE SOFTWARE………………………………………………………………………………………...22

4. 1. INTRODUÇÃO
1.1 Âmbito do Projeto
O Sistema de Gerenciamento dos Projetos de Pesquisas (SIGEP) foi
desenvolvido para o Hospital Universitário da Universidade Federal de Sergipe, com o
objetivo de automatizar o processo do controle dos Projetos de Pesquisas realizados
pelo mesmo. Os professores poderão cadastrar novas pesquisas que futuramente
poderão ser validadas pelo Diretor. O sistema permitirá ainda, gerar relatórios para uma
melhor administração do controle das pesquisas do Hospital.
Antes da implementação do SIGEP, o processo era feito de forma manual. O
que resultava muitas vezes em perdas de informação. Com a automação, todo o
processo tornou­se mais agilizado e seguro.
1.2 Funções principais do produto de software
O diagrama da exposto na Figura 1 abaixo, refere­se ao diagrama de Casos de
Uso e contém as principais funcionalidades do sistema SIGEP. Nele é apresentado as
operações que serão possíveis através do sistema, como: fazer ​login​, cadastrar uma
pesquisa, validar a pesquisa, gerar relatórios, manutenir cadastros e alterar ​status ​da
pesquisa. As atividades que envolvem a manutenibilidade de determinado objeto estão
relacionadas com as operações: incluir, alterar e inativar.

5.
Figura 1 ­ Diagrama de Casos de Uso do SIGEP
1.3 Requisitos comportamentais ou de performance
● Usabilidade:
○ As mensagens devem ser claras e objetivas, favorecendo o bom
entendimento do funcionamento do sistema.
○ Todas as telas referentes à transição deverão possuir a mesma estrutura
e padronização referente ao layout de cores.
● Confiabilidade:
○ O sistema deve realizar as transações exatamente de acordo com o que
o usuário solicitar, sem excessos nem omissões.
○ O sistema deverá permitir que sua confiabilidade seja medida e avaliada,
principalmente através de testes, onde serão verificadas as transações

6. mais vulneráveis e que necessitam de maior atenção em correções e
ajustes.
● Desempenho:
○ O sistema deverá retornar consultas gerais em no máximo 5s.
○ Para transações de cadastros e alterações em geral, o sistema deverá
retornar o sucesso ou insucesso da transação em no máximo 3s.
● Segurança:
○ O Acesso do sistema se dará através de ​login e senha, com isso, poderá
acessar o sistema apenas pessoas habilitadas para este fim.
○ Todas as informações a nível de memória e armazenamento do ​browser
(​cookies​) serão sumariamente apagadas quando o usuário sair do
sistema, com isso, evita­se o risco que informações possam de alguma
forma ser manipuladas por pessoas não autorizadas.
1.4 Gestão e Restrições Técnicas
As restrições encontradas na descrição do sistema que poderão limitar o
escopo podem ser:
● É necessária a existência de uma estrutura de computadores ligados
através de uma rede interna.
● É necessária a existência de uma máquina que será utilizada como
servidor com dedicação exclusiva que será responsável pelo controle de
todas as atividades referentes à infraestrutura, como backups de
informações e demais atividades controladas pela administração do
sistema.
● O sistema atuará sobre a plataforma Windows XP SP3 ou superior.
● O produto deve ser implementado como uma aplicação web e portável
para as plataformas Internet Explorer 8.0.6001.18702 (Ou superior) ou

7. Google Chrome 33.0.1750.117m (Ou superior) ou Mozilla Firefox 27.0.1
(Ou superior).
● O produto deve utilizar Banco de Dados PostgreSql.
● O produto deve ser implementado na linguagem de programação PHP.
● Falta de capacitação técnica da equipe, sendo necessário um treinamento
específico para alguns componentes da equipe com ferramentas que
serão utilizadas.
2. ESTIMATIVAS DO PROJETO
2.1 Dados históricos utilizados para as estimações
Não serão utilizados dados históricos na avaliação do projeto, visto que este
será o primeiro projeto da equipe.
2.2 Técnicas de estimação e resultados
Para estimar o tempo é necessária a utilização de uma técnica de estimativa, e a
técnica escolhida foi a de Lorenz & Kidd, Orientada a Classes, adotada pela Lacertae
Software.
2.2.1 Técnicas de estimação e resultados
A técnica de estimação escolhida para o SIGEP foi a adotada pela Lacertae
Software. Trata­se de uma métrica orientada a classes que consiste em:
1. Determinar a quantidade de classes­chave do projeto;
2. Encontrar o número de classes de suporte, classificando o tipo de
interface do produto e utilizando multiplicadores correspondentes para as
classes de suporte;

8. 3. Multiplicar a quantidade de classes­chave pelo multiplicador
correspondente para estimar o número de classes de suporte;
4. Multiplicar o total de classes (chave + suporte) pelo número médio de
unidades de trabalho (dias­pessoa) por classe;
5. Calcular o tempo previsto para a realização do projeto.
A Tabela 1 com os Multiplicadores utilizados para encontrar a quantidade de
classes de suporte:
INTERFACE MULTIPLICADOR
Não Gráfica 2
Baseada em Texto 2,25
GUI Simples 2,5
GUI Complexa 3
Tabela 1 ­ Fatores Multiplicativos
2.3 Resultados
Com base no diagrama de classes de análise da Figura 2, fez­se a estimativa:

10.
1. Número de classes­chave encontradas após a análise do diagrama de
classes de domínio: ​10​;
2. Interface selecionada (De acordo com o modelo de arquitetura do
sistema): ​GUI simples​;
3. Número de classes de suporte encontrado: 10 (classes­chave) x 2,5
(valor multiplicador utilizado da Tabela 1)= ​25 classes de suporte​;
4. Número total de classes: 10 (chave) + 25 (suporte)= ​35 classes​;
5. Quantidade de dias que uma pessoa gastaria para desenvolver uma
única classe: ​9 dias​;
No modelo Lacertae, é recomendado o uso de 15 a 20 dias porém,
utilizamos a quantidade de 9 dias com base no tempo utilizado quando o SIGEP foi
desenvolvido.
6. Quantidade total de dias que uma pessoa gastaria para construir todo o
sistema: 9 (dias) * 35 (classes) = ​315 dias​;
7. Quantidade total de dias que a equipe gastaria para construir todo o
sistema: 315 (dias) / 5 (quantidade de integrantes)= ​63 dias​.
Sendo assim, o tempo necessário para a construção do projeto deve ser de,
aproximadamente, 63 dias, que dividindo por 22 (quantidade de dias úteis de um mês)
resulta num tempo aproximado de 3 meses.
2.4 Recursos do projeto
2.4.1 Recursos Humanos
O projeto contará com cinco pessoas que exercerão os diversos papéis
que serão necessários para a execução do projeto de desenvolvimento de software. Na

11. Tabela2 abaixo, podemos verificar os envolvidos de acordo os com seus respectivos
papéis.
Papel Responsável
Gerente de Projeto Vanessa Menezes
Analista de Sistemas Henrique Mandt
Arquiteto de Software Edson Poderoso
Codificador Domenico Medeiros, Edson Poderoso
Testador Eric Souza, Henrique Mandt, Vanessa Menezes
Tabela 2 ­ Recursos Humanos
2.4.2 Recursos do Ambiente de Desenvolvimento
Para o bom desenvolvimento deste projeto, foram utilizados os seguintes
recursos de software:
● PostgreSql ­ Sistema de gerenciamento do banco de dados;
● PHP ­ Linguagem de programação a ser utilizada no
desenvolvimento do software;
● Microsoft Office ­ Editor de texto, planilhas e apresentações usados
na documentação e relativos;
● Gmail ­ Sistema de e­mail utilizado para troca de informações;
● Google Drive ­ Sistema de armazenamentos de dados em nuvem
para compartilhamento de arquivos e alterações dos mesmos em
tempo real;
● GanttProject 2.7 ­ Utilizada para elaborar o Diagrama de Gantt;
● NetBeans 7.2.1 ­ IDE que será utilizada na implementação do
produto de software;

12. ● MsProject 2010 ­ Auxilia na gerência das atividades do projeto.
2.4.3 Recursos de Hardware
Computador para Desenvolvimento:
Processador: Core i3 ou superior.
Memória RAM: 4 Gb de RAM.
HD: 250 Gb ou superior.
3. ANÁLISE E GESTÃO DE RISCOS
Nesta seção, serão analisados os possíveis riscos prejudiciais para o
desenvolvimento do projeto de software. Por meio desta análise, visamos minimizar o
máximo possível a sua ocorrência e, consecutivamente, o seu impacto caso venha a
ocorrer.
3.1 Riscos do projeto
Segue abaixo a Tabela 3 com os riscos levantados para o referido projeto:
Risco Projeto Técnico Negócio Comum Especial
Equipe não domina totalmente
a tecnologia adotada no
projeto
X
X
Equipe não possui o
treinamento necessário na
linguagem de desenvolvimento
adotada
X
X
Equipe pequena no
desenvolvimento do projeto
X X

13. Custos relacionados ao mal
uso da ferramenta
X X
Ferramentas de teste com
baixo suporte à tecnologia
empregada no projeto
X
X
Período de desenvolvimento
do projeto relativamente curto
X X
Equipe não disponível em
tempo integral
X X
Constante necessidade de
aprimoramento do software
X X
Tabela 3 ­ Riscos x Classificação
3.2 Tabela de riscos
Na Tabela 4 a seguir, foram definidos para cada risco, apresentado
anteriormente na Tabela 3, uma probabilidade que determina a chance de ocorrência
do mesmo, bem como o impacto após o acontecimento do risco.
Risco Probabilidade (%) Impacto
Ferramentas de teste com baixo suporte
à tecnologia empregada no projeto
90% Catastrófico
Período de desenvolvimento do projeto
relativamente curto
80% Crítico
Equipe não disponível em tempo integral 70% Moderado
Equipe pequena no desenvolvimento do
projeto
70% Marginal
Custos relacionados ao mal uso da
ferramenta
70% Marginal
Equipe não domina totalmente a
tecnologia adotada no projeto
60% Moderado

14. Equipe não possui o treinamento
necessário na linguagem de
desenvolvimento adotada
60%
Moderado
Constante necessidade de
aprimoramento do software
40% Moderado
Tabela 4 ­ Riscos do Projeto
3.3 Redução e Gestão do Risco
Visando garantir a redução e/ou gestão dos riscos apresentados, as estratégias
de redução, supervisão e gestão dos riscos (RSGR) foram adotadas:
1. Equipe não domina totalmente a tecnologia adotada no projeto
Probabilidade: ​60% Impacto: ​Moderado
Descrição: ​A equipe não possui o conhecimento mínimo suficiente sobre a
tecnologia utilizada no desenvolvimento do projeto.
Estratégia de Redução: ​Buscar métodos que visem expandir e aprimorar os
conhecimentos acerca da referida tecnologia.
Plano de Contingência: ​Planejar e definir em em equipe as estruturas de dados
utilizadas no SIGEP em oposição à prática do desenvolvimento individual com o
intuíto de evitar bloqueios por falta de domínio da tecnologia.
Responsável: ​Edson Poderoso
Status: ​Concluído
Tabela 5 ­ Análise do risco 1
2. Equipe não possui o treinamento necessário na linguagem de
desenvolvimento adotada
Probabilidade: ​60% Impacto: ​Moderado
Descrição: ​Devido à escassez de cursos locais, o treinamento da equipe é baixo.
Estratégia de Redução: ​Cursos e apostilas de aprendizado online

15. Plano de Contingência: ​Adotar uma linguagem de programação comum ao
conhecimento de todos os participantes.
Responsável: ​Domenico Medeiros
Status: ​Concluído
Tabela 6 ­ Análise do risco 2
3. Equipe pequena no desenvolvimento do projeto
Probabilidade: ​70% Impacto: ​Marginal
Descrição: ​A equipe responsável pela construção do projeto é relativamente
pequena.
Estratégia de Redução: ​Divisão das tarefas da equipe de acordo com um
planejamento, evitando assim a sobrecarga de funções.
Plano de Contingência: ​Entregar o projeto em etapas incrementais.
Responsável: ​Vanessa Menezes Oliveira
Status: ​Concluído
Tabela 7 ­ Análise do risco 3
4. Custos relacionados ao mau uso do SIGEP
Probabilidade: ​70% Impacto: ​Marginal
Descrição: ​Caso o software se comporte de forma não planejada, erros poderão
acontecer implicando em custos extras
Estratégia de Redução: ​Efetuar exaustivos testes no software antes da entrega.
Plano de Contingência: ​Capacitar pessoas a oferecer suporte ao SIGEP, bem como
fornecer manuais de uso para os usuários.
Responsável: ​Eric Souza
Status: ​Concluído
Tabela 8 ­ Análise do risco 4

16. 5. Ferramentas de teste com baixo suporte à tecnologia empregada no
projeto
Probabilidade: ​90% Impacto: ​Catastrófico
Descrição: ​Ferramentas de teste automatizado acabam por oferecer pouco suporte
à tecnologia usada na codificação do produto.
Estratégia de Redução: ​Diminuição gradativa do uso dessas ferramentas por meio
da implantação de outros processos de teste, visando novas soluções.
Plano de Contingência: ​Divisão de testes complexos em outros menores, mais
simplificados, de forma a facilitar o uso das ferramentas já utilizadas.
Responsável: ​Henrique Mandt
Status: ​Concluído
Tabela 9 ­ Análise do risco 5
6. Período de desenvolvimento do projeto relativamente curto
Probabilidade: ​80% Impacto: ​Crítico
Descrição: ​O prazo para a completa construção do software é curto.
Estratégia de Redução: ​Divisão pertinente das atividades seguindo o planejamento.
Plano de Contingência: ​Efetuar entregas parciais do SIGEP ao usuário.
Responsável: ​Eric Souza
Status: ​Concluído
Tabela 10 ­ Análise do risco 6
7. Equipe não disponível em tempo integral
Probabilidade: ​70% Impacto: ​Moderado
Descrição: ​Devido às atividades independentes dos membros da equipe, o tempo
disponível para o projeto não é integral.
Estratégia de Redução: ​Divisão pertinente das atividades seguindo 0 planejamento
à risca.

17. Plano de Contingência: ​Revisar as atividades realizadas por cada integrante de
forma a não haver uma sobrecarga de tarefas. Uma nova divisão de tarefas pode
facilitar o processo.
Responsável: ​Vanessa Menezes
Status: ​Concluído
Tabela 11 ­ Análise do risco 7
8. Constante necessidade de aprimoramento do SIGEP
Probabilidade: ​40% Impacto: ​Moderado
Descrição: ​As necessidades do usuário podem passar por diversas modificações
mediante a evolução das atividades, levando a uma constante modificação do
produto.
Estratégia de Redução: ​Disponibilizar versões ​alpha (versões de testes) para que
os usuários conheçam o software e possam opinar no aprimoramento do mesmo,
identificando precocemente as necessidades dos usuários, de forma a melhorar o
produto.
Plano de Contingência: ​Buscar atender prioritariamente as obrigações definidas
contratualmente, oferecendo o serviço de customização como uma opção posterior.
Responsável: ​Edson Poderoso
Status: ​Concluído
Tabela 12 ­ Análise do risco 8
4. PLANEJAMENTO TEMPORAL
Nesta seção serão apresentadas as tarefas realizadas no SIGEP e seu
planejamento temporal do Diagrama de Gantt, onde será definido as datas de início e
fim e o responsável por cada tarefa.
4.1 Conjunto de Tarefas do Projeto

18. Aqui são apresentados o Modelo de Processo escolhido, suas atividades e
algumas tarefas escolhidas para serem apresentadas nesta seção.
Com base nos cálculos descritos na seção 2 presente no item 2.3 (Resultados),
o esforço estimado para a realização do projeto é de 63 dias trabalhados.
Abaixo é exibido o plano temporal das fases do SIGEP.
Fases Porcentagem Dias Trabalhados
Planejamento 18% 11,34
Análise de Requisitos 34% 21,42
Geração de Código 37% 23,31
Testes 11% 6,93
Tabela 13 ­ Dias por Tarefa
A porcentagem estabelecida para as fases do SIGEP diferenciam­se das
sugeridas no modelo Lacertae. Visto que o SIGEP já foi desenvolvido posteriormente e
a média de dias para desenvolvimento de uma classe (apresentada na secão 2, item
2.3) também resultou nos valores de porcentagem apresentados na Tabela 13.
Diagrama de Gantt

20.
5. ORGANIZAÇÃO DO PESSOAL
Cada membro da equipe possui seus papéis e atividades bem definidas, onde
cada um sabe qual deverá ser a tarefa a ser realizada. As decisões são sempre
tomadas em conjunto.
5.1 Estrutura da equipe
Analista de Sistemas ­ estudam os diversos sistemas existentes entre
hardwares (equipamentos), softwares (programas) e o usuário final.
Responsável: Henrique Mandt
Analista de Testes ­ identificam e definem os testes necessários, monitorar a
abrangência dos testes e avaliar a qualidade obtida ao realizar os testes. Responsável
ainda por desenvolver e testar componentes de acordo com os padrões adotados para
o projeto, para fins de integração com subsistemas maiores.
Responsável: Eric Souza
Arquiteto de Software ­ lideram e coordenam as atividades e os artefatos
técnicos no decorrer do projeto. Estabelece também, a estrutura geral de cada visão de
arquitetura: a decomposição da visão, o agrupamento dos elementos e as interfaces
entre esses principais agrupamentos.
Responsável: Edson Poderoso
Gerente de Projetos ­ gerencia o progresso do empreendimento e por meio
das variáveis (qualidade, custo, prazo e âmbito) verificam seus desvios, de forma a
minimizar as falhas ligadas ao processo.
Responsável: Vanessa Menezes

21. Product Owner ­ trata­se da única pessoa responsável pelo gerenciamento do
Backlog do Produto e por garantir o valor do trabalho realizado pelo ​Time Scrum​,
permitindo que todos os outros membros da equipe possam visualizá­lo.
Responsável: Domenico Medeiros.
5.2 Mecanismos de comunicação
As formas de comunicação utilizadas para o projeto foram:
● E­mail ­ comunicação direta para os demais participantes do projeto com
relatórios informando as evoluções e problemas encontrados ao longo do
desenvolvimento.
● Reuniões Diárias ­ permitiram a comunicação face­a­face e ajudaram a
verificar o andamento do projeto.
● Ferramentas Colaborativas ­ documentos importantes foram
compartilhados e editados em tempo real por meio do Google Drive,
permitindo a participação de todos os envolvidos.
● Aplicativos (Whatsapp) ­ interações rápidas e tomadas de decisões
diretas foram realizadas em tempo hábil através da criação de um grupo
no aplicativo para ​smatphones​.
5.3 Uso do Edu­blog como ferramenta de apoio
O Edu­blog é uma ferramenta bastante simples e possui acesso facilitado, apóia
a colaboração entre pessoas como fonte de disseminação de conhecimentos.
A utilização do blog durante o desenvolvimento desse trabalho foi importante
para o seu bom andamento. Um importante papel do blog foi compartilhar os
conhecimentos por nós elencados, bem como compartilhar informações com outras
equipes que serviram como base para a edição deste documento.

22.
6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SOFTWARE
Visando garantir a qualidade do software, algumas atividades foram
desenvolvidas durante o projeto, sendo elas:
● Testes ­ ​Sucessivos testes foram realizados durante a fase de
desenvolvimento do software, com a finalidade de evitar futuras ​releases
de correção de eventuais erros que possam vir a ocorrer no software.
● Reuniões Diárias ­ Por meio das reuniões diárias realizadas pelos
membros da equipe, foi possível sanar eventuais dúvidas que vieram a
surgir com relação ao desenvolvimento do projeto. Auxiliando evitar, de
maneira ágil, desvios de má interpretação. Atividades de ​brainstorming
foram essenciais para tomadas de decisão com relação a um melhor
desenvolvimento do software.
● Elaboração de Documentação ­ para um melhor controle do projeto,
documentações foram elaboradas nas fases de análise, projeto e testes.