02 documentotecnicosiinu ccaa

MINISTERIO
DE EDUCACIÓN
Sistema Integrado de Información
Universitaria
Especificación de Requisitos
SECRETARÍA GENERAL DE UNIVERSIDADES
Sub. Gral. de Análisis, Estudios y Prospectiva Universitaria

EDICIÓN 2.0
FECHA 26/01/2010
Proyecto: Error: Reference source not found
Edición: Error: Reference source not
found
ii Fecha: Error: Reference source
not found

Información General
• Proyecto: Error: Reference source not found
• Entidad de Destino: Secretaría General de Universidades
• Título: Error: Reference source not found
• Edición: Error: Reference source not found
• Fecha de Edición: Error: Reference source not found
• Código de fichero: 02documentotecnicosiinuccaa-140703155148-
phpapp01.doc
• Herramienta/s de Edición: Microsoft Word 2003
• Autores: everis
Proyecto:
Edición: I Fecha:

ÍNDICE
1. INTRODUCCIÓN.................................................................................................................................1
1.1 OBJETO...........................................................................................................................................1
1.2 AMBITO DE LA APLICACIÓN..................................................................................................1
2. DESCRIPCIÓN GENERAL DEL SISTEMA.....................................................................................2
2.1 DESCRIPCIÓN DE LA SITUACIÓN ACTUAL.......................................................................2
2.2 DESCRIPCIÓN DEL SISTEMA FUTURO.................................................................................2
3. REQUISITOS..........................................................................................................................................9
3.1 REQUISITOS FUNCIONALES.............................................................................................................9
3.2 REQUISITOS OPERATIVOS..............................................................................................................21
3.3 REQUISITOS DE USABILIDAD.........................................................................................................24
3.4 REQUISITOS DE SEGURIDAD..........................................................................................................25
4. GLOSARIO DE TÉRMINOS Y ACRÓNIMOS.............................................................................27
Proyecto:
Edición: II Fecha:

1. INTRODUCCIÓN
En este capítulo se enumeran los objetivos y el ámbito de aplicación del documento
técnico de Especificación de Requisitos para el desarrollo de un Sistema Integrado de
Información Universitaria.
1.1 OBJETO
El presente documento realiza una descripción detallada de los requisitos relativos al
Sistema Integrado de Información Universitaria, determinando para ello la
funcionalidad que exige el nuevo sistema, así como las necesidades y condicionantes
que se deberán tener en cuenta durante las fases siguientes del ciclo de vida del
proyecto.
1.2 AMBITO DE LA APLICACIÓN
El ámbito de análisis abarca las Comunidades Autónomas y las Universidades, tanto
públicas como privadas, ubicadas en territorio español, que se encuentren en situación
de impartir y expedir Títulos Oficiales.
Proyecto:
Edición: 1 Fecha:

2. DESCRIPCIÓN GENERAL DEL SISTEMA
2.1 DESCRIPCIÓN DE LA SITUACIÓN ACTUAL
Actualmente, la Secretaría General de Universidades no dispone de un sistema único
que le permita gestionar la información remitida por las Universidades y realizar un
seguimiento de todos los indicadores requeridos.
El modo de trabajo empleado en la actualidad, tanto para la información Académica,
Económica y de Recursos Humanos, es el siguiente:
•Se recibe la información a través del correo electrónico.
•Se revisan los ficheros recibidos con programas estadísticos específicos: SAS o
SPSS. Se analiza el formato, la completitud y el contenido de los ficheros.
•Posteriormente, se procesan los datos en local, utilizando programas y macros
desarrollados por el usuario en SAS y/o SPSS, con el fin de obtener los informes
requeridos.
•Por último, se publican las estadísticas y se da respuesta a las peticiones a
medida.
2.2 DESCRIPCIÓN DEL SISTEMA FUTURO
En este apartado se realiza una descripción detallada del sistema futuro.
2.2.1 CARACTERÍSTICAS PRINCIPALES
En este documento se especifica la metodología a seguir para el desarrollo de un
Sistema Integrado de Información Universitaria, que recabe la información de sus
diferentes orígenes, la procese de forma homogénea y finalmente proporcione un
conjunto de indicadores que permitan la comparabilidad de las diferentes instituciones
dentro del Sistema Universitario Español (SUE), ofreciendo las siguientes ventajas:
•Creación de un almacén de datos unificado diseñado para el análisis, donde se
recoja la información Académica, de Recursos Humanos, Económica, de Inserción
Laboral e I+D para todo el territorio nacional.
•Creación de una herramienta que permita la disponibilidad y el seguimiento de
la información y los indicadores del área Académica, de Recursos Humanos,
Económica, de Inserción Laboral e I+D.
•Intercambio automatizado de información con las Universidades y
Comunidades Autónomas, que permita solicitar, generar y procesar los informes
predefinidos.
•Disponibilidad de herramientas administrativas que faciliten la parametrización
de alarmas de validación de los datos de entrada, con capacidad para indicar y
Proyecto:
Edición: 2 Fecha:

modificar los plazos de entrega de ficheros, las plantillas de los avisos y las
personas de contacto.
•Disponibilidad de una herramienta que desarrolle de forma homogénea el
cálculo de un conjunto de indicadores universitarios, que sean comparables
entre todas las instituciones en cada una de las áreas de información.
2.2.2 SISTEMA FUTURO
En el siguiente diagrama se presentan los principales módulos del sistema futuro,
identificando a alto nivel cada uno de sus componentes:
2.2.2.1Módulo de Gestión del Aprovisionamiento
El objetivo principal del módulo será la recepción (o extracción), transformación y
carga desde las Universidades hasta el almacenamiento destino, garantizando la
calidad de los datos. Se distinguen los siguientes procesos:
•Recepción: Permiten obtener la información de los ficheros enviados por todas
las Comunidades Autónomas y Universidades españolas. Para lo cual hay que
tener en cuenta el volumen y tamaño de los ficheros, la definición de una
estructura de fichero que garantice el entendimiento entre los sistemas
originales y el sistema de información, y la transferencia y Gestión de ficheros.
Proyecto:
Edición: 3 Fecha:

Las Universidades enviarán mediante la invocación a Web Services los ficheros
que generen. Los Web Services ejecutarán una serie de validaciones sobre la
información contenida en los ficheros, con el objetivo de que la Universidad
remitente pueda corregir los errores detectados y vuelva a enviar los ficheros al
sistema analítico. La detección de dichos errores generará alarmas que serán
comunicadas a la Universidad propietaria del fichero y a la Comunidad
Autónoma correspondiente, haciéndola participe y responsable de la validación
de los ficheros.
De esta manera si las validaciones han sido correctas durante el proceso de
recepción, el sistema grabará la información recibida para su posterior
tratamiento por parte del proceso de carga.
•Transformación: son las acciones que hay que realizar sobre los datos que
provienen de los ficheros de las Universidades para adecuarlos al modelo
relacional del Sistema de Información, permitiendo una sencilla explotación de la
información por parte de los usuarios finales.
Mediante dicho proceso se verificará la adecuación de los datos en el modelo
relacional del sistema, pudiendo producirse errores de consolidación. La
detección de dichos errores generará alarmas que serán comunicadas en un
primer momento al Ministerio de Educación, que analizará el problema y
procederá a su corrección, pudiendo necesitar de la colaboración de la
Universidad propietaria del fichero y de la Comunidad Autónoma
correspondiente.
Si las verificaciones han sido correctas, el proceso de transformación permitirá
consolidar la información recibida para su posterior tratamiento por parte del
proceso de carga.
•Carga: Incorpora la información que ya se ha tratado en los procesos anteriores
(sistemas de almacenamiento), que serán los que proporcionarán información a
los reportes, se extraerán informes analíticos o cuadros de mando.
El proceso de carga recogerá la información proporcionada por:
o El proceso de recepción, y la cargará en el ODS del Sistema de Información.
o El proceso de transformación, y la cargará en el DWH o en el data mart
correspondiente del Sistema de Información.
En la siguiente imagen se muestra el esquema de los procesos de extracción,
transformación y carga de los datos procedentes de los ficheros de las Universidades.
Proyecto:
Edición: 4 Fecha:

2.2.2.2Módulo de Gestión de Almacenamiento
El módulo de Gestión de Almacenamiento está compuesto por:
•ODS: Es un repositorio o almacén de información analítica desagregada e
histórica, compuesto por un conjunto de tablas que recopilan información
procedente de los sistemas de origen.
•Data warehouse (DW): Sistema de información relacional centralizado que
contendrá toda la información sobre el Área Académica, de Recursos Humanos,
Económica, de Inserción Laboral e I+D y que permite de forma ágil y flexible
consultar la información. El origen de la información para el data warehouse será
el ODS.
•Data mart (DM): Subconjunto del data warehouse de un área informacional
especifica.
•Cuadros de Mando: Es un sistema para la Gestión cuyo objetivo es mostrar los
informes y los indicadores estratégicos que se hayan definidos.
En el siguiente esquema se observan los componentes descritos:
Proyecto:
Edición: 5 Fecha:

2.2.2.3Módulo de Gestión de Explotación
El módulo de Gestión de la explotación permitirá realizar lo siguiente:
•Acceder a informes a través de una herramienta de explotación de manera
centralizada y no distribuida.
•Disponer de un inventario de informes, permitiendo la clasificación y tipificación
de todos ellos, indicando su descripción, funcionalidad y origen de la
información.
•Automatizar la generación de los informes más utilizados.
•Definir las consultas e informes predefinidos de uso común. Incluido los
requeridos por organismos públicos.
•Definir, recopilar, estructurar y organizar los datos relevantes para el Ministerio,
las Comunidades Autónomas y las Universidades.
•Determinar los indicadores del Sistema Universitario que se encontrarán en el
repositorio de información corporativa.
•Entorno web a través del cual se podrá acceder a los informes que se hayan
generado.
•Usabilidad, información en un clic.
Proyecto:
Edición: 6 Fecha:

La siguiente imagen resume los componentes del modulo de explotación.
Cuadro
de mando
Análisis
Reporting
Reporting. Este tipo de explotación se basa en el acceso a informes predefinidos con
baja posibilidad de modificación por el usuario.
Análisis. Permite:
• Construir consultas no predefinidas de forma sencilla para el usuario final no técnico
de manera flexible.
• Realizar análisis multidimensionales desde niveles de destalle agregados a niveles de
detalle desagregados.
Cuadro de mando. Entorno con capacidades visuales avanzadas, alto rendimiento y
usabilidad que muestra indicadores clave sobre Educación para dar soporte a la toma
de decisión
2.2.2.4Módulo de Gestión de Metadatos
En el desarrollo de sistemas de Business Intelligence el uso de Metadatos es pieza
importante (información sobre la información) que permite tener el control sobre el
contenido del sistema y su operación, de manera que se puedan ofrecer indicadores
de calidad del dato mostrado, incrementando la credibilidad de las áreas usuarias en
los datos mostrados.
Los metadatos se pueden estructurar en tres tipologías claramente diferenciadas:
•Técnico: Los metadatos técnicos permitirán conocer la estructura de datos
tanto de los sistemas de origen de información como del propio sistema
analítico, tales como tamaño de campos, estructura de tablas, formato de
ficheros, etc.
•De operación: Permiten realizar el seguimiento y control de los procesos de
carga de información en el sistema y la generación de informes, aportando
información de tiempos de ejecución, finalización correcta o errónea de
procesos, seguimiento del flujo de la carga (trazabilidad) y, en definitiva, todo el
conocimiento necesario para la realización del control y soporte de la
información.
•Funcional: Constituyen el nexo de unión entre la información técnica
almacenada en el sistema y la interpretación del negocio a disposición del
usuario. Los metadatos funcionales dan información sobre los conceptos de
negocio definido y tratados en el sistema. De esta manera cualquier concepto
utilizado en el sistema de información deberá ser almacenado en lenguaje
funcional, de manera que el usuario de la información sepa exactamente las
definiciones que está tratando.
Proyecto:
Edición: 7 Fecha:

