Modelo plano de projeto de sw oo gerenciamento de clientes final

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
CURSO DE SISTEMAS DE INFORMAÇÃO - BACHARELADO
GERÊNCIA DE PROJETOS 2014/2
Bruno Meneses
Thauane Moura
Thiago Dantas
Waldson Rodrigues
PLANO DE PROJETO DE SOFTWARE PARA PRODUTOS DA
LACERTAE SW
São Cristóvão - Sergipe, Brasil
2014

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
CURSO DE SISTEMAS DE INFORMAÇÃO - BACHARELADO
GERÊNCIA DE PROJETOS 2014/2
Bruno Meneses
Thauane Moura
Thiago Dantas
Waldson Rodrigues
PLANO DE PROJETO DE SOFTWARE PARA PRODUTOS DA
LACERTAE SW
Trabalho apresentado ao Prof. PhD
Rogério Patrício Chagas do
Nascimento como nota parcial para
disciplina Gerência de Projetos do
curso de graduação em Sistemas
de Informação – Bacharelado da
Universidade Federal de Sergipe.
São Cristóvão - Sergipe, Brasil
2014

Histórico de Alterações
Data Versão Descrição Autor(es)
05/11/2014 1.1 Criação do documento Bruno,
Thauane, Thiago e Waldson
05/11/2014 1.2 Introdução Bruno,
05/11/2014 1.3 Convenções, termos e abreviações Bruno,
05/11/2014 1.4 Principais funções do produto de
software
Bruno,
05/11/2014 1.5 Visão geral de alguns requisitos do
sistema
Bruno,
19/11/2014 1.6 Estimativas do Projeto Bruno,
22/11/2014 1.7 Técnicas de Estimação Bruno,
22/11/2014 1.8 Resultados Bruno,
15/12/2014 1.9 Recursos do Projeto Bruno,
07/01/2015 2.0 Recursos Humanos Bruno,
14/01/2015 2.1 Recursos de Software Bruno,
15/01/2015 2.2 Recursos de Hardware Bruno,
14/01/2015 2.3 Análise e Gestão dos Riscos Bruno,
20/01/2015 2.4 Redução e Gestão do Risco Bruno,
23/01/2015 2.5 Plano de Contingência Bruno,
25/01/2015 2.6 Planejamento Temporal Bruno,
28/01/2015 2.7 Conjunto de Tarefas do Projeto Bruno,
30/01/2015 2.8 Diagrama de Gantt Bruno,
31/01/2015 2.9 Organização do Pessoal Bruno,
02/01/2015 3.0 Precauções Tomadas para Assegurar
e Controlar a Qualidade do Produto
de Software
Bruno,
03/01/2015 3.1 Revisão Parcial do Documento Bruno,
04/01/2015 3.2 Revisão Final do Documento Bruno,

Sumário
1. INTRODUÇÃO ..................................................................................................................... 6
1.1 Convenções, termos e abreviações ................................................................................. 6
1.2 Principais funções do produto de software ...................................................................... 7
1.3 Visão geral de alguns requisitos do sistema..................................................................... 7
1.3.1 Requisitos Funcionais ............................................................................................... 8
1.3.2 Prioridade dos Requisitos.......................................................................................... 8
[RF001] – Efetuar Login ................................................................................................ 9
[RF002] – Manter Clientes............................................................................................. 9
[RF003] – Manter Seguradoras ..................................................................................... 9
[RF004] – Manter Negociações..................................................................................... 9
[RF005] – Manter Cotações .......................................................................................... 9
[RF006] – Agendar atendimento ao cliente ................................................................... 9
[RF007] – Gerar Relatórios ......................................................................................... 10
[RF008] – Gerar Estatísticas ....................................................................................... 10
[RF009] – Efetuar Backup ........................................................................................... 10
[NFSG001] O sistema deve possuir um login para cada usuário................................. 10
[NFIM001] O sistema deve possuir conexão com o banco de dados MySQL.............. 11
[NFPA001] O sistema deve ser implementado usando a linguagem de orientação a
objetos Java................................................................................................................ 11
2. ESTIMATIVAS DO PROJETO............................................................................................ 11
2.1 Dados históricos utilizados para as estimações............................................................ 11
2.2 Técnicas de estimação e resultados.............................................................................. 12
2.2.1 Técnica de estimação.............................................................................................. 14
2.3 Resultados .................................................................................................................... 14
2.4 Informações para a codificação do projeto.................................................................... 16
2.5 Recursos do projeto ...................................................................................................... 16
2.5.1 Recursos humanos ................................................................................................. 17
2.5.2 Recursos de software.............................................................................................. 18
2.5.3 Recursos de hardware ............................................................................................ 19
3 ANÁLISE E GESTÃO DE RISCOS ..................................................................................... 19
3.1 Riscos do projeto .......................................................................................................... 20
3.2 Tabela de riscos............................................................................................................ 21
3.3 Redução e Gestão do risco........................................................................................... 22
3.4 Plano de Contingência .................................................................................................. 27
4. PLANEJAMENTO TEMPORAL.......................................................................................... 28
4.1 Conjunto de Tarefas do Projeto .................................................................................... 28
4.2 Diagrama de Gantt........................................................................................................ 29
5 PROJETO DO BANCO DE DADOS.................................................................................... 35

5.1 Modelo de Dados – versão Inicial (Diagrama ER)......................................................... 35
6 ORGANIZAÇÃO DO PESSOAL .......................................................................................... 36
6.1 Estrutura da equipe....................................................................................................... 36
6.2 Mecanismos de comunicação ....................................................................................... 36
6.3 Uso do Edu-blog como ferramenta de apoio................................................................. 37
7 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO
PRODUTO DE SOFTWARE ........................................................................................... 37

1. INTRODUÇÃO
A TI está presente em nosso dia a dia alterando a forma e a velocidade como lidamos
com as informações.
O software projetado durante essa disciplina consiste em uma solução Web para
pequenas e médias corretoras de seguros. Atualmente, diante do cenário tão competitivo na
busca por clientes as empresas necessitam de ferramentas que possam lhes auxiliar na
gestão da informação.
A ideia do projeto consiste em desenvolver uma aplicação que possa centralizar os
dados dos atuais clientes de uma corretora de seguros e diante desses dados, interpretar e
analisar para que esses dados se transformem em informação que possam auxiliar na gestão
da empresa.
O cenário atual possui algumas ferramentas que fornecem esse serviço de forma paga, no
entanto, essas ferramentas não apresentam um layout que represente a essência da TI para o
século XXI que é a simplicidade e eficiência na manipulação dos dados.
Para mudar o cenário atual foi projetado uma ferramenta que funciona na Web, o
gestor irá manipular as informações da sua empresa em qualquer lugar, facilitando assim o
uso da informação de uma forma eficiente e segura pois o sistema implementará rotinas de
backup para assegurar a integridade da informação.
Os benefícios são notáveis, cada gestor poderá gerar gráficos e relatórios que os
auxiliem a tomar decisões que possam influenciar no resultado final da empresa.
A experiência com o software tornará os gestores mais preparados para lidar com as
adversidades surgidas no dia a dia pois conseguirá ter uma visão macro do negócio, evitando
que a empresa tome rumos não desejados.
1.1 Convenções, termos e abreviações
A correta interpretação deste documento exige o conhecimento de algumas
convenções e termos específicos e abreviações, que são:
 PMBOK – do inglês, Project Body of Knowledge;
 PMI – Profissional de Gerência de Projetos (do inglês, Project Management
Professional);
 RF – Requisito Funcional;
 RI – Requisito Inverso;
 RNF – Requisito não funcional;
 SW - Software;
 TI - Tecnologias da Informação.

1.2 Principais funções do produto de software
O diagrama representado na Figura 1 abaixo apresenta as principais funcionalidades
do sistema de gerenciamento de clientes. Esse diagrama é chamado de use case que mostra
ilustrativamente os atores que atuam no sistema de controle gerenciamento de clientes.
Figura 1 - Diagrama de casos de uso do sistema
1.3 Visão geral de alguns requisitos do sistema
Abaixo serão listadas alguns requisitos do sistema de gerenciamento de clientes:
1. O sistema irá ser desenvolvido utilizando arquitetura Web;
2. O sistema irá utilizar a linguagem de programação Java;
3. O sistema irá utilizar o MySQL como banco de dados;
4. O acesso ao sistema será feito através de um browser (navegador Web).
5. O sistema será utilizado por 2 usuários que terão permissão para alimentar o
sistema integralmente.
6. O sistema não terá integração com qualquer outro sistema externo.

1.3.1 Requisitos Funcionais
Nessa seção apresentamos todos os requisitos funcionais da aplicação relacionados ao nosso
caso de uso na Figura 1:
[RF001] O sistema deve permitir efetuar o login.
[RF002] O sistema deve manter clientes.
[RF003] O sistema deve manter seguradora.
[RF004] O sistema deve manter negociações.
[RF005] O sistema deve manter cotações.
[RF006] O sistema deve permitir agendar atendimento ao cliente.
[RF007] O sistema deve ser capaz de gerar relatórios.
[RF008] O sistema deve ser capaz de gerar estatísticas.
[RF009] O sistema deve permitir efetuar backup.
1.3.2 Prioridade dos Requisitos
Para estabelecimento de prioridades foram usadas três denominações, sendo elas,
“essencial”, “importante” e “desejável”.
 Essencial é o requisito sem o qual o sistema não entra em funcionamento.
Requisitos essenciais são requisitos imprescindíveis, que têm que ser
implementados impreterivelmente.
 Importante é o requisito sem o qual o sistema entra em funcionamento, mas de
forma não satisfatória. Requisitos importantes devem ser implementados, mas, se
não forem, o sistema poderá ser implantado e usado mesmo assim.
 Desejável é o requisito que não compromete as funcionalidades básicas do sistema,
isto é, o sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveis
podem ser deixados para versões posteriores da solução, caso não haja tempo hábil
para implementá-los na versão que está sendo especificada.

1.3.2.1 Prioridade dos Requisitos Funcionais (RF)
Nessa seção apresentamos todas as prioridades e autor(es) dos requisitos funcionais
da aplicação relacionados ao nosso caso de uso.
[RF001] – Efetuar Login
Prioridade: Essencial Importante Desejável
Ator(es): Corretor, Funcionário
[RF002] – Manter Clientes
Ator(es): Corretor
[RF003] – Manter Seguradoras
Ator(es): Funcionário
[RF004] – Manter Negociações
[RF005] – Manter Cotações
[RF006] – Agendar atendimento ao cliente
Ator(es): Corretor, Funcionário, Cliente

[RF007] – Gerar Relatórios
[RF008] – Gerar Estatísticas
[RF009] – Efetuar Backup
1.3.2.2 Prioridade dos Requisitos Não-Funcionais (RNF)
Nesta seção descrevemos os requisitos não funcionais da solução de nosso sistema
neurológico.
Os Requisitos não-funcionais são os requisitos relacionados ao uso da aplicação em
termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade,
manutenibilidade e tecnologias envolvidas. Em geral, requisitos não-funcionais podem
constituir restrições aos requisitos funcionais e não é preciso o cliente dizer sobre eles, pois
eles são características mínimas de um software de qualidade.
1.3.2.2.1 Segurança
Nessa seção descrevemos os requisitos não-funcionais associados à integridade, privacidade
e autenticidade dos dados da nossa aplicação.
[NFSG001] O sistema deve possuir um login para cada usuário.
Requisitos
funcionais
associados:
RF001 – O sistema deve permitir efetuar o login.

1.3.2.2.2 Implantação
Nessa seção descrevemos os requisitos não-funcionais associados à implantação da
nossa solução.
[NFIM001] O sistema deve possuir conexão com o banco de dados MySQL.
Requisitos
funcionais
associados:
Todos os requisitos de RF001 a RF009.
1.3.2.2.3 Padrões
Nessa seção descrevemos os requisitos não-funcionais associados a padrões ou
normas que devem ser seguidos pela nossa aplicação ou pelo nosso processo de
desenvolvimento.
[NFPA001] O sistema deve ser implementado usando a linguagem de orientação a
objetos Java.
Requisitos
funcionais
associados:
Todos os requisitos de RF001 a RF009.
2. ESTIMATIVAS DO PROJETO
Nesta seção serão descritas as estimativas que permitem calcular custo, esforço e
tempo gastos durante a construção do projeto. Essas informações são úteis para analisar e
distribuir as atividades de acordo com um cronograma preciso de tempo e recursos
necessários para cada uma delas.
2.1 Dados históricos utilizados para as estimações
Por se tratar de um projeto novo, que está sob a responsabilidade de uma equipe
graduanda em sistemas de informação, não existem dados históricos utilizados para as
estimações.

2.2 Técnicas de estimação e resultados
Nesta seção utilizamos a métrica de Lorenz & Kidd para calcular o esforço por pessoa
necessário para a construção do projeto. Utilizamos o diagrama de classes de domínio,
mostrado na Figura 2 abaixo, como fonte de informações.
De acordo com o diagrama de classes, na Figura 2, identificamos que o software possui 5
classes chaves. Utilizando interface gráfica, com fator multiplicador de 2,5, teremos 13 classes
de suporte totalizando 18 classes.

Figura 2 - Diagrama de classes

