Plano de projeto final

1
UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Sistema DashBoard TI
Plano de Projeto de Software
Claudemiro José da Silva Neto, Erasmo Sena de Jesus, Leonardo
Rodrigues Paixão
São Cristóvão – Sergipe
2018

2
UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Claudemiro José da Silva Neto, Erasmo Sena de Jesus, Leonardo
Rodrigues Paixão
Sistema DashBoard TI
Plano de Projeto de Software submetido a matéria
de Gestão de Projeto requisito parcial para a
obtenção da nota final
Professor (a): Dr. Rogério Patrício Chagas do
Nascimento
São Cristóvão – Sergipe
2018
Lista de Ilustrações

3
Figura 1 – Diagrama de casos de uso DashBoard TI
Figura 2 – Representação da tela em que é efetuado login no sistema DashBoard TI.
Figura 3 – Representação da tela de cadastro de novo colaborador
Figura 4 – Representação da tela de cadastro de nova atividade
Figura 5 – Representação da tela que apresenta o Dashboard
Figura 6 – Representação da tela de cadastro de metas
Figura 7 – Representação do diagrama de classe de projeto.
Figura 8 – Representação do diagrama de Gantt.
Figura 9 – Atividades do Projeto (Diagrama de Gantt).
Lista de tabelas
Tabela 1 – Tipo de Interface do produto e respectivo multiplicador

4
Tabela 2 – Dados referentes aos dados obtidos com a aplicação das métricas de
Lorenz e Kidd (LORENZ M.; KIDD, 1994).
Tabela 3 - Estimativas dos dias de trabalho em cada etapa do projeto
Tabela 4 – Tabela de Riscos do DashBoard TI
Tabela 5 – Risco 1
Lista de quadros
Quadro 1 - Integrantes da equipe e atribuições 22

5
Lista de abreviações e siglas
HU – Hospital Universitário;
UFS – Universidade federal de Sergipe;
TI – Tecnologia da informação;

6
RF – Requisito funcional
FA – Fluxo alternativo
FE – Fluxo de erro
Sumário
1 Introdução 8
1.1 Escopo do Projeto 8
1.2 Funções principais do produto de software 8
1.2.1 Descrição de casos de uso 8
1.3 Requisitos comportamentais ou de performance 18
1.4 Gestão e Restrições Técnicas 18

7
2 18
2.1 Técnicas de estimação e resultados 19
2.2 Resultados 20
2.3 Recursos do projeto 20
2.3.1 Recursos humanos 20
2.3.2 Recursos de software 20
2.3.3 Recursos de hardware 21
2.3.4 Recursos bibliográficos 21
3. 21
3.1 Riscos do Projeto 22
3.2 Redução e contingencia de riscos 22
4. 26
4.1 Conjunto de tarefas do projeto 26
4.2 Diagrama de Gantt 26
5. 28
5.1 Estrutura da equipe 28
5.2 Mecanismo de comunicação 28
5.3 Uso do Edu-blog como ferramenta de apoio 28
6. 29
1 Introdução
1.1 Escopo do Projeto
Devido à necessidade de gerenciar as atividades exercidas pelo setor de
tecnologia do Hospital Universitário do Estado de Sergipe, também foi levado em
consideração que este controle não é realizado com ajuda de uma ferramenta
dedicada, foi desenvolvido o sistema Dash Board TI. Pois, o DashBoard TI tem como
objetivo auxiliar o gestor de TIC do HU em suas principais decisões administrativas,
por meio do controle das requisições cadastradas no sistema e dos recursos
disponíveis (quadro de funcionários). Os dados necessários para realizar este controle
estão disponibilizados em um DashBoard.

8
1.2 Funções principais do produto de software
Nesta seção são descritas as principais funcionalidades do sistema DashBoard TI
através da imagem 1, a qual demonstra o diagrama de casos de uso do software.
Figura 1 – Diagrama de casos de uso DashBoard TI.
Fonte: Próprios autores
1.2.1 Descrição de casos de uso
Nesta subseção são descritos os casos de uso do sistema DashBoard TI.
[RF001] Efetuar Login
Prioridade: ☒ Essencial ☐ Importante ☐ Desejável
Ator (es): Gestor de TI, colaborador
Requisitos
associados:
Descrição: Para ter acesso ao sistema o usuário deve efetuar Login.
Pré-condições:O usuário deve estar cadastrado no sistema para fazer Login.

9
Pós-condições: O usuário fica logado no sistema.
Fluxo principal
1. O Usuário solicita acesso ao sistema.
2. O Sistema exibe tela 1 solicitando matrícula e senha.
3. O Usuário informa matricula e senha.
4. O Sistema autentica matrícula e senha e exibe as funcionalidades para o
usuário.
5. Este caso de uso se encerra aqui.
Fluxos alternativos
[FA01] O Usuário esqueceu a senha.
1. O Usuário clica no link de “Esqueceu a senha? ” No canto inferior da tela.
2. O Sistema exibe uma tela solicitando a matricula, e-mail, nova senha e repetir
senha.
3. O Usuário preenche os campos e clica em atualizar senha.
4. O Sistema vai para o passo 2 do fluxo principal.
Fluxos de erro
[FE01] O Usuário informa senha inválida.
1. O Sistema exibe na tela uma mensagem informando que a matricula e
senha estão incorretas.
2. O Usuário repete a operação 3 do fluxo principal.
3. Caso a matricula e senha estejam corretas o Sistema autentica o usuário e
exibe as funcionalidades, senão ele exibe mensagem de erro e repete o passo
2 do fluxo principal até que os dados estejam corretos.
Figura 2 – Representação da tela em que é efetuado login no sistema DashBoard TI.

10
[RF002] Manter colaborador
Ator (es): Gestor de TI,
Requisitos
associados:
RF001
Descrição: Esse caso de uso serve para cadastrar, alterar e consultar um usuário.
Pré-condições:O usuário logado no Sistema.
Pós-condições: Alteração, Cadastro ou Consulta de usuário no sistema.
Fluxo principal
1. O gestor de TI solicita a manutenção de cadastro de um novo colaborador,
clicando no item “manter colaborador” existente no menu principal da tela 2.
2. O Sistema apresenta a tela de cadastro de colaborador e fornece as opções:
Incluir, Alterar, Consultar e encerrar.
3. O gestor de TI escolhe a opção incluir.
4. O Sistema habilita os campos.
5. O gestor de TI informa os dados: nome, matricula, e-mail, tipo de usuário.
6. O Sistema verifica se o gestor de TI não está cadastrado.
7. O Sistema verifica se todos os dados obrigatórios foram preenchidos.
8. O Sistema valida os dados.
9. O gestor de TI clica em salvar.
10. O Sistema salva os dados.
11. O Sistema exibe a mensagem: “Colaborador cadastrado com sucesso. ”
Fluxos alternativos
[FA01] O gestor de TI escolhe a opção alterar.
1. O Sistema exibe uma tela de busca para a seleção do colaborador a ser
alterado.
2. O gestor de TI escolhe colaborador a ser alterado.
3. O gestor de TI preenche os campos e clica em atualizar senha.
4. O sistema exibe os dados do colaborador selecionado.
5. O caso de uso vai para o passo 4 do fluxo principal.
[FA02] O gestor de TI escolhe a opção consultar.
1. O Sistema fornece uma tela de busca para a seleção do colaborador a ser
consultado.
2. O gestor de TI escolhe o colaborador que ele deseja consultar.
3. O Sistema exibe os dados do colaborador selecionado.

11
Fluxos de erro
[FE01] O gestor de TI cadastra um usuário do tipo colaborador já
existente.
1. O Sistema exibe na tela uma mensagem informando que o colaborador já
está cadastrado.
2. O colaborador repete o passo 2 do fluxo principal.
Fluxos de erro
[FE02] O gestor de TI cadastra um usuário do tipo gestor de TI já
existente.
1. O Sistema exibe na tela uma mensagem informando que o gestor de TI já
está cadastrado.
2. O gestor de TI repete o passo 2 do fluxo principal.
[FE03] O gestor de TI deixa campos obrigatórios em branco.
1. O Sistema exibe na tela uma mensagem informando que os campos
obrigatórios não foram preenchidos.
2. O Usuário repete o passo 5 do fluxo principal.
Figura 3 – Representação da tela de cadastro de novo colaborador
[RF003] Manter atividade
Ator (es): Gestor de TI, colaborador

