- Procedimiento Abierto - Pliego de Prescripciones...
65
- Procedimiento Abierto - Pliego de Prescripciones Técnicas Número de Expediente: A12-0517 “Iniciativa de análisis de servicio, producto y canales de interacción con el cliente” PLAZO DE PRESENTACIÓN: FECHA LÍMITE EL 13 DE JUNIO DE 2017. Horario de entrega de 9:00 a 14:00 horas. LUGAR DE PRESENTACIÓN: CESCE, S.A. C/ VELÁZQUEZ Nº 74 – 28001 Madrid Entregar en Recepción a la atención del Área de Compras. Fecha de Publicación: 30/05/2017 Consultas: Durante los 5 primeros días desde la fecha de publicación, vía correo electrónico: [email protected]
Transcript of - Procedimiento Abierto - Pliego de Prescripciones...
- Procedimiento Abierto -
Pliego de Prescripciones Técnicas
Número de Expediente: A12-0517
“Iniciativa de análisis de servicio, producto y canales de interacción
con el cliente”
PLAZO DE PRESENTACIÓN: FECHA LÍMITE EL 13 DE JUNIO DE 2017. Horario de entrega de 9:00 a 14:00 horas. LUGAR DE PRESENTACIÓN: CESCE, S.A. C/ VELÁZQUEZ Nº 74 – 28001 Madrid Entregar en Recepción a la atención del Área de Compras. Fecha de Publicación: 30/05/2017 Consultas: Durante los 5 primeros días desde la fecha de publicación, vía correo electrónico: [email protected]
2 de 65
Índice 1 Objeto de la licitación ........................................................................................................... 5
2 Aspectos generales del pliego ............................................................................................ 6
2.1 Características de la prestación................................................................................. 6
2.2 Medios Técnicos y Humanos del Contratista ........................................................... 6
2.3 Contratos y obligaciones existentes .......................................................................... 8
2.4 Metodología de ejecución y gestión del proyecto. .............................................. 8
2.5 Seguimiento y Control de la Ejecución ..................................................................... 9
2.6 Gestión de riesgos ........................................................................................................ 10
2.7 Responsables del proyecto ....................................................................................... 11
2.7.1 Responsable del proyecto del adjudicatario ................................................... 11
2.7.2 Responsable del proyecto de CESCE ................................................................. 11
2.8 Transferencia del conocimiento y gestión de la transición. ............................... 11
2.9 Cumplimiento de los trabajos de esta RFP ............................................................. 12
2.9.1 Cumplimiento de Plazos y Penalizaciones ......................................................... 12
2.9.2 Penalizaciones por demora .................................................................................. 12
2.9.3 Pago de las Penalizaciones .................................................................................. 13
2.9.4 Demoras no imputables al adjudicatario........................................................... 14
3 LOTE 1. Diagnóstico y diseño del servicio, producto y canales de contacto con el
cliente ............................................................................................................................................... 15
3.1 Análisis de contexto .................................................................................................... 15
3.1.1 Descripción ............................................................................................................... 15
3.1.2 Entregables ............................................................................................................... 15
3.1.3 Perfiles ........................................................................................................................ 16
3.2 Diseño de la propuesta de valor .............................................................................. 16
3.2.1 Diseño propuesta valor personalizada y entregables ..................................... 16
3.2.2 Perfiles ........................................................................................................................ 17
3.3 Definición de la plataforma....................................................................................... 17
3.3.1 Diseño del Servicio .................................................................................................. 17
3.3.2 Definición Funcional ............................................................................................... 17
3.3.3 Diseño de Interfaz .................................................................................................... 18
3.4 Go to market................................................................................................................. 19
3.4.1 Definición de impacto sobre el modelo comercial actual. ........................... 20
3.4.2 Entregable: ............................................................................................................... 20
3 de 65
3.4.3 Perfiles ........................................................................................................................ 20
3.5 Requisito propuesta técnica ..................................................................................... 20
3.6 Garantía y soporte post-implantación .................................................................... 20
4 LOTE 2. Construcción de un nuevo framework de transformación digital en CESCE y
reingeniería de dos aplicaciones del dominio de Risk Management de CESCE. ............ 22
4.1 Objeto del lote ............................................................................................................. 22
4.2 Descripción de los servicios ....................................................................................... 24
4.2.1 Puntos a cubrir por la arquitectura ...................................................................... 26
4.2.2 Los principios............................................................................................................. 26
4.2.3 Ejes tecnológicos ..................................................................................................... 27
4.2.4 Ejes metodológicos ................................................................................................. 27
4.3 Arquitectura de la era digital .................................................................................... 28
4.3.1 Ejes tecnológico: API management .................................................................... 28
4.3.2 Eje tecnológico: Arquitectura de Integración: microservicios ....................... 29
4.3.3 Definición e implantación de metodología de desarrollo y explotación ... 35
4.4 Apificación del dominio de riesgos .......................................................................... 40
4.4.1 Caso de Uso 1: Identificación de empresa ....................................................... 41
4.4.2 Caso de Uso 2: Clasificación de empresa ......................................................... 41
4.4.3 Reingeniería del dominio de riesgos ................................................................... 42
4.4.4 Convivencia con los sistemas actuales .............................................................. 43
4.5 Modelo de infraestructura ......................................................................................... 43
4.6 Formación a CESCE ..................................................................................................... 44
4.7 Servicio de mantenimiento evolutivo y soporte .................................................... 44
4.8 Hitos, Tareas y Entregables del proyecto ................................................................ 45
4.8.1 Definición y diseño de la arquitectura de la era digital.................................. 45
4.8.2 Definición e implantación de la metodología de desarrollo y explotación
basada en DevOps .............................................................................................................. 46
4.8.3 Desarrollo e implantación de la Arquitectura ................................................... 46
4.8.4 Diseño y desarrollo de servicios y APIs para el servicio de identificación y clasificación de empresas. ................................................................................................. 47
4.9 Entregas ......................................................................................................................... 48
4.10 Requisito propuesta técnica ..................................................................................... 49
4.11 Formación a CESCE ..................................................................................................... 49
4.11.1 Hito 5.1: Formación ............................................................................................. 49
4 de 65
4.12 Ejecución y Gestión del Proyecto ............................................................................ 49
4.12.1 Horario y condiciones de los Servicios ............................................................ 49
4.12.2 Equipo de proyecto ........................................................................................... 51
4.13 Garantía / Soporte post-implantación .................................................................... 51
5 LOTE 3. Construcción de una plataforma digital para CESCE .................................... 53
5.1 Objeto del lote ............................................................................................................. 53
5.2 Objetivo y alcance del proyecto ............................................................................. 53
5.3 Plan de desarrollo del proyecto ............................................................................... 55
5.4 Garantía y soporte post-implantación .................................................................... 57
5.5 Equipo de trabajo y perfiles requeridos .................................................................. 58
5.6 Formación...................................................................................................................... 59
5.7 Lugar de Prestación del Servicio............................................................................... 59
6 Descripción de perfiles involucrados ................................................................................ 60
5 de 65
1 Objeto de la licitación Actualmente CESCE se encuentra en un proceso de mejora de su servicio al cliente tanto en su propuesta de valor como en los canales de interacción. Los objetivos de
este trabajo son:
• Mejorar la calidad de servicio a los clientes existentes
• Crecimiento de nuevos clientes e ingresos
• Mejorar el ratio de abandono de clientes
Para llevar a cabo estos objetivos se solicitan 3 lotes independientes.
Lote 1: Diagnóstico y diseño del servicio, producto y canales de contacto con el cliente. Este lote consiste en las siguientes acciones:
• Análisis del mercado y tendencias en España y Portugal para las empresas que venden a otras empresas y con respecto a sus necesidades relacionadas con la
gestión del riesgo comercial (prospección de clientes nacional e internacional, gestión del riesgo de impago de su cartera de clientes, gestión de impagos,
seguros de impagos, financiación,…), • Estudio de clientes y sus necesidades con respecto a los servicios y productos
que presta actualmente CESCE. Identificando los segmentos existentes y sus respectivas necesidades en cuanto al producto, servicios y canales de
interacción. • Análisis de los canales de interacción y propuesta de valor de CESCE actual.
• Propuesta de diseño de producto para los distintos segmentos de cliente identificados en la fase anterior y sus necesidades de plataforma digital para su
interacción.
Lote 2: Construcción nuevo framework de transformación digital en CESCE y reingeniería de dos aplicaciones del dominio de Risk Management de CESCE. Este lote consiste en:
Construir un framework metodológico y técnico en el campo de la transformación digital con vista a su gradual implantación a nivel global.
En la actualidad CESCE dispone de unos avanzados sistemas de Gestión del Riesgo y Gestión del Crédito. En el afán de mejorar y dar soporte a los futuros
modelos de negocio, CESCE cree conveniente definir una estratégica de arquitectura tecnológica que se alinee con las necesidades de negocio y las
arquitecturas tecnológicas y soluciones emergentes en el mercado, de forma que CESCE pueda disponer de una arquitectura renovada aún más flexible,
desacoplada y modular, con nuevas capacidades de futura explotación.
En este contexto CESCE se plantea desarrollar una nueva arquitectura que
permita exponer sus capacidades a nuevos modelos de negocio orientados a canales digitales. Este requisito se conceptualiza como un conjunto de
microservicios y APIs, orientadas a la monetización del conjunto de productos o servicios y que por su propia naturaleza tiende a tener un mayor número de
6 de 65
consumidores y se enfoca en facilitar el consumo self service externo. Al mismo tiempo, obliga a tener en cuenta políticas y mecanismos de gestión, gobierno,
securización y monitorización orientados a “producto”.
Lote 3: Construcción de una plataforma digital. Este lote consiste en:
Disponer de servicios de asistencia técnica para la construcción de una plataforma digital que incorpore funcionalidades de libre acceso y acceso
transaccional a servicios de gestión de crédito.
Esta plataforma debe ser un ecosistema integrado de soluciones tecnológicas
que proporcione a CESCE la capacidad completa para desarrollar cualquier iniciativa de negocio que se canalice en un entorno digital.
En esta plataforma se pone al cliente en el centro de los desarrollos y la arquitectura pivota en torno al “Customer Engament”, esto es, que se generen
acciones por y para el cliente y se construye un offering modular y adaptado a cada cliente.
Los licitadores podrán licitar a uno, varios o todos los lotes.
Los lotes 1 y 2 comenzarán a la firma del contrato. El lote 3 tiene dependencia con el
lote 1 y comenzará transcurrido ente 10 y 16 semanas del comienzo del lote 1.
A tal efecto, CESCE convoca la presente licitación para la contratación de una o varias
empresas externas que deberán demostrar tener los recursos y experiencias que acrediten su capacidad para llevar a cabo estos trabajos.
2 Aspectos generales del pliego Los siguientes aspectos son de aplicación a todos los lotes descritos en el presente pliego.
2.1 Características de la prestación
El coste de cada uno de los proyectos incluye su gestión, servicios y entregables
especificados en el presente pliego.
Los gastos relativos al desplazamiento del equipo a las instalaciones del cliente deben de estar incluidos en el coste presentado. NO están incluidos registros de marcas,
estudios de patentes, homologaciones, adquisición de licencias de software o cualquier
otro gasto no especificado en el presente pliego.
2.2 Medios Técnicos y Humanos del Contratista
El licitador declara que cuenta con una organización propia y estable, viabilidad
económica y medios materiales y personales necesarios para el desarrollo de la actividad a la que licita.
El licitador se compromete a asignar al Proyecto objeto del presente Pliego, los medios técnicos y personales que se especifican en el presente RFP.
El personal que el licitador asigne para la realización del Proyecto estará compuesto por profesionales expertos en la realización de las funciones específicas que deban realizar,
7 de 65
asumiendo el licitador total responsabilidad respecto a la selección y formación de estos profesionales para la correcta realización del Proyecto o servicio que licitan.
La descripción del equipo de los profesionales/perfiles que el licitador vaya a asignar al Proyecto deberá ser detallada en la oferta, siendo necesario incluir el curriculum vitae
y/o perfil profesional de cada uno de los integrantes del equipo de trabajo que se ofrece.
El licitador se compromete a que el equipo propuesto en su Oferta sea el que realmente forme parte de la realización del Proyecto objeto de estos lotes, no admitiéndose, una
vez adjudicado el contrato, cambios en el equipo que no sean justificados por causa mayor. Si durante la vigencia del contrato se produjeran sustituciones superiores a un
treinta por ciento (30%) del total del equipo, CESCE podrá instar la resolución del contrato.
La comprobación de la falsedad en las cualificaciones del equipo ofertado durante el análisis de la oferta será objeto de exclusión de la misma. Si este hecho se produce una
vez adjudicado el contrato, CESCE se reserva el derecho a resolver el contrato o solicitar del licitador la sustitución de aquellos recursos que no cumplan las cualificaciones
ofertadas.
La incorporación, sustitución o baja de las personas designadas por el licitador requerirá
la previa aprobación por parte de CESCE. Asimismo, CESCE se reserva el derecho a solicitar y obtener la baja de las personas asignadas, cuando concurran circunstancias
que así lo aconsejen, entre otras y sin tener carácter exclusivo la falta de formación y/o experiencia requerida.
En caso de tener que sustituir recursos, será potestad de CESCE la aceptación de los nuevos recursos propuestos por parte del licitador para formar parte del equipo.
En caso de sustitución de recursos, el licitador deberá con quince (15) días de antelación:
- Presentar una solicitud de cambio explicando el motivo por el que se requiere el cambio.
- Presentar el curriculum vitae del nuevo recurso. - Asumir los costes de trasferencia de conocimientos y solapamiento de ambos
perfiles
Cuando la realización del Proyecto objeto de la presente licitación, exigiera una
contribución neta de recursos mayor o menor a la prevista, por un periodo determinado de tiempo, el licitador se compromete a aportar o retirar los recursos necesarios.
Asimismo, deberá contar el licitador con el personal preciso que cubra la posibles bajas o sustituciones de los profesionales que inicialmente asigne al Proyecto.
La organización, control y dirección de la actividad y de los profesionales que formen parte del Equipo de Trabajo (incluido el poder disciplinario y la concesión de permisos y
vacaciones) corresponden en exclusiva al licitador, aun cuando éste se encuentre sometido a las instrucciones técnicas de CESCE y exista una supervisión por parte de
CESCE.
El licitador designará en su oferta técnica un coordinador, que actuará como
interlocutor con CESCE y será el único empleado del licitador al que CESCE dé las
8 de 65
instrucciones necesarias. El coordinador deberá después transmitirlas a los trabajadores que formen parte del equipo de trabajo.
La ejecución del contrato implicará la dotación de infraestructura suficiente (ordenadores, licencias, software, teléfonos, etc.) a los equipos humanos. Será
responsabilidad exclusiva del licitador proveer a aquellos de los equipos antedichos, así como la formación necesaria para realizar el Proyecto.
En los casos en los que proceda, la infraestructura y equipos, licencias, software, etc necesarios para realizar el desarrollo del presente proyecto (entorno de desarrollo) serán
responsabilidad exclusiva del licitador.
CESCE proporcionará la infraestructura, equipos y software necesario para los entornos
de integración, de UAT (User Acceptance Test) y productivo.
2.3 Contratos y obligaciones existentes
Los adjudicatarios deberán relacionarse en el desarrollo de sus funciones con otros proveedores de CESCE que actualmente prestan servicios en CESCE, no comprendidos
en este Pliego, pero que afectan en mayor o menor medida al mismo. Estos servicios comprenden, entre otros, a los servicios de CPD, Infraestructuras y Operaciones, centro
de atención a clientes, desarrollo y mantenimiento de aplicaciones, etc.
2.4 Metodología de ejecución y gestión del proyecto.
Las ofertas describirán, al máximo nivel de detalle, la metodología que soportará el
Proyecto y que se aplicará a lo largo de él, incluyendo, como mínimo, información referida a:
Componentes principales y descripción de la metodología (flujo de los procesos de mantenimiento y sus relaciones; entradas y salidas).
- Métricas, herramientas, etc.
- Métodos que garanticen la Calidad del Software.
- Experiencias con la metodología.
- Aspectos que el licitador considere importante destacar.
Para el Lote 1, Los licitadores incluirán la metodología que consideren más oportuna, para abordar estos proyectos de forma más eficiente, en particular mediante el uso de
metodologías ágiles como SCRUM, Lean, Crystal, XP…
Para los Lotes 2 y 3, se seguirá una metodología DevOps
Será obligatorio que los métodos de trabajo utilizados en el desarrollo de software de cualquiera de los lotes del presente pliego estén completamente alineados y utilicen la
arquitectura, software y normativa que se define en el lote 2 del presente pliego o en su defecto la normativa y arquitectura que CESCE decida.
Será obligatorio que la gestión de la calidad forma parte de la metodología empleada por el proveedor e incorpore a los responsables de QA desde las primeras fases del
proyecto, esto ayudará:
• Detectar y prevenir errores cuanto antes facilita su corrección y es menos costoso.
9 de 65
• Las pruebas sean mucho más efectivas. • Asegurar el progreso constante.
Las entregas de software y de documentación se realizarán a través de los servidores de
control de versiones que CESCE indique a tal efecto. Durante el desarrollo del proyecto, se decidirá conjuntamente entre CESCE y el proveedor la mejor organización del
repositorio de entregables.
CESCE ofrecerá acceso a sus entornos según las necesidades de los proyectos, pero el
entorno de desarrollo para las tecnologías exigidas será responsabilidad del Adjudicatario.
2.5 Seguimiento y Control de la Ejecución
El licitador deberá proponer un modelo de gestión de la relación que facilite un procedimiento de seguimiento y control del proyecto, y en este contexto, permita
exponer, revisar y consensuar los aspectos más relevantes en la ejecución del Proyecto. Este modelo de gestión se basa en una estructura de tres niveles compuesto por
miembros tanto de CESCE como del adjudicatario tal y como indica la figura siguiente:
El licitador deberá especificar la metodología de seguimiento del Proyecto propuesta,
que se sustentará como mínimo sobre las siguientes bases:
10 de 65
Comité Operativo
Mediante los comités operativos, se realizará un seguimiento continuo de la evolución del Proyecto entre el responsable del proyecto por parte de CESCE y el responsable o
coordinador de Proyecto de la empresa adjudicataria.
Comité Seguimiento
Comité que realiza un seguimiento continuo y se encarga de asegurar el cumplimiento
de los planes de trabajo, asegurar la calidad, identificar riesgos y proponer planes de acción.
Comité Dirección
Lo componen los máximos responsables del proyecto, tanto por parte del adjudicatario
como por parte de CESCE y es donde se marcan las estrategias y líneas generales de actuación, toma de decisiones respecto a los riesgos detectados, control y aprobación
de cualquier cambio, etc. El Comité de Dirección tendrá un carácter finalista en sus decisiones
Para cada uno de los proyectos, como mínimo se deben identificar las siguientes figuras:
- Director de proyecto de CESCE
- Jefe de proyecto de CESCE
- Director de proyecto del adjudicatario
- Jefe de proyecto del adjudicatario
2.6 Gestión de riesgos
La metodología utilizada para el seguimiento y control de la ejecución de cada proyecto debe tener en cuenta una adecuada gestión de riegos.
Los riesgos de un proyecto son eventos o condiciones inciertas que en el momento de ocurrir pueden ocasionar un impacto negativo en alguno de los objetivos principales
del proyecto: alcance, tiempo, costo o calidad. Un riesgo puede estar relacionado con
Comité Dirección
Comité Seguimiento
Comité Operativo
11 de 65
una o más causas, lo cual a su vez puede generar uno o más impactos en el desarrollo del proyecto.
Es importante que toda la organización alrededor del proyecto actúe de manera activa, anticipada y consistente frente al proceso de gestión de riesgos.
2.7 Responsables del proyecto
CESCE y el licitador designarán cada uno a una persona (responsables de proyecto)
que tendrán la autoridad para representar a su respectiva organización en relación con todos los aspectos del contrato. Los responsables de proyecto canalizarán las
comunicaciones, instrucciones, consultas y notificaciones que se produzcan en la ejecución del contrato y serán sus representantes en el comité de seguimiento.
2.7.1 Responsable del proyecto del adjudicatario
El adjudicatario nombrará un responsable de proyecto que será el interlocutor a nivel
de gestión para los perfiles que el adjudicatario designe. Su función principal será velar por el correcto cumplimiento de las condiciones, plazos y calidad del proyecto
asignado. Sus funciones concretas serán:
• Llevar a cabo el control de plazos, de calidad, de requerimientos y
especificaciones de los proyectos. • La gestión de la provisión de infraestructuras y recursos.
• Efectuar el control económico. • Acordar con CESCE, establecer y evolucionar los procedimientos operativos de
gestión. • Controlar el cumplimiento y calidad del proyecto.
• Coordinar con CESCE los problemas y cambios, informando del estado de los problemas, y facilitando las correspondientes soluciones.
2.7.2 Responsable del proyecto de CESCE
CESCE nombrará un responsable por cada proyecto, encargado de toda la toma de decisiones y adopción de medidas por parte de CESCE para el cumplimiento y
desarrollo adecuado del proyecto contratados. Sus funciones concretas serán:
• Supervisión y seguimiento económico, de plazos, de calidad, de requerimientos y
especificaciones del proyecto. • Provisión de infraestructuras y recursos responsabilidad de CESCE.
• Acordar con el adjudicatario, establecer y evolucionar los procedimientos operativos de gestión.
• Controlar el cumplimiento y calidad del proyecto. • Coordinar con el adjudicatario los problemas y cambios, e informar a éste del
estado de los problemas que impacten capacidad para prestar los servicios. • Canalizar las peticiones del adjudicatario relativas al proyecto.
2.8 Transferencia del conocimiento y gestión de la transición.
El adjudicatario, a la finalización de la relación contractual de cada uno de los lotes,
deberá transferir el conocimiento y toda la documentación actualizada del Proyecto a
12 de 65
CESCE, o a la empresa que CESCE determine, con la suficiente antelación y sin coste adicional al presente Proyecto.
La devolución del servicio tendrá una duración estimada de uno o dos meses, con el fin de que CESCE o un tercero identificado por CESCE se haga cargo del proyecto.
Para ello el adjudicatario definirá un plan de retorno del servicio que recoja con el adecuado nivel de detalle aspectos tales como:
• Planificación.
• Procedimientos y documentación para el traspaso del conocimiento.
• Entregables.
• Cualquier otro aspecto que se considere relevante para un proceso de traspaso
del servicio de calidad.
El adjudicatario presentará en la oferta técnica, un Plan de Transición del Servicio a la
finalización de la implantación y puesta en producción de la plataforma.
Cualquier coste económico asociado al plan de transferencia de conocimiento debe
estar incluidos en la oferta económica del licitador. 2.9 Cumplimiento de los trabajos de esta RFP
El contrato se entenderá cumplido por el contratista cuando éste haya realizado, de acuerdo con los términos del mismo, y a satisfacción de CESCE, la totalidad de su objeto.
2.9.1 Cumplimiento de Plazos y Penalizaciones
El adjudicatario estará obligado a cumplir los plazos y tiempos de respuesta para la
ejecución de cada entrega (entendiendo por entrega, un proyecto, subproyecto, evolutivo, hito o iteración) y en general, para la total realización del contrato.
2.9.2 Penalizaciones por demora
Si el adjudicatario por causas imputables al mismo incurre en demora, o proporciona servicios de una calidad inferior a la especificada en una entrega (subproyecto,
evolutivo, hito o iteración), CESCE podrá optar indistintamente por la resolución del contrato o por la imposición de las penalizaciones que se especifican en la presente
condición. Su importe se calculará en función de los siguientes indicadores:
• Retrasos en las entregas definidas.
• Calidad de los trabajos realizados.
Una entrega se compone de una serie de tareas que culminan en un producto final o
la puesta en productivo de los requerimientos incluidos en dicha entrega.
Cada entrega (subproyecto, evolutivo, hito o iteración) tendrá una fecha de inicio y
fecha de fin comprometida.
La planificación de cada una de las entregas tendrá una duración con una fecha de
inicio y fin que conllevará un esfuerzo en horas y un coste asociado.
La definición de la entrega, su planificación, fecha de inicio y fin serán definidas por
común acuerdo y en otro caso, serán las indicadas por CESCE.
13 de 65
Los importes a aplicar para los indicadores antedichos se fijarán según se indica en las siguientes tablas.
El retraso de una entrega se mide como el porcentaje que representa el número de días laborables de retraso en la entrega respecto a la duración total de la entrega
Penalizaciones por retraso en las fechas de entrega planificadas:
Valor Indicador Penalización
(% Coste de la entrega)
10,1%-15% de retraso 3%
15,1%- 20% de retraso 8%
20,1%- 30% de retraso 15%
Más del 30% de retraso 20%
Penalizaciones por calidad en los entregables de cada entrega
Valor Indicador Penalización (% Coste de la entrega)
Más de 2 defectos por cada 200 horas de esfuerzo
2%
Más de 4 defectos por cada 200 horas
de esfuerzo
5%
Más de 8 defectos por cada 200 horas
de esfuerzo
10%
Se entiende por defectos, en este contexto, aquellos errores encontrados en los entregables o productos finales englobados dentro de una entrega después de haber
sido puesta en producción dicha entrega o entregado el producto final.
2.9.3 Pago de las Penalizaciones
Los importes de las penalizaciones por retraso o por calidad se harán efectivos mediante
deducción de los mismos de la facturación de cada entrega. En caso de ser necesario, por imposibilidad de deducir en una única factura el importe total de las penalizaciones,
se descontarán de facturas sucesivas hasta su completa extinción.
Cada vez que las penalizaciones alcancen un múltiplo del cinco por ciento (5%) del
precio total del contrato, CESCE estará facultado para proceder a la resolución del mismo o acordar la continuidad de su ejecución con imposición de nuevas
penalidades. En este último supuesto, CESCE concederá la ampliación del plazo que estime necesaria para la terminación del contrato.
La aplicación y el pago de estas penalizaciones no excluyen la indemnización por daños y perjuicios a que hubiere lugar.
14 de 65
2.9.4 Demoras no imputables al adjudicatario
Si el retraso fuera producido por motivos no imputables al adjudicatario, a solicitud de éste, CESCE concederá una ampliación del plazo de ejecución como máximo igual al
tiempo perdido a no ser que el adjudicatario solicitase otro menor.
La solicitud de ampliación del plazo por parte del adjudicatario será realizada por
escrito y en el mismo día en que se produzca la causa originaria, alegando las razones que estime imputables al objeto de que CESCE pueda resolver sobre la ampliación del
plazo y tomar las medidas correctoras que correspondan.
En el caso de que el adjudicatario no solicitase ampliación del plazo en el plazo
anteriormente señalado se entenderá que renuncia a su derecho, quedando facultado CESCE para aplicar las penalizaciones correspondientes y el régimen indicado en los
apartados 2.9. 1, 2 y 3.
15 de 65
3 LOTE 1. Diagnóstico y diseño del servicio, producto y canales de contacto con el cliente
3.1 Análisis de contexto
Fase de inmersión en el proyecto para entender los activos fundamentales del proyecto:
Esta fase sirve para conocer la evolución de la empresa y del sector, red de actores y
detección de principales tendencias, inquietudes y retos para la empresa en España y Portugal. Este análisis junto con la situación de partida de CESCE dará una foto de la
situación real del mercado con respecto a CESCE en cuanto a su propuesta de valor y servicio, las necesidades concretas de los usuarios y las tendencias sociales del mundo
que nos rodea.
3.1.1 Descripción
• Análisis comparativo con el mercado (identificación de alternativas sobre qué oferta de valor puede tener el producto para sus clientes y su diferenciación vs.
otras propuestas existentes en el mercado: canales de venta, ventajas competitivas etc.).
• Análisis de la situación actual de CESCE (“as is”) producto, segmentación de clientes, marca, red de distribución, canales de contacto…. Inmersión y
entendimiento de la funcionalidad actual. • Análisis de la marca, su posicionamiento, la relevancia y conocimiento para el
consumidor en un entorno de competencia directa e indirecta. • Segmentación Necesidades Clientes y Clientes Potenciales. CESCE tiene como
eje principal estratégico el Cliente para realizar el análisis del servicio actual e identificar áreas de mejora, es clave poder entender, quienes, cuántos son,
cuáles son sus necesidades y cuál es el contexto en el que podemos interactuar con ellos. Este análisis tiene que permitir crear micro segmentos homogéneos a
partir de las necesidades de los clientes y no clientes (perfil del cliente actual y potencial).
• Análisis de la Red de distribución actual. Detección de los puntos sensibles del proceso de venta. Análisis cualitativo de la red comercial para detectar el grado
de ajuste del proceso a las necesidades reales del cliente así como las necesidades particulares de la red comercial.
• Worskshop conjunto con cliente (producto, benchmark…) • Investigación consumidores (focus groups, encuestas,….)
• Análisis de tendencias, socio-culturales, económicas y tecnológicas que afectan directamente al negocio/sector.
3.1.2 Entregables
• Análisis de comportamiento del cliente • El Customer Journey, “as Is” de la gestión del riesgo comercial (prospección de
clientes, gestión de riesgos, aseguramiento, financiación). • La propensión hacia la contratación de este tipo de productos
16 de 65
• Las variables clave que activan el interés y permiten diferenciarnos de la competencia: en función de los perfiles, de empresa, canales.
• Claves para optimizar la acción de venta del producto por parte de la red comercial
3.1.3 Perfiles
Equipo mínimo involucrado en esta fase:
• Equipo de Research • Consultores investigación cualitativa
• Consultor senior negocio. • Jefe de Proyecto
3.2 Diseño de la propuesta de valor
Una vez realizado el análisis y diagnóstico de la situación actual de CESCE, se requiere realizar una propuesta de acercamiento al mercado que mejore la experiencia y grado
de penetración de nuestra propuesta en el mercado. Para realizar esto se requiere los siguientes elementos:
• Descripción detallada de la metodología para definir la propuesta de valor en sus distintos aspectos, creación de “customer journeys”, diseño de la experiencia
de usuario, identidad de producto, … • Proponer como la oferta de valor y la identidad se relaciona con los diferentes
perfiles de usuarios en todos los puntos de contacto. • Propuesta de diseño de la experiencia de usuario más adecuada con el diseño
más atractivo. • Definir la marca y guía de estilo para los distintos canales y usuarios.
3.2.1 Diseño propuesta valor personalizada y entregables
• Definición de la propuesta de valor
• Definición de la propuesta y valor para cada uno de los segmentos / personas: cómo se posiciona y qué valor va a ofrecerle
• Determinación de los productos y servicios finales que debe incluir la plataforma y cuáles son universales o cuáles son prioritarios por segmento / persona
• Diseño de los Customer Journeys segmentados y el modelo de relación e interacción basado en reglas de negocio (reglas de what if y what if not) y la
propuesta de valor anteriormente definida (por ejemplo la prioridad de productos por segmento)
• Identidad del producto • Imagen Corporativa, naming e Imagen Gráfica. Definición de los valores estéticos
y funcionales en base a los valores de la aplicación, de la marca, a través de referentes estéticos y funcionales.
• Naming & Quick Brand Guide Lines para una puesta en marcha ágil y efectiva. • Brand Manifesto
• Guía y Arquitectura de mensajes por target y segmentos para su aplicación en los diferentes puntos de contacto.
17 de 65
3.2.2 Perfiles
Equipo mínimo involucrado en esta fase:
• Jefe de Proyecto
• Director de Planificación Estratégica / Senior Planner (Comunicación) • Creative Director
• Senior Creative Copywriter • Senior Branding Art Director
• Content Manager • Product Director
3.3 Definición de la plataforma
Partiendo del análisis y diagnóstico de la fase anterior, esta actividad consiste en definir
las especificaciones de la solución en forma de historias de usuario, para que el equipo de desarrollo informático pueda crear la plataforma apropiada.
3.3.1 Diseño del Servicio
En la fase de diseño del servicio, se diseñará la experiencia del cliente desde un punto
de vista global (trascendiendo las funcionalidades del propio producto).
Se definirá el “Customer Journey” ideal por cada segmento de cliente, detallando los
diferentes canales a los que recurrir para la contratación, el uso y la asistencia, además de detallar aquellos puntos de contacto especialmente relevantes y las necesidades
que despiertan.
Tareas:
• Diseño de Blueprint con la experiencia completa desde el punto de vista del
cliente. • Detalle de los wireframes y visualización de esa experiencia sobre la plataforma
3.3.2 Definición Funcional
En la definición funcional, se especificara el alcance total del proyecto a nivel diseño,
contenidos y tecnología. Se definirá la propuesta de valor en base a lo definido en la fase anterior para enriquecer el producto con nuevas funcionalidades y establecer el
modelo ideal de desarrollo tecnológico.
3.3.2.1 Tareas y entregables:
• Definición de la arquitectura de la información. • Definición funcional de la solución tecnológica.
• Definición de requerimientos no funcionales (ciclo de vida, modelo de entrega, rendimiento, seguridad del dato)
• Definición del producto digital:
- Listado y descripción de funcionalidades
- Modelo de desarrollo y metodología - Arquitectura (Tech + Data)
18 de 65
• Diseño de la estrategia SEO global en base a las necesidades identificadas de clientes
• Definición e implantación de la Estrategia de medición digital. Adecuando la estrategia a cada activo digital (Área Pública y Área Privada) y a los diferentes
elementos de medición del entorno offline, posibilitando un entorno medición 360 con el usuario en el centro. Estos son los entregables mínimos del proyecto:
o Plan de medición de negocio: � Definición de los objetivos de negocio y su posterior adaptación
a objetivos de activos digitales. � Identificar los KPIs que darán respuesta a si esos objetivos se
están cumpliendo o no a lo largo del proyecto � Establecer la periodicidad con la que los KPIs serán revisados
para entender su evolución � Elegir los segmentos que aplicados sobre los KPIs ayudarán a
tomar decisiones de negocio � Elegir la visualización óptima para esos KPIs
o Definición casos análisis: Listado de casos de análisis que permitan validar:
� Objetivos de negocio � Comprensión del cliente de la funcionalidad del producto digital � Aceptación y efectividad de los formularios � Customer journey del cliente. � Medición por funnel de conversión y segmento
o Guía de etiquetado: Documento funcional / técnico que permita al equipo de implementación definir tanto en el código como desde el lado del servidor la medición necesaria para cubrir los casos de análisis:
� Documento área Pública � Documento área Privada � Soporte a la implementación
o Auditoría de la implementación: es necesario verificar que toda implementación es óptima y persiste en la herramienta de medición definida.
o Creación de un modelo de datos funcional vinculando la estrategia
definida en el entorno digital con los activos offline.
3.3.3 Diseño de Interfaz
En la fase de diseño de interfaz, partiendo del punto anterior, se propone un diseño de la propuesta de valor y las diferentes interfaces, para cada uno de los canales digitales,
además de la generación de los contenidos.
Se estima que para la definición de la experiencia de usuario habrá 120 wireframes, el
70% de las mismas de alta complejidad diseñadas para 3 dispositivos.
Se entiende que un wireframe de alta complejidad es aquél cuya funcionalidad debe
ser definida desde cero partiendo de un proceso de negocio y están compuestas entre cuatro y seis módulos con interacción en lugar de solo contenidos.
Se entiende que un wireframe de complejidad media es aquel que no cumple lo anterior.
19 de 65
3.3.3.1 Tareas y entregables:
• Definición Customer Journey • Definición experiencia de usuario (120 plantillas, el 70% de las mismas de alta
complejidad diseñadas para 3 dispositivos) • Definición de look and Feel, sobre los wireframes (120) que describen la
funcionalidad. • Creación y carga de contenidos mínimos redaccionales que reflejen la oferta de
valor según la marca, tono y arquitectura de mensajes definida por cada uno de los segmentos definidos.
• Testar el interfaz con clientes • Diseño ilustrativo de piezas de comunicación de marketing (al menos 3)
o Guía de estilo y UI Kit o Documentación y guía de la interacción contemplando navegación,
animación, etc… o Prototipo interactivo sobre los diferentes journeys
Se advierte que el número de plantillas o wireferames indicadas en el presente pliego es una estimación que CESCE considera necesario en este momento y en lo que el
licitador debe apoyarse para la elaboración de la oferta, sin que ello implique compromiso económico para CESCE.
CESCE únicamente abonará al adjudicatario el número de plantillas o wireferames diseñadas y aprobadas durante la vigencia del contrato, pudiendo ser el número de
plantillas o wireferames finalmente demandados diferentes a los estimados en el presente pliego, aunque, en ningún caso, llegando a superar el precio máximo del lote.
3.3.3.2 Perfiles
Equipo mínimo involucrado en esta fase:
• Creative Director • Senior Creative Copywriter
• Content Manager • Diseñador de Experiencia de Usuario Senior
• Diseñador de Interfaz Senior • Service Designer Senior
• Product Director • SEO Strategy manager
• Jefe de Proyecto • Digital Data Manager
3.4 Go to market
En este apartado se requiere definir un planteamiento conceptual sobre la estrategia a
seguir en la distribución, el rol de los distintos agentes involucrados etc.
Para este apartado se solicita unas líneas generales de aspectos a considerar en el
modelo comercial existente y posibles cambios que habría que incluir.
20 de 65
3.4.1 Definición de impacto sobre el modelo comercial actual.
Actualmente CESCE distribuye sus productos mediante distintos canales de ventas (red comercial propia, agentes, brokers, bancos) soportada por una estructura interna
comercial. Para este apartado se requiere analizar a alto nivel la estructura y modelo comercial actual de CESCE e identificar posibles aspectos a tener en cuenta con
respecto al planteamiento de producto elaborado en la fase anterior.
3.4.2 Entregable:
• Consideraciones generales (“guidelines”) con respecto al modelo de distribución comercial para el lanzamiento del nuevo producto y plataforma.
• Identificación y análisis de diferentes alternativas de distribución y canales comerciales
• Diseño de la estrategia comercial (o de sus guidelines) • Análisis del impacto en la estructura de canales actuales y plan de mitigación
• Foco específico en el rol de la red actual: cómo se realiza el onboarding, cómo se forma, se comunica, se mide y sigue su actividad en este sentido
• Sistema de carterización de clientes directos y Rol de la red en los clientes de la plataforma
3.4.3 Perfiles
Equipo mínimo involucrado en esta fase:
• Consultor senior negocio
• Senior Creative Copywriter • Planner estratégico
3.5 Requisito propuesta técnica
La propuesta técnica del licitador deberá contener una valoración en plazo y fechas para cada uno de las siguientes entregas.
• Las entregas identificadas del proyecto cerrado del Lote 1, son: • Análisis del contexto
• Diseño de la propuesta de valor. • Definición de la plataforma
• Go to Market. • Finalización del proyecto de transferencia del conocimiento y formación.
3.6 Garantía y soporte post-implantación
Todos los trabajos realizados dispondrán de un periodo de garantía como mínimo de
cuatro meses. Este periodo de garantía dará inicio en el momento de la validación por parte de CESCE de todos los entregables definidos en el Lote 1.
Esta garantía establece que el adjudicatario se compromete a dar soporte y corrección sin coste alguno para CESCE a cualquier contingencia o duda que pudiera aparecer
relacionada con un entendimiento incorrecto o incompleto del producto entregado en el presente lote y que será desarrollado en el lote 3.
21 de 65
Todos estos aspectos deberán ser corregidos por el licitador tan pronto sean reportados y se les aplicarán las penalizaciones relativas a la calidad identificadas en el apartado
2.9. Cumplimiento de Plazos y Penalizaciones.
Las anomalías detectadas en período de garantía deberán subsanarse sin coste alguno
para CESCE y las nuevas entregas realizadas por el Adjudicatario en subsanación de las mismas quedarán sometidas a las mismas condiciones de validación y garantía
recogidas en este Pliego.
22 de 65
4 LOTE 2. Construcción de un nuevo framework de transformación digital en CESCE y reingeniería de dos aplicaciones del dominio de Risk Management de CESCE.
4.1 Objeto del lote
CESCE precisa disponer de un nuevo framework metodológico y técnico en el campo
de la transformación digital con vista a su gradual implantación a nivel global.
En la actualidad CESCE dispone de unos avanzados sistemas de Gestión del Riesgo y Gestión del Crédito. En el afán de mejorar y dar soporte a los futuros modelos de negocio, CESCE cree conveniente definir una estratégica de arquitectura tecnológica
que se alinee con las necesidades de negocio y las arquitecturas tecnológicas y soluciones emergentes en el mercado, tal que CESCE pueda disponer de una
arquitectura renovada aún más flexible, desacoplada y modular, con nuevas capacidades de futura explotación.
En este contexto CESCE se plantea desarrollar una nueva arquitectura que permita exponer sus capacidades a nuevos modelos de negocio orientados a canales digitales.
Este requisito se conceptualiza como un conjunto de microservicios y APIs, orientadas a la monetización del conjunto de productos o servicios y que por su propia naturaleza
tiende a tener un mayor número de consumidores y se enfoca en facilitar el consumo self service externo. Al mismo tiempo, obliga a tener en cuenta políticas y mecanismos
de gestión, gobierno, securización y monitorización orientados a “producto”.
El despliegue de la nueva arquitectura y la evolución hacia este nuevo modelo de
negocio se materializará en la reingeniería de dos servicios del dominio de riesgos: identificación de empresas y clasificación de empresas.
Esta licitación comprende los siguientes grandes bloques o subproyectos:
1. Definición y diseño de la arquitectura de la era digital 2. Definición e implantación de metodología de desarrollo y explotación, basada
en DevOps 3. Desarrollo e implantación de la Arquitectura 4. Diseño y desarrollo de microservicios y APIs para el servicio de identificación y
clasificación de empresas. 5. Formación al equipo de CESCE. 6. Servicio de mantenimiento evolutivo y soporte.
En este documento se presenta el catálogo completo de premisas, condicionantes,
requerimientos (funcionales, tecnológicos, temporales y de gestión de proyecto) y especificaciones para la realización del proyecto que permita a los proveedores la
elaboración de una propuesta de colaboración que cubra los requisitos que se detallan en este documento.
El desarrollo del proyecto se realizará inSitu, en las oficinas de CESCE y siguiendo metodología DevOps, por lo que existirá una comunicación constante. La participación
23 de 65
de CESCE será constante, pero la responsabilidad del diseño, implementación y puesta en funcionamiento será del proveedor.
Se valorará positivamente la inclusión de mejoras sobre este documento en la propuesta presentada por los distintos proveedores
En este documento se indica exactamente el stack de productos que CESCE ha seleccionado y que son los que deben utilizarse de cara a la presentación de las
propuestas a este RFP y serán con los que se valore la idoneidad de cada una de las propuestas presentadas. CESCE se reserva el derecho a cambiar alguno de estos
productos durante la ejecución del proyecto.
La Arquitectura de Aplicaciones para CESCE deberá proporcionar un enfoque a servicios, de forma que se maximice la reutilización y redunde en un menor acoplamiento de los mismos.
Dichos servicios serán multilenguaje y accesibles desde todo el ecosistema de
Aplicaciones que existe actualmente, y estar preparado para nuevos canales de forma ágil y estándar.
Los procesos de la compañía se modelarán como el uso o la orquestación de varios procesos sin estado.
El Licitador ha de tener experiencia demostrada en las capacidades funcionales, técnicas, de desarrollo, de gestión de proyectos y de soporte de las Tecnologías
expresadas en este pliego.
24 de 65
Las suscripciones Enterprise de productos OpenSource van fuera de este RFP y serán propiedad y a cargo de CESCE (A excepción de WSO2 o IBM Connect, cuya licencia sí
estaría incluida en el coste de este proyecto)
4.2 Descripción de los servicios
El objetivo del proyecto será definir, diseñar e implantar una arquitectura tecnológica y metodológica para el desarrollo del sistema de información corporativo de CESCE, potente y que sea capaz de hacer frente a los requerimientos de agilidad, excelencia operativa, robustez, seguridad, escalabilidad y fiabilidad. Todo ello para permitir una Transformación Digital con un objetivo concreto y tangible:
• Mejorar nuestro actual modelo de negocio: o Optimizar la operativa o Entender y mejorar la experiencia del cliente
• Transformar/crear nuevos modelos de negocio: o Innovar el modelo actual de negocio o Crear nuevos modelos de negocio
• Adaptarnos con Agilidad a los cambios disruptivos provocados por la aparición de nuevos modelos de negocio basados en soluciones digitales.
El proyecto adicionalmente deberá incluir todas las tareas relacionadas con la
definición, diseño, instalación, puesta en marcha y desarrollo de dos APIs (i.e. modelo de licenciamiento, diseño arquitectura técnica, documentación de soporte, diseño de
modelo de desarrollo, modelo de gobierno, etc.)
El fin de una arquitectura empresarial se basa en el alineamiento de las necesidades de
negocio con la visión y solución técnica, dividiéndola en varios puntos de vista.
La Arquitectura que se desarrolle deberá cubrir, de forma coherente, todas las capas
descritas en la figura.
25 de 65
En la imagen siguiente se muestran los componentes a alto nivel que debe tener la arquitectura, a modo de referencia, no se trata de una vista detallada, pero sí indica el
objetivo perseguido:
• Channels: La arquitectura debe ser capaz de soportar diferentes canales: Web,
Móvil, Call Center, Sistemas de terceros… • API Management System: Conjunto de herramientas que permiten la gestión del
ciclo de vida de la API así como el consumo de servicios internos desde fuera de DMZ
• Business Microservices: Conjunto de microservicios que contendrán la lógica de negocio de los aplicativos. Estos microservicios harán uso de sistemas de terceros,
de sistemas internos o del DaaS. • DaaS Microservices: Conjunto de microservicios encargados de facilitar el
acceso al dato a los Business Microservices. El acceso al dato para las aplicaciones sólo será permitido utilizando esta capa.
• Data Intelligence: El objetivo de esta capa es la aplicación de distintos algoritmos ML a los datos con distintos fines: clasificación, agregación, cálculos...
26 de 65
• Data Centric: Las bases de datos tienen un papel crucial. El dato será accedido únicamente por el DaaS y estará compuesto por distintos tipos de bases de
datos: relacional, nosql y data lakes. • Infraestructura cloud: Infraestructure as a Service (IaaS) que permita al equipo
provisionar y escalar de manera eficiente.
4.2.1 Puntos a cubrir por la arquitectura
La arquitectura deberá cubrir todos los siguientes puntos:
1. Seguridad 2. Alto rendimiento 3. Escalado y consumo eficiente de recursos 4. Alta capacidad de integración 5. Omnicanalidad 6. Auditoría 7. Trazabilidad 8. Monitorización 9. Monetización de los servicios 10. Agilidad en el desarrollo y despliegue 11. Unicidad del dato
4.2.2 Los principios
Los principios bajo los cuales debe definirse y construirse esta nueva arquitectura son:
• Cultura “agile” sobre metodología “agile”.
• Autonomía equipos desarrollo • Estándares técnicos abiertos y con gran aceptación en el mercado de
desarrolladores. • Costes variables en la explotación de los aplicativos según aumenta el uso sobre
costes fijos. • Uso de componentes open source con posibilidad de soporte Enterprise de
terceros. • Maximización capacidades integración.
• Soporte multilenguaje para favorecer varios proveedores. • Facilitar innovación y experimentación.
• El centro es la funcionalidad. La lógica del negocio definida por CESCE que da valor a sus clientes.
• Iteraciones de producto en vez de Enfoque de producto completo • Tecnologías cloud nativas/Escalabilidad. Una de las máximas de la arquitectura
proporcionada será la escalabilidad del sistema, de forma que se garantizará la calidad del servicio de manera constante. La arquitectura garantizará:
- Uso eficiente de los recursos, minimizando el consumo en tiempos de baja
volumetría de peticiones. - Escalado automático sin necesidad de realizar intervenciones manuales. El
sistema creará nuevas instancias de los servicios necesarios cuando el número de peticiones aumente.
- Automatización de despliegue de componentes con “zero downtime”.
27 de 65
- Alta tolerancia a fallos. - Seguridad. La seguridad debe ser un requisito incuestionable de cualquier
arquitectura. La seguridad proporcionará las siguientes características: o Single sign on: una vez autenticado, los usuarios deberán poder
acceder al resto de aplicaciones sin tener que volver a introducir las credenciales.
o Cada usuario deberá acceder a los servicios a los que esté autorizado. o Mecanismos para la trazabilidad del uso de la arquitectura.
4.2.3 Ejes tecnológicos
Los ejes tecnológicos bajo los cuales debe estar definida y construida esta nueva
arquitectura tecnológica serán:
• API management • Microservicios
En apartados posteriores, se concreta cómo debe ser la arquitectura tecnologica en estos dos sentidos que se seguirá para la propuesta y posterior proyecto.
4.2.4 Ejes metodológicos
• Continuous Delivery • DevOps
En el mundo en que vivimos, las necesidades de negocio crecen y se renuevan constantemente.
Los procesos de IT necesitan poder responder de forma ágil a las necesidades de los clientes y los usuarios. Para ello deberá contarse con métodos ágiles, permeables al
cambio manteniendo la capacidad productiva de los equipos de trabajo.
Tan importante como adaptarse a los cambios de negocio es la velocidad a la que
llegan esos cambios a producción: cuanto antes lleguen, mayor beneficio para la compañía.
Por tanto, la arquitectura deberá proporcionar mecanismos para:
• Descubrir y gestionar los servicios disponibles.
• Versionar el código facilitando el desarrollo de nuevas funcionalidades y hotfixes sin penalizar otros desarrollos.
• Permitir un desarrollo rápido. • Facilitar mecanismos de despliegue rápidos de forma que los cambios suban lo
antes posible hasta el entorno de producción.
Dentro del proyecto deberán acometerse todas las tareas relativas al diseño y configuración de una arquitectura de desarrollo: herramientas a utilizar, modelo de
desarrollo, software base puestos de desarrollo, empaqueta del software, gestión de la configuración, gestión de la calidad de la aplicación (herramientas pruebas unitarias,
integración, regresión).
28 de 65
4.3 Arquitectura de la era digital
En este apartado vamos a aterrizar cuáles son las bases que deben seguirse para la
elaboración de la propuesta por los proveedores de cara a abordar el proyecto planteado por CESCE.
Se darán las indicaciones de cómo deben abordarse en la propuesta y posterior desarrollo del proyecto.
Se indica cual es el stack de productos a utilizar para cada de las piezas de la arquitectura a crear. CESCE se reserva el derecho a cambiar alguno de estos productos
durante la ejecución del proyecto. Será necesario instalar y configurar todas estas herramientas en CESCE.
Tal y como se indicaba en el apartado de Descripción de los servicios, en la imagen siguiente se muestran los componentes a alto nivel que debe tener la arquitectura, a
modo de referencia. No se trata de una vista detallada, pero sí indica el objetivo perseguido:
4.3.1 Ejes tecnológico: API management
Una API (Application Programming Interface) es una interfaz que recubre una
funcionalidad de negocio provista por una aplicación, y especifica cómo deberían interactuar los diferentes componentes software que se quieran integrar con ella.
Una herramienta de API Management es aquella que permite definir el proceso de publicar, promocionar, supervisar y monetizar APIs en un entorno seguro y escalable.
Asimismo, incluye todos aquellos recursos enfocados a la creación, documentación y socialización de las mismas.
29 de 65
Los API management que CESCE permite ofertar son:
1. Plataforma Open Source WSO2 API Management, en modo SaaS e instalación en EU
2. IBM API Connect, en modo SaaS e instalación en EU
El coste del servicio SaaS del api manager estará incluida en el coste de este proyecto durante todo el período del servicio. El proveedor deberá presentar junto con su
elección un TCO de la solución a medio y largo plazo, con la escala de precios. El servicio SaaS debe además proveer de lo necesario para una conexión segura
(encriptada) a los servicios on-premises
4.3.2 Eje tecnológico: Arquitectura de Integración: microservicios
Para la exposición de las funcionalidades, se debe construir una arquitectura de
microservicios como servicios independientes que interactúen entre ellos.
A alto nivel la arquitectura puede visualizarse según la siguiente imagen:
30 de 65
Los requisitos de esta arquitectura de microservicios son:
• Gestión de configuración. • Descubrimiento de servicios • Resiliencia y Tolerancia a Fallos. • API Gateway. • Seguridad de servicios. • Logs centralizados. • Métricas centralizadas. • Trazabilidad distribuida. • Scheduling y despliegue. • Auto Escalado y Self-Healing • Mantenibilidad • Responsabilidad única de los servicios. • Poliglotismo • Despliegues unitarios y progresivos • Escalado eficiente
Patrón de comunicación
• Se priorizará la comunicación asíncrona sobre la síncrona para la
comunicación entre los servicios, aplicando arquitectura Event Driven en base a colas/brokers de mensajería. Esto permite que la comunicación entre los
distintos dominios sea menos rígida y más desacoplada.
31 de 65
4.3.2.1 Transaccionalidad
La división de los datos en diferentes repositorios (base de datos, colas de mensajes,
etc.) y su accesibilidad a través de servicios que los envuelven supone perder la transaccionalidad.
La arquitectura debe proporcionar implementación de los patrones de diseño que permiten tratar esta situación:
• Reintentar: en situaciones de caída puntual o no disponibilidad parcial del servicio (caída de un nodo por ejemplo), reintentar la
operación puede ser una solución válida. • Abortar la operación completa: en esta situación, debe existir una
operación de ‘compensación’ para volver a un estado de consistencia.
• Transacción distribuida: basa su funcionamiento en la existencia de un proceso de gobierno de la transacción (‘transaction manager’).
4.3.2.2 Componentes de la arquitectura de microservicios a desarrollar
4.3.2.3 Arquitectura Microservicios - Stack de aplicación
La creación de microservicios se realizarán en Java y se utilizará la plataforma Spring:
Spring Boot y Spring Cloud, así como componentes Netflix OSS. A continuación se detallan las principales características, componentes operaciones y componentes
técnicos que se deben utilizar.
Spring Boot
Framework para la construcción rápida de aplicaciones basado en convención-sobre-
configuración.
• Runtime integrado (servidor).
• Capacidades de monitorización out-of-the-box. • Parametrización desacoplada mediante ficheros o servicios externos.
32 de 65
• Auto-configuración basada en anotaciones, sin necesidad de complejos XML. • Gran número de integraciones soportadas oficialmente gracias al stack Spring.
• Bootstraping de aplicaciones mediante Spring Boot Starters.
Spring Cloud
Provee de herramientas para el desarrollo de algunos de los patrones más comunes en
sistemas distribuidos como gestión de configuración, descubrimiento de servicios, circuit-breakers, etc. Se basa en abstracciones sobre componentes liberados a la comunidad
por Netflix y altamente probados en entornos críticos en cuanto a disponibilidad y escalabilidad.
COMPONENTE OPERACIONAL COMPONENTE TÉCNICO
Servidor descubrimiento de servicios Netflix Eureka
Routing dinámico y Balanceo de Carga Netflix Ribbon
Circuit Breaker Netflix Hystrix
Monitorización y logging Dashboard Netflix Hystrix, Elastic Stack y
Turbine
Configuración centralizada Spring Cloud Config Server
Seguridad (OAuth 2.0) Spring Cloud Security + Spring Security
OAuth2
Edge Service Netflix Zuul
Broker de mensajería Spring Cloud Bus + RabbitMQ
Trazabilidad
Spring Cloud Sleuth para todos los servicios
que se encuentren bajo el stack de Java-Spring. Opentracing para otros stack no java.
Dashboards con Zipkin.
33 de 65
Netflix OSS
4.3.2.4 Arquitectura Microservicios - Virtualización de procesos, contenedores (Docker)
Se utilizará la tecnología de contendores Docker, que nos proporciona un nivel de
aislamiento que permite abstraernos de la infraestructura donde estos servicios se ejecutarán y al mismo tiempo, de la elección del stack tecnológico más adecuado
sobre el que están desarrollados los propios servicios.
4.3.2.5 Arquitectura Microservicios – Orquestación de contenedores (Kubernetes)
Será preciso la utilización de Kubernetes para automatizar el despliegue, escalado y gestión de aplicaciones que se ejecutan dentro de contenedores. El uso de Kubernetes
nos permitirá que sea políglota y provee funciones genéricas para provisionar, ejecutar, escalar y administrar sistemas distribuidos.
34 de 65
Este tipo de orquestadores de contenedores se está convirtiendo en la base de la nueva generación de “plataformas como servicio”, proponiendo el concepto de CaaS
(Container as a Service), proporcionando un ecosistema auto gestionado y que puede ser desplegado de la misma forma en infraestructura on premise, virtualizada (IaaS) o
sistemas Cloud gestionados (PaaS)
La instalación y gestión de Kubernetes están fuera del ámbito de este RFP y será realizado por un tercero. Nos referimos a las siguientes tareas:
Instalación y actualización de componentes base de kubernetes
Instalación y mantenimiento del sistema operativo donde correo kubernetes
Monitorización de componentes (demonios) de kubernetes
Mantenimiento arquitectura alta disponibilidad solución kubernetes
Diseño de Integración de red e implementación del mismo en la red de Cesce
Habilitado de nodos interfaz Kubernetes para la publicación de aplicaciones
Backup de configuración de aplicaciones desplegadas
Gestión del storage persistente y efímero de la solución Kubernetes
Creación de registro privado en Kubernetes
Mantenimiento integración de red (ej.: publicar más puertos al exterior)
Monitorización de aplicaciones desplegadas (no solo el contenedor)
Definición de ficheros de descripción de aplicación
Creación de integración de Jenkins con Kubernetes en los pipeline DevOps
Creación de los healthcheck para los servicios Diseño de integración de aplicación con kubernetes (número de réplicas, distribución, etc.)
4.3.2.6 Monitorización (Prometheus)
En entornos tradicionales con despliegues estáticos y máquinas/servicios gestionados
individualmente, los sistemas habituales de monitorización son suficientes; sin embargo, en enfoques orientados a Cloud/microservicios, donde los componentes son dinámicos
y están altamente automatizados, se necesitan soluciones más sofisticadas que permitan agregar la información compuesta de los intervinientes en nuestros entornos
de ejecución.
La Arquitectura de Aplicaciones que se proponga debe proporcionar monitorización
tanto a nivel técnico como a nivel de negocio del estado de los distintos componentes.
Además, debe permitir la trazabilidad de las peticiones de forma que en el sistema
pueda detectarse rápidamente anomalías o fallos de funcionamiento.
Esta monitorización debe ser accesible, a través de la personalización por roles, por
todas aquellas personas involucradas en los procesos con el objetivo de mantenerlos, analizarlos y mejorarlos.
Se propone la implantación de Prometheus, que fue creado pensando en entornos dinámicos y heterogéneos desde el inicio y está amparado por la Cloud Native
Computing Foundation.
35 de 65
Posee integraciones con sistemas como Kubernetes. Permite instrumentar las aplicaciones para la obtención de métricas y KPIs, a la vez que proporciona exporters
que exponen las métricas útiles de aplicaciones de 3os, incluso con protocolos como SNMP o JMX.
4.3.2.7 Trazabilidad (OpenTracing)
La trazabilidad distribuida es crítica para comprender y depurar un sistema basado en
microservicios. Este tipo de instrumentación es complicada ya que se ha de mantener entre los distintos procesos que componen la petición completa. La iniciativa
OpenTracing propone una estandarización mediante un vocabulario y conceptos comunes para los principales lenguajes (Java, .Net, C++, NodeJS, etc.)
Para servicios basados en Java con Spring, se plantea el uso de Spring Sleuth que se encarga de persistir la información anterior entre las los distintos procesos que
intervienen en la petición. Para el caso de tecnologías fuera de este stack, al trabajar sobre el estándar, se podrán aportar implementaciones que implementen la
funcionalidad y que por lo tanto se integren de forma natural.
Toda esta información se ingesta en un sistema de agregación basado en OpenZipkin que nos dará la información en forma de dashboard.
Siempre se tendrá en cuenta que un requisito será utilizar el mismo estándar para otras tecnologías que
se desplieguen sobre la plataforma, en este caso se usará Opentracing.
4.3.2.8 Seguridad
En un sistema donde los clientes de los servicios expuestos como APIs se ejecutan fuera del contexto de seguridad proporcionado por el entorno controlado de nuestra intranet,
como apps móviles, se propone el uso del protocolo OAuth en base al esquema definido a continuación.
Para las aplicaciones basadas en Java + Spring, se plantea utilizar Spring Security, que es el proveedor de seguridad, dentro del framework Spring, que permite gestionar
completamente la seguridad de las aplicaciones Java, y, específicamente, la autenticación y la autorización de usuarios.
Independiente del servidor de aplicaciones, fácilmente extensible y con soporte para CAS, OpenID, certificados, etc.
Es capaz de gestionar la seguridad a varios niveles: URLs solicitadas al servidor, acceso a métodos y clases Java, y acceso a instancias concretas de las clases.
Permite separar la lógica de las aplicaciones del control de la seguridad, usando filtros para las peticiones al servidor de aplicaciones o aspectos para la seguridad en clases y
métodos.
En el caso de que la herramienta de API Management no contemple un servidor OAuth,
se podrá implementar utilizando el mismo framework gracias al proyecto Spring Security OAuth.
4.3.3 Definición e implantación de metodología de desarrollo y explotación
Se utilizará DevOps como método base de trabajo para el proyecto, para el cual se
define un marco de arquitectura que engloba un conjunto de prácticas, herramientas
36 de 65
y procesos, con el objetivo de hacer que el desarrollo y entregas sean más agiles, continuas, automatizadas y eficientes, y para que los desarrolladores y administradores
de sistemas puedan colaborar de una forma más efectiva.
Por tanto, la arquitectura deberá proporcionar mecanismos para:
• Descubrir y gestionar los servicios disponibles.
• Versionar el código facilitando el desarrollo de nuevas funcionalidades y hotfixes sin penalizar otros desarrollos.
• Permitir un desarrollo rápido.
• Facilitar mecanismos de despliegue rápidos de forma que los cambios suban lo antes posible hasta el entorno de producción.
Forma parte de los entregables de este proyecto Definición e implantación de la metodología de desarrollo y explotación basada en DevOps, así como la creación de las plantillas, procedimientos, buenas prácticas de trabajo que permitan esta metodología de trabajo DevOps.
4.3.3.1 DevOps
En el diseño e implantación de la metodología DevOps deberán tenerse en cuenta
todos los aspectos indicados en la siguiente imagen
37 de 65
4.3.3.2 Arquitectura DevOps – Stack de herramientas
En el desarrollo del Proyecto, se utilizará el siguiente stack de herramientas para la
automatización de procesos de desarrollo y entrega continua:
COMPONENTE OPERACIONAL
COMPONENTE TÉCNICO
SCM
Git control versión system: Control de versiones de código fuente y command line c liente para interactura con GitLab
GitLab repository manager server: Se usará para almacenar el código fuente d elos artefactos del proyecto y sus versiones
BUILD
Maven Build automation tool: Gestión de dependencias y construcción de los artefactos del proyecto.
Nexus Artifact repository server: Almacenar las difretenes versiones de artefactos o entregables binarios del proyecto
Gulp JS Build automation tool: Gestión de dependencias y automatización de tareas para artefactos JavaScript
CALIDAD
SonarQube Code quality analizer server: Análisis de calidad del código del proyecto, establecer reglas de calidad, monitorizar y
gestionar la calidad del código.
Pmd code analizer: análisis de calidad del código para entorno
local, para detectar malas prácticas de codificación en tiempo de build process.
38 de 65
CheckStyle: análisis de calidad de diseño y estilo de codificación en entorno local, para detectar problemas en diseño de código,
durante build process.
Cucumber: Definición e implementación de pruebas de criterios
de aceptación basado en BDD
Selenium WebDriver: Grabar/definir/reproducción brower-based
pruebas automáticas para validación/regresión funcional u otro.
JMeter: Pruebas de rendimiento del proyecto.
WireMock: Simular sistemas externos como sustituto de estos en el proceso de testing.
AUTOMATIZACIÓN
Jenkis CI/DV automation server: Construir, orquestar, integrar y
distribuir los procesos de automatización de construcción, integración, entrega y de despliegue continuo.
INFRA
Docker: Contenedor para automatización, despliegue de servicios
y/o aplicaciones
Vagrant: Automatizar la creación y configuración de entornos.
Kubernetes: Despliegue automático, autoescalado, gestión de contenedores de aplicaciones
CONFIG Ansible automation engine software provisioning: Aprovisionamiento y configuración, automatización de tareas.
4.3.3.3 Los distintos entornos en DevOps a utilizar
Se identifica como necesario el uso de los siguientes entornos durante la fase de desarrollo:
1. Entorno de desarrollo local: el PC de cada desarrollador, con un entorno de desarrollo integrado y un runtime ligero para pruebas.
2. Entorno de integración: entorno donde se integran frecuentemente los cambios de todos los desarrolladores a medida que están listos.
3. Entorno de UAT (User Acceptance Test): es el entorno donde el cliente puede
probar una nueva versión antes de que pase a producción para dar el visto
bueno. También se puede usar para pruebas de interfaz de usuario, carga y estrés, bien automatizadas, bien on-demand por parte del equipo de testing.
4. Entorno de producción.
4.3.3.4 Toolset desarrollo
La herramienta de desarrollo será Eclipse y habrá ejecución de dockers integrada con Eclipse, según se muestra en la siguiente imagen:
39 de 65
En la siguiente tabla se detallen otros componentes operaciones y cuál es el componente técnico que habrá que utilizar.
COMPONENTE OPERACIONAL COMPONENTE TÉCNICO
Continuous deploy Jenkins
Continuous testing Maven + Jenkins
Configuration management Ansible
Repositorio artefactos para CI Nexus OSS
Control de calidad estática del código SonarQube
Pruebas automatizadas Junit, Jmeter, Selenium
Este ToolSet permitirá:
• Los desarrolladores pueden probar los cambios y tomar las acciones necesarias
en caso de error. • Cada noche se construyen todos los módulos de forma automática, se ejecutan
los test unitarios y de integración y se realiza un análisis estático de calidad de código mediante SonarQube, informando de los problemas a los interesados.
40 de 65
• Al día siguiente, a primera hora, los desarrolladores disponen de los resultados y corrigen los nuevos problemas encontrados, como mínimo, hasta que se
cumplan los umbrales de calidad establecidos. • Los desarrolladores ven también información de calidad de código de forma
integrada con Eclipse mediante SonarLint.
4.3.3.5 Los Flujos DevOps
Deberán diseñarse, documentarse y procedimentarse los siguientes Flujos (es una representación a alto nivel)
4.4 Apificación del dominio de riesgos
Una vez definida, implementada y documentada la nueva arquitectura, así como
definida la metodología, plantillas, procedimientos, de desarrollo, será necesario su
41 de 65
aplicación a dos servicios del dominio de Riesgos de CESCE: identificación y clasificación de empresas. Para ello será necesario realizar una reingeniería de estos
servicios ya existentes y productivos actualmente y su reescritura total según la arquitectura de referencia diseñada y creada en este proyecto.
Estos servicios serán desarrollados en java y tendrán tanto un caso de uso síncrono como caso de uso asíncrono.
Estos servicios deberán convivir con los sistemas de información actuales.
4.4.1 Caso de Uso 1: Identificación de empresa
En este caso de uso dados una serie de datos de una empresa se buscan todos los datos posibles identificativos sobre ella consultando fuentes propias y externas (vía Webservice y la plataforma de comunicaciones corporativa a través de un API java).
A modo explicativo y esquemático el proceso actual es el siguiente:
4.4.2 Caso de Uso 2: Clasificación de empresa
En este caso de uso se valora la capacidad de una empresa para responder ante un
obligación financiara. Con un conjunto de datos locales y de fuentes externas se procesa con un algoritmo de evaluación de riesgos propiedad de CESCE y
empaquetado en un JAR y accesible a través de un API java.
Este servicio puede ofrecer una respuesta online o en diferido.
A modo explicativo y esquemático el proceso actual es el siguiente:
42 de 65
4.4.3 Reingeniería del dominio de riesgos
La reingeniería para la construcción de estos dos servicios, deberá ser realizará bajo los
siguientes principios:
• Mantener los sistemas actuales funcionando en paralelo y dotar de capas de
abstracción que permitan el posterior apagado progresivo sin grandes impactos. • Contemplar las dependencias de otros sistemas legados que puedan verse
afectados por la refactorización y plantear posible roadmap de migración. Ejecuta rápido e itera.
• Sopesar la coexistencia de distintas tecnologías de desarrollo en base al conocimiento y a la complejidad de su mantenimiento.
• Identificar los servicios síncronos/asíncronos y evitar, en la medida de lo posible, el uso de los primeros para mejorar la eficiencia evitando los posibles bloqueos.
• Identificación de los nuevos dominios de información. Considerar el particionado de los datos entre los servicios expuestos en el API, incluyendo su desnormalización y la
replicación de los mismos. • Contemplar los requisitos de reliability en etapas tempranas de la definición.
• Monitorizar, securizar, escalar, automatizar y pensar en posibles fallos desde el principio.
• Aplicar las mejores herramientas, componentes, APIs y patrones, que se ajusten a cada contexto.
• En ambos procesos se van a crear nuevos modelos de información que prioricen la lectura para dotar de mayor eficiencia a las APIs expuestas y, al mismo tiempo,
promover el desacoplamiento en esta capa. • Servicio de Agencias de Información para que todas las peticiones del nuevo
sistema, y en el futuro desde otros, se realicen desde el mismo punto único y que pueda ser fácilmente expuesto hacia un consumo de terceros, si así se considerase.
• Aislar el Motor de Scoring en un servicio que se pueda evolucionar de forma independiente sin necesidad de que se vean impactadas las aplicaciones que lo
consumen en cambios de versión que no requieran de una modificación de la interface de exposición.
43 de 65
La reingeniería de estos dos servicios en modo microservicios y APIs será total y, permitirá cuantificar el éxito de la implantación de esta arquitectura para poder convencer al
resto de su aplicación.
4.4.4 Convivencia con los sistemas actuales
Con el volumen de aplicaciones y datos que maneja CESCE no es posible pensar en una migración total de la arquitectura existente a una nueva.
La arquitectura proporcionada será capaz de convivir con la arquitectura actual, sin que por ello se produzca una disminución en la calidad del servicio. Por tanto, la
arquitectura proporcionará mecanismos para la sincronización entre la nueva arquitectura y la persistencia existente.
4.5 Modelo de infraestructura
Todo este proyecto se basará en el uso de Infraestructure as a Service (IaaS) que permita
al equipo provisionar y escalar de manera eficiente.
Formará parte de los entregables de este proyecto, la definición de las buenas prácticas
de gobierno para la explotación y operación, siempre racionalizando el uso de la infraestructura.
Se solicita que en este entorno dinámico se alineen los requisitos de seguridad y operaciones con la productividad para conseguir las metas definidas por negocio.
Para ello se deben definir una serie de reglas y/o guías que aseguren que la implantación de los productos software cumpla con las buenas prácticas que han de
tenerse en cuenta en estos ambientes.
Se tiene que tener en cuenta por lo tanto los siguientes puntos fundamentales:
• Control de los elementos. Se requiere la estandarización de las configuraciones, limitar las opciones de configuración y el control de los permisos a los elementos
y su creación. • Monitorización de los elementos. Obtener métricas de uso y salud de cada
elemento identificado que permitan conocer si se hace un uso fuera de los umbrales previamente definidos.
• Corrección. Se deben definir reglas que permitan identificar/eliminar aquellos elementos que no han sido especificados.
• Auditoría. Se han de proponer reviews del ciclo de vida de los elementos que validen su cumplimiento.
• Uso eficiente de la infraestructura
En la medida de lo posible se premiará la automatización de las reglas que se ajusten
las herramientas o mecanismos propuestos para cubrir los requisitos funcionales y operativos.
Como se indica en el apartado de principios, una de las máximas de la arquitectura proporcionada será la escalabilidad del sistema, de forma que se garantizará la calidad
del servicio de manera constante. La arquitectura garantizará:
• Uso eficiente de los recursos, minimizando el consumo en tiempos de baja
volumetría de peticiones.
44 de 65
• Escalado automático sin necesidad de realizar intervenciones manuales. El sistema creará nuevas instancias de los servicios necesarios cuando el número
de peticiones aumente. • Automatización de despliegue de componentes con “zero downtime”.
• Alta tolerancia a fallos. • Autonomía equipos desarrollo
• Costes variables en la explotación de los aplicativos según aumenta el uso sobre costes fijos.
4.6 Formación a CESCE
El proyecto contemplará sesiones de formación a CESCE, o en quien esta delegue, adaptada a los distintos perfiles que participan en la gestión del Ciclo de Vida del
Software, desde el diseño, desarrollo hasta la explotación, en CESCE teniendo en cuenta un DevOps, de la arquitectura de transformación digital construida.
En la propuesta se indicarán las sesiones, contenido, perfiles de los asistentes y planificación preliminar.
Esta formación incluirá tanto formación en la arquitectura, como formación en los dos servicios desarrollados (identificación y clasificación de empresas), así como en el resto
de servicios que se puedan desarrollar dentro de los evolutivos implementados dentro del Servicio de mantenimiento evolutivo y soporte de este pliego, como en el stack de
productos instalados y en las características de su instalación y su gestión.
4.7 Servicio de mantenimiento evolutivo y soporte
Este servicio permitirá la evolución de la arquitectura y el desarrollo de nuevos servicios sobre la misma, adicional a la garantía del proyecto.
La oferta a presentar contendrá un servicio de mantenimiento evolutivo y de soporte de una bolsa de horas cuantificada en dos mil horas, que CESCE estima se puede dividir en
los diferentes perfiles
Servicio de mantenimiento evolutivo y soporte Nº de Horas estimadas
Desarrollador fullstack 1.500
Arquitecto canal digital 500
Se advierte que el número de horas indicadas en el presente pliego es una estimación que CESCE considera necesario en este momento y en lo que el licitador debe apoyarse
para la elaboración de la oferta, sin que ello implique compromiso económico para CESCE.
CESCE únicamente abonará al adjudicatario el número de horas estimadas por cada perfil profesional en cada petición aprobada durante la vigencia del contrato,
pudiendo ser el número de horas o de recursos finalmente demandados diferentes a los estimados en el presente pliego, aunque, en ningún caso, llegando a superar el precio
máximo del lote.
45 de 65
La oferta a presentar contendrá un servicio de mantenimiento evolutivo y de soporte para las siguientes áreas:
• el stack de productos instalados • la arquitectura desarrollada • los servicios desarrollados • nuevos proyectos evolutivos a desarrollar que CESCE estime durante esta fase
En general, una petición de evolutivo requerirá las actividades de toma de
requerimientos y diseño funcional (AF), diseño técnico, construcción (programación, parametrización), pruebas (unitarias / integración / aceptación), documentación,
despliegue en los distintos entornos de ejecución y tareas de soporte al post-arranque de la nueva funcionalidad.
Las peticiones de evolutivo serán priorizados por CESCE.
En el caso de que una solicitud de evolutivo que se esté llevando a cabo deba ser
interrumpida a petición de CESCE, se computará el consumo en el que se haya incurrido hasta el momento de la notificación de la interrupción de los trabajos.
Los nuevos desarrollos se gestionarán en base a estimaciones cerradas de esfuerzo y plazos por petición de evolutivo.
Una vez instalado un desarrollo evolutivo, éste dispondrá de un periodo de garantía. Esta garantía y soporte post-implantación es la descrita en el apartado
Garantía/Soporte post-implantación.
Se seguirán los mismos criterios indicados en el apartado de Cumplimiento de Plazos y Penalizaciones para cada uno de los evolutivos y soportes acometidos.
4.8 Hitos, Tareas y Entregables del proyecto
Vamos a describir las entregas mínimas requeridas a los proveedores para cada uno de
los subproyectos que comprenden el proyecto descrito en este pliego. El proveedor deberá satisfacer estas entregas mínimas e incorporar en su propuesta todas las que
considere de acuerdo al desarrollo del proyecto que plantea.
Los hitos y tareas comprendidas para cada subproyecto serán a grandes rasgos:
4.8.1 Definición y diseño de la arquitectura de la era digital
4.8.1.1 Hito 1.1
1. Diseño técnico de los componentes de la arquitectura. 2. Definición de la arquitectura y herramientas (DevOps).
3. Definición de las tipologías de la aplicación (contenedores). 4. Identificación de los requisitos de seguridad.
5. Identificación de los requisitos de monitorización. 6. Identificación de requisitos de gobierno/auditoría.
7. Diseño y dimensionamiento de la infraestructura. 8. Definición de los perfiles necesarios para el mantenimiento y evolución de las
nuevas herramientas
4.8.1.2 Hito 1.2
1. Identificación del escenario base de despliegue de la plataforma de API Management y las dependencias con las que integrar el producto.
46 de 65
2. Establecer la estrategia de definición de nomenclatura y versionado a seguir en el diseño de las interfaces de las APIs.
4.8.2 Definición e implantación de la metodología de desarrollo y explotación
basada en DevOps
4.8.2.1 Hito 2.1
1. Definición de la metodología de desarrollo: cómo utilizar las herramientas, modelo de desarrollo, software base puestos de desarrollo, empaquetado del
software, gestión de la configuración, gestión de la calidad de la aplicación (herramientas pruebas unitarias, integración, regresión)
2. Patrones de diseño 3. Normativa de programación
4. Guía de buenas prácticas de desarrollo 5. Configuración del entorno de desarrollo
6. Diseño del modelo de provisión del entorno de desarrollo
4.8.2.2 Hito 2.2.
1. Definición de los procedimientos de administración, seguridad, monitorización y explotación.
2. Seguridad. Se deberá definir el uso de las funcionalidades de seguridad proporcionadas por cada una de las piezas de la arquitectura diseñada.
3. Monitorización. Se deberá definir el uso de las funcionalidades de monitorización proporcionadas por cada una de las piezas de la arquitectura diseñada.
4. Gestión de la configuración, definición y utilización del modelo de Gestión de Configuración a utilizar tanto en este proyecto, como en los futuros que se
implementen con esta arquitectura. 5. Se elaborará un procedimiento de paso entre entornos basado en DevOps para
las aplicaciones desarrolladas con esta arquitectura, así como se generarán los scripts necesarios para permitir su automatización
6. Se definirán las plantillas para la documentación de los servicios, mecanismos para su búsqueda. Los servicios serán documentados en Swagger.
4.8.3 Desarrollo e implantación de la Arquitectura
Una vez definida y diseñada la arquitectura, será preciso su desarrollo e implantación. Los hitos y tareas a nivel genérico serán:
4.8.3.1 Hito 3.1: Capa de acceso a datos
1. Acceso a BBDD.
2. Integración con sistemas externos.
4.8.3.2 Hito 3.2: Componentes transversales
1. Módulo de mensajería. 2. Módulo de seguridad.
3. Módulo de monitorización. 4. Módulo de gestión de errores.
5. Módulo de configuración. 6. Módulo de auditoría.
47 de 65
7. Módulo de caché.
4.8.3.3 Hito 3.3: Arquitectura de ejecución
1. Implantación de arquitectura base. 2. Configuración de componentes del Framework de arquitectura.
3. Módulos de soporte EIP. 4. Integración con componentes transversales.
4.8.3.4 Hito 3.4: Arquitectura de desarrollo
1. Implantación y configuración de las herramientas de soporte al ciclo.
2. Dimensionamiento de las piezas de runtime. 3. Desarrollo de módulos de soporte a los procesos de entrega.
4. Integración con repositorios de usuario y perfilado. 5. Creación de entornos de desarrollo local.
6. Integración con los servicios intervinientes. 7. Definición de guía de pruebas (unitarias, integración, regresión, E2E, estrés).
4.8.3.5 Hito 3.5: Plataforma de ejecución
1. Implantación y configuración.
2. Dimensionamiento según los requisitos de volumetría y concurrencia.
4.8.3.6 Hito 3.6: API
1. Implantación y configuración de la plataforma API Management en los diferentes entornos.
2. Creación de APIs o políticas de autenticación e integración con módulos de seguridad.
3. Creación de políticas base. 4. Aplicación de la definición previa de diseño y gobierno.
5. Creación de políticas ad hoc si fuese necesario. 6. Manuales y documentación.
4.8.3.7 Hito 3.7: Arquitectura de información
1. Implantación y configuración de servicios.
2. Dimensionamiento según los requisitos de volumetría y concurrencia. 3. Integración con repositorios de usuario y perfilado.
4. Aplicación de modelos previamente definidos.
4.8.4 Diseño y desarrollo de servicios y APIs para el servicio de identificación y
clasificación de empresas.
Una vez implementada la arquitectura, será preciso el diseño, desarrollo e implantación. De los servicios de identificación y clasificación de empresas. Los hitos y tareas a nivel
genérico serán:
4.8.4.1 Hito 4.1: Diseño de Servicios y API para identificación
1. Análisis funcional y técnico. 2. Definición de los patrones de integración.
3. Identificación de los casos de prueba. 4. Definición del dominio de información y los modelos que lo soporten.
48 de 65
4.8.4.2 Hito 4.2: Desarrollo de microservicios y APIs para identificación
1. Creación de las políticas adhoc y base.
2. Desarrollo de los servicios. 3. Desarrollo en entorno sandbox.
4. Integración con las demás piezas de arquitectura y dependencias de seguridad. 5. Creación de las pruebas unitarias, de integración y carga.
6. Documentación y manuales. 7. Definición y elaboración del catálogo de servicios REST a exponer.
8. Identificar las entidades de negocio del catálogo de servicio y formar las APIs según la estrategia establecida.
4.8.4.3 Hito 4.3: Diseño de Servicios y API para clasificación de empresas
1. Análisis funcional y técnico.
2. Definición de los patrones de integración. 3. Identificación de los casos de prueba.
4. Definición del dominio de información y los modelos que lo soporten.
4.8.4.4 Hito 4.4: Desarrollo de microservicios y APIs para clasificación empresas
1. Creación de las políticas adhoc y base. 2. Desarrollo de los servicios.
3. Desarrollo en entorno sandbox. 4. Integración con las demás piezas de arquitectura y dependencias de seguridad.
5. Creación de las pruebas unitarias, de integración y carga. 6. Documentación y manuales.
7. Definición y elaboración del catálogo de servicios REST a exponer. 8. Identificar las entidades de negocio del catálogo de servicio y formar las APIs
según la estrategia establecida.
4.9 Entregas
Para todos los casos, las entregas deberán ir precedidas de la realización de las
oportunas pruebas, que se llevarán a cabo por el Adjudicatario conjuntamente con CESCE y/o las personas que ésta designe, que definirán la profundidad y alcance de las
pruebas, sin perjuicio de que CESCE podrá siempre indicar que se complete la batería prevista con otras pruebas adicionales de mayor amplitud, con el fin de comprobar el
correcto funcionamiento y su adecuación al diseño funcional y técnico, de forma que se pueda detectar en esta fase cualquier error, disfunción o falta de adecuación a los
requerimientos. El Adjudicatario asume el compromiso de solucionar en los plazos que CESCE indique cualesquiera errores, disfunciones o defectos que presente la solución en
este momento, antes de su puesta en producción. A estos efectos, la entrega solo se entenderá producida una vez CESCE confirme y valide el funcionamiento estable y adecuado y el Adjudicatario ponga a disposición de CESCE la documentación y materiales necesarios con el fin de conseguir la adecuada puesta en funcionamiento
de las labores realizadas, y, en especial, entregará la integridad del código fuente documentado de los programas resultantes de las labores realizadas por el
Adjudicatario, así como la documentación preparatoria o intermedia, la
49 de 65
documentación técnica y cualquier otra derivada de tales labores, incluida la que se genere en los procesos de análisis, diseño, desarrollo, implantación y realización de
pruebas, y los manuales de uso (cuando sean requeridos) en el formato e idioma indicado por el CLIENTE.
4.10 Requisito propuesta técnica
La propuesta técnica del licitador deberá contener una valoración en plazo y fechas
para cada uno de las siguientes entregas.
• Definición y diseño de la arquitectura de la era digital
• Definición e implantación de la metodología de desarrollo y explotación basada en DevOps.
• Desarrollo e implantación de la Arquitectura • Diseño y desarrollo de servicio y API para el servicio de identificación de
empresas • Diseño y desarrollo de servicio y API para el servicio de clasificación de empresas
• Finalización del proyecto de transferencia del conocimiento y formación
4.11 Formación a CESCE
4.11.1 Hito 5.1: Formación
1. Definición de sesiones de formación/transferencia conocimiento a CESCE o a
quien CESCE delegue en su nombre, según perfiles y material necesario. 2. Preparación de documentación de apoyo a la formación, que sea necesario
adicionalmente a la documentación generada durante el proyecto. 3. Impartir formación
4.12 Ejecución y Gestión del Proyecto
4.12.1 Horario y condiciones de los Servicios
El horario de los servicios que el Suministrador deberá prestar es de lunes a viernes en
horario de 8,00 a 18,30 horas.
En función de las necesidades de CESCE, podrá definirse la necesidad de un soporte
24x7, únicamente para la corrección de incidencias críticas fuera del horario laboral. En dicho caso, se acordaría también el coste de dicho servicio.
El Idioma del servicio será en castellano. La documentación funcional o destinada a los usuarios finales estará siempre en castellano, pudiéndose utilizar el inglés, solo en casos
excepcionales y para la documentación técnica.
Los canales de comunicación serán siempre los establecidos por CESCE a través de las
herramientas propuestas de Gestión de Portfolio y Proyectos (CA-Clarity) y las de ticketing para gestión de incidencias, peticiones y cambios (CA-Service Desk). El uso de
los procedimientos internos y operativos que establezca CESCE adaptados, si fuese necesario, a las necesidades de estos servicios, será un claro objetivo para garantizar la
correcta interpretación por ambas partes.
CESCE tiene la potestad de modificar y evolucionar estas herramientas cuando
entienda necesario. Será responsabilidad del adjudicatario las adaptaciones de
50 de 65
cualquier interface que se haya creado para facilitar o mejorar la entrega del servicio; así como la adaptación de sus procedimientos a la nueva herramienta o versión.
51 de 65
4.12.2 Equipo de proyecto
Se identifican como imprescindibles los siguientes perfiles dentro del equipo de proyecto:
Nº de efectivos
Perfil Dedicación
1 Jefe de proyecto 100% 1 Arquitecto SW FULLSTACK SENIOR. LIDER TÉCNICO:
microservicios, integración API management ,integración componentes y métodos de trabajo agile.
40%
1 Arquitecto canal digital 40% 1 Consultor API management 15% 1 Técnico especialista en despliegue y configuración API
Management 20%
2 Desarrollador fullstack 80% 1 Arquitecto integración DevOps 50%
4.13 Garantía / Soporte post-implantación
En esta fase el adjudicatario dará soporte y corrección a cualquier contingencia que
pudiera aparecer relacionada con un funcionamiento incorrecto del producto final, del stack de productos o de la documentación generada.
El alcance del soporte post implantación se circunscribe a la garantía por parte del implantador del correcto funcionamiento de todas y cada una de las funcionalidades,
instalaciones de producto, documentación generada, identificadas en el presente Pliego de Prescripciones Técnicas.
Se considerará como un funcionamiento incorrecto aquellos defectos en el funcionamiento del producto tales como pérdidas de funcionalidad, requerimientos
incompletos, bugs de programa o calidad del software, documentación incompleta o de baja calidad, incorrecta/ no optima instalación del stack de productos, incorrecto
uso eficiente de las infraestructuras etc.,
Todos estos aspectos deberán ser corregidos por el licitador tan pronto sean reportados
y se les aplicarán las penalizaciones relativas a la calidad identificadas en el apartado de Cumplimiento de Plazos y Penalizaciones
Todos los servicios prestados ofrecerán un periodo de garantía mínimo de tres meses, quedando entendido tal periodo a partir de la validación por CESCE de su entrada en
servicio en entorno productivo.
Se realizará la gestión de la resolución de las incidencias recibidas desde CESCE,
incluyendo la cualificación (impacto y complejidad), asignación de prioridades y resolución. No se permitirá que ninguna incidencia quede sin resolver. Si la resolución
no fuera posible por los técnicos de desarrollo del adjudicatario, será responsabilidad de éste escalar la situación a CESCE y llevar a cabo la consulta a los proveedores
responsables del producto o entorno en el que está fallando la aplicación
52 de 65
La corrección de los defectos funcionales y técnicos de las aplicaciones cubiertas por el servicio de mantenimiento correctivo incluye:
• Análisis del error / problema.
• Análisis funcional y técnico de la solución.
• Desarrollo de las modificaciones a los sistemas (programación y/o configuración), incluyendo pruebas documentadas.
• Mantenimiento de las documentaciones técnicas y funcionales del sistema.
• Despliegue en los distintos entornos
• Elaboración de lecciones aprendidas
Las anomalías detectadas en período de garantía deberán subsanarse sin coste
alguno para CESCE y las nuevas entregas realizadas por el Adjudicatario en
subsanación de las mismas quedarán sometidas a las mismas condiciones de
validación y garantía recogidas en este Pliego.
53 de 65
5 LOTE 3. Construcción de una plataforma digital para CESCE
5.1 Objeto del lote
CESCE precisa de los servicios de asistencia técnica para la construcción de una
plataforma digital para la gestión del crédito comercial que incorpore funcionalidades de libre acceso y acceso transaccional a servicios de gestión de crédito.
5.2 Objetivo y alcance del proyecto
El objetivo del proyecto es disponer de servicios de asistencia técnica para la construcción de una plataforma digital.
Esta plataforma debe ser un ecosistema integrado de soluciones tecnológicas que proporcione a CESCE la capacidad completa para desarrollar cualquier iniciativa de
negocio que se canalice en un entorno digital.
En esta plataforma se pone al cliente en el centro de los desarrollos y la arquitectura
pivota en torno al “Customer Engament”, esto es, que se generen acciones por y para el cliente y se construye un offering modular y adaptado a cada cliente basado en dos
planos:
- El plano de servicios proporciona a los clientes y usuarios utilidades para mejorar
la gestión operativa de sus créditos. Los servicios son la palanca que deben
permitir hacer cross/up – selling de productos.
- El plano de los productos proporciona toda la utilidad completa para gestionar
los productos contratados más allá de lo que es posible integrar en la capa de
servicios.
La plataforma a construir debe constar de al menos:
• Uno o varios Front públicos abiertos basados en un CMS (Drupal). Estos front, siguen un esquema de captación de usuarios freemium, por lo que además de
información, proporciona utilidades gratuitas que persiguen que los usuarios anónimos se conviertan en registrados.
• Uno o varios Front públicos para usuarios registrados. • Plataforma/s transaccional privada para usuarios registrados y clientes que les
permite interactuar con los servicios y productos disponibles y se adapta a las características del usuario.
Las principales características que debe cumplir la plataforma a construir son:
• Basada en productos open source.
• Permitir la gestión de varios modelos de negocio como modelo de suscripción,
modelo freemium, etc.
• La experiencia del usuario debe estar adaptada a cualquier dispositivo
(Responsive dising y multidispositivo).
• Permitir la contratación de productos y servicios.
54 de 65
• Permitir definir estrategias de marketing digital como monetización de clientes y
estrategias digitales donde se puedan incluir todos los espacios relevantes en
donde el target objetivo interactúe.
• Debe ser multi-idioma, multi-compañía
• Disponer de un interfaz de administración. La plataforma está orientada a
empresas, por esa razón se pide que tengan la opción de dar de alta múltiples
usuarios por empresa, con perfilado de servicios por cada usuario. (si fuera
posible con la opción de poder delegar la seguridad de cada empresa a un
administrador de la empresa).
• Control de accesos de la plataforma delegada en el sistema corporativo de
seguridad de CESCE que permite interconexión con protocolo OAUTH 2.
• Disponer de una zona de servicios parametrizable en función del usuario y sus
características.
• La integración con los servicios del back-end es mediante la arquitectura de
microservicios y API's que se define en el lote 2 del presente pliego
• La construcción del "Front End" debe estar basada en un framework SPA
(angular js, react js,..) con soporte responsive sobre un framework estándar con
conexiones a los diferentes microservicios de negocio.
• Servicio backend for frontend que permita orquestar las llamadas a servicios en
base a los flujos de interacción definidos, así como la gestión de contenidos del
área transaccional, construido sobre tecnologías abiertas que permitan la
entrega en ciclos de desarrollo ágil (PHP, Python, Ruby, Node o equivalentes)
• La construcción de cualquier componente no front deberá seguir las directrices,
framework de desarrollo, arquitecturas y metodologías definidas en el lote 2 del
presente pliego.
• De forma general, la plataforma debe manejar el flujo de la presentación. La
lógica de negocio residirá en los microservicios y APIs,
• Implantación de herramienta de medición: área pública y área.
transaccional/privada.
• Creación de funnels de navegación adaptados a los distintos perfiles de
usuarios y objetivos de negocio.
• Implantación técnica estrategia SEO.
• Disponer de un bloque de servicios dentro de la plataforma que permita mostrar
cuadros de mando (es decir una herramienta de BI con capacidad OLAP)
donde el usuario tendrá toda la información de sus propios clientes y de las
facturas de sus clientes y tendrá opciones de filtrado por distintos criterios (zona
geográfica, sector, facturas pendientes, o un cliente concreto) y de
visualización gráfica. Para desarrollar este bloque se utilizara una base de datos
de alto rendimiento (DRUID; CASSANDRA; hbase, opentsdb, ...) con Highcharts
(o algo equivalente).
55 de 65
5.3 Plan de desarrollo del proyecto
El licitador deberá presentar un Plan de Trabajo acorde a la metodología ágil definida
en el que se describan las diferentes fases e iteraciones del Proyecto, con las tareas que se van a realizar.
Existirá una fase inicial cuyo objetivo es la definición del product backlog, o documento
de alto nivel para todo el proyecto. Es el conjunto de todos los requisitos de proyecto.
Este documento debe contener descripciones genéricas de funcionalidades deseables, priorizadas según su retorno sobre la inversión (ROI). Representa lo que va a ser
construido en su totalidad. Para la realización de esta fase es requisito necesario disponer de versiones avanzadas de los entregables definidos en el Lote 1.
Con el fin de una mejor gestión y control de los trabajos a realizar, se considera apropiado el fraccionamiento del Proyecto de implementación y puesta en productivo
de la plataforma en Iteraciones (o sprint) de construcción.
Cada iteración o sprint se compone de un conjunto de requisitos y su alcance incluye, desde el desarrollo, pruebas, pruebas de aceptación del usuario y puesta en
producción y documentación.
Una vez definida el alcance de una iteración en conjunto con los responsables de
CESCE, será necesario que el adjudicatario realice
• Cronograma de las actividades detallado
• Recursos técnicos que participan en la iteración
• Relación de entregables como resultado de la iteración.
• Definición de plazos de realización
• Coste de dicha iteración.
56 de 65
Una vez definida una iteración y aprobada por CESCE, los plazos y costes se consideraran compromisos firmes para el adjudicatario. A dichos compromisos firmes se
les aplican las condiciones definidas en el apartado 2.9. Cumplimiento de Plazos y Penalizaciones y el coste definido en dicho compromiso se descontará del presupuesto
adjudicado a este lote dentro del presente pliego. Cumpliéndose siempre la condición de que el sumatorio de todos los subproyectos o iteraciones derivadas del presente lote
no puede superar el precio máximo del lote.
Cada iteración al menos debe contemplar:
• Desarrollo del código necesario para la implementación de la integración de
los flujos de interacción con los servicios de negocio.
• Desarrollo y maquetación de la interfaz web responsiva.
• Definición y ejecución del plan de pruebas end-to-end.
• Elaboración de la guía de explotación del servicio y manuales de usuario.
• Implantación de herramienta de medición: área pública y área.
transaccional/privada.
• Creación de funnels de navegación adaptados a los distintos perfiles de
usuarios y objetivos de negocio.
• Auditoria implementación técnica.
• Implantación técnica estrategia SEO.
• Documentación técnica y funcional asociada a la iteración.
• Despliegue y puesta en producción de los desarrollos incluidos en la iteración.
Para todos los casos, las entregas de cada iteración deberán ir precedidas de la
realización de las oportunas pruebas, que se llevarán a cabo por el Adjudicatario conjuntamente con CESCE y/o las personas que ésta designe, que definirán la
profundidad y alcance de las pruebas, sin perjuicio de que CESCE podrá siempre indicar que se complete la batería prevista con otras pruebas adicionales de mayor amplitud,
con el fin de comprobar el correcto funcionamiento y su adecuación al diseño funcional y técnico, de forma que se pueda detectar en esta fase cualquier error, disfunción o
falta de adecuación a los requerimientos. El Adjudicatario asume el compromiso de solucionar en los plazos que CESCE indique cualesquiera errores, disfunciones o defectos
que presente la solución en este momento, antes de su puesta en producción. A estos efectos, la entrega solo se entenderá producida una vez CESCE confirme y valide el funcionamiento estable y adecuado y el Adjudicatario ponga a disposición de CESCE la documentación y materiales necesarios con el fin de conseguir la adecuada puesta
en funcionamiento de las labores realizadas, y, en especial, entregará la integridad del código fuente documentado de los programas resultantes de las labores realizadas por
el Adjudicatario, así como la documentación preparatoria o intermedia, la documentación técnica y cualquier otra derivada de tales labores, incluida la que se
genere en los procesos de análisis, diseño, desarrollo, implantación y realización de pruebas, y los manuales de uso (cuando sean requeridos) en el formato e idioma
indicado por el CLIENTE
57 de 65
5.4 Garantía y soporte post-implantación
Todos los desarrollos realizados dispondrán de un periodo de garantía como mínimo de
tres meses. Este periodo de garantía dará inicio en el momento de la validación por CESCE de la puesta en producción de cada desarrollo.
Esta garantía establece que el adjudicatario se compromete a dar soporte y corrección sin coste alguno para CESCE a cualquier contingencia que pudiera aparecer
relacionada con un funcionamiento incorrecto del producto final durante el periodo arriba descrito.
Se considerará como un funcionamiento incorrecto aquellos defectos en el funcionamiento del producto tales como pérdidas de funcionalidad, requerimientos
incompletos, bugs de programa o calidad del software, documentación incompleta o de baja calidad, etc.
Todos estos aspectos deberán ser corregidos por el licitador tan pronto sean reportados y se les aplicarán las penalizaciones relativas a la calidad identificadas en el apartado
2.9. Cumplimiento de Plazos y Penalizaciones.
Las anomalías detectadas en período de garantía deberán subsanarse sin coste alguno
para CESCE y las nuevas entregas realizadas por el Adjudicatario en subsanación de las mismas quedarán sometidas a las mismas condiciones de validación y garantía
recogidas en este Pliego.
58 de 65
5.5 Equipo de trabajo y perfiles requeridos
La oferta deberá incluir el equipo de trabajo propuesto por el licitador para la realización
del Proyecto.
El número de componentes del equipo y su composición para cada iteración del
proyecto será decisión del contratista y deberá ser aprobada por CESCE, de forma que todas las iteraciones estén finalizados en el plazo y coste comprometido.
CESCE considera conveniente la constitución de un equipo mínimo de técnicos, con los perfiles descritos en el Anexo "Perfiles Profesionales" que deberán estar a lo largo de toda
la ejecución del proyecto.
El equipo mínimo estimado para la prestación de los servicios solicitados estará formado
por:
Nº Efectivos Perfil Número estimado de
horas
1 Jefe de proyecto 1.000
1 Responsable de experiencia usuario 400
1 Arquitecto canal digital 200
1 Data web analyst 100
2 Desarrollador fullstack 1.600
2 Diseñador 1.200
1 Desarrollador PHP exp Drupal 500
1 Arquitecto Front 400
2 Desarrollador Front 1.600
TOTAL 7.000
Se advierte que el número de horas indicadas en el presente pliego es una estimación
que CESCE considera necesario en este momento y en lo que el licitador debe apoyarse para la elaboración de la oferta, sin que ello implique compromiso económico para
CESCE, pudiendo ser el número de horas o de recursos finalmente demandados diferentes a los estimados en el presente pliego, aunque, en ningún caso, llegando a
superar el precio máximo del lote.
Para cada iteración definida y aprobada por CESCE, los plazos y costes se consideraran
compromisos firmes para el Adjudicatario. En su consecuencia, CESCE únicamente abonará al adjudicatario el número de horas efectivamente incurridas por cada perfil
profesional en cada iteración aprobada durante la vigencia del contrato, sin que en ningún caso se abone un importe superior a aquellas horas que fueron estimadas.
59 de 65
5.6 Formación
Se deberá contemplar en la oferta presentada cuáles van a ser las actividades de
formación de la solución ofrecida. El Plan de Formación debe, en cualquier caso, abarcar todos los aspectos del Proyecto cubriendo las necesidades de formación de
los diferentes usuarios relacionados con el sistema incluyendo el área técnica de CESCE.
Las actividades formativas se coordinarán en todo momento con los responsables
funcionales, gestores de clientes y responsables de formación de CESCE, estando ésta enfocada a la formación de formadores, usuarios claves de la herramienta así como a
la oficina técnica de CESCE.
5.7 Lugar de Prestación del Servicio
Los trabajos objeto del presente Lote se realizarán principalmente en las instalaciones de CESCE en Madrid.
60 de 65
6 Descripción de perfiles involucrados Planner estratégico: Experto en la definición estratégica de lanzamiento de productos al mercado, diseñando el plan de lanzamiento, la estrategia de canales de
comunicación y mensajes clave. (Lote 1)
Product Director: Responsable último de la definición funcional del producto, así como
de sus diferentes canales. Más de 10 años de experiencia en la definición de productos digitales con equipos de trabajo en metodologías agile. Su dedicación será del 100%
durante las fases de definición y diseño, y del 50% a lo largo del desarrollo. (Lote 1).
Director de Planificación Estratégica / Senior Planner (Comunicación): experto en
planificación estratégica de comunicación y posicionamiento de productos y servicios desde una perspectiva de insights de consumidor. Experiencia en creación de
estrategias de comunicación para lanzamiento en diferentes medios y canales. Al menos más de 6 años de experiencia. (Lote 1).
Creative Director: responsable creativo con experiencia en creación de ideas y conceptos creativos transversales para lograr la diferenciación de productos y servicios,
ideas innovadoras y notorias que tengan un marcado carácter digital. Con al menos 5 años de experiencia en agencias creativas, branding o similares. (Lote 1).
Senior Creative Copywriter: encargado de generar conceptos, ideas y redacción de contenidos en base a la propuesta de posicionamiento e idea de marca. 3 años de
experiencia. (Lote 1).
Content Manager: encargado de asegurar la alineación de los contenidos generados
para el proyecto a la estrategia de negocio y marca definida, supervisar y realizar el guardianship de su creación y redacción y de la calidad de su subida a producción. 3
años de experiencia. (Lote 1).
Senior Branding Art Director: director de arte y diseñador senior, experto en creación de
identidades corporativas y brand guidelines aplicadas bajo una perspectiva 360 de comunicación y con especial sensibilidad en entornos digitales. 10 años de experiencia.
(Lote 1)
Jefe de proyecto. Dedicación mínima: 80% a lo largo de todo el proyecto. (Lote 1,2 y 3).
- Formación específica en Scrum y herramientas de seguimiento y control de proyectos ágiles (Jira Agile, Cosmo).
- Capacidad de análisis, comprensión de problemas de negocio, y búsqueda de soluciones técnicas.
- Habilidades personales de comunicación, resolución de conflictos y solución de problemas.
- Más de cinco años de experiencia en proyectos de desarrollo software gestionados con metodologías ágiles, en proyectos complejos con equipos de
trabajo grandes. - Diplomatura, licenciatura, ingeniería técnica o superior relacionada con las
Tecnologías de la Información. - Experiencia demostrable en la dirección de proyectos con metodologías Devop
61 de 65
Consultor senior negocio. Con más de 3 años de experiencia en el definición de modelos de relación con los clientes, diseño de Customer Journeys de clientes y definición de
propuesta de valor segmentada además de portfolios de P&S por segmento. (Lote 1).
Arquitecto SW FULLSTACK SENIOR. LIDER TÉCNICO. microservicios, integración API
management, integración componentes y métodos de trabajo agile. Será el responsable de la definición de la solución tecnológica y responsable de la interlocución
de los equipos de tecnología del proveedor y CESCE. (Lote 2).Será obligatorio:
- Diplomatura, licenciatura, ingeniería técnica o superior relacionada con las
Tecnologías de la Información - Experiencia demostrable de 5 años en diseño e implementación de
orquestación de microservicios con la suite de orquestación y gestión de microservicios Netflix. Componentes: Hystrix, Ribbon, Eureka, Turbine y Zuul
- Experiencia demostrable de 5 años en diseño de aplicativos basados en microservicios usando tecnología springboot y APIs.
- Experiencia demostrable en diseño de integración de fuentes de datos heterogéneas.
- Experiencia en arquitecturas con componentes de base de datos NOSQL - Experiencia demostrable en diseño e implantación de soluciones con
microservicios con soporte de escalado horizontal y enfoques de aplicación stateless.
- Experiencia en definición de fragmentado de funcionalidades para convertirlas en microservicios
- Experiencia demostrable de definición de despliegues orquestados de microservicios en contenedores.
- Experiencia demostrable aplicando métodos arquitecturales formales así como justificación de decisiones arquitecturales en los diseños.
- Experiencia en gestión de configuración de aplicativos Contenerizados - Experiencia demostrable en creación de arquitecturas de integración entre API
Managers y servicios (o microservicios) de backend
Arquitecto canal digital. Arquitecto de SW microservicios, integración API management,
integración componentes y métodos de trabajo agile. En el caso de existir el Líder técnico (Lote 2), dependerá de él y en el caso de no existir será el responsable de la
definición de la solución tecnológica y responsable de la interlocución de los equipos de tecnología del proveedor y CESCE. (Lote 2 y 3). Será obligatorio:
- Diplomatura, licenciatura, ingeniería técnica o superior relacionada con las Tecnologías de la Información
- Experiencia demostrable de 3 años en diseño e implementación de orquestación de microservicios con la suite de orquestación y gestión de
microservicios Netflix. Componentes: Hystrix, Ribbon, Eureka, Turbine y Zuul - Experiencia demostrable de 3 años en diseño de aplicativos basados en
microservicios usando tecnología springboot y APIs. - Experiencia demostrable en diseño de integración de fuentes de datos
heterogéneas. - Experiencia en arquitecturas con componentes de base de datos NOSQL
62 de 65
- Experiencia demostrable en diseño e implantación de soluciones con microservicios con soporte de escalado horizontal y enfoques de aplicación
stateless. - Experiencia en definición de fragmentado de funcionalidades para convertirlas
en microservicios - Experiencia demostrable de definición de despliegues orquestados de
microservicios en contenedores. - Experiencia demostrable aplicando métodos arquitecturales formales así como
justificación de decisiones arquitecturales en los diseños. - Experiencia en gestión de configuración de aplicativos Contenerizados
- Experiencia demostrable en creación de arquitecturas de integración entre API Managers y servicios (o microservicios) de backend
Consultor API management. (Lote 2). Será obligatorio:
- Diplomatura, licenciatura, ingeniería técnica o superior relacionada con las
Tecnologías de la Información - Experiencia demostrable en consultoría de adopción de api management
desde cero y definición de estrategia API de al menos 2 años - Experiencia creando modelos de relación con integradores y estructura de
portal del desarrollador de al menos 2 años. - Experiencia demostrable en la asistencia en un proyecto de despliegue de un
api manager para uso de entidades externas al propietario de al menos 2 años - Experiencia trabajando en entornos de proyectos ágiles
Técnico especialista en despliegue y configuración API Management. (Lote 2). Será obligatorio:
- Diplomatura, licenciatura, ingeniería técnica o superior relacionada con las Tecnologías de la Información
- Experiencia demostrable en implantación de soluciones de API management, tanto la parte de plataforma como en la configuración e integración del
producto. - Experiencia demostrable en aplicación de modelos de seguridad dentro de un
API manager - Experiencia trabajando en entornos de proyectos ágiles
Arquitecto integración DevOps. (Lote 2).Será obligatorio:
- Diplomatura, licenciatura, ingeniería técnica o superior relacionada con las
Tecnologías de la Información - Experiencia demostrable de 2 años en definición de pipelines DevOps y diseño
de arquitecturas de integración continúa. - Experiencia demostrable de 2 años en uso de la herramienta open source
“Jenkins” para orquestación de workflows DevOps e integración con herramientas externas.
- Experiencia demostrable de 2 años en uso de la herramienta open source “Jenkins” para orquestación de workflows DevOps.
- Experiencia trabajando en entornos de proyectos ágiles
63 de 65
Responsable de experiencia usuario: Responsable de usabilidad con 5 años de experiencia. Experto en CX / UX / UI. (Lote 3). Será obligatorio:
- Minuciosidad y gusto por el detalle para crear interfaces "pixel perfect" basadas en retículas adaptables y adecuadas para la producción digital.
- Habilidad para ilustrar y crear conceptos gráficos que doten de personalidad a la aplicación y ejecutarlos ejerciendo una dirección creativa o propagar una ya
determinada.
- Experto en composición gráfica, principios universales de diseño, teoría del color,
etc.
- Generación de libros de estilo: Definición de componentes gráficos, layouts,
colores y tipografías.
- Manejo profesional de software de producción gráfica para llevar a cabo todas
las anteriores.
- Capacidad de presentar y defender su diseño en público y a la vez encajar otros
puntos de vista.
Consultor _UX: Profesional con 5 años de experiencia especializado en CX/UX/UI que da
soporte al responsable de UX. Diseño responsive, creación de flujos de navegación y definición de interacciones. (Lote 3). Será obligatorio:
- Profundo conocimiento de los principios de interacción hombre-máquina, diseño centrado en usuario, arquitectura de información, diseño de interacción,
etc.
- Experiencia y habilidad en la dirección de dinámicas de grupo como test con
usuarios, card sorting, mapas de historias de usuario.
- Excelente capacidad de comunicación oral y escrita para exponer su trabajo
en público, elaborar entregables y redactar documentación.
- Habilidades de negociación para tratar con equipos dispares como,
especialistas en marketing, departamentos comerciales, jefes de proyecto, directores de negocio, desarrolladores de software, etc.
- Manejo a nivel profesional del software necesario para desempeñar todas las tareas descritas.
Consultor investigación cualitativa: Mínimo 3 años de experiencia en el desarrollo de proyectos dentro del sector con un componente de investigación cualitativa (focus,
shadowing, netnografy, etc.). (Lote 1).
Data web analyst: Experto en definición de métricas web, definición e implantación de
dashboards de seguimiento. (Lote 3).
Responsable de contenidos: Encargado de la definición de la estrategia de contenidos
que deberá ser implantada en la plataforma en su fase de operación.
Desarrollador fullstack : (Lote 2 y 3) Será obligatorio:
- Diplomatura, licenciatura, ingeniería técnica o superior relacionada con las Tecnologías de la Información
64 de 65
- Experiencia demostrable en programación de microservicios en springboot a ser ejecutados en contenedores.
- Experiencia creando componentes que permitan escalado horizontal - Experiencia en la creación de contenedores para contener aplicativos basados
en springboot - Experiencia de 2 años en el desarrollo y despliegue de APIs
- experiencia en integración continua y herramientas asociadas (GIT, Jenkins, Maven,junit, jmeter, selenium,etc)
- Conocimientos de patrones de diseño, patrones arquitecturales, programación concurrente, síncrona y asíncrona, y en general algoritmos, estructuras de datos
y buenas prácticas en desarrollo software orientado a objetos. - Experiencia en diseño de modelos de datos tanto en entornos relacionales como
no relacionales (NoSQL). - Experiencia de 2 años trabajando en entornos de proyectos ágiles
Responsable SEO con más de 7 años de experiencia en Estrategia de Marketing de
Captación y marketing de atracción (Lote 1). Será obligatorio experiencia en :
- Solvencia en análisis de datos cuantitativos y cualitativos, incluidos estadística
descriptiva, modelización y predicción, y A/B testing. - Experiencia en programación de Perl, Python, PHP y front y bases de datos
MySQL. - Conocimientos básicos de programación batch scripting, y R.
- Experiencia en Data Mining, análisis en Excel y R. - Experiencia en gestión y proyectos de marketing en múltiples sectores, mercados
e idiomas
Métricas: Equipo con experiencia en definición avanzada de métricas en sector con
customer journeys complicados (financiero, seguros, etc...) en al menos 5 años experiencia (Lote 1).
Director de investigación cualitativa: Al menos 10 años de experiencia liderando proyectos de investigación cualitativa. Alta capacidad para generar insights de valor
que aporten claves estratégicas sobre el consumidor y den foco a las fases posteriores. Amplia experiencia en investigación multipais. (Lote 1).
Técnico senior de investigación cualitativa: Al menos 8 años de experiencia, con capacidad de realización de trabajo de campo cualitativo B2B en español, portugués
e inglés. Gran capacidad de profundizar en actitudes, percepciones vivencias y motivaciones (Lote 1).
Técnico junior de investigación cualitativa: Al menos 2 años de experiencia como moderador y analista. (Lote 1)
Service Designer: Diseñador de servicios con más de 4 años de experiencia en el diseño de customer journeys. Con experiencia demostrable en proyectos de Service Design.
(Lote 1).
Desarrollador Front: Desarrollador con mínimo 5 años de experiencia. (Lote 3). Será
obligatorio
65 de 65
- Conocimiento profundo de los distintos dispositivos / navegadores y sus peculiaridades.
- Profundo conocimiento de frameworks como Angular, REACTJs o vueJS y maquetación en HTML5/CSS3
- Conocimientos en canvas y gráficos mediante librerías como puede ser D3js
- Conocimiento profundo de Javascript y alguno de los distintos frameworks MV*
desarrollados en Javascript (Angular, Backbone, Ember, React, etc.).
- Profundo conocimiento de frameworks de testing Javascript (Protactor, Mocha,
Jasmin, QUnit, etc.)
- Amplia experiencia en el desarrollo de aplicaciones REST, consumo de servicios,
API's, etc.
- Experiencia en desarrollo de proyectos en modelo DevOps utilizando técnicas y
herramientas de integración continua y continuous delivery.
Arquitecto Front: Arquitecto Front con mínimo 8 años de experiencia con conocimientos en gestión de aplicativos REST, gestión de entornos de desarrollo Front automatizados ,
conocimientos de JavaScript puro y de frameworks como Angular, REACTJs o vueJS,a sí como experiencia en HTML5/CSS3 (lote 3).
Desarrollador PHP exp Drupal: Desarrollador mínimo 5 años de experiencia con PHP para generación de métodos personalizados, así como CMS Drupal (lote 3).
Diseñador: Visual designer con 5 años de experiencia. (Lote 3).
- Experto en UX/UI, diseño responsive, creación de flujos de navegación y
definición de iteraciones.
- Conocimiento profundo de los distintos dispositivos / navegadores y sus
peculiaridades.
- Profundo conocimiento de HTML5, CSS3
- Profundo conocimiento de Javascript (manipulación de DOM) y/o JQuery (o similar).
- Más de tres años de experiencia en maquetación de sitios / aplicaciones web
