Este documento apresenta o plano de projeto de um software de gestão para o Berçário Girassol. Ele descreve as principais funcionalidades, requisitos, estimativas de tempo e esforço, análise de riscos, planejamento e organização da equipe. O objetivo é melhorar o gerenciamento de alunos, responsáveis, turmas e funcionários da instituição de forma digital.

1. UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Sistema de Gestão do Berçário Girassol
Plano de Projeto de Software
Anderson Costa Moreira Santana
Pedro Sturaro dos Reis
Rodrigo Fonseca Nascimento
Tawanna Hakkinen Oliveira Leite
Prof.º Dr. Rogério Patrício Chagas do Nascimento
SÃO CRISTÓVÃO-SERGIPE
NOVEMBRO DE 2019

2. UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Sistema de Gestão do Berçário Girassol
Plano de Projeto de Software do Sistema de Gestão
do Berçário Girassol desenvolvido pelos alunos
Anderson Costa M. Santana, Pedro Sturaro dos
Reis​, ​Rodrigo Fonseca Nascimento ​e ​Tawanna
Hakkinen Oliveira Leite, apresentado à disciplina
Gerência de Projetos para obtenção de nota parcial
sob a orientação do Profº Dr. Rogério Patrício
Chagas do Nascimento para composição de nota.
SÃO CRISTÓVÃO-SERGIPE
NOVEMBRO DE 2019

3. SUMÁRIO
INTRODUÇÃO 4
Âmbito do projeto 4
Funções principais 4
Requisitos comportamentais ou de performance 6
1.4. Gestão e Restrições técnicas 14
ESTIMAÇÕES DO PROJETO 14
Dados históricos utilizados para as estimações 14
Técnicas de estimação e resultados 14
Técnicas de estimação 15
Resultados 16
ANÁLISE E GESTÃO DE RISCOS 17
3.1. Riscos do projeto 18
3.2. Avaliação Global dos Riscos 19
3.3. Tabela de riscos 20
3.4. Plano de Redução e Gestão do Risco 20
PLANEJAMENTO TEMPORAL 24
4.1. Conjunto de tarefas do projeto 24
4.2. Diagrama de Gantt 25
ORGANIZAÇÃO DO PESSOAL 27
5.1. Estrutura da equipe 27
5.2. Mecanismos de comunicação 27
5.3. Uso do Edu-blog como ferramenta de apoio 28
PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO
PRODUTO DE SOFTWARE 29
REFERÊNCIAS BIBLIOGRÁFICAS 30

4. 1. INTRODUÇÃO
O presente documento visa apresentar o plano de projeto de um software
que tem por objetivo realizar o gerenciamento dos alunos e seus responsáveis do
Berçário Girassol.
1.1. Âmbito do projeto
Este projeto busca melhorar as atividades de controle dos alunos e seus
responsáveis do Berçário Girassol. Esse berçário possui pouco tempo de atuação
no mercado e pouco mais de 100 alunos por ano letivo. Devido a esses fatores, o
gerenciamento interno da instituição e de pessoas atendidas são feitos usando
papel. Essa utilização de meios analógicos causa dificuldades de organização,
busca e armazenamento das informações.
Por isso, está sendo proposto a construção de um software que facilite todo o
processo de gerenciamento e garanta a segurança dos dados.
1.2. Funções principais
As principais funcionalidades do software foram representadas no diagrama
de casos de uso na Figura 1, o diagrama demonstra os atores envolvidos, suas
funcionalidades e seus relacionamentos.
4

5. Figura 1: Diagrama de Caso de Uso
O Quadro 1 traz uma descrição de cada ator identificado e representado no
diagrama de caso de uso. O objetivo é demonstrar o papel de cada um no contexto
do projeto.
Quadro 1 - ​Descrição dos Atores e suas Respectivas Funções
Atores Descrição
Funcionário
Esse ator representa o(s) funcionário (s) que terá (terão) acesso ao
sistema para cadastrar, lista ou pesquisar alunos.
Administrador
Esse ator representa o (os) administrador (es) do sistemas que
podem fazer as mesmas funções do (os) funcionários e, além disso
poderá (poderão) manipular turmas e funcionário (s) no sistema.
5

6. O Quadro 2 mostram os Requisitos Funcionais para o desenvolvimento do
Sistema de Gestão da Creche Girassol com uma breve descrição de cada um e seu
código.
Quadro 2 - ​Descrição dos requisitos funcionais
Requisito Descrição
[RF001] O sistema deve permitir que os administradores realizem login no sistema.
[RF002] O funcionario pode cadastrar aluno.
[RF003] O sistema deve permitir a visualização de aluno.
[RF004] O administrador pode excluir aluno.
[RF005] O administrador pode alterar dados do aluno.
[RF006] O administrador pode cadastrar turma.
[RF007] O sistema deve permitir a visualização da turma.
[RF008] O administrador pode matricular aluno em uma turma.
[RF009] O administrador pode excluir turma.
[RF010] O administrador pode alterar dados da turma.
[RF011] O funcionário pode cadastrar responsável.
[RF012] O administrador pode excluir responsável.
[RF013] O sistema deve permitir a visualização de responsável.
[RF014] O administrador pode alterar dados do responsável.
[RF015] O administrador pode cadastrar funcionário.
[RF016] O administrador pode excluir funcionário.
[RF017] O sistema deve permitir a visualização de funcionário.
[RF018] O administrador pode alterar dados do funcionário.
[RF019] O administrador pode alocar funcionário a uma turma.
6

