PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE RIGEN RIGEN LA CONTRATACIÓN DEL “DESARROLLO DE LA WEB DE CONSUMO RESPONDE” RESPONDE” POR IAVANTE. FUNDACIÓN PÚBLICA ANDALUZA PARA EL AVANCE TECNOLÓGICO Y ENTRENAMIENTO PROFESIONAL (EXPTE. 023/10) 023/10)

Málaga a 4 de agosto de 2010

1 de 15

Introducción IAVANTE, Fundación Pública Andaluza para el Avance Tecnológico y Entrenamiento Profesional es una organización cuya misión es la Gestión del Conocimiento en salud en su sentido más amplio: TRANSFERIR, COMPARTIR Y CREAR CONOCIMIENTO.

Creada en el 2002 por la Consejería de Salud de la Junta de Andalucía, tiene como misión facilitar y promover el Desarrollo y Entrenamiento Integral de profesionales tanto en competencias técnicas como en habilidades relacionales y sociales, a través de las más innovadoras metodologías de entrenamiento, así como liderar el desarrollo e innovación en nuevas tecnologías de aplicación en el sistema sanitario, especialmente aquellas, basadas en las TIC’s. Líneas de actividad Las líneas de actividad de IAVANTE son: de

aprendizaje:

simulación




Entrenamiento mediante innovadoras metodologías robótica, virtual, escénica, e-training y vídeo análisis.




Innovación en tecnología y comunicación aplicada a la salud: IAVANTE desarrolla proyectos innovadores de alto contenido tecnológico, de interés para el Sistema Sanitario Público de Andalucía y sobre aspectos tan diferentes como el e-learning, el trabajo colaborativo, los sistemas multimedia y sistemas multidispositivo, los simuladores robóticos y virtuales o los sistemas de inteligencia artificial aplicada a la formación, con especial interés en la utilización y publicación de los desarrollos como software libre.




Consultoría: dado al bagaje profesional de IAVANTE y su equipo, su línea de consultoría está orientada a los ámbitos de actuación en los que la fundación es experta. IAVANTE desarrolla proyectos en las áreas de Urgencias y Emergencias, Política de Gestión de Personas, Procesos de Selección y Assesment en el ámbito sanitario, Gestión de Programas de Formación y Sistemas de Información.




Línea Editorial: IAVANTE pone a disposición de alumnos y profesionales todo el conocimiento derivado de sus acciones formativas a través de los soportes físicos o electrónicos que su línea editorial desarrolla. Las publicaciones IAVANTE se caracterizan por su actualización constante y se pueden adquirir en la página web y en librerías especializadas.

IAVANTE tiene como uno de sus objetivos promover las políticas de investigación e innovación en la aplicación de Tecnologías de la Información y las Comunicaciones (TICs) al entorno de la salud, tal y como se recoge en el marco del II Plan de Calidad de la Consejería de Salud y la Segunda Modernización de Andalucía.

2 de 15

Objeto del pliego. El presente pliego de prescripciones técnicas establece las condiciones para la contratación de los servicios profesionales para el DESARROLLO DE LA WEB DE CONSUMO RESPONDE. No se establece en el presente pliego las tecnologías o plataformas a utilizar para el desarrollo, que serán propuestas por los licitadores de forma que se minimice el precio del “punto de esfuerzo” y se asegure la máxima velocidad (“puntos de esfuerzo” por Sprint). El alcance de este proyecto es la contratación de un servicio de desarrollo de software contratado en paquetes de trabajo valorados en base a PUNTOS DE ESFUERZO bajo la supervisión de IAVANTE según las condiciones descritas en el presente pliego, por lo que los licitadores deben ofertar las mejores condiciones económicas de los equipos de desarrollo necesarios con los conocimientos metodológicos descritos en el presente pliego y técnicos según la tecnología elegida por el proveedor. Se establece como fecha máxima de finalización del contrato el 30 de junio de 2011, pero se valorará la velocidad propuesta para la ejecución del proyecto y por tanto la finalización en un plazo inferior. Las condiciones del presente pliego deben entenderse como mínimas y obligatorias, siendo objeto de valoración su mejora y ampliación, siempre que a juicio del órgano de contratación contribuyan a obtener un mejor servicio y resultado.

Descripción del Sistema No existe un portal web de Consumo Responde como tal, por tanto el objeto del pliego será la creación de un nuevo portal Web que incluya los contenidos generados desde la Dirección General de Consumo dependiente de la Consejería de Salud de la Junta de Andalucía. En la actualidad los contenidos de consumo se encuentran disponibles en el Portal de Salud de la Consejería de Salud de la junta de Andalucía: http://www.csalud.juntaandalucia.es/salud/sites/csalud/portal/index.jsp?idioma=es&perfil=ciu d&opcion=listadoTematico&tema=/temas_es/C_8_CONSUMO/&desplegar=/temas_es/C_8_CO NSUMO/&menu=S Los tipos de contenidos disponibles en el nuevo portal de Consumo Responde y su estructura no se ceñirán a los actualmente disponibles en el Portal de Salud y en cualquier caso serán los definidos por la pila de producto establecida para el presente proyecto. Una posible imagen del portal a desarrollar sería la siguiente:

3 de 15

Esta imagen no es definitiva y se adjunta como ejemplo de un posible diseño a implementar. A modo orientativo y con el objetivo de facilitar la accesibilidad a los servicios de Consumo Responde de la manera más sencilla posible, se plantea:

4 de 15




la generación de tres perfiles de acceso: para consumidores, para empresas y para asociaciones y entidades (deberíamos valorar abrir un perfil solo para entidades, en concreto para OMIC)




el establecimiento de cuatro categorías: Información, Ayuda-Orientación, EducaciónFormación, Opinión-Participación




para el perfil de consumidor se propone además la diferenciación de las categorías formación y Ayuda en dos status: Antes de la compra y Después de la compra

Características


NO es objeto de este pliego la generación de contenidos, ni el maquetado y registro de los mismos, sino la creación de un portal Web con la estructura necesaria para dar cabida a los contenidos de consumo que se definan y permitan a los distintos grupos de interés el acceso a los mismo de una forma sencilla, usable y amigable.




El diseño y la imagen del portal será generada por la Fundación IAVANTE como parte de las especificaciones iniciales y la empresa licitadora será la encargada de adaptar y maquetar esta imagen propuesta al portal definitivo según las características de las tecnologías que se propongan y en cualquier caso basados en CSS de forma que sea fácil su modificación.




Como se ha comentado anteriormente no se define tecnología base, dejando libertad a los proveedores para que propongan aquella que se adapte a las necesidades propuestas y de la que sean expertos de forma que se maximice tanto la capacidad de trabajo como la velocidad de desarrollo.




Implantación de un CMS que permita el alta contenidos y un workflow básico de publicación y que posibilite la evolución del portal hacia características avanzadas que se definirán a lo largo del proyecto.




Preparado para multi-idioma. Aunque inicialmente tanto la Web como los contenidos que deberá soportar serán en idioma español, el portal deberá soportar un esquema multi-idioma tanto en las etiquetas o contenidos estáticos, como la traducción de los contenidos publicados.




Utilizará todos los canales y herramientas digitales disponibles. El portal estará preparado para incluir integración con distintos canales, como pueden ser redes sociales o plataformas de microbbloging y podrá disponer de distintas versiones o adaptaciones para dispositivos como móviles, PDAs o tablets.

Especificaciones Las espcificaciones del proyecto estrán basadas en una Pila de Producto según la metodología SCRUM definida en el presenta pliego. Esta pila de producto es una lista abierta de historías de usuario que estará disponible para la empresa adjudicataría antes de la firma del contrato y el inicio de los trabajos de desarrollo. En ningún caso se entenderá la Pila como una lista cerrada de tareas, ya que podrá evolucionar a lo largo de la marcha del proyecto según se define en el capítulo metodología del presente pliego.

5 de 15

Definición del objeto del contrato: Se describen a continuación las condiciones en las que se realizará el proyecto:


El alcance de este proyecto es la contratación de un servicio de desarrollo de software contratado en paquetes de trabajo valorados en base a PUNTOS DE ESFUERZO.




La metodología a utilizar para el desarrollo y seguimiento del proyecto será SCRUM y en el presente pliego se utilizan notaciones y conceptos de esta metodología.




Para el control y seguimiento, IAVANTE definirá las personas que tendrán los perfiles de Dueño de Producto y Cliente según la metodología SCRUM.




La unidad de medida utilizada para el cálculo de la dimensión de los SPRINT, su planificación y seguimiento será el punto de esfuerzo. Esta unidad define la cantidad de trabajo necesaria para realizar una tarea concreta, que se define mas adelante en el presente pliego.




Los puntos de esfuerzo definidos en la pila de producto se ejecutarán en base a SPRINTS (iteraciones incrementales) de una duración de 2 semanas.




Los SPRINTS son la base para la certificación y facturación de los trabajos. En la planificación inicial de cada SPRINT se definirá el alcance del mismo en base a puntos de esfuerzo a ejecutar, y por tanto define el precio de las historias de usuario incluidas en el SPRINT que una vez finalizadas y validadas (certificadas) se podrán facturar por la empresa responsable de los trabajos.

1. Descripción de un punto de esfuerzo Se define a continuación una historia de usuario, con un coste estimado de 1 punto de esfuerzo, que incluye todo el trabajo necesario para su definición, desarrollo, pruebas, documentación, instalación y validación.

Contexto general del desarrollo: •

El portal de Consumo Responde se plantea como la personalización de la funcionalidad del CMS básico / herramienta o framework de desarrollo elegido.

•

Se permite la utilización de módulos estándares según la tecnología y será necesario el desarrollo de módulos propios, con el fin de ampliar su funcionalidad y adaptarlo a los requisitos de Iavante.

•

Será necesaria la creación o modificación de temas gráficos propios para la generación de portales Web adaptados.

•

Con la tecnología elegida se deberá cumplir el patrón MVC para separar el modelo de datos, de la lógica del controlador y la capa de presentación.

6 de 15

•

Al ser un portal abierto a la ciudadanía en general hay que tener en cuanta que se exigirán características como usabilidad, accesibilidad (AA), multi-idioma, URLs internas legibles o cualquier otra que favorezca este objetivo.

Condiciones previas: Para el desarrollo de la historia de usuario se va a suponer que el proyecto está en ejecución y con los siguientes condicionantes: •

La historia forma parte de un Sprint intermedio del proyecto.

•

El equipo de desarrollo es estable y lleva trabajando en el proyecto varios Sprints.

•

Los entornos de desarrollo / demo (proveedor) y preproducción (Iavante) están instalados y en funcionamiento.

•

Las herramientas de desarrollo, repositorios de código, documentación y sistemas de pruebas son conocidos y están en funcionamiento.

•

La imagen del portal está definida (IAVANTE) y se ha maquetado la estructura general del portal y la necesaria para todas las historias de usuario realizadas previamente.

•

El portal web público está en desarrollo y ya se han revisado algunas pantallas que se consideran definitivas.

•

El sistema de usuarios y permisos es básico, donde sólo aparece un rol de administrador de contenidos encargado de la gestión de los contenidos (accede a la herramienta de gestión), y el super administrador del CMS. El portal es público. Este sistema de usuarios y permisos ya está implementado y en funcionamiento.

Descripción del punto de esfuerzo: Desarrollo de un módulo que registre en el CMS un nuevo tipo de contenido propio “Producto” con los siguientes campos: •

Nombre del producto: será un campo de texto obligatorio con una longitud máxima definida. Por defecto estará vacío.

•

Descripción: será un área de texto donde se podrán introducir varios párrafos. Este campo será opcional. El campo de texto deberá incluir un editor de texto enriquecido. Por defecto estará vacío.

•

Categoría, será un desplegable que obtendrá los datos dinámicamente de una tabla de la base de datos. Este campo será opcional. Por defecto estará vacío. Para la estimación del punto de esfuerzo se tendrá en cuenta que esta tabla de categorías (y sus herramientas de gestión) ya está generada y en uso por otros contenidos modelados con anterioridad.

•

Publicar. Será un tipo binario que indicará si queremos que el contenido se publique en el portal o no. Este campo será obligatorio y por defecto estará a “verdadero”. 7 de 15

•

Idioma: es el idioma del contenido y por defecto es español (es). El contenido estará preparado para ser multi-idioma, pero no se incluye en la historia de usuario las herramientas específicas de generación, publicación o visualización de contenidos en múltiples idiomas. Para esta versión del contenido este campo será un combo donde sólo estará disponible el idioma por defecto (es), ya que el portal estará configurado para soportar únicamente este idioma.

•

Autor: se rellenará automáticamente con el usuario del CMS que crea el contenido. Este campo será obligatorio. Como se ha comentado el sistema de gestión de usuarios, autenticación y permisos se debe considerar finalizado a la hora de estimar el punto de esfuerzo.

•

Fecha de creación. Este campo se rellenará automáticamente en el momento de creación del contenido. Este campo es obligatorio.

•

Fecha de modificación: Este campo será rellenado automáticamente cada vez que se edite el contenido. Este campo es obligatorio.

El CMS dispondrá de una interfaz de administración sencilla, con la imagen y estructura estándar de la herramienta, tecnología o CMS elegido (no hay que generar una específica para el portal). Esta herramienta de administración, al no ser pública, no necesita cumplir con los parámetros de accesibilidad o usabilidad definidos. El contenido estará preparado para ser multi-idioma, pero no se deben incluir en la valoración del punto de esfuerzo las herramientas específicas para generar traducciones. Desde la herramienta se podrán realizar las siguientes operaciones:


Listado de contenidos: Debe ser posible ver un listado con todos los objetos de ese tipo creados. El listado estará formado por los títulos de los contenidos que serán enlaces a sus vistas de edición e incluirá un enlace/botón para eliminar. El listado deberá estar paginado con un tamaño fijo de 20 contenidos.




Crear. Se mostrará al usuario un formulario donde podrá rellenar los campos “título”, “descripción”, “categoría” y “publicar”. Los campos “autor”, “fecha de creación” y “fecha de modificación” permanecerán ocultos para el usuario ya que son completados automáticamente por el CMS. Se deberá realizar una validación del formulario de forma que se detecten si hay campos obligatorios que no han sido rellenados. En caso de errores de validación, se mostrará un mensaje al usuario indicándole el campo que debe completar para que el formulario sea válido. No se almacenará el contenido en la base de datos hasta que sea válido. Cuando se realice el envío del formulario y el contenido haya sido creado se redirigirá al usuario a la pantalla de “Listado de contenidos”.




Editar: el usuario podrá modificar cualquiera de los campos visibles para él (“título”, “descripción”, “publicar” y “categoría”) de un contenido previamente creado. Al igual que en el formulario de creación se realizará validación del formulario en el momento del envío para comprobar que todos los campos obligatorios han sido rellenados. En el caso de que haya errores de validación, se mostrará un mensaje indicando el campo que debe ser rellenado para que el formulario sea válido. Cuando se realice el envío del formulario y el contenido haya sido editado se redirigirá al usuario a la pantalla de “Listado de contenidos”.

8 de 15




Eliminar. El usuario podrá eliminar un contenido ya creado. Cuando se pulsa sobre este botón se eliminará el contenido de la base de datos pero no sus categorías. Cuando se borre el contenido se redirigirá al usuario a la pantalla de “Listado de contenidos”.

El contenido “Producto” tendrá una vista pública, que será la que se mostrará en el portal de Consumo Responde para todos los usuarios:


