O documento apresenta o plano de projeto de software para o sistema Residents Control, desenvolvido para o condomínio Sergipe Del Rey. O sistema tem como objetivo controlar a entrada e saída de visitantes e funcionários, além de manter cadastros de moradores, visitantes e visitas. O projeto foi estimado em aproximadamente 3 meses para uma equipe de 4 pessoas, utilizando a metodologia Scrum e ferramentas como Delphi e SVN.

1. 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

2. 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

3. 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.

4. 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.

5.
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.

6. 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

7. ● 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:

8. 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 classes­chave pelo multiplicador
correspondente para estimar o número de classes de suporte.
4. Calcula­se 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 (dias­pessoa) 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​,
fez­se a estimativa. O diagrama de classes fornece uma r​epresentação da
estrutura e relações d​as ​classes​ que servem de modelo para ​objetos​.

9.
Figura 2 ­ Diagrama de Classe.
1. Quantidade de classes­chave: 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 (classes­chave) x 2,5 (Valor
multiplicador) = 12,5 classes de suporte;
5. Total de classes: 5 (classes­chave) + 12,5 (classes de suporte) = 17,5;
6. Número médio de unidades de trabalho: 15 dias­pessoa;
7. Tempo previsto: 17,5 (total de classes) x 15 (dias­pessoa) = 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.

10. 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.

11. 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;
○ 8 gb de memória ram;
○ Processador Intel i7.
● Terceiro Notebook
○ Disco rígido de 500 GB;
○ 8 gb de memória ram;
○ Processador Intel i7.

12. ● Quarto Notebook
○ Disco rígido de 500 GB;
○ 6 gb de memória ram;
○ Processador Intel i3.
3.0 ANÁLISE E GESTÃO DE RISCOS
Entende­se 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

13. 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
Nota­se 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

14. 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 entende­se que os
integrantes da equipe possuem conhecimento prévio.
Responsável​: Christiano Santana

15. 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
Status​: em andamento
Quadro 2 ­ Análise do risco 2
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
Status​: em andamento
Quadro 3 ­ Análise do risco 3

16.
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
Status​: em andamento
Quadro 4 ­ Análise do risco 4
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.
Responsável​: Christiano Santana
Status​: em andamento
Quadro 5 ­ Análise do risco 5
6 ­ Sistema ficar fora do ar

17. 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
Responsável​: Leonardo Finato
Status​: em andamento
Quadro 6 ­ Análise do risco 6
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, deve­se identificar as
prioridades do projeto, negociar um prazo maior com a promessa de entregar
incrementos neste período
Responsável​: Manoela Oliveira
Status​: em andamento
Quadro 7 ­ Análise do risco 7
8 ­ Mau uso do sistema
Probabilidade​: 60%
Impacto​: marginal

18. 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
Responsável​: Ricardo Souza
Status​: em andamento
Quadro 8 ­ Análise do risco 8
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
Responsável​: Christiano Santana
Status​: em andamento
Quadro 9 ­ Análise do risco 9
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

19. Responsável​: Leonardo Finato
Status​: em andamento
Quadro 10 ­ Análise do risco 10
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
Responsável​: Manoela Oliveira
Status​: em andamento
Quadro 11 ­ Análise do risco 11
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
Responsável​: Ricardo Souza

20. Status​: em andamento
Quadro 12 ­ Análise do risco 12
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 fez­se 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.

21. 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.
Na ​Tabela 3 ​temos a ​Sprint número 2 com duração de 14 dias e responsável
pela entrega das funcionalidades de Manter Visitante, Manter Usuário e Manter
Condômino. Tendo como Scrum Master, Christiano Santana.
Na ​Tabela 4 ​temos a ​Sprint número 3 com duração de 14 dias e responsável
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.
Na ​Tabela 5 ​temos a ​Sprint número 4 com duração de 14 dias e responsável
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

22. 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

23. 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. Ressalva­se que as figuras 4 e 5 são imagens
ampliadas da Figura 3, objetivando maior entendimento.

24.
Figura 3 ­ Diagrama de Gantt

25. Na ​figura 3 ​pode­se observar o diagrama completo. Nota­se 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 ​pode­se notar o planejamento temporal onde cada atividade está
relacionada a um período de realização.

26.
Figura 5 ­ Duração das tarefas
Na ​figura 5 ​nota­se 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:

27. 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 repassando­as para a equipe de desenvolvimento.
5.2 Mecanismos de comunicação
Mecanismos de comunicação utilizados por nossa equipe foram:
● E­mail​, 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 mostrou­se uma ferramenta colaborativa muito poderosa
aproximando os membros da equipe na elaboração de documentos e
papéis de trabalho.
5.3 Uso do Edu­blog como ferramenta de apoio
O uso do Edu­Blog proporciona um aprendizado descentralizado e uniforme,
todos os assuntos disponibilizados são expostos de forma clara e flexível. Dessa
forma, entende­se que o aluno é incentivado a buscar novidades tecnológicas,

28. 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 extra­classe.
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

29. código é desenvolvido e analisado simultaneamente, melhorando a
produtividade.