PLAN GENERAL DEL PROYECTO

“Sistema Geminis”

1.  Introducción

                                   

Uno de los objetivos que persigue el Plan Maestro de Informática y Telecomunicaciones (PMIT-UD) es promover un sistema de información integral que soporte los servicios institucionales. Para ello, y tomando en cuenta las necesidades que permitan apoyar los procesos misionales de la Universidad, la Oficina Asesora de Sistemas, a través del proyecto “Sistema Institucional de Información UD”, ha establecido el desarrollo de los siguientes subproyectos que a su vez constituyen los 4 componentes del Sistema de Información de la Universidad, estos son:

El presente documento se denomina Plan General de Proyecto y define los parámetros para realizar el direccionamiento y seguimiento al proyecto. Especifica los objetivos de alto nivel de las iteraciones y sus correspondientes hitos.

2. Antecedentes del Proyecto

Con la puesta en marcha de la Aplicación Académica desde 1982 en la Universidad Distrital se da inicio a la automatización de algunos procesos de tipo académico. Durante los primeros años la información fue administrada por entidades externas, pero finalmente la Universidad asumió el manejo de su información por medio de la Oficina Asesora de Sistemas. Con la experiencia adquirida por la Oficina se fueron automatizando más procesos por medio de la Aplicación Académica. Ya en el 2005 se dio inicio a la conversión de esta aplicación en un Sistema Web. al que se le denominó Sistema Cóndor, permitiendo a los estudiantes y docentes (entre otros) consultar y gestionar servicios académicos de la Universidad desde Internet las 24 horas del día. El beneficio se ha hecho notorio en los estudiantes pues en procesos como adición de asignaturas, algunos de ellos pasaban la noche a las puertas de la Universidad esperando la mañana para ser atendidos.

El Sistema de información académico–administrativo ha tenido un desarrollo extensivo en los últimos veinte años; sin embargo, su cobertura no ha sido suficiente debido a cambios en la visión Institucional de la Universidad Distrital que  han producido desfases en la planificación relacionada con las Tecnologías de la Información(TI), en la cual no se tenía en cuenta aún los componentes tecnológicos como elementos transversales a todos los procesos de la Universidad. Este hecho genera un despliegue mínimo del gobierno de TI y una pobre alineación de éste con los gobiernos institucionales y los modelos de calidad y seguridad.

Los procesos académico de la Universidad Distrital están sólo parcialmente  automatizados, mientras que la información de aquellos procesos que no están considerados en el sistema de información institucional no se encuentra identificada, clasificada ni analizada. Así, las tareas de agregación, consolidación y generación de informes presentan grandes dificultades. La sincronización de la información se realiza de forma manual o semi-automatizada, lo que genera redundancia y falta de integridad en los datos que la Universidad maneja.

Hoy en día sólo está en uso en la Universidad Sistema Cóndor, que aunque, involucra gran parte de los procesos académicos en su estructura, opera como un híbrido que ha pasado por varias fases de desarrollo, cada una de las cuales mantiene su herencia. En la primera fase se implementaron desarrollos aunque funcionales presentaban diversas vulnerabilidades en el aspecto de seguridad, adicionalmente todavía carecía de ser el resultado de un proceso de desarrollo estandarizado y documentado, y, adicionalmente, estaba limitado por no disponer de la separación de los ambientes de pruebas y producción.

En la segunda fase, en el año 2009, se da inicio al desarrollo y adopción de la metodología de desarrollo OPENUP/OAS, y a la reconstrucción del proyecto Sistema Cóndor en uno nuevo que recibió internamente el nombre de Sistema de Gestión Académica. Durante esta fase se impulsaron los desarrollos necesarios en Cóndor para implementar el sistema de créditos y flexibilidad curricular en la Universidad, y se efectúo la transición que dió lugar, cuando finaliza esta fase a inicios de 2014, en la absorción y cierre de todas las funcionalidades de la antigua aplicación académica en Cóndor.

A estas alturas se observa que el Sistema Cóndor ha obtenido importantes mejoras, no obstante no ha alcanzado a satisfacer las expectativas de cobertura, por ejemplo no incluye los servicios de gestión académica para posgrados, calendario académico ni módulos de administración que entreguen la responsabilidad de la información y el control de los procesos a los usuarios destinatarios, por otra parte no logra implementar características de arquitectura y diseño que permitan identificar el estado de sus procesos y servicios y es deficiente en la entrega de reportes, e identificación y resolución de inconsistencias de información.

