Diplomatura en Análisis de Negocios

(Business Analysis)

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 2

Módulo 3: Evaluación de la Solución y Lecciones

Aprendidas

Unidad 2: Ejecución de la Evaluación de la Solución

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 3

Presentación de la Unidad:
En esta unidad presentaremos el proceso de ejecución de las pruebas de acuerdo al plan
de evaluación que hemos construido, el cual culmina con la decisión de implementar la
solución en producción.

También analizaremos qué ocurre con la solución una vez implantada en el ambiente
productivo, ya que es necesario continuar evaluando su funcionamiento en el mediano y
largo plazo, para controlar a lo largo del tiempo que satisface los objetivos de negocio
para los cuales fue concebida.

Durante ese período post implementación seguramente se introducirán cambios, ya sea

por mejoras a la solución, o bien porque han cambiado los parámetros o los riesgos del
negocio. Es entonces que recurriremos al proceso de Gestionar los cambios a los
Requerimientos que desarrollamos en la Unidad 4 del Módulo 2.

Y nuevamente continuaremos armando un nuevo plan de evaluación y un nuevo ciclo de

pruebas para instalar la nueva versión de la solución.

Este ciclo de evaluación del funcionamiento en producción de la solución, análisis

continuo del negocio, solicitud y gestión de cambios, nuevo plan de pruebas, ejecución de
las mismas y proceso de implementación de mejoras, se repetirá tantas veces como sea
necesario, hasta el fin de la vida del producto o servicio, o hasta que decida discontinuarlo
por su obsolescencia, su probable reemplazo o por decidir la organización que su vida útil
ha concluido de acuerdo a los objetivos o plazos para los que fue pensado.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 4

Objetivos
Que los participantes

 Puedan definir cómo validar los resultados producidos por la solución de negocio

 Puedan desarrollar criterios para registrar, priorizar y resolver los defectos de acuerdo
a los criterios de aceptación definidos

 Aprendan cómo recomendar planes de acción para la implantación de la solución en

producción y su posterior operación.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 5

Bloques temáticos:

1. Ejecución de Casos y Etapas de testeo

2. Análisis de resultados reales vs esperados - Evaluar criterios de Aceptación

3. Registrar, categorizar y resolver los defectos

4. Recomendar la implantación de la solución

4.1. Facilitar la decisión de ir o no ir a Producción (“Go / No-Go decisión”)

4.2. Obtener la Aprobación (“Signoff”) de la Solución

4.3. Estrategias de implementación

5. Definir los parámetros de medición de performance a mediano y largo plazo

5.1. Analizar los resultados de las mediciones

5.2. Recomendar las mejoras en el desempeño de la solución

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 6

Consignas para el aprendizaje colaborativo

En esta Unidad los participantes se encontrarán con diferentes tipos de actividades que,
en el marco de los fundamentos del MEC*, los referenciarán a tres comunidades de
aprendizaje, que pondremos en funcionamiento en esta instancia de formación, a los
efectos de aprovecharlas pedagógicamente:

 Los foros proactivos asociados a cada una de las unidades.

 La Web 2.0.
 Los contextos de desempeño de los participantes.

Es importante que todos los participantes realicen algunas de las actividades sugeridas y
compartan en los foros los resultados obtenidos.

Además, también se propondrán reflexiones, notas especiales y vinculaciones a

bibliografía y sitios web.

El carácter constructivista y colaborativo del MEC nos exige que todas las actividades
realizadas por los participantes sean compartidas en los foros.

* El MEC es el modelo de E-learning colaborativo.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 7

Tomen nota:
Las actividades son opcionales y pueden realizarse en forma individual, pero siempre es
deseable que se las realice en equipo, con la finalidad de estimular y favorecer el trabajo
colaborativo y el aprendizaje entre pares. Tenga en cuenta que, si bien las actividades
son opcionales, su realización es de vital importancia para el logro de los objetivos de
aprendizaje de esta instancia de formación. Si su tiempo no le permite realizar todas las
actividades, por lo menos realice alguna, es fundamental que lo haga. Si cada uno de los
participantes realiza alguna, el foro, que es una instancia clave en este tipo de cursos,
tendrá una actividad muy enriquecedora.

Asimismo, también tengan en cuenta cuando trabajen en la Web, que en ella hay de todo,
cosas excelentes, muy buenas, buenas, regulares, malas y muy malas. Por eso, es
necesario aplicar filtros críticos para que las investigaciones y búsquedas se encaminen a
la excelencia. Si tienen dudas con alguno de los datos recolectados, no dejen de consultar
al profesor-tutor. También aprovechen en el foro proactivo las opiniones de sus
compañeros de curso y colegas.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 8

1. Ejecución de Casos y Etapas de testeo

Tal como mencionamos en las consideraciones y recomendaciones para la evaluación de

la solución de la Unidad 1 de este Módulo, debemos acompañar el desarrollo del producto
o servicio con las etapas de prueba definidas en el plan, intentando comenzar lo más
temprano posible.

En ciclos de vida predictivos el plan de pruebas se ejecuta en paralelo a la construcción

