Modelo plano de projeto de sw oo gerenciamento de clientes final

UNIVERSIDADE FEDERAL DE SERGIPE

CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA

DEPARTAMENTO DE COMPUTAÇÃO

CURSO DE SISTEMAS DE INFORMAÇÃO - BACHARELADO

GERÊNCIA DE PROJETOS 2014/2

Bruno Meneses

Thauane Moura

Thiago Dantas

Waldson Rodrigues

PLANO DE PROJETO DE SOFTWARE PARA PRODUTOS DA

LACERTAE SW

São Cristóvão - Sergipe, Brasil

2014

UNIVERSIDADE FEDERAL DE SERGIPE

CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA

DEPARTAMENTO DE COMPUTAÇÃO

CURSO DE SISTEMAS DE INFORMAÇÃO - BACHARELADO

GERÊNCIA DE PROJETOS 2014/2

Bruno Meneses

Thauane Moura

Thiago Dantas

Waldson Rodrigues

PLANO DE PROJETO DE SOFTWARE PARA PRODUTOS DA

LACERTAE SW

Trabalho apresentado ao Prof. PhD

Rogério Patrício Chagas do

Nascimento como nota parcial para

disciplina Gerência de Projetos do

curso de graduação em Sistemas

de Informação – Bacharelado da

Universidade Federal de Sergipe.

São Cristóvão - Sergipe, Brasil

2014

Histórico de Alterações

Data Versão Descrição Autor(es)

05/11/2014 1.1 Criação do documento Bruno, Thauane, Thiago e Waldson

05/11/2014 1.2 Introdução Bruno, 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


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


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


Ator(es): Corretor

[RF003] – Manter Seguradoras


Ator(es): Funcionário

[RF004] – Manter Negociações



[RF005] – Manter Cotações



[RF006] – Agendar atendimento ao cliente


Ator(es): Corretor, Funcionário, Cliente

[RF007] – Gerar Relatórios



[RF008] – Gerar Estatísticas



[RF009] – Efetuar Backup



1.3.2.2 Prioridade dos Requisitos Não-Funcionais (RNF)

Nesta seção descrevemos os requisitos não funcionais da solução de nosso sistema neurológico.

Os Requisitos não-funcionais são os requisitos relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenibilidade e tecnologias envolvidas. Em geral, requisitos não-funcionais podem constituir restrições aos requisitos funcionais e não é preciso o cliente dizer sobre eles, pois eles são características mínimas de um software de qualidade.

1.3.2.2.1 Segurança

Nessa seção descrevemos os requisitos não-funcionais associados à integridade, privacidade e autenticidade dos dados da nossa aplicação.

[NFSG001] O sistema deve possuir um login para cada usuário.


Requisitos funcionais associados:

RF001 – O sistema deve permitir efetuar o login.

1.3.2.2.2 Implantação

Nessa seção descrevemos os requisitos não-funcionais associados à implantação da nossa solução.

[NFIM001] O sistema deve possuir conexão com o banco de dados MySQL.



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.



Todos os requisitos de RF001 a RF009.

2. ESTIMATIVAS DO PROJETO

Nesta seção serão descritas as estimativas que permitem calcular custo, esforço e

tempo gastos durante a construção do projeto. Essas informações são úteis para analisar e

distribuir as atividades de acordo com um cronograma preciso de tempo e recursos

necessários para cada uma delas.

2.1 Dados históricos utilizados para as estimações

Por se tratar de um projeto novo, que está sob a responsabilidade de uma equipe

graduanda em sistemas de informação, não existem dados históricos utilizados para as

estimações.

2.2 Técnicas de estimação e resultados

Nesta seção utilizamos a métrica de Lorenz & Kidd para calcular o esforço por pessoa necessário para a construção do projeto. Utilizamos o diagrama de classes de domínio, mostrado na Figura 2 abaixo, como fonte de informações.

De acordo com o diagrama de classes, na Figura 2, identificamos que o software possui 5 classes chaves. Utilizando interface gráfica, com fator multiplicador de 2,5, teremos 13 classes de suporte totalizando 18 classes.

Figura 2 - Diagrama de classes

2.2.1 Técnica de estimação

A métrica mencionada a métrica de Lorenz & Kidd, da seção 2.2, foi utilizada de

acordo com os seguintes passos:

1. Determinar as classes-chave do projeto, através da análise do diagrama de

classes de domínio (apresentado na Figura 2);

2. Determinar o tipo da interface do projeto, que deve ser classificada de acordo

