UP19222259

Prévia do material em texto

UNIVERSIDADE PAULISTA – UNIP 
 
 
 
ERICK PATRIK ALVES DA FONSECA 
 
 
 
 
 
 
 
SISTEMA PARA LOCADORA DE VEÍCULOS 
 
 
 
 
 
 
 
 
 
Aluno: Erick Patrik Alves da Fonseca 
Matricula: UP19222259 
Curso: Analise e Desenvolvimento de 
Sistemas 
Semestre: 4 semestre 
 
 
 
 
 
 
 
 
 
 
 
 
BELÉM 
2020 
1 
 
 
 
UNIVERSIDADE PAULISTA – UNIP 
 
 
 
 ERICK PATRIK ALVES DA FONSECA 
 
 
 
 
 
 
 
SISTEMA PARA LOCADORA DE VEÍCULOS 
 
 
 
 
Trabalho do Projeto Integrado 
Multidisciplinar – PIM para obtenção de 
nota no 4º período, apresentado à 
Universidade Paulista – UNIP. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
BELÉM 
2020
 
 
 
DEDICATÓRIA 
 
Este trabalho é dedicado a todos nossos familiares e pessoas intimamente 
ligadas às nossas vidas, que no período de desenvolvimento deste trabalho nos 
ajudaram com paciência, carinho e compreensão, nos dando forças para que 
possamos alcançar nosso sucesso. 
 
 
 
AGRADECIMENTOS 
 
Ao professor orientador Daniel Fernandes de Oliveira, pela orientação, 
atenção, confiança e conhecimento compartilhado durante todo o trabalho; 
Aos professores Celio Santos e Wilker Bueno, pela expertise, motivação e 
cases compartilhados para elaboração desse trabalho; 
Especialmente aos nossos pais por todo apoio e carinho que nos oferecem em 
toda a nossa vida; 
Aos amigos, familiares, colegas de trabalho e de faculdade e a todos que 
colaboraram direta ou indiretamente com a execução deste trabalho. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
“Se hoje fosse o último dia de minha vida, 
queria fazer o que vou fazer hoje? E se a 
resposta fosse Não muitos dias seguidos, 
sabia que precisava mudar algo”. 
(Steve Jobs) 
 
 
 
RESUMO 
 
O Projeto Integrado Multidisciplinar IV do 4° Período do Custo Superior em 
Tecnologia de Análise e Desenvolvimento de Sistemas da Universidade Paulista - 
UNIP, traz o desafio de fazer uma análise e o desenvolvimento de um sistema 
destinado a Locadoras de Veículos. Se espera que mesmo se tratando de um projeto 
acadêmico, onde existem dificuldades, riscos e incertezas, realizar a entrega de um 
projeto, de acordo com as exigências do mercado de trabalho na qual proporcione ao 
cliente uma ferramenta que consiga atender às necessidades do mesmo. 
 
 
 
ABSTRACT 
 
The Integrated Multidisciplinary Design IV of the 4th Period of Higher 
Technology Cost Analysis and Systems Development Universidade Paulista - UNIP, 
brings the challenge of making an analysis and development of a system for rental car 
companies. Expected that despite being an academic project where there are 
difficulties, risks and uncertainties, make delivery of a project, in accordance with the 
requirements of the labor market in which the customer provides a tool that can meet 
the needs of the same. 
9 
 
 
 
 
SUMÁRIO 
DEDICATÓRIA ...................................................................................................... 4 
AGRADECIMENTOS ............................................................................................. 5 
RESUMO ............................................................................................................... 7 
ABSTRACT ............................................................................................................ 8 
SUMÁRIO .............................................................................................................. 9 
LISTA DE ABREVIAÇÕES .................................................................................. 12 
LISTA DE ILUSTRAÇÕES ................................................................................... 13 
LISTA DE TABELAS ............................................................................................ 14 
1 INTRODUÇÃO .................................................................................................. 15 
1.1 Justificativa .................................................................................................... 15 
1.2. Objetivos Gerais. .......................................................................................... 16 
Plano de Negocio ................................................................................................. 17 
Termo de Abertura do Projeto .............................................................................. 24 
Escopo do Projeto ................................................................................................ 24 
2 DESCRIÇÃO ..................................................................................................... 25 
2.2 Cronograma ................................................................................................... 26 
3 DESENVOLVIMENTO ...................................................................................... 28 
3.1 Engenharia de Software ................................................................................. 28 
I - Objetivo do projeto ........................................................................................... 28 
II - Justificativa do projeto .................................................................................... 28 
III - Riscos da Inexecução .................................................................................... 29 
IV - Premissas e restrições para o projeto ........................................................... 29 
V - Designação do gerente do projeto .................................................................. 29 
VI - Atribuições do solicitante do projeto .............................................................. 30 
VII - Descrição do projeto ..................................................................................... 31 
1. Produto do projeto ........................................................................................... 31 
10 
 
 
2. Cronograma básico do projeto ......................................................................... 31 
3. Estimativas iniciais de custo ............................................................................ 31 
VIII - Administração .............................................................................................. 32 
1. Necessidade inicial de recurso......................................................................... 32 
2. Necessidade de suporte pela organização ...................................................... 32 
3. Controle e gerenciamento das informações do projeto .................................... 32 
IX - Registro de alterações ................................................................................... 33 
X - Autorizações ................................................................................................... 33 
3.1.2 Modelo Cascata .......................................................................................... 34 
3.1.3 Engenharia de Sistemas ............................................................................. 34 
3.1.4 Análise de Sistemas .................................................................................... 34 
3.1.5 Projeto ......................................................................................................... 34 
3.2 Cenário .......................................................................................................... 35 
3.3 Levantamento de requisitos ........................................................................... 36 
3.3.1 Requisitos funcionais .................................................................................. 36 
3.3.2 Requisitos não funcionais ........................................................................... 38 
3.4 Regras de negócio ......................................................................................... 38 
3.5 Modelagem de software ................................................................................. 403.5.1 Casos de uso .............................................................................................. 40 
3.5.2 Diagrama de Caso de uso ........................................................................... 41 
3.5.3 Documentação de casos de uso ................................................................. 42 
3.5.4 Diagrama de classe .................................................................................... 45 
3.5.5 Diagrama de Sequência .............................................................................. 46 
3.5.6 Diagrama de Pacotes .................................................................................. 51 
3.5.6 Diagrama de Máquina de Estado ................................................................ 53 
3.6 Termo de encerramento do projeto ................................................................ 55 
XI - Título do projeto ............................................................................................. 55 
XII - Considerações finais .................................................................................... 55 
XIII - Autorizações ................................................................................................ 56 
11 
 
 
4 CONSIDERAÇÕES FINAIS .............................................................................. 57 
4.1 Aprendizado Adquirido. .................................................................................. 57 
5 - REFERÊNCIAS BIBLIOGRÁFICAS ................................................................ 58 
12 
 
 
 
LISTA DE ABREVIAÇÕES 
 
CNH: Carteira de Nacional de Habilitação. 
CPF: Cadastro de Pessoa Física. 
CNPJ: Cadastro Nacional de Pessoa Jurídica. 
DP: Departamento. 
13 
 
 
 
 
LISTA DE ILUSTRAÇÕES 
Figura 2 - Caso de uso ......................................................................................... 41 
Figura 3 - Diagrama de classes ........................................................................... 45 
Figura 4 - Diagrama de sequência "Inserir funcionário" ....................................... 46 
Figura 5 - Diagrama de sequência "Editar funcionário" ........................................ 47 
Figura 6 - Diagrama de sequência "Remover funcionário" ................................... 47 
Figura 7 - Diagrama de sequência "Inserir veículo" ............................................. 47 
Figura 8 - Diagrama de sequência "Editar veículo" .............................................. 48 
Figura 9 - Diagrama de sequência "Remover veículo" ......................................... 48 
Figura 10 - Diagrama de sequência "Inserir cliente" ............................................ 48 
Figura 11 - Diagrama de sequência "Editar cliente" ............................................. 49 
Figura 12 - Diagrama de sequência "Remover cliente" ........................................ 49 
Figura 13 - Diagrama de sequência "Efetuar locação" ......................................... 49 
Figura 14 - Diagrama de sequência "Finalizar locação" ....................................... 50 
Figura 15 - Diagrama de pacotes ......................................................................... 52 
Figura 16 - Diagrama máquina de estados .......................................................... 53 
Figura 17 - Diagrama de comunicação ................................................................ 54 
14 
 
 
 
LISTA DE TABELAS 
 
Tabela 2 - Requisitos não funcionais .................................................................... 38 
Tabela 3 - Documentação do caso de uso Manter Empresa ................................. 42 
Tabela 4 - Documentação do caso de uso Manter Cliente .................................... 43 
Tabela 5 - Documentação do caso de uso Manter Frota....................................... 44 
Tabela 6 - Documentação do caso de uso Manter Locação ................................. 44 
15 
 
 
 
 
1 INTRODUÇÃO 
 
O desafio do Projeto Integrado Multidisciplinar IV, para o 4º período do curso 
de Análise e Desenvolvimento de Sistema é fazer uma análise e o desenvolvimento 
de um sistema para uma solução no ramo de locação de veículos, usando os 
aprendizados adquiridos nas disciplinas bases e complementares: Desenvolvimento 
de Software para Internet, Gerenciamento de Projetos de Software, Programação 
Orientada Objetos II, Projeto Sistema Orientado a Objetos, Top. Esp. programação 
Orientado Objetos. 
A análise e o desenvolvimento de sistema, tem como objetivo projetar, 
identificar e apresentar as melhores soluções em software, no intuito de automatizar 
os processos executados nas empresas, diminuindo o tempo e custo da operação. 
 
 
1.1 Justificativa 
 
O ramo de locação de veículos está em ascensão no Brasil. Segundo a 
Associação Brasileira das Locadoras de Automóveis (ABLA), o setor registrou 
contribuições tributárias superiores a R$ 1,8 bilhão em 2011, empregando direta e 
indiretamente, mais de 277 mil pessoas. A duração média das locações aumentou 
de 3,6 dias para 6 dias em dois anos. 
Este tipo de atividade possuí um ativo imobilizado de alto custo, os veículos. 
Por este motivo encontrar soluções e estratégias para redução de custos e 
otimização de processos é uma prioridade. É preciso um controle rigoroso de 
aspectos como duração da locação e facilitar a venda de itens opções. 
Utilizando a análise de sistemas e as técnicas e ferramentas adquiridas no 
ambiente acadêmico é possível a abstração deste problema para a elaboração de 
um projeto de software que satisfaça a necessidade de empresas deste setor. 
A possibilidade de aplicação do conhecimento científico em problemas reais 
torna este projeto necessário, visto que o mesmo gera oportunidade de aplicação de 
diversos assuntos como UML, Gerência de Projetos e Processos. 
16 
 
 
 
 
1.2. Objetivos Gerais. 
Fazer a análise e o desenvolvimento do sistema Unip Rent a Car para a 
locadora de veículos Locartyn. 
 
1.3. Objetivos Específicos. 
 Pesquisar o ramo de locação de veículos para levantamento de processos e 
atividades; 
 Criar a locadora de veículos Locartyn, uma empresa fictícia para abstração 
do domínio do problema; 
 Elaborar um projeto de software para informatizar os principais processos da 
locadora de veículos Locartyn; 
 Utilizar os diagramas da UML para modelagem do projeto de software; 
 Aplicar técnicas de Gerenciamento de Projetos para gestão das atividades e 
membros da equipe; 
 Desenvolver um software que torne o processo de locação otimizado e 
seguro. 
17 
 
 
 
 
Plano de Negocio 
1 Informações sobre o responsável pela proposta. 
Nome: Aldir Origuela França 
Identidade: 2039904-9 Órgão Emissor: SSP/MT CPF: 032.271.331-56 
Endereço: AV-T37 QD 166 AP 2901 ED. BORGES LANDEIRO OLYMPUS 
Bairro: SETOR BUENO Cidade: GOIANIA Estado: GO CEP:74230-050 
Telefone: (62) 3612-4226 FAX: (62) 3612-4226 E-mail: Dinho.o.f@hotmail.com 
Formação Profissional: Analista de Sistemas. 
Atribuições no Empreendimento: Proprietário. 
2 Natureza/Descrição do empreendimento: 
Individual Limitada X Sociedade Anônima 
Razão Social: HOJE SOLUÇÕES LTDA 
Nome Fantasia: HOJE SOLUÇÕES LTDA 
CGC - Insc. Estadual: ISENTO Insc. Municipal 
2.1. Nome dos sócios e respectivas participações na empresa 
Nome Participação 
ALDIR ORIGUELA FRANÇA 100% 
 
2.2. Áreas de competência tecnológica (áreas de conhecimento técnico 
que são dominadas) 
Nome Área 
Programação Khyquer Ronaldy 
Projeto e Processo Janaina Fonseca 
 
 
2.3 Responsáveis pela gestão do empreendimento (por área). 
Área Responsável 
Administração Fabio Gandolfo 
Financeira Marcia Brito 
Produção Alessandro Ferreira 
Tecnológica Kleber Marques 
Comercial Renato Brito 
Outras 
(especificar) 
mailto:Dinho.o.f@hotmail.com
18 
 
 
 
 
3 Plano estratégico 
 
3.1 – Missão e objetivos estratégicos: 
A missão da empresa é proporcionar soluções inteligentes emsoftware que vão otimizar 
processos de uma empresa. 
Objetivo estratégico a curto prazo é conquistar a fidelização de clientes e expandir a 
carteira. Se tornar uma empresa que seu ponto forte seja qualidade e pontualidade nos 
projetos solicitados. 
 
3.2 – Ameaças e oportunidades: 
Devido ao nível de profissionais qualificados no mercado de trabalho serem poucos, a 
empresa tem como objetivo formar profissionais na qual vão contribuir com o 
crescimento da empresa a longo prazo. 
 
3.3 – Pontos fortes: 
O ponto forte da empresa é proporcionar ao cliente o suporte necessário e entregar o 
serviço solicitado com qualidade e cumprir as datas propostas nos projetos. 
 
3.4 – Pontos fracos: 
 
Muitas vezes nem mesmo o cliente sabe qual a sua real necessidade, devido a 
esse fator negativo, a empresa acaba estendendo a análise para identificar com o cliente 
as reais necessidades e apresenta ao mesmo uma solução eficaz. 
Isso acaba tendo um custo e muitas vezes os clientes não estão dispostos a 
investir o necessário para que o projeto seja iniciado. 
 
4 Produtos e serviços. 
 
4.1 – Descrição do produto/serviço. 
O serviços básicos para que seja feito o projeto é analise do sistema, na qual vai 
ser aprovada pelo cliente e depois 
19 
 
 
 
 
4.2 – Foco do Negócio. (Mercado potencial e concorrência) 
O foco do negócio é oferecer soluções em software, apesar de ter empresas que 
estão consolidadas nesse ramo, está sendo exposto como diferencial a qualidade e 
pontualidade na entrega dos projetos solicitados. 
Hoje várias empresas tanto de pequeno e grande porte, precisam de soluções 
para ajudar no crescimento da empresa. 
 
4.3 - Diferenciais dos produtos/serviços (em relação aos disponíveis no 
mercado) 
O diferencial do serviço é a qualidade e pontualidade, pois cada projeto é 
baseado na necessidade de cada cliente. 
Suporte sobre o produto entregue é gerenciado através de prazos que são 
definidos para solucionar supostos erros de sistema ou melhoria, solicitada pelo cliente. 
 
4.4 – Estágio atual do desenvolvimento do produto/serviço* 
FASE ESTÁGIO Estági Cronograma por semestre 
 
 o atual 1º 2º 3º 4º 5º 6º 
 
01 Maturação da ideia 
 
X 
Sem 
X 
Sem Sem Sem Sem Sem 
02 Em especificação X X 
 
03 Em desenvolvimento X X 
04 Em teste X X 
05 Protótipo 
06 Demonstração 
cliente 
07 Em comercialização 
X 
em X 
 
X 
 X 
X 
 
 
 
X 
 
* Quando o projeto se referir a mais de um produto/serviço, fazer um cronograma para cada produto, 
separadamente. 
 
5) Comercialização 
20 
 
 
 
5.1 – Estratégias de venda e assistência técnica. 
Procurar clientes com potencial na qual precisam de soluções em software para 
ajudar no crescimento da empresa. 
Oferecer todo o auxílio possível ao cliente, desde a elaboração do projeto até o 
momento em que o produto esteja entregue. 
 
6) Plano de investimentos 
 
6.1 – Investimentos iniciais 
 
Descrição Valor 
1. Estudo de mercado R$ 1.000,00 
2. Registro de marcas e patentes R$ 1.000,00 
3. Honorários R$ 20.000,00 
4. Registro da Empresa R$ 1.000,00 
5. Máquinas e Equipamentos R$ 900.000,00 
6. Móveis / Utensílios R$ 20.000,00 
7. Capital de giro R$ 9.000.000,00 
8. Outros (especificar) R$ 1.000,00 
9. Total R$ 9.944.000,00 
 
6.2 – Origem dos recursos (investimentos iniciais) 
Valor Total Recursos próprios (%) Recursos de terceiros (%) Reinvesti mento (%) 
R$ 9.944.000,00 50% 50% 0% 
 
7) – Receita e custos 
 
7.1 – Receitas operacionais 
 
Ano 1º Trimestre 2ºTrimestre 3º Trimestre 4º Trimestre Total 
1º Ano 100.000,00 200.000,00 300.000,00 400.000,00 1.000.000,00 
2º Ano 500.000,00 600.000,00 700.000,00 800.000,00 2.600.000,00 
3º Ano 900.000,00 910.000,00 920.000,00 930.000,00 3.660.000,00 
21 
 
 
 
7.2 – Custo fixo anual (1º ano) 
 
Descrição Valor Anual 
1. Salários e encargos 50.000,00 
2. Pró-labore 10.000,00 
3. Taxa de Incubação 10.000,00 
4. Taxas Diversas (Telefone, aluguel de Equipamentos, etc.) 10.000,00 
5. Materiais Diversos 2.000,00 
6. Manutenção e Conservação 1.000,00 
7. Seguros 2.000,00 
8. Depreciação 1.000,00 
9. Outros 3.000,00 
10. Total 89.000,00 
 
7.3 – Custo variável (1º ano) 
 
Descrição Valor Anual 
1. Matéria Prima 10.000,00 
2. Embalagem 1.000,00 
3. Outros insumos 1.000,00 
4. Frete 1.000,00 
5. Outros (comissões, impostos, etc.) 20.000,00 
6. Total 33.000,00 
8) Demonstrativos simplificados de resultados (1º ano) 
Item Descrição 
 
Valores 
1 Receita bruta (Quadro 7.1) 1.000.000,00 
2 (-) Custos Fixos (Quadro 7.2) 89.000,00 
3 (-) Custos variáveis (Quadro 7.3) 33.000,00 
4 Resultado Operacional (1 – 2 – 3) 1.122.000,00 
5 (+) Receitas não operacional 50.000,00 
6 (-) Despesas não operacionais 2.000,00 
7 Lucro Bruto (4 + 5 – 6) 1.170.000,00 
22 
 
 
 
9 – Projeção do fluxo de caixa. 
 
Mês 
Descrição 
1. Receita 
Operacional 
2.Receita não 
operacional 
(A) Total de Entrada 
3. Despesa 
Operacional 
4. Despesa não 
operacional 
4. Investimento 
 
(B) Total de 
Saída 
(C) Saldo no 
mês 
A = (1 + 2); B = (2 + 3 + 4); C = (A – B); Total = Soma (Mês 1 à 12) 
 
10) Indicadores 
 
10.1 – Ponto de equilíbrio anual: Primeiro ano (se não houver previsão 
de receita para o primeiro ano, não considere este item) 
P.E = 
89.000,00 x 
1.000,00 – 33.000,00 100 
 
10.2 – Tempo de retorno do investimento (TR) : 
 
Número de meses 
 
necessário para recuperar o dinheiro aplicado no investimento inicial. 
 
9.944.000,00 
TR = 
1.122.000,00 
x 12 
1 2 3 4 5 6 7 8 9 10 11 12 Total 
100 100 100 100 100 100 100 100 50 50 50 50 1 mi 
 
5 
 
5 
 
5 
 
5 
 
5 
 
5 
 
5 
 
5 
 
3 
 
3 
 
3 
 
1 
 
50 
 mil 
100 100 100 100 100 100 100 100 50 50 50 50 1 mi 
 
100 
 
100 
 
100 
 
100 
 
100 
 
100 
 
100 
 
100 
 
100 
 
100 
 
500 
 
500 
 
2 mil 
 
1 
 
1 
 
1 
 
1 
 
1 
 
1 
 
1 
 
1 
 
1 
 
250 
 
250 
 
444 
 
9.94 
4 mi 
100 100 100 100 100 100 100 100 100 100 11 11 122 
mil 
100 100 100 100 100 100 100 100 30 30 10 8 782 
mil 
 
23 
 
 
Necessário serviço de RH, serviço de internet, telefonia, serviço administrativo. 
12 – Considerações finais. (Texto Livre) 
 
A empresa tem como compromisso e objetivo alcançar as metas propostas e crescer 
no mercado de soluções em software, de forma solida e sempre procurando a 
satisfação do cliente. 
 
 
 
11) Utilização da infraestrutura da incubadora 
 
11.1 – Área física necessária: 
Uma sala com 300 M² 
11.2 – Necessidades quanto a serviços administrativos, treinamento, 
consultoria, laboratórios, oficinas, etc.: 
24 
 
 
SISTEMA PARA LOCADORA DE VEÍCULOS 
TERMO DE ABERTURA 
Nome do projeto: Locadora de veículos Versão: 1.0 
Área Responsável: Desenvolvimento de software 09/8/2020 
Preparado / Revisado por: Aldir Origuela França, Carlos Alberto de Oliveira, João Everto 
de Araújo Melo e Tiago Lucas Rodrigues da Silva 
Aprovado por: Daniel Fernandes de Oliveira, Antônio Cruvinel Borges Neto, 
Antônio Carvalho Torres. 
Área: 
[ x ] Fim 
[ x ] Meio 
Tipo: 
[x] Meta Geral 
[ ] Problema Prioritário 
[ ] Problema não prioritário 
[ ] Outros 
 
Termo de Abertura do Projeto 
 
Escopo do Projeto 
 
No projeto foi definido que seria feito o cadastro de cliente, cadastro de 
funcionário, cadastro de frota e a locação da frota. Para maior conforto do cliente, o 
desenvolvimento da solução será realizado em duas plataformas Java Web e 
Desktop, disponibilizando também o banco de dados. 
Todo desenvolvimento do software será baseado na análise realizada pela 
gerencia de projeto feita juntamente com o cliente, ou seja, nada que não esteja 
dentro da análise documentada será feito, pelos desenvolvedores da solução. 
25 
 
 
 
 
 
2 DESCRIÇÃO 
 
2.1 Planejamento 
Para o planejamento da análise e o desenvolvimento do sistema, foi adotado 
a divisão de tarefas como a colaboração de conhecimento em deficiências 
possivelmenteencontradas que poderiam atrapalhar o andamento do projeto no 
tempo esperado, executando o cronograma, seguindo os passos do modelo cascata 
e fazendo um bom levantamento de requisitos, para desenvolver um software com 
margem de segurança e tranquilidade. 
26 
 
 
 
 
2.2 Cronograma 
Fase1 
ID Nome da tarefa Início Conclusão Duração 
1 Iniciar projeto documentado: Iniciar 
documentação do projeto 
2 Criar cenário: Coletar narrativas de 
situações no domínio que favorecem o 
levantamento de informações, a 
identificação de problemas e a 
antecipação das soluções. Lembrar de 
focar as atividades que as pessoas 
realizam na organização possibilitando 
uma perspectiva mais ampla dos 
problemas atuais onde o sistema 
deverá ser inserido, explicando porque 
ele é necessário. 
3 Levantar requisitos: Levantar ou 
capturar requisitos para descobrir junto 
15/03/0213 10/06/0213 87d 
 
25/03/2020 29/03/2020 5d 
 
 
 
 
 
 
 
08/04/2020 12/04/2020 5d 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
eficiente. 
 ao cliente quais são as características 
necessárias ao sistema. Mesmo 
existindo diversas técnicas que podem 
ser utilizada, utilizar a mais básica e 
intuitiva que é a entrevista. 
4 Definir regras de negócio: Listar as 15/04/2020 17/04/2020 3d 
 regras de negócios determinando como 
 a empresa funciona, o que deve ser 
 feito e como deve ser feito. 
5 Criar os casos de uso: Documentar os 17/04/2020 19/04/2020 3d 
 requisitos funcionais do sistema 
 utilizando a UML, descrever a interação 
 entre o usuário e o sistema com o 
 intuito de prover a funcionalidade 
 solicitada, indicando as sequências de 
 passos seguidos durante a interação. 
 Para cada funcionalidade do sistema, 
 será criado pelo menos um caso de 
 uso. 
6 Documentar os diagramas de caso 22/04/2020 26/04/2020 5d 
 de uso: Realizar a documentação do 
 caso de uso para melhorar a 
 comunicação entre o usuário final e o 
 desenvolvedor tornando o processo de 
 análise de requisitos mais eficaz e 
7 Diagrama de classe: Criar o diagrama 06/05/2020 17/05/2020 10d 
 de classe com objetivo de mostrar os 
 
27 
 
 
 
 
relacionamentos existentes entre as 
classes que são abstraídas no projeto, 
e como esses relacionamentos 
colaboram para a execução dos 
processos específicos. 
8 Diagrama de Sequência: Criar os 
diagramas de sequência para fornecer 
suporte real a implementação, 
representando os objetos participantes 
da colaboração enquanto emitem e 
recebem mensagem no intuito de 
realizar um caso de uso. 
 
 
 
 
27/05/2020 31/05/2020 5d 
 
Fase 2 
Tabela 1 – Lista de tarefas fase1 
 
 
 
 
para representar os subsistemas ou 
sub-módulos englobados por um 
sistema de forma a determinar partes 
que o compõem. 
Desenvolvimento do Software: 
Desenvolver o software da locadora de 
carro de acordo com a análise feita 
usando a linguagem JAVA WEB e 
Desktop. 
Testar o Software: Testar o software 
para encontrar possíveis erros de 
codificação e divergências com a regra 
de negócio. 
Desenvolver o documento de 
Conclusão do projeto: 
Documentação com as especificações 
da conclusão do projeto. 
 
 
 
 
10/09/2020 10/10/2020 30d 
 
 
 
15/10/2020 28/10/2020 14d 
 
 
01/11/2020 25/11/2020 25d 
Tabela 2 - Lista de tarefas fase2 
Desenvolver o plano de negócio: 02/09/2020 02/09/2020 1d 
Desenvolver o Termo de Abertura: 02/09/2020 02/09/2020 1d 
9 Diagrama de pacote: Criar diagramas 02/09/2020 05/09/2020 4d 
 
28 
 
 
 
 
3 DESENVOLVIMENTO 
 
3.1 Engenharia de Software 
 
De maneira simplificada, podemos definir como uma área da tecnologia da 
informação preocupada com os métodos e práticas de desenvolvimento de software, 
incluindo planejamento, especificação, codificação, testes e outras atividades 
inclusas no ciclo de um software. 
 
 
I - Objetivo do projeto 
 
Análise e Desenvolvimento de um software para gestão de locadoras de 
veículos que realize o controle de veículos, locação, clientes e funcionários. 
 
 
II - Justificativa do projeto 
 
Diante do atual cenário competitivo que temos hoje, as empresas estão 
buscando expandir seus limites. Esse contexto exige que profissionais sejam 
aproveitados ao máximo de sua produtividade, e com um menor tempo possível 
necessário para realizar suas atividades, reduzindo custos na operação, e fazendo 
com que a empresa tenha ainda mais um potencial competitivo, com um serviço 
rápido, seguro, eficiente e que tenha um grande valor agregado. 
 
Resumo das condições do projeto 
Atualmente, a empresa já dispõe de funcionários e insumos para implementar 
um novo modelo gestão baseado nos mais modernos padrões de qualidade. Será 
realizado um treinamento de capacitação, onde será oferecido toda capacitação 
técnica necessária para operacionalizar o sistema de locação. 
29 
 
 
 
 
Benefícios e Beneficiados 
 
Benefícios Beneficiados 
Agilidade no processo Clientes, Colaboradores, Gestão 
Redução de custos Clientes 
Maior lucratividade Gestão 
Diminuição de retrabalho Colaboradores 
Diminuição de falhas Clientes, Colaboradores 
Controle de cadastro Colaboradores, Gestão 
 
 
III - Riscos da Inexecução 
 
Como firmado em contrato, até a data 09/12/2020 todo o sistema deverá estar 
implementado e funcionários necessários capacitados. 
O não cumprimento deste prazo acarretara em uma multa, na forma de 
redução do valor a ser pago pelo projeto, firmado em 1% por dia de atraso. 
 
 
IV - Premissas e restrições para o projeto 
 
Premissas Restrições 
 Desenvolver uma aplicação que atenda 
às necessidades do cliente. 
 Utilizar as melhores práticas de 
desenvolvimento de software 
 Gerir bem os recursos disponíveis 
 Entregar no prazo estipulado 
 Garantir a máxima excelência no produto 
entregue 
 Nenhuma flexibilidade no prazo de 
entrega 
 Compensar a lacuna de alguns 
profissionais necessários com estudos 
individuais e em grupo. 
 
 
V - Designação do gerente do projeto 
 
O Sr. Tiago Lucas Rodrigues da Silva será responsável por toda gestão 
técnica e administrativa do projeto. Terá autonomia para adquirir equipamentos, 
ferramentas, recrutar pessoal e todas outras demandas, de acordo com orçamento 
já previsto pela diretoria administrativa. Em sua ausência, questões de cunho técnico 
30 
 
 
 
 
deverão ser tratadas com o arquiteto de softwares e questões administrativas com a 
própria diretoria. 
Tendo ainda as seguintes atribuições: 
 
 Planejar o projeto de maneira realística. 
 Elaborar a documentação do Projeto e gerenciar o seu andamento; 
 Elaborar o cronograma das tarefas do projeto; 
 Revisar a documentação formal do projeto emitindo pareceres quanto a 
viabilidade do projeto; 
 Atuar como o ponto central de contato para toda comunicação formal 
relacionada ao projeto; 
 Comunicar o Setor de Qualidade da indústria o andamento do projeto; 
 Assegurar que a equipe do projeto esteja ciente de suas 
responsabilidades; 
 Divulgar antecipadamente a pauta de cada reunião; 
 Gerenciar os compromissos estabelecidos para realizá-los em tempo, 
dentro do orçamento e com satisfação do solicitante; 
 Elaborar e atualizar os documentos de Projeto com a anuência expressa 
do solicitante; 
 Controlar o cronograma, escopo e variações técnicas dentro das margens 
estabelecidas do projeto; 
 Monitorar e manter a prioridade do projeto em relação a outros projetos; 
 Manter toda documentação, pertinente ao gerenciamento do projeto, 
atualizada nos sistemas, bem como na base de conhecimento; 
 Seguir todos processos e padrões metodológicos; 
 Disponibilizar o status do projeto e toda a documentação à gerência 
regularmente, evitando surpresas. 
 Tomar todas as providências necessárias para que o projeto ocorra 
conforme o planejado. 
 
 
VI - Atribuições do solicitante do projeto 
31 
 
 
 
 
A autoridade do solicitanteou patrocinador do projeto é a sua contribuição 
principal. Cabe a ele: 
 Apoiar o gerente do projeto; 
 Analisar e aprovar este termo de Abertura; 
 Analisar e aprovar a Declaração do Escopo; 
 Analisar e aprovar documentos do Projeto; 
 Auxiliar o Gestor do Projeto a superar os obstáculos organizacionais. 
 
 
VII - Descrição do projeto 
 
1. Produto do projeto 
Produto: Software Gestão Locado de Veículos 
Processo: Planejar, desenvolver, codificar, testar, homologar, capacitar, 
implantar e manter. 
 
2. Cronograma básico do projeto 
O projeto tem início previsto para 02/09/2020 com a conclusão prevista para 
25/11/2020. 
3. Estimativas iniciais de custo 
1. Custos com Recursos Humanos 
2. Custos com aquisição de licenças 
3. Custos com Aquisição de materiais específicos como computadores, 
telefones, etc. 
4. Custos com material escritório. 
O presente projeto terá um custo inicial de R$ XXX, conforme detalhado 
abaixo: 
1 – Serviço ou Entregue 1 R$ 25.000,00 
2 – Serviço ou Entregue 2 R$ 8.000,00 
3 – Serviço ou Entregue 3 R$ 3.000,00 
4 – Serviço ou Entregue 4 R$ 600,00 
TOTAL R$ 36.000,00 
32 
 
 
 
 
Este projeto tem previsão orçamentária solicitada através do memorando 024 
da Diretoria Administrativa. 
 
*Obs.: O prazo e o custo aqui apresentados são estimados por analogia, 
portanto com grande margem de erro. Conforme o escopo seja detalhado será 
possível fornecer estimativas com margem de erro menor. 
VIII - Administração 
1. Necessidade inicial de recurso 
Toda a equipe que será envolvida neste projeto, será formada pelo quadro de 
funcionários permanentes da empresa, aonde inicialmente não haverá nenhuma 
nova contratação. 
Quanto a aquisição de equipamentos e licenças para o desenvolvimento do 
software, também serão utilizadas as já disponíveis em nosso parque. Sendo que o 
valor inicial de sua aquisição estará sendo diluído não apenas neste, mas em todos 
os projetos (anteriores e futuros) que deles usufruírem. 
As licenças e equipamentos necessárias para implementação no ambiente do 
cliente, terão seus valores embutidos no orçamento final do projeto. 
 
2. Necessidade de suporte pela organização 
Outros setores não ligados ao projeto, conforme possíveis necessidades, 
poderão ser acionados para apoiar em questões fora do escopo de nosso 
departamento (Dp Jurídico, Dp Recursos Humanos, Dp Contabilidade, ...) 
 
3. Controle e gerenciamento das informações do projeto 
1) Ata oficial de atividades da empresa 
2) Controle de projetos do Dp de Desenvolvimento 
3) Ferramenta Redmine 
4) Mural aberto da equipe 
5) Email semanal de interação dos DPs 
33 
 
 
Data Modificado por Descrição da mudança 
 
 
IX - Registro de alterações 
 
 
15/10/2020 Tiago Lucas Cliente desistiu de ter reserva de carro. 
15/10/2020 Tiago Lucas Cliente desistiu de ter controle de revisão. 
 
 
X - Autorizações 
 
 
 
Belém, 09 de 08 de 2020. 
 
 
 
 
 
 
 
 
 
 
 
Fabio Gandolfo 
Diretor Administrativo 
34 
 
 
 
 
3.1.2 Modelo Cascata 
Devido à sua simplicidade para o fácil entendimento do cliente o foi optado o 
Cascata um modelo de processo para desenvolvimento de softwares, que supõe um 
início e fim claro e determinado, assim sua estimativa precisa de custos logo no 
início, fatores bastantes importantes na conquista do cliente. 
Problemas podem ocorrer, quando o cliente, após esperar até o fim do 
processo de desenvolvimento para receber a primeira versão do sistema, pode não 
concordar com ela. Apesar de cada fase terminar com uma documentação aprovada, 
certamente haverá lacunas devido a requisitos mal descritos pelo cliente, não 
entendido pelo analista ou por mudança de estratégia de negócio na empresa que 
exija adaptações nos requisitos. O modelo Cascata não prevê revisão de fases. 
Assim, o risco de desenvolvimento se torna muito alto, principalmente para 
sistemas de maior porte e complexos, afinal o modelo cascata pressupõe uma 
estática realidade bem comparada a uma linha de produção fabril. 
Por outro lado, o modelo cascata adéqua-se bem como um submodelo para 
outros modelos. 
 
3.1.3 Engenharia de Sistemas 
Avaliar quais as principais medidas para garantir a segurança no processo e 
escolha das tecnologias a serem adotadas, além dos métodos a serem seguidos. 
 
3.1.4 Análise de Sistemas 
A partir da solicitação do projeto acadêmico, efetuamos uma análise do 
produto final desejado, quais dificuldades possíveis para impedimento tanto no 
desenvolvimento quanto na satisfação do cliente (UNIP) no momento da 
apresentação do software. 
 
3.1.5 Projeto 
O projeto do Software Locadora de Veículo, foi planejado para ser 
desenvolvido no ciclo de vida em cascada, que tem o grande mérito de ser o primeiro 
a impor o planejamento e o gerenciamento ao processo de software, que antes era 
casual. 
Como o modelo escolhido durante a análise do sistema o desenvolvimento foi 
o cascata, portanto, o projeto terá muita ênfase ás fases de análise e projeto antes 
35 
 
 
 
 
de partir para a programação, a fim de que o objetivo do software esteja bem definido 
e que sejam evitados erros. 
 
3.2 Cenário 
Uma locadora de veículos necessita de um sistema para facilitar o 
atendimento a seus clientes e tornar os processos realizados na empresa mais 
ágeis. A empresa é composta por funcionários e mecânicos na qual são prestadores 
de serviço, clientes e veículos para locação. A empresa pretende expandir seus 
negócios futuramente más ainda não possui nenhuma filial. É importante que o 
sistema esteja preparado para atender futuras necessidades de expansão. 
Para controle dos funcionários o sistema precisa registrar os dados do 
funcionário como cpf, nome, rg, endereço do funcionário, telefone, sexo e data de 
nascimento. Nos dados do funcionário deve ter um campo para informar qual a 
empresa responsável pela sua contratação. 
Clientes a serem gerenciados devem ser do tipo pessoa física e pessoa 
jurídica, para pessoa física deve ser informado nome, sexo, CPF, RG, data 
nascimento, dados da CNH e endereço. Para pessoa jurídica deve ser registrado 
nome fantasia, razão social, CNPJ, I.E e endereço do cliente e seus respectivos 
cadastros de pessoa física para vincular ao cliente pessoa jurídica. 
A frota da empresa deve ter as informações de placa do veículo, marca, 
modelo, ano do modelo, ano da versão, chassi, cor, combustível, quilometragem e 
tipo de câmbio. O carro deve possuir sua lista de acessórios para complementar o 
veículo e facilitar a consulta do veículo no perfil desejável pelo cliente. A empresa só 
compra carros com 4 portas, não necessitando a informação registrada da mesma. 
O sistema deve informar quais carros estão disponíveis para locação, quais estão 
em negociação para venda ou já foi vendido. 
Na locação o cliente deve escolher o veículo, informar a quantidade de dias 
na qual ficará com o veículo. O cliente só poderá efetuar a locação de um veículo 
por vez, não existindo a possibilidade de existem mais de um veículo alugado em 
seu nome ao mesmo tempo. Após selecionar o veículo deve ser registrado 
quilometragem inicial do veículo na locação ou seja a quilometragem atual do veículo 
e no ato da entrega deve ser registrado a quilometragem final ou seja a 
quilometragem no momento da entrega. O pagamento do aluguel será a quantidade 
de dias vezes o valor da diária. 
36 
 
 
ID 
RF001 
Nome 
Manter empresa 
Descrição Dep. 
Menu “Empresa” para gerenciar as 
empresas com os sub-itens Inserir empresa, 
Editar empresa, Remover empresa e 
 
 
A frota não pode ser disponibilizada para locação quando o veículo 
ultrapassar os 80.000 km rodados ou 4 anos de uso. 
3.3 Levantamento de requisitos 
O levantamento ou captura de requisitos consiste em descobrir, junto ao 
cliente, quais são as características necessárias ao sistema. Existem diversas 
técnicas que podem ser utilizadas. Uma das mais básicas e intuitivas é a entrevista.Inicialmente foi levantado os requisitos de forma projetista para o sistema da 
Locadora de Veículos, com objetivo de mostrar ao programador como deverá ser o 
funcionamento do mesmo, indicando o processo, as dependências e regras de 
negócio. 
 
3.3.1 Requisitos funcionais 
São requisitos diretamente ligados a funcionalidade do software, descrevem 
as funções que o software deve executar. 
 
 
 
 
 
 
 
 Consultar empresa 
RF002 Inserir empresa Inserir empresas filiais RF001 
RF003 Editar empresa Editar dados das empresas, buscando a RF001 
 empresa a partir de seu cnpj ou id da 
 empresa 
RF004 Remover Remover empresa do sistema RF001 
 empresa 
RF005 Consultar Listar as empresas cadastradas RF001 
 empresas 
RF006 Manter 
funcionário 
Menu “Funcionário” para gerenciar os 
funcionários com sub-itens Inserir 
RF001 
 funcionário, Editar funcionário e Consultar 
 funcionário 
RF007 Inserir funcionário Inserir funcionário no sistema, registrando RF006 
 ele em uma empresa 
37 
 
 
 
 
RF008 Editar funcionário Editar dos do funcionário no sistema, RF006 
 buscando funcionário a partir do seu cpf ou 
nome ou id do funcionário 
 
RF009 Remover Remover o funcionário do sistema caso não RF006 
 funcionário haja nenhuma dependência dele no sistema 
RF010 Consultar Lista os funcionários cadastrados na RF006 
 funcionário empresa, com opção de busca a partir do 
 nome ou cpf ou id do funcionário ou id da 
empresa 
 
RF011 Manter frota Menu “Frota” para gerenciar as frotas da 
empresa com sub-itens Inserir frota, Editar 
RF001 
 frota, Remover frota e Consultar frota. 
RF012 Inserir frota Inserir o veículo para empresa na qual RF011 
 pertence 
RF013 Editar frota Editar dados do veículo buscando o veículo RF011 
 a partir da placa 
RF014 Remover frota Remover veículo da empresa caso não haja RF011 
 nenhuma dependência dele no sistema 
RF015 Consultar frota Lista os veículos cadastrados na empresa RF011 
 com opção de busca a partir da placa ou 
empresa ou status do veículo (disponível, 
 
 negociação e vendido) 
RF021 Manter cliente Menu “Cliente” para gerenciar clientes com RF001 
 sub-itens Inserir cliente, Editar cliente e 
 Remover cliente 
RF022 Inserir cliente Inserir cliente para empresa RF021 
RF023 Editar cliente Editar cliente a partir do cpf do cliente RF021 
RF024 Remover cliente Remover cliente caso não haja nenhuma RF021 
 dependência dele no sistema 
RF025 Consultar cliente Consultar clientes a partir da empresa ou cpf RF021 
 ou nome 
RF026 Manter locação Menu de “Locação” com sub-item Locar RF001 
 Veículo 
38 
 
 
 
 
RF027 Locar Veículo Realizar a locação do veículo ao cliente RF026 
RF028 Consultar 
Locação 
Consultar as locações já realizadas com 
filtros a partir da empresa ou cpf do cliente 
ou placa do veículo ou data inicial e final para 
período de locação 
Tabela 02 – Requisitos funcionais 
RF026 
 
3.3.2 Requisitos não funcionais 
São requisitos que expressam condições que o software deve atender ou 
qualidades específicas que o software deve ter. Em vez de informar o que o sistema 
fará, os requisitos não-funcionais colocam restrições no sistema. 
ID Descrição Dep. 
RNF001 Desenvolver o software na plataforma java em sua versão 7 ou 
superior 
RNF002 O software deve rodar nas plataformas Linux e Windows 
Tabela 1 - Requisitos não funcionais 
 
 
3.4 Regras de negócio 
Conhecer bem o negócio é fundamental para o sucesso no desenvolvimento 
do sistema, ter as definições de regras bem elaboradas e documentadas dá 
credibilidade e segurança no desenvolvimento e manutenção do software. Em nosso 
projeto as regras de negócios determinam como a locadora funciona, o que dever 
ser feito e como deve ser feito. A capacidade de coletar dados, interpretá-los e agir 
com base neles, rapidamente, pode diferenciar vencedores de perdedores, em um 
mercado altamente competitivo. Isso pode determinar um fator de sucesso não 
somente para o software más também para o negócio do cliente. 
ID Descrição Req. 
RN001 Usuário com função diferente de administrador não poderá 
exibir esse menu 
RN002 A empresa deve ser cadastrada com cnpj e o id da empresa 
deve ser gerado automaticamente 
RN003 Não deve ser permitido a alteração do cnpj da empresa nem id 
apenas o nome de referência da empresa 
RF001 
 
RF002 
 
RF003 
39 
 
 
 
 
RN004 Caso haja alguma dependência de dados da empresa 
cadastrada no sistema a mesma não deve permitir sua exclusão 
RN005 Usuário com acesso diferente de administrador poderá exibir 
apenas o menu de funcionário com sub menu consultar 
RN006 Deve ser validado o cpf do funcionário antes de inserir ele no 
sistema 
RN007 Caso haja alguma dependência de dados do funcionário no 
sistema, não deve ser permitido sua exclusão 
RN008 Usuário com acesso de administrador acessa todos os menus 
de frota, outro tipo de acesso exibe frota com sub-item apenas 
para consulta 
RN009 Caso haja alguma dependência de dados da frota cadastrada 
no sistema a mesma não deve permitir sua exclusão 
RN010 Usuário com acesso diferente de administrador poderá exibir 
apenas o menu de funcionário com sub menu consultar 
RN011 Usuário com acesso diferente de administrador poderá exibir 
apenas o menu de funcionário com sub menu consultar 
RF004 
 
RF006 
 
RF007 
 
RF009 
 
RF011 
 
 
RF014 
 
RF016 
 
RF021 
RN012 Deve ser validado o cpf do cliente antes de inserir ele no sistema RF022 
RN013 Caso haja alguma dependência de dados do cliente no sistema 
a mesma não deve permitir sua exclusão 
RN014 Usuário com acesso diferente de administrador poderá exibir 
apenas o menu de “Locação” com sub menu “Consultar 
Locação” 
RN015 Caso o veículo selecionado esteja com mais de 80.000 km 
rodados não será possível efetuar a locação, caso o veículo 
tenha mais de 4 anos de uso não será possível efetuar a 
locação. 
RF024 
 
RF026 
 
 
RF027 
 
Tabela 04 – Regras de negócio 
Impresso por Jhessy, CPF 033.815.112-54 para uso pessoal e privado. Este material pode ser protegido por direitos autorais e não pode 
ser reproduzido ou repassado para terceiros. 26/10/2020 11:44:46 
40 
 
 
 
 
3.5 Modelagem de software 
 
3.5.1 Casos de uso 
Os casos de uso são uma técnica criada que definiram a UML e o 
UnifiedProcess, usada para documentar os requisitos funcionais de um sistema. Um 
caso de uso, basicamente, consiste na descrição da interação entre um usuário 
(mais precisamente um ator, como veremos adiante) e o sistema, com o intuito de 
prover a funcionalidade solicitada. Esta descrição é feita indicando sequências de 
passos seguidos durante a interação. Cada uma dessas sequências é tipicamente 
chamada de cenário. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Tabela 05 – Casos de uso 
Nome Atores 
Manter empresa Funcionário 
Manter cliente Cliente, 
funcionário 
Manter frota Funcionário 
Manter proteção Funcionário 
Manter locação Funcionário 
Descrição 
Ator funcionário gerencia a empresa inserindo, 
editando, removendo e consultando 
Ator cliente interage com o funcionário no perfil 
de atendente onde a mesma mantem o cliente 
inserindo, editando, removendo e consultado 
Ator funcionário gerencia a frota inserindo, 
editando, removendo e consultando 
Ator funcionário gerencia as proteções possíveis 
para os veículos: inserindo, editando, removendo 
e consultando 
Ator funcionário gerencia a locação inserindo, 
editando removendo e consultado 
41 
 
 
 
 
3.5.2 Diagrama de Caso de uso 
Esse diagrama documenta o que o sistema faz do ponto de vista do usuário. 
Em outras palavras, ele descreve as principais funcionalidades do sistema e a 
interação dessas funcionalidades com os usuários do mesmo sistema. Nesse 
diagrama não nos aprofundamos em detalhes técnicos que dizem como o sistema 
faz. 
 
Figura 1 - Caso de uso 
42 
 
 
 
 
3.5.3 Documentaçãode casos de uso 
Precisamos ir além do diagrama de casos de uso para descrever os cenários 
de interação com os atores. 
Caso de uso Manter Empresa 
Caso de uso geral Inserir, alterar, excluir e consultar 
Ator Principal Funcionário 
Atores Secundários 
Pré-condição Está logado no sistema 
Fluxo Normal Inserir 
Informar dados da empresa. 
Confirmar inclusão. 
Alterar 
Informar cnpj da empresa ou id da empresa. 
Alterar dados. 
Confirmar alteração. 
Remover 
Informar id da empresa. 
Confirmar exclusão. 
Consultar 
Listar dados da empresa. 
Fluxos Excepcionais Empresa já cadastrada no sistema 
Pós-condição Inserir 
Inclusão efetuada com sucesso. 
Editar 
Alteração efetuada com sucesso. 
Remover 
Empresa removida com sucesso. 
Tabela 2 - Documentação do caso de uso Manter Empresa 
 
Caso de uso Manter Cliente 
Caso de uso geral Inserir, alterar e consultar 
Ator Principal Funcionário 
Atores Secundários Cliente 
Pré-condição Está logado no sistema 
43 
 
 
 
 
Fluxo Normal Inserir 
Informar dados do Cliente. 
Confirmar inclusão. 
Alterar 
Informar o Cliente. 
Alterar dados. 
Confirmar alteração 
Consultar 
Listar dados do Cliente 
Fluxos Excepcionais Cliente já cadastrado no sistema. 
1.A Informe um novo CPF/CNPJ do Cliente. 
1.B Confirmar Cadastro. 
Não é permitido remover o cadastro do cliente. 
 
 
Pós-condição Inserir 
Inclusão efetuada com sucesso 
Alterar 
Alteração efetuada com sucesso 
 
Tabela 3 - Documentação do caso de uso Manter Cliente 
Caso de uso Manter frota 
Caso de uso geral Inserir, alterar, remover e consultar 
Ator Principal Funcionário 
Atores Secundários 
Pré-condição Está logado no sistema 
Fluxo Normal Inserir 
Informar dados do veículo. 
Confirmar inclusão. 
Alterar 
Informar a placa do veículo. 
Alterar dados. 
Confirmar alteração. 
44 
 
 
 
 
Remover 
Informar id do veículo 
Confirmar exclusão 
Consultar 
Listar veículos 
Fluxos Excepcionais Veículo já cadastrado. 
Cadastro não pode ser removido. 
Pós-condição Inserir 
Inclusão efetuada com sucesso. 
Alterar 
Alteração efetuada com sucesso. 
Remover 
Remoção efetuada com sucesso. 
Tabela 4 - Documentação do caso de uso Manter Frota 
Caso de uso Manter locação 
 
geral 
Caso de uso Inserir e Consultar 
Ator Principal Funcionário 
Atores 
Secundários 
Cliente 
Pré-condição Esta logado no sistema 
Fluxo Normal  Inserir 
1. Incluir dados da locação. 
2. Confirmar locação do cliente. 
 Consultar 
1. Listar dados da locação. 
Fluxos 
Excepcionais 
1. Não é possível excluir locação. 
2. Cliente já possui uma locação em aberto. 
3. Não é possível alterar dados. 
Pós-condição  Inserir 
1. Inclusão efetuada com sucesso. 
Tabela 5 - Documentação do caso de uso Manter Locação 
45 
 
 
 
 
3.5.4 Diagrama de classe 
O principal objetivo da análise de sistemas é realizar um mapeamento prévio 
do comportamento requerido para os elementos de modelagem no sistema a serem 
implementados posteriormente nas fases de construção. Durante as etapas iniciais 
de um projeto, é comum realizarmos um refinamento nos detalhes e na precisão do 
“desenho do sistema” a fim de conseguir classes de análise que possam evoluir 
antes de serem detalhadas durante as atividades de especificação e implementação. 
O diagrama de classes é considerado por muitos autores como o mais 
importante e o mais utilizado diagrama da UML. Seu principal enfoque está em 
permitir a visualização das classes que irão compor o sistema com seus respectivos 
atributos e métodos, bem como em demonstrar como as classes do sistema se 
relacionam, se complementam e transmitem informações entre si. 
Figura 2 - Diagrama de classes 
46 
 
 
 
 
3.5.5 Diagrama de Sequência 
Diagramas de Sequência são muito úteis em fornecer suporte real à 
implementação e em constituir rica documentação de alto nível. Eles representam 
os objetos participantes de uma colaboração enquanto emitem e recebem 
mensagens no intuito de realizar um caso de uso. As mensagens são apresentadas 
em sua ordem temporal, o que facilita a compreensão do fluxo de controle do caso 
de uso. 
A maior dificuldade associada à sua criação parece estar relacionada ao grau 
de detalhamento a ser aplicado a esses diagramas. Mas pode-se adotar uma 
perspectiva prática para criação de uma documentação realmente útil, e que não se 
torne uma tarefa ainda mais árdua do que a própria codificação do sistema. 
Diagramas de Sequência são muito úteis em fornecer suporte real à 
implementação e em constituir rica documentação de alto nível. Eles representam 
os objetos participantes de uma colaboração enquanto emitem e recebem 
mensagens no intuito de realizar um caso de uso. As mensagens são apresentadas 
em sua ordem temporal, o que facilita a compreensão do fluxo de controle do caso 
de uso. 
A maior dificuldade associada à sua criação parece estar relacionada ao grau 
de detalhamento a ser aplicado a esses diagramas. Mas pode-se adotar uma 
perspectiva prática para criação de uma documentação realmente útil, e que não se 
torne uma tarefa ainda mais árdua do que a própria codificação do sistema. 
 
Funcionário: Inserir funcionário 
 
Figura 3 - Diagrama de sequência "Inserir funcionário" 
47 
 
 
Figura 4 - Diagrama de sequência "Editar funcionário" 
Funcionário: Remover funcionário 
Figura 5 - Diagrama de sequência "Remover funcionário" 
Veículo: Inserir 
 
 
Funcionário: Editar funcionário 
 
Figura 6 - Diagrama de sequência "Inserir veículo" 
48 
 
 
Figura 7 - Diagrama de sequência "Editar veículo" 
Veículo: Remover 
Figura 8 - Diagrama de sequência "Remover veículo" 
Cliente: Inserir cliente 
 
 
Veículo: Editar 
 
Figura 9 - Diagrama de sequência "Inserir cliente" 
49 
 
 
Figura 10 - Diagrama de sequência "Editar cliente" 
Cliente: Remover cliente 
Figura 11 - Diagrama de sequência "Remover cliente" 
Locação: Efetuar Locação 
 
 
Cliente: Editar cliente 
 
Figura 12 - Diagrama de sequência "Efetuar locação" 
50 
 
 
 
 
Locação: Finalizar Locação 
 
Figura 13 - Diagrama de sequência "Finalizar locação" 
51 
 
 
 
 
3.5.6 Diagrama de Pacotes 
 
O Diagrama de pacotes, ou diagrama de módulos, definido pela UML 
descreve os pacotes ou pedaços do sistema divididos em agrupamentos lógicos 
mostrando as dependências entre estes, ou seja, pacotes podem depender de 
outros pacotes. Este diagrama é muito utilizado para ilustrar a arquitetura de um 
sistema mostrando o agrupamento de suas classes. 
Em muitos casos um único diagrama de classes pode ser exageradamente 
grande para representar todo o sistema. Assim é conveniente utilizar-se de um 
elemento para organizar os subsistemas do modelo. Para isto utilizam-se os 
diagramas de pacote. Um pacote representa um grupo de classes (ou outros 
elementos) que se relaciona com outros pacotes através de uma relação de 
dependência. Um diagrama de pacotes pode ser utilizado em qualquer fase do 
processo de modelagem e visa organizar os modelos. 
O pacote é o elemento básico organizador de um modelo de sistema UML. É 
possível considerar o sistema todo como um pacote que contém todos os outros 
pacotes, diagramas e elementos. Um pacote pode conter pacotes subordinados, 
diagramas ou elementos únicos e é possível definir a visibilidade de um pacote bem 
como a visibilidade dos elementos contidos nele. 
Um diagrama de pacotes mostra pacotes e relações entre pacotes. Na 
realidade, não existem propriamente diagramas de pacotes em UML; em vez disso, 
pacotes e relações entre pacotes aparecem noutros diagramas, de acordo com o 
tipo de pacote. 
Uma vez que representa um agrupamento, um pacote é em geral dono de 
diversos elementos: classes, interfaces, componentes, nós, colaborações, casos de 
uso, diagramas, e até outros pacotes. 
Na figura abaixo o pacote de classes das janelas que cuida da interface da 
aplicação dependente funcionalmente das classes de negóciopara cumprirem suas 
atividades. 
52 
 
 
 
 
 
 
Figura 14 - Diagrama de pacotes 
53 
 
 
 
 
3.5.6 Diagrama de Máquina de Estado 
 
O diagrama de máquina de estados era conhecido nas versões anteriores 
como diagrama de estados, tendo então mudado para este novo nome após a 
versão 2.0 da UML. Este diagrama procura acompanhar as mudanças sofridas nos 
estados de uma instância de uma determinada classe. 
Através de sua simbologia gráfica, ele procura demonstrar o comportamento 
de um elemento por meio de transições de estado. O elemento modelado muitas 
vezes é uma instância de uma classe, no entanto, pode se usar esse diagrama para 
modelar o comportamento de um caso de uso, o comportamento de um dado durante 
uma transação ou mesmo o comportamento de um sistema completo – neste caso 
estaremos considerando o caso de uso ou o sistema como objetos. 
O diagrama de máquina de estados é um dos diagramas disponíveis na UML 
para a modelagem dos aspectos dinâmicos de sistemas. Assim como o diagrama de 
sequência, o diagrama de máquina de estados muitas vezes baseia-se em um caso 
de uso descrito em um e apoia-se no diagrama de classes. 
Figura 15 - Diagrama máquina de estados 
54 
 
 
 
 
3.5.7 Diagrama de Comunicação 
 
O Diagrama de comunicação é definido pelo 
UML(UnifiedModelingLanguage). O Diagrama de Comunicação exibe uma 
interação, consistindo de um conjunto de objetos e seus relacionamentos, incluindo 
as mensagens que podem ser trocadas entre eles. O diagrama de sequência e de 
colaboração são isomórficos. 
O diagrama de comunicação mostra, de maneira semelhante ao diagrama de 
sequência, a colaboração dinâmica entre os objetos. Se a ênfase do diagrama for o 
decorrer do tempo, é melhor escolher o diagrama de sequência, mas se a ênfase for 
o contexto do sistema, é melhor dar prioridade ao diagrama de colaboração. O 
diagrama de colaboração é desenhado como um diagrama de objeto, onde os 
diversos objetos são mostrados juntamente com seus relacionamentos. 
O Diagrama de Comunicação dá ênfase à ordenação estrutural em que as 
mensagens são trocadas entre os objetos de um sistema. 
Figura 16 - Diagrama de comunicação 
55 
 
 
DESENVOLVIMENTO DE UM SISTEMA PARA LOCADORA DE VEÍCULOS 
TERMO DE ENCERRAMENTO 
Preparado por Carlos Alberto de Oliveira 
Aprovado por Daniel Fernandes 
Versão 1.0 
09/12/2020 
 
 
3.6 Termo de encerramento do projeto 
 
 
XI - Título do projeto 
Desenvolvimento de um sistema para locadora de veículos 
 
XII - Considerações finais 
Pelo presente termo damos por encerrado o Projeto Desenvolvimento de um 
sistema para locadora de veículos atestando que todas as solicitações constantes 
da Ordem de Serviço 001 foram plenamente atendidas. 
56 
 
 
 
 
XIII - Autorizações 
 
Belém, 12 de Outubro de 2020 
 
 
 
 
 
 
 
 
 
 
Aldir Origuela França 
Presidente/Diretor 
 
 
 
 
João Everton de Araújo Melo 
Vice Presidente/Diretor 
 
 
 
 
Tiago Lucas Rodrigues da Silva 
 
Gerente do Projeto 
 
 
 
Nota: Quaisquer alterações neste documento deverão ser submetidas ao processo de controle de projeto para 
aprovações antes de serem incorporadas a este documento. 
57 
 
 
 
 
4 CONSIDERAÇÕES FINAIS 
O objetivo do Projeto Integrado Multidisciplinar IV é transforma a teoria 
aprendida em sala de aula para pratica, devido ao nível de conhecimento estar mais 
avançado a exigência e expectativa é maior. Para um resultado mais completo e 
coerente com o nível na qual se encontramos é necessário bem mais dedicação e 
pesquisas. 
Mantendo a forma simples e objetiva, foi possível estar aplicando a teoria e 
pratica simultaneamente, formando o resultado de um software para uma Locadora 
de Veículos na qual consegue atender as necessidades fundamentais de qualquer 
cliente. 
 
4.1 Aprendizado Adquirido. 
O projeto proporcionou a oportunidade do grupo desenvolver a habilidade de 
Análise, seguindo todas as etapas da mesma, além de fazer a iteração da equipe 
compartilhando conhecimentos técnicos adquiridos ao longo desse projeto. Por fim 
o resultado final da análise foi bem satisfatório, pois o grupo conseguiu atingir o 
objetivo pretendido. 
58 
 
 
 
 
5 REFERÊNCIAS BIBLIOGRÁFICAS 
 
ABLA, Associação Brasileira de Locadoras de Automóveis. Empregos e tributos. 
São Paulo, 2020. Disponível em: <http://www.abla.com.br/setor-de- 
locacao/principais-indicadores/empregos-e-tributos/>. 
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J.UML- guia do usuário. 2. ed. Rio de 
Janeiro, Campus, 2006. 
BOOKMAN, Utilizando UML e padrões - Uma introdução a análise e ao projeto 
orientados, 2007. 
CIÊNCIA MODERNA, Engenharia de Software: Análise e Projeto de Sistema, 2008. 
DEITEL, Java - Como Programar HARVEY M. DEITEL & PAUL J., 2010. 
Guia PMBOK 4a edição; 
MARQUES, P.; PEDROSO, H. C# 2.0. Rio de Janeiro: LTC, 2007. 
MARTINS, J. C. C. Gerenciando projetos de desenvolvimento de software com PMI, 
RUP e UML. 4. ed. Rio de Janeiro: Brasport, 2007. 
MARTINS, J. C. C. Técnicas para gerenciamento de projetos de software. Rio de 
Janeiro: Brasport, 2007. 
SHARP, J. Microsoft visual C# 2008 passo a passo. Porto Alegre, Bookman, 2008. 
SCHMITZ, E. A.; ALENCAR, A. J.; VILLAR, C. B. Modelos qualitativos de análise 
de risco para projetos de tecnologia da informação. Rio de Janeiro: Brasport, 2007. 
VARGAS, R. V. Gerenciamento de projetos. 6. ed. Rio de Janeiro: Brasport, 2005. 
VAZQUEZ, C. E.; SIMÕES, G. S.; ALBERT, R. M. Análise de pontos de função: 
medições, estimativas e gerenciamento de projetos de software. 3. ed. São Paulo: 
Érica, 2003. 
Autor(es). Título da página [Internet]. Lugar de publicação: editor; data de publicação 
do site [data da revisão/atualização d a página; citado em data da citação]. 
Disponível em: endereço eletrônico da página (URL). 
http://www.abla.com.br/setor-de-
http://www.abla.com.br/setor-de-
 
 
 
 
UNIP INTERATIVA 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
PIM VIII - APLICAÇÃO WEB PARA TAREFAS ACADÊMICAS EM ASP.NET 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Unidade Nazaré 
2020 
 
 
 
 
UNIP INTERATIVA 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
PIM VIII - APLICAÇÃO WEB PARA TAREFAS ACADÊMICAS EM ASP.NET 
 
 
 
 
 
 
 
Aluno: Erick Patrik Alves da Fonseca 
UP: 19222259 
Curso: Tecnologia em Análise e 
Desenvolvimento de Sistema 
4o Semestre 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Unip – Nazaré 
 2020 
 
 
 
 
RESUMO 
 
A estrutura do sistema de tarefas acadêmicas foi desenvolvida em ASP.NET, 
permitindo uma maior aplicabilidade para a web e, assim, garantindo a sua 
funcionalidade a partir de estruturas comuns e de fácil acesso. O sistema foi projetado 
para atuar como uma agenda, com opções de modificação de datas, adição de 
informações como nome e a descrição da tarefa ambientada. Toda a sua estrutura 
possui conceitos que foram exigidos em seu escopo, observando a estrutura analítica 
de um projeto, o seu cronograma, o seu plano de risco e a observação dos padrões 
de qualidade que foram observados e esperados dentro do projeto, permitindo a sua 
usabilidade pelos clientes. 
Palavras-chave: tarefa, agenda, sistema, aplicabilidade, qualidade. 
 
 
 
 
ABSTRACT 
 
The structure of the academic task system was developed in ASP.NET, allowing 
greater applicability to the web and thus ensuring its functionality from common 
structures and easy access. The system is designed to act as a schedule, with options 
for modifying dates, adding information such as name and the description of the task 
set. All of its structure has concepts that were required in its scope, observing the 
analytical structure of a project, its schedule, its risk plan and the observation of the 
quality standards that were observed and expected within the project, allowing its 
usability customers.Keywords: task, agenda, system, applicability, quality. 
 
 
 
 
SUMÁRIO 
1. INTRODUÇÃO ................................................................................................. 05 
2. DESENVOLVIMENTO ..................................................................................... 06 
2.1 – ESCOPO DO PROJETO ............................................................................. 06 
2.2 – EAP – ESTRUTURA ANALÍTICA DE PROJETOS ................................... 08 
2.2.1 – EAP INDENTADA .................................................................................... 07 
2.3 – CRONOGRAMA DO PROJETO.................................................................. 11 
2.4 – PLANO DE RISCO ...................................................................................... 13 
2.5 – PADRÕES DE QUALIDADE ESPERADOS ............................................. 14 
2.6 – MANUAL DO USUÁRIO ...............................................................................15 
3. CONCLUSÃO .................................................................................................. 23 
4. REFERÊNCIAS ............................................................................................... 24 
 
5 
 
INTRODUÇÃO 
 
O sistema a ser desenvolvido deve ser baseado em uma aplicação web, com 
o intuito de gerenciar atividades acadêmicas, como trabalhos, provas, atividades 
extracurriculares e complementares e vários outros modelos de usabilidade. Assim, 
sendo aplicados para o desenvolvimento de uma estrutura baseada em uma agenda. 
A aplicação web, estruturada em ASP.NET, deve ser gerenciada desde a sua 
definição, assim, garantindo a sua completude e correta funcionalidade ao final do 
projeto. Isso pode ser caracterizado como a sua estruturação analítica, fomentando o 
seu escopo, o projeto, o cronograma do projeto, o plano de risco e os padrões de 
qualidade que devem ser esperados dentro da estrutura. 
Inicialmente, o sistema web em ASP.NET deve ser capaz de permitir o cadastro 
das tarefas, ainda com a opção de excluir e alterar cada tarefa, incluindo a 
característica de manutenção da data limite para a realização da tarefa adicionada. 
Esse sistema, também, deve englobar um banco de dados, a fim de manter toda a 
informação adicionada. 
 
 
6 
 
2. DESENVOLVIMENTO 
 
2.1 – Escopo do Projeto. 
 
O escopo do projeto é uma das partes essenciais da estrutura de um sistema. 
Isso, pois ele engloba o conceito das funcionalidades existentes no sistema, 
especificando o que deve haver em todo o projeto, garantindo ao desenvolvedor a 
observância do que deve existir no sistema final. 
As definições do projeto ficaram definidas em alguns pontos, como estão 
apresentados a seguir, em toda a sua estrutura e existência a ser aplicada ao 
desenvolvimento do projeto. 
 O sistema deve ser desenvolvido em ASP.NET. 
 O sistema deverá possuir banco de dados desenvolvido em Microsoft Access. 
 O sistema desenvolvido deve ser uma aplicação Web. 
 O sistema deverá permitir o cadastro de tarefas acadêmicas. 
 O sistema deverá manter opções de exclusão e alteração de tarefas. 
 O sistema deverá exigir uma data limite para a realização da tarefa. 
 O sistema deverá possuir sistemas de alerta para quando atingir a data de 
entrega de uma tarefa adicionada. 
 
2.2 – EAP – Estrutura Analítica de Projetos. 
 
A Estrutura Analítica de Projetos ou “EAP” como e mais utilizada no cotidiano 
trata-se de uma divisão de tarefas e/ou atividades que serão realizadas dentro de um 
projeto, sendo útil a sua utilização nos mais variados tipos de projetos. 
Alto índice de aceitação deste processo se dá por razão de que os projetos são 
muitos difíceis de ser administrados, analisados e visto de uma maneira completa, 
com o uso desse processo torna-se fácil realizar tal analise e administração. 
A EAP facilita na elaboração de todas as tarefas que estão contidas no projeto, 
pelo fato dos integrantes terem uma visão completa das fases que serão realizadas e 
no decorrer do trabalho saber quais as que foram concluídas e ainda as próximas a 
ser desenvolvidas. 
 
 
7 
 
Basicamente a EAP divide todo o projeto em tópicos menores “que podem ser 
desenvolvidos separadamente”, e a partir desses tópicos são analisadas as atividades 
que serão realizadas dentro deles, formando uma espécie e hierarquia entre as 
tarefas, sendo que no mais alto nível está o projeto a ser desenvolvido e abaixo dele 
os tópicos principais, e por sua vez abaixo dos tópicos principais os subtópicos. Na 
maioria das vezes sua criação deve ser criada por meio de um fluxograma para ter 
uma maior interpretação. 
E necessário que toda a equipe do projeto far-se-á presente no momento da 
elaboração da EAP, para contribuir com sua criação. Após a feitura da EAP e o início 
das atividades do projeto poderão surgir tarefas e/ou atividades que não constam no 
rol das que estão presentes na EAP, caso isso ocorra poderá essas tarefas, se 
realmente necessárias ao projeto, serem incluídas, e por consequência fazer uma 
adequação à Estrutura Analítica do Projeto. 
Figura 1 – Sistema de Controle Acadêmico. 
Fonte: Autor, 2020. 
SISTEMA DE CONTROLE 
ACADÊMICO 
Inicialização Planejamento 
 
Fechamento 
Identificação das 
Necessidades Viabilização do 
projeto 
Codificaçao 
Aceitaçao do 
sistema 
Definiçao do 
Problema 
Criaçao da EAP Revisão do codigo 
Suporte pós- 
entrega 
Determinaçao 
dos Objetivos 
Levantamentos 
dos Riscos 
Atividades de 
implementaçao 
Requisitos de 
Qualidade 
Realização de 
testes 
Elaboração do 
Cronograma 
Validações 
 
 
8 
 
2.2.1 EAP Indentada. 
 
O Sistema de Controle engloba quatro processos, sendo o de inicialização, de 
planejamento, de execução e controle e o de fechamento. Todos eles são definidos 
em forma de garantir que a estrutura seja estruturada em consonância com a 
necessidade que é apresentada para o desenvolvimento do projeto. Segue os tópicos 
e subtópicos. 
Quadro 1 - EAP – Estrutura. 
SISTEMA DE CONTROLE ACADÊMICO 
 
INICIALIZAÇÃO 
 
IDENTIFICAÇÃO DAS NECESSIDADES 
 
DEFINIÇÃO DO PROBLEMA 
 
DETERMINAÇÃO DOS OBJETIVOS 
 
PLANEJAMENTO 
 
VIABILIZAÇÃO DO PROJETO 
 
CRIAÇÃO DA EAP 
 
LEVANTAMENTOS DOS RISCOS 
 
REQUISITOS DE QUALIDADE 
 
ELABORAÇÃO DO CRONOGRAMA 
 
EXECUÇÃO E CONTROLE 
 
CODIFICAÇÃO 
 
REVISÃO DO CÓDIGO 
 
ATIVIDADES DE IMPLANTAÇÃO 
 
REALIZAÇÃO DE TESTES 
 
VALIDAÇÕES 
 
FECHAMENTO 
 
ACEITAÇÃO DO SISTEMA 
 
INFORMAÇÕES SOBRE O PROJETO 
 
 
9 
 
Fonte: Autor, 2020. 
 
Dentro do processo de inicialização, durante a identificação das necessidades, 
estão relacionados a atividade de repasse, pelo cliente, ao gerente do projeto. Aqui, 
englobando todas as necessidades que o mesmo encontra ao realizar a tarefa, serão 
catalogadas e documentadas para passar para a fase seguinte. 
No tópico 1.2, referente a definição do problema, temos que após todas as 
necessidades serem elencadas e documentas, a equipe se reunira para definição do 
problema principal do cliente e verificar se e capaz se ser sanado. 
Dentro do ultimo tópico da inicialização, denominado determinação dos 
objetivos, está apresentada a ideia de viabilidade à atividade de criação de um 
sistema. Assim, com a ideia de sanar as necessidades do cliente e deverão ser 
determinados os objetivos para a serem alcançados com realização do projeto 
Para a etapa de planejamento, são um total de cinco tópicos. A viabilização do 
projeto apresenta a sua análise e avaliação, tanto do ponto de vista técnico e 
operacional relacionado a questões de segurança, legislação, controle, adequação da 
solução a organização, dentro outros, como também o financeiro que está mais ligada 
ao necessário para custeio de todas as etapas indispensáveis para bom sucesso do 
projeto. 
O tópico 2.2 engloba a criação da EAP, que é relacionada pela seguinte 
definição, sendo a elaboração de todasas atividades que deverão ser realizadas no 
decorrer do trabalho, desde o início até a última fase do mesmo do projeto. 
A etapa de levantamento de risco deverá identificar todos os possíveis perigos 
e ricos associados a elaboração do projeto, com isso serão adotadas medidas que 
conseguem diminuir ou aniquilar essas possíveis ameaças. 
Já em requisitos de qualidade, estão as apresentações de elaboração de todo 
um conjunto completo de requisitos que deverão ser alcançados em seus pontos 
mínimos ou máximos na realização do projeto. 
4.3 SUPORTE PÓS-ENTREGA 
 
 
10 
 
O tópico 2.5, voltado para a área de planejamento, estará designado para o 
desenvolvimento do cronograma, em que deverá ser realizado e embasado em todas 
as datas e processos administrativos e de desenvolvimento. Assim, ele deverá 
englobar as estimativas de prazos para todas as atividades que serão realizadas no 
decorrer da elaboração do sistema. 
O início do tópico 3.0 é apresentado como a execução e controle da estrutura 
de desenvolvimento do software. Dentro do seu primeiro tópico, a codificação, está a 
parte de responsabilidade grande de equipe de desenvolvedores onde será criado 
como o sistema, usando a linguagem escolhida para o projeto que e ASP.NET, com 
isso inicia-se efetivamente a construção do sistema. 
A revisão do código é essencial e ela é uma grande responsabilidade da equipe 
de desenvolvimento. É nesse momento em que deverão ser corrigidos os erros que 
possam ocorrer no código e, também, algum tipo de mudança que possa surgir em 
relação ao código. 
A fase de atividades de implementação, integrada ao tópico 3.3, basicamente 
se concentra em complicar todo o código desenvolvido para que possa realmente 
colocar o software em execução, neste momento pode surgir alguns problemas que 
serão resolvidos nas demais etapas. 
E, dentro da realização dos testes, com o sistema já todo implementado são 
iniciados os testes para verificar se o software não apresenta problema com o seu 
funcionamento. É nesta fase que serão realizados os mais diversos testes, sendo 
todos eles documentados e caso surgindo erros ou comportamentos anormais serão 
resolvidos com a equipe de desenvolvedores. 
E, dentro do processo de validação, após a gestão e realização de testes, é o 
momento em que o sistema deverá estar em acordo com o projeto apresentado. Aqui, 
serão realizadas, junto ao cliente e usuários, as validações para confirmar a sua 
confiabilidade relacionada a necessidade do cliente, e, consequentemente, receber a 
validação e confirmação do usuário quanto ao atendimento da sua solicitação. 
O tópico voltado para o fechamento do projeto engloba dois subtópicos 
essenciais, sendo a aceitação do sistema e o suporte pós entrega. Dentro da 
 
 
11 
 
aceitação, temos o sistema todo finalizado e que será entregue ao mesmo, nesta fase 
para o cliente, e que deverão ser realizados uma espécie de aceitação do projeto. 
E, a estrutura de pós entrega que é baseada no atendimento, tanto técnico 
como instrucional, para dúvidas ou problemas que poderão surgir após a entregar do 
produto ao usuário final. Este atendimento deverá ser gratuito nos primeiros 180 dias 
após a entrega e tem como uma de suas premissas à melhor satisfação ao cliente. 
2.3 – Cronograma do Projeto. 
 
O Cronograma é essencial para o sucesso de um projeto. Ele desse ser 
desenvolvido utilizando a Estrutura Analítica de Projetos (EAP) e em conjunto com a 
equipe, tendo como duração máxima para as atividades o período de cinco dias. 
Podemos observar que, na figura abaixo, temos uma ilustração de 5 atividades 
que auxiliam na criação do cronograma. Elas estão definidas como as ações de definir 
as atividades, estimar a duração de cada atividade, sequenciar as atividades, estimar 
os recursos e por fim, desenvolver o cronograma. 
Figura 2 - Criação do Cronograma. 
 
 
Fonte: Autor, 2020. 
A necessidade de definir as atividades é voltada para a utilização da EAP. Isso, 
pois é necessário que todas as atividades sejam definidas de forma satisfatória para 
o desenvolvimento do projeto. É preciso, ainda, que os objetivos a serem alcançados 
estejam alinhados com o escopo do projeto. 
A estimativa de duração das atividades recebe a sua base nas atividades 
definidas, conhecimento da equipe e informações de projetos anteriores, é preciso 
estimar em dias o tempo necessário para concluir cada atividade. 
O processo de sequenciar atividades, também, é essencial para o 
desenvolvimento do projeto e do cronograma em si. Isso, pois ele demonstra a relação 
entre as atividades, ainda com a aplicabilidade de existência ou de possuir algum tipo 
de dependência, pois isso poderá afetar o tempo de duração do projeto. 
Definir as 
atividades 
Estimar a 
duração das 
atividades 
Sequenciar 
as atividades 
Estimar os 
recursos 
Desenvolver 
o 
cronograma 
 
 
12 
 
Existem três tipos básicos de dependência, a Arbitrária, que está relacionada 
com a limitação de pessoal, a Externa, que são as atividades que afetam diretamente 
a continuidade da atividade, mesmo estando fora do projeto, e a Mandatória, que são 
a atividades que não podem ser desenvolvidas sem a conclusão de uma anterior. 
A ação de estimar recurso é essencial e deve ser aplicada, a fim de determinar 
quais e quantos recursos serão necessários para a conclusão das atividades 
estabelecidas, tanto recursos matérias quanto de pessoas. É responsabilidade do 
gerente de projetos alocar o recurso necessário para cada atividade, bem como 
estimar os valores disponíveis para o projeto. 
Figura 3 – Cronograma. 
Fonte: Autor, 2020. 
 
 
13 
 
O cronograma possui, basicamente, o propósito de estimar a duração 
das atividade do projeto, sendo elas Identificar as necessidades, definição do 
problema, determinar objetivos, viabilização do projeto, criação da EAP, levantamento 
dos riscos, requisitos de qualidade, elaboração do cronograma, codificação, revisão 
de código, atividades de implantação, realização de testes, validações, aceitação do 
sistema, informações sobre o projeto e suporte pós entrega, baseando-se na data de 
início e término de cada atividade, considerando também as limitações de recursos. 
2.4 – Plano de Risco. 
 
O planejamento de riscos em um processo de software se faz necessário por 
que além de prevenir futuros problemas, pode também fazer a diferença quanto a 
prazos e custos de um projeto. 
Em nosso projeto foi feito um planejamento de riscos em cima do escopo do 
projeto proposto abordando áreas técnicas, externas, organizacionais e de 
cronograma, a seguir vemos a tabela com os riscos identificados além de suas 
respectivas ações para contingência e demais situações: 
Figura 4 – Plano de Risco 1. 
Fonte: Autor, 2020. 
 
 
14 
 
Figura 5 – Plano de Risco 2. 
Fonte: Autor, 2020. 
 
2.5 – Padrões de Qualidade Esperados. 
 
A qualidade de software é um processo que está dentro da engenharia de 
software e pode ser descrita como uma das características desejadas do produto de 
software. É a partir desse processo que conseguimos observá-la por dentro, e a partir 
dessa área temos os padrões internacionais de qualidade de software. 
O nosso projeto deverá utilizar a ISO/IEC 9126 como referência. Ela é focada 
na qualidade do produto de software, e tem 6 áreas de características, podendo ser 
voltadas para a funcionalidade, confiabilidade, usabilidade, manutenibilidade, 
portabilidade e qualidade em uso. 
Todas essas estruturas são condizentes e podem ser aplicadas de forma a 
garantir uma maior qualidade ao sistema final. Quanto a funcionalidade, o software 
deverá ser capaz de prover tarefas para o usuário com segurança das informações. 
Assim, ele deverá se manter em uma utilização de métodos de acesso para o banco 
de dados, apresentado e desenvolvido aqui com o Microsoft Access. 
A confiabilidade está voltada para ao que o código se mantenha livre de erros.Assim, sendo capaz de evitar falhas, e, caso ocorra, ter os determinados tratamentos 
de exceção para que possa se recuperar sem ser necessário reiniciar e gerar a perca 
da informação utilizada no momento da falha. 
 
 
15 
 
Dentro da usabilidade, podemos observar que a aplicação precisa ser atraente 
e fácil de operar, sendo mantida em sua maior estruturação e garantindo a maior 
simplicidade em operação, inclusive para aqueles não conhecedores da tecnologia. 
Além de exibir alertas e correções para prevenir erros do usuário, para que os mesmos 
possam aprender enquanto utilizam o software. 
Em manutenibilidade o código deverá ser apresentado de forma indentada. 
Assim, ele deverá estar documentado e comentado, para que seja fácil fazer a 
manutenção ou encontrar possíveis erros, também para que não sofra efeitos 
colaterais da manutenção. 
Atualmente, uma das características essenciais para um projeto é a sua 
portabilidade. Dessa forma, o software será desenvolvido em uma linguagem que 
permita ser utilizado em várias plataformas(ASP.NET),e que esteja preparado caso o 
sistema que ele está hospedado precise ser trocado. 
E, quanto a sua qualidade de uso, o sistema deve apresentar uma proposta 
capaz de satisfazer as necessidades do usuário, ser eficaz, produtiva e segura para 
garantir um bom uso do mesmo. 
2.6 Manual do Usuário. 
 
Ao iniciar a aplicação a tela apresentará um resumo das tarefas cadastradas. 
Apresentando o nome da tarefa, uma descrição, data de entrega, status indicando se 
está em dia ou atrasado e as opções de atualizar e deletar a tarefa. 
Figura 4 – Início da Aplicação. 
Fonte: Autor, 2020. 
 
 
16 
 
Para cadastrar uma nova tarefa clicar no botão “Adicionar”. 
 
Figura 5 – Cadastrar. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Fonte: Autor, 2020. 
 
 
 
Abrirá a tela de adicionar com os campos Nome, Descrição e Data de entrega 
para preenchimento. 
Figura 6 – Dados Informativos de Criação. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Fonte: Autor, 2020. 
 
 
17 
 
Após o preenchimento, para inserir a tarefa clicar no botão “Inserir”, ou para 
cancelar e voltar para a tela anterior, “Cancelar”. 
Figura 7 – Inserir ou Cancelar. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Fonte: Autor, 2020. 
Ao clicar no botão “Inserir”, caso a tarefa esteja preenchida corretamente, 
aparecerá a mensagem “Tarefa inserida com sucesso”. Caso seja necessário, poderá 
incluir várias tarefas, ou então voltar para a tela inicial no botão “Voltar”. 
Figura 8 – Tarefa Inserida com Sucesso. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Fonte: Autor, 2020. 
 
 
18 
 
Caso os dados estejam incorretos, aparecerá a mensagem de erro. 
 
Figura 9 – Tipo de Dados Incompatível na Expressão de Critério. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Fonte: Autor, 2020. 
 
Para atualizar uma tarefa clicar no botão “Atualizar”. 
 
Figura 10 – Atualizar Tarefa Desejadas. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Fonte: Autor, 2020. 
 
Abrirá a tela de atualização com os campos Nome, Descrição e Data de entrega 
para preenchimento. Acima dos mesmos aparecerá os dados atuais da tarefa que 
está sendo atualizada. 
 
 
19 
 
Figura 11 – Forma de Atualização. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Fonte: Autor, 2020. 
 
Após o preenchimento, para atualizar a tarefa clicar no botão “Atualizar”, ou 
para cancelar e voltar para a tela anterior, “Cancelar”. 
Figura 12 – Adição de Nova Tarefa. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Fonte: Autor, 2020. 
 
 
20 
 
Ao clicar no botão “Atualizar”, caso a tarefa esteja preenchida corretamente, 
aparecerá a mensagem “Tarefa atualizada com sucesso”. Após atualizar poderá voltar 
para a tela inicial no botão “Voltar”. 
Figura 13 – Atualização de Tarefa com Sucesso. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Fonte: Autor, 2020. 
Caso os dados estejam incorretos, aparecerá a mensagem de erro. 
 
Figura 14 – Tipo de Dados Incompatível. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Fonte: Autor, 2020. 
 
Para deletar uma tarefa clicar no botão “Deletar”. 
 
 
21 
 
Figura 15 – Deletar Tarefa. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Fonte: Autor, 2020. 
 
Abrirá a tela de deletar com os dados Nome, Descrição e Data de entrega da 
tarefa a ser deletada. Para deletar a tarefa clicar no botão “Deletar”, ou para cancelar 
e voltar para a tela anterior, “Cancelar”. 
Figura 16 – Confirmar Ação de Deletar. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Fonte: Autor, 2020. 
 
Ao clicar no botão “Deletar” aparecerá a mensagem “Tarefa deletada com 
sucesso”. Após deletar poderá voltar para a tela inicial no botão “Voltar”. 
 
 
22 
 
Figura 17 – Tarefa Deletada com Sucesso. 
Fonte: Autor, 2020. 
 
 
23 
 
CONSIDERAÇÕES FINAIS 
 
O sistema de web desenvolvido abrange todas as necessidades e solicitações 
aplicadas ao escopo do projeto. Por consequência, o sistema está bastante completo 
e embasa todas as necessidades de um usuário acadêmico, possibilitando 
implementar todos os pontos de tarefas acadêmicas e estruturando as datas com a 
possibilidade de correção, posteriores. 
Toda a apresentação do projeto foi desenvolvida sobre conceitos de melhorias 
que pudessem aperfeiçoar e incrementar o desenvolvimento da estrutura do sistema 
web. Foi possível observar, também, o crescimento da atividade e a sequência quanto 
as informações essenciais que deveriam constar no sistema finalizado. 
Foi criado, inclusive, um manual de usabilidade do sistema, permitindo ao 
usuário a sua total compreensão e, ainda, com a inclusão de imagens, para facilitar o 
seu entendimento. Todo processo que englobe métodos de apresentação positivas, 
assim como auxílio na sua capacidade de utilização, são válidos e acrescentam a 
estrutura e imagem do sistema. 
 
 
24 
 
REFERÊNCIAS 
 
ARAÚJO NETO, Antônio Palmeira de. Empreendedorismo / Antônio Palmeira de 
Araújo Neto. - São Paulo: Editora Sol, 2013. 124 p., il. 
 
BLOG.SOFTEXPERT. Guia prático para elaborar um plano de riscos completo em 12 
etapas. Disponível em: <https://blog.softexpert.com/plano-de-riscos-completo-12- 
etapas/>. Acesso em: 19 nov. 2020. 
CRISTOVÃO, Andréa Martins. Gestão da qualidade. / Andréa Martins Cristovão. – 
São Paulo: Editora Sol, 2013. 120 p., il. 
 
GUNJI, José Cassiano Grassi. Tópicos especiais de programação orientada a objetos. 
/ José Cassiano Grassi Gunji, Salatiel Luz Marinho, Luciano Soares de Souza. – São 
Paulo: Editora Sol, 2015. 128 p., il. 
MARINHO, Salatiel Luz. Desenvolvimento de Software para Internet. / Salatiel Luz 
Marinho, - São Paulo: Editora Sol, 2015 116 p., il. 
MARINHO, Salatiel Luz. Programação Orientada a Objetos II. / Salatiel Luz Marinho. 
–São Paulo: Editora Sol, 2015, 164 p., il. 
 
RIBEIRO, André Luiz. Gerenciamento de Projetos de Software. / André Luiz Ribeiro. 
– São Paulo: Editora Sol, 2015, 176 p., il. 
 
VERSOLATTO, Fábio Rossi. Projeto de Sistemas Orientado a Objetos. / Fábio Rossi 
Versolatto. – São Paulo: Editora Sol, 2015. 152 p., il.