de la solución, luego de haber definido y aprobado los requerimientos. Es así que se
construyen y ejecutan los casos de prueba que sirvan para validar el diseño y el
funcionamiento esperado de la solución, a medida que las piezas o componentes están
disponibles.

Esta prueba unitaria permite detectar y corregir defectos en forma temprana, evitando
que los mismos se propaguen en el resto de los módulos o piezas de la solución.

Luego de haber verificado el funcionamiento de cada pieza de la solución avanzaremos

con la prueba del sistema, verificando la interacción entre los diferentes componentes, el
correcto almacenamiento de los datos y su manipulación a lo largo del proceso, y la
integridad de todos los resultados producidos o del funcionamiento como un todo.

Una vez estabilizado el sistema en su conjunto deberemos verificar a través de la prueba

integral que se comunica correctamente con el mundo exterior y con los sistemas con los
que debe interactuar dentro de la organización. Y que el producto o servicio no provoca
disrupciones en el ambiente productivo donde se pretende implantar, provocando
resultados inesperados en otros sistemas o componentes. O que no envía informaciones
incorrectas a organismos externos.

En un mundo tan interconectado como el actual la prueba de integración (o integral) es

esencial para homologar el funcionamiento de la solución, ya que cada vez más se
necesita recibir y proveer datos e información de otros sistemas o entidades. Con mayor
frecuencia nuestra solución debe estar integrada en plataformas o ecosistemas que
funcionan en conjunto brindando una cantidad de prestaciones relacionadas a un vasto y
variado conjunto de usuarios. Los sistemas en línea en internet, por ejemplo los de
comercio electrónico son un acabado ejemplo, en donde se integran sistemas de
almacenamiento, stock, logística, distribución, entrega, pago, reclamos y soporte al
cliente.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 9

Ya una vez finalizada esta etapa de integración, nos encontramos en la etapa final donde
deberemos decidir la puesta en producción de la solución. Aquí tendremos la última etapa
de testeo denominada la prueba de aceptación del usuario o cliente (UAT por su sigla
en inglés “User Acceptance Test”). Esta prueba se realiza en un ambiente similar al de
producción (llamado “pre-productivo), es decir con idénticas condiciones de
comportamiento: desempeño, capacidad y velocidad de procesamiento, conectividad,
comunicación, capacidad de almacenamiento de datos, condiciones ambientales, etc.,
para simular situaciones reales escogidas especialmente por el cliente y el equipo de
testeo.

Esas condiciones deben apuntar a que las funciones normales y habituales del producto
puedan ejecutarse satisfactoriamente, en concordancia con los requerimientos, y que
además la solución implantada en producción no provoque alteraciones o disrupciones en
los sistemas o eco sistemas relacionados.

En esta etapa y en este ambiente se suelen realizar pruebas más específicas como las de
volumen o desempeño que describimos en la Unidad 1 de este módulo, ya que es en este
ambiente donde reunimos las condiciones necesarias para evaluar este tipo de aspectos.

A su vez, si el producto que hemos desarrollado reemplaza a uno ya existente en

producción, deberemos realizar las denominadas pruebas de paralelo. Esta etapa
apunta a demostrar que las anteriores prestaciones, que deban mantenerse operativas de
acuerdo a la definición de requerimientos, efectivamente se mantienen con el nuevo
producto y que se producen idénticos resultados tanto de transacciones individuales como
del conjunto de la solución. A su vez se controlan los flujos de datos enviados a las
interfaces externas para comprobar que el nuevo sistema no los ha alterado.

La etapa de paralelo suele realizarse en el ambiente pre-productivo, y se extienden por el

tiempo necesario como para verificar que se ha cumplido un ciclo de funciones de negocio
completo en forma satisfactoria. Normalmente en el transcurso de varias semanas o de un
mes se debería haber resuelto ese ciclo.

No obstante, a veces esas funciones se ejecutan temporalmente en un período

demasiado extenso como para prolongar tanto tiempo el paralelo (por ejemplos funciones
de periodicidad mensual, trimestral o anual), con lo cual se simulan las pre-condiciones
para que dichas funciones puedan ejecutarse y verificarse.

Cuando se trata de proyectos de software, este tipo de pruebas implica una conversión de
datos desde la antigua solución a la nueva, para que se pueda comenzar el paralelo

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 10

desde situaciones de datos equivalentes, y una etapa de prueba específica, denominada

prueba de conversión o migración.

Esta conversión implica el desarrollo de código fuente específico para transportar los
datos de un sistema a otro, y completar con algún valor por omisión los datos que son
nuevos. Además se debe ejecutar una cantidad casos de pruebas para verificar que los
datos han sido correctamente migrados y completados para que puedan ser utilizados en
la nueva solución.

A veces implica la creación de procesos de carga manual con transacciones específicas

desarrolladas a tal fin, a efectos ingresar en el nuevo sistema los datos que no existían en
el antiguo.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 11

2. Análisis de resultados reales vs esperados – Evaluar

Criterios de Aceptación

En cada una de las etapas de prueba deberemos evaluar los resultados y el

comportamiento de la solución para asegurar que se cumplan los requerimientos definidos
y que se verifiquen los criterios de aceptación.

Es decir que deberemos poner en práctica, o sea ejecutar en forma manual o

automática, los casos de testeo que hemos definido en el plan de evaluación. En dichos
casos se establecía el evento, función o proceso a verificar, las precondiciones para que
se pudiera ejecutar o producir, y los resultado esperados.

Previo a cada etapa de prueba deberemos obtener o construir los datos específicos
de prueba que cumplan con esas pre-condiciones para cada uno de los casos, y con
esos datos describir los resultados exactos que pretendo obtener.

A veces la obtención de estos datos de prueba de repositorios ya existentes, o la creación

desde cero, es una tarea bastante ardua para poder recrear con fidelidad las condiciones
para todos los casos de prueba, por lo cual es muy recomendable tener en cuenta el
esfuerzo que esta actividad demandará en el plan de evaluación.

Es frecuente que se requiera de procesos especiales parcial o totalmente automatizados

para crear estos casos en el ambiente de prueba de que se trate, los cuales deberán
ejecutarse cada vez que se quiera comenzar con la etapa de prueba, a efectos de tener el
ambiente “limpio” de datos alterados o generados por pruebas anteriores que pudieran
distorsionar la prueba que estoy efectuando actualmente.

Por ejemplo, supongamos que tengo un caso de prueba en el que quiero verificar que un
cliente nuevo (pre-condición) no puede efectuar compras en un sistema en línea por
encima de un determinado monto, digamos 10.000 pesos (este es el evento a evaluar), y
que si lo intentara le debe dar un mensaje de aviso explicándole la situación y enviarle un
e-mail recordándole los montos máximos por tipo de producto (estos serían los resultados
esperados).

Para ejecutar este caso tengo que tener creado en el sistema un usuario con sus datos de
registro que no haya efectuado ninguna compra anteriormente, y tener cargados en el
sistema ítems de compra cuyo precio conjunto superen al menos los 10.000 pesos.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 12

Supongamos que he creado 3 ítems por 5.000, 4.000 y 3.000 pesos respectivamente y
luego intento efectuar una compra de los 3 ítems simultáneamente, el sistema debería
emitir un mensaje de error avisándome que me excedido en 2.000 pesos de mi límite de
compra y sugerirme que elimine alguno de los ítems, además de enviar el e-mail a la
casilla de correo que he creado para ese usuario entre los datos de registro, detallando
las condiciones de venta y montos máximos de compra.

Una vez ejecutado el caso de prueba debemos comparar resultados reales vs

resultados esperados. Si no fueran exactamente los esperados, los criterios de
aceptación definidos para ese requerimiento son los que decidirán si la funcionalidad
puede ser válida desde el punto de vista del cliente o requiere ser modificada por el
equipo de desarrollo.

En el ejemplo anterior de la compra que no debe exceder un determinado monto máximo,

podría ocurrir que el criterio de aceptación mínimo para salir a producción con esta
funcionalidad fuera que el sistema impidiera concluir con la transacción de compra y que
emita el mensaje aclaratorio al usuario, pero que el envío del e-mail no fuera una
condición invalidante para aceptar la funcionalidad de compra.

En estos casos en que pueden quedar parte de los requerimientos para ser completados
en una etapa posterior, debe documentarse cuándo se completará y cuál será su fecha
estimada de prueba y puesta en producción.

A veces la ejecución real de los casos de prueba y la comparación de resultados reales

versus esperados, puede llevar al equipo del proyecto a decidir que ciertos requerimientos
en realidad excedían la necesidad de negocio o la usabilidad requerida. Con lo cual
pueden desecharse en este momento o re-priorizarse, o post-ponerse para un análisis
más detallado a futuro.

En el ejemplo que planteamos, podría ocurrir que el e-mail con las condiciones de venta y
los montos máximos por producto fuera algo que se debe enviar cuando el usuario se
registra por primera vez en el sitio, en lugar de enviarlo con cada intento de compra por
encima del tope máximo establecido.

Por otro lado al evaluar cierto tipo de requerimientos, en general los no funcionales, nos
encontramos con rangos de valores en los criterios de aceptación. Es decir se define
un “peor caso” que se corresponde con el valor mínimo aceptado, un “mejor caso”
correspondiente al valor máximo deseado o esperable dadas las características del
producto, y un valor “más probable” que se corresponde con el valor objetivo buscado.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 13

Luego el resultado esperado del caso de prueba podrá variar entre el peor caso y el mejor
caso, con el valor objetivo situado en algún lado entre medio de ambos.

Usar rangos de valores en los criterios de aceptación es reconocer la incertidumbre que

pueden tener ciertas variables de la solución, pero al mismo tiempo definir cuál es el valor
mínimo exigido para la característica que se está evaluando, y cuál es el valor objetivo al
que se debería apuntar con el tiempo (si es que no se obtuviera inicialmente) siempre en
concordancia con el límite de tolerancia y expectativas de los interesados.

Por debajo del peor caso la solución no será aceptada en lo que respecta a ese
requerimiento. Si el valor resultante luego de ejecutar el caso de prueba estuviera por
encima del peor caso, pero aún por debajo del valor objetivo, la solución será aceptada
pero esta situación deberá representar una toma de conciencia para el equipo de
proyecto, y se deberá registrar un compromiso de tiempo y esfuerzo para poder satisfacer
la necesidad de negocio establecida por el caso objetivo.

Este tipo de rangos de valores de aceptación es muy común encontrarlos en los casos de
testeo que miden requerimientos de performance o de volumen.

Continuando con el ejemplo del sitio on line de compras, podría tener un requerimiento de
tiempo de respuesta en la búsqueda de productos en el catálogo que no fuera superior a
5 segundos, considerándose el objetivo 2 segundos y el mejor caso 1 segundo.

Ante requerimientos de este tipo es conveniente definir en el caso de prueba los máximos
de volumen exigidos para un desempeño determinado, y efectuar el caso de prueba en
forma individual, es decir midiendo un solo evento ejecutado en forma aislada, y luego ver
cómo se desempeña la solución con simultaneidad de casos, hasta un tope máximo
requerido.

En el ejemplo que describimos, podría requerirse ese tiempo de respuesta aun cuando
hubiera como máximo 200 usuarios concurrentes, permitiéndose valores superiores en
caso de existir mayor cantidad de usuarios realizando compras en forma simultánea en el
sitio.

En estas situaciones es útil definir en el caso de prueba cuál es el límite máximo de

capacidad de funcionamiento de la solución, es decir su nivel de “stress” máximo, o sea
el punto a partir del cual deja de funcionar sin importar el parámetro de desempeño.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 14

En nuestro ejemplo podríamos requerir al menos 500 usuarios concurrentes aunque el

tiempo de respuesta estuviera excedido aún de los 5 segundos del peor caso, pero sin
que el sitio quedara indisponible.

Además de los criterios de aceptación, para evaluar los resultados reales producidos por
nuestra solución, deberemos considerar las métricas y KPIs que definimos en el plan.

Estos indicadores nos permitirán saber si el producto cumple con las metas y objetivos
organizacionales, más allá de los requerimientos funcionales o no funcionales requeridos.

Así por ejemplo podríamos haber definido para nuestro caso del sitio on line una serie de
métricas, que ahora debemos chequear que se cumplan, o bien que serán evaluadas a lo
largo del tiempo durante la vida útil de la solución.

Entre esas métricas podríamos definir:

 % de disponibilidad (“up time”) del sitio en forma diaria, semanal y mensual,

definiendo a su vez las ventanas no aceptadas de indisponibilidad (horarios pico o
fines de semana)

 Tiempo máximo de solución a un problema crítico que no permite utilizar el sitio

con sus funcionalidades esenciales o que directamente lo tornan indisponible.

 Tiempo medio de resolución de problemas en general y discriminado por tipo de

incidente (métrica de mantenibilidad o soporte)

 Frecuencia de ocurrencia de incidentes en producción (métrica de confiabilidad)

 % de búsquedas en catálogo exitosas sobre el total de búsquedas

 Cantidad de usuarios registrados por periodo de tiempo (mensual, trimestral, anual)

 Monto promedio de compras realizadas (ticket promedio) en un período dado

 Cantidad de pedidos o tickets efectuados por mes

 Monto total de facturación mensual

 % de tiempos de entregas de productos cumplidos de acuerdo a lo pactado

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 15

3. Registrar, categorizar y resolver los defectos

Toda vez que al comparar los resultados o el funcionamiento real de la solución exista
una discrepancia con los resultados esperados, estaremos ante una situación que
deberemos analizar sus causas para determinar si se trata de un defecto a corregir, de
una situación anormal de la prueba, o bien de un cambio a los requerimientos planteados.

Puede ocurrir que efectivamente los resultados no satisfagan los criterios de aceptación,
las métricas o los KPIs definidos, con lo cual deberemos registrar la situación como
defecto.

Pero podría ocurrir que los elementos de medición estuvieran errados, se hubiera
efectuado la medición en forma incorrecta, o que los datos de prueba y sus pre-
condiciones no se ajustaran a lo especificado por el caso de prueba, invalidando en esos
casos los resultados obtenidos, no pudiendo caracterizarse por tanto la discrepancia
como defecto.

También podría darse la situación que los requerimientos no estén definidos por el cliente
con el suficiente nivel de detalle como para producir los resultados esperados o que las
condiciones del mercado hayan cambiado respecto del momento en que se definieron los
requerimientos produciendo con los datos actuales situaciones inesperadas.

Por ejemplo si estamos probando un nuevo sistema de denuncias de un compañía de

seguros, uno de cuyos objetivos sea que los reclamos sean resueltos en un 80 % en
forma automática, y nos encontramos luego de la prueba con que el nivel de
automatización es del 50%, podría ocurrir que:

 No se definieron las suficientes reglas de negocio que contemplen todos los tipos
de situaciones para producir tal nivel de automatización de resolución

 O que los casos de reclamos actuales tengan una complejidad mayor a la

esperada en el momento de definir la solución, que ocasione que muchos de ellos
se deriven a una resolución manual

Una vez que el equipo de pruebas detecta la causa de la discrepancia, si estamos ante un
defecto, deberemos ejecutar el proceso definido en el plan de evaluación o el que posea
la organización para lograr la efectiva resolución de los mismos.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 16

Ese proceso es ejecutado por el equipo de seguimiento de las pruebas y supervisado por
el comité de pruebas si lo hubiera y por el analista de negocios y el gerente de proyecto.
En ocasiones de proyectos muy grandes se define un centro de comando y control de las
pruebas con varios roles permanentes operando en algún lugar específico.

Este proceso de gestión y resolución de defectos podría incluir entre otros los siguientes
pasos:

1. Captura y registro: Se debe tomar de la fuente que ejecutó la prueba una cantidad
de datos que permitan evaluar y categorizar el defecto, y al equipo de desarrollo
tener los elementos para entenderlo y resolverlo. Esos datos se vuelcan a un
registro de defectos que puede instrumentase en una planilla o en algunos de los
muchos sistemas disponibles para el registro y seguimiento de problemas. En
cualquier caso debería ser una herramienta compartida por todo el equipo y los
usuarios de fácil actualización y que permita la elaboración de algunos reportes
para el seguimiento. Entre los datos que se registran podemos mencionar:
a. la descripción del defecto
b. el caso de prueba utilizado
c. las condiciones y datos de prueba
d. los resultados esperado y los obtenidos
e. capturas de pantallas o de reportes que ayuden a la clarificación del
problema
f. severidad (ver punto 2)
g. prioridad (ver punto 2)
h. tiempo requerido de resolución
i. solución alternativa o “workaround” (ver punto 4)

2. Categorización: En base a la información del defecto se debe colocar una

severidad y una prioridad de resolución. La severidad está relacionada con la
gravedad que tiene el defecto respecto de las funciones que inhabilita de la
solución. Podrían establecerse una escala de valores desde crítico para denotar
una inoperatividad completa del producto hasta leve para marcar aspectos
menores como formatos o estilos o sintaxis por ejemplo, y tener entre ambos dos o
tres valores intermedios (alta, media y normal). La prioridad está asociada con un
orden de resolución de los defectos. Si bien ambas variables están relacionadas,

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 17

es decir a mayor severidad, mayor prioridad de resolución debería tener el defecto,

muchas veces defectos de menor severidad deben resolverse antes para destrabar
fases o etapas de la prueba con lo cual se les asigna una prioridad alta.

A su vez cada defecto tendrá un estado que permitirá efectuar el seguimiento del
defecto desde que fue abierto hasta que logró resolverse, que indicará por ejemplo,
si está abierto (estado inicial), en análisis, en resolución, en prueba de
comprobación de resolución, entregado para el equipo de pruebas, solucionado /
cerrado o re-abierto para volver a analizar y resolver.

3. Asignación de responsable: Una vez categorizado el defecto se asignará a un

responsable de la solución del mismo. Puede ser una persona o un sector, al que
se le informará un tiempo máximo en el cual el defecto debe estar resuelto para no
impactar el plan de pruebas.

4. Análisis y resolución: El responsable asignado deberá evaluar el problema y

determinar el método más efectivo de resolución del mismo apuntando a una
solución definitiva del problema. Si no pudiera cumplir con la meta establecida de
tiempos para resolverlo de la manera óptima, deberá proveer al equipo de pruebas,
toda vez que sea posible, una solución alternativa o “workaround” para poder
continuar con el plan de pruebas.

En ocasiones el responsable podría determinar que no se trata de un defecto en

virtud de los requerimientos definidos y elevar la correspondiente justificación al
comité de pruebas para su evaluación y eventual cierre del mismo.

5. Seguimiento y control: Se debe efectuar un seguimiento de los defectos que están

abiertos (no solucionados), para acelerar la resolución de aquellos que estén
próximos a vencer su plazo máximo. Por otro lado de deben emitir reportes
periódicos con el estado de las pruebas, detallando entre otros datos, cantidad de
defectos abiertos con su nivel de criticidad, cantidad de defectos cerrados, tiempo
estimado para finalizar con la etapa actual de pruebas e impactos en el plan
original. A veces se suele usa semáforos en el reporte para indicar el nivel de
avance. Estos datos nos sirven también para medir la calidad del testeo.

6. Comprobación de resolución: Una vez que el responsable de resolución del defecto

ha solucionado el mismo deberá efectuar una prueba preliminar en su ambiente

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 18

con datos y en condiciones lo más similares posibles a las indicadas en ocasión de

producirse el defecto, para hacer una primera comprobación de la resolución del
mismo.

7. Entrega para nueva prueba: Una vez comprobada la solución del defecto por parte
del responsable, se entrega al equipo de pruebas para ser verificado en el
ambiente y en las condiciones de la prueba real. Si se comprueba que el defecto
ha sido efectivamente solucionado se modifica su estado a” resuelto”. Caso
contrario se re-abre y se vuelve a pasar al responsable para su revisión.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 19

4. Recomendar la implantación de la solución

4.1 Facilitar la decisión de ir o no ir a Producción (“Go / No-Go decisión”)

Una vez que se han cumplido las etapas de prueba definidas en el plan y se han
solucionado los defectos considerados críticos o importantes por el Comité de Pruebas,
los interesados definidos en el Plan de Análisis como los responsables de tomar la
decisión de implementar la solución en producción deben reunirse a tal fin.

Para facilitar esa reunión deberemos presentar los resultados de las pruebas en una
manera ejecutiva, incluyendo los resultados generales de las pruebas y los defectos o
problemas (“issues”) abiertos que aún queden por resolver. En general, como los
resultados de las evaluaciones suelen ser voluminosos, sumarizaremos y resumiremos
los resultados en la forma más concisa y clara posible, ayudándonos de tablas y gráficos.

Dada la importancia de esta reunión es conveniente prepararla con antelación con una
agenda ajustada a tiempo (los ejecutivos que participen por lo general tienen escaso
tiempo), asegurarse la presencia de todos los involucrados en la decisión (o en su defecto
de ejecutivos alternativos que los puedan suplantar con el mismo nivel de decisión
delegada) y de anticiparles el resumen que hemos confeccionado, cerciorándose que lo
han leído y comprendido antes de la reunión, aclarando las dudas que sean necesarias en
forma previa.

Es importante que la decisión se tome en una reunión cara a cara donde los responsables
tengan la oportunidad de dar su opinión basada en los resultados presentados y que
puedan explicar sus razones para sostener la implantación de la solución, la
desaprobación o la recomendación de diferir la puesta en producción.

Los individuos que participaron de la evaluación de los resultados producidos y los que
analizaron los resultados esperados versus los reales deberían participar como soporte a
la reunión, ya que inevitablemente surgirán preguntas y dudas que sólo ellos pueden
contestar. A su vez la persona que conduzca la reunión debe tener experiencia como
facilitador y grandes habilidades de comunicación y negociación.

Debemos considerar que los resultados si bien pueden ser satisfactorios para el comité de
pruebas en forma global, pueden ser analizados desde otras ópticas por los interesados
claves. Por ejemplo alguna regulación nueva del mercado, alguna alteración importante
en la política del país, o algún defecto considerado menor por el comité de pruebas pero

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 20

clave para los intereses de negocio de la organización, podrían ser razones más que
suficientes para que la decisión de la mayoría de los decisores se volcara por demorar la
implementación y recomendar la introducción de cambios específicos en el producto para
atender esos nuevos escenarios.

A veces también es posible que se decida la implantación de la solución pero con la

condición de llevar a cabo un plan estricto de solución de los defectos remanentes más
importantes, en un período de tiempo bastante acotado, a fin de no impactar objetivos de
negocio. Las razones de una decisión de esta naturaleza pueden encontrarse en la
necesidad de salir a mercado con el nuevo producto por razones de competitividad, o en
tener que cumplir con regulaciones mandatorias de organismos de control, entre otros
motivos que pueden hacer inviable el diferimiento de la implementación.

Por último en cualquier escenario de decisión algo que estará siempre presente será la re-
evaluación de los riesgos y parámetros del negocio, para determinar si es viable para la
organización implementar la solución con el nivel de exposición o de incertidumbre que
plantee el estado de la solución y las variables del negocio actuales.

4.2 Obtener la Aprobación (“Signoff”) de la Solución

Luego de tomada la decisión de “ir a Producción” con la solución, deberá obtenerse la

aprobación formal de la solución que sostenga esa decisión. La mayor o menor formalidad
del procedimiento de aprobación dependen del tipo de proyecto, del tipo de producto, del
ciclo de vida elegido para el proyecto, o de restricciones corporativas o regulatorias.

En general las personas signadas como responsables de tomar la decisión de implantar la

solución son las mismas que proveen la aprobación formal, pero podría haber alguna otra
instancia de nivel superior jerárquico que se requiera que provea su aprobación. En todo
caso los niveles de aprobación deberán estar especificados en el plan o provendrán de
las políticas de la organización para implementaciones en producción.

También deberá estar definido el formato y contenidos del documento que formaliza la
aprobación, quién lo debe emitir, cómo debe ser archivado, y que tipo de firmas son
requeridas, si precisa ser firmado en forma física presencial o son admitidas firmas
remotas mediante algún mecanismo de firma electrónica autenticada o enviada la
conformidad por e-mail de la compañía.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 21

Dependiendo el ciclo de vida que se utilice puede haber una sola aprobación formal al
final del proyecto, en ciclos predictivos, o varias aprobaciones más informales al final de
cada incremento, en ciclos iterativos o adaptativos, que además incluyan una aprobación
formal al finalizar con el desarrollo completo de la solución, coincidiendo con su liberación
a producción.

4. 3 Estrategias de implementación

Ya sea que la solución objeto de nuestro proyecto reemplace a otra existente, o bien que
se trate de un producto totalmente nuevo y diferente de cualquier otro, se deberá tener en
cuenta la estrategia de implementación, y/o de eventual discontinuación de la solución
anterior. Esta estrategia deberá considerar los procesos o sistemas tanto automáticos
como manuales existentes, que pudieran ser reemplazados por la nueva solución.

Existen varias estrategias que podríamos resumirlas de las siguientes formas:

 Implementación de una sola vez en forma masiva: también llamada “big bang”,
significa que en un solo momento se implementa la nueva solución y se discontinúa
en forma simultánea la anterior si existiera.

 Implementación segmentada: también llamada por “roll out” significa implementar la

solución en fases, por ejemplo por región geográfica, por sucursal, por tipo de
cliente, por área o departamento, o cualquier otro criterio de segmentación que se
defina. Si estuviéramos en la situación de reemplazo de una solución, esta
estrategia implica la coexistencia de ambas, es decir que durante el tiempo que
dure el roll out algunos usuarios o clientes estarán utilizando la nueva solución
mientras que otros continuarán utilizando la anterior.

 Implementación con paralelo limitado al tiempo (“time boxing”): implica la

coexistencia de la solución actual y la nueva durante algún tiempo hasta que se
discontinúa la actual. Es la que se alinea con la prueba en paralelo que
describimos previamente, y el fin del paralelo se produce una vez que la
organización se siente lo suficientemente confiada de los resultados de la nueva
solución. Durante ese período de coexistencia no sólo existe un esfuerzo y
recursos involucrados considerables por mantener funcionando ambas soluciones,
cada una siguiendo sus propias políticas, procedimientos y formas de trabajo, sino
que debe considerarse el esfuerzo de comparación de resultados entre ambas, y la

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 22

lógica y proceso de comparación ya que los resultados producidos por una solución
pueden tener que combinarse para poder ser comparados contra la otra. Esta
estrategia es utilizada a menudo en proyectos de software que implican
conversiones de bases de datos o cambios de arquitectura.

 Coexistencia permanente de ambas soluciones: esto implica que toda nueva

transacción u operación de negocios utilizará la nueva solución pero que las
antiguas continuarán utilizando la anterior, hasta que no quede ninguna
transacción, operación o registro con vida útil en la antigua solución. Esta
estrategia se aplica cuando es muy costoso o impracticable migrar los datos de una
solución a otra, o cuando por normas regulatorias las operaciones que nacieron
bajo un determinado proceso de negocios deben continuar manteniendo ese
proceso hasta su finalización o expiración.

Generalmente la estrategia de implementación masiva o de “big bang” representa un

riesgo mayor que cualquiera de las otras, pero también es cierto que cuando se adopta es
porque es impracticable hacerlo de otra forma debido a restricciones de la solución o del
negocio, o bien porque el esfuerzo y el riesgo de un paralelo o “roll out” son aún mayores
e intolerables de soportar para la organización.

Por lo general se realiza un análisis de costo-beneficio asociado a cada una de las

estrategias para determinar cuál es la más apropiada. Independientemente de ese
análisis es interesante formularse las siguientes preguntas para ayudar a la toma de
decisión:

 Cuál es el impacto organizacional de tener dos soluciones? Puede que sea muy
laborioso desde el punto de vista operativo pero menos riesgoso desde el punto de
vista del negocio. A veces migrar de una solución a otra puede ser complejo y
existen pocas operaciones en la actual solución, con lo cual conviene que
convivan, con la premisa de gestionar las nuevas operaciones en la nueva
solución.

 Existen condiciones de marketing o de cara al cliente que requieren que todos los
clientes trabajen con la nueva solución al mismo tiempo? Por ejemplo cambios de
marca o de logo de la empresa.

 La nueva solución involucra software? Como usualmente implican conversiones de

datos, las estrategias de paralelo o segmentación suelen ser mejores opciones.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 23

 Es aceptable que algunos clientes o usuarios estén utilizando la solución vieja

mientras otros utilizan la nueva? Podría ser conveniente ya que debido a
determinadas restricciones existen clientes que no pueden utilizar la nueva
solución. Por ejemplo, en proyectos de software, cuando se cambia la versión del
sistema operativo de una marca de celulares, podría haber aparatos que no
soportaran esa nueva versión y debieran seguir funcionando con la vieja hasta el
fin de la vida útil o el reemplazo en el mercado de ese tipo de equipos.

Más allá de la estrategia de implementación escogida, se debe comunicar la misma de

manera adecuada y anticipada a los usuarios y clientes, de forma tal que sepan de qué
forma adaptarse a la nueva solución y a partir de qué momento deberán utilizarla.

Esta comunicación deberá tener en cuenta entre otros los siguientes factores:

 Desarrollo de los entrenamientos necesarios y entrega de materiales de

capacitación en la nueva solución

 Actualización o creación de las correspondientes procedimientos estándar de

operación e instrucciones de uso

 Compra, licenciamiento e instalación del hardware, equipamiento y software de

terceras partes necesarios para soportar la nueva solución

 Coordinación con otras áreas de la organización para asegurar que la

implementación ocurra en el momento que el negocio pueda aceptar los cambios, y
que no sea disruptiva o entre en conflicto con otros programas, trabajos o
implementaciones de otras soluciones

 Coordinación y aseguramiento que cualquier interrupción de los procesos de

negocio está claramente identificada, entendida, comunicada y sobre todo
aceptada por los clientes o usuarios impactados.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 24

5 Definir los parámetros de medición de performance

a mediano y largo plazo

Una vez que la solución ha sido implementada, debemos medir su desempeño en

Producción a lo largo del tiempo para evaluar si los beneficios que se buscaban con su
implementación se van logrando y de qué forma, y eventualmente realizar los ajustes o
cambios que fueran necesarios para cumplirlos.

Las métricas, los KPIs y los SLAs que definimos en el plan de evaluación cobran mucho
sentido en esta etapa, porque van a ser los parámetros de nuestra medición.

