LICITACIÓN DE LOS SERVICIOS DE FÁBRICA DE SOFTWARE …

(c) Consorci de Transports de Mallorca Página 1 de 28

LICITACIÓN DE LOS SERVICIOS DE

FÁBRICA DE SOFTWARE PARA EL APOYO Y

EL REFUERZO EN LAS TAREAS DE

DESARROLLO DEL SISTEMA CENTRAL DE GESTIÓN, CÁMARA DE COMPENSACIÓN E

INTERFACES DE INTEGRACIÓN DEL

PROYECTO 2019

CONSORCI DE TRANSPORTS DE MALLORCA

2016-11-16 – v1.0

Área de Tecnología y Comunicaciones

Consorci de Transports de Mallorca


Índice

1. INTRODUCCIÓN ................................................................................................. 5

2. OBJETO Y CONTENIDO ........................................................................................ 6 2.1. Características de la R4 ................................................................................. 6 2.2. Alcance del servicio ...................................................................................... 6

2.2.1. Software ............................................................................................... 6 2.2.2. Sistemas ............................................................................................... 7

3. Servicios de software .......................................................................................... 8

3.1. Perfiles y recursos humanos de la fábrica de software ........................................ 8 3.1.1. Arquitecto Java ...................................................................................... 8 3.1.2. Programador sénior ................................................................................ 9

3.1.3. Equipo de recursos adscritos .................................................................. 10 3.2. Relación con el adjudicatario ........................................................................ 11

3.2.1. Estructura de personal del CTM asignada a la fábrica de software ................ 11 3.2.2. Estructura de personal del adjudicatario asignado a la fábrica de software .... 12

3.3. Metodología y herramientas ......................................................................... 12

3.4. Parámetros de calidad ................................................................................. 13 3.4.1. Rotación del personal ............................................................................ 13 3.4.2. No adecuación del personal .................................................................... 14

3.4.3. Calidad de código ................................................................................. 14 4. Servicios de sistemas ....................................................................................... 15 5. DOCUMENTACIÓN ............................................................................................ 17

6. PROPIEDAD INTELECTUAL Y CONFIDENCIALIDAD ................................................. 18 6.1. Propiedad intelectual .................................................................................. 18 6.2. Confidencialidad ......................................................................................... 18

6.2.1. Datos personales .................................................................................. 18 6.2.2. Sobre la documentación y el negocio ....................................................... 18

7. CALIDAD DEL SERVICIO. ANS MÍNIMOS EXIGIDOS ............................................... 20

7.1. ANS de rotación de personal ........................................................................ 20 7.1.1. Garantías de rotación ............................................................................ 20

7.2. ANS de calidad de código ............................................................................ 20

7.2.1. Garantías de calidad de código ............................................................... 21 7.3. ANS de productividad.................................................................................. 21

7.3.1. Garantías de productividad .................................................................... 22

8. Aspectos generales, económicos y de puntuación .................................................. 23 8.1. Importe económico ..................................................................................... 23

8.1.1. Lote 1. Fábrica de software .................................................................... 23

8.1.2. Lote 2. Servicios de sistemas ................................................................. 23 8.2. Forma de pago ........................................................................................... 23 8.4. Modelo normalizado de las ofertas ................................................................ 24

8.4.1. Lote 1. Fábrica de software .................................................................... 24 8.4.2. Lote 2. Sistemas .................................................................................. 24

8.7. Valoración del Lote 1. Fábrica de software ...................................................... 25

8.7.1. Criterios de valoración ........................................................................... 25 8.8. Valoración del Lote 2. Sistemas. ................................................................... 26

8.8.1. Criterios de valoración ........................................................................... 26


Tabla de acrónimos

Abreviación

CTM Consorci de Transports de Mallorca

R3 Versión (release) 3 del Sistema de Información del Transporte

R4 Versión (release) 4 del Sistema de Información del Transporte

SIT Sistema de Información del Transporte

CPD Centro de Procesamiento de Datos

MaaS Mobility as a Service

ANS Acuerdo de Nivel de Servicio


1. INTRODUCCIÓN

El Plan Director Sectorial de Transportes de las Illes Balears, aprobado por el Decreto 41/2006, de 28 de abril, establece como uno de los objetivos esenciales la integración

tarifaria de los títulos de transporte de los diferentes operadores de transporte público. De conformidad con lo dispuesto en el artículo 7, letra f, de la Ley 8/2006, de 14 de junio,

de creación del consorcio de transportes de Mallorca, el Consorci (de ahora en adelante CTM) es la entidad responsable de elaborar, aprobar, implantar y gestionar un marco tarifario común para la prestación del servicio público regular de viajeros.

Dentro de este marco competencial, el CTM está desarrollando un proceso de definición de un nuevo sistema tarifario integrado en el que intervienen diferentes operadores

tecnológicos, los cuales aportan los elementos técnicos necesarios para alcanzar la plena implantación del sistema tarifario integrado. En concreto, se trata de empresas especializadas, cada una de las cuales está realizando tareas diferenciadas pero a la vez

complementarias y dirigidas hacia un mismo objetivo (antes mencionado). Dichas tareas consisten en: el suministro, la instalación y la puesta en marcha de un sistema de venta y validación de títulos de transporte —SVV— para las concesiones de los servicios regulares

permanentes de viajeros por carretera de Mallorca; las adaptaciones y el desarrollo del software de estos equipos o del software de gestión de datos; y el suministro, la instalación y el desarrollo del sistema de venta de los billetes para los servicios públicos de

transporte, entre otras.

Se trata, por lo tanto, de actividades que requieren una coordinación adecuada con el fin de garantizar la compatibilidad de las herramientas y de los procedimientos tecnológicos que cada uno de los operadores utiliza.

Además, el CTM ha desarrollado en los últimos ocho años su propia plataforma software, que incluye los elementos siguientes:

Sistema central de gestión Cámara de compensación

IOManager Centro de control de acceso tarifario Validadores automáticos de liquidaciones

Portal de informes e inteligencia empresarial etc.

Este ecosistema software tendrá que migrar/adaptarse al nuevo sistema tarifario integrado y a las nuevas reglas de negocio. Todo ello hace que no sea posible abordar estas tareas con los recursos actuales y dentro del plazo exigido (1 de enero de 2019).

La fecha de 1 de enero de 2019 viene impuesta por la renovación de todas las concesiones de transporte regular de Mallorca. La migración al nuevo sistema tarifario coincidirá con el

inicio de las nuevas concesiones.


2. OBJETO Y CONTENIDO

Este pliego regula las condiciones que han de regir la contratación del servicio de programación de aplicaciones y mejora tecnológica para llevar a cabo las adaptaciones

técnicas y de negocio de los sistemas de información del CTM, de acuerdo con las directrices y los objetivos marcados por la citada entidad.

2.1. Características de la R4

El CTM actualmente desarrolla, opera y explota la tercera generación, de ahora en adelante R3, de su plataforma Mobility as a Service, en adelante MaaS. La licitación que describe este pliego prevé el refuerzo de su departamento de software para acometer las

tareas de programación de la cuarta generación de la plataforma MaaS, en adelante R4. Los objetivos principales de esta versión son los siguientes:

100 % en línea. La nueva R4 no dispondrá de servicios por lotes o diferidos. La totalidad de los servicios ofrecidos serán en línea.

100 % en tiempo real. La R4 responderá a las necesidades del negocio en tiempo real, entendiendo «tiempo real» en el sentido que establece su definición formal: programa informático que responde a las peticiones con la rapidez requerida por el

usuario o el proceso que lo invoca. 0 % tiempo de inactividad. De las dos premisas anteriores se deduce esta. Un

sistema 100 % en línea y 100 % en tiempo real no puede tener caídas, ni parciales ni totales.

Esta reingeniería completa de la R4 requerirá, además, un refuerzo en el área de sistemas del CTM, con el fin de implementar los mecanismos de hardware, red y almacenaje necesarios para garantizar los objetivos anteriores.

2.2. Alcance del servicio

El servicio licitado se compone de dos lotes diferenciados. El primer lote de servicios licita los servicios de ayuda a la programación de la R4 en forma de fábrica de software mixta. El segundo lote licita los servicios de refuerzo del área de sistemas del CTM, que han de

dar apoyo a la R4.

2.2.1. Software

El CTM precisa aumentar la capacidad de producción de software de su departamento de

aplicaciones. Por esta razón licita los servicios de fábrica de software en horas anuales según la tabla siguiente:


Recurso Cantidad Horas anuales totales1

Arquitecto Java 0,5 900 Programador Java sénior 3 5 400 Perfiles especiales No determinado No determinado

Totales: 3,5 6 500

2.2.2. Sistemas

El CTM precisa aumentar la capacidad de gestión, configuración y mantenimiento de su departamento de sistemas. Por esta razón licita el servicio de asistencia técnica de un

ingeniero de sistemas en plantilla a tiempo completo (35 h semanales) = 1800 horas/año

Recurso Cantidad Horas anuales totales2

Ingeniero de sistemas sénior 1 1 800

Totales: 1 1 800

1Se considera que un recurso realiza 1 800 horas anuales. 2Se considera que un recurso realiza 1 800 horas anuales.


3. Servicios de software

3.1. Perfiles y recursos humanos de la fábrica de software

3.1.1. Arquitecto Java

El arquitecto Java constituye la pieza principal del servicio. Será el (único) enlace del CTM con la fábrica de software y, por lo tanto, el único interlocutor válido.

Condiciones a cumplir por los profesionales propuestos por la empresa adjudicataria: Ingeniería Informática / Ingeniería Técnica Informática de Gestión o Sistemas

Se valorarán# las certificaciones siguientes:

PMP o equivalente PMI-ACP o equivalente

Experiencia mínima de cinco años en estándar Java y en las tecnologías siguientes:

JavaEE EJB, POJO, JSF, JPA, SOAP (JAXWS), REST (JAXRS), etc.

Angular, BootStrap, HTML, CSS, JS, etc.

Maven, JUnit

Jboss / Wildfly Entornos de desarrollo: Eclipse, NetBeans, IntelliJ

Documentación de proyectos: Procedimientos, blogs, wikis, etc.

Bases de datos SQL. Modelado, diseño y optimización Sistema de control de versiones: Subversión o GIT

Se valorará# la experiencia en las tecnologías siguientes:

Docker Experiencia demostrable en proyectos de un volumen como mínimo igual al

especificado en este pliego. Experiencia mínima de tres años en servicios en línea. El CTM migrará toda su

plataforma de servicios a un modelo exclusivamente en línea. Se entienden por servicios


en línea los que, por ejemplo, ofrecen un metabuscador de hoteles, una agencia de viajes

web o un banco de camas. Cualquier caída de la plataforma se traduce directamente en pérdidas de explotación. Así, pues, es imprescindible contar con experiencia en este tipo

de plataformas, concretamente: arquitectura orientada a servicio;

arquitectura orientada a rendimiento; y

arquitectura orientada a alta disponibilidad y redundancia. Puesto que el arquitecto es el elemento clave del servicio, el CTM valorará# que el

adjudicatario aporte perfiles superiores en formación, experiencia y dedicación siempre y cuando:

si mejora la formación, aporte documentos oficiales que lo acrediten; si mejora la experiencia, aporte documentos oficiales que lo acrediten;

si mejora la dedicación, aporte oferta firmada con la mejora ofrecida.

3.1.2. Programador sénior

Los perfiles de programador sénior serán los encargados de implementar las

funcionalidades que el CTM requiera. Condiciones a cumplir por los profesionales propuestos por la empresa adjudicataria:

Ingeniería Informática / Ingeniería Técnica Informática de Gestión o Sistemas

Experiencia mínima de cinco años en estándar Java y en las tecnologías siguientes: Java EE

EJB, POJO, JSF, JPA, SOAP (JAXWS), REST (JAXRS), etc.

Angular, BootStrap, HTML, CSS, JS, etc. Maven, JUnit

Jboss / Wildfly

Entornos de desarrollo: Eclipse, NetBeans, IntelliJ Documentación de proyectos: Procedimientos, blogs, wikis, etc.

Bases de datos SQL. Modelado, diseño y optimización

Sistema de control de versiones: Subversión o GIT Experiencia mínima de tres años en servicios en línea. El CTM migrará toda su

plataforma de servicios a un modelo exclusivamente en línea. Se entienden por servicios en línea los que, por ejemplo, ofrecen un metabuscador de hoteles, una agencia de viajes web o un banco de camas. Cualquier caída de la plataforma se traduce directamente en


pérdidas de explotación. Así, pues, es imprescindible contar con experiencia en este tipo

de plataformas, concretamente:

arquitectura orientada a servicio; arquitectura orientada a rendimiento; y

arquitectura orientada a alta disponibilidad y redundancia.

3.1.3. Equipo de recursos adscritos

Con «equipo de recursos adscritos» hacemos referencia al conjunto de programadores que

están a disposición del CTM, de forma exclusiva o no, en el marco de este contrato. Para que el CTM admita un recurso en dicho equipo, el adjudicatario deberá cumplir los requisitos siguientes:

deberá estar formado en las tecnologías, herramientas y metodologías utilizadas en el proyecto del CTM;

deberá contar con los conocimientos necesarios relativos al negocio del CTM para que, en caso de necesidad, pueda incorporarse a las tareas de codificación sin demora

cuando el CTM lo solicite;

deberá haber solicitado por escrito al CTM la adscripción al equipo y el CTM deberá haber aceptado tal solicitud.

Condiciones del equipo: El CTM podrá solicitar al adjudicatario la eliminación de un recurso del equipo si

existen indicadores de falta de cualificación, formación, productividad o calidad del mismo. El adjudicatario tendrá que consignar el estatus de cada recurso del equipo de la

forma siguiente: Prioritario -> recurso del equipo con dedicación exclusiva o casi exclusiva al CTM

Titular -> recurso del equipo sin dedicación exclusiva al CTM pero con amplios conocimiento técnicos del mismo y con interacción continua con el servicio.

Reserva -> recurso del equipo con colaboraciones puntuales en las tareas encargadas por el CTM y con conocimientos técnicos suficientes pero no al nivel de los dos

anteriores. El CTM valorará# la oferta del adjudicatario en función de la configuración del

equipo que presente, siendo mejor valorados los recursos «prioritarios» y peor valorados los «reserva».

Los recursos adscritos al equipo que excedan de los «prioritarios» + «titulares» podrán ser requeridos por el CTM con el objetivo de absorber picos de demanda.


3.2. Relación con el adjudicatario

Mediante este contrato, el CTM pone en manos del adjudicatario buena parte del desarrollo y de la actualización de su actividad principal. Por lo tanto, es requisito

indispensable la definición de la metodología de trabajo con el fin de garantizar el desarrollo de un producto de alta calidad, así como el cumplimiento de los plazos del proyecto.

3.2.1. Estructura de personal del CTM asignada a la fábrica de software

El CTM asignará dos recursos a la fábrica de software: un jefe de proyectos para la gestión técnica del proyecto y un director del contrato para la gestión administrativa y ejecutiva

del mismo. Jefe de proyectos -> será el encargado de gestionar la fábrica de software.

Realizará los requerimientos a la fábrica de software y será el interlocutor del arquitecto de la misma. Entre sus funciones principales, se encuentran:

redactar diseños funcionales; valorar en esfuerzo los desarrollos y acordar el valor con el arquitecto software;

realizar el seguimiento de las tareas en marcha para garantizar calidad, plazo y funcionalidades;

definir las pruebas unitarias a cumplir por cada funcionalidad;

aceptar o rechazar las entregas de funcionalidad en virtud de los parámetros de calidad y de las pruebas unitarias;

valorar y calificar la totalidad de los recursos humanos asignados a la fábrica de software; valorar la idoneidad de cada uno de los perfiles y trasladar esta valoración al director del contrato del CTM.

Director del contrato -> es el responsable de la licitación del CTM. Lleva a cabo tareas ejecutivas de control y seguimiento, como por ejemplo:

realizar el seguimiento económico del contrato;

garantizar el correcto funcionamiento de la fábrica de software en virtud de los parámetros de calidad, dimensionamiento y conocimientos técnicos;

asegurar en todo momento que el personal adscrito a la fábrica de software por parte del adjudicatario es idóneo;

asegurar la implementación y la entrada en producción de todas las funcionalidades necesarias para el proyecto 2019-R4;

gestionar los riesgos y prevenir y mitigar las crisis.


3.2.2. Estructura de personal del adjudicatario asignado a la fábrica de software

El adjudicatario, aparte de los recursos descritos en el apartado de alcance, tendrá que asignar los recursos siguientes y designarles, como mínimo, las funciones siguientes:

Responsable de RRHH. El responsable de RRHH será el encargado de seleccionar los perfiles de la fábrica de software que más se ajusten a las necesidades del CTM y al proyecto. Sus funciones principales, aparte de la mencionada, se describen a

continuación: ejercer de interlocutor entre el jefe de proyectos y el director del contrato del CTM;

gestionar los recursos humanos asignados a la fábrica de software del contrato;

gestionar y prevenir la rotación de personal; elaborar un plan de formación de los perfiles, formación continua, etc.

Director del contrato:

ejercer de interlocutor principal del director del contrato del CTM;

garantizar el correcto funcionamiento de la fábrica de software en virtud de los parámetros de calidad, dimensionamiento y conocimientos técnicos;

gestionar los riesgos y prevenir y mitigar las crisis.

3.3. Metodología y herramientas

La metodología de desarrollo y gestión de proyectos del CTM se basa en Agile-Scrum y

será la que regirá el contrato de servicios: Se programarán reuniones de planificación, para extraer y organizar las tareas, y

reuniones periódicas para hacer el seguimiento de las mismas. Las reuniones se planificarán con una frecuencia no superior a treinta días, si bien por necesidades del servicio el CTM podrá solicitar reuniones ad hoc. El CTM permite las reuniones telemáticas,

aunque, a su discreción, podrá solicitar reuniones presenciales cuando así lo considere oportuno. Estas reuniones presenciales no devengarán dietas ni otros conceptos facturables que no sean las horas realizadas por el arquitecto.

El arquitecto del adjudicatario y el jefe de proyecto del CTM se entrevistarán todos los días con el fin de seguir el estado de las tareas diarias, los riesgos, desvíos y

cumplimientos. Las estimaciones se harán de forma tradicional, en horas, no en puntos.

Se harán entregas continuas de los productos que se estén desarrollando.

El código fuente desarrollado pertenece al CTM y estará alojado en sus repositorios. Las


entregas se harán a través del SCV (sistema de control de versiones), haciendo un uso

adecuado de enlaces/canales de subida, ramas/bifurcaciones, etiquetas, solicitudes de incorporación de cambios, etc.

El adjudicatario tendrá que hacer uso y demostrar solvencia y experiencia con las herramientas siguientes:

SCV GIT o Subversion

JUnit. Pruebas unitarias. JMeter, Apanche Benchmark, u otras pruebas de rendimiento.

Jenkins. Integración continua

Sonarqube. Calidad de código. Artifactory. Gestión de artefactos/librerías.

Maven.

Dada la elevada cantidad de proyectos a desarrollar y gestionar, se valorará# que el adjudicatario proponga una herramienta de gestión de carteras de proyectos. La herramienta proporcionada tendrá que incluir todas las licencias perpetuas necesarias o

bien encontrarse bajo una licencia de código abierto. Se tendrán que describir íntegramente las funcionalidades de la herramienta, así como sus capacidades a la hora de presentar informes de seguimiento de medio y alto nivel (gerenciales), detectar

desviaciones y corregirlas.

3.4. Parámetros de calidad

3.4.1. Rotación del personal

Con el fin de poder implementar las funcionalidades que el CTM defina, se tendrá que

transferir a la fábrica de software un tanto por ciento del conocimiento de negocio del CTM. Esta transferencia permitirá llevar a cabo las tareas encargadas en los términos acordados y con la calidad requerida en este pliego. Como contrapartida, el CTM tendrá

que destinar recursos y esfuerzos a la formación del equipo adscrito a la fábrica de software para transferirles estos conocimientos. Es por este motivo que una elevada rotación en el equipo adscrito sería crítica para el éxito del proyecto y la correcta

realización del contrato.

El CTM impone una rotación máxima de un 25 % del equipo de recursos adscritos a lo largo de todo el contrato. Este límite superior y las salvaguardias en caso de

incumplimiento del mismo se encuentran documentados y especificados en el apartado del ANS de este pliego.

El volumen máximo del equipo que el CTM permite es el doble del personal necesario para

llevar a cabo las horas solicitadas en caso de dedicación completa. Es decir, si el CTM pide 3 x 1 800 horas anuales y 1 800 horas son las horas que puede trabajar un recurso, el

equipo máximo permitido es de 6 programadores. Esta limitación se establece para evitar que, al proponer un equipo sobredimensionado con recursos ficticios, se supere de facto el 25 % máximo de rotación efectiva.


Los recursos adscritos al equipo que excedan de los «nominales» podrán ser requeridos

por el CTM con el objetivo de absorber picos de demanda.

3.4.2. No adecuación del personal

El CTM evaluará de forma continua la calidad de los productos finales de la fábrica de

software, así como la capacidad de la misma para entender, evaluar y dimensionar los requisitos del CTM. Esta evaluación continua de cada uno de los recursos involucrados en el presente contrato podrá ser satisfactoria o no satisfactoria. En caso de obtener un

resultado no satisfactorio se informará al responsable de RRHH y al director del contrato para sustituir al recurso que no llegue a los estándares de formación, productividad o calidad exigidos.

Hay que tener en cuenta que el CTM considerará la no adecuación de un recurso como una rotación deflactada. Es decir, en caso de que, por los motivos expuestos, el CTM solicite al adjudicatario el reemplazo de un recurso, este contará como 0,5 unidades de rotación de

la fábrica de software (ver punto anterior). A tal efecto, se aplicarán las medidas correctoras y compensatorias que se deriven según los ANS exigidos.

3.4.3. Calidad de código

El CTM mide la calidad de código teniendo en cuenta los factores siguientes:

Cobertura de código en las pruebas unitarias. Se requerirá al menos un 80 % de código funcional cubierto (no se tendrán en cuenta captadores/reguladores ni librerías

externas). Se valorará# que el adjudicatario mejore la cobertura de código exigida. Calidad de las pruebas unitarias. Las pruebas unitarias estarán supervisadas por el

CTM, sobre todo la funcionalidad más crítica. Deuda técnica. Es la medida que indica el tiempo que habría que invertir en el

proyecto para cumplir al 100 % con las métricas de SonarQube. Esta deuda no tendría que ser superior al 10 % del tiempo invertido en el proyecto. Se valorará# que el adjudicatario mejore la deuda técnica máxima exigida.

El CTM validará las entregas de código fuente mediante revisión manual y utilizando herramientas de calidad de código como SonarQube. El adjudicatario tendrá acceso a los

informes generados mediante estas herramientas así como a las métricas que sigue.

Estas métricas podrán ser modificadas de común acuerdo a lo largo del contrato.


4. Servicios de sistemas

Para la prestación del servicio se tendrá que asignar presencialmente a una persona a tiempo completo (35 horas semanales). Esta persona deberá estar profesionalmente

cualificada para poder asumir las tareas técnicas de soporte y mantenimiento de los sistemas hardware y software del CTM. En concreto, tendrá que asumir el mantenimiento, la planificación, la gestión, la adaptación y la mejora de los CPD del CTM y todo lo que

contienen.

Condiciones a cumplir por el profesional propuesto por la empresa adjudicataria:

FTP2 de Informática o similar. Se valorará# ingeniería técnica o superior o equivalente, en Informática de Sistemas

Experiencia mínima de cinco años en mantenimiento y gestión de los sistemas tecnológicos siguientes:

Hardware: servidores, cabinas de discos (SAN, NAS), robots de cintas, etc.

Red: SAN, LAN, WAN. Firewalls. Routing, switching, load balancing.

Sistemas de backup multidisciplinares.

Entornos de alta disponibilidad. Replicación de CPD.

Entornos virtualizados. VMWARE/VEEAM

Experiencia mínima de cinco años en mantenimiento y administración de los sistemas software siguientes (* = requerido, + = se valorará#)

Linux* (CentOS 7)

Apache*

Bind*

Wildfly*

Windows server*

Keycloak+

Alfresco+

Liferay+

Herramientas de orquestación de contenedores Docker (Openshift, Rancher, ...) +

Además, la licitación descrita tiene que cumplir las características de servicio siguientes:

A petición del CTM, el recurso tiene que poder realizar las tareas en las dependencias del CTM (concretamente, en los CPD del CTM donde se encuentran los

servidores, cabinas y electrónica de red).

Actuaciones ocasionales fuera del horario laborable (noches y fines de semana).


Guardias compartidas (no presenciales, con móvil) en fines de semanas alternos

(máximo de dos fines de semana cada mes).

Guardias compartidas de tarde (no presenciales, con móvil) de 15 a 22 horas en semanas alternas (máximo de 1 semana cada mes).


5. DOCUMENTACIÓN

La empresa adjudicataria se compromete a documentar toda su labor y a utilizar las herramientas que el CTM usa en su departamento de desarrollo, entre las que se incluyen:

Jira/Redmine para tareas, incidencias, fallos, etc.;

JavaDoc para todo el software desarrollado; Alfresco como gestor documental y repositorio;

GitHub, Jenkins, Sonarqube, Artifactory, etc. como herramientas de factoría;

y, en general, cualquier otra herramienta que el CTM considere necesaria para el correcto desarrollo, seguimiento y fiscalización del contrato.

El adjudicatario se compromete a utilizar estas herramientas del CTM directamente sobre los sistemas del CTM. Es decir, no se permitirá que la información se introduzca en las

herramientas del adjudicatario para luego dar acceso al CTM. La información y los conocimientos técnicos tienen que quedar depositados directamente y en todo caso en los sistemas del CTM.


6. PROPIEDAD INTELECTUAL Y CONFIDENCIALIDAD

6.1. Propiedad intelectual

El CTM tiene la titularidad exclusiva, tanto en el caso de finalización del contrato como de

resolución anticipada, de la propiedad intelectual, en exclusividad y a todos los efectos, de todas las entregas, documentación, software y código fuente. En consecuencia, el CTM es el propietario único y puede reproducir, modificar y divulgar, total o parcialmente, todas

las entregas, sin que el adjudicatario se pueda oponer a ello. El adjudicatario acepta esta titularidad del CTM y se compromete a respetarla y a no hacer

uso, comunicar o divulgar ninguna de las entregas del contrato, ya sea de forma total o parcial, directa o indirectamente, sin la autorización expresa del CTM, y renuncia expresamente a cualquier acción o reclamación legal, profesional o económica o de

cualquier otro tipo.

6.2. Confidencialidad

6.2.1. Datos personales

De acuerdo con lo establecido en el artículo 124 y en la disposición 31 de la LCSP, el adjudicatario se compromete a la más estricta y absoluta confidencialidad y reserva acerca de la información a la que tenga acceso en virtud de la ejecución del contrato, y, en

especial, acerca de los datos de carácter personal, que no puede copiar ni utilizar para ninguna otra finalidad distinta a la prevista en este pliego y que tiene que devolver o destruir completamente al finalizar el contrato.

6.2.2. Sobre la documentación y el negocio

El CTM, en virtud de esta licitación, entregará al adjudicatario documentación confidencial acerca de sus sistemas y arquitectura. Por este motivo, el CTM requiere la firma previa de un acuerdo de confidencialidad entre las partes y protege toda la documentación e

información entregada mediante el Copyright siguiente:

© Copyright CONSORCI DE TRANSPORTS DE MALLORCA, 2017. Todos los derechos

reservados. La expresión, total o parcial, así como todos los datos e información contenida en el presente documento constituye una obra de propiedad intelectual o industrial del CONSORCI DE TRANSPORTS DE MALLORCA. Quedan prohibidas la

reproducción, comunicación pública, distribución, modificación, cesión y cualquier otro acto que el CONSORCI DE TRANSPORTS DE MALLORCA no haya autorizado expresamente por escrito.

La información comprendida en este documento es estrictamente confidencial y pertenece al CONSORCI DE TRANSPORTS DE MALLORCA. Cualquier forma de

divulgación, reproducción, copia o distribución total o parcial de la misma queda estrictamente prohibida, no pudiendo ser utilizado su contenido para otros fines que la propia información del destinatario, sin la previa autorización expresa y por


escrito del CONSORCI DE TRANSPORTS DE MALLORCA.

El adjudicatario se compromete a aceptar y cumplir estos requisitos sin modificación

alguna salvo que se haya acordado de mutuo acuerdo y por escrito.


7. CALIDAD DEL SERVICIO. ANS MÍNIMOS EXIGIDOS

El servicio licitado en el presente pliego será vital para alcanzar los objetivos estratégicos del CTM. Por este motivo, resulta necesario definir y exigir acuerdos de nivel de servicio

(«ANS») que regulen, vigilen y midan la calidad del servicio ofrecido por el adjudicatario.

7.1. ANS de rotación de personal

Un indicador clave de la calidad es la rotación del personal adscrito a la fábrica de software. El CTM tendrá que invertir muchos recursos y horas de trabajo para formar al

equipo de la fábrica de software para que internalice los conceptos, buenas prácticas y casuísticas de un sistema de movilidad pública. Por lo tanto, resulta prioritario medir,

minimizar y acotar la rotación de los recursos adscritos con el fin de garantizar el éxito del proyecto.

Se definen los incumplimientos siguientes: Leve: si la rotación de personal a lo largo del contrato resulta superior a un 10 %

del total del equipo adscrito a la fábrica de software. Grave: si la rotación de personal a lo largo del contrato resulta superior a un 25 %

del total del equipo adscrito a la fábrica de software. Crítica: si la rotación de personal a lo largo del contrato resulta superior a un 40 %

del total del equipo adscrito a la fábrica de software.

7.1.1. Garantías de rotación

En caso de incumplimiento del ANS de rotación de personal, se aplicarán directamente las garantías y penalizaciones siguientes:

Leve: sin penalización.

Grave: se descontará de la factura mensual de servicios el importe correspondiente al coste de un mes del recurso de programador sénior en concepto de gastos de formación y adaptación del nuevo recurso, que tendrá que sufrir y soportar el CTM.

Crítica: se descontará de la factura mensual de servicios el importe correspondiente al coste de tres meses del recurso de programador sénior en concepto de gastos de

formación y adaptación del nuevo recurso, que tendrá que sufrir y soportar el CTM.

7.2. ANS de calidad de código

El CTM define los indicadores de calidad del código siguientes, explicados anteriormente en el apartado 3.4.3. de este pliego:

cobertura de código; deuda técnica.


Se definen los incumplimientos siguientes para la cobertura de código:

Leve: si la cobertura de código funcional está entre un 70 y un 80 %. Grave: si la cobertura de código funcional está entre un 50 y un 70 %.

Crítica: si la cobertura de código funcional es inferior al 50 %.

Se definen los incumplimientos siguientes para la deuda técnica: Leve: si la deuda técnica del proyecto está entre un 10 % y un 20 %.

Grave: si la deuda técnica del proyecto está entre un 20 % y un 35 %.

Crítica: si la deuda técnica del proyecto es superior al 35 %. En caso de que el adjudicatario mejore los mínimos exigidos por el CTM en su oferta,

estos nuevos valores se utilizarán para el cálculo de los ANS.

7.2.1. Garantías de calidad de código

En caso de incumplimiento del ANS de calidad de código, se aplicarán directamente las

garantías y penalizaciones siguientes:

Leve: sin penalización.

Grave: se efectuarán las correcciones oportunas para llegar al umbral leve sin descontar horas de servicio.

Crítica: se efectuarán las correcciones oportunas para llegar al umbral leve sin

descontar horas de servicio.

En caso de incumplimientos reiterados en los ANS de calidad de código, el CTM podrá solicitar la modificación del equipo adscrito a la fábrica de software, incluso la sustitución

del arquitecto asignado al contrato. En caso de carencias graves, el CTM podrá incluso rescindir el contrato y volver a licitar los servicios de fábrica de software.

7.3. ANS de productividad

El CTM no mide la productividad en función de las líneas de código desarrolladas, sino en función del cumplimiento de la planificación de las tareas a desarrollar. Esta planificación se acordará en las reuniones de planificación entre el jefe de proyectos del CTM y el

arquitecto del adjudicatario. En caso de no llegar a un acuerdo en la planificación, el CTM se reserva el derecho a

solicitar una auditoría externa para determinar la estimación final. Con base en esta auditoría, se aplicarán los incumplimientos siguientes:

Leve: la estimación auditada reduce en un 10 % la estimación del adjudicatario Grave: la estimación auditada reduce en un 20 % la estimación del adjudicatario

Crítica: la estimación auditada reduce más de un 20 % la estimación del

adjudicatario


7.3.1. Garantías de productividad

En caso de incumplimiento del ANS de productividad, se aplicarán directamente las garantías y penalizaciones siguientes:

Leve: las horas consumidas se basarán en la estimación auditada.

Grave: las horas consumidas se basarán en la estimación auditada menos un 10 %

Crítica: las horas consumidas se basarán en la estimación auditada menos un 20 %

En caso de incumplimientos reiterados en los ANS de productividad, el CTM podrá solicitar la modificación del equipo adscrito a la fábrica de software, incluso la sustitución del arquitecto asignado al contrato. En caso de carencias graves, el CTM podrá incluso

rescindir el contrato y volver a licitar los servicios de fábrica de software.


8. Aspectos generales, económicos y de puntuación

8.1. Importe económico

El importe económico total del contrato se ha valorado en 496 000 euros, distribuidos en

248 000 euros por anualidad. A continuación se desglosan las partidas para cada uno de los lotes y anualidades.

8.1.1. Lote 1. Fábrica de software

El importe máximo de la parte de software no superará los 198 000 euros, IVA excluido, por anualidad.

Este lote se licita a precio unitario por hora, con una distribución de precios (máxima), tal como sigue:

El CTM irá consumiendo horas de fábrica de software a medida que las necesite, teniendo en cuenta el límite superior de 198 000 euros por anualidad y 3 * 1 800 horas de

programador y 900 horas de arquitecto por anualidad.

Al ser el Lote 1 una licitación a precio unitario, la adjudicación se realizará por el total del

importe de licitación.

8.1.2. Lote 2. Servicios de sistemas

El importe máximo de la parte de sistemas no superará los 53 000 euros, IVA excluido, por anualidad.

8.2. Forma de pago

La forma de pago se describe en los pliegos administrativos.


8.4. Modelo normalizado de las ofertas

Con respecto a la valoración de las ofertas, se tendrá en cuenta la claridad de la exposición, además de la calidad técnica y la adecuación a los objetivos deseados.

8.4.1. Lote 1. Fábrica de software

El licitador ha de presentar una oferta adaptada al esquema de contenidos siguiente:

Capítulo I: Descripción general de la propuesta.

Funcionamiento de la fábrica de software del adjudicatario.

Herramientas, metodología, procesos, seguimiento, control, métodos de medida de

métricas, etc.

Garantías de calidad, ANS comprometidos, indicadores claves de rendimiento, etc.

Capítulo II: Equipo.

Recursos humanos destinados al proyecto. Perfiles y organización.

Formación de los equipos.

Experiencia en proyectos similares en entornos en línea, en la nube y misión crítica.

Capítulo III: Prestaciones superiores o complementarias a las exigidas.

En este apartado se tiene que incluir cualquier mejora sobre el pliego de prescripciones

técnicas incluidas en la oferta y que se consideren destacables, siempre y cuando cumplan con la definición de mejora del punto 8.7.1. de este pliego.

8.4.2. Lote 2. Sistemas

El licitador ha de presentar una oferta adaptada al esquema de contenidos siguiente:

Capítulo I: Perfil propuesto

Recurso humano destinado al proyecto. Perfil y organización.

Formación y titulación del recurso.

Experiencia en proyectos similares en entornos como el descrito en este pliego.

Capítulo II: Prestaciones superiores o complementarias a las exigidas.

En este apartado se tiene que incluir cualquier mejora sobre el pliego de prescripciones


técnicas incluidas en la oferta y que se consideren destacables, siempre y cuando cumplan

con la definición de mejora del punto 8.8.1. de este pliego.

8.7. Valoración del Lote 1. Fábrica de software

8.7.1. Criterios de valoración

En este apartado se muestra la tabla de criterios que seguirá el departamento de tecnología del CTM para evaluar las ofertas, indicando el peso máximo de cada criterio.

No se especifica un apartado de «Mejoras» porque estas se evalúan en el marco de la calidad de la oferta técnica. A continuación se define el concepto de mejora.

Definición de mejora

Se entiende por mejora la ampliación de las funcionalidades, cantidades o características de los equipos, programas o servicios que cumplan los criterios siguientes:

Se encuentren descritas en este pliego bajo el epígrafe «se valorará»3.

No se encuentren descritas en este pliego pero tengan un valor tangible, mesurable

y objetivo para el CTM.

No se valorará ninguna otra mejora que no esté incluida en los dos preceptos anteriores.

Criterio Puntuación

1 Elementos técnicos de valoración 40

2 Oferta económica 60

Total criterios objetivos (2) = 60 %.

1. Elementos técnicos de valoración (40 puntos)

Adecuación de las ofertas a los requisitos del pliego de prescripciones técnicas.

3Los puntos de mejora valorados se encuentran marcados dentro del pliego con la palabra

«valorará» y el carácter «#» a continuación.


Perfiles (formación, experiencia en proyectos similares, capacidad) de los recursos

asignados al grupo adscrito a la fábrica de software.

Metodología, herramientas y procesos de la oferta que se adecuen a las prescripciones técnicas del pliego o las mejoren.

Mejoras valoradas tal y como se detallan en el pliego de prescripciones técnicas.

2. Oferta económica (60 puntos)

Comparación económica de las ofertas. Se otorgarán 60 puntos a la mejor oferta económica y al resto se las puntuará proporcionalmente mediante la fórmula siguiente:

Punto(i)= ([VOmín+(VLmáx-VO(i))]/VLmáx)*60

Siendo:

iPuntla puntuación otorgada a la empresa «i»;

minVO el valor mínimo ofrecido de entre todas las empresas concursantes;

maxVLel valor máximo de licitación;

iVOel valor ofrecido por la empresa «i».

Para calcular el importe económico de cada oferta se multiplicará el precio/hora del

programador sénior por el total de horas de programador sénior sumando el precio/hora de arquitecto multiplicado por las horas de arquitecto anuales previstas.

8.8. Valoración del Lote 2. Sistemas.

8.8.1. Criterios de valoración

En este apartado se muestra la tabla de criterios que seguirá el departamento de

tecnología del CTM para evaluar las ofertas, indicando el peso máximo de cada criterio.

No se especifica un apartado de «Mejoras» porque estas se evalúan en el marco de la

calidad de la oferta técnica. A continuación se define el concepto de mejora.

Definición de mejora

Se entiende por mejora la ampliación de las funcionalidades, cantidades o características de los equipos, programas o servicios que cumplan los criterios siguientes:


Se encuentren descritas en este pliego bajo el epígrafe «se valorará»4.

No se encuentren descritas en este pliego pero tengan un valor tangible, mesurable y objetivo para el CTM.

No se valorará ninguna otra mejora que no esté incluida en los dos preceptos anteriores.

Criterio Puntuación

1 Elementos técnicos de valoración 40

2 Oferta económica 60

Total criterios objetivos (2) = 60 %.

1. Elementos técnicos de valoración (40 puntos)

Experiencia del recurso propuesto en relación con los requisitos expuestos en el

pliego Formación del recurso propuesto en relación con los requisitos expuestos en el

pliego Aportación de mejoras respecto a los mínimos expuestos en el pliego, siempre que

estas cumplan estrictamente la definición de mejora.

2. Oferta económica (60 puntos)

Comparación económica de las ofertas. Se otorgarán 60 puntos a la mejor oferta económica y al resto se las puntuará proporcionalmente mediante la fórmula siguiente:

Punto(i)= ([VOmín+(VLmáx-VO(i))]/VLmáx)*70

Siendo:

iPuntla puntuación otorgada a la empresa «i»;

minVO el valor mínimo ofrecido de entre todas las empresas concursantes;

4Los puntos de mejora valorados se encuentran marcados dentro del pliego con la palabra

«valorará» y el carácter «#» a continuación.


maxVLel valor máximo de licitación;

iVOel valor ofrecido por la empresa «i».

LICITACIÓN DE LOS SERVICIOS DE FÁBRICA DE SOFTWARE …

Documents

Transcript of LICITACIÓN DE LOS SERVICIOS DE FÁBRICA DE SOFTWARE …