RELATÓRIO DA PROVA DE APTIDÃO PROFISSIONAL

PLATAFORMA PARA GESTÃO DE FROTA

Estabelecimento de Ensino: Escola Profissional de Aveiro

Curso Profissional: Técnico de Eletrónica e Telecomunicações
Júnior: Douglas, a408221, 4CZ
DE: Samuel Teixeira
Entidade Parceira: Roboplan
Período de Realização da PAP: 1 de Fevereiro de 2024 a X de xxxxxx de 2024
Ciclo de Formação: 2021-2024
Época Letiva: 2023-2024

EF.181.r1
 DEDICATÓRIA
A mim mesmo,

Dedico-te este relatório como um símbolo da minha perseverança e dedicação. As horas

de estudo, pesquisa e trabalho árduo culminaram neste projeto que representa um
marco importante em minha carreira. Que este trabalho sirva como um lembrete da
minha capacidade de superar obstáculos e alcançar os meus objetivos.

Com orgulho e reconhecimento a quem é devido também menciono Samuel Teixeira,

João Paulo dos Santos e Mykola Davydiv.

EF.181.r1
 AGRADECIMENTOS
Agradeço — mais uma vez — à Escola Profissional de Aveiro pela oportunidade que
me facultaram com a AE2EP e mesmo em diversas outras atividades promovidas pela
escola, cumpre expor o quanto isto tudo me ajudou a crescer como pessoa e
profissional. Obrigado por tudo e todos.

Agradeço ao meu ODE Samuel Teixeira por exortar-me sempre para o meu melhor,
mesmo quando falho, sem desistir. A sua orientação me ajudou a superar muitos
desafios e travas internas.

Agradeço ao meu sénior Mykola Davydiv mais uma vez pela estádia impecável ao longo
desses três anos e boa companhia e pelos ensinamentos de sua área e não só.

Agradeço ao meu coach João Paulo dos Santos por esparsos momentos em que tive a
oportunidade de absorver conhecimentos e instruir-me em como ou não executar algo.

ii

EF.181.r1
 ÍNDICE

Dedicatória .......................................................................................................................i

Agradecimentos............................................................................................................... ii

Introdução....................................................................................................................... 1

Aprendizagens mobilizadas ........................................................................................ 1

Desenvolvimento ............................................................................................................ 3

Cronograma de Execução .......................................................................................... 3

Recursos utilizados ................................................................................................... 18

Análise do processo PAP ......................................................................................... 19

Conclusão..................................................................................................................... 20

Bibliografia .................................................................................................................... 20

Anexos............................................................................................................................ A iii
Anexo I – Anteprojeto PAP ......................................................................................... A

Designação do Projeto ............................................................................................ A

Fundamentação do Projeto ..................................................................................... A

Anexo II – Plano de Conceção e Desenvolvimento .................................................... A

Tema da PAP .......................................................................................................... A

Resumo ................................................................................................................... A

Objetivos do Projeto ................................................................................................ A

Plano de Conceção e Desenvolvimento do Projeto ................................................ A

Recursos Necessários ............................................................................................ A

EF.181.r1
 INTRODUÇÃO
A Roboplan, desde que comecei a estagiar na EPEP, enfrentava uma carência de
um sistema sólido para gerir a sua frota de veículos. Anteriormente, os gestores lidavam
com documentos em papel, e os colaboradores faziam as requisições diretamente a
eles. Então, o meu sénior — Mykola Davydiv —, que estava no prenuncio de engendrar
uma aplicação que viria ser conhecida mais tarde como «Gestão de Viaturas», desafiou-
me a ajudá-lo com o seu desenvolvimento. Cumpria que a aplicação tivesse as
seguintes capacidades:

• Requisições de veículos;
• Documentações;
• Abastecimentos.
À medida que o projeto avançava outras competências foram integradas à aplicação.
Em produção a aplicação saiu-se muito bem. Junto com os gestores em momentos de
brainstorm discutíamos e ideávamos como aperfeiçoar a aplicação.
1
Soma-se que a aplicação necessitava ser migrada da plataforma — low-code —
Zoho para uma aplicação interna. Para tal, cumpria que alguém desenvolvesse a
aplicação à EPEP e foi-me oferecido a oportunidade de desenvolvê-la. Aos moldes da
aplicação «Gestão de Viaturas» desponta a nova «Gestão de Frota». Para esse efeito,
a aplicação foi desenvolvida com foco em dois campos: o back-end e o front-end,
utilizando diversas ferramentas e dois frameworks — o Laravel e o Vue.js.

APRENDIZAGENS MOBILIZADAS
Na escola, adquiri uma base sólida em conceitos fundamentais de programação
e desenvolvimento de software. Durante o meu percurso, explorei conceitos basilares
que serviram como alicerce para o meu desenvolvimento profissional. Além disso, tive
a oportunidade de mergulhar na programação em Arduino, uma plataforma de eletrónica
de código aberto e fácil utilização. Embora possa parecer distante do desenvolvimento
web, essa experiência foi valiosa, pois ajudou a fortalecer a minha lógica de
programação e a compreender os princípios fundamentais por trás do funcionamento
dos sistemas computacionais. O professor João Paulo dos Santos foi de grande ajuda
para o design do software.

EF.181.r1
 Por meio do Laravel 10, um framework PHP elegante e poderoso que simplifica
o processo de desenvolvimento de aplicações web aprendi a criar aplicações robustas,
seguras e de alto desempenho de forma eficiente. Explorei conceitos avançados como
routing, middleware, Eloquent ORM, authentication e authorization, além de utilizar
recursos poderosos como queued jobs (filas de trabalhos de segundo plano) e
agendamento de tarefas para otimizar o desempenho das minhas aplicações.Tudo sob
a alçada da arquitetura MVC (Model View Controller) que permite o desenvolvimento
descomplicado e inteligente do back-end da aplicação.

Estudei o Vue.js 3 uma poderosa ferramenta para a criação de interfaces de

usuário dinâmicas e responsivas. Através da sua abordagem reativa e baseada em
componentes, aprendi a desenvolver aplicações front-end de forma eficiente,
maximizando a reutilização de código e facilitando a manutenção do projeto. Além disso,
a integração do Vue.js com o Laravel através do Inertia proporcionou uma experiência
de desenvolvimento suave e coesa.

Estudei o Inertia.js, uma biblioteca que traz uma nova abordagem na construção 2
de aplicativos web orientados pelo servidor, denominada de «o monólito moderno».
Com o Inertia, é possível criar aplicativos single page application (SPA), totalmente
renderizados no lado do cliente, sem a complexidade dos SPAs modernos, aproveitando
os padrões já existentes do lado do servidor. Ele não requer roteamento no cliente nem
uma API separada, permitindo construir controladores e visualizações de página como
de costume, com especial integração para o Laravel e o Vue.js.

Na minha experiência na EPEP, aprofundei-me em tecnologias como Laravel

Sail e Docker para facilitar o desenvolvimento e a implantação de aplicações web.
Laravel Sail oferece um ambiente de desenvolvimento local leve e eficiente para
aplicações Laravel usando Docker. Com o Sail, aprendi a configurar rapidamente um
ambiente de desenvolvimento consistente e isolado, permitindo-me focar no
desenvolvimento da aplicação sem me preocupar com a configuração do ambiente.
Além disso, o Docker foi fundamental para simplificar o processo de desenvolvimento e
garantir a consistência do ambiente de trabalho. Através da criação de ambientes
isolados e facilmente replicáveis, aprendi a gerir de forma eficiente as dependências do
projeto e a garantir a portabilidade das aplicações desenvolvidas.

Por fim, o Postman emergiu como uma ferramenta indispensável para testar e
depurar as minhas aplicações. A sua interface intuitiva e poderosas funcionalidades
EF.181.r1
 permitiram-me automatizar testes, monitorar o desempenho das APIs e garantir a
qualidade do software desenvolvido.

DESENVOLVIMENTO
Diante o desafio oferecido a mim pela EPEP, tornei a investigar no mercado as
tecnologias que melhor se qualificavam para o que a «Gestão de Frota» cumpria ser e
que fossem descomplicadas e intuitivas na experiência de desenvolvimento (DX). Com
efeito, cheguei a conclusão de que as ferramentas que melhor me atenderiam seriam o
Laravel, o Vue.js e o Inertia.js. Prontamente, reportei ao meu sénior e o mesmo assentiu.
À título de curiosidade, na EPEP utiliza-se o Laravel numa aplicação interna que acede
a uma base de dados interna.

No que tange o back-end, o Laravel é a cabeça por detrás de tudo e arquiteto de

sua estrutura: tanto no desenvolvimento, como no produto final. O Laravel apresenta-se
como: «[…] um framework de aplicação web com sintaxe expressiva e elegante. [Que] 3
fornece uma estrutura e um ponto de partida para a criação de seu aplicativo, permitindo
que você se concentre na criação de algo incrível» (Otwell, 2023). Para o efeito ter um
ambiente de desenvolvimento consistente e isolado, permitindo-me focar no
desenvolvimento da aplicação sem me preocupar com a configuração do ambiente,
utilizei o Laravel Sail, que por detrás dos panos usa o Docker que permite a criação de
ambientes isolados e facilmente replicáveis, a fim de gerir de forma eficiente as
dependências do projeto e a garantir a portabilidade do mesmo projeto em qualquer
host.

A respeito do front-end, o Vue.js encaixou-se como uma luva relativamente ao

Laravel e à ideia da aplicação. O Vue.js apresenta-se como: «[…] uma framework
JavaScript para construção de interfaces de usuário. Ele se baseia em HTML, CSS e
JavaScript padrão e fornece um modelo de programação declarativo e baseado em
componentes que ajuda a desenvolver interfaces de usuário com eficiência, sejam elas
simples ou complexas.» (You, 2014). E para juntar esses dois extremos, desbravei o
Inertia.js, que nas palavras da ferramenta é «o monólito moderno», isto é, facilita muitos
processos de desenvolvimento que são necessários para a criação de SPAs (Inertia.Js).

Num agregado a minha PAP (Prova de Aptidão Profissional) cumpre ser

repartida em duas fases: teórica e prática. No nível teórico, no decorrer de fevereiro até
EF.181.r1
 março, estive a estudar por meio de projetos de estudo, isto é, para cada conceito de
estudo, criava do zero um projeto em Laravel através de seu instalador via composer
que é gestor de dependências de pacotes para PHP (Adermann & Boggiano). No nível
prático, estes projetos de estudo renderam-me um ótimo playground para analisar,
aprender e aprimorar. Tanto no back-end com o Laravel, como no front-end com o
Vue.js. Então, a meio do estudo destas duas tecnologias descobri uma terceira — o
Inertia.js — que permite criar SPAs sem uma API — o método convencional. Com efeito,
agilizando o desenvolvimento da renderização da aplicação e mantendo, porém, o
processo quase que o mesmo com mínimas alterações. Soma-se a tudo isto, a utilização
do Docker através de um pacote — o Laravel Sail. Com efeito, o Sail proporcionou-me,
sem estresse, integrar o meu projeto num container Docker que depois vai dar muita
segurança à EPEP para alojar a aplicação em qualquer host.

Os projetos que eu desenvolvi para estudo são nomeadamente um gestor de

ficheiros; um Gestão do Relacionamento com Clientes (Customer Relationship
Management); um Sistema de Controle de Acesso (Acess Control List); entre outros
para experimentar com bibliotecas de componentes para UI (interface de usuário) como
4
as bibliotecas shadcn-vue (Shadcn for Vue - Shadcn/Vue, 2023), Radix Vue (Haaziq,
2021) e até escolher entre JavaScript ou TypeScript. Acerca do primeiro projeto, foi o
que mais despendi tempo e recursos para fazê-lo. A seguir vem uma vista da aba
principal do gestor de ficheiros aonde mostra os ficheiros e/ou pastas:

EF.181.r1
 Este projeto é basicamente uma clone do Google Drive, onde pode-se fazer subir 5
ficheiros, pastas, pastas com pastas e/ou mais ficheiros, mantendo sua estrutura. E
depois fazer o descarregamento destes ficheiros/pastas. Ademais, quando se faz o
descarregamento de um ficheiro só é feito o download dele com o próprio ficheiro;
quando é feito dois ou mais arquivos ou pastas é comprimido num .zip com o nome do
diretório atual, por exemplo:

EF.181.r1
 Outrossim, é possível fazer o partilhamento de pastas e/ou ficheiros entre usuários. Nas
abas «Shared with Me» e «Shared by Me», respetivamente «Partilhado por mim» e
«Partilho comigo», por exemplo:

Aqui eu partilhei dois itens com o «joao.pato@sapo.pt», ele, por sua vez, pode
descarregar estes itens. Isto é a aba «Partilhado comigo», para quem partilhou os itens
poderia ver na aba «Partilhado por mim» os itens partilhados. Por fim, a aba «Trash» é
onde se aloja os ficheiros e pastas deitadas fora, sendo, porém, mantidas na lixeira até
que o usuário decida livrar-se de eles de uma vez — ou restaurá-los. Isto ocorre, porque
os arquivos/ficheiros no código têm um atributo chamado «soft delete» que permite que
estes sejam apenas filtrados da lista de ficheiros/pastas do usuário e se o mesmo
desejar pode novamente torná-los visíveis, isto é, restaurá-los.

Dentro deste primeiro projeto tive a oportunidade de aprender além de gerir

ficheiros, como também gerir roteamento e autenticação. As rotas mais básicas do

EF.181.r1
 Laravel aceitam um URI (Uniform Resource Identifier) e uma closure fornecendo um
método muito simples e expressivo de definir rotas e comportamento sem arquivos
complicados de configuração de roteamento. O Laravel categoriza as rotas em quatro
tipos principais:

• API
• Auth(entication);
• Channels;
• Console;
• Web.
Como mencionado nas aprendizagens adquiridas na EPEP, não utilizei a API, pois
o Inertia permite uma melhor integração com a web sem necessitar de utilizar APIs por
detrás. A seguir uma evidência das rotas que escrevi e também uma elaboração acerca
delas:

Como é possível constatar eu segui o padrão sugerido pelo Laravel na documentação

de como nomear as rotas e seus verbos corretas a utilizar, para as rotas convencionais:

EF.181.r1
 Depois de receber uma requisição em qualquer destas rotas a requisição é tratada no
controller, no caso no FileController.php. Por exemplo, a rota «trash» servirá para
explicar como é tratado uma requisição:
8

EF.181.r1
 É possível tratar de muitos assuntos somente neste simples trecho de código primeiro
faz-se um recuperamento do argumento na linha 3; já na linha faz-se um query de todos
os Files que estão atualmente na lixeira, a partir do método «onlyTrashed()», depois faz-
se mais alguns filtros; da linha 10 a 20 é feita a lógica para a busca, onde mediante o
que o usuário mandar como argumento na request para a busca é feito um query que
busca os registos a ver com a busca, então o resultado é paginado, isto é, divido com
xis páginas mediante o tamanho da paginação que no meu caso é 10 itens, ou seja,
numa query onde devolve-me 145 itens terei 15 páginas, 14 com 10 itens e a última com
5, e então a rol de itens é tratada por meio de um Resource que pega a query que vem
dopada de dados que, por vezes, é indesejável que o usuário tenha acesso e só passa-
se para frente os campos desejados ou datas formatadas, por exemplo. Por fim, se a
request vier pedindo JSON, ou seja, apenas dados, nada de re-renderizar a página. Fiz
isto para a ver o famoso scroll infinito, mas comum de ser visto em redes sociais, que
quanto mais descemos em busca de novo conteúdo, mais surge; caso, então, o usuário
esteja acedendo a rota «trash» pela primeira vez é-lhe renderizada a página e enviada
a query com os Files. Caso o usuário não tenha nenhum item na lixeira ou em qualquer 9
outra aba é-lhe mostrado uma mensagem de erro. Esta é tratado diretamente no front-
end, com o Vue e suas diretivas:

Neste exemplo de projeto o CRUD (Create, Read, Update, Delete) foi tratado como bem
visto antes, através das rotas juntamente com o controller:

EF.181.r1
 10

Na linha 2 os dados são validados, baseados nas condições da «FilesActionRequest»

— que basicamente diz se o usuário que fez a request pode ou não a realizar no caso
de ser dono do ficheiro; de ele existir etc. É, então, da linha 4 a 19 reside a lógica para
detectar se o ficheiro/pasta possui mais dentro de si e subsequentemente e movê-los
para a lixeira. Por fim, é redirecionado o usuário para página «MyFiles.vue» no nível de
ficheiro que ele estava, isto é, se eu estava neste caminho
«root/pessoal/epa/pap/prepartivos» quando deletei o ficheiro/pasta serei redirecionado
para lá, dando a ilusão que nem saí da página quando cliquei no botão «delete» e isso
é de certo modo como uma aplicação SPA funciona, o servidor performa chamadas nos
bastidores e para o usuário apenas clicou num botão.

No nível da base de dados tive de estudar bastante conceitos relativamente às

tabelas, as relações entre elas e como, então, integrar tudo isso ao eloquente ORM
(Object-relational Mapping) do Laravel. Este permite-me interagir com a base de dados
e suas tabelas e relações sem diretamente acedê-la, e isso torna agradável a interação
com a base de dados. Ao usar o Eloquent, cada tabela do banco de dados possui um
«modelo» (que é uma abstração) correspondente que é usado para interagir com aquela
EF.181.r1
 tabela. Além de recuperar registos da tabela do banco de dados, os modelos do
Eloquent também permitem inserir, atualizar e excluir registos da tabela. No exemplo é
possível ver um query utilizando o Eloquent ORM, onde o voo estiver ativo (1 = true,
verdadeiro), então é ordenado pelo nome e devolve-se 10 registos:

Neste projeto a autenticação foi tratada a partir do starter kit Laravel Breeze. Laravel
Breeze é uma implementação mínima e simples de todos os recursos de autenticação
do Laravel, incluindo login, registo, redefinição de senha, verificação de e-mail e 11
confirmação de senha. Além disso, o Breeze inclui uma página simples de “perfil” onde
o usuário pode atualizar seu nome, endereço de e-mail e senha.

No Controle de Acesso Baseado em Função (RBAC), as Listas de Controle de

Acesso (ACL) desempenham um papel crucial na definição de permissões para usuários
individuais. Uma ACL funciona como um mapeamento entre entidades — normalmente
usuários ou grupos — e as operações que eles estão autorizados a realizar em recursos
específicos do sistema. Imagine a ACL como uma tabela onde linhas representam
entidades e colunas representam recursos. Cada célula da tabela indica se a entidade
correspondente possui permissão para executar uma determinada operação no recurso
associado. Por exemplo, uma ACL pode permitir que o usuário «administrador» crie,
leia, atualize e exclua posts, enquanto o usuário «editor» só pode criar e editar posts.
Embora o RBAC não exija necessariamente a implementação de ACLs, elas fornecem
uma maneira granular e flexível de gerenciar permissões. Frameworks como o Laravel
oferecem pacotes para implementar RBAC com ACLs, simplificando a lógica de controle
de acesso em sua aplicação. Para ilustrar o conceito de forma prática, consideremos o
seguinte cenário: uma loja virtual com os seguintes tipos de usuários:

EF.181.r1
 • Administradores: Possuem acesso total ao sistema, incluindo a criação, leitura,
atualização e exclusão de produtos, pedidos e usuários.
• Gerentes: Podem visualizar e editar produtos e pedidos, mas não podem criar ou excluir
usuários.
• Vendedores: Podem visualizar produtos e pedidos, mas só podem editar pedidos.
• Clientes: Podem visualizar produtos e realizar compras.

Para implementar uma ACL para este cenário, podemos utilizar uma estrutura de dados
simples, como uma matriz bidimensional. As linhas da matriz representariam os tipos de
usuários, enquanto as colunas representariam as operações que cada tipo de usuário
pode realizar em cada recurso:

Tipo de Usuário Recursos Operações

Administrador Produtos Criar, Ler, Atualizar, Excluir

Administrador Pedidos Criar, Ler, Atualizar, Excluir

12
Administrador Usuários Criar, Ler, Atualizar, Excluir

Gerente Produtos Ler, Atualizar

Gerente Pedidos Ler, Atualizar

Gerente Usuários Ler

Vendedor Produtos Ler

Vendedor Pedidos Ler, Atualizar

Cliente Produtos Ler

Cliente Pedidos Criar

EF.181.r1
 Criaremos uma política «ProductPolicy» para definir as permissões de acesso aos
produtos. Arquivamos a política em «app/Policies/ProductPolicy.php»:

13

Nosso controlador de produtos pode utilizar métodos como authorize para verificar se o
usuário possui permissão para uma determinada ação:

EF.181.r1
 14

Em seu modelo de usuário, você pode definir um relacionamento com a tabela de roles
e implementar métodos para verificar se o usuário possui um determinado role:

EF.181.r1
 15

Como vimos, o Controle de Acesso Baseado em Função (RBAC) utiliza Listas de

Controle de Acesso (ACLs) para definir permissões para usuários em um sistema. O
RBAC define funções (como administrador, gerente, editor) e associa permissões a
essas funções. As ACLs mapeiam entidades (usuários ou grupos) às permissões que
elas possuem para recursos específicos do sistema. Benefícios do RBAC com ACLs:

• Segurança: Permite restringir o acesso a recursos apenas para usuários autorizados,

aumentando a segurança do sistema.
• Flexibilidade: Facilita a adição de novos usuários, funções e permissões sem afetar toda
a lógica de autorização.
• Gerenciamento Simples: Simplifica o gerenciamento de permissões para grandes
equipes de usuários.
Contudo isto é senão uma breve introdução ao assunto de authorization que estive a
aprender para pô-lo na aplicação.

EF.181.r1
 Para a principal funcionalidade da aplicação encontrei duas alternativas
concorrentes: o Vue Fullcalendar (Shaw, 2009) e o Vue Schedule-X (Österlund, 2020).
O primeiro é uma poderosa biblioteca JavaScript que oferece um componente de
calendário completo e personalizável para aplicações construídas com a framework
Vue.js. Ela falha, porém, em ser mobile-friendly, ou seja, em telas menores o calendário
não se comporta como esperado, antes como se estivesse num desktop com a tela
pequeníssima. Já o Vue Schedule-X é uma biblioteca de componentes Vue.js que
oferece uma solução elegante para a construção de calendários e agendadores de
tarefas. Com o Vue Schedule-X pude facilmente criar interfaces visuais atraentes para
gerir eventos, compromissos e horários, permitindo funcionalidades como arrastar e
largar, redimensionamento de eventos e muito mais. A sua integração perfeita com o
framework Vue torna-o numa escolha flexível e eficaz. O exemplo de um calendário no
desktop e depois no mobile:

16

EF.181.r1
 17

Para controlar todo o desenvolvimento utilizei de uma ferramenta famosa — o

Git e o Github. O último é uma plataforma online de hospedagem de código que usa o
primeiro para controle de versão. Ele permite que desenvolvedores colaborem em
projetos de software de qualquer lugar do mundo. No projeto de «Gestão de Frota», o
Git e o GitHub foram ferramentas essenciais para o desenvolvimento e a manutenção
do software. O Git forneceu controle de versionamento robusto, permitindo o
rastreamento de alterações no código, a criação de branches para testes e a fácil
reversão para versões anteriores. Através do sistema de issues, bugs e solicitações de
recursos foram facilmente registados e gerenciados. A documentação do projeto foi
centralizada no README.md, facilitando o acesso à informação para todos os
envolvidos. A combinação do Git e do GitHub proporcionou um ambiente de
desenvolvimento eficiente e profissional para o projeto de «Gestão de Frota».

Por fim, o processo de desenvolvimento foi ubérrimo tanto a nível de

aprendizagem como da experiência em si. O projeto foi idealizado desde o início para
solucionar um problema: falibilidade humana nas reservações das viaturas. Isto ocorre,

EF.181.r1
 porque a aplicação tolhe o gestor ou mesmo o colaborador de fazer reservas em cima
de outras, algo que é capaz de ocorrer oralmente. Para esse efeito, a aplicação
mostrava ao colaborador as reservas de seus colegas e suas para que ele pudesse
analisar e reservar onde lhe coubesse. Nesta nova aplicação «Gestão de Frota», a
missão inicial mantém-se, é ainda, porém, reforçado alguns conceitos e mais bem
desenvolvido alguns outros. Com efeito, uma vez que a aplicação foi feita do zero sem
nenhuma plataforma a quem a aplicação subjaz permitiu-se que a ela fosse feita sob
medida para a EPEP, assim transpondo os limites impostos pela plataforma Zoho.

Após um desenvolvimento categórico, a aplicação foi lançada em produção e

está funcionando como esperado pelos colaboradores. A integração com outros
sistemas foi tranquila e a migração dos dados foi tranquila. A EPEP está confiante de
que a aplicação atenderá às necessidades dos colaboradores e trará benefícios para a
empresa, como aumento da produtividade, melhor comunicação e acesso rápido à
informação. A segurança da aplicação e dos dados dos colaboradores é uma
prioridade, com medidas como autenticação, criptografia de dados e testes regulares. 18
No futuro, novos recursos serão adicionados.

CRONOGRAMA DE EXECUÇÃO
Calendarização
Tarefas / Atividades / Etapas
MAR

ABR

MA I
JAN

JUN
FEV

JUL

Aprendizagem das diversas tecnologias x x x

Desenvolvimento do front-end x x x x x
Desenvolvimento do back-end x x x x x
Entrega do MVP (produto viável mínimo) x x

(…)

RECURSOS UTILIZADOS
Descrição Tipologia Quantidade

EF.181.r1
 (materiais, equipamentos, espaços,
RH)
PhpStorm Software n/a
LaraDumps Software n/a
Docker Software n/a
Visual Studio Code Software n/a
DBeaver Software n/a
Postman Software n/a
Git Software n/a

(…)

ANÁLISE DO PROCESSO PAP

19

(…)

EF.181.r1
 CONCLUSÃO
Este projeto marcou um marco significativo em minha jornada profissional,
representando não apenas uma oportunidade de aplicar, mas também de aprofundar
meus conhecimentos em uma variedade de tópicos relevantes. Ao longo do processo,
fui desafiado a assimilar novos conceitos e habilidades, contribuindo para meu
desenvolvimento pessoal e profissional. A experiência de participar ativamente do
desenho, discussão e implementação do projeto foi verdadeiramente enriquecedora,
proporcionando insights valiosos e oportunidades de aprendizado inigualáveis.

Testemunhar o projeto em pleno funcionamento, entregando resultados

tangíveis, foi gratificante e motivador. A aplicação não só cumpre sua função primordial,
mas também demonstra um potencial significativo para gerar impacto positivo, tanto
para mim quanto para a organização. Estou comprometido em continuar aprimorando a
aplicação, garantindo que ela permaneça relevante e eficaz diante das mudanças e
desafios em curso. Meu objetivo é não apenas satisfazer as necessidades presentes da
EPEP, mas também antecipar e atender às demandas futuras, contribuindo assim para 20
o sucesso contínuo da organização.

BIBLIOGRAFIA
Adermann, N., & Boggiano, J. (n.d.). Composer. Introduction - Composer. Retrieved
March 8, 2024, from https://getcomposer.org/doc/00-intro.md

Shadcn for Vue - shadcn/vue. (2023, March 11). https://www.shadcn-vue.com/

Haaziq, K. (2021). Radix Vue | Unstyled, accessible components for building high-quality
design systems and web apps in Vue. https://www.radix-vue.com/

Österlund, T. (2020). Schedule-X. Schedule-X | Material Design Event Calendar –

Schedule-X . https://schedule-x.dev/

Otwell, T. (2023, February 14). Laravel. Why Laravel? - Laravel 10.x - The PHP
Framework For Web Artisans. https://laravel.com/docs/10.x#why-laravel

Reinink, J., Dekker, C., Pittman, J., Archer, J., & Maduro, N. (n.d.). Inertia.js. Retrieved
March 8, 2024, from https://inertiajs.com/

EF.181.r1
 Shaw, A. (2009). FullCalendar. FullCalendar - JavaScript Event Calendar.
https://fullcalendar.io/

You, E. (2014). Vue.js. Introduction | Vue.Js. https://vuejs.org/guide/introduction.html

21

EF.181.r1
 ANEXOS

ANEXO I – ANTEPROJETO PAP

Designação do Projeto

Fundamentação do Projeto

EF.181.r1
 ANEXO II – PLANO DE CONCEÇÃO E DESENVOLVIMENTO
Tema da PAP

Resumo

Objetivos do Projeto

Plano de Conceção e Desenvolvimento do Projeto

Etapas de Conceção e Calendarização

A
desenvolvimento DEZ JAN FEV MAR ABR MAI JUN JUL

Recursos Necessários

Tipologia
Descrição (materiais, equipamentos, espaços, Quantidade
RH)

EF.181.r1