Gerenciamento de condomínio

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





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

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ês Use 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 um login 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 na Figura 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.

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.

Gerenciamento de condomínio

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (18)

Semelhante a Gerenciamento de condomínio

Semelhante a Gerenciamento de condomínio (20)

Gerenciamento de condomínio