Títol del treball: AutoTallerGestió Nom de l'autor: Marc Casas Soler Nom del consultor: Vicenç Font Sagrista. El resultat final del treball ha complert els objectius definits inicialment i inclou totes les funcionalitats definides.
Introducció
- Context i justificació del Treball
- Objectius del Treball
- Eines i tecnologies
- Enfocament i mètode seguit
- Planificació del Treball
- Breu sumari de productes obtinguts
- Breu descripció dels altres capítols de la memòria
Com que el sistema de treball es basa en Docker, en comptes d'utilitzar un Apache, s'ha escollit un Nginx com a servidor web. A partir d'aquesta entrevista s'ha pogut definir l'abast del projecte i quines necessitats s'han de cobrir.
Anàlisi funcional
- Actors
- Casos d’ús
- Diagrama dels casos d’ús
- Fitxes de casos d’ús
El sistema verifica que les dades introduïdes són correctes, les emmagatzema a la base de dades i les redirigeix a la pantalla de llista de categories. El sistema verifica que les dades introduïdes són correctes, les emmagatzema a la base de dades i les redirigeix a la pantalla de llista de clients. El sistema verifica que les dades introduïdes són correctes, les emmagatzema a la base de dades i les redirigeix a la pantalla de llista de vehicles.
El sistema verifica que les dades introduïdes són correctes, desa les dades a l'ordre de reparació i la marca com a completada. El sistema verifica que les dades introduïdes són correctes, les emmagatzema a la base de dades i redirigeix a la pantalla de llista de fulls de càlcul. El sistema retorna un document PDF amb les ordres de reparació que compleixen les condicions del filtre.
No hi ha ordres de reparació que compleixin les condicions del filtre i el sistema retorna un document PDF buit. El sistema mostra un formulari amb diverses opcions per filtrar fulls de treball (data d'inici i finalització, operador, ordre de reparació) i un botó "Crea una llista". El sistema mostra un formulari amb ordres de reparació que tenen un pressupost assignat i un botó.
Disseny tècnic
- Models de pantalles
- Diagrama de classes
- Model de dades
- Diagrama d’arquitectura
L'ordre de reparació és el document que el taller ha de lliurar al client quan aquest deixa el cotxe per a la reparació. L'ordre de reparació emmagatzema dades com ara el vehicle i el client, la data de matriculació del vehicle, els quilòmetres que té i una descripció de les tasques de reparació a realitzar. Un cop lliurada la comanda, es marca com a lliurada (de la llista d'ordres de reparació) i no es pot modificar.
Totes les dades del full de treball són obligatòries: data, operador i ordre de reparació. No és possible eliminar un client si està inclòs en una especificació o una comanda de reparació. No es pot suprimir un vehicle si està inclòs en un pressupost o comanda de reparació.
Podeu introduir articles sense codificar (o referències inexistents) a les ordres de reparació i les línies de pressupost.
Implementació
- Estructura de fitxers
- Proves realitzades
- Millores futures
- Resultat
Originalment estava previst preparar una suite de proves automatitzada, aprofitant la bona integració de Symfony amb el marc de proves PHPUnit. Per tal de garantir la qualitat del programari, i tenint en compte que durant la fase de disseny ja s'havia dissenyat un conjunt complet de proves [8.3 Annex 3: Test Set of AutoTallerGestió], les proves es van realitzar manualment. Aquesta sèrie de proves té 118 diferents proves, i tractar de considerar els diferents casos d'ús definits al capítol 2.
És a dir, és una aplicació completa que fa el que demana l'actor principal, però res més. Per millorar la qualitat del programari, el primer que cal fer és automatitzar tot el conjunt de proves. La primera vegada que s'inicia aquest entorn, es carreguen algunes dades de demostració perquè el sistema no estigui buit.
La informació surt agrupada i resumida segons la referència i descripció dels conceptes (cal destacar que un dels requisits per part de l'interessat era que no era obligatori codificar els articles), amb pressupost total i full de treball a la part inferior.
Conclusions
Glossari
Bibliografia
Annexos
Annex 1: Entrevista per a la definició del projecte i l’abast d’aquest
Hi ha registres de clients i cotxes que entren, així com un registre de pressupostos lliurats (matrícula, propietari, data i import). Si hi ha un pressupost previ, el pressupost es factura directament o pot haver-hi revisions en funció de les hores treballades, materials utilitzats, peces, etc. Si no hi ha pressupost, hi ha un registre de les hores treballades en cada lloc de treball.
Hi ha un registre de les eines existents al taller, juntament amb les seves dades (compra, preu, etc.). No hi ha registre de consumibles, ja que funciona d'una manera molt senzilla: sempre hi ha un paquet en estoc i un paquet per treballar. Hi ha un calendari per predir quan un vehicle nou pot venir a reparar.
Quan no és urgent, els vehicles es fabriquen segons l'ordre de sortida i arribada, en funció de les necessitats de cada client.
Annex 2: Exemple de fulla de treball
Annex 3: Joc de proves d’AutoTallerGestió
Estructura d'un entorn LAMP (Linux, Apache, MySQL i PHP)
Tenint en compte els punts anteriors, s'ha decidit utilitzar un entorn LAMP clàssic (Linux, Apache, MySQL i PHP)[1], utilitzant la versió 7.4 de PHP i la 8.0 de MySQL. Pel que fa a l'estructura del projecte, es crearà una aplicació utilitzant el framework Symfony 5.4 [2], tant per a backend com per a frontend.
Diagrama GANTT de la planificació del treball
Per organitzar els casos d'ús i veure'ls de manera més gràfica, s'ha elaborat un diagrama de casos d'ús amb actors. Això vol dir que un usuari usuari tindrà assignats tots els casos d'ús, però un usuari administrador tindrà els seus propis i, al mateix temps, els de l'actor usuari.
Diagrama de casos d'ús
El sistema verifica que les dades introduïdes són correctes, les emmagatzema a la base de dades i redirigeix a la pantalla de llista d'usuaris. El sistema verifica que les dades introduïdes són correctes, les emmagatzema a la base de dades i redirigeix a la pantalla de llista d'elements. El sistema verifica que les dades introduïdes siguin correctes, assigna un nou número d'ordre de reparació, l'emmagatzema a la base de dades i redirigeix a la pantalla de llista d'ordres de reparació.
El sistema marca el full de treball com a suprimit i torna a la pantalla de llista de fulls de treball. El sistema mostra un formulari amb diverses opcions per filtrar els elements (categoria, codi inicial i codi final) i un botó "Genera llista". El sistema mostra un formulari amb diverses opcions per filtrar els clients (ID inicial, ID final, nom i cognom) i un botó "Genera llista".
El sistema retorna un document PDF amb fulls de treball que compleixen les condicions del filtre. El sistema mostra un formulari amb diverses opcions per filtrar ofertes (número d'inici i finalització, data d'inici i finalització, vehicle, client, estat) i un botó. El sistema retorna un document PDF amb ofertes que compleixen les condicions del filtre.
Pantalla d'entrada al sistema
Gestió d'usuaris (administrador)
Alta d'usuari (administrador)
Pantalla principal (dashboard)
Llista d'ordres de reparació
Creació d'una ordre de reparació
Llista de pressupostos
Alta de pressupostos
Alta de fulles de treball
Informe de fulles de treball
Diagrama de classes
Un cop disposeu de tota la informació necessària, es crea el diagrama entitat-relació de la base de dades. La raó és que es va utilitzar una tècnica de codi primer per implementar l'accés a les dades, on primer es creen totes les classes amb les seves relacions al sistema i es deixen al propi framework (en aquest cas Doctrine) per crear la base de dades, taules, relacions i restriccions. A causa de l'ús de Doctrine Migrations [11] per generar la base de dades, també es van crear les taules doctrine_migrations i messenger_messages.
Diagrama entitat-relació
Capa de servei: aquesta capa rep les peticions del client, les processa i retorna una resposta al client. La seva tasca és transferir el tractament de dades als serveis i retornar les seves respostes. Reben sol·licituds dels controladors, modifiquen dades o estableixen valors per defecte i les reenvien a diversos repositoris.
Carpeta d'imatges: totes les imatges adjuntes a ordres de reparació, vehicles o com a logotip de configuració s'emmagatzemen en aquesta carpeta.
Arquitectura de l'aplicació
En mode de producció (amb Docker) això no s'utilitza, ja que el propi contenidor Docker envia les variables amb les dades de MySQL. Com que els paquets s'instal·len directament des de la línia d'ordres, aquest fitxer no es modifica manualment. Té la llista de tots els paquets, amb les versions exactes, instal·lats a l'aplicació.
Això garantiria que tot funcioni correctament, ja que actualment hi ha 118 proves, però és llarg i complicat executar totes aquestes proves. Un cop resolta l'automatització de les proves, cal definir, dissenyar i vincular la resta de mòduls necessaris al projecte actual. Els mòduls que es poden afegir són molt nombrosos: des de gestió d'estocs, comandes a proveïdors, sistema de facturació, comptabilitat, calendari per organitzar l'entrada i sortida de vehicles, etc.
És un entorn de contenidors amb servidor web, intèrpret PHP i base de dades MySQL.
Pantalla principal (dashboard)
Creació d'un nou pressupost
Pressupost imprès
Preparació del llistat de fulles de treball
Llistat de fulles de treball
Comparativa entre pressupost i fulles de treball
A més de les hores i el material, també es registra informació com ara els desplaçaments (km i temps) o altres despeses. Per a treballs basats en un pressupost fet amb la base de dades de preus (pressupost amb obra i recanvis), no es registren hores. Si el pressupost es calcula a partir de la pròpia experiència, per regla general tampoc es registren hores.
Això només es fa per a feines que no s'han fet abans (models de vehicles nous), només per comprovar que l'estimació d'hores era correcta. Aquest registre es fa en una llibreta i el responsable és qui ho anota tot. Els clients es facturaran pel temps que triga a recollir el vehicle si arriben més d'una setmana de retard.
Tenim estadístiques de mesos forts i febles basades en les dades enviades a la direcció.
Exemple d'ordre de reparació
2 Com a usuari, feu clic al botó per crear un article nou. Aneu a la pantalla de l'article nou. 2 Com a usuari, feu clic al botó per crear una categoria nova. Aneu a la pantalla de categoria nova. 2 Com a usuari, feu clic al botó per crear un client nou. Aneu a la pantalla del client nou.
2 Com a usuari, feu clic al botó per crear un vehicle nou Vés a la pantalla del vehicle nou. 2 Com a usuari, feu clic al botó Crea un pressupost nou Vés a la pantalla de pressupost nou. 8 Com a usuari, feu clic a un pressupost marcat com a acceptat. Aneu a la visió general del pressupost.
2 Com a usuari, feu clic a generar llista sense establir cap opció. Genereu una llista en PDF de tots els pressupostos.
