SIGAP Plano Projeto

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Sistema de Gestão de Agendamentos e Prontuário - SIGAP
Plano de Projeto de Software
Anderson Nunes, Marcos Felipe, Rafael Rabelo, Samila Ruane,
Sílvio Passos
Departamento de Computação/UFS
São Cristóvão – Sergipe
2017

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Anderson Nunes, Marcos Felipe, Rafael Rabelo, Samila Ruane,
Sílvio Passos
Sistema de Gestão de Agendamentos e Prontuário - SIGAP
Plano de Projeto de Software submetido a matéria de
Gestão de Projeto requisito parcial para a obtenção da
nota ﬁnal
Professor(a): Dr. Rogério Patrício Chagas do Nasci-
mento
São Cristóvão – Sergipe
2017

Lista de ilustrações
Figura 1 – Diagrama de Casos de Uso SIGAP . . . . . . . . . . . . . . . . . . . . . . 7
Figura 2 – Diagrama de Classes - Manter Atendimento . . . . . . . . . . . . . . . . . 8
Figura 3 – Diagrama de Classes - Manter Colaborador . . . . . . . . . . . . . . . . . 9
Figura 4 – Diagrama de Classes - Manter Agendamento . . . . . . . . . . . . . . . . 10
Figura 5 – Diagrama de Classes - Manter Paciente . . . . . . . . . . . . . . . . . . . 10
Figura 6 – Diagrama de Classes - Gerar Relatórios . . . . . . . . . . . . . . . . . . . 11
Figura 7 – Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figura 8 – Diagrama de Gantt - Codiﬁcação em Sprints . . . . . . . . . . . . . . . . . 25

Lista de tabelas
Tabela 1 – Tipo de Interface do produto e respectivo multiplicador . . . . . . . . . . . 14
Tabela 2 – Estimativas dos dias de trabalho em cada etapa do projeto . . . . . . . . . . 15
Tabela 3 – Tabela de Riscos do SIGAP . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Tabela 4 – Risco 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Tabela 5 – Risco 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Tabela 6 – Risco 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Tabela 7 – Risco 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Tabela 8 – Risco 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Tabela 9 – Risco 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Tabela 10 – Risco 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Tabela 11 – Risco 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Tabela 12 – Risco 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Tabela 13 – Risco 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Tabela 14 – Risco 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Tabela 15 – Risco 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Tabela 16 – Risco 13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Tabela 17 – Risco 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Tabela 18 – Risco 15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Tabela 19 – Tempo Estimado em Cada Tarefa Macro do Projeto . . . . . . . . . . . . . 23
Tabela 20 – Organização da Equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Lista de abreviaturas e siglas
UDOPE Unidade de Diagnóstico Oral e Odontologia para Pacientes Especiais
HU Hospital Universitário
UFS Universidade Federal de Sergipe
SIGAP Sistema de Gestão de Agendamentos e Prontuários
SGBD Sistema de Gerenciamento de Banco de Dados
PMBOK Project Management Body of Knowledge

Sumário
1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1 Escopo do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Funções principais do produto de software . . . . . . . . . . . . . . . . . . . . 6
1.3 Requisitos comportamentais ou de performance . . . . . . . . . . . . . . . . . 11
1.4 Gestão e Restrições Técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Estimação do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1 Técnicas de estimação e resultados . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1 Técnicas de estimação . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Recursos do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 Recursos humanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Recursos de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Recursos de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.4 Recursos Bibliográﬁcos . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Gestão de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Riscos do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Redução e Contingência de Riscos . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Planejamento Temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1 Conjunto de Tarefas do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5 Organização da equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1 Estrutura da Equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 Mecanismos de comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3 Uso do Edu-Blog como ferramenta de apoio . . . . . . . . . . . . . . . . . . . 31
6 Precauções tomadas para assegurar e controlar a qualidade do produto de soft-
ware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6
1Introdução
1.1 Escopo do Projeto
Devido a dificuldade de gerenciar os agendamentos e prontuários da Unidade de Diag-
nóstico Oral e Odontologia para Pacientes Especiais (UDOPE), na qual hoje esta atividade é
realizada de forma manual e em papel, foi decidido criar um sistema que auxiliasse este processo.
O SIGAP, Sistema de Gestão de Agendamentos e Prontuários, é responsável pela manu-
tenção dos agendamentos e prontuários da UDOPE, que está situado no setor de Odontologia do
Hospital Universitário da Universidade Federal de Sergipe. O sistema proposto permite cadastrar,
editar e consultar pacientes, profissionais e usuários, registrar a anamnese (uma entrevista reali-
zada com o paciente pelo profissional da saúde e se caracteriza como ponto inicial no diagnostico
daquele paciente), o exame clínico e as evoluções do paciente, além de possibilitar a geração de
relatórios.
As entradas do software são principalmente os dados pessoais do paciente, dados dos
colaboradores, dados dos atendimentos e dados do agendamento de consultas e eventos.
1.2 Funções principais do produto de software
As principais funções do sistema são apresentadas na Figura 1, a qual se trata de um
diagrama de casos de uso que contém os 5 requisitos principais do sistema proposto.

Capítulo 1. Introdução 7
Figura 1 – Diagrama de Casos de Uso SIGAP
Fonte: Próprios autores
O requisito Manutenção do Atendimento, cujo diagrama de classes é apresentado na
Figura 2, tem como objetivo gerenciar as variáveis envolvidas no atendimento de um paciente
como cadastro da anamnese, cadastro do exame clínico, geração de receitas, atestados e plano de
tratamento e cadastro da evolução do paciente. Esta seção é restrita aos proﬁssionais da saúde e
tratam-se de dados sigilosos os quais devem ser criptografados antes de serem salvos.

Figura 2 – Diagrama de Classes - Manter Atendimento
O requisito Manutenção do Colaborador, cujo diagrama de classes está apresentado
na Figura 3, é responsável pelo cadastro, edição e consulta de colaboradores, além de gerenciar
uma lista de presença.

Figura 3 – Diagrama de Classes - Manter Colaborador
O requisito Manter Agendamento, cujo diagrama de classes é apresentado na Figura
4 tem como objetivo gerenciar as consultas e eventos do setor, de forma que seja possível
cadastrar e visualizar consultas e eventos e pesquisa-los por data, além de atualizar seu status.
Este requisito também trata dos horários dos dentistas e gerencia uma escala com os seus dias e
horários de atendimento.

Figura 4 – Diagrama de Classes - Manter Agendamento
O requisito Manter Paciente, cujo diagrama de classes é apresentado na Figura 5 tem
como objetivo cadastrar, editar e consultar os pacientes que chegam a unidade, esse requisito
também trata da classiﬁcação dos pacientes entre pacientes Udope, os quais são efetivamente
pacientes da unidade e pacientes que ainda irão passar por uma pré triagem.
Figura 5 – Diagrama de Classes - Manter Paciente
O requisito Gerar relatório, cujo diagrama está apresentado na Figura 6, tem como
objetivo a partir de uma data de inicio, uma data de ﬁm e um parâmetro que pode ser, consultas ou
uso dos procedimentos, retornar os dados referente àquele parâmetro, ou seja, quantas consultas

foram realizadas ou canceladas nesse período e em quantas o paciente não compareceu, ou
quantas vezes determinado procedimento foi utilizado durante este período.
Figura 6 – Diagrama de Classes - Gerar Relatórios
1.3 Requisitos comportamentais ou de performance
Também conhecidos como requisitos não-funcionais, os requisitos apresentados abaixo
tratam-se daqueles que também são necessários para que as funcionalidades do sistema sejam
alcançadas de forma que apresente requisitos de qualidade como usabilidade, confiabilidade,
desempenho e segurança, além de definir quais são os requisitos de implantação e requisitos de
Hardware e Software.
• Usabilidade
– Interface com o Usuários: A interface com o usuário deve apresentar ícones intuitivos,
no qual o usuário possa associar cada opção a função que esta é responsável com
facilidade.
• Confiabilidade
– Consistências dos dados: Os dados não podem, em hipótese nenhuma, serem corrom-
pidos ou excluídos por falha do sistema.
• Desempenho
– Inicialização do Sistema: O Sistema deve demorar menos de um 30 segundos para
iniciar em pelo menos 90% dos casos.
• Segurança
– Sigilo das Informações do Atendimento: As informações sobre determinado pa-
ciente geradas pelo Dentista em um atendimento não podem ser visualizadas por
profissionais que não fazem parte da ala médica.

