1.
UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
CURSO DE SISTEMAS DE INFORMAÇÃO
PLANO DE PROJETO DE SOFTWARE
para produtos da Lacertae SW
Caio Vinicius Meneses Silva
João Gabriel Leite Lima
Lays Cruz Lopes
Lizianne M. G. Menezes Sales
Maicon Matheus Santana
Robson Correia Luz
Docente: Dr. Rogério Patrício Chagas do
Nascimento
São Cristóvão
2017
Departamento de Computação/UFS

2.
UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
CURSO DE SISTEMAS DE INFORMAÇÃO
PLANO DE PROJETO DE SOFTWARE
para produtos da Lacertae SW
Trabalho apresentado ao Prof. Dr. Rogério
Patrício Chagas do Nascimento do Curso
de Sistemas de Informação da
Universidade Federal de Sergipe, como
requisito parcial para obtenção de nota da
disciplina Gerência de Projetos –
COMP0295.
Docente: Dr. Rogério Patrício Chagas do
Nascimento
São Cristóvão
2017

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 ........................................................................................................ 6
2.1 Dados históricos utilizados para as estimações ................................................................. 6
2.2 Técnicas de estimação e resultados ................................................................................... 6
2.2.1 Técnica de estimação............................................................................................... 7
2.3Resultados ............................................................................................................................. 8
2.4Recursos do projeto............................................................................................................... 9
2.4.1 Recursos Humanos.................................................................................................... 9
2.4.2 Recursos de Software ................................................................................................ 9
2.4.3 Recursos de Hardware............................................................................................... 9
3. Análise e Gestão de Riscos.................................................................................................. 9
3.1 Riscos do projeto .............................................................................................................. 10
3.2 Tabela de riscos................................................................................................................ 11
3.3 Redução e Gestão do Risco.............................................................................................. 12
4. Planejamento temporal..................................................................................................... 19
4.1 Conjunto de tarefas do Projeto.......................................................................................... 19
4.2 Diagrama de Gantt............................................................................................................ 21
5. Organização do pessoal..................................................................................................... 23
5.1 Estrutura da equipe............................................................................................................ 23
5.2 Mecanismos de comunicação............................................................................................ 23
5.3 Uso do Edu-blog como ferramenta de apoio..................................................................... 24
6. Precauções tomadas para assegurar e controlar a qualidade do produto de SW ....... 24

4.
1. Introdução
Esta seção fornece uma visão geral do projeto de software.
1.1 Âmbito do projeto
O Bariatric Dashboard System é um sistema desenvolvido para o gerenciamento
de cirurgias bariátricas do Hospital Universitário da Universidade Federal de Sergipe.
Permitindo o acompanhamento de todo o processo dos pacientes pelos profissionais da
saúde de diversas especialidades que irão decidir se o paciente está apto ou não para a
cirurgia através do sistema.
1.2 Funções principais do produto de software
O Bariatric Dashboard System possui usuários (recepcionista, paciente,
profissional de saúde) que irão interagir com o sistema e utilizar as funções do produto
de software. Na Figura 1 pode ser visto o diagrama de caso de uso que descreve o
cenário e as principais funções do produto de software.
Figura 1 - Diagrama de Caso de Uso
Fonte: Autores
Em síntese à Figura 1, temos que as principais funções do produto de software são:
 Manutenir Paciente (Cadastrar/Consultar/Alterar/Excluir Pacientes);
 Manutenir Usuários (Cadastrar/Consultar/Alterar/Excluir Usuários);
 Manutenir Profissional da Saúde (Cadastrar/Consultar/Alterar/Excluir
Profissionais da Saúde);
 Manutenir Especialidade (Cadastrar/Consultar/Alterar/Excluir Especialidades);

5.
 Manutenir Ocorrência (Cadastrar/Consultar/Alterar/Excluir Ocorrências)
 Login de usuários;
 Gerar Relatório.
Além das funções descritas no diagrama de caso de uso, o produto de software
conterá as seguintes funções:
 Exibir dashboard com informações da avaliação do paciente;
 Avaliar a aptidão do paciente para uma determinada especialidade médica;
 Painel de avaliação em que o profissional da saúde tem acesso aos dados
pessoais do paciente, podendo registrar as consultas médicas e as observações
que foram feitas durante as mesmas, além de pode aprovar ou reprovar um
paciente;
 Aprovar paciente para a cirurgia.
1.3 Requisitos comportamentais ou de performance
A. Usabilidade
 Os usuários deverão visualizar a situação de todas as especialidades de um
paciente de uma forma rápida e simples;
 O sistema deverá possuir uma interface amigável, ou seja, prazerosa ao usuário e
de fácil manuseio e aprendizado.
B. Confiabilidade
 O sistema deve operar sem falhas durante todo o tempo de execução com o
usuário.
 O sistema deve assegurar que os dados persistidos no banco de dados foram
realizados com sucesso e sem falha.
C. Desempenho
 O sistema não deverá demorar mais de 5 segundos para processar informações,
seja ela qual for.
D. Segurança
 A senha e outros campos de entrada de dados sensíveis deverão ser mascarados.
 O sistema deve preservar os dados do paciente e não deve possibilitar que
usuários não autorizados os acessem.

6.
1.4 Gestão e Restrições Técnicas
As restrições técnicas são condições que não devem ocorrer no software. As restrições
do Bariatric Dashboard System são:
 O paciente nunca deverá ser excluído, uma vez que tenha iniciado alguma
avaliação.
 O profissional de saúde nunca deverá ser excluído, uma vez que tenha iniciado
alguma avaliação.
 Um usuário do sistema, que não seja o psicólogo do paciente, jamais poderá acessar
informações pessoais da avaliação psicológica.
 Um paciente não poderá ser encaminhado a cirurgia se todas as etapas não
estiverem com o status “Concluído”.
2. Estimativas do projeto
Esta seção fornece as estimações de custo, esforço e tempo.
2.1 Dados históricos utilizados para as estimações
Neste projeto não foram utilizados dados históricos para as estimações visto que é um
projeto inicial 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. A
técnica escolhida foi a Lorenz e Kidd, orientada a objetos, adotada pela Lacertae
Software. O conjunto de métricas de Lorenz e Kidd foi proposto por Lorenz e Kidd
(1994).
Eles propuseram algumas métricas baseadas em classes divididas entre as
categorias: (1) tamanho: baseada na contagem de atributos e operações da classe
individualmente e na média para um valor do sistema como um todo; (2) herança:
avaliação de como as operações são reutilizadas através da hierarquia de classe; (3)
características internas: 32 avaliações de coesão; e (4) características externas:
acoplamento e reutilização.

7.
2.2.1 Técnica de estimação
Para utilização da técnica escolhida é necessário seguir alguns passos:
Passo 1: Identificar e determinar, por meio de contagem, o total de classes-chaves
presentes no diagrama de classes de domínio. As classes-chaves são classes do
Diagrama de Classes de Domínio que estão diretamente ligadas com a regra de negócio,
identificadas no levantamento de requisitos.
Passo 2: Com o número de classes chaves definido, agora é necessário definir o número
de classes de suporte/apoio. Para isso, é preciso classificar o tipo de interface para a
aplicação, e para cada uma destas existe um respectivo multiplicador. A aplicação pode
não ter nenhuma interface e possuir multiplicador igual a 2,0; interface baseada em
texto, com multiplicador igual a 2,25; GUI (GraphicalUser Interface) simples, com
multiplicador igual a 2,5; ou GUI (GraphicalUser Interface) complexa e possuir
multiplicador igual a 3,0.
Passo 3: Neste passo, faz-se o cálculo para obter o número estimado de classes de apoio.
Nº de Classes Chaves x Multiplicador correspondente
Passo 4: Agora, multiplicar o número total de classes, ou seja, nº classes-chaves + nº
classes de apoio pelo número médio de unidades de trabalho (dia-pessoa) por classe. Os
autores desta técnica sugerem 15 a 20 pessoas-dia por classe.
Nº de total de Classes x Nº médio de unidades de
trabalho
E como resultado da aplicação dos passos descritos obtém-se a estimativa do tempo
necessário para a realização do projeto.

8.
2.3 Resultados
Para o cálculo da estimativa de tempo foi utilizado o Diagrama de Classes de
Domínio exposto na Figura 2.
Figura 2 - Diagrama de Classe de Domínio
Fonte: Autores
Os resultados gerados pela aplicação da técnica de estimação são:
 Classes Chaves do Software: Pessoa, Paciente, Avaliação, Especialidades,
ProfissionalDeSaude e Usuário.
 Tipo das classes de suporte: GUI (GraphicalUser Interface) simples;
 Valor Multiplicador: 2,5;
 Classes de suporte: 6 (classes chaves) x 2,5 (Valor multiplicador) = 15 classes de
suporte;
 Total de classes: 6 (classes chaves) + 15 (classes suporte) = 21 classes;
 Número médio de unidades de trabalho: 16 dias-pessoa;
 Tempo previsto: 21 (classes) x 16 (dias) = 336 dias por pessoa para a construção
das classes;

9.
 Considerando que a equipe é formada por 6 pessoas, chega-se então ao total de
56 dias;
 Considerando que um mês tem 22 dias úteis, o tempo total do projeto será de 2
