CICLO DE VIDA DEL BA:

MONITOREO,
CONTROL Y EVALUACIÓN
DE LAS SOLUCIONES
AUTORA: ROCÍO ZELADA
CONTENIDO
INTRODUCCIÓN.................................................................................................................. 3

1. TRAZABILIDAD Y MONITOREO ................................................................................ 5

1.1. Beneficios del rastreo de requisitos.........................................................................6
1.2. La matriz de Trazabilidad..........................................................................................7
1.2.1. Atributos de requisitos........................................................................................7
1.2.2. Jerarquía de la matriz de trazabilidad............................................................8
1.2.3. Relaciones y dependencias ...............................................................................9
1.2.4. Aprobación de requerimientos...................................................................... 10
1.2.5. Niveles de autorización .................................................................................. 10
1.2.6. Línea base de requisitos .................................................................................. 11
1.2.7. Línea base: alcance del producto y alcance del proyecto.......................11
1.2.8. Cartera de productos o Backlog de producto ........................................... 12
1.2.9. Monitoreo de requisitos y uso de una matriz de trazabilidad ..............13
1.2.10. Beneficios del uso de la trazabilidad para monitorear los requisitos.13
1.2. 11. Ciclo de vida de los requerimientos ......................................................... 13
1.2. 12. Gestión de cambios en los requerimientos............................................. 14
1.2.13. Gestión del cambio en relación con el análisis de negocios ................15
1.2.14. Herramientas y técnicas de control de cambios.................................... 16
1.2.15. Análisis de impacto........................................................................................ 17
1.2. 16. Cursos de acción frente a un cambio........................................................ 18
1.2.17. Control de cambios relacionados con defectos ..................................... 20

2. EVALUACIÓN DE SOLUCIÓN ...................................................................................21

2.1. Propósito de la evaluación de soluciones........................................................... 22
2.2. Mentalidad recomendada para la evaluación .................................................. 22
2.3. Planificar la evaluación de la solución................................................................ 23
2.4. Determinar qué evaluar.......................................................................................... 24
2.5. Cuándo y cómo validar los resultados de la solución...................................... 26
2.6. Evaluar los criterios de aceptación y abordar los defectos............................ 27
2.7. Decisión de hacerlo/no hacerlo (GO / NO GO) ................................................ 27
2.8. Obtener la aprobación de la solución ................................................................. 28

2
 2.9. Evaluar el rendimiento a largo plazo de la solución ........................................ 29
2.10. Reemplazo/eliminación gradual de soluciones.............................................. 30

3. CONCLUSIÓN...............................................................................................................32

BIBLIOGRAFÍA...................................................................................................................35

3
INTRODUCCIÓN

Desde la perspectiva de la Guía PMBOK®, la tra-

zabilidad y el monitoreo consisten en las activi-
dades complementarias para garantizar que los
requisitos se aprueben y gestionen a lo largo del
ciclo de vida del proyecto. Durante la trazabilidad
y el monitoreo, la matriz de trazabilidad y los atri-
butos asociados se crean y aplican para ayudar a
monitorear y controlar el alcance del producto.
(Institute, 2015).

En base a los requisitos aprobados se realizan

monitoreos y seguimientos. A medida que surgen
nuevos requisitos, estos se documentan, se agre-
gan a la matriz de trazabilidad, se evalúan por sus
impactos en el proyecto y el producto, y se pre-
sentan a las partes interesadas para su aproba-
ción. A lo largo de la trazabilidad y el seguimiento,
el estado de todos los requisitos se comunica uti-
lizando los métodos de comunicación definidos y
aprobados dentro del plan de análisis de negocio.

El tipo de pensamiento que es inherente a la tra-

zabilidad y el monitoreo se aplica a todos los pro-
yectos y todos los ciclos de vida. Pensar en las
relaciones entre los requisitos y sus relaciones
con otras consideraciones del proyecto, como
pruebas y lanzamientos, es fundamental para ga-
rantizar la consistencia y la integridad del proyec-
to. Los principios de trazabilidad que permiten el
análisis del impacto del cambio son la base para
confirmar el cumplimiento de los objetivos y ga-
rantizar la cobertura de las pruebas. La trazabili-
dad permite descubrir requisitos faltantes y ex-
traños.

Existe la necesidad de rastrear y monitorear los

requisitos completados, sin importar qué tipo de
ciclo de vida se use para un proyecto o qué tipo de
formato se use para documentar los requisitos. La

4
trazabilidad debe mantenerse, como mínimo, durante toda la duración del proyecto, inclu-
so cuando alguien con un rol de análisis de negocio ya no está asociado con el proyecto.

La trazabilidad y el monitoreo formales e integrales requieren un esfuerzo inicial para la

configuración, pero solo proporcionan beneficios cuando existe un compromiso continuo
de esfuerzo para mantenerlos y cuando las partes interesadas los utilizan porque les agre-
ga valor. No todas las organizaciones o proyectos pueden necesitar una trazabilidad formal
e integral de los requisitos. Además, se puede lograr cierto grado de trazabilidad de mane-
ras menos formales y puede ser suficiente para el trabajo en cuestión.

*Nota de autor: este libro está basado principalmente en Business Analysis for Practitiones -
PMI (Institute, PMI-Project Management, 2015).

5
 01
TRAZABILIDAD
Y MONITOREO
La trazabilidad proporciona la capacidad de rastrear los requisitos del producto
desde su origen hasta los entregables que los satisfacen. La trazabilidad a veces se
califica como bidireccional o hacia adelante y hacia atrás, porque los requisitos se
rastrean en más de una dirección. No todos los proyectos requieren la misma canti-
dad de trazabilidad; por lo tanto, los entregables específicos que se rastrearán para
el proyecto se determinan durante la planificación del análisis de negocios. En ge-
neral, los proyectos más complejos requieren más trazabilidad. Un proyecto en una
industria fuertemente regulada o con numerosos componentes, interfaces, riesgos
y partes interesadas probablemente requerirá más trazabilidad que un proyecto
sin estas características (Institute, 2015).

La trazabilidad incluye, pero no se limita al seguimiento de los siguientes requisitos:

• Necesidades comerciales (problemas u oportunidades comerciales), metas y