En siguiente grafico se muestran las tipologías de metadatos que componen el
modulo:
Proyecto:
Edición: 8 Fecha:

3. REQUISITOS
En este capítulo se describen los requisitos relativos a la creación del Sistema
Integrado de Información Universitaria. Todos los requisitos se identifican
unívocamente mediante un código que constará de la codificación de la categoría a la
que pertenece, un identificador de subcategoría y del número de orden. Este código
será utilizado como referencia cada vez que sea necesario mencionarlo a lo largo del
ciclo de vida del proyecto.
3.1 Requisitos Funcionales
Especificaciones destinadas a cubrir los siguientes aspectos:
1. Adecuación: Capacidad del producto software para proporcionar un conjunto
apropiado de funciones para tareas y objetivos de usuario especificados.
2. Exactitud: Capacidad del producto software para proporcionar los resultados o
efectos correctos o acordados, con el grado necesario de precisión.
3. Interoperabilidad: Capacidad del producto software para interactuar con uno o
más sistemas especificados.
3.1.1 Aplicación
RF.APL.1 A los usuarios dados de alta en el sistema se les asociará un perfil de
acceso y se informará el organismo al que pertenece y el nivel de actuación de su
organización, ya sea a Universidad, Comunidad Autónoma, Ministerio de Educación y
otras Instituciones.
RF.APL.2 Los privilegios dados a un usuario, vendrán informados en el perfil que
se asigne al usuario.
RF.APL.3 Los perfiles de acceso al sistema serán descritos como la combinación de
dos criterios:
•Tipos de Usuario (RF.APL.04)
•Niveles de Usuario (RF.APL.05)
RF.APL.4 Para limitar el acceso a los apartados que se definan en la aplicación
existirán cuatro tipos de usuario.
•
Proyecto:
Edición: 9 Fecha:

• Lectura. Solo podrá acceder a la aplicación en modo lectura, es
decir, solo podrá visualizar informes predefinidos ya ejecutados. Este
será el perfil del usuario general.
• Ejecución. Además de poseer los permisos del usuario de Lectura,
podrá acceder a la aplicación para ejecutar y visualizar informes más
especializados, previamente desarrollados por otro perfil de usuario.
En este perfil estarán, por ejemplo, el Observatorio Universitario o la
Fundación Universidad.es.
• Desarrollo. Además de poseer los permisos del usuario de Ejecución,
podrá acceder a la aplicación para generar, ejecutar y visualizar
informes. En este perfil estarán, por ejemplo, las Universidades, la
ANECA, las CCAA.
• Administración. Además de poseer los permisos del usuario de
Desarrollo, tendrá acceso a la parte de administración (seguridad,
parametrización…) del Sistema. En este perfil estará el personal
especializado del Ministerio de Educación, de las CCAA y de las
Universidades.
RF.APL.5 Los permisos de acceso a la información del sistema serán otorgados
mediante la asignación de privilegios en base a la siguiente matriz.
Detalle del dato
(microdato)
datos agregados Indicadores
Área Académica Nivel Nivel Nivel
Área de Recursos
Humanos
Nivel Nivel Nivel
Área Económica Nivel Nivel Nivel
Área de Inserción
Laboral
Nivel Nivel Nivel
Área I+D Nivel Nivel Nivel
Dicha matriz deberá contemplar las distintos áreas (Académica, Económica, de
Recursos Humanos, de Inserción Laboral e I+D) que existan en el sistema.
El nivel de usuario indicado en la matriz podrá tomar los siguientes valores:
• Nivel 4. No se tendrá acceso a este tipo de información.
• Nivel 3. Indica que el usuario sólo podrá acceder a los datos de la
Universidad a la que esté asociado.
• Nivel 2. Indica que el usuario sólo podrá acceder a los datos de la
Comunidad Autónoma a la que esté asociado, lo que implica que
Proyecto:
Edición: 10 Fecha:

tendrá acceso a los datos de las Universidades que se localizan en
dicha Comunidad Autónoma.
• Nivel 1. Corresponde a los usuarios que tienen el privilegio de
acceder a todos los niveles de información.
A continuación se muestra un posible ejemplo de privilegios que podría tener un
Rector de Universidad.
Detalle del dato
(microdato)
datos agregados Indicadores
Área Académica Nivel 3 Nivel 3 Nivel 1
Área Económica Nivel 3 Nivel 3 Nivel 1
Área de
Recursos
Humanos
Nivel 3 Nivel 3 Nivel 1
Área de
Inserción
Laboral
Nivel 3 Nivel 3 Nivel 1
Área I+D Nivel 3 Nivel 3 Nivel 1
RF.APL.6 Se asignarán tipo de usuario con sus respectivos niveles de seguridad a
todos los organismos implicados: Ministerio de Educación, CCAA, Universidad, ANECA,
CRUE, Observatorio Universitario de Becas y Ayudas al Estudio y Rendimiento
Académico, Fundación Universidad.es, etc.
RF.APL.7 El sistema debe soportar un portal web donde estarán accesibles los
manuales de ayuda, de formación y los accesos a los distintos módulos del sistema,
habilitados o no dependiendo de la seguridad del perfil de los usuarios.
RF.APL.8 En el sistema debe existir un módulo que permita crear y modificar
informes a los usuarios de desarrollo.
RF.APL.9 En el sistema deberá existir un módulo de gestión de las validaciones,
donde se permita crear validaciones de los ficheros, modificarlas, aplicarlas o
deshabilitarlas.
Proyecto:
Edición: 11 Fecha:

RF.APL.10 A los usuarios de desarrollo que generen informes se les permitirá
realizar la publicación del diseño del mismo, siendo dependientes de los privilegios del
usuario que posteriormente acceda al informe los datos que visualizará en el mismo.
RF.APL.11 Las universidades y las Comunidades Autónomas tendrán accesible vía
web un módulo de depuración y seguimiento de datos, donde podrán:
• ver todos los envíos realizados, incluyendo las posibles versiones de un
mismo envío. Se informará de los resultados de carga de cada envío o
del estado del fichero en cuestión (pendiente de la CCAA, pendiente del
Ministerio, aplicado, con errores y esperando otro).
• ver los próximos envíos a realizar con la fecha límite,
• subir ficheros a esa web y que se realicen las validaciones (sin cargar el
fichero) para que detecten posibles errores.
RF.APL.12 El Ministerio de Educación tendrá accesible vía web un módulo de
depuración y seguimiento de datos, donde podrán observar todo lo indicado en el
requisito RF.APL.11, con la salvedad de que se podrá ver todo el conjunto del sistema.
RF.APL.13 Es deseable que en el sistema exista una herramienta para la petición de
nuevos informes.
3.1.2 Datos de entrada
RF.ENT.1 Es necesario que todos los ficheros sean adaptables a las modificaciones
anuales que pudieran producirse y los procesos derivados en todas las áreas.
1. Área académica.
RF.ENT.2 El sistema debe ser capaz de recibir, validar, cargar y consolidar los datos
del Área Académica recibidos en los ficheros enviados por las Universidades y las
Comunidades Autónomas, siempre y cuando dichos ficheros sigan el diseño acordado
en el documento, de acuerdo al interfaz de los estudiantes. Dicho documento se
definirá durante la fase de análisis en base a la “Metodología de la Estadística de
Estudiantes Universitarios” que será revisada y aprobada en la Comisión Técnica de
Estadística e Información Universitaria [REF.1]. Estos ficheros se revisarán anualmente.
A continuación se enumeran los ficheros que inicialmente se recibirán, remitidos por
las Universidades y las Comunidades Autónomas, referentes al Área Académica:
•Fichero de matrícula de primer y segundo ciclo.
•Fichero de graduados de primer y segundo ciclo.
Proyecto:
Edición: 12 Fecha:

•Fichero de matrícula de grado.
•Fichero de graduados de grado.
•Fichero de matrícula de doctorado LRU. (RD 778/1998).
•Fichero de graduados de 3º ciclo. Doctorado LRU. (RD 778/1998).
•Fichero de matrícula de máster. (RD 56/2005 y RD 1393/2007).
•Fichero de graduados de máster. (RD 56/2005 y RD 1993/2007).
•Fichero de matrícula de doctorado. (RD 56/2005 y RD 1993/2007).
•Fichero de graduados de doctorado. Tesis leída y apta (RD 56/2005 y RD
1993/2007).
•Fichero de movilidad temporal (entrada).
•Fichero de movilidad temporal (salida).
RF.ENT.3 Los ficheros del Área Académica deberán seguir la nomenclatura
indicada:
AC + “_” + UNIVERSIDAD + “_” + CODIGO + “_” + CURSO + “_” + VERSIÓN
Siendo:
•AC: Nomenclatura tomada para los ficheros correspondientes al Área
Académica.
•UNIVERSIDAD: Identificador de la Universidad que manda el fichero.
•CODIGO: Código que identifica inequívocamente la tipología de los datos
contenidos en el fichero.
•CURSO: Se consignarán los cuatro dígitos del primer año de los dos años
naturales que compone el año académico al que corresponden los datos.
•VERSIÓN: Corresponderá al orden de la partición del fichero que se envía. El
formato corresponderá a cuatro dígitos numéricos comenzando por el ‘0000’ e
incrementando una unidad por cada nueva partición que se envíe.
2. Área de Recursos Humanos.
del Área de Recursos Humanos recibidos en los ficheros enviados por las Universidades
y las Comunidades Autónomas, siempre y cuando dichos ficheros sigan el diseño
acordado en el documento de acuerdo al interfaz del personal. Dicho documento se
definirá durante la fase de análisis en base al documento “Metodología de la
Estadística de Personal al Servicio de las Universidades” que será revisado y aprobado
Proyecto:
Edición: 13 Fecha:

