UNIVERSIDADE FEDERAL DE SERGIPE

CENTRO DE CINCIAS EXATAS E TECNOLOGIA

DEPARTAMENTO DE COMPUTAO
CURSO DE SISTEMAS DE INFORMAO - BACHARELADO
GERNCIA DE PROJETOS 2014/2

Bruno Meneses
Thauane Moura
Thiago Dantas
Waldson Rodrigues

PLANO DE PROJETO DE SOFTWARE PARA PRODUTOS DA

LACERTAE SW

So Cristvo - Sergipe, Brasil

2014

UNIVERSIDADE FEDERAL DE SERGIPE

CENTRO DE CINCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAO
CURSO DE SISTEMAS DE INFORMAO - BACHARELADO
GERNCIA 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

Rogrio

Patrcio

Chagas

do

Nascimento como nota parcial para

disciplina Gerncia de Projetos do
curso de graduao em Sistemas
de Informao Bacharelado da
Universidade Federal de Sergipe.

So Cristvo - Sergipe, Brasil

2014

Histrico de Alteraes
Data
05/11/2014

Verso
1.1

Descrio
Criao do documento

05/11/2014

1.2

Introduo

05/11/2014

1.3

Convenes, termos e abreviaes

05/11/2014

1.4

05/11/2014

1.5

19/11/2014

1.6

Principais funes do produto de

software
Viso geral de alguns requisitos do
sistema
Estimativas do Projeto

22/11/2014

1.7

Tcnicas de Estimao

22/11/2014

1.8

15/12/2014

1.9

Recursos do Projeto

07/01/2015

2.0

Recursos Humanos

14/01/2015

2.1

Recursos de Software

15/01/2015

2.2

Recursos de Hardware

14/01/2015

2.3

20/01/2015

2.4

Reduo e Gesto do Risco

23/01/2015

2.5

Plano de Contingncia

25/01/2015

2.6

Planejamento Temporal

28/01/2015

2.7

Conjunto de Tarefas do Projeto

30/01/2015

2.8

Diagrama de Gantt

31/01/2015

2.9

Organizao do Pessoal

02/01/2015

3.0

03/01/2015

3.1

Precaues Tomadas para Assegurar

e Controlar a Qualidade do Produto
de Software
Reviso Parcial do Documento

04/01/2015

3.2

Reviso Final do Documento

Resultados

Anlise e Gesto dos Riscos

Autor(es)
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson
Bruno,
Thauane, Thiago e Waldson

Sumrio
1. INTRODUO ..................................................................................................................... 6
1.1 Convenes, termos e abreviaes ................................................................................. 6
1.2 Principais funes do produto de software ...................................................................... 7
1.3 Viso 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 Negociaes ..................................................................................... 9
[RF005] Manter Cotaes .......................................................................................... 9
[RF006] Agendar atendimento ao cliente ................................................................... 9
[RF007] Gerar Relatrios ......................................................................................... 10
[RF008] Gerar Estatsticas ....................................................................................... 10
[RF009] Efetuar Backup ........................................................................................... 10
[NFSG001] O sistema deve possuir um login para cada usurio. ................................ 10
[NFIM001] O sistema deve possuir conexo com o banco de dados MySQL. ............. 11
[NFPA001] O sistema deve ser implementado usando a linguagem de orientao a
objetos Java. ............................................................................................................... 11
2. ESTIMATIVAS DO PROJETO............................................................................................ 11
2.1 Dados histricos utilizados para as estimaes ............................................................ 11
2.2 Tcnicas de estimao e resultados .............................................................................. 12
2.2.1 Tcnica de estimao .............................................................................................. 14
2.3 Resultados .................................................................................................................... 14
2.4 Informaes para a codificao 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 ANLISE E GESTO DE RISCOS ..................................................................................... 19
3.1 Riscos do projeto .......................................................................................................... 20
3.2 Tabela de riscos ............................................................................................................ 21
3.3 Reduo e Gesto do risco ........................................................................................... 22
3.4 Plano de Contingncia .................................................................................................. 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 verso Inicial (Diagrama ER) ......................................................... 35

6 ORGANIZAO DO PESSOAL .......................................................................................... 36
6.1 Estrutura da equipe ....................................................................................................... 36
6.2 Mecanismos de comunicao ....................................................................................... 36
6.3 Uso do Edu-blog como ferramenta de apoio ................................................................. 37
7 PRECAUES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO
PRODUTO DE SOFTWARE ........................................................................................... 37

1. INTRODUO
A TI est presente em nosso dia a dia alterando a forma e a velocidade como lidamos
com as informaes.
O software projetado durante essa disciplina consiste em uma soluo Web para
pequenas e mdias corretoras de seguros. Atualmente, diante do cenrio to competitivo na
busca por clientes as empresas necessitam de ferramentas que possam lhes auxiliar na
gesto da informao.
A ideia do projeto consiste em desenvolver uma aplicao 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 informao que possam auxiliar na gesto
da empresa.
O cenrio atual possui algumas ferramentas que fornecem esse servio de forma paga, no
entanto, essas ferramentas no apresentam um layout que represente a essncia da TI para o
sculo XXI que a simplicidade e eficincia na manipulao dos dados.
Para mudar o cenrio atual foi projetado uma ferramenta que funciona na Web, o
gestor ir manipular as informaes da sua empresa em qualquer lugar, facilitando assim o
uso da informao de uma forma eficiente e segura pois o sistema implementar rotinas de
backup para assegurar a integridade da informao.
Os benefcios so notveis, cada gestor poder gerar grficos e relatrios que os
auxiliem a tomar decises que possam influenciar no resultado final da empresa.
A experincia com o software tornar os gestores mais preparados para lidar com as
adversidades surgidas no dia a dia pois conseguir ter uma viso macro do negcio, evitando
que a empresa tome rumos no desejados.

1.1 Convenes, termos e abreviaes

A correta interpretao deste documento exige o conhecimento de algumas
convenes e termos especficos e abreviaes, que so:

PMBOK do ingls, Project Body of Knowledge;

PMI Profissional de Gerncia de Projetos (do ingls, Project Management
Professional);
RF Requisito Funcional;
RI Requisito Inverso;
RNF Requisito no funcional;
SW - Software;
TI - Tecnologias da Informao.

1.2 Principais funes 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 Viso geral de alguns requisitos do sistema

Abaixo sero 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 programao Java;
3. O sistema ir utilizar o MySQL como banco de dados;
4. O acesso ao sistema ser feito atravs de um browser (navegador Web).
5. O sistema ser utilizado por 2 usurios que tero permisso para alimentar o
sistema integralmente.
6. O sistema no ter integrao com qualquer outro sistema externo.

1.3.1 Requisitos Funcionais

Nessa seo apresentamos todos os requisitos funcionais da aplicao 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 negociaes.
[RF005] O sistema deve manter cotaes.
[RF006] O sistema deve permitir agendar atendimento ao cliente.
[RF007] O sistema deve ser capaz de gerar relatrios.
[RF008] O sistema deve ser capaz de gerar estatsticas.
[RF009] O sistema deve permitir efetuar backup.

1.3.2 Prioridade dos Requisitos

Para estabelecimento de prioridades foram usadas trs denominaes, sendo elas,
essencial, importante e desejvel.

Essencial o requisito sem o qual o sistema no entra em funcionamento.

Requisitos essenciais so requisitos imprescindveis, que tm que ser
implementados impreterivelmente.
Importante o requisito sem o qual o sistema entra em funcionamento, mas de
forma no satisfatria. Requisitos importantes devem ser implementados, mas, se
no forem, o sistema poder ser implantado e usado mesmo assim.
Desejvel o requisito que no compromete as funcionalidades bsicas do sistema,
isto , o sistema pode funcionar de forma satisfatria sem ele. Requisitos desejveis
podem ser deixados para verses posteriores da soluo, caso no haja tempo hbil
para implement-los na verso que est sendo especificada.

1.3.2.1 Prioridade dos Requisitos Funcionais (RF)

Nessa seo apresentamos todas as prioridades e autor(es) dos requisitos funcionais
da aplicao relacionados ao nosso caso de uso.

[RF001] Efetuar Login

Prioridade:
Ator(es):

Essencial

Importante

Desejvel

Corretor, Funcionrio
[RF002] Manter Clientes

Prioridade:
Ator(es):

Essencial

Importante

Desejvel

Corretor

[RF003] Manter Seguradoras

Prioridade:
Ator(es):

Essencial

