Source: http://docplayer.es/2544618-Pliego-de-prescripciones-tecnicas.html
Timestamp: 2017-08-18 12:53:03+00:00

Document:
Álvaro Olivera Silva
1 SERVICIOS DE APOYO PARA LA IMPLANTACIÓN DE LA PLATAFORMA DE INTEROPERABILIDAD Y GOBIERNO DE LA ARQUITECTURA ORIENTADA A SERVICIOS (SOA) DE LA WAN DE PROPOSITO GENERAL DEL MINISDEF EXPEDIENTE PLIEGO DE PRESCRIPCIONES TÉCNICAS
2 Índice 1 Introducción PROPÓSITO ANTECEDENTES Descripción del Proyecto OBJETO ALCANCE Especificaciones PRINCIPIOS CONCEPTO DE ARQUITECTURA ORIENTADA A SERVICIOS (SOA) GOBIERNO SOA PLATAFORMA DE INTEROPERABILIDAD Y GOBIERNO SOA SERVICIOS A REALIZAR Soporte de productos SOA de TIBCO Desarrollo de infraestructura SOA de TIBCO MODELO DE TRABAJO Planificación Organización del Proyecto Presentación de la Oferta CONDICIONES GENERALES CONTENIDO DE LA OFERTA TÉCNICA Anexo 1 Glosario de Abreviaturas
3 1 Introducción 1.1 Propósito El Ministerio de Defensa, siguiendo los objetivos marcados en su Plan Director de Sistemas de Información y Telecomunicaciones, pretende desarrollar e implantar una Plataforma de Servicios de Interoperabilidad y Gobierno SOA que constituya una infraestructura SOA para facilitar la integración entre sistemas de información del MINISDEF, y de éstos con los de otras entidades externas (tanto públicas como privadas). Esta plataforma dará el necesario soporte de arquitectura en la WANPG y los nodos I*net del MINISDEF para soportar la implementación de los procedimientos de la e-administración a los que está obligado por ley el Ministerio. El presente Pliego de Prescripciones Técnicas establece los requisitos técnicos y funcionales de los trabajos orientados a obtener dichos servicios, al objeto de solicitar ofertas para su desarrollo e implantación en el Ministerio de Defensa. 1.2 Antecedentes La Directiva núm. 134/1999 del Ministro de Defensa sobre la elaboración del Plan Director de Sistemas de Información para la modernización / profesionalización de las FAS apuesta por el empleo de las Tecnologías de la Información y de las Telecomunicaciones como factor multiplicador de la capacidad operativa y como instrumento para reducir efectivos. Esta Directiva establece además, entre otros factores, la necesidad de homogeneizar y estandarizar los sistemas de información del Ministerio de Defensa para alcanzar la interoperabilidad entre dichos sistemas nacionales, tanto operativos como de gestión, y con los sistemas de otros organismos y alianzas internacionales. Por otra parte, por Orden DEF/315/2002 de 14 de febrero de 2002, el Ministro de Defensa aprobó el Plan Director de Sistemas de Información y Telecomunicaciones en el que se establece la política del Ministerio respecto a las Tecnologías de la Información y Comunicaciones. Según el RD 1126/2008 art. 6.5.c, la Inspección General del Plan Director de Sistemas de Información y Telecomunicaciones ejercerá las funciones de definición de las políticas y estrategias corporativas en el ámbito de la Administración Electrónica, las tecnologías de la información, telecomunicaciones y seguridad de la información del Ministerio de Defensa, así como la planificación y coordinación de las actuaciones en estas materias. La OM 315/2002 por la que se aprueba el Plan Director CIS del Ministerio de Defensa, dentro del apartado referido a Infraestructura Tecnológica determina que la Plataforma Informática y la Arquitectura Técnica del MINISDEF evolucionan a una WAN Corporativa de Propósito General, que da soporte a todos los sistemas de información que no sean específicos para mando y control y se extiende a todos los emplazamientos. Este entorno incluye la conexión a Internet del Ministerio de Defensa, 3
4 desde un único punto de acceso común para todos los usuarios, siendo la única conexión que la WAN de Propósito General tendrá con el exterior. Esta Red se configurará y explotará con una perspectiva corporativa e integrada. En lo referente a Interoperabilidad: Existirá una única plataforma tecnológica de interoperabilidad básica con dos dominios diferenciados para cada una de las dos redes WAN. La ley 11/07, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos establece el principio de cooperación en la utilización de medios electrónicos por las Administraciones Públicas al objeto de garantizar tanto la interoperabilidad de los sistemas y soluciones adoptados por cada una de ellas como, en su caso, la prestación conjunta de servicios a los ciudadanos. Asimismo, en su artículo 41 establece que las Administraciones Públicas utilizarán las tecnologías de la información en sus relaciones con las demás administraciones y con los ciudadanos, aplicando medidas informáticas, tecnológicas, organizativas, y de seguridad, que garanticen un adecuado nivel de interoperabilidad técnica, semántica y organizativa y eviten discriminación a los ciudadanos por razón de su elección tecnológica. Por último, en el artículo 43 establece que la Administración General del Estado, [ ], adoptarán las medidas necesarias e incorporarán en sus respectivos ámbitos las tecnologías precisas para posibilitar la interconexión de sus redes con el fin de crear una red de comunicaciones que interconecte los sistemas de información de las Administraciones Públicas españolas y permita el intercambio de información y servicios entre las mismas, así como la interconexión con las redes de las Instituciones de la Unión Europea y de otros Estados Miembros. La Instrucción Técnica de IGECIS Modelo de Arquitectura I*Net de Mayo de 2006 establece el modelo de arquitectura I*Net para la Red de Área Extensa de Propósito General (WAN PG) que normaliza los servicios que ofrece dicha red desde o hacia el exterior. El Ministerio de Defensa ha determinado, entre otros, como servicios con el exterior asociados a la WAN PG la publicación de información accesible por Internet, acceso desde el exterior a recursos de la red de Propósito General, acceso a la Intranet Administrativa de la AGE, y acceso mediante líneas dedicadas de otros organismos y entidades al Ministerio de Defensa. Dichas necesidades sumadas a condicionantes de seguridad e interoperabilidad establecidos por el Ministerio de Defensa y normativa vigente del Centro Criptológico Nacional del Centro Nacional de Inteligencia ponen de manifiesto la necesidad de la definición de un modelo de arquitectura que englobe y regule los servicios previamente expuestos. En el contexto anterior del Modelo I*net y de los requisitos establecidos por la aplicación de la Ley 11/2007 es clara la necesidad de establecer una arquitectura de interoperabilidad uniforme y corporativa que permita al MINISDEF publicar servicios para el ciudadano y para otras administraciones públicas y, de modo simétrico, consumir los servicios expuestos por otras administraciones públicas, en ambos casos de modo seguro, monitorizado y gestionado de manera uniforme, y conforme a los estándares establecidos por el Ministerio de Defensa. 4
5 2 Descripción del Proyecto 2.1 Objeto Se pretende llevar a cabo el desarrollo e implantación de la arquitectura software establecida por el Modelo de Arquitectura SOA del MINISDEF y su correspondiente desarrollo técnico, cumpliendo los siguientes requisitos: Implantación de los elementos de la Plataforma de Interoperabilidad y Gobierno SOA del MINISDEF en el ámbito de la red de Propósito General y nodos I*net requeridos, basado en productos TIBCO. Desarrollo de plantillas, procedimientos, normas y guías técnicas para diseñar y desplegar servicios y procesos de integración sobre la Plataforma de Interoperabilidad y Gobierno SOA. Desarrollo de los componentes de integración comunes de la Plataforma orientados a establecer un modelo uniforme de seguridad (integrado con PSSDEF y PKIDEF), de gestión de errores y de logs, que permita cumplir con la política de seguridad del MINISDEF, la normativa aplicable del Centro Criptológico Nacional del Centro Nacional de Inteligencia y la normativa legal vigente. 2.2 Alcance Como resultado de los trabajos se obtendrán una serie de servicios y procesos de integración basados en tecnologías SOA de TIBCO, operativos para los sistemas de propósito general del MINISDEF. Además se obtendrá una documentación detallada de la implementación de dichos servicios así como de su diseño y explotación. El presente pliego se refiere al suministro de los servicios de desarrollo y adaptación de software, consultoría técnica, técnica de sistemas, testeo y generación de documentación, no incluyéndose equipo hardware ni adquisición de licencias de software de ningún tipo. El alcance del proyecto abarca: Diseño e implantación de la solución en sistemas de WAN-PG y nodo I*Net, en entornos de desarrollo, preproducción y producción. Diseño y desarrollo de servicios o componentes comunes técnicos de interoperabilidad, tales como: políticas de seguridad, registro de servicios, gestión de errores y trazas, metodología de implantación de servicios, framework de desarrollo de servicios, monitorización, administración etc. Establecimiento de las políticas necesarias para satisfacer el modelo de gobierno SOA establecido por el MINISDEF. 5
6 Establecimiento del proceso de gestión del ciclo de vida de los componentes SOA. Implantación de la plataforma SOA del MINISDEF. 3 Especificaciones 3.1 Principios A continuación se enumeran una serie de principios de alto nivel, de aplicación para el desarrollo de la Plataforma Interoperabilidad y Gobierno SOA del MINISDEF: Solución corporativa. Solución capaz de abarcar las necesidades de integración de los distintos sistemas de información de la WAN PG, independientemente de sus plataformas tecnológicas, tanto en interacciones internas a la WANPG como con el exterior. Robustez y perdurabilidad en el tiempo de la Arquitectura. Se pretende que sea lo más independiente posible de la evolución de la tecnología y los productos software con que se implemente. Adaptabilidad. Arquitectura capaz de adaptarse y evolucionar de acuerdo a los cambios tecnológicos y las nuevas necesidades de integración de los sistemas de la WANPG. Neutralidad tecnológica basada en estándares abiertos, independiente de la plataforma y del lenguaje de programación. De este modo se garantiza soportar las necesidades de integración de la mayor parte de los sistemas, independientemente de su tecnología. Escalabilidad. Debe permitir implantar soluciones técnicas fácilmente escalables de modo que soporte tanto necesidades de integración con requisitos de baja criticidad y volúmenes de datos discretos como necesidades más exigentes en volumen, rendimiento y fiabilidad. 3.2 Concepto de Arquitectura Orientada a Servicios (SOA) SOA es un modelo de arquitectura de software que proporciona un enfoque modular y flexible para la implementación de requisitos funcionales en los sistemas. En una SOA las funciones software de los sistemas se exponen como servicios reutilizables que pueden ser descubiertos e invocados a través de la red. El uso de SOA facilita la compartición de aplicaciones y datos, proporcionando un mecanismo flexible para reutilizar los servicios, habilitando el desarrollo de nuevas aplicaciones mediante la composición de servicios ya existentes. 6
7 Un objetivo fundamental de SOA es hacer que los recursos de información estén disponibles en la red para todos los potenciales sistemas consumidores, y soportar el descubrimiento y entrega eficiente de dicha información al sistema consumidor. El desarrollo del concepto SOA está ligado a los requisitos cambiantes de los entornos corporativos, lo que provoca la necesidad de adaptarse más rápidamente a los cambios. SOA facilita el desarrollo de aplicaciones nuevas basadas en la reutilización de los servicios disponibles en la red. SOA es también consecuencia de la búsqueda de acoplamiento débil entre sistemas, de modo que un sistema pueda utilizar las funciones y datos de otro mediante interfaces bien definidos. Este acoplamiento débil debe ser lo más neutral posible desde el punto de vista tecnológico, facilitando la evolución independiente de cada sistema. SOA puede definirse como un modelo de arquitectura para la creación de sistemas modulares, que pueden interoperar mediante interfaces bien definidas e independientes de la tecnología en la que estén implementados, que utilizan metadatos estándar y cuya localización es posible gracias a un registro de servicios estandarizado. Estos servicios pueden invocarse de modo independiente o en secuencias definidas para formar procesos de negocio. Los sistemas están débilmente acoplados y se ven los unos a los otros como servicios, accesibles vía interfaces estándar sin conocer la implementación subyacente del servicio. Un bus de servicios gestiona y coordina la interacción entre los servicios. Los datos se intercambian mediante un formato común usando protocolos estándar, lo cual asegura la interoperabilidad. Todo ello permite que se produzcan interacciones sistema-a-sistema no previstas en el momento del diseño de cada sistema. Cualquier SOA contiene tres roles básicos: consumidor de servicios, proveedor de servicios e intermediario de servicios. 1. Un proveedor de servicios es responsable de la creación y descripción de un servicio, publicarlo en un intermediario de servicios, y recibir los mensajes de invocación del servicio desde uno o más consumidores a través del intermediario de servicios. 2. Un consumidor de servicios es responsable de encontrar una descripción de un servicio en un intermediario de servicios, y utilizar la descripción para invocarlo. 3. Un intermediario de servicios es responsable de publicar las descripciones de servicios publicadas por los proveedores y de permitir a los consumidores descubrir e invocar servicios. La Plataforma de Interoperabilidad y Gobierno SOA del MINISDEF debe proporcionar una serie de servicios comunes que permitan a cualquier sistema de información de la WANPG actuar como proveedor o consumidor de servicios, asumiendo esta Plataforma el rol de intermediario de servicios. 7
8 3.3 Gobierno SOA El Gobierno SOA (SOA Governance) se centra en la gestión del ciclo de vida de los servicios con el objetivo de garantizar el valor de negocio de SOA para la organización. Se refiere a las actividades relacionadas con el ejercicio de control sobre los elementos que componen la arquitectura, afectando especialmente al ciclo de vida de los servicios. La necesidad de gobierno SOA es consecuencia de la inherente granularidad y complejidad de la arquitectura, en la que diferentes elementos (sistemas proveedores y consumidores, componentes de servicio, bus de servicios, procesos de negocio, etc.) cooperan para resolver necesidades de negocio comunes y además, muy frecuentemente, bajo ámbitos de responsabilidad diferentes. A lo largo del tiempo los servicios deben adaptarse a nuevas necesidades y cambiar su funcionalidad y comportamiento. La alineación entre requisitos de la organización y tecnología implica adaptarse a cambios constantes y evitar la creación de servicios con funcionalidades similares o la existencia de múltiples versiones de un mismo servicio de modo innecesario. El propósito de establecer Gobierno SOA en una organización consiste en ejercer control mediante el establecimiento de políticas para la gestión y monitorización de los servicios tanto desde un punto de vista técnico (disponibilidad de los servicios) como de negocio (qué servicios son necesarios, cómo y quién los autoriza, quién los realiza, etc.). La Plataforma de Interoperabilidad y Gobierno SOA del MINISDFE debe incluir componentes y herramientas software para facilitar el Gobierno SOA, complementando los procedimientos y normativas que establezcan buenas prácticas para una gestión completa del ciclo de vida de los servicios. Desde un punto de vista tecnológico los elementos de la arquitectura que soportan el Gobierno SOA son: Registro de Servicios: Repositorio de información donde se publican y categorizan las descripciones de servicios disponibles junto con sus, interfaces, restricciones de uso, condicionantes de seguridad, versionado, etc. Se utiliza primordialmente en tiempo de diseño. Herramientas de monitorización: En tiempo de ejecución monitorizan el estado de los servicios en su aspecto técnico (disponibilidad, rendimiento, errores, log,..) soportando la supervisión del cumplimiento de los posibles SLA s que se establezcan. Adicionalmente monitorizan los propios elementos de la infraestructura SOA. Elementos de seguridad: En tiempo de ejecución supervisan el cumplimiento 8
9 de las políticas de seguridad establecidas para cada servicio. 3.4 Plataforma de Interoperabilidad y Gobierno SOA En el diagrama siguiente se resume la arquitectura lógica de alto nivel definida para soportar la SOA corporativa del MINISDEF, reflejando la relación con los nodos del modelo I*net implicados. En base al diagrama anterior se describen a continuación los elementos de la arquitectura: Los Sistemas funcionales, legados o nuevas aplicaciones (como en el caso de componentes funcionales para la e-administración), están basados en diferentes plataformas tecnológicas. Mediante componentes de servicio se conectan a la plataforma mediante protocolos de transporte de nivel de aplicación tales como http, SOAP, ftp, jdbc, etc. o Siempre que sea posible se utilizarán esquemas XML para especificar los datos intercambiados por los servicios. Dichos esquemas XML forman 9
10 parte del Modelo de Datos Canónico (común) almacenado en el Registro de Metadatos de Defensa. Los sistemas de plataforma, proporcionan diversos servicios comunes, pero no soportan funcionalmente el negocio de la organización. Inicialmente se requiere la integración con los sistemas siguientes: o PSSDEF. Provee servicios de seguridad tales como validación de certificados electrónicos, firma digital y cifrado. o DICODEF. Directorio corporativo del MINISDEF que gestiona los usuarios, roles y autorizaciones. o Notes. Cuando la operativa lo requiera proporciona envío de notificaciones mediante correo interpersonal. Bus de servicio en intranet. Permite la ejecución de los servicios de la plataforma proporcionando las siguientes características: o Mediación de datos: Permite la interacción entre el consumidor y proveedor del servicio. Contiene capacidades para transformación y transporte de datos. Adicionalmente, permite la orquestación de servicios. o Servicios core no funcionales. Proporciona gestión de errores y de trazas comunes para todos los servicios, además de una gestión de logs uniforme. o Capacidades de monitorización y cumplimiento de SLA s. Registro de Servicios. Repositorio de información donde se publicarán los servicios disponibles en la red para poder ser reutilizados por otras aplicaciones. Existen dos instancias diferentes: o El Registro de Servicios de la Intranet publica los servicios disponibles en la red para ser reutilizados por aplicaciones internas del MINISDEF. o El Registro de Servicios Público del Nodo extranet publica los servicios del MINISDEF susceptibles de ser consumidos por una organización externa al Ministerio de Defensa. o En el caso de servicios proporcionados por una organización externa al MINISDEF que susceptibles de ser consumidos por aplicaciones internas del MINISDEF, serán publicados en el Registro de Servicios de la Intranet, aunque siempre mediados por el Bus de Servicios, para garantizar seguridad y monitorización. Registro de Metadatos de Defensa (RMD). Se publican y gestionan los 10
11 esquemas de datos pertenecientes al Modelo Común de Datos, así como otros esquemas, metadatos y documentación asociada relacionada con la Plataforma. Portales y aplicaciones web del MINISDEF en Internet. Son todas aquellas aplicaciones web (incluyendo portales) residentes en el Nodo de Servicios Web que requieren consumir servicios disponible en la Intranet, los cuales están publicados en el Registro de Servicios de la Intranet. Bus de servicios en el nodo extranet. Su función primordial es mediar los servicios publicados por el MINISDEF susceptibles de ser consumidos por organizaciones externas, garantizando la seguridad. Autentica y autoriza a las aplicaciones ajenas al MINISDEF mediante PPSDEF. Adicionalmente transforma y enruta los mensajes de la aplicación consumidora hacia el servicio final de la intranet, junto con el Agente de Políticas. Agentes de políticas. Aplica las políticas de seguridad que se requieran para permitir la invocación de un servicio. Existirán las instancias requeridas en cada caso, indicadas en el apartado siguiente. 3.5 Servicios a realizar El alcance de los servicios a realizar está agregado por los siguientes puntos Diseño e implantación de la solución en sistemas de WAN-PG y nodo I*Net, en entornos de desarrollo, preproducción y producción. Diseño y desarrollo de servicios o componentes comunes técnicos de interoperabilidad, tales como: políticas de seguridad, registro de servicios, gestión de errores y trazas, metodología de implantación de servicios, framework de desarrollo de servicios, monitorización, administración etc. Establecimiento de las políticas necesarias para satisfacer el modelo de Gobierno SOA definido para el MINISDEF. Establecimiento del proceso de gestión del ciclo de vida de los componentes SOA. Implantación de la plataforma SOA del MINISDEF Soporte de productos SOA de TIBCO Con la finalidad de garantizar el cumplimiento de los objetivos y el alcance del proyecto definidos por el MINISDEF, estas son las tareas que deben ser realizadas por un perfil de Arquitecto experto TIBCO que forme parte del equipo de trabajo: Diseño de los Componentes Comunes de la Plataforma. 11
12 Asistencia técnica al equipo de trabajo durante las pruebas piloto y desarrollo de los Componentes Comunes. A continuación se resumen las tareas a realizar: 1. Diseño Guías Técnicas de Implementación de Servicios 2. Diseño Gestión Central de Errores 3. Diseño de la Automatización del Ciclo del Despliegue 4. Diseño de Reglas de Administración y Monitorización 5. Diseño de las Políticas de Seguridad 6. Diseño del Registro de Servicios 7. Participación reuniones de validación y explicación de entregables a lo largo del proyecto A continuación se detalla el alcance de cada una de las tareas: Diseño Guías Técnicas de Implementación de Servicios Crear plantillas comunes adaptadas a las necesidades del MINISDEF y basadas en los productos SOA de TIBCO, incluye las siguientes guías técnicas: Guía de Diseño Funcional. Guía de Diseño Técnico. Guía de Desarrollo de servicios. Guía de Instalación y despliegue. Guía de Casos de pruebas. Guía de operación. Estas guías deben facilitar disponer de un formato común y estándar para la creación de documentos asociados a la fase de diseño, desarrollo e implementación de los servicios corporativos por parte de las áreas de desarrollo del Ministerio. Además, deben facilitar la validación de los proyectos SOA, porque cualquier equipo de trabajo implementaría los servicios bajo las mismas reglas y normas. Por último. Proporcionarán estandarización corporativa de los requisitos de información necesarios para la implementación de los servicios. 12
13 Diseño Gestión Central de Errores Diseñar la aplicación de gestión de los errores a nivel de la Plataforma de Interoperabilidad y Gobierno SOA mediante la aplicación de: políticas de error, catalogación de los errores y resolución automática de los mismos. Debe proporcionar: Control y seguimiento centralizado de todos los errores detectados en la Plataforma de Interoperabilidad y Gobierno SOA Resolución automática y manual de los errores mediante la aplicación de políticas de error. Seguimiento estadístico de los errores por: criticidad, área organizacional, tipo, localización, etc. Utilización de una librería común de errores por parte de los equipos de desarrollo de los servicios. Esto facilita el mantenimiento de los servicios. Diseño de la Automatización del Ciclo del Despliegue Diseño detallado de los procedimientos automáticos de despliegue de los servicios en los diferentes entornos, incluyendo: Procedimientos automáticos de creación de ficheros de despliegues. Procedimientos de automáticos de despliegue en los diferentes entornos. Procedimientos automáticos de configuración de los servicios desplegados. Aportando los siguientes beneficios: Desplegar servicios de manera rápida y fiable, disminuyendo la posibilidad de cometer errores por intervenciones manuales durante la configuración de los mismos. Menor tiempo invertido en el despliegue de los servicios. Diseño de Reglas de Administración y Monitorización Diseñar procedimientos de control y monitorización de la Plataforma de Interoperabilidad. Estos procedimientos permitirían crear reglas automáticas de arranque/paradas de los servicios, detección automática de posibles fallos de máquina o consumo de recursos de hardware/software por parte de los servicios. Aportando los siguientes beneficios: Anticiparse a los posibles fallos de la Plataforma en el momento oportuno, garantizando de esa manera la disponibilidad de la plataforma a las diferentes áreas usuarias. 13
14 Aumentar la fiabilidad y disponibilidad de la Plataforma. Diseño de las Políticas de Seguridad Diseñar los diferentes escenarios de seguridad aplicables al Ministerio de Defensa. Consiste en detallar los procedimientos que se aplican a las casuísticas del Ministerio tales como: procedimientos de seguridad para petición de servicios desde el Nodo de los Servicios Web hacia la WAN-PG (red interna), procedimientos de seguridad para la petición de servicios desde el Nodo Internet hacia la WAN-PG. Es decir esta tarea detallará qué pasos de seguridad hay que seguir para los diferentes escenarios que se van a implementar en la Plataforma de Interoperabilidad y Gobierno SOA, las cuales estarían dentro del marco de las políticas de seguridad del Ministerio. Aportando los siguientes beneficios: Garantizar que los escenarios implementados en la Plataforma de Interoperabilidad y Gobierno SOA, cumplen con las políticas de seguridad del MINISDEF. Garantizar que cada implementación de servicio se realice siguiendo las normas establecidas para cada uno de ellos. Identificar que componentes arquitecturales y productos de seguridad que intervienen en la implementación de los servicios. Diseño del Registro de Servicios Diseñar la organización del almacenamiento de los servicios en la plataforma SOA. Permite determinar lo siguiente: en que punto de acceso de la red (URL) se proveen los servicios?, qué servicios son públicos y cuales privados?, qué perfiles y roles pueden visualizar los servicios?, etc. Aportando los siguientes beneficios: Centralizar todos los servicios implementados en un único sitio, permitiendo un mayor control y reutilización de los mismos. Compartir del Registro de Servicios Corporativo con todas las áreas usuarias de la Plataforma de Interoperabilidad y Gobierno SOA. Participación reuniones de validación y explicación de entregables a lo largo del proyecto Asistencia a las reuniones realizadas en el proyecto para: validación de entregables, acuerdos de equipo, etc. Aportando los siguientes beneficios: 14
15 Resolución directa de dudas y preguntas del equipo de proyecto en los casos necesarios. Participación directa en todas las decisiones y acuerdos realizados por el equipo del proyecto Desarrollo de infraestructura SOA de TIBCO Con la finalidad de garantizar el cumplimiento de los objetivos y el alcance del proyecto definidos por el MINISDEF, estas son las tareas que deben ser realizadas por un perfil de Consultor/Ingeniero de desarrollo experto en integración SOA y con conocimientos prácticos de las herramientas de TIBCO: 1. Desarrollo y validación sobre las herramientas TIBCO de las guías técnicas de implementación de servicios 2. Desarrollo sobre las herramientas TIBCO de la gestión Central de Errores 3. Desarrollo y configuración sobre herramientas TIBCO de los componentes necesarios para la automatización del Ciclo del Despliegue 4. Desarrollo y configuración sobre herramientas TIBCO de las reglas Administración y Monitorización de la plataforma SOA 5. Implantación y configuración sobre herramientas TIBCO de las Políticas de Seguridad 6. Implantación y configuración del Registro de Servicios 7. Desarrollo sobre herramientas TIBCO de los Componentes Comunes de la Plataforma de Interoperabilidad y Gobierno SOA 8. Instalación de productos software TIBCO y realización de pruebas para la integración con los sistemas de plataforma existentes en WANPG y nodos I*net tales como PSSDEF, PKIDEF y Directorios corporativos. 9. Análisis y Desarrollo de servicios y procesos de integración SOA en los pilotos que se determinen. 3.6 Modelo de trabajo El control y seguimiento, y la supervisión del proyecto será responsabilidad de la IGECIS. El personal contratado en base a la prestación de servicios ofertada deberá asumir tareas de análisis, diseño, desarrollo, pruebas e implantación de los servicios software y procesos de integración SOA desarrollados, además de instalar el software 15
16 de base y configurar el entorno de desarrollo y explotación del sistema, en definitiva, constituyen el equipo de desarrollo del proyecto. El equipo de desarrollo del proyecto deberá asumir las siguientes tareas: Análisis detallado de la funcionalidad a satisfacer por los servicios y procesos de integración SOA a desarrollar. Diseño, desarrollo y pruebas de los servicios y procesos de integración SOA en el entorno de desarrollo. Realización de informes técnicos sobre la evolución del proyecto y sobre las pruebas realizadas. Adaptación, instalación y configuración de los productos requeridos. Adaptación y desarrollo de la documentación técnica correspondiente. Lugar de trabajo: El equipo de proyecto dispondrá de puestos de trabajo durante la duración del proyecto en las Oficinas de la IGECIS (actualmente en C/ Joaquín Costa, 6, MADRID). Puntualmente el personal deberá desplazarse para reuniones de trabajo y/o intervenciones puntuales a otras dependencias del Ministerio de Defensa o de entidades con las que el Ministerio colabore. Los costes de desplazamiento correrán por cuenta del contratista. Recursos Hardware y Software: La IGECIS proporcionará los recursos de hardware y software de base para los entornos de servidor que se determinen. El sistema operativo servidor para el entorno de desarrollo y pruebas será Microsoft Windows XP. Los entornos de desarrollo y pruebas de integración estarán alojados en la IGECIS y los entornos de preproducción y producción en el CCEA. El contratista deberá proporcionar (sin cargo en la oferta) los puestos de trabajo cliente del personal contratado, que consistirán en PC s portátiles con sistema operativo Windows XP, Microsoft Office y las herramientas software de desarrollo (IDE s, editores XML, ) que se consideren oportunas. La propiedad intelectual de todos los documentos, código fuente, diagramas y cualesquiera otros productos creados en el contexto del proyecto corresponderá en exclusiva al Ministerio de Defensa. 16
17 La empresa facilitará un informe semanal detallado de las horas dedicadas al proyecto desglosado por personal y tareas realizadas. Dicho informe se elaborará y entregará puntualmente a la IGECIS a semana vencida, utilizando preferentemente medios electrónicos, salvo que la IGECIS establezca el formato y procedimiento que estime oportuno. 4 Planificación Una vez adjudicado el contrato y como fase previa inicial del proyecto se realizará una planificación detallada en la que se desarrollarán las tareas identificadas en el modelo de trabajo identificado en los apartados anteriores. 5 Organización del Proyecto La estimación de los perfiles necesarios para la ejecución de los trabajos se detalla en la tabla siguiente: Por parte del Contratista Categoría Consultor / Ingeniero de desarrollo Arquitecto experto TIBCO Tareas a realizar Análisis y diseño de servicios y procesos de integración SOA. Elaboración de documentación técnica, informes. Análisis, diseño, desarrollo y pruebas de componentes de integración. Diseño, desarrollo y adaptación de arquitecturas de servicios de infraestructura SOA: Registro, Seguridad, Monitorización, Bus de Servicios Diseño e implantación de Arquitecturas Corporativas de Integración SOA Análisis y diseño de servicios y procesos de integración SOA. Elaboración de informes y documentación técnica. Diseño, desarrollo y adaptación de arquitecturas de servicios de infraestructura SOA: Registro, Seguridad, Monitorización, Bus de Servicios Dedicación 100% 100% Titulación Universitaria Superior, preferiblemente en informática Superior, preferiblemente en informática Experiencia 5 años en proyectos de integración aplicaciones en entornos corporativos 5 años en proyectos de integración de aplicaciones y SOA en entornos corporativos Los componentes del equipo de desarrollo deberán contar con conocimientos y/o experiencia en los siguientes entornos y tecnologías: 17
18 Tecnologías de integración java (JCA, JBI, JTA, JMS, ) Tecnologías XML y webservices orientadas a la integración de aplicaciones. Middleware orientado a mensajes (MOM), JMS, MQ s, etc. Entornos de desarrollo de integración de aplicaciones basados en tecnologías J2EE (sobre servidores de aplicaciones o stand-alone) Configuración y adaptación de Registros de Servicios UDDI Arquitectura de aplicaciones en tres capas: J2EE y.net Servidores de aplicaciones: Java (weblogic, tomcat, etc.) e IIS RDBMS: Oracle, SQL-server Herramientas de integración de TIBCO: Business Works, Policy Agent, EMS, Lifecycle Governance y otras herramientas TIBCO de la familia Active Matrix. En el caso del perfil Arquitecto experto TIBCO se exige que tenga acceso a los recursos de ingeniería y soporte del fabricante del software y a sus procesos de resolución de incidencias. 6 Presentación de la Oferta 6.1 Condiciones Generales El importe máximo fijado para la oferta es de euros incluido IVA. Para facilitar la valoración de ofertas, adicionalmente se remitirán en formato electrónico (.doc o.pdf) vía correo electrónico Internet a: ó se adjuntará el soporte físico en el sobre número 2 de la Oferta Económica y Técnica. 6.2 Contenido de la Oferta Técnica La oferta contendrá, al menos, la siguiente información: - Número de jornadas (8 horas diarias) ofertadas por cada uno de los perfiles solicitados, estableciéndose el siguiente mínimo pora el perfil de: o Consultor/Ingeniero de desarrollo: 185 jornadas 18
19 _ Ministerio de Defensa Del perfil a continuación relacionado se ofertarán el siguiente número de jornadas no pudiendo ser estas ampliadas, ya que se consideran suficientes para los trabajos a desarrollar: o Arquitecto Experto TIBCO: 53 - Plan de proyecto detallado de los trabajos a realizar especificados en el apartado 3.5 de este documento, con estimaciones de esfuerzo en cada uno de los entregables solicitados, incluyendo una breve descripción de cada entregable. Madrid, a D'd' de abril de 2009 El Teniente Coronel del ET, Director Técnico, ~L ü~ - Miguel Martin Marcos 19
20 Anexo 1 Glosario de Abreviaturas API BAM BPEL4WS BPM CIS EAI EDA EMAD ESB FAS ftp HTML http IDE IGECIS IIS J2EE JEMACON JEMAD JMS JBI JCA JTA LAN MOM MINISDEF MQ PDCIS PPT RDBMS RMD SMTP SOA SOAP UML UDDI WAN WAN PG WDSL WS XML XSLT Application Programing Interface Business Activity Monitoring Business Process Execution Language for Web Services Business Process Management Sistemas de Información y Comunicaciones Enterprise Application Integration Event Driven Architecture Estado Mayor de la Defensa Enterprise Service Bus Fuerzas Armadas File Transmision Protocol Lenguaje de marcas de hipertexto Hyper Text Transmision Protocol Integrated Development Environment del MINISDEF Internet Information Server Java 2 Enterprise Edition Jefe del Estado Mayor Conjunto Jefe del Estado Mayor de la Defensa Java Messaging Service Java Business Integration J2EE Connector Architecture Java Transaction API Local Area Network Middleware Orientado a Mensajes Ministerio de Defensa Message Queuing Plan Director CIS Pliego de Prescripciones Técnicas Sistema Gestor de Bases de Datos Relacionales Registro de Metadatos de Defensa Simple Mail Transmisión Protocol Service Oriented Architecture Simple Object Access Protocol Unified Modelling Language Universal Description, Discovery & Integration Wide Area Network WAN de Propósito General (entorno de producción de sistemas de información corporativos del MINISDEF) Web Services Description Language Web services extensible Markup Language extensible Stylesheet Language Transformation 20
EXPEDIENTE 1.00.40.10.1580
PLIEG DE PRESCRIPCINES TÉCNICAS PARA LA ADQUISICIÓN DE MÓDUL SFTWARE PARA AMPLIAR CAPACIDADES DE LA PLATAFRMA SA EXPEDIENTE 1.00.40.10.1580 INSPECCI~N GENERAL CIS índice 1. BJET... 1 2. ANTECEDENTES...

References: artículo 41
 artículo 43
 resolución 
 Resolución 
 Resolución 
 resolución