Diferència entre revisions de la pàgina «Projecte Portal de Matriculacions»
m (→Referències) |
|||
(8 revisions intermèdies per 3 usuaris que no es mostren) | |||
Línia 57: | Línia 57: | ||
<br> | <br> | ||
+ | |||
+ | == BACKLOG Fase 2 == | ||
+ | |||
+ | Transversals | ||
+ | * missatges flash per TOT | ||
+ | * responsive TOT | ||
+ | |||
+ | |||
+ | === Producció === | ||
+ | * social login google+microsoft | ||
+ | * login estàndard amb codi d'un sol us via email | ||
+ | * posta en prod Heroku | ||
+ | * posta en prod AWS | ||
+ | * càrrega de docs/imatges versió DB. assegurar que carreguen imatges grans. | ||
+ | * càrrega de docs/imatges versió FILESYSTEM. | ||
+ | * documentar posta en producció | ||
+ | |||
+ | === API & + === | ||
+ | * documentar totes les API a la Wiki del projecte | ||
+ | * APIs per app mòbil | ||
+ | ** login alumne | ||
+ | ** selecció perfil de requeriments | ||
+ | ** autoritzacions/acceptació de polítiques de privacitat | ||
+ | ** selecció de UFs | ||
+ | ** càrrega d'arxius (i canvi d'estat) | ||
+ | ** enviament de notificacions (sol·licitud de canvi de dades personals, incidències, etc.) | ||
+ | |||
+ | * social login per mobile app | ||
+ | * test APIs | ||
+ | * versió amb taules separades per admins i alumnes | ||
+ | |||
+ | |||
+ | |||
+ | === Admin panel === | ||
+ | * CRUD complert alumnes (sense AJAX) | ||
+ | * CRUD complert admins (sense AJAX) | ||
+ | * CRUD complert de Perfils de requeriments i requeriments (sense AJAX) | ||
+ | |||
+ | * llistat alumnes amb filtres per: cicle, nom, cognom1, cognom2, estat matrícula | ||
+ | |||
+ | * ordenar per diferents criteris | ||
+ | * visualització de documents carregats | ||
+ | * ''panell de revisió de documentació'' carregada | ||
+ | ** Quan un alumne carrega TOTS els documents, es visualitza en el panell de matrícules a revisar. | ||
+ | ** Es podrà canviar l'estat de doc a OK (verd) o ERROR (vermell) amb COMENTARIS. | ||
+ | ** Quan tota la doc estigui OK s'activarà un botó d'estat total de la matrícula a FINALITZADA | ||
+ | |||
+ | * gestió de notificacions/incidències | ||
+ | ** panell de control on es mostren incidències a resoldre | ||
+ | ** Ha d'estar integrat amb el panell de revisió de la documentació | ||
+ | |||
+ | * enviament emails: (alumnes) | ||
+ | ** canvi estat doc | ||
+ | ** nova incidència | ||
+ | ** nova sol·licitud de canvi de dades | ||
+ | ** noves respostes | ||
+ | |||
+ | |||
+ | |||
+ | === Alumne frontend === | ||
+ | per tot: RESPONSIVE | ||
+ | |||
+ | * selecció perfil de requeriments | ||
+ | * càrrega de Documentació | ||
+ | ** versió FILESYSTEM | ||
+ | ** versió DB | ||
+ | * visualització de documentació i UX clara d'estat de cada Doc i de la matrícula general | ||
+ | ** q s'entengui q és un semàfor | ||
+ | |||
+ | * enviament de notificacions | ||
+ | ** sol·licitud de canvi de dades personals | ||
+ | ** incidències | ||
+ | ** ...? | ||
+ | * autoritzacions/acceptació de polítiques de privacitat | ||
+ | * càlcul cost matrícula | ||
+ | * selecció d'UFs | ||
+ | * pasarel·la de pagament (simulació) | ||
+ | |||
+ | === Importació i testing === | ||
+ | |||
+ | * tancar importació alumnes admesos | ||
+ | * importació dades SAGA (UFs superades) | ||
+ | * gestió errors (log/consultable) | ||
+ | * tests browser site | ||
+ | * documentació testing | ||
+ | * CI amb Jenkins | ||
== Fase 2: Desenvolupament avançat == | == Fase 2: Desenvolupament avançat == | ||
Línia 81: | Línia 167: | ||
==== API ==== | ==== API ==== | ||
− | * implementar funcionalitats | + | * implementar funcionalitats que demanin els altres grups |
* documentació | * documentació | ||
* testing | * testing | ||
− | * autenticació API | + | * autenticació API(token) |
* CRUDs cursos, cicles, mps, ufs | * CRUDs cursos, cicles, mps, ufs | ||
* CRUD alumnes/matrícules | * CRUD alumnes/matrícules | ||
* CRUD admin users | * CRUD admin users | ||
+ | * Preparar controlador para enviar el mail | ||
+ | * Preparar migracion para añadir columna de estado a los req_enrolments | ||
+ | * Preparar migracion para añadir columna active en las mps y ufs | ||
+ | <br> | ||
− | |||
− | |||
==== Dashboard per a l'administrador de l'aplicació (back-of-the-frontend) ==== | ==== Dashboard per a l'administrador de l'aplicació (back-of-the-frontend) ==== | ||
* Un admin ha de poder filtrar per: curs (1r/2n, desplegable), cicle (autocompletar), cognom1, cognom2, nom, estat matrícula (tots els docs estan pujats o no, vàlids o no...) | * Un admin ha de poder filtrar per: curs (1r/2n, desplegable), cicle (autocompletar), cognom1, cognom2, nom, estat matrícula (tots els docs estan pujats o no, vàlids o no...) | ||
Línia 99: | Línia 187: | ||
** Discapacitat: hauria de presentar, per exemple, 4 documents, una imatge y un identificador digital | ** Discapacitat: hauria de presentar, per exemple, 4 documents, una imatge y un identificador digital | ||
** etc | ** etc | ||
− | > Aquest documents, després, es validaran en el dashboard de l'admin. Es mostraran totes les dades de l'usuari | + | > Aquest documents, després, es validaran en el dashboard de l'admin. Es mostraran totes les dades de l'usuari, a més de l'estat de cada document pujat. Els documents pujats varien en funció del perfil de requeriment seleccionat desde el dashboard d'alumne. Per a això: |
− | * L'admin ha de poder descarregar-se una còpia dels documents adjuntats | + | * L'admin ha de poder descarregar-se una còpia dels documents adjuntats. |
** Després, revisarà manualment la validesa dels documents. | ** Després, revisarà manualment la validesa dels documents. | ||
*** Després, marcarà quins estan OK i quins no. Guardarà els canvis. | *** Després, marcarà quins estan OK i quins no. Guardarà els canvis. | ||
**** Llavors s'enviarà un mail automatitzat donant un OK o un KO. En cas de KO, agafarà de manera automàtica els camps que estiguin malament, i ho escriurà en el cos del mail. | **** Llavors s'enviarà un mail automatitzat donant un OK o un KO. En cas de KO, agafarà de manera automàtica els camps que estiguin malament, i ho escriurà en el cos del mail. | ||
− | En el dashboard, hi haurá una sèrie de pistes visuals que indicaran a l'admin l'estat de la solicitud de matrícula | + | |
− | * gris: no enviat | + | En el dashboard, hi haurá una sèrie de pistes visuals que indicaran a l'admin l'estat de la solicitud de matrícula de cada alumne. |
− | * taronja: enviat pendent de revisió | + | * gris: no enviat cap document enviat |
+ | * taronja: document(s) enviat(s) pendent de revisió. Cap la possibiltat que l'usuari només hagi pujat una part de tots els documents!! | ||
* verd: revisat ok | * verd: revisat ok | ||
* vermell: revisat error | * vermell: revisat error | ||
Línia 186: | Línia 275: | ||
<br> | <br> | ||
+ | |||
+ | == Apèndix == | ||
+ | === Ramas: === | ||
+ | * x Pre | ||
+ | * x Pro | ||
+ | * x Integración | ||
+ | ** Una rama por cada alummno | ||
+ | ** Una rama por cada funcionalidad | ||
+ | ** Una rama para CRUD | ||
+ | ** Una rama para CSS | ||
+ | |||
+ | === Proceso de dailys === | ||
+ | 1 Daily de cada equipo | ||
+ | 2 Daily de representantes de equipos, con dudas de los dailys de cada equipo | ||
+ | 3 Se solucionan dudas (y nuevas preguntas) a los equipos otra vez | ||
+ | 4 Última resolución, idealmente... | ||
+ | |||
+ | === Nomenclatura de los JSON cuando se estén intercambiando datos === | ||
+ | * Cuando se pidan datos a API, y API los devuelva, enviará un array de JSON, cuyas claves serán los nombres de las columnas | ||
+ | * Cuando se envíen datos a API desde el frontend, por ahora hay que hablar con el equipo de API y pactar la convención de nombres. Quizás en el futuro bastará con los nombres de las columnas también a la hora de enviar datos. | ||
+ | ** Recordar usar verbos HTTP adecuados |
Revisió de 12:33, 15 abr 2021
Hem iniciat un projecte de matriculacions d'alumnes per a centres educatius. Podeu veure la descripció del projecte i els primers 2 sprints al següent link:
https://scrum.ieti.cat/scrum/projecte/10
Referències
- Portal de Matriculacions - core specs al portal Scrum IETI
- Matrics - Portal de Mariculacions a Github
Descripció del projecte
Portal de matriculacions per a centres educatius de formació professional. De moment només ens ocupem de la FP i no de la ESO/BAT.
MVP: Minimum Viable Product. Cas més senzill: matricular els alumnes nous de 1r de cicles formatius (es matriculen de tot el curs sencer, o sigui, totes les UFs).
2n cas: matricular alumnes de cicles de 2n o repetidors de 1r amb UFs aprovades.
Tipus d'usuaris: administradors (PAS del centre) i alumnes que es volen matricular.
Els usuaris administradors han de poder:
- Crear (des de zero) i editar: cursos, cicles, mòduls professionals (MPs) i unitats formatives (UFs).
- Importar cicles sencers (amb MPs i UFs) de plantilles predefinides. El cas més comú és per afegir un nou cicle. Els plans d'estudi s'ajustarien després amb la funcionalitat anterior.
- Importar les dades dels nous alumnes admesos al centre per cada cicle.
- Importar els expedients acadèmics dels alumnes amb els mòduls i UFs aprovats per tal de facilitar la seva matriculació.
- Crear requeriments de documents que l'alumne ha d'aportar per formalitzar la matrícula.
- Crear perfils de requeriments per aplicar a diversos casos (CFGM, CFGS, ESO, BAT, menors d'edat, etc).
- Obrir i tancar l'accés dels alumnes al portal de matriculació.
- Enviar email d'invitació als alumnes per tal que comencin el procés de matriculació. Aquest enviament pot ser en massa (per a tots els alumnes, per cicle o per curs d'un cicle), o individualitzat.
Els usuaris alumnes han de poder:
- Accedir al portal mitjançant el correu electrònic subministrat a la inscripció. Abans requerirà que recuperin contrasenya via email.
- Rebre un email d'invitació a formalitzar la matrícula.
- Seleccionar els MPs i les UFs a matricular-se.
- Oferir un total del preu de la matrícula (pels CFGS) en base als MPs i UFs.
- Bloquejar els MPs i UFs superades per evitar que es matriculi de nou.
- Pujar els documents requerits per formalitzar la matrícula.
- Mostrar un estat de la matrícula amb una interfície adequada (tipus semàfor en vermell, taronja i verd), que faciliti l'alumne saber quins requeriments té pendents per tal de finalitzar el procés de matriculació.
Els documents requerits han de ser revisats i validats pel PAS. Només després d'aquest pas final l'alumne tindrà la llum verda final de la matrícula.
Opcionalment es contemplen les següents funcionalitats:
- Social login per als alumnes (Gmail, Hotmail/Outlook, etc.)
- Social login per als admins (xtec)
- Simulació de visualització de rol alumne per part dels admins.
Fase 1: core
Als 2 primers sprints hem implementat el projecte base en Laravel, BD, migracions, taules i les primeres funcionalitats. Tots els equips han desenvolupat totes les specs.
Ho podeu llegir a https://scrum.ieti.cat/scrum/projecte/10
BACKLOG Fase 2
Transversals
- missatges flash per TOT
- responsive TOT
Producció
- social login google+microsoft
- login estàndard amb codi d'un sol us via email
- posta en prod Heroku
- posta en prod AWS
- càrrega de docs/imatges versió DB. assegurar que carreguen imatges grans.
- càrrega de docs/imatges versió FILESYSTEM.
- documentar posta en producció
API & +
- documentar totes les API a la Wiki del projecte
- APIs per app mòbil
- login alumne
- selecció perfil de requeriments
- autoritzacions/acceptació de polítiques de privacitat
- selecció de UFs
- càrrega d'arxius (i canvi d'estat)
- enviament de notificacions (sol·licitud de canvi de dades personals, incidències, etc.)
- social login per mobile app
- test APIs
- versió amb taules separades per admins i alumnes
Admin panel
- CRUD complert alumnes (sense AJAX)
- CRUD complert admins (sense AJAX)
- CRUD complert de Perfils de requeriments i requeriments (sense AJAX)
- llistat alumnes amb filtres per: cicle, nom, cognom1, cognom2, estat matrícula
- ordenar per diferents criteris
- visualització de documents carregats
- panell de revisió de documentació carregada
- Quan un alumne carrega TOTS els documents, es visualitza en el panell de matrícules a revisar.
- Es podrà canviar l'estat de doc a OK (verd) o ERROR (vermell) amb COMENTARIS.
- Quan tota la doc estigui OK s'activarà un botó d'estat total de la matrícula a FINALITZADA
- gestió de notificacions/incidències
- panell de control on es mostren incidències a resoldre
- Ha d'estar integrat amb el panell de revisió de la documentació
- enviament emails: (alumnes)
- canvi estat doc
- nova incidència
- nova sol·licitud de canvi de dades
- noves respostes
Alumne frontend
per tot: RESPONSIVE
- selecció perfil de requeriments
- càrrega de Documentació
- versió FILESYSTEM
- versió DB
- visualització de documentació i UX clara d'estat de cada Doc i de la matrícula general
- q s'entengui q és un semàfor
- enviament de notificacions
- sol·licitud de canvi de dades personals
- incidències
- ...?
- autoritzacions/acceptació de polítiques de privacitat
- càlcul cost matrícula
- selecció d'UFs
- pasarel·la de pagament (simulació)
Importació i testing
- tancar importació alumnes admesos
- importació dades SAGA (UFs superades)
- gestió errors (log/consultable)
- tests browser site
- documentació testing
- CI amb Jenkins
Fase 2: Desenvolupament avançat
Es tria el millor projecte de la Fase 1, i s'utilitza com a base per al desenvolupament posterior.
Cada equip desenvoluparà una part diferent del projecte, per tal d'avançar més ràpid i cobrir més funcionalitats.
Es refaran els equips depenent de les preferències de l'alumnat.
Equips i backlog fase 2
UI + Social Login + posta producció
- social login Google + Microsfot
- posta en producció Heroku
- assegurar càrrega d'imatges
- disseny frontend web alumne
- disseny frontend app mòbil
- disseny backend administració
- missatges flash
API
- implementar funcionalitats que demanin els altres grups
- documentació
- testing
- autenticació API(token)
- CRUDs cursos, cicles, mps, ufs
- CRUD alumnes/matrícules
- CRUD admin users
- Preparar controlador para enviar el mail
- Preparar migracion para añadir columna de estado a los req_enrolments
- Preparar migracion para añadir columna active en las mps y ufs
Dashboard per a l'administrador de l'aplicació (back-of-the-frontend)
- Un admin ha de poder filtrar per: curs (1r/2n, desplegable), cicle (autocompletar), cognom1, cognom2, nom, estat matrícula (tots els docs estan pujats o no, vàlids o no...)
- Ordenar/invertir ordre per un sol criteri
- Un admin ha de poder editar o actualitzar dades d'un alumne de les que vénen del SAGA. Només PUT y UPDATE, no podrà mai fer un DELETE
- Perfils de requeriments: en funció de si un alumne marca que es eligible a beques o altres ajudes, se li desbloquejarà en el seu dashboard la posibilitat de penjar els documents pertinents.
- Monoparental: hauria de presentar, per exemple, tres documents
- Discapacitat: hauria de presentar, per exemple, 4 documents, una imatge y un identificador digital
- etc
> Aquest documents, després, es validaran en el dashboard de l'admin. Es mostraran totes les dades de l'usuari, a més de l'estat de cada document pujat. Els documents pujats varien en funció del perfil de requeriment seleccionat desde el dashboard d'alumne. Per a això:
- L'admin ha de poder descarregar-se una còpia dels documents adjuntats.
- Després, revisarà manualment la validesa dels documents.
- Després, marcarà quins estan OK i quins no. Guardarà els canvis.
- Llavors s'enviarà un mail automatitzat donant un OK o un KO. En cas de KO, agafarà de manera automàtica els camps que estiguin malament, i ho escriurà en el cos del mail.
- Després, marcarà quins estan OK i quins no. Guardarà els canvis.
- Després, revisarà manualment la validesa dels documents.
En el dashboard, hi haurá una sèrie de pistes visuals que indicaran a l'admin l'estat de la solicitud de matrícula de cada alumne.
- gris: no enviat cap document enviat
- taronja: document(s) enviat(s) pendent de revisió. Cap la possibiltat que l'usuari només hagi pujat una part de tots els documents!!
- verd: revisat ok
- vermell: revisat error
Documents que s'hauran d'adjuntar, en funció dels perfil triat:
- Obligatoris: DNI/NIE, targeta sanitaria, resguard del títol, pagament
- Menor: DNI pares, llibre de família / partida naixement
- Perfils pagament superior:
- Família nombrosa: carnet de família nombrosa
- Família monoparental
- Beca
- Discapacitat
- Alumne tutelat
- Beneficiari de la RMI
alumne frontend
- dashboard
- selecció UFs
- selecció perfil de req.
- càlcul cost matrícula
- estat dels docs enviats
- estat de la matrícula
- correcció dades personals
- ????
POT CANVIAR: direcció, telèfons, - NO POT CANVIAR: DNI, NIE, Nom, Cognoms
- ????
- sol·licitud de canvis de dades
- versió mòbil
- simulació pasarela de pagament
- Autoritzacions (radio button, obligatori):
- autorització drets d'imatge (tots)
- autorització sortides (menors)
- sortides extraescolars (menors)
Càlcul preu de la matrícula:
- CFGM (curs sencer)
- >28 : assegurança a part de l'escolar 105,38€
- <28 : 86,50€
- CFGM (per MPs)
- 10€/MP + asseg. escolar (<28 1,12€, >28 20€)
- CFGS
- curs sencer:
- <28 anys: 360,00 € + 65 (material) + 1,12 € (asseg.)
- >28 anys: 360,00 € + 65 (material) + 20 € (asseg.)
- bonificació 50% (fam. nombrosa/monoparental/beca)
- <28 anys: 180 € + 66,12 €
- >28 anys: 180 € + 85 €
- exempció: (fam. nombrosa/minusvalia/víctimas terr./privats de llibertat/...)
- <28 anys: 66,12 €
- >28 anys: 85 €
- CFGS per UFs:
- 25 €/UFs (sin bonif.)
- 12,5 €/UFs (con bonif.)
- 1,12 €/20€ assegurança
- 10€ material si només son UFs de 1 MP
- 65 € material si son UFs de >1 MPs
- curs sencer:
Pagament fraccionat CFGS:
- 1a fracció 1/2 del preu públic (360/180) + material+asseg. (66,12/85)
- 2a fracció 1/2 del preu públic
importació i testing
- importació alumnes admesos (manteniment)
- importació dades SAGA (UFs superades)
- gestió dels errors d'importació:
- fitxer de sortida amb registre d'errors (per a ser corregits i reimportats)
- matrícules duplicades: es sobreescriuen si son del mateix any i mateix cicle
- importació cicles duplicats: preguntar
- testing de la site
Apèndix
Ramas:
- x Pre
- x Pro
- x Integración
- Una rama por cada alummno
- Una rama por cada funcionalidad
- Una rama para CRUD
- Una rama para CSS
Proceso de dailys
1 Daily de cada equipo 2 Daily de representantes de equipos, con dudas de los dailys de cada equipo 3 Se solucionan dudas (y nuevas preguntas) a los equipos otra vez 4 Última resolución, idealmente...
Nomenclatura de los JSON cuando se estén intercambiando datos
- Cuando se pidan datos a API, y API los devuelva, enviará un array de JSON, cuyas claves serán los nombres de las columnas
- Cuando se envíen datos a API desde el frontend, por ahora hay que hablar con el equipo de API y pactar la convención de nombres. Quizás en el futuro bastará con los nombres de las columnas también a la hora de enviar datos.
- Recordar usar verbos HTTP adecuados