En serio va a cambiar...
Esta debería ser la primera regla en cuanto al diseño de software, la regla sobre
la que se debe sustentar todo el enfoque con respecto al análisis, el diseño y la
codificación de un sistema software.
Todo cambia muy rápido en el proceso de desarrollo de un software, el mismo software
construido, genera nuevos requisitos, la satisfacción de las necesidades de un proyecto,
genera a su vez nuevas necesidades.
Explicado de otra forma la resolución de un problema, genera un entendimiento más
claro de dicho problema, y en esta situación, se abren nuevas posibilidades sobre
las capacidades del software y el negocio que sustenta.
Actualmente es muy difícil encontrar un proyecto que funcione con las fases tradicionales
de la ingeniera de software, y que no requiera regresos continuos a las fases de
análisis y diseño, además de un alargamiento innecesario de las fase de construcción.
Ese el motivo del auge de la metodologías ágiles. Están pensadas desde un principio
para ser validas en un contexto donde el cambio de los requisitos y las necesidades
de los usuarios son constantes.
¿Significa esto que los cambios en mitad de la construcción de un software, es algo
bueno y deseable?, no necesariamente, no es algo que se deba plantear en esos términos,
más bien es algo que se debe aceptar como la realidad el día a día, y preparar nuestros
procesos y enfoques para el cambios, si nos negamos a él, solo repercutirá en inacabables
horas extras de construcción.
Desde un primer momento debemos estar listos y asumir que nuestro proyecto va a
cambiar, y adaptarnos rápidamente a ese cambio, para lo cual necesitamos apoyarnos
(entre otros) en los siguientes puntos:
- Metodologías que estas diseñadas para gestionar los cambios.
- Herramientas para gestionar los cambios en el software (como herramientas de control de versiones).
- Herramientas para gestionar las necesidades y los requisitos.
- Herramientas para probar el software de manera automatizada, para controlar el impacto del cambio en nuestro software de una manera rápida.
- Software diseñado (y construido) desde el puntos de vista del cambio.
- Software generado automáticamente, mediante técnicas de generación automática de código.
- Equipos cuyos integrantes que compartan un "mismo lenguaje", esto es que entienda y apoyen un conjunto de prácticas y estándares de programación, y objetivos comunes para todos.
Profundizare en un futuro en cada uno de estos puntos.
Muy interesante tu exposición y muy cierta. Además de que el software va a cambiar te llegas a topar con que no conoces algunos detalles hasta ya muy cerca de la construcción y entonces tienes que tomar decisiones sin conocer completamente todo el panorama. ¿Conoces alguna forma de medir en costo-beneficio de tener este tipo de prácticas? ¿Que herramientas recomiendas para gestionar las necesidades y los requisitos?
ResponderEliminarSaludos
Creo que cualquier herramienta de BugTracking debería servir para el tema de los controles de cambios y asignación de tareas, siempre y cuando sea conocida y cómoda para todo el equipo, estoy pensando en hacer un listado de mis "herramientas favoritas".
ResponderEliminarEl tema del costo es mas complejo, por que normalmente se mide cuando nos cuesta un recurso, por tiempo, pero es difícil medir cuando nos cuesta programar sin vistas al futuro, por ejemplo si un software es tan difícil de entender que requiere hacerse de cero, cuando se va el responsable del mantenimiento, el costo de este software se duplica en tiempo y dinero, ademas que si se toma la decisión de dejar el software como esta y no aplicarle cambios, el costo se mediera en las perdidas de negocio que que ocasionara, pero esos datos "indirectos" y "pesimistas" son complicados de medir en costos.