O documento apresenta o plano de projeto de um sistema de gerenciamento de instrumentos para uma prefeitura, descrevendo suas principais funcionalidades, estimativas de esforço, riscos e plano de gerenciamento.

1. UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA(CCET)
DEPARTAMENTO DE COMPUTAÇÃO
PLANO DO PROJETO DE SOFTWARE
SISTEMA DE GERENCIAMENTO DE INSTRUMENTOS
PROF DR ROGÉRIO PATRÍCIO CHAGAS NASCIMENTO
DOUGLAS DE OLIVEIRA DÉDA
GEOVANNE SANTOS ATANAZIO
KAIO HENRIQUE DA COSTA FERREIRA
RAUL SILVEIRA VILAR
VITOR NEVES VARJÃO
São Cristóvão, 2020

2. INTRODUÇÃO 3
Convenções, termos e abreviações 3
Âmbito do Projeto 4
Funções principais do produto de software 4
Diagrama de casos de uso 4
Diagrama de classes 5
Requisitos comportamentais ou de performance 5
Gestão e Restrições Técnicas 5
ESTIMAÇÕES DO PROJETO 6
Dados históricos utilizados para as estimações 6
Técnicas de estimação e resultado 6
Resultados 7
Recursos do projeto 7
Recursos humanos 7
Recursos de software 7
Recursos de hardware 8
ANÁLISE E GESTÃO DE RISCOS 8
Riscos do projeto 8
Tabela de riscos 9
Redução e Gestão do Risco 10
PLANEAMENTO TEMPORAL 13
Conjunto de Tarefas do Projeto 13
Diagrama de Gantt 14
ORGANIZAÇÃO DO PESSOAL 16
Estrutura da equipe 16
Mecanismos de comunicação 16
Uso do Edu-blog como ferramenta de apoio 16
PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE
DO PRODUTO DE SW 17
REFERÊNCIAS 17

3. 1.0 INTRODUÇÃO
O objetivo do documento de projeto é oferecer uma visão geral do escopo do
sistema de gerenciamento de instrumentos da prefeitura municipal de São Cristóvão
1.1 Convenções, termos e abreviações
A correta interpretação deste documento exige o conhecimento de algumas
convenções, termos específicos e abreviações, que são descritos na Tabela 1.
Sigla/Abreviação/Termos Significado
Programa
Incentivo financeiro para elaboração
de um convênio de determinado
gênero.
Instrumento
Formulário necessário para solicitar
recursos de um programa do
governo. Um instrumento é
segmentado em 3 etapas onde em
cada uma delas novas informações
são inseridas.
Projeto
Primeiro estado de um instrumento.
Pode ser feita por qualquer
funcionário da prefeitura.
Proposta
Segunda estado de um instrumento.
É quando um projeto é cadastrado
no sistema do governo federal para
concorrer pelos recursos de um
programa.
Convênio
Terceiro estado de um instrumento.
É quando a proposta é aceita e a
mesma receberá verba do programa
no qual foi inscrito.
Diligência
Demanda de inserção ou edição de
informações ou documentos de um
instrumento em qualquer uma de
seus estados.
SPT
Sistema de Processamento de
Transação.
SIG Sistema de Informações Gerenciais.
SAD Sistema de Apoio à Decisão.
Framework
Abstração que une códigos comuns
entre vários projetos de software
provendo uma funcionalidade
genérica.
Tabela 1. Sigla e Significados

4. 1.2 Âmbito do Projeto
O sistema em foco possui dois objetivos. O primeiro, é o registro de todas as etapas
dos instrumentos concebidos na prefeitura municipal de São Cristóvão. Já o
segundo, trata-se da possibilidade do gestor cadastrar diligências para que o autor
do instrumento possa fazer as alterações solicitadas.
É importante salientar que o sistema aqui descrito não pode ser classificado como
SPT, nem como um SIG e muito menos com um SAD. Este e esse pelo o fato de
que a aplicação não irá gerar nenhum tipo de relatório que auxilie no processo de
tomada de decisão da organização. E aquele porque não se trata de uma rotina
diária em nível operacional. Assim, os registros gerados não são imprescindível para
o funcionamento da prefeitura.
1.3 Funções principais do produto de software
Para facilitar a compreensão dos funcionalidades e dar uma noção de como será a
implementação do sistema, será apresentado os diagramas de casos de uso e de
classes
1.3.1 Diagrama de casos de uso
Com o diagrama de casos de uso (Figura 1) é possível visualizar os atores que
interagem com o sistema e as funcionalidades que cada um deles podem têm
acesso no sistema.
Figura 1. Diagrama de Caso de Uso

5. 1.3.2 Diagrama de classes
Com o diagrama de classe em nível de análise (Figura 2) é possível visualizar as
classes chaves e seus atributos.
Figura 2. Diagrama de Classe
1.4 Requisitos comportamentais ou de performance
É essencial que a interface seja simples e intuitiva para o usuário baseado nas
heurísticas adaptadas de Jakob Nielsen. (ROCHA, BARANAUSKAS; 2003; p.170).
1.5 Gestão e Restrições Técnicas
As restrições técnicas associadas ou desenvolvimento do sistema são:
● O sistema deverá ser desenvolvido com o framework Laravel 6.x;
● O sistema deverá ser estruturado para trabalhar com o sistema de
gerenciamento de banco de dados PostgreSQL 12.

6. 2.0 ESTIMAÇÕES DO PROJETO
Esta seção fornece as estimações de custo, esforço e tempo. Aqui será mostrado
todas as técnicas de estimação e métricas usadas no desenvolvimento do Sistema
de gerenciamento de Instrumentos.
2.1 Dados históricos utilizados para as estimações
Por ser o primeiro trabalho realizado pela equipe não existe nenhum registro
histórico que pode ser utilizado para mensurar o custo, esforço ou tempo do atual
projeto.
2.2 Técnicas de estimação e resultado
O primeiro passo da técnica de estimação é identificar e determinar as possíveis
classes-chaves do projeto, que são as classes ligadas diretamente com as regras de
negócio, identificadas no levantamento de requisitos.
Depois de definir as classes-chaves, foi definido as classes suportes. Para isso, é
preciso classificar o tipo de interface para a aplicação, tendo para cada uma de suas
interfaces um multiplicador. Abaixo a Tabela 2 mostra os fatores de multiplicação
para cada classe suporte do projeto.
Interface Multiplicador
Não gráfica 2
Baseada em
texto
2,25
GUI 2,5
GUI
complexa
3,0
Tabela 2. Fatores de Multiplicação
No passo seguinte é feito a multiplicação da quantidade de classes chaves por um
dos fatores de multiplicação exibidos na Tabela 2 para obter o número estimado de
classes suportes.
Por último, é feito a multiplicação do número total de classes(chaves e de suporte)
com o número médio de unidades de trabalho por classe.O resultado será a
estimativa necessário para realizar esse projeto

7. 2.3 Resultados
Feito a aplicação das métricas de Lacertae SW, obtivemos:
● Classes-chaves: 5 (Projeto, Proposta, Usuário, Diligência e Convênio);
● Todas as classes chaves se encaixam no padrão GUI que tem multiplicador
2.5. Calculando a quantidade de classes de suporte temos 5 * 2.5 ​≅​ 13;
● O número total de classes para o projeto é : 5(classes chaves) + 13(classes
de suporte) = 18;
● O conhecimento da tecnologia a ser utilizada no projeto é média e a
quantidade de dias-pessoa por classe foi definida como 18;
● Sabendo que a quantidade de dias-pessoa por classe como 18 e o número
total de classes como 18 temos que o esforço total em dias será de 18x18=324 dias;
● Considerando que um dia de trabalho equivale a 8 horas e que o turno de
trabalho do projeto é de 4 horas, ou seja, 1 dia de trabalho normal equivale a 2 dias
no projeto, temos que o esforço total é igual a 648 dias-pessoa;
● Como a equipe é composta por 5 membros, a distribuição de dias de trabalho
por pessoa é calculado pelos dias totais dividido pela quantidade de membros que
resulta em aproximadamente 130 dias corridos de trabalho;
● Sabendo que um mês tem 22 dias úteis e foi estimado 130 dias corridos para
conclusão do projeto, então o projeto levará aproximadamente 5 meses e 28 dias
para ser concluído.
2.4 Recursos do projeto
Para conseguir desenvolver esse projeto são necessários alguns recursos. Nesta
seção serão apresentados todos eles.
2.4.1 Recursos humanos
Para o desenvolvimento desse projeto foram escalados 5 colaboradores. As
principais funções de cada um deles estão descritas na seção 5.
É importante salientar que por conta do tamanho reduzido da equipe cada um dos
membros também será responsável por selecionar e desenvolver uma
funcionalidade a cada rodada de implementação.
2.4.2 Recursos de software
Os softwares necessários para desenvolver a aplicação são:
● Xampp: servidor independente que servirá de suporte para o desenvolvimento
da aplicação;
● VsCode: IDE utilizada para o codificar o sistema;
● Trello: ferramenta para gerenciamento de atividades;
● Git: controle de versão;
● BitBucket: serviço de hospedagem de projetos;
● MySQL workbench: ferramenta utilizado para modelar o banco de dados;

8. ● Draw.io: plataforma utilizada para modelar de forma cooperativa o diagrama
de classes;
● Astah: ferramenta utilizada para modelar o diagrama de casos de uso;
● Google Docs: ferramenta utilizada para elaboração da documentação de
forma cooperativa.
2.4.3 Recursos de hardware
Foram utilizados 5 notebooks para o desenvolvimento do sistema.
3.0 ANÁLISE E GESTÃO DE RISCOS
Nesta seção iremos identificar e medir os riscos do projeto de forma organizada. Na
seção 3.1 iremos apresentar 10 riscos considerados mais importantes pela equipe
de desenvolvimento. Na seção 3.2 serão apresentados os riscos, com as suas
probabilidades de ocorrência e o impacto desses riscos no ciclo de vida do projeto.
Por fim, na seção 3.3 iremos identificar ações e métodos para a previsão e
gerenciamentos dos riscos citados.
3.1 Riscos do projeto
Nesta seção, por meio da Tabela 3, iremos listar todos os riscos, classificando eles
em riscos gerais e riscos únicos desse projeto.
Código Risco Tipo
001 Problema na definição dos requisitos Gerais
002 Não ter equipe definida para o desenvolvimento
do projeto
Gerais
003 A tecnologia usada é nova para a equipe Gerais
004 Disponibilidade da equipe Gerais
005 Não atender os prazos definidos Gerais
006 A equipe não irá fazer manutenção após a
entrega do projeto
Gerais

9. 007 Mais usuários do que o previsto Únicos
008 Cliente não conhece o processo de
desenvolvimento de software.
Únicos
009 Não trabalhou com o cliente antes Únicos
010 Cliente entusiasmado com o produto Únicos
Tabela 3. Tabela de risco com classificada.
3.2 Tabela de riscos
Os riscos identificados no projeto possuem informações que podem ser
consideradas importantes, como a identificação da probabilidade de ocorrência de
um risco. Com esses dados, o analista pode tomar precauções medidas no grau de
probabilidade do risco.
Outra informação é o impacto que o risco pode causar no projeto. Esta informação é
essencial para a gestão do projeto pelo analista. Os impactos podem ser
categorizados como desprezível, marginal, moderado, crítico e catastrófico.
Logo abaixo, apresentaremos uma tabela de riscos identificados durante o projeto. E
em cada linha terá a informação do risco, de sua probabilidade e do seu impacto no
projeto.
Código Risco Probabilidade Impacto
001 Problema na definição dos
requisitos
2 Marginal
002 Não ter equipe definida para o
desenvolvimento do projeto
2 Marginal
003 A tecnologia usada é nova para a
equipe
4 Crítico
004 Disponibilidade da equipe 4 Crítico
005 Não atender os prazos definidos 4 Crítico
006 A equipe não irá fazer
manutenção após a entrega do
projeto
4 Crítico

10. 007 Mais usuários do que o previsto 1 Insignificante
008 Cliente não conhece o processo
de desenvolvimento de software.
1 Insignificante
009 Não trabalhou com o cliente antes 3 Moderado
010 Cliente entusiasmado com o
produto
5 Catastrófico
Tabela 4. Tabela de Risco com sua probabilidade de ocorrer e seu impacto.
3.3 Redução e Gestão do Risco
Como uma forma de antecipação aos riscos foram elencadas estratégias com o
objetivo de reduzi-los, também foram pensados em planos de contingência para
contornar possíveis problemas, caso os mesmos sejam inevitáveis. As tabelas a
seguir contém a descrição desses planos:
Risco: 001 Probabilidade 20% Impacto Marginal
Descrição:​Dificuldade para definir os requisitos
Estratégia de Redução: ​Padronizar estratégias que auxiliem o levantamento de
requisitos. (Ex.: Histórias de Usuário).
Plano de Contingência: ​Realizar mais reuniões com o cliente​ ​e tentar reduzir o escopo
do problema.
Pessoa Responsável:​ Geovanne
Status: ​Concluído
Risco: 002 Probabilidade 20% Impacto Marginal
Descrição: ​Falta de equipe bem definida para o projeto
Estratégia de Redução: ​Documentar pessoas que já trabalharam juntas em projetos
anteriores e ter cargos bem definidos dentro da empresa.
Plano de Contingência: ​Elaborar o perfil do pessoal necessário para o desenvolvimento
do projeto e alocar os novos membros, juntamente com os que já estavam no projeto, de
acordo com suas experiências de projetos anteriores, habilidade e disponibilidades.
Pessoa Responsável: ​Raul
Status: ​Em andamento

11. Risco: 003 Probabilidade: 60% Impacto: Crítico
Descrição: ​A equipe não tem familiaridade com as tecnologias utilizadas no projeto.
Estratégia de Redução: ​Fornecer treinamento e capacitação para a equipe antes do
início do projeto, provendo cursos das tecnologias necessárias para desenvolvimento do
produto para os membros da equipe.
Plano de Contingência: ​ Negociar a entrega das funcionalidades com o cliente, e caso
não seja possível, contratar um profissional que tem familiaridade com a tecnologia.
Pessoa Responsável: ​Vítor
Status: ​Concluído
Risco 004 Probabilidade 65% Impacto Crítico
Descrição: ​A disponibilidade está comprometida, pois a equipe não pode ser dedicar
exclusivamente ao projeto.
Estratégia de Redução: ​Realizar reuniões frequentes para que todos os membros da
equipe tenham conhecimento sobre os requisitos, processos e andamento do projeto. A
partir disso caso algum membro esteja com a disponibilidade comprometida, ele poderá
receber auxilio nas funcionalidades delegadas ao mesmo por outros membros da
equipe.
Plano de Contingência: ​Renegociar os prazos com o cliente e alocar funcionalidades
de menor prioridade do sistema a membros que estão com a disponibilidade mais
comprometida. Caso os prazos não sejam possíveis renegociar, terceirizar as
funcionalidades menos importantes.
Pessoa Responsável: ​Raul
Status: ​Em andamento
Risco 005 Probabilidade 60% Impacto Crítico
Descrição: ​ Não cumprimento dos prazos pré estipulados.
Estratégia de Redução: ​Elaborar cronograma de atividades semanais da equipe
baseado na disponibilidade de cada um.
Plano de Contingência: ​Renegociar prazo com o cliente
Pessoa Responsável: ​Geovanne
Status: ​Em andamento
Risco 006 Probabilidade 60% Impacto Crítico

12. Descrição: ​Após a finalização do projeto a equipe de criação não irá fazer manutenção
do projeto.
Estratégia de Redução: ​Utilização de artefatos para documentação, adotar padrões de
documentação do código, e utilizar ferramentas de controle de versionamento.
Plano de Contingência: ​Fornecer treinamento a nova equipe que irá assumir o projeto
explicando conhecimentos adquiridos com o cliente e questões técnicas adotadas no
projeto.
Pessoa Responsável: ​Vitor
Status: ​Em análise
Risco: 007 Probabilidade 10% Impacto Insignificante
Descrição: ​O número de usuários acessando a aplicação ser maior que o planejado.
Estratégia de Redução: ​fazer uma análise para ver se é possível o aumento no número
de servidores.
Plano de Contingência: ​Buscar soluções distribuídas para melhorar o acesso.
Pessoa Responsável: ​Kaio Henrique
Status: ​Em análise
Risco: 008 Probabilidade 10% Impacto Insignificante
Descrição: ​O cliente não entende como funciona o desenvolvimento de software
Estratégia de Redução: ​Criar estratégias de marketing que possam educar os
possíveis clientes da empresa, para que estes já tenham algum conhecimento sobre a
área de desenvolvimento de software antes do primeiro contato.
Plano de Contingência: ​Explicar durante a primeira reunião o que é o desenvolvimento
de software tal como suas etapas, além de documentar tais etapas no contrato e/ou
documento de visão.
Pessoa Responsável: ​Douglas
Status: ​Concluído
Risco: 009 Probabilidade 50% Impacto Moderado
Descrição: ​É o primeiro projeto feito com o cliente.
Estratégia de Redução: ​Manter sempre o contato com cliente com o intuito de ter um
noção de sua perspectiva do projeto.
Plano de Contingência: ​fazer visitas e videoconferência com o cliente.

13. Pessoa Responsável: ​Kaio Henrique
Status: ​Em andamento
Risco: 010 Probabilidade 75% Impacto Catastrófico
Descrição: ​O cliente se mostra muito entusiasmado com o projeto e por consequência
espera recebê-lo logo.
Estratégia de Redução: ​Explicar durante as primeiras reuniões o tempo que leva para
desenvolver um projeto e sua complexidade
Plano de Contingência: ​Trabalhar com MVP’s e/ou protótipos visuais e se possíveis
funcionais, para que o cliente possa ver que o projeto está em andamento e mantenha
suas expectativas.
Pessoa Responsável: ​Douglas
Status: ​Em andamento
4.0 PLANEAMENTO TEMPORAL
Nesta seção serão apresentadas as tarefas e suas dependências estimando a
duração total do projeto. O planejamento temporal é uma tarefa importante no
projeto do software, pois serve como base para o gerenciamento do
desenvolvimento do software. Nessa etapa o objetivo é identificar as tarefas,
designar os responsáveis, fornecer uma visão da ascensão do projeto e pode ser
utilizado tanto pelo cliente quanto pela equipe de desenvolvimento(SOMMERVILLE,
2011 apud ROCHA, 2003).
4.1 Conjunto de Tarefas do Projeto
O conjunto de tarefas para a realização do processo de desenvolvimento do projeto
estão na Tabela, assim como o tempo estimado para a conclusão de cada tarefa. A
definição do tempo estimado para a realização das atividades foi de 115 dias úteis e
fazendo a distribuição com base na regra 40-20-40, onde 5% do esforço foi para o
planejamento, 36% para as atividades de levantamento de requisitos, análise, e
especificação de requisitos, 20% atribuído a codificação do software e 39% para a
realização dos testes.
Tarefas Porcentagem Tempo
(Dias de Trabalho)
Planejamento 5% 6
Levantamento, Análise e 36% 41

14. Especificação de Requisitos
Codificação 20% 23
Testes 39% 45
TOTAL 100% 115
Tabela 5. Tarefas do projeto
4.2 Diagrama de Gantt
A tabela 6 traz o detalhamento de todas as tarefas que serão realizadas durante o
processo de desenvolvimento do projeto e seu tempo de execução:
Tabela 6. Tabela com distribuição das atividades, seu início e duração.

15. Figura 3. Diagrama de Gantt. Início em 05/11/2019 término em 05/05/2020.

16. 5.0 ORGANIZAÇÃO DO PESSOAL
Nesta seção será apresentado a estrutura da equipe, os mecanismos utilizados para
a comunicação entre os membros e a importância do conteúdo do edu-blog.
5.1 Estrutura da equipe
A equipe foi estruturada como descrito na tabela 7:
Responsável Papel Descrição
Raul villar Gerente de
Projeto
Responsável pela alocação de recursos, ajuste
de prioridades, coordenação das interações
entre clientes e usuários, manter o foco da
equipe na meta, e acompanhar as atividades
executadas pela equipe do projeto.
Douglas Déda Analista de
Sistema
Responsável pelo levantamento de requisitos e
atividade de análise e projeto no qual irá
elaborar todos os diagramas necessários para a
implementação do produto de software.
Geovanne
Atanazio
Programador Responsável pela implementação do produto de
software.
Vitor Neves Programador Responsável pela implementação do produto de
software.
Kaio Henrique Testador Responsável pelos testes sistêmicos.
Tabela 7. Estrutura da equipe.
5.2 Mecanismos de comunicação
A comunicação do grupo foi feita da seguinte forma:
● WhatsApp e Slack, para agilizar a comunicação entre os membros;
● Reuniões presenciais, para solucionar questões complexas;
● Trello e Redmine, para o gerenciamento das tarefas.
5.3 Uso do Edu-blog como ferramenta de apoio
O edu-blog foi muito importante tanto para a elaboração desta documentação quanto
para o desenvolvimento do seminário.
Graças ao edu-blog foi possível visualizar os trabalhos das turmas anteriores o que
acabou servindo de referência para o desenvolvimento deste documento.

17. O blog do grupo serviu de preparação para a montagem do conteúdo do seminário e
para aprofundar o conhecimento dos membros sobre as metodologias ágeis que
foram utilizadas no processo de desenvolvimento desse software.
Em suma, o edu-blog ajuda no desenvolvimento das principais tarefas da disciplina.
Além disso, com a criação do blog do grupo novos conteúdos são gerados para as
futuras turmas.
6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SW
Para garantir a qualidade do produto é de suma importância a atualização dessa
documentação sempre que necessário.
7.0 REFERÊNCIAS
ROCHA, Heloísa Vieira da.; BARANAUSKAS, Maria Cecília Calani. Design e
Avaliação de Interfaces Humano-Computador. ​São Paulo: Instituto de
Computação, Universidade Estadual de Campinas, 2003.