plano de projeto de software do residents control

UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA

DEPARTAMENTO DE COMPUTAÇÃO Gerência de Projetos 2014.2

PLANO DO PROJETO DE SOFTWARE para produtos da Lacertae SW

GRUPO 4

Christiano Santana Leonardo Finato Manoela Oliveira Ricardo Souza

São Cristóvão – Sergipe 2014

Christiano Santana Leonardo Finato Manoela Oliveira Ricardo Souza

PLANO DO PROJETO DE SOFTWARE para produtos da Lacertae SW

Trabalho apresentado ao Prof. Dr. Rogério Patrício Chagas do Nascimento como parte avaliativa da disciplina Gerência de Projetos do Curso de Graduação em Sistemas de Informação da Universidade Federal de Sergipe – UFS.

São Cristóvão – Sergipe 2015

PLANO DO PROJETO DE SOFTWARE OO para produtos da Lacertae SW

1.0 INTRODUÇÃO Foi verificado no condomínio Sergipe Del Rey a necessidade de controlar a

entrada e saída de visitantes, assim como o ponto dos seus funcionários. E

então, manutenir um cadastro de moradores para auxiliar o porteiro na

identificação do bloco e apartamento que será visitado. O Residents Control foi

desenvolvido para suprir a necessidade do condomínio, tendo por objetivo

prover maior segurança, agilidade e controle.

1.1 Âmbito do Projeto

O Residents Control apresenta uma solução satisfatória para a deficiência

detectada no condomínio. O software foi desenvolvido objetivando controlar a

entrada e saída dos visitantes, manutenir todo o cadastro de moradores,

funcionários, usuários, visitantes e visitas. Além de prover o controle de ponto

dos funcionários e agregar uma interface em que o usuário possa interagir com

o sistema de acordo com suas necessidades e permissões.

Todos os funcionários realizarão a leitura biométrica e o sistema registrará a sua

entrada e sua saída, inclusive horário de almoço. Todos os moradores serão

registrados para controle quantitativo, todos os visitantes necessitam realizar o

cadastro biométrico e por conseguinte, auxiliando o porteiro na identificação do

bloco e apartamento, tanto para as visitas quanto para os moradores. O sistema

ainda oferece relatórios estatísticos e quantitativos referentes as visitas e

relatórios mensais de ponto dos funcionários.

1.2 Funções principais do produto de software O sistema desenvolvido é composto de diversas funcionalidades. Todas

elas com maior ou menor importância dentro do projeto, mas que juntas formam

o software necessário para as atividades do cliente

São elas:

Manter Funcionários;

Manter Moradores;

Manter Usuários;

Manter Condômino;

Manter Apartamento;

Manter Visitantes;

Manter Visitas;

Registrar o ponto do funcionário a partir da digital;

Gerar relatório;

Gerar gráfico.

Também especificadas no diagrama de caso de uso (do inglêsUse Case) como

pode ser visto na Figura 1. O diagrama de caso de uso é um diagrama que

documenta as funcionalidades do sistema, relacionadas aos "atores". Um ator é

um humano ou entidade máquina que interage com o sistema para executar um

significante trabalho.

Figura 1 Diagrama de Caso de Uso

O sistema deve disponibilizar as funções de acordo com os seguintes papéis:

Gestor:

Gerenciar Usuários;

Gerenciar Funcionários;

Visualizar e alterar ponto do funcionário;

Visualzar relatório;

Visualizar gráfico.

Funcionário:

Gerenciar Moradores;

Gerenciar Condômino;

Gerenciar Apartamento;

Gerenciar Visitantes;

Gerenciar Visitas;

Registrar seu ponto.

1.3 Requisitos comportamentais ou de performance

Dentre os requisitos comportamentais e de performance temos :

Usabiidade

Ser fácil de usar, possuindo uma linguagem de acordo com o

ambiente do negócio.

Compatibilidade

O sistema funcionará em ambiente Windows (Windows XP ou

superior na versão desktop). O sistema deverá gerar relatório em PDF.

O sistema deverá gerar gráfico em PDF.

Disponibilidade

O sistema deve estar disponível sete dias por semana, 24 horas

por dia.

Segurança

Todos os usuário do sistema deverão ter umlogin e uma senha de

acesso.

O sistema não deve permitir o acesso de pessoas não autorizadas.

O sistema só deve permitir alterações no ponto do funcionário para

o papel de gestor.

Performance

Em condições normais o sistema não deve demorar mais de dez

segundos para responder às requisições.

1.4 Gestão e Restrições Técnicas

As restrições técnicas que definem o escopo do projeto são:

O sistema de gerenciamento de banco de dados utilizado no projeto será

PostgreSQL.

O software será desenvolvido utilizando a linguagem Delphi. O bom funcionamento do software depende da infraestrutura de rede.

2.0 ESTIMAÇÕES DO PROJETO

Serão descritas nesta seção, as etapas utilizadas para calcular o tempo total de

execução deste projeto. Para isso, a métrica de Lorenz & Kidd será aplicada a

fim de estimar o esforço em termos de dias por pessoa.

2.1 Dados históricos utilizados para as estimações Não serão utilizados dados históricos na mensuração do projeto, uma vez que é

o primeiro projeto da equipe.

2.2 Técnicas de estimação e resultados

Como descrito anteriormente, neste projeto será utilizada a métrica de Lorenz &

Kidd para o cálculo do tempo de execução do projeto. Esta técnica leva em

consideração as classes que serão construídas no projeto.

2.2.1 Técnica de estimação

As seguinte etapas serão utilizadas para essa estimação:

1. Definir quais e quantas serão as classes chave do projeto podendo utlizar

para isso o diagrama de classes de domínio.

2. Para definir o número de classes de suporte, classificar qual interface

será utilizada no produto e de acordo com essa interface utilizar os

multiplicadores correspondentes, especificados na Tabela 1:

INTERFACE MULTIPLICADOR

Não gráfica 2

Baseada em texto 2,25

GUI 2,5

GUI complexa 3 Tabela 1 Valores Interface x Multiplicador

3. Multiplicar a quantidade de classeschave pelo multiplicador

correspondente para estimar o número de classes de suporte.

4. Calculase o total das classes do projeto (classes de domínio + classes de

suporte).

5. Multiplicar o total de classes (chave + suporte) pelo número médio de

unidades de trabalho (diaspessoa) por classe.

6. Calcular o tempo previsto para a realização do projeto.

2.3 Resultados

Com base no diagrama de classes de domínio, como pode ser visto naFigura 2,

fezse a estimativa. O diagrama de classes fornece uma representação da

estrutura e relações das classes que servem de modelo para objetos.

http://pt.wikipedia.org/wiki/Classe_(programa%C3%A7%C3%A3o)

http://pt.wikipedia.org/wiki/Objeto

Figura 2 Diagrama de Classe.

1. Quantidade de classeschave: 5. São elas: Visita, Visitantes, Condomino,

Funcionário e Ponto. Enquanto que as classes Apto, Morador e Usuário

são classes secundárias.

2. Tipo de interface das classes de suporte: GUI simples;

3. Valor multiplicador: 2,5;

4. Quantidade das classes de suporte: 5 (classeschave) x 2,5 (Valor

multiplicador) = 12,5 classes de suporte;

5. Total de classes: 5 (classeschave) + 12,5 (classes de suporte) = 17,5;

6. Número médio de unidades de trabalho: 15 diaspessoa;

7. Tempo previsto: 17,5 (total de classes) x 15 (diaspessoa) = 262,5 dias

por pessoa para a construção das classes;

8. Tendo em vista que a equipe é formada por 4 integrantes chegasse ao

total de: 262,5 (total previsto) / 4 (número de integrantes) = 65,625 dias ou

aproximadamente 66 dias.

Sendo assim, como um mês possui em média 22 dias úteis então o projeto se

estenderia por aproximadamente 3 meses.

2.4 Recursos do projeto

Nas seções abaixo serão explanados os recursos utilizados no projeto.

Subdivididos em Recursos Humanos, Recursos de Software e Recursos de

Hardware.

2.4.1 Recursos Humanos

Para subsidiar todo o desenvolvimento e projeto do nosso produto utilizamos

metodologias ágeis em virtude dos benefícios que estas proporcionam. Para o

gerenciamento do projeto utilizamos a metodologia ágil Scrum pois possibilita

uma iteração diária e uma boa colaboração da equipe. Como metodologia ágil

de desenvolvimento utilizamos o XP, portanto, reafirma a integração entre os

componentes da equipe com sua rotatividade de papéis e sua programação em

pares. Todo o planejamento adotado no Scrum está descrito na seção 4 que fala

sobre o planejamento temporal do desenvolvimento do projeto de software.

2.4.2 Recursos de software

No desenvolvimento do projeto foram utilizados softwares que subsidiaram o

processo:

Delphi XE7 Ferramenta utilizada na modelagem do Diagrama de Classe

e para a codificação do sistema.

SVN Ferramenta para controle de versão.

PostgreSQL Banco de dados utilizado.

Google Docs Software de armazenamento em nuvem que foi utilizado

para construir a documentação do projeto.

Redmine Ferramenta utilizada no gerenciamento das fases do projeto.

GanttProject Ferramenta utilizada na modelagem do diagrama de

Gantt.

2.4.2 Recursos de Hardware

Como utilizamos serviços de armazenamento em nuvem para promover um

processo centralizado e mais eficiente e o controle de versão apoiado pelo SVN,

então os computadores pessoais de cada integrante foram os únicos recursos

físicos utilizados na construção do projeto. Totalizando dessa forma 4

notebooks.

Primeiro Notebook

Disco rígido de 1 Tb;

6 gb de memória ram;

Processador Intel i5.

Segundo Notebook

SSD 256 GB;



Terceiro Notebook

Disco rígido de 500 GB;



Quarto Notebook

Disco rígido de 500 GB;



3.0 ANÁLISE E GESTÃO DE RISCOS

Entendese como análise e gerência de riscos o processo de planejar, organizar,

dirigir e controlar os recursos humanos e materiais dentro de um projeto, com o

intuito de minimizar os efeitos dos riscos ao mínimo possível. Nesta seção serão

apresentados os riscos que poderiam vir a prejudicar o andamento do projeto.

3.1 Riscos do projeto

Segue a Tabela 6 com todos os riscos identificados e sua respectiva

classificação para distinção entre riscos gerais e específicos. Os riscos

específicos são os riscos de projeto enquanto que os riscos gerais são todos os

outros, técnicos, negócio, comum e até mesmo especial.

Risco Projeto Técnico Negócio Comum Especial

1 Tecnologia desconhecida pela equipe

X

2 Pouco treinamento da equipe

X

3 O produto não cumprir o tamanho esperado

X X

4 Grande quantidade de usuários

X X

5 Acesso lento ao banco de dados

X

6 Sistema ficar fora do ar

X

7 Saída de um dos integrantes da equipe

X X

8 Mau uso do sistema X X

9 Documentação incompleta

X

10 Demora na identificação biométrica

X

11 Equipe insuficiente X X

12 Requisito mal especificado pelo cliente

X X

Tabela 6 Riscos do projeto

Notase que dos 12 riscos encontrados, aproximadamente 83% assumem a

classificação de projeto e/ou técnico, sendo assim foi necessário focar num

projeto bem especificado e em condições tecnológicas favoráveis ao

desenvolvimento do projeto.

3.2 Tabela de riscos

Segue a Tabela 7 com os riscos identificados, a sua probabilidade de ocorrência

e impacto esperado.

Risco Probabilidade (%) Impacto

O produto não cumprir o tamanho 65% Catastrófico

esperado

Sistema ficar fora do ar 40% Catastrófico

Pouco treinamento da equipe 50% Crítico

Tecnologia desconhecida pela equipe 45% Crítico

Saída de um dos integrantes da equipe 30% Crítico

Requisito mal especificado pelo cliente 45% Crítico

Grande quantidade de usuários 70% Marginal

Acesso lento ao banco de dados 60% Marginal

Mau uso do sistema 60% Marginal

Documentação incompleta 40% Marginal

Demora na identificação biométrica 60% Marginal

Equipe insuficiente 20% Marginal Tabela 7 Probabilidade e impacto dos ricos

3.3 Redução e Gestão do Risco

Levando em consideração os riscos identificados, os quadros numerados de 1 à

12 apresentam as estratégias para a redução e/ou gestão dos mesmos.

1 Tecnologia desconhecida pela equipe

Probabilidade: 45%

Impacto: crítico

Descrição: a tecnologia escolhida é desconhecida pelos desenvolvedores

Estratégia de redução: cursos presenciais ou online

Plano de Contingência: adotar a tecnologia C# pois entendese que os integrantes da equipe possuem conhecimento prévio.

Responsável: Christiano Santana

Status: em andamento Quadro 1 Análise do risco 1

2 Pouco treinamento da equipe

Probabilidade: 50%

Impacto: crítico

Descrição: devido à falta de experiência com projetos anteriores a equipe possui pouco treinamento

Estratégia de redução: oferecer treinamento aos desenvolvedores

Plano de Contingência: contratar alguém experiente para auxílio e acompanhamento do desenvolvimento em tempo real.

Responsável: Leonardo Finato


3 O produto não cumprir o tamanho esperado

Probabilidade: 65%

Impacto: catastrófico

Descrição: devido à complexidade do projeto pode acontecer de não conseguir concluir o esperado

Estratégia de redução: negociar entregas parciais e novas datas com o cliente

Plano de Contingência: negociar os prazos com o cliente revertendo os prazos definidos incorretamente

Responsável: Manoela Oliveira


4 Grande quantidade de usuários

Probabilidade: 70%

Impacto: marginal

Descrição: em alguns momentos, o acesso simultâneo pode sobrecarregar a infraestrutura adotada

Estratégia de redução: investir em alta disponibilidade do sistema

Plano de Contingência: adotar sistema de logoff automático com tempo definido

Responsável: Ricardo Souza


5 Acesso lento ao banco de dados

Probabilidade: 60%

Impacto: marginal

Descrição: com a grande quantidade de acessos o banco pode ficar sobrecarregado

Estratégia de redução: investir na alta disponibilidade do banco

Plano de Contingência: investir na replicação do banco de dados, fazendo com que, caso um banco sobrecarregue ainda tenhamos outro dispónivel oferecendo segurança e estabilidade.



6 Sistema ficar fora do ar

Probabilidade: 40%

Impacto: catastrófico

Descrição: ocorrer algum problema da rede ou algum problema com o software e o sistema ficar inacessível

Estratégia de redução: ter sempre alguém disponível para manutenção

Plano de Contingência: contratar suporte a distância



7 Saída de um dos integrantes da equipe

Probabilidade: 30%

Impacto: crítico

Descrição: há apenas 4 pessoas envolvidas no projeto e não há garantia que todos permaneçam até o final do projeto.

Estratégia de redução: dividir entre a parte da equipe restante as funcionalidades que faltam

Plano de Contingência: caso um integrante saia, devese identificar as prioridades do projeto, negociar um prazo maior com a promessa de entregar incrementos neste período



8 Mau uso do sistema

Probabilidade: 60%

Impacto: marginal

Descrição: os usuários do sistema podem não usar corretamente o sistema

Estratégia de redução: oferecer treinamento aos usuários

Plano de Contingência: oferecer acompanhamento presencial aos usuários para treinamento



9 Documentação incompleta

Probabilidade: 40%

Impacto: marginal

Descrição: pelo curto tempo para o desenvolvimento do projeto a documentação pode acabar sendo deixada com baixa prioridade.

Estratégia de redução: investir tempo em documentar o sistema

Plano de Contingência: negociar prazo com o cliente para entrega da documentação completa



10 Demora na identificação biométrica

Probabilidade: 60%

Impacto: marginal

Descrição: a digital pode ter dificuldade em ser colhida

Estratégia de redução: cadastrar todos os dedos para que haja outras opções de colheita

Plano de Contingência: permitir identificação através do nome e cpf



11 Equipe insuficiente

Probabilidade: 20%

Impacto: marginal

Descrição: o número de programadores no desenvolvimento do projeto deste software é pequeno

Estratégia de redução: investir na contratação de novos desenvolvedores

Plano de Contingência: fazer com que os programadores tenham dedicação exclusiva a esse projeto



12 Requisito mal especificado pelo cliente

Probabilidade: 45%

Impacto: crítico

Descrição: diferentes clientes com diferentes pensamentos solicitam os requisitos.

Estratégia de redução: padronizar o uso das mais diversas técnicas de elicitação no processo de descoberta dos requisitos

Plano de Contingência: analisar com todos os clientes os artefatos oriundos da elicitação dos requisitos e encontrar o ponto comum



4.0 PLANEJAMENTO TEMPORAL

Nesta seção iremos definir todas as atividades relativas à execução do projeto

com suas respectivas data de execução e prazo. Para auxiliar a visualização de

todas as tarefas, em relação ao aspecto temporal fezse o uso do gráfico de

Gantt.

4.1 Conjunto de Tarefas do Projeto

Segue a Tabela 8 onde é mostrada a relação entre as tarefas macro, os dias de

trabalho e a porcentagem a qual faz parte.

Dias de Trabalho Porcentagem Tarefas Macro

3 4,55% Planejamento

15 22,73% Requisitos, Análise e Desenho

40 60,60% Codificação

8 12,12% Testes Tabela 8 Relação entre tarefas, dias de trabalho e a porcentagem

A justificativa da escolha dessa divisão temporal ser diferente da sugerida pelo

Lacertae é o fato de utilizarmos Scrum e XP no nosso desenvolvimento pois

ambos tem um foco maior em desenvolvimento e entregas incrementais e um

foco menor em documentação.

Segue a divisão do cronograma que foi seguido, segundo a metodologia Scrum,

sendo composto por quatro Sprints que está respectivamentes explicitadas nas

Tabelas 2, 3, 4 e 5.

Na Tabela 2 temos a Sprint número 1 com duração de 14 dias e responsável

pela entrega das funcionalidades de Manter Morador e Manter Funcionário.

Tendo como Scrum Master, Manoela Oliveira.


pela entrega das funcionalidades de Manter Visitante, Manter Usuário e Manter

Condômino. Tendo como Scrum Master, Christiano Santana.


pela entrega das funcionalidades de Manter Apartamento, Manter Visita e

Registrar o ponto do funcionário a partir da digital. Tendo como Scrum Master,

Ricardo Souza.


pela entrega das funcionalidades de Gerar relatório e Gerar gráfico Tendo como

Scrum Master, Leonardo Finato.

Sprint 1 Período: 15/12/2014 à 28/12/2014

Funcionalidades Manter Morador Manter Funcionário

Scrum Master Manoela Oliveira

Desenvolvedor 1 Christiano Santana

Desenvolvedor 2 Ricardo Souza

Testador Leonardo Finato

Tabela 2 Sprint 1

Sprint 2 Período: 29/12/2014 à 11/01/2015

Funcionalidades Manter Visitante Manter Usuário

Manter Condômino

Scrum Master Christiano Santana

Desenvolvedor 1 Ricardo Souza

Desenvolvedor 2 Leonardo Finato

Testador Manoela Oliveira

Tabela 3 Sprint 2

Sprint 3 Período: 12/01/2015 à 25/01/2015

Funcionalidades Manter Apartamento Manter Visita Registrar o ponto do funcionário a partir da digital

Scrum Master Ricardo Souza

Desenvolvedor 1 Leonardo Finato

Desenvolvedor 2 Manoela Oliveira

Testador Christiano Santana Tabela 4 Sprint 3

Sprint 4 Período: 26/01/2015 à 08/02/2015

Funcionalidades Gerar relatório Gerar gráfico

Scrum Master Leonardo Finato

Desenvolvedor 1 Manoela Oliveira

Desenvolvedor 2 Christiano Santana

Testador Ricardo Souza Tabela 5 Sprint 4

4.2 Diagrama de Gantt

O Diagrama de Gantt permite visualizar de forma gráfica o avanço e

planejamento das diferentes etapas de um projeto. As Figuras 3, 4 e 5

descrevem tal diagrama. Ressalvase que as figuras 4 e 5 são imagens

ampliadas da Figura 3, objetivando maior entendimento.

Figura 3 Diagrama de Gantt

Na figura 3 podese observar o diagrama completo. Notase o período em que as atividades são realizadas, permitindo uma visualização simplificada de como o projeto foi desenvolvido.

Figura 4 Tarefas e seus os respectivos intervalos de tempo

Na figura 4 podese notar o planejamento temporal onde cada atividade está

relacionada a um período de realização.

Figura 5 Duração das tarefas

Na figura 5 notase o período de codificação subdividido nas quatro sprints de duração igual, a realização de testes durante todo o processo como pede a metodologia XP e o período para Planejamento e Requisitos, análise e desenho. Ver figura 3.

5.0 ORGANIZAÇÃO DO PESSOAL

Mesmo existindo o gestor da equipe, toda decisão da equipe é tomada em grupo

e compartilhada com todos os indivíduos.

5.1 Estrutura da equipe

O projeto foi desenvolvido por meio de um processo iterativo e incremental.

Dessa forma a cada Sprint uma pessoa diferente assumiu o papel de Scrum

master e a responsabilidade pela codificação e testes. Porém para questão de

organização e estruturação temos os seguintes papéis definidos:

Gestor de projetos: Manoela dos Reis Oliveira. O Gestor de projetos exerce a

função de planejar e controlar a execução dos projetos com o intuito de conduzir

melhor a equipe.

Desenvolvedores: Christiano Santana e Ricardo Souza. O Desenvolvedor

exerce a função de codificar ou prestar manutenção em rotinas de um sistema

especifico.

Testador: Leonardo Finato. O Testador exerce a função de verificação do

funcionamento do software, localizando e registrando as falhas e como elas

acontecem repassandoas para a equipe de desenvolvimento.

5.2 Mecanismos de comunicação

Mecanismos de comunicação utilizados por nossa equipe foram:

Email, devido a rápida comunicação, capacidade de armazenamento e

acesso ao histórico e também a presença de todos os componentes da

equipe;

Google Hangouts também foi uma ferramenta muito útil pela agilidade e

registro das conversas;

Whatsapp e Viber rápida comunicação e acesso fácil. Google drive mostrouse uma ferramenta colaborativa muito poderosa

aproximando os membros da equipe na elaboração de documentos e

papéis de trabalho.

5.3 Uso do Edublog como ferramenta de apoio

O uso do EduBlog proporciona um aprendizado descentralizado e uniforme,

todos os assuntos disponibilizados são expostos de forma clara e flexível. Dessa

forma, entendese que o aluno é incentivado a buscar novidades tecnológicas,

proporcionando maior conhecimento no que tange Tecnologia da Informação.

Contudo, esse processo de aprendizado objetiva “romper” os paradigmas do

ensino demasiado em sala de aula e abrange o conhecimento extraclasse.

6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A

QUALIDADE DO PRODUTO DE SW

Com a finalidade de garantir a qualidade de todas as fases do projeto, algumas

preocupações foram tomadas:

Testes: realizados durante todo o ciclo de vida do software. Desde o

levantamento dos requisitos até possíveis manutenções no produto

depois dele ter sido entregue, foram efetuados testes de caixa branca e

caixa preta. Também toda a documentação passou por testes.

Reuniões diárias: segundo a metodologia SCRUM são necessárias

pequenas reuniões diárias durante todo o processo para atualização do

que está sendo feito, como está sendo feito e quais as dificuldades

encontradas.

Controle de versão: para a confecção dos documentos foram utilizadas

ferramentas de controle de versão atribuindo marcos nos quais

representavam algum tipo de alteração, seja de melhoria ou correção.

Documentação: a documentação fornece um parâmetro para avaliar o

que foi feito na prática em comparação com o que foi descrito. É

composta por toda a descrição de como o desenvolvimento foi feito, os

diagramas que foram utilizados, planejamento temporal, recursos de

hardware, humanos e software, etc. Programação pareada: é uma das técnicas da metodologia XP que foi

utilizada no nosso desenvolvimento. Consiste em dois programadores

sentados lado a lado, sendo que somente um codifica, enquanto o outro

fica responsável em analisar o andamento da implementação. Assim o

código é desenvolvido e analisado simultaneamente, melhorando a

produtividade.