– Controle de Acesso: Cada usuário terá permissões de acesso especíﬁca mediante seu
papel no setor.
• Implantação
– Compatibilidade com outros sistemas: O sistema deve ser compatível com os outros
sistemas que já estão em uso no HU.
• Hardware e Software
– Linguagem de Desenvolvimento: A linguagem a ser utilizada no desenvolvimento do
software é o Java.
– Sistemas de Gerenciamento de Banco de Dados: O SGBD utilizado no desenvolvi-
mento das Tabelas da aplicação será o PostgreSQL.
1.4 Gestão e Restrições Técnicas
As restrições técnicas associadas ao desenvolvimento do projeto são:
• A linguagem de programação utilizada é Java 1.
• O SGBD utilizado no desenvolvimento das Tabelas da aplicação será o PostgreSQL 2.
• O protótipo de telas deve ser construído no Belsamiq 3.
• As atividades do desenvolvimento do projeto devem ser gerenciadas pelo TRELLO 4.
• A metodologia para gestão de projeto de software utilizada deve ser o método ágil
SCRUM5.
1 Disponível em: https://www.oracle.com/br/java/index.html
2 Disponível em: https://www.postgresql.org/
3 Disponível em: https://balsamiq.com/
4 Disponível em: https://trello.com/
5 Mais informações em: https://goo.gl/3A2HA6

13
2Estimação do Projeto
As estimativas que serviram de base ao desenvolvimento do projeto foram calculadas de
acordo com as métricas de Lorenz e Kidd (LORENZ M.; KIDD, 1994). Essas métricas foram
escolhidas por se adequarem bem ao desenvolvimento de softwares construídos de acordo com o
paradigma da orientação a objetos, como é o caso deste software.
2.1 Técnicas de estimação e resultados
2.1.1 Técnicas de estimação
Para usar as métricas de Lorenz e Kidd (LORENZ M.; KIDD, 1994) é preciso seguir as
seguintes etapas:
1. Definir o número de classes chave;
2. Encontrar o número de classes de suporte, que para isso temos que classificar o tipo de
Interface do Produto e desenvolver um Multiplicador para as Classes de Suporte;
3. Multiplicar a quantidade de classes-chave pelo Multiplicador para obter uma estimativa do
número de classes de suporte;
4. Logo após, calcula-se a quantidade total de Classes, somando o nº de Classes-Chave com
o nº de Classes de Suporte;
5. Multiplicar a quantidade total de Classes (classes-chave + classes de suporte) pelo “número
médio de unidades de trabalho (dias-pessoa) por classe”( Lorenz & Kidd sugerem entre 15
e 20 dias-pessoa por classe) Escolher um número entre 15-20 dias-pessoa e justificar a
escolha.

Capítulo 2. Estimação do Projeto 14
6. Determinar a quantidade de esforço estimada;
7. Calcular o tempo previsto para a elaboração do projeto.
A Tabela 1 mostra os fatores de multiplicação para encontrar a quantidade de classes de suporte:
Tabela 1 – Tipo de Interface do produto e respectivo multiplicador
Interface Multiplicador
Não Gráﬁca 2
Baseada em Texto 2,25
GUI 2,5
GUI Complexa 3
2.1.2 Resultados
Aplicando as métricas de Lorenz e Kidd (LORENZ M.; KIDD, 1994), obtivemos:
1. O número de classes chave: 6.
2. Pela natureza do projeto, as classes possuem como fator multiplicador: 2,5.
3. O número de classes de suporte é: 15. Classes chave * Fator multiplicador => 6 x 2,5 = 15
4. O total de classes projetadas para o sistema é: 21. Total de classes = Classes chave +
Classes de suporte => 6+15 = 21
5. Como os proﬁssionais não estão familiarizados com a linguagem em que o software será
desenvolvido e é o primeiro projeto dessa natureza na empresa, o “número médio de
unidades de trabalho (dias-pessoa) por classe” será de 20 dias-pessoa por classe.
6. A quantidade de esforço estimada é: 420 dias de trabalho. Quantidade de esforço = Total
de classes * unidades de trabalho => 21 * 20 = 420
7. Como a equipe para a execução desse projeto é composta por 3 pessoas, a distribuição de
dias de trabalho por pessoa é a seguinte: 140 dias de trabalho por pessoa. Total de dias de
trabalho/Quantidade de pessoas = Dias de trabalho por pessoal 420/3 = 140
Aplicando-se a distribuição dos dias de trabalho aos percentuais de cada fase obtém-se a
Tabela 2