7. 1.3. Requisitos comportamentais ou de performance
Nesta seção são descritos os requisitos não funcionais do software que
descrevem características de qualidade do software. Estas características estão
ligadas a usabilidade do software.
Quadro 3 - ​Descrição dos Requisitos Não Funcionais
Requisito Descrição
[RNF001] O sistema deve ser desktop e funcionar para os Sistemas Operacionais Windows 7 ou superior.
[RNF002]
O sistema deve possuir usabilidade uma interface que promova facilidade em manuseio onde um
usuário sem intimidade com computador possa utilizar, bem como aprender sem necessidade de
auxílio técnico.
[RNF003]
O sistema tem que ser capaz de ser reparado e expandido estando em execução nas máquinas
dos usuários, ou seja, manter a manutenibilidade.
[RNF004]
O sistema deve utilizar o banco de dados PostgreSQL e manter os dados dos alunos,
responsáveis, turmas e clientes.
[RNF005] O sistema deve possuir dois níveis de acesso por meio do login​.
[RNF006] O sistema deve garantir que o aluno esteja matriculado em apenas uma turma.
[RNF007]
Deve-se garantir que possua o mínimo de falhas possíveis afim de se manter a confiabilidade da
aplicação garantindo a segurança das transações.
Descrição dos Casos de Uso Críticos
UC01 – Cadastrar Aluno
Objetivo: Cadastrar aluno para que possa ser matriculado.
Requisitos: Apresentação de documentos do aluno.
Atores (Primário e Secundário): Funcionário (primário) e aluno (secundário).
Prioridade: Crítico
7

8. Pré-condições: Identificação do aluno não constar no sistema. Responsável precisa
estar cadastrado no sistema.
Frequência de Uso:
Criticidade:
Fluxo Principal
1. O funcionário seleciona a opção Cadastrar Aluno.
2. O sistema exibe uma tela para Pesquisar dados do responsável.
3. O funcionário seleciona o responsável pelo aluno.
4. O sistema exibe uma tela para preenchimento de identificação do aluno.
5. O funcionário fornece a identificação do aluno.
6. O sistema verifica os dados preenchidos.
7. O sistema exibe uma tela para preenchimento de dados do aluno.
8. O funcionário preenche os dados solicitados e seleciona a opção Cadastrar.
9. O sistema verifica os dados preenchidos.
10. O sistema salva os dados do aluno.
Fluxo Alternativo
2.a: Responsável não encontrado.
1- O sistema exibe mensagem que o responsável não foi encontrado.
2- Retorna ao passo 2.
4.a: O sistema verifica que já existe um aluno com a identificação apresentada.
1- O sistema informa que já existe um aluno com a mesma identificação.
8

9. 2- Retorna ao passo 3.
9.a: Campos obrigatórios não preenchidos.
1- O sistema informa quais os campos obrigatórios não apresentam o preenchimento dos dados.
2- Retorna ao passo 6.
9.b: Campos obrigatórios preenchidos incorretamente:
1- O sistema informa quais os campos obrigatórios apresentam erros no preenchimento.
2- Retorna ao passo 6.
Regras de Negócio: Além dos dados do aluno é necessário fornecer dados do responsável.
UC02 – Criar Turma
Objetivo: Permite ao administrador criar uma nova turma.
Requisitos: Administrador precisa estar autenticado no sistema.
Atores (Primário e Secundário): Administrador (primário).
Prioridade: Crítico
Pré-condições: Nenhuma
Frequência de Uso:
Criticidade:
Fluxo Principal
1. O funcionário seleciona a opção Criar Turma.
2. O sistema exibe uma tela para preenchimento dos dados da turma.
3. O administrador insere os dados da turma e seleciona a opção Criar Turma.
9

10. 4. O sistema verifica os dados preenchidos.
5. O sistema salva os dados da turma.
Fluxo Alternativo
4.a: Campos obrigatórios não preenchidos.
1- O sistema informa quais os campos obrigatórios não apresentam o preenchimento dos dados.
2- Retorna ao passo 3.
4.b: Campos obrigatórios preenchidos incorretamente:
1- O sistema informa quais os campos obrigatórios apresentam erros no preenchimento.
2- Retorna ao passo 3.
Regras de Negócio:
UC03 – Matricular Aluno
Objetivo: Permite matricular o aluno em uma turma.
Requisitos: Entrar no perfil do aluno.
Atores (Primário e Secundário): Funcionário (primário) e Aluno (secundário).
Prioridade: Crítico
Pré-condições: O aluno precisa estar cadastrado no sistema.
O aluno não pode estar matriculado em uma turma.
Frequência de Uso:
Criticidade:
Fluxo Principal
10

11. 1. O funcionário entra no perfil do aluno e seleciona a opção Matricular Aluno.
2. O sistema exibe uma tela com as turmas disponíveis.
3. O funcionário seleciona uma turma e clica na opção salvar.
4. O sistema matrícula o aluno na turma selecionada.
Fluxo Alternativo
Regras de Negócio: As turmas têm um limite de alunos.
UC04 - Cadastrar Responsável
Objetivo: Cadastro de responsável no sistema.
Requisitos: Apresentação de documentos do aluno.
Atores (Primário e Secundário): Funcionário (primário) e responsável (secundário).
Prioridade: Crítico
Pré-condições: Identificação do responsável não constar no sistema.
Frequência de Uso:
Criticidade:
Fluxo Principal
1. O funcionário seleciona a opção Cadastrar Responsável.
2. O sistema exibe uma tela para preenchimento de identificação do responsável.
3. O administrador fornece a identificação do responsável.
11

12. 4. O sistema verifica os dados preenchidos.
5. O sistema exibe uma tela para preenchimento de dados do responsável.
6. O funcionário preenche os dados solicitados e seleciona a opção cadastrar.
7. O sistema verifica os dados preenchidos.
8. O sistema salva os dados do responsável.
Fluxo Alternativo
4.a: O sistema verifica que já existe um responsável com a identificação apresentada.
1- O sistema informa que já existe um responsável com a mesma identificação.
2- Retorna ao passo 3.
7.a: Campos obrigatórios não preenchidos.
1- O sistema informa quais os campos obrigatórios não apresentam o preenchimento dos dados.
2- Retorna ao passo 6.
7.b: Campos obrigatórios preenchidos incorretamente:
1- O sistema informa quais os campos obrigatórios apresentam erros no preenchimento.
2- Retorna ao passo 6.
Regras de Negócio:
UC05 - Cadastrar Funcionário
Objetivo: Cadastro de funcionário no sistema.
Requisitos: Administrador autenticado no sistema.
Atores (Primário e Secundário): Administrador (primário) e funcionário (secundário).
12

13. Prioridade: Crítico
Pré-condições: Identificação do funcionário não constar no sistema.
Frequência de Uso:
Criticidade:
Fluxo Principal
1. O administrador seleciona a opção Cadastrar Funcionário
2. O sistema exibe uma tela para preenchimento de identificação do funcionário.
3. O administrador fornece a identificação do funcionário.
4. O sistema verifica os dados preenchidos.
5. O sistema exibe uma tela para preenchimento de dados do funcionário.
6. O administrador preenche os dados solicitados e seleciona a opção Cadastrar.
7. O sistema verifica os dados preenchidos.
8. O sistema salva os dados do funcionário.
Fluxo Alternativo
4.a: O sistema verifica que já existe um funcionário com a identificação apresentada.
1- O sistema informa que já existe um funcionário com a mesma identificação.
2- Retorna ao passo 3.
7.a: Campos obrigatórios não preenchidos.
1- O sistema informa quais os campos obrigatórios não apresentam o preenchimento dos dados.
2- Retorna ao passo 6.
13

14. 7.b: Campos obrigatórios preenchidos incorretamente:
1- O sistema informa quais os campos obrigatórios apresentam erros no preenchimento.
2- Retorna ao passo 6.
Regras de Negócio:
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 (DCOMP) da UFS que
possuem pouca ou média experiência com desenvolvimento de um projeto de
software.
As restrições técnicas associadas ao desenvolvimento do projeto são:
1. Utilização de recursos ​open source ​e gratuitos.
2. Deverá ser desenvolvido em linguagem C#.
3. Usar IDE Visual Studio para desenvolvimento do código.
4. Utilização do banco de dados Postgresql.
5. Usar Git para controle de versão e armazenamento do código.
6. Listar atividades desenvolvidas usando Trello.
O desenvolvimento seguirá o modelo iterativo-incremental, utilizando a
metodologia ágil Scrum. Cada ​sprint terá duas semanas de duração, ao final da qual
haverá sido finalizada uma nova versão funcional do sistema que poderá ser
validada pelo cliente.
2. ESTIMAÇÕES DO PROJETO
Esta seção fornece as estimações do esforço e tempo demandado para a
produção do Sistema de Gestão da Creche Girassol.
14

15. 2.1. Dados históricos utilizados para as estimações
Este projeto é o primeiro desenvolvido pela equipe, portanto não há dados
anteriores que possam ser utilizados para a estimação deste projeto.
2.2. Técnicas de estimação e resultados
As estimativas têm grande importância na elaboração de projetos de
software. À medida que os projetos se tornam maiores e mais complexos é
necessário que as equipes conheçam e determinem prazos de entrega realistas.
Além disso, os executivos necessitam de estimativas de custos precisas que os
auxiliem na definição do orçamento anual e na análise da viabilidade do projeto.
Mas, de acordo com Pressman (2011, p. 609), "as estimativas de custo e
esforço de software nunca serão uma ciência exata". Isso porque, o custo final do
software e o esforço necessário para o seu desenvolvimento podem ser afetados
por variáveis como fatores humanos, técnicos, ambientais e políticos.
Apesar disso, usando uma série de técnicas de estimação, é possível fazer
com que as estimativas de projeto de software tenham um risco aceitável.
Uma dessas técnicas é a técnica de estimação para projetos orientados a
objetos criado por Lorenz e Kidd. Essa técnica é usada para suplementar os
métodos que normalmente são utilizados na estimativa de custo de software
(Pressman, 2011, p. 622).
Esta técnica foi usada neste plano de projeto para definir a estimação do
esforço necessário para o seu desenvolvimento.
2.2.1. Técnicas de estimação
Lorenz & Kidd (1994) sugerem que sejam realizadas as seguintes etapas
para a definição das estimativas de esforço do projeto:
1. Determinar a quantidade de classes-chave;
2. Classificar o tipo de interface do produto usando a Tabela 1 e desenvolver
um multiplicador para classes de suporte;
15

16. 3. Multiplicar o número de classes-chave pelo multiplicador para obter uma
estimativa do número de classes de apoio;
4. Multiplicar o número total de classes pelo número médio de unidades de
trabalho por classes. Lorenz & Kidd sugerem 15 a 20 pessoas-dia por
classe;
5. Determinar a quantidade de esforço estimada;
6. Calcular o tempo previsto para a elaboração do projeto.
O número total de classes é definido por:
Total de classes = classes-chave + classes de suporte
Tabela 1 - ​Multiplicadores da Métrica Lorenz & Kidd
Interface Multiplicador
Não Gráfica 2,00
Baseada em Teste 2.25
GUI 2,50
GUI Complexa 3,00
A Tabela 1 é formada por duas colunas Interface e Multiplicador. A coluna
Interface apresenta os vários tipos de interface que um software pode ter e a
coluna Multiplicador apresenta o valor do multiplicador associado a cada uma
dessas interfaces.
2.2.2. Resultados
Utilizando o Diagrama de Classes de Domínio, mostrado na Figura 2,
aplicamos a técnica de Lorenz & Kidd(1994) explicada na subseção anterior.
16

17. Figura 2 -​ Diagrama de Classe do Sistema de Gestão da Creche Girassol
17

18. Cumprida as etapas proposta por Lorenz & Kidd(1994), identificamos 4
Classes Chaves do Diagrama de Domínio da Figura 2. São elas:
1. Aluno
2. Adulto
3. Funcionário
4. Usuário
Com base nisso, chegamos ao seguinte cálculo:
1. Como nosso sistema é baseado em GUI, utilizamos o multiplicador 2,5.
Conforme mostrado na Tabela 1.
2. Depois, calculamos o total de classes de suporte. O total de classes de
suporte é calculado multiplicando a quantidade de classes-chave pelo
multiplicador 2,5. Assim temos:
Total de classes de suporte = classes-chave * multiplicador
Total de classes de suporte = 4 * 2,5 = 10
3. Após encontrarmos o valor total de classes de suporte, calculamos o total
de classes para o sistema. O total de classes para o sistema é calculado
somando a quantidade de classes chave com o total de classes de
suporte. Assim temos:
Total de classes do sistema = classes-chave + total classes de suporte
Total de classes do sistema = 4 + 10 = 14
4. Usando o valor total de classes do sistema, calculamos a quantidade de
esforço. A Quantidade de esforço é calculada multiplicando o total de
classes do sistema pelo o número de dias-pessoas por classes que foi
estimado. Esse número foi escolhido baseado na sugestão de Lorenz &
Kidd, conforme visto na subseção 2.2.1. O número escolhido foi 20
dias-pessoa. Assim temos:
Quantidade de esforço = Total de classes * Unidades de Trabalho
18

19. Quantidade de esforço = 14 * 20 = 280
5. E por último, utilizando o valor da quantidade de esforço, calculamos a
quantidade de dias de trabalho. A quantidade de dias de trabalho da
equipe foi calculada dividindo a quantidade de esforço estimado pela
quantidade de membros da equipe. Assim temos:
Dias de trabalho = quantidade de esforço / quantidade de membros da
equipe
Dias de trabalho = 280 / 4 = 70 dias úteis.
Esses resultados foram organizados na Tabela 2.
Tabela 2​ - Resultado da técnica de Lorenz & Kidd
Resultado
1 Número de Classe Chave: 4
2 Projeto de natureza classificada como GUI 2,5
3 Número de Classes de Suporte
(Classe Chave X Multiplicador)
4 x 2,5 = 10
4 Total de Classe
(Classe Chave + Classe Suporte)
4 + 10 = 14
5 Quantidade de Esforço Estimado
(Qtd de Classe X Unidade de Trabalho)
14 x 20 = 280
6 Dias de Trabalho da Equipe:
(Esforço Estimado / Qtd de Pessoas)
280 / 4 = 70
3. ANÁLISE E GESTÃO DE RISCOS
A análise e gestão de riscos é um meio de identificar e medir os riscos de
forma organizada, com o objetivo de antecipá-los para propor medidas de
contingência e redução dos seus impactos no projeto.
19

20. 3.1. Riscos do projeto
Na Tabela 3, estão listados os possíveis riscos do projeto Sistema de
Gestão do Berçário Girassol. Os mesmos foram classificados baseando-se em
um ​checklist previamente definido conforme o tipo: Projeto, Técnico ou de
Negócio​.
Tabela 3​ ​-​ Risco e tipo de impacto
Item Risco Projeto Técnico Negócio
01 O tamanho do banco de dados não foi
estimado
x
02 O produto possui limitações
significativas de performance
x
03 O tamanho do produto em números de
programas, arquivos e transações não
foi estimado
x
04 O prazo de entrega do software não foi
definido
x
05 O cliente não tem ideia dos requisitos do
produto
x
06 Processo de trabalho de equipe não foi
definido
x
07 O custo da entrega de um produto com
defeito não foi estimado
x
08 Documentação para o usuário não foi
planejada
x
09 A equipe não possui treinamento
necessário para esse projeto
x
10 O cliente não entende o processo de
engenharia de software
x
11 Ferramentas CASE não são usadas no
projeto
x
20

21. 3.2. Avaliação Global dos Riscos
A avaliação global dos riscos tem como objetivo identificar alguns
possíveis riscos que o projeto possa ter.
Tabela 4​ - Avaliação Global dos Riscos
Descrição Situação
1. Os Gestores de Software e Clientes dão suporte ao projeto
?
Sim
2. Os Clientes estão entusiasmados com o projeto e o
produto?
Sim
3. Os Engenheiros de Software e os Clientes
compreenderam bem os requisitos?
Sim
4. Os Clientes estiveram envolvidos na definição dos
requisitos?
Sim
5. As expectativas dos usuários são realistas? Sim
6. O âmbito do projeto é estável? Sim
7. O Engenheiros de Software têm as competências
requeridas?
Sim
8. Os requisitos do Projeto são estáveis? Sim
9. A Equipe de Desenvolvimento tem experiência com a
tecnologia que usará para implementar?
Não, nem todos da equipe tem
conhecimento com a
linguagem de programação
que usará para implementar.
10. É adequado o número de pessoas da equipe de
trabalho?
Sim
11.O cliente e os usuários concordam quanto à importância
do projeto? e nos requisitos do sistema ou produto a
construir?
Sim
21

22. 3.3. Tabela de riscos
Os riscos associados ao projeto estão listados na Tabela 5. A coluna Chance
de ocorrência mostra, em porcentagem, a probabilidade do risco se tornar realidade.
A coluna Impacto indica qual o nível de ameaça que ele representa para o projeto​,
podendo ser um dos seguintes, em ordem do menor para o maior impacto
(NASCIMENTO, 2019):
1. Desprezível - Terá uma influência muito pequena no projeto.
2. Marginal - Influenciará o projeto, mas não a ponto de pará-lo.
3. Crítico - Pode parar o projeto.
4. Catastrófico - Irá parar o projeto.
Eles foram escolhidos e avaliados de acordo com nossas experiências em
projetos anteriores, autoavaliação técnica, aprendizado adquirido nas diversas
matérias da graduação e a infraestrutura tecnológica atual do cliente.
Tabela 5 ​- Risco, probabilidade e impacto.
Item Risco Chance de
ocorrência
Impacto
01 O tamanho do banco de dados não foi estimado 30% CATASTRÓFICO
02 O produto possui limitações significativas de
performance
70% CRÍTICO
03 O tamanho do produto em números de
programas, arquivos e transações não foi
estimado
35% CRÍTICO
04 O prazo de entrega do software não foi definido 30% CRÍTICO
05 O cliente não tem ideia dos requisitos do
produto
30% CRÍTICO
06 Processo de trabalho de equipe não foi definido 25% CRÍTICO
07 O custo da entrega de um produto com defeito
não foi estimado
20% CRÍTICO
08 Documentação para o usuário não foi planejada 20% CRÍTICO
09 A equipe não possui treinamento necessário
para esse projeto
50% MODERADO
10 O cliente não entende o processo de
engenharia de software
20% MODERADO
22

23. 11 Ferramentas CASE não são usadas no projeto 10% MODERADO
3.4. Plano de Redução e Gestão do Risco
Com o objetivo de minimizar os problemas decorrentes dos riscos listados na
Tabela 5, nos Quadros de 4 a 11 foram traçados os planos para redução,
supervisão e contingência de riscos.
Quadro 4.​ ​Risco 01 -​ O tamanho do banco de dados não foi estimado
Risco:​ 01 Chance de ocorrência:​ 30% Impacto:​ Catastrófico
Descrição do risco:​ Possibilidade do tamanho do banco de dados crescer a ponto de atrapalhar
a performance do sistema, já que o banco ficará na máquina do usuário.
Estratégia de redução:​ Adoção de boas práticas na construção do banco de dados, como a
escolha correta do tipo de dado dos campos, o uso dos tipos booleano ou inteiro para os campos
que são ​flags​, etc.
Plano de contingência: ​ Exclusão de dados que não são mais necessários e criação de uma
política de ​backup​ que permita a exclusão dos backups mais antigos.
Pessoa responsável:​ Tawanna Hakkinen Oliveira Leite
Status:​ Concluído
Quadro 5.​ ​Risco 02 -​ O produto possui limitações significativas de performance
Risco:​ 02 Chance de ocorrência:​ 70% Impacto:​ Crítico
Descrição do risco:​ Possibilidade da performance do produto no equipamento do cliente ser
baixa a ponto de prejudicar sua utilização.
Estratégia de redução:
● Testar o desempenho toda vez que um novo recurso que possa impactar a performance
for implementado.
● Testar novos tipos de animações conforme forem implementados na máquina que irá
rodar o sistema.
● Realizar testes de carga, teste de stress, teste de pico, teste de escalabilidade e teste de
volume.
● Identificar os ​bottlenecks​ do sistema e otimizá-los.
Plano de contingência:​ Desativar as animações. Propor instalação de hardware de melhor
desempenho.
Pessoa responsável: ​Rodrigo Fonseca Nascimento
Status:​ Concluído
23

24. Quadro 6.​ ​Risco 03 -​ O tamanho do produto em números de programas, arquivos e
transações não foi estimado
Risco:​ 03 Chance de ocorrência:​ 35% Impacto:​ Crítico
Descrição do risco:​ Possibilidade do tamanho do produto em números de programas, arquivos e
transações ser maior do que o inicialmente esperado.
Estratégia de redução:
● Estudar o uso de mais de uma técnica de estimação de tamanho.
● Pesquisar o tamanho de produtos semelhantes.
Plano de contingência:​ Reavaliar o nível de cada requisito, completar os requisitos funcionais
antes de dar continuidade aos não-funcionais, diminuir escopo dos requisitos não-funcionais.
Pessoa responsável: ​Rodrigo Fonseca Nascimento
Status:​ Concluído
Quadro 7.​ ​Risco 04 -​ O prazo de entrega do software não foi definido
Risco:​ 04 Chance de ocorrência:​ 30% Impacto:​ Crítico
Descrição do risco:​ Com prazo não definido​ ​pode atrasar muito a entrega e a equipe cair em um
ciclo vicioso e não conseguir entregar o software.
Estratégia de redução:
● 1. Definir com o cliente todos os requisitos do software;
● 2. Estimar juntamente com o cliente qual a urgência da implementação do software em
seu negócio.
● 3. Estimar com a equipe de desenvolvimento quanto tempo precisará para desenvolver,
aplicando métricas de estimação;
● 4. Definir com a equipe qual nível de prioridade deve-se da ao software, baseando-se no
item 2.
● 5. Definir e apresentar ao cliente uma data para entrega do software.
Plano de contingência: ​Deve ficar atento às possíveis mudanças que podem ocorrer durante a
implementação do software, fazer backup periodicamente dos fontes e usar controle de versões
durante o desenvolvimento.
Pessoa responsável: ​Anderson Costa Moreira Santana
Status:​ Concluído
Quadro 8.​ ​Risco 05 -​ O cliente não tem ideia dos requisitos do produto
Risco:​ 05 Chance de ocorrência:​ 30% Impacto:​ Crítico
Descrição do risco:​ Possibilidade de haver constantes alterações nos requisitos do produto
devido ao fato de que o cliente não tem ideia dos requisitos do mesmo.
Estratégia de redução:
24

25. ● A equipe da análise deve fazer entrevistas com o cliente para entender o que ele deseja;
● A equipe da análise deve entrevistar outras pessoas que irão utilizar o software para obter
mais informações sobre quais problemas o software deve resolver;
● A equipe da análise deve sempre estar em contato com o cliente durante o processo de
desenvolvimento do software;
Plano de contingência:​ Usar outras técnicas de elicitação de requisitos, como a Etnografia que é
uma técnica de observação usada para compreender os requisitos organizacionais e sociais.
Pessoa responsável: ​Tawanna Hakkinen Oliveira Leite
Status:​ Concluído
Quadro 9.​ ​Risco 06 -​ Processo de trabalho de equipe não foi definido
Risco:​ 06 Chance de ocorrência:​ 25% Impacto:​ Crítico
Descrição do risco:​ Possibilidade de haver retrabalho por decorrência da elicitação de requisito
mal executada.
Estratégia de redução:
● Elicitação de Requisito mais apurada
● Revisões dos Modelos Conceituais
Plano de contingência:​ Realizar com mais frequência reuniões com o cliente.Fazer visitas ao
local de trabalho onde será implementado o software. Buscar entender melhor o modelo de
negócio do cliente.
Pessoa responsável: ​Pedro Sturaro dos Reis
Status:​ Concluído
Quadro 10.​ Risco 07 -​ O custo da entrega de um produto com defeito não foi
estimado
Risco:​ 07 Chance de ocorrência:​ 20% Impacto:​ Crítico
Descrição do risco:​ O custo inesperado gerado por entrega de um produto com defeito.
Estratégia de redução:
● Realizar todos teste indicados antes da entrega do produto
● Fazer verificações no processo de produção do software
● Realizar revisões por meio de uma equipe diferente da de desenvolvimento
Plano de contingência:​ Por meio de uma equipe de controle de qualidade, criar e realizar testes
no produto a ser entregue. A gestão do projeto deve verificar o métodos e os procedimentos para
a produção do software, de forma que minimize a possibilidade de bugs e outros defeitos.
Pessoa responsável: ​Pedro Sturaro dos Reis
Status:​ Concluído
25

26. Quadro 11.​ ​Risco 08 -​ Documentação para o usuário não foi planejada
Risco:​ 08 Chance de ocorrência:​ 20% Impacto:​ Crítico
Descrição do risco:​ O usuário pode ter dificuldade em utilizar o software principalmente se
novas funcionalidade forem implementadas em curtos espaços de tempo.
Estratégia de redução:
● 1. À medida que for implementando as funcionalidades do software deve-se fazer uma
breve descrição destas;
● 2. Documentar todas as funcionalidades do software após testadas;
● 3. Após implementada todas as funcionalidade montar, juntamente com o testador de
software, um plano de teste que possa verificar todas as possíveis falhas que possa
ocorrer durante o uso do software;
● 4. Deve-se criar uma cartilha ilustrativa de como usar o software e como agir em caso de
erros, baseando-se no item 2.
● 5. Inserir no próprio software um espaço onde o usuário possa tirar dúvidas;
Plano de contingência: ​Deve-se criar uma canal que permita aos usuários fazer da um feedback
aos desenvolvedores do software para reportar possíveis falhas que não foram descritas na
cartilhas.
Pessoa responsável: ​Anderson Costa Moreira Santana
Status:​ Concluído
4. PLANEJAMENTO TEMPORAL
Esta seção apresenta o planejamento temporal do projeto. O planejamento
temporal é desenvolvido pelos gestores de software e consiste na definição das
datas de execução das tarefas e dos seus responsáveis. A partir dele é possível ver
a interdependência entre as tarefas e o avanço do projeto.
Nas próximas subseções serão apresentados o conjunto de tarefas do
projeto e o diagrama de Gantt.
4.1. Conjunto de tarefas do projeto
Na Tabela 6 estão definidas as tarefas que serão realizadas durante o
processo de desenvolvimento do software. A estimativa dos dias de trabalho em
cada tarefa foi feita usando o total de dias de trabalho da equipe, obtido na Tabela
2, dividido pela quantidade de esforço utilizado em cada tarefa. Foi destinado 3% do
26

27. esforço para o Planejamento, 40% para Requisitos - Análise - Desenho, 22% para a
codificação e 35% para teste.
Tabela 6 ​- Conjunto de tarefas do projeto
Etapa Estimativa Dias de trabalho
Planejamento 3% (70*3%) = 2,1
Requisitos - Análise -Desenho 40% (70*40%) = 28
Codificação 22% (70*22%) = 15,4
Teste 35% (70*35%) = 24,5
Total 70 dias
4.2. Diagrama de Gantt
O diagrama de Gantt é um gráfico usado para mostrar o avanço das etapas
de um projeto. No Apêndice 1 é mostrado o diagrama de Gantt, onde pode ser vista
cada tarefa e sua lista de subtarefas, além da data inicial e final de cada uma. ​O
projeto terá início no dia 22/10/2019 e está previsto para ser concluído em
31/12/2019.
27

28. APÊNDICE 1
Diagrama de Gantt
A Figura 3 mostra o diagrama de Gantt desse plano de projeto.
Figura 3.​ Diagrama de Gantt
28

29. 5. ORGANIZAÇÃO DO PESSOAL
Nesta seção são apresentadas as funções de cada membro da equipe e uma
breve descrição de cada uma delas. Além disso, também são apresentadas as
ferramentas usadas na comunicação da equipe e no monitoramento das atividades
do projeto. E por último, será apresentado o Edu Blog e seu uso como ferramenta
de apoio.
5.1. Estrutura da equipe
O Quadro 12 apresenta o papel de cada integrante e uma breve descrição de
cada um desses papéis.
Quadro 12 ​- Estrutura da equipe
Papel Integrante Descrição
Gerente de Projeto
Desenvolvedor
Pedro Sturaro Define o objetivo geral do projeto, os
objetivos individuais, o cronograma
de atividades, as responsabilidades e
os recursos. Sua principal atribuição
é evitar que as falhas inerentes aos
processos aconteçam.
Analista de Sistemas Tawanna Oliveira Tem como função projetar o sistema,
atuar com análise e projeto de
sistemas, levantamento de requisitos
e regras de negócio, mapeamento de
processos e modelagem de dados
Desenvolvedor Rodrigo Nascimento Tem como função codificar e fazer a
manutenção do software..
Testador Anderson Costa Tem como função elaborar os planos
de teste e sua execução. Também
deve auxiliar no desenvolvimento de
automações de teste para que a
equipe de qualidade consiga agilizar
a identificação de erros em
atividades desenvolvidas.
5.2. Mecanismos de comunicação
A ferramenta utilizada para a comunicação entre os membros da equipe foi
WhatsApp. Já para o monitoramento das atividades foram utilizados o Trello e o
29

30. Google Drive. Abaixo se encontra uma breve descrição de cada uma dessas
ferramentas:
● WhatsApp - é um aplicativo multiplataforma de mensagens instantâneas e
chamadas de voz para smartphones. Além de mensagens de texto, os
usuários podem enviar imagens, vídeos e documentos em PDF, além de
fazer ligações grátis por meio de uma conexão com a internet.
● Trello - é um aplicativo de gerenciamento de projeto baseado na web. Nesta
ferramenta os projetos são representados por quadros (boards), que contêm
listas de tarefas. As tarefas são representadas por cartões que são criados
dentro dos quadros. Cartões podem ser movidos de uma lista para outra para
representar o progresso da tarefa sendo que os usuários podem ser inscritos
nos cartões. Ele opera um modelo de negócio Freemium (gratuito com opção
de assinatura para acesso a recursos avançados).
● Google Drive - é um serviço de armazenamento e sincronização de
arquivos. Google Drive abriga também o Google Docs, um leque de
aplicações de produtividade, que oferece a edição de documentos, folhas de
cálculo, apresentações, e muito mais.
5.3. Uso do Edu-blog como ferramenta de apoio
O Edu-Blog foi uma ferramenta de grande importância durante todo o
processo de desenvolvimento deste plano de projeto. Todo assunto dado em sala
de aula encontrava-se no blogue. Isso permitiu a equipe realizar consultas sempre
que preciso para tirar dúvidas sobre algo. Ou ainda, relembrar algo que foi dado em
sala de aula.
Além do conteúdo da disciplina, ele nos deu acesso aos blogs criados pelas
turmas anteriores que serviram como fonte de inspiração e referência para que
pudéssemos evoluir nosso trabalho a partir de uma rica base de conhecimentos.
30

31. 6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SOFTWARE
A primeira medida tomada para assegurar a qualidade do produto de
software foi entrevistar o cliente algumas vezes para definir a problemática e o
escopo do projeto. Após documentado, isso se tornou uma base sólida a partir da
qual nós desenvolvemos o projeto sem perder o foco no objetivo inicial.
Com o estabelecimento da equipe e análise de seus pontos fortes e fracos,
pudemos fazer um levantamento dos riscos para que traçássemos o melhor
caminho durante o desenvolvimento do projeto, sempre seguindo as orientações do
nosso professor e do material bibliográfico recomendado da disciplina.
Apesar da pouca experiência prática em desenvolvimento de software,
pudemos aproveitar conhecimentos adquiridos em outras disciplinas da graduação
como forma de complementar e aprimorar o presente trabalho.
Ao longo da evolução, continuamos consultando nossas bases de
conhecimento para ter certeza que o que estávamos construindo se alinhava com a
proposta inicial e cumpria as expectativas dentro do prazo estabelecido.
31

32. 7. REFERÊNCIAS BIBLIOGRÁFICAS
AS atribuições do gerente de projeto. ​Gerenciar Projetos. Disponível em
<​http://gerenciarprojetos.com.br/as-atribuicoes-do-gerente-de-projeto/>. Acesso em:
19 de fev. de 2020.
FRANZ, Natália. Guia de profissões: analista de testes. ​Tutano​. Disponível em
<​http://tutano.trampos.co/11576-guia-profissoes-analista-testes/>. Acesso em: 19 de
fev. de 2020.
GOOGLE Drive. ​Wikipédia​. Disponível em
<https://pt.wikipedia.org/wiki/Google_Drive>. Acesso em: 19 de fev. de 2020.
KIDD, Jeff; LORENZ, Mark. ​Object-Oriented Software Metrics. 1. Ed. Londres:
Pearson Technology Group, 1994.
NASCIMENTO, Rogério P C do. Lecture 3 :: Análise e Gestão de Risco. ​Edu-blog >
GP | UFS::2019​, 2019. Disponível em:
<https://gp-ufs.blogspot.com/2019/11/lecture-3-analise-e-gestao-de-risco.html>.
Acesso em: 12 de fev. de 2020.
PRESSMAN, R. S. ​Engenharia de software: uma abordagem profissional. 7. ed.
São Paulo: Pearson Makron Books, 2011.
PUTNAM JR., Larry. Saiba por que a estimativa de software está mais importante
do que nunca. ​Infoq​, 2018. Disponível em
<https://www.infoq.com/br/articles/software-estimation-important​/​>. Acesso em: 09
de mar. de 2020.
TRELLO. ​Wikipédia​. Disponível em <https://pt.wikipedia.org/wiki/Trello>. Acesso
em: 19 de fev. de 2020.
WHATSAPP. ​Wikipédia​. Disponível em <https://pt.wikipedia.org/wiki/WhatsApp>.
Acesso em: 19 de fev. de 2020.
32