meses e 12 dias.
2.4 Recursos do projeto
Nesta seção são listados os recursos humanos, de software e hardware necessários
para o desenvolvimento do projeto.
2.4.1 Recursos Humanos
A equipe é composta por (um) gerente, (dois) programadores, (dois) analistas de
sistema e (um) testador de software.
2.4.2 Recursos de Software
No desenvolvimento deste projeto serão utilizados os seguintes softwares: Eclipse
(desenvolvimento do código e criação de telas), PostgreSQL (banco de dados),
Selenium (testes).
2.4.3 Recursos de Hardware
As configurações necessárias nas quatro estações de trabalho estão especificadas no
Quadro 1.
Quadro 1 – Configurações das estações de trabalho
Produto Especificação
Processador
Intel® Core™ i5 Processor (4M Cache, upto
3.10 GHz) ou superior
Disco Rígido 500 GB de armazenamento ou superior.
Memória Ram 4 GB de memória RAM ou superior
Fonte: Autores

10.
3. Análise e Gestão de Riscos
Nesta seção discutem-se os riscos do projeto e como geri-los.
3.1 Riscos do projeto
O Quadro 2 mostra os riscos do projeto classificados pela sua categoria (projeto,
técnico, negócio, comum e especial). Um risco é considerado de projeto quando ele
ameaça o plano de projeto; técnico quando ameaça à qualidade e o planejamento
temporal do software; negócio quando ameaça à viabilidade do software; comum
quando o risco é previsível de acontecer e especial quando o risco é imprevisível.
Quadro 2 – Riscos do Projeto
Riscos Projeto Técnico Negócio Comum Especial
001
Falta de conhecimento das
regras de negócio
X X
002
Ausência de recursos
financeiros para
investimento do
desenvolvimento do
produto de software
X X
003
Falha na coleta de
requisitos
X X
004
Não cumprimento da
entrega do software na
data acordada
X X
005
Ausência de
documentação no projeto,
o que pode dificultar a
manutenabilidade do
software
X
006
Ausência de infraestrutura
de rede para utilização do
Sistema.
X
007
Perda de dados do banco
de dados
X
008
Ausência de ferramentas
de teste de software
X
009
Insuficiência de pessoas
na equipe
X X
010
Falta de capacitação da
equipe de
desenvolvimento
X X
011 Mudanças de requisitos X X
012
Falta de conhecimento em
tecnologias exigidas pelo
cliente no
desenvolvimento do
software (Ex: SVN e
X

11.
Java)
013
Falta de engajamento dos
usuários no uso e na
validação do software e
resistência deles no uso
do mesmo.
X X
014
Inconsistências no uso de
padrões de projeto no
desenvolvimento do
software.
X X
015
Pouco treinamento da
equipe
X X
016
Usuários com baixo
conhecimento no uso de
tecnologias
X X
017
Cliente não teve
expectativas superadas
X X
018
Ferramentas para
integração do time
X X
Fonte: Autores
3.2 Tabela de riscos
O Quadro 3 mostra os riscos identificados anteriormente classificando-os quanto a
sua probabilidade (0...90%) de ocorrência e impacto (insignificante ou desprezível,
marginal, moderado, crítico e catastrófico) esperado caso ocorra.
Quadro 3 – Probabilidade e impacto dos riscos do projeto
Riscos % Probabilidade Impacto
001
Falta de conhecimento das regras
de negócio
75% Catastrófico
002
Ausência de recursos financeiros
para investimento do
desenvolvimento do produto de
software
75% Catastrófico
003 Falha na coleta de requisitos 50% Catastrófico
004
Não cumprimento da entrega do
software na data acordada
50% Catastrófico
005
Ausência de documentação no
projeto, o que pode dificultar a
manutenabilidade do software
30% Catastrófico
006
Ausência de infraestrutura de rede
para utilização do Sistema.
30% Catastrófico
007 Perda de dados do banco de dados 10% Catastrófico
Ponto de Corte
008 Ausência de teste de software 75% Crítico
009 Insuficiência de pessoas na equipe 75% Crítico
010 Falta de capacitação da equipe de 30% Crítico

12.
desenvolvimento
011 Mudanças de requisitos 30% Crítico
012
Falta de conhecimento em
tecnologias exigidas pelo cliente
no desenvolvimento do software
(Ex: SVN e Java)
25% Crítico
013
Falta de engajamento dos usuários
no uso e na validação do software
e resistência deles no uso do
mesmo.
20% Crítico
014
Inconsistências no uso de padrões
de projeto no desenvolvimento do
software.
20% Crítico
015 Pouco treinamento da equipe 10% Moderado
016
Usuários com baixo
conhecimento no uso de
tecnologias
10% Moderado
017
Cliente não teve expectativas
superadas
30% Marginal
018 Ferramentas para integração do
time
20% Marginal
Fonte: Autores
3.3 Redução e Gestão do Risco
Nesta seção apresenta-se as ações a serem tomadas para prever, reduzir ou gerir os
riscos identificados no Quadro 2.
Quadro 4 – Risco 001
Falta de conhecimento das regras de negócio
Risco: 001 Probabilidade: 75% Impacto: Catastrófico
Descrição: Possibilidade de o software não funcionar apropriadamente devido à falta
de conhecimento das regras de negócio pela equipe.
Estratégia de redução: Estudar como funcionam os processos da área da saúde.
Plano de contingência:
A- Reuniões com a equipe e cliente para que as regras de negócio sejam melhor
esclarecidas.
B- Pesquisar sobre como as regras de negócio devem ser aplicadas corretamente.
C- Entrar em contato com pessoas de confiança que entendam sobre o assunto.
Pessoa responsável: Robson Correia Luz
Status: Simulação incompleta.
Fonte: Autores
Quadro 5 – Risco 002
Ausência de recursos financeiros para investimento do desenvolvimento do
produto de software
Risco: 002 Probabilidade: 75% Impacto: Crítico

13.
Descrição: O hospital não possui recursos financeiros suficientes para investir no
desenvolvimento produto de software.
Estratégia de redução: Evitar gastos desnecessários.
Plano de contingência:
A- Reduzir o escopo do projeto.
B- Remover membros de áreas menos essenciais.
C- Gastar menos recursos com documentação, testes e verificações.
Pessoa responsável: Robson Correia Luz
Status: Simulação incompleta.
Fonte: Autores
Quadro 6 – Risco 003
Falha na coleta de requisitos
Risco: 003 Probabilidade: 50% Impacto: Crítico
Descrição: A equipe teve um mau entendimento na hora de levantar os requisitos que
poderão ocasionar erros no futuro.
Estratégia de redução: Tirar todas as dúvidas referentes aos requisitos na reunião
com o cliente para que não haja erros.
Plano de contingência:
A- Reunião para validação dos requisitos com o cliente.
B- Definir como prioridade a correção dos requisitos na documentação e os que
já foram implementados.
C- Convocar cliente a acompanhar o desenvolvimento com certa frequência.
Pessoa responsável: Robson Correia Luz
Status: Simulação incompleta.
Fonte: Autores
Quadro 7 – Risco 004
Não cumprimento da entrega do software na data acordada
Risco: 004 Probabilidade: 50% Impacto: Catastrófico
Descrição: O prazo acordado com o cliente é curto visto que, o contrato exigia um
prazo apertado devido a necessidade urgente do produto de software.
Estratégia de redução: Implantação de metodologia ágil para desenvolvimento do
produto de software, realizando pequenas entregas de alto valor para o cliente. E
renegociação com o cliente para que alguns requisitos de software sejam entregues
durante a fase de manutenção do software.
Plano de contingência:
A- Realização de capacitação da equipe em um curso de metodologias ágeis para
que estejam adaptados a nova forma de trabalho.
B- Reunião com o cliente para explicar o problema e propor o ajuste a forma de
trabalho.
C- Redefinição dos requisitos mínimos do software e dos requisitos que podem
ser desenvolvidos em outro momento do software.
Pessoa responsável: João Gabriel Leite Lima
Status: Simulação incompleta.
Fonte: Autores

14.
Quadro 8 – Risco 005
Ausência de documentação no projeto, o que pode dificultar a manutenabilidade
do software
Risco: 005 Probabilidade: 30% Impacto: Catastrófico
Descrição: Devido ao prazo curto para entrega do produto de software, a
documentação em alguns momentos se mostrou escassa. Por exemplo, as
funcionalidades do software foram documentadas de maneira resumida, pouco
explicativa. E esta pouca documentação pode fazer com que, se outras pessoas forem
destinadas a manutenção necessite muito tempo para adquirir conhecimento sobre as
regras do negócio e sobre a codificação do software.
Estratégia de redução: Implantar um padrão de documentação do software, destinar
um tempo específico para documentação como passo obrigatório do ciclo de
desenvolvimento de software, onde o cliente deve ter atualizações sobre a
documentação do software.
Plano de contingência:
A- Adoção de ferramentas wiki para documentação do software.
B- Definição de 30% do tempo do ciclo de desenvolvimento de software para
documentação do software.
C- Definição do padrão de documentação de software, IEEE 829.
Pessoa responsável: João Gabriel Leite Lima
Status: Simulação completa.
Fonte: Autores
Quadro 9 – Risco 006
Ausência de infraestrutura de rede para utilização do Sistema
Risco: 006 Probabilidade: 30% Impacto: Catastrófico
Descrição: O projeto foi desenvolvido para um hospital público, de grande porte do
estado de Sergipe, o Hospital Universitário, como todos os hospitais públicos
possuem verba curta e menor ainda para investimento em tecnologia. E o pouco
investimento reflete em infraestrutura escassa, já que o sistema por ser Web, necessita
de um servidor para hospedagem e uma boa internet wifi disponível para os usuários
acessarem o sistema.
Estratégia de redução: O hospital pode buscar parcerias com outros órgãos
públicos, para doação de infraestrutura. Além de buscar empresas para parcerias em
doação de valores e até hardwares para montar uma infraestrutura mínima necessária
para o uso.
Plano de contingência:
A- A equipe de desenvolvimento deve definir a infraestrutura mínima para que o
sistema possa ser usado de forma minimamente perfeita no Hospital
Universitário.
B- A equipe de desenvolvimento deve analisar o ambiente atual, para dizer se é
um ambiente que oferece o que é necessário ou se precisa de melhoria na
infraestrutura.
C- Os gestores do Hospital devem elaborar um plano de ações de busca para
conseguir doações de equipamentos para a mudança na infraestrutura.
D- Os gestores do Hospital devem buscar doações e parcerias sendo em outros
órgãos públicos ou em empresas particulares.
Pessoa responsável: João Gabriel Leite Lima
Status: Simulação incompleta.

15.
Fonte: Autores
Quadro 10 – Risco 007
Perda de dados do banco de dados
Risco: 007 Probabilidade: 10% Impacto: Catastrófico
Descrição: Possibilidade de haver alguma falha no banco de dados e perder dados
importantes.
Estratégia de redução: Utilizar técnicas de espelhamento da base de dados.
Plano de contingência:
A- Fazer uso periódico de backups localmente.
B- Usar a redundância de dados.
C- Efetuar backups na nuvem.
Pessoa responsável: Caio Vinícius Meneses Silva
Status: Simulação incompleta.
Fonte: Autores
Quadro 11 – Risco 008
Ausência de teste de software
Risco: 008 Probabilidade: 75% Impacto: Crítico
Descrição: O produto foi entregue ao cliente sem passar pela fase de testes.
Estratégia de redução: Utilizar o cliente como “testador”.
Plano de contingência:
A- Entregar uma versão Beta
B- Possuir uma boa equipe de suporte, para atender as demandas de correções.
C- Disponibilizar um membro da equipe de desenvolvimento para ir
implementando aos poucos técnicas de teste de software.
Pessoa responsável: Caio Vinícius Meneses Silva
Status: Simulação incompleta.
Fonte: Autores
Quadro 12 – Risco 009
Insuficiência de pessoas na equipe
Risco: 009 Probabilidade: 75% Impacto: Crítico
Descrição: Uma equipe de desenvolvimento pequena pode ocasionar atraso na
entrega do produto caso a demanda do projeto seja maior que a equipe possa suportar.
Estratégia de redução: Se o projeto demanda mais tempo do que a equipe de
desenvolvimento pode suportar, datas e prazos devem ser readequados ao tamanho da
equipe.
Plano de contingência:
A- Uso de uma metodologia ágil de desenvolvimento de software.
B- Caso não haja tempo suficiente para completar o desenvolvimento do produto,
decidir juntamente com todos os stakeholders quais funcionalidades têm
maior prioridade e entregá-las primeiro.
C- Contração de mão de obra qualificada como freelancers para desenvolver
pontos específicos do projeto.
Pessoa responsável: Caio Vinícius Meneses Silva
Status: Simulação incompleta.
Fonte: Autores

16.
Quadro 13 – Risco 010
Falta de capacitação da equipe de desenvolvimento
Risco: 010 Probabilidade: 30% Impacto: Crítico
Descrição: A falta de treinamento adequando pode afetar diretamente no processo de
desenvolvimento do projeto. A qualificação de profissionais tornou-se essencial para
que os projetos atinjam seus objetivos de prazos, custos, escopo, qualidade e
satisfação das partes interessadas
Estratégia de redução: Implantação de metodologias de treinamentos para equipe,
pois equipes treinadas tendem a se concentrar em maior valor agregado, tais como
atividades de planejamento, processo de reestruturação e melhoria da infraestrutura.
Plano de contingência:
A- Realização de treinamento da equipe nos processos e ferramentas que serão
utilizados no processo de desenvolvimento.
B- Reunião com toda equipe que está envolvida no processo e testar os
conhecimentos dos envolvidos, assim garantindo que a equipe está pronta para
o desenvolvimento.
C- Alocar para determinadas funções as pessoas que tiverem o maior
conhecimento do processo ou ferramenta.
Pessoa responsável: Maicon Matheus Santana Santos
Status: Simulação completa.
Fonte: Autores
Quadro 14 – Risco 011
Mudanças de requisitos
Risco: 011 Probabilidade: 30% Impacto: Crítico
Descrição: Devido a algumas incertezas nas funcionalidades, mesmo após os
requisitos terem sido levantados e o projeto já estar em desenvolvimento, mudanças
nos requisitos podem ocorrer.
Estratégia de redução: Estudar a real situação do cliente, e entender o domínio da
aplicação e não ficar preso só ao que o cliente passa, toda informação é importante.
Plano de contingência:
A- Adoção de ferramentas de prototipagem.
B- Desenvolver protótipos e validar com o cliente.
C- Analisar o impacto de qualquer tipo de mudança no projeto, por menor que
seja.
D- Elaborar e atualizar o documento de requisitos do software.
E- Verificar se os requisitos estão de acordo com os modelos propostos.
Pessoa responsável: Maicon Matheus Santana Santos
Status: Simulação Incompleta.
Fonte: Autores
Quadro 15 – Risco 012
Falta de conhecimento em tecnologias exigidas pelo cliente no desenvolvimento
do software (Ex: SVN e Java).
Risco: 012 Probabilidade: 25% Impacto: Crítico
Descrição: O cliente solicitou o desenvolvimento do software com ferramentas onde
o mesmo tem certo conhecimento, para que o processo de suporte e utilização seja
mais fácil.

17.
Estratégia de redução: Para resolvermos esta questão, caso a equipe não seja
capacitada para determinada função, será investido em capacitação, assim atendendo
o pedido do cliente.
Plano de contingência:
A- A equipe de desenvolvimento fará os treinamentos necessários.
B- O gerente do projeto irá avaliar se a equipe está em condições para
desenvolvimento do software.
C- E o software será desenvolvido, atendendo ao pedido do cliente.
Pessoa responsável: Maicon Matheus Santana Santos
Status: Simulação completa.
Fonte: Autores
Quadro 16 – Risco 013
Falta de engajamento dos usuários no uso e na validação do software e
resistência deles no uso do mesmo.
Risco: 013 Probabilidade: 20% Impacto: Crítico
Descrição: Os usuários não compraram a ideia do sistema sendo assim não querem
validar e resistem a usá-lo.
Estratégia de redução: Para resolver essa questão os gestores do hospital e os
gerentes de projetos devem mostrar aos usuários os benefícios que serão obtidos no
cotidiano deles.
Plano de contingência:
A- Os gestores do hospital juntamente com o gerente de projetos devem fazer um
cronograma em escalas (para que não prejudique o trabalho do hospital) para
apresentar aos usuários do sistema os benefícios para cada um da utilização do
novo software;
B- Os gestores do hospital devem elaborar campanhas de divulgação entre os
usuários e o público (pacientes) mostrando a evolução dos processos com o
novo sistema, isso trará um ambiente de expectativas positivas sobre o
software.
Pessoa responsável: Lays Cruz Lopes
Status: Simulação completa.
Fonte: Autores
Quadro 17 – Risco 014
Inconsistências no uso de padrões de projeto no desenvolvimento do software.
Risco: 014 Probabilidade: 20% Impacto: Crítico
Descrição: Foram definidos alguns padrões de projeto para o desenvolvimento do
software proposto, porém o pouco conhecimento e a inexperiência no uso de padrões
do projeto fez com que o uso dos mesmos, pudesse ser feito de forma equivocada.
Estratégia de redução: Capacitar responsáveis no projeto que pudesse garantir o uso
correto dos padrões de projetos definidos na etapa de modelagem e design no
software.
Plano de contingência:
A- Exigir capacitação da equipe envolvida no projeto;
B- O gerente do projeto deve proporcionar capacitação a equipe;
C- O gerente do projeto deve contratar um especialista para servir de
inspecionador do código para evitar codificação errada.

18.
Pessoa responsável: Lays Cruz Lopes
Status: Simulação completa.
Fonte: Autores
Quadro 18 – Risco 015
Pouco treinamento da equipe de usuários
Risco: 015 Probabilidade: 10% Impacto: Moderado
Descrição: A equipe de usuários teve um modelo de treinamento definido entre os
gestores do hospital e o gestor da equipe de desenvolvimento, porém este modelo
pode ser considerado pouco ou ineficaz pelos usuários
Estratégia de redução: Elaborar e realizar programas de treinamentos por grupos ou
individualizados, visando um acompanhamento de efetivo.
Plano de contingência:
A- Elaborar um cronograma de treinamentos por grupos e por usuários
individuais;
B- Realizar um cronograma de treinamentos por grupos e por usuários
individuais;
C- Acompanhar os usuários durante um período pós treinamento;
D- Elaborar e disponibilizar um manual do software para os usuários;
E- Disponibilizar uma central de suporte a usuários;
F- Disponibilizar visitas técnicas para análise e suporte à usuários.
Pessoa responsável: Lays Cruz Lopes
Status: Simulação incompleta.
Fonte: Autores
Quadro 19 – Risco 016
Usuários com baixo conhecimento no uso de tecnologias
Risco: 016 Probabilidade: 10% Impacto: Moderado
Descrição: Após a entrega do produto, pode ocorrer de existirem usuários do sistema
com pouca habilidade no uso de tecnologias.
Estratégia de redução: Ao fechar contrato do produto, deixar o cliente ciente das
tecnologias que deverão ser conhecidas para utilização do sistema.
Plano de contingência:
A- Verificar com a equipe a possibilidade de uma reunião com os usuários para
esclarecer dúvidas sobre a (s) tecnologia (s);
B- Propor e trazer opções de cursos da tecnologia utilizada para o (s) usuário (s) com
dificuldade.
Pessoa responsável: Lizianne Maria Gomes Menezes Sales
Status: Simulação incompleta.
Fonte: Autores
Quadro 20 – Risco 017
Cliente não teve expectativas superadas
Risco: 017 Probabilidade: 30% Impacto: Marginal
Descrição: Possibilidade do cliente não ficar satisfeito, ou seja, não ter suas
expectativas superadas com a entrega do produto;
Estratégia de redução: Entregas de incrementos durante o processo de
desenvolvimento. Dessa forma, o cliente acompanha todo o processo e ao decorrer
faz suas aprovações e modificações.
Plano de contingência:

19.
A- Reunião com o cliente e a equipe inteira para que o cliente passe para equipe o
que não o deixou satisfeito;
B- Reunião da equipe para verificar a possibilidade de mudanças e ajustes para o
gosto do cliente, dentro do que estava definido no contrato.
Pessoa responsável: Lizianne Maria Gomes Menezes Sales
Status: Simulação incompleta.
Fonte: Autores
Quadro 21 – Risco 018
Ferramentas para integração do time
Risco: 018 Probabilidade: 20% Impacto: Marginal
Descrição: A falta da adoção de integração do time pode significar um risco para a
construção do software.
Estratégia de redução: Adoção da integração contínua pela empresa.
Plano de contingência:
A- Reunião com o time para definir a adoção de uma ferramenta de emergência;
B- Estudo de várias ferramentas e até mesmo, de metodologias ágeis para
adoção.
Pessoa responsável: Lizianne Maria Gomes Menezes Sales
Status: Simulação incompleta.
Fonte: Autores
4. Planejamento temporal
Nesta seção apresentam-se as tarefas e as suas dependências de forma a estimar a
duração total do projeto.
4.1 Conjunto de tarefas do Projeto
No desenvolvimento do Bariatric Dashboard System, foi utilizado o modelo de
processo incremental e iterativo, aliado ao framework Scrum. Sendo assim, o tempo
estimado para cada etapa do projeto não foi baseado na estimativa 4/2/4 (Requisitos –
Análise – Desenho – 40%, Geração de Código – 20%, Testes – 40%). Pois o Scrum visa
atender as necessidades do cliente e realizar entregas (sprints) para validação do cliente,
podendo resultar em alterações e mudanças no planejamento.
No Quadro 22 são descritas as etapas do projeto e as tarefas de cada etapa que
devem ser executadas, bem como as sprints na etapa do desenvolvimento.
Quadro 22 – Tarefas do projeto
Etapa Tarefa
Planejamento
Visão Geral do Produto
Levantamento de Requisitos Funcionais
Levantamento de Requisitos Não-Funcionais
Levantamento de Requisitos Inversos

20.
Especificação do
Projeto
Especificação de Requisitos
Diagrama de Caso de Uso
Diagrama de Classes de Domínio
Estimação de Tempo do Projeto
Diagrama de Gantt
Realizar Gestão de Riscos
Criar Repositório do projeto
Desenvolvimento
Sprint 1
Desenvolvimento do Banco de Dados
Codificação
Manutenir Paciente
Manutenir Profissional de Saúde
Testes e Validação
Apresentação da Sprint1 ao ProductOwner
Sprint 2
Revisão da Sprint 1
Revisão da Especificação do Sistema
Ajuste do ProductBacklog para Sprint 2
Codificação
Manutenir Especialidade
Testes e Validação
Apresentação da Sprint2 ao ProductOwner
Sprint 3
Revisão da Sprint 2
Revisão da Especificação do Sistema
Ajuste do ProductBacklog para Sprint 3
Codificação
Manutenir Ocorrências
Gerar Relatórios
Testes e Validação
Apresentação da Sprint3 ao ProductOwner
Sprint 4
Revisão da Sprint 3
Revisão da Especificação do Sistema
Ajuste do ProductBacklog para Sprint 4
Codificação
Efetuar Login
Testes e Validação
Apresentação da Sprint 4 ao ProductOwner
Transição
Validação do Sistema
Testes de Aceitação
Entrega do Sistema
Fonte: Autores