Capítulo 2. Estimação do Projeto 15
Tabela 2 – Estimativas dos dias de trabalho em cada etapa do projeto
Etapa Modelo (%) Projeto (%) Cálculo
Dias de
Trabalho
Planejamento 2-3 3 140*3 4
Requisito-
Análise-Desenho
37-38 37 140*37 52
Codificação 20 20 140*20 28
Testes 40 40 140*40 56
Resultado 140
2.2 Recursos do projeto
2.2.1 Recursos humanos
A equipe deste projeto é composta por Anselmo Rodrigues, Samila Ruane e Sílvio Passos.
Todos são graduandos no Bacharelado em Sistemas de Informação da Universidade Federal de
Sergipe(UFS).
2.2.2 Recursos de Software
Os softwares a serem utilizados neste projeto são:
1. Eclipse: IDE utilizada na codificação do software.
2. Google Chrome: navegador utilizado para testar as funcionalidades do software.
3. Mozilla Firefox: navegador utilizado para testar as funcionalidades do software.
2.2.3 Recursos de Hardware
Os dispositvos de hardware a serem utilizados neste projeto são:
1. Notebooks: utilizados para a codificação e testes.
2.2.4 Recursos Bibliográficos
As referências bibliográficas utilizadas no projeto são:
1. PRESSMAN, Roger S. Engenharia de Software, 6ª edição, São Paulo, McGraw-Hill, 2006
2. LORENZ, M.; KIDD, J. Object-oriented software metrics: a practical guide.Prentice-Hall,
Inc., Upper Saddle River, NJ, USA, 1994.

16
3Gestão de Riscos
A gestão de risco é um meio de identificar e medir riscos de forma organizada. Com
essa gestão é possível selecionar e gerenciar opções para lidar com esses riscos quando eles de
fato acontecerem. Antigamente, os gerentes de projetos não possuíam técnicas e tecnologias
suficientes para quantificar os riscos, reagir aos riscos, desenvolver planos de contingências
e manter registros de lições aprendidas. Basicamente, o conhecimento para lidar com riscos
vinha de gestores mais experientes(sênior), que tinham mais conhecimento para sair das várias
situações adversas. Atualmente, os gerentes sênior estão estimulando e dando condições para que
os próprios gerentes do projetos tomem decisões relacionadas a gestão de riscos (KERZNER,
2016).
Este capítulo apresenta a descrição dos riscos pressupostos para o projeto e os planos de
redução e contingência desses.
3.1 Riscos do Projeto
A gestão de risco nos incentiva a olhar para o futuro, prever o que pode dar errado e,
então, desenvolver estratégias de contingência para diminuir os prejuízos (KERZNER, 2016).
Com vista a isso, foram definidos possíveis riscos ao desenvolvimento do SIGAP. Esses riscos
são apresentados na Tabela 3.

Capítulo 3. Gestão de Riscos 17
Tabela 3 – Tabela de Riscos do SIGAP
Risco Descrição Impacto Probabilidade
001 Perder informações do banco de dados Catastrófico 5%
002 O time não recebeu o treinamento necessário Crítico 70%
003 O cliente não possui ideia clara dos requisitos Crítico 60%
004 A tecnologia adotada é nova para a equipe Crítico 30%
005
A equipe que trabalha no projeto não continua
depois da entrega do produto
Moderado 90%
006 Não trabalhou com o cliente antes Moderado 85%
007
Os prazos estabelecidos são demasiadamente
apertados
Moderado 80%
008
A equipe só está disponível em tempo parcial
para o projeto
Moderado 80%
009
O software precisa se integrar a outras
ferramentas
Moderado 60%
010
O cliente não possuía sofisticação técnica em
termos de software
Moderado 45%
011 A equipe trabalhando no projeto é reduzida Moderado 40%
012 A equipe tem alta rotatividade Moderado 30%
013 O cliente não participou das revisões do projeto Moderado 20%
014 Primeiro trabalho nesta área de negócio Marginal 50%
015 Falha em Equipamentos Marginal 30%
3.2 Redução e Contingência de Riscos
Para uma antecipação aos riscos, foram elencados planos para redução e contingência.
Assim é possível evitar ao máximo os problemas e caso sejam inevitáveis, já esteja traçado um
plano de ação para contorna-lo o mais breve possível, evitando a perda de recursos. Esses planos
estão elencados nas Tabelas que seguem.
Tabela 4 – Risco 1
Risco: Perder informações do banco de dados
Código: 001 Probabilidade: 5% Impacto: Catastrófico
Descrição: Perder as tabelas do banco de dados da aplicação
Estratégia de Redução: Fazer backups frequentes com um intervalo pre determinado em outro
banco de dados espelhado ao original, de forma que a perda seja mínima ou nenhuma.
Plano de Contingência: Restaurar o backup do banco de dados espelho para o banco de
dados de produção.
Pessoa Responsável: Samila Ruane
Status: Simulação Completa

Risco: O time não recebeu o treinamento necessário
Código: 002 Probabilidade: 70% Impacto: Crítico
Descrição: O treinamento do time para realizar o projeto é inexistente ou insuﬁciente, ou seja
o time não conhece, ou conhece pouco, as ferramentas utilizadas no desenvolvimento,
casos assim induz o tempo de produção a aumentar e gera atrasos para o projeto.
Estratégia de Redução:
a. Promover treinamento a equipe antes do início do projeto;
b. Contratar pessoas que conheçam boa parte das ferramentas utilizadas antes do inicio do
projeto.
Plano de Contingência:
a. Distribuir cartilhas, manuais e vídeos que deem um entendimento emergencial melhor do
problema.
b. Convidar um consultor, especialista no assunto para dar noções básicas e acompanhar o
desenvolvimento do projeto para sanar possíveis dúvidas.
Status: Simulação incompleta
Risco: 3 O cliente não possui ideia clara dos requisitos
Descrição: O cliente está indeciso sobre as funcionalidades desejadas no software, não tem
ideia do que deseja que o software possua ou não sabe explicar o problema de forma clara.
Estratégia de Redução: Entender sobre o negocio do cliente antes do inicio da fase de
levantamento de requisitos
a. Acompanhar como funciona o dia a dia no ambiente do negócio
b. Aplicar técnicas de levantamento de requisitos como questionários,workshops,
brainstorming, entre outras técnicas conhecidas e que sejam adequadas àquele ambiente
Risco: A tecnologia adotada é nova para a equipe
Descrição: A equipe nunca trabalhou com a tecnologia requisitada
Estratégia de Redução: Promover constante atualização com as tecnologias de mercado,
aﬁm de ter as melhores tecnologias para com a empresa
Plano de Contingência: Capacitar a equipe através de cursos e tutoriais.
Pessoa Responsável: Anderson Nunes

Risco: A equipe que trabalha no projeto não continua depois da entrega do produto
Código: 005 Probabilidade: 90% Impacto: Moderado
Descrição: A equipe é realocada ou desfeita após a conclusão do projeto
Estratégia de Redução: Investir em documentação de qualidade. Manter uma boa linguagem e
descrição dos métodos baseados na metodologia e literatura de Engenharia de Software
Plano de Contingência: Passar o conhecimento para as novas equipes. Documentar de maneira
que qualquer programador compreenda o que o sistema faz
Risco: Não trabalhou com esta área de atuação do cliente
Descrição: A equipe não conhece o cliente nem suas necessidades
Estratégia de Redução: Pesquisar o cliente em potencial e sua área de atuação.
Plano de Contingência: Marcar reuniões para que se conheça mais a fundo o cliente e sua
área de atuação
Risco: Os prazos estabelecidos são demasiadamente apertados
Descrição: Os prazos de entrega para atendimento a necessidade do cliente são curtos
a. Negociar prazos mais acessíveis;
b. Realizar um bom planejamento para otimizar o tempo de desenvolvimento;
c. Otimizar a produtividade dos funcionários;
d. Tentar utilizar componentes pré-moldados ou templates que agilizem o desenvolvimento;
e. Reutilizar módulos já desenvolvidos.
a. Contratar mais proﬁssionais para aumentar a produtividade e por consequência aumentar
o orçamento do produto;
b. Aumentar o expediente de trabalho no projeto;
c. Dedicar equipes em tempo integral ao projeto.
Pessoa Responsável: Rafael Rabelo

Risco: A equipe só está disponível em tempo parcial para o projeto
Descrição: A equipe está alocada em vários projetos simultâneos e consequentemente
não está em tempo integral dedicada ao projeto
a. Destacar uma parte da equipe para ficar dedicada ao projeto seccionando os seus membros;
b. Planejar terceirização de parte do projeto para desafogar a equipe;
a. Contratar mais profissionais para ficarem dedicados ao projeto;
b. Aumentar o expediente da equipe e consequentemente custear horas extras;
c. Parar os outros projetos em andamento para dedicar-se somente a um.
Risco: O software precisa se integrar a outras ferramentas
Descrição: O software precisa integrar-se ou funcionar com outros softwares
a. Ter a documentação do(s) softwares ao qual o seu se integrará;
b. Usar o software para entender melhor seu fluxo e funcionamento.
a. Fazer engenharia reversa para entender o funcionamento do outro software;
b. Procurar os desenvolvedores do software para saber mais detalhes da implementação;
Risco: O cliente não possuía sofisticação técnica em termos de software
Descrição: O cliente não possuí conhecimento técnico em termos de software para pensar melhor
a sua necessidade
Estratégia de Redução: Dar instruções prévias ao cliente
Plano de Contingência: Conduzir o cliente e orienta-lo quanto a melhor alternativa de software
para atender sua necessidade
Pessoa Responsável: Sílvio Passos

Risco: A equipe trabalhando no projeto é reduzida
Descrição: Se dispõe de pouco pessoal para realizar o projeto
Estratégia de Redução: Alocar mais pessoas ao projeto
Plano de Contingência: Aumentar o expediente da equipe
Risco: A equipe tem alta rotatividade
Descrição: A equipe do projeto tem alta rotatividade
Estratégia de Redução: Documentar os processos para que um membro novato possa se
inteirar com facilidade
Plano de Contingência: Membros mais experientes da equipe inteirem os novatos sobre
o andamento do projeto
Risco: O cliente não participou das revisões do projeto
Descrição: O cliente não esteve presente para checar se o projeto
estava atendendo sua necessidade
Estratégia de Redução: Convidar o cliente para estar conferindo o andamento do projeto
Plano de Contingência: Realizar reunião para apresentar o projeto ao cliente
Pessoa Responsável: Marcos Felipe
Risco: Primeiro trabalho nesta área de negócio
Código: 014 Probabilidade: 50% Impacto: Marginal
Descrição: Não possui experiência na área de negócio do cliente
Estratégia de Redução: Estudar sobre a área de negócio do cliente
Plano de Contingência: Consultar o cliente sobre sua área de negócio

Risco: Falha em Equipamentos
Código: 015 Probabilidade: 30% Impacto: Marginal
Descrição: Algum equipamento de desenvolvimento pode dar defeito
Estratégia de Redução: Dar manutenção regular nos equipamentos.
Plano de Contingência: Ter Equipamentos de Reserva

23
4Planejamento Temporal
O Planejamento Temporal é uma das partes mais importantes do Projeto de Software.
Nesta etapa conseguimos identificar e elucidar as tarefas e suas dependências em todo o Projeto
de Software, além de mostrar toda a duração do projeto para uma melhor monitoria por parte
dos Gerentes e Clientes.
4.1 Conjunto de Tarefas do Projeto
Esta seção é responsável por descrever o Modelo de Processo ao qual foi escolhido para
o Projeto e as Tarefas que irão compor o modelo. No contexto do HU, decidimos utilizar o
Modelo de Processo Iterativo-Incremental, tendo como metodologia a SCRUM, em vista que
a empresa habita em um cenário dinâmico. Desta forma as entregas dos artefatos (partes do
software) são realizadas ao fim de cada Sprint ao Cliente, e este pode sugerir mudanças em
algum destes artefatos. As Tarefas do Projeto foi dividida em 4, porém por ser a metodologia
Scrum não utilizamos o modelo 40%/20%/40% (4/2/4),Tabela 2, por termos um planejamento
entre as fases e a codificação levará mais tempo do que os outros aspectos. Definimos um
modelo aproximadamente 30/40/30, fazendo uma adaptação com o modelo visto na literatura de
Engenharia de Software, como segue na Tabela 19.
Tabela 19 – Tempo Estimado em Cada Tarefa Macro do Projeto
Tarefas Porcentagem (%)
Tempo - Dias de
Trabalho
Planejamento 3% 5
Requisito-Análise-
Desenho
29% 40
Codificação 39% 55
Testes 29% 40

Capítulo 4. Planejamento Temporal 24
4.2 Diagrama de Gantt
A Figura 7 traz o detalhamento de todas as tarefas que serão realizadas durante o processo
de desenvolvimento do projeto e seu tempo de duração em forma de gráfico de Gantt. Já a Figura
8 é um destacamento para a codificação em Sprints e ampliamos para uma melhor visualização
da Figura. Para desenhar o gráfico foi utilizada a ferramenta online Smartsheet 1.
Figura 7 – Diagrama de Gantt
1 https://www.smartsheet.com/

Figura 8 – Diagrama de Gantt - Codiﬁcação em Sprints
1. Planejamento: Esta fase foi dividida em duas:
• Levantamento dos Requisitos: Deﬁnição e Delimitação dos Problemas. Reunião com
os Clientes e Administradores: Obtenção dos dados por meio de um questionário
direcionado ao problema.
• Validação de Requisitos: Validação do documento produzido com o sistema que o
cliente deseja, divididos em 3 tipos de requisitos.

a) Requisitos Funcionais: Delimitação dos requisitos que fazem parte da construção
de uma parte do sitema.
b) Requisitos Não-Funcionais: Delimitação dos requisitos que não são ligados
diretamente com a construção do sistema, mas que delimitam ou restringem
propriedades do sistema.
c) Requisitos Inversos: Delimitação dos requisitos que estão relacionados com o
que não deve ocorrer no sistema.
2. Requisito-Analise-Desenho: Esta fase foi dividida em:
• Criação dos Casos de Uso: Descreve a iteração com outro usuário/sistema.
• Criação dos Diagramas de Classe: Representa os objetos ou entidades do projeto e
seus relacionamentos.
• Definição da Arquitetura do Projeto: A arquitetura é em camadas, Interface do
Usuário, Controladores e Banco de Dados.
• Revisão das Especificações: Após a Criação dos Diagramas, faz-se necessário revisar
junto ao Cliente se todas as informações passadas estão presentes nestes diagramas.
3. Codificação: Esta fase foi dividida em Sprints:
• Sprint 1:
a) Desenvolvimento - AtendimentoController: Desenvolvimento de uma das 6
classes chaves, e suas classes de suporte.
b) Testes e Validação: Teste de Unidade para procurar falhas ocasionadas por
defeitos de lógica.
c) Apresentação da Sprint 1 ao Product Owner: Apresentação da 1º parte do
projeto/sistema ao Cliente e/ou Usuário.
• Sprint 2:
a) Revisão da Sprint 1: Possíveis e/ou Prováveis Correções da 1º parte do Sistema.
b) Ajustes do Product Backlog para Sprint 2: Fazer as correções definidas na
Revisão.
c) Desenvolvimento - AgendamentoController: Desenvolvimento de uma das 6
d) Testes e Validação: Teste de Unidade e Integração para procurar falhas ocasiona-
das por defeitos de lógica e integração entre os módulos.
e) Apresentação da Sprint 2 ao Product Owner: Apresentação da 2º parte do
projeto/sistema ao Cliente e/ou Usuário, integrado a correções da Sprint 1.
• Sprint 3

Revisão.
c) Desenvolvimento - ColaboradorController: Desenvolvimento de uma das 6
• Sprint 4
Revisão.
c) Desenvolvimento - PacienteController: Desenvolvimento de uma das 6 classes
chaves, e suas classes de suporte.
• Sprint 5
Revisão.
c) Desenvolvimento - Tratamento: Desenvolvimento de uma das 6 classes chaves,
e suas classes de suporte.
• Sprint 6
Revisão.
c) Desenvolvimento - Gerar Relatório: Desenvolvimento de uma das 6 classes
chaves, e suas classes de suporte.

4. Testes: Esta fase foi dividida em:
• Teste de Integração: procurar falhas na integração entre os módulos, feitos em cada
Sprint e também após todas elas para não ter erros e falhas simples posteriormente..
• Teste de Sistema: teste em busca de falhas do sistema como um todo, porém ainda
não foi distribuído para o usuário.
• Teste de Aceitação: teste junto ao usuário ﬁnal, validando o comportamento do
software e se está de acordo com a especiﬁcação do cliente.

29
5Organização da equipe
Fazer as pessoas trabalharem em equipe é um grande desafio para as empresas. Uma
ótima maneira de começar é deixar clara a função de cada um.
Nesta seção será apresentada a forma de distribuição dos recursos humanos no projeto e
qual a função das pessoas envolvidas de acordo com o perfil necessário para o seu desempenho.
5.1 Estrutura da Equipe
Para execução do projeto contaremos com a participação de 3 (três) integrantes que
desempenharam funções do seu cargo, a fim de garantir o andamentos e o sucesso final do
projeto. Abaixo veremos a Tabela 20, onde são descritas as responsabilidades, funções de cada
cargo, seu responsável e o perfil necessário para ocupar este cargo.

Capítulo 5. Organização da equipe 30
Tabela 20 – Organização da Equipe
Responsável Cargo/Papel Descrição Perfil
Silvio Rodrigo
Gerente de
Projeto
Responsável pela alocação
de recursos, ajuste de
prioridades, coordenação
das interações entre clientes
e usuários, manter o foco da
equipe na meta, e
acompanhar as atividades
executadas pela equipe do
projeto
*Possuir experiência em
gerência de projetos, análise,
gerenciamento de riscos,
estimativas e planejamento.
*Ter bom relacionamento
interpessoal. *Possui
capacidade de liderança.
Samila Ruane
e Silvio Passos
Analistas de
Sistema
Responsável pelo
levantamento de requisitos e
atividades de análise e
projeto no qual irá elaborar
todos os diagramas
necessários para a
implementação (codificação)
do produto de software.
* Ter bom conhecimento do
negócio.
* Comunicar-se bem.
Anselmo
Rodrigues
Analista de
testes
Responsável por identificar e
definir os teste necessários,
monitorar a abrangência dos
testes e avaliar a qualidade
obtida ao realizar os testes.
* Ser farejador, critico e
detalhista.
* Ter boa comunicação e
objetividade, para reportar
os defeitos
* Possuir experiência em
esforços de teste.
Samila Ruane
e Silvio Passos
Programadores
Responsável pela
implementação do produto
de software.
* Possuir experiência
codificação.
* Ter conhecimento em
Lógica de programação e
linguagens de programação.
em
Anselmo
Rodrigues
Testador
Responsável pela realização
dos testes sistêmicos.
* Possuir experiência testes.
* Ter conhecimento nos
tipos de testes.
5.2 Mecanismos de comunicação
A comunicação foi por meio de reuniões semanais entre os membros da equipe, por meio
de videoconferência e de forma presencial. Estas reuniões serviram para discutir o andamento
do projeto, onde nos reunimos juntos com o gerente de projeto.

Capítulo 5. Organização da equipe 31
5.3 Uso do Edu-Blog como ferramenta de apoio
A utilização do Edu-blog fez com que nossa equipe compreendesse o PMBOK, livro de
boas práticas de gerência de projetos, sua certiﬁcação PMP e seu órgão certiﬁcador o PMI, sendo
este primeiro utilizado diariamente por vários gerentes de projetos. A partir deste aprendizado
adquirido buscamos encaixa-lo na execução deste projeto.
O Edu-blog facilitou também na interação entre nossa equipe e as outras equipes da
disciplina, fazendo com que tivéssemos conhecimento sobre os assuntos abordados pelas outras
equipes. Como por exemplo, a utilização de ferramentas para o gerenciamento de um projeto,
metodologias ágeis ou a utilização da computação em nuvem para auxiliar no desenvolvimento
de um produto de software.
Este jeito fácil e empolgante de aprender sobre outros assuntos de diversas áreas por
meio de uma ferramenta deste tipo só veio a somar no aprendizado desta equipe.

32
6Precauções tomadas para as-
segurar e controlar a quali-
dade do produto de software
Como precauções, foram feitas adequações do projeto às melhores práticas de Gestão de
Projetos seguindo as diretrizes do Project Management Body of Knowledge (PMBOK), atráves
da contratação de consultoria especializada. Além disso, a equipe alocada a este projeto fará uso
dos padrões previamente estabelecidos para a codiﬁcação e documentação e teste do software
melhorando assim a qualidade do produto de software.

33
Referências
KERZNER, H. Gestão de Projetos-: As Melhores Práticas. [S.l.]: Bookman Editora, 2016.
Citado na página 16.
LORENZ M.; KIDD, J. Object-oriented software metrics: a practical guide. [S.l.]: Prentice-Hall,
Inc., 1994. Citado 2 vezes nas páginas 13 e 14.

SIGAP Plano Projeto

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a SIGAP Plano Projeto

Semelhante a SIGAP Plano Projeto (20)

SIGAP Plano Projeto