objetivos.
• Objetivos del proyecto.
• Alcance del proyecto/entregables..
• Componentes de diseño y desarrollo de productos.
• Estrategia de prueba y escenarios de prueba.
• Requisitos de alto nivel.
• Diferentes tipos de requisitos funcionales que están relacionados entre sí.
Por ejemplo, agregar un nuevo tipo de cliente requiere cambios en varios
procesos empresariales que utilizan datos de clientes.

Para proyectos que utilizan un ciclo de vida adaptativo:

• Epics¹ o historias de usuario² se pueden rastrear a características y pruebas

de aceptación.
• Un tablero Kanban³ puede proporcionar cierto nivel de trazabilidad.

6
1.1. BENEFICIOS DEL RASTREO DE REQUISITOS
El rastreo de requisitos proporciona beneficios significativos:

Ayuda a garantizar que cada requisito agregue valor de negocio. Conectar

cada requisito a la necesidad, metas y objetivos del negocio ayuda a garantizar
su relevancia. Cuando el requisito ayuda a resolver un problema de negocio,
aprovecha una oportunidad de negocio o cumple al menos una meta u
objetivo, es relevante y es una indicación de que el producto final agregará
valor.

Por otro lado, cuando el requisito no se puede relacionar con una necesidad,
meta u objetivo comercial, su relevancia debe analizarse. En este caso, el
analista de negocios debe considerar hacer las siguientes preguntas:

Figura 1: Preguntas para garantizar que cada requisito agregue valor de negocio (Elaboración propia)

Ayuda a satisfacer las expectativas del cliente. La trazabilidad proporciona

un medio para realizar un seguimiento de los requisitos a lo largo del ciclo
de vida del proyecto, lo que ayuda a garantizar que los requisitos aprobados
se entreguen al final del proyecto. Por ejemplo, un campo de datos en una
interfaz de usuario (IU) es un requisito aprobado, pero si no se desarrolla,
prueba o entrega, el campo de datos esperado faltará en la interfaz de usuario
en la solución implementada.

Ayuda a administrar el alcance. Es más difícil que los requisitos que no

agregan valor se desarrollen como parte del producto, porque se da prioridad
a los requisitos que agregan valor. Los proyectos predictivos proporcionan
un mejor caso para la trazabilidad formal que los proyectos adaptativos; sin
embargo, el modelo de ciclo de vida no es el único factor que determina la
cantidad óptima de trazabilidad. Otros factores incluyen si el negocio está o
no altamente regulado, las políticas y procesos organizacionales, y el grado
en que se utiliza realmente la trazabilidad.

7
 Figura 2: Analista de negocios versus Gerentes de proyecto en relación al alcance.
(Elaboración propia)

1.2. LA MATRIZ DE TRAZABILIDAD

Una matriz de trazabilidad permite la vinculación de los requisitos del
producto desde su origen hasta los entregables que los satisfacen a lo largo del
ciclo de vida del proyecto. La implementación de una matriz de trazabilidad de
requisitos apoya el objetivo de que cada requisito agregue valor de negocio
al vincularlo a los objetivos del negocio y del proyecto. Proporciona un medio
para realizar un seguimiento de los requisitos a lo largo del ciclo de vida del
proyecto, lo que ayuda a garantizar que los requisitos se entreguen al final del
proyecto. La matriz también proporciona una estructura para gestionar los
cambios, lo que ayuda a gestionar el alcance del producto (Institute, 2015).

Para los proyectos que utilizan una matriz de trazabilidad, el analista

de negocios puede aprovechar la plantilla de matriz de trazabilidad
estándar de la organización. Cuando no hay una plantilla de matriz
de trazabilidad, entonces la matriz debe crearse como parte de la
planificación del análisis de negocios.

1.2.1. Atributos de requisitos

Para la trazabilidad formal, el analista de negocios debe tener cuidado al se-
leccionar los atributos de los requisitos para garantizar que se elijan el tipo y
el número adecuados. El analista de negocios debe asegurarse de elegir atri-
butos que realmente se rastrearán y administrarán y no se pasarán por alto.
Se debe tener cuidado para garantizar que los atributos seleccionados no se
superpongan con la información que se rastrea y administra en otros lugares.
Cuando la información se duplica, se deben tomar medidas para asegurarse
de que esté sincronizada en todas las ubicaciones.

La organización puede determinar que siempre se deben tener en cuenta al-

gunos atributos, por ejemplo, la fecha de creación, la fecha de la última revi-
sión y el número de versión, debido al valor que estos atributos proporcionan
para administrar y controlar los cambios de requisitos.

8
 Figura 3: Matriz de Trazabilidad de Requisitos (En base a PMcollege)

1.2.2. Jerarquía de la matriz de trazabilidad

Una matriz de trazabilidad formal generalmente se construye jerárquica-
mente, comenzando con los requisitos de alto nivel y completando los deta-
lles a medida que el requisito se elabora progresivamente. Esta jerarquía es
similar a un esquema que se completa a medida que se conocen más detalles.

Hay varias ventajas de crear una matriz jerárquica:

• Proporciona un orden lógico para los requisitos, no se interrumpe cuando se

agregan nuevos requisitos. Está claro a dónde pertenece cada nuevo requi-
sito y si está relacionado con otro requisito. También proporciona una forma
de organizar los requisitos para garantizar que no haya requisitos duplicados
o contradictorios.
• La trazabilidad se puede iniciar tan pronto como se define y detalla el primer
requisito, ya que los requisitos se elaboran progresivamente, lo que permite
el desarrollo incremental de los requisitos.
• No hay una secuencia implícita, lo que permite que el trabajo se divida fácil-
mente entre el equipo.

9
1.2.3. Relaciones y dependencias
La matriz de trazabilidad es una herramienta que soporta el análisis de de-
pendencias y el análisis de impacto. Los requisitos a menudo están relaciona-
dos con otros requisitos; por lo tanto, a veces un requisito no puede satisfa-
cerse en una solución sin que el otro (s) esté presente. Una vez analizado, el
conjunto de requisitos en la matriz de trazabilidad se registra agrupando los
requisitos dependientes. Algunas herramientas de gestión de requisitos ilus-
tran visualmente las dependencias mediante la creación de árboles de traza-
bilidad. Algunos ejemplos de relaciones dependientes son los siguientes:

Figura 4: Tipos de Dependencia entre Requerimientos (Elaboración propia)

10
1.2.4. Aprobación de requerimientos
Las organizaciones y los proyectos varían en la forma en que se aprueban los
requisitos. Algunas organizaciones requieren una firma formal de un paque-
te de requisitos, como un documento de requisitos empresariales. En otras
organizaciones o para tipos específicos de proyectos, la aprobación de los re-
quisitos puede ser informal, requiriendo solo una aprobación verbal. El pro-
ceso de aprobación se determina, documenta y aprueba por adelantado en la
planificación del análisis de negocios. Determinar el proceso desde el princi-
pio ayuda a evitar conflictos más adelante cuando se buscan las aprobaciones
(Institute, 2015).

1.2.5. Niveles de autorización

Los niveles de autorización forman parte de un sistema de autorización de
trabajo. Los niveles de aprobación proporcionan los detalles sobre quién tie-
ne la autoridad para aprobar requisitos nuevos y modificados. En ausencia de
un sistema de autorización de trabajo o cuando el sistema actual no cubre la
aprobación de requisitos, el analista de negocios, el gerente de proyecto y el
patrocinador determinan los niveles de aprobación de requisitos en la plani-
ficación del análisis de negocios.

Herramientas como una matriz RACI³’ son útiles para facilitar las
discusiones y decisiones sobre los niveles de aprobación. Existen
diferentes tipos de aprobaciones. Distinguir entre estos diferen-
tes tipos ayuda a evitar confusiones sobre quién puede aprobar
qué. Algunos ejemplos son:

11
 Figura 5: Niveles de Autorización (Elaboración propia, 2022)

1.2.6. Línea base de requisitos

La línea base contiene todos los requisitos aprobados del proyecto, la fase
del proyecto, la iteración, el incremento, la liberación o cualquier otra par-
te de un proyecto. La línea de base proporciona un mecanismo de compara-
ción, lo que permite al equipo del proyecto reconocer que se ha producido un
cambio. Todo el trabajo aprobado está dentro del límite o línea de base. Todo
lo que está fuera del límite debe ser aprobado. Una vez que se aprueban los
requisitos, estos solo se pueden cambiar a través de los procedimientos de
control de cambios definidos para el proyecto.

El grado de formalidad aplicado a los cambios fuera de la línea de base varía

según el ciclo de vida del proyecto y los procesos de la organización para ges-
tionar el cambio. Un proyecto que utiliza un ciclo de vida predictivo es apto
para aplicar un proceso de control de cambios más formal y complejo; un pro-
ceso menos formal se utiliza para proyectos con ciclos de vida adaptativos.

1.2.7. Línea base: alcance del producto y alcance

del proyecto
El alcance del proyecto es el trabajo realizado para entregar un producto,
servicio o resultado. El alcance del producto se compone de las caracterís-
ticas y funciones que caracterizan el producto, servicio o resultado. Los re-
quisitos describen características y funciones del producto final, servicio o

12
 resultado para el proyecto; por lo tanto, existe una relación directa en-
tre el número de requisitos y el alcance del producto. Cuantos más
requisitos aprobados haya, mayor será el alcance del producto y el
alcance del proyecto.

1.2.8. Cartera de productos o Backlog

de producto
El trabajo de análisis de negocios es importante en los proyectos, indepen-
dientemente si el proyecto sigue ciclos de vida adaptativos o predictivos.
Para los proyectos que siguen un ciclo de vida adaptativo, los requisitos de
la línea base se realizan manteniendo el backlog del producto. El backlog del
producto es la lista de requisitos, generalmente escrita en forma de historias
de usuario. Aunque no se conoce comúnmente como línea de base, el princi-
pio es el mismo para todos los ciclos de vida del proyecto. El backlog puede
tener algunas historias de usuario grandes, que cuando se desglosan, se pue-
de decidir que no se van a seleccionar y no se aprueban. En los proyectos de
ciclo de vida adaptativo, se aprueba un subconjunto del backlog para cada
iteración.

El propietario del producto es responsable de los requisitos del producto, co-

nocidos como características, así como de tomar decisiones prioritarias ba-
sadas en qué requisitos o historias de usuario proporcionan el mayor valor
al negocio. Los requisitos solicitados (características) se escriben como his-
torias de usuario y se agregan al backlog del producto a lo largo del proyecto.
Los nuevos requisitos a menudo surgen después de una revisión del producto
al final de cada iteración, pero se pueden solicitar en cualquier momento.

La prioridad de las historias de usuario puede cambiar en cualquier

momento. Un requisito que se considera de alta prioridad al co-
mienzo de un proyecto puede cambiarse a una prioridad más baja
a medida que avanza el proyecto. Por otro lado, el propietario
del producto podría elevar la prioridad de otros requisitos que
originalmente se pensaba que no eran importantes. El analista
de negocios o la persona que desempeña ese rol puede optar por
mantener el estado de los requisitos a medida que se ejecuta el
proyecto, la versión o la iteración.

A medida que los requisitos se agregan al backlog del producto o los cambios
en la prioridad resultan en el movimiento de los requisitos de una versión o
iteración a otra, los cambios se rastrean y se comunican a las partes interesa-
das apropiadas según lo acordado en el plan de comunicación, ya sea formal
o informalmente.

13
1.2.9. Monitoreo de requisitos y uso de una
matriz de trazabilidad
Una vez que se determinan los atributos de los requisitos, se crea la matriz
de trazabilidad y se aprueban los requisitos, los requisitos se supervisan a lo
largo del ciclo de vida del proyecto. Los proyectos con un ciclo de vida adap-
tativo que utilizan una matriz de trazabilidad pueden construir la matriz de
manera incremental de manera consistente a medida que se obtienen y ana-
lizan los detalles.

1.2.10. Beneficios del uso de la trazabilidad

para monitorear los requisitos
El monitoreo de los requisitos a lo largo del ciclo de vida utilizando una matriz
de trazabilidad o una estructura similar ayuda a garantizar que: Los requisi-
tos más detallados están vinculados a los requisitos de referencia. A medida
que los requisitos se elaboran progresivamente y surgen detalles adicionales,
las relaciones se elaboran progresivamente.

1.2. 11. Ciclo de vida de los requerimientos

El estado muestra dónde se encuentra en el ciclo de vida ese requi-
sito. El ciclo de vida de los requisitos, no debe confundirse con el
ciclo de vida del proyecto, representa las diversas fases por las
que se mueve un requisito a medida que se mantiene a lo largo
del proyecto. Durante la planificación del análisis de negocio, se
define la lista de estados de requisitos para el proyecto.

Cuando una organización utiliza una herramienta de administración

de requisitos, el software mantiene automáticamente el estado de re-
quisitos después de que las reglas de negocio para determinar los cambios de
estado se configuran dentro de la herramienta. Sin una herramienta de ges-
tión de requisitos, el analista de negocios mantiene los estados manualmen-
te. Un organismo de autorización influye en el estado del requisito al tomar
decisiones sobre los requisitos, tales como:
• Aprobar un requerimiento, pero posponerlo a otro proyecto, iteración o fase
del proyecto.
• Diferir un requerimiento a algún proyecto, iteración o fase de proyecto futu-
ro no especificado.

14
 • Reemplazar un requerimiento aprobado que no se ha iniciado por otro re-
querimiento.
• Cancelar un requerimiento aprobado.
• Rechazar un requerimiento solicitado; o una combinación de lo anterior. Por
ejemplo, el organismo autorizante podría aprobar una parte del requerimien-
to, pero aplazar otra.

1.2. 12. Gestión de cambios

en los requerimientos
Se puede proponer un cambio en un requisito en cualquier momento duran-
te un proyecto. Quién puede proponer cambios y cómo se proponen esos
cambios se definen en el plan de análisis de negocios. Aunque los cambios
sugeridos pueden iniciarse verbalmente, estos deben registrarse para fines
de seguimiento y gestión.

Figure 6: Ciclo de Vida de los Requisitos (PMI-BA Practitioners Guide, 2022)

Las solicitudes de cambio son parte del proceso general de control de cam-
bios. La Guía PMBOK® define una solicitud de cambio como una propues-
ta formal para modificar cualquier documento, entregable o línea de base.
Cuando la plantilla de solicitud de cambio se define y se mantiene como un

En los casos en que una plantilla no está definida, la plantilla debe

crearse como parte de la planificación del análisis empresarial. Algunos
ciclos de vida de los proyectos utilizan un proceso informal de control
de cambios y, por lo tanto, una propuesta menos formal es aceptable,
por ejemplo, discutir el cambio.
15
 activo de proceso organizativo, el equipo del proyecto debe usar la plantilla
aprobada en el proyecto.

El proceso de control de cambios define cómo se gestionan los cambios. Para

el control formal de cambios, las solicitudes de cambio se envían manualmen-
te o como parte de un proceso en línea. El analista de negocios monitorea las
solicitudes de cambio y toma un papel activo en la evaluación de los impactos
de un cambio propuesto. Un proceso de solicitud de cambio define la infor-
mación que se debe recopilar antes de que una solicitud pueda considerarse
para su aprobación. Es posible que se requiera que el analista de negocios
recopile información basada en el nivel de esfuerzo para realizar el cambio,
los impactos en los costos, los impactos de riesgo y los impactos en el trabajo
completado o los requisitos aprobados existentes.

Eventualmente, cada solicitud de cambio registrada debe ser apro-

bada, diferida o rechazada por el organismo de aprobación de
cambios de acuerdo con el proceso definido en el plan de análisis
de negocios. El proceso de cambio puede requerir un tiempo de
respuesta recomendado que el equipo del proyecto debe cum-
plir al evaluar un cambio propuesto.

1.2.13. Gestión del cambio en relación con

el análisis de negocios
Tanto los gerentes de proyectos y los analistas de negocios tienen interés en
la gestión del cambio, pero desde puntos de vista distintos:

16
 Figura 7: Gestión de Cambio: Gerente de proyectos versus Analista de Negocio. (Elaboración propia)

1.2.14. Herramientas y técnicas de control

de cambios
Se pueden utilizar herramientas manuales o automatizadas para gestionar
las solicitudes de cambio y las decisiones resultantes. Es posible que estas
herramientas ya existan dentro de la organización. Cuando se introduce una
herramienta de control de cambios en un proyecto, se deben considerar las
necesidades de todas las partes interesadas involucradas en el proceso de
control de cambios.

Dos de las herramientas clave para el control de cambios son:

Figura 8: Herramientas de Control de Cambios. (Elaboración propia)

17
1.2.15. Análisis de impacto
Cuando se propone un cambio de requisito, es necesario completar un análi-
sis de impacto para evaluar el cambio propuesto en relación con cómo afec-
tará a otros requisitos, el producto, el proyecto y el programa. El análisis de
impacto es el trabajo realizado para evaluar un cambio propuesto, que inclu-
ye la identificación de los riesgos asociados al cambio, el trabajo requerido
para incorporar el cambio y las implicaciones de cronograma y costos.

Un beneficio clave de completar un análisis de impacto es que per-

mite que los cambios dentro del proyecto se consideren de mane-
ra integrada, reduciendo así el riesgo del proyecto y del produc-
to, que a menudo surge de los cambios realizados sin tener en
cuenta el efecto en el programa, el proyecto y el producto final.

Las siguientes secciones explican un enfoque formal para el análi-

sis de impacto. Los proyectos que utilizan un ciclo de vida adaptativo
pueden utilizar un enfoque informal para evaluar los impactos y diseñar
un curso de acción basado en el valor del cambio junto con sus impactos. El
análisis de impacto incluye, pero no se limita a, lo siguiente:

18
1.2. 16. Cursos de acción frente a un cambio
Figura 9: Tipos de Impactos (Elaboración propia)

Después de analizar todos los impactos del cambio y comprender el alcance,

el riesgo, el cronograma y las implicaciones de costos, el analista de negocios
reúne los resultados del análisis. El analista de negocios recomienda un curso
de acción e incluye esta recomendación en la evaluación. Algunas organiza-
ciones buscan que el equipo del proyecto proporcione más de una alternativa
junto con los pros y los contras, suposiciones, riesgos, etc. para cada alterna-
tiva.

Cada evaluación de impacto puede dar lugar a una forma abreviada

de un caso de negocio para hablar del valor del cambio. El propó-
sito de la recomendación y el análisis de apoyo es proporcionar
a los responsables de aprobar el cambio toda la información re-
querida para tomar una decisión acertada.

Los siguientes cursos de acción son posibles después de evaluar el

cambio propuesto:

19
 Figura 10: Cursos de Acción frente a un cambio (Elaboración propia)

Independientemente de la decisión tomada por el organismo autorizante, el

analista de negocios tiene la responsabilidad de comunicar el resultado de la
discusión del cambio con las partes interesadas del proyecto. Las partes inte-
resadas deben comprender por qué un cambio fue aplazado o rechazado y la
justificación de la decisión tanto como tienen la necesidad de escuchar sobre
las solicitudes de cambio aprobadas.

Figura 11: Cambios en proyectos de Ciclo de vida adaptativos. (Elaboración propia)

20
 El grado de formalidad y la cantidad de documentación para el proceso de
decisión de cambio depende de los requisitos de las políticas y procesos de la
organización o las regulaciones externas.

1.2.17. Control de cambios relacionados

con defectos
No todos los cambios propuestos son solicitudes de nuevas características
o nuevos requisitos. Algunos cambios son solicitudes para corregir defectos
que se identifican en la solución. Dichos defectos pueden plantearse después
de auditorías formales o informales (por ejemplo, inspecciones o tutoriales) o
pueden surgir cuando las partes interesadas interactúan con la solución.

Debido a que un defecto es una desviación de un requisito, el analista de

negocios se mantiene involucrado en el proceso de reparación de defectos
al monitorear la reparación o el reemplazo del componente de solución no
conforme. Aunque la documentación relacionada con los requisitos no se ve
afectada, es el componente que se está modificando para que se alinee con el
requisito aprobado.

21
 02
EVALUACIÓN
DE SOLUCIÓN
La evaluación consiste en actividades de análisis de negocio realizadas para validar
una solución completa, o un segmento de una solución, que está a punto de ser o ya
se ha implementado. La evaluación determina qué tan bien una solución satisface
las necesidades de negocio expresadas por las partes interesadas, incluida la en-
trega de valor al cliente. Algunas actividades de evaluación dan lugar a una evalua-
ción cualitativa o cuantitativa gruesa de una solución. La realización de encuestas
o grupos focales y el análisis de los resultados de las pruebas exploratorias de fun-
cionalidad son ejemplos de evaluación cualitativa. Otras actividades de evaluación
implican mediciones más precisas, cuantitativas y explícitas.

Las comparaciones entre los resultados esperados y reales obtenidos

de una solución generalmente se expresan cuantitativamente. Para
las soluciones que involucran software, el análisis de comparaciones
entre los valores esperados y reales de los datos manipulados por
la funcionalidad de alto nivel de la solución pueden ser parte de la
evaluación.

Las características no funcionales de una solución (a veces conocidas

como atributos de calidad) a menudo se evalúan con mediciones. Por
ejemplo, se requieren mediciones para evaluar si se están cumpliendo los
acuerdos de nivel de servicio de rendimiento. Además, la comparación de los
costos y beneficios estimados y reales puede ser parte de una evaluación de una
solución.

Esta sección se cubrirán las actividades de evaluación cualitativa y

cuantitativa. Las técnicas descritas en este documento son compati-
bles con los ciclos de vida predictivos, iterativos y adaptativos de los
proyectos. La mayoría de estas técnicas son útiles para todo tipo de
proyectos y soluciones. Se identifican algunas técnicas que se apli-
can específicamente a soluciones que involucran software.

22
 Muchas de las técnicas utilizadas durante las actividades de evaluación también
se utilizan durante el análisis o las pruebas y, a veces, durante la evaluación de las
necesidades. Además, existe cierta superposición entre las técnicas de evaluación
y la trazabilidad. El uso de técnicas de análisis para múltiples propósitos es natural
porque uno de los objetivos generales de todas las actividades de análisis es obte-
ner una comprensión clara e inequívoca de todos los aspectos de un problema en
consideración.

2.1. PROPÓSITO DE LA EVALUACIÓN DE

SOLUCIONES
Las actividades de evaluación de soluciones proporcionan la capacidad de
evaluar si una solución ha logrado o no el resultado comercial deseado. La
evaluación proporciona información para tomar decisiones de negocio y téc-
nicas al lanzar una solución completa o un segmento de ella. Para proyectos
que utilizan ciclos de vida iterativos o adaptativos, y para proyectos multifá-
sicos que utilizan ciclos de vida predictivos, la evaluación puede identificar un
punto de rendimientos decrecientes. Un ejemplo de esto es cuando se podría
obtener un valor adicional de un proyecto, pero el esfuerzo adicional necesa-
rio para lograrlo no está justificado.

La evaluación de una solución implementada también se puede utilizar para

identificar requisitos nuevos o modificados, lo que puede conducir al refina-
miento de la solución o a nuevas soluciones. La identificación y definición de
criterios de evaluación también apoya otras actividades de análisis.

2.2. MENTALIDAD RECOMENDADA PARA LA

EVALUACIÓN
Durante el proceso de evaluación es importante utilizar la mentalidad ade-
cuada, las siguientes son recomendaciones de cómo y cuándo evaluar:

Figure 12: Mentalidad para la Evaluación (Elaboración propia)

23
2.3. PLANIFICAR LA EVALUACIÓN
DE LA SOLUCIÓN
Realizar actividades de evaluación no es una tarea trivial. Se necesita tiempo
y esfuerzo para identificar y confirmar los criterios de evaluación, implemen-
tar todo lo necesario para tomar medidas que aún no están integradas en la
solución o su infraestructura, tomar las mediciones e informar y analizar las
mediciones. Los factores a considerar al planificar las actividades de evalua-
ción incluyen:

Figura 13: Preparación para la Evaluación (Elaboración propia)

24
2.4. DETERMINAR QUÉ EVALUAR

Hay una serie de factores en los que pensar al identificar los criterios de eva-
luación. En esta sección se presenta una lista de estos elementos para su con-
sideración.

• Considerar las metas y objetivos de negocio

Las metas, objetivos y prioridades de negocio permiten que un proyecto se

lance y resulte en una solución. La solución debe evaluarse en función de esas
metas y objetivos. Las metas y objetivos deben ser SMART. Las mediciones
especificadas en las metas y objetivos sirven como buenas pistas sobre lo que
debe medirse durante la evaluación de la solución.

Figura 14: Objetivos SMART (Diccionario de Marketing, DIRCOMFIDENCIAL)

• Considerar los indicadores clave de rendimiento

Los indicadores clave de rendimiento (KPI) son métricas que generalmente

son definidas por los ejecutivos de una organización. Estos indicadores se
pueden utilizar para evaluar el progreso de una organización en el logro de
sus objetivos o metas. Las categorías amplias típicas de KPI son: finanzas,
clientes, ventas y marketing, procesos operativos, empleados y medio am-
biente / corporativo, y responsabilidad social / sostenibilidad.

A veces, la tecnología de la información se incorpora a la categoría de pro-

cesos operativos y, a veces, se considera una categoría de KPI separada. La
mayoría de las metas y objetivos del proyecto están asociados con uno o más
de estos KPI. Para las organizaciones que ya definen y miden kpis, uno o más
de estos KPIs se pueden utilizar para evaluar la solución, aprovechando las
capacidades de medición para KPIs que ya se han utilizado de alguna manera.

25
 Figure 15: KPI (Key Performance Indicator) (Atrahunt, s.f.2022)

• Considerar métricas de evaluación adicionales y criterios de aceptación de

evaluación

Si bien muchas de las métricas y criterios de aceptación para evaluar la solu-

ción se salen de las metas, objetivos o KPI, puede haber métricas y criterios
de aceptación adicionales a considerar. Algunos ejemplos de métricas adicio-
nales y criterios de aceptación son:

26
 Figura 16: Métricas adicionales para la evaluación de una solución (Elaboración propia)

A medida que se identifican las mediciones, se deben revisar las es-

timaciones de los costos de la evaluación y actualizarlas según sea
necesario. Cuando sea necesario, se debe volver a confirmar que
la organización o el departamento que patrocina la evaluación y
cubre los costos aún puede o está dispuesto a hacerlo.

2.5. CUÁNDO Y CÓMO VALIDAR

LOS RESULTADOS DE LA SOLUCIÓN

Figura 17: validación de los resultados de la solución (Elaboración propia)

Las siguientes técnicas de evaluación se pueden utilizar para evaluar los re-
sultados de la solución:

• Encuestas y grupos focales

• Resultados de pruebas exploratorias y pruebas de aceptación del usuario
• Resultados de pruebas diarias
• Resultados de pruebas de integración
• Resultados esperados vs. resultados reales para la funcionalidad
• Resultados esperados vs. reales para requisitos no funcionales
• Mediciones de resultados y cálculo financiero de beneficios

Si bien esta lista no es exhaustiva, contiene técnicas ampliamente utilizadas.

27
2.6. EVALUAR LOS CRITERIOS DE ACEPTACIÓN Y
ABORDAR LOS DEFECTOS
A medida que se producen las evaluaciones, independientemente del tipo de
ciclo de vida, se produce una o más de las siguientes actividades:

Figura 18: Criterios de Aceptación (Elaboración Propia)

2.7. DECISIÓN DE HACERLO/NO HACERLO

(GO / NO GO)
Cuando la evaluación se lleva a cabo antes del lanzamiento de una solución
completa o un segmento de una solución, las partes interesadas necesitan
decidir si la solución debe liberarse en su totalidad o en parte o no debe libe-
rarse en absoluto. Las partes interesadas en la matriz RACI tienen un papel
para aprobar o aprobar la solución son generalmente las personas que toman
la decisión de hacerlo /no hacerlo (GO / NO GO).

Siempre que sea posible, los resultados de la evaluación deben presentarse

en forma tabular o visual (es decir, tablas / gráficos / pictóricos) para ayudar a
los tomadores de decisiones a comprender el impacto y tomar una decisión.

Es importante resumir los resultados de la evaluación de una manera

significativa, porque las evaluaciones pueden producir cantidades
voluminosas de información.

28
 A su vez, dentro de lo posible, las decisiones de hacerlo o no hacerlo deben
tomarse durante una reunión en persona para permitir que todas las partes
interesadas escuchen la justificación de las decisiones de sus contrapartes. Al
igual que cualquier reunión bien dirigida, se recomienda el uso de una agenda
de tiempo limitado que se comparta con todas las partes interesadas antes
de la reunión para las reuniones de decisión de hacerlo / no hacerlo.

Las partes interesadas deben tener acceso a los resultados resu-

midos de la evaluación antes de la reunión. Ya debería haber un
modelo de decisión acordado sobre cómo llegar a una decisión.
Un “hacerlo” permite la liberación de la solución. Un “no hacerlo”
retrasa o desaprueba el lanzamiento de la solución.

La persona que analizó los resultados reales frente a los esperados

debe asistir a la reunión de decisión. En algunas organizaciones, ese
individuo también facilita la reunión, aunque el papel que facilita esta re-
unión depende de las preferencias de la organización. En cualquier caso, la
persona que dirige la reunión debe tener experiencia como facilitador. A ve-
ces, un resultado de la evaluación revela una razón primordial para retrasar
la liberación.

2.8. OBTENER LA APROBACIÓN DE LA

SOLUCIÓN
La formalidad de la firma depende del tipo de proyecto, el tipo de producto, el
ciclo de vida del proyecto y las restricciones corporativas y regulatorias. Por
ejemplo, las firmas formales para proyectos son un protocolo común cuando
una o más de las siguientes características están presentes:

• Proyectos con una línea de impacto en todo el negocio o en toda la empresa

• Productos en los que los errores o el incumplimiento de las tolerancias po-
drían provocar la muerte o un nivel inaceptable de riesgo para la vida, la pro-
piedad o la solvencia financiera
• Proyectos en organizaciones siguiendo estrictos ciclos de vida predictivos
• Industrias fuertemente reguladas, como la banca y los seguros o los dispositi-
vos médicos, la investigación clínica o las compañías farmacéuticas.

Las organizaciones con cualquier tipo de firma formal deben llegar a un acuer-
do sobre el formato de un documento de firma, cómo debe registrarse, cómo
debe almacenarse y si es necesario obtener la firma cuando todos los signata-
rios están físicamente juntos o si es aceptable firmar de forma remota.

29
2.9. EVALUAR EL RENDIMIENTO A LARGO
PLAZO DE LA SOLUCIÓN
La evaluación del rendimiento a largo plazo es parte de la evaluación
de los beneficios empresariales obtenidos mediante la implementa-
ción de la solución. El desempeño a largo plazo es un concepto am-
plio y se aplica a la ejecución o realización de trabajo en cualquier
forma por personas o sistemas o ambos. Casi cualquier cosa en
una solución que se identificó para la medición antes del lanza-
miento se puede evaluar a intervalos regulares a largo plazo para
identificar tendencias de rendimiento positivas o negativas.

Para las empresas que hacen uso de técnicas de inteligencia empre-

sarial, una vez que se lanza una solución, toda la información capturada
como parte de esa solución se puede analizar para identificar logros y ten-
dencias. Las organizaciones de marketing modernas confían en las capacida-
des de análisis / inteligencia empresarial para evaluar si las campañas de mar-
keting lograron o no los cambios deseados en el comportamiento del cliente
a largo plazo.

Figura 19: Actividades para Evaluar Rendimiento a largo Plazo de la Solución (Elaboración Propia)
30
2.10. REEMPLAZO/ELIMINACIÓN GRADUAL
DE SOLUCIONES
En general, existen cuatro estrategias para el reemplazo/eliminación gradual
de soluciones. Estas estrategias se aplican igualmente bien a las soluciones
automatizadas, manuales y mixtas:

Figura 20: Reemplazo/Eliminación gradual de soluciones. (Elaboración propia)

En general, los recortes masivos presentan más riesgo comercial que cual-
quier tipo de recorte segmentado o en el tiempo. Ocasionalmente, sin embar-
go, ese riesgo debe ser aceptado. Se puede realizar un análisis de costo-be-
neficio para determinar qué enfoque utilizar. Ya sea que se realice o no un
análisis formal de costo-beneficio, algunas preguntas de muestra o investiga-
ción que podrían llevarse a cabo para determinar la estrategia más adecuada
incluyen:

• ¿Cuál es el impacto operativo de tener dos soluciones? Subjetivamente, tener

dos soluciones puede parecer una mala idea desde un punto de vista operativo.
Sin embargo, cuando hay una gran cantidad de complejidad asociada con la solu-
ción anterior, puede ser más rentable hacer que ambas soluciones coexistan con
todos los nuevos negocios que van al reemplazo (por ejemplo, cuando es difícil
alinear la solución anterior con su reemplazo y la cantidad de negocios realizados
utilizando la solución anterior es muy pequeña).

• ¿Existen condiciones de marketing o de cara al cliente que requieran que todos

los clientes interactúen con la nueva solución al mismo tiempo? Los cambios
de logotipo son un ejemplo de un cambio que requeriría que todas las empresas
usen el nuevo logotipo en la misma fecha.

31
• ¿La solución de reemplazo involucra software? Para las soluciones que
involucran software, la transferencia generalmente incluye la con-
versión de datos de la solución anterior. Los recortes segmentados
o en caja de tiempo son buenas opciones cuando se trata de la con-
versión de datos.

• ¿Es aceptable que parte de la base de clientes use la solución an-

terior mientras que otros usan la solución de reemplazo? Muchas
empresas optan por ofrecer soluciones de reemplazo y anteriores
juntas como parte de una estrategia de reemplazo segmentada o de
caja de tiempo. Esto es especialmente cierto cuando se trata de sistemas
operativos de software e interfaces para software. Por ejemplo, los usuarios de
teléfonos celulares que tienen la misma marca de teléfono celular pueden usar
diferentes versiones de su sistema operativo; la nueva versión puede implemen-
tarse en segmentos, donde algunos clientes en un área específica pueden obte-
ner la nueva versión antes que otros; también es posible que los teléfonos más
antiguos no funcionen con el nuevo sistema operativo. Las aplicaciones ofrecidas
en estos teléfonos celulares pueden tener interfaces de usuario ligeramente di-
ferentes dependiendo del sistema operativo subyacente.

Independientemente de la estrategia que se seleccione, se debe tener cuida-

do de desarrollar toda la comunicación y el despliegue de la garantía necesa-
ria para cortar con éxito y adaptarse a una nueva solución. Estas actividades
incluyen, entre otras:

• Comunicación suficiente a las partes interesadas que se verán directa o indi-

rectamente afectadas por la nueva solución
• Finalización de los materiales de capacitación necesarios y entrega de capa-
citación
• Finalización o actualización de los procedimientos operativos estándar e ins-
trucciones de trabajo
• Compra, licencia e instalación de cualquier hardware necesario y software de
terceros necesario para respaldar la solución
• Coordinación con otras actividades dentro de la organización para garantizar
que la implementación ocurra en un momento en que la empresa pueda acep-
tar los cambios y la implementación no esté en conflicto con otros programas
en proceso y trabajo de proyecto
• Coordinación para garantizar que cualquier interrupción del negocio sea cla-
ramente identificada, comunicada y aceptable por los clientes.

32
 03
CONCLUSIÓN
En este libro se han resumido los conceptos, herramientas y técnicas más impor-
tantes relacionados a trazabilidad y el monitoreo del cumplimiento de requisitos.

Tanto en los proyectos que tienen ciclo de vida adaptativo o aquellos que tienen
ciclo de vida predictivo, la trazabilidad de los requisitos es muy importante para
asegurar que se cumple tanto con el alcance del producto, así también como el al-
cance el proyecto.

Una de las herramientas más importantes para lograr el rastreo y la trazabilidad

de requisitos es la Matriz Trazabilidad que permita la vinculación de los requisi-
tos del producto desde su origen hasta los entregables que los satisfacen a lo largo
del ciclo de vida del proyecto. La Matriz de Trazabilidad también permite registrar
ciertos Atributos de los Requisitos además de permitir entender las Relaciones y
Dependencias entre Requisitos.

Es muy importante tomar en cuenta que parte de la trazabilidad está relaciona-

da por la aprobación de requerimientos, es importante no solo entender quién ha
pedido un requerimiento sino también quién ha aprobado o rechazado un reque-
rimiento; para realizar una adecuada gestión de los estados de un requerimiento
se tienen distintos niveles de autorización. Otro concepto muy importante en el
ciclo de vida de un requerimiento es la línea base que es la que contiene los requi-
sitos aprobados ya sea para un proyecto, una fase una iteración, un incremento o
cualquier parte del proyecto, gracias a la línea base es que podemos identificar los
cambios en los requisitos y poder gestionarlos adecuadamente.

Para este efecto existen dos herramientas de apoyo a estas gestiones que son: sis-
tema de gestión de la configuración (CMS) que ayuda a garantizar que el producto
o servicio que se está construyendo cumpla con los requisitos previamente apro-
bados; proporciona un proceso para verificar la conformidad, documentar los cam-
bios e informar el estado de cada cambio a lo largo del ciclo de vida del proyecto.
Luego está el sistema de control de versiones (SCV) que permite llevar un registro
e historial de las distintas revisiones, esta herramienta se usa mucho en software,

33
pero también se aplica durante la construcción de cualquier otro producto o servi-
cio, un SCV es un tipo CMS ya que el control de versionado es uno de los muchos
procesos que comprenden la gestión de la configuración.

Cada vez que se solicita un cambio, este debe analizarse en cuanto a su impacto,
ese impacto puede ser de distintos tipos como ser: impacto en la línea base, con-
flicto con otro requisito, impacto en el análisis del negocio, impacto en la gestión de
proyectos, no todos los cambios llevan a los mismos cursos de acción, dependiendo
de las decisiones tomadas por el personal autorizado lo cambio podría: aprobarse,
diferirse, rechazarse o requerir de más información antes de tomar una decisión.

La evaluación de la solución, son actividades del Análisis de Negocios que permi-

ten validar una solución completa o una porción de una solución, que está a punto
de ser implementada o que ya se ha implementado; dicha evaluación mide que tan
bien una solución satisface las necesidad del negocio expresadas por las partes in-
teresadas incluido el valor para el cliente. Para realizar una correcta evaluación se
debe tener una mentalidad especial que permita: evaluar temprano y a menudo,
tratar la evaluación como un complemento del análisis de requisitos y la trazabili-
dad, Evaluar tomando en cuenta el contexto de uso y el valor, confirmar los valores
esperados (soluciones de software).

La evaluación debe ser planificada y para eso se debe determinar qué

es lo que se va a evaluar, se deben considerar metas y objetivos de
negocio SMART, considerar indicadores clave de rendimiento o
KPIs, además de otras métricas adicionales y también criterios de
aceptación de la evaluación. Estas evaluaciones dan lugar a la deci-
sión más importante de una solución que es GO/NO GO es decir la
decisión de lanzar o no la solución o una porción de esta.

Una vez que la solución ha sido puesta en producción o lanzada, se debe

evaluar su rendimiento en el largo plazo y verificar si su promesa de valor se cum-
plió o no; para dicha evaluación se deben determinar las métricas, luego obtener
dichas métricas y medir el rendimiento, hacer un análisis de los resultados, evaluar
las limitaciones tanto de la solución como de la organización y dar una recomenda-
ción para mejorar el rendimiento de la solución.

Dado que todas las soluciones tienen un ciclo de vida finito, es muy importante
definir una estrategia de reemplazo o eliminación de la solución que permita a la
organización prepararse con anticipación, independientemente de la estrategia se-
leccionada, se debe tener cuidado de comunicar adecuadamente a toda la organi-
zación y a las partes interesadas de la solución, incluyendo al usuario final, en caso
de corte de garantía, cambio de funcionalidades, reemplazo u otra situación en la
que se necesite adaptar a una nueva solución.

Durante todas estas gestiones vemos que tanto el analista de negocios como el ge-
rente de proyectos tienen un rol primordial y diferentes responsabilidades que ha-

34
cen que la solución a implementarse no solamente sea la adecuada para responder
a los requisitos del negocio y de las partes interesadas, pero también que aporte el
valor esperado; por eso ambos deben estar en permanente comunicación y traba-
jar de la mano.
 

35
BIBLIOGRAFÍA
ATLASSIAN. (s.f.). https://www.atlassian.
com/es/agile/kanban/boards. Recupe-
rado de: https://www.atlassian.com/es/
agile/kanban/boards

ATLASSIAN. (s.f.). https://www.atlassian.

com/es/agile/project-management.
Recuperado de: https://www.atlassian.
com/es/agile/project-management/
epics-stories-themes

ATRAHUNT. (s.f.). Atrahunt/ Que es KPI.

Recuperado de: https://atrahunt.com/
que-es-kpi/

DIRCOMFIDENCIAL. (s.f.). Diccionario

de Marketing. Recuperado de: https://
dircomfidencial.com/diccionario/

INSTITUTE, PMI-PROJECT MANAGE-

MENT. (2015). Business analysis for
practitioners: a practice guide.

PMCOLLEGE. (s.f.). PMCollege. Obtenido

de https://pmcollege.edu.ni/la-ma-
triz-de-trazabilidad-de-requisitos/

PURCELL, S. (2021) Matriz RACI: qué es,

cómo crearla y ejemplos. Recuperado
de: https://blog.hubspot.es/marketing/
matriz-raci

36
REFERENCIAS
1 Los epics son grandes cantidades de trabajo que se pueden des-
glosar en un número de tareas más pequeñas (llamadas “historias”).
(Atlassian, s.f.)
2 Las historias, también llamadas “historias de usuario”, son breves
requisitos o solicitudes escritas desde el punto de vista del usuario fi-
nal. (Atlassian, s.f.)
3 Un tablero de kanban es una herramienta ágil de gestión de pro-
yectos diseñada para ayudar a visualizar el trabajo, limitar el trabajo en
curso y maximizar la eficiencia (o el flujo) (Atlassian, s.f.).
4 Matriz RACI: La matriz de la asignación de
responsabilidades (RACI por las iniciales de los tipos de
responsabilidad) se utiliza gene-ralmente en la gestión de proyectos
para relacionar actividades con re-cursos (individuos o equipos de
trabajo). De esta manera se logra ase-gurar que cada uno de los
componentes del alcance esté asignado a una persona o a un [equipo].

Imágenes de portada obtenidas de Shutterstock.

37