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 notfound

ii Fecha: Error: Reference sourcenot 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...........................................................................................................................................11.2 AMBITO DE LA APLICACIÓN..................................................................................................1

2. DESCRIPCIÓN GENERAL DEL SISTEMA.....................................................................................2

2.1 DESCRIPCIÓN DE LA SITUACIÓN ACTUAL.......................................................................22.2 DESCRIPCIÓN DEL SISTEMA FUTURO.................................................................................2

3. REQUISITOS..........................................................................................................................................9

3.1 REQUISITOS FUNCIONALES.............................................................................................................93.2 REQUISITOS OPERATIVOS..............................................................................................................213.3 REQUISITOS DE USABILIDAD.........................................................................................................243.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

ReportingReporting. Este tipo de explotación se basa en el acceso a informes predef inidos conbaja posibilidad de modificación por el usuario.

Análisis. Permite:• Construir consultas no predef inidas de forma sencilla para el usuario f inal no técnicode manera f lexible.• Realizar análisis multidimensionales desde niveles de destalle agregados a niveles dedetalle desagregados.

Cuadro de mando. Entorno con capacidades visuales avanzadas, alto rendimiento yusabilidad que muestra indicadores clave sobre Educación para dar soporte a la tomade 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.

RF.ENT.4 El sistema debe ser capaz de recibir, validar, cargar y consolidar los datos 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.

RF.ENT.6 El sistema debe ser capaz de recibir, validar, cargar y consolidar los datos 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.

RF.ENT.8 El sistema debe ser capaz de recibir, validar, cargar y consolidar los datos 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.

RF.ENT.10 El sistema debe ser capaz de recibir, validar, cargar y consolidar los datos 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 guardada en base de datos, adaptada al destinatario y al o los ficheros 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 guardada en base de datos, adaptada al destinatario y al o los ficheros 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.

RF.AVI.2 Existirá un proceso que envíe avisos automáticos, vía correo electrónico, 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 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 guardada en base de datos, adaptada al destinatario y al o los ficheros 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 guardada en base de datos, adaptada al destinatario y al o los ficheros 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.

RF.AVI.3 Existirá un proceso que envíe avisos automáticos, vía correo electrónico, 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 guardada en base de datos, adaptada al destinatario y al o los errores de

Proyecto:

Edición: 18 Fecha:

consolidación encontrados en el fichero procesado. Se enviará cada vez que se encuentren errores de validación al procesar los ficheros.

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 contenidos en el fichero.


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: