Upload
thauane-garcia
View
11
Download
0
Embed Size (px)
DESCRIPTION
Modelo Plano de Projeto de SW OO - Gerenciamento de Clientes
Citation preview
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
Bruno, Thauane, Thiago e Waldson
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
Bruno, Thauane, Thiago e Waldson
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
Prioridade: Essencial Importante Desejvel
Ator(es): Corretor
[RF003] Manter Seguradoras
Prioridade: Essencial Importante Desejvel
Ator(es): Funcionrio
[RF004] Manter Negociaes
Prioridade: Essencial Importante Desejvel
Ator(es): Corretor, Funcionrio
[RF005] Manter Cotaes
Prioridade: Essencial Importante Desejvel
Ator(es): Corretor, Funcionrio
[RF006] Agendar atendimento ao cliente
Prioridade: Essencial Importante Desejvel
Ator(es): Corretor, Funcionrio, Cliente
[RF007] Gerar Relatrios
Prioridade: Essencial Importante Desejvel
Ator(es): Corretor, Funcionrio
[RF008] Gerar Estatsticas
Prioridade: Essencial Importante Desejvel
Ator(es): Corretor, Funcionrio
[RF009] Efetuar Backup
Prioridade: Essencial Importante Desejvel
Ator(es): 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: Essencial Importante Desejvel
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.
Prioridade: Essencial Importante Desejvel
Requisitos funcionais associados:
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: Essencial Importante Desejvel
Requisitos funcionais associados:
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
Perodo: 13/11/2014 a 30/11/2014 Durao: 18 dias
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
Perodo: 01/12/2014 a 30/12/2015 Durao: 30 dias
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
Perodo: 02/01/2015 a 03/02/2015 Durao: 31 dias
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
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.
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
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.
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.
Responsvel: Waldson Rodrigues 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.
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.
Responsvel: Thiago Dantas 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.
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.
Responsvel: Thauane Moura 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. 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.
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 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
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.