en la Comisión Técnica de Estadística e Información Universitaria. [RF.3]. Estos ficheros
se revisarán anualmente.
A continuación se enumeran los ficheros que se recibirán inicialmente y que serán
remitidos por las Universidades:
•Fichero del PDI (Personal Docente e Investigador).
•Fichero del PAS (Personal de Administración y Servicios).
•Fichero del personal investigador.
RF.ENT.5 Los ficheros del Área de Recursos Humanos deberán seguir la
nomenclatura indicada:
RH + “_” + UNIVERSIDAD + “_” + CODIGO + “_” + CURSO + “_” + VERSIÓN
Siendo:
•RH: Nomenclatura tomada para los ficheros correspondientes al Área de
Recursos Humanos.
3. Área Económica.
del Área Económica recibidos en los ficheros enviados por las Universidades, siempre y
cuando dichos ficheros sigan el diseño acordado en el documento de acuerdo al
interfaz del Área Económica. Dicho documento se definirá en el seno de la Comisión
Técnica de Estadística e Información Universitaria, en función de las conclusiones de la
Comisión de Contabilidad Analítica en la que participan representantes del Ministerio
de Educación, de IGAE, de las Comunidades Autónomas y de las Universidades.
RF.ENT.7 Los ficheros del Área Económica deberán seguir la nomenclatura
indicada:
EC + “_” + UNIVERSIDAD + “_” + CODIGO + “_” + CURSO + “_” + VERSIÓN
Siendo:
Proyecto:
Edición: 14 Fecha:

•EC: Nomenclatura tomada para los ficheros correspondientes al Área
Económica.
4. Área de I+D.
de Gestión I+D recibidos en los ficheros enviados por las Universidades, siempre y
cuando dichos ficheros sigan el diseño acordado en el documento de acuerdo al
interfaz del Área de I+D. Dicho documento se realizará en la Comisión Técnica de
Estadística e Información Universitaria.
RF.ENT.9 Los ficheros del Área de I+D deberán seguir la nomenclatura indicada:
ID + “_” + UNIVERSIDAD + “_” + CODIGO + “_” + CURSO + “_” + VERSIÓN
Siendo:
•ID: Nomenclatura tomada para los ficheros correspondientes al Área de I+D.
5. Área de Inserción Laboral.
del Área de Inserción Laboral que se obtengan del cruce de información con otras
bases de datos. Se contemplarán también otras vías de obtención de esta información.
Proyecto:
Edición: 15 Fecha:

RF.ENT.11 Los ficheros del Área de Inserción Laboral deberán seguir la
nomenclatura indicada:
IL + “_” + UNIVERSIDAD + “_” + CODIGO + “_” + CURSO + “_” + VERSIÓN
Siendo:
•IL: Nomenclatura tomada para los ficheros correspondientes al Área de
Inserción Laboral.
3.1.3 Indicadores
RF.IND.1 El sistema debe ser capaz de calcular los indicadores relativos a cada
Área que se acuerden en el seno de la Comisión Técnica de Estadística e Información
Universitaria en la que están representadas las Comunidades Autónomas, que a su vez
trabajarán en coordinación con las universidades de su competencia.
RF.IND.2 El sistema debe ser capaz de calcular aquellos indicadores del Área
Académica que sean necesarios para el desarrollo de las funciones evaluadoras de la
ANECA.
RF.IND.3 El sistema debe ser capaz de calcular los indicadores de Gestión
Económica que se determinen en el seno de la Comisión de Contabilidad Analítica y
que serán de interés tanto para el Ministerio, como las Comunidades Autónomas y las
propias universidades.
RF.IND.4 El sistema debe ser capaz de calcular aquellos indicadores que pudieran
ser necesarios para el desarrollo de las funciones del Observatorio Universitario de
Becas, Ayudas y Rendimiento Académico.
RF.IND.5 El sistema debe ser capaz de calcular aquellos estadísticos que permitan
la comparación entre las distintas instituciones
Proyecto:
Edición: 16 Fecha:

3.1.4 Informes predefinidos
RF.INF.1 El sistema debe ser capaz de generar los informes estándar que se
definan. Entre ellos deben estar:
•Informes estándar para el Ministerio de Educación con información relativa al
conjunto del Sistema Universitario Español.
•Informes estándar destinados a las Comunidades Autónomas con la
información y los indicadores que ellas requieran.
•Informes estándar destinados a las Comunidades Autónomas que permitan la
comparabilidad entre ellas en cada una de las áreas temáticas.
•Informes estándar destinados a las Universidades con la información y los
indicadores que ellas requieran.
•Informes estándar destinados a las Universidades que permitan la
comparabilidad entre ellas en cada una de las áreas temáticas
•Los indicadores requeridos por ANECA para el desarrollo de sus funciones
•Los informes que precise el Observatorio Universitario de Becas, Ayudas y
Rendimiento Académico para el desarrollo de sus funciones.
•La Estadística de Estudiantes Universitarios
•La Estadística de Persona al Servicio de las Universidades
•La Estadística de Acceso al Sistema Universitario
•El informe ‘Datos y Cifras del Sistema Universitario’.
•Los cuestionarios UOE de la OCDE
•El sistema debe ser capaz de generar el informe de “Validación de ficheros”.
Este informe aporta información sobre la validación de los ficheros de entrada
enviados por las Universidades. Deberá mostrar los ficheros validados y no
validados, en cuyo caso se especificará el motivo o motivos del error de
validación.
•El sistema debe ser capaz de generar el informe de “Consolidación de ficheros”.
Este informe aporta información sobre la consolidación de los ficheros de
entrada enviados por las Universidades. Deberá mostrar los ficheros
consolidados y no consolidados, en cuyo caso se especificará el motivo o motivos
del error de consolidación.
3.1.5 Avisos
RF.AVI.1 Existirá un proceso que envíe avisos automáticos, vía correo electrónico,
a las personas de contacto de las Universidades en referencia a:
Proyecto:
Edición: 17 Fecha:

•Comienzo del plazo de recepción de ficheros. La plantilla estará previamente
guardada en base de datos, adaptada al destinatario y al o los ficheros
solicitados. Se enviará el día de comienzo de plazo.
•Fin del plazo de recepción de ficheros. La plantilla estará previamente
solicitados. Se enviará “n” días antes del final de plazo, donde “n” es un número
administrable por el usuario de la aplicación.
•Fuera del plazo de recepción de ficheros. La plantilla estará previamente
solicitados. Se enviará cada “n” días después del final de plazo, donde “n” es un
número administrable por el usuario de la aplicación.
•Error de validación en alguno de los ficheros. La plantilla estará previamente
guardada en base de datos, adaptada al destinatario y al o los errores de
validación encontrados en el fichero procesado. Se enviará cada vez que se
encuentren errores de validación al procesar los ficheros.
a las personas de contacto de las Comunidades Autónomas, que incluirá a todas las
Universidades de la Comunidad Autónoma correspondiente, en referencia a:
•Comienzo del plazo de recepción de ficheros. La plantilla estará previamente
solicitados. Se enviará el día de comienzo de plazo.
•Fin del plazo de recepción de ficheros. La plantilla estará previamente
solicitados. Se enviará “n” días antes del final de plazo, donde “n” es un número
administrable por el usuario de la aplicación.
•Fuera del plazo de recepción de ficheros. La plantilla estará previamente
solicitados. Se enviará cada “n” días después del final de plazo, donde “n” es un
número administrable por el usuario de la aplicación.
•Error de validación en alguno de los ficheros. La plantilla estará previamente
validación encontrados en el fichero procesado. Se enviará cada vez que se
a las personas de contacto de la Secretaría General de Universidades en referencia a:
•Error de consolidación en alguno de los ficheros. La plantilla estará previamente
Proyecto:
Edición: 18 Fecha:

consolidación encontrados en el fichero procesado. Se enviará cada vez que se
3.1.6 Administración
RF.ADM.1 El usuario administrador podrá determinar los plazos de recepción de
cada uno de los ficheros de cada área indicando la fecha de inicio y de fin de los plazos,
la fecha en la que se envíe aviso de finalización del plazo de recepción de los ficheros,
las plantillas de aviso que se enviarán a los contactos, etc.
RF.ADM.2 Las tablas auxiliares de universidades, centros, títulos, etc. se obtendrán
del Registro de Universidades Centros y Titulaciones de la Secretaría General de
Universidades. Aquellas que no puedan extraerse del RUCT tendrán un interfaz sencillo
para su mantenimiento.
RF.ADM.3 El usuario administrador debe poder administrar las personas de
contacto, tanto de las universidades como de las Comunidades Autónomas.
Los contactos serán designados con las siguientes directrices:
•La Secretaría General de Universidades determinará una persona de contacto
para cada área y si fuese necesario para cada fichero.
•Cada Comunidad tendrá una persona de contacto que será el coordinador de la
comunidad
•Cada Universidad tendrá una persona de contacto que será el coordinador de la
universidad
•Dentro de cada universidad se determinará una persona de contacto que será el
coordinador de cada área.
•Si fuese necesario en cada área de determinaría un coordinador de cada tipo de
fichero.
RF.ADM.4 El usuario administrador podrá:
• Dar de alta a los usuarios en el sistema, informando los datos de usuario
requeridos.
•Modificar los datos de los usuarios del sistema.
•Dar de baja a los usuarios del sistema. Impidiendo dicha acción en caso de que
el usuario a eliminar corresponda a una persona de contacto para el envío de
ficheros.
Proyecto:
Edición: 19 Fecha:

RF.ADM.5 Es deseable que el sistema esté coordinado con el Directorio Activo.
RF.ADM.6 Los datos de los usuarios dados de alta en el sistema deberán incluir la
información de:
•Nombre y Apellidos.
•Correo electrónico.
•Teléfono.
•Nivel de contacto (Universidad, Comunidad Autónoma, Ministerio de
Educación, Organismos).
•Universidad (si es persona de contacto a este nivel).
•Comunidad Autónoma (si es persona de contacto a este nivel).
•Organismos (si es persona de contacto a este nivel).
RF.ADM.7 Los usuarios dados de alta en el sistema se deberán asociar a perfiles de
acceso a la aplicación.
En el momento de alta del usuario esta relación se asociará a un perfil predefinido,
pudiendo ser modificada en cualquier momento o cuantas veces se requiera.
RF.ADM.8 Se podrá realizar la administración de los perfiles de seguridad del
sistema permitiendo:
•Dar de alta en el sistema los perfiles requeridos por el administrador,
informando los datos de perfil solicitados.
•Modificar los perfiles del sistema.
•Dar de baja a los perfiles del sistema. Impidiendo dicha acción en caso de que el
perfil a eliminar tenga asociados usuarios del sistema.
RF.ADM.9 Los datos de los perfiles dados de alta en el sistema deberán incluir la
información de:
•Denominación del perfil.
•Tipos de Usuario (RF.APL.04).
•Niveles de Usuario (RF.APL.05).
Proyecto:
Edición: 20 Fecha:

3.1.7 Datos históricos
RF.HIS.1 Los datos históricos referentes a cada una de las áreas serán cargados en
el sistema. Se deberá tener especial cuidado en verificar que los datos de años
anteriores respondan a la misma metodología y normalización que los propuestos en
el documento de acuerdo del interfaz de los estudiantes [RF.1].
RF.HIS.2 Los datos referentes al Área Académica, de Recursos Humanos,
Económica, Inserción Laboral e I+D deberán ser mantenidos en el sistema durante al
menos diez años, para permitir observar ciclos completos en los informes. No es
necesario generar procesos de borrado de la información durante la ejecución de este
proyecto, pues es necesario mantener un histórico de todos los años disponibles.
3.2 Requisitos Operativos
Requisitos de operación del sistema. Especificaciones destinadas a cubrir los siguientes
aspectos:
1. Fiabilidad: Capacidad del software para mantener un nivel especificado de
prestaciones en caso de fallos software o de infringir sus interfaces especificados.
2. Eficiencia y Rendimiento: Capacidad del producto software para proporcionar
tiempos de respuesta, tiempos de proceso y potencia apropiados, bajo condiciones
determinadas.
3. Mantenibilidad: Es la capacidad del producto software para diagnosticar
deficiencias y causas de los fallos en el software, o para identificar las partes que
han de ser modificadas.
3.2.1 Arquitectura
RO.ARQ.1. El sistema se montará sobre una máquina virtual proporcionada por el
Ministerio de Educación.
RO.ARQ.2. El sistema operativo de la máquina virtual será alguna versión de Linux
proporcionada por el Ministerio de Educación.
RO.ARQ.3. Java será el lenguaje de programación a utilizar para desarrollar el
aplicativo necesario para el sistema, montado sobre un servidor de aplicaciones
Tomcat proporcionado por el Ministerio de Educación.
RO.ARQ.4. Oracle 10g será la base de datos a usar por el sistema, proporcionada
por el Ministerio de Educación.
Proyecto:
Edición: 21 Fecha:

RO.ARQ.5. La programación de los procesos ETL necesarios para el sistema podrán
realizarse mediante la utilización de Oracle Warehouse Builder. En caso de ser
necesaria alguna otra herramienta, el Ministerio de Educación estudiaría su necesidad.
RO.ARQ.6. Los procesos batch se planificarán en el crontab de los servidores. Esta
tarea podrá ser realizada directamente por el equipo de desarrollo de la aplicación,
aunque también se le puede solicitar al Área de Sistemas.
RO.ARQ.7. La aplicación recibirá los ficheros de entrada mediante WS, por lo que la
validación inicial de los ficheros consistirá en la comprobación del formato xml
acordado.
RO.ARQ.8. En caso de que no puedan adaptarse todas las Universidades al envío de
los ficheros por WS, se habilitaría temporalmente la opción de enviarlos vía upload.
Esto se hará usando clases ya definidas, utilizadas por otras aplicaciones que validan
los ficheros y los almacenan en un directorio a propósito para la aplicación.
RO.ARQ.9. La estructura de carpetas necesaria para el intercambio de ficheros
estará ubicada en un servidor propiedad del Ministerio de Educación.
RO.ARQ.10. Para el envío de los correos electrónicos desde el sistema se utilizará SW
ya definidos, usados por otras aplicaciones del Ministerio de Educación.
3.2.2 Procesos
RO.PRO.1 Los procesos dejarán registradas en un log las trazas necesarias que
puedan permitir identificar los errores que se produzcan durante la ejecución de los
mismos.
RO.PRO.2 Los distintos procesos independizarán los tipos de ficheros de entrada,
permitiendo procesar la información en base a cuatro parámetros:
•ÁREAS: Anagrama del área al que pertenece el fichero
•UNIVERSIDAD/COMUNIDAD AUTÓNOMA: Identificador de la
Universidad/Comunidad Autónoma que envía el fichero.
•CÓDIGO: Código que identifica inequívocamente la tipología de los datos
Proyecto:
Edición: 22 Fecha:

RO.PRO.3 Los procesos que graben información en base de datos, deberán evitar la
carga duplicada de información incluyendo validaciones y borrados en caso de ser
necesario. Esto permite procesar información previamente cargada, que pueda haber
sido modificada.
RO.PRO.4 Los procesos de validación rechazarán aquellos ficheros de entrada que
incumplan los requisitos básicos (tamaño, tipo de dato, obligatoriedad del campo…)
indicados en el correspondiente acuerdo de interfaz.
Tras dicho rechazo además de incluir el detalle en el informe de Validación (RF.INF.1),
se notificará el problema a las personas de contacto de la Universidad y la Comunidad
Autónoma correspondientes. La cual deberán responsabilizarse de enviar otro fichero
con el mismo nombre que el anterior, habiendo realizado las acciones oportunas para
corregir la incidencia, permitiendo que el nuevo fichero pueda ser validado por el
proceso.
RO.PRO.5 Los procesos de consolidación rechazarán aquellos ficheros de entrada
que incumplan el modelo relacional definido para el sistema (relaciones incoherentes,
valores fuera rango…), donde se debe mantener la integridad referencial con las tablas
auxiliares. Se incluirá el detalle en el informe de Consolidación (RF.INF.12) y se
notificará el problema a la persona de contacto de la Secretaría General de
Universidades.
RO.PRO.6 Los procesos de validación moverán los ficheros validados de la carpeta
de entrada a la carpeta de validados.
RO.PRO.7 Los procesos de validación moverán los ficheros no validados de la
carpeta de entrada a la carpeta de fallidos, donde constará la última versión recibida
del fichero a la espera de la resolución de la incidencia.
RO.PRO.8 Los procesos de consolidación moverán los ficheros consolidados de la
carpeta de validados a la carpeta de procesados, donde constará la última versión
recibida del fichero. Si existe el fichero en la carpeta de fallidos será eliminado.
RO.PRO.9 Los procesos de consolidación moverán los ficheros no consolidados de
la carpeta de validados a la carpeta de fallidos, donde constará la última versión
recibida del fichero a la espera de la resolución de la incidencia.
En caso de que la resolución de la incidencia no necesite una nueva versión del fichero
de entrada, bastará con mover o copiar el fichero de la carpeta de fallidos a la carpeta
de validados. Pendiente de definir con el usuario si será mediante acción manual o uso
de algún proceso visual.
Proyecto:
Edición: 23 Fecha:

RO.PRO.10 Tanto los procesos de validación como los de consolidación deberán
registrar el estado de los ficheros tratados, que podrán ser los siguientes:
•No recibido: estado inicial, que indica la necesidad del fichero para el sistema.
•No Validado: indica que se han producido errores en la validación.
•Validado: estado temporal que indica que la validación ha sido correcta y que
está pendiente de la ejecución del proceso de consolidación.
•No Consolidado: indica que se han producido errores en la consolidación.
•Procesado: estado final del fichero, que indica la carga correcta del mismo en el
sistema.
RO.PRO.11 El sistema mantendrá el control de los ficheros mediante el siguiente
flujo funcional:
•carga del fichero y ejecución de validaciones.
•control visual desde la Universidad que valora lo que va a cargar y acepta la
carga.
•control visual desde la Comunidad Autónoma que valora lo que va a cargar y
acepta la carga.
•control visual desde el Ministerio que valora lo que va a cargar y acepta la
carga.
RO.PRO.12 Cualquier carga de fichero en explotación debe poder ser rastreada de
forma que pueda ser eliminado de toda la base de datos cuando se cargue una nueva
versión actualizada y sin errores.
3.2.3 Informes
RO.INF.1 Los informes obtenidos en el sistema evitarán realizar operaciones
complejas. Su ejecución sólo necesitará realizar acciones de lectura sobre la
información recogida en la base de datos. Esto permitirá una rápida ejecución de los
informes.
RO.INF.2 Es deseable que en los informes exista la posibilidad de obtener
resultados estimados, como pueden ser regresiones o proyecciones.
3.3 Requisitos de Usabilidad
Especificaciones destinadas a cubrir los siguientes aspectos:
Proyecto:
Edición: 24 Fecha:

1. Capacidad para ser entendido: Capacidad del producto software que permite al
usuario entender si el software es adecuado y cómo puede ser utilizado para unas
tareas o condiciones particulares.
2. Capacidad para ser aprendido: Capacidad del producto software que permite al
usuario aprender sobre su aplicación.
3. Capacidad para ser operado: Capacidad del producto software que permite al
usuario operarlo y controlarlo.
4. Capacidad de atracción: Capacidad del producto software para ser atractivo al
usuario.
3.3.1 Aplicación
RU.APL.1 La aplicación será accesible mediante un enlace situado en la intranet.
También será accesible desde la extranet.
RU.APL.2 Se implementará un interface de usuario o front-end de la aplicación
acorde a las normas existentes en el Ministerio de Educación.
3.3.2 Servidor de Ficheros
RU.SER.1 Mediante la utilización de los SW se mantiene un mismo sistema de
intercambio de información con actores externos al Ministerio de Educación.
RU.SER.2 El nombre de los ficheros siempre corresponderá con lo indicado en los
requisitos RF.ENT.02, RF.ENT.04 y RF.ENT.06 aunque puedan enviarse varias veces
para la corrección de incidencias. Permitiendo así que los programas de Validación y
Consolidación procesen siempre la última versión del fichero.
3.3.3 Informes
RU.INF.1 La ejecución de os informes será planificada y realizada a petición del
usuario.
RU.INF.2 Los informes deben ser exportables a fichero Excel y a fichero pdf.
3.4 Requisitos de Seguridad
Especificaciones destinadas a cubrir la capacidad del producto software para proteger
información y datos, de manera que las personas o sistemas no autorizados no puedan
Proyecto:
Edición: 25 Fecha:

leerlos o modificarlos, al tiempo que no se deniega el acceso a las personas o sistemas
autorizados.
3.4.1 Aplicación
RS.APL.1 Los usuarios internos para entrar en la aplicación (Intranet o Extranet),
serán dados de alta en el OpenLDAP, y mediante la utilización del Single Sign-On se
validarán contra la aplicación.
RS.APL.2 Los usuarios externos para entrar en la aplicación, se les dará de alta en
el OpenLDAP. Al acceder por Internet se les pedirá usuario y contraseña que se
validará contra el OpenLDAP.
RS.APL.3 Los usuarios externos (público) al acceder por Internet se les pedirá
usuario y contraseña que se validará contra el OpenLDAP, al no estar dados de alta se
les asignará un role público que se defina.
3.4.2 Servidor de Ficheros
RS.SER.1 Los SW se autentifican vía la aplicación interna SVA. Las Universidades
para autentificarse tendrán que tener un usuario y contraseña dados de alta en dicha
aplicación.
3.4.3 Base de datos
RS.BDD.1 La seguridad de la base de datos corresponderá con la normativa
existente en el Ministerio de Educación.
Proyecto:
Edición: 26 Fecha:

4. GLOSARIO DE TÉRMINOS Y ACRÓNIMOS
RD
Real Decreto.
LRU
Ley de Reforma Universitaria.
Single sign-on
(SSO) es un procedimiento de autenticación que habilita al usuario para acceder a
varios sistemas con una sola instancia de identificación.
SW
(Servicios Web) es un conjunto de protocolos y estándares que sirven para
intercambiar datos entre aplicaciones.
Proyecto:
Edición: 27 Fecha:

02 documentotecnicosiinu ccaa

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (8)

Similar a 02 documentotecnicosiinu ccaa

Similar a 02 documentotecnicosiinu ccaa (20)

Último

Último (20)

02 documentotecnicosiinu ccaa