pliego de condiciones técnicas -...

Pliego de Condiciones Técnicas

41-0021/03

Soporte y administración del entorno administrado de

Webfocus ( Portal e Infoassist ) y desarrollo de

aplicaciones de Datawarehouse y Business Intelligence

Julio/2016

DIRECCIÓN GENERAL FINANCIERA Y CORPORATIVA

DIRECCIÓN DE SISTEMAS Y TECNOLOGÍAS DE LA INFORMACIÓN

41-0021/03 –

Soporte y administración del entorno administrado de Webfocus (Portal e Infoassist) y desarrollo de

aplicaciones de datawarehouse y business intelligence

Vers. 1

Fecha 04-07-2016

Pags. 39

Pliego de Condiciones Técnicas 2

Hoja de Control

Título 41-021/03 -Soporte y administración del entorno administrado de Webfocus

(Portal e Infoassist ) y desarrollo de aplicaciones de datawarehouse y business

intelligence

Autor

Versión Fecha Versión

Revisado por Fecha Revisión

Aprobado por Fecha Aprobac.

Control de Cambios

Versión Fecha Autor Descripción

41-0021/03 –



Vers. 1

Fecha 04-07-2016

Pags. 39


Control de Distribución

Distribuido a Área / Departamento Nº Copias

ELABORADO REVISADO APROBADO

Fdo:

Fecha:

Fdo:

Fecha:

Fdo:

Fecha:

41-0021/03 –



Vers. 1

Fecha 04-07-2016

Pags. 39


Tabla de Contenidos

1. ANTECEDENTES E INTRODUCCIÓN ......................................................................................... 5

2. OBJETO ............................................................................................................................................... 5

3. REQUERIMIENTOS Y ALCANCE .................................................................................................. 6

3.1. REQUERIMIENTOS FUNCIONALES Y ALCANCE ................................................................... 6

3.2. REQUERIMIENTOS TECNOLÓGICOS ...................................................................................... 10

3.3. OTROS REQUERIMIENTOS ........................................................................................................ 11

4. EJECUCIÓN Y GESTIÓN DEL PROYECTO .............................................................................. 12

4.1. METODOLOGÍA .............................................................................................................................. 13

4.2. ORGANIZACIÓN ............................................................................................................................ 13

4.3. EJECUCIÓN ..................................................................................................................................... 13

4.4. EQUIPO DE TRABAJO .................................................................................................................. 14

4.5. PERIODO DE GARANTÍA ............................................................................................................ 15

4.6. FORMACIÓN Y GESTIÓN DEL CAMBIO ................................................................................. 16

5. OTRAS CONSIDERACIONES ..................................................................................................... 17

ANEXO I. ESTÁNDARES TECNOLÓGICOS DE TI ................................................................................................... 18

ANEXO II. ESTÁNDARES DE ARQUITECTURA ...................................................................................................... 27

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39

Pliego de Condiciones Técnicas- 5

1. ANTECEDENTES E INTRODUCCIÓN

La Dirección de Sistemas y Tecnologías de la Información (DSTI) de ADIF tiene encomendada, como

parte de sus funciones, el mantenimiento y desarrollo de las aplicaciones de Sistemas de

Información. El conjunto de estas aplicaciones utilizan diferentes tecnologías y dan respuesta a

diferentes áreas de la empresa. En concreto, un subconjunto de estas aplicaciones se enmarca

dentro de la categoría de Business Intelligence, desarrolladas principalmente con tecnología

WebFocus.

Para la realización de nuevos desarrollos y prestar soporte a los usuarios finales de la herramienta

de Webfocus/Infoassist/Portal, ADIF necesitaría disponer de un servicio que permita, a través de la

DSTI, evolucionar sus sistemas de BI, tanto funcional como tecnológicamente, permitiendo:

• Dotar en todo momento al negocio de la capacidad de adaptación y crecimiento requerida

para sus Sistemas de Información de BI.

• Colaboración en el desarrollo del entorno a utilizar por las herramientas de autoservicio.

• Soporte y ayuda a los usuarios que utilicen la herramienta de autoservicio Infoassist

instalada en ADIF incluyendo la colaboración parcial en sus proyectos como consultor

• Soporte y ayuda a los usuarios que utilicen la herramienta de autoservicio Developer

Studio/App Studio instalada en ADIF incluyendo la colaboración parcial en sus proyectos

como consultor

• Colaboración en el desarrollo de un entorno informacional de ADIF que aísle la generación

de información de los entornos productivos de ADIF

• Garantizar la correcta evolución de los Sistemas de Información de BI, asegurando una

adecuada transferencia de conocimiento que facilite el mantenimiento futuro.

2. OBJETO

El objeto del presente servicio es la ejecución de todas las tareas necesarias para cubrir las

necesidades del negocio a nivel informacional ya sea mediante el desarrollo de nuevas aplicaciones

como a través de la implantación y fomento del uso de la herramienta de autoservicio de informes,

Dichas actividades estarán siempre bajo la supervisión del personal responsable de ADIF.

ADIF, en función de la necesidad plateada, demandará un perfil marcado por una doble vertiente

de conocimientos:

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


- Conocimientos funcionales dentro del área de BI y capacidad de desarrollo de aplicaciones

analíticas

- Dominio de la arquitectura y herramientas usadas dentro de ADIF en el área de BI.

Los sistemas a desarrollar, en su mayoría estarán basados en acceso a bases de datos relacionales

de diferente tipo (DB2, Oracle, ODS de SAP, etc.) y la presentación de información será a través de

las herramientas de BI utilizadas en ADIF.

Por lo tanto han de garantizarse los siguientes objetivos operativos:

- Establecer el soporte adecuado a todos los usuarios del sistema de autoservicio de informes.

- Colaboración en la promoción y desarrollo de aplicaciones analíticas dentro del ámbito de

BI

- Soporte en la gestión del entorno administrado de Webfocus, Portal e Infoassist

- Desarrollo de aplicaciones en el ámbito de la inteligencia de negocio que aporten valor a los

usuarios de los diferentes departamentos de ADIF

- Cualquier otra tarea que entre dentro del normal desarrollo de las tareas de desarrollo de

software de BI/DW.

3. REQUERIMIENTOS Y ALCANCE

En este apartado se detalla cada una de las acciones que son objeto del servicio solicitado en el

presente pliego.

3.1. REQUERIMIENTOS FUNCIONALES Y ALCANCE

Dentro del Servicio se distinguirán dos tipos de tareas, por un lado el desarrollo de soluciones a

medida que cubra las necesidades de los usuarios en el área informacional o de análisis de

información, y por otro el diseño, la configuración y el soporte del Entorno Administrado de

WebFOCUS, Portal e InfoAssist.

Dentro de la primera podemos señalar las siguientes tareas :

1. Desarrollo y carga del modelo de información para consultas ad-hoc de inversiones

Basándose en el Centro de Información de Inversiones actual (CII) se deberá diseñar y cargar

un modelo de datos especifico para las consultas ad-hoc que garantice una rápida

respuesta. Para medir este tiempo se utilizaran las consultas que se están realizando

actualmente y que servirán de base en la construcción del modelo

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


2. Nueva aplicación informacional sobre el DW del registro material rodante ferroviario

Desarrollo de una herramienta de generación de informes sobre la nueva estructura de

datos DW REF

3. Desarrollo solución para auditoría interna

Dotar de una herramienta dentro de infoassist/Portal para que el departamento de

Auditoría interna pueda explotar y analizar la información proporcionada por las diferentes

direcciones de la empresa

4. Desarrollo centro de información específico para Inversiones Alta Velocidad

Generar una nueva herramienta para poder explotar la información específica sobre las

inversiones de alta velocidad. Dicha herramienta permitirá explotación de informes a

medida junto con la posibilidad de diseño de informes ad-hoc

5. Desarrollo de propuestas y demos para incentivar el uso de cuadros de mando y otras

aplicaciones de componente analítico dentro de ADIF

Se diseñaran aplicaciones piloto que muestren al usuario como la tecnología BI puede

ayudarles en los procesos de toma de decisión ayudándoles a transformar la información en

conocimiento

6. Soporte en la creación de nuevos Data Marts

El equipo de BI deberá analizar las diferentes estructuras de datos residentes en el Centro

de Información para poder establecer relaciones entre ellas. Estas relaciones deberán

publicarse para que cualquier equipo de desarrollo pueda hacer uso de ellas.

En el momento de la creación de un nuevo Data Mart por parte de cualquier departamento

de Adif dentro del paraguas de la Dirección de Sistemas de Información, se analizará la

posibilidad de obtención de parte de la información en los sistemas ya existentes. Además

se establecerán las relaciones entre la nueva información incorporada con la ya residente.

El objetivo es dotar a Adif de los instrumentos necesarios para evitar la repetición de

información dentro del sistema Data Warehouse dependiente de la Dirección de Sistemas de

Información

7. Creación Sistema Informacional PIDAME, GAM, GII

Para liberar a la parte operacional de dichas aplicaciones de la carga que supone las

consultas para obtener información, se deberá realizar un modelo de datos DW y desarrollar

una herramienta de generación de informes. Se deberá valorar el uso de Infoassist/Portal.

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


8. Desarrollo de otras aplicaciones BI

Se deberá realizar el análisis previo de las peticiones de desarrollo de aplicaciones BI y si

así se decidiera por ADIF abordar fases posteriores del desarrollo.

Dentro del segundo trabajo que entraría dentro del alcance del servicio podríamos diferenciar las

siguientes tareas:

1. Configuración y Administración del Entorno Administrado (Infoassis/Portal)

Se realizarán las tareas o se dará soporte al equipo definido por ADIF en cuestiones relativas

a:

- Creación de elementos comunes a la infraestructura del Portal.

- Creación y gestión de Usuarios, Grupos y Roles.

- Asignación de reglas de accesos a los contenidos.

- Uso de Plantillas.

- Adaptación de las opciones de seguridad y explotación para alcanzar los

requerimientos establecidos.

- Uso de utilidades para resolución de problemas y gestión del modelo de seguridad.

2. Creación de los elementos del entorno administrado

Se realizarán las tareas o se dará soporte al equipo definido por ADIF en cuestiones relativas

a:

- Uso del Interface del Portal, creación de un Portal, uso de propiedades, gestión de la

seguridad.

- Interrelación del Portal con AppStudio/Developer.

- Cuadros de Mando: creación de cuadros de mando, generación de componentes –

gráficos, informes-. Asignación de estilos nuevos o predefinidos. Reutilización de

componentes.

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


- Creación, publicación y uso de Objetos de Informe: Opciones de Pre y Post proceso,

Filtros y Selecciones, Informe y Gráficos asociados.

- Creación y uso de Metadatos.

Generación y edición de sinónimos (MASTER) desde las herramientas de

desarrollo.

Creación de campos virtuales en los sinónimos.

Uso de filtros e implementación de seguridad en los sinónimos.

Referencias cruzadas en los sinónimos.

Creación de vistas de negocio.

- Empleo de técnicas eficientes para el acceso a fuentes relacionales

3. Soporte a usuarios finales y a administradores en la utilización y en la gestión del

entorno y en la utilización de herramientas de desarrollo de BI

- Soporte general al uso del Portal de WebFOCUS, de los Cuadros de Mando y resto de

elementos del entorno administrado.

- Prestar soporte y ayuda a especialistas en BI de otras áreas de ADIF en el uso de la

herramienta Developer Stupio/App Studio.

- Soporte e intermediación respecto de las peticiones de información, tablas, datos,

informes de los usuarios de las áreas de negocio al área informática de ADIF.

- Soporte específico en el uso de InfoAssist: resolución de consultas acerca de la

utilización de la herramienta y de las estructuras de datos definidas.

Uso del interface de InfoAssist.

Creación, organización y publicación de contenido propio (informes y

gráficos).

Uso de filtros propios y predefinidos.

Creación de campos virtuales.

Empleo de técnicas de ranking, subtotalización, medias…

Ampliar la funcionalidad de los informes (creación de Drilldown, uso de

informes activos).

Combinación de Fuentes de información en una única fuente.

Creación de formatos de salida: Excel, PDF, TOC, acordeón, plano….

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


Generación de gráficos. Selección del tipo gráfico según problemática a

representar, uso de las distintas opciones del asistente, creación de

drill-downs, uso de HTML5.

Creación / Uso de Objetos de Informe.

Metadatos: interpretar su contenido, su influencia en el resultado de los

informes.

Criterios de eficiencias de acceso a fuentes relacionales.

Generación de uso posterior de ficheros intermedios (HOLD)

Incorporación y uso de tecnologías activas.

- Soporte a los Administradores de Sistemas:

Monitorización y gestión de los procesos del entorno administrado.

Activación y exploración de trazas.

Uso de ficheros de configuración, variables y comandos (APP comands).

Creación de sinónimos en enriquecimiento de los mismos.

3.2. REQUERIMIENTOS TECNOLÓGICOS

El adjudicatario se compromete a desarrollar el/los Sistemas de forma que:

Puedan explotarse en las instalaciones del Centro de Proceso de Datos de ADIF.

Cumplan los estándares actuales de arquitectura y tecnología definidos por ADIF con

capacidad de adaptación a sus evoluciones.

Cumpla las métricas de calidad de código y buenas prácticas de codificación definidas en

ADIF.

Cumpla los requisitos de seguridad de ADIF.

Cumpla los niveles mínimos de rendimiento establecidos por ADIF.

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


Por lo tanto, deben cumplirse los siguientes estándares de ADIF:

- Estándares tecnológicos (Anexo I).

Recoge los requisitos técnicos en cuanto a servidores, unidades de almacenamiento,

sistemas operativos, etc.

- Estándares de arquitectura de sistemas (Anexo II).

Contiene los requisitos arquitectónicos para cada tipo de solución o producto presente

en ADIF, y utilizable dentro del entorno de esta licitación.

Las soluciones técnicas deberán ceñirse a soluciones basadas en los productos implantados en la

actualidad o en la evolución de los mismos que ADIF establezca y que siga las recomendaciones de

arquitectura aquí referidas, salvo que exista una justificación expresa para lo mismo o se considere

que es la mejor alternativa.

3.3. OTROS REQUERIMIENTOS

Otros requerimientos que debe cumplir el Sistema son los siguientes:

Integración con otras aplicaciones.

Cuando sea necesario realizar la integración del Sistema con otras soluciones, deberán

seguirse las políticas y estándares existentes en ADIF para tal fin.

Componentes Reutilizables.

Cuando se detecta que una funcionalidad que se está desarrollando para un nuevo Sistema

puede ser útil para futuros desarrollos, se requiere que dicha funcionalidad se implemente

de forma que pueda ser reutilizada en el futuro. De este modo, actualmente se cuenta con

una serie de funcionalidades y servicios estándar en ADIF. Por este motivo:

- Si alguna funcionalidad del desarrollo objeto de este pliego puede ser cubierta con

algún componente estándar ya existente en ADIF, el proveedor tendrá que usarlos

obligatoriamente, de forma que se mantenga la homogeneidad en todos los

desarrollos, con el objetivo de favorecer y facilitar su mantenimiento futuro.

- Si durante el desarrollo se detectan funcionalidades susceptibles de ser reutilizadas en

el futuro, el proveedor deberá implementarlas obligatoriamente cumpliendo los

estándares de ADIF para su reusabilidad futura.

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


Estándares y pruebas.

Con el objetivo de verificar el cumplimiento de los estándares de ADIF, el software recibido

será examinado para comprobar que cumple la arquitectura de ADIF, los requisitos de

seguridad y calidad y que su rendimiento es el esperado, realizando para ello las pruebas

necesarias definidas por ADIF. Si el software no cumple alguno de estos requisitos, se

rechazará la entrega. El contenido y alcance de las pruebas será comunicado al

adjudicatario al inicio del proyecto.

El equipo técnico.

a. Perfiles y Roles:

o Consultores Funcionales en el ámbito DW/BI.

b. Conocimientos Técnicos

o Amplia experiencia en la utilización de WebFocus como herramienta BI.

o Experiencia o formación demostrable con la herramienta Infoassist-Portal tanto

a nivel de desarrollo como a nivel administración

o Experiencia o formación demostrable en Developer studio/APP studio

o Experiencia en las Bases de Datos Relacionales DB2 y Oracle, así como las

herramientas de mantenimiento propias de cada una.

Transferencia de conocimiento.

El adjudicatario deberá realizar la transferencia del conocimiento del sistema al responsable

del mantenimiento, en la forma y momentos establecidos por ADIF.

4. EJECUCIÓN Y GESTIÓN DEL PROYECTO

El desarrollo de los trabajos se adecuará de forma general a los siguientes aspectos metodológicos y

organizacionales, salvo que entre el adjudicatario y ADIF se establezca otra forma de actuar al inicio

del proyecto.

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


4.1. METODOLOGÍA

De forma general, las tareas objeto del presente contrato deberán realizarse en el marco de la

metodología, procesos, herramientas de gestión y plantillas de documento de ADIF, las cuales serán

establecidas al inicio de los trabajos entre ADIF y el adjudicatario.

En este sentido, el adjudicatario se obliga a usar la metodología establecida por ADIF, que si bien es

una metodología propia, está basada en referentes estándar de mercado. Por lo tanto, el

adjudicatario deberá entregar toda aquella documentación técnica y de gestión del proyecto

contemplada en la citada metodología, así como cualquier documentación adicional que, a juicio

del Director Técnico del proyecto de ADIF, sea necesaria para alcanzar los objetivos del proyecto en

cada momento.

Así mismo, el adjudicatario se compromete a realizar y facilitar la información de planificación y

seguimiento del proyecto tal como se establezca por ADIF y el adjudicatario al inicio del mismo.

No obstante, al inicio del proyecto se establecerá entre ADIF y el adjudicatario todos los aspectos

metodológicos relevantes.

4.2. ORGANIZACIÓN

La organización, gobierno, control y seguimiento del proyecto será la establecida por ADIF (Anexo V).

El proveedor deberá ceñirse a dicha estructura.

Cualquier otra propuesta, no será tenida en cuenta en la valoración de la oferta, pero podrá ser

evaluada tras la adjudicación del contrato por parte de ADIF junto con el adjudicatario,

reservándose ADIF la potestad de aceptarla o rechazarla.

4.3. EJECUCIÓN

Los trabajos se llevarán a cabo por norma general en las oficinas de ADIF. El adjudicatario deberá

disponer de la infraestructura técnica (equipos portátiles, comunicaciones, hardware y software)

adecuada para poder desarrollar los trabajos contenidos dentro del alcance del presente pliego.

Además, todos los costes de la mencionada infraestructura serán a cargo del adjudicatario, estando

incluidos en el precio de la oferta. No obstante, tras la adjudicación del contrato, y antes del inicio

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


del proyecto, ADIF y el adjudicatario podrán establecer otra forma de relación diferente, siempre

cumpliendo la normativa legal vigente en esta materia.

El adjudicatario se encargará de realizar todas las tareas necesarias y disponer de los mecanismos

suficientes para el desempeño adecuado de su actividad.

La jornada de trabajo será de lunes a viernes, de acuerdo con los horarios que se establezcan en

ADIF.

Durante los trabajos realizados, el licitador se basará en su experiencia para recomendar a ADIF los

cambios en los procesos actuales que beneficien su gestión y la calidad del servicio ofrecido.

No se aceptarán costes adicionales por el uso de activos cuya propiedad intelectual corresponda al

licitador ni por servicios asociados a la implantación de la solución, propios o de terceros.

Si por algún motivo excepcional, alguna tarea dentro de la actividad asignada, requiere una

ejecución fuera de horarios típicos de oficina, el adjudicatario se compromete a llevar a cabo dichas

tareas, sin que esto suponga un sobrecoste para el proyecto.

Así mismo, el adjudicatario deberá garantizar un período post-implantación suficiente para dar

soporte a la puesta en marcha de la solución, incluyendo en su oferta tanto la duración como los

servicios ofrecidos en el mismo.

4.4. EQUIPO DE TRABAJO

La empresa adjudicataria aportará un equipo de trabajo configurado por cuantos técnicos de

adecuada cualificación y nivel de dedicación estime necesarios para la realización de los trabajos.

No obstante, para la realización de los servicios descritos anteriormente se considera recomendable

un equipo de trabajo compuesto, como mínimo, por los siguientes perfiles:

Perfil Tecnología Horas / año

Consultor Senior/Funcional DataWareHouse – Webfocus

Infoassist/Portal – Developer Studio

3.400

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


El equipo técnico ofrecido deberá ser lo suficientemente autónomo como para desarrollar sus

actividades requiriendo el apoyo de técnicos de ADIF únicamente de forma puntual. No obstante,

ADIF ofrecerá la información y soporte necesarios para el cumplimiento de dichas obligaciones.

El cambio del personal técnico que preste sus servicios sólo se realizará por causas mayores

debidamente documentadas y requerirá las siguientes condiciones:

- Justificación escrita, detallada y suficiente, explicando el motivo que suscita el cambio, con

una antelación mínima de quince días.

- Presentación de posibles candidatos con un perfil de cualificación técnica igual o superior al

de la persona que se pretende sustituir.

- Aceptación de los candidatos por parte del Director del Proyecto.

4.5. PERIODO DE GARANTÍA

El adjudicatario deberá garantizar por un período no inferior a 6 meses, a contar desde la fecha de

recepción de conformidad por parte de ADIF de los productos derivados de la presente contratación,

obligándose a realizar durante dicho período todos los cambios, revisiones, asistencia necesaria

para solventar las deficiencias detectadas e imputables al mismo (tanto en código fuente como la

documentación del proyecto, manuales, etc.) sin coste adicional alguno para ADIF.

En todo caso, el adjudicatario es el responsable del correcto funcionamiento del sistema en todo

momento, con independencia de las garantías que hayan ofrecido los proveedores de otros

productos integrados en el mismo.

Las empresas licitantes deberán especificar en sus respectivas ofertas el plazo máximo en horas (a

contar desde la fecha/hora de comunicación de la incidencia por parte de ADIF) al que se

comprometen para la atención de las incidencias detectadas durante el período de garantía.

Asimismo deberán especificar el plazo máximo en horas (a contar desde la fecha/hora de

comunicación de la incidencia por parte de ADIF) al que se comprometen para la resolución de la

incidencias detectadas, en las mismas condiciones que durante el período de vigencia del contrato.

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


En cualquier caso estos tiempos no serán superiores a:

- 4 horas naturales para el plazo de atención.

- 48 horas naturales para el plazo de resolución.

El incumplimiento durante el período de garantía de cualquiera de estos plazos (o de los ofertados

si fueran mejores) en cualquier incidencia, será penalizado aplicando las condiciones recogidas en

el Pliego de Condiciones Generales de Servicios de ADIF.

Así mismo, el número de incidencias que se detecten tras la entrega de los productos implicados y

durante el período de garantía serán registradas por ADIF y podrán ser tenidas en cuenta

negativamente para la solvencia técnica y profesional del adjudicatario en futuras licitaciones.

4.6. FORMACIÓN Y GESTIÓN DEL CAMBIO

El proveedor incluirá en su oferta el plan de formación, entendiendo como tal las actividades

necesarias para realizar el traspaso de conocimientos, tanto en su vertiente funcional, a los usuarios

responsables de la explotación de la solución, como técnica, a los equipos responsables del

mantenimiento posterior del sistema. Estos últimos, participarán puntualmente durante el

proyecto, con el objetivo de minimizar el impacto posterior.

Así mismo, durante el período de garantía, los equipos de mantenimiento de Adif y el adjudicatario

deberán mantener sesiones puntuales de revisión de peticiones / incidencias acometidas durante

dicho período.

Se deberá incluir el plan de gestión del cambio en la organización, si aplica, de modo que se

mitiguen lo más posible los riesgos derivados de la implantación del nuevo sistema.

La empresa adjudicataria colaborará con ADIF, a fin de coordinar, desde el inicio del proyecto, la

preparación, diseño, calendario, metodología y contenidos de la formación a impartir, para

garantizar su planificación y prever y subsanar las posibles dificultades o necesidades que se

deriven del proyecto.

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


Por lo tanto, todas las actividades tanto formativas, como de gestión del cambio y transferencia del

conocimiento, se recogerán en un plan detallado de comunicación que deberá incluirse en la oferta

con el fin de su valoración por parte de ADIF.

5. OTRAS CONSIDERACIONES

Idioma de la prestación del servicio.

Tanto el servicio como toda la documentación generada en el mismo será facilitada en castellano,

utilizando formatos electrónicos de uso común (Word, Pdf, etc.)

Control de Calidad

La calidad del servicio contratado se controlará fundamentalmente a través del seguimiento del

grado de cumplimiento de los hitos establecidos. No obstante, ADIF podrá establecer controles de

calidad sobre la actividad desarrollada y los productos obtenidos. Dichos controles serán

comunicados a la empresa adjudicataria con la antelación suficiente para su correcta observancia.

Guía de estilos

Los trabajos desarrollados seguirán las guías de estilos definidas por ADIF. A tal efecto, antes de

iniciar el proyecto, dichas guías serán entregadas al adjudicatario del contrato, y su seguimiento y

cumplimiento serán obligatorios para la aceptación de los trabajos, salvo que la Dirección Técnica

de ADIF establezca lo contrario.

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


ANEXO I. ESTÁNDARES TECNOLÓGICOS DE TI

1. INTRODUCCIÓN

La plataforma tecnológica del Centro de Proceso de Datos (CPD) de la Dirección de Sistemas

y Tecnologías de la Información forma el marco de referencia sobre el que se basan los

distintos sistemas de información, aplicaciones y demás servicios relacionados con las TIC

que esta proporciona a Adif.

La plataforma establece un catálogo de servicios, productos y tecnologías que conforman la

instalación del CPD en su objetivo de ofrecer el mejor rendimiento, flexibilidad y

disponibilidad a los sistemas y aplicaciones que se alojan en el mismo.

El objeto del presente documento es dar a conocer los estándares tecnológicos corporativos

determinados en el Plan Director de Sistemas de Adif y que sirva de guía para la elección

de la infraestructura de los proyectos que surjan fuera de la DSTI para que de este modo

puedan adaptarse a la arquitectura del Centro de Proceso de Datos.

La arquitectura elegida como estándar en el CPD se apoya en las siguientes soluciones:

Virtualización. La adopción de la virtualización como tecnología proporciona

fiabilidad, escalabilidad y una mayor optimización de los recursos. Permite,

asimismo, tener capacidad de adaptación y agilidad para acometer proyectos al

mismo tiempo que provee de las herramientas para facilitar la administración y

gestión de los recursos y servicios de una forma más eficiente.

Consolidación de servidores y almacenamiento, reduciendo la complejidad fruto de

una diversificación descontrolada de la instalación y permite conseguir un grado de

especialización suficiente que permita afrontar retos futuros. La consolidación

permite igualmente una mejor eficiencia energética en el centro de proceso de

datos.

Alta disponibilidad que abarca todos los niveles de la plataforma, con hardware

tolerante a fallos, redundancia, empleo de tecnologías clúster tanto de sistemas

como de aplicaciones, balanceo de carga, etc.

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


2. MAPA DE SERVIDORES – CPD PRINCIPAL Y CPD DE RESPALDO

Existen dos centros de proceso de datos, el principal y el secundario donde los datos se

encuentran replicados con conexiones de Fibra Óptica a través de DWDM.

En la instalación conviven sistemas de producción basados tanto en sistemas Mainframe

de IBM con z/OS como Distribuidos (Windows, Unix, Aix, Linux), siendo la utilización de

virtualización de servidores basados en S.O. Linux la recomendación como solución de

referencia en todos aquellos sistemas donde sea posible, procurando limitar el uso de

servidores basados en Windows a los casos estrictamente imprescindibles, todos ellos

basados en arquitectura Blade. Del mismo modo, se posibilita el uso de servidores Unix en

los casos en que no sea posible utilizar tecnología anterior.

Los datos se encuentran en distintos sistemas sistemas de almacenamiento en función del

origen de los mismos (Mainframe/Sistemas Distribuidos), utilizando la tecnología de

conexión a los mismos más óptima para cada caso de uso (SAN/NAS) y el tipo de disco más

apropiado para cada aplicación (FC/SATA).

Para las aplicaciones que requieren de las mayores prestaciones, en acceso y/o

transferencia, existen cabinas de discos FC conectadas a una red SAN de alto rendimiento

que, a través de switches directores, llega a los distintos chasis de servidores a través de

conexiones de fibra óptica. El almacenamiento de la SAN se encuentra respaldado en el

CPD secundario mediante réplica síncrona. Para aquellas aplicaciones que precisan de gran

volumen de almacenamiento se dispone de cabinas de tecnología NAS con discos SATA de

alta capacidad unidas a los servidores a través de conexiones de red, y los datos se

encuentran respaldados en el CPD secundario mediante réplica asíncrona.

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


3. ESQUEMA LÓGICO DE ENTORNO DISTRIBUIDO

A continuación se muestra el esquema lógico del entorno distribuido.

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


4. PRODUCTOS

4.1. SERVIDORES - HARDWARE.

La línea de hardware principal de proceso se basa en sistemas x86 Intel y AMD de 64 bits

multicore, concentrados en chasis de servidores Blade. Esta tecnología permite concentrar

un número elevado de servidores en un chasis que proporciona los servicios de red,

alimentación, conectividad FC para almacenamiento externo, gestión, etc., de modo

centralizado, ofreciendo las condiciones de fiabilidad, robustez y versatilidad que

requieren instalaciones de este tipo.

En aquellos casos que las características del producto y/o aplicación impidan utilizar la

tecnología anterior, la instalación acepta servidores con otras arquitecturas (p.ej. Unix),

siempre que esté justificado por los requisitos del proyecto en cuestión.

Una relación detallada de los servidores hardware existentes en ambos CPDs se puede

consultar en el documento “Informe de Hardware”.

4.2. VIRTUALIZACIÓN.

Para la virtualización en los entornos x86 se está usando Virtual Infrastructure de Vmware.

Existen diferentes Datacenters utilizando actualmente la 4.1 (VMware ESXi) en cinco de

ellos y uno con versión 5.0.0, estando en estudio la actualización de todos ellos a la

versión 5.5

Estas tecnologías permiten disfrutar entre otras ventajas de:

● Fiabilidad y tolerancia a fallos.

● Optimización de los recursos.

● Disminución del tiempo de despliegue.

4.3. SISTEMAS OPERATIVOS.

En arquitectura x86 se utiliza Linux como sistema operativo de referencia, siendo la

distribución elegida Novell SLES11 y en algunos casos RedHat 5.x. Igualmente actualmente

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


existen servidores con SLES10. Cuando se precisa utilizar Windows como sistema operativo,

la versión de referencia actual es la 2008 Server R2.

La línea a seguir, es que siempre que la aplicación o el producto lo permitan se instale en

Linux, optando por Windows cuando no exista solución Linux.

Linux ha demostrado ser un sistema robusto y fiable preparado absolutamente para

cualquier tipo de carga, desde servicios de infraestructura a grandes bases de datos, y por

supuesto, pionero en todas aquellas cargas relacionadas con Internet.

4.4. ALMACENAMIENTO DE DATOS.

Los datos se encuentran consolidados en sistemas de almacenamiento de varios

fabricantes y tecnologías para atender las distintas necesidades de los sistemas a los que

prestan servicio.

Se dispone de una cabina de discos DS8300 de IBM y otra VSP de Hitachi que proporcionan

almacenamiento de alto rendimiento y dos switches director 48000 (arquitectura Brocade)

que junto con los switches de los Chasis de servidores Blade conforman una red SAN que

da servicio a los sistemas distribuidos. Del mismo modo se dispone de una cabinas de

discos de alta capacidad VNX de EMC2 y FAS3240 de NetApp.

También se dispone de una librería de cintas LTO conectada a esta red SAN para backup y

archivado.

Como herramienta de backup disponemos de Tivoli Storage Manager (TSM) con la que se

tiene una amplia experiencia.

Los datos se encuentran replicados en el centro de respaldo con conexiones F.O. a través

de DWDM. La cabina DS8300 con réplica síncrona y la cabina Clariion con réplica asíncrona.

Las cintas LTO se copian en una librería idéntica en el centro de respaldo.

Existen dos modelos de backup, uno que afecta a la virtualización y mantiene copia bare

metal de todas las máquinas virtuales.

El procedimiento de backup estándar mantiene las tres últimas versiones distintas a nivel

de fichero. Con políticas adecuadas a cada caso para el resto de sistemas, BBDD, SAP,

correo, etc.

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


Finalmente, se dispone de la herramienta de archivado Symantec Enterprise Vault. Su

objeto es guardar en un almacenamiento secundario, de mayor capacidad pero más

económico. aquellos archivos almacenados en red y correos residentes en el servidor que

lleven largo tiempo sin haber sido accedidos. De este modo se recupera espacio en

almacenamiento de disco de primer nivel al tiempo que se salvaguarda la información del

usuario.

4.5. BASES DE DATOS Y SERVIDORES DE APLICACIONES.

Las bases de datos soportadas son:

● DB2 v9.1 en z/OS al que se puede acceder desde sistemas linux y windows

mediante db2 connect para aquellas aplicaciones que tengan que acceder a datos

consolidados en el mainframe.

● Oracle 10g y 11g en Linux y Aix.

● Microsoft SQL Server 2005 en cluster Windows, con el objeto de dar servicio a

aquellas aplicaciones y productos que solamente soportan esta base de datos.

Como monitor de teleproceso en el entorno z/OS se está utilizando IMS.

Actualmente se mantiene DB2 para dar servicio a aplicativos ya desarrollados y que

utilizan esta base de datos. Para nuevos desarrollos, se ha optado por Oracle como base de

datos de referencia.

Para el servicio de correo, colaboración, y aplicaciones afines se opta por Domino como

solución global, utilizando también Sametime como herramienta de mensajería

instantánea.

Como servidor de aplicaciones java se está utilizando WebSphere Application Server y

también se acepta la utilización de Tomcat 7.x y 8.x.

Como sistemas de gestión de portales y contenidos web se dispone de WebSphere Portal

Server o de Liferay.

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


4.6. GESTIÓN DOCUMENTAL

La familia de productos a utilizar para soluciones de gestión documental es documentum

de EMC2, la versión en producción es la 6.7 SP1. También, en los proyectos basados en

Liferay se utiliza el gestor documental que incluye este producto.

4.7. ERP

Para los departamentos financieros y RRHH está implantado SAP con los módulos R3, BI,

Portal, XI, usando Real Estate para la gestión de locales por parte de Estaciones.

4.8. SOA

Dentro del proyecto de SOA se han definido las herramientas para ESB y Registry siendo

elegido el software de la familia WebSphere de la empresa IBM.

4.9. VIRTUALIZACIÓN DEL PUESTO DE TRABAJO

La plataforma Citrix proporciona la tecnología para proporcionar acceso a aplicaciones

(XenApp) de forma remota y segura. Las aplicaciones residen en servidores del Datacenter y

son accesibles bajo demanda desde cualquier dispositivo y cualquier localización.

La virtualización de las aplicaciones permite la centralización de los mismos junto con la

consolidación de la información, con las consecuentes ventajas de disponibilidad y

seguridad que ofrece el CPD.

4.10. ESTADÍSTICAS WEB

Se utiliza Urchin como herramienta para el estudio de accesos a las páginas Web. Realiza

gráficos y estadísticas de los accesos que hacen los usuarios a las páginas Web con

posibilidad de exportarlos a xml y csv.

4.11. OTRAS HERRAMIENTAS

Para el proceso de la información y su explotación para informes, cuadros de mando, data

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


mining, etc., se dispone de WebFOCUS e IWay.

Para la gestión del ciclo de vida del software (control de versiones, entornos, etc.)

desarrollado en Adif, la herramienta utilizada es HARVEST.

Para la automatización de procesos y scheduling CONTROL-M.

La gestión de procesos de cambio, control de la configuración de los sistemas, gestión de

incidencias y problemas, etc., todos ellos llevados a cabo siguiendo las prácticas

recomendadas por ITIL se realizan utilizando la herramienta REMEDY.

4.12. SOLUCIONES DE MOVILIDAD

La plataforma oficial de movilidad en Adif es BlackBerry, y todos los dispositivos

corporativos de este fabricante están gestionados a través del BlackBerry Enterprise Server

(BES). Esta herramienta facilita la gestión remota de los dispositivos y proporciona la

pasarela de acceso al correo, libreta de direcciones y calendario, así como a otros servicios

corporativos, de manera segura.

Para el resto de plataformas de movilidad (iOS de Apple, Android de Google, Windows

Phone) se dispone de IBM Lotus Notes Traveler, que permite acceder al correo, libreta de

direcciones y calendario de forma segura desde la mayor parte de dispositivos móviles

actuales.

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


ANEXO II. ESTÁNDARES DE ARQUITECTURA

1. Arquitectura JavaEE

En la Dirección de Sistemas de Información se ha definido una arquitectura de referencia

que deberán seguir todas las aplicaciones transaccionales que se realicen. A continuación

se mostrará la arquitectura basada en JavaEE elegida por ADIF, los framework elegidos para

implementar cada uno de los elementos que conforman la arquitectura y los componentes

que conforman dicha arquitectura. El diagrama de contexto de dicha arquitectura es el

siguiente:

Las características y definición de cada capa para ADIF se explica a continuación.

Capa de presentación

Sus principales características son:

• Es la parte de la aplicación que interactúa con el usuario (Interfaz de usuario)

• Contendrá la lógica de presentación de la aplicación

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


• No contendrá código de control o de negocio de la aplicación

El Framework elegidos para crear la capa de presentación es Apache Struts 1 (versión

1.3.10) Para aquellos interfaces que se requiera un grado mayor de dinamismo, también

se podrá utilizar HTML 5 con JavaScript para componer esta capa.

Los componentes para una mejor gestión de la interfaz de usuario son los siguientes:

• Frameworks de JavaScript jQuery v1.7.2

• Componentes de interfaz de usuario jQuery Tools v.1.2.7

• Elementos visuales sobre jQuery jQueryUI 1.10.4

• Grid de presentación de datos sobre jQuery dataTables v1.9.4

• Componentes de generación automática basada en la seguridad de aplicaciones

JavaEE (Aplicación SJA)

Capa de Negocio


Contiene el control del flujo

• Contiene la lógica de negocio.

Para el control del flujo de la capa de negocio, los frameworks elegido son:

Apache Struts 1, versión 1.3.10

Spring MVC v. 4.0.4

Para la lógica de negocio, el framework elegido es Spring Framework (versión 4.0.4).

Los componentes creados para una mejor gestión de la capa de negocio son los siguientes:

• Cargador de Contexto de los ficheros de configuración de Spring.

• Cargador de configuración del fichero de propiedades de log4j.

• Recubrimiento de las excepciones de la capa de negocio: librería AdifException que

se comunica con AdifDAO

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


Capa de acceso a base de datos


• Es la parte de la aplicación que accede a los datos de la aplicación

• Contendrá la lógica de control de acceso a Base de Datos

• No contendrá código de control o de negocio de la aplicación

• Utilizará el patrón de diseño DAO para separar lo máximo posible la lógica de

negocio de la lógica de Acceso a Base de Datos

El framework elegido para crear la capa DAO es MyBatis Data Mapper (versión 3.2.7).

Los componentes creados para una mejor gestión de la capa DAO son los siguientes:

• Librería de recubrimiento de MyBatis (ADIFDao). Esta librería permite:

o Operaciones básicas sobre la Base de Datos (Insert, Update, Delete y Select)

o Inserciones masivas

• Librería de integración con negocio (ADIFNegocio)

• Recubrimiento de las excepciones de la capa DAO

Componentes transversales

Los componentes de ayuda y apoyo a todas las partes de ADIF – Núcleo son los siguientes:

Apache Commons: Proyecto de la fundación Apache cuyo principal objetivo es la

creación de componentes Java Mantenibles y reusables. Las librerías commons

recomendadas son:

commons-beanutils (Versión 1.9.1)

commons-beanutils-core (Versión 1.7.0)

commons-betwixt (Versión 0.8)

commons-digester (Versión 1.7)

commons-codec (Versión 1.9)

commons-compress (Versión 1.8.1)

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


commons-collections (Versión 3.2.1)

commons-dbcp (Versión 1.4)

commons-digester3 (Versión 3.2)

commons-email (Versión 1.3.2)

commons-fileupload (Versión 1.3.1)

commons-io (Versión 1.3.2)

commons-lang3 (Versión 3.1)

commons-logging (Versión 1.1.3)

commons-math (Versión 2.2)

commons-net (Versión 3.3)

commons-pool (Versión 1.6)

commons-validator (Versión 1.4.0)

Logging. Se recomienda el uso de SLF4J (Simple Logging Facade for Java) que nos

proporciona un API de logging a través de un patrón Facade. Se recomienda utilizar

SL4J con la implementación de Log4j. Las librería que necesitaremos serán las

siguientes:

slf4j-api (Versión 1.7.5)

jcl-over-slf4j (Versión 1.7.5)

slf4j-log4j12 (Versión 1.7.5)

log4j (1.2.15)

JasperReports. JasperReports es una librería OpenSource que permite la generación

de informes en formato PDF, HTML, XLS o XML partiendo de una plantilla. La versión

recomendada es 5.5.2

JavaMail. JavaMail es una librería que permite leer, crear y enviar mensajes de

correos electrónicos. La versión recomendada es 1.4.7

JFreeChart. JFreeChart es una librería para la generación de gráficos realizada en

Java. La versión recomendad es 1.0.9

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


Apache POI. Apache POI es un APO de JAVA con la que podemos manipular ficheros

basados en estándares de Office Open XML (OOXML) y documento en formato

Microsoft OLE2. La versión recomendada es 3.10

Spring LDAP. Spring LDAP es una librería de Java para simplificar operaciones contra

LDAP. La versión recomendada es 2.0.1

Xalan. Xalan es una librería que pemite procesar XSLT (XSL Transformation) para

transformar ficheros XML en HTML, ficheros de texto u otro fichero XML. La versión


Apache CXF. Framework OperSource para servicios Web. La versión recomendada es

2.7.11

Jackson JSON Processor. Procesamiento de datos en formato JSON. La versión


Quartz. Job Scheduler. Framework OpenSource que permite integrar en una

aplicación Java planificación de procesos. La versión recomendad es 2.2.1

SJA: Aplicación de ADIF para la gestión de la seguridad en aplicaciones JavaEE.

Plataforma de desarrollo

Existen dos opciones de plataforma de desarrollo que se recomienda para la creación de

aplicaciones JavaEE en ADIF:

Opción 1

o IDE: IBM Rational Software Architect for WebSphere Software v. 8.0.4

o Gestor de versiones: AllFusion Harvest Change Manager v. 7.1.101

Opción 2

o IDE: Eclipse IDE for Java Developers (Versión Eclipse Kepler 4.3.2 SR2)

o Gestor de versiones: AllFusion Harvest Change Manager v. 7.1.101

Generación

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


Se pretende ayudar a los programadores Java a realizar aplicaciones en la nueva

arquitectura propuesta. Las principales funciones que se pretende abarcar son la creación

automática de los artefactos necesarios (clases, ficheros de configuración, paginas JSP,..)

para que una aplicación administre las tablas que componen su Base de Datos, es decir,

controlar las operaciones CRUD en las tablas (Altas, Bajas, Modificación y Consulta). Para

generar todos estos componentes, se podrá utilizar la aplicación ARI. Esta aplicación tiene

como principal función ayudar a los programadores Java a realizar aplicaciones. ARI

permitirá crear automáticamente los componentes necesarios (Paginas JSP, clases Java y

ficheros de configuración) para que una aplicación administre las tablas que la componen,

es decir, controlar las operaciones CRUD en las tablas (Altas, Bajas, Modificación y Consulta)

Elementos Comunes de ADIF

Existen una serie de servicios englobados dentro de la aplicación de arquitectura ECA que

pueden ser utilizados por las aplicaciones. El glosario de servicios que se ofertan

actualmente son:

Servicio LDAP .- Permite autenticarse en LDAP

Servicio de envío de SMS .- Envío de SMS

Auditoría de calidad de código

Para comprobar que los trabajos entregados están correctamente realizados, con los

suficientes comentarios y con la utilización adecuada de todos los Frameworks

recomendados, el equipo de arquitectura realizara pruebas de calidad del código

entregado antes del paso de la aplicación al entorno de preproducción. Para ello, utilizara

la herramienta SonarQube. SonarQube es una herramienta Open Source utilizado para el

estudio de calidad de código de los desarrollos.

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


2. Arquitectura Documentum

En la Dirección de Sistemas de Información se ha definido una arquitectura de referencia

que deberán seguir todas las aplicaciones que se realicen bajo la plataforma de ECM,

Documentum. A continuación se mostrarán las pautas que se deberán seguir y cumplir en

los proyectos que se lleven a cabo en ADIF sobre los siguientes aspectos:

Arquitectura de la documentación

Tipos Documentales y organización de los repositorios documentales

Desarrollo y personalización de aplicaciones

Toda esta información está recogida y publicada en un documento denominado “Libro

Blanco” que será facilitado a todos los responsables de los desarrollos que se vayan a

realizar en ADIF.

De esta manera, cualquier aplicación definida en Adif tendrá un enfoque común, ofrecerá

una mayor facilidad en cuanto a legibilidad y mantenibilidad y será más fácilmente portable y reutilizable.

Los productos de DCTM que componen la plataforma documental de Adif son los siguientes:

Documentum Content Server – Versión 6.7 SP1

Documentum Process Engine Versión 6.7 SP1

Documentum Index Server – Version 6.7 SP1

Documentum Administrator – Versión 6.7 SP1

Documentum WebTop – Versión 6.7 SP1

Documentum TaskSpace – Versión 6.7 SP1

Documentum Composer – Versión 6.7 SP1

Documentum Foundation Classes (DFC) – Versión 6.7 SP1

Documentum Foundation Services (DFS) – Versión 6.7 SP1

Documentum ADTS – Versión 6.7 SP1

Documentum IDS – Versión 6.7 SP2

Documentum Bussiness Activity Monitor (BAM)– Versión 6.7

MS Office

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


DESCRIPCIÓN DE ENTORNOS

Está constituida por tres entornos: Desarrollo, Preproducción y Producción. A continuación

se define el marco general sobre el que se deben desarrollar todas las aplicaciones

siguiendo las directrices marcadas por la Dirección de Sistemas de Información.

NORMA DE DESARROLLO BAJO PLATAFORMA DCTM

A continuación se muestran las normas de parametrización y desarrollo que deben

aplicarse durante la realización de una aplicación sobre plataforma Documentum.

Se podrán realizar desarrollos utilizando los Clientes Estándar de Documentum: WebTop,

Web Publisher y TaskSpace.

Se utilizará el cliente estándar siempre y cuando los cambios a realizar consistan en la

parametrización del cliente, no en desarrollos a medida, salvo que éstos den como

resultado componentes reutilizables por otras aplicaciones DCTM.

No sé podrá utilizar el cliente estándar, bien cuando los desarrollos previstos sean

considerables y entren en conflicto con el comportamiento del cliente estándar o bien

cuando la aplicación estándar exceda las necesidades del cliente ya que obligaría a una

fuerte customización para modificar su comportamiento.

Cuando no sea viable la utilización de cliente estándar se utilizará el Framework de

servicios documentales siendo obligatorio su uso para el desarrollo o la integración de

aplicaciones.

En las integraciones con productos de terceros, se deberán utilizar los conectores

específicos de DCTM para cada uno de ellos. Los productos que deberán utilizar conectores

son:

SAP

LOTUS NOTES

MS OUTLOOK

Web Content Management de IBM

Para Migraciones y procesos batch que se deban realizar de manera puntual, en los que se

realicen cargas de grandes volúmenes de documentación, o se deban programar Jobs, se

deberán utilizar DFCs. En el caso de los Jobs, deberán ser ejecutados bajo el servidor de

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


métodos propio del producto (Java Method Server) con la autorización del la Dirección de

Sistemas de Información. Cuando sean necesarios procesos batch de negocio se utilizará el

Framework de servicios documentales de Adif.

Además de lo anterior, se deberá seguir la normativa del Libro Blanco para los siguientes

puntos:

- Normativa de Repositorios

Las opciones para elegir el tipo de repositorio vienen determinadas por el tipo y las

características de las necesidades. Será ADIF en último término quién especifique el

repositorio a usar.

- Nomenclatura de objetos

Se ha definido una nomenclatura estándar que aplica tanto a los repositorios como

a los distintos objetos que los integran.

- Normativa archivadores y carpetas (dm_folder y dm_cabinet)

- Nomenclatura de tipos de objetos de usuario en los repositorios (tipos

customizados)

- Nomenclatura de atributos

- Nomenclatura de tablas externas

GESTIÓN DE USUARIOS Y GRUPOS

Se deberá tener en cuenta lo establecido en el documento “PLAN DIRECTOR DE SEGURIDAD DE

LA INFORMACIÓN: Especificación de Requisitos de Seguridad”, publicado por la Jefatura de

Seguridad Informática de adif.

En el Libro Blanco se recogen un conjunto de recomendaciones y normas a seguir para la

gestión de usuarios y grupos en el desarrollo de aplicaciones Documentum:

1.- Autenticación de usuarios

En ADIF la autenticación de usuarios se realizará a través del LDAP corporativo de ADIF.

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


2.- Creación de un grupo en documentum

El administrador de cada aplicación deberá encargarse del mantenimiento de los

grupos de usuarios.

3.- Grupos dinámicos

Sólo se permitirán en implementaciones de aplicaciones.

4.- Directrices sobre usuarios y grupos

Descrito en el Libro Blanco

5.- Seguridad en el repositorio y gestión de acl’s

La seguridad por defecto en los repositorios se configurará por carpeta. Podría darse el

caso que fuera conveniente aplicar otro modelo de seguridad por defecto a un repositorio

debido a las características de una aplicación concreta, no obstante debería de ser

aprobado por la DSI.

6.- Seguridad a nivel de repositorio

Con respecto al Modelo de Seguridad Pública, permisos sobre Tablas Registradas y las

directrices de seguridad de objetos y ACL’s, se atenderá a lo que indique el Libro Blanco de

Adif.

AUDITORÍAS

El procedimiento de creación de una nueva entrada del Registro de Auditoría se realizará

de acuerdo a lo expuesto en el Libro Blanco de Adif.

CONFIGURACIÓN DE OBJETOS DOCUMENTUM

Conforme a lo establecido en el apartado de “Normas de desarrollo” del Libro Blanco, se

define el tipo de desarrollo y el tipo de repositorio. Así mismo, se seguirá la norma en

cuanto a la selección y configuración de objetos dentro del repositorio.

Quedan prohibidas las jerarquías verticales con más de 3 niveles (a partir de

dm_document o dm_folder). Cualquier excepción deberá de ser autorizada por el

administrador de DCTM.

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


FLUJOS DE TRABAJO Y CICLOS DE VIDA

Como buenas prácticas en la definición de flujos de trabajo caben destacar el establecer

convenciones en los nombres de los procesos y sus elementos y realizar el versionado de

objetos.

Inicialmente los flujos de trabajo se definirán haciendo uso de WFM.

Siempre que sea necesaria la monitorización del flujo de trabajo, el análisis y la

realización de informes para la obtención de resultados destinados a la optimización

continua del flujo de trabajo, habrá que utilizar Process Builder.

Se utilizarán ciclos de vida siempre que sea únicamente necesario definir reglas que se

encarguen de guiar un documento a través de un conjunto de cambios de estado o

transiciones predefinidas.

Se utilizarán Flujos cuando haya que definir secuencias de actividades que impliquen

intervención manual en su ejecución, control de cuando se realizan las actividades,

integraciones con otros sistemas, toma de decisiones o bucles.

INFORMACIÓN A CUMPLIMENTAR

El documento de diseño técnico que tendrá que entregarse antes de iniciar el desarrollo de

cada aplicación documental y que será validado por la DSI deberá recoger la siguiente

información:

Tipos de objetos de usuario y jerarquía definida.

Tipos de objetos DCTM. Deberá detallarse la definición y jerarquía (cuando aplique)

de los distintos tipos de objetos.

Definición de Flujos de trabajo y ciclos de vida.

RECOMENDACIONES DE DESARROLLO SOBRE DCTM

Los desarrollos de aplicaciones J2EE que hagan uso del framework de servicios

documentales deberán seguir lo establecido en los documentos de Arquitectura en cuanto

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


a la estructura de la aplicación J2EE, la Capa de Presentación, la Capa de negocio y la capa

de Acceso a base de datos.

El control de versiones de los objetos del repositorio se realizará a través de la herramienta

de desarrollo basada en Eclipse “COMPOSER”.

También se crea un nuevo concepto, los Proyectos DCTM de Composer, formado por los

ficheros de configuración y artefactos necesarios para generar el repositorio.

Se recomienda a los desarrolladores de versiones previas consultar el documento

“Introduction to Documentum Composer for DAB users.pdf” de EMC, para familiarizarse con

los nuevos términos introducidos por Composer.

Para crear una nueva aplicación, es necesario crear un Proyecto de Documentum en

Composer, configurando el entorno de trabajo en Eclipse y garantizando el control de

versiones de código.

Todos los objetos DCTM de una aplicación se deberán empaquetar en un fichero .dar

(Composer) para la instalación en los diferentes entornos.

El nombre del proyecto en Composer debe coincidir con las tres siglas que identifican

unívocamente a la aplicación. Por ejemplo, nyp.dar para el proyecto Normas y

Procedimientos.

DIRECTRICES DE DESARROLLO WEBTOP / WDK

Las directrices que se deberán tener en cuenta a la hora de realizar un desarrollo

WDK/Webtop son las siguientes:

Se deberá de disponer de un despliegue de Webtop independiente para cada

aplicación.

Al construir una aplicación sobre Webtop, se deberá utilizar el directorio /custom

(el nombre “custom” puede modificarse).

Además deberán tenerse en cuenta otras consideraciones incluidas en el documento

“Libro Blanco”.

Otros Documentos de Referencia:

- Modelo global

41-021/03



Vers. 1

Fecha 04-07-2016

Pags. 39


- Guía de Estilos

pliego de condiciones técnicas -...

Documents