1. O documento apresenta o plano de projeto de software para o aplicativo Outlay, que tem como objetivo fornecer ferramentas para gerenciamento de finanças pessoais. 2. São descritas as principais funcionalidades do aplicativo, incluindo diagramas de casos de uso e requisitos funcionais e não funcionais. 3. Estimativas iniciais indicam que o projeto pode ser concluído em aproximadamente 4 meses e 18 dias por uma equipe de 5 pessoas.

1. Universidade Federal de Sergipe
Centro de Ciências Exatas e Tecnologia/CCET
Departamento de Computação/DCOMP
Disciplina Gerência de Projetos
Prof.º Dr.º Rogério Patrício Chagas do Nascimento
Aplicativo OUTLAY
Plano de Projeto de Software
Ivan Gomes Ferreira Junior
João Paulo Souza Prado
Jocelino Alves Pereira Neto
Vicente José Santiago Costa Oliveira
São Cristóvão - SE
Fevereiro 2020
1

2. Universidade Federal de Sergipe
Centro de Ciências Exatas e Tecnologia/CCET
Departamento de Computação/DCOMP
Disciplina Gerências de Projetos
Prof.º Dr.º Rogério Patrício Chagas do Nascimento
Aplicativo OUTLAY
Plano de Projeto de Software
Plano de Projeto de Software
desenvolvido na disciplina de Gerência de
Projetos para obtenção de nota.
São Cristóvão - SE
Fevereiro 2020
2

3. Sumário
1. INTRODUÇÃO 4
1.1. Âmbito do Projeto 4
1.2. Funções principais do produto de software 4
1.3. Requisitos Comportamentais ou de Performance 11
1.4. Gestão e Restrições Técnicas 13
2. ESTIMAÇÕES DO PROJETO 14
2.1. Técnicas de Estimativas e Resultados 14
2.2. Recursos do projeto 16
3. ANÁLISE E GESTÃO DE RISCOS 17
3.1. Riscos do projeto 17
3.2. Redução e Gestão de Riscos 18
4. PLANEJAMENTO TEMPORAL 21
4.1. Conjunto de tarefas do projeto
4.2. Diagrama de Gantt 22
5. ORGANIZAÇÃO DA EQUIPE 23
5.1. Estrutura da equipe 23
5.2. Mecanismos de comunicação 24
5.3. Uso do Edu-Blog como ferramenta de apoio 24
5.4. Ferramentas de gestão do projeto 25
6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE
DO PRODUTO DE SOFTWARE 25
7. REFERÊNCIAS 26
8. APÊNDICE 1 - DIAGRAMA DE GANTT DO PROJETO DE SOFTWARE 26
3

4. 1. INTRODUÇÃO
O objetivo deste documento é descrever uma visão geral do plano de projeto de
software do aplicativo Outlay. Como o nome sugere, trata-se de um aplicativo cujo objetivo
é fornecer ao usuário ferramentas para o gerenciamento de suas finanças. Este plano
apresenta abordagens de gestão de projetos e da engenharia de software, como os
requisitos funcionais, não-funcionais e domínio, casos de uso e stakeholders.
1.1. Âmbito do Projeto
O aplicativo Outlay tem como público alvo pessoas que gostam ou querem fazer um
controle melhor das suas finanças. Para tanto, entre outras funcionalidades, a aplicação
disponibiliza ao usuário 'carteiras', nas quais se registram informações como saldo,
despesas e histórico de atividades, e acontecem operações relativas ao tratamento desses
dados.
1.2. Funções principais do produto de software
Nesta seção serão listados as principais funcionalidades do Projeto Outlay através
do diagrama de caso de uso, lista de requisitos funcionais e modelo conceitual.
Figura 1: Diagrama de caso de uso - categoria
Fonte: Próprios autores
4

5. Figura 2: Diagrama de caso de uso - Cadastro/Login
Fonte: Próprios autores
Figura 3: Diagrama de caso de uso - Lançamento Futuros
Fonte: Próprios autores
5

6. Figura 4: Diagrama de caso de uso - Gerar Relatório
Fonte: Próprios autores
Figura 5: Diagrama de caso de uso - CRUD Receita
Fonte: Próprios autores
6

7. Figura 6: Diagrama de caso de uso - CRUD Meta de economia
Fonte: Próprios autores
Figura 7: Diagrama de caso de uso - CRUD Carteira
Fonte: Próprios autores
7

