View
154
Download
2
Category
Preview:
Citation preview
UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
CURSO DE SISTEMAS DE INFORMAÇÃO - BACHARELADO
GERÊNCIA DE PROJETOS 2014/2
Bruno Meneses
Thauane Moura
Thiago Dantas
Waldson Rodrigues
PLANO DE PROJETO DE SOFTWARE PARA PRODUTOS DA
LACERTAE SW
São Cristóvão - Sergipe, Brasil
2014
UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
CURSO DE SISTEMAS DE INFORMAÇÃO - BACHARELADO
GERÊNCIA DE PROJETOS 2014/2
Bruno Meneses
Thauane Moura
Thiago Dantas
Waldson Rodrigues
PLANO DE PROJETO DE SOFTWARE PARA PRODUTOS DA
LACERTAE SW
Trabalho apresentado ao Prof. PhD
Rogério Patrício Chagas do
Nascimento como nota parcial para
disciplina Gerência de Projetos do
curso de graduação em Sistemas
de Informação – Bacharelado da
Universidade Federal de Sergipe.
São Cristóvão - Sergipe, Brasil
2014
Histórico de Alterações
Data Versão Descrição Autor(es)
05/11/2014 1.1 Criação do documento Bruno, Thauane, Thiago e Waldson
05/11/2014 1.2 Introdução Bruno, Thauane, Thiago e Waldson
05/11/2014 1.3 Convenções, termos e abreviações Bruno, Thauane, Thiago e Waldson
05/11/2014 1.4 Principais funções do produto de software
Bruno, Thauane, Thiago e Waldson
05/11/2014 1.5 Visão 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 Técnicas de Estimação 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 Análise e Gestão dos Riscos Bruno, Thauane, Thiago e Waldson
20/01/2015 2.4 Redução e Gestão do Risco Bruno, Thauane, Thiago e Waldson
23/01/2015 2.5 Plano de Contingência 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 Organização do Pessoal Bruno, Thauane, Thiago e Waldson
02/01/2015 3.0 Precauções Tomadas para Assegurar e Controlar a Qualidade do Produto
de Software
Bruno, Thauane, Thiago e Waldson
03/01/2015 3.1 Revisão Parcial do Documento Bruno, Thauane, Thiago e Waldson
04/01/2015 3.2 Revisão Final do Documento Bruno, Thauane, Thiago e Waldson
Sumário
1. INTRODUÇÃO ..................................................................................................................... 6
1.1 Convenções, termos e abreviações ................................................................................. 6
1.2 Principais funções do produto de software ...................................................................... 7
1.3 Visão geral de alguns requisitos do sistema ..................................................................... 7
1.3.1 Requisitos Funcionais ............................................................................................... 8
1.3.2 Prioridade dos Requisitos .......................................................................................... 8
[RF001] – Efetuar Login ................................................................................................ 9
[RF002] – Manter Clientes ............................................................................................. 9
[RF003] – Manter Seguradoras ..................................................................................... 9
[RF004] – Manter Negociações ..................................................................................... 9
[RF005] – Manter Cotações .......................................................................................... 9
[RF006] – Agendar atendimento ao cliente ................................................................... 9
[RF007] – Gerar Relatórios ......................................................................................... 10
[RF008] – Gerar Estatísticas ....................................................................................... 10
[RF009] – Efetuar Backup ........................................................................................... 10
[NFSG001] O sistema deve possuir um login para cada usuário. ................................ 10
[NFIM001] O sistema deve possuir conexão com o banco de dados MySQL. ............. 11
[NFPA001] O sistema deve ser implementado usando a linguagem de orientação a objetos Java. ............................................................................................................... 11
2. ESTIMATIVAS DO PROJETO............................................................................................ 11
2.1 Dados históricos utilizados para as estimações ............................................................ 11
2.2 Técnicas de estimação e resultados .............................................................................. 12
2.2.1 Técnica de estimação .............................................................................................. 14
2.3 Resultados .................................................................................................................... 14
2.4 Informações para a codificação do projeto .................................................................... 16
2.5 Recursos do projeto ...................................................................................................... 16
2.5.1 Recursos humanos ................................................................................................. 17
2.5.2 Recursos de software .............................................................................................. 18
2.5.3 Recursos de hardware ............................................................................................ 19
3 ANÁLISE E GESTÃO DE RISCOS ..................................................................................... 19
3.1 Riscos do projeto .......................................................................................................... 20
3.2 Tabela de riscos ............................................................................................................ 21
3.3 Redução e Gestão do risco ........................................................................................... 22
3.4 Plano de Contingência .................................................................................................. 27
4. PLANEJAMENTO TEMPORAL .......................................................................................... 28
4.1 Conjunto de Tarefas do Projeto .................................................................................... 28
4.2 Diagrama de Gantt ........................................................................................................ 29
5 PROJETO DO BANCO DE DADOS .................................................................................... 35
5.1 Modelo de Dados – versão Inicial (Diagrama ER) ......................................................... 35
6 ORGANIZAÇÃO DO PESSOAL .......................................................................................... 36
6.1 Estrutura da equipe ....................................................................................................... 36
6.2 Mecanismos de comunicação ....................................................................................... 36
6.3 Uso do Edu-blog como ferramenta de apoio ................................................................. 37
7 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SOFTWARE ........................................................................................... 37
1. INTRODUÇÃO
A TI está presente em nosso dia a dia alterando a forma e a velocidade como lidamos com as informações.
O software projetado durante essa disciplina consiste em uma solução Web para
pequenas e médias corretoras de seguros. Atualmente, diante do cenário tão competitivo na busca por clientes as empresas necessitam de ferramentas que possam lhes auxiliar na gestão da informação.
A ideia do projeto consiste em desenvolver uma aplicação que possa centralizar os dados dos atuais clientes de uma corretora de seguros e diante desses dados, interpretar e analisar para que esses dados se transformem em informação que possam auxiliar na gestão da empresa. O cenário atual possui algumas ferramentas que fornecem esse serviço de forma paga, no entanto, essas ferramentas não apresentam um layout que represente a essência da TI para o século XXI que é a simplicidade e eficiência na manipulação dos dados.
Para mudar o cenário atual foi projetado uma ferramenta que funciona na Web, o gestor irá manipular as informações da sua empresa em qualquer lugar, facilitando assim o uso da informação de uma forma eficiente e segura pois o sistema implementará rotinas de backup para assegurar a integridade da informação.
Os benefícios são notáveis, cada gestor poderá gerar gráficos e relatórios que os auxiliem a tomar decisões que possam influenciar no resultado final da empresa. A experiência com o software tornará os gestores mais preparados para lidar com as adversidades surgidas no dia a dia pois conseguirá ter uma visão macro do negócio, evitando que a empresa tome rumos não desejados.
1.1 Convenções, termos e abreviações
A correta interpretação deste documento exige o conhecimento de algumas convenções e termos específicos e abreviações, que são:
PMBOK – do inglês, Project Body of Knowledge; PMI – Profissional de Gerência de Projetos (do inglês, Project Management
Professional); RF – Requisito Funcional; RI – Requisito Inverso; RNF – Requisito não funcional; SW - Software; TI - Tecnologias da Informação.
1.2 Principais funções do produto de software
O diagrama representado na Figura 1 abaixo apresenta as principais funcionalidades
do sistema de gerenciamento de clientes. Esse diagrama é chamado de use case que mostra
ilustrativamente os atores que atuam no sistema de controle gerenciamento de clientes.
Figura 1 - Diagrama de casos de uso do sistema
1.3 Visão geral de alguns requisitos do sistema
Abaixo serão listadas alguns requisitos do sistema de gerenciamento de clientes:
1. O sistema irá ser desenvolvido utilizando arquitetura Web;
2. O sistema irá utilizar a linguagem de programação Java;
3. O sistema irá utilizar o MySQL como banco de dados;
4. O acesso ao sistema será feito através de um browser (navegador Web).
5. O sistema será utilizado por 2 usuários que terão permissão para alimentar o sistema integralmente.
6. O sistema não terá integração com qualquer outro sistema externo.
1.3.1 Requisitos Funcionais
Nessa seção apresentamos todos os requisitos funcionais da aplicação relacionados ao nosso caso de uso na Figura 1:
[RF001] O sistema deve permitir efetuar o login.
[RF002] O sistema deve manter clientes.
[RF003] O sistema deve manter seguradora.
[RF004] O sistema deve manter negociações.
[RF005] O sistema deve manter cotações.
[RF006] O sistema deve permitir agendar atendimento ao cliente.
[RF007] O sistema deve ser capaz de gerar relatórios.
[RF008] O sistema deve ser capaz de gerar estatísticas.
[RF009] O sistema deve permitir efetuar backup.
1.3.2 Prioridade dos Requisitos
Para estabelecimento de prioridades foram usadas três denominações, sendo elas, “essencial”, “importante” e “desejável”.
Essencial é o requisito sem o qual o sistema não entra em funcionamento. Requisitos essenciais são requisitos imprescindíveis, que têm que ser implementados impreterivelmente.
Importante é o requisito sem o qual o sistema entra em funcionamento, mas de forma não satisfatória. Requisitos importantes devem ser implementados, mas, se não forem, o sistema poderá ser implantado e usado mesmo assim.
Desejável é o requisito que não compromete as funcionalidades básicas do sistema, isto é, o sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveis podem ser deixados para versões posteriores da solução, caso não haja tempo hábil para implementá-los na versão que está sendo especificada.
1.3.2.1 Prioridade dos Requisitos Funcionais (RF)
Nessa seção apresentamos todas as prioridades e autor(es) dos requisitos funcionais da aplicação relacionados ao nosso caso de uso.
[RF001] – Efetuar Login
Prioridade: Essencial Importante Desejável
Ator(es): Corretor, Funcionário
[RF002] – Manter Clientes
Prioridade: Essencial Importante Desejável
Ator(es): Corretor
[RF003] – Manter Seguradoras
Prioridade: Essencial Importante Desejável
Ator(es): Funcionário
[RF004] – Manter Negociações
Prioridade: Essencial Importante Desejável
Ator(es): Corretor, Funcionário
[RF005] – Manter Cotações
Prioridade: Essencial Importante Desejável
Ator(es): Corretor, Funcionário
[RF006] – Agendar atendimento ao cliente
Prioridade: Essencial Importante Desejável
Ator(es): Corretor, Funcionário, Cliente
[RF007] – Gerar Relatórios
Prioridade: Essencial Importante Desejável
Ator(es): Corretor, Funcionário
[RF008] – Gerar Estatísticas
Prioridade: Essencial Importante Desejável
Ator(es): Corretor, Funcionário
[RF009] – Efetuar Backup
Prioridade: Essencial Importante Desejável
Ator(es): Corretor, Funcionário
1.3.2.2 Prioridade dos Requisitos Não-Funcionais (RNF)
Nesta seção descrevemos os requisitos não funcionais da solução de nosso sistema neurológico.
Os Requisitos não-funcionais são os requisitos relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenibilidade e tecnologias envolvidas. Em geral, requisitos não-funcionais podem constituir restrições aos requisitos funcionais e não é preciso o cliente dizer sobre eles, pois eles são características mínimas de um software de qualidade.
1.3.2.2.1 Segurança
Nessa seção descrevemos os requisitos não-funcionais associados à integridade, privacidade e autenticidade dos dados da nossa aplicação.
[NFSG001] O sistema deve possuir um login para cada usuário.
Prioridade: Essencial Importante Desejável
Requisitos funcionais associados:
RF001 – O sistema deve permitir efetuar o login.
1.3.2.2.2 Implantação
Nessa seção descrevemos os requisitos não-funcionais associados à implantação da nossa solução.
[NFIM001] O sistema deve possuir conexão com o banco de dados MySQL.
Prioridade: Essencial Importante Desejável
Requisitos funcionais associados:
Todos os requisitos de RF001 a RF009.
1.3.2.2.3 Padrões
Nessa seção descrevemos os requisitos não-funcionais associados a padrões ou normas que devem ser seguidos pela nossa aplicação ou pelo nosso processo de desenvolvimento.
[NFPA001] O sistema deve ser implementado usando a linguagem de orientação a objetos Java.
Prioridade: Essencial Importante Desejável
Requisitos funcionais associados:
Todos os requisitos de RF001 a RF009.
2. ESTIMATIVAS DO PROJETO
Nesta seção serão descritas as estimativas que permitem calcular custo, esforço e
tempo gastos durante a construção do projeto. Essas informações são úteis para analisar e
distribuir as atividades de acordo com um cronograma preciso de tempo e recursos
necessários para cada uma delas.
2.1 Dados históricos utilizados para as estimações
Por se tratar de um projeto novo, que está sob a responsabilidade de uma equipe
graduanda em sistemas de informação, não existem dados históricos utilizados para as
estimações.
2.2 Técnicas de estimação e resultados
Nesta seção utilizamos a métrica de Lorenz & Kidd para calcular o esforço por pessoa necessário para a construção do projeto. Utilizamos o diagrama de classes de domínio, mostrado na Figura 2 abaixo, como fonte de informações.
De acordo com o diagrama de classes, na Figura 2, identificamos que o software possui 5 classes chaves. Utilizando interface gráfica, com fator multiplicador de 2,5, teremos 13 classes de suporte totalizando 18 classes.
Figura 2 - Diagrama de classes
2.2.1 Técnica de estimação
A métrica mencionada a métrica de Lorenz & Kidd, da seção 2.2, foi utilizada de
acordo com os seguintes passos:
1. Determinar as classes-chave do projeto, através da análise do diagrama de
classes de domínio (apresentado na Figura 2);
2. Determinar o tipo da interface do projeto, que deve ser classificada de acordo
com um dos itens da Tabela 1;
Interface Multiplicador
Interface não gráfica 2
Baseada em texto 2,25
GUI 2,5
GUI Complexa 3
Tabela 1 - Valores Interface x Multiplicador
3. Determinar o número de classes de suporte, efetuando o produto da quantidade de
classes-chave pelo multiplicador da interface escolhida anteriormente;
4. Determinar o total de classes do projeto, somando a quantidade de classes de
suporte com a quantidade de classes-chave;
5. Determinar a quantidade de dias que uma pessoa levaria para construir uma classe.
Quando não existem dados históricos a serem considerados, Lorenz
& Kidd sugerem de quinze a vinte dias;
6. Determinar a quantidade total de dias que uma pessoa levaria para construir todo o
projeto, efetuando o produto do total de classes do projeto pela quantidade de dias
escolhida anteriormente;
7. Determinar a quantidade total de dias que a equipe levaria para construir todo o
projeto, efetuando a divisão da quantidade total de dias pela quantidade de
pessoas que a equipe possui.
2.3 Resultados
Para realizarmos as estimações através da técnica de Lorenz & Kidd, descrita na
seção 2.2, utilizamos o diagrama de classes, exibido na Figura 2. Após a análise do diagrama e das considerações da técnica utilizada, podemos obter as seguintes conclusões abaixo, descritos nos itens 2.3.1 e 2.3.2.
2.3.1 Passo a Passo
1. Número de classes-chave encontradas após a análise do diagrama de classes de domínio;
5 classes-chaves:
Cliente; Usuário; CorretoraSeguros; Negocio; Seguradora.
2. Interface selecionada (De acordo com o modelo de arquitetura do sistema);
GUI
3. Número de classes de suporte encontrado;
5 (item 1) x 2,5 (multiplicador do item 2) = 12,5 classes de suporte
4. Número total de classes;
5 (item 1) + 12,5 (item 3) = 17,5 classes
5. Quantidade de dias que uma pessoa gastaria para desenvolver uma única classe
(Valor retirado do intervalo sugerido por Lorenz & Kidd);
17,5 * 17 = 297, 5 Dias- pessoa (esforço)
6. Quantidade total de dias que uma pessoa gastaria para construir todo o sistema;
5 (item 5) * 17 (item 4) = 297 dias
7. Quantidade total de dias que a equipe gastaria para construir todo o sistema.
297 (item 6) / 4 (quantidade de integrantes) = 74,3 dias Dividido por 30 → 74,3 / 30 = 2,4 (2 meses, 14 dias, 2 horas 24min) – com sábado e domingo (sem parar). Dividido por 22 → 74,3 / 22 = 3 meses, 8 dias
Sendo assim, de acordo com a métrica de Lorenz & Kidd, o tempo necessário para a
construção do projeto deve ser de, aproximadamente, 2 meses, 14 dias, 2 horas 24min, sem
parar. Levando em consideração a quantidade de dias úteis no mês, o projeto se estenderá
por 3 meses e 8 dias.
2.3.2 Tabela Geral
Nessa seção será mostrada a Tabela 2, com uma visão geral descrita na seção 2.3.1.
Interface Multiplicador
Não gráfica 2
Baseada em texto 2,25
GUI 2,5 2,5 (multiplicador do GUI) * 5 (classes chaves) = 12,5 (classes de suporte); 5(classes chaves) + 12,5 (classes de suporte) = 17,5 (classes); 17,5 (classes) * 17 = 297 (dias), 5 Dias- pessoa (esforço) 297,5 / 4 (quantidade de pessoas na equipe) = 74,3 Dividido por 30 → 74,3 / 30 = 2,4 (2 meses, 14 dias, 2 horas 24min) – com sábado e domingo (sem parar) Dividido por 22 → 74,3 / 22 = 3 meses, 8 dias
GUI complexa 3,0
Tabela 2 – Tabela da execução de métricas descritas da seção 2.2.1
2.4 Informações para a codificação do projeto
As seguintes regras de codificação serão adotadas no desenvolvimento do sistema de gerenciamento de clientes:
Nomes de classes começando com letra maiúscula e com nome convincente.
Nomes de atributos vão começar com letra minúscula e quando for formado por mais de uma palavra, a primeira letra de cada palavra deverá ser maiúscula, possuindo também nomes convincentes.
2.5 Recursos do projeto
Nas seções abaixo serão listados os recursos utilizados na construção do projeto, que
são: humanos, de software e de hardware.
2.5.1 Recursos humanos
A metodologia adotada para o gerenciamento do projeto foi o SCRUM. Os Sprints das
Tabelas 3, 4, 5 e 6 definem a estrutura de organização e execução do conjunto de tarefas
classificados de acordo com uma disposição hierárquica das funcionalidades a serem
desenvolvidas e das datas disponíveis para a sua construção, listadas na Tabela 8. Além
disso, temos o ScrumMaster que é o elemento que faz a ligação entre o dono do produto ou
projeto e a equipe.
SPRINT 1
Período: 22/10/2014 a 12/11/2014 Duração: 22 dias
Funcionalidades: RF001 - Efetuar Login; RF002 - Manter Clientes; RF003 - Manter Seguradora.
ScrumMaster: Thauane Moura
Desenvolvedor 1: Thiago Dantas Desenvolvedor 2: Waldson Rodrigues Testador: Bruno Meneses
Tabela 3 - Sprint 1
SPRINT 2
Período: 13/11/2014 a 30/11/2014 Duração: 18 dias
Funcionalidades: RF004 - Manter negociações; RF005 - Manter oficinas;
ScrumMaster: Thiago Dantas
Desenvolvedor 1: Bruno Meneses Desenvolvedor 2: Thauane Moura Testador: Waldson Rodrigues
Tabela 4 - Sprint 2
SPRINT 3
Período: 01/12/2014 a 30/12/2015 Duração: 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
Período: 02/01/2015 a 03/02/2015 Duração: 31 dias
Funcionalidades: RF007 - Gerar estatísticas; RF008 - Gerar relatórios; RF009 - Efetuar Backup.
ScrumMaster: Bruno Meneses
Desenvolvedor 1: Waldson Rodrigues Desenvolvedor 2: Thauane Moura Testador: Thiago Dantas
Tabela 6 - Sprint 4
2.5.2 Recursos de software
O sistema irá contar com os recursos disponíveis na internet para desenvolvimento de software como:
Banco de dados Mysql - utilizado para armazenar as informações; Netbeans IDE - utilizado para desenvolver o algoritmo; StarUML - utilizado para modelagem de dados; Google Drive - utilizado para permitir o armazenamento dos documentos salvos
pela equipe de desenvolvimento.
2.5.3 Recursos de hardware
Para o desenvolvimento da aplicação foram usados pcs com a seguinte configuração:
Processador Intel Core™ i3 Memória 4GB HD 500GB Monitor LED 15,6" Conexão à internet - fornecida pela operadora Oi Internet.
Com o andamento do projeto as máquinas não apresentaram nenhum tipo de problema e mostraram ser bastante eficaz para o desenvolvimento da aplicação em questão.
3 ANÁLISE E GESTÃO DE RISCOS
Nesta seção serão analisados os riscos potenciais que foram prejudiciais para
o andamento do projeto. O objetivo desta análise é conhecer e minimizar, o máximo
possível, a probabilidade de sua ocorrência e o impacto causado por ela, caso venha a
acontecer.
3.1 Riscos do projeto
Segue abaixo tabela com os riscos identificados e sua respectiva classificação, que
visa determinar se a sua ocorrência é geral ou única do projeto:
Nº Risco Projeto Técnico Negócio Comum Especial
1 Volume de informações maior do que o projetado
X
2 Quantidade de mudanças projetadas nos requisitos para o produto. Antes e após a entrega.
X X
3 Baixa motivação dos usuários em inserir dados no sistema por completo
X
4 Pouca quantidade de software reutilizado
X
5 Rigidez no prazo de entrega X X
6 Restrições de interoperabilidade X
7 Necessidade de uma interface especializada
X X
8 Tamanho pequeno da equipe X X
9 Comprometimento da equipe durante o projeto
X X
10 A equipe não está disponível integralmente.
X X
11 Nível baixo de conhecimento por parte da equipe sobre a(s) tecnologia(s) usada(s)
X X
Tabela 7 - Riscos x Classificação
3.2 Tabela de riscos
Na Tabela 8 foi atribuída a cada um dos riscos uma probabilidade que determina
o grau da chance deste risco acontecer e um impacto após o efetivo acontecimento deste
evento.
Nº Risco Probabilidade Impacto
1 Volume de informações maior do que o projetado
60% Crítico
2 Quantidade de mudanças projetadas nos requisitos para o produto. Antes e após a entrega
50% Crítico
3 Pouca quantidade de software reutilizado 45% Crítico
4 Rigidez do prazo de entrega 40% Crítico
5 Baixa motivação dos usuários em inserir dados no sistema por completo
50% Moderado
6 Restrições de interoperabilidade 35% Moderado
7 Necessidade de uma interface especializada 30% Moderado
8 Comprometimento da equipe durante o projeto 25% Moderado
9 Nível baixo de conhecimento por parte da equipe sobre a(s) tecnologia(s) usada(s)
20% Moderado
10 Tamanho pequeno da equipe 25% Marginal
11 A equipe não está disponível integralmente. 20% Marginal
Tabela 8 - Análise Risco x Probabilidade x Impacto
3.3 Redução e Gestão do risco
Os quadros a seguir, de 1 a 11 apresentam estratégias para a redução e/ou gestão dos riscos identificados na seção 3.2:
Análise do Risco 1
1- Volume de informações maior do que o projetado
Probabilidade: 30% Impacto: Crítico
Descrição: O volume de informações trafegado pelo sistema pode ser maior que o projetado e causar lentidão no sistema.
Plano de Contingência: Alocar mais espaços no servidor para suportar o tráfego de dados.
Estratégia de redução: Acompanhar as estatísticas de utilização do sistema para evitar que os usuários fiquem com o sistema indisponível.
Responsável: Thiago Dantas Status: Em Andamento
Quadro 1 - Análise do risco 1
Análise do Risco 2
2- Quantidade de mudanças projetadas nos requisitos para o produto. Antes e após a entrega
Probabilidade: 50% Impacto: Crítico
Descrição: Os requisitos do projeto podem vir a ser alterados durante o projeto.
Plano de Contingência: Renegociar com o cliente os prazos anteriormente definidos.
Estratégia de redução: Negociar junto ao cliente os requisitos, a fim de definir o escopo do projeto.
Responsável: Thiago Dantas Status: Em Andamento
Quadro 2 - Análise do risco 2
Análise do Risco 3
3- Baixa motivação dos usuários em inserir dados no sistema por completo
Probabilidade: 50% Impacto: Moderado
Descrição: Os usuários podem não inserir dados no sistema por completo por achar que devem disponibilizar tempo para outras atividades da empresa. Plano de Contingência: Disponibilizar telas
alternativas com um número mínimo de informações para o usuário utilizar em casos de urgência.
Estratégia de redução: Simplificar ao máximo os formulários para agilizar a inserção de dados.
Responsável: Bruno Meneses Status: Em Andamento
Quadro 3 - Análise do risco 3
Análise do Risco 4
4- Pouca quantidade de software reutilizado
Probabilidade: 45% Impacto: Crítico
Descrição: A maior parte dos componentes utilizados no produto implementados sem utilizar componente reutilizados.
Plano de Contingência: Pesquisar por componentes reutilizáveis para utilizar no projeto.
Estratégia de redução: Planejar medidas que facilitem a reutilização de software, tais como utilizar, quando possível, padrões de projeto.
Responsável: Bruno Meneses Status: Em Andamento
Quadro 4 - Análise do risco 4
Análise do Risco 5
5- Rigidez do prazo de entrega
Probabilidade: 40% Impacto: Crítico
Descrição: O prazo para entregar todo o projeto é pequeno e inflexível.
Plano de Contingência: Remanejar a divisão das atividades entre os membros da equipe, visando colocar as atividades dentro do prazo de entrega, realizando-as por incrementos. Porém tentando sempre evitar sobrecarga de atividades.
Estratégia de redução: Realizar divisão das atividades do projeto entre a equipe de forma que a entrega permaneça dentro do prazo.
Responsável: Thauane Moura Status: Em Andamento
Quadro 5 - Análise do risco 5
Análise do Risco 6
6- Restrições de interoperabilidade
Probabilidade: 35% Impacto: Moderado
Descrição: O sistema não é projetado para se comunicar com outro sistema.
Plano de Contingência: Disponibilizar no sistema, a exportação de dados em extensões .pdf e .xls.
Estratégia de redução: Identificar quais os possíveis sistemas externos que o produto irá interagir.
Responsável: Thauane Moura Status: Em Andamento
Quadro 6 - Análise do risco 6
Análise do Risco 7
7- Necessidade de uma interface especializada
Probabilidade: 30% Impacto: Moderado
Descrição: Desenvolver uma interface específica ao setor de seguros para evitar que o usuário sinta dificuldades de adaptação ao sistema.
Plano de Contingência: Disponibilizar telas de esboço para usuários experientes com as regras de negócio, afim de obter feedback.
Estratégia de redução: Desenvolver uma interface levando em consideração as interfaces dos sistemas utilizados pelas Seguradoras nos quais os usuários já estão acostumados a utilizar.
Responsável: Waldson Rodrigues Status: Em Andamento
Quadro 7 - Análise do risco 7
Análise do Risco 8
8- Tamanho pequeno da equipe
Probabilidade: 25% Impacto: Marginal
Descrição: A quantidade de pessoas na equipe que está no projeto é pequena.
Plano de Contingência: Remanejar a divisão das atividades entre o membros da equipe, porém tentando sempre evitar sobrecarga de atividades.
Renegociar com o cliente, o tamanho do produto que será entregue.
Estratégia de redução: Realizar divisão das atividades do projeto entre a equipe de forma que a entrega permaneça dentro do prazo, como também, evitar sobrecarga de atividades.
Responsável: Waldson Rodrigues Status: Em Andamento
Quadro 8 - Análise do risco 8
Análise do Risco 9
9- Comprometimento da equipe durante o projeto
Probabilidade: 25% Impacto: Moderado
Descrição: A equipe, ou parte dela, não está comprometida com o projeto seguindo o que foi planejado.
Plano de Contingência: Realizar pequenas reuniões periódicas ao longo do projeto para revisar sobre o seu andamento, e discutir as dificuldades percebidas pela equipe.
Estratégia de redução: Distribuir as atividades de acordo com o grau de afinidade e experiência de cada membro da equipe para utilizar o máximo de conhecimento do membro em questão.
Responsável: Thiago Dantas Status: Em Andamento
Quadro 9 - Análise do risco 9
Análise do Risco 10
10 - Equipe não está disponível integralmente
Probabilidade: 20% Impacto: Marginal
Descrição: Devido a outras atividades extras ao projeto realizadas por cada integrante da equipe, o tempo disponibilizado para o projeto não é integral.
Plano de Contingência: Revisar as atividades realizadas por cada integrante para remanejar qualquer sobrecarga de trabalho sobre alguém. A divisão das tarefas entre os membros da equipe deve facilitar o processo.
Estratégia de redução: Realizar divisão das atividades do projeto entre a equipe, de forma que a entrega permaneça dentro do prazo.
Responsável: Thauane Moura Status: Em Andamento
Quadro 10 - Análise do risco 10
Análise do Risco 11
11 – Pouco conhecimento por parte da equipe sobre a(s) tecnologia(s) usada(s)
Probabilidade: 10% Impacto: Moderado
Descrição: A equipe, ou parte dela, não possui conhecimento aprofundado sobre a tecnologia que está sendo utilizada. Plano de Contingência: Realizar o
planejamento para que desenvolvimento de trechos de codificação mais complexos sejam feitos utilizando a técnica de programação em par, ao invés de serem desenvolvidas individualmente, aproveitando assim o máximo de conhecimento de ambos os programadores.
Estratégia de redução: Reunir e disponibilizar para a equipe, materiais de estudo que forneçam aprendizado sobre a(s) tecnologia(s) utilizada(s).
Realizar treinamento da equipe sobre a tecnologia que será utilizada.
Responsável: Waldson Rodrigues Status: Em Andamento
Quadro 11 - Análise do risco 11
3.4 Plano de Contingência
Atualmente, a maioria dos negócios necessita de Tecnologia da Informação e de
sistemas automatizados para auxiliar na gestão organizacional.Desta forma, para algumas empresas, ficar com o serviço indisponível por algumas horas pode significar perdas significativas gerando prejuízos financeiros.
É necessário avaliar o nível de dependência do negócio em relação a TI e a dependência
de serviços baseados na Internet. Para evitar futuros transtornos, toda e qualquer empresa deve desenvolver um plano de contingência que possa garantir a continuidade do negócio mesmo em situações como desastres naturais, roubos, fraudes ou até mesmo um ataque cibernético de grande proporção.
Pensando nisso, foi desenvolvido uma rotina de backup que além de efetuar
rotineiramente o armazenamento das informações, disponibiliza a exportação dos arquivos no formato .xls para garantir que mesmo em situações onde a Internet seja ausente o mínimo de informações possa ser acesso nem que seja via papel.
Além disso, foi garantido que o backup gerado não seja salvo no mesmo local do
escritório, para isso foi contratado um serviço de armazenamento na nuvem para garantir que as informações não sejam perdidas mesmo em situação de um desastre natural local.
4. PLANEJAMENTO TEMPORAL
Nesta seção são apresentadas as datas de execução das tarefas, bem como seus
responsáveis. No planejamento temporal definimos os marcos e planos de ações. A
mensuração do tempo para construção do projeto definido no item 2.3 foi utilizado para dividir
as fases do projeto. Essa parte é de extrema importância para a mensuração do andamento
do projeto, e do cumprimento das suas expectativas na esfera temporal. As fases tiveram a
divisão do tempo conforme a Tabela 9.
Fase Porcentagem Duração (Dias)
Planejamento 15% 16 dias
Análise e Projeto 20% 30 dias
Codificação 50% 40 dias
Testes 15% 15 dias
Tabela 9 - Fases do projeto
4.1 Conjunto de Tarefas do Projeto
O SCRUM define a divisão das funcionalidades em tarefas menores
executáveis pelos desenvolvedores. A Tabela 10 relaciona as tarefas com sua fase.
Fase Tarefas
Planejamento Definição de escopo; Funcionalidades e restrições; Documento de concepção.
Análise e Projeto Especificação de Requisitos; Especificação de Requisitos não funcionais; Especificação dos diagramas de análise; Documento de Analise; Definição da arquitetura de Projeto; Especificação dos diagramas de projeto; Documento de Projeto; Especificação e detalhamento de requisito.
Codificação Desenvolvimento da interface gráfica; Desenvolvimento da regra de negócio.
Teste Teste e validação de documentação; Teste e validação de software.
Tabela 10 - Distribuição das tarefas em fases
4.2 Diagrama de Gantt
O diagrama de Gantt é um instrumento que permite modelar graficamente a
bplanificação do avanço e planejamento das tarefas necessárias para a realização de um
projeto. As Figuras 3, 4, 5, 6 e 7 mostram as tarefas planejadas do projeto em forma de
diagrama de Gantt.
Figura 3 – Diagrama de Gantt
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 seção apresentamos todos os detalhes do projeto de Banco de Dados que tem como objetivo identificar as classes persistentes de design, projetar as estruturas do banco apropriadas e definir mecanismos e estratégias de armazenamento e recuperação.
5.1 Modelo de Dados – versão Inicial (Diagrama ER)
Figura 8 - Diagrama ER
6 ORGANIZAÇÃO DO PESSOAL
Nessa seção será descrita a organização da nossa equipe.
6.1 Estrutura da equipe
A cada Sprint, uma pessoa diferente assumiu o papel de Scrum Master e a
responsabilidade dos testes. Os testes foram executados pelo próprio desenvolvedor de
cada tarefa e também pela pessoa responsável por aquele Sprint.
A equipe é formada por quatro membros, com as seguintes distribuição de papéis:
Nome do membro Papel do membro
Thauane Moura Gestora de Projeto
Waldson Rodrigues Analista, Desenvolvedor e Testador
Thiago Emmanuel Gestor de Negócios
Bruno Meneses Arquiteto de Projeto Tabela 11 – Estrutura da equipe
Descrição das Responsabilidades:
Analista – Define uma visão geral dos requisitos, detalhar e documentar os requisitos.
Desenvolvedor – Projetar, desenvolver e construir o software.
Testador – Criar os casos de testes e executar os testes.
Arquiteto de Projeto – Analisar os requisitos, projetar e desenvolver o software.
Gerente de Projeto – Planeja as iterações, desenvolver planos do projeto e lista os
riscos.
Gestor de Negócios – Responsável em planejar e controlar a execução de projetos
Nossa equipe por ser pequena com 4 membros, logo uma pessoa assume mais de um papel.
6.2 Mecanismos de comunicação
Os mecanismos de comunicação utilizados pelo grupo foram:
● E-mail - Facilidade de comunicação e permite manter o registro das discussões;
● Reuniões Presenciais - Permitem a comunicação face-a-face e ajudam a verificar o
andamento do projeto;
● Redes Sociais – Permitindo a comunicação e dúvidas frequentes através do
Facebook e Whatsapp.
● Ferramentas Colaborativas - Vários documentos foram editados através do
Google Drive e Skype, permitindo a colaboração de todos.
O acompanhamento do projeto será realizado semanalmente através de reuniões presenciais, a depender da demanda semanal, ou à distância, utilizando ferramentas web de comunicação citadas acima.
6.3 Uso do Edu-blog como ferramenta de apoio
O blog trata de uma compilação das informações pesquisadas, torna-se uma
maneira de recuperá-las após o fim do projeto. Logo, foi adotado como uma ferramenta de
apoio necessário para o conhecimento adquirido durante o projeto designando e abordado na
disciplina de gerência de projetos, auxiliando na elaboração do modelo de projeto utilizando
as boas práticas de PMBOK + PMI + Certificações.
7 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SOFTWARE
Com a finalidade de garantir a qualidade de todas as fases do projeto, algumas preocupações foram tomadas: ● Documentação – Durante o projeto, a equipe se preocupou e tomou como compromisso realizar a atualização da documentação do sistema sempre que uma alteração em nível de projeto era realizada. Essa preocupação com a documentação do sistema foi alcançada pela rigidez que os testes demandavam afim de que o sistema estivesse totalmente de acordo com as especificações. ● Testes – A fim de atribuir qualidade final ao produto e minimizar as eventuais falhas que viesse a ocorrer, os testes foram realizados em 3 níveis, no nível unitário no qual era realizado pelo próprio programador, nível de integração e de sistema ambos realizados pelo Analista de Teste e testador. ● Reuniões quinzenais - Utilizando a ideia do SCRUM, foram feitas reuniões quinzenais de atualização do processo. Isso garantiu que as atividades mantivessem sob controle e ocasionais dificuldades fossem conhecidas o mais rápido possível para que possam ser controladas e contornadas. ● Controle do projeto de software - As atividades desenvolvidas durante todo o ciclo de desenvolvimento são acompanhadas constantemente e todos os requisitos são validados com os clientes. ● Entregas frequentes de partes funcionais do software - Isso garante que o usuário valide cada etapa do desenvolvimento, tornando uma possível mudança nas características do produto mais fáceis de serem gerenciadas e implementadas. Além disso, o usuário irá se manter atualizado sobre o andamento do processo e se sentirá parte dele. Essas iterações deverão acontecer sempre ao final de cada Sprint.
Recommended