9/14/2004

Obtención de conocimiento para proyectos SW

Comentario al artículo "Toward a Practical Solution for Capturing Knowledge for Software Projects", de S. Komi-Sirviö y A. Mäntyniemi. IEEE Software, Mayo/Junio 2002

Los autores se centran en:

  • mantener información sobre proyectos pasados, que denominan "Lessons to learn" database. Pero crear una bd no significa que se utilice.

  • "Data Transfer Days": reuniones de análisis de problemas y éxitos pasados. El inconveniente era juntar a la gente, pero el éxito es mayor que con la bbdd.



El problema es que estas acciones no están incorporadas a la metodología organizacional. Por otra parte, ningún cambio que ignore los hechos comportamentales y culturales de la organización, podrá tener éxito.

9/13/2004

XP en una compañía con Proceso definido

Comentario al artículo "Launching Extreme Programming at a Process-Intensive Company, de J. Grennnig, en el IEEE Software de Noviembre/Diciembre de 2001

En un ejemplo "real", una empresa tiene mucho "overhead" al desarrollo de software:

  • Comienzo de Diseño

  • Modelado en Rose

  • Planificación de una reunión de revisión

  • Distribución de materiales a revisar
  • Introducción de temas a discutir en la web

  • Reunión de revisión

  • Acta de la reunión con tareas a realizar

  • Reparación de defectos

  • Cierre de defectos en la web

  • Modificación de documentos

  • Vuelta a empezar



¿Cuánta documentación es necesaria?

  • La suficiente para la definición de requisitos de producto, permitir revisiones técnicas y dar soporte al mantenimiento

  • Código fuente comprensible

  • Documentación de interfaz



Utilizan CppUnit como framework de pruebas unitarias.

Al comienzo del proyecto, se trabaja sobre casos de uso -sin descripción detallada, sólo el nombre-, y se priorizan. No se realiza un diagrama de casos de uso, se da por hecho que no hay especialización.

El resto del proyecto se realiza siguiendo casi al 100% el XP, pero teniendo en cuenta la forma de trabajar habitual del cliente -p.e. siguiendo sus convenciones de codificación y nombrado-.



Desarrollo de SW en proyectos Internet

Comentario sobre artículo "Software Development on Internet Time", del Computer de Octubre del 99

Las pequeñas y medianas empresas, así como departamentos de grandes compañías que estén involucradas en proyectos "internet", han de desarrollar técnicas y metodologías mucho más flexibles.

Para comentar esta idea, se basa en entrevistas con Microsoft y Netscape para estudiar su modo de trabajo diario -lo que el autor denomina "Synchronize and stabilize"-.

Microsoft:

  1. Builds de producto diarias

  2. Dos o más hitos de proyecto -milestones-: estos son los momentos de "estabilización"

  3. Releases alpha y/o beta



Los equipos de Microsoft no intentan tener una especificación completa al comienzo del proyecto: crean un "vision statement". Este "outline", sin embargo, ha de ser lo suficientemente detallado como para poder realizar una estimación de tiempos y equipo necesario.


Las alpha y beta salen en cada hito de proyecto -las alpha son internas y las beta externas, por lo que éstas últimas no siempre-.

Se crea un "buffer time" de entre un 20-50% en cada hito para hacer frente a dificultades inesperadas, retrasos, etc. En el caso de productos con fecha límite estricta, se pueden llegar a eliminar funcionalidades para cumplir la fecha de salida.

Idea interesante de Netscape: Advance Planning Meetings, una especie de brainstorming una vez cada, aproximadamente, tres meses, que reúne a ejecutivos, ingenieros y comerciales para pensar en nuevas características y planes de salida de cada nuevo producto.