Situación del proyecto

En cuanto al manejo de un proyecto de mantenimiento:

1. Entender lo que está hecho

 

 

Ojo, quizás quedó la impresión que hay que entender completamente al desarrollo anterior --lo cierto es que hay que entender suficiente para:

• Respetar su arquitectura,
• Aprovechar su flexibilidad prevista,
• No perder calidad,
• No perder tiempo.


En cuanto a la evaluación de Delta Pensum según modelo Maslow-O'Donnell-Teruel:

El proyecto no está en peligro de cancelación inmediata (previo fin de la cadena)
 
1. Necesidades de supervivencia
• Situación política

Delicada. Se continúa la estrategia de bajo perfil, sin búsqueda inmediata de patrocinante.
Riesgo importante: Perder un campeón del sistema por cambio de coordinador de la carrera
Acción inmediata: Tratar de interesar a la nueva coordinadora en el rol de campeón de DP.
Responsable: Gerente de Sistemas (Prof.)
Visión de negocio cambia: pendiente por analizar
Opiniones sobre funcionalidad actual: pendiente --usuarios han sido invitados (Martes -MOF)
Desarrolladores previos: irrelevante
 
• Calidad mínima del producto

Hipótesis de trabajo: El producto cumple con calidad mínima (ejecuta sin caerse catastróficamente y los resultados son confiables)
Acciones de confirmación: Entrevista a usuarios (pendiente). Instalación y ejecución preliminar por parte de empresa desarrolladora.
Responsable: pendiente por designar
 
• Calidad mínima de documentación

Hipótesis de trabajo: La documentación mínima (manual de instalación y uso) existen, se entienden y corresponden al producto. Puede haber problemas en la instalación con los class-path.
Acciones de confirmación: Entrevista a usuarios. Instalación y ejecución preliminar.
Responsable: por designar
2. Necesidades de fiabilidad
• Calidad metodológica

Hipótesis de trabajo:
Adecuada, el desarrollo siguió la metodología RPM y sus modelos se encuentran disponibles. Puede haber discrepancias entre modelos y la realidad .
Acciones de confirmación:
• Validar modelo de uso contra uso.

Responsable: por designar
• Revisar modelo conceptual

Responsable: por designar
• Validar otros modelos en paralelo con desarrollo de nuevo incremento (es decir esta acción se pospone).

Quizás resulte ilógico agregar extensiones antes de terminar de entender el sistema, pero el tiempo apremia...
Riesgo: Desarrollar sobre arenas movedizas
Acción de control:
Ajustes pequeños primero que permitan explorar fiabilidad de modelos y software,
Revisión de manejo de riesgos
Responsable: por designar.
• Calidad razonable del producto

Hipótesis de trabajo: El producto cumple parcialmente con este requisito, pues el proceso de pruebas no ha sido suficientemente riguroso ni completo. El uso del sistema también ha identificado algunos errores.
Acciones:
Entrevista a usuarios, uso del sistema revisando si cumple con los atributos exigidos.
Si bien debería diseñarse un proceso de pruebas de fiabilidad de producto, esto escapa de los alcances del curso.
Riesgo: Desarrollar sobre arenas movedizas
Acción de control:
Inspección de código al realizar ajustes pequeños. Posible aplicación de técnicas de refactorización.
Responsable: Por designar
 
• Extensibilidad mínima del producto

Hipótesis de trabajo:
El producto es mínimamente extensible. Por el lado positivo, el desarrollo incorpora una serie de patrones de diseño orientados a tal fin. Sin embargo, el mejor diseño extensible es el del equipo Injavakus, cual no conforma la base de nuestro desarrollo. Adicionalmente hay una serie de decisiones que llevan a DP 1.1 a su estado de prototipo, por cuanto simplifican notablemente la complejidad real con que debe trabajar y que pueden comprometer la flexibilidad real del producto. (mencionar experiencia 0.1 -> 1.0, pero temperado por esa misma experiencia)
Acciones:
 Inspeccionar diseño al realizar ajustes pequeños.
Evaluar alcance de decisiones "sobresimplificadores" e incluir requerimientos de revisión en los primeros incrementos a desarrollar.
Riesgo: Compromiso (fallas por incompletitud) del diseño y código del producto.
Acción de control:
Revisar patrones usados en desarrollo Southpark y en desarrollo Injavakus.
Responsable: Por designar
 
• Estado de herramientas de desarrollo:

Hipótesis de trabajo:
El uso previo de herramientas es deficiente y las pocas utilizadas probablemente requieran reinstalación en versiones más actualizadas. Realistamente es poco probable que este punto se resuelva satisfactoriamente este trimestre por lo que la estrategia de adopción ad-hoc persistirá.
Acciones:
• Revisar versión de JDK instalada en LDC, instalar nueva versión si es necesario  y recompilar.
• Exigir uso de JavaDoc
• Adoptar uso de alguna herramienta o mecanismo semiformal de control de configuraciones.
• Usar JUNIT como base para pruebas (posiblemente en el próximo trimestre).
• Estudiar posibilidad de adoptar uso de Forte.
• Estudiar al menos uno de los ambientes BlueJ, JJ, ReadyToProgram. Hay alto riesgo que Delta Pensum rebase su capacidad.
• Estudiar posibilidad de usar Rational Rose (el uso de la nueva versión Gold ha sido descartada por sus precios prohibitivos --hay que estudiar licencia del viejo).
Riesgos:
Excesiva pesadez en el desarrollo con fuerte tentación de abandono metodológico.
Consumo excesivo de tiempo en estudio de herramientas.
Acciones:
  A determinar.
Responsable:
  Por designar


En conclusión, el análisis preliminar  anterior debe dejar claro que el proyecto Delta Pensum 2.x llega a lo sumo al nivel tres del modelo. Esto significa que puede esconder "cangrejos" significativos que retrasen el desarrollo por necesidades de mantenimiento correctivo .
 

2. Escoger funcionalidad para el próximo incremento
3. Planificar próximo incremento

Formación de "empresas"

Dividir pizarra en 4 partes y escribir Empresa 1,2,3 en las primeras tres.

Dejar que libremente discutan entre ellos los grupos y si hay n estudiantes presentes, a medida que los equipos lleguen a piso(n/3) integrantes, que pasen a escribir sus integrantes en pizarra.  [15 minutos]

Si en 15 minutos no han llegado a un consenso, usar cuarta parte de la pizarra. En ella que cada estudiante coloque el nombre de la persona con que más le gustaría trabajar (dibuje un arco dirigido desde él hacia la persona con que quiere trabajar). Analizar grafo a ver si se forman clusters naturales. (encerrar en círculo los que están presentes).

Si no llegan a formar las empresas, dar un deadline para formación y proceder al próximo ejercicio con equipos "tentativos".
 

Tarea 1

• Decidir su nombre y crear el esqueleto de su sitio web.
• Instalar y usar Delta Pensum 1.1.
• Revisar que los manuales (de instalación, del usuario) correspondan al producto.

Cada estudiante llenará el formato de la hoja de registro semanal entregada en clase. Por favor agregue a los datos de la hoja, el nombre de la empresa a que pertenece.

El martes (19 de septiembre), cada empresa debe traer a la clase por lo menos 6 copias impresas del documento Delta Pensum: Los Requerimientos Generales para los ejercicios que se harán en la sesión de clase.

---

Esta página fue creada por el Prof. Alejandro Teruel el 8 de septiembre de 2000.

Ultima actualización: 15 de septiembre de 2000.

Por favor dirija sus comentarios al Prof. Alejandro Teruel.