2.2.1 Técnica de estimação
A métrica mencionada a métrica de Lorenz & Kidd, da seção 2.2, foi utilizada de
acordo com os seguintes passos:
1. Determinar as classes-chave do projeto, através da análise do diagrama de
classes de domínio (apresentado na Figura 2);
2. Determinar o tipo da interface do projeto, que deve ser classificada de acordo
com um dos itens da Tabela 1;
Interface Multiplicador
Interface não gráfica 2
Baseada em texto 2,25
GUI 2,5
GUI Complexa 3
Tabela 1 - Valores Interface x Multiplicador
3. Determinar o número de classes de suporte, efetuando o produto da quantidade de
classes-chave pelo multiplicador da interface escolhida anteriormente;
4. Determinar o total de classes do projeto, somando a quantidade de classes de
suporte com a quantidade de classes-chave;
5. Determinar a quantidade de dias que uma pessoa levaria para construir uma classe.
Quando não existem dados históricos a serem considerados, Lorenz
& Kidd sugerem de quinze a vinte dias;
6. Determinar a quantidade total de dias que uma pessoa levaria para construir todo o
projeto, efetuando o produto do total de classes do projeto pela quantidade de dias
escolhida anteriormente;
7. Determinar a quantidade total de dias que a equipe levaria para construir todo o
projeto, efetuando a divisão da quantidade total de dias pela quantidade de
pessoas que a equipe possui.
2.3 Resultados
Para realizarmos as estimações através da técnica de Lorenz & Kidd, descrita na
seção 2.2, utilizamos o diagrama de classes, exibido na Figura 2. Após a análise do diagrama
e das considerações da técnica utilizada, podemos obter as seguintes conclusões abaixo,
descritos nos itens 2.3.1 e 2.3.2.

2.3.1 Passo a Passo
1. Número de classes-chave encontradas após a análise do diagrama de classes de
domínio;
5 classes-chaves:
 Cliente;
 Usuário;
 CorretoraSeguros;
 Negocio;
 Seguradora.
2. Interface selecionada (De acordo com o modelo de arquitetura do sistema);
GUI
3. Número de classes de suporte encontrado;
5 (item 1) x 2,5 (multiplicador do item 2) = 12,5 classes de
suporte
4. Número total de classes;
5 (item 1) + 12,5 (item 3) = 17,5 classes
5. Quantidade de dias que uma pessoa gastaria para desenvolver uma única classe
(Valor retirado do intervalo sugerido por Lorenz & Kidd);
17,5 * 17 = 297,
5 Dias- pessoa (esforço)
6. Quantidade total de dias que uma pessoa gastaria para construir todo o
sistema;
5 (item 5) * 17 (item 4) = 297 dias
7. Quantidade total de dias que a equipe gastaria para construir todo o sistema.
297 (item 6) / 4 (quantidade de integrantes) = 74,3 dias
Dividido por 30 → 74,3 / 30 = 2,4 (2 meses, 14 dias, 2 horas 24min) –
com sábado e domingo (sem parar).
Dividido por 22 → 74,3 / 22 = 3 meses, 8 dias
Sendo assim, de acordo com a métrica de Lorenz & Kidd, o tempo necessário para a
construção do projeto deve ser de, aproximadamente, 2 meses, 14 dias, 2 horas 24min, sem
parar. Levando em consideração a quantidade de dias úteis no mês, o projeto se estenderá
por 3 meses e 8 dias.

2.3.2 Tabela Geral
Nessa seção será mostrada a Tabela 2, com uma visão geral descrita na seção 2.3.1.
Interface Multiplicador
Não gráfica 2
Baseada em texto 2,25
GUI 2,5 2,5 (multiplicador do GUI) * 5 (classes
chaves) = 12,5 (classes de suporte);
5(classes chaves) + 12,5 (classes de
suporte) = 17,5 (classes);
17,5 (classes) * 17 = 297 (dias),
5 Dias- pessoa (esforço)
297,5 / 4 (quantidade de pessoas na
equipe) = 74,3
Dividido por 30 → 74,3 / 30 = 2,4
(2 meses, 14 dias, 2 horas 24min) – com
sábado e domingo (sem parar)
Dividido por 22 → 74,3 / 22 = 3 meses, 8
dias
GUI complexa 3,0
Tabela 2 – Tabela da execução de métricas descritas da seção 2.2.1
2.4 Informações para a codificação do projeto
As seguintes regras de codificação serão adotadas no desenvolvimento do sistema de
gerenciamento de clientes:
 Nomes de classes começando com letra maiúscula e com nome convincente.
 Nomes de atributos vão começar com letra minúscula e quando for formado por mais de
uma palavra, a primeira letra de cada palavra deverá ser maiúscula, possuindo também
nomes convincentes.
2.5 Recursos do projeto
Nas seções abaixo serão listados os recursos utilizados na construção do projeto, que
são: humanos, de software e de hardware.

2.5.1 Recursos humanos
A metodologia adotada para o gerenciamento do projeto foi o SCRUM. Os Sprints das
Tabelas 3, 4, 5 e 6 definem a estrutura de organização e execução do conjunto de tarefas
classificados de acordo com uma disposição hierárquica das funcionalidades a serem
desenvolvidas e das datas disponíveis para a sua construção, listadas na Tabela 8. Além
disso, temos o ScrumMaster que é o elemento que faz a ligação entre o dono do produto ou
projeto e a equipe.
SPRINT 1
Período: 22/10/2014 a 12/11/2014 Duração: 22 dias
Funcionalidades:
RF001 - Efetuar Login;
RF002 - Manter Clientes;
RF003 - Manter Seguradora.
ScrumMaster: Thauane
Moura
Desenvolvedor 1: Thiago
Dantas
Desenvolvedor 2: Waldson
Rodrigues
Testador: Bruno Meneses
Tabela 3 - Sprint 1
SPRINT 2
Funcionalidades:
RF004 - Manter negociações;
RF005 - Manter oficinas;
ScrumMaster: Thiago Dantas
Desenvolvedor 1: Bruno
Meneses
Desenvolvedor 2: Thauane
Moura
Testador: Waldson Rodrigues
Tabela 4 - Sprint 2

SPRINT 3
Funcionalidades:
RF006 - Agendar atendimento ao cliente.
ScrumMaster: Waldson
Rodrigues
Desenvolvedor 1: Bruno
Menezes
Desenvolvedor 2: Thiago
Dantas
Testador: Thauane Moura
Tabela 5 - Sprint 3
SPRINT 4
Funcionalidades:
RF007 - Gerar estatísticas;
RF008 - Gerar relatórios;
RF009 - Efetuar Backup.
ScrumMaster: Bruno Meneses
Desenvolvedor 1: Waldson
Rodrigues
Desenvolvedor 2: Thauane
Moura
Testador: Thiago Dantas
Tabela 6 - Sprint 4
2.5.2 Recursos de software
O sistema irá contar com os recursos disponíveis na internet para desenvolvimento
de software como:
 Banco de dados Mysql - utilizado para armazenar as informações;
 Netbeans IDE - utilizado para desenvolver o algoritmo;
 StarUML - utilizado para modelagem de dados;
 Google Drive - utilizado para permitir o armazenamento dos documentos salvos
pela equipe de desenvolvimento.

2.5.3 Recursos de hardware
Para o desenvolvimento da aplicação foram usados pcs com a seguinte
configuração:
 Processador Intel Core™ i3
 Memória 4GB
 HD 500GB
 Monitor LED 15,6"
 Conexão à internet - fornecida pela operadora Oi Internet.
Com o andamento do projeto as máquinas não apresentaram nenhum tipo de
problema e mostraram ser bastante eficaz para o desenvolvimento da aplicação em
questão.
3 ANÁLISE E GESTÃO DE RISCOS
Nesta seção serão analisados os riscos potenciais que foram prejudiciais para
o andamento do projeto. O objetivo desta análise é conhecer e minimizar, o máximo
possível, a probabilidade de sua ocorrência e o impacto causado por ela, caso venha a
acontecer.

3.1 Riscos do projeto
Segue abaixo tabela com os riscos identificados e sua respectiva classificação, que
visa determinar se a sua ocorrência é geral ou única do projeto:
Nº Risco Projeto Técnico Negócio Comum Especial
1 Volume de informações maior do que o
projetado
X
2
Quantidade de mudanças projetadas
nos requisitos para o produto. Antes e
após a entrega.
X X
3
Baixa motivação dos usuários em
inserir dados no sistema por completo
X
4
Pouca quantidade de software
reutilizado
X
5 Rigidez no prazo de entrega X X
6 Restrições de interoperabilidade X
7
Necessidade de uma interface
especializada
X X
8 Tamanho pequeno da equipe X X
9
Comprometimento da equipe durante o
projeto
X X
10
A equipe não está disponível
integralmente.
X X
11
Nível baixo de conhecimento por parte
da equipe sobre a(s) tecnologia(s)
usada(s)
X X
Tabela 7 - Riscos x Classificação

3.2 Tabela de riscos
Na Tabela 8 foi atribuída a cada um dos riscos uma probabilidade que determina
o grau da chance deste risco acontecer e um impacto após o efetivo acontecimento deste
evento.
Nº Risco Probabilidade Impacto
1 Volume de informações maior do que o
projetado
60% Crítico
2
Quantidade de mudanças projetadas nos
requisitos para o produto. Antes e após a
entrega
50% Crítico
3 Pouca quantidade de software reutilizado 45% Crítico
4 Rigidez do prazo de entrega 40% Crítico
5
Baixa motivação dos usuários em inserir dados
no sistema por completo
50% Moderado
6 Restrições de interoperabilidade 35% Moderado
7 Necessidade de uma interface especializada 30% Moderado
8 Comprometimento da equipe durante o projeto 25% Moderado
9
Nível baixo de conhecimento por parte da
equipe sobre a(s) tecnologia(s) usada(s)
20% Moderado
10 Tamanho pequeno da equipe 25% Marginal
11 A equipe não está disponível integralmente. 20% Marginal
Tabela 8 - Análise Risco x Probabilidade x Impacto

3.3 Redução e Gestão do risco
Os quadros a seguir, de 1 a 11 apresentam estratégias para a redução e/ou
gestão dos riscos identificados na seção 3.2:
Análise do Risco 1
1- Volume de informações maior do que o projetado
Probabilidade: 30% Impacto: Crítico
Descrição: O volume de informações trafegado pelo
sistema pode ser maior que o projetado e causar
lentidão no sistema.
Plano de Contingência: Alocar mais espaços
no servidor para suportar o tráfego de dados.
Estratégia de redução: Acompanhar as
estatísticas de utilização do sistema para evitar que
os usuários fiquem com o sistema indisponível.
Responsável: Thiago Dantas Status: Em Andamento
Quadro 1 - Análise do risco 1
Análise do Risco 2
2- Quantidade de mudanças projetadas nos requisitos para o produto. Antes e após a entrega
Descrição: Os requisitos do projeto podem vir a ser
alterados durante o projeto.
Plano de Contingência: Renegociar com o
cliente os prazos anteriormente definidos.
Estratégia de redução: Negociar junto ao cliente
os requisitos, a fim de definir o escopo do projeto.

Análise do Risco 3
3- Baixa motivação dos usuários em inserir dados no sistema por completo
Probabilidade: 50% Impacto: Moderado
Descrição: Os usuários podem não inserir dados no
sistema por completo por achar que devem
disponibilizar tempo para outras atividades da
empresa. Plano de Contingência: Disponibilizar telas
alternativas com um número mínimo de
informações para o usuário utilizar em casos de
urgência.
Estratégia de redução: Simplificar ao máximo os
formulários para agilizar a inserção de dados.
Responsável: Bruno Meneses Status: Em Andamento
Análise do Risco 4
4- Pouca quantidade de software reutilizado
Descrição: A maior parte dos componentes utilizados
no produto implementados sem utilizar componente
reutilizados.
Plano de Contingência: Pesquisar por
componentes reutilizáveis para utilizar no
projeto.
Estratégia de redução: Planejar medidas que
facilitem a reutilização de software, tais como utilizar,
quando possível, padrões de projeto.
Responsável: Bruno Meneses Status: Em Andamento

Análise do Risco 5
5- Rigidez do prazo de entrega
Descrição: O prazo para entregar todo o projeto é
pequeno e inflexível. Plano de Contingência: Remanejar a divisão
das atividades entre os membros da equipe,
visando colocar as atividades dentro do prazo
de entrega, realizando-as por incrementos.
Porém tentando sempre evitar sobrecarga de
atividades.
Estratégia de redução: Realizar divisão das
atividades do projeto entre a equipe de forma que a
entrega permaneça dentro do prazo.
Responsável: Thauane Moura Status: Em Andamento
Análise do Risco 6
6- Restrições de interoperabilidade
Descrição: O sistema não é projetado para se
comunicar com outro sistema.
Plano de Contingência: Disponibilizar no
sistema, a exportação de dados em extensões
.pdf e .xls.
Estratégia de redução: Identificar quais os
possíveis sistemas externos que o produto irá
interagir.

Análise do Risco 7
7- Necessidade de uma interface especializada
Descrição: Desenvolver uma interface específica
ao setor de seguros para evitar que o usuário sinta
dificuldades de adaptação ao sistema.
Plano de Contingência: Disponibilizar telas de
esboço para usuários experientes com as regras
de negócio, afim de obter feedback.
Estratégia de redução: Desenvolver uma
interface levando em consideração as interfaces dos
sistemas utilizados pelas Seguradoras nos quais os
usuários já estão acostumados a utilizar.
Responsável: Waldson Rodrigues Status: Em Andamento
Análise do Risco 8
8- Tamanho pequeno da equipe
Probabilidade: 25% Impacto: Marginal
Descrição: A quantidade de pessoas na equipe
que está no projeto é pequena.
Plano de Contingência: Remanejar a divisão
das atividades entre o membros da equipe,
porém tentando sempre evitar sobrecarga de
atividades.
Renegociar com o cliente, o tamanho do
produto que será entregue.
atividades do projeto entre a equipe de forma que a
entrega permaneça dentro do prazo, como também,
evitar sobrecarga de atividades.

Análise do Risco 9
9- Comprometimento da equipe durante o projeto
Descrição: A equipe, ou parte dela, não está
comprometida com o projeto seguindo o que foi
planejado.
Plano de Contingência: Realizar pequenas
reuniões periódicas ao longo do projeto para
revisar sobre o seu andamento, e discutir as
dificuldades percebidas pela equipe.
Estratégia de redução: Distribuir as atividades de
acordo com o grau de afinidade e experiência de
cada membro da equipe para utilizar o máximo de
conhecimento do membro em questão.
Análise do Risco 10
10 - Equipe não está disponível integralmente
Probabilidade: 20% Impacto: Marginal
Descrição: Devido a outras atividades extras ao
projeto realizadas por cada integrante da equipe, o
tempo disponibilizado para o projeto não é integral.
Plano de Contingência: Revisar as atividades
realizadas por cada integrante para remanejar
qualquer sobrecarga de trabalho sobre
alguém. A divisão das tarefas entre os
membros da equipe deve facilitar o processo.
atividades do projeto entre a equipe, de forma que a
entrega permaneça dentro do prazo.

Análise do Risco 11
11 – Pouco conhecimento por parte da equipe sobre a(s) tecnologia(s) usada(s)
Descrição: A equipe, ou parte dela, não possui
conhecimento aprofundado sobre a tecnologia que
está sendo utilizada. Plano de Contingência: Realizar o
planejamento para que desenvolvimento de
trechos de codificação mais complexos sejam
feitos utilizando a técnica de programação em
par, ao invés de serem desenvolvidas
individualmente, aproveitando assim o máximo
de conhecimento de ambos os programadores.
Estratégia de redução: Reunir e disponibilizar
para a equipe, materiais de estudo que forneçam
aprendizado sobre a(s) tecnologia(s) utilizada(s).
Realizar treinamento da equipe sobre a tecnologia
que será utilizada.
3.4 Plano de Contingência
Atualmente, a maioria dos negócios necessita de Tecnologia da Informação e de
sistemas automatizados para auxiliar na gestão organizacional.Desta forma, para algumas
empresas, ficar com o serviço indisponível por algumas horas pode significar perdas
significativas gerando prejuízos financeiros.
É necessário avaliar o nível de dependência do negócio em relação a TI e a dependência
de serviços baseados na Internet. Para evitar futuros transtornos, toda e qualquer empresa deve
desenvolver um plano de contingência que possa garantir a continuidade do negócio mesmo
em situações como desastres naturais, roubos, fraudes ou até mesmo um ataque cibernético
de grande proporção.
Pensando nisso, foi desenvolvido uma rotina de backup que além de efetuar
rotineiramente o armazenamento das informações, disponibiliza a exportação dos arquivos no
formato .xls para garantir que mesmo em situações onde a Internet seja ausente o mínimo de
informações possa ser acesso nem que seja via papel.
Além disso, foi garantido que o backup gerado não seja salvo no mesmo local do
escritório, para isso foi contratado um serviço de armazenamento na nuvem para garantir que
as informações não sejam perdidas mesmo em situação de um desastre natural local.

4. PLANEJAMENTO TEMPORAL
Nesta seção são apresentadas as datas de execução das tarefas, bem como seus
responsáveis. No planejamento temporal definimos os marcos e planos de ações. A
mensuração do tempo para construção do projeto definido no item 2.3 foi utilizado para dividir
as fases do projeto. Essa parte é de extrema importância para a mensuração do andamento
do projeto, e do cumprimento das suas expectativas na esfera temporal. As fases tiveram a
divisão do tempo conforme a Tabela 9.
Fase Porcentagem Duração (Dias)
Planejamento 15% 16 dias
Análise e Projeto 20% 30 dias
Codificação 50% 40 dias
Testes 15% 15 dias
Tabela 9 - Fases do projeto
4.1 Conjunto de Tarefas do Projeto
O SCRUM define a divisão das funcionalidades em tarefas menores
executáveis pelos desenvolvedores. A Tabela 10 relaciona as tarefas com sua fase.
Fase Tarefas
Planejamento Definição de escopo;
Funcionalidades e restrições;
Documento de concepção.
Análise e Projeto Especificação de Requisitos;
Especificação de Requisitos não funcionais;
Especificação dos diagramas de análise;
Documento de Analise;
Definição da arquitetura de Projeto;
Especificação dos diagramas de projeto;
Documento de Projeto;
Especificação e detalhamento de requisito.
Codificação Desenvolvimento da interface gráfica;
Desenvolvimento da regra de negócio.
Teste Teste e validação de documentação;
Teste e validação de software.
Tabela 10 - Distribuição das tarefas em fases

4.2 Diagrama de Gantt
O diagrama de Gantt é um instrumento que permite modelar graficamente a
bplanificação do avanço e planejamento das tarefas necessárias para a realização de um
projeto. As Figuras 3, 4, 5, 6 e 7 mostram as tarefas planejadas do projeto em forma de
diagrama de Gantt.

Figura 3 – Diagrama de Gantt

5 PROJETO DO BANCO DE DADOS
Nessa seção apresentamos todos os detalhes do projeto de Banco de Dados que tem
como objetivo identificar as classes persistentes de design, projetar as estruturas do banco
apropriadas e definir mecanismos e estratégias de armazenamento e recuperação.
5.1 Modelo de Dados – versão Inicial (Diagrama ER)
Figura 8 - Diagrama ER

6 ORGANIZAÇÃO DO PESSOAL
Nessa seção será descrita a organização da nossa equipe.
6.1 Estrutura da equipe
A cada Sprint, uma pessoa diferente assumiu o papel de Scrum Master e a
responsabilidade dos testes. Os testes foram executados pelo próprio desenvolvedor de
cada tarefa e também pela pessoa responsável por aquele Sprint.
A equipe é formada por quatro membros, com as seguintes distribuição de papéis:
Nome do membro Papel do membro
Thauane Moura Gestora de Projeto
Waldson Rodrigues Analista, Desenvolvedor e Testador
Thiago Emmanuel Gestor de Negócios
Bruno Meneses Arquiteto de Projeto
Tabela 11 – Estrutura da equipe
Descrição das Responsabilidades:
 Analista – Define uma visão geral dos requisitos, detalhar e documentar os requisitos.
 Desenvolvedor – Projetar, desenvolver e construir o software.
 Testador – Criar os casos de testes e executar os testes.
 Arquiteto de Projeto – Analisar os requisitos, projetar e desenvolver o software.
 Gerente de Projeto – Planeja as iterações, desenvolver planos do projeto e lista os
riscos.
 Gestor de Negócios – Responsável em planejar e controlar a execução de projetos
Nossa equipe por ser pequena com 4 membros, logo uma pessoa assume mais de um papel.
6.2 Mecanismos de comunicação
Os mecanismos de comunicação utilizados pelo grupo foram:
● E-mail - Facilidade de comunicação e permite manter o registro das discussões;
● Reuniões Presenciais - Permitem a comunicação face-a-face e ajudam a verificar o
andamento do projeto;
● Redes Sociais – Permitindo a comunicação e dúvidas frequentes através do
Facebook e Whatsapp.
● Ferramentas Colaborativas - Vários documentos foram editados através do
Google Drive e Skype, permitindo a colaboração de todos.
O acompanhamento do projeto será realizado semanalmente através de reuniões presenciais,
a depender da demanda semanal, ou à distância, utilizando ferramentas web de comunicação
citadas acima.

6.3 Uso do Edu-blog como ferramenta de apoio
O blog trata de uma compilação das informações pesquisadas, torna-se uma
maneira de recuperá-las após o fim do projeto. Logo, foi adotado como uma ferramenta de
apoio necessário para o conhecimento adquirido durante o projeto designando e abordado na
disciplina de gerência de projetos, auxiliando na elaboração do modelo de projeto utilizando
as boas práticas de PMBOK + PMI + Certificações.
7 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SOFTWARE
Com a finalidade de garantir a qualidade de todas as fases do projeto, algumas
preocupações foram tomadas:
● Documentação – Durante o projeto, a equipe se preocupou e tomou como
compromisso realizar a atualização da documentação do sistema sempre que uma alteração
em nível de projeto era realizada. Essa preocupação com a documentação do sistema foi
alcançada pela rigidez que os testes demandavam afim de que o sistema estivesse totalmente
de acordo com as especificações.
● Testes – A fim de atribuir qualidade final ao produto e minimizar as eventuais falhas
que viesse a ocorrer, os testes foram realizados em 3 níveis, no nível unitário no qual era
realizado pelo próprio programador, nível de integração e de sistema ambos realizados pelo
Analista de Teste e testador.
● Reuniões quinzenais - Utilizando a ideia do SCRUM, foram feitas reuniões quinzenais
de atualização do processo. Isso garantiu que as atividades mantivessem sob controle e
ocasionais dificuldades fossem conhecidas o mais rápido possível para que possam ser
controladas e contornadas.
● Controle do projeto de software - As atividades desenvolvidas durante todo o ciclo
de desenvolvimento são acompanhadas constantemente e todos os requisitos são validados
com os clientes.
● Entregas frequentes de partes funcionais do software - Isso garante que o usuário
valide cada etapa do desenvolvimento, tornando uma possível mudança nas características do
produto mais fáceis de serem gerenciadas e implementadas. Além disso, o usuário irá se
manter atualizado sobre o andamento do processo e se sentirá parte dele. Essas iterações
deverão acontecer sempre ao final de cada Sprint.

Modelo plano de projeto de sw oo gerenciamento de clientes final

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (16)

Destaque

Destaque (8)

Semelhante a Modelo plano de projeto de sw oo gerenciamento de clientes final

Semelhante a Modelo plano de projeto de sw oo gerenciamento de clientes final (20)

Modelo plano de projeto de sw oo gerenciamento de clientes final