21.
4.2 Diagrama de Gantt
O diagrama de Gantt tem como objetivo disponibilizar aos membros da equipe
todo o planejamento do projeto, considerando prazos e atribuições, de forma visual e de
fácil compreensão. O desenvolvimento do diagrama de Gantt foi baseado no Scrum, que
foi o framework utilizado no projeto.
Na Figura 3 são exibidas as quatro etapas planejadas para execução do projeto. A
linha do tempo citada, que caracteriza um diagrama de Gantt, tem início dia 01/11/2015
e término dia 01/02/2016, tempo estimado para execução e finalização do projeto e a
linha do tempo de execução da tarefa dentro dos prazos definidos para cada tarefa.
Figura 3 - Diagrama de Gantt resumido
Fonte: Autores
A Figura 4 apresenta o digrama de Gantt expandido com as tarefas das etapas, as
quatro sprints cada uma com tempo médio de execução de 18 dias e suasrespectivas
tarefas. Cada tarefa possui atribuído o (s) membro (s) da equipe responsável (is) pela
sua execução, data início, data fim e total de dias necessários para execução da tarefa.

22.
Figura 4 - Diagrama de Gantt expandido
Fonte: Autores
Devido a pouca legibilidade do diagrama e da linha temporal as Figuras 3, 4 e o
diagrama de Gantt completo podem ser acessados por meio do link1
.
1
https://drive.google.com/open?id=0B3L7qO5obxLkUXE4ek1RaWs2UWM

23.
5. Organização do pessoal
Nesta seção apresenta-se a forma de organização da equipe.
5.1 Estrutura da equipe
O Quadro 23 mostra a composição da equipe e os papéis desempenhados por cada
membro no desenvolvimento do Bariatric Dashboard System.
Quadro 23 – Estrutura da Equipe
Responsável (is) Papel Descrição
Lays Cruz Lopes Gerente de Projetos
O Gestor de projetos exerce a
função de planejar e controlar
a execução dos projetos com o
intuito de conduzir melhor a
equipe.
João Gabriel Leite Lima
e
Lizianne M. G. M. Sales
Analista de Sistema
O Analista de Sistemas tem a
função projetar o sistema,
atuar com análise e projeto de
sistemas, levantamento de
requisitos e regras de negócio,
mapeamento de processos e
modelagem de dados, atuará
com padrões de qualidade das
rotinas e processos e impacto
das alterações.
Caio Vinicius Meneses Silva
e
Robson Correia Luz
Desenvolvedores
O Desenvolvedor exerce a
função de codificar ou prestar
manutenção em rotinas de um
sistema especifico.
Maicon Matheus Santana Testador
O Testador exerce a função de
verificação do funcionamento
do software, localizando e
registrando as falhas e como
elas acontecem repassando-as
para a equipe de
desenvolvimento.
Fonte: Autores

24.
5.2 Mecanismos de comunicação
Os mecanismos para comunicação utilizados por nossa equipe foram:
 E-mail, devido a rápida comunicação, capacidade de armazenamento e acesso ao
histórico e também a presença de todos os componentes da equipe;
 Google Hangouts também foi uma ferramenta muito útil pela agilidade e registro
das conversas;
 WhatsApp que facilita a rápida comunicação e é de acesso fácil.
 Google drive mostrou-se uma ferramenta colaborativa muito poderosa
aproximando os membros da equipe na elaboração de documentos e papéis de
trabalho.
5.3 Uso do Edu-blog como ferramenta de apoio
O uso do Edu-Blog proporciona um aprendizado descentralizado e uniforme,
todos os assuntos disponibilizados são expostos de forma clara e flexível. Dessa forma,
entende-se que o aluno é incentivado a buscar novidades tecnológicas, proporcionando
maior conhecimento no que tange a Tecnologia da Informação. Contudo, esse processo
de aprendizado objetiva “romper” os paradigmas do ensino demasiado em sala de aula e
abrange o conhecimento extraclasse.
6. Precauções tomadas para assegurar e controlar a qualidade do produto de
SW
Com a finalidade de garantir a qualidade de todas as fases do projeto, algumas
preocupações foram tomadas:
 Testes: realizados durante todo o ciclo de vida do software. Desde o
levantamento dos requisitos até possíveis manutenções no produto depois dele
ter sido entregue, foram efetuados testes de caixa branca e caixa preta. Também
toda a documentação passou por testes.
 Reuniões diárias: segundo a metodologia Scrum são necessárias pequenas
reuniões diárias durante todo o processo para atualização do que está sendo
feito, como está sendo feito e quais as dificuldades encontradas.
 Controle de versão: para a confecção dos documentos foram utilizadas
ferramentas de controle de versão atribuindo marcos nos quais representavam
algum tipo de alteração, seja de melhoria ou correção.
 Documentação: a documentação fornece um parâmetro para avaliar o que foi
feito na prática em comparação com o que foi descrito. É composta por toda a
descrição de como o desenvolvimento foi feito.

25.
Referências
LORENZ, Mark; KIDD, Jeff. Object-oriented software metrics: a practical guide.
Prentice-Hall, Inc., 1994.