12
Requisitos
associados:
RF001
Descrição: Esse caso de uso serve para criar, alterar, consultar e excluir uma
atividade.
Pré-condições:O usuário deve estar logado no sistema.
Fluxo principal
1. O Sistema exibe tela 1 solicitando manutenção de atividade.
2. O Usuário informa o tipo de manutenção (criar, consultar, alterar, encerrar).
3. O Sistema exibe as funcionalidades requisitadas pelo usuário.
Fluxos alternativos
[FA01] O colaborador escolhe a opção alterar.
1. O Sistema exibe uma tela de busca para a seleção atividade a ser alterada.
2. O colaborador escolhe a atividade a ser alterada.
3. O colaborador preenche os campos e clica em atualizar atividade.
4. O sistema exibe os dados da atividade selecionada.
[FA02] O colaborador escolhe a opção consultar.
1. O Sistema fornece uma tela de busca para a seleção da atividade a ser
consultada.
2. O colaborador escolhe a atividade que ele deseja consultar.
3. O Sistema exibe os dados da atividade selecionada.
[FA03] O colaborador escolhe a opção criar.
1. O Sistema fornece uma tela de criação da nova atividade.
2. O Sistema exibe os campos obrigatórios para criação da atividade.
3. O Sistema exibe os dados da atividade criada.
[FA04] O colaborador escolhe a opção encerrar.
1. O Sistema fornece uma tela de encerramento de atividade.
2. O Sistema exibe os campos obrigatórios para encerramento de atividade.
3. O Sistema exibe os dados da atividade encerrada.
Fluxos de erro
[FE01] O colaborador deixa campos obrigatórios em branco.

13
[FE02] O colaborador tenta consultar atividade inexistente.
1. O Sistema exibe na tela a seguinte mensagem: “Atividade Inexistente”
Figura 4 – Representação da tela de cadastro de nova atividade
[RF004] Exibir Painel
Ator (es): Gestor de TI
Requisitos
associados:
RF001
Descrição: Esse caso de uso serve exibir o DashBoard.
Pré-condições:O usuário deve estar logado no sistema como gestor de TI.
Fluxo principal
1. O Sistema exibe tela 1 solicitando exibição de painel.
2. O Sistema exibe o DashBoard TI e suas funcionalidades.
[FA01] O gestor de TI escolhe a opção detalhar gráficos de atividades.

14
1. O DashBoard fornece um botão para detalhamento de atividade.
2. O DashBoard exibe pop-up com dados detalhados da atividade.
Figura 5 – Representação da tela que apresenta o Dashboard
[RF005] Manter metas
Ator (es): Gestor de TI
Requisitos
associados:
RF001
Descrição: Esse caso de uso serve para criar, alterar, consultar e excluir uma
meta.
Pré-condições:O usuário deve estar logado no sistema no tipo gestor de ti.
Fluxo principal
1. O Sistema exibe tela 1 solicitando manutenção de meta.
2. O gestor de TI informa o tipo de manutenção (criar, consultar, alterar,
encerrar).

15
3. O Sistema exibe as funcionalidades requisitadas pelo gestor de TI.
Fluxos alternativos
[FA01] O gestor de TI escolhe a opção alterar.
1. O Sistema exibe uma tela de busca para a seleção meta a ser alterada.
2. O gestor de TI escolhe a meta a ser alterada.
3. O gestor de TI preenche os campos e clica em atualizar meta.
4. O sistema exibe os dados da meta selecionada.
[FA02] O gestor de TI escolhe a opção consultar.
1. O Sistema fornece uma tela de busca para a seleção da meta a ser
consultada.
2. O gestor de TI escolhe a meta que ele deseja consultar.
3. O Sistema exibe os dados da meta selecionada.
[FA03] O gestor de TI escolhe a opção criar.
1. O Sistema fornece uma tela de criação da nova meta.
2. O Sistema exibe os campos obrigatórios para criação da meta.
3. O Sistema exibe os dados da meta criada.
[FA04] O gestor de TI escolhe a opção encerrar.
1. O Sistema fornece uma tela de encerramento de meta.
2. O Sistema exibe os campos obrigatórios para encerramento de meta.
3. O Sistema exibe os dados da meta encerrada.
Fluxos de erro
[FE01] O colaborador deixa campos obrigatórios em branco.
[FE02] O gestor de TI tenta consultar meta inexistente.
1. O Sistema exibe na tela a seguinte mensagem: “Meta Inexistente”

