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 20 de março 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 1
brainstorm discutíamos e ideávamos como aperfeiçoar a aplicação.

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, 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 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 2

construção 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 3
elegante. [Que] 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) .

EF.181.r1
 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é 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

4
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 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 9
nenhum item na lixeira ou em qualquer 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

EF.181.r1
 interagir com aquela 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 11
do Laravel, incluindo login, registo, redefinição de senha, verificação de e-mail e
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 12

Administrador Pedidos Criar, Ler, Atualizar, Excluir

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 (Torvalds, 2005) 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, porque a aplicação
tolhe o gestor ou mesmo o colaborador de fazer reservas em cima de outras, algo que é capaz de
EF.181.r1
 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 q uem 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. No futuro, novos recursos serão adicionados.

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

ABR

MA I
JAN

JUN
FEV

Aprendizagem das diversas tecnologias x x x JUL

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
Tipologia
Descrição (materiais, equipamentos, espaços, Quantidade
RH)
PhpStorm Software n/a
LaraDumps Software n/a
Docker Software n/a

EF.181.r1
 Visual Studio Code Software n/a
DBeaver Software n/a
Postman Software n/a
Git Software n/a

(…)

ANÁLISE DO PROCESSO PAP

19

(…)

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
EF.181.r1
 desenho, discussão e implementação do projeto foi verdadeiramente enriquecedora,
proporcionando insights valiosos e oportunidades de aprendizado inigualáveis.

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 o sucesso contínuo
da organização. No presente momento, a aplicação ainda está em desenvolvimento.
Não por muito tempo, em breve já estará em produção e utilização pelos
colaboradores.

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

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/

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

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

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

Calendarização
Etapas de Conceção e
desenvolvimento DEZ JAN FEV MAR ABR MA JUN JUL
I A

Recursos Necessários
Tipologia
Descrição (materiais, equipamentos, espaços, Quantidade
RH)

EF.181.r1