Pliego de Bases Técnicas Oficina Técnica y Calidad para proyectos estratégicos de la Dirección Aseguramiento y Contratación

Transcripción

1 Pliego de Bases Técnicas Oficina Técnica y Calidad para proyectos estratégicos de la Dirección Aseguramiento y Fecha: Junio de 2012 Referencia: 026/2012 EJIE S.A. Mediterráneo, 14 Tel * Fax Vitoria-Gasteiz Posta-kutxatila / Apartado: Vitoria-Gasteiz Este documento es propiedad de EJIE, S.A. y su contenido es confidencial. Este documento no puede ser reproducido, en su totalidad o parcialmente, ni mostrado a otros, ni utilizado para otros propósitos que los que han originado su entrega, sin el previo permiso escrito de EJIE, S.A.. En el caso de ser entregado en virtud de un contrato, su utilización estará limitada a lo expresamente autorizado en dicho contrato. EJIE, S.A. no podrá ser considerada responsable de eventuales errores u omisiones en la edición del documento. i/55

2 Contenido Capítulo/sección Página 1 Introducción Perfil de la compañía Antecedentes 5 2 Objeto del contrato Objeto y alcance del servicio Descripción del servicio 7 3 Contenido Evolución del Sistema Transaccional de gestión de ITEMP Aplicativo actual Proyecto de evolución Nuevo modelo analítico para la herramienta de gestión de Incapacidad Temporal Aplicativo actual Proyecto de evolución Sistema de Información de Aseguramiento con Base Poblacional (SIABP) Aplicativo actual Proyecto de evolución 14 4 Oficina Técnica y Calidad para los proyectos estratégicos de la Dirección de Aseguramiento y Objetivos y tareas a realizar por la Oficina Técnica 16 ii/55

3 4.2 Composición de la Oficina Técnica y periodo de servicio a contratar 19 5 Metodología Aplicable y Entorno Tecnológico Metodología de desarrollo, normativa y Guía de Estilo Metodología de Pruebas Modelo de aseguramiento de la calidad (SQA) Nivel de Aseguramiento de la Calidad Plan SQA y actividades de seguimiento de la calidad Herramientas del ciclo de vida de las aplicaciones Entorno Tecnológico Descripción de entregables Normativa para la puesta en producción y posterior explotación del sistema 34 7 Planificación y Organización Plan de Proyecto Plan de Entregas e Hitos de Control Diagrama de Gantt Organización del Equipo de Trabajo Asignación de recursos a fases del proyecto Equipo de Trabajo Transferencia Tecnológica 42 8 Presupuesto y oferta económica 43 9 Mecanismos de Seguimiento, Control y Supervisión Mecanismos de Seguimiento y Control Supervisión del proyecto Plazo de ejecución y Plan de Facturación 46 iii/55

4 11 Criterios de Valoración Garantía y Confidencialidad Garantía Confidencialidad de la información Protección de datos Propiedad intelectual Prestaciones superiores o complementarias a las exigidas Estructura y Formato de la Propuesta Estructura normalizada y contenido de las propuestas Formato de la Propuesta Sobres y Elementos. 55 iv/55

5 1 Introducción 1.1 Perfil de la compañía EJIE, empresa pública del Gobierno Vasco contribuye, mediante la prestación de servicios informáticos, a conseguir una Administración Pública Vasca moderna y eficiente, construyendo y manteniendo la infraestructura de los Sistemas de Información y posibilitando su continuidad y seguridad en base a un personal cualificado y a unos recursos y costes adecuados a la demanda. EJIE, tiene como meta final la consecución de la satisfacción de sus clientes, para ello se ha impuesto como objetivos permanentes los siguientes: Prestar servicios de manera eficiente y con calidad, asegurando el cumplimiento de los plazos de respuesta y un nivel "cero" de reclamaciones e incidencias. Prestar servicios competitivos en relación al sector, en base a la permanente adecuación de los servicios internos al ámbito de actuación y asignando los recursos óptimos mediante la aplicación de los principios de racionalidad, especialidad y eficiencia. Integrarse activamente con sus clientes en un entorno de transparencia, comunicación y con objetivos comunes: comprensión del problema, enfoque adecuado y resolución satisfactoria. Obtener una imagen corporativa de servicio eficiente, de calidad y de empresa en punta tecnológica en el sector. 1.2 Antecedentes El Departamento de Sanidad del Gobierno Vasco, y más concretamente la Dirección de Aseguramiento y Sanitaria, está inmersa en la actualidad en una serie de proyectos estratégicos entre los que destacan los siguientes: Evolución de sistema de gestión de Incapacidad Temporal o Evolución del Sistema de Información Transaccional o Evolución del Modelo Analítico 5/55

6 Implantación del nuevo Sistema de Información de Aseguramiento con Base Poblacional (SIABP) Otros proyectos de implantación e integración con Plataforma Tecnológica de la E-Administración (PLATEA) A raíz de los requerimientos anteriores por el Departamento, éste encomienda a EJIE la ejecución de los trabajos necesarios para la consecución de los objetivos marcados. Para ello, EJIE realizará la contratación de aquellos servicios que, por sus características, deba cubrir mediante contratación de personal externo. Entre ellos se encuentra la dotación de una Oficina Técnica y Calidad para la gestión y control de los proyectos de implantación anteriormente mencionados. El objeto del presente documento es servir de Pliego de Bases Técnicas para la contratación de los servicios necesarios para cumplir con los requerimientos que se presentarán posteriormente a lo largo del documento. 6/55

7 2 Objeto del contrato 2.1 Objeto y alcance del servicio De acuerdo a lo indicado anteriormente, el objeto de este pliego es la contratación a una empresa del sector, en modalidad de CONTRATO CERRADO, para la realización de los trabajos de Oficina Técnica y Calidad para el soporte de los proyectos estratégicos de la Dirección de Aseguramiento y del Departamento de Sanidad y Consumo. Los requerimientos principales que ayudan a concretar el alcance de los servicios a prestar se detallan en el apartado Descripción del servicio. Asimismo, el conjunto de los entregables resultantes de los trabajos definidos como alcance del servicio se explicarán posteriormente dentro del apartado Oficina Técnica y Calidad para los proyectos estratégicos de la Dirección de Aseguramiento y del presente documento. 2.2 Descripción del servicio Para la consecución de los objetivos marcados, será necesario realizar una serie de tareas que se concretarán en el siguiente apartado de Contenido dentro del presente Pliego de Bases Técnicas. Tal y como se comentará posteriormente, el periodo de contratación será de 12 meses a partir de la fecha de inicio de los servicios una vez hayan sido adjudicados los trabajos siguiendo la normativa vigente asociada a la modalidad de contratación correspondiente. 7/55

8 3 Contenido Dentro de este apartado ser realiza un breve resumen de los proyectos principales a gestionar así como la situación actual de los mismos. 3.1 Evolución del Sistema Transaccional de gestión de ITEMP Aplicativo actual La Dirección de Aseguramiento y cuenta a nivel interno con una aplicación que cubre la funcionalidad necesaria para dar soporte a los procesos relacionados con la Gestión de Incapacidad Temporal. Dentro de dicha Dirección, este sistema es utilizado por el grupo de Inspectores Médicos para el mantenimiento de Bajas y Altas por enfermedad y el seguimiento de las Incapacidades Temporales por parte de las Inspecciones Médicas. El ámbito de este proyecto afecta a todos los Afiliados de la Comunidad Autónoma, susceptibles de suspender por motivos médicos su trabajo habitual de manera temporal. Un Afiliado podrá tener varios Procesos de Baja y Alta, entendiendo como Proceso el periodo de tiempo que comprende una Baja y su Alta correspondiente. Un proceso permanecerá abierto en el caso de que se haya introducido una Baja pero aún no se haya indicado un Alta posterior para dicho episodio. Durante un proceso, es posible realizar Revisiones / Anotaciones y Consultas, así como consultar la Historia de un Afiliado. Si un Afiliado nunca ha cogido una Baja es posible que no se encuentre en la Base de Datos, de manera que habrá que introducir todos sus datos. Puede darse el caso de que un Afiliado solicite una Incapacidad Permanente, si ésta se resuelve de manera positiva, esto se tratará de la forma adecuada en la Aplicación. En el caso de que un Afiliado esté de Baja, se pueden generar Citas de forma automática, para un Afiliado en concreto, o para los Afiliados que cumplan ciertos requisitos introducidos previamente. Las Citas se generarán en base a unas condiciones de Fecha previamente establecidas y teniendo en cuenta un calendario definido en la Agenda interna del usuario. Asimismo, se pueden realizar Cartas de Citación, automáticamente, que se enviarán a los Afiliados correspondientes. Existen una serie de Tareas Pendientes, a las que el Usuario podrá acceder en cada sesión. El personal encargado de esta gestión de la información abarca a personal administrativo y sanitario, y dentro de éste último se encuentran los ATS/DUE, médicos inspectores y coordinadores de inspección. 8/55