Importante

Desejvel

Funcionrio

[RF004] Manter Negociaes

Prioridade:
Ator(es):

Essencial

Importante

Desejvel

Corretor, Funcionrio

[RF005] Manter Cotaes

Prioridade:
Ator(es):

Essencial

Importante

Desejvel

Corretor, Funcionrio

[RF006] Agendar atendimento ao cliente

Prioridade:
Ator(es):

Essencial

Importante

Corretor, Funcionrio, Cliente

Desejvel

[RF007] Gerar Relatrios

Prioridade:
Ator(es):

Essencial

Importante

Desejvel

Corretor, Funcionrio

[RF008] Gerar Estatsticas

Prioridade:
Ator(es):

Essencial

Importante

Desejvel

Corretor, Funcionrio

[RF009] Efetuar Backup

Prioridade:
Ator(es):

Essencial

Importante

Desejvel

Corretor, Funcionrio

1.3.2.2 Prioridade dos Requisitos No-Funcionais (RNF)

Nesta seo descrevemos os requisitos no funcionais da soluo de nosso sistema
neurolgico.
Os Requisitos no-funcionais so os requisitos relacionados ao uso da aplicao em
termos de desempenho, usabilidade, confiabilidade, segurana, disponibilidade,
manutenibilidade e tecnologias envolvidas. Em geral, requisitos no-funcionais podem
constituir restries aos requisitos funcionais e no preciso o cliente dizer sobre eles, pois
eles so caractersticas mnimas de um software de qualidade.

1.3.2.2.1 Segurana
Nessa seo descrevemos os requisitos no-funcionais associados integridade, privacidade
e autenticidade dos dados da nossa aplicao.
[NFSG001] O sistema deve possuir um login para cada usurio.
Prioridade:
Requisitos
funcionais
associados:

Essencial

Importante

RF001 O sistema deve permitir efetuar o login.

Desejvel

1.3.2.2.2 Implantao
Nessa seo descrevemos os requisitos no-funcionais associados implantao da
nossa soluo.
[NFIM001] O sistema deve possuir conexo com o banco de dados MySQL.
Prioridade:
Requisitos
funcionais
associados:

Essencial

Importante

Desejvel

Todos os requisitos de RF001 a RF009.

1.3.2.2.3 Padres
Nessa seo descrevemos os requisitos no-funcionais associados a padres ou
normas que devem ser seguidos pela nossa aplicao ou pelo nosso processo de
desenvolvimento.
[NFPA001] O sistema deve ser implementado usando a linguagem de orientao a
objetos Java.
Prioridade:
Requisitos
funcionais
associados:

Essencial

Importante

Desejvel

Todos os requisitos de RF001 a RF009.

2. ESTIMATIVAS DO PROJETO
Nesta seo sero descritas as estimativas que permitem calcular custo, esforo e
tempo gastos durante a construo do projeto. Essas informaes so teis para analisar e
distribuir as atividades de acordo com um cronograma preciso de tempo e recursos
necessrios para cada uma delas.

2.1 Dados histricos utilizados para as estimaes

Por se tratar de um projeto novo, que est sob a responsabilidade de uma equipe
graduanda em sistemas de informao, no existem dados histricos utilizados para as
estimaes.

2.2 Tcnicas de estimao e resultados

Nesta seo utilizamos a mtrica de Lorenz & Kidd para calcular o esforo por pessoa
necessrio para a construo do projeto. Utilizamos o diagrama de classes de domnio,
mostrado na Figura 2 abaixo, como fonte de informaes.
De acordo com o diagrama de classes, na Figura 2, identificamos que o software possui 5
classes chaves. Utilizando interface grfica, com fator multiplicador de 2,5, teremos 13 classes
de suporte totalizando 18 classes.

Figura 2 - Diagrama de classes

2.2.1 Tcnica de estimao

A mtrica mencionada a mtrica de Lorenz & Kidd, da seo 2.2, foi utilizada de
acordo com os seguintes passos:
1. Determinar as classes-chave do projeto, atravs da anlise do diagrama de
classes de domnio (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
Interface no grfica

Multiplicador
2

Baseada em texto

2,25

GUI

2,5

GUI Complexa

3
Tabela 1 - Valores Interface x Multiplicador

3. Determinar o nmero 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 no existem dados histricos 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 diviso da quantidade total de dias pela quantidade de
pessoas que a equipe possui.

2.3 Resultados
Para realizarmos as estimaes atravs da tcnica de Lorenz & Kidd, descrita na
seo 2.2, utilizamos o diagrama de classes, exibido na Figura 2. Aps a anlise do diagrama
e das consideraes da tcnica utilizada, podemos obter as seguintes concluses abaixo,
descritos nos itens 2.3.1 e 2.3.2.

2.3.1 Passo a Passo

1. Nmero de classes-chave encontradas aps a anlise do diagrama de classes de
domnio;
5 classes-chaves:

Cliente;
Usurio;
CorretoraSeguros;
Negocio;
Seguradora.

2. Interface selecionada (De acordo com o modelo de arquitetura do sistema);

GUI
3. Nmero de classes de suporte encontrado;
5 (item 1) x 2,5 (multiplicador do item 2) = 12,5 classes de
suporte
4. Nmero 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 (esforo)
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 sbado e domingo (sem parar).
Dividido por 22 74,3 / 22 = 3 meses, 8 dias

Sendo assim, de acordo com a mtrica de Lorenz & Kidd, o tempo necessrio para a
construo do projeto deve ser de, aproximadamente, 2 meses, 14 dias, 2 horas 24min, sem
parar. Levando em considerao a quantidade de dias teis no ms, o projeto se estender
por 3 meses e 8 dias.

2.3.2 Tabela Geral

Nessa seo ser mostrada a Tabela 2, com uma viso geral descrita na seo 2.3.1.
Interface
No grfica
Baseada em texto
GUI

Multiplicador
2
2,25
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 (esforo)
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
sbado e domingo (sem parar)
Dividido por 22 74,3 / 22 = 3 meses, 8
dias

GUI complexa
3,0
Tabela 2 Tabela da execuo de mtricas descritas da seo 2.2.1

2.4 Informaes para a codificao do projeto

As seguintes regras de codificao sero adotadas no desenvolvimento do sistema de
gerenciamento de clientes:

Nomes de classes comeando com letra maiscula e com nome convincente.

Nomes de atributos vo comear com letra minscula e quando for formado por mais de
uma palavra, a primeira letra de cada palavra dever ser maiscula, possuindo tambm
nomes convincentes.

2.5 Recursos do projeto

Nas sees abaixo sero listados os recursos utilizados na construo do projeto, que
so: 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 organizao e execuo do conjunto de tarefas
classificados de acordo com uma disposio hierrquica das funcionalidades a serem
desenvolvidas e das datas disponveis para a sua construo, listadas na Tabela 8. Alm
disso, temos o ScrumMaster que o elemento que faz a ligao entre o dono do produto ou
projeto e a equipe.
SPRINT 1
Perodo: 22/10/2014 a 12/11/2014

Durao: 22 dias
ScrumMaster: Thauane
Moura

Funcionalidades:
RF001 - Efetuar Login;
RF002 - Manter Clientes;
RF003 - Manter Seguradora.

Desenvolvedor 1: Thiago
Dantas
Desenvolvedor 2: Waldson
Rodrigues
Testador: Bruno Meneses

Tabela 3 - Sprint 1

SPRINT 2
Perodo: 13/11/2014 a 30/11/2014

Durao: 18 dias

ScrumMaster: Thiago Dantas

Funcionalidades:
RF004 - Manter negociaes;
RF005 - Manter oficinas;

Desenvolvedor 1: Bruno
Meneses
Desenvolvedor 2: Thauane
Moura
Testador: Waldson Rodrigues

Tabela 4 - Sprint 2

SPRINT 3
Perodo: 01/12/2014 a 30/12/2015

Durao: 30 dias

ScrumMaster: Waldson
Rodrigues

Desenvolvedor 1: Bruno
Menezes
Desenvolvedor 2: Thiago
Dantas
Testador: Thauane Moura

Funcionalidades:
RF006 - Agendar atendimento ao cliente.

Tabela 5 - Sprint 3

SPRINT 4
Perodo: 02/01/2015 a 03/02/2015

Durao: 31 dias

ScrumMaster: Bruno Meneses

Funcionalidades:
RF007 - Gerar estatsticas;
RF008 - Gerar relatrios;
RF009 - Efetuar Backup.

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 disponveis na internet para desenvolvimento
de software como:

Banco de dados Mysql - utilizado para armazenar as informaes;

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 aplicao foram usados pcs com a seguinte
configurao:

Processador Intel Core i3

Memria 4GB
HD 500GB
Monitor LED 15,6"
Conexo internet - fornecida pela operadora Oi Internet.

Com o andamento do projeto as mquinas no apresentaram nenhum tipo de

problema e mostraram ser bastante eficaz para o desenvolvimento da aplicao em
questo.

3 ANLISE E GESTO DE RISCOS

Nesta seo sero analisados os riscos potenciais que foram prejudiciais para
o andamento do projeto. O objetivo desta anlise conhecer e minimizar, o mximo
possvel, a probabilidade de sua ocorrncia 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 classificao, que
visa determinar se a sua ocorrncia geral ou nica do projeto:

Risco

Volume de informaes maior do que o

projetado

Quantidade de mudanas projetadas

nos requisitos para o produto. Antes e
aps a entrega.

Baixa motivao dos usurios em

inserir dados no sistema por completo

Pouca quantidade de software

reutilizado

Rigidez no prazo de entrega

Restries de interoperabilidade

Necessidade
especializada

Tamanho pequeno da equipe

Comprometimento da equipe durante o

projeto

10

A equipe no
integralmente.

disponvel

11

Nvel baixo de conhecimento por parte

da equipe sobre a(s) tecnologia(s)
usada(s)

de

Projeto

uma

est

Tcnico Negcio Comum Especial

interface

Tabela 7 - Riscos x Classificao

3.2 Tabela de riscos

Na Tabela 8 foi atribuda a cada um dos riscos uma probabilidade que determina
o grau da chance deste risco acontecer e um impacto aps o efetivo acontecimento deste
evento.

Risco

Probabilidade

Impacto

Volume de informaes maior do que o

projetado

60%

Crtico

Quantidade de mudanas projetadas nos

requisitos para o produto. Antes e aps a
entrega

50%

Crtico

Pouca quantidade de software reutilizado

45%

Crtico

Rigidez do prazo de entrega

40%

Crtico

Baixa motivao dos usurios em inserir dados

no sistema por completo

50%

Moderado

Restries de interoperabilidade

35%

Moderado

Necessidade de uma interface especializada

30%

Moderado

Comprometimento da equipe durante o projeto

25%

Moderado

Nvel 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 no est disponvel integralmente.

20%

Marginal

Tabela 8 - Anlise Risco x Probabilidade x Impacto

3.3 Reduo e Gesto do risco

Os quadros a seguir, de 1 a 11 apresentam estratgias para a reduo e/ou
gesto dos riscos identificados na seo 3.2:

Anlise do Risco 1
1- Volume de informaes maior do que o projetado
Probabilidade: 30%

Impacto: Crtico

Descrio: O volume de informaes trafegado pelo

sistema pode ser maior que o projetado e causar
lentido no sistema.
Plano de Contingncia: Alocar mais espaos
no servidor para suportar o trfego de dados.
Estratgia de reduo: Acompanhar as
estatsticas de utilizao do sistema para evitar que
os usurios fiquem com o sistema indisponvel.
Responsvel: Thiago Dantas

Status: Em Andamento
Quadro 1 - Anlise do risco 1

Anlise do Risco 2
2- Quantidade de mudanas projetadas nos requisitos para o produto. Antes e aps a entrega
Probabilidade: 50%

Impacto: Crtico

Descrio: Os requisitos do projeto podem vir a ser

alterados durante o projeto.

Plano de Contingncia: Renegociar com o

cliente os prazos anteriormente definidos.

Estratgia de reduo: Negociar junto ao cliente

os requisitos, a fim de definir o escopo do projeto.
Responsvel: Thiago Dantas

Status: Em Andamento
Quadro 2 - Anlise do risco 2

Anlise do Risco 3
3- Baixa motivao dos usurios em inserir dados no sistema por completo
Probabilidade: 50%

Impacto: Moderado

Descrio: Os usurios podem no inserir dados no

sistema por completo por achar que devem
disponibilizar tempo para outras atividades da
empresa.

Plano de Contingncia: Disponibilizar telas

alternativas com um nmero mnimo de
informaes para o usurio utilizar em casos de
urgncia.

Estratgia de reduo: Simplificar ao mximo os

formulrios para agilizar a insero de dados.

Responsvel: Bruno Meneses

Status: Em Andamento
Quadro 3 - Anlise do risco 3

Anlise do Risco 4
4- Pouca quantidade de software reutilizado
Probabilidade: 45%

Impacto: Crtico

Descrio: A maior parte dos componentes utilizados

no produto implementados sem utilizar componente
reutilizados.
Plano de Contingncia: Pesquisar por
componentes reutilizveis para utilizar no
projeto.
Estratgia de reduo: Planejar medidas que
facilitem a reutilizao de software, tais como utilizar,
quando possvel, padres de projeto.

Responsvel: Bruno Meneses

Status: Em Andamento
Quadro 4 - Anlise do risco 4

Anlise do Risco 5
5- Rigidez do prazo de entrega
Probabilidade: 40%

Impacto: Crtico

Descrio: O prazo para entregar todo o projeto

pequeno e inflexvel.

Estratgia de reduo: Realizar diviso das

atividades do projeto entre a equipe de forma que a
entrega permanea dentro do prazo.

Responsvel: Thauane Moura

Plano de Contingncia: Remanejar a diviso

das atividades entre os membros da equipe,
visando colocar as atividades dentro do prazo
de entrega, realizando-as por incrementos.
Porm tentando sempre evitar sobrecarga de
atividades.

Status: Em Andamento
Quadro 5 - Anlise do risco 5

Anlise do Risco 6
6- Restries de interoperabilidade
Probabilidade: 35%

Impacto: Moderado

Descrio: O sistema no projetado para se

comunicar com outro sistema.
Plano de Contingncia: Disponibilizar no
sistema, a exportao de dados em extenses
.pdf e .xls.
Estratgia de reduo: Identificar quais os
possveis sistemas externos que o produto ir
interagir.

Responsvel: Thauane Moura

Status: Em Andamento
Quadro 6 - Anlise do risco 6

Anlise do Risco 7
7- Necessidade de uma interface especializada
Probabilidade: 30%

Impacto: Moderado

Descrio: Desenvolver uma interface especfica

ao setor de seguros para evitar que o usurio sinta
dificuldades de adaptao ao sistema.
Plano de Contingncia: Disponibilizar telas de
esboo para usurios experientes com as regras
de negcio, afim de obter feedback.
Estratgia
de
reduo:
Desenvolver uma
interface levando em considerao as interfaces dos
sistemas utilizados pelas Seguradoras nos quais os
usurios j esto acostumados a utilizar.
Responsvel: Waldson Rodrigues

Status: Em Andamento
Quadro 7 - Anlise do risco 7

Anlise do Risco 8
8- Tamanho pequeno da equipe
Probabilidade: 25%

Impacto: Marginal

Descrio: A quantidade de pessoas na equipe

que est no projeto pequena.

Estratgia de reduo: Realizar diviso das

atividades do projeto entre a equipe de forma que a
entrega permanea dentro do prazo, como tambm,
evitar sobrecarga de atividades.

Responsvel: Waldson Rodrigues

Plano de Contingncia: Remanejar a diviso

das atividades entre o membros da equipe,
porm tentando sempre evitar sobrecarga de
atividades.
Renegociar com o cliente, o tamanho do
produto que ser entregue.

Status: Em Andamento
Quadro 8 - Anlise do risco 8

Anlise do Risco 9
9- Comprometimento da equipe durante o projeto
Probabilidade: 25%

Impacto: Moderado

Descrio: A equipe, ou parte dela, no est

comprometida com o projeto seguindo o que foi
planejado.

Estratgia de reduo: Distribuir as atividades de

acordo com o grau de afinidade e experincia de
cada membro da equipe para utilizar o mximo de
conhecimento do membro em questo.

Responsvel: Thiago Dantas

Plano de Contingncia: Realizar pequenas

reunies peridicas ao longo do projeto para
revisar sobre o seu andamento, e discutir as
dificuldades percebidas pela equipe.

Status: Em Andamento
Quadro 9 - Anlise do risco 9

Anlise do Risco 10
10 - Equipe no est disponvel integralmente
Probabilidade: 20%

Impacto: Marginal

Descrio: Devido a outras atividades extras ao

projeto realizadas por cada integrante da equipe, o
tempo disponibilizado para o projeto no integral.

Estratgia de reduo: Realizar diviso das

atividades do projeto entre a equipe, de forma que a
entrega permanea dentro do prazo.

Responsvel: Thauane Moura

Plano de Contingncia: Revisar as atividades

realizadas por cada integrante para remanejar
qualquer sobrecarga de trabalho sobre
algum. A diviso das tarefas entre os
membros da equipe deve facilitar o processo.

Status: Em Andamento
Quadro 10 - Anlise do risco 10

Anlise do Risco 11
11 Pouco conhecimento por parte da equipe sobre a(s) tecnologia(s) usada(s)
Probabilidade: 10%

Impacto: Moderado

Descrio: A equipe, ou parte dela, no possui

conhecimento aprofundado sobre a tecnologia que
est sendo utilizada.

Estratgia de reduo: Reunir e disponibilizar

para a equipe, materiais de estudo que forneam
aprendizado sobre a(s) tecnologia(s) utilizada(s).

Plano
de
Contingncia:
Realizar
o
planejamento para que desenvolvimento de
trechos de codificao mais complexos sejam
feitos utilizando a tcnica de programao em
par, ao invs de serem desenvolvidas
individualmente, aproveitando assim o mximo
de conhecimento de ambos os programadores.

Realizar treinamento da equipe sobre a tecnologia

que ser utilizada.
Responsvel: Waldson Rodrigues

Status: Em Andamento

Quadro 11 - Anlise do risco 11

3.4 Plano de Contingncia

Atualmente, a maioria dos negcios necessita de Tecnologia da Informao e de
sistemas automatizados para auxiliar na gesto organizacional.Desta forma, para algumas
empresas, ficar com o servio indisponvel por algumas horas pode significar perdas
significativas gerando prejuzos financeiros.
necessrio avaliar o nvel de dependncia do negcio em relao a TI e a dependncia
de servios baseados na Internet. Para evitar futuros transtornos, toda e qualquer empresa deve
desenvolver um plano de contingncia que possa garantir a continuidade do negcio mesmo
em situaes como desastres naturais, roubos, fraudes ou at mesmo um ataque ciberntico
de grande proporo.
Pensando nisso, foi desenvolvido uma rotina de backup que alm de efetuar
rotineiramente o armazenamento das informaes, disponibiliza a exportao dos arquivos no
formato .xls para garantir que mesmo em situaes onde a Internet seja ausente o mnimo de
informaes possa ser acesso nem que seja via papel.
Alm disso, foi garantido que o backup gerado no seja salvo no mesmo local do
escritrio, para isso foi contratado um servio de armazenamento na nuvem para garantir que
as informaes no sejam perdidas mesmo em situao de um desastre natural local.

4. PLANEJAMENTO TEMPORAL
Nesta seo so apresentadas as datas de execuo das tarefas, bem como seus
responsveis. No planejamento temporal definimos os marcos e planos de aes. A
mensurao do tempo para construo do projeto definido no item 2.3 foi utilizado para dividir
as fases do projeto. Essa parte de extrema importncia para a mensurao do andamento
do projeto, e do cumprimento das suas expectativas na esfera temporal. As fases tiveram a
diviso do tempo conforme a Tabela 9.

Fase
Planejamento
Anlise e Projeto
Codificao
Testes

Porcentagem
15%
20%
50%
15%
Tabela 9 - Fases do projeto

Durao (Dias)
16 dias
30 dias
40 dias
15 dias

4.1 Conjunto de Tarefas do Projeto

O SCRUM define a diviso das funcionalidades em tarefas menores
executveis pelos desenvolvedores. A Tabela 10 relaciona as tarefas com sua fase.

Fase

Tarefas

Planejamento

Definio de escopo;
Funcionalidades e restries;
Documento de concepo.

Anlise e Projeto

Especificao de Requisitos;
Especificao de Requisitos no funcionais;
Especificao dos diagramas de anlise;
Documento de Analise;
Definio da arquitetura de Projeto;
Especificao dos diagramas de projeto;
Documento de Projeto;
Especificao e detalhamento de requisito.

Codificao

Desenvolvimento da interface grfica;

Desenvolvimento da regra de negcio.

Teste

Teste e validao de documentao;

Teste e validao de software.
Tabela 10 - Distribuio das tarefas em fases

4.2 Diagrama de Gantt

O diagrama de Gantt um instrumento que permite modelar graficamente a
bplanificao do avano e planejamento das tarefas necessrias para a realizao 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

Figura 4 Diagrama de Gantt

Figura 5 Diagrama de Gantt

Figura 6 Diagrama de Gantt

Figura 7 Diagrama de Gantt

5 PROJETO DO BANCO DE DADOS

Nessa seo 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 estratgias de armazenamento e recuperao.

5.1 Modelo de Dados verso Inicial (Diagrama ER)

Figura 8 - Diagrama ER

6 ORGANIZAO DO PESSOAL
Nessa seo ser descrita a organizao 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 prprio desenvolvedor de
cada tarefa e tambm pela pessoa responsvel por aquele Sprint.
A equipe formada por quatro membros, com as seguintes distribuio de papis:
Nome do membro
Papel do membro
Thauane Moura
Gestora de Projeto
Waldson Rodrigues
Analista, Desenvolvedor e Testador
Thiago Emmanuel
Gestor de Negcios
Bruno Meneses
Arquiteto de Projeto
Tabela 11 Estrutura da equipe
Descrio das Responsabilidades:

Analista Define uma viso 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 iteraes, desenvolver planos do projeto e lista os
riscos.
Gestor de Negcios Responsvel em planejar e controlar a execuo de projetos

Nossa equipe por ser pequena com 4 membros, logo uma pessoa assume mais de um papel.
6.2 Mecanismos de comunicao
Os mecanismos de comunicao utilizados pelo grupo foram:

E-mail - Facilidade de comunicao e permite manter o registro das discusses;

Reunies Presenciais - Permitem a comunicao face-a-face e ajudam a verificar o
andamento do projeto;
Redes Sociais Permitindo a comunicao e dvidas frequentes atravs do
Facebook e Whatsapp.
Ferramentas Colaborativas - Vrios documentos foram editados atravs do
Google Drive e Skype, permitindo a colaborao de todos.
O acompanhamento do projeto ser realizado semanalmente atravs de reunies presenciais,
a depender da demanda semanal, ou distncia, utilizando ferramentas web de comunicao
citadas acima.

6.3 Uso do Edu-blog como ferramenta de apoio

O blog trata de uma compilao das informaes pesquisadas, torna-se uma
maneira de recuper-las aps o fim do projeto. Logo, foi adotado como uma ferramenta de
apoio necessrio para o conhecimento adquirido durante o projeto designando e abordado na
disciplina de gerncia de projetos, auxiliando na elaborao do modelo de projeto utilizando
as boas prticas de PMBOK + PMI + Certificaes.

7 PRECAUES 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
preocupaes foram tomadas:

Documentao Durante o projeto, a equipe se preocupou e tomou como

compromisso realizar a atualizao da documentao do sistema sempre que uma alterao
em nvel de projeto era realizada. Essa preocupao com a documentao do sistema foi
alcanada pela rigidez que os testes demandavam afim de que o sistema estivesse totalmente
de acordo com as especificaes.

Testes A fim de atribuir qualidade final ao produto e minimizar as eventuais falhas

que viesse a ocorrer, os testes foram realizados em 3 nveis, no nvel unitrio no qual era
realizado pelo prprio programador, nvel de integrao e de sistema ambos realizados pelo
Analista de Teste e testador.

Reunies quinzenais - Utilizando a ideia do SCRUM, foram feitas reunies quinzenais

de atualizao do processo. Isso garantiu que as atividades mantivessem sob controle e
ocasionais dificuldades fossem conhecidas o mais rpido possvel para que possam ser
controladas e contornadas.

Controle do projeto de software - As atividades desenvolvidas durante todo o ciclo

de desenvolvimento so acompanhadas constantemente e todos os requisitos so validados
com os clientes.

Entregas frequentes de partes funcionais do software - Isso garante que o usurio

valide cada etapa do desenvolvimento, tornando uma possvel mudana nas caractersticas do
produto mais fceis de serem gerenciadas e implementadas. Alm disso, o usurio ir se
manter atualizado sobre o andamento do processo e se sentir parte dele. Essas iteraes
devero acontecer sempre ao final de cada Sprint.