com um dos itens da Tabela 1;

Interface Multiplicador

Interface não gráfica 2

Baseada em texto 2,25

GUI 2,5

GUI Complexa 3

Tabela 1 - Valores Interface x Multiplicador

3. Determinar o número de classes de suporte, efetuando o produto da quantidade de

classes-chave pelo multiplicador da interface escolhida anteriormente;

4. Determinar o total de classes do projeto, somando a quantidade de classes de

suporte com a quantidade de classes-chave;

5. Determinar a quantidade de dias que uma pessoa levaria para construir uma classe.

Quando não existem dados históricos a serem considerados, Lorenz

& Kidd sugerem de quinze a vinte dias;

6. Determinar a quantidade total de dias que uma pessoa levaria para construir todo o

projeto, efetuando o produto do total de classes do projeto pela quantidade de dias

escolhida anteriormente;

7. Determinar a quantidade total de dias que a equipe levaria para construir todo o

projeto, efetuando a divisão da quantidade total de dias pela quantidade de

pessoas que a equipe possui.

2.3 Resultados

Para realizarmos as estimações através da técnica de Lorenz & Kidd, descrita na

seção 2.2, utilizamos o diagrama de classes, exibido na Figura 2. Após a análise do diagrama e das considerações da técnica utilizada, podemos obter as seguintes conclusões abaixo, descritos nos itens 2.3.1 e 2.3.2.

2.3.1 Passo a Passo

1. Número de classes-chave encontradas após a análise do diagrama de classes de domínio;

5 classes-chaves:

Cliente; Usuário; CorretoraSeguros; Negocio; Seguradora.

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

GUI

3. Número de classes de suporte encontrado;

5 (item 1) x 2,5 (multiplicador do item 2) = 12,5 classes de suporte

4. Número total de classes;

5 (item 1) + 12,5 (item 3) = 17,5 classes

5. Quantidade de dias que uma pessoa gastaria para desenvolver uma única classe

(Valor retirado do intervalo sugerido por Lorenz & Kidd);

17,5 * 17 = 297, 5 Dias- pessoa (esforço)

6. Quantidade total de dias que uma pessoa gastaria para construir todo o sistema;

5 (item 5) * 17 (item 4) = 297 dias

7. Quantidade total de dias que a equipe gastaria para construir todo o sistema.

297 (item 6) / 4 (quantidade de integrantes) = 74,3 dias Dividido por 30 → 74,3 / 30 = 2,4 (2 meses, 14 dias, 2 horas 24min) – com sábado e domingo (sem parar). Dividido por 22 → 74,3 / 22 = 3 meses, 8 dias

Sendo assim, de acordo com a métrica de Lorenz & Kidd, o tempo necessário para a

construção do projeto deve ser de, aproximadamente, 2 meses, 14 dias, 2 horas 24min, sem

parar. Levando em consideração a quantidade de dias úteis no mês, o projeto se estenderá

por 3 meses e 8 dias.

2.3.2 Tabela Geral

Nessa seção será mostrada a Tabela 2, com uma visão geral descrita na seção 2.3.1.

Interface Multiplicador

Não gráfica 2

Baseada em texto 2,25

GUI 2,5 2,5 (multiplicador do GUI) * 5 (classes chaves) = 12,5 (classes de suporte); 5(classes chaves) + 12,5 (classes de suporte) = 17,5 (classes); 17,5 (classes) * 17 = 297 (dias), 5 Dias- pessoa (esforço) 297,5 / 4 (quantidade de pessoas na equipe) = 74,3 Dividido por 30 → 74,3 / 30 = 2,4 (2 meses, 14 dias, 2 horas 24min) – com sábado e domingo (sem parar) Dividido por 22 → 74,3 / 22 = 3 meses, 8 dias

GUI complexa 3,0

Tabela 2 – Tabela da execução de métricas descritas da seção 2.2.1

2.4 Informações para a codificação do projeto

As seguintes regras de codificação serão adotadas no desenvolvimento do sistema de gerenciamento de clientes:

Nomes de classes começando com letra maiúscula e com nome convincente.

Nomes de atributos vão começar com letra minúscula e quando for formado por mais de uma palavra, a primeira letra de cada palavra deverá ser maiúscula, possuindo também nomes convincentes.

2.5 Recursos do projeto

Nas seções abaixo serão listados os recursos utilizados na construção do projeto, que

são: humanos, de software e de hardware.

2.5.1 Recursos humanos

A metodologia adotada para o gerenciamento do projeto foi o SCRUM. Os Sprints das

Tabelas 3, 4, 5 e 6 definem a estrutura de organização e execução do conjunto de tarefas

classificados de acordo com uma disposição hierárquica das funcionalidades a serem

desenvolvidas e das datas disponíveis para a sua construção, listadas na Tabela 8. Além

disso, temos o ScrumMaster que é o elemento que faz a ligação entre o dono do produto ou

projeto e a equipe.

SPRINT 1

Período: 22/10/2014 a 12/11/2014 Duração: 22 dias

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

ScrumMaster: Thauane Moura

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

Tabela 3 - Sprint 1

SPRINT 2


Funcionalidades: RF004 - Manter negociações; RF005 - Manter oficinas;

ScrumMaster: Thiago Dantas

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

Tabela 4 - Sprint 2

SPRINT 3


Funcionalidades: RF006 - Agendar atendimento ao cliente.

ScrumMaster: Waldson Rodrigues

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

Tabela 5 - Sprint 3

SPRINT 4


Funcionalidades: RF007 - Gerar estatísticas; RF008 - Gerar relatórios; RF009 - Efetuar Backup.

ScrumMaster: Bruno Meneses

Desenvolvedor 1: Waldson Rodrigues Desenvolvedor 2: Thauane Moura Testador: Thiago Dantas

Tabela 6 - Sprint 4

2.5.2 Recursos de software

O sistema irá contar com os recursos disponíveis na internet para desenvolvimento de software como:

Banco de dados Mysql - utilizado para armazenar as informações; Netbeans IDE - utilizado para desenvolver o algoritmo; StarUML - utilizado para modelagem de dados; Google Drive - utilizado para permitir o armazenamento dos documentos salvos

pela equipe de desenvolvimento.

2.5.3 Recursos de hardware

Para o desenvolvimento da aplicação foram usados pcs com a seguinte configuração:

Processador Intel Core™ i3 Memória 4GB HD 500GB Monitor LED 15,6" Conexão à internet - fornecida pela operadora Oi Internet.

Com o andamento do projeto as máquinas não apresentaram nenhum tipo de problema e mostraram ser bastante eficaz para o desenvolvimento da aplicação em questão.

3 ANÁLISE E GESTÃO DE RISCOS

Nesta seção serão analisados os riscos potenciais que foram prejudiciais para

o andamento do projeto. O objetivo desta análise é conhecer e minimizar, o máximo

possível, a probabilidade de sua ocorrência e o impacto causado por ela, caso venha a

acontecer.

3.1 Riscos do projeto

Segue abaixo tabela com os riscos identificados e sua respectiva classificação, que

visa determinar se a sua ocorrência é geral ou única do projeto:

Nº Risco Projeto Técnico Negócio Comum Especial

1 Volume de informações maior do que o projetado

X

2 Quantidade de mudanças projetadas nos requisitos para o produto. Antes e após a entrega.

X X

3 Baixa motivação dos usuários em inserir dados no sistema por completo

X

4 Pouca quantidade de software reutilizado

X

5 Rigidez no prazo de entrega X X

6 Restrições de interoperabilidade X

7 Necessidade de uma interface especializada

X X

8 Tamanho pequeno da equipe X X

9 Comprometimento da equipe durante o projeto

X X

10 A equipe não está disponível integralmente.

X X

11 Nível baixo de conhecimento por parte da equipe sobre a(s) tecnologia(s) usada(s)

X X

Tabela 7 - Riscos x Classificação

3.2 Tabela de riscos

Na Tabela 8 foi atribuída a cada um dos riscos uma probabilidade que determina

o grau da chance deste risco acontecer e um impacto após o efetivo acontecimento deste

evento.

Nº Risco Probabilidade Impacto

1 Volume de informações maior do que o projetado

60% Crítico

2 Quantidade de mudanças projetadas nos requisitos para o produto. Antes e após a entrega

50% Crítico

3 Pouca quantidade de software reutilizado 45% Crítico

4 Rigidez do prazo de entrega 40% Crítico

5 Baixa motivação dos usuários em inserir dados no sistema por completo

50% Moderado

6 Restrições de interoperabilidade 35% Moderado

7 Necessidade de uma interface especializada 30% Moderado

8 Comprometimento da equipe durante o projeto 25% Moderado

9 Nível baixo de conhecimento por parte da equipe sobre a(s) tecnologia(s) usada(s)

20% Moderado

10 Tamanho pequeno da equipe 25% Marginal

11 A equipe não está disponível integralmente. 20% Marginal

Tabela 8 - Análise Risco x Probabilidade x Impacto

3.3 Redução e Gestão do risco

Os quadros a seguir, de 1 a 11 apresentam estratégias para a redução e/ou gestão dos riscos identificados na seção 3.2:

Análise do Risco 1

1- Volume de informações maior do que o projetado

Probabilidade: 30% Impacto: Crítico

Descrição: O volume de informações trafegado pelo sistema pode ser maior que o projetado e causar lentidão no sistema.

Plano de Contingência: Alocar mais espaços no servidor para suportar o tráfego de dados.

Estratégia de redução: Acompanhar as estatísticas de utilização do sistema para evitar que os usuários fiquem com o sistema indisponível.

Responsável: Thiago Dantas Status: Em Andamento

Quadro 1 - Análise do risco 1

Análise do Risco 2

2- Quantidade de mudanças projetadas nos requisitos para o produto. Antes e após a entrega


Descrição: Os requisitos do projeto podem vir a ser alterados durante o projeto.

Plano de Contingência: Renegociar com o cliente os prazos anteriormente definidos.

Estratégia de redução: Negociar junto ao cliente os requisitos, a fim de definir o escopo do projeto.



Análise do Risco 3

3- Baixa motivação dos usuários em inserir dados no sistema por completo

Probabilidade: 50% Impacto: Moderado

Descrição: Os usuários podem não inserir dados no sistema por completo por achar que devem disponibilizar tempo para outras atividades da empresa. Plano de Contingência: Disponibilizar telas

alternativas com um número mínimo de informações para o usuário utilizar em casos de urgência.

Estratégia de redução: Simplificar ao máximo os formulários para agilizar a inserção de dados.

Responsável: Bruno Meneses Status: Em Andamento


Análise do Risco 4

4- Pouca quantidade de software reutilizado


Descrição: A maior parte dos componentes utilizados no produto implementados sem utilizar componente reutilizados.

Plano de Contingência: Pesquisar por componentes reutilizáveis para utilizar no projeto.

Estratégia de redução: Planejar medidas que facilitem a reutilização de software, tais como utilizar, quando possível, padrões de projeto.

Responsável: Bruno Meneses Status: Em Andamento


Análise do Risco 5

5- Rigidez do prazo de entrega


Descrição: O prazo para entregar todo o projeto é pequeno e inflexível.

Plano de Contingência: Remanejar a divisão das atividades entre os membros da equipe, visando colocar as atividades dentro do prazo de entrega, realizando-as por incrementos. Porém tentando sempre evitar sobrecarga de atividades.

Estratégia de redução: Realizar divisão das atividades do projeto entre a equipe de forma que a entrega permaneça dentro do prazo.

Responsável: Thauane Moura Status: Em Andamento


Análise do Risco 6

6- Restrições de interoperabilidade


Descrição: O sistema não é projetado para se comunicar com outro sistema.

Plano de Contingência: Disponibilizar no sistema, a exportação de dados em extensões .pdf e .xls.

Estratégia de redução: Identificar quais os possíveis sistemas externos que o produto irá interagir.



Análise do Risco 7

7- Necessidade de uma interface especializada


Descrição: Desenvolver uma interface específica ao setor de seguros para evitar que o usuário sinta dificuldades de adaptação ao sistema.

Plano de Contingência: Disponibilizar telas de esboço para usuários experientes com as regras de negócio, afim de obter feedback.

Estratégia de redução: Desenvolver uma interface levando em consideração as interfaces dos sistemas utilizados pelas Seguradoras nos quais os usuários já estão acostumados a utilizar.

Responsável: Waldson Rodrigues Status: Em Andamento


Análise do Risco 8

8- Tamanho pequeno da equipe

Probabilidade: 25% Impacto: Marginal

Descrição: A quantidade de pessoas na equipe que está no projeto é pequena.

Plano de Contingência: Remanejar a divisão das atividades entre o membros da equipe, porém tentando sempre evitar sobrecarga de atividades.

Renegociar com o cliente, o tamanho do produto que será entregue.

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.



Análise do Risco 9

9- Comprometimento da equipe durante o projeto


Descrição: A equipe, ou parte dela, não está comprometida com o projeto seguindo o que foi planejado.

Plano de Contingência: Realizar pequenas reuniões periódicas ao longo do projeto para revisar sobre o seu andamento, e discutir as dificuldades percebidas pela equipe.

Estratégia de redução: Distribuir as atividades de acordo com o grau de afinidade e experiência de cada membro da equipe para utilizar o máximo de conhecimento do membro em questão.



Análise do Risco 10

10 - Equipe não está disponível integralmente

Probabilidade: 20% Impacto: Marginal

Descrição: Devido a outras atividades extras ao projeto realizadas por cada integrante da equipe, o tempo disponibilizado para o projeto não é integral.

Plano de Contingência: Revisar as atividades realizadas por cada integrante para remanejar qualquer sobrecarga de trabalho sobre alguém. A divisão das tarefas entre os membros da equipe deve facilitar o processo.

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.



Análise do Risco 11

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


Descrição: A equipe, ou parte dela, não possui conhecimento aprofundado sobre a tecnologia que está sendo utilizada. Plano de Contingência: Realizar o

planejamento para que desenvolvimento de trechos de codificação mais complexos sejam feitos utilizando a técnica de programação em par, ao invés de serem desenvolvidas individualmente, aproveitando assim o máximo de conhecimento de ambos os programadores.

Estratégia de redução: Reunir e disponibilizar para a equipe, materiais de estudo que forneçam aprendizado sobre a(s) tecnologia(s) utilizada(s).

Realizar treinamento da equipe sobre a tecnologia que será utilizada.



3.4 Plano de Contingência

Atualmente, a maioria dos negócios necessita de Tecnologia da Informação e de

sistemas automatizados para auxiliar na gestão organizacional.Desta forma, para algumas empresas, ficar com o serviço indisponível por algumas horas pode significar perdas significativas gerando prejuízos financeiros.

É necessário avaliar o nível de dependência do negócio em relação a TI e a dependência

de serviços baseados na Internet. Para evitar futuros transtornos, toda e qualquer empresa deve desenvolver um plano de contingência que possa garantir a continuidade do negócio mesmo em situações como desastres naturais, roubos, fraudes ou até mesmo um ataque cibernético de grande proporção.

Pensando nisso, foi desenvolvido uma rotina de backup que além de efetuar

rotineiramente o armazenamento das informações, disponibiliza a exportação dos arquivos no formato .xls para garantir que mesmo em situações onde a Internet seja ausente o mínimo de informações possa ser acesso nem que seja via papel.

Além disso, foi garantido que o backup gerado não seja salvo no mesmo local do

escritório, para isso foi contratado um serviço de armazenamento na nuvem para garantir que as informações não sejam perdidas mesmo em situação de um desastre natural local.

4. PLANEJAMENTO TEMPORAL

Nesta seção são apresentadas as datas de execução das tarefas, bem como seus

responsáveis. No planejamento temporal definimos os marcos e planos de ações. A

mensuração do tempo para construção do projeto definido no item 2.3 foi utilizado para dividir

as fases do projeto. Essa parte é de extrema importância para a mensuração do andamento

do projeto, e do cumprimento das suas expectativas na esfera temporal. As fases tiveram a

divisão do tempo conforme a Tabela 9.

Fase Porcentagem Duração (Dias)

Planejamento 15% 16 dias

Análise e Projeto 20% 30 dias

Codificação 50% 40 dias

Testes 15% 15 dias

Tabela 9 - Fases do projeto

4.1 Conjunto de Tarefas do Projeto

O SCRUM define a divisão das funcionalidades em tarefas menores

executáveis pelos desenvolvedores. A Tabela 10 relaciona as tarefas com sua fase.

Fase Tarefas

Planejamento Definição de escopo; Funcionalidades e restrições; Documento de concepção.

Análise e Projeto Especificação de Requisitos; Especificação de Requisitos não funcionais; Especificação dos diagramas de análise; Documento de Analise; Definição da arquitetura de Projeto; Especificação dos diagramas de projeto; Documento de Projeto; Especificação e detalhamento de requisito.

Codificação Desenvolvimento da interface gráfica; Desenvolvimento da regra de negócio.

Teste Teste e validação de documentação; Teste e validação de software.

Tabela 10 - Distribuição das tarefas em fases

4.2 Diagrama de Gantt

O diagrama de Gantt é um instrumento que permite modelar graficamente a

bplanificação do avanço e planejamento das tarefas necessárias para a realização de um

projeto. As Figuras 3, 4, 5, 6 e 7 mostram as tarefas planejadas do projeto em forma de

diagrama de Gantt.

Figura 3 – Diagrama de Gantt

5 PROJETO DO BANCO DE DADOS

Nessa seção apresentamos todos os detalhes do projeto de Banco de Dados que tem como objetivo identificar as classes persistentes de design, projetar as estruturas do banco apropriadas e definir mecanismos e estratégias de armazenamento e recuperação.

5.1 Modelo de Dados – versão Inicial (Diagrama ER)

Figura 8 - Diagrama ER

6 ORGANIZAÇÃO DO PESSOAL

Nessa seção será descrita a organização da nossa equipe.

6.1 Estrutura da equipe

A cada Sprint, uma pessoa diferente assumiu o papel de Scrum Master e a

responsabilidade dos testes. Os testes foram executados pelo próprio desenvolvedor de

cada tarefa e também pela pessoa responsável por aquele Sprint.

A equipe é formada por quatro membros, com as seguintes distribuição de papéis:

Nome do membro Papel do membro

Thauane Moura Gestora de Projeto

Waldson Rodrigues Analista, Desenvolvedor e Testador

Thiago Emmanuel Gestor de Negócios

Bruno Meneses Arquiteto de Projeto Tabela 11 – Estrutura da equipe

Descrição das Responsabilidades:

Analista – Define uma visão geral dos requisitos, detalhar e documentar os requisitos.

Desenvolvedor – Projetar, desenvolver e construir o software.

Testador – Criar os casos de testes e executar os testes.

Arquiteto de Projeto – Analisar os requisitos, projetar e desenvolver o software.

Gerente de Projeto – Planeja as iterações, desenvolver planos do projeto e lista os

riscos.

Gestor de Negócios – Responsável em planejar e controlar a execução de projetos

Nossa equipe por ser pequena com 4 membros, logo uma pessoa assume mais de um papel.

6.2 Mecanismos de comunicação

Os mecanismos de comunicação utilizados pelo grupo foram:

● E-mail - Facilidade de comunicação e permite manter o registro das discussões;

● Reuniões Presenciais - Permitem a comunicação face-a-face e ajudam a verificar o

andamento do projeto;

● Redes Sociais – Permitindo a comunicação e dúvidas frequentes através do

Facebook e Whatsapp.

● Ferramentas Colaborativas - Vários documentos foram editados através do

Google Drive e Skype, permitindo a colaboração de todos.

O acompanhamento do projeto será realizado semanalmente através de reuniões presenciais, a depender da demanda semanal, ou à distância, utilizando ferramentas web de comunicação citadas acima.

6.3 Uso do Edu-blog como ferramenta de apoio

O blog trata de uma compilação das informações pesquisadas, torna-se uma

maneira de recuperá-las após o fim do projeto. Logo, foi adotado como uma ferramenta de

apoio necessário para o conhecimento adquirido durante o projeto designando e abordado na

disciplina de gerência de projetos, auxiliando na elaboração do modelo de projeto utilizando

as boas práticas de PMBOK + PMI + Certificações.

7 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SOFTWARE

Com a finalidade de garantir a qualidade de todas as fases do projeto, algumas preocupações foram tomadas: ● Documentação – Durante o projeto, a equipe se preocupou e tomou como compromisso realizar a atualização da documentação do sistema sempre que uma alteração em nível de projeto era realizada. Essa preocupação com a documentação do sistema foi alcançada pela rigidez que os testes demandavam afim de que o sistema estivesse totalmente de acordo com as especificações. ● Testes – A fim de atribuir qualidade final ao produto e minimizar as eventuais falhas que viesse a ocorrer, os testes foram realizados em 3 níveis, no nível unitário no qual era realizado pelo próprio programador, nível de integração e de sistema ambos realizados pelo Analista de Teste e testador. ● Reuniões quinzenais - Utilizando a ideia do SCRUM, foram feitas reuniões quinzenais de atualização do processo. Isso garantiu que as atividades mantivessem sob controle e ocasionais dificuldades fossem conhecidas o mais rápido possível para que possam ser controladas e contornadas. ● Controle do projeto de software - As atividades desenvolvidas durante todo o ciclo de desenvolvimento são acompanhadas constantemente e todos os requisitos são validados com os clientes. ● Entregas frequentes de partes funcionais do software - Isso garante que o usuário valide cada etapa do desenvolvimento, tornando uma possível mudança nas características do produto mais fáceis de serem gerenciadas e implementadas. Além disso, o usuário irá se manter atualizado sobre o andamento do processo e se sentirá parte dele. Essas iterações deverão acontecer sempre ao final de cada Sprint.

Modelo plano de projeto de sw oo gerenciamento de clientes final

Technology

Transcript of Modelo plano de projeto de sw oo gerenciamento de clientes final