sistema de generacion de horarios para …zeus.inf.ucv.cl/~jrubio/docs/2009-02/pet/material de...

Pontificia Universidad Católica de Valparaíso

Escuela de Ingeniería Informática

Magíster en Ingeniería Informática.

SISTEMA DE GENERACION DE HORARIOS PARA CURSOS

UNIVERSITARIOS

MII - 711 Administración de Proyectos Informáticos

Fecha: 26 de Junio de 2007 Profesor: Dr. Claudio Cubillos

Alumnos: José Maureira

José Miguel Rubio

Tabla de Contenidos 1. Introducción........................................................................................................................ 1 2. Charter del Proyecto ........................................................................................................... 3

2.1 Introducción.................................................................................................................. 3 2.1.1 Visión................................................................................................................. 3 2.1.2 Autoridades........................................................................................................ 3 2.1.3 Agentes .............................................................................................................. 3 2.1.4 Supuestos ........................................................................................................... 3

2.2 Descripción del Proyecto.............................................................................................. 3 2.2.1 Definición del Sistema....................................................................................... 3 2.2.2 Objetivos............................................................................................................ 4 2.2.3 Actores............................................................................................................... 4

2.3 Alcance del Proyecto .................................................................................................... 4 2.3.1 Entregables ........................................................................................................ 4 2.3.2 Programación..................................................................................................... 4 2.3.3 Ítems Fuera de Alcance ..................................................................................... 4

2.4 Supuestos...................................................................................................................... 5 2.5 Caso de Negocio........................................................................................................... 5

2.5.1 Beneficios ......................................................................................................... 5 2.5.2 Costos ................................................................................................................ 5

3. Planificación ....................................................................................................................... 6 3.1 Estructura de Desglose de Trabajo (EDT).................................................................... 6

3.1.1 Lista ................................................................................................................... 6 3.1.2 Diagramas .......................................................................................................... 8

3.2 Organigrama del Proyecto.......................................................................................... 12 3.3 Fichas de Tareas ......................................................................................................... 13

4. Plan de Riesgos................................................................................................................. 27 5. Programación.................................................................................................................... 30

5.1 Carta Gantt.................................................................................................................. 30 5.2 Diagrama de Precedencias.......................................................................................... 32 5.3 Diagrama de Cálculo de Fechas y Camino Crítico..................................................... 33 5.4 Diagramas de Uso de Recursos .................................................................................. 36

6. Estimación ........................................................................................................................ 38 6.1 Puntos de Función ...................................................................................................... 38 6.2 Cocomo....................................................................................................................... 39

7. Conclusión........................................................................................................................ 40

Administración de proyectos Informáticos

Sistema de Generación de Horarios para Cursos Universitarios

1

1. Introducción El problema de generación de horarios ha sido atacado a través de diferentes técnicas y con diferentes

resultados pero en muy pocos casos se ha aplicado a la resolución de problemas reales. Es por este motivo que

nos vemos obligados a aplicar una técnica de resolución innovadora basada en algoritmos híbridos entre la

optimización de colonias de hormigas y búsqueda local para resolver una instancia real de este problema,

generando así una herramienta computacional que entregue soluciones factibles optimas para esta clase de

problemas en Universidad de las Américas, campus Viña del Mar.

El Problema de optimización combinatorial al que nos enfocaremos se llama problema de generación de

Horarios (Timetabling). Se describe un problema que se presenta generalmente en un contexto educativo

(escuelas, universidades, conferencias). La base de este problema está en la tarea de poner los

acontecimientos genéricamente llamados eventos (cursos, clases, exámenes, lecciones, negociaciones) en un

horario. El horario se compone de un número limitado de unidades atómicas llamadas timeslots que se

ordenan y se agrupan generalmente en unidades más grandes como mañanas, tardes o días. Poner un

acontecimiento en el horario significa asignar el número requerido de timeslots consecutivos al

acontecimiento. Se debe considerar que se asumirá la duración de todos los eventos de forma uniforme y que

este largo corresponde al largo de un timeslot.

El problema de poner todos los eventos dentro de timeslots produce el hecho de que tenemos que ocuparnos

de restricciones duras (restricciones que necesariamente se tienen que cumplir) y de restricciones suaves, que

pueden no cumplirse, pero que provocan una reducción en la calidad del horario generado. Una restricción

dura presente en todos los problemas de timetabling es que ciertos pares de eventos no se pueden poner en el

mismo timeslot. Esto es debido al hecho de que a estos eventos asisten estudiantes, profesores o participantes

y que ninguno de ellos pueden asistir a dos eventos en el mismo tiempo. Así pues, ciertos eventos se deben

poner en diversos timeslot para evitar estas colisiones de horarios para los asistentes, ya sean profesores,

alumnos o participantes.

Además de estas restricciones duras que ofrecen todos los problemas timetabling, hay una gran diversidad de

modelos de estos problemas. En este proyecto nos centraremos en los problemas de asignación de horarios

(timetabling) para la Universidad. En este caso específico solamente un número limitado de eventos puede

ocurrir por timeslot y los eventos tienen que ser acomodados a las salas. Obviamente, podemos poner

solamente un acontecimiento por sala y no podemos separar generalmente un acontecimiento sobre dos salas.

Por otra parte, hay una variedad enorme de restricciones suaves que expresan características deseables de un

horario. A continuación se muestra, una selección de restricciones suaves:

• Ciertos timeslot deben ser evitados si es posible

• No muchos eventos para un estudiante particular en un día



2

• No tener solo un evento para un estudiante en un día

• No más que X eventos por estudiante dentro de Y timeslot consecutivos

• Intentar utilizar la menor cantidad de timeslot posibles

La creación manual de horarios manual aún con algunas pocas sesiones, puede tomar una cantidad

significativa de tiempo con solo algunas restricciones sencillas. Para una gran cantidad de cursos con un

conjunto complejo de restricciones esto es muy poco práctico.

Esto hace deseable encontrar una forma de generar automáticamente una programación de horarios a partir de

una descripción inicial de los profesores, alumnos, salones y las sesiones requeridas. El problema de

programación de horarios puede manifestarse en variadas formas todo dependiendo del entorno o Institución

en el que se vaya aplicar.

Para resolver el problema de la programación de horarios se han diseñado diversos algoritmos y se han

aplicado diversas estrategias de solución.

Asignar cursos a las salas de clase de Universidad de las Américas es cada vez una tarea más compleja, dada

la escasez de salas de clase y el crecimiento de la población estudiantil, y los criterios de asignación que se

deben resolver para lograr la tarea satisfactoriamente. Las salas de clase tienen diversas características que se

considerarán, por ejemplo: televisión, VHS, computadoras, proyectores de computadora, aire acondicionado,

etc. Una asignación aceptable debe resolver una variedad de condiciones, las más básicas (tales como la

necesidad de que cada curso debe ser asignado a una sala de clase, que no exista ningún traslapo de cursos en

las salas de clase, que la capacidad de los asiento sea la adecuada, y que una clase que se dicte en varios días

de la semana se asigne a la misma sala de clase), otras condiciones que puedan ser consideradas de

preferencia (por ejemplo son , que los cursos con pocos estudiantes no ocupen salas de clase con una gran

cantidad de sillas). De esta forma se tiene un problema a resolver, varias técnicas de resolución y herramientas

informáticas para lograr la mejor solución de este problema.



3

2. Charter del Proyecto

2.1 Introducción

2.1.1 Visión

Una mejora en la calidad de los horarios generados para los cursos de Universidad de las Américas (en

adelante UDLA), Campus Viña del Mar (en adelante vl), mediante la automatización de este proceso.

2.1.2 Autoridades

• Auspiciador Corporativo – Rodrigo Torres:

Supervisa la definición del detalle del proyecto y de los principales requisitos de los productos. Provee de

personal al proyecto y supervisa directamente al encargado de proyecto. Asegura que las necesidades del

negocio de la compañía sean satisfechas por el proyecto. Toma las decisiones finales.

• Auspiciador del Proyecto – Felipe Leighton:

Supervisa la definición del detalle del proyecto y de los principales requisitos de los productos. Provee de

personal al proyecto y supervisa directamente al encargado de proyecto. Asegura que las necesidades del

negocio de la compañía sean satisfechas por el proyecto. Toma las decisiones finales.

2.1.3 Agentes

José Rubio, encargado del proyecto: define en detalle el proyecto y los principales requisitos de los productos.

2.1.4 Supuestos

El equipo del proyecto se basa en los siguientes supuestos:

• Los sistemas informáticos actuales estarán disponibles para la integración de prueba con el nuevo sistema

el segundo semestre del presente año.

• Los recursos necesarios (capacitación del personal, computadores, personal, etc.) estarán disponibles

antes de la puesta en marcha del sistema.

2.2 Descripción del Proyecto

2.2.1 Definición del Sistema

El problema de generación de horarios ha sido atacado a través de diferentes técnicas y con diferentes

resultados pero en muy pocos casos se ha aplicado a la resolución de problemas reales. En este proyecto se

pretende aplicar una técnica de resolución innovadora basada en algoritmos híbridos de optimización de

colonias de hormigas y búsqueda local para resolver una instancia real de este problema, generando así una

herramienta computacional que entregue soluciones óptimas para esta clase de problemas aplicados, en

UDLA vl.



4

2.2.2 Objetivos • Crear un sistema computacional para la generación de Horarios en UDLA vl, haciendo uso de un

algoritmo hibrido basado en Optimización de Colonias de Hormiga y Búsqueda Local.

• Evaluar el rendimiento del algoritmo con una calificación en función de calidad de las soluciones, en

términos de la complejidad y de la violación de las restricciones impuestas a los horarios.

2.2.3 Actores Patrocinador: Rodrigo Torres, Director de Sede.

Patrocinador: Sergio Valenzuela, Director Académico Facultad de Ciencias de la Ingeniería.

Usuarios: Coordinadores de Área.

Usuarios: Coordinadores de Carrera.

Clientes: Alumnos de programas de pregrado, diurno y vespertino.

Clientes: Alumnos de programas executive.

2.3 Alcance del Proyecto

2.3.1 Entregables • Sistema de Ingreso de programas de carreras de pregrado.

• Sistema de Ingreso disponibilidad de profesores y salas.

• Motor de generación de horarios.

• Motor para exportación de horarios generados a formato Excel y PDF.

• Integración con sistema de administración académica.

• Manuales de usuario.

2.3.2 Programación Se anticipa un marco general de 10-12 meses de desarrollo.

El proyecto espera partir el S2 2007 para completarse el S2 2008

La versión 1.0 se espera a los 10 meses y su entrega a los 2-4 meses posteriores.

2.3.3 Ítems Fuera de Alcance • Infraestructura de Seguridad.

• Sistema de Ayuda.

• Integración con sitio Web corporativo.

• Sistema de reserva de laboratorios y salas.

• Sistema de Ingreso preferencias de profesores.



5

2.4 Supuestos • Se reutilizará la infraestructura tecnológica (hardware y software) disponible.

• El sistema se construirá según una arquitectura cliente-servidor

• El cliente entregará expertos del negocio durante el desarrollo.

• El sistema correrá en los computadores y red existentes.

• El cliente firmará los entregables intermedios dentro de 1 semana de la entrega.

• Todos los datos a importar estarán disponibles en formato Excel.

• Esta será una aplicación de escritorio.

2.5 Caso de Negocio

Si bien el proyecto no es crítico para la organización puesto que no se relaciona directamente con el ámbito

del negocio de esta (educación superior), este permitirá optimizar uno de sus principales procesos; la

planificación y asignación de recursos humanos y materiales de forma óptima.

2.5.1 Beneficios

La realización de este proyecto permitirá a UDLA vl:

• Una disminución entre un 80 y 90% en el tiempo requerido para la generación de horarios.

• Mejora en la calidad de los horarios ofrecidos tanto a sus alumnos como a sus profesores.

• Utilización óptima de los recursos disponible.

2.5.2 Costos

Durante la ejecución de este proyecto UDLA vl incurrirá en los siguientes costos:

• Se espero que este proyecto cueste $ 6.900.000 destinados completamente a financiar el personal del

proyecto.

• El proyecto comprenderá la mayor parte del trabajo de mantenimiento de los sistemas asociados al

proceso de generación de horarios existente.

.



6

3. Planificación

3.1 Estructura de Desglose de Trabajo (EDT)

3.1.1 Lista

0. Sistema de Generación de Horarios para Cursos Universitarios

1. Especificar requerimientos.

1.1. Análisis del Sistema Actual.

1.2. Especificar Necesidades a Satisfacer.

1.3. Estudio y Análisis Técnicas de Resolución Específicas.

1.4. Evaluación y Definición Técnicas de Resolución a Aplicar.

2. Etapa de Análisis

2.1. Definir Proceso de Generación de Horarios.

2.2. Estudiar Procesos Organizacionales Asociados.

2.3. Estudiar y Definir Datos de Entrada del Proceso.

2.4. Definir Interfaces de Comunicación con los Sistemas Actuales.

3. Etapa de Diseño

3.1. Diseño del programa

3.1.1. Diseñar algoritmo de asignación.

3.1.2. Diseñar algoritmo de optimización.

3.2. Diseño Funcional

3.3. Diseño de Interfaces de Usuario

3.4. Diseño de Interfaces de comunicación.

3.5. Diseñar Base de Datos

3.6. Diseño de Casos de Prueba

4. Implementación

4.1. Codificar algoritmo de asignación.

4.2. Codificar algoritmo de optimización.

4.3. Implementar Base de Datos

4.4. Implementar Interfaces de usuario.

4.5. Implementar Interfaces de comunicación.

5. Pruebas

5.1. Pruebas Unitarias

5.1.1. Prueba Unitaria Base de Datos

5.1.2. Prueba Unitaria Interfaces de Usuario

5.1.3. Prueba Unitaria Interfaces de Comunicación

5.2. Corrección de errores

5.3. Pruebas de Integración



7

5.4. Pruebas del Sistema

6. Evaluación de Rendimiento y Ajustes

6.1. Iteración 1

6.1.1. Evaluación Tiempo de Respuesta

6.1.2. Evaluación Calidad de la Solución

6.1.3. Análisis de Resultados

6.1.4. Ajuste de Parámetros y Función Objetivo

6.2. Iteración 2





6.3. Iteración 3





7. Cierre del proyecto

7.1. Elaboración Manual de usuario.

7.2. Capacitación de usuarios.



8

3.1.2 Diagramas

• Diagrama General:

Figura 1. Fases Principales del Proyecto

• Desglose de Cada Fase

1. Especificación de

Requerimientos

1.1 Análisis del Sistema

Actual

1.2 Especificar Necesidades

del Cliente

1.3 Estudio y Análisis de

Técnicas de Resolución

Especificas

1.4 Evaluación y Definición

de Técnicas a Aplicar

Figura 2. Desglose Fase 1: Especificación de Requerimientos



9

Figura 3. Desglose Fase 2: Análisis

Figura 4. Desglose Fase 3: Diseño



10

4. Implementación

4.1 Codificación Algoritmo de

Asignación

4.2 Codificación Algoritmo de

Optimización

4.3 Implementar Base de Datos

4.4 Implementar Interfaces de

Usuario

4.5 Implementar Interfaces de

Comunicación

Figura 5. Desglose Fase 4: Implementación

5.1 Pruebas Unitarias

5.2 Corrección de Errores

5.3 Pruebas de Integración

5.4 Pruebas del Sistema

5.1.1 Pruebas Unitarias de

Base de Datos


Interfaces de Usuario


Interfaces de Comunicación

5. Pruebas

Figura 6. Desglose Fase 5: Pruebas



11

6. Evaluación de

Rendimiento

6.1 Iteración 1

6.1.1 Evaluación del Tiempo

de Respuesta

6.1.2 Evaluación de la

Calidad de la Solución

6.1.3 Análisis de Resultados

6.1.4 Ajuste de Parámetros y

Función Objetivo

6.2 Iteración 2


de Respuesta





Función Objetivo

6.3 Iteración 3


de Respuesta





Función Objetivo

Figura 7. Desglose Fase 6: Evaluación de Rendimiento



12

7. Cierre del Proyecto

7.1 Elaboración Manual de

Usuarios

7.2 Capacitación a Usuarios

Figura 8. Desglose Fase 7: Evaluación de Rendimiento

3.2 Organigrama del Proyecto

Figura 9. Organigrama del Equipo de Proyecto

Encargado de Proyecto

Analista Programador 1



Auspiciador Corporativo

Auspiciador del Proyecto



13

3.3 Fichas de Tareas

Especificación de Tarea

Número: 1.1

Nombre: Análisis del Sistema Actual

Descripción: Descripción del sistema actual de generación de horarios

Personas: Encargado de Proyecto

Esfuerzo Estimado: 5 Día/Hombre

Duración: 5 días

Entregables: Documento de Especificación de Requerimientos

Predecesoras:


Número: 1.2

Nombre: Especificar Necesidades a Satisfacer

Descripción: Definición de problemas y necesidades no cubiertas del sistema actual

Personas: Analista Programador 1


Duración: 2 días


Predecesoras: 1.1 (FC)


Número: 1.3

Nombre: Estudio y Análisis Técnicas de Resolución Específicas

Descripción: Análisis de técnicas disponibles para modelar y resolver el problema de generación

de horarios.



Duración: 2 días





14


Número: 1.4

Nombre: Evaluación y Definición Técnicas de Resolución a Aplicar

Descripción: Se evalúan las técnicas de modelamiento y resolución disponibles y se escoge la más

adecuada según las características del problema.



Duración: 2 días




Número: 2.1

Nombre: Definir Proceso de Generación de Horarios

Descripción: Se describe en detalle el proceso de generación de horarios



Duración: 4 días

Entregables: Documento de Análisis

Predecesoras: 1 (FC)


Número: 2.2

Nombre: Estudiar Procesos Organizacionales Asociados

Descripción: Se describen y establecen dependencias entre el proceso de generación de horarios y

los otros procesos organizacionales



Duración: 2 días





15


Número: 2.3

Nombre: Estudiar y Definir Datos de Entrada del Proceso

Descripción: Se describen en detalla los datos de entrada para el proceso de generación de horarios



Duración: 2 días




Número: 2.4

Nombre: Definir Interfaces de Comunicación con los Sistemas Actuales

Descripción: Se describen en detalle las necesidad de comunicación con los sistemas existentes



Duración: 2 días




Número: 3.1.1

Nombre: Diseñar algoritmo de asignación

Descripción: Se diseña el algoritmo de asignación de horarios, profesores y salas de clases



Duración: 4 días

Entregables: Documento de Diseño




16


Número: 3.1.2

Nombre: Diseñar algoritmo de optimización

Descripción: Se diseña el algoritmo de optimización para las asignaciones posibles y se define la

función objetivo



Duración: 6 días


Predecesoras: 3.1.1 (FC)


Número: 3.2

Nombre: Diseño Funcional

Descripción: Se diseña y refina el modelo de casos de uso general del sistema



Duración: 5 días




Número: 3.3

Nombre: Diseño de Interfaces de Usuario

Descripción: Se diseñan los prototipos de interfaces de usuario gráficas del sistema



Duración: 2 días





17


Número: 3.4

Nombre: Diseño de Interfaces de comunicación

Descripción: Se diseñan las interfaces de comunicación con los sistemas existentes



Duración: 2 días




Número: 3.5

Nombre: Diseñar Base de Datos

Descripción: Se diseña el modelo de la base de datos a implementar



Duración: 4 días




Número: 3.6

Nombre: Diseño de Casos de Prueba

Descripción: Se diseñan los casos de prueba unitaria de caja negra para el sistema



Duración: 3 días

Entregables: Documento de Casos de Prueba




18


Número: 4.1

Nombre: Codificar algoritmo de asignación

Descripción: Se implementa en lenguaje C++ el algoritmo para asignación de salas, horarios y

profesores



Duración: 4 días

Entregables: Programa de asignación



Número: 4.2

Nombre: Codificar algoritmo de optimización

Descripción: Se implementa en lenguaje C++ el algoritmo para optimización de la asignación



Duración: 5 días

Entregables: Programa de optimización



Número: 4.3

Nombre: Implementar Base de Datos

Descripción: Se implementa el modelo de datos en SQL Server



Duración: 2 días

Entregables: Base de Datos




19


Número: 4.4

Nombre: Implementar Interfaces de usuario

Descripción: Se implementan los prototipos de interfaces



Duración: 4 días

Entregables: Interfaces del Sistema

Predecesoras: 3.5 (FC), 3.2 (FC)


Número: 4.5

Nombre: Implementar Interfaces de comunicación

Descripción: Se implementa la comunicación del sistema con los sistemas ya existentes



Duración: 2 días

Entregables: Interfaces de Comunicación



Número: 5.1.1

Nombre: Prueba Unitaria Base de Datos

Descripción: Se prueba el rendimiento de la base de datos



Duración: 1 día

Entregables: Documento de Pruebas Unitarias




20


Número: 5.1.2

Nombre: Prueba Unitaria Interfaces de Usuario

Descripción: Se evalúan la facilidad de uso de las interfaces



Duración: 1 día




Número: 5.1.3

Nombre: Prueba Unitaria Interfaces de Comunicación

Descripción: Se prueba la comunicación con los sistemas existentes



Duración: 1 día




Número: 5.2

Nombre: Corrección de errores

Descripción: Se corrigen los errores detectados en las pruebas unitarias



Duración: 2 días

Entregables:




21


Número: 5.3

Nombre: Pruebas de Integración

Descripción: Se prueba la integración de los componentes del sistema



Duración: 2 días

Entregables: Documento de Pruebas del Sistema



Número: 5.4

Nombre: Pruebas del Sistema

Descripción: Se prueba el sistema completo



Duración: 5 días

Entregables: Documento de Pruebas del Sistema



Número: 6.1.1

Nombre: Evaluación Tiempo de Respuesta

Descripción: Se evalúa el tiempo de respuesta del sistema para la generación de horarios


Esfuerzo Estimado: 0,5 Día/Hombre

Duración: 0,5 día

Entregables: Documento de Evaluación y Ajustes




22


Número: 6.1.2

Nombre: Evaluación Calidad de la Solución

Descripción: Se evalúa la calidad de la solución optima generada



Duración: 0,5 día




Número: 6.1.3

Nombre: Análisis de Resultados

Descripción: Se analizan los resultados obtenidos en cuanto a tiempo de respuesta y calidad



Duración: 1 día


Predecesoras: 6.1.1 (FC), 6.1.2 (FC)


Número: 6.1.4

Nombre: Ajuste de Parámetros y Función Objetivo

Descripción: Se ajustan los parámetros del algoritmo de asignación y/o se modifica la función

objetivo



Duración: 1 día





23


Número: 6.2.1





Duración: 0,5 día




Número: 6.2.2





Duración: 0,5 día




Número: 6.2.3





Duración: 1 día


Predecesoras: 6.2.1 (FC), 6.2.2 (FC)



24


Número: 6.2.4



objetivo



Duración: 1 día




Número: 6.3.1





Duración: 0,5 día




Número: 6.3.2





Duración: 0,5 día





25


Número: 6.3.3





Duración: 1 día

Entregables: 6.3.1 (FC), 6.3.2 (FC)

Predecesoras:


Número: 6.3.4



objetivo



Duración: 1 día




Número: 7.1

Nombre: Elaboración Manual de usuario

Descripción: Se desarrolla el documento “manual de uso del sistema”



Duración: 3 días

Entregables: Manual de Usuario




26


Número: 7.2

Nombre: Capacitación de usuarios

Descripción: Se capacita a los usuarios del sistema para el uso de este



Duración: 5 días

Entregables:




27

4. Plan de Riesgos

4.1 Lista de Riesgos Ranking Descripción P I E*

1 Esfuerzo de desarrollo e implementación de los algoritmos de resolución subestimado.

3 3 9

2 Las técnicas de resolución no son comprendidas por todo el equipo.

3 2 6

3 El personal académico de UDLA no entrega la información requerida a tiempo.

3 2 6

4 Las restricciones necesarias para modelar el problema se tornan inestables.

2 3 6

5 Esfuerzo de integración con los sistemas actuales subestimado.

3 2 6

6 El sistema ofrece un pobre rendimiento en calidad y tiempo de respuesta de las soluciones.

2 3 6

7 Se incorporan requerimientos adicionales.

3 2 6

8 La dirección de UDLA no entrega toda la información requerida para el modelamiento.

2 2 4

9 El proceso de generación de horarios no está bien definido.

2 2 4

10 Problemas de comunicación del lenguaje de programación con las bases de datos de UDLA.

1 3 4

11 Las técnicas de resolución escogidas no son las mejores para el problema en cuestión.

2 2 4

12 Dificultades de comunicación con el experto UDLA.

1 3 3

13 El sistema ofrece un nivel bajo de usabilidad.

2 1 2

* E=Exposición al Riesgo = P (Probabilidad del Riesgo) × I (Impacto o Severidad del Riesgo)

4.2 Gestión de Riesgos Descripción Mitigación Contingencia Responsable Esfuerzo de desarrollo e implementación de los algoritmos de resolución subestimado.

Se deberá capacitar al personal de programación en las técnicas a utilizar para el proyecto.

Se contratará personal adicional con experiencia en las técnicas de programación empleadas.

José Rubio

Las técnicas de resolución no son comprendidas por todo el equipo.

Se dictarán charlas y se entregará material de estudio acerca de las técnicas a todo el equipo del proyecto.

Se contratará un asesor experto en las técnicas de resolución empleadas.

José Rubio

El personal académico de

Se debe comprometer e informar al personal académico acerca de la

Se emplea información recopilada de semestres anteriores

Felipe Leighton



28

UDLA no entrega la información requerida a tiempo.

realización del proyecto. proporcionada por el auspiciador del proyecto.

Las restricciones necesarias para modelar el problema se tornan inestables.

Se debe comprometer al auspiciador corporativo y al auspiciador del proyecto en la definición de restricciones.

Se emplean restricciones empleadas en semestres anteriores proporcionadas por el auspiciador del proyecto

José Rubio

Esfuerzo de integración con los sistemas actuales subestimado.

Se debe realizar un análisis detallado de los sistemas existentes.

Se debe redefinir el alcance del proyecto.

José Maurerira

El sistema ofrece un pobre rendimiento en calidad y tiempo de respuesta de las soluciones.

Se debe realizar un análisis detallado de las técnicas de optimización disponibles.

Se vuelve a iterar sobre la fase de construcción y pruebas del algoritmo de optimización para obtener mejores resultados.

José Maureira

Se incorporan requerimientos adicionales.

El alcance del proyecto se establece en conjunto con el auspiciador del proyecto y el auspiciador corporativo.

Se modifica el alcance del proyecto y se estima el esfuerzo requerido para incluir los nuevos requerimientos.

José Rubio

La dirección de UDLA no entrega toda la información requerida para el modelamiento.

Se debe comprometer al auspiciador corporativo del proyecto con la entrega de la información requerida.

No Aplica Felipe Leighton

El proceso de generación de horarios no está bien definido.

Se debe analizar el sistema actual de generación de horarios.

No Aplica José Rubio

Problemas de comunicación del lenguaje de programación con las bases de datos de UDLA.

Se estudia la compatibilidad de las bases de datos de UDLA con las herramientas de desarrollo a utilizar en el proyecto.

No Aplica José Maureira

Las técnicas de resolución escogidas no son las mejores para el problema

Se debe realizar un análisis previo detallado del problema y de las técnicas de resolución disponibles.

No Aplica José Rubio



29

en cuestión. Dificultades de comunicación con el experto UDLA.

El auspiciador del proyecto y el encargado del proyecto establecen lazos fuertes de comunicación y confianza antes del comienzo del mismo.

No aplica José Rubio

El sistema ofrece un nivel bajo de usabilidad.

Se calendarizan pruebas de usabilidad para las interfaces de usuario.

No aplica José Maureira



30

5. Programación

5.1 Carta Gantt



31



32

5.2 Diagrama de Precedencias



33

5.3 Diagrama de Cálculo de Fechas y Camino Crítico



34



35



36

5.4 Diagramas de Uso de Recursos

• Encargado de Proyecto

• Analista Programador 1



37

• Analista Programador 2

• Analista Programador 3 •



38

6. Estimación

6.1 Puntos de Función Entradas Externas: Cantidad de Alumnos Preinscritos, Profesores, Salas, Horarios, Mallas curriculares.

Salidas Externas: Asignación de Horarios.

Consultas: No Aplica.

Archivos Lógicos Internos: Profesores, Profesor-Asignatura, Asignatura-Salas, Asignatura-Horario.

Archivos de Interfaz Externos: Navegador Académico.

Simple Media Compleja

Cantidad *Peso Cantidad *Peso Cantidad *Peso

Total

(PFSA)

Entradas 1 *3 3 *4 1 *6 21

Salidas 0 *4 0 *5 1 *7 7

Consultas 0 *3 0 *4 0 *6 0

Arch.Lógicos 1 *7 3 *10 0 *15 37

Arch.Interfaz 0 *5 1 *7 0 *10 7

72

Valores de ajuste de Complejidad Escala de

Complejidad

1 Comunicación de datos 3

2 Procesamiento Distribuido 3

3 Rendimiento 5

4 Conf. Operacional Compartida 0

5 Tasa de Transacciones 0

6 Entrada de datos en línea 5

7 Facilidad de uso de la aplicación 3

8 Actualizaciones en línea 0

9 Complejidad de procesamiento 5

10 Reusabilidad del código 3

11 Contempla la Conversión e Instalación 0

12 Facilidades Operacionales 0

13 Instalaciones Múltiples 1

14 Facilidad de cambio 3

Valor de ajuste de Complejidad (FC) 31

Tabla 1.Calculo de Puntos de Función sin Ajustar y Factores de Complejidad



39

PFA = PFSA × (0,65 + (0,01 × FC) = 72 × (0,65 + (0,01 × 31) = 72 × (0,65 + 0,31) = 72 × 0,96 = 69,12

LCOT (Líneas de Código Totales) = PFA × Promedio Líneas (Lenguaje C++) = 69,12 × 53 = 3663,36

KDSI (Miles de Líneas de Código) = 4

6.2 Cocomo El tipo de COCOMO utilizado para esta estimación fue el del tipo básico Orgánico.

Proyecto de Software a b c D

Orgánico 2,4 1,05 2,5 0,38

Tabla 2.Parámetros para Cocomo según Proyecto Orgánico

KDSI = Obtenido en el Punto de función = 4

E (Esfuerzo) = a × (KDSI ^ b) = 2,4 × (4 ^ 1,05)= 10,28 (personas * mes)

T (Tiempo) = c × (E ^ d) = 2,5 × (10,28 ^ 0,38) = 6 (meses)

P (Cantidad de Personas) = E/T =10,28 / 6 = 1,71 = 2



40

7. Conclusión La experiencia señala que la administración de Proyectos definitivamente es una ventaja competitiva para las

empresas que la utilicen formalmente, considerando ésta como la aplicación de conocimientos, habilidades,

herramientas y técnicas, orientados a un conjunto de actividades necesarias para cumplir con los

requerimientos de un proyecto específico.

Ventaja competitiva, debido a que permite a las organizaciones incrementar su nivel de eficacia y eficiencia

(productividad), maximizando el uso de sus recursos financieros, materiales y de capital humano, dentro de

los tiempos establecidos para el desarrollo del producto o servicio, sobre todo en el ámbito de los proyectos de

innovación tecnológica.

Universidad de las Américas está gradualmente reconociendo la necesidad de especialización y está valorando

cada vez más el colocar gerentes de proyecto profesionales al frente de sus proyectos de innovación. Sin

embargo, la realización y administración de proyectos requiere una visión integral que vincule los factores

que determinan el éxito o fracaso del mismo. Dichos factores son varios y su incidencia en los proyectos varía

de un proyecto a otro.

A pesar de todos los esfuerzos por estandarizar y aplicar técnicas de gestión de proyectos, la probabilidad de

que finalicen con éxito sigue siendo muy baja. La implantación de un Sistema de Calidad, que efectivamente

se aplique, se mantenga y se revise periódicamente, ayudará a prevenir y controlar los problemas y los riesgos

habituales de los proyectos informáticos, aunque no será una garantía del éxito de los mismos. Una clave

importante sigue siendo hoy en día el recurso humano y muy especialmente la experiencia del líder de

proyectos.

Es un hecho que aún necesitamos seguir preguntándonos, a pesar de todo el trabajo realizado, acerca de ¿será

exitoso este proyecto informático? y hasta que no se haya concluido el proyecto, se debe seguir ajustando esta

planificación, seguir investigando y corrigiendo los errores posibles, registrando las verdaderas causas que

propiciaron dichos errores con el objeto de que no se produzcan en el futuro y en otros proyectos de esta

naturaleza.

sistema de generacion de horarios para …zeus.inf.ucv.cl/~jrubio/docs/2009-02/pet/material de...

Documents