JUSTIZIA ETA HERRI ADMINISTRAZIO SAILA

DEPARTAMENTO DE JUSTICIA Y ADMINISTRACIÓN PÚBLICA

PLIEGO DE BASES TÉCNICAS Documento:

SPB- 2009-PY058-001

C02/025/2009

Denominación:

SPB 02 - 03/04

Tramitación y Pago Móvil

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Página: 2/54

Contenido Capítulo/sección

Página

1

Introducción: Antecedentes

5

2

Visión General del Proyecto

6

3

Necesidades Detectadas

8

4

Introducción a la Funcionalidad de Pago con Dispositivos Móviles

9

5

Objeto:

12

6

Alcance

12

7

Requisitos del bien o servicio:

14

7.1

Estudio de Plataformas de pago por móvil

14

7.2

Selección y Provisión de Dispositivos Móviles

15

7.2.1 Selección y Provisión

15

7.2.2 Guía de Usabilidad de las Aplicaciones

16

7.2.3 Características técnicas de los Dispositivos

16

7.3

Estudio de Plataformas de Gestión de Dispositivos

17

7.4

Aplicación de Configuración del Dispositivo

18

7.5

Aplicación de captura de liquidaciones y pago móvil

19

7.5.1 Descripción General de la Funcionalidad de la Aplicación

19

7.5.2 Pago en condiciones de “no conectividad”

22

7.5.3 Detección de condiciones de conectividad

23

7.6

24

Aplicación de tramitación con pago móvil

7.6.1 Aplicación Departamental conectada con la aplicación de tramitación de pago móvil

24

7.6.2 Envío de eventos desde el móvil a un sistema back-end

25

8

Descripción entregables

26

9

Entorno Tecnológico

28

9.1

Tecnologías de Servidor

28

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Página: 3/54

9.2

Entorno Cliente Web

28

9.3

Herramientas

29

9.4

Pruebas e Implantación

29

9.5

Tratamiento del Idioma

30

9.6

Tecnologías Homologadas

31

10

Gestión del Proyecto

32

10.1 Metodología

32

10.2 Equipo de Proyecto

34

10.3 Recursos Materiales: Lugar de trabajo y equipamiento

35

10.4 Organización del Proyecto y Estructuras de Control

36

11

Puntos de Riesgo

38

12

Procedimientos de Calidad

38

13

Garantía

38

14

Confidencialidad

38

15

Propiedad Intelectual

39

16

Plazos:

39

17

Presupuesto y Forma de Pago

40

18

ANEXO: Aplicación Piloto de Pago Móvil

41

18.1 Introducción

41

18.2 Realizar un pago

42

18.2.1 Descripción general

42

18.2.2 Introducción de los datos de pago

43

18.2.3 Confirmación del pago

44

18.2.4 Modo de pago diferido

46

18.3 Accesibilidad en dispositivos UMPC

49

18.4 Otras opciones

52

18.5 Especificaciones Técnicas

54

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

SPB 02 - 03/04

Página: 4/54

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

1

Página: 5/54

Introducción: Antecedentes La Pasarela de Pagos de las Administraciones Vascas surge en el año 2001 ante la necesidad por parte del Gobierno Vasco de incorporar el pago en sus procedimientos tramitados tanto presencialmente como telemáticamente. Desde el año 2001 hasta la actualidad el proyecto ha ido evolucionando principalmente en la incorporación de funcionalidades que permitieran / flexibilizaran su utilización en cualquier Administración. En resumen, la vida del proyecto hasta la fecha ha sido:

Pasarela de Pagos

2001

Concepción inicial: acuerdo con las Entidades Financieras y prototipos

2002 2003

Versión 1 de la Pasarela de Pagos como un proyecto interno de EJIE. Incorporación de Ayuntamientos de Gipuzkoa

2004

Incorporación de algunos ayuntamientos de Bizkaia (Bilbao) y Araba que utilizan el formato 57 Incorporación de la Diputación Foral de Gipuzkoa

2005

Incorporación de mas ayuntamientos de Bizkaia y Araba que utilizan el formato 57 Inicio del diseño y construcción de la versión 2 ampliando y mejorando las funcionalidades de la versión 1

2006

Implantación de la Versión 2 en producción.

2007

Incorporación de ayuntamientos de Bizkaia y Araba (Vitoria-Gasteiz) con cualquier formato. Pago con dispositivos en ventanillas de la Administración

2008

Incorporación de las oficinas de tráfico TPV Virtual para pago con tarjetas de cualquier entidad

2009

Pago Móvil

En grandes líneas, la Pasarela de Pagos ha tenido dos versiones, ampliando la versión 2 las funcionalidades de la versión 1 para hacerla más flexible: Funcionalidad Unificación de interfaces de usuario en Entidades Financieras

Versión 1

Versión 2

NO

SI

Formato 57

SI

SI

Formato 57 no estándar (tráfico)

NO

SI

Formatos 60

NO

SI

Pago múltiple

NO

SI

Pago desde formulario

SI

SI

Integración en aplicaciones

SI

SI

Solo resultado de pago

Todos los eventos

Eventos de Pago (para ser utilizados en las aplicaciones) Pago en Ventanillas de la Administración con dispositivos

NO

SI

Listado on-line de administraciones

NO

SI

Interfaz mínimo / ligero de la pasarela de pagos

NO

SI

Consulta del estado del pago

NO

SI

Solicitud de justificante de pago (post-pago en la Entidad

NO

SI

NO

SI

Financiera)

NRC (número de referencia completo del pago)

SPB 02 - 03/04

Librerías (APIs) para aplicaciones y entidades financieras

NO

SI

TPV Virtual (pago con tarjeta de entidades no adheridas)

NO

SI

Pago con dispositivos móviles

NO

SI

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Página: 6/54

La Pasarela de Pagos, pese a ser una infraestructura impulsada desde la extinta Dirección de la Oficina para la Modernización Administrativa (DOMA), actual Dirección de Innovación y Administración Electrónica (DIAE), y la Dirección de Finanzas del Gobierno Vasco, desde el inicio se concibió como una plataforma horizontal utilizable por cualquier entidad, lo que ha supuesto un éxito en su adopción por parte de gran parte de las Administraciones Vascas.

2

Visión General del Proyecto Una vez implantada la versión 2 de la infraestructura, y muy especialmente tres de sus funcionalidades principales: • • •

Pago de cualquier formato de intercambio (formatos 57 y 60) TPV Virtual para pago con tarjetas emitidas por cualquier entidad financiera Pago con dispositivos móviles

se abre el camino para iniciar la exploración de nuevos usos, canales y aplicaciones de la Pasarela de Pagos. En esta línea, en el presente proyecto se pretende analizar la viabilidad de utilización de la infraestructura para tramitaciones utilizando dispositivos móviles. Tal y como se ha descrito anteriormente, la Pasarela de Pagos es una infraestructura consolidada, utilizada por decenas de Administraciones y que procesa miles de transacciones diariamente. Sin embargo, hasta el momento, el ámbito de utilización se ha limitado al canal web: pago utilizando un navegador de Internet (web-browser) -MSExplorer o Firefox- como interfaz de usuario. En el último año, se están empezando a implantar en las ventanillas de las Administraciones dispositivos que facilitan el proceso de pago: captura de código de barras y lectura de banda magnética de la tarjeta de crédito/débito, sin embargo, el interfaz sigue estando basado en el navegador (web-browser). Dado que la pasarela se concibió y diseñó como una infraestructura multi-canal, ha llegado el momento de abrir su utilización a otro tipo de interfaces de usuario como los dispositivos móviles: PDAs, teléfonos móviles, ordenadores ultra-portátiles (UMC-Ultra Mobile Computers), etc. Respecto al interfaz web-browser tradicional, los interfaces y conexión con la infraestructura son totalmente distintos en este tipo de dispositivos ya que tienen una serie de características particulares, entre otras: •

Normalmente disponen de pantallas de un tamaño reducido.

•

Los interfaces de captura de datos (teclados, ratón, lectores, etc) son limitados.

•

No todos los dispositivos disponen de interfaz web-browser (navegador) y en caso de disponer del mismo, no tiene las mismas funcionalidades que sus homólogos para PCs tradicionales.

•

La conexión es inalámbrica (WI-FI, GSM, GPRS, UMTS, HSDPA…) lo que implica limitaciones en algunos casos: ancho de banda o la disponibilidad de la red.

Dada la heterogeneidad en las soluciones de movilidad, parece razonable empezar a estudiar las posibilidades del “canal móvil” comenzando con un piloto del cual extraer conclusiones en cuanto a: •

Disponibilidad y funcionalidades de dispositivos móviles.

•

Usabilidad de los interfaces de usuario en estos dispositivos.

•

Conectividad y capacidad de datos.

El presente Proyecto va precisamente encaminado en este sentido: servir como piloto del cual extraer conclusiones extrapolables a cualquier aplicación para el “canal móvil”. Sin embargo, a pesar de

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Página: 7/54

constituir un piloto, los entregables del proyecto han de ser utilizables de forma inmediata en aplicaciones reales.

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

3

Página: 8/54

Necesidades Detectadas La Pasarela de Pagos es una infraestructura que desde su concepción inicial ha sido desarrollada y evolucionada por la DIAE contando con EJIE como consultor tecnológico; de esta forma, todas las decisiones funcionales y de negocio así como el diseño e implementación técnica se centralizan en el tándem DIAE-EJIE. Esto ha permitido tener un conocimiento y un control absoluto sobre el negocio y la tecnología; una de las bases del éxito de la Pasarela de Pagos. Sin embargo, teniendo como base el control sobre el núcleo de la infraestructura, hay aspectos de la misma para los cuales es imprescindible contar con agentes externos en funciones de consultoría tecnológica, administración del sistema, marketing, etc. Precisamente en esta línea, el proyecto resultante del presente Pliego de Bases Técnicas ha de dotar al proyecto global del conocimiento y experiencia en las siguientes áreas: •

Estado del arte en el mercado de dispositivos móviles en los que se pueda integrar una aplicación de tramitación.

•

Desarrollo de aplicaciones en dispositivos móviles, tomando como base la Pasarela de Pagos.

•

Infraestructuras necesarias para un ordenado despliegue de aplicaciones en dispositivos móviles.

•

Pautas de usabilidad para las aplicaciones a integrar en dichos dispositivos

•

Particularidades a tener en cuenta en las aplicaciones derivadas de su utilización en medios de conexión inalámbricos.

•

Plataformas de pago por móvil (tipo mobipay, etc) y su adaptación / posibles usos en el entorno de las Administraciones Públicas.

para esto, se hace necesario contar con una empresa de servicios de consultoría que aporte valor en cuanto a experiencia en proyectos de movilidad, conocimiento del mercado y tendencias.

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

4

Página: 9/54

Introducción a la Funcionalidad de Pago con Dispositivos Móviles El proceso de pago utilizando un dispositivo móvil es idéntico al proceso de pago desde una aplicación departamental si se asimila el dispositivo móvil a la aplicación departamental, con la única diferencia de que es el propio dispositivo el que hace la llamada a la Entidad Financiera.

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Paso

Fase

Página: 10/54

Descripción El dispositivo móvil en base a las pantallas de captura de datos adecuadas, genera un pago componiendo un mensaje XML (Petición de Pago no inicializada) que envía al Interfaz de Aplicaciones de la Pasarela de Pagos.

Identificación, Generación del Pago 1a (Petición de Pago), Validación y Registro

1b

2

3

Consolidación de la Petición de Pago en el sistema back-end de la Administración correspondiente

Recogida de la información de la tarjeta

Envío de los datos pago y de la tarjeta a la Entidad Financiera

El Interfaz de Aplicaciones pasa la petición de pago al Gestor de Pagos quien la valida y registra, devolviendo un resultado de operación que encapsula: a.

El pago inicializado, es decir, completado con descripciones, conceptos, etc de los que no dispone el dispositivo móvil.

b.

La url del servicio de pago móvil de la entidad financiera al que tiene que enviar el pago anterior.

Se consolida la petición de pago en el sistema back-end de la Administración para que posteriormente pueda ser “casado” con los cobros recibidos de la Entidad Financiera (paso 14) NOTA:

Este paso únicamente se realiza si se indica así en la Petición de Pago. En el caso del Gobierno Vasco el sistema back-end es SIPCA (Sistema de Cobros y Pagos de la Administración)

Con la Petición de Pago validada (es correcta) y registrada (respuesta OK), el dispositivo permite la captura de la información de la tarjeta de crédito: el ciudadano “pasa la tarjeta”. El dispositivo envía convenientemente encriptados los datos de la tarjeta a la Entidad Financiera que ofrece el servicio de TPV Virtual junto con los datos del pago (el XML de Pago devuelto por la Pasarela de Pagos en el paso 1a). IMPORTANTE:

La respuesta a esta petición http del dispositivo móvil a la Entidad Financiera es el resultado de la operación (ver paso 6b)

Ante la recepción de un mensaje XML de un ciudadano/a que desea realizar un pago online, la Entidad Financiera valida que dicho mensaje XML procede de la Pasarela de Pagos y que además no ha sido alterado. 4

Validación del Pago Para ello, envía un mensaje de validación a la Pasarela de Pagos, de igual forma que se hace en cualquier pago, independientemente del dispositivo (navegador web / dispositivo móvil)

5

Pago y consolidación en el back-end de la Entidad Financiera Consolidación back-end Entidad Financiera

La Entidad Financiera con los datos del pago (xml de pago) y los datos de la tarjeta realiza la transacción de pago directamente, devolviendo una respuesta de operación (xml) al terminal que inició la petición (no hay interfaz de usuario) adjuntando el resultado del pago. La Entidad Financiera consolida la transacción de pago en su sistema back-end. Posteriormente, y en función de los acuerdos individuales de intercambio de datos con cada una de las administraciones, los datos de los cobros recibidos se enviarán a la Administración correspondiente (paso 14). En este envío de cobros consolidados, la Pasarela de Pagos es transparente.

Resultado del Pago 6a (a la Pasarela de Pago) Resultado del Pago 6b (al dispositivo móvil)

7

Consolidación del Resultado de Pago

SPB 02 - 03/04

Tanto si el pago ha ido correctamente como si no ha sido así, la Entidad Financiera enviará un mensaje a la Pasarela de Pagos indicando el resultado del pago.

Como respuesta a la petición http que el dispositivo móvil inició en el paso 3, la Entidad Financiera devolverá el mismo mensaje de resultado que a la Pasarela de Pagos (paso 6a) La Pasarela de Pagos envía el resultado al Gestor de Pagos a través del Interfaz de Aplicaciones, que en función de dicho resultado actualiza el estado del pago, aunque no lo pasa al sistema back-end ya que los pagos realizados son enviados por otros métodos (editran) por las Entidades Financieras en función de acuerdos individuales con las Administraciones (paso 14)

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Página: 11/54

8

Envío a la aplicación departamental del resultado del pago

El Gestor de Pagos, re-envía la respuesta del pago recibida de la Entidad Financiera a una aplicación departamental.

9

Consolidación de la Petición de Pago en el sistema back-end de la Administración correspondiente

Las Entidades Financieras periódicamente y en función de acuerdos individuales con las Administraciones reciben los cobros recibidos que se consolidan en el sistema back-end con las liquidaciones emitidas.

NOTAS IMPORTANTES DE CONTEXTO •

En estos momentos todo el sistema que facilita el pago con dispositivos móviles está ya desarrollado y disponible, tanto en la parte de la Pasarela de Pagos como en la parte de la Entidad Financiera.

•

Se ha desarrollado un piloto de aplicación de tramitación para un dispositivo móvil cuyas características se explican en el anexo y que servirá como base de la aplicación que se requiere implementar como un producto del presente Proyecto.

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

5

Página: 12/54

Objeto: El objetivo del presente Pliego de Bases Técnicas es la contratación de los servicios profesionales necesarios para llevar a cabo el Proyecto de Pago y Tramitación con Dispositivos Móviles como un proyecto llave en mano que contará con la supervisión de la Dirección de Innovación y Administración Electrónica (DIAE).

6

Alcance Aunque más adelante se describe pormenorizadamente cada unos de los trabajos a realizar, en la siguiente tabla hace un resumen de los mismos: Plataformas de pago por móvil

Estudio de las plataformas comerciales para el pago utilizando el teléfono móvil en lugar de la tarjeta de crédito / débito. El estudio se centrará en la adaptación / adecuación y posibles usos de estas plataformas en el entorno de las Administraciones Públicas así como recopilación de experiencias previas en otras Administraciones o empresas privadas.

Selección y Provisión de dispositivos móviles

Teniendo en cuenta: • Los requerimientos técnicos y funcionales descritos en el presente Pliego de Bases Técnicas • Los requerimientos funcionales y de usabilidad de las aplicaciones a realizar dentro del alcance del proyecto. se realizará la selección y provisión de una unidad de dispositivo móvil y los periféricos necesarios de cada uno de los dos tipos de dispositivo y plataformas siguientes: Teléfono móvil (tipo PDA o similar)

• •

Plataforma Google Android Plataforma Microsoft Windows CE / Mobile

UMC/UMPC (Ultra Mobile Computer)

• •

Plataforma Windows XP / CE / Mobile Plataforma Linux

IMPORTANTE! •

En total, hay dos tipos de dispositivos con dos plataformas en cada caso.

•

La aplicación piloto de pago móvil debe funcionar en cada una de las plataformas anteriores, incluyendo la integración con los periféricos (impresora, lector de código de barras y lector de tarjeta)

•

El número de dispositivos a suministrar puede ser 4 (2 tipos de dispositivo x 2 plataformas) o menos si algún dispositivo soporta varias de estas plataformas.

Guía de Usabilidad Aunque el presente Proyecto es un piloto de utilización de dispositivos móviles, junto con la selección y provisión de dispositivos se incluirá una guía de usabilidad para el desarrollo de aplicaciones en cada uno de los dispositivos / plataformas.

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Estudio de Plataformas de Gestión de Dispositivos Móviles

Página: 13/54

La distribución de dispositivos móviles debe de estar soportada por una infraestructura que permita al menos: • La distribución remota de software desde un único punto a todos los dispositivos • El inventario de dispositivos El espíritu del presente proyecto es convertirse en un piloto del uso de dispositivos móviles en aplicaciones de tramitación en movilidad, NO tiene como objeto la implantación de una plataforma de gestión de dispositivos móviles, sin embargo, si puede ser un buen momento para estudiar las diferentes plataformas de gestión. Por lo tanto, el entregable correspondiente será un estudio de las diferentes alternativas para los sistemas de gestión de dispositivos móviles para las plataformas señaladas.

Aplicación de Configuración del dispositivo

De cara a ser utilizado para aplicaciones de pago móvil, el dispositivo normalmente habrá de ser configurado: • • •

Instalación de certificados para el cifrado HTTPS Instalación de token de seguridad para identificar el dispositivo de forma única en el sistema etc

Para ello, es necesaria una aplicación que automatice al máximo esta tarea a un técnico de instalaciones. Esta aplicación podría integrarse dentro de un sistema de gestión centralizada de dispositivos móviles, sin embargo, para el presente proyecto se limita a una aplicación instalada “manualmente” en el dispositivo y que facilite la configuración de cada uno de los tipos de dispositivo y en cada una de las plataformas.

Aplicación de captura de liquidaciones y pago móvil

Para cada uno de los dispositivos seleccionados se programará una aplicación que permitirá la captura de una / varias liquidaciones y su pago utilizando la funcionalidad de pago móvil de la Pasarela de Pagos. Como piloto de esta aplicación se ha desarrollado una aplicación de prueba que estará disponible para el adjudicatario (e incluso para los ofertantes si así lo solicitan) y que tiene todas las funcionalidades requeridas. La aplicación piloto es una aplicación Windows desktop “tradicional” (Windows XP/Vista) que se ha adaptado (visualmente) a un dispositivo móvil (Panasonic ToughBook) con una pantalla de dimensiones reducidas. La aplicación se describe en el anexo

Aplicación de tramitación con pago móvil

Para cada uno de los dispositivos seleccionados se programará una aplicación de tramitación simple que incluya un paso de pago dentro del flujo de la misma. La idea final es una aplicación de tramitación que “genere” una liquidación para cuyo pago se integra con la aplicación descrita en el punto anterior. La aplicación piloto de pago móvil originalmente se ha realizado para su integración con una aplicación de tramitación desktop (Windows) y también puede servir como ejemplo.

Estudio de Cobertura

SPB 02 - 03/04

Asociada a la selección y a las aplicaciones piloto, se realizará un estudio de conectividad (cobertura) utilizando los dispositivos seleccionados en puntos significativos que recojan la diversidad de la Comunidad Autónoma del País Vasco: principales municipios y sus infraestructuras ciudadanas: •

Edificios públicos, centros de congresos, oficinas de turismo, ferias de muestras, etc.

•

Estructuras de comunicaciones (aeropuertos, principales estaciones de tren, puertos, peajes, áreas de servicio y descanso de autopistas, etc.),

•

Municipios pequeños y medianos distribuidos en diversos puntos del territorio

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

7

Requisitos del bien o servicio:

7.1

Estudio de Plataformas de pago por móvil

Página: 14/54

Con el objetivo de estar al corriente del estado del arte de las plataformas comerciales de pago por móvil existentes en la actualidad (mobipay, paypal, etc), se realizará un estudio de las mismas, incidiendo especialmente en: •

La viabilidad tecnológica

•

La disponibilidad comercial

•

Los costes operativos para la Administración

•

Los posibles campos de utilización en la Administración

•

El horizonte de uso / despliegue

•

Implicaciones de la adopción de este modo de pago para la Administración: qué pasos tendría que dar la una Administración para incorporar el pago por móvil

•

Implicaciones tecnológicas (si las hay) en los sistemas de información de la Administración

El estudio deberá estar respaldado entre otras cosas con: •

Ejemplos de utilización comercial de este medio de pago en otras Administraciones / entidades privadas

• Información comercial y técnica de cada una de las plataformas estudiadas Se valorará, en caso de considerarse oportuno, la posibilidad de organizar reuniones con el servicio pre-venta de cada plataforma analizada.

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Página: 15/54

7.2

Selección y Provisión de Dispositivos Móviles

7.2.1

Selección y Provisión Uno de los objetivos del proyecto es la selección de tres dispositivos móviles con diferentes características para ser utilizados en función de la naturaleza del proyecto de tramitación móvil. Inicialmente se han identificado dos grupos de dispositivos móviles, aunque queda abierto al ofertante reducir o ampliar esta selección en sus ofertas. Los grupos de dispositivos móviles y plataformas inicialmente identificados son: Plataforma Grupo I

Móviles “estándar” de mercado

Teléfonos móviles de mercado con navegador, capacidad de procesamiento, etc.

Google Android Windows CE / Mobile

Grupo II

UMC/UMPC

UltraMobileComputers – Ordenadores UtraPortátiles: Ordenadores portátiles convencionales de tamaño reducido Thin Clients

Windows XP / Vista / CE / Mobile Linux

Para poder realizar esta selección, el adjudicatario deberá: •

Hacer una pre-selección inicial de dispositivos, para cada uno de los grupos así como de los periféricos necesarios para cada dispositivo.

•

Hacer un informe comparativo de los dispositivos, incluyendo una presentación al comité de seguimiento de los mismos que permita una selección final, para ello, el adjudicatario deberá encargarse de la relación con los fabricantes y proveedores para obtener unidades de muestra. La selección se hará en base a parámetros como: • • • • • • • • •

Robustez del dispositivo Tamaño de pantalla e interfaces de usuario (teclados, ratón, etc) Posibilidad de conexión de periféricos: impresoras, lectores de código de barras, banda magnética, chip, etc Facilidad de programación de aplicaciones: APIs / lenguajes disponibles, etc Posibilidades de conexión móvil Duración de las baterías Coste Integración con plataformas de gestión de dispositivos móviles Etc

Una vez seleccionado un dispositivo de cada grupo, el adjudicatario deberá proveer de dos unidades del mismo así como de todos los periféricos necesarios como entregable final del proyecto. Las unidades entregadas deberán ser plenamente operativas y las aplicaciones piloto objeto de este Pliego de Bases Técnicas deberán funcionar correctamente en todos los dispositivos seleccionados. El número de dispositivos físicos a proveer puede variar dependiendo de los modelos y de las plataformas soportadas en cada uno. El objetivo del proyecto es evaluar todas las plataformas anteriormente mencionadas (Google Android, Windows CE/Mobile para móviles “tradicionales” y Windows CE/Mobile/XP/Vista, Linux para UMPCs) NOTA: En el tiempo de duración del proyecto el adjudicatario se hará cargo de todos los costes de conexión (líneas, tráfico, etc) para los dispositivos móviles. Una vez entregados los mismos, estos costes serán asumidos por el Gobierno Vasco. SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

7.2.2

Página: 16/54

Guía de Usabilidad de las Aplicaciones Teniendo presente que el espíritu del Proyecto es servir como un piloto pero con aplicación real inmediata, un entregable del proyecto es una guía de buenas prácticas en aras a la usabilidad de las aplicaciones para cada uno de los dispositivos seleccionados. Esta guía debe proporcionar las pautas de usabilidad / recomendaciones para los interfaces de usuario para cualquier aplicación que se integre en cada uno de los dispositivos / plataformas. La guía de usabilidad debe estar adaptada a cada uno de los dispositivos / plataformas La guía de usabilidad debe incluir temas como:

7.2.3

•

Controles de interfaz de usuario

•

Disposición de controles en pantalla

•

Secuencias de navegación entre pantallas

•

Tamaños de letra

•

Uso de gráficos

•

etc

Características técnicas de los Dispositivos En la siguiente tabla se resumen las características técnicas obligatorias y opcionales que deben tener los dispositivos seleccionados: Plataforma (Sistema)

Capacidad de establecer conexiones HTTP/HTTPs Capacidad para incluir librerías de encriptación 3DES / DES Capacidad para almacenar certificados en un contenedor seguro Capacidad para programar interfaces de usuario Capacidad de almacenamiento de datos en local Kit de desarrollo de aplicaciones

Conectividad

WI-FI, WIMAX - opcional Móvil: GSM, GPRS, HSDPA y UMTS

Periféricos

Posibilidad de conexión de: • Impresora • Lector de código de barras • Lector de banda magnética de tarjetas de crédito/débito • Lector de tarjetas chip EMV • Lector de certificados digitales (IZENPE, DNI, etc)

Interfaces

Pantalla gráfica Teclado

Otros

Baterías de larga duración Resistencia a condiciones adversas: lluvia, golpes, etc - opcional

NOTA:

SPB 02 - 03/04

La lista anterior no pretende ser exhaustiva sino meramente orientativa. La definición final de las características técnicas se hará durante la ejecución del proyecto en base a las especificaciones funcionales de la DIAE y el proceso de selección del dispositivo.

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

7.3

Página: 17/54

Estudio de Plataformas de Gestión de Dispositivos La distribución de dispositivos móviles debe de estar soportada por una infraestructura que permita al menos: •

La distribución remota de software desde un único punto a todos los dispositivos

•

El inventario de dispositivos

El espíritu del presente proyecto es convertirse en un piloto del uso de dispositivos móviles en aplicaciones de tramitación en movilidad, NO tiene como objeto la implantación de una plataforma de gestión de dispositivos móviles, sin embargo, si puede ser un buen momento para estudiar preliminarmente las diferentes plataformas de gestión y su adecuación a los dispositivos seleccionados. Por lo tanto, el entregable correspondiente será un estudio de las diferentes alternativas para los sistemas de gestión de dispositivos móviles para las plataformas señaladas: Plataforma Grupo I

Grupo II

SPB 02 - 03/04

Móviles “estándar” de mercado UMC/UMPC

Teléfonos móviles de mercado con navegador, capacidad de procesamiento, etc. UltraMobileComputers – Ordenadores UtraPortátiles: Ordenadores portátiles convencionales de tamaño reducido Thin Clients

Plataforma Google Android Plataforma Windows CE / Mobile Plataforma Windows XP / Vista / CE / Mobile Plataforma Linux

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

7.4

Página: 18/54

Aplicación de Configuración del Dispositivo De cara a permitir la utilización para el Pago Móvil, los dispositivos han de ser configurados, inicialmente con los siguientes parámetros (pueden aparecer más en la definición detallada del proyecto durante la fase de diseño): Cadena pública de certificación del servidor de la Pasarela de Pagos

Para poder establecer una comunicación HTTPS con la Pasarela de Pagos será necesario instalar los certificados públicos utilizados en www.euskadi.net, actualmente certificados de IZENPE.

Cadena pública de certificación del servidor de la Entidad Financiera que proporciona la funcionalidad de Pago Móvil.

Para poder establecer una comunicación HTTPS con la Entidad Financiera que proporciona la funcionalidad de pago móvil (en estos momentos BBK), será necesario instalar los certificados públicos utilizados en dicha Entidad Financiera.

Token identificativo del dispositivo

De cara a identificar el dispositivo en el sistema, el procedimiento inicialmente planteado se basa en la instalación de un token (algún tipo de fichero) que identificará unívocamente al dispositivo.

Tokens de encriptación de la tarjeta de crédito / debito

Dado que la captura de los datos de la tarjeta de crédito / débito se realiza en el dispositivo móvil, han de ser transmitidos a la Entidad Financiera encriptados. Para realizar la encriptación, es necesario utilizar una clave que hay que configurar en el dispositivo.

Tokens de encriptación de datos para aplicaciones

En ocasiones puede ser necesario encriptar datos antes de enviarlos a un sistema backend. Para realizar la encriptación específica de cada aplicación, es necesario utilizar una clave que hay que configurar en el dispositivo.

En caso de ser necesaria alguna aplicación cliente a instalar en un puesto de sobremesa (PC), esta deberá respetar las tecnologías homologadas por el Gobierno Vasco. Así mismo, en caso de ser necesarias, se suministrarán las licencias necesarias para su instalación en 20 puestos.

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

7.5

Página: 19/54

Aplicación de captura de liquidaciones y pago móvil La aplicación de captura de liquidaciones y pago móvil es en grandes líneas la implementación / “porting” de la actual aplicación de pago de liquidaciones de www.euskadi.net/mipago en cada uno de los dispositivos móviles seleccionados, utilizando periféricos de captura (lectores de código de barras / banda magnética) así como la impresión de los justificantes de pago. Se ha desarrollado una aplicación piloto que se describe en el ANEXO y que básicamente tiene todas las funcionalidades requeridas; a continuación se hace una introducción a las mismas:

7.5.1

Descripción General de la Funcionalidad de la Aplicación La aplicación básicamente permite ir capturando liquidaciones en un lote para posteriormente proceder a su pago en una entidad financiera, tal y como se detalla a continuación en base a la tramitación actual en el canal web (web-browser) como referencia: Introducción de la ráfaga bancaria de las liquidaciones La introducción se puede hacer tecleando los dígitos de la ráfaga o capturando la misma a utilizando un lector de código de barras El interfaz debe permitir acumular un “lote de pagos”: capturar varias liquidaciones para proceder a su pago de forma conjunta.

Selección de la Entidad Financiera que proporciona el pago móvil Una vez formado el lote de pagos (normalmente una sola liquidación), hay que seleccionar la Entidad Financiera donde se va a realizar el pago. Actualmente solamente hay una única Entidad Financiera que proporciona esta funcionalidad de pago con dispositivos móviles, sin embargo, no se descarta la incorporación de otras Entidades en un futuro. Captura de los datos de la tarjeta de crédito / débito

Se leerá la información del número de tarjeta utilizando algún dispositivo de lectura de banda magnética / chip EMV. En caso de no ser posible la lectura de la banda, deberá ser posible la captura manual del número.

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Página: 20/54

Confección de los justificantes de pago La funcionalidad de pago con dispositivos móviles implementada por BBK no tiene interfaz de usuario, simplemente envía un mensaje de pago (XML) a la Entidad Financiera y devuelve otro mensaje (XML) con el resultado del pago de cada una de las liquidaciones del lote. Tomando como referencia los pasos de pago descritos anteriormente, el objetivo de esta parte del proyecto es implementar la misma funcionalidad en cada uno de los dispositivos / plataformas y sus periféricos, para ello básicamente hay que utilizar los servicios de la Pasarela de Pagos ofrecida por el Gobierno Vasco y la funcionalidad de Pago Móvil ofrecida por las Entidades Financieras.

La utilización de los servicios de Pasarela de Pagos se basa en el envío y recepción de mensajes XML al servidor correspondiente utilizando HTTPS como protocolo de nivel de aplicación. Los detalles de los mensajes a intercambiar se encuentran en la amplia documentación disponible en http://www.testpago.euskadi.net

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Página: 21/54

En el siguiente diagrama de secuencia se detallan las interacciones entre el dispositivo móvil, la pasarela de pagos y la Entidad Financiera.

Básicamente el dispositivo móvil actúa como una Aplicación Departamental enviando él mismo XML la Petición de Pago a la Pasarela de Pagos. Si la Petición de Pago se valida y registra correctamente en la Pasarela de Pagos (se recibe un OK de la pasarela de pagos), el dispositivo móvil permite capturar la información de la tarjeta del ciudadano, bien de la banda magnética. Una vez se tiene la información de la tarjeta, se envían los datos de la tarjeta junto con los datos del pago a una zona especial de pago para dispositivos móviles en la web de la Entidad Financiera. La Entidad Financiera valida los datos del pago (los mismos que en cualquier pago que venga de la Pasarela de Pagos) y con la información de la tarjeta puede realizar directamente una operación en el TPV Virtual devolviendo al terminal que inició la llamada una respuesta. Con esta respuesta, el dispositivo móvil debe de ser capaz de imprimir un justificante de pago mínimo para entregar al ciudadano. SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Página: 22/54

Es importante señalar que en ningún momento datos de la tarjeta del ciudadano pasan por servidores de la Administración: los datos van directamente desde el dispositivo móvil de captura a la zona de TPV Virtual de la Entidad Financiera. Únicamente pasan por el dispositivo móvil de captura, donde no se van a almacenar ni transferir a un servidor / base de datos. Por otro lado, dado que el dispositivo actúa como una aplicación departamental, se garantiza: •

La integración en los sistemas back-end de la administración (SIPCA en el caso del Gobierno Vasco) Ej: La Entidad Financiera enviará los pagos en movilidad en el fichero de pagos junto con el resto de pagos recibidos por otros medios (cajeros, presencial, internet, etc)

•

La recepción de eventos de pago en una aplicación departamental. Ej: Informar on-line a un “listener” departamental cuando se completa (confirma) un pago Una aplicación de back-end que estuviera on-line al corriente de los pagos que se están haciendo remotamente con los dispositivos móviles ya que va a recibir un evento on-line por cada pago realizado.

Durante el tiempo de desarrollo de la aplicación, se contará con el soporte técnico de EJIE en lo que se refiere a: • • • •

7.5.2

Detalles técnicos de bajo nivel Detalles en los mensajes XML Depuración de las conversaciones en base a mensajes Cualquier detalle técnico / funcional relativo a la integración con la infraestructura de la Pasarela de Pagos.

Pago en condiciones de “no conectividad” Hay ocasiones donde el proceso de pago ha de realizarse en condiciones de no conectividad (pe no hay cobertura de conexión de datos móvil); en estos casos obviamente no se puede contactar con la Pasarela de Pagos ni con la Entidad Financiera, así que la aplicación de pago móvil deberá guardar temporalmente los detalles de los lotes de pago (liquidaciones), la Entidad Financiera seleccionada y el número de la tarjeta de crédito / débito para proceder a su tramitación cuando se restablezca la conectividad. Cuando el dispositivo no puede conectar con la Pasarela de Pagos para inicializar el pago (ver secuencia en el punto anterior), se considerará que se está en condiciones de “no conectividad”, así que la aplicación debe indicar esta circunstancia y preguntar si se desea trabajar en modo de “no conectividad”. En caso afirmativo, el proceso de pago es idéntico al normal, solo que en lugar de enviar los datos de liquidación(es) y tarjeta de crédito a la Entidad Financiera, se almacenan internamente para su procesamiento posterior. De la misma forma que cuando la aplicación opera de modo “conectado”, se emitirá un justificante de pago al ciudadano, sin embargo, en el mismo se indicará claramente que el pago no está confirmado (de hecho no incluirá NRC –número comprobante- ya que obviamente, cuando se opera de esta forma, no se puede asegurar que la tarjeta de crédito / débito es válida, que el ciudadano tiene fondos suficientes, etc.

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Página: 23/54

Una vez que el dispositivo está en condiciones de contactar con la Pasarela de Pagos y las Entidades Financieras, deberá ofrecer la posibilidad de proceder al pago de cada uno de los lotes almacenados. El proceso de pago será idéntico al normal eliminando los pasos de captura de datos de liquidación y tarjeta de crédito / débito: 1. Se toma una liquidación(es) almacenada junto con la Entidad Financiera y el número de la tarjeta de crédito / débito. 2. Se inicializa el pago en la Pasarela de Pagos 3. Dado que ya se disponen de los datos de la tarjeta de crédito / débito, se enviarán directamente los datos a la Entidad Financiera. 4. Se imprimirá el justificante de pago 5. Se descartará la liquidación(es) y se continuará con la siguiente.

7.5.3

Detección de condiciones de conectividad En muchas ocasiones es útil conocer las condiciones de conectividad de un punto concreto, por ejemplo, en el caso de un cuerpo de policía, si se quiere montar un punto de control de velocidad, normalmente se escogerá un punto donde los ciudadanos puedan realizar directamente el pago. Para facilitar situaciones como la anterior la aplicación deberá dar la posibilidad de detectar las condiciones de conectividad simplemente haciendo un intento de conexión con la Pasarela de Pagos utilizando el protocolo de aplicación HTTPs; en caso de que la Pasarela de Pagos sea accesible, se indicará que el punto “tiene conectividad”, en caso contrario (no hay cobertura) se indicará lo contrario. NOTA:

SPB 02 - 03/04

En principio, no se trata de una medida de la cobertura o de la “potencia de la señal de red”, simplemente de detectar si hay conectividad o no la hay.

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

7.6

Página: 24/54

Aplicación de tramitación con pago móvil Será responsabilidad de la Dirección de Innovación y Administración Electrónica (DIAE) la definición de la aplicación piloto concreta a integrar en el dispositivo y con la Pasarela de Pagos Móvil.

7.6.1

Aplicación Departamental conectada con la aplicación de tramitación de pago móvil Tomando como base la aplicación de pago anteriormente descrita, se trata de utilizar la Pasarela de Pagos cuando se llega desde una aplicación de tramitación, es decir, cuando no se parte de una liquidación en papel con código de barras sino que la liquidación es generada “on-line” en una aplicación de tramitación. Para esto, se plantea la creación de una pequeña aplicación de tramitación que integre como paso final un pago móvil, así la aplicación permitirá la captura de alguna información relativa al expediente y finalmente generará una liquidación que se podrá pagar directamente en la Pasarela de Pago móvil (la aplicación descrita en los puntos anteriores) Inicialmente y de cara a la estimación del proyecto, el flujo de tramitación será similar al del siguiente diagrama:

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

7.6.2

Página: 25/54

Envío de eventos desde el móvil a un sistema back-end De la misma forma que se envían datos a la Pasarela de Pagos y a la Entidad Financiera, cuando el trámite comience en una aplicación departamental, normalmente se requerirá el envío de información a un sistema backend. Como ejemplo de cómo puede un sistema backend recibir datos del dispositivo móvil, se desarrollará el esqueleto de un servicio de escucha de mensajes recibidos desde el dispositivo móvil. En este punto también habrá que tener en cuenta las condiciones de no conectividad por lo que la aplicación deberá almacenar temporalmente los eventos para enviarlos al sistema back-end en el momento que exista conexión con el sistema back-end

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

8

Página: 26/54

Descripción entregables En la siguiente tabla se detallan los entregables en base a los trabajos a realizar: Estudio de Plataformas de pago por móvil

•

Estudio en el que se detalle el estado del arte y la capacidad para implementar a corto plazo el pago utilizando móvil en base a plataformas comerciales.

Selección y Provisión de dispositivos móviles

•

Informe comparativo y presentación al comité de seguimiento de unidades y periféricos necesarios de cada uno de los grupos de dispositivos.

•

Selección de dispositivos base para el desarrollo de la Pasarela de Pagos Móvil y la aplicación de tramitación de ejemplo: Plataforma Grupo I

Móviles “estándar” de mercado

Teléfonos móviles de mercado con navegador, capacidad de procesamiento, etc.

Grupo II

UMC/UMPC

UltraMobileComputers – Ordenadores UtraPortátiles: Ordenadores portátiles convencionales de tamaño reducido Thin Clients

Plataforma Google Android Plataforma Windows CE / Mobile Plataforma Windows XP / Vista / CE / Mobile Plataforma Linux

•

Suministro de dos unidades plenamente operativas del dispositivo seleccionado de cada uno de los grupos/plataformas así como de los periféricos necesarios (inicialmente lector de código de barras, lector de datos de tarjeta de crédito/débito e impresora).

•

Manual de instalación y configuración de los dispositivos y de los periféricos necesarios.

•

Guía de usabilidad para el desarrollo de aplicaciones para cada uno de los dispositivos.

•

Informe de estudio de conectividad (cobertura) de cada uno de los dispositivos seleccionados y utilizando la aplicación de Pago Móvil en distintos puntos seleccionados que recojan la diversidad de la Comunidad Autónoma del País Vasco: Principales municipios y sus infraestructuras ciudadanas como edificios públicos, centros de congresos, oficinas de turismo, ferias de muestras, etc

10 puntos en cada una de las tres provincias de la CAPV (total 30 puntos)

Estructuras de comunicaciones como aeropuertos, principales estaciones de tren, puertos, peajes, áreas de servicio y descanso de autopistas, etc Cata en municipios pequeños y medianos distribuidos en diversos puntos del territorio, etc Principales atractivos turísticos de la CAPV

15 puntos en cada una de las tres provincias de la CAPV (total 60 puntos)

El estudio de conectividad deberá estar respaldado / soportado por los datos públicos de cobertura de la operadora móvil seleccionada.

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Aplicación de Configuración del Dispositivo

•

Aplicación de captura de liquidaciones y pago móvil

•

• • •

SPB 02 - 03/04

Fuentes de la aplicación y documentación detallada de compilación para cada dispositivo Procedimiento de instalación de la aplicación en cada dispositivo. Manual de Usuario En caso de ser necesaria la instalación de alguna aplicación de PC y en caso de requerir esta licencia de uso, se suministrarán las licencias para la 10 puestos.

• •

Análisis de funcionalidades a implementar consensuadas con la DOMA. Prototipo “en papel” de la operativa y pantallas de la aplicación. Diseño técnico de la arquitectura de la aplicación. Aplicación de captura de liquidaciones y pago móvil plenamente operativa en cada uno de los dispositivos e integrada con los periféricos correspondientes (lector de código de barras, tarjeta de crédito/débito e impresora) Fuentes de la aplicación y documentación detallada de compilación para cada dispositivo Procedimiento de instalación de la aplicación en cada dispositivo. Manual de Usuario

•

Análisis de funcionalidades a implementar consensuadas con la DIAE

•

Prototipo “en papel” de la operativa y pantallas de la aplicación.

•

Diseño técnico de la arquitectura de la aplicación.

•

Aplicación de tramitación que incluye un paso de pago móvil en su flujo de tramitación, plenamente operativa en cada una de los dispositivos e integrada con los periféricos correspondientes.

•

Fuentes de la aplicación y documentación detallada de compilación para cada dispositivo

•

Procedimiento de instalación de la aplicación en cada dispositivo

•

Manual de usuario

•

Prototipo de una aplicación en backend que recibe mensajes de datos desde el dispositivo móvil.

• • •

•

Aplicación de tramitación con pago móvil

Página: 27/54

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

9

Entorno Tecnológico

9.1

Tecnologías de Servidor

Página: 28/54

En la siguiente tabla se detallan las tecnologías de servidor homologadas por el Gobierno Vasco utilizables en el presente proyecto: Producto Base de Datos

Oracle

Servidor Web

Apache

Servidor de Aplicaciones

BEA Weblogic

Entorno Java

J2SE J2EE

9.2

Entorno Cliente Web Todos los desarrollos se validarán y testearán para su funcionamiento en los siguientes navegadores web: Aplicaciones Intranet / Extranet

Internet Explorer 6 + Mozilla Firefox 3 +

Aplicaciones Internet

Internet Explorer 6 + Mozilla Firefox 3 + Safari Google Chrome

Será responsabilidad del adjudicatario las pruebas de funcionamiento en los diferentes navegadores web. NOTA:

SPB 02 - 03/04

Las posibles evoluciones de las versiones de los productos sobre los que se sustentará el producto y los efectos de estos cambios durante el desarrollo serán asumidos por la empresa adjudicataria.

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

9.3

Página: 29/54

Herramientas Las herramientas normalizadas para la ejecución de proyectos informáticos son: Herramientas Ofimáticas

IDE de Desarrollo

o

Microsoft Office 2003 (Word, Excel y PowerPoint)

o

Microsoft Visio 2003

o

Eclipse 3.X

o

MyEclipse 8.X + XDoclet

o

Servidor de aplicaciones instalado en local e integrado con el IDE Eclipse

NOTA: Es responsabilidad del adjudicatario la instalación y el correcto funcionamiento de los entornos de desarrollo en los equipos de los programadores.

9.4

Pruebas e Implantación Es responsabilidad del adjudicatario la realización de un Plan de Pruebas que ha de incluir dos tipos de pruebas: Pruebas

Descripción

Pruebas Funcionales

Tienen como objetivo la comprobación del correcto funcionamiento de todos los puntos de la aplicación, tanto interfaz de usuario como APIs programáticos

Pruebas de Rendimiento

Tienen como objetivo la comprobación del desempeño de la aplicación en servidor bajo carga de trabajo

Entorno de Realización o Equipo (PC) de Pruebas o

Entorno de Desarrollo de EJIE

o

Entorno de Pruebas de EJIE

La implantación en los entornos de EJIE será coordinada por personal de EJIE, sin embargo, se requiere la asistencia por parte del adjudicatario en todas las tareas de implantación para la resolución de cualquier duda / problema que en este proceso de implantación pueda surgir.

El adjudicatario deberá entregar un manual de implantación y será responsable de actualizarlo ante cualquier error, omisión o sugerencia al mismo. En todos los desarrollos se tendrán en cuenta las normativas de implantación y albergue asociadas a la distribución de componentes en Internet, extranet e intranet El adjudicatario deberá proponer en la oferta su metodología para el plan de pruebas e implantación, así como prever tanto recursos como tiempo en la planificación para su realización.

Los trabajos NO se considerarán terminados hasta que el producto esté instalado y funcionando correctamente en el entorno de PRODUCCIÓN de EJIE SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

9.5

Página: 30/54

Tratamiento del Idioma La política de tratamiento del idioma será la siguiente: Aplicaciones de Intranet / Extranet

Funcionamiento bilingüe: euskera / castellano, dejando abierta la posibilidad a cualquier otro idioma

Aplicaciones Internet

Funcionamiento multilingüe según el caso, con el mínimo de euskera / castellano, se definirá el uso de otros idiomas en caso de ser necesario.

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

9.6

Página: 31/54

Tecnologías Homologadas Además de las tecnologías de base, el Gobierno Vasco ha homologado las siguientes para su utilización: Sistemas de Seguridad

Firma Digital

Gestión de Contenidos Web

XLNETs V 2.0 −

Autenticación de usuarios

−

Almacenamiento de cualquier parámetro de seguridad como permisos de acceso a módulos de la aplicación, permisos sobre acciones, claves de base de datos, etc.

−

Almacenamiento de parámetros generales de la aplicación (INIs o .properties)

Los casos de uso en los que será necesaria la Firma Digital serán entre otros: −

Control de acceso a datos personales

−

Firma digital de documentos

−

Huella digital de documentos (hash)

−

Gestor de Contenidos

−

Gestor de Portales

−

Publicador

−

Gestor de Ejes de Catalogación

−

Buscador

Infraestructura Tecnológica de Base para la Tramitación

Frameworks

En general se deberán reutilizar al máximo los posibles componentes software existente actualmente en EJIE. Así mismo, el diseño del software se hará de forma modular con el objetivo de facilitar el mantenimiento del software y alargar su ciclo de vida. El diseño técnico y la calidad del software serán supervisados por los técnicos de EJIE que revisarán y en su caso designarán los patrones de diseño y programación a utilizar.

Se tendrá en cuenta la utilización de estas tecnologías en el desarrollo de las aplicaciones.

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

10

Gestión del Proyecto

10.1

Metodología

Página: 32/54

La gestión del proyecto objeto del presente Pliego de Bases Técnicas se basará en la adaptación al mismo de la metodología y buenas prácticas descritas en el Project Management Body Of Knowledge publicado por el Project Management Institute que identifican un ciclo de gestión basado en cinco grupos de procesos: Iniciación

•

Fundación del proyecto: definición de objetivos generales (alcance inicial), equipo, riesgos, etc

NOTA: El Presente Pliego de Bases técnicas y la oferta correspondiente se pueden considerar como un documento del grupo de procesos de iniciación ya que define en algún grado el alcance

Planificación

•

• • •

La gestión de proyectos es iterativa: el producto se va definiendo cada vez más conforme se va conociendo más acerca del mismo durante la ejecución del proyecto.

Ejecución

•

Monitorización • y Control

• Cierre

•

Definir con el mayor grado de precisión posible el alcance del proyecto. Planificar los costes, calendario y recursos Definir estándares de calidad y aceptación Identificar riesgos y definir estrategias de mitigación y actuación. Dirigir la ejecución del trabajo según lo especificado en el plan Verificar que el trabajo que se está realizando se ajusta a lo especificado en el plan en cuanto a costes, calendario, calidad. Identificar la aparición de riesgos

•

Archivado de documentación de proyecto Lecciones aprendidas

•

Cierre administrativo

En este punto hay que señalar que la metodología anterior es una metodología de gestión del proyecto que no es lo mismo que el ciclo de vida de un proyecto que es: •

Las fases en que se divide un proyecto: aquellas que conectan el principio del proyecto con el final del mismo.

•

Describe qué hay que hacer para hacer el trabajo del proyecto

En el presente proyecto, el software se desarrollará iterativamente enfocando hacia la solución a medida que se vaya definiendo el sistema, esto implica que el desarrollo comenzará una vez terminada la planificación, específicamente sin esperar a tener un análisis funcional o un diseño técnico cerrados. Esta estrategia tiene un cierto riesgo de repetición de trabajo pero controlando el riesgo adecuadamente, puede contribuir a una mayor calidad y menor tiempo de construcción.

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Página: 33/54

Esta estrategia de “comienzo temprano” del desarrollo permitirá detectar riesgos técnicos en estadios iniciales de desarrollo y redundará en una involucración y conocimiento técnico del sistema por parte de todo el equipo desde el principio de proyecto. En la práctica, una vez adjudicado el proyecto: 1. La dirección del proyecto DIAE-EJIE “fundará” el proyecto: a. Nombrando un Project Manager que será la autoridad responsable de la gestión del proyecto b. Proporcionando el entorno para la ejecución del mismo c. Identificando las personas y entidades implicadas o afectadas por el proyecto d. Definiendo los objetivos de alto nivel del proyecto e. Definiendo las restricciones (de tiempo, expectativas, etc) y asunciones iniciales 2. La empresa adjudicataria, trabajando bajo la autoridad de la dirección del proyecto definirá el plan de proyecto: a. Definirá con la mayor exactitud posible el alcance del proyecto b. Realizará una descomposición de los trabajos y tareas al mayor nivel de desglose posible c. Realizará una planificación en tiempo y costes para la ejecución de los trabajos identificados d. Realizará un plan de comunicación fundamentalmente encaminado a: i. Obtener informes puntuales y exactos del rendimiento de la ejecución de cada uno de los trabajos ii. Mantener a los implicados / afectados en el proyecto al día de aquello que les interesa e. Identificará los riesgos y los planes de respuesta f. Definirá los estándares de calidad para la aceptación de cada uno de los entregables 3. Una vez definido el plan de proyecto, el equipo de proyecto comenzará la ejecución de las tareas definidas en el plan. 4. La monitorización y control del proyecto será realizado por el Project Manager del proyecto contando con la colaboración del staff de gestión de la empresa adjudicataria para: a. Identificar cambios en el alcance b. Detectar desviaciones en tiempo y costes c. Detectar desviaciones en la calidad de los trabajos realizados. d. Identificar la eventual aparición de un riesgo identificado NOTA: Cualquier cambio, corrección, mejora, etc requerirá de planificación 5. Finalmente cuando todos los entregables del proyecto se hayan llevado a cabo, se entrará en la fase de cierre del proyecto que implica principalmente: a. Recopilación de la documentación del proyecto b. Recopilación de lecciones aprendidas c. Liberación del equipo Es importante recalcar que el procedimiento de gestión del proyecto es iterativo en línea con los ciclos de mejora PDCA (Plan-Do-Check-Act), por lo tanto, los grupos de proceso anteriores no son grupos cerrados ni secuenciales sino que debido a la naturaleza de elaboración progresiva de los proyectos, podrán ser “visitados” de forma iterativa a lo largo de la vida del proyecto.

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

10.2

Página: 34/54

Equipo de Proyecto El equipo de proyecto será el siguiente: Gobierno Vasco

Empresa Adjudicataria

Rol

Funciones

Funciones en el proyecto

Dirección de Innovación y Administración Electrónica (DIAE)

Dirige y marca las directrices en cuanto a digitalización de servicios en la Administración General del País Vasco.

o Sponsor del proyecto o Liderazgo del proyecto o Proporciona las condiciones para la realización del proyecto

Jefe de Proyecto de la Dirección de Innovación y Administración Electrónica (DIAE)

Responsable funcional del proyecto

o Sponsor del proyecto o Especificaciones funcionales o Coordinación con los usuarios de negocio o Pruebas de negocio

Jefe de Proyecto de la DIT

Responsable tecnológico

o Fijar tecnología

Jefe de Proyecto de la Asistencia Técnica EJIE

Responsable de la ejecución en la parte informática del proyecto.

o Project Management: gestión del alcance, comunicaciones, riesgos, calidad y recursos del proyecto. o Coordinación con el resto de áreas de EJIE

Staff técnico de EJIE adscrito al proyecto

Apoyo técnico

o Especificaciones técnicas o Pruebas técnicas: monitorización, carga, alta disponibilidad, etc o Coordinación técnica: implantación, pruebas, etc

Usuarios de negocio

Usuarios finales del sistema

o Especificaciones funcionales o Pruebas de negocio

Rol

Funciones

Conocimientos necesarios / Experiencia

Gestor del proyecto

Seguimiento global de la evolución y progreso

•

Dirección del proyecto

•

Proyectos en aplicaciones similares con dispositivos móviles

• • • •

Java HTML-CSS XML Plataformas de base de los dispositivos móviles seleccionados

Seguimiento y coordinador de los recursos humanos asignados al proyecto. Interlocución con la Dirección de Innovación y Administración Electrónica/ EJIE en lo que al seguimiento del proyecto se refiere

Responsable Funcional

Consultoría funcional Consultoría tecnológica dispositivos.

en

la

selección

de

Consultoría de usabilidad Coordinación del equipo técnico e interlocución con los responsables funcionales de la DIAE-EJIE Responsable Técnico

Implementación de los pilotos en las plataformas seleccionadas

NOTAS sobre el Equipo de Trabajo y Organización SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Página: 35/54

El presente proyecto como todos los proyectos es un esfuerzo temporal en el que se comprometen una serie de recursos para crear un producto único y como tal es muy importante que el equipo de proyecto tenga la capacidad suficiente para abordar el trabajo y que además permanezca estable durante el desarrollo del mismo. Por la razón descrita, el adjudicatario intentará (en la medida de lo posible) mantener un equipo estable de personas que intervendrán en el proyecto según lo planificado en el Plan de Proyecto Teniendo en cuenta que: • Se debe proponer un equipo de proyecto estable • El proyecto tiene una alta componente de innovación (no es un proyecto de mantenimiento de datos al uso) • El desarrollo se hará de forma iterativa desde las fases iniciales del proyecto • Debe de haber una alta interacción con DIAE-EJIE el equipo de trabajo debe tener las siguientes características: • Altamente especializado: técnicos con contrastada y demostrada experiencia en análisis y arquitectura técnica • Mantenerse lo más reducido posible y conservando un “core” (nucleo) estable, complementado con la intervención puntual de especialistas en algunas de las áreas Es decir, el equipo de proyecto estable y que será responsable del grueso del trabajo será lo más reducido posible y estable durante toda la vida del proyecto. Se propone que esté compuesto por: • Project Manager • Analista Funcional • Arquitecto Técnico • Técnico responsable de los desarrollos en los dispositivos para trabajos específicos y apoyos puntuales se dispondrá de refuerzos que intervendrán en el proyecto según la planificación.

10.3

Recursos Materiales: Lugar de trabajo y equipamiento Lugar de Trabajo

En las dependencias del Adjudicatario

Disponibilidad horaria

Horario de trabajo del Gobierno Vasco

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

10.4

Página: 36/54

Organización del Proyecto y Estructuras de Control Pese a que la organización exacta del proyecto tal y como se ha descrito anteriormente se definirá exactamente en las fases de iniciación y planificación del proyecto, hay una estructura mínima que existirá a lo largo de la vida del proyecto:

•

Visión del proyecto a nivel de dirección

Comité de Dirección

Componentes

Reuniones

→ → →

Dirección de la DIAE Dirección de Proyecto de DIAE-EJIE Dirección de Proyecto del Adjudicatario

→

Cualquier persona de la que se considere necesario su asistencia

→

Lugar: Gobierno Vasco

→ Temas

→ → → → →

•

Entorno del proyecto: protección de las condiciones de existencia del mismo. Evolución y seguimiento del proyecto Variaciones en el alcance Certificaciones parciales Cualquier tema relativo al proyecto que se considere necesario

Control de alcance: es de vital importancia controlar el alcance del proyecto y que este se ajuste a lo planificado.

Comité de Cambios

Componentes

Reuniones

→ →

Dirección de Proyecto de DIAE-EJIE Dirección de Proyecto del Adjudicatario

→

Cualquier persona de la que se considere necesario su asistencia

→

Lugar: Gobierno Vasco

→ Temas

→ →

•

Periodicidad: mensual o en función de las necesidades puntuales del proyecto, en base a convocatorias formales por parte de la dirección de proyecto del Adjudicatario o de DIAE-EJIE

Periodicidad: quincenal o en función de las necesidades puntuales del proyecto, en base a convocatorias formales por parte de la dirección de proyecto del Adjudicatario o de DIAE-EJIE Verificación del alcance: verificar que se está trabajando única y exclusivamente en el alcance definido. Variaciones en el alcance: aprobación / Rechazo de cambios de alcance

Comité técnico: Dado que el proyecto tiene una alta componente tecnológica y se desarrolla en el entorno de EJIE, se considera imprescindible definir un comité técnico para tratar de minimizar riesgos técnicos y agilizar trámites relacionados con la infraestructura.

Comité de Técnico

Componentes

Reuniones

→ →

Staff técnico de EJIE Staff técnico del adjudicatario

→

Cualquier persona de la que se considere necesario su asistencia

→

Lugar: EJIE

→ Temas

SPB 02 - 03/04

→ → →

Periodicidad: en función de las necesidades puntuales del proyecto, en base a convocatorias formales por parte de la dirección de proyecto del Adjudicatario o de DIAE-EJIE Aspectos técnicos o de diseño del sistema Identificar riesgos técnicos. Agilizar trámites relacionados con la infraestructura Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Página: 37/54

NOTAS IMPORTANTES A TENER EN CUENTA:

•

El control y seguimiento del proyecto se hará utilizando la metodología, herramientas y directrices designadas por DIAE.

•

Se levantará acta de cuantas reuniones formales se realicen

•

El adjudicatario deberá poner a disposición de los responsables de DIAE toda la documentación del proyecto mientras se está elaborando en un servidor de trabajo colaborativo (Microsoft SharePoint o similar) que EJIE dispondrá específicamente para el proyecto. En otras palabras: los responsables de DIAE-EJIE deben poder acceder a cualquier documento relacionado con el proyecto en cualquier fase de su elaboración (aunque no esté terminado ni entregado)

•

De la misma forma el código del proyecto debe ser almacenado y versionado en un servidor subversión del entorno de desarrollo de EJIE de forma que los responsables técnicos de EJIE deben poder acceder al código en cualquier momento.

IMPORTANTE Si alguna de estas normas no es respetada, puede dar lugar a la no aceptación de los entregables involucrados.

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

11

Página: 38/54

Puntos de Riesgo A continuación se detallan los puntos de riesgo inicialmente identificados y ante los cuales los ofertantes deben incluir una descripción de sus propuestas de acciones mitigadoras:

12

Disponibilidad de los dispositivos

Posibilidad para obtener dispositivos de muestra, periféricos, etc

Conocimiento de la tecnología

Disponibilidad de personas con conocimiento de la tecnología concreta a utilizar en cada dispositivo

Soporte del fabricante

Soporte del fabricante ante necesidades no soportadas inicialmente, bugs, etc

Plazo de entrega

Plazo de entrega ajustado

Procedimientos de Calidad La gestión del proyecto se realizará según las normas procedimentales y de calidad de la Gestión de Proyectos de la Dirección de Innovación y Administración Electrónica, así será responsabilidad del adjudicatario la realización de cualquier documento relativo al procedimiento de calidad y referente al proyecto.

13

Garantía Los trabajos o prestaciones serán examinados y comprobados por los representantes del Gobierno Vasco. Si los encuentran conformes, emitirán su informe favorable, empezándose a computar desde ese momento un año de garantía que todo trabajo de realización externa debe aportar, en previsión de defectos no detectados en las pruebas realizadas. El incumplimiento de los plazos pactados sin causa que lo justifique, dará lugar a las penalizaciones que se acuerden en las condiciones particulares.

14

Confidencialidad Todos los trabajos realizados tendrán carácter confidencial, no pudiendo la empresa adjudicataria utilizar para sí ni proporcionar a terceros, datos o información alguna de los trabajos contratados sin autorización escrita del Gobierno Vasco, estando, por tanto, obligado a poner todos los medios a su alcance para conservar el carácter confidencial y reservado tanto de la información y documentación recibida del Gobierno Vasco, como de los resultados obtenidos del trabajo realizado. La empresa adjudicataria será responsable de daños y perjuicios que se deriven del incumplimiento de esta obligación.

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

15

Página: 39/54

Propiedad Intelectual Todos los derechos de propiedad intelectual y de ‘Copyright’ que se puedan derivar de dichos trabajos serán propiedad exclusiva del Gobierno Vasco, obligándose las partes a otorgar el documento oportuno cuando éste sea necesario, para la debida constancia pública de este hecho ante cualquier Organismo o Registro, tanto de la Comunidad Autónoma como de la Administración Central del Estado Español. La empresa adjudicataria será responsable de daños y perjuicios que se deriven del incumplimiento de esta obligación.

16

Plazos: Dadas las áreas en las que se ha dividido el proyecto, la secuenciación del mismo será la siguiente: Mes 1

Mes Quincena

1

Mes 2 2

3

Mes 3 4

5

Mes 4 6

7

Mes 5 8

9

10

Estudio de Plataformas de pago por móvil Selección y Provisión de dispositivos móviles Estudio de plataformas de gestión Aplicación de Configuración del Dispositivo Aplicación de captura de liquidaciones y pago móvil Aplicación de tramitación con pago móvil

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Página: 40/54

Se establecerán los siguientes hitos de control:

H0

Inicio del Proyecto

Definición exacta del alcance del proyecto: acta de alcance del proyecto

H1

Plataformas de pago con móvil

Presentación del estudio del mercado de plataformas de pago con móvil.

H0 + 1 mes

H2

Selección de dispositivos

Presentación de dispositivos de pago con dispositivos móviles para la selección final

H0 + 2 meses

H3

Aplicación de pago de liquidaciones

Finalización de las aplicaciones de:

H1 + 2 meses

H4

Aplicación de tramitación con pago

•

Configuración del dispositivo

•

Pago de liquidaciones

Finalización de la aplicación de tramitación con un paso de pago

H3 + 1 mes

Previo a cualquier trabajo, se redactará un acta de alcance de proyecto en base a lo expresado en el presente Pliego de Bases Técnicas y a la Oferta del adjudicatario; este acta de alcance deberá ser elevado, aprobado y firmado en el Comité de Dirección del Proyecto. Cualquier modificación en el alcance del proyecto, entregables, etc respecto a lo definido en el acta de alcance, deberá quedar reflejado en un documento de modificación de alcance que deberá ser así mismo aprobado en el Comité de Dirección del proyecto y firmado por los responsables por parte de DIAE y el adjudicatario. Dada la extrema dependencia en el cumplimiento de los hitos, vencido el plazo de cada uno de ellos, la parte contratante y el adjudicatario del proyecto firmarán una certificación parcial del proyecto. En caso de no alcanzarse alguno de los hitos parciales el contratante puede decidir la resolución del contrato y el fin del anticipado del proyecto, eximiéndole del pago del importe asociado a los hitos restantes.

17

Presupuesto y Forma de Pago El presupuesto máximo de adjudicación del contrato asciende a 90.000 euros (IVA incluido). El cumplimiento de los hitos de control determinará el pago del importe del proyecto de la siguiente forma:

SPB 02 - 03/04

Hito 0

20% del importe total

Hito 1

10% del importe total

Hito 2

10% del importe total

Hito 3

30% del importe total

Hito 4

30% del importe total

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

18 18.1

Página: 41/54

ANEXO: Aplicación Piloto de Pago Móvil Introducción Este anexo describe el manejo básico de la aplicación MiPago Mobile Desktop; una aplicación piloto de pago móvil desarrollada para la plataforma Microsoft (.NET)MiPago Mobile Desktop es una aplicación de escritorio diseñada para ejecutarse en el sistema operativo Microsoft Windows. La aplicación funciona en cualquier ordenador compatible con el entorno de ejecución de la plataforma Microsoft .NET (para información más detallada consultar el anexo sobre los requisitos e instalación). A pesar de funcionar en cualquier ordenador equipado con las características anteriores, la aplicación está orientada especialmente a ordenadores portátiles, dispositivos UMPC (Ultra Mobile PC) y, en general, a cualquier situación de conectividad limitada a Internet. La aplicación permite completar el proceso de pago de recibos de los cuadernos 57 y 57 no estándar, desde la introducción de las cartas de pago hasta la confirmación on-line del pago con tarjeta de crédito, así como la generación correspondiente de los justificantes de pago. MiPago Mobile Desktop se integra con otros dispositivos necesarios en la interacción con el usuario final, y recomendados para facilitar el proceso de pago, como un lector de códigos de barras unidimensional, un lector de tarjetas de banda magnética y una impresora para entregar al ciudadano los justificantes de pagos generados dinámicamente.

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

18.2

Realizar un pago

18.2.1

Descripción general

Página: 42/54

Al arrancar la aplicación MiPago Mobile Desktop se mostrará un nuevo icono de notificación en la barra de tareas del sistema:

Al pulsar con el botón derecho sobre el icono anterior se mostrarán dos opciones en un menú contextual: “Abrir” que mostrará la ventana principal de la aplicación y “Cerrar” que detendrá la ejecución de la misma. Así mismo, también puede hacerse doble clic sobre el icono para mostrar directamente la ventana principal. La pantalla principal de la aplicación presenta el siguiente aspecto: En los dispositivos portátiles, con resoluciones de pantalla de 600 píxeles o menos, la interfaz gráfica varía ligeramente, adaptándose a las condiciones más limitadas de visibilidad. Por ejemplo, la pantalla principal presenta el siguiente aspecto: El menú principal contiene diversas opciones, agrupadas en varios menús que son comentadas en los apartados posteriores. Debajo del menú principal, o justo a su derecha en la versión para dispositivos portátiles, se muestra el logotipo de la pasarela de pagos del Gobierno Vasco. Pinchando sobre la imagen se abrirá una ventana con el navegador web por defecto para acceder a la versión de Internet de la pasarela. La pantalla principal se organiza en dos pestañas: “General” con los datos relativos a los pagos, y la pestaña “Detalles”, que puede mostrarse opcionalmente para visualizar distintos mensajes de error y otras informaciones de interés. La parte inferior de la ventana muestra dos botones: “Cancelar”, que borra todos los datos cargados actualmente en la ventana y “Realizar pago”, que envía los datos al servidor y muestra una ventana con el resultado del proceso. Debajo de los controles anteriores se muestra la barra de estado de la aplicación, que ofrece información útil sobre la operación en curso. La barra de progreso, situada a la derecha de los mensajes de estado, muestra el avance actual en la comunicación con los servidores de la pasarela de pagos y la SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Página: 43/54

entidad financiera móvil.

18.2.2

Introducción de los datos de pago La parte superior de la ventana contiene los datos de la carta de pago, agrupados bajo el título “Carta de pago”, según el código de procedimiento recaudatorio 9050794: -

“Entidad emisora”. Los datos del emisor de la carta de pago y el sufijo identificativo del tributo en cuestión. “Referencia”. La referencia del pago. “Fecha límite de pago”. “Importe”. El importe del pago en euros, separando la parte entera de la decimal (céntimos).

Justo debajo de los campos de texto anteriores se muestra una lista con los pagos cargados actualmente en la aplicación, bajo el título “Pagos”. El botón “Aceptar” permite añadir el pago actual a la lista, mientras que “Borrar datos” cancela la edición actual, vaciando todos los campos anteriores. Los pagos añadidos a la lista no pueden ser modificados pero sí borrados, pulsando sobre el botón “Borrar” que se muestra en la última columna de cada fila. En la parte inferior de la ventana, debajo de la sección “Carta de pago” se recogen los datos referentes a la tarjeta de crédito, con la que se formalizará los pagos mostrados en la lista de “Pagos”. Los campos que constituyen la sección “Datos de tarjeta” son los siguientes: -

“Número de tarjeta”. Número de la tarjeta de crédito. Se corresponden con los 16 dígitos identificativos de la tarjeta de crédito o débito que figuran en la parte frontal de la misma, habitualmente agrupados de cuatro en cuatro. “Fecha de caducidad”. Se refiere al mes y año de caducidad de la tarjeta, respectivamente, indicados en este orden y con dos dígitos. “Titular”. Opcionalmente, puede indicarse el titular de la tarjeta empleada.

Con el fin de agilizar la captura de información, es posible emplear un lector de códigos de barras unidimensionales, que cargue directamente los datos de la carta de pago. Para ello, basta con que la ventana de la aplicación se visualice actualmente el pantalla y se pase el lector sobre el código en cuestión. Si los datos recibidos son correctos, pasarán a añadirse directamente a la lista de la sección “Pagos”. Por otro lado, también es aconsejable utilizar un lector de banda magnética. Los datos capturados a través del dispositivo lector se mostrarán directamente en la sección “Datos de tarjeta”. De esta forma, se van cargando los datos de uno o varios tributos, que serán pagados con la tarjeta indicada por el ciudadano. Una vez introducidos los datos anteriores, el botón “Realizar pago” permitirá enviar los datos a través de la conexión a Internet, mostrándose una ventana con el resultado del proceso (ver apartado siguiente).

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

18.2.3

Página: 44/54

Confirmación del pago La siguiente ventana se muestra después de haber procedido a confirmar el pago con el botón “Realizar pago” de la ventana principal: La ventana se divide en dos secciones: los pagos realizados correctamente (en la sección “Pagos correctos”) y los pagos que han producido algún tipo de error (en la sección “Pagos incorrectos”). El botón “Ver” situado en la columna “Detalles” de ambas secciones permite mostrar la información adicional sobre el estado del pago.

En casa de existir algún pago incorrecto, el botón “Imprimir resumen” permitiría enviar a la impresora un resumen general de los pagos efectuados, tanto correctos como incorrectos.

Si el pago ha podido efectuarse correctamente, el botón “Imprimir justificante” mostrará una ventana con las copias de los justificantes de todos los pagos correctos, desde la que podrá solicitarse la impresión de los documentos:

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

SPB 02 - 03/04

Página: 45/54

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

18.2.4

Página: 46/54

Modo de pago diferido En situaciones con conectividad limitada a Internet, el modo de pago diferido permite almacenar en la propia aplicación la información referente a diversos pagos (generando justificantes de pago provisionales para los ciudadanos) y procesarlos todos juntos cuando se recupere la conectividad.

El modo de pago diferido puede activarse bajo demanda (ver el apartado referente a otras opciones de la aplicación) o al detectarse la situación de conectividad limitada o nula:

El modo de pago diferido incluye una barra de herramientas adicional en la parte inferior de la ventana:

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Página: 47/54

En la esquina inferior de la ventana, en la barra de estado, aparecerá el mensaje “Sin conexión.”, indicativo de que el modo de pago diferido se encuentra activado. La barra de herramientas muestra los siguientes controles de interacción: -

Contador del número de pagos. A la derecha de la etiqueta de “Pago diferido” se muestra el número de pagos almacenados actualmente en este modo. Cada pago diferido incluye uno o varios pagos con los datos correspondientes de la tarjeta de crédito utilizada como medio de pago.

-

Los botones de navegación “”. Permiten desplazarse por los diversos pagos almacenados.

-

El botón “Nuevo” permite dar de alta un nuevo pago diferido.

-

El botón “Guardar” permite almacenar los datos visualizados actualmente en pantalla, es decir, la lista de pagos de la sección “Pagos” y los datos de la tarjeta de “Datos de tarjeta”.

-

El botón “Justificante” genera un justificante provisional para entregar al ciudadano:

-

El botón “Borrar” elimina los datos almacenados del pago visualizado actualmente o cancela la edición actual.

-

El botón “Pagar todos” permite dar por concluido el proceso, enviando los datos de los pagos almacenados a través de Internet. Obviamente, si las condiciones de conectividad no lo permiten, esta opción no tendrá efecto alguno. Una vez enviados los datos al servidor se mostrará una ventana con el resultado del proceso completo:

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Página: 48/54

Los datos de los pagos diferidos se almacenan localmente, de tal forma que es posible salir de la aplicación en este modo y al arrancarla más adelante recuperar los datos anteriores. Por ejemplo, al ejecutar la aplicación nuevamente, se detectarán los pagos que no han sido tramitados por completo, ofreciendo la posibilidad de continuar desde el punto anterior:

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

18.3

Página: 49/54

Accesibilidad en dispositivos UMPC Con el fin de adaptarse mejor a las limitaciones propias de dispositivos UMPC, la aplicación incorpora una serie de ayudas en la carga de los datos de pago. A la izquierda de las secciones principales, “Carta de pago” y “Datos de tarjeta”, de los dispositivos con pantalla táctil de tamaño reducido, se muestran dos botones de ampliación, con la imagen de una lupa:

La opción de ampliación de la carta de pago mostrará la siguiente pantalla:

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

Página: 50/54

La ventana anterior funciona de forma análoga a lo comentado previamente en la sección “Carta de pago”, incluyendo también la captura de los datos del pago mediante un lector de códigos de barras: -

Los pagos leídos se añadirán automáticamente a la lista de “Pagos”. El botón “Introducir datos de tarjeta” lleva directamente a la ventana ampliada de lectura de los datos de la tarjeta de crédito. El botón “Cerrar” permite volver a la vista normal de la aplicación.

La ventana ampliada de captura de los datos de tarjeta se muestra a continuación:

La ventana anterior también funciona de forma análoga a lo comentado previamente en la sección “Datos de tarjeta”, incluyendo la captura de los datos de la tarjeta a través del lector de banda magnética:

SPB 02 - 03/04

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001 -

SPB 02 - 03/04

Página: 51/54

El botón “Volver a datos de pago” lleva directamente a la ventana ampliada de introducción de los datos de pago. El botón “Realizar pago”, si todos los datos son correctos, da por finalizado el proceso y envía los datos cargados actualmente a la pasarela de pagos. El botón “Cerrar” permite volver a la vista normal de la aplicación.

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

18.4

Página: 52/54

Otras opciones A parte de las opciones generales de pago, la aplicación incluye otras opciones secundarias, que se describen a continuación.

El menú “Archivo > Salir” termina la ejecución actual de la aplicación. Si la aplicación se encontraba en el modo de pago diferido, guardará en este momento todos los datos de los pagos pendientes, con el fin de reanudar el proceso en ejecuciones posteriores.

El menú “Herramientas > Comprobar conexión” permite comprobar, bajo petición del usuario, las condiciones de conectividad actuales, permitiendo, si así se desea, cambiar al modo más adecuado: pago normal o con conexión, o pago diferido o sin conexión.

El menú “Herramientas > Cambiar modo” permite alternar entre los diferentes de modos de funcionamiento independientemente de la conectividad actual: modo de pago normal o con conexión, o modo de pago diferido o sin conexión. El menú “Ayuda > Enviar…” muestra la siguiente ventana: Esta opción permite enviar al servidor la información almacenada localmente en la aplicación, y que puede ser de utilidad para resolver ciertos problemas. La ventana presenta diversas opciones para filtrar y seleccionar la información deseada: -

-

-

SPB 02 - 03/04

Con “Fecha desde:” y “Fecha hasta:” se establece el período temporal de la información enviada. En “Categoría” se escogen las categorías de información que serán utilizadas en el envío. En “E-mail de contacto:” se debe indicar una dirección de e-mail de contacto del usuario. “Mensaje:” es un campo libre que puede contener cualquier texto o explicación adicional sobre la información que se adjunta.

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

SPB 02 - 03/04

Página: 53/54

Dirección de Innovación y Administración Electrónica

PLIEGO DE BASES TÉCNICAS: Tramitación y Pago Móvil Documento: SPB- 2009-PY058-001

18.5

Página: 54/54

Especificaciones Técnicas La aplicación se ejecuta en el entorno proporcionado por la plataforma .NET 2.0, cuyos requisitos mínimos se detallan a continuación: -

SPB 02 - 03/04

Sistemas operativos compatibles: Windows 2000 Service Pack 3; Windows 98; Windows 98 Second Edition; Windows ME; Windows Server 2003; Windows XP Service Pack 2 Software necesario: o Windows Installer 3.0 (excepto para Windows 98/ME, que requiere Windows Installer 2.0 o una versión posterior). Windows Installer 3.1 o posterior, recomendado. o IE 5.01 o versión posterior: en todas las instalaciones de .NET Framework se debe ejecutar Microsoft Internet Explorer 5.01 o una versión posterior. o Requisitos de espacio en disco: 280 MB (x86), 610 MB (64 bits).

Dirección de Innovación y Administración Electrónica