Este documento describe los requerimientos generales que capturan el wish-list para el sistema, es decir la unión de todo lo que se desearía que tuviera el sistema si tuviéramos recursos ilimitados.

1. Breve descripción del sistema

El objetivo del software es apoyar la Coordinación de la Carrera en los procesos repetitivos que involucran consultas al pensum relacionadas con los estudios realizados por los estudiantes de la carrera. Para ello el software debe ayudar a determinar:

• Las asignaturas que ha aprobado el estudiante, así como las que cursa actualmente;
• Las asignaturas aprobadas y en curso de un estudiante en el nuevo pensum;
• Las asignaturas que tiene que cursar y aprobar ese estudiante en el nuevo pensum;
• Un plan para que ese estudiante culmine la carrera. Un plan para un estudiante indica las asignaturas que dicho estudiante debe cursar, por trimestre, hasta culminar la carrera. En Delta Pensum este plan recibe el nombre de Recomendación Curricular.


Se encuentra disponible un glosario de términos utilizados en Delta Pensum.

• Coordinador y al Asistente de la Coordinación de la Carrera en las consultas que  le puedan hacer los estudiantes sobre cómo les puede afectar un cambio de pensum, qué asignaturas les conviene inscribir el próximo trimestre, en cuánto tiempo pueden graduarse, qué carga deben cursar y planes alternativos de estudio.
• Estudiante de la carrera, en su planificación curricular tanto en épocas de pensum estable como en épocas de cambio de pensum, antes de recurrir a la Coordinación de su carrera.

2. Las metas del sistema

1. Proporcionar un medio rápido y confiable para que el estudiante consulte su situación curricular particular frente a un cambio de pensum. En este sentido conviene destacar que tradicionalmente los períodos de cambio de pensum son angustiantes para un número significativo de estudiantes. También se sospecha que en los períodos de cambio de pensum se incrementan los errores que cometen los estudiantes al seleccionar las asignaturas a cursar por trimestre.

 
2. Reducir el número de estudiantes que requieren consultar su situación curricular en la Coordinación;

 
3. Proporcionar una herramienta que le permita al Coordinador y a su Asistente atender con mayor rapidez, calidad y consistencia los casos de consulta que persistan.

3. Las funciones que desempeñará el sistema

1. Determinar las asignaturas aprobadas  por un estudiante en la USB, así como aquellas que cursa con expectativas de aprobación en el trimestre de la consulta.

 
1. Registrar las asignaturas que un estudiante haya aprobado y las que cursa con expectativas de aprobación a partir de lo que el estudiante, el Coordinador o la Asistente indique en forma interactiva.

 
2. Determinar las asignaturas aprobadas a partir de los datos guardados en los archivos del programa Cápsula (DACE-Coordinaciones).

 
3. Advertir aquellas asignaturas que hayan sido aprobadas o que se cursen sin que se hubiesen aprobado sus  prelaciones [Millennium Systems].

 
2. Determinar a partir de las asignaturas aprobadas y con expectativas de aprobación en el trimestre de la consulta, las asignaturas que se encontrarían aprobadas en un pensum al finalizar el trimestre, bien sea por aprobación directa, por equivalencia con asignaturas aprobadas en pensa anteriores y por equivalencias dadas por la Coordinación (por ejemplo aquellas que se dieron cuando el estudiante cambió de carrera). Note que esta determinación puede requerir identificar asignaturas extra-curriculares, así tipificar en forma exacta las asignaturas consideradas como Estudios Generales, Electivas de Areas y Electivas Libres.

 
3. Capturar otros datos sobre el desempeño del estudiante que puede condicionar su avance en la carrera, tales como su índice (para efectos de la carga permitida en períodos de prueba), su deseo de cursar ciertas opciones establecidas en los pensa (por ejemplo Proyecto de Grado o Pasantía Larga) o el rango de carga crediticia que desea cursar por trimestre (siempre y cuando ello respete lo establecido en las normas y reglamentos de la USB).

 
4. Determinar la Recomendación Curricular para un estudiante. Para cada trimestre se indicará qué asignaturas se le recomienda cursar para graduarse en un tiempo mínimo respetando factores como:
1. La oferta trimestral de asignaturas;
2. Los requisitos de las asignaturas;
3. El número mínimo y máximo de créditos cursables por período;
4. Requerimientos sobre grupos de asignaturas. Por ejemplo, hay ciertas aignaturas que se deben cursar a exclusión de las demás (Pasantía Corta, Pasantía Larga); hay otras asignaturas que pertenecen a bloques como el bloque de los Estudios Generales, el bloque de Electivas de Area y el bloque de Electivas Libres que tienen restricciones especiales sobre cómo y cuándo cursarlas.
5. Otras restricciones derivadas de las normas y reglamentos de la USB;

 
5. Reportar las asignaturas sobrantes. Una asignatura sobra si fue aprobada por un estudiante pero no forma parte del pensum que se usa para elaborar la Recomendación Curricular, ni formó parte de una equivalencia con alguna asignatura de ese pensum. Esto puede ocurrir con asignaturas cursadas con un permiso extra-curricular otorgado por la Coordinación o con asignaturas cursadas previas a un cambio de carrera y que no pertenecen a la carrera actual que cursa el estudiante.

 
6. Mejorar las heurísticas de elaboración de la Recomendación Curricular y pensar en la posibilidad de permitirle al Coordinador escoger cuáles heurísticas aplicar.

 
7. Manejo de una secuencia de pensa viejos (por ej. pensum de 1989, pensum de 1996).

 
8. Incluir un repositorio de recomendaciones curriculares previos e indexarlos por estado en el pensum. Esto permitiría buscar estudiantes en situación similar para quienes se armó una recomendación curricular. El repositorio podría servir eventualmente de base de aprendizaje para una red neuronal.

 
9. Permitirle al Coordinador modificar la Recomendación Curricular, trasladando las asignaturas o elementos genéricos de un período a otro, agregando electivas libres o estableciendo equivalencias entre asignaturas sobrantes y elementos del pensum. El sistema debe advertirle al Coordinador si estas modificaciones requieren del otorgamiento de permisos por parte de la Coordinación, en cuyo caso lo que se elabora pasa a ser una Recomendación Curricular Especial descrita en el próximo requerimiento. Nótese que la idea es que el sistema proporciona un borrador de Recomendación sobre el cual juega el Coordinador. También es conveniente registrar ciertas equivalencias sobre todo  de asignaturas concretas a elementos genéricos o créditos de bloques homogéneos. Los términos elemento genérico y bloque se definen en el glosario.

 
10. Permitir al Coordinador modificar la Recomendación Curricular de acuerdo a la discrecionalidad que le permiten las normas y reglamentos de la USB para elaborar una Recomendación Curricular con Permisos. En este caso, la Recomendación debe registrar los permisos especiales a conceder previstos por la Coordinación y  las condiciones bajo las cuales se concederían.

 
11. Permitir al Coordinador agregar notas u observaciones pertinentes a la consulta realizada.
 
12. Reportarle al Coordinador, Asistente o estudiante discrepancias que surgen entre los tiempos de culminación previstos para un pensum viejo (vigente) y los previstos para un pensum nuevo (por entrar en vigencia).

 
13. Permitirle al Coordinador introducir los datos que definen un cambio de pensum. Estos datos incluyen:

 
1. El pensum nuevo.

 
2. La fecha en que entra (o entró) en vigencia un pensum y la fecha en que deja de tener vigencia.

 
3. Las equivalencias entre pensa y su período de vigencia.

 
4. La oferta trimestral normal y la del período de transición.

 
5. Ajustes en las normas y reglamentos de la  USB que afecten la elaboración de una Recomendación Curricular, tales como el número de créditos mínimos o máximos que pueden cursarse y las condiciones de un período de prueba.

 
14. Permitir consultas incluso si la USB llegara a "perder" uno o más trimestres. Esto puede involucrar:
1. Correr los trimestres (por ej. el primer trimestre de un año académico podría pasar a ser Enero-Marzo en vez de Septiembre-Diciembre);
2. Manejar calendarios diferentes según la cohorte. En algún momento entre 1980 y 1985 se perdió un trimestre en la USB. A las cohortes viejas se les corrió el trimestre pero las nuevas cohortes comenzaron sin corrimiento inicial. Ello condujo a complicaciones no triviales en la oferta de las asignaturas.

 
15. Permitir acceso en línea a datos que pueden ayudar a visualizar las asignaturas aprobadas, los pensa vigentes y reglamentos vigentes tales como:
• El código de una asignatura;
• El nombre de una asignatura;
• Su creditaje;
• Las asignaturas que la prelan;
• Las asignaturas a que prela;
• La cadena de asignaturas preladas;
• Las equivalencias vigentes y su período de vigencia;
• Las ofertas trimestrales;
• El flujograma de un pensum;
• Mostrar el flujograma (permitiendo mostrar, a petición, el nombre y creditaje de la asignatura que corresponde a un código).

 
16. Facilitar consultas virtuales respecto a cambios de pensum (es decir vía www).

 
17. Permitir al Coordinador imprimir una Recomendación Curricular que, debidamente firmado, sellado, refrendado  y registrado, documente los compromisos adquiridos por una Coordinación en cuanto a la oferta de asignaturas, las asignaturas a aprobar para culminar la carrera, el otorgamiento de permisos  futuros y las condiciones que rigen dichos compromisos.

 
18. Identificar las personas involucradas en el desarrollo del proyecto.

 
19. Permitir el manejo de preferencias, tales como:
• Trimestre a partir del cual se desea construir la Recomendación Curricular (por defecto puede ser el trimestre próximo al de la consulta) ;
• Comenzar a determinar el estado de un estudiante a partir del pensum viejo o del pensum nuevo;
• Presentar las asignaturas utilizando sus abreviaciones o utilizando su código;
• Parámetros para salvar o imprimir reportes (por ej. nombre por defecto del parámetro), así como datos a imprimir ( tales como asignaturas aprobadas  directamente en pensum viejo, asignaturas  aprobadas directamente/ por equivalencia en pensum nuevo, asignaturas en curso con expectativas aprobatorias, recomendación curricular, asignaturas sobrantes).
20. Permitirle al sistema de la Coordinación conectarse con DACE para notificar los permisos especiales concedidos.

4. Los atributos del sistema

1. Tiempo de respuesta

 
1. Pueden haber dos versiones del software, uno que corre en una máquina standalone y otro que se accesa por una página web através de la red.

 
2. La respuesta del sistema debe ser menor de dos segundos en lo que se refiere a inclusión de campos de texto, respuestas a botones presionados o selección de items de menú en una máquina standalone. El acceso por la red puede ser más lento pero sólo debido a la carga del servidor o al grado de saturación de la red.

 
3. La operación de extracción de los datos de la Cápsula, la determinación del plan de estudios y la comparación entre dos planes de estudio puede tardar hasta 10 segundos (pero sería deseable conservar dos segundos como caso límite). De nuevo el acceso por red puede ser más lento.

 
4. El usuario del software no debe poder distinguir significativamente entre el tiempo que tarda una operación de selección/deselección de una asignatura y el tiempo que tarda una operación de selección/deselección de ciertos conjunto de asignaturas (para indicar que fueron aprobadas o para indicar que no fueron cursadas)  en una máquina standalone.

 
2. Filosofía de la interfaz

 
1. Debe ser clara, discreta y amistosa.

 
2. En prototipos previos se determinó que la parte más tediosa de este tipo de sistema es la introducción manual de las asignaturas aprobadas. Para ello debe ser posible introducir abreviadamente un conjunto de asignaturas (todas las asignaturas de un año, o de un trimestre).

 
3. Tolerancia a fallas

 

 

No es importante. Si el sistema se "cae" sólo se pide que pueda volver a comenzar desde el principio.
 
 
 

4. Rendimiento (throughput)

 

 

No se harán exigencias de rendimiento en esta primera versión del producto.
 
 

5. Seguridad

 
1. Las operaciones que permiten elaborar un Plan Especial de Estudios o que definen un cambio de pensum están restringidos al Coordinador.
1. Las operaciones restringidas se registran en un rastro auditable.
2. Los rastros auditables deben ser protegidos.
3. Todo Plan de Estudio identificará los pensa vigente utilizados en su elaboración.
4. Otros (e.g. acceso del administrador).

 
6. Plataforma tecnológica

 
1. El sistema debe desarrollarse en JDK, preferiblemente bajo la versión estable más reciente que aparezca y que agregue bondades relevantes significativas al proyecto.

 
2. Deberá probarse su ejecución en ambiente Windows (95, 98 y NT preferiblemente), Linux y Solaris.

 
3. Debe probarse que Delta Pensum pueda ejecutarse en al menos una de las computadoras actuales de la Coordinación de Computación.

 
7. Flexibilidad

 
1. El sistema debe ser suficientemente flexible para incorporar un cambio menor trimestral de pensum, un cambio moderado anual de pensum y un cambio mayor cada dos años con poco esfuerzo y una dedicación por parte del Coordinador de quince minutos, cuarenta minutos y ocho horas respectivamente.
2. Se deben prever cambios a Cápsula o su sustitución por una aplicación basada en un manejador de base de datos con posibilidad de acceso remoto.
3. Debe prever que eventualmente debe atender a estudiantes que estén en carrera por hasta quince años, que provengan de otras carreras, que cursen más de una carrera, que provengan por equivalencia de otros institutos de educación superior, que estudien carreras tanto de cinco como de tres años y que estudien postgrados.
4. Debe prever que eventualmente puede requerirse que maneje variantes de un pensum, pasantía corta, pasantía larga, normas sobre los Estudios Generales exigidos, áreas de especialización, menciones, períodos de pasantía, período de verano, electivas libres, asignaturas extra-pensum y asignaturas extra-calendario curricular [ojo, no son lo mismo], correquisitos e intercambios.
5. Debe prever exigencias nuevas para eventualmente permitirle a sus usuarios ciertos juegos hipotéticos (what-if). En particular esto incluye la fijación de prioridades a las asignaturas por parte del estudiante.
6. Debe prever cambios menores de los reglamentos y normas una vez por año y cambios mayores una vez cada dos años.
7. Debe prever su futura adaptación tanto al Núcleo de Sartenejas como al Núcleo del Litoral de la USB.
8. Debe preverse que a futuro puede utilizarse como base para la estimación de la demanda de cursos y para el seguimiento de los estudiantes en carrera.

5. Atributos asociados a cada función [Falta actualizar esta sección]

6. Grupos afectados Falta rehacer

• Dra. Lourdes Iturralde, Decano de Estudios Profesionales,
• Coordinadores de otras carreras en la USB,
• Lic. Josefina Alvarez, Directora DACE
• Prof. Marianela Aveledo, Dirección de Ingeniería de la Información

Los usuarios del sistema serían:

• Prof. Maruja Ortega

Es la actual Coordinadora de Computación (pregrado) y tanto patrocinante como usuaria intensiva del sistema. Tiene poca disponibilidad de tiempo, por lo que se ha designado al Prof. Alejandro Teruel como enlace con la Coordinación.
• Lic. Yadira Muñoz

Es la actual Asistente de la Coordinación de Computación y será una de las principales usuarias del sistema. Debe participar en el diseño de la interfaz, preferiblemente como piloto de pruebas para un prototipo. Su disponibilidad de tiempo es baja.
• Estudiantes y profesores de la carrera de Computación.

• LDC, Comisión de Carrera.
• Miembros del Consejo de la Coordinación de Computación (pregrado)

• Lic. Argenis Molina, DACE.

7. Suposiciones

1. La plataforma tecnológica de la Coordinación de Computación (y eventualmente de otras Coordinaciones) podrá ejecutar el software.

Esta suposición ha sido válida hasta la última versión desarrollada (1.1) y se aspira a que se siga cumpliendo. En caso que Delta pensum  sobrepase la capacidad de la plataforma de la Coordinación, sería aceptable instalar el software en otra plataforma siempre y cuando la Coordinación tenga acceso vía www a ella.
 
2. Se encontrará un mecanismo adecuado de acceso al software para los estudiantes.

 
3. Se encontrará un mecanismo adecuado de protección del software y los archivos que utilice.

 
4. El cambio de pensum de la carrera de Ingeniería de Computación entró en vigencia en Septiembre 1999. Se aspira que los primeros incrementos de desarrollo estarán operacionales a tiempo para probarse en el período de transición entre pensa (Septiembre 1999- Julio 2000).

Un prototipo del sistema (Delta Pensum 1.1) fue instalado y utilizado por la Coordinadora de Computación en Junio 2000.
 
5. El software puede ser útil para futuros cambios de pensa, para elaborar planes de estudio en un pensum estable y para determinar el cumplimiento de requisitos de los graduandos.

 
6. El entrenamiento en JDK 1.2 y la incorporación de componentes Swing en la interfaz puede hacerse en el contexto del curso.

Esta suposición fue satisfecha en las versiones 0.1, 1.0 e 1.1 sin dificultades por lo que no se preven dificultades en el desarrollo de futuras versiones.
 
7. Pueden determinarse equivalencias en forma automática, sobre todo identificando por separado asignaturas de Estudios Generales, asignaturas obligatorias de un pensum, asignaturas de Electivas de Area, asignaturas de Electivas Libres, los créditos en Trabajo de Grado y asignaturas adicionales no contempladas en el pensum de estudios (e.g. asignaturas cursadas para otra carrera o con permiso especial).

 
8. Se puede encontrar una heurística sencilla para elaborar el Plan de Estudios con resultados satisfactorios.

Delta Pensum 1.0 y 1.1 incorporan una heurística sencilla aceptables para el nivel de prototipo alcanzado por el desarrollo. Esta suposición puede invalidarse a medida que se tomen en cuenta factores adicionales (no contemplados en el prototipo) en la construcción de la Recomendación Curricular.
 
9. En un trimestre es factible que los estudiantes de la asignatura de Sistemas de Programas, de Ingeniería de Software 2 o de Ingeniería de Software 3 elaboren al menos un incremento "interesante" y utilizable de Delta Pensum, si realizan un desarrollo en equipo.

Esta suposición corre mayor peligro de invalidarse a medida que crezca el sistema. En un interesante artículo [referencia incompleta] , Stonebraker cierra el proyecto de desarrollo de Posgres (uno de los primeros manejadores de bases de datos orientadas a objetos) , justamente cuando el volumen del sistema rebasa la capacidad de estudiantes de pregrado de entenderlo y adquirir cierto dominio operacional básico en el período académico relevante y las labores de desarrollo incremental pierden el componente de investigación necesario para atraer estudiantes de postgrado.
 
10. Puede resolverse el problema de impresión de reportes desde Java.

La versión 0.1 satisfizo esta suposición permitiéndole al usuario de Delta Pensum 0.1 salvar un archivo plano de texto (ascii text) que despues puede abrirse en cualquier procesadora de palabra e imprimirse desde ella.
Las versiones 1.0 y 1.1 pierden la capacidad de salvar el archivo reporte. Sin embargo, como la recomendación curricular cabe en una ventana de una pantalla de 14", el usuario puede hacer uso de las facilidades del sistema de operación para imprimir el "reporte", imprimiendo  una instantánea apropiada de la pantalla (screen snapshot).
 
11. El software puede accesar los archivos de Cápsula oportunamente. Eventualmente la institución tiene planes para proporcionar acceso www para las Coordinaciones al registro histórico de notas de los estudiantes, lo que haría Cápsula obsoleto. Para ese momento se espera que el software bajo desarrollo utilice el acceso www previsto.

Para Septiembre 2000 no hay fechas concretas para el proyecto de acceso www indicado previamente.

8. Riesgos

Relacionados con el uso de Delta Pensum (A2, A5, A6, A7)

• La Coordinación de Computación decide no adoptar Delta Pensum por razones políticas relacionadas con su elaboración por parte de estudiantes.
• La Coordinación de Computación adopta Delta Pensum pero no lo utiliza.
• La Coordinación de Computación deja de usar Delta Pensum al darse un cambio de coordinador que desconozca el software o lo considere irrelevante, tedioso o insuficiente.
• Las Coordinaciones de las carreras diferentes a Computación(pregrado) rechazan Delta Pensum.
• Delta Pensum es adoptado para un cambio de pensum, deja de usarse en el período de vigencia estable de un pensum y es olvidado o resulta obsoleto para el próximo cambio de pensum.
• No se distribuye Delta Pensum a los estudiantes, tienen acceso inadecuado a él o sencillamente no lo usen.
• Se adopta y usa Delta Pensum pero no cumple con sus metas

 

Relacionados con el registro de asignaturas aprobadas (R1, R2, A1, A2, A6, A7)

• El registro de asignaturas resulta tedioso, engorroso o propenso a errores.

La interfaz desarrollada por la versión 0.1 y adoptada con algunas modificaciones menores en 1.0, 1.1 permite un registro ágil de las asignaturas obligatorias, de algunos elementos genéricos y del número de créditos cursados en electivas libres. De todos modos la captura directa de estos datos (o del grueso de estos datos) de Cápsula o de algún sistema equivalente sería beneficioso pues reduce un proceso manual propenso a errores.
• La documentación de los archivos de Cápula es inadecuado.
• El programa Cápsula es descontinuado.
• Resulta complicado o imposible automatizar la correspondencia entre las asignaturas cursadas y aprobadas por el estudiante según Cápsula y las asignaturas aprobadas en los pensa.

 
• Surgen complicaciones serias en la determinación automática de equivalencia de asignaturas entre pensa.

 

Relacionados con la elaboración de la Recomendación Curricular (R3, R4, A7)

• Delta Pensum no captura todos los datos que pueden condicionar el avance del estudiante.
• No se identifican todos los factores que requieren tomarse en consideración para determinar la Recomendación Curricular.
• No es posible balancear los factores.
• No es posible encontrar un algoritmo para determinar la Recomendación Curricular.
• No es posible decidir entre varios algoritmos para determinar el plan de estudios.
• El algoritmo adecuado para determinar la recomendación curricular rebasa la capacidad del curso.
• Delta Pensum no es suficientemente flexible para adaptarse al surgimiento de nuevos factores, en particular los derivados de modificaciones a los reglamentos o normas de la USB.

 

Relacionados con la Recomendación Curricular con Permisos (R5, A1, A2, A5, A7)

• Delta Pensum restringe artificialmente las modificaciones que pueda hacer el Coordinador de Carrera.
• La existencia de Delta Pensum estimula la concesión de permisos.
• Los permisos concedidos por el Coordinador no son justificados apropiadamente.
• Los permisos concedidos por un Coordinador son rechazados por uno de sus sucesores.
• El estudiante malinterpreta o ignora las condiciones que rigen los permisos.
• Los permisos, sus justificaciones y condiciones no son registrados apropiadamente.
• Resulte engorroso o complicado para el Coordinador realizar modificaciones especiales a una Recomendación Curricular para convertirlo en una Recomendación Currciular con Permisos.
• Se elaboran Recomendaciones Curriculares  que no registran todos los permisos necesarios para cursarlo.

 

Relacionados con discrepancias entre Planes de Estudios (R6, A2)

• No tiene sentido reportar las discrepancias en los tiempos de culminación previstos para pensa diferentes.
• Las discrepancias son fuente de confusión o angustia en el estudiante y por ende atenta contra las metas del sistema.

 

Relacionados con el registro de datos sobre cambios (R7, R8, A2, A5, A7)

• Delta Pensum cae en desuso porque resulta engorroso para el Coordinador introducir los datos asociados a un cambio de pensum.
• Delta Pensum resulta poco confiable porque el proceso de introducción de datos asociados a un cambio de pensum es propenso a errores.
• Delta Pensum cae en desuso porque no es suficientemente flexible para adaptarse a cambios en los reglamentos y la normativa de la USB.

 

Relacionados con la cantidad de funcionalidad incorporada (A2, A6, A7)

• Delta Pensum se hace muy pesado para la plataforma tecnológica.
• El desarrollo de la las facilidades de visualización de datos sobre las asignaturas aprobadas, los pensa y reglamentos vigentes resulte inútil, confuso o poco usado.

 

Relacionados con las consultas virtuales (R9, A1, A2, A3, A5, A6)

• El acceso vía www resulte más complejo o engorroso de lo previsto.
• El acceso vía www resulte inseguro o poco confiable.
• La consulta virtual atente contra las metas de Delta Pensum.

 

Relacionado con aspectos legales o procedimentales de la institución (R10, A3, A5, A7)

• La institución rechace el uso de Delta Pensum para generar documentos oficiales.

 

Relacionado con las herramienta de programación y desarrollo (A6)

• La calidad de compilación de JDK 1.2 resulte inadecuada.

En las versiones 0.1, 1.0 y 1.1 este riesgo no se ha materializado, pese a que la compilación puede ser pesada (sobre todo en la plataforma Solaris que para Julio 2000 empieza a mostrar señales de ser insuficiente en cuanto a su capacidad de memoria).
• Las herramientas CASE resultan insuficientes.

Los desarrollos de las versiones 0.1, 1.0 y 1.1 no se apoyan en herramientas CASE, lo cual hace muy pesado el desarrollo por la falta de facilidades específicas para crear, validar y mantener los diagramas y demás productos de la metodología utilizada. Los equipos de desarrollo adoptaron herramientas en forma ad-hoc para elaborar y mantener sus sitios web, proporcionar la documentación del código Java (JavaDoc), construir clases a partir de archivos (Claire) y, en el caso de Injavakus, administrar la configuración de su código (**falta referencia**).

Relacionados con el esfuerzo de desarrollo (A7)

• Se pierda  la ventana de oportunidad abierta por el cambio de pensum en marcha.
• Se extienda la fase de diseño.

Durante el desarrollo de las versiones 0.1 y 1.0 sólo se pudo controlar parcialmente este riesgo; de hecho es claro que se subestimó el tiempo y esfuerzo necesario para realizar este proceso y se seleccionaron incrementos demasiado grandes.
• Se intente incorporar demasiados mecanismos en Delta Pensum.
• La cantidad de trabajo requerido rebase la capacidad del curso.
• Los estudiantes desarrolladores se desmotiven o presenten problemas serios relacionados con su dinámica de grupo.

 

Relacionados con la calidad del producto (A1, A2, A3, A4, A5, A7)

• El software se usa pero sus resultados no son de calidad suficiente, por lo que no se cumplen las metas previstas.
• La calidad del producto implementado resulte insuficiente para proporcionárselo a los usuarios previstos.

 

Misceláneos (A5)

• Los resultados del software muestran un claro y extendido retraso en las recomendaciones curriculares.
• Se divulgan varias versiones del software con resultados diferentes, incrementando el grado de confusión de sus potenciales usuarios.

9. Dependencias

La empresa Southpark aprovechó más elementos de 0.1, notablemente una buena parte de la interfaz creada para 0.1. Esta reutilización requirió corregir  algunos elementos que enturbiaban la separación entre la capa de interfaz y la capa del dominio de la aplicación. Injavakus contribuyó notablemente al desarrollo al aprovechar el software desarrollado por otro proyecto (Claire) para mejorar la capa del repositorio. Esta contribución de Injavakus fue posteriormente incorporada en el desarrollo de sus rivales

La versión 1.1 se apoya en los mismos artefactos que la versión 1.0, de hecho la versión 1.1 sólo corrige algunos detalles del código.

[**Falta completar]

[Análisis: Factibilidad del desarrollo]
[Análisis: Estimaciones]
[Análisis: Recursos especiales]

Autor y copyright:

Prof. Alejandro Teruel

Dpto. de Computación y Tecnología de la Información

Universidad Simón Bolívar

Fecha de creación: 21 de septiembre de 1999

Ultima actualización: 15 de septiembre de 2000