1. Inici
  2. Estandards
  3. Estàndard desenvolupament programari mòbils

    Estàndard desenvolupament programari mòbils

Classificació de l'estàndard MÒBILS  (35.090)
Codi de l'estàndard 35.080.06
Versió 1.0
Data última actualització 19/07/2021
Responsable Disciplines. Qualitat i mètodes. DGSEC
Llicència

Part 1: Abast

Aquest document especifica els requisits i recomanacions en el desenvolupament d’aplicacions mòbils per a la Generalitat de Catalunya

Part 2: Referències

Part 3: Termes i definicions

Direcció General de Serveis Digitals i Experiència Ciutadana

Dirigeix i planifica l’oferta de serveis mòbils de la Generalitat i altres dispositius que s’interconnecten a través d’internet per comunicar serveis a la ciutadania o relacionar-s’hi.

Oficina Tècnica de Mobilitat

Gestiona el procés de publicació d’una app o versió als Markets sota el paraigües del compte de la Generalitat de Catalunya.

Aplicació Nativa

Aplicació que s’instal·la o executa directament en el dispositiu mòbil, i que ha estat desenvolupada específicament per a cada sistema operatiu (Android, iOS)

Aplicació Web optimitzada per mòbil

Aplicació desenvolupada en tecnologia web que s’adapta a les característiques del dispositiu mòbil. En aquest cas, caldrà adaptar-se a l’estàndard de desenvolupament del programari de la interfície web.

Aplicació Híbrida

Aplicació que té parts natives i parts desenvolupades en tecnologia web.

Configuració

Una configuració és la combinació de les diferents possibilitats que poden afectar a la visualització o comportament de l’aplicació. Podem trobar:

  • Tipologia de terminal: smartphone o tauleta.
  • Plataforma: SO i versió
  • Resolució de pantalla: ldpi; mdpi; hdpi…
  • Navegador: marca i versió
Gestió de versions actives

És la capacitat que té la app per sí mateixa per determinar si la versió instal•lada de l’app en el dispositiu és vigent (una versió de l’App funcional 100%) o no i en cada cas, notificant al usuari amb la informació adient.

Reputació digital

La reputació digital és un reflex del prestigi o estima versus una marca a Internet. El seu nivell determina o pot ajudar a definir el full de ruta d’evolutius tecnològics i funcionals. La reputació es pot obtenir mitjançant diferents canals:

  • Valoracions i comentaris que els usuaris publiquen a les botigues d’aplicacions
  • Anàlisi de logs de tancaments o comportaments inesperats de l’app
  • Analítiques d’ús: evolució del nombre de descàrregues, la fidelització dels usuaris, els patrons d’ús de l’aplicació, el grau d’utilització de cada funcionalitat o secció de l’app…

Part 4: Requisits per a la definició, desenvolupament i publicació

Definició abast i estratègia

  1. Les iniciatives mòbils adreçades a la ciutadnia han de validar el seu enfocament funcional amb la DGSEC seguint el Procediment de sol·licitud de Serveis mòbils gencat

Anàlisi i Disseny

  1. Les aplicacions mòbils han de ser dissenyades i construïdes de forma desacoblada a la informació (seguir l’Estàndard per la definició d’arquitectures dels sistemes d’informació)

  2. Les aplicacions mòbils han de ser dissenyades seguint els requisits d’imatge corporativa

  3. Segons el Reial Decret 1112⁄2018, de 7 de setembre, les aplicacions mòbils han de ser accessibles i complir amb la Norma EN 301 549. Aquesta normativa és d’estricte compliment per a totes les aplicacions mòbils a partir del 23 de juny de 2021.

  4. Les aplicacions mòbils han d’integrar-se amb el SDK de Firebase per Analytics i Crashlytics.

  5. Les aplicacions mòbils han de considerar la necessitat de fer ús dels serveis de mobilitat proporcionats pel CTTI:

Construcció i integració

  1. Les aplicacions mòbils han de ser construïdes de forma que puguin ser usades en diferents configuracions de mòbil, seguint els Requisits de Cobertura del Parc Mòbil

  2. Les aplicacions mòbils han de ser construïdes garantint els Requisits de qualitat

  3. Les aplicacions mòbils han de seguir les directrius de desenvolupament establertes per cada sistema operatiu:

Implantació i qualificació

  1. El proveïdor de desenvolupament ha de realitzar proves de qualificació de la versió a publicar seguint la Guia de Proves sobre aplicacions mòbils

  2. El responsable funcional ha d’encarregar la realització de l’informe de revisió de l’Accessibilitat (IRA) que determina el grau d’accessibilitat de l’aplicació, i la declaració d’accessibilitat. Aquest informe ha de ser lliurat a l’Oficina de Qualitat del CTTI i a la DGSEC (En aquest enllaç podeu accedir a la comunitat d’accessibilitat on trobareu tota la informació per realitzar els informes IRA). D’altra banda, també podeu accedir a la guia d’accessibilitat.

Certificació

  1. L’Oficina de Qualitat del CTTI executa un procés de certificació bàsica abans de la seva publicació als Markets.

  2. L’aplicació NO ha de ser publicada si no es supera la certificació.

Acceptació i posada en servei

  1. La DGSEC, el Responsable Funcional i l’Oficina de Qualitat del CTTI han de donar el seu vist-i-plau per publicar una aplicació mòbil

Manteniment

  1. Les iniciatives mòbils de la Generalitat de Catalunya han de garantir un manteniment tecnològic adequant el codi a les noves llibreries garantint una publicació anual a les principals botigues d’Aplicacions.

  2. Les aplicacions mòbils haurien de publicar dues noves versions funcionals a l’any.

  3. La DGSEC pot avaluar la despublicació de les aplicacions que NO hagin publicat una nova versió funcional en els darrers dos anys i/o que tinguin una puntuació inferior a 3.0 en les botigues d’aplicacions

Reputació digital

  1. La DGSEC ha d’enviar als promotors de cada iniciativa mòbil un conjunt d’indicadors sobre la reputació digital (veure Procediment de reputació digital)

  2. Els promotors haurien d’atendre i respondre els comentaris dels Markets, així com incorporar les millores que la ciutadania sol·licita, en cas de ser viables

Part 5: Requisits d’imatge corporativa

  1. L’aplicació ha de complir amb la guia d’estils i criteris d’imatge corporatius de la Generalitat de Catalunya

  2. La icona de l’app ha de tenir la mida correcta.

  3. La splash screen ha d’incloure el logo de l’organisme o departament que promou l’app, així com el nom de l’app.

  4. La interfície, interacció, comportament i distribució dels elements s’ha de realitzar segons les directrius establertes pel sistema operatiu

Part 6: Requisits de cobertura del parc mòbil

  1. Les aplicacions natives han de ser desenvolupades per Android i iOS

  2. L’aplicació ha de ser desenvolupada amb la darrera versió de sistema operatiu disponible en el moment d’iniciar el desenvolupament, encara que per la seva novetat tingui un nivell baix d’adopció

  3. S’han d’adaptar les aplicacions per a que siguin compatibles amb el 90% del parc mòbil de cadascun dels sistemes operatius iOS i Android, tenint en compte les possibles configuracions (orientació, resolució, …)

    Veure ANNEX Distribució de sistemes del parc mòbil

  4. S’han de seleccionar terminals amb totes les versions majors de sistema operatiu on ha de funcionar, i escollir versions menors que, per les seves capacitats intrínseques, poden implicar un comportament diferent del servei a provar

  5. S’han de seleccionar terminals tipus smartphone i tipus tauleta si l’aplicació te visualitzacions específiques per a cada tipologia.

  6. Si l’aplicació és nativa, està adreçada a la ciutadania i fa ús de sensors del dispositiu (GPS; brúixola, acceleròmetre…) s’han de realitzar proves de camp amb terminals físics

Part 7: Requisits de qualitat

Funcionalitat

  1. L’aplicació ha d’incloure la funcionalitat de “Gestió de Versions Actives” i verificar per sí mateixa si la versió instal·lada en el dispositiu és vigent.

  2. En el cas que no es pugui garantir el bon funcionament de l’App d’una versió anterior (compatibilitat, backoffice..) s’haurà d’informar a l’usuari si és necessari descarregar una versió més recent de l’App guiant a l’usuari d’on descarregar la nova versió i realitzar el tancament de l’App

  3. L’aplicació no ha de duplicar funcionalitats ja existents en el dispositiu

  4. El conjunt de funcions de l’aplicació ha de ser consistent amb l’ajuda

  5. Els enllaços externs han de funcionar correctament

  6. L’aplicació ha d’usar capacitats que estan disponibles en tots els dispositius avaluats (GPS, brúixola, …)

  7. L’aplicació ha de gestionar adequadament la configuració de notificacions i esdeveniments push

  8. L’aplicació no ha de modificar permanentment cap ajust en el dispositiu per al que no estigui destinada.


Interoperabilitat

  1. Els serveis mòbils han d’estar construïts de forma desacoblada a la informació.


Usabilitat, accessibilitat i portabilitat

  1. L’aplicació ha de complir amb les pautes d’accessibilitat establertes en la Norma EN 301 549.

  2. L’aplicació s’ha de poder visualitzar correctament en els diferents dispositius mòbils establerts en la cobertura (mida de lletra, elements gràfics, etc.)

  3. El repintat de la pantalla ha de funcionar correctament en canvis d’orientació del dispositiu, menús emergents, finestres emergents, etc.

  4. La interfície gràfica ha de ser coherent en tota l’aplicació, i es manté la continuïtat en tot l’estil (literals, elements gràfics, errors ortogràfics)

  5. L’aplicació ha d’estar correctament localitzada (texts per diferents idiomes, monedes, unitats de mesura, etc.).

  6. S’ha de mostrar el teclat adequat per cada tipus d’entrada (numèrica o alfanumèrica).

  7. L’aplicació ha de gestionar adequadament les pulsacions múltiples o multitouch.

  8. Cada pantalla ha de ser visible durant el temps necessari per llegir còmodament tota la seva informació.

  9. L’app s’ha d’instal·lar per defecte sempre en català, excepte en el cas de que l’idioma del dispositiu estigui en anglès, que s’instal•larà en aquest idioma.

  10. Ha de funcionar el canvi d’idioma i aquest s’ha d’ajustar de forma adequada la interfície i els continguts, i la configuració de l’idioma s’ha de mantenir en tancar l’app.


Fiabilitat

  1. L’aplicació ha de comprovar la introducció de dades errònies (format, rangs, …)

  2. L’aplicació no pot fallar abruptament durant el seu ús (bloquejos, …)

  3. L’aplicació ha de notificar a l’usuari en cas d’operacions de llarga durada

  4. L’aplicació s’ha de recuperar correctament en canvis de context (canvi a un altra aplicació diferent i tornar), interrupcions externes (trucada entrant, recepció d’un missatge, …) i apagats del terminal.

  5. L’aplicació ha de notificar a l’usuari en cas d’interrupció externa.

  6. L’aplicació ha d’avisar quan no es disposa de connectivitat

  7. L’aplicació ha de notificar a l’usuari en cas de baixa qualitat de la xarxa a la que s’està connectat

  8. L’aplicació no pot consumir recursos excessivament: bateria, CPU, memòria, dades

  9. L’aplicació s’ha de poder instal·lar i desinstal·lar adequadament.


Seguretat

  1. Les contrasenyes no han de ser mostrades en clar i no poden ser emmagatzemades en el dispositiu.

  2. L’aplicació ha de gestionar correctament l’accés a informació personal (agenda, …) amb aprovació per part de l’usuari

  3. L’aplicació ha de sol·licitar els permisos necessaris per accedir als diferents serveis del dispositiu i aquests, estan publicats i descrits.

  4. L’aplicació ha de disposar d’un mecanisme de validació d’usuari propi per accedir a informació confidencial o privada.

  5. L’aplicació no pot danyar les dades al dispositiu

ANNEX A (Informatiu) Distribució de sistemes del parc mòbil


La definició del parc mòbil al que ha d’anar destinat una aplicació ha de tenir en compte quina és la distribució dels sistemes.

En el cas de l’ús de navegadors web de dispositius mòbils, es pot obtenir la distribució en les dades d’analítica dels webs gencat. En cas de no disposar-ne, les dades es poden obtenir de Stacounter GlobalStats.

En el cas d’aplicacions natives, es pot obtenir informació de la distribució estimada a: