Desarrollo de software. Los cambios en los requisitos

Y lo es pese a que le hayas dado muchas vueltas con él a cada uno de los requisitos y se haya consensuado una solución.

Esto es así porque el usuario trabaja con imágenes abstractas de lo que va a ser el producto final y porque pasado un tiempo (en ocasiones horas) no recordará con exactitud detalles en los requisitos. A esto le podemos añadir el descubrimiento de nuevos matices ya sea por un análisis más meditado por parte del usuario (o porque terceros le hayan hecho ver aspectos en las funcionalidades que tienen que cambiar) y por la propia evolución en las prioridades por parte del área usuaria que haga no solo que ahora sean más importante unas funcionalidades que otras, sino nuevos cambios en las especificaciones.

Y estas circunstancias suceden desde el momento siguiente al cerrar una especificación hasta prácticamente el minuto antes de la entrega.

Es cierto que el área usuaria debe ser responsable de los requisitos que ha dado pero tenemos que entender también que por mucha atención que le hayan dedicado, esos cambios van a suceder.

Como esos cambios son inherentes al propio proceso de desarrollo y a la existencia de usuarios la solución pasa porque los mismos sean realizados cuando tengamos versiones del software en funcionamiento ya que no es lo mismo opinar sobre algo tangible que hacerlo sobre elementos abstractos.

Es cierto que es más costoso hacer cambios en el software que cambios sobre las especificaciones recogidas en un documento o en una herramienta CASE pero por mucho que nos esforcemos en intentar que esos cambios se hagan en el análisis siempre vendrán cambios después.

Desde mi punto de vista el enfoque debe ser iterativo incremental, realizándose cada iteración con intención, con ciclos lo más cortos posibles en función de la naturaleza del sistema a desarrollar y su contexto.

Un enfoque iterativo incremental puede ser llevado a cabo de distintas maneras, si tiene una fase de análisis previa no se tiene por qué renunciar a estudiar bien las especificaciones con el usuario, no se trata de dejarlo todo para el feedback. Si en cada iteración se hace el ciclo completo no se debe renunciar a que la especificación de la historia de usuario o del caso de uso sea la mejor posible.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: