Diferència entre revisions de la pàgina «Projecte Portal de Matriculacions»

De Wiket
Salta a la navegació Salta a la cerca
 
(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 q demanin els altres grups
+
* 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>
  
<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 (front encara per determinar). Per a això:
+
> 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


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.


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


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