Tarea 4

Adicionalmente su empresa debe:

 
1. Actualizar los documentos de diseño y manuales correspondientes.

 
2. Instalar una versión del incremento 2.2 en la cuenta de su empresa, que compile y ejecute en JDK 1.2 en ambiente Solaris.

 
3. Instalar una versión en ambiente Windows que compile y ejecute en JDK 1.3.

 
4. Preparar una versión para su posible instalación en la Coordinación de Computación.

 
5. Manejar el control de las configuraciones del software y los manuales con una herramienta automatizadas. Opcionalmente puede manejar otros documentos con la misma herramienta.

 
6. Escribir un informe que indique la herramienta adoptada para diagramar esquemas UML y si adoptó algún ambiente de programación (p. ej. Forte, Kawa, JBuilder o BlueJ). El informe debe incluir una breve evaluación del uso de la herramienta.

Para a más tardar el Miércoles 11 de octubre (Miércoles de semana 5) a las 12:00 m, su empresa debe publicar en el www y dejar la versión impresa bajo la puerta de la oficina del Prof. Teruel, la planificación del incremento 2.2:

• La distribución de tareas entre los miembros del equipo (recuerde incluir las actividades de integración);

 
• El plan de desarrollo, que incluye para cada tarea, la estimación del tiempo que requiere (en horas-persona), la probable fecha de culminación, las dependencias entre tareas, la descripción y fecha de los hitos, incluyendo como hito final, la entrega final de esta tarea.

 
• La lista de los ocho riesgos más peligrosos de este incremento y las acciones propuestas para mitigarlos. De estos riesgos, no más de cinco pueden ser riesgos técnicos específicos al incremento, no más de dos pueden ser general al proyecto y al menos dos tienen que estar relacionados con la dinámico del equipo.

Los riesgos relacionados con la dinámica del equipo sin duda son los más difíciles e incómodos de identificar. Siempre es más cómodo dejar estos aspectos menos técnicos y más emocionales en manos de alguien externo (p. ej. el profesor) o un líder de proyecto. En un equipo altamente efectivo, el equipo  debe aprender a  tener la suficiente confianza y tacto como para plantear y discutir abiertamente sus preocupaciones respecto al:
1. Cumplimiento con las normas del equipo (asistencia puntual y oportuna a las reuniones, respeto de fechas y productos solicitados);
2. Cumplimiento oportuno con las tareas encomendadas, al nivel de calidad exigido por el equipo;
3. Comunicación entre los miembros y subgrupos;
4. Liderazgo;
5. Desempeño de roles;
6. Manejo de diferencias y conflictos.


La descripción de estos riesgos y acciones mitigantes deben  respetar la privacidad del grupo, por lo que estos riesgos debe codificar las referencias a personas o subgrupos específicos, si los hubiera. Por ejemplo, NO puede entregarle al profesor que su mayor riesgo es que Pedro José no entregue a tiempo las tareas que le fueron designadas; en todo caso debe escribir que el mayor riesgo es que A no entregue a tiempo las tareas que le son designadas.

No confunda la sesión de identificación de riesgos con una sesión de evaluación de un individuo o subgrupo. Si alguién no está desempeñándose bien, lo peor que se puede hacer es un comentario del estilo "Por cierto, creo que nuestro mayor riesgo es Fulanito, pues nunca cumple las tareas que le damos" en la mitad de la reunión y sin previo aviso. Si está inconforme con el desempeño de algunos miembros, plantéselo en otra ocasión con suficiente antelación a la reunión, sea concreto en sus críticas y antes de soltar sus críticas déle la oportunidad a la persona de justificarse y de escoger el momento de recibir las críticas ("Mira, ahora no, tengo que tomar el autobus..."). Lo ideal es que la misma persona tenga la suficiente madurez , auto-crítica, y compromiso con su equipo como para plantear el riesgo: "Miren, la próxima semana tengo tres entregas y tengo que llevar mi madre al médico, por lo que veo difícil cumplir con esa tarea. Si alguien me ayuda con la primera parte y dejan que la segunda parte la tenga para el viernes y no el jueves, creo que no habrán problemas."
 
 

• Su presupuesto.

Para calcular el presupuesto, la empresa debe fijar un costo por hora-persona de trabajo en bolívares. Estime cuántas horas de trabajo le llevará el desarrollo y multiplique por el costo por hora-persona. Agregue un factor para contingencias y para ganancias. El presupuesto entregado debe detallar los factores utilizados en sus cálculos (costo por hora-persona, horas estimadas, factor de contingencia, factor de ganancias).

• El hito debe ser tangible ("entrega del incremento 2.1.2 que cumple los primeros tres requerimientos" es tangible; "haber empezado el diseño de 2.1.2" no es tangible);

 
• La cantidad y fechas de los hitos deben planificarse con cuidado. Un exceso de hitos conduce a demasiadas interrupciones en el proceso de desarrollo; una deficiencia de hitos significa que su gerente no tiene idea por donde anda el desarrollo. Se sugiere que para el curso, se debe planificar un hito cada dos semanas aproximadamente.

Cualquier cambio que afecte el diseño de Delta Pensum debe ser reportado a la brevedad y no esperar la fecha de entrega de un hito. También deben ser reportados cualquier riesgo desbordado o imprevisto que amenace el calendario, costo o funcionalidad del incremento, acompañado por una estimación de la magnitud del impacto y las acciones propuestas para mitigarlo.

La entrega final incluirá la bitácora de los desarrolladores, el costo del desarrollo (explicitando el número de horas trabajadas y el costo por hora-persona) y el análisis de manejo de los riesgos según la siguiente clasificación:

• Riesgo ausente: se previó que podía presentarse y no se presentó;
• Riesgo disuelto: el riesgo se previó y se presentó pero las acciones mitigantes impidieron que impactara el desarrollo;
• Riesgo controlado: el riesgo se previó y se presentó, pero gracias a las acciones mitigantes el impacto sobre el desarrollo fue controlado;
• Riesgo desbordado: el riesgo se previó y se presentó y pero las acciones mitigantes no fueron capaz de controlarlo o lo controlaron demasiado tarde;
• Riesgo imprevisto: no se previó el riesgo por lo que hubo que improvisar una acción mitigante.

•  Cada  empresa cumplirá con el 90% de los requerimientos correctivos de Delta Pensum 2.x, y los requerimientos nuevos 1, 2, 6 y 9 para el final del próximo trimestre.

 
• Cada empresa completará el incremento 2.2 y el diseño del incremento Delta Pensum 2.3 para el final de este trimestre (Lunes, semana 12). Ese incremento cumplirá con una parte significativa de los requerimientos nuevos 1 y 2.

 
• La calidad de los incrementos 2.2 y 2.3 serán tal que podrán instalarse en la Coordinación de Computación y que puedan servir de base para desarrollos en futuros cursos.

 
• El trabajo del curso exigirá en promedio 8 horas de dedicación semanal fuera de las sesiones de clase.

 

Requerimientos para la versión 2.2

1. Comprobar la validez del carnet del estudiante.

Debe permitir tambien dejar el carnet en blanco con cualquier cosa como nombre (esto permite jugar con escenarios y que el Coordinador haga pruebas del sistema...).

Idealmente el sistema debe dejar introducir los primeros dos dígitos del carnet, escribir el guión y dejar que el usuario termine de introducir los demás números. Hay que prestar atención a que capture y valide  los carnets "00-" correctamente.
 

2. Incluir facilidad rudimentaria que permita salvar la Recomendación Curricular.

Esta primera aproximación a la facilidad, permitiría salvar la Recomendación Curricular como un archivo .txt,  que pueda abrirse en Word (bajo Windows NT) y en emacs (bajo Solaris).

El archivo guardará la siguiente información en orden:

1. Encabezado de la página con nombre de la Universidad y la Coordinación.
2. Título apropiado y personalizado (por ej. "Recomendación Curricular No Oficial  para XXXX, carnet YYYYY").
3. La recomendación curricular :
• Guardada por períodos, indicando nombre y fecha del período (p.e. "Sept.-Dic. 2002"),
• Para cada encajable debe indicar su código (sólo para asignaturas), nombre y créditos,
• Cada período debe indicar la suma de los créditos a cursar.
• Recuerde incluir el nombre y número de créditos aprobados en bloques heterogéneos (como por ejemplo, ll bloque de Electivas Libres) y el número de créditos  que faltan).
• El modelo a seguir es la descripción de un pensum en el Catálogo de carreras de la USB.
4. Elementos del rastro auditable como nota al pie del documento: Versión de Delta Pensum que genera el archivo , la fecha de generación del archivo y en dos líneas al final  texto similar al siguiente: "Modificado por: " y "Fecha de última modificación".


El sistema debe escoger  un directorio y nombre por defecto para el archivo (el nombre preferiblemente construido en base al carnet o nombre del estudiante --cuidado cuando estos campos se dejan en blanco!), advertir si ya existe un archivo en el mismo directorio con el mismo nombre y debe permitir cambiar el directorio y nombre por defecto.

Sugerencia: Si bien las versiones 1.x no incluyen una facilidad para salvar archivos, la versión 0.1 sí la incluía por lo que puede resultar interesante revisarla a ver si es aprovechable.
 

3. Revisar el manejo de equivalencias al pasar del pensum viejo  al nuevo.

Documente el diseño del paquete Equivalencias. Preste particular atención a equivalencias que incluyan como fuente o destino, un conjunto de asignaturas y créditos aprobados por bloque. Recuerde revisar si se permite definir un equivalencia que tome como fuente cualquier combinación entre un número de créditos en Electivas Libres y cero o más encajables en el viejo pensum, y  como destino cualquier combinación de número de créditos en Electivas Libres y encajables en el nuevo pensum. Extienda el sistema, si es necesario.
 
4. Revisar y corregir si es necesario las reglas para mostrar encajables en gris o en negro al pasar de un pensum viejo a un pensum nuevo.

 
5. Documentar  la arquitectura y diseño de la capa del repositorio.

 
6. Incorporar un segundo calendario (Proyecto de Grado) por pensum.

Al cambiar de un pensum a otro, se debe conservar el tipo de calendario que se mostraba. Hay que revisar si se requiere introducir el concepto de equivalencias entre calendarios (tenga cuidado con los bloques --en particular el bloque Electivas Libres.

En la versión 2.2, la Recomendación Curricular se construirá para el calendario del pensum nuevo que se muestre en pantalla. Para esta version, es admisible que para construir la Recomendación Curricular correspondiente al  otro calendario tenga que realizarse una consulta nueva.
 

7. Empaquetar las clases del dominio de la aplicación, de acuerdo a su arquitectura.

---

Esta página fue creada por el Prof. Alejandro Teruel el 3 de octubre de 2000.

Ultima actualización: 4 de octubre de 2000.

Por favor dirija sus comentarios al Prof. Alejandro Teruel.