Sólo se mostrará en el portal en el caso en que tenga el campo “Publicar” activado. Este modo de funcionamiento es el estándar y para la valoración del punto de esfuerzo se tendrá en cuenta que en anteriores sprints ya se han generado otros tipos de contenidos que incorporan un funcionamiento similar.




Los contenidos de tipo “producto” se listarán junto con el resto de contenidos de otros tipos en el listado correspondiente a la categoría seleccionada, donde el título es un enlace a la vista de detalle del contenido y tendrá asociado un icono que identifica el tipo de contenido (este icono será fijo y se establecerá en la creación del tipo de contenido “producto”). Para la valoración del punto de esfuerzo se tendrá en cuenta que estos listados ya existen y han sido utilizados y probados para otros tipos de contenidos anteriores.




Se generará la vista de detalle del contenido. Esta vista se visualizará al acceder desde el listado de contenidos por categoría definida con anterioridad. La vista se cargará en el contexto y estructura del portal ya definida y utilizada para otros tipos de contenidos. Será necesaria la adaptación de la imagen a la general del portal (que como se comentó ya está definida y en funcionamiento) y a la específica para este tipo de contenido que estará disponible en la reunión de especificación del sprint.

Aspectos metodológicos y entregables En base a la metodología elegida, a los entregables definidos y a aspectos de calidad en el desarrollo aparecen tareas específicas a realizar para cada historia de usuario. Tareas de finalización de la historia de usuario: •

El módulo estará instalado en el servidor de desarrollo del proveedor (con posibilidad de acceso desde Iavante).

•

El código fuente y su documentación deben de estar subidos al repositorio.

•

El módulo deberá disponer de sus tests unitarios (para este caso crear, modificar y borrar un “producto”) y de integración (en este caso, test de capa de presentación de usuario final para la vista pública con una herramienta tipo Selenium o similar). El código fuente de los test debe de estar subido al repositorio.

•

Para la historia de usuario definida será necesario modificar los manuales de usuario y administración para incluir este nuevo tipo de contenido. Se subirán al repositorio del proyecto.

9 de 15

Para la valoración de la historia de usuario de 1 punto de esfuerzo, sólo se tendrán en cuenta los aspectos y definiciones específicas establecidas en este apartado del pliego. NO se valorarán trabajos, tareas o funcionalidades no definidas. En sus ofertas, las empresas licitadoras deberán definir el precio del punto de esfuerzo.

2. Definición de los actores. Se establecerán las siguientes figuras y órganos de dirección, que quedarán perfectamente definidos al inicio del proyecto: •

Director del proyecto, por parte de Fundación IAVANTE.

•

Cliente, por parte de Fundación IAVANTE.

•

Dueño de producto, por parte de Fundación IAVANTE.

•

SCRUM Master, por parte de la empresa adjudicataria. Con perfil de analista o analista programador.

•

Equipo del proyecto, por parte de la empresa adjudicataria. Con los perfiles necesarios para la ejecución de los trabajos.

3. SPRINT 0. Se define como SPRINT 0 o inicial al periodo de tiempo, que no debe superar a la duración de 1 SPRINT, que va desde la firma del contrato y la reunión de planificación y por tanto inicio del primer SPRINT del proyecto. Este SPRINT inicial es donde la empresa adjudicataria debe organizar el equipo de trabajo y donde se realizan los trabajos de montaje de los entornos necesarios para que sea productivo. Se valoraran como mejoras todas aquellas acciones o circunstancias que acorten la duración del SPRINT 0.

4. Ejecución de los trabajos. Para la ejecución se utilizará metodología SCRUM, que se basa en desarrollo iterativo e incremental basado en SPRINTS. La pila de producto se divide en SPRINTS que son un conjunto de historias de usuario que se van a desarrollar en un tiempo definido y que debe tener un resultado demostrable y que se pueda validar por IAVANTE. Para el seguimiento global del proyecto se van a utilizar diagramas “Burn-up”, “Puntos de Esfuerzo (eje y) ejecutados en los sucesivos SPRINTS (eje x)” (la pendiente es la velocidad del equipo). En este diagrama se relaciona el alcance del proyecto con el plazo estimado para finalizarlo y es la herramienta principal de seguimiento de la dirección del proyecto. El dueño de producto y el equipo son los encargados de mantener esta gráfica actualizada al finalizar cada SPRINT. En sus ofertas, las empresas licitadoras deberán definir la velocidad efectiva del equipo de trabajo y deberán dimensionar adecuadamente los equipos de trabajo a lo largo de la ejecución del proyecto para corregir las desviaciones que se produzcan. 10 de 15

Para el cálculo de la velocidad efectiva no se tendrán en cuenta los puntos de esfuerzo necesarios para la resolución de incidencia y errores producidos en SPRINT anteriores.

5. SPRINTS Con objeto de garantizar la calidad de los trabajos realizados, toda la documentación que se vaya generando durante el SPRINT estará siempre disponible para Fundación IAVANTE mediante las herramientas oportunas de seguimiento, debiendo poder consultarla en cualquier momento. Si la empresa adjudicataria no dispone de tales herramientas, Fundación IAVANTE facilitará acceso a sus herramientas con objeto de garantizar este objetivo. Cada SPRINT o iteración se divide en las siguientes fases: Planificación de SPRINT. Al inicio de cada iteración se celebrará una reunión en el que al menos debe de estar presente el dueño de producto y el equipo completo. En esta reunión se decide que historias de usuario de la pila de producto que se van a ejecutar en el SPRINT. La pila de producto estará priorizada por el dueño de producto según las necesidades de IAVANTE. Cada historia de usuario deberá ser estimada en base a Puntos de Esfuerzo utilizando la técnica de “Planning Pocker”. Para cada iteración se planificarán tantas historias de usuario como sean necesarias para que la velocidad efectiva del equipo de trabajo sea la propuesta por las empresas licitadoras en su oferta. La disminucion de la velocidad efectiva del equipo que puedan producirse deberá ser compensada en 2 SPRINT. En la reunión de planificación se pueden tomar decisiones que varíen la planificación base siempre que sean justificadas por el equipo y aceptadas por el dueño de producto: •

Incluir los puntos de esfuerzo necesarios para resolver incidencias de SPRINTS anteriores, que si son achacables al equipo del proyecto no computarán para la certificación, ni facturación del SPRINT, ni participaran en el cálculo de la velocidad efectiva del equipo de trabajo.

•

Re-Estimación de historias de usuario. Si fuera necesario y justificado, el dueño de producto puede aceptar la re-estimación de los puntos de esfuerzo de una determinada historia de usuario. En ese caso se estimará de nuevo entre el dueño de producto y el equipo utilizando la técnica de “Planning Pocker”.

•

Disminuir la velocidad del equipo para el siguiente SPRINT. Sólo se podrá aceptar por razones justificadas de vacaciones o bajas de miembros del equipo. IAVANTE podrá solicitar a la empresa adjudicataria el reemplazo de recursos del equipo si el problema persiste más de 1 SPRINT.

•

Aumento o disminución de la velocidad de equipo por necesidades del proyecto. IAVANTE podrá solicitar a la empresa adjudicataria el aumento o disminución de la velocidad del equipo en no más de un 20% (cada 2 SPRINTS) por necesidades específicas del proyecto (cumplimiento de plazos) o de IAVANTE. 11 de 15

Desarrollo del SPRINT. Una vez cerrada la planificación comienza el periodo de desarrollo de un SPRINT. Este periodo durará 2 semanas y finaliza con la reunión de demostración. Durante el desarrollo el equipo de trabajo (incluido el SCRUM Master) ejecutará las historias de usuario planificadas (no será posible una re-planificación intermedia) y el dueño de producto es el encargado del seguimiento de los trabajos. Para la organización y seguimiento de los trabajos se utilizará metodología SCRUM y se considera indispensable al menos los siguientes puntos: •

Utilización de un repositorio de código fuente, donde siempre estará disponible y accesible para el dueño de producto todo el código generado para cada historia de usuario finalizada.

•

Herramienta de gestión de tareas (tickets) de desarrollo. Al inicio de cada SPRINT el SCRUM Master es el encargado de generar tantos tickets como historias de usuario se han planificado en la herramienta. Estos tickets (historias) podrán estar en estado “planificado”, “en ejecución” o “finalizado” Estas tareas se irán asignando a los miembros del equipo que deberán incorporar antes de cada reunión diaria los puntos de esfuerzo que le quedan por ejecutar para finalizar cada historia de usuario que tiene asignada. Esta herramienta estará accesible para el dueño de producto que podrá llevar un seguimiento diario del equipo.

•

SCRUM diario. En una reunión diaria (de no más de 15 minutos) el SCRUM Master y el equipo revisan el trabajo del día anterior y resuelven posibles conflictos o bloqueos. En esta reunión se revisará que tanto el repositorio de código como la herramienta de gestión de tickets están actualizados. El dueño de producto podrá asistir a cualquiera de estas reuniones, pero no es obligatorio a no ser que lo requiera el SCRUM Master.

•

Diagrama de “Burn-Down”. Es la herramienta principal de seguimiento del equipo por parte del dueño de producto en cada SPRINT. El SCRUM Master debe actualizarlo a diario con los datos de puntos de esfuerzo restantes para finalizar el SPRINT.

Cierre del SPRINT. Además del desarrollo de las historias de usuario, el equipo deberá cerrar el SPRINT antes de que se celebre la reunión de demo al cliente. Para considerar que un sprint está cerrado será necesario: •

Instalar el producto, incluyendo la nueva funcionalidad del presente SPRINT, en el entorno de demo. Este entorno podrá estar instalado en IAVANTE si el proyecto lo requiere y en todo caso debe ser accesible y funcional desde las sedes de IAVANTE.

•

Generar y copiar todos los entregables del SPRINT en el servidor documental del proyecto que dotará IAVANTE.

Los entregables del sistema a la finalización de cada SPRINT serán específicos o actualizaciones de documentos generales del proyecto para incluir la nueva funcionalidad y habrán de incluir:

12 de 15

•

Documento de historias de usuario.

•

Código fuente.

•

Documentación del código fuente.

•

Diagramas de burnup, burndown y Kanban.

•

Documentación de retrospectiva del sprint ejecutado.

•

Código fuente de tests funcionales. Informe del resultado de las pruebas.

•

Paquete completo de instalación que incluya todos los sistemas y herramientas, documentado y con manual.

•

Manual de Instrucciones de la aplicación. Procedimiento de instalación. Parametrización. Procedimiento de actualización.

•

Manual de usuario y administrador del sistema.

El idioma de la documentación será el castellano. Para todos los entregables, deberá documentarse el contenido de los puntos del índice hasta el nivel que sea posible. Toda la documentación que resulte del desarrollo del SPRINT, tanto documentación del código fuente, manuales de desarrollo, administración, ayuda al usuario, tutoriales, páginas web, etc. deberán ser presentados en formatos de ficheros de ordenador basados en estándares abiertos. Demo al cliente Una vez cerrado el SPRINT se celebrará la Reunión de Demo con el Cliente. Esta reunión se celebrará siempre y de forma planificada el último día de cada SPRINT y a esta reunión asistirán los miembros del equipo (incluido el SCRUM Master) y el dueño de producto, que podrá invitar a la misma a la dirección del proyecto o al cliente final de IAVANTE cuando lo considere oportuno. En esta reunión de demo se validarán funcionalmente todas las historias de usuario finalizadas en el SPRINT sobre el entorno de demo. Como resultado el dueño de producto generará un informe de validación donde se incluirá la siguiente información:


Historias de usuario finalizadas, validadas y conformes.




Historias de usuario finalizadas y NO conformes según las validaciones definidas. Se deberá estimar los puntos de esfuerzo necesarios para solucionar los problemas detectados, que se planificarán para el siguiente SPRINT.




Historias planificadas NO finalizadas.




Historias finalizadas y conformes que no se habían planificado.

Pruebas en el entorno de producción de IAVANTE. Una vez finalizada la demo, IAVANTE iniciará un periodo de prueba de los desarrollos del SPRINT finalizado que durará como máximo 1 SPRINT de forma que se puedan llevar las noconformidades a la reunión de planificación del SPRINT posterior. Estas pruebas de validación se podrán realizar en el entorno de demo, o en entornos de preproducción o producción de IAVANTE.

13 de 15

Con los resultados de las pruebas el dueño de producto modifica, en caso necesario, el informe de validación.

Certificación y Facturación del SPRINT. A partir del informe de validación del SPRINT, se generará la certificación del SPRINT y se aceptará el pago de la factura del SPRINT. La certificación se hará en base a los Puntos de Esfuerzo correspondientes a las historias de usuario finalizadas y conformes planificadas o adicionales. El valor económico de la factura y la certificación será el correspondiente a multiplicar los Puntos de Esfuerzo modificados por el precio por punto ofertado. El dueño de producto será el encargado de generar las certificaciones que serán presentadas y aceptadas por la Dirección del Proyecto.

Condiciones generales de la contratación.

1. Información para el proyecto Fundación IAVANTE facilitará cuanta información disponga y sea necesaria, relacionada con el objeto del presente pliego.

2. Confidencialidad y protección de datos La empresa adjudicataria y todo el personal que trabaje para él estarán sujetos al deber de confidencialidad en el ejercicio de sus funciones cuando trabajen para el órgano de contratación, configurándose este deber como la prohibición de la revelación de datos de las personas que se conocen a ningún tercero ni el uso de los mismos para ningún fin distinto al de la actividad que desempeñan. Asimismo, estará obligada a conocer, respetar y asegurar que se cumplan en el desarrollo de su trabajo, todas las normas, pautas, procedimientos, recomendaciones, etc., que se fijan en el Manual de Seguridad de la Información Corporativa de la Fundación IAVANTE, y a adoptar las medidas de índole técnica y organizativas necesarias que garanticen la seguridad de los datos facilitados por la Fundación IAVANTE y eviten su alteración, pérdida, tratamiento o acceso no autorizado, todo ello en consonancia con el nivel de seguridad exigible de acuerdo con la información que trate. Una vez cumplida la prestación contractual, toda la información corporativa de la Fundación IAVANTE deberá ser destruida o devuelta al Responsable Funcional, al igual que cualquier soporte o documentos en que conste algún dato de carácter personal u otra información objeto del tratamiento.

14 de 15

El contratista está obligado al cumplimiento de todas las disposiciones vigentes en relación con la actividad desarrollada. Deberá obtener las cesiones, permisos y autorizaciones necesarias, de los titulares de las patentes, modelos y marcas de fabricación correspondientes, corriendo de su cuenta el pago de los derechos e indemnizaciones por tales conceptos, siendo responsable de toda reclamación relativa a la propiedad industrial y comercial.

3. Garantía Los periodos de garantía de los desarrollos serán los detallados en el anexo I del pliego de cláusulas administrativas.

Dudas Los licitadores podrán realizar preguntas y solicitar aclaraciones en una reunión de resolución de dudas que se realizará el día 23 de agosto de 2010, a las 10:30 y de manera simultánea en las 3 sedes de IAVANTE conectadas por videoconferencia. •

Sede de la Fundación Iavante en Málaga Parque Tecnológico de Andalucía C/ Marie Curie, 16 Edificio Possibilia 2005 - 1ª Planta 29590 Campanillas. Málaga. España

•

CMAT, sede de la Fundación Iavante en Granada Parque Tecnológico Ciencias de la Salud Avda. de la Ciencia, s/n 18100 Armilla. Granada. España

•

Sede de la Fundación Iavante en Sevilla Av. de la Innovación, s/n Edificio Arena 3 – 2ª planta 41020 – Sevilla – España

En Málaga a 4 de agosto de 2010

15 de 15