9 Proyecto de evolución Alcance A continuación realizamos una breve descripción de los principales objetivos a cubrir el proyecto de evolución actualmente en curso: Integraciones 1. Nuevas integraciones entre la aplicación existente en el Departamento con el sistema de información asistenciales de Osakidetza para Atención Primaria Osabide AP, Dicha integración deberá realizarse mediante servicios web con el objeto automatizar la gestión y lograr una minimización tanto de los errores como de las intervenciones manuales, 2. Generación de nuevos sistemas de integración con el INSS y con Osalan. Reducción al máximo posible de los errores en el envío de partes al INSS. Ampliaciones funcionales, en el sentido de mejoras detectadas durante el uso diario del aplicativo Estado actual El proyecto en la actualidad se encuentra en fase de desarrollo habiéndose entregado la primera de las tres releases con parte de las funcionalidades detectadas en el Análisis Funcional ya completadas Plataforma tecnológica base El entorno tecnológico base es el actual del aplicativo ITEMP: J2EE sobre WebLogic Server 8.1 Oracle 10g como repositorio de Base de Datos 3.2 Nuevo modelo analítico para la herramienta de gestión de Incapacidad Temporal Aplicativo actual En la actualidad, el Departamento de Sanidad y Consumo cuenta a nivel interno con una aplicación que cubre la funcionalidad necesaria para dar soporte a los procesos relacionados con la Gestión de Incapacidad 9/55

10 Temporal. Este sistema es utilizado por el grupo de Inspección Médica para realizar, entre otros procesos, el asociado al mantenimiento de Bajas y Altas por enfermedad y el seguimiento de las Incapacidades Temporales derivadas de los procesos anteriores. El mencionado sistema dispone en la actualidad de un módulo informacional que se explota la información generada mediante la herramienta de SAP Business Objects, con gran número de informes predefinidos. Como resultado del análisis del sistema informacional actual, se han obtenido determinadas consideraciones técnicas que derivan en la necesidad de la construcción de un nuevo modelo analítico. Entre otros aspectos, podemos destacar los siguientes: o El actual modelo dimensional de ITEMP (explotado desde SAP Business Objects) se ha diseñado con el objeto principal de resolver informes particulares perdiendo la perspectiva global del modelo analítico. Por ejemplo: Existen multitud de cubos, muchos de ellos duplicados o muy similares Un mismo indicador existe en diferentes cubos Los cubos muchas veces no son navegables entre sí, por no compartir todas sus dimensiones o granularidad. o En un sistema de Business Intelligence los principales esfuerzos no se deben focalizar en la construcción de informes puntuales, sino en modelizar el DatawareHouse de forma que sea viable construir cualquier informe o análisis que se pueda necesitar en el futuro con el mínimo esfuerzo posible Proyecto de evolución Alcance El principal objetivo del nuevo proyecto es dotar a los usuarios de la aplicación L31-2-Itemp (Incapacidad Temporal) de una herramienta que facilite la obtención/gestión de listados, estadísticas y cuadros de mando de forma eficaz y autónoma utilizando para ello el tool de herramientas Oracle Business Intelligence Enteprise Edition (OBIEE). Dadas las deficiencias detectadas en el actual sistema informacional, muy focalizado en su diseño y construcción a los informes concretos que ahora contiene, no se contempla la posibilidad de reutilizar dicho datamart, sino que se pretende analizar, construir e implantar un nuevo sistema informacional, diseñado para la consecución del objetivo que se persigue y que incluya una visión de las potenciales evoluciones del sistema en el futuro. Deberá por tanto incluir los procesos de descarga y carga de información del operacional al informacional que sean necesarios y contemplando distintas periodicidades (por ejemplo, incremental diario y total semanal). La periodicidad concreta será definida en la fase de análisis y diseño del proyecto correspondiente en función de los requerimientos de negocio a cumplir que se determinen. 10/55

