Explicación

15.1 Cambios en los requerimientos

Los requerimientos nunca son escritos en piedra, incluso después de pasar por un extenso proceso de validación que haya concluido con la firma del documento de especificaciones. Es muy probable que el cliente desee realizar cambios o agregar nuevas funciones, principalmente debido a que las necesidades van cambiando con el tiempo (sobre todo en sistemas grandes que tardan en desarrollarse algunos años), no todos los errores a los requerimientos fueron detectados a tiempo, o bien, porque existe algún factor externo a la organización que le obliga realizar ciertos ajustes.

Rara vez se encuentran todos los problemas de requisitos durante el proceso de validación de requerimientos, y es inevitable que haya cambios a los requisitos para corregir las omisiones y malentendidos después de que el documento de requerimientos ha sido acordado Sommerville (2011).

En el siguiente diagrama, Sommerville (2011), muestra en bloques los diferentes momentos de la ingeniería de requerimientos en donde los stakeholders adquieren un entendimiento diferente del problema que desean solucionar. Conforme pasa el tiempo, tanto el usuario como el equipo desarrollador reconocen mejor las necesidades verdaderas que el sistema debe cubrir. Esto provoca cambios inevitables a los requerimientos iniciales. No aceptar ninguna modificación podría generar que se desarrolle un software inútil y corregirlo después de haberlo implementado será todavía más costoso.

Fuente: Sommerville, I. (2011). Software Engineering (9ª ed.). EE. UU.: Pearson.

No todos los cambios deben ser aceptados a ciegas. Cada solicitud de cambio de ser analizada con detenimiento antes de aceptarse, debido principalmente a que pueden traer impactos considerables al proyecto (tiempo, costo, alcance o calidad) que finalmente terminen por convertirlo en un fracaso.

Razones de los cambios:

Algunas de las razones por las cuales los cambios en los requerimientos son inevitables:

Las condiciones del negocio cambian constantemente debido principalmente a que el cliente final va cambiando sus exigencias y expectativas de los productos o servicios.
Cambios en la tecnología en cuanto a nuevos dispositivos electrónicos, nuevas capacidades, acceso a Internet e interfaces gráficas.
Legislaciones impuestas por entidades gubernamentales con carácter de obligatorio que provocan cambios en los procesos internos de las organizaciones.
Limitaciones en el presupuesto de los proyectos de desarrollo.
Cambios en los objetivos estratégicos de las empresas.

Evolución de los requerimientos:

En opinión de Sommerville (2008), existen dos clases de requerimientos desde la perspectiva de su evolución:

Clase	Descripción	Ejemplo
Duraderos	Son aquellos que describen funciones principales de la organización y pertenecen al dominio del sistema, por lo que son relativamente estables.	Los requerimientos relacionados con un sistema para administrar un hotel incluirán huéspedes, reservación de habitaciones, check in/check out, entre otros; rara vez existirán cambios al proceso general que los describe.
Volátiles	Aquellos que los cambios son muy comunes. Piensa por ejemplo en un sistema de contabilidad.	Las reglas que impone el SAT (Servicio de Administración Tributaria) para el cálculo de impuestos hacen que los contadores deban ajustar sus procesos cada vez que se publica un cambio en el Diario Oficial de la Federación y esto suelen ser muy recurrentes durante el año.

Para Harker et al. (1993) dentro de los requerimientos volátiles se encuentran los siguientes:

Clase	Descripción
Mutables	Requerimientos que cambian debido modificaciones en el entorno de la organización.
Emergentes	Son requerimientos nuevos que el cliente solicita porque al analizar sus necesidades comprende mejor cuál es su problema.
Consecuentes	Implementar un sistema de información puede provocar cambios en los procesos internos a la organización y abre nuevas posibilidades de realizar el mismo trabajo, lo que conduce a generar nuevos requerimientos.
De compatibilidad	Algunos requerimientos dependen de otros sistemas. Si estos sistemas cambian pueden provocar nuevos ajustes para mantener la compatibilidad.

15.2 Solicitud de cambios

Ante esta posibilidad de cambios a los requerimientos iniciales del proyecto de sistema, surge la necesidad de tener un control sobre aquellas modificaciones que se aceptan o se rechazan, es decir, una administración de cambios. No todos se pueden aceptar, tampoco es posible impedirlos. Es mejor establecer un mecanismo adecuado para mantener la inspección y seguimiento a los cambios que vayan surgiendo.

Fuente: Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson.

Gestión del cambio:

Si los cambios son inevitables y pueden surgir en cualquier etapa del desarrollo del sistema, lo mejor que puedes hacer es prepararte para administrarlos de la mejor manera. Esto implica establecer un proceso formal en el que se puedan solicitar, analizar e implementar.

“La ventaja de utilizar un proceso formal para gestionar el cambio es que todos los cambios propuestos son tratados de forma consistente y que los cambios en el documento de requerimientos se hacen de forma controlada”. Sommerville (2011)

Sommerville (2011) propone tres pasos para establecer este proceso formal:

Análisis del problema y especificación del cambio. Cualquier persona involucrada en el proyecto puede proponer un cambio a un requerimiento, siempre y cuando lo justifique. Para ello debe llenar una solicitud de cambio, esta información será estudiada para un posterior análisis de factibilidad.
Análisis del cambio y cálculo de costos. La solicitud de cambio se analiza por el ingeniero de requerimientos y las personas que posiblemente se vean afectadas. En este paso se realiza un rastreo de los requerimientos relacionados, se analizan los posibles impactos directos o indirectos y se hace un cálculo del costo de hacer las modificaciones. Con este análisis se determina si es posible implementar el cambio o si se requerirá de un proceso de negociaciones.
Implementación del cambio. Cuando los cambios son factibles, se realizan los ajustes a la documentación y, si aplica, a las etapas del desarrollo que se vean impactadas.

Formato de solicitud de cambios

Llenar una solicitud de cambios debe ser un proceso sencillo y conocido por todos los stakeholders. Tiene dos objetivos, el primero tiene que ver con obligar al solicitante a analizar el cambio que está solicitando. Es común que soliciten cambios triviales o sin reflexionar y el acto de llenar la solicitud permite que lo describan mejor. El segundo objetivo es contar con un repositorio donde se ubique toda la información de los cambios solicitados.

La forma incluye los siguientes datos:

Observa que aparecen dos secciones, la primera es llenada por el solicitante y la segunda por el comité evaluador. Cada solicitud debe tener un identificador único con el que se le pueda dar seguimiento y respuesta.

Es recomendable utilizar un formato electrónico que llene automáticamente algunos datos, como el número de solicitud y la fecha, y precargue los números de requerimientos y su descripción. Esto permitirá evitar errores de captura y asegura la trazabilidad de los cambios. La sección de la resolución deberá estar activa sólo para el comité evaluador.

En algunos modelos de desarrollo ágil, la solicitud de cambios se realiza dentro de la junta semanal de seguimiento, el cambio es analizado y priorizado en la misma reunión. Si su prioridad es alta podría desplazar a otros requerimientos que serían atendidos en esa semana.

15.3 Análisis de impacto

Algunos cambios serán muy simples y no tendrán impacto en el proyecto, otros, en cambio, provocarán posibles modificaciones en el documento de especificaciones, retrabajo en el diseño, modificaciones al código y repetir las pruebas. El análisis del impacto es indispensable porque hay alteraciones que podrían poner en riesgo el resultado mismo del proyecto.

Para evaluar el impacto de una solicitud de cambio, se debe crear un comité evaluador, que será responsable de considerar los siguientes elementos:

Elementos a considerar para evaluar el impacto

Razón del esfuerzo y los beneficios del cambio propuesto.
Efectos negativos del cambio propuesto.
Daños colaterales a requerimientos no funcionales que podrían surgir al aceptar el cambio, como rendimiento, velocidad, capacidad o calidad.
Consecuencias de no realizar el cambio.
Factibilidad del cambio con los recursos actuales (restricciones presupuestales, habilidades del personal y tiempo necesario).
Nuevas herramientas para implementar y probar el cambio.
Necesidad de crear prototipos o simulaciones para revisar la idoneidad del cambio.
Cantidad de esfuerzo ya realizado que podría perderse.
Impacto a la secuencia de actividades del cronograma y a la fecha original de entrega.

Una vez analizado el impacto este comité dictaminará si aprueba o se rechaza. En caso de ratificarlo deberá asignarle una prioridad dentro de la lista de cambios sugeridos y se asignará a un proyecto que gestione todos los cambios aprobados.

Fuente: Pohl, K. y Rupp, C. (2011). Requirements Engineering Fundamentals. EE. UU.: Rocky Nook.

Una vez implementado el cambio, el comité validará los costos y beneficios que se habían estimado en comparación con los reales, con el objetivo de determinar si efectivamente el proceso de pronosticación es correcto o deben realizarse ajustes para los siguientes cambios o proyectos.