Por los anteriores elementos relacionados se propone, a mediados del 2014, una nueva fase que renueve, complete y las características en las que aún es deficiente este sistema.

3. Problema/Necesidad institucional a ser resuelta

El problema de

                

Gestionar los procesos académicos de la Universidad en el marco de un sistema coherente con dichos procesos, confiable y aceptado por la comunidad universitaria, versátil a la hora de ajustar sus reglas de operación entre las probables variantes que puedan escoger sus usuarios clientes e interesados, reconstruible en toda condición de operación programada para sustentar sus contenidos de información en cualquier tiempo, sencillo de consultar y actualizar, y que responda apropiadamente a las necesidades del modelo de negocio y sus particularidades, tal como se dá en esta institución, e integrado al ECOSIIS según la especificación del Plan Maestro de Informática y Telecomunicaciones.

Afecta         Principalmente a

                                        

                

Las comunidades de usuarios Aspirantes, Estudiantes, Docentes, Directivas y otros usuarios claves en los procesos académicos, incluyendo clientes  en otros sistemas.

El impacto del problema es

                        

                                        

                

- Percepción negativa del sistema de información académica al interior y exterior de la Universidad.

- Algunas inconsistencias en los contenidos de información.

- Inapropiada representación de los procesos académicos

- Demoras en la entrega de información.

- Sin solución efectiva en el flujo de los procesos de interés de determinados componentes.

- Capacidad limitada para sustentar la responsabilidad de los usuarios respecto de la información registrada en él.

- Altamente dependiente de los recursos de soporte para su mejor utilización, lo que incide en la dilatación de los procesos.

- Baja de la confianza de los usuarios en el sistema.

- Dificultades en la administración del sistema de información.

- Demora en la incorporación de mejoras.

- Carencia de elementos de integración en el modelo ambiente ECOSIIS.

Una solución con éxito debería ser                                        

                

- Un Sistema de Administración de Información Académico basado en tecnologías Web, orientado a servicios, escalable, modular, con mecanismos que garanticen la confidencialidad, integridad, disponibilidad de la información así como la acertada y confiable autenticación de los usuarios.

- Debería ser muy amigable e incluir numerosos mecanismos de consulta y la facilidad para obtener todo tipo de reportes de los procesos en curso.

- Ser completo e integral de manera que los usuarios cuenten con las herramientas suficientes para la administración de sus procesos y para ejercer la responsabilidad sobre su información.

- Integrada al ECOSIIS en su aspecto tecnológico y de arquitectura.

                                   

4. Enfoque de Desarrollo

Alternativa 1:  Adquirir e implantar productos comerciales que ofrezcan soluciones integradas de software que cumplan con los requerimientos institucionales.

Esta alternativa incluye los siguientes aspectos:

(1) Captura de requerimientos institucionales , (2) elaboración de términos de referencia, (3) selección del proveedor y el producto, (4) proceso de aceptación del Software – Conformidad con los requerimientos, (5) proceso de Instalación, (6) proceso de Adaptación, (7) proceso de pruebas, (8) proceso de capacitación, (9)proceso de mantenimiento.

Junto con los elementos conexos asociados a la administración del contrato y la gestión de calidad en la adquisición del producto.

Alternativa 2: Diseñar, construir e implementar una solución a la medida que cumpla con los requerimientos institucionales.

Esta alternativa incluye los siguientes aspectos:

(1) Captura de requerimientos institucionales, (2) diseño de solución, (3) elaboración de la solución, (4) proceso de instalación, (5) proceso de integración, (6) proceso de pruebas, (7) proceso de capacitación, (8) proceso de mantenimiento.

Junto con los elementos conexos asociados a la administración del proyecto y la gestión de calidad en el desarrollo del producto.  

Alternativa 3:

Adquirir e implementar soluciones de software libre y diseñar, construir e implementar elementos propios que en conjunto cumplan los requerimientos institucionales.

Esta alternativa incluye:

(1) Captura de requerimientos institucionales, (2) selección del producto, (3) diseño de la solución, (4) proceso de aceptación del Software – Conformidad con los requerimientos, (5) elaboración de la solución, (6) proceso de instalación, (7) proceso de adaptación e integración, (8) proceso de pruebas, (9) proceso de capacitación, (10) proceso de mantenimiento.

Junto con los elementos conexos asociados a la administración del proyecto y la gestión de calidad en la adquisición, desarrollo y mantenimiento del producto.

Alternativa Seleccionada

Alternativa 2: Diseñar, construir e implementar una solución a la medida que cumpla con los requerimientos institucionales.

Esta alternativa incluye los siguientes aspectos:

(1) Captura de requerimientos institucionales, (2) diseño de solución, (3) elaboración de la solución, (4) proceso de instalación, (5) proceso de integración, (6) proceso de pruebas, (7) proceso de capacitación, (8) proceso de mantenimiento.

Junto con los elementos conexos asociados a la administración del proyecto y la gestión de calidad en el desarrollo del producto. 

5. Arquitectura General del Sistema

https://www.draw.io/?#G0B5drzSU0WfUtZHVMdWVGemo5MEU

6. Objetivos del Proyecto

6.1. Objetivo General

Promover el desarrollo, establecimiento y consolidación de un sistema de gestión académica que con orientación a servicios apoye los procesos académicos, con flexibilidad se ajuste a las variaciones de requerimientos en los procesos y el registro de información, y que se inscriba en el modelo de comunidades, miembros y espacios virtuales del ECOSIIS.

Se especifica para el sistema ser seguro, bien definido, desarrollado, probado e implementado, que introduzca técnicas avanzadas de desarrollo de software y aplique el Proceso de Desarrollo OPENUP/OAS vigente en la Universidad Distrital con un término de tres años para el logro de sus metas.

6.2. Objetivos Específicos

6.3. Duración del Proyecto

Fecha de Inicio : 1 de Junio de 2014

Fecha Final :  30 diciembre de 2014

Tiempo total : 18 meses

6.4. Cronograma General

Disciplina

Artefacto

FASE DE INICIO

FASE DE ELABORACIÓN

FASE DE CONSTRUCCIÓN

FASE DE TRANSICIÓN

2014

2015

Iter 0

Iter 1

Iter 8

Iter 29

Gestion del proyecto

Plan General del Proyecto

x

x

x

Cronograma

x

x

x

Plan y tratamiento de Riesgos

x

x

x

Gestion de Requerimientos

Vision del Proyecto

x

x

x

Requerimientos y requisitos

x

x

x

Diagramas de Casos de Uso

x

x

Especificaciones de Caso de Uso

x

x

Glosario

x

x

x

Diagrama de Actividades

x

x

x

Arquitectura

Bloc de Notas de la Arquitectura

x

x

x

x

Diseño

Diagramas de Clases

x

x

x

Arquitectura de Datos

x

x

x

Diagrama de secuencia

x

x

x

Desarrollo

Codigo fuente

x

x

x

Gestión de Pruebas

Especificaciones de Caso de Prueba

x

x

x

Aplicación de pruebas funcionales y no funcionales

x

x

x

Despliegue

Manuales y/o tutoriales de usuario

x

x

x

7.  Interesados y Colaboradores

                                   

La Oficina asesora de Sistemas tiene un compromiso de calidad en el desarrollo de software. Para garantizar el adecuado cumplimiento de los requerimientos funcionales y no funcionales se ha identificado el siguiente grupo de interesados y colaboradores

Estudiantes

Docentes

Coordinadores

Decanos

Vicerrector Académico

Asistente Coordinación

8. Equipo de Trabajo Base

Integrante del Equipo

Roles que desempeña

Paulo Cesar Coronado Sanchez

Director del Proyecto

Carlos Rodriguez  Jimenez

Jefe de Proyecto

Diana Leonor Tinjaca Rodriguez

Lider de Proyecto e ingeniero de proceso

Arquitecto

Fernando Torres

Fausto Puerto

Analista

Violeta Sosa, Carlos Romero,

Fernando Torres

Desarrolladores

9. Declaración de Trabajo

El proceso OpenUP/OAS propende por un enfoque iterativo e incremental, en donde el equipo de trabajo, durante las fases de Inicio, Elaboración, Construcción y Transición; recorre varias veces las siguientes áreas de trabajo: