LA CONSTANTE UNIVERSAL EN EL DESARROLLO DE SOFTWARE ES EL CAMBIO.

De acuerdo a los autores de nuestro libro de texto, no importa qué estemos desarrollando, en qué lenguaje o para quién, siempre habrá una constante universal, el cambio, acompañada de una regla de oro: dale al cliente lo que quiere. 

En nuestra vida como desarrolladores nos encontraremos con situaciones en las que estaremos tranquilos después de haber entregado un robusto proyecto que nos llevó meses desarrollar, testear, corregir y perfeccionar para que un día nos informen que requerirá un gran cambio que nos tomará semanas implementar (si es que documentaste bien). Esto puede sonar muy frustante pero te diré algo, los cambios en cualquier sistema se traducen a tiempo y trabajo, y eso, pues a dinero.

Así que, antes de enojarte con el cliente, respira profundo y comienza a buscar la manera de hacer sus nuevas ideas una realidad. Sin embargo, habrá un par de cosas que debes tener en cuenta.

Para empezar, existen dos tipos de cambios, los cambios que se deben hacer sobre un código que ya existe, ya sea para mejorarlo o adaptarlo o bien, los cambios que se deben hacer para implementar una nueva funcionalidad sobre el sistema.

Así que, si desde un inicio te basaste en buenos casos de uso y levantaste requerimientos claros y completos, el adaptar el sistema no debería ser tan complicado. Probablemente puedas resolverlo creando vías alternativas, o vías opcionales. Pero primero, ¿qué son estas vías que menciono?

Las vías alternativas son una serie de pasos que el usuario puede realizar o no. Es decir, para realizar una tarea o cumplir un objetivo, puedes seguir el camino A o el camino B, cada uno te pedirá que hagas cosas distintas, pero al final, terminarás en el mismo sitio al que querías llegar, lo importante es que ambas vías te llevarán al mismo punto.

Todas estas nuevas vías que añadas se representan por lo general con números decimales, es decir, si mi vía principal tiene el paso número 2, pues una ruta alternativa sería la 2.1 o la 2.2, etc. Son subvías que te harán seguir un camino distinto en el caso de uso.

Retomando un poco los casos de uso y las vías principales o las vías alternativas nos topamos con un nuevo concepto, los escenarios. 

Un escenario es una vía en particular, que comienza desde el primer paso en el caso de uso hasta el último paso del usuario. Es como un camino que se tomó, sirve para dar ejemplos concretos a los programadores de cómo las cosas suceden si sigues una vía u otra.

Una vez que añadas a tu caso de uso las nuevas vías que el cliente te pidió es momento de revisar tus requerimientos ya que en un 99% de los casos, cuando cambias un caso de uso también deberás cambiar tus requerimientos y recuerda, el objetivo de todo esto es levantar los requerimientos correctos para que el sistema haga lo que el cliente espera que haga. Si en algún momento, ajustando tus requerimientos te topas con código duplicado, lo mejor será buscar una manera para hacer que ese código trabaje para ambos requerimientos ya que se debe evitar a toda costa el código duplicado.

En fin, recuerda tres cosas: siempre habrá cambios, dale al cliente lo que necesita y sobretodo, no te frustres, los cambios son buenos, siempre y cuando representen una mejora u optimización.

Fuentes consultadas:

Head First Object – Oriented Analysis and Design. – Brett McLaughlin, Gary Pollice, David West
Why do requirements change? – https://accu.org/index.php/journals/319
How to Deal With Changing Requirements in Software Development – https://www.upwork.com/hiring/for-clients/changing-requirements-software-development/
Imagen recolectada en: rawpixel.com de Pexels
Anuncios