11 Estado actual El proyecto en el momento de la elaboración de este documento se encuentra aún sin comenzar, aunque se prevé su arranque en un plazo muy breve de tiempo Plataforma tecnológica base El entorno tecnológico base es el actual del aplicativo ITEMP: Oracle Business Intelligence Enterprise Edition Oracle 10g como repositorio de Base de Datos 3.3 Sistema de Información de Aseguramiento con Base Poblacional (SIABP) Aplicativo actual El Departamento de Sanidad cuenta con una serie de herramientas, desarrolladas alrededor del Sistema Integrado de Información de Aseguramiento (en adelante, SIIA), que cubren la funcionalidad necesaria para dar soporte a los procesos relacionados con la gestión del aseguramiento y la tarjeta sanitaria. De modo esquemático podemos reflejar lo siguiente: 11/55

12 Descripción de relaciones 12/55

13 Sistemas de Información 13/55

14 Modelo Tecnológico Proyecto de evolución Alcance El principal objetivo del nuevo proyecto es la implantación de un nuevo Sistema de Información de Aseguramiento con Base Poblacional que, además de dar cobertura a los requerimientos ya cubiertos por el antiguo sistema de información, realice de modo satisfactorio la integración con los Sistemas de Información 14/55

15 de Osakidetza y dotarse de la característica poblacional : no ser únicamente un sistema de control del proceso y repositorio de lo relacionado con el aseguramiento, sino convertirse en un repositorio el que se almacenen, entre otros aspectos, la totalidad de los usuarios que han hecho uso del Sistema Sanitario Vasco Estado actual El proyecto está en curso Plataforma tecnológica base El entorno tecnológico es el asociado con la implantación del producto CIVITAS de Steria: Oracle 10g como repositorio de Base de Datos Oracle WebLogic Server 11g a modo de servidor de aplicaciones Java Web Start como herramienta cliente 15/55

16 4 Oficina Técnica y Calidad para los proyectos estratégicos de la Dirección de Aseguramiento y Como se ha mencionado anteriormente en este Pliego de Bases Técnicas, el objetivo del mismo es la contratación de los servicios asociados a la Oficina Técnica y de Calidad para el proyecto los proyectos estratégicos de la Dirección de Aseguramiento y. En este punto se detallarán los requerimientos que deberán cumplirse por el servicio a contratar y que serán analizados convenientemente en la fase de valoración de las ofertas presentadas como respuesta a este Pliego. 4.1 Objetivos y tareas a realizar por la Oficina Técnica Las tareas a llevar a cabo por la Oficina Técnica deberán detallarse en las ofertas que se presenten como respuesta al presente Pliego de Bases Técnicas como parte de la visión de la compañía ofertante dentro de su propuesta de valor para una oficina de estas características. No obstante, de entre las tareas mínimas a realizar que deberán ser cubiertas, destacan los siguientes aspectos: Gestión de proyecto o La gestión del proyecto de implantación será realizada por el Jefe de Proyecto de EJIE o La Oficina Técnica deberá servir de soporte a la Jefatura de Proyecto de EJIE para llevar a cabo dicha gestión mediante las tareas de seguimiento, control de la planificación, identificación de riesgos, etc. que se derivan de un proyecto de estas características. o Deberá, dentro de la gestión de proyecto, garantizar que ésta se acomoda a lo ya definido a este tipo de tareas en la metodología ARINBIDE aplicada en EJIE para los proyectos de construcción e implantación de Sistemas de Información. Nivel funcional o Los requerimientos funcionales serán definidos por los interlocutores que el Departamento de Sanidad determine. Será responsabilidad de los proyectos de implantación la realización del análisis funcional para que el sistema a construir cubra con los requerimientos demandados por los usuarios. o La Oficina Técnica a este respecto deberá realizar, entre otras, las siguientes tareas: Asistencia a reuniones de toma de requerimientos funcionales. Revisión de los análisis funcionales, no sólo desde el punto de vista de calidad marcados por la metodología ARINBIDE, sino también para comprobar que éste cubre con las expectativas que los responsables de la definición funcional demandan del nuevo sistema. Ejecución, soporte y seguimiento de las pruebas funcionales del sistema. La ejecución de las pruebas funcionales será responsabilidad de los usuarios que el Departamento 16/55

17 de Sanidad defina. Aun así, la Oficina Técnica y Calidad deberá realizar en colaboración con el equipo de Asistencia Técnica y Sanidad, previa o conjuntamente las pruebas funcionales que se consideren necesarias, bien para servir de filtro previo a la ejecución de las mismas por parte del personal del Departamento, bien para servir de refuerzo en la ejecución de las pruebas como tal. Este trabajo se realizará con el apoyo del personal de EJIE asignado a los proyectos definidos. Nivel técnico o Soporte de la tecnología Colaborar en la definición de la arquitectura general del Sistema de Información incluyendo aspectos como: Arquitectura general o Definición de CPDs o Comunicaciones y seguridad Tecnologías y frameworks de desarrollo Tecnologías y frameworks de integración Tareas a realizar por la Oficina Técnica en relación a la metodología de desarrollo: Deberá definir el modo de entrega de las releases del producto así como del trabajo con las mismas en los diferentes entornos contemplados, uso de la herramienta de control de versiones, etc. Algunos de los proyectos estarán basados en metodologías ágiles y, derivado del requerimiento anterior, deberá concretar el modus-operandi en el que éstas se aplicarán a cada uno de los proyectos en cuanto a la gestión de configuración, etc. Además de la definición como tal, deberá realizar el seguimiento de los aspectos comentados con anterioridad. Metodología y control de la calidad o Calidad y gestión de los entregables de documentación Asociada la metodología ARINBIDE, se determinan los entregables para cada una de las fases del proyecto tanto en contenido como en forma (plantillas, nomenclatura, etc.). Será responsabilidad de la Oficina Técnica identificar cuál será el nivel de cumplimiento de ARINBIDE y, por tanto, de los entregables a realizar por parte de los diferentes equipos de proyecto. Será responsabilidad de la Oficina Técnica el aseguramiento de la calidad asociado al nivel de cumplimiento de ARINBIDE determinado. 17/55

18 o Para el trabajo interno de los proyectos estratégicos, se dispondrá de entornos colaborativos para la gestión de los entregables de documentación. La oficina técnica será la responsable de la gestión de los diferentes portales. Calidad de software La Oficina Técnica deberá garantizar el cumplimiento por parte de los diferentes proyectos uno de los aspectos que se derivan de la condición anterior. PROBAMET. Deberán analizarse las posibles adopciones de PROBAMET para cada uno de los proyectos así como el soporte a los equipos del proyecto y personal de EJIE asociado para las primeras releases entregadas de cada proyecto. La Oficina Técnica será la responsable de la coordinación, supervisión y seguimiento de las diferentes planes y ejecuciones de los tipos de pruebas asociadas a la calidad del software tales como: Pruebas unitarias Pruebas de integración Pruebas de rendimiento Pruebas de carga Para ciertos aspectos relativos a la ejecución de las pruebas anteriores, la Oficina Técnica deberá coordinar los trabajos del equipo del proyecto de implantación de la proyectos estratégicos de la Dirección de Aseguramiento y con otros equipos terceros como los de Proyectos Soft. y Consultoría y Soporte Software de EJIE. Implantación de las plataformas o Para la puesta en marcha de las nueva plataformas, deberán realizarse acciones a llevar a cabo por equipos de trabajo diferentes: tareas de infraestructura, de despliegue de aplicativos, etc. La Oficina Técnica, en función de la planificación establecida, deberá coordinar y realizar el seguimiento de las acciones concretas para garantizar el cumplimiento de los requerimientos y planificación asociadas a la iniciativa. Gestión del servicio de la Oficina Técnica o Deberá existir la figura del gestor del servicio de Oficina Técnica que tendrá como responsabilidades principales las siguientes: Realizar reuniones de seguimiento del servicio prestado Tratar asuntos de facturación relativo a la Oficina Técnica Búsqueda de los perfiles adecuados en caso de precisar apoyos puntuales o sustitución de alguno de los miembros. Caso, este último, que deberá atenerse a los 18/55

19 condicionantes definidos en el punto Equipo de Trabajo de este Pliego de Bases Técnicas. La totalidad de los trabajos deberá realizarse en colaboración con el equipo de Asistencia Técnica de Sanidad de EJIE que colaborará en cada uno de los proyectos. 4.2 Composición de la Oficina Técnica y periodo de servicio a contratar Al igual que en los objetivos y tareas, la composición de la Oficina Técnica es orientativa y estará abierta a la visión que las diferentes empresas aporten al respecto en sus ofertas. A continuación, se presenta la composición del equipo de Oficina Técnica inicialmente planteado así como su ubicación en el organigrama general, siendo esta parte organizativa algo que se deriva de la naturaleza de los servicios a contratar. Composición de la Oficina Técnica La composición de la Oficina Técnica estará formada por dos personas con dedicación completa y exclusiva durante la totalidad del periodo de contratación de los servicios. El gran grueso, si no la totalidad, de las tareas mencionadas con anterioridad deberán ser realizadas por este equipo de proyecto estable. Asimismo, se considera interesante una dedicación parcial de perfiles adicionales de apoyo para tareas como: Apoyo puntual en tecnologías específicas por parte de expertos conocedores de las mismas. Gestión del servicio, tanto en su vertiente de seguimiento como en los aspectos relativos a facturación y gestión del equipo de trabajo. La totalidad de los integrantes del equipo de Oficina Técnica presentado deberán atenerse a las condiciones expresadas en el capítulo Equipo de Trabajo del presente Pliego de Bases Técnicas. Organigrama propuesto de la Oficina Técnica dentro de los proyectos estratégicos de la DAC 19/55

20 Periodo de servicio a contratar Los servicios de la Oficina Técnica especificados dentro del presente Pliego de Bases Técnicas, deberán ser prestados durante, al menos, 12 meses a partir de la fecha de inicio de los servicios una vez hayan sido adjudicados los trabajos siguiendo la normativa vigente asociada a la modalidad de contratación correspondiente. 20/55

21 5 Metodología Aplicable y Entorno Tecnológico La Oficina Técnica a contratar, tal y como se ha comentado anteriormente en el apartado Objetivos y tareas a realizar por la Oficina Técnica, deberá garantizar que el proyecto de implantación de los sistemas de información sigue la metodología y controles de calidad que se determinen. Dentro de este apartado explicamos brevemente alguno de los aspectos más importantes a este respecto. 5.1 Metodología de desarrollo, normativa y Guía de Estilo La organización del trabajo y ejecución del proyecto estará basada en la metodología de planificación y desarrollo de sistemas de información ARINbide v1.0., y la metodología de pruebas PROBAMET v2.0. ARINbide v1.0 se concibe como una metodología práctica para el ciclo de vida completo del software, basada en Métrica 3, y adaptada a las necesidades y directrices de E.J.I.E. Además consta de un apartado para el establecimiento de una metodología de Gestión de Proyectos. Como Plan de Calidad la propia metodología, en sus apartados de trabajo habitual, genera los registros de calidad necesarios para el sistema de calidad de E.J.I.E. Para todo el ciclo de vida del proyecto, ARINbide define los siguientes procesos: Ingeniería del Software (ISW) Gestión del Proyecto (GPR) Gestión de Riesgos del Proyecto (GRP) Gestión de la configuración (GCO) Mantenimiento del Sistema de Información (MSI) El proceso principal de ingeniería del software (ISW) describe y normaliza la secuencia de fases y actividades a realizar en el proyecto de desarrollo de un sistema de información, así como los entregables a obtener en cada una de ellas. En este ámbito, ARINbide v1.0 contempla el desarrollo de las siguientes fases metodológicas: Catálogo de Requisitos de Usuario (CRU) (proceso diferenciado dentro del Análisis del Sistema de Información, ASI) Análisis del sistema (ASI) Diseño del sistema (DSI) Construcción del sistema (CSI) Implantación y aceptación del sistema (IAS) 21/55

22 El ciclo de vida descrito en la metodología de desarrollo ARINbide se alinea y complementa a lo largo del tiempo con la metodología de pruebas corporativa Probamet, centrándose ésta última en la especificación de todas las actividades relacionadas con la planificación, definición y ejecución de los diferentes tipos de pruebas. Existe una correspondencia entre las fases de ejecución de ARINbide y las fases de ejecución de Probamet. Información detallada sobre las fases y entregables de la metodología ARINbide, se encuentra en la página web de E.J.I.E.: En las distintas fases del proyecto, teniendo en cuenta la mencionada metodología ARINBIDE, y según el alcance de aplicación de la misma acordada entre la dirección del proyecto y la empresa adjudicataria en las fases iniciales del proyecto, ésta última deberá contemplar, entre otros, los siguientes elementos: Catálogo de Requisitos de Usuario. Debe incluir: La definición del sistema La definición, análisis y validación del catálogo de requisitos Análisis del Sistema de Información. Debe incluir : La relación de los módulos del sistema. Análisis de las aplicaciones, ASI (ERS) Especificación del Plan de Pruebas, según las directrices establecidas en Probamet El adjudicatario partirá de los entregables resultantes de las actividades del Catálogo de Requisitos de Usuario. Diseño del sistema. Lo realizará en su totalidad el adjudicatario de los proyectos de implantación y en sus dependencias. Debe incluir: Diseño de las aplicaciones, DSI. (EDS) Especificar el detalle del Plan de Pruebas del sistema por cada uno de los niveles de prueba: unitarias, de integración, de sistema, de implantación y de aceptación, según las directrices establecidas en Probamet Construcción del sistema. Lo realizará en su totalidad el adjudicatario de los proyectos de implantación en sus dependencias, teniendo en cuenta las directrices de E.J.I.E. en lo que se refiere a los módulos estándar, las normas de funcionamiento y albergue de las aplicaciones en Internet/Intranet, el Manual de Identidad Corporativa del Gobierno Vasco y las directrices de la Dirección de Atención a la Ciudadanía en lo que respecta a estética, diseño y funcionalidades de las páginas Web. 22/55

23 Incluirá la ejecución del Plan de Pruebas, para verificar el cumplimiento de los requisitos establecidos en el mismo, abarcando pruebas unitarias, de integración y del sistema, siguiendo el modelo y las actividades descritas en la metodología Probamet Los entregables de esta fase incluyen en la Especificación de Construcción del Sistema (ECS) y el sistema construido. Asimismo, deberán respetarse las convenciones adoptadas para un desarrollo de aplicaciones homogéneas recogidas en el Libro de Estilo del Departamento de Sanidad y Consumo El diseño del sistema tendrá en cuenta el nivel de accesibilidad AA (WAI-AA), para aquellos módulos que sean accesibles desde Internet. Todos los sistemas desarrollados deberán soportar al menos los siguientes idiomas: euskera, castellano. La aplicación, las páginas, los textos, los mensajes de error/aviso y/o cualquier otro componente (tool-tip, textos en imagen,.) dirigidos al usuario final deberán estar al menos en ambos idiomas: euskera y castellano. Implantación en desarrollo. La empresa adjudicataria del proyecto de implantación realizará la entrega de la aplicación en el sistema de corporativo de control de versiones Subversion, tanto de la entrega inicial como de las sucesivas La empresa adjudicataria del proyecto de implantación llevará a cabo la instalación de la aplicación en el entorno de desarrollo de E.J.I.E., habiendo realizado previamente las pruebas necesarias durante la fase de construcción Ejecución de las Pruebas del sistema, acorde con lo establecido en la metodología Probamet y el Modelo SQA, evaluando los resultados Implantación en entorno de test o preexplotación. La empresa adjudicataria del proyecto de implantación preparará los paquetes y dará soporte a la realización por E.J.I.E. de la correspondiente implantación en el entorno de test o preexplotación Ejecución de las Pruebas del sistema, en sus distintos niveles de prueba, incluidas las Pruebas de Aceptación, acorde con lo establecido en la metodología Probamet y el Modelo SQA, evaluando los resultados Pruebas de prestaciones: Conforme a lo establecido en el Modelo SQA, realización de pruebas de rendimiento y carga, que incluyen la verificación de los niveles de respuesta de la aplicación ante las previsiones de carga del sistema, así mismo se verificará el comportamiento global del sistema en 23/55