modelo plano de projeto de sw oo - gerenciamento de clientes

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 Verso Descrio Autor(es)

05/11/2014 1.1 Criao do documento Bruno, Thauane, Thiago e Waldson

05/11/2014 1.2 Introduo Bruno, Thauane, Thiago e Waldson

05/11/2014 1.3 Convenes, termos e abreviaes Bruno, Thauane, Thiago e Waldson

05/11/2014 1.4 Principais funes do produto de software

Bruno, Thauane, Thiago e Waldson

05/11/2014 1.5 Viso geral de alguns requisitos do sistema


19/11/2014 1.6 Estimativas do Projeto Bruno, Thauane, Thiago e Waldson

22/11/2014 1.7 Tcnicas de Estimao Bruno, Thauane, Thiago e Waldson

22/11/2014 1.8 Resultados Bruno, Thauane, Thiago e Waldson

15/12/2014 1.9 Recursos do Projeto Bruno, Thauane, Thiago e Waldson

07/01/2015 2.0 Recursos Humanos Bruno, Thauane, Thiago e Waldson

14/01/2015 2.1 Recursos de Software Bruno, Thauane, Thiago e Waldson

15/01/2015 2.2 Recursos de Hardware Bruno, Thauane, Thiago e Waldson

14/01/2015 2.3 Anlise e Gesto dos Riscos Bruno, Thauane, Thiago e Waldson

20/01/2015 2.4 Reduo e Gesto do Risco Bruno, Thauane, Thiago e Waldson

23/01/2015 2.5 Plano de Contingncia Bruno, Thauane, Thiago e Waldson

25/01/2015 2.6 Planejamento Temporal Bruno, Thauane, Thiago e Waldson

28/01/2015 2.7 Conjunto de Tarefas do Projeto Bruno, Thauane, Thiago e Waldson

30/01/2015 2.8 Diagrama de Gantt Bruno, Thauane, Thiago e Waldson

31/01/2015 2.9 Organizao do Pessoal Bruno, Thauane, Thiago e Waldson

02/01/2015 3.0 Precaues Tomadas para Assegurar e Controlar a Qualidade do Produto

de Software


03/01/2015 3.1 Reviso Parcial do Documento Bruno, Thauane, Thiago e Waldson

04/01/2015 3.2 Reviso Final do Documento 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: Essencial Importante Desejvel

Ator(es): Corretor, Funcionrio

[RF002] Manter Clientes


Ator(es): Corretor

[RF003] Manter Seguradoras


Ator(es): Funcionrio

[RF004] Manter Negociaes



[RF005] Manter Cotaes



[RF006] Agendar atendimento ao cliente


Ator(es): Corretor, Funcionrio, Cliente

[RF007] Gerar Relatrios



[RF008] Gerar Estatsticas



[RF009] Efetuar Backup



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.


Requisitos funcionais associados:

RF001 O sistema deve permitir efetuar o login.

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.



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.



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 Multiplicador

Interface no grfica 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 Multiplicador

No grfica 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 (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

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 negociaes; 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 estatsticas; RF008 - Gerar relatrios; 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 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:

N Risco Projeto Tcnico Negcio Comum Especial

1 Volume de informaes maior do que o projetado

X

2 Quantidade de mudanas projetadas nos requisitos para o produto. Antes e aps a entrega.

X X

3 Baixa motivao dos usurios em inserir dados no sistema por completo

X

4 Pouca quantidade de software reutilizado

X

5 Rigidez no prazo de entrega X X

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

X X

11 Nvel baixo de conhecimento por parte da equipe sobre a(s) tecnologia(s) usada(s)

X X

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.

N Risco Probabilidade Impacto

1 Volume de informaes maior do que o projetado

60% Crtico

2 Quantidade de mudanas projetadas nos requisitos para o produto. Antes e aps a entrega

50% Crtico

3 Pouca quantidade de software reutilizado 45% Crtico

4 Rigidez do prazo de entrega 40% Crtico

5 Baixa motivao dos usurios em inserir dados no sistema por completo

50% Moderado

6 Restries de interoperabilidade 35% Moderado

7 Necessidade de uma interface especializada 30% Moderado

8 Comprometimento da equipe durante o projeto 25% Moderado

9 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


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.



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


Anlise do Risco 4

4- Pouca quantidade de software reutilizado


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


Anlise do Risco 5

5- Rigidez do prazo de entrega


Descrio: O prazo para entregar todo o projeto pequeno e inflexvel.

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.

Estratgia de reduo: Realizar diviso das atividades do projeto entre a equipe de forma que a entrega permanea dentro do prazo.

Responsvel: Thauane Moura Status: Em Andamento


Anlise do Risco 6

6- Restries de interoperabilidade


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.



Anlise do Risco 7

7- Necessidade de uma interface especializada


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


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.

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.

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.



Anlise do Risco 9

9- Comprometimento da equipe durante o projeto


Descrio: A equipe, ou parte dela, no est comprometida com o projeto seguindo o que foi planejado.

Plano de Contingncia: Realizar pequenas reunies peridicas ao longo do projeto para revisar sobre o seu andamento, e discutir as dificuldades percebidas pela equipe.

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.



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.

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.

Estratgia de reduo: Realizar diviso das atividades do projeto entre a equipe, de forma que a entrega permanea dentro do prazo.



Anlise do Risco 11

11 Pouco conhecimento por parte da equipe sobre a(s) tecnologia(s) usada(s)


Descrio: A equipe, ou parte dela, no possui conhecimento aprofundado sobre a tecnologia que est sendo utilizada. 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.

Estratgia de reduo: Reunir e disponibilizar para a equipe, materiais de estudo que forneam aprendizado sobre a(s) tecnologia(s) utilizada(s).

Realizar treinamento da equipe sobre a tecnologia que ser utilizada.



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 Porcentagem Durao (Dias)

Planejamento 15% 16 dias

Anlise e Projeto 20% 30 dias

Codificao 50% 40 dias

Testes 15% 15 dias

Tabela 9 - Fases do projeto

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

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.

modelo plano de projeto de sw oo - gerenciamento de clientes

Documents