CONTRATACIÓN DEL DESARROLLO DE NUEVAS FUNCIONALIDADES PARA LA PLATAFORMA DE NOTIFICACIONES POSTALES Y ENVÍO DE SMS PLIEGO DE CONDICIONES DE CONTRATACIÓN 1
1 Antecedentes Lanbide, Servicio Vasco de Empleo, nace como organismo autónomo de carácter administrativo tras la aprobación de la Ley 3/2011, de 13 de octubre, ostentando personalidad jurídica propia y plena capacidad de obrar, con la aprobación de los presupuestos de la Comunidad Autónoma de Euskadi el 1 de enero de 2010, derivado del acuerdo de traspaso de funciones y servicios a la Comunidad Autónoma del País Vasco en materia de ejecución de la legislación laboral en el ámbito del trabajo, el empleo y la formación profesional para el empleo, aprobado mediante Real Decreto 1441/2010, de 5 de noviembre y por Decreto del Gobierno Vasco 289/2010, de 9 de noviembre. Lanbide está estructurado en unos Servicios Centrales en Vitoria-Gasteiz, Sestao y Donostia- San Sebastián, una red de 42 oficinas de empleo, más dos centros de formación Ocupacional, en las principales comarcas y municipios de la Comunidad Autónoma Vasca. A su vez, está conformada por aproximadamente 930 profesionales repartidos en 14 áreas. Ante este modelo organizativo, se intensifica la necesidad de establecer herramientas transversales que faciliten la gestión de las diferentes áreas. Entre estas herramientas indispensables para el buen funcionamiento de las áreas, se encuentra la gestión de los envíos postales y SMS que se realizan tanto de manera puntual como masiva. Por todo ello, Lanbide decide abordar un proyecto de Desarrollo de nuevas funcionalidades de la plataforma de notificaciones postales y envío de SMS, que centralice la gestión de los envíos realizados desde cualquiera de las áreas que lo componen independientemente de su volumen. El objeto del presente pliego es la descripción técnica de dicho proyecto. 2
2 Objetivos Dado que actualmente las diferentes áreas de Lanbide, bien en Servicios Centrales bien en oficinas, realizan las tareas de envío de manera heterogénea, se precisa una herramienta que centralice, normalice y homogeneice tanto la gestión y envío de cartas en sus diferentes modalidades como el envío de SMS. El objeto del presente pliego es el desarrollo de nuevas funcionalidades que permitan sobre la plataforma de notificaciones actual, la gestión integral de los envíos desde la petición del envío hasta la recepción del resultado del mismo. Asimismo facilitará la impresión, ensobrado y depósito de los envíos. El alcance mínimo del proyecto que debe ser ofertado debe comprender los siguientes puntos: Desarrollo: El desarrollo de la plataforma ofertada debe cubrir las funcionalidades definidas en detalle en los apartados 3.3 y 3.4. Integración: La plataforma deberá integrarse con los sistemas ya disponibles en Lanbide y Gobierno Vasco (ver cuáles son estos sistemas en el apartado 3.2). Implantación: Deberá implantarse la plataforma en el entorno tecnológico especificado en el apartado 3.1. Formación: Se facilitará la formación necesaria dentro de Lanbide para conseguir un mayor aprovechamiento de la plataforma (más información en el apartado 3.5). Garantía de los trabajos ofertados: Deberá incluirse en las ofertas un periodo de garantía de al menos 2 años de duración. 3
3 Características técnicas de la plataforma y alcance detallado El desarrollo de la plataforma de notificaciones tendrá que cumplir tanto los requisitos funcionales definidos en el presente pliego así como la arquitectura de referencia de Lanbide que se detalla a continuación. 3.1 Tecnología sobre la que debe sustentarse Lanbide ha definido para satisfacer, de una manera homogénea y escalable en cuanto a tecnología se refiere, todos los requisitos funcionales actuales y futuros dentro de su negocio, la arquitectura lógica de desarrollo Java EE basada en las siguientes tecnologías: Facelets como motor de plantillas para la capa de presentación JSF con implementación RichFaces. JBoss-Seam como Framework de integración, motor de inyección de dependencias y proveedor de contexto de conversación. JPA con implementación Hibernate para la capa de persistencia. Planificación de procesos con Quartz. La infraestructura tecnológica actual de Lanbide está compuesta por productos Oracle como solución corporativa para servidores de aplicaciones y bases de datos. Actualmente los productos sobre los que se soportan los sistemas de información en Lanbide son: Oracle 11g (RAC). Oracle Weblogic Server 11g (Clúster de dos nodos). 4
Apache Web Server (Clúster de dos nodos). Alfresco Active Directory. 3.2 Integraciones La plataforma de notificaciones solicitada debe integrarse funcionalmente con los siguientes elementos: Identificación y autorización: Sistema común para la identificación de usuarios en el acceso a las aplicaciones y la obtención de sus permisos y perfiles para su autorización. Gestores documentales (DOKUSI y Alfresco): tanto las cartas enviadas como los acuses de recibo digitalizados o la Prueba Electrónica de Entrega (PEE) se almacenarán en el gestor documental corporativo de Gobierno, garantizando la compatibilidad hacía atrás con sistemas anteriores. Operador postal autorizado: La herramienta a desarrollar deberá integrarse con el operador postal para realizar los envíos y recoger los estados de aquellos envíos que lo permitan y requieran. Boletín Oficial del País Vasco (BOPV): Las notificaciones devueltas por el operador postal deben ser, en función de la causa de devolución, publicadas en el BOPV. La herramienta deberá facilitar la generación de estas publicaciones. Plataforma de Tramitación Electrónica del Gobierno Vasco (PLATEA): En caso necesario se depositará en Mis Gestiones de Gobierno el resultado del envío utilizando PLATEA. Plataforma de envío de SMS del Gobierno Vasco (LATINIA): Para el envío de SMS se utilizará la plataforma de Gobierno existente. 3.3 Requisitos funcionales Las adaptaciones y mejoras a realizar sobre la herramienta de notificaciones serán un desarrollo web que contemple el envío tanto de cartas de manera masiva como individual para lo cual deberá cubrir como mínimo los siguientes requisitos funcionales: Carga de envíos: Sobre la funcionalidad actual, deberá permitir diferentes modos de integración para la solicitud de envíos: servicios web, carga de ficheros, interfaz web. Origen de los documentos: El origen de las cartas será el Gestor Documental (Alfresco o Dokusi) para los envíos masivos o bien serán adjuntada manualmente a través del interfaz web de la aplicación para los envíos individuales. Clasificación de envíos: El sistema debe ser capaz de clasificar los envíos en función de criterios como el tipo de envío (correo ordinario, cartas certificadas sin/con acuse, notificación administrativa ), peso, etc. Gestión de remesas: La aplicación organizará los envíos de manera óptima para su impresión y ensobrado. Ello implica gestión de remesas, ficheros de control que faciliten la impresión de acuses de recibo en caso necesario así como el control de calidad de los envíos. 5
Operador postal: En función del tipo de envío se requerirá integración con el Operador Postal Autorizado (actualmente mediante el estándar SICER). Podrá incluir la generación de códigos de barras e inserción del mismo en la carta a enviar. Control de remesas: La aplicación debe proporcionar las consultas necesarias para el cierre de las remesas, es decir, saber en todo momento el estado de las remesas así como los envíos pendientes de realizar. Gestión del envío: En función del tipo de envío se requiere cargar las fechas de entrega/devolución así como los motivos de la misma. Esta carga puede ser automática en caso de integración con operador postal o bien manual por medio de la interfaz web. Seguimiento: Se podrá consultar el estado y recepción de los envíos (fechas de depósito, entrega, devolución ) así como sus motivaciones tanto en la propia aplicación como en fuentes externas (operador postal). Comunicación con otras aplicaciones: En el caso de que el origen del envío sea una aplicación, se notificará a la misma el resultado del envío. Envío de SMS: Una característica adicional al envío postal, es el envío de SMS utilizando la plataforma de Gobierno Vasco (Latinia). De estos envíos también es necesario poder realizar un seguimiento y detalle de estado. Consultas: Deberá proporcionar consultas flexibles para el seguimiento y detalle de los envíos realizados en función del perfil del usuario. Informes: Proporcionará un listado de informes prediseñados para el control financiero de los envíos realizados. Asimismo proporcionará datos estadísticos de uso. 3.4 Requisitos no funcionales Como requisitos no funcionales, la herramienta a desarrollar deberá cumplir como mínimo los siguientes: Seguridad: El acceso al Sistema debe estar restringido por el uso de claves asignadas a cada uno de los usuarios. Sólo podrán ingresar al Sistema las personas que estén registradas, estos usuarios serán clasificados en varios tipos de usuarios (o roles) con acceso a las opciones de trabajo definidas para cada rol. El control de acceso implementado debe permitir asignar los perfiles para cada uno de los roles identificados. o o Confidencialidad: La información manejada por el sistema de estar protegida de acceso no autorizado y divulgación. Integridad: La información manejada por el sistema dispondrá de mecanismos de chequeo de integridad y realización de auditorías. Requisitos de Rendimiento y Escalabilidad: El sistema debe ser construido sobre la base de un desarrollo evolutivo e incremental, de manera tal que nuevas funcionalidades y requerimientos relacionados puedan ser incorporados afectando el código existente de la menor manera posible; para ello deben incorporarse aspectos de reutilización de componentes. El sistema debe ser capaz de permitir en el futuro el desarrollo de nuevas funcionalidades, modificar o eliminar funcionalidades después de su construcción y puesta en marcha inicial. Flexibilidad: El sistema debe ser diseñado y construido con los mayores niveles de flexibilidad en cuanto a la parametrización de los tipos de datos. 6
Usabilidad: La solución debe operar de manera independiente del navegador que se utilice. La solución debe tener interfaces gráficas de administración y de operación en los idiomas oficiales de la Comunidad. 3.5 Formación La formación que debe ofertarse comprenderá a los usuarios finales en función de los roles definidos para la utilización de la herramienta. Deberá detallarse en la oferta el contenido aproximado del programa preparado para cada perfil junto al número de sesiones que se realizarán. 7
4 ORGANIZACIÓN, PLANIFICACIÓN Y CONTROL DEL TRABAJO 4.1 Organización, planificación y control Los trabajos se realizarán en las instalaciones del licitador, salvo aquellos que por su definición requieran una presencia física en Lanbide, en cuyo caso el personal del licitador realizará los trabajos en las dependencias que Lanbide habilite a tal efecto. Se deberá detallar en la oferta el plan de trabajo para cada una de las fases del proyecto, cuyos hitos serán de carácter mensual. Asimismo, se designará un Comité de Dirección formado por miembros de Lanbide y de la adjudicataria que colaboren en la verificación y evaluación de las tareas bajo la supervisión del director de proyecto. Los licitadores deberán proponer el modelo organizativo óptimo para la coordinación y dirección del proyecto, teniendo en cuenta las características, organización y capacidades de Lanbide. En dicho modelo organizativo deberán hacerse constar los mecanismos a desarrollar con el fin de mantener la coordinación conjunta del proyecto. 4.2 Volúmenes mínimos de horas a contratar El volumen mínimo de recursos a contratar en función de los perfiles solicitados en la carátula de este pliego será de 1.950 horas repartidas según la tabla que se presenta a continuación a lo largo del período de ejecución. Estas horas podrán aumentarse manteniendo la proporcionalidad exigida por perfil hasta agotar el presupuesto máximo de licitación en base a los costes / hora por perfil que aparezcan recogidos en la oferta económica de licitador. PERFIL HORAS MINIMAS % DEDICACION Jefe Proyecto 117 6% De 5% a 8% Consultor funcional 175,5 9% De 8% a 12% Arquitecto J2EE 97,5 5% De 4% a 6% Analista programador 682,5 35% De 30% a 35% Programador 877,5 45% De 40% a 45% TOTALES 1.950 100,00% 4.3 Volúmenes estimados de notificaciones La herramienta de notificaciones a desarrollar, deberá soportar volúmenes de envío de cartas del orden de 30.000 cartas mensuales. En cuanto al volumen de SMS a enviar, se estima en unos 200.000 SMS mensuales. 8