8. Figura 8: Diagrama de caso de uso - Alterar Cadastro
Fonte: Próprios autores
Figura 9: Diagrama de caso de uso - CRUD Despesas
Fonte: Próprios autores
8

9. Figura 10: Modelo Conceitual
Fonte: Próprios autores
Com base no modelo conceitual
na tabela 1 é descrito as principais funcionalidades do software.
Tabela 1: Descrição dos requisitos funcionais
Requisito Descrição
RF01 O Visitante deve poder realizar o seu cadastro como usuário.
RF02 Usuário poderá atualizar o seu cadastro.
RF03 Usuário deve poder cadastrar suas dívidas.
RF04 O Usuário deve poder atualizar suas despesas.
9

10. RF05 O Usuário deve poder cadastrar sua receita(valor do dinheiro disponível).
RF06 O usuário deve poder atualizar seu saldo disponível.
RF07 Deve haver o campo “Lançamentos Futuros”, que registra rendas e
despesas futuras.
RF08 O app deve permitir a geração de relatórios, quando requerida pelo
usuário.
RF09 O app deve permitir a criação de categorias de receitas e despesas.
RF10 O app deve permitir verificar rendimentos de valor em poupança
RF11 O app deve permitir gerir gastos por categorias(tags).
RF12 O software deve permitir registro de contas a pagar, incluindo data de
pagamento/vencimento.
RF13 O app deve alertar sobre vencimentos de contas.
RF14 O usuário deve poder imprimir os relatórios.
RF15 O usuário deve manter sua(s) carteira(s).
RF16 O usuário pode favoritar transações recorrentes.
RF17 O app deve permitir a visualização da receita total (por mês/por ano).
RF18 O app deve permitir a visualização da despesa total (por mês/por ano).
RF19 O usuário pode gerenciar metas de economia.
1.3. Requisitos Comportamentais ou de Performance
Nesta seção estão descritos os requisitos não funcionais do sistema, sendo
relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade,
segurança, disponibilidade, manutenção e tecnologias envolvidas. Estes requisitos dizem
respeito a como as funcionalidades serão entregues ao usuário do software.
1.3.1. Usabilidade
Esse grupo de requisitos estão relacionados com a facilidade com os usuários
podem empregar ao fazer uso do software para realizar uma tarefa.
10

11. Tabela 2: Requisitos Não Funcionais de Usabilidade
Requisito Descrição
RNF01 O usuário deve conseguir encontrar um função do aplicativo em até 20
segundos.
RNF02 Possuir recurso de acessibilidade.
RNF03 Possuir mecanismos de ajuda com explicação passo a passo.
1.3.2. Confiabilidade
Refere-se à frequência de ocorrência de falhas e recuperabilidade em caso de falha.
Tabela 3: Requisitos Não Funcionais de Confiabilidade
Requisito Descrição
RNF01 Os dados presentes no dashboard devem estar sempre atualizados.
RNF02 O sistema deverá ter histórico de eventos que registra todas as
operações realizadas (logs).
RNF03 O aplicativo deve ter função que funciona meio como uma função
alarmante(o usuário informa a média de que pode gastar no período e
com base nisso o sistema retornará a situação em que ele se
encontra).
1.3.3. Performance
Referem-se ao desempenho do sistema e estão associados à eficiência, uso de
recursos e tempo de resposta da aplicação, como: transações processadas/segundo; tempo
de resposta do usuário/evento, entre outros.
Tabela 4: Requisitos Não Funcionais de Performance
Requisito Descrição
RNF01 Ter capacidade para mais de 5 acessos simultâneos.
RNF02 A emissão do relatório deverá ficar disponível para o usuário em até
10s.
11

12. 1.3.4. Suportabilidade
Este grupo de requisitos estão relacionados a facilidade de alterações no sistema
após a implantação, incluindo os aspectos de adaptabilidade, manutenibilidade e
internacionalização.
Tabela 5: Requisitos Não Funcionais de Suportabilidade
Requisito Descrição
RNF01 Testes de Unidade e de Aceitação deverão ser completamente
automatizados.
RNF02 Integração com o Internet bank.
RNF03 Possuir documentação e clareza no código.
1.3.5. Segurança
Esse grupo refere-se aos requisitos associados à integridade, privacidade e
autenticidade dos dados.
Tabela 6: Requisitos Não Funcionais de Segurança
Requisito Descrição
RNF01 O sistema deve prover controle de acesso para visualizar e manter
custos e carteira.
RNF02 O armazenamento dos dados do usuário deve ser seguro e restrito, só
poderão ser divulgados e consultados com a devida autorização.
RNF03 As informações divulgadas no dashboard para o público externo não
podem conter dados pessoais dos usuários, apenas dados gerais.
1.4. Gestão e Restrições Técnicas
A equipe de desenvolvimento do projeto será composta por alunos dos cursos de
graduação do Departamento de Computação da Universidade Federal de Sergipe, que
passarão por um processo de seleção podendo ter pouca ou média experiência com
desenvolvimento de software.
As restrições técnicas associadas ao desenvolvimento do projeto são:
12

13. 1. Desenvolvimento do aplicativo deverá usar a linguagem JavaScript com framework
ReactNative para o mobile, React.Js para plataforma web, e Node.js para o
back-end. Porém a utilização de Flutter pode ser negociada.
2. Utilização do banco de dados não relacional MongoDB.
Este projeto será desenvolvido baseado no modelo de desenvolvimento
iterativo-incremental, ou seja, deve ser entregue um componente funcional ao final de cada
etapa do processo de desenvolvimento para testes e validação com o cliente. O
gerenciamento da equipe será feito seguindo uma metodologia ágil, o Scrum, que foi
escolhido pela equipe.
2. ESTIMAÇÕES DO PROJETO
Utilizamos a métrica orientada a classe de Lorenz & Kidds para fazer a estimação do
projeto, pois é uma boa métrica quando as classes podem ser bem definidas. Essa
métrica indica pelos seus cálculos uma número definido para o esforço, tempo e
custo do projeto.
2.1. Técnicas de Estimativas e Resultados
Nessa subseção está o passo-a-passo da técnicas de estimativas e o seu
resultado no projeto.
2.1.1. Técnicas de Estimativas
Olhando o modelo conceitual(na Figura 10) podemos encontrar os
dados necessários para fazer a métrica de Lorenz & Kidds(1994).
● Encontrando o número de classes-chaves(são as que fazem parte do
domínio do problema).
● Com isso podemos calcular número das classes de suporte (não
ajudam a resolver o problema mas dão suporte as classes-chave)
necessárias de acordo com a Tabela 2, usa-se o cálculo
classes-chave*multiplicador = classes-suporte.
Interface Multiplicador
Não gráfica 2
Baseada em texto 2,25
GUI 2,5
GUI Complexa 3
Tabela 7: Multiplicador de classe suporte de Lorenz & Kidds(1994)
● Com o números de classes-chave e números de classes de suporte,
encontramos o números de classes totais que é a soma desses dois.
13

14. ● Então, o valor de classe totais são multiplicados pelo número médio
de unidades de trabalho(dias-pessoas) por classe. Lorenz &
Kidds(1994) sugerem entre 15-20 dias-pessoas por classe, a escolha
deve ser feita de acordo com a capacidade da equipe.
● Com isso se determina o esforço necessário para se realizar o
projeto.
● Então, se separa o esforço entre a equipe que irá trabalhar nele.
2.1.2. Resultados
Seguindo as etapas descritas acima temos os resultados:
● Temos ​9 classes-chaves: Login, Usuario, Carteira, Receita,
Despesa, Meta de Economia, Categoria de Entradas,
Relatórios, Lançamentos Futuros.
● Como utilizaremos GUI usaremos o multiplicador 2,5 de
acordo com a Tabela 2, nesse caso, temos 9 * 2,5 = 22,5
classes de suporte.
● Então, 22,5 + 9 = 31,5 como número total de classes.
● Nós decidimos escolher 19 como o número médio de unidades
de trabalho, pois queríamos dar um tempo a mais para os
desenvolvedores aprenderem a se adaptar ao projeto, logo
ficaria 31,5 * 19 = 532 dias-pessoas.
● Lembrando que o mês tem 22 dias úteis com 8 horas diárias,
para encontrar os dias corridos irei fazer esses cálculos: 532 /
22 = 24,18 meses corridos.
● Com uma equipe de 5 pessoas o tempo poderia ser dividido
para: 24,18 / 5 = 4,83 ou 4 meses e 18,26 dias no
total(aproximadamente 106,3 dias corridos)
Usando a distribuição dos dias de trabalho para as etapas do projeto
ficaria assim:
Modelo %Modelo %Projeto Cálculo Dias
Trabalho
Planejamento 2-3% 3% 106,3*3% =3,2
Requisitos
Análise-Desenho
40% 40% 106,3*40% =42,5
Geração de Código 20% 20% 106,3*20% =21,3
Testes 37-38% 37% 106,3*37% =39,3
Total =106,3
Tabela 8: Distribuição dos dias de trabalho entre as etapas
14

15. 2.2. Recursos do projeto
Os recursos utilizados neste projeto serão: humanos, hardware e software.
2.2.1. Recursos Humanos
O projeto será feito por 5 pessoas e será dividido da seguinte forma:
Cargo Responsável
Gerente de Projeto Vicente
Analista de Sistemas Ivan
Analista de Testes Jocelino
Programador João Paulo
Ivan
Vicente
Testador João Paulo
Jocelino
Vicente
Tabela 9: Separação das funções dos membros do projeto
2.2.2. Recursos de Software
● JavaScript, linguagem escolhida para escrever o projeto.
● React Native, como framework para o desenvolvimento do aplicativo
mobile.
● React.Js, como plataforma para construção em web.
● Node.js, para o desenvolvimento do back-end.
● Flutter, como um possível framework para o desenvolvimento.
● MongoDB, como escolha do banco de dados do projeto.
2.2.3. Recursos de Hardware
Serão utilizados os PCs pessoais de cada desenvolvedor para
realizar o projeto.
3. ANÁLISE E GESTÃO DE RISCOS
15

16. A gestão de riscos é uma atividade que propicia a atuação da organização de forma
preventiva, suprimindo prejuízos de natureza humana ou material. Com esta gestão é
possível selecionar opções para quando os riscos realmente ocorrerem, avaliando a
probabilidade de ocorrência e estimar o impacto destas incertezas.
3.1. Riscos do projeto
Na Tabela a 10, estão listados os riscos, sua probabilidade estimativa para
ocorrer e seus impacto no projeto com sua descrição. Todas estas
informações foram frutos de um ​brainstorm em sala de aula, auxiliados por
uma análise circular. Com isso, também foram definidos os pontos de corte.
Risco Categoria Impacto % Probabilidade Descrição
004 Tecnologia Catastrófico 30% Perda de informação no banco
de dados
006 Equipe Catastrófico 50% Não definição de tecnologias
008 Cliente Catastrófico 30% Problema na definição de
requisitos
002 Equipe Crítico 50% Prazos de entrega muito curto
003 Cliente Crítico 50% Cliente não participou das
validações do projeto
005 Tecnologia Crítico 50% Falha ao integrar com APIs de
câmbio
009 Tecnologia
s
Crítico 60% Não conexão com internet
banking
Ponto de corte
001 Equipe Marginal 75% Desistência de membro da
equipe
010 Tamanho Marginal 30% Evolução do projeto
011 Equipe Marginal 30% Rotatividade da equipe
012 Negócio Crítico 20% Usabilidade de usuário
013 Negócio Crítico 70% Expectativas não satisfeitas
014 Negócio Marginal 50% Conhecimento prévio escasso
dos usuários finais
16

17. Tabela 10: Riscos do projeto e pontos de corte
3.2. Redução e Gestão de Riscos
Risco: 002 Probabilidade: 50% Impacto: Crítico
Descrição: prazos de entrega muito curto para a rotina da equipe de
desenvolvimento.
Estratégia de Redução: negociar prazos adaptados para a equipe;
melhorar o planejamento para cada entrega; utilizar de reutilização de
funcionalidades.
Plano de contingência: realizar as atividades com maior prioridade;
aumentar a carga de trabalho.
Responsável: Gerente de Projetos.
Status: Concluído.
Tabela 11: Riscos do projeto 002
Risco: 003 Probabilidade: 50% Impacto: Crítico
Descrição: cliente não participou das validações do projeto
Estratégia de Redução: guardar e registrar cada reunião com os
stakeholders.
Plano de contingência: solicitar ao cliente alguém de confiança e com
conhecimentos sólidos sobre a aplicação, possivelmente um ​Product
Owner​.
Responsável: Analista de Sistemas.
Status: Concluído.
Tabela 12: Riscos do projeto 003
Risco: 004 Probabilidade: 30% Impacto: Catastrófico
Descrição: perda de informações no banco de dados
Estratégia de Redução: realizar redundâncias de dados em servidores,
além do uso de ​clusters com backups de todas as transações no banco,
para em caso de defeito em um servidor utilizar de outros já disponíveis.
Plano de contingência: realizar backups diários as informações, possuindo
17

18. redundâncias das informações que possuem mais solicitações.
Responsável: Analista de Testes.
Status: Concluído.
Tabela 13: Riscos do projeto 004
Risco: 005 Probabilidade: 50% Impacto: Crítico
Descrição: falha ao integrar com APIs de câmbio
Estratégia de Redução: pesquisa sobre APIs proprietárias que retornam as
informações de câmbio.
Plano de contingência: desenvolver um web crawler que captura
informações de sites proprietários sobre o câmbio.
Responsável: Analista de sistemas e Programadores.
Status: Em andamento.
Tabela 14: Riscos do projeto 005
Risco: 006 Probabilidade: 50% Impacto: Catastrófico
Descrição: não definição de tecnologias para a aplicação, ocasionando
problemas de desperdício de tempo com tecnologias não bem utilizadas.
Estratégia de Redução: A pesquisa e o teste de cada tecnologia para
desenvolvimento, além de listagem de prós e contras sobre cada
tecnologia em buscas em outros projetos consolidados.
Plano de contingência: reutilizar módulos disponíveis na Internet para
acelerar o processo de desenvolvimento.
Responsável: Analista de sistemas
Status: Concluído.
Tabela 15: Riscos do projeto 006
Risco: 008 Probabilidade: 30% Impacto: Catastrófico
Descrição: problema na definição de requisitos
Estratégia de Redução: retirar as dúvidas referentes aos requisitos em
reuniões frequentes com o cliente para que erros não ocorram e estudar
como funcionam os processos com aplicações financeiras.
Plano de contingência: contratar consultoria de finanças para auxiliar nos
processos financeiros que não estão corretos, além de trazer o cliente para
18

19. um acompanhamento mais próximo em cada entrega.
Responsável: Analista de Sistema.
Status: Em andamento.
Tabela 16: Riscos do projeto 008
Risco: 009 Probabilidade: 60% Impacto: Crítico
Descrição: não conexão com internet banking, impossibilitando integração
com informações de gastos e entradas com cartões
Estratégia de Redução: entrar em contato com bancos permitem o uso de
informações do internet banking para o gerenciamento de gastos utilizando
seus cartões e contas bancárias.
Plano de contingência: permitir o usuário de listar cada cartão e os gastos
e receitas manualmente, separados por categorias de banco.
Responsável: Analista de Testes.
Status: Em andamento.
Tabela 17: Riscos do projeto 009
Risco: 012 Probabilidade: 20% Impacto: Crítico
Descrição: Usabilidade de usuário pode prejudicar a utilização do
aplicativo
Estratégia de Redução: implementação de testes A/B com usuários que
estão qualificados na persona do projeto.
Plano de contingência: adoção de réplica da aparência de outras
aplicações, utilizando da aparência de recursos já conhecidos e bem
aceitos.
Responsável: Analista de testes e Testadores
Status: Em andamento.
Tabela 18: Riscos do projeto 012
Risco: 013 Probabilidade: 70% Impacto: Crítico
Descrição: expectativas não satisfeitas com o produto para o stakeholder
Estratégia de Redução: verificar a cada interação sobre quais as
expectativas do cliente e separar por prioridades de requisitos.
Plano de contingência: buscar redução dos problemas no período de
manutenção do software.
19

20. Responsável: Gerente de Projetos.
Status: Em andamento.
Tabela 19: Riscos do projeto 013
4. PLANEJAMENTO TEMPORAL
4.1. CONJUNTO DE TAREFAS DO PROJETO
O projeto ​Outlay se baseia em desenvolvimento baseado no modelo
iterativo-incremental, no qual as atividades são realizadas sequencialmente, e com
melhorias gradativas em atividades menores, ou atividades incrementais. Este projeto
pretende ser realizado em 115 dias (5 meses e 3 dias), utilizando o modelo de tempo a
seguir, tendo alguns espaços sem desenvolvimento
Tarefas Porcentagem (%) Tempo - dias de trabalho
Planejamento e Análise de
Requisitos
40% 42 dias
Codificação 20% 23.3 dias
Testes/Implementação 40% 42 dias
Total 100% 106.3 dias
Tabela 20: Tempo estimado para tarefas do projeto
A seguir temos um apanhado sobre as etapas do processo:
4.1.1. Planejamento e Análise de Requisitos
Esta etapa está dividida pelas etapas de: Abertura do Projeto,
Definição do escopo, Reuniões com os clientes, Levantamento de
requisitos, Refinamento dos requisitos, Análise dos requisitos, Criação
do plano de projeto, Análise e gestão de riscos, Projeto de arquitetura
e Ajustes no plano de projeto, onde cada uma destas etapas lida com
o planejamento e a análise e refinamento dos requisitos. Nesta etapa
o Analista de Sistemas e o Gerente de Projetos definem as atividades
e verifica os requisitos, para o Analista de Testes definir os testes e os
padrões do projeto.
20

21. 4.1.2. Codificação
Nesta etapa a equipe de programadores e o analista de sistemas
define a arquitetura e o ambiente em que a aplicação será executada.
Além disso, é realizada a cada ciclo de codificação as tarefas de
implementação de funcionalidades descritas nos requisitos funcionais
e não funcionais, além de seguir os casos de uso descritos.
4.1.3. Testes e Implementação
A equipe de testes, acompanhado pelo analista de testes realizam os
testes programados pelo analista no primeiro ciclo do projeto, na
etapa de planejamento e análise de requisitos. É importante frisar
que, no início de cada ciclo de codificação, testes unitários são
escritos para garantir a integridade das funcionalidades.
Após o período de testes, a equipe estará focada em integrar o
ambiente de desenvolvimento para o ambiente de produção, além de
passar o treinamento para os clientes.
4.2. DIAGRAMA DE GANTT
As atividades ao longo do processo são descritas no diagrama de gantt,
encontrado no apêndice 1 deste documento.
5. ORGANIZAÇÃO DA EQUIPE
5.1. ESTRUTURA DA EQUIPE
A tabela a seguir apresenta a composição da equipe e os papéis designados para
cada integrante, bem como uma breve descrição das atribuições de cada função.
Cargo Responsável Descrição
Gerente de projeto Vicente José Santiago
Costa Oliveira
É o responsável pela
elaboração do projeto,
planejamento e revisão.
Além de controlar a
execução dos processos a
fim de indicar o melhor
caminho para toda a equipe.
21

22. Analista de sistemas Ivan Gomes Ferreira Junior Esse profissional deve atuar
no levantamento dos
requisitos do sistema,
regras de negócio,
modelagem do banco,
dados e arquitetura do
projeto.
Analista de testes Jocelino Alves Pereira Neto Responsável por elaborar e
traçar os diversos tipos de
teste no projeto. Avaliar e
expor os resultados dos
testes para toda a equipe.
Desenvolvedor Ivan Gomes Ferreira Junior O desenvolvedor tem como
responsabilidade todo o
desenvolvimento e
codificação do sistema, bem
como manutenções e
correções providas dos
testes.
Testador
João Paulo Souza Prado
Jocelino Alves Pereira Neto
Vicente José Santiago
Costa Oliveira
Esse profissional é
responsável por codificar os
casos de testes elaborados
pelo analista, avaliar a
cobertura do código e
alertar a equipe
desenvolvimento sobre as
devidas correções.
Tabela 21: Estrutura da equipe
5.2 MECANISMOS DE COMUNICAÇÃO
A fim de manter uma comunicação ativa entre os integrantes da equipe e o
monitoramento das atividades e andamento do projeto, algumas ferramentas foram vitais,
como por exemplo, controle de versionamento, gerência de projetos, ferramentas case,
entre outras. No quadro abaixo serão listadas as ferramentas utilizadas junto a uma breve
descrição:
Ferramenta Descrição
WhatsApp Ferramenta mais utilizada para conversas
rápidas e informais entre todos os membro
da equipe. Pode ser utilizado via
dispositivos mobile ou navegadores web.
Google Drive A ferramenta permite a edição colaborativa
e simultânea de arquivos e elaboração de
22

23. documentos.
Tabela 22: Ferramentas de comunicação utilizadas
Vale citar que a equipe também contou com reuniões periódicas entre todos os
integrantes na própria Universidade Federal de Sergipe.
5.3 USO DO EDU-BLOG COMO FERRAMENTA DE APOIO
Alinhado com as ferramentas mencionadas acima, não podemos deixar de citar a
ferramenta “Edu-blog”, um blog criado pelo Prof.º Dr.º Rogério Patrício Chagas do
Nascimento, para a disciplina de Gerência de Projetos.
No blog <http://gp-ufs.blogspot.com> é possível acompanhar todos os conteúdos
abordados em sala de aula. Esses conteúdos contribuem para a formação de um projeto de
software de qualidade. Além disso, um dos objetivos da disciplina gerência de projetos é
fazer com que cada grupo de alunos torne-se responsável por abordar um tema em um
blog. De maneira recorrente é incentivado que os alunos realizem postagens referentes a
esses temas.
Essa metodologia foi muito interessante para nós alunos, pois nos fez buscar novos
conhecimentos e curiosidades a respeito dos temas para poder compartilhar com nossos
colegas, e da mesma forma incentivar e conhecer os blog dos outros colegas da disciplina e
de turmas anteriores da disciplina.
5.4 FERRAMENTAS DE GESTÃO DE PROJETO
Para auxiliar no gerenciamento do aplicativo OUTLAY, algumas ferramentas para
controle de reuniões e tarefas foram utilizadas, como mostra a tabela abaixo.
Ferramenta Descrição
Trello O trello é uma ferramenta que permite a
organização de tarefas. O que há para ser
feito, o que estão fazendo e o que já foi
concluído, seguindo a metodologia do
kanban.
Github O GitHub é uma ferramenta de controle de
versionamento de projetos, com ela é
possível verificar alterações e adição de
novas funcionalidades.
SmartSheet É uma ferramenta online capaz de gerar
diagramas e outros dashboards. No projeto
foi utilizado para gerar o diagrama de gantt.
Tabela 23: Ferramentas de gestão de projeto utilizadas
23

24. 6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E
CONTROLAR A QUALIDADE DO PRODUTO DE SOFTWARE
Para assegurar ao máximo a qualidade do nosso produto, foi necessário observar e
seguir alguns caminhos “seguros” da qualidade de software. Alguns desses caminhos são
mais óbvios. Como por exemplo, manter a documentação do produto sempre clara e
atualizada. Permitindo que outros membros da equipe consigam de maneira prática
entender as informações contidas no software.
Outra prática aplicada no nosso projeto foram as reuniões constantes entre os
membros da equipe, reuniões rápidas e objetivas. Onde cada membro colocava seus
pontos, sugestões e dúvidas em questão, formando assim um grande debate democrático.
Nessas reuniões a equipe se atualizava sobre os problemas encontrados e os avanços dos
colegas, além de dialogar frequentemente com os clientes, tornando o desenvolvimento
mais transparente e eficiente.
Uma etapa relevante para a validação da qualidade foram os testes. Os testes
devem ser feitos com atenção redobrada e sempre com um fim específico: encontrar erros.
Dessa forma, a nossa equipe trabalhou com testes ao longo de todo o desenvolvimento do
projeto a fim de garantir uma entrega consistente e livre de falhas. Utilizando o
desenvolvimento de maneira incremental, aplicando técnicas de prototipação foi possível
realizar a validação das fases junto aos clientes, garantindo satisfação e agilidade.
7. REFERÊNCIAS
LORENZ, M.; KIDD, J. ​Object-Oriented Software Metrics.​ Prentice Hall, 1994.
PRESSMAN, Roger; MAXIM, Bruce. ​Engenharia de Software: Uma abordagem
Profissional. ​8ª Edição. Editora McGraw Hill Brasil, 2016.
SOMMERVILLE, Ian. Engenharia de Software​. 8ª Edição. Editora Person
Education, 2007.
24

25. 8. APÊNDICE 1 - DIAGRAMA DE GANTT DO PROJETO DE
SOFTWARE
Figura 12: Diagrama de Gantt - Parte 01
25

26. Figura 13: Diagrama de Gantt - Parte 02
26

27. Figura 14: Diagrama de Gantt - Parte 03
27

28. Figura 15: Diagrama de Gantt - Parte 04
28

29. Figura 16: Diagrama de Gantt - Parte 05
Para acesso em melhor qualidade, o diagrama em PDF pode ser acessado em
<​https://drive.google.com/file/d/1pBoFCMoTfHOEUgXZbPB-Y61_Dp44nx-K/view?usp=shari
ng​> ou em PNG acessando em
<​https://drive.google.com/file/d/1_YWWkZKCC-JvpaZliaw2rjn786_WXYrm/view?usp=sharin
g​>.
29