16
Figura 6 – Representação da tela de cadastro de metas.
Na imagem abaixo podemos visualizar o diagrama de classes do projeto DashBoard
TI.
Figura 7 – Representação do diagrama de classe de projeto.

17
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 corrompidos ou excluídos por falha do sistema.
● Desempenho
– Inicialização do Sistema: O Sistema deve demorar menos de 30 segundos
para iniciar em pelo menos 90% dos casos.
● Segurança
– Sigilo das Informações do Atendimento: As informações sobre as requisições
só poderão ser visualizadas pelo colaborador que fez o atendimento e pelo
gestor da área de TI
– Controle de Acesso: Cada usuário terá permissões de acesso específica
mediante seu papel no setor.
• Implantação

18
– 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
desenvolvimento 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.
● O SGBD utilizado no desenvolvimento das Tabelas da aplicação será o
PostgreSQL.
● A metodologia para gestão de projeto de software utilizada deve ser o método ágil
SCRUM.
2 Estimaçã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
Para usar as métricas de Lorenz e Kidd é 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

19
sugerem entre 15 e 20 dias-pessoa por classe) Escolher um número entre 15-20 dias-
pessoa e justificar a escolha.
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áfica 2
Baseada em texto 2.25
GUI 2.5
GUI Complexa 3
2.2 Resultados
Aplicando as métricas de Lorenz e Kidd (LORENZ M.; KIDD, 1994), obtivemos:
O número de integrantes da equipe de desenvolvimento limita-se a três pessoas,
sendo que todos são inexperientes no quesito produção de sistemas. Com isso,
levaremos em consideração que uma classe será produzida por uma pessoa em um
tempo médio de 20 (vinte) dias, que é o tempo médio máximo adotado nas métricas
utilizadas.
Tabela 2 – Dados referentes aos dados obtidos com a aplicação das métricas de
Lorenz e Kidd (LORENZ M.; KIDD, 1994).
Resultados Obtidos
Classe Chave 5
Natureza do Projeto GUI Complexa
Multiplicador 3
Classes de suporte 15
Total de classes projetadas 5+15 = 20
Quantidade de esforço estimado ((5+15) * 20) = 400 dias
Ainda levando em consideração o número de integrantes, a quantidade de dias de
trabalho por pessoa é de aproximadamente 134(centro e trinta e quatro) dias de
trabalho por pessoa, que é a quantidade de esforço estimado dividido pela quantidade
de integrantes (400 ÷ 3 ≅ 134).
Aplicando-se a distribuição dos dias de trabalho aos percentuais de cada fase obtém-
se a tabela 3, segue abaixo:

20
Tabela 3 - Estimativas dos dias de trabalho em cada etapa do projeto
Etapa Modelo (%) Projeto (%) Cálculo Dias de Trabalho
Planejamento 3-5 5 134*0,05 7
Requisitos-Análise-
Desenho
35-37 35 134*0,35 47
Codificação 20 20 134*0,20 27
Teste 40 40 134*0,40 53
Total 134
2.3 Recursos do projeto
2.3.1 Recursos humanos
A equipe deste projeto é composta por Claudemiro José da Silva Neto, Erasmo
Sena e Leonardo Rodrigues Paixão. Todos são graduandos no Bacharelado em
Sistemas de Informação da Universidade Federal de Sergipe(UFS).
2.3.2 Recursos de software
Os softwares a serem utilizados neste projeto são:
● Eclipse: IDE utilizada na codificação do software.
● Google Chrome: navegador utilizado para testar as funcionalidades do
software.
● Mozilla Firefox: navegador utilizado para testar as funcionalidades do software.
2.3.3 Recursos de hardware
● Os dispositivos de hardware a serem utilizados neste projeto são: 1.
Notebooks: utilizados para a codificação e testes.
2.3.4 Recursos bibliográficos
As referências bibliográficas utilizadas no projeto são:
● PRESSMAN, Roger S. Engenharia de Software, 6ª edição, São Paulo,
McGraw-Hill, 2006
● LORENZ, M.; KIDD, J. Object-oriented software metrics: a practical
guide.Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1994.

21
3. Gestã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 dos 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). Assim, foram definidos possíveis riscos ao desenvolvimento do
DashBoard TI. Esses riscos são apresentados na Tabela 4.