Aquellas organizaciones donde se utilizan las técnicas de la Inteligencia de Negocios

(“Bussiness Intelligence” o “BI”), se puede tomar ventaja de las mismas para analizar, a
partir de la información generada por la solución, los logros efectivamente cumplidos y las
tendencias de cara al futuro.

Las organizaciones modernas de marketing confían en BI y en las métricas obtenidas a

través de “analytics” (que permiten hacer análisis a partir del comportamiento de los
usuarios) para evaluar precisamente si sus campañas producen o no el comportamiento
deseado en sus clientes a lo largo del tiempo.

Las métricas, los KPIs y los SLAs deben ser recolectadas periódica y regularmente
(semanal, mensual, trimestral o anualmente), para poder ir comparando los resultados de
cada período con los anteriores, y poder elaborar curvas acumulativas de
comportamiento.

Es importante notar que la recolección de estas medidas del rendimiento de la solución

puede ser mucho más costosa cuando la organización no tiene la capacidad para
capturarlas de los sistemas productivos mediante algún tipo de herramientas, o cuando
los datos para la medición no se encuentran registrados como parte del modelo de datos
de la solución.

5.1 Analizar los resultados de las mediciones

A través del análisis de las mediciones a lo largo del tiempo es posible identificar:

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 25

 Cuáles métricas permanecen estables

 Cuáles métricas experimentan una tendencia ya sea ascendente o descendente
 Cuáles métricas presentan anomalías en los valores medidos

Una vez que el comportamiento de la métrica es conocido se puede investigar y realizar

un análisis de las causas del mismo para identificar el / los problemas que están
afectando en forma adversa el desempeño de la solución.

Analicemos el siguiente ejemplo: una compañía de seguros quiere automatizar el proceso

de resolución de sus reclamos de incidentes para reducir el tiempo promedio de atención
y mejorar la productividad de sus agentes. Entonces se definen 2 métricas a ser
evaluadas a lo largo del tiempo:

- Promedio de tiempo de atención mensual

- Cantidad de reclamos atendidos por agente por día
Ambas métricas están relacionadas: se espera reducir el tiempo promedio de atención
producto de la automatización, y al mismo tiempo que poder procesar mayor cantidad de
incidentes. Sin embargo si la productividad decreciera o se mantuviera estable a lo largo
de varios períodos consecutivos, se deberán analizar las causas que pueden deberse a:

- Hay una mayor complejidad en los incidentes actuales debido a una inundación en
la región
- La solución no provee el suficiente soporte o la suficiente cantidad de datos para
ayudar a los agentes
- La solución provee el soporte suficiente pero es muy incómoda para usar (poco
“user friendly” una característica de calidad muy buscada)
- Confirmar los daños del incidente toma mucho tiempo a los agentes
- Hay otros trabajos que surgieron que están ocupando progresivamente más
cantidad del tiempo diario de los agentes

Una vez analizadas las métricas y las causas raíces de la desviación del comportamiento
deseado de la solución, se pueden utilizar las mismas técnicas usadas para entender el

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 26

problema (cuando evaluamos las necesidades y relevamos los requerimientos) para

evaluar las limitaciones de la solución y de la organización.

En el ejemplo de la compañía de seguro podríamos desarrollar las siguientes actividades:

- Desarrollar un análisis de costo / beneficio para determinar si vale la pena agregar

más agentes para incrementar la productividad durante los períodos de pico de
incidentes.
- Investigar cuáles son los tipos de incidentes que insumen la mayor cantidad de
tiempo para ser procesados y examinar qué nivel de soporte la solución provee
para soportar ese tipo de reclamos.
- Realizar una serie de entrevistas a los agentes y efectuar estudios de usabilidad en
soluciones similares en el mercado para identificar los aspectos salientes que
producen la incomodidad en el uso.
- Revisar el flujo del proceso anotando los tiempos que lleva cada paso para
identificar las oportunidades de mejora.
- Realizar entrevistas o grupos focales para entender el origen, la naturaleza y la
permanencia en el tiempo de los trabajos que se han agregado a los agentes

5.2 Recomendar las mejoras en el desempeño de la solución

Luego de entender las causas de las desviaciones y haber efectuado las investigaciones
necesarias para entender los problemas, usaremos las técnicas empleadas en el análisis
para recomendar las mejoras a implementar. El trabajo resultante debe ser aprobado y
priorizado dentro del marco del proceso de Control de Cambios y del resto de las
actividades de mejora que la organización está llevando a cabo.

Continuando con nuestro ejemplo, podríamos proponer las siguientes recomendaciones

basadas en cada una de las actividades de investigación, relevamiento y análisis
efectuadas:

- Agregar más agentes en períodos pico u ofrecerles un entrenamiento especial para

manejar situaciones de mayor complejidad

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
 p. 27

- Proveer entrenamiento adicional o agregar más datos o reglas de negocio a la

solución para soportar los incidentes
- Rediseñar los aspectos de la solución que inciden en los problemas de usabilidad
- Rediseñar el flujo de proceso de atención de reclamos para acortar los tiempos de
cada paso y eliminar los cuellos de botella
- Re-priorizar el nuevo trabajo adicional o agregar más recursos para atender esa
demanda en los momento pico

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning