Este expediente es renovación de un servicio ya existente desde hace años, prestado por otras empresas, aunque en esta ocasión se busca un enfoque más técnico desde el punto de vista del desarrollo de front.

La fecha limite para la presentación de ofertas es el 04 de marzo de 2025 a las 14:00 horas

1. En la página 7 del pliego de condiciones indica "Un mismo proyecto no puede aparecer en la Tabla de Evaluación de Capacidades para acreditar distintas líneas de experiencia". ¿Nos podrían indicar si un proyecto permite acreditar varias líneas de experiencia si podríamos repetirlo? El objetivo es que no se repitan las destrezas de un proyecto en varias líneas de experiencia; es decir, si un proyecto acreditativo de HTML se emplea en una línea de experiencia, ese mismo proyecto no puede acreditar HTML en otra línea de experiencia, debe ser otro proyecto distinto. Los paquetes de destrezas son "cerrados" por proyecto, y tienen distinto grado de complejidad. Los proyectos pueden ser simultáneos en el tiempo, pero distintos, cuando tienen destrezas coincidentes. En el caso de que no se pudiesen repetir el perfil Desarrollador Front – end / Coordinador del servicio ¿tendría que tener por tanto al menos 10 años de experiencia? Son 2 perfiles diferenciados: 1. Desarrollador Front-end. 2. Desarrollador Front-end + Coordinador de servicio. En el caso del coordinador, puede haber complementado su faceta de desarrollador puro con el de jefe de proyecto, o puede haberlo ejercido de forma independiente. En cualquier caso, los proyectos pueden ser simultáneos en el tiempo, no consecutivos. 2. En el perfil de maquetador de accesibilidad indica que tiene que justificarse "Al menos 3 años de experiencia en proyectos de front-end accesibles (HTML5/CSS3/JQuery/ WCAG 2.1(AA)/WAI-ARIA)" ¿este perfil tendría que tener conocimientos de desarrollo o sería suficiente que hubiese trabajado en dichos proyectos realizando tareas especializadas de accesibilidad sin tener experiencia específica de desarrollo? Se busca un perfil bajo de desarrollo front-end, un maquetador tradicional de HTML + CSS + funcionalidades básicas JS, pero que haga código accesible; este sería el caso de la línea de experiencia ACC-1 solicitada. Si no tuviera experiencia en maquetación, y sólo pudiera acreditar experiencia en auditoría/asesoría de accesibilidad, el rango de experiencia cubriría sólo la línea ACC-2.

Es la suma de ambas referencias.

Como se explica en el arranque del punto 4, la muestra de proyecto para evaluación, deben acreditar la utilización de todas las tecnologías relacionados entre "/", todas en conjunto. Esto implica que, para el caso apuntado, en la línea de experiencia DFE-1, se puedan acreditar proyectos puramente de maquetación, sin conexión con servidores, pero que en el caso DFE-2, deban reseñarse proyectos donde se haya llegado a utilizar tecnologías de desarrollo back, junto con el resto.

El servicio debe cubrirse en esa franja horaria, por tanto, la propuesta de prestación del servicio debe cubrir dicha franja, con la propuesta de turnos que se estime oportuna y la distribución de horas/recursos necesaria para la propuesta. En el caso de accesibilidad, al ser las horas licitadas de servicio la mitad que para el resto de líneas de actuación, lógicamente no puede abarcarse toda la amplitud del servicio, pero la implicación de accesibilidad no debería ser tan continuada ni constante como en el resto del servicio.

El servicio de coordinación debe estar disponible en el horario habitual que se establezca, para las labores habituales de coordinación con RTVE, sin dejar de lado la parte de cumplimiento técnico que sea requerido. Esto no implica que una persona tenga que cubrir todo el horario establecido de prestación de servicio, sino que exista un mecanismo para activar los protocolos de actuación que se establezcan en caso de necesidad (que puede ser un simple teléfono). Cuando se piensa en "incidencias", se piensa en denegación de servicio, problemas de servidores o BB.DD., etc., pero en el caso que nos ocupa, una "intervención urgente" puede ser que haya que ajustar un widget de resultados de los premios Goya, sobre la marcha, porque en esta edición se ha decidido que en vez de haber un sólo ganador de "mejor película", sea un premio compartido y haya que abrir hueco para 2 resultados.

PCG - Cláusula 11 "CRITERIOS DE VALORACIÓN DE LAS OFERTAS": o Por pruebas documentales ¿se entienden que son urls o es algo más? Se entiende que puede ser cualquier tipo de documentación, aunque se valorará más positivamente si existe una URL donde poder testar el código. o Que un mismo proyecto no pueda aparecer en la tabla de evaluación de capacidades para acreditar distintas líneas de experiencia, ¿quiere decir que cada línea de experiencia tiene que ser referenciado por un proyecto diferente? Cada línea de experiencia puede contener uno o más proyectos para cumplir con las exigencias de experiencia, pero un mismo proyecto no puede computar en varias líneas de experiencia. o Que un mismo proyecto no pueda aparecer en la tabla de evaluación de capacidades para acreditar distintas líneas de experiencia, ¿quiere decir que tampoco puede acreditar distintas líneas de experiencia si es en fechas diferentes? Por ejemplo, ¿se podría indicar un mismo proyecto que acredita una línea de experiencia en una fecha concreta y en otra fecha diferente acredita otra línea de experiencia? Si el proyecto tiene un largo recorrido, con fases diferenciadas (lanzamiento, evolutivos, fase "n", etc.) con una cierta lógica, podrían computar en diferentes líneas, pero explicando claramente cuál es la partición temporal del proyecto. Por ejemplo, en nuestro caso, "desarrollo para la plataforma RTVE Play", podría abarcar desde 2020 en adelante, pero eso no sería constitutivo de "varios proyectos", sino de uno sólo; sin embargo, si contamos con "desarrollo guía TV para RTVE Play" + "migración del player video-JS a Theo-player para RTVE Play", sí se considerarían proyectos diferenciados. o Se indica que RTVE se reserva 2 puntos adicionales para valorar el equipo en su conjunto, ¿quiere esto decir que en la valoración de criterios sujetos a juicio de valor se puede llegar a conseguir 47 puntos? "Con el total de puntos relativos obtenidos por cada oferta, se establecerá la oportuna ponderación para asignar la valoración final de las mismas". La ponderación implica que al final se equiparará el máximo de puntuación de cualquier equipo al máximo de puntos posibles establecidos en la cláusula 11ª del PCG-.

"Detección de recursos que no cumplen con el mínimo ofertado" >> hace referencia a la experiencia de los recursos presentados; cuando se detecte que los conocimientos supuestos para los recursos no son tales. Esto es una vez que se constituye el equipo y arranca el servicio, puesto que de entrada no seremos capaces de evaluar la verdadera valía de los recursos. "Arranque del servicio con recursos..." >> hace referencia a que, de entrada, se nos presenta un equipo de arranque de servicio que no corresponde con los que aparecen en la propia oferta. Esto es el momento del arranque del servicio, cuando se detecta que no se corresponden los recursos con los perfiles sobre los que se ha evaluado la oferta; en ese momento sólo podemos atestiguar que hay correspondencia entre lo ofertado y los recursos presentados, pero no su valía real.

Gracias por su respuesta, en referencia a la misma nos gustaría aclarar una serie de cuestiones, de su respuesta debemos entender que para el perfil de coordinador si se solicita 3 años de experiencia en una línea de experiencia ello supondría haber participado un total de 5.400 horas en ese proyecto lo que impediría simultanear esos años en otro proyecto con otra línea de experiencia, por lo tanto en el caso del coordinador tendría que tener un mínimo de 10 años de experiencia ¿ es esto correcto? El supuesto expuesto para realizar esta consulta, si no lo entendemos mal, implica que el rol de coordinador solo se ha ejercido como "coordinador" o jefe de proyecto, sin intervenir en desarrollo alguno durante esos proyectos; precisamente eso es lo que no estamos pidiendo, sino un desarrollador, que haya ejercido de jefe de proyecto o coordinador de equipos, pero actuando como desarrollador. En este último supuesto, se pueden simultanear ambas tareas en un mismo proyecto y acreditar distintas líneas de experiencia. Si sólo se pueden acreditar proyectos en los que se haya intervenido de forma excluyente (o coordinador o desarrollador) pues, efectivamente, alarga las exigencias temporales de experiencia para alcanzar los mínimos exigidos. Por otra parte si un proyecto permite acreditar dos líneas de experiencia de tecnologías no coincidentes ¿se podría repetir el proyecto para acreditar ambas? Si el proyecto tiene un largo recorrido, con fases diferenciadas (lanzamiento, evolutivos, fase "n", etc.) con una cierta lógica, podrían computar en diferentes líneas, pero explicando claramente cuál es la partición temporal del proyecto. Por ejemplo, en nuestro caso, "desarrollo para la plataforma RTVE Play", podría abarcar desde 2020 en adelante, pero eso no sería constitutivo de "varios proyectos", sino de uno sólo; sin embargo, si contamos con "desarrollo guía TV para RTVE Play" + "migración del player video-JS a Theo-player para RTVE Play", sí se considerarían proyectos diferenciados.

Hasta ahora no hay restricciones ni preferencias sobre ningún framework concreto.

No tenemos un repositorio centralizado, ni documentación técnica previa. Sí solemos aplicar la máxima de reutilizar componentes previos cuando la funcionalidad es similar. El objeto de este servicio no es crear un proyecto desde cero, sino evolucionar el ecosistema rtve.es, encauzar su normalización y generar ese repositorio de componentes, si fuera el caso, dado que una gran parte de nuestras publicaciones se basa en un CMS con capacidad de generar portadas e incluso páginas, con lo que los componentes estructurales de maquetación están soportados por el propio CMS.

Por esa necesidad se incluye en el servicio un perfil de especialista en accesibilidad, que es quien debería poseer el conocimiento de qué pruebas de validación deberán aplicarse en nuestros desarrollos.

No podemos detallarlas. Sí podemos asegurar que son ocasiones "especiales", como pueden ser unas elecciones, eventos como Los Goya, Eurovisión, Lotería de Navidad, etc.

Se comunicaría con suficiente antelación, de forma planificada. Será en ocasiones "especiales", como pueden ser unas elecciones, eventos como Los Goya, Eurovisión, Lotería de Navidad, etc.

No exigimos compatibilidad con exploradores tan antiguos. En cualquier caso, por nuestra experiencia, si se aplican adecuadamente las reglas CSS, sin la utilización de frameworks generales, aplicadas a un código HTML lo más claro posible, no suele haber ningún problema de visualización entre navegadores. Donde sí seremos más exigentes es en la visualización en Web mobile, especialmente para Safari, Chrome y Firefox.

El CMS es bCube, con una implementación personalizada para RTVE. La integración de los componentes que se diseñen para ser gestionados dentro de CMS, en ningún caso corresponde a este servicio, pero sí su construcción en HTML, diseño funcional, conceptualización y la dependencia de hojas de estilo externas para su correcta visualización.

Ambas opciones son posibles, dependerá del modelo de integración que se acuerde.

Esto dependerá del modelo de integración que se acuerde al principio del servicio.

En principio, el servicio no incluye QA como tal; solo las pertinentes pruebas para comprobar que el modelo de integración será el adecuado y a nivel de maquetación/css, que lo desarrollado está en sintonía con el resto de componentes del ecosistema rtve.es.

- Deben indicar los servicios que van a subcontratar en su oferta técnica. -La información aportada ira anonimizada preferiblemente -Las certificaciones no es obligatorio presentarlas junto con el anexo III aunque es preferible. En caso de resultar adjudicatarios y no haberlos presentado anteriormente se les podrá solicitar esa documentación. -Las certificaciones que se valoran como criterios de valoración automáticos deben incluirse en el sobre C. Cualquier otra certificación que deseen aportar y que no sea de las específicamente solicitadas, podrán incluirlas en el sobre B.

Para el cálculo de las ofertas anormalmente bajas se considera la puntuación total, no solo la económica.

Las certificaciones que se valoran como criterios de valoración automáticos deben incluirse en el sobre C. Cualquier otra certificación que deseen aportar y que no sea de las específicamente solicitadas, podrán incluirla en el sobre B. Las certificaciones no es obligatorio presentarlas junto con el anexo III aunque es preferible. En caso de resultar adjudicatarios y no haberlos presentado anteriormente se les podrá solicitar esa documentación.

Las horas del perfil "desarrollador front-end" son las mismas que para el perfil de accesibilidad, pero el servicio "desarrollador front-end" también cuenta con las horas del coordinador, que es este mismo perfil. Por tanto, con este planteamiento, el servicio "desarrollador front-end" sí puede cubrir el horario completo del servicio, pero el perfil de accesibilidad, sólo la mitad. El horario a cubrir por parte del perfil de accesibilidad queda a merced del prestatario del servicio, de manera que pueda dar el soporte necesario al resto del equipo.

Buenos días La solvencia técnica en un primer momento se valora a través de la declaración responsable, Anexo II. En caso de resultar adjudicatarios se solicitaran los certificados que confirmen lo declarado en su Anexo presentado antes de la formalización del contrato.

La presentación del Anexo II es obligatoria, según el punto 6ª.- PRESENTACIÓN DE PROPOSICIONES. 1. 1. DOCUMENTACIÓN ADMINISTRATIVA: a) Declaración responsable a cumplimentar conforme al Anexo II. Si desean presentar también el DEUC, pueden subir un pdf único con ambos documentos.

Se deberá aportar la información necesaria para poder comprobar que los periodos de tiempo consignados en las tablas correspondientes tienen viso de veracidad, bien en las propias tablas, bien en documento CV. Dicho lo cuál, el CV será necesario, en cualquier caso, para comprobar otros datos como la formación del recurso, destrezas genéricas y específicas, periodos de contratación, docencia, posibles publicaciones, etc.

En respuesta a su pregunta, le informamos de que el régimen de penalizaciones se establece conforme a la cláusula 18ª del Pliego, garantizando proporcionalidad y respetando los límites fijados. Este régimen de penalidades es un mecanismo de garantía del cumplimiento contractual y su aplicación varía según los incumplimientos detectados. Para minimizar riesgos, se recomienda el cumplimiento riguroso de las condiciones del contrato.

Se encuentran anexos en el PCAP