22
Tabela 4 – Tabela de Riscos do DashBoard TI
Risco Descrição Impacto Probabilidade
001 O cliente não tem um bom
entendimento do seu problema
Crítico 50 %
002 Prazos de entrega muito
curtos
Moderado 50%
003 Cliente não participou das
validações do que foi sendo
entregue
Moderado 30%
004 O cliente não possui um
bom entendimento técnico em
software
Moderado 35%
005 A equipe não oferece
manutenção pós entrega do
produto
Crítico 80%
006 Alta rotatividade da equipe Moderado 20%
007 Perda de informação do
Banco de dados
Catastrófi
co
4%
008 Integração do software
com ferramentas externas
Marginal 50%
009 Falha de hardware 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,

23
evitando a perda de recursos. Esses planos estão elencados nas Tabelas que
seguem.
Risco: O cliente não tem um bom entendimento do seu problema
Código: 001 Probabilidade: 50% Impacto: Crítico
Descrição: O cliente não tem uma ideia clara sobre seu problema e está indeciso
quanto as funcionalidades desejadas do software
Estratégia de Redução: Acompanhar o cotidiano do negócio do cliente, antes da
fase de levantamento de requisitos
Plano de Contingência: 1 - Acompanhar o cotidiano do ambiente do negócio
2 – Utilizar de técnicas avançadas de levantamento de
requisitos (brainstorming, workshop e etc.), que sejam adequadas para o negócio do
cliente
Pessoa Responsável:Claudemiro Neto
Status: Simulação Completa
Risco: Prazos de entrega muito curtos
Código: 002 Probabilidade: 50% Impacto: Moderado
Descrição: Prazos de entrega tidos como muito curtos
Estratégia de Redução: 1- Negociar prazos mais acessíveis
2- Melhorar o planejamento para estabelecer prazos mais
adequados
3- Otimizar a produtividade da equipe
4- Reutilizar features, métodos, templates
Plano de Contingência: 1- Dedicação da equipe em tempo integral
2- Aumentar as horas de trabalho
3- Começar pelo que é mais importante para o cliente
Pessoa Responsável: Leonardo Paixão

24
Risco: Cliente não participou das validações do que foi sendo entregue
Descrição: O cliente não esteve presente nas validações periódicas
Estratégia de Redução: Incentivar o cliente para participar das validações e explicar
o quão importante elas são
Plano de Contigência: Realizar reuniões periódicas e explicar a importância da
presença do cliente nesta fase
Pessoa Responsável: Erasmo Sena
Risco: O cliente não possui um bom entendimento técnico em software
Descrição: O cliente não possui entendimento técnico em termos de software para
identificar melhor seu problema
Estratégia de Redução: Oferecer uma mentoria para o cliente
Plano de Contigência: Convidar pessoas da confiança do cliente para que o auxilie
sobre a melhor solução para seu problema
Pessoa Responsável: Claudemiro Neto
Risco: A equipe não oferece manutenção pós entrega do produto
Código: 005 Probabilidade: 80% Impacto: Crítico
Descrição: A equipe é realocada ou inicia outros projetos, deixando sem
manutenção o produto entregue
Estratégia de Redução: Criar uma documentação de qualidade para facilitar o
entendimento de uma nova equipe

25
Plano de Contingência:1- Transferir corretamente o conhecimento para as novas
equipes
2- Criar uma documentação que seja bastante didática,
facilitando ao máximo o entendimento das novas equipes
Risco: Alta rotatividade da equipe
Código: 006 Probabilidade: 20 % Impacto: Moderado
Descrição: A equipe possui uma alta rotatividade
Estratégia de Redução: Documentar da melhor forma possível para facilitar o
entendimento de um novo membro da equipe
Plano de Contingência: Implantar uma arquitetura baseada em conhecimento como
suporte ao processo de desenvolvimento de software
Risco: Perda de informação do Banco de dados
Código: 007 Probabilidade: 4% Impacto: Catastrófico
Descrição: Perca de tabelas da aplicação
Estratégia de Redução: Fazer backups frequentes em um outro banco de dados
espelhado ao original, que esteja localizado em outro local
Plano de Contigência: Restaurar o backup do banco de dados espelhado para o
banco de dados de produção
Pessoa Responsável: Erasmo Sena
Risco: Integração do software com ferramentas externas
Código: 008 Probabilidade: 50% Impacto: Marginal
Descrição: O software necessita de uma integração com softwares externos
Estratégia de Redução: 1- Criar documentação necessária para as ferramentas que
vão ser integradas ao sistema
2- Utilizar as ferramentas, analisar e entender seu fluxo

26
Plano de Contigência: Entrar em contato com os desenvolvedores da ferramenta
para obter mais informações técnicas sobre a mesma
Risco: Falha de Hardware
Código: 009 Probabilidade: 30% Impacto: Marginal
Descrição: Algum hardware pode dar defeito nos equipamentos de desenvolvimento
Estratégia de Redução: 1- Oferecer manutenção regular aos equipamentos
2- Armazenar os equipamentos em ambientes frescos e
sem humidade
3- Realizar check-ups periódicos nos equipamentos
Plano de Contigência: Possuir equipamentos reservas
Pessoa Responsável:Leonardo Paixão
4. Planejamento Temporal
Nesta seção serão apresentadas as tarefas que serão executadas no projeto e
sua disposição em ordem cronológica, ilustradas através de uma linha temporal, qual
seja, o diagrama de Gantt, que por definição é um gráfico usado para ilustrar o avanço
das diferentes etapas de um projeto. Os intervalos de tempo representando o início e
fim de cada fase aparecem como barras coloridas sobre o eixo horizontal do gráfico
4.1 Conjunto de tarefas do projeto
Metodologia de desenvolvimento escolhida foi o modelo clássico, em cascata,
por se tratar de um projeto de pequeno a médio porte, além de não apresentar um
grande potencial para que sejam efetuadas mudanças.
4.2 Diagrama de Gantt
Nesta seção será apresentada a representação gráfica do calendário de
atividades do projeto, figura 8

28
Figura 8: Representação do diagrama de Gantt
Fonte: Próprios Autores
5. Organização do pessoal
Nesta seção, serão descritas de forma resumida as funções e
responsabilidades tidas por cada integrante da equipe no projeto DashBoard TI.
5.1 Estrutura da equipe
A equipe é composta por: Claudemiro José da Silva Neto, Erasmo Sena de
Jesus e Leonardo Rodrigues Paixão. O quadro 1 demonstra o papel de cada
integrante
Integrante Papel Descrição da atividade
Claudemiro José da Silva
Neto
Administrador de Banco
de Dados
Instalar, configurar e
manter o sistema de
banco de dados
Erasmo Sena de Jesus Gerente de Projeto Analisar os requisitos,
mapear e modelar os
processos
Leonardo Rodrigues
Paixão
Analista de Sistema Gerir as atividades do
projeto e definir as
funções de cada membro
do time
Neto,Erasmo Sena de
Jesus
Desenvolvedores Desenvolver o código do
sistema
Neto,Erasmo Sena de
Jesus
Analista de Teste Planejar, desenvolver e
executar os testes.
Quadro 1 - Integrantes da equipe e atribuições
5.2 Mecanismo de comunicação
O mecanismo de comunicação e organização das tarefas foi o Trello, de forma
secundária utilizou-se o Hangouts para as reuniões por vídeo conferência.

29
5.3 Uso do Edu-blog como ferramenta de apoio
O Edu-blog foi muito útil no sentido de dar perspectiva e embasamento acerca
das ferramentas e técnicas disponíveis na atualidade para gerência e execução da
construção de um projeto de software. Além de fomentar a pesquisa e
compartilhamento de conteúdo pertinentes a este fim.
6. Precauções tomadas para assegurar e controlar a
qualidade do produto de software
Foram feitas adequações do projeto às melhores práticas de gestão de
projetos e framework, seguindo as diretrizes e modelos do Project Management
Body of Knowledge (PMBOK), The Open Group Architecture Framework (TOGAF)
e do Capability Maturity Model Integration (CMMI).
‘
7. Referências
Edu-blog > GP | UFS .Disponível em:< http://gp-ufs-2017.blogspot.com.br/>
Acesso em: 15 de Janeiro de 2018
Ajax: Um Blog sobre PMI e suas dependências.Disponível em:<http://ajax-gp-
2017-ufs.blogspot.com.br/> Acesso em: 15 de Janeiro de 2018

Plano de projeto final

Mais conteúdo relacionado

Semelhante a Plano de projeto final

Último

Plano de projeto final