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.
3. Sumário
1. INTRODUÇÃO................................................................................................................... 4
1.1Âmbito do Projeto....................................................................................................... 4
1.2Funções principais do produto de software.................................................................... 4
1.3Requisitos comportamentais ou de performance............................................................ 5
1.4Gestã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 Edublog 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 tornouse mais agilizado e seguro.
1.2 Funções principais do produto de software
O diagrama da exposto na Figura 1 abaixo, referese 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, evitase 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. Tratase de uma métrica orientada a classes que consiste em:
1. Determinar a quantidade de classeschave 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 classeschave 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 (diaspessoa) 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, fezse a estimativa:
9.
10.
1. Número de classeschave 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 (classeschave) 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 email 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;
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
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 diferenciamse 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
19.
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 tratase 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:
● Email 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 faceaface 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 Edublog como ferramenta de apoio
O Edublog é 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.