Plan de Calidad TI

EMPRESA DE SERVICIOS CLOUD DTD GAMMA
Plan de gestión de calidad TI
Versión 2.0
26/06/2021
PLAN DE GESTIÓN DE CALIDAD TI
CONTROL DEL DOCUMENTO
INFORMACIÓN
Información
Id del documento Plan de Calidad TI-v0.2
Propietario del documento Ing. Juan Perez
Fecha de publicación 26 de junio de 2021
Último almacenamiento 26 de junio de 2021
Nombre del archivo Plan_Calidad_TI_Gamma.pdf
HISTORIA DEL DOCUMENTO
Versión Fecha Cambios
1.0 19/06/2021 Se elabora la primera versión del documento
Se elabora una segunda versión con modificaciones en:
La estructura del documento, colocamos el apartado de análisis luego de Alcance

Objetivo y Restricciones.
Se completan el resto de los apartados.
Se modifica el documento s/ comentarios de la Tutora:

2.0 26/06/2021
Objetivos:
 definir políticas
 definir metodologías de trabajo o implementación de marcos de
trabajo.
APROBACIONES DEL DOCUMENTO
Rol Nombre Firma Fecha
Grupo de revisión de proyecto Ing. Juan Gonzalez 26/06/2021
Líder del Proyecto Ing. Juan Rodriguez 26/06/2021
Líder de Calidad Ing. Juan Fernandez 26/06/2021
CONTENIDO
CONTROL DEL DOCUMENTO................................................................................................................................. 1

INFORMACIÓN.................................................................................................................................................................... 1
HISTORIA DEL DOCUMENTO................................................................................................................................................1
APROBACIONES DEL DOCUMENTO.....................................................................................................................................1
INTRODUCCIÓN................................................................................................................................................. 4
ALCANCE......................................................................................................................................................... 4
OBJETIVOS....................................................................................................................................................... 4
EXCLUSIONES, SUPUESTOS Y RESTRICCIONES.................................................................................................... 5

EXCLUSIONES.......................................................................................................................................................................... 5
SUPUESTOS............................................................................................................................................................................. 5
RESTRICCIONES........................................................................................................................................................................ 5
ANÁLISIS DE DTD GAMMA................................................................................................................................... 6

1. SAAS................................................................................................................................................................................ 7
2. PAAS................................................................................................................................................................................ 7
3. IAAS................................................................................................................................................................................. 8
DEVOPS............................................................................................................................................................................... 8
ESTRATEGIAS Y POLÍTICAS.................................................................................................................................... 9
PRÁCTICAS............................................................................................................................................................................ 11
IMPLEMENTACIÓN...................................................................................................................................... 14
ANALISIS DE RIESGOS..................................................................................................................................... 15
SOFTWARE COMO SERVICIO......................................................................................................................................................16
PLATAFORMA COMO SERVICIO..................................................................................................................................................17
INFRAESTRUCTURA COMO SERVICIO...........................................................................................................................................17
PERSONAS............................................................................................................................................................................ 21
PROCESOS............................................................................................................................................................................ 22
INFRAESTRUCTURA................................................................................................................................................................. 23
IMPLEMENTACIÓN..................................................................................................................................................................24
RESPONSABILIDADES........................................................................................................................................ 25
PLAN DE COMUNICACIÓN................................................................................................................................... 26
¿A QUIÉN QUEREMOS LLEGAR? ¿QUÉ QUEREMOS DECIR? ¿CÓMO VAMOS A DECIRLO? ¿CÓMO EVALUAMOS?........................................27
MADUREZ DE LA EMPRESA................................................................................................................................. 28
INDICADORES Y PRESENTACIÓN DE INFORMES......................................................................................................... 30

TÉCNICA............................................................................................................................................................................... 30
FRECUENCIA DE LAS REVISIONES ................................................................................................................................................31
LÍNEA BASE, OBJETIVO Y PUNTO DE REFERENCIA ...........................................................................................................................31
FUENTE DE DATOS Y FRECUENCIA DE RECOLECCIÓN ..................................................................................................................31
ACCIONES PARA TOMAR...................................................................................................................................................31
RESPONSABILIDADES...............................................................................................................................................................32
PRESENTACIÓN DE LA INFORMACIÓN..........................................................................................................................................33
INDICADORES EN TECNOLOGÍA.........................................................................................................................................34
INDICADORES EN PERSONAS.............................................................................................................................................37
INDICADORES EN PROCEDIMIENTO...................................................................................................................................41
INDICADORES DE INFRAESTRUCTURA...............................................................................................................................45
HERRAMIENTAS.............................................................................................................................................. 49
DE MEJORA CONTINUA.....................................................................................................................................................49
DE SOFTWARE LICENCIADO...............................................................................................................................................49
AUDITORIAS................................................................................................................................................... 49
AUDITORÍAS INTERNAS O DE PRIMERA PARTE..................................................................................................................50
AUDITORÍAS EXTERNAS.....................................................................................................................................................50
CONCLUSIONES............................................................................................................................................... 51
REFERENCIAS.................................................................................................................................................. 52
INTRODUCCIÓN
A modo de presentar nuestro trabajo, describiremos los diferentes capítulos que contendrá nuestro Plan de
Calidad para la empresa DTD GAMMA. Comenzaremos realizando una descripción y análisis breve de la
situación actual de la empresa identificando el ambiente del proyecto y sus características, luego arribamos a
un diagnóstico primario del contexto en el cual se encuentra DTD GAMMA. Seguidamente describimos el
proceso de definición de la forma de trabajo en el proyecto a través de la planificación de la calidad de TI,
presentando las actividades y recursos seleccionados y requeridos para que la empresa pueda brindar el
servicio, plasmándolo en este Plan de Calidad a través de un diagrama de Gantt. Luego documentaremos el
Plan de Calidad y sugeriremos la forma de subsistencia o mantenimiento de éste.
ALCANCE
El alcance de este proyecto va a consistir en la realización de un plan de calidad de TI que contenga aspectos
relacionados al análisis de la problemática, el brindar soluciones y/o propuestas de mejoras brindadas para la
adopción e introducción de mejoras en sus procesos, tanto de servicios de TI como de las herramientas
generales los cuales beneficiarán tanto a la compañía como a sus usuarios.
Esta problemática abarca los procesos, tareas, actividades, responsabilidades de TI, específicamente los cuatro
servicios que brinda la empresa: IAAS, PAAS, SAAS y en un futuro DEVOPS.
La documentación del modelo de gestión deberá ser mantenida y comunicada de manera eficiente dentro de
las diferentes áreas, se deberán de planificar adecuadamente y recaerá también el control de los procesos
implementados por parte de los diferentes actores dentro de la organización.
OBJETIVOS
Hay que asegurar que la calidad de TI esté planificada, hay que definir cómo se gestionará, afirmar el
aseguramiento de la calidad y definir estándares de calidad aceptables.
Para ellos se listan los puntos claves que se cubrirán en este documento:
 Identificar un modelo de ciclo de vida adecuado para el problema a resolver.

 Identificar los procesos necesarios para el proyecto. Esto podría incluir prácticas, responsabilidades,
productos y precedencias entre las actividades.
 Identificar necesidades de capacitación del equipo de proyecto.
 Identificar riesgos.
 Definir criterios de aceptación para los diferentes componentes del producto de software y servicios a
entregar.
 Definir las actividades de revisión, verificación y validación con el objetivo de asegurar la calidad del
software y/o servicio, así como también los mecanismos a utilizar para dar resolución a los problemas
que surjan a lo largo del proyecto.
 Identificar estándares, convenciones, especificaciones de pruebas, uso de herramientas para el
soporte del proceso de software y/o servicio.
 Definir cómo medir la satisfacción dla empresa/usuario, del proceso de software, del producto de
software y/o servicio.
 Definir el proceso de gestión de la configuración del software.
EXCLUSIONES, SUPUESTOS Y RESTRICCIONES

EXCLUSIONES
El asesoramiento de este equipo de calidad finaliza al lograr el propósito y objetivo de este Plan. Consideramos
que posteriormente la organización podrá trabajar todas las áreas en conjunto ya que la herramienta se verá
fortalecida y los equipos alcanzarán la madurez necesaria para seguir trabajando con cultura de calidad.
SUPUESTOS
El éxito de este proyecto supone:
 La aprobación de la propuesta de trabajo, por parte del CEO de la empresa.

 Disponibilidad de los funcionarios para la realización de las tareas que los involucren.
 Recursos económicos y humanos para la ejecución del proyecto.
 Una comunicación eficiente y universal a la plantilla de funcionarios mediante todos los medios
con los que cuenta la empresa.
 La plantilla de funcionarios conoce el proyecto y su alcance antes del comienzo de ejecución.
RESTRICCIONES
Por fuera del alcance de nuestro asesoramiento, se determinó por parte de la empresa que no tenemos
injerencia en:
 La estrategia de negocio de la empresa

 La estructura organizacional de la empresa
 Cantidad de recursos por áreas.
 Interacciones entre áreas y/o restructuras de las mismas.
 Lo referentes a ventas, facturación, administración, contabilidad, capital humano, o temas legales.
 Interacción con proveedores.
 El cambio de arquitecturas, herramientas, desarrollo y gestión de éstas.
 El detalle de las herramientas o tecnologías utilizadas para implementar y sostener la infraestructura
de los servicios cloud.
ANÁLISIS DE DTD GAMMA
DTD GAMMA es una empresa uruguaya proveedora de servicios de TI en la nube, es joven y con mucho
entusiasmo. Es una Cooperativa pequeña, cuyos socios son profesionales de TI y tienen en mente que los
objetivos de los servicios que brinda la empresa deben tener estándares altos de calidad y desean que se mida
todo aquello que sea posible.
Los tipos de servicios que están trabajando son:
1. Software As a Service (SaaS)

2. Platform As a Service (PaaS)
3. Infrastructure As a Service (IaaS)
4. DevOps (en creación)
Nuestro equipo de QA realizó un análisis exhaustivo sobre las características de la empresa, a través de un
mapa conceptual, utilizando insumos que los responsables de la empresa nos brindaron, además de la
información que les solicitamos. Dicho mapa se utilizó como herramienta interna de la empresa, para poder
realizar el análisis y el diagnóstico actual de la situación de DTD GAMMA.
Analizamos los siguientes factores a nivel general de los procesos de TI la empresa, y encontramos:
No se tienen datos del ciclo de vida del proyecto, pero dado que es una empresa joven o nueva en el mercado,
podemos inferir que se encuentra en una etapa temprana en su desarrollo de gestión empresarial.
DTD Gamma no ha definido políticas de calidad, tampoco ha definido su estrategia de negocio, ni

documentado sus procedimientos. En definitiva, no cuenta con un modelo de gestión de calidad
implementado. Utilizan el sistema Jira que sirve como herramienta para la administración de tareas, el
seguimiento de errores e incidencias y para la gestión operativa de proyectos, pero no aprovechan todas las
funcionalidades de la herramienta, simplemente la utilizan como repositorio de tarjetas.
Respecto al talento humano, como se mencionó en la introducción de este Plan de Calidad de TI, es una
empresa joven y pequeña, su personal asciende a 58 técnicos que cubren todos los servicios de TI de la
empresa.
En relación con las partes interesadas o involucradas, según la norma ISO 9000:2015 las definen como:
“Persona u organización que puede afectar, verse afectada o percibirse como afectada por las decisiones o
actividades que realiza nuestra organización”. Para este análisis consideramos como actores principales que
influirían en el sistema de gestión a implementar, al personal de TI la empresa y a los clientes; si bien existen
otros actores como el resto del personal de la organización, proveedores externos, sindicatos, gobiernos, etc.,
los mismos no serán considerados.
Sobre la forma de comunicación dentro del equipo, la empresa no aporta información relevante sobre posibles
dificultades de comunicación entre el personal. Podemos inferir por los datos entregados que no cuentan con
ningún sistema de comunicación laboral.
La comunicación con la empresa/usuario se realiza vía telefónica directa con cada área de servicio, detectamos
que la organización no tiene implementada una mesa de ayuda o de soporte, o algún sistema que centralice
las solicitudes o reclamos de sus clientes, tampoco tiene un sistema de monitoreo ni de acciones correctivas de
los servicios.
Cabe destacar también, que la empresa actualmente no gestiona los riesgos del negocio ni los de TI por lo cual
en este aspecto deja abierto el campo a propuestas que se adecuen a su caso particular.
A continuación, detallaremos los puntos débiles o críticos de cada área/servicio de la empresa.
1. SAAS
Acerca de este servicio, es el más utilizado/demandado por los clientes, por lo tanto, es el que tiene mayor
exigencia. Consideramos que se deben tener en cuenta los siguientes aspectos:
 Soporte de la infraestructura y de la empresa.

 Seguridad de los datos de los clientes.
 Disponibilidad. Se requiere una conexión a Internet en todo momento.
 Integración con otros servicios/sistemas limitada.
 Escalabilidad.
 Velocidad de procesamiento.
 No se implementan metodologías de calidad para mejorar el servicio.
 Costos operativos relacionados con la insuficiente eficiencia de la gestión.
La empresa encontró dificultades para adelantarse a las necesidades de la empresa, actualmente estiman que
se reciben 5 llamadas al soporte por cliente por semana y detectaron deficiencias en el monitoreo respecto a
la eficiencia y representatividad.
Respecto al talento humano se sabe que: el área está compuesta por un Ingeniero Jefe de SAAS, 10 Analistas y
20 Técnicos.
Hay un equipo asignado a mantenimiento, otro a soporte y otro para instalaciones nuevas. Después de
finalizar una instalación se cambia al modo mantenimiento y soporte.
2. PAAS
En relación con este servicio, la empresa nos manifiesta que no se tiene conocimiento sobre el cumplimiento
de los acuerdos de nivel de servicios o SLA por su sigla en inglés. SLA es un acuerdo escrito entre un proveedor
de servicio y su cliente con el objetivo de fijar el nivel acordado para la calidad del servicio.
Sobre el servicio propiamente dicho, consideramos que se deben tener en cuenta los siguientes aspectos:
 Conocimiento extremo de todas las herramientas que se ofrecen.

 Mediciones de cada herramienta.
 ¿Se está cumpliendo con el SLA?
Este servicio PAAS se estructura como un proyecto, se ejecuta y al finalizar se cambia a modalidad de soporte.
Para todo el servicio existen SLAs que se deben definir.
Respecto al talento humano, cuentan con dos Ingenieros Jefes de PAAS, 5 Analistas, 5 Técnicos y 4
Arquitectos.
3. IAAS
Es el área más nueva, por lo tanto, aún no cuenta con la estabilidad que le otorga la madurez y experiencia que
se logran con el transcurso de los años de trabajo.
El esquema operativo es diferente que el resto de las áreas: existe un área interna que se dedica al desarrollo
de las APIs, además de los servicios propios del IAAS.
Referente al talento humano, esta área cuenta con un Ingeniero Jefe de IAAS, 2 Analistas, 3 Técnicos. Y el área
de desarrollo con 1 Analista funcional, 2 Programadores y 1 Tester.
Es intención de todo el equipo lograr medir todo aquello que agregue valor debido a que no tienen
implementado un sistema de monitoreo.
Sobre este servicio podemos decir que no tiene implementado ningún modelo de gestión de la calidad, ni
tampoco un sistema de monitoreo de las actividades y resultados que se obtienen en la operativa diaria.
DEVOPS
Esta área no se encuentra desarrollada, la empresa detectó que se necesita una línea base para comenzar a
implementarla, existen temas culturales y de metodología que aún no se han definido.
Tienen pensado contratar a un arquitecto al inicio del proyecto.
Sobre este servicio, no tenemos otros insumos para analizar, debido a que es un área que se deberá
desarrollar.
ESTRATEGIAS Y POLÍTICAS
Se deberá contemplar en la estrategia la necesidad de la empresa de equilibrar la estabilidad y previsibilidad

con la agilidad y la mayor velocidad de respuesta operativa.
Para la organización de sus procesos internos nos vamos a basar en la toma de acciones, criterios y
procedimientos para la aplicación y el funcionamiento de la empresa. Estas decisiones deberán de ser tomadas
por los referentes de gestión de la calidad y con el apoyo de los jefes, quienes deberán de elaborar estas
políticas e informar a las áreas involucradas en su implementación y cumplimiento de su utilización. Una
evolución en la forma en que trabaja la organización, para que pueda progresar frente a un cambio
significativo y continuo.
La información y la tecnología se están integrando cada vez más a fondo con otras capacidades de la
organización, los equipos multifuncionales se están utilizando más ampliamente. La gestión de servicios está
cambiando para abordar y apoyar este cambio organizacional y garantizar que se maximicen las oportunidades
de las nuevas tecnologías y formas de trabajar.
Como normas específicas, nos vamos a basar en aquellas que tienen como finalidad el proceso de desarrollo
de software basado en la norma de calidad de la ISO/IEC 25010, el resto de la familia 25000 y la familia ISO/IEC
27000 (seguridad de la información) que se ajustan a este tipo de servicios brindados a través de cloud,
además de tomar el marco de referencia de calidad de servicios que nos provee el modelo ITIL ® 4.
¿Por qué ITIL 4?
Se opta por recomendar un marco metodológico ágil como ITIL ® 4, considerando las características de la
empresa: estructura adhocrática, pequeña, matricial, sumamente técnica y especializada.
ITIL Introduce un enfoque holístico para la gestión de servicios y se centra en la "gestión de servicios de
extremo a extremo desde la demanda hasta el valor".
La nueva edición de ITIL 4 es sin duda una respuesta a la aparición de nuevos marcos de gestión de servicios
como VeriSM™, SIAM® y FitSM. Amplía la versión anterior de ITIL V3 y proporciona una base flexible para
ayudar a las organizaciones en su viaje hacia el nuevo mundo de la transformación digital.
ITIL 4 describe un modelo operativo para la entrega de productos y servicios tecnológicos y también refleja las
tendencias recientes en el desarrollo de software y las operaciones de TI, e incluye consejos sobre cómo
aplicar filosofías como Agile, DevOps y Lean en el dominio de la gestión de servicios.
Por último, pero no menos importante, destaca por ser "un marco para la gestión de servicios" (en oposición a
la "gestión de servicios de TI"), lo que refleja la tendencia creciente de aplicar las mejores prácticas de gestión
de servicios en el ámbito de los servicios empresariales.
La estructura y los beneficios del marco ITIL ® 4
Los componentes claves del marco son:
 El modelo de cuatro dimensiones.

 El sistema de valores de servicio (SVS).
El Sistema de Valor del Servicio, representa cómo los diversos componentes y actividades de la organización
trabajan juntos para facilitar la creación de valor a través de los ITeS (Information Technology Enable Services).
Estos se pueden combinar de una manera flexible, lo que requiere integración y coordinación para mantener la
coherencia de la organización. El SVS de ITIL facilita esta integración y coordinación y proporciona una
dirección sólida, unificada y centrada en el valor para la empresa.
Las 4 dimensiones de la gestión de servicios según ITIL ® 4
Para garantizar un enfoque holístico de la gestión de servicios, describe cuatro dimensiones, a partir de las
cuales se debe considerar cada componente del SVS. Las cuatro dimensiones son:
 organización y personas
 información y tecnología
 socios y proveedores
 flujo de valor y procesos.
Al dar a cada una de las cuatro dimensiones una cantidad apropiada de enfoque, una organización se asegura
de que su SVS siga siendo equilibrado y efectivo. Estas dimensiones son aplicables al sistema de valor del
servicio en general y a servicios específicos.
Los componentes principales del SVS son:
1. la cadena de valor del servicio ITIL

2. las prácticas de ITIL
3. los principios rectores/guías principales del ITIL
4. la gobernanza
5. la mejora continua.
Ilustración 1 Sistema de Valor del Servicio ITIL4
La cadena de valor de servicios ITIL proporciona un modelo operativo para la creación, entrega y mejora
continua. Es un modelo flexible que define seis actividades clave que se pueden combinar de muchas maneras,
formando múltiples flujos de valor. La cadena de valor del servicio es lo suficientemente flexible como para
adaptarse a múltiples enfoques, incluidos DevOps y TI centralizada, para abordar la necesidad de una gestión
de servicios multimodal. La adaptabilidad de la cadena de valor permite a las organizaciones reaccionar a las
demandas cambiantes de sus grupos de interés de la manera más efectiva y eficiente. Cada práctica de ITIL
apoya múltiples actividades de la cadena de valor de servicios, proporcionando un conjunto de herramientas
completo y versátil para los profesionales de ITSM (IT service management).
PRÁCTICAS
ITIL ® 4 incluye 34 prácticas de gestión como "conjuntos de recursos organizativos diseñados para realizar un
trabajo o lograr un objetivo". Para cada práctica, proporciona varios tipos de orientación, como términos y
conceptos clave, factores de éxito, actividades clave, objetos de información, etc.
Las prácticas se agrupan en tres categorías:
 Prácticas generales de gestión

 Prácticas de gestión de servicios
 Prácticas de gestión técnica
Prácticas generales de gestión
 Gestión de estrategia
 Gestión de la cartera
 Gestión de arquitectura
 Gestión financiera de servicios
 Gestión de personal y talento
 Mejora continua
 Medición e informes
 Gestión de riesgos
 Gestión de la seguridad de la información
 Conocimiento administrativo
 Gestión del cambio organizacional
 Gestión de proyectos
 Gestión de relaciones
 Administración de suministros
Prácticas de gestión de servicios
 Análisis comercial
 Gestión del catálogo de servicios
 Diseño de servicio
 Gestión de nivel de servicio
 Administración de disponibilidad
 Administración de capacidad y rendimiento
 Gestión de la continuidad del servicio
 Seguimiento y gestión de eventos
 Servicio de mesa
 Administración de incidentes
 Gestión de solicitudes de servicio
 Manejo de problemas
 Gestión de la liberación
 Cambiar habilitación
 Validación y prueba de servicios
 Gestión de la configuración del servicio
 Gestión de activos de TI
Prácticas de gestión técnica
 Gestión de la implementación
 Administración de infraestructura y plataformas
 Desarrollo y gestión de software
Dado que este proyecto es del tipo Servicios Cloud, pero también está construido/constituido por software
creemos que podrían aplicarse ciertas métricas las cuales conforme al Modelo de Calidad de Software
propuesto en la ISO/IEC 25010 son:
Adecuación Funcional: mide atributos relacionados con la capacidad del servicio cloud para proporcionar
funciones que satisfagan las necesidades implícitas y explícitas de los usuarios bajo ciertas condiciones.
Eficiencia de desempeño: mide atributos relacionados con la capacidad del servicio cloud para encontrar las
funciones que satisfagan las necesidades de los clientes.
Seguridad: mide atributos relacionados con la capacidad de protección de la información y los datos de
manera que personas o sistemas no autorizados no puedan leerlos o acceder a los mismos, modificarlos,
borrarlos, etc.
Fiabilidad: mide atributos relacionados con la capacidad de un servicio cloud para desempeñar ciertas
funcionalidades específicas o cuando se usa bajo ciertas condiciones de tiempo determinados.
Usabilidad: mide atributos relacionados con la capacidad del servicio cloud para ser entendió, aprendido,
usado e intentar demostrar si el usuario se encuentra atraído a su uso.
Compatibilidad: mide los atributos relacionados con la capacidad de los servicios cloud para intercambiar
información o llevar a cabo funciones que hagan uso del mismo entorno de hardware o software.
Mantenibilidad: mide atributos relacionados con la capacidad del servicio cloud para ser modificados efectiva
y eficientemente debido a necesidades de evolución, corrección o perfectivas.
Portabilidad: mide atributos relacionados con la capacidad de los servicios cloud de ser transferidos de forma
efectiva y eficiente de un entorno de hardware, software, operacional o escalabilidad de estos.
Creemos que la adopción de metodologías agiles será de gran ayuda para las diferentes áreas de servicios de la
empresa, porque todas están en la línea de la tecnología de software, tanto la gestión como los diferentes
conjuntos de tareas y características propias de las metodologías agiles como el desarrollo evolutivo,
flexibilidad, autonomía, planificación y comunicación serian de complemento en general.
La adopción de una herramienta que ayude a la planificación, en este caso Jira, sería de gran ayuda en el uso
de las diferentes áreas, ya que mostrará información, dará orden, brindara ciclos, actividades y tareas de
acuerdo a los diferentes requisitos, además de ser un medio de comunicación, también ayudara con la
productividad, participación e involucrará a los responsables de cada área, así como también, la utilización y
alimentación con los datos obtenidos para la generación de métricas.
IMPLEMENTACIÓN
A continuación, presentamos un mapa de ruta general sobre la implementación de ITIL considerando las
estrategias del negocio.
El mapa de ruta planteado en la imagen anterior muestra a grandes rasgos los caminos que la empresa debería
recorrer en un plazo ajustable a dos años y medio.
No se conocen antecedentes de la empresa que demuestren que se tenga una planificación estratégica y este
aspecto es importante porque para implementar un marco o modelo de gestión de la calidad en TI, es
necesario alinearlo a los cometidos y objetivos del negocio.
No corresponde al alcance de este trabajo implementar estrategias del negocio, pero si considerarlas.
El detalle de las fases y tareas que se realizarán para implementar la metodología, los presentamos en un
diagrama de Gantt, en el mismo detallamos también los entregables y productos de cada fase.
A continuación, adjuntamos el cronograma de fases y actividades

ANALISIS DE RIESGOS
La Planificación de la Gestión de Riesgos es un aspecto muy importante que tiene como cometido crear planes
para atacar cada riesgo que pueda presentarse, incluyendo todas las partes que quieran controlarse dentro del
plan general del proyecto. Las principales metodologías incluyen listas de verificación de técnicas de resolución
de riesgos, análisis costo-beneficio, y planes de gestión de riesgos estándares.
Los riesgos que afectan a una organización son múltiples, por lo tanto, definimos un alcance de la gestión de
éstos restringida a los activos que impactan en la prestación de los servicios de TI.
Recomendamos a la empresa un relevamiento de activos de TI y su clasificación según la gravedad del impacto

y su probabilidad de ocurrencia, esto como puntapié inicial para comenzar con un análisis, el cual será utilizado
para evaluar los riesgos detectados para la prestación de los servicios cloud.
No hay un único modelo de análisis de riesgos, por lo tanto, tuvimos en cuenta aspectos como: precisión
buscada, recursos disponibles, existencia de información histórica y complejidad de la organización.
A continuación, describiremos las etapas para llevar adelante el análisis de riesgos:
1. Primero definir las responsabilidades sobre la gestión y el monitoreo de los riesgos. O sea, construir un
equipo de trabajo adecuado.
2. La siguiente etapa es la identificación de riesgos dentro del alcance propuesto.
3. La definición sobre cuáles son más importantes.
4. El paso siguiente es la definición de la metodología y controles adecuados para enfrentarlos, en esta etapa
se requieren estimaciones y juicios.
5. Hay que determinar los recursos financieros que la empresa está dispuesta a invertir en controles.
1. La empresa tercerizará el servicio de forma de contratar una consultoría para realizar las tareas de análisis
del riesgo. Considerando que el personal que integra la plantilla es meramente técnico, abocado a las tareas
específicas de infraestructura cloud.
Otorgaremos como herramienta, la metodología de análisis y su forma de implementarla como insumo de este
proyecto, debido a que se nos solicitó por parte de la dirección que se evalué todo aquello que se pueda
medir.
Volvemos a aclarar que el estado actual de la empresa es sin antecedentes, ni información relativa a este
análisis, por lo tanto, se parte desde cero.
2. Para identificar los riesgos primero comenzaremos con un análisis de los servicios. En la siguiente tabla se
visualizan los recursos administrados por la empresa/usuario en color amarillo y aquellos administrados por la
empresa en fondo verde.
Para el análisis de riesgos consideraremos todos los recursos listados:
Servicios que brinda el centro de datos de DTD Gamma

Infraestructura (como Plataforma (como un

En el servidor del usuario servicio) servicio) Software (como un servicio)
Aplicaciones Aplicaciones Aplicaciones Aplicaciones
Datos Datos Datos Datos
Tiempo de ejecución Tiempo de ejecución Tiempo de ejecución Tiempo de ejecución
Middleware Middleware Middleware Middleware
Sistema operativo Sistema operativo Sistema operativo Sistema operativo
Virtualización Virtualización Virtualización Virtualización
Servidores Servidores Servidores Servidores
Almacenaje Almacenaje Almacenaje Almacenaje
Redes Redes Redes Redes
Servicios administrados por el usuario

Servicios administrados por la empresa
La empresa DTD Gamma como proveedor de la nube, se encarga de la función operativa de TI con expertos y
herramientas que posibilitan brindar diferentes tipos de servicios IaaS, PaaS, SaaS y a futuro DevOps.
Todos los beneficios que nos brinda esta tecnología son muy utilizados y contribuyen a mejorar el uso de los
recursos, pero también generan ciertos riesgos que deben ser tomados en cuenta a la hora de iniciar cualquier
implementación. El cumplimiento de seguir los lineamientos para mantener la seguridad en ambientes cloud,
será responsabilidad del Equipo de Seguridad de la Nube.
A continuación, detallaremos por servicio, cuáles son los aspectos que deberá considerar la empresa para
realizar el análisis de riesgos de las actividades que implican a la operativa de sus servicios.
SOFTWARE COMO SERVICIO
La empresa como proveedora de servicios en la nube es responsable de casi toda la seguridad, ya que los
usuarios que accederán a los servicios solo pueden acceder y administrar el uso de la aplicación que contraten
y no puede alterar su funcionamiento. Por ejemplo, como proveedora de SaaS, la empresa es responsable de
la seguridad del perímetro, el registro, monitoreo, auditoría y de la aplicación, mientras que el consumidor
solo puede administrar la autorización y los derechos del software que utiliza.
• Protección de datos: Se deben validar las estrategias de protección de datos que ofrece el proveedor de
SaaS, cumpliendo con los requerimientos corporativos de confidencialidad, integridad y disponibilidad al usar
este modelo de SaaS.
• Protección del dispositivo y aplicación de la empresa: se debe evaluar el nivel de impacto ocasionado por
los dispositivos de los clientes que utilizan los servicios de la nube que brinda la empresa y los requisitos
utilizados para controlar la exposición a ataques.
• Cifrado: se debe implementar el uso de cifrado fuerte con algoritmos robustos, esto es importante cuando se
activan las sesiones web en el uso de aplicaciones SaaS, como también en los datos almacenados.
• Borrado seguro de datos: se deben conocer las condiciones mínimas que ofrece la empresa para el correcto
borrado de los datos, de manera confiable, cuando estas acciones son ejecutadas por la empresa.
PLATAFORMA COMO SERVICIO
La empresa como proveedora de servicios en la nube es responsable de la seguridad de la plataforma,

mientras que el consumidor es responsable de todo lo que implementa en la misma.
• Interfaces genéricas: se debe evaluar si las interfaces de la aplicación en el manejo de los archivos, la cola o
la tabla de hash ofrecen portabilidad e interoperabilidad al momento de desarrollar las aplicaciones.
• Idiomas y herramientas estándar: se debe tener en cuenta que la plataforma acepte lenguajes y
herramientas estándares y que tenga incorporadas la aceptación de las últimas versiones de cada una.
• Acceso a datos: se debe validar que el sistema PaaS funcione con protocolos estándar de acceso a datos.
• Protección de datos: se debe validar las estrategias de protección de datos, ubicación de las bases de datos,
las tecnologías de procesamientos de transacciones que se ofrecen, evaluar si cumplirá los requerimientos
corporativos de confidencialidad, integridad y disponibilidad.
• Frameworks: se debe validar la implementación de frameworks actualizados con manejo de herramientas

para mitigar vulnerabilidades de seguridad.
• Prueba de componentes: se debe validar la funcionalidad y eficiencia de las bibliotecas de software incluidas
en la fase de compilación.
• Seguridad: se debe validar que la aplicación PaaS permita ejecutarse de manera segura como en una VLAN o
usando cifrado en las comunicaciones cliente-servidor.
• Borrado seguro de datos: En lo posible establecer con el proveedor de nube o conocer las condiciones
mínimas que ofrece para el correcto borrado de los datos, de manera confiable, cuando lo solicita la
empresa.
INFRAESTRUCTURA COMO SERVICIO
Al igual que PaaS, la empresa es responsable de la seguridad fundamental, mientras que el usuario de la nube
es responsable de todo lo que construye en la infraestructura. A diferencia de PaaS, esto otorga mucha más
responsabilidad al cliente.
• Múltiples clientes: se debe validar que el proveedor de Infraestructura como Servicio (IaaS), cuando ofrece
recursos como máquinas virtuales (VM), tenga establecidos mecanismos de protección contra ataques
ocasionados por otras máquinas virtuales del mismo host, de otros hosts en la misma red o también desde la
red externa.
• Protección de datos. Se debe validar las estrategias de protección de datos y si cumplirá los requerimientos
corporativos de confidencialidad, integridad y disponibilidad al usar el modelo de IaaS.
• Borrado seguro de datos: se debe evaluar las condiciones mínimas que ofrece para el correcto borrado de
los datos, de manera confiable, cuando lo solicita la empresa.
• Acceso administrativo: se debe establecer el mínimo grupo de permisos de acceso administrativo en las
máquinas virtuales a las personas con permisos.
• Migración de máquinas virtuales. Se debe documentar una estrategia para migrar las máquinas virtuales
desde y hacia la nube.
• Mejores prácticas de virtualización: se debe apoyar en las guías disponibles de sistemas convencionales y
redes virtuales en temas de seguridad.
3. De acuerdo con todos los servicios identificados que ofrece la empresa, hemos detectado que las principales
amenazas que podría tener, comenzando desde las más peligrosas hasta las menos relevantes son:
 Violación de datos
 Administración de acceso inadecuada, con credenciales débiles
 APIs inseguras
 Vulnerabilidades en sistema y aplicaciones
 Secuestro de cuentas
 Agentes internos maliciosos
 Amenazas Persistentes Avanzadas
 Pérdida de datos
 Diligencia insuficiente
 Uso indebido de servicios
 Denegación de servicios
 Vulnerabilidad en la tecnología compartida
4. Sugerimos la utilización de la siguiente metodología de análisis:
Primero hay que considerar que la medida del riesgo abarca dos aspectos importantes básicos: la probabilidad
de que se produzca una amenaza, la cual se puede expresar en términos de frecuencia relativa, y el impacto, o
sea la severidad con que se produzca dicha amenaza.
Apuntar a hacer una representación visual o gráfica de los entornos de amenaza; esto en sí será el mapa de
riesgos (en forma de tabla para este caso).
En una columna vertical los responsables de esta tarea deberán indicar la probabilidad de que suceda (poco
posible, posible, muy posible) y una horizontal que mostrará el impacto (bajo, medio, crítico). La persona
encargada de la realización del mapa será quien establezca los niveles que crea convenientes; pueden ser por
ejemplo: improbable, ocasional, moderado, constante; o para el impacto: insignificante, menor, mayor, crítico
o catastrófico.
Esto le va a generar un mapa de calor con colores, y la escala para asignar los colores sería la siguiente.
Verde: si está en los cuadrantes poco posible-impacto bajo, posible-impacto bajo, poco posible-impacto
medio.
Amarillo: si es muy posible-impacto bajo, posible-impacto medio, poco posible-impacto crítico.
Rojo: para posible-impacto crítico, muy posible-impacto medio, muy posible-impacto crítico.
Definimos la siguiente escala para lograr la clasificación:
 Baja probabilidad = Casi nunca sucedería se da valor 1

 Probabilidad media = Podría suceder se da valor 2
 Alta probabilidad = Lo más probable es que suceda se da valor 3
Y para calcular el nivel del riesgo la siguiente formula:
NR = (Probabilidad x Impacto)
Ilustración 2 Tabla de dos dimensiones Probabilidad e Impacto
Controles de los riesgos
Cuando ya se tenga el mapa de riesgos representado: su nivel, dónde se ubican y cuáles serán las acciones, se
deberá seguir con la etapa de implementación de controles.
Por quiénes atenderán lo que indica el mapa, se deberán planificar las acciones concretas y cómo se realizarán.
Se deberá establecer quién realizará el monitoreo y en caso de que ocurra una amenaza, se deberán
establecer también los mecanismos para verificar que el riesgo ya no está o que existe un control.
Toma de decisiones
En general, ante un riesgo hay diferentes formas de actuar o de abordarlo.
Recomendamos las acciones:
Evitar: hay amenazas que sí o sí se tienen que evitar porque sus impactos pueden ser significativos. Entonces
las acciones tienen que orientarse a que ese riesgo no pase.
Asumir: cuando se trata de riesgos de bajo impacto se asume o se acepta; por lo tanto, no se hace nada al
respecto, pero se tiene en consideración y se registra para evitar que escale a un grado de impacto mayor.
Transferir: esta decisión traslada el impacto a un tercero o para que un tercero sea quien gestione la amenaza.
Esto se entiende como un riesgo que otra entidad o persona puede evitar, asumir o minimizar, porque tiene la
experiencia o capacidad para hacerlo.
Minimizar: aquí lo que buscas es mitigar los impactos o bajar de nivel de probabilidad. Las acciones
estratégicas se orientarán para que un rojo o amarillo quede en verde.
Explotar: si se ha identificado un riesgo y en el análisis se ve la opción de convertirlo en una oportunidad, hay

que generar las acciones para que suceda.
Escalar: en caso de que el responsable de hacer el mapa de riesgos no tenga la facultad de tomar una decisión,
deberá escalar de nivel, es decir, puntualizar la amenaza para que un directivo tome la decisión adecuada para
la gestión.
Ejemplo:
Riesgo 1- Violación de datos
Riesgo 2- Personal que no cumple con la política de confidencialidad
Riesgo 3- Bug en el software (esto podría implicar tener que efectuar una actualización del SW)
Recomendamos una implementación gradual comenzando con un área piloto y luego continuar con el resto de
los servicios.
5. No hay limitantes financieras para el desarrollo de las actividades.
Ejemplo de análisis de riesgo aplicado a la empresa
La autora Elaine M. Hall, propuso en su libro “Managing Risk: Methods for Software Systems Development”
que, para realizar una gestión de riesgos exitosa, nos debemos enfocar en cuatro factores críticos de éxito –
Personas, Procesos, Infraestructura e Implementación – denotadas por la fórmula P 2 I 2.
Para este caso tomamos este modelo de Hall para adaptarlo a las necesidades de la empresa DTD Gamma
proveedora de servicios cloud.
PERSONAS
P I Decisione
N Riesgo s Mitigación
Deficiencia en la Promover la participación e involucrar a todos los actores de la
1 2 2 Minimizar
participación empresa.
Generar incentivos que ayuden a mejorar la motivación de los

2 Desmotivación 1 3 Evitar
miembros de la compañía.
Definir perfiles que actúen como líderes en cada área y brindar

3 Falta de liderazgo 1 3 Evitar
las capacitaciones necesarias.
Falta de
Brindar talleres y capacitaciones en habilidades blandas a los
4 habilidades 3 3 Evitar
empleados.
blandas
Incompatibilidades
de formación Brindar capacitaciones e incentivar a la formación continua.
5 respecto a las 3 3 Evitar Facilitar becas para que los empleados puedan adquirir nuevas
tecnologías habilidades.
utilizadas
Falta de personal
Contratar personal inherente a las responsabilidades y puestos
6 para cubrir las 2 3 Escalar
a cubrir.
tareas
Pérdida o fuga de
información
debido al mal uso Implementar API potentes para el control de acceso. Proteger
7 1 3 Minimizar
de las claves de el tránsito de datos mediante el cifrado de los mismos.
cifrado y de
software
Ambiente negativo Análisis de la cultura de la empresa y de ese sector en
8 para relaciones de 1 3 Minimizar particular para realizar talleres de buen relacionamiento
trabajo laboral.
PROCESOS
N Riesgo P I Mitigación
°
1 Pautas de trabajo no 2 3 Escalar Definir un estándar documentado para las tareas y sus
establecidas definiciones las cuales aporten claridad a las mismas.
claramente
2 Desviarse de la 1 3 Minimizar Definir el alcance y los objetivos de manera eficiente para

ejecución de las el cumplimiento de las tareas evitando así el desvió.
tareas definidas Establecer controles y herramientas adecuadas para el
control de las tareas asignadas o definidas.
3 Incumplimientos de 2 3 Asumir Implementar las previsiones necesarias para el

SLAs cumpliendo del pago en caso de demandas. Implementar
las acciones necesarias para no incumplir las SLAs
definidas.
4 Cambios en las 1 3 Escalar Elaboración de contratos laborales donde expliciten las

condiciones laborales pautas necesarias para que el empleado/empresa puedan
cumplir con las condiciones definidas. Pago de primas y/o
compensaciones necesarias.
5 Abuso/mal uso del 2 2 Minimizar Definir políticas y condiciones del servicio que la empresa
cloud computing informe y acepte al momento de la utilización de los
servicios.
6 Interfaces/API poco 2 3 Minimizar Asegurar las interfaces con hardware y/o softwares
seguros adecuados.
Implementar software de monitorización de las terminales.
Considerar un cambio en proveedor de la API.
7 Brechas de seguridad 2 3 Minimizar Actualización y revisión y control de las bases de datos,

debido a que el permisos, etc. a modo de mantener los datos actualizados.
consumidor/cliente
del Especificar en los contratos de servicio con la empresa, que
servicio no informa a este último debe informar a la empresa sobre los cambios
la empresa de las en su plantilla de personal y a su vez las responsabilidades
bajas de su personal. por no cumplimiento.
8 Exploits o malware 2 3 Minimizar Diseñar buenas prácticas para la instalación y

que consiguen configuración. Monitorizar los entornos para detectar
acceder a los cambios no deseados en las configuraciones o la actividad
recursos del equipo o proporcionar autenticación fuerte y control de acceso para
anfitrión de la el acceso de administración o adecuar los acuerdos de nivel
virtualización de servicio para controlar el parcheado y la
corrección de vulnerabilidades.
INFRAESTRUCTURA
N° Riesgo P I Decisiones Mitigación

Incumplimiento de
Implementar un plan que contemple todos los puntos
los requerimientos
1 1 3 Minimizar necesarios que deben de existir para la implementación
mínimos para los
de un centro que brinde servicios cloud.
servicios.
Falta de recursos Replanificar para escalar las condiciones que se

2 necesarios para 1 2 Asumir consideran necesarias y rever las licencias de software
hardware y software. para mantenerlas al día.
Falta de
Definir un plan de crecimiento anual mínimo de un 20%
acompasamiento con
y establecer un seguimiento preventivo adecuado que le
3 el nivel de 1 2 Evitar
permita a la empresa anticiparse ante futuros cambios
crecimiento de la
tanto positivos como negativos.
empresa.
Inclemencias Implementar planes para contingencias climáticas.

4 1 2 Minimizar
naturales Planificar la continuidad en el negocio.
Daños intencionales Políticas claras de seguridad de la información y sus

5 del personal de la 2 3 Minimizar consecuencias en caso de incumplimientos.
empresa Controles sobre el personal de la empresa.
Efectos de la Si bien es un riesgo y se debe planificar los recursos

6 obsolescencia 1 3 Explotar necesarios y de renovación de equipos, termina siendo
programada un beneficio la actualización del hardware.
Contar con hardware en stock para previsiones de fallos

Fallos en cálculos de
o de faltantes.
7 presupuestación del 1 2 Escalar
Solicitar un margen de presupuesto una vez establecidos
HW
los cálculos para afrontar imponderantes.
Obsolescencia del Llevar un registro y seguimiento de las condiciones del
8 cableado 1 3 Evitar cableado estructurado de la empresa. Realizar
estructurado mantenimientos mensuales.
Realizar un análisis y planificación previa para instalar o
Sitio inadecuado para
actualizar un datacenter de la empresa.
9 establecer un 1 3 Evitar
Tercerizar el servicio en los casos que sea meramente
datacenter
necesario.
1 Falta de seguridad Implementar un Sistema de Gestión de Seguridad
1 3
0 activa y pasiva Minimizar de la Información.
IMPLEMENTACIÓN
N
Riesgo P I Mitigación
°
Capacitaciones, talleres de concientización con los líderes
Que la empresa no
de los servicios y con el resto del personal.
1 adopte una cultura 1 3 Evitar
Establecer un sistema de reconocimientos y logros para
de calidad
el personal, por ejemplo, premiar al empleado del mes.
Establecer procedimientos para la contratación de

Inexistencia de
personal.
recursos humanos
Realizar previsiones respecto a la rotación del personal.
2 suficientes para la 1 3 Evitar
Realizar convenios/contratos con terceros que puedan
implementación del
cubrir las actividades si sucede un faltante de personal,
Plan de Calidad de TI
hasta que la empresa logre cubrirlo.
No ajustarse al Dedicar más recursos en las tareas a fin de replanificar el

cronograma de trabajo para alcanzar los objetivos.
3 2 2 Evitar
implementación del Realizar cronogramas ajustados a la realidad de la
Proyecto empresa y de su entorno.
Cambios inesperados Readecuar a los equipos que trabajan en marcos agiles
4 en el alcance del 1 3 Asumirlos para replanificar las tareas y poder cubrir los cambios
proyecto inesperados.
Establecer procedimientos claros para transferir estas

Modificaciones en
situaciones al área que corresponda de la empresa.
regulaciones por
5 1 2 Escalar Establecer mecanismos para realizar informes
cambios
situacionales frecuentes a los jefes de las diferentes
Gubernamentales
áreas.
Afiliaciones a Establecer canales de negociación con gremios y con el

sindicatos y cambios personal de la empresa.
6 en la negociación de 1 2 Mitigar Cumplir con las obligaciones reglamentarias y cargas
los contratos sociales. Ajustarse a los estatutos laborales. Implementar
laborales un sistema de ascensos y compensaciones equitativo
para el personal de la empresa.
RESPONSABILIDADES
En este apartado detallaremos nuestras responsabilidades como equipo de QA y las responsabilidades de los
empleados de la empresa llevarán a cabo la ejecución de las metodologías y actividades planteadas.
Nuestro equipo de QA será responsable de relevar la información necesaria para arribar a un diagnóstico de la
situación actual de la problemática planteada, también será responsable de presentar un informe detallando
los aspectos considerados para el diagnóstico actual de la empresa. Además, será responsable de la
elaboración de un Plan de Calidad donde se presentarán las soluciones propuestas con las metodologías
necesarias para garantizar la calidad de los servicios que involucran a la organización, brindando lineamientos,
pautas, mejoras y procedimientos en la generación de éstos. Mantener la confidencialidad de la información
suministrada y relevada en DTD GAMMA, para ello se ha firmado un acuerdo legal con cláusulas específicas.
Las responsabilidades de los diferentes referentes de la empresa DTD Gamma, en sus diferentes roles en
general abarcan:
 Ejecución práctica de las actividades referentes a la implementación de las metodologías de

calidad propuestas. Las tareas operativas referentes a la gestión del riesgo de los servicios.
 Participar de las fases del proyecto y registrar si se alcanzan las acciones definidas para el
cumplimento de los estándares y sus satisfacciones. Analizar y revisar los indicadores definidos
para el sistema, determinar si se cumple con objetivos estratégicos de calidad planificados.
 Elaborar informes para los líderes del proyecto o negocio y demás referentes de la empresa, para
la toma de decisiones.
 Planificar y participar de las auditorías internas y/o externas que permiten determinar el
cumplimiento de los estándares definidos de los diferentes servicios.
Responsabilidades no exhaustivas por áreas de servicios en la empresa:
 Cada área deberá de mantener designado un jefe líder o referente del servicio.
 Deberá de seguir procedimientos en el desarrollo de software, basados en normas de calidad ISO-
IEC 25000 e ISO-IEC 27000 que corresponden a estándares en el resguardo de la seguridad de la
información como la ciberseguridad, la integridad de la información alojada en la nube, etc.
 Usar las herramientas disponibles, por ejemplo, Jira.
 Implementar un sistema de gestión para la comunicación interna y externa de la empresa con la
finalidad de atender por ejemplo las solicitudes, incidentes, reclamos, tiempos de respuesta, etc.
 Definir y monitorear los acuerdos de nivel de servicio (Service Level Agreement – SLA)
Confidencialidad en el uso y el manejo de la información recabada.
 Los reclamos deberán de ser registrados, clasificados, actualizados, escalados, resueltos y

cerrados, brindándole información a los responsables, por ejemplo, clientes, utilizando la vía de
comunicación definida.
 Gestión de indicadores para medir procesos y resultados
 Mantenimiento de equipamiento
PLAN DE COMUNICACIÓN
La empresa ha manifestado que la comunicación entre sus funcionarios no fluye correctamente, por ejemplo,
no se utiliza una de las herramientas de trabajo y de comunicación llamada Jira, ya que se utiliza sólo como
repositorio de tarjetas. Asumimos que tienen el mismo problema en las distintas áreas que conforman a la
empresa.
La comunicación deberá de ser clave e imprescindible herramienta y de mejora continúa teniendo que
cumplir con algunos lineamientos claves como:
 El trabajo en equipo
 Dar a conocer los procesos y procedimientos.
 Facilitar la integración y participación de acciones definidas por la empresa y la adopción de esta
a nuevos trabajadores, con capacitaciones constantes y evolutivas.
 Comunicar de manera efectiva eventos, formaciones y demás temas relacionados a las áreas
competentes y la temática relacionada a la calidad.
 Promover el cumplimento de las acciones definidas de manera natural y como parte de los
valores y culturas empresariales.
 Se definen como medios de comunicación interna, el correo electrónico y medio de
comunicación integrales como Slack, Jira, entre otros, para la interacción entre los diferentes
miembros del equipo. Para las reuniones virtuales se utilizará Zoom.
Para comenzar a trabajar, se pondrá en conocimiento sobre lo que sucede actualmente a todos los integrantes
de la organización.
Objetivo General: implementar comunicaciones efectivas que fomenten el uso de las herramientas de trabajo
entre los funcionarios y sus diferentes áreas/servicios.
Objetivos Específicos:
 Informar al 100% de los empleados sobre el Plan de Calidad y sus objetivos.

 Lograr que se implementen las mejores prácticas de calidad en el uso de las herramientas de
comunicación de la empresa.
Estrategia: ¿cómo vamos a lograr los objetivos planteados?
Para comenzar a trabajar sobre los objetivos establecidos, lo primero que haremos será informar a los
Ingenieros jefes sobre los mismos. Se realizarán acciones centradas en los funcionarios. En primer lugar, se
determinarán los aspectos sobre los que hay que trabajar para mejorar la comunicación y se llevarán a cabo
acciones que generen interés en el proyecto de Gestión de Calidad de TI.
Se comenzará a trabajar de manera coordinada entre las áreas, buscando así mejorar la comunicación; se
realizarán talleres y focus group, donde se aborde la importancia de la gestión de la calidad de TI, se analizará
la manera actual en la que se desarrolla la operativa de la empresa y el nuevo plan de calidad. Por otra parte,
se hará un relevamiento de expectativas con el nuevo plan de gestión.
Para el cumplimiento de los objetivos, será clave el desarrollo de los jefes, quienes están en un rol de liderar el
proyecto para sus equipos. Lo primero que debemos lograr es que ellos internalicen los procedimientos y
comprendan la importancia que éstos tienen en el cumplimiento de la planificación de la gestión de calidad de
TI. Ofreceremos talleres de habilidades comunicativas, buscando con ellos acompañar el proceso de cambio.
Se formará una red de referentes internos por área con perfiles previamente identificados por la Dirección,
quienes serán líderes informales, y nos ayudarán a transmitir objetivos e información relevante de las nuevas
herramientas, mediante el reconocimiento que tendrán dentro de la organización. Dicha red contará con el
apoyo y respaldo de la Dirección.
¿A QUIÉN QUEREMOS LLEGAR? ¿QUÉ QUEREMOS DECIR? ¿CÓMO VAMOS A DECIRLO? ¿CÓMO
EVALUAMOS?
Objetivo Específico Público Mensaje Acciones/Medios Evaluación
Informar al 100% Todo el El cambio y las Utilización del correo Cantidad de

de los empleados personal. mejoras lo electrónico para enviar correos con
sobre el Plan de haremos en mensajes masivos que funcione confirmación
Calidad y sus conjunto, será le como “memo” del proyecto de lectura.
objetivos. mayor objetivo de “Gestión de la Calidad de TI”.
la empresa. Incluirá banners con
información destacada.
Carteleras con información, Participación

datos y logros importantes del
proyecto.
Talleres de motivación con Participación

equipos definidos previamente.
Entrevistas a funcionarios de Cantidad de

relevamiento de situación. entrevistas
realizadas.
Focus group. Participación
Lograr que se Ingenieros Somos el equipo Capacitación en habilidades Cambios en los

implementen las jefes de que hacemos que comunicacionales. resultados
mejores prácticas las Áreas las cosas pasen. obtenidos.
de calidad en el uso
de las herramientas Nos
Jornadas de escucha y Encuesta de
de comunicación responsabilizamos
motivación con sus equipos. clima anónima
de la empresa. por lo bueno y
por lo malo y
entendemos Reuniones mensuales con jefes Participación
nuestras para planificar estrategias en actividades
fortalezas y
debilidades.
MADUREZ DE LA EMPRESA
La madurez podría ser el grado en que se definen, gestionan, miden y mejoran continuamente los procesos de
un sistema de gestión.
De todos los gurús de la calidad, Philip Crosby es uno de los más presentes, defiende el uso de una
herramienta simple para mostrar dónde se encuentra cualquier organización en el espectro de gestión de la
calidad; él lo llama la Cuadrícula de Madurez de Gestión de Calidad.
El modelo de madurez es de gran ayuda para que la empresa entienda sus procesos y por lo tanto pueda
brindar ayuda con la medición y la mejora de estos.
Además, este modelo de madurez sirve para identificar los niveles de madurez deseables a futuro y de esta
forma orientar a la empresa para alcanzar estos niveles.
A nivel general la evolución de la capacidad de un proceso se asocia con mayor predictibilidad y

mensurabilidad, lo que resulta en una mayor calidad y productividad, donde la mejora de la capacidad da
como resultado un aumento de la madurez de la organización.
En 1979, Crosby presentó la siguiente Cuadrícula de Madurez de Gestión de la Calidad (QMMG), es una matriz
simple de 5x 6 que muestra las diferentes etapas de madurez de la gestión de calidad de la empresa frente a
seis categorías diferentes de gestión de calidad:
Según las categorías de medición comenzando desde la primera hasta la sexta, la empresa se encuentra en
las siguientes etapas:
Comprensión y actitud de la Gerencia: los fundadores de la empresa son proactivos a la hora de pensar en la
necesidad de contratar servicios de consultoría para mejorar las actividades de la empresa y comprenden los
principios absolutos de la gestión de la calidad. Por lo tanto, se ubica en la etapa 4: sabiduría.
Estado de la organización de la calidad: Etapa 1 de incertidumbre.
Manejo de problemas: etapa 2 despertar.
Costo de calidad como % de ventas: Etapa 1 de incertidumbre.
Acciones de mejora de calidad: Etapa 1 de incertidumbre.
Resumen de la postura de calidad de la empresa: Etapa 1 de incertidumbre.

INDICADORES Y PRESENTACIÓN DE INFORMES
El propósito de la práctica de medición y presentación de informes es apoyar a la toma de decisiones y la

mejora continua mediante la disminución de los niveles de incertidumbre. Esto se logra mediante la
recopilación de datos relevantes sobre diversos objetos gestionados y la evaluación de estos datos en un
contexto adecuado. Los objetos administrados para la empresa incluyen, entre otros, los servicios, las prácticas
y las actividades de la cadena de valor, equipos e individuos, proveedores y socios, y la organización en su
conjunto. Muchos de estos objetos administrados están conectados entre sí, así como sus respectivas métricas
e indicadores.
TÉCNICA
Para establecer objetivos claros para la medición y la presentación de informes, es necesario comprender las
metas de la empresa y establecer una relación clara entre las de alto nivel y bajo nivel y los objetivos que se
relacionan con ellas.
Para construir las métricas, primero la empresa identificó y definió conceptos a medir, para ello desarrollamos
4 dimensiones que nos ayudaron a dividir para que sea más fácil de comprender. Por último, construimos las
métricas que integran cada dimensión.
Dimensiones:
 Tecnológica, ya que la empresa funciona sobre Tecnologías de la Información.

 Personas, ya que sus servicios son consumidos por clientes finales.
 Procedimientos, verificar existencia de estos y su implementación o cumplimiento.
 Estructuras de las diferentes áreas que componen a la empresa.
Como lineamiento se adoptó que las métricas cumplieran con el criterio SMART, porque las que no superen el
mencionado criterio, no aportarán información útil, no serán viables o recuperar la información tendrá un
costo excesivo.
Las métricas en sí mismas, como las auditorías, no tienen ningún valor inherente. El valor proviene del
conocimiento adquirido y de cómo las personas tomen las medidas adecuadas.
Las acciones que se tomen respecto a los resultados de las mediciones pueden ser proactivas o reactivas,
dependerá de las métricas si son preventivas o tardías.
FRECUENCIA DE LAS REVISIONES
La decisión sobre la frecuencia que tendrán las notificaciones y la frecuencia del análisis de los datos se decidió
a la hora de decidir qué métrica crear, estas frecuencias varían según el propósito de la métrica, pero como
pauta general, se definió que serán menos frecuentes en los niveles más altos de la organización o cuanto más
alta sea la jerarquía de la métrica.
También hay una variación significativa en las frecuencias, dependiendo del tipo de proceso. En la medida que
la organización implemente sistemas computarizados de gestión de procesos de negocio (BPMSs), muchas de
las revisiones se realizarán con mayor frecuencia y de forma automática, y se generarán alarmas cuando se
justifique la adopción de acciones.
LÍNEA BASE, OBJETIVO Y PUNTO DE REFERENCIA
Para tomar una decisión basada en una métrica, debe haber algo con lo que compararla. Por lo general,
incluye:
Línea base: ¿cómo se comparan los datos de métricas con los niveles anteriores de performance? Para una
nueva métrica, normalmente hay un nivel mínimo de tiempo en el que se recopilarán y notificarán los datos,
pero no se tomará ninguna decisión sobre las tendencias hasta que se haya establecido una línea de base a
partir de los datos.
Objetivo: éste es el nivel deseado para la métrica; puede ser un mínimo, un máximo o un número específico.
Algunos ejemplos son las especificaciones, los límites de control y los objetivos de organización/proceso.
Punto de referencia: mientras que la comparación de la métrica con los objetivos puede mostrar que el
proceso se está desempeñando bien, a menudo es útil compararlos con los puntos de referencia externos que
indican qué tan bien alguien más se desempeña en la misma métrica. El punto de referencia puede ser otros
procesos comparables internos de la empresa, el rendimiento de la competencia o lo que se denominan
resultados de "mejores prácticas" que no son necesariamente específicos de la industria.
FUENTE DE DATOS Y FRECUENCIA DE RECOLECCIÓN
Una vez que se ha especificado el contenido de la métrica, se debe definir el origen de los datos, así como la
frecuencia con la que se recopilarán. Los orígenes por ejemplo pueden ser una base de datos determinada, un
individuo, un informe, etc. Es decir, ¿a dónde buscaríamos esos datos específicos? La frecuencia para recopilar
los datos no es la misma frecuencia con la que se generan, sino la frecuencia con la que la empresa desea
evaluar el rendimiento. Además, para cada métrica o conjunto de métrica se especificará el punto específico
en el tiempo (por ejemplo, qué día de la semana o mes), así como el período de tiempo en el que se recopilará
(por ejemplo, mensual, acumulativo para el año).
ACCIONES PARA TOMAR
Cuando revisemos una métrica, se tomarán alguna de las siguientes decisiones:
• No hacer nada: La métrica está funcionando como se desea y/o se espera.
• Se desea un cambio en el promedio: para cambiar el nivel de rendimiento.
• Se desea un cambio en el proceso: para reducir o aumentar la cantidad de variación.

Crear el cambio deseado requiere identificar y efectuar las métricas o factores de control respectivos, o los
indicadores principales y sus procesos asociados, pero para evaluar la pertinencia del cambio, previamente se
deben de tener algunas consideraciones.
Consideraciones para evaluar cuando se desea realizar cambios SI NO
¿Hay recursos suficientes disponibles para crear el cambio?
¿El esfuerzo de cambio es lo suficientemente importante en relación con otras

posibles asignaciones de esos mismos recursos?
¿Qué podría afectar si el cambio es apropiado o no?
Cuando se realice un cambio, se deberá documentar para permitir la trazabilidad y se deberá comunicar a
aquellos que necesitan actuar sobre él o que pueden ser capaces de detectar cualquier efecto adverso.
Después del cambio, la métrica debe ser monitoreada para ver si se logró el resultado deseado y, de ser así, si
el mismo cambio podría aplicarse en otra parte de la organización (aprovechando el aprendizaje).
RESPONSABILIDADES
El siguiente detalle es especificar con qué frecuencia (y de nuevo qué día, hora del día, etc.) se informarán los
datos y a qué ubicaciones / individuos / grupos. Esto requiere considerar quién debe monitorear y/o actuar
sobre la métrica.
Algunas de estas frecuencias serán definidas por reglamentos o requisitos contractuales con los clientes,
mientras que otras serán impulsadas por la necesidad de la toma de decisiones internas. La misma métrica
puede tener diferentes frecuencias dependiendo de dónde se envíe la información.
Es posible que algunas métricas no necesiten notificarse de forma regular, sino solo de forma excepcional. Esto
ayuda a reducir el desorden de la información, pero aun así permite que la atención se centre cuando sea
necesario o de utilidad.
Para cada métrica se definió qué rol deberá hacer la medición y recae en cada Jefe de Área designar a la
persona específica para que realice la tarea, así como su rotación y/o alternancia con otra persona del área.
A su vez cada jefe reportará los informes correspondientes a la Dirección según lo establecido
contractualmente, o por lo establecido para cada objetivo de la organización.
PRESENTACIÓN DE LA INFORMACIÓN
Tener datos no tiene mucho valor a menos que se presenten de una manera que permita una toma de
decisiones efectiva. Las personas necesitan ser capaces no solo de ver el rendimiento en un momento
determinado y compararlo con los límites de acción, sino también de buscar tendencias, diferenciar entre
fuentes de variación y evaluar la posible correlación.
Las siguientes serán formas comunes de presentar información para permitir la toma de decisiones:
Tablas: pueden ser útiles como información de apoyo, pero normalmente no son útiles para detectar valores
atípicos o tendencias.
Gráficos de líneas: cuando se desea un análisis de tendencias a lo largo del tiempo, un gráfico de líneas suele
ser la mejor opción. Se pueden incluir varias líneas siempre que las escalas sean equivalentes o si se utilizan
dos escalas (una en el eje izquierdo y otra en la derecha).
Gráficos de barras (horizontales, similares a los gráficos de líneas): también permiten comparar el rendimiento
a lo largo del tiempo, pero pueden ser especialmente beneficiosos cuando lo que se está midiendo tiene más
de un componente y existe el deseo de ver tanto la variación total como la variación en cada uno de los
componentes, que un gráfico de barras maneja bien.
Gráficos de barras (verticales): esta forma de visualización es la mejor para realizar comparaciones entre
diferentes grupos. Los grupos se pueden ordenar de alto a bajo o se pueden organizar en algún otro orden
lógico.
Gráficos circulares: solo son útiles para observar la proporcionalidad (por ejemplo, el porcentaje del total
asignado a cada grupo), ya que el tamaño del gráfico circular en sí es demasiado difícil de interpretar.
Figuras/diagramas: cualquier cosa que haga que el análisis de la información sea casi intuitivo, como mapas
codificados por colores, u otras imágenes, a menudo puede mostrar datos de una manera que es mucho más
fácil de interpretar, debido a que también se puede incluir o implicar el contexto.
INDICADORES EN TECNOLOGÍA
La calidad en ingeniería del software es el cumplimento de los requerimientos de software y contractuales por
parte de lo que brinda el producto en su desarrollo, así como luego en su mantenimiento.
Indicador 0001
Nombre Cobertura de buenas practicas
Referencia Porcentaje de cobertura de buenas prácticas en funcionalidades de cada

liberación
Escala de aceptación Aceptable >= 80 No aceptable < 80
Formula de calculo FD = Funcionalidades definidas
FR = Funcionalidades resueltas
C = Cobertura
C = (FD – FR) * 100
Periodicidad Evaluar en cada liberación de nueva versión
Responsable Equipos de desarrollo y/o QA
Fuente de datos Entregables, metas planificadas y pautadas vs requerimientos
Resultado esperado Contar con el mínimo permitido del. Criterio de aceptación
Indicador 0002
Nombre Cobertura de recuperación en caso de falla
Referencia Controlar los tiempos de inoperatividad definidos en el SLA. Medir capacidad de

respuesta y mitigación de los problemas
Escala de aceptación TR = Tiempo de recuperación del servicio
TR <= 15 minutos
Aceptable > TR
Formula de calculo TRF = Tiempo reporte de fallos
TSF = Tiempo de soluciones de fallas

TAS = Tiempo definido en SLA
TR = (TRF + TSF) / TAS
Periodicidad Cuando se den incidentes
Responsable Equipos de infraestructura
Fuente de datos Reportes de incidencia
Resultado esperado Contar con información y evaluar la mitigación menor al tiempo definido.
Indicador 0003
Nombre Cobertura de servicios monitoreados
Referencia Medir la cantidad de incidentes o fallas que fueron reportados por los servicios
que se encuentren monitoreados
Escala de aceptación Bajo < 3, Medio < 6 Alto >= 7
Formula de calculo SM = Servicio Monitoreado
IR = Incidentes Reportados
S = SUMA
IR = SIR - SSM
Periodicidad Semanal
Responsable Equipos de infraestructura
Fuente de datos Reportes de incidencia, SLA, Informe de Incidentes
Resultado esperado Se deberá cuantificar al menos un 90% de los casos que fueron reportados.
Indicador 0004
Nombre Cobertura de calidad de código en servicios
Referencia Medir la cantidad de bugs introducidos en el software implementado.
Escala de aceptación Aceptable < 10
Formula de calculo CC = Code Coverage

IL= Implementaciones probadas
IT= Implementaciones totales
CC = (ITT/IL) * 100
Periodicidad Por cada liberación o mensual
Responsable Equipos de TI
Fuente de datos Reportes de incidencias
Resultado esperado Se deberá de mantener un code coverage entre mayor al 70% con un total de
no mayor a 10 bugs.
Indicador 0005
Nombre Cantidad de Peticiones recibidas en los servicios
Referencia Se mediría la cantidad de peticiones que son atendidas por los diferentes
servicios, así como también los horarios de estos, para detectar picos de
peticiones a los servidores.
Escala de aceptación Aceptable < 10
Formula de calculo TP = Total peticiones
PA = Peticiones anteriores
PAC = Peticiones actuales
TP = PA + PAC
Periodicidad Semanal
Responsable Equipos de TI
Fuente de datos Reportes de servicios y peticiones
Resultado esperado Se espera contar con la información necesaria para implementar mejoras en
servidores para que sean capaces de sostener y mantener el crecimiento en las
peticiones a futuro.
INDICADORES EN PERSONAS
Indicador 0006
Nombre Confianza de nuestros clientes
Referencia Se medirá, en base a encuestas a los clientes para evaluar su confianza en los
servicios que utilizan en base a la cantidad de proyectos que tiene la empresa.
Escala de aceptación Mayor al 80 % de satisfacción
Formula de calculo C = Satisfacción
EP = Total Encuetas positivas
EN = Total Encuetas negativas
TE = Total de encuestas
C = (EP – EN) / TE
Periodicidad Semestral
Responsable Servicios
Fuente de datos Encuesta a clientes, seguimiento de proyectos
Resultado esperado Se espera que el resultado de las encuestas sea de un 80% de satisfacción por
parte de los clientes.
Indicador 0007
Nombre Productividad de los equipos.
Referencia Se medirá la productividad de los equipos de desarrollo en base a las tareas

que estén finalizadas.
Escala de aceptación Equipo Productivo > 100
Equipo no productivo < 100
Formula de calculo P = Productividad
TF = Tareas finalizadas
TDF = Tareas definidas
TI = Tiempo invertido
P = (TF– TDF) / TI
Periodicidad Cada cierre de sprint por proyecto,
Responsable Equipos de desarrollo y testing
Fuente de datos Seguimiento de proyectos,
Resultado esperado Los equipos deberían de tener una productividad mayor a 100 por cada uno de
sus integrantes.
Indicador 0008
Nombre Atención al cliente
Referencia Medir la eficiencia con la cual son atendidos los tickets de los clientes
Escala de aceptación 5 = Alto
3-4 = Medio
1- 2 = Bajo
Formula de calculo CPA = Promedio clientes
CCA = Cantidad clientes atendidos
CTC = Cantidad total de clientes
CPA = CCA / CTC
Periodicidad Mensual
Responsable Mesa de ayuda, Soporte de Usuarios
Fuente de datos Informes de atención al cliente
Resultado esperado Los clientes deben de atenderse en un 90% sus peticiones o >. a 5
Indicador 0009
Nombre Ciclo de vida de reclamos de usuarios
Referencia Medir el cumplimiento de los reclamos de los usuarios.
Escala de aceptación Aceptación > 80%
No aceptable < 80%

Formula de calculo CR = Cumplimiento reclamo
TJ = Tiempo creación tickets en Jira
TA = Tiempo actual
CR = (TR / TA) * 100
Fuente de datos Informes de atención al cliente, Jira, encuesta a Usuarios
Resultado esperado Se espera poder atender los tickets de clientes en un plazo no mayor a 5 días
Indicador 0010
Nombre Eficiencia de servicios
Referencia Medir el cumplimiento de los servicios
Escala de aceptación % mayor = eficiente
% menor = ineficiente
Formula de calculo E = eficiencia servicio
RS = Reclamos por Servicios
SR = Solicitudes por Reclamos
E = (RS / SR) * 100
Resultado esperado Reconocer cuales son los servicios con menor cantidad de reclamos puede
servir como medio de información para implementar en otros proyectos.
Indicador 0011
Nombre Retención de clientes
Referencia Medir la retención de los clientes.
Escala de aceptación % mayor = eficiente
% menor = ineficiente
Formula de calculo TR = Tasa de retención de clientes
CF = Clientes en total
CN = Clientes nuevos
TR = (CF - CG) * 100
Periodicidad Bimestral
Resultado esperado Se espera que la cantidad de clientes no sea inferior a la cantidad inicial de
clientes, el 90% de los usuarios retenidos.
INDICADORES EN PROCEDIMIENTO
Indicador 0012
Nombre Cumplimiento de cronogramas
Referencia Medir el grado de cumplimiento de los plazos establecidos por los cronogramas
en Jira
Escala de aceptación
Formula de calculo C = Cumplimiento
TC = Tiempo definido por cronograma
TE = Tiempo empleado
C = TC / TE
Responsable Jefes de proyectos, PM

Fuente de datos Seguimiento de proyectos, Jira, Calendarios definidos
Resultado esperado Se espera cumplir con los procedimientos definidos para el cumplimento de los
cronogramas con un 90 % de los plazos previstos
Indicador 0013
Nombre Cumplimiento de SLA
Referencia Medir el grado de cumplimiento de los SLAs
Escala de aceptación Aceptable < 90%
Inaceptable >= 90%
C = TC / TE
SLAs en un 90 % de los plazos previstos
Indicador 0014
Nombre Grado de Validación de los Requerimientos (VR)
Referencia Este indicador mide el grado en que los requerimientos fueron validados para
un proyecto de software.
Escala de aceptación Calcular el grado de validación de los requerimientos. VT = (RV / RSV)
El valor ideal de VR es uno (1). Son aceptables los valores superiores a 0,8.
Mientras más tienda a cero (0) el valor de VR, menor será el grado de
validación de los requerimientos.
Formula de calculo Calcular el grado de validación de los requerimientos.
El valor ideal de VR es uno (1). Son aceptables los valores superiores a 0,8.
Mientras más tienda a cero (0) el valor de VR, menor será el grado de
validación de los requerimientos.
Periodicidad Por proyecto

Responsable Referente de Calidad
Fuente de datos Seguimiento de proyectos
Resultado esperado Lista con el 100% de requerimientos registrados (Por tipo de requerimiento).
Distinguir en la lista el registro de requerimientos validados y no validados.
Indicador 0015
Nombre Grado de Eficacia en Eliminación de Defectos (EED)
Referencia Este indicador mide la eficacia de eliminación de defectos para un mismo

proyecto de software.
Dp: Cantidad de defectos detectados durante la fase de pruebas de software.
Dc: Cantidad de defectos detectados en la fase de pruebas del usuario cliente.
Escala de aceptación El valor ideal de EED es uno (1). Son aceptables los valores superiores a 0,5.
Mientras más tienda a cero (0) el valor de EDD, menor será la eficacia en la
eliminación de defectos.
Formula de calculo Calcular el grado eficacia en la eliminación de defectos. EED = (DP + DC) / DP
El valor ideal de EED es uno (1). Son aceptables los valores superiores a 0,5.
Mientras más tienda a cero (0) el valor de EDD, menor será la eficacia en la
eliminación de defectos.
Fuente de datos Registro de defectos en pruebas de software
Registro de defectos en pruebas de los usuarios clientes (Ej: UAT)
Resultado esperado Es un indicador cuantitativo que puede ser expresado en tablas o gráficos.
Indicador 0016
Nombre Porcentaje de Eficiencia del Proceso de Desarrollo de soluciones Tecnológicas

(%ED)
Referencia Este indicador se mide con proyectos de software de igual nivel de criticidad
(baja, media, alta)
Escala de aceptación El %ED ideal es el 100%.
Se considera aceptable los siguientes %ED:
Criticidad Baja: 90%.
Criticidad Media: 90%
Criticidad Alta: 95%
Formula de calculo D: Cantidad de defectos encontrados en la fase de pruebas.
C: Nivel de criticidad que tiene el software a desarrollar. Los valores de

criticidad son: Baja=1; Media= 1,4; Alta=1,8.
H: Cantidad de horas dedicadas al desarrollo del software.
Calcular el porcentaje de eficiencia del proceso de desarrollo del software.
ED = 1 - (D * C / H) * 100
Fuente de datos Registro de defectos
Horas dedicadas al proceso de desarrollo
Definición del nivel de criticidad de la solución.
Indicador 0017
Nombre Porcentaje de Disminución de Defectos (%DD)
Referencia Este indicador se mide con proyectos de software de igual complejidad (baja,
media, alta)
CdAn: Cantidad de defectos anteriores.
CdAc: Cantidad de defectos actuales.
Escala de aceptación Sí el resultado es positivo significa que existe una disminución satisfactoria de
los defectos. Si el resultado es negativo significa que hay incremento de
defectos.
Formula de calculo Calcular porcentaje de disminución de defectos.
DD = (CDAC / CDAN) * 100
Periodicidad Semestral/Anual
Fuente de datos Registro de defectos
INDICADORES DE INFRAESTRUCTURA
Indicador 0018
Nombre Interoperabilidad y disponibilidad de conexión
Referencia Medir el cumplimiento del acuerdo de SLAs en la conectividad, operatividad y

monitoreo
Inaceptable >= 95%
Formula de calculo D = Disponibilidad del servicio
HD = Horas disponibles
HC = Horas contratadas
D = HD – HR /100
Periodicidad Periódico
Responsable Infraestructura
Fuente de datos Acuerdo SLA. Informa de proveedor
Resultado esperado Se espera que todos los servicios cuenten con disponibilidad e interoperabilidad
Indicador 0019
Nombre Conectividad de los servicios

Referencia Se verifica que no existan caídas de los servicios.
Inaceptable >= 5%
Formula de calculo C = Calidad del servicio
CC = Cantidad de caídas
CS = Cantidad de servicios
C = CC / CS
Periodicidad Anual
Responsable Infraestructura
Fuente de datos Políticas de conectividad y calidad de los servicios
Resultado esperado Se espera que las caídas de los servicios sean entre el rango del 5% anual.
Indicador 0020
Nombre Crecimiento de Infraestructura
Referencia Medir el grado de crecimiento de la infraestructura
Inaceptable >= 90%
C = TC / TE
Periodicidad Anual
SLAs en un 90 % de los plazos previstos
Indicador 0021
Nombre Recuperación de datos
Referencia Medir la capacidad de recuperación de datos que tiene el servicio
Escala de aceptación <90% inaceptable
>= 90% aceptable
Formula de calculo % Copias de seguridad actuales en el plazo de una hora desde la última
actualización
Periodicidad Cada una hora
Responsable Equipo de QA – Técnicos de cada servicio, jefe de cada servicio
Fuente de datos Seguimiento de la actividad por JIRA, registro en el sistema de seguimiento.
Resultado esperado Se espera cumplir con el 90% de los respaldos estipulados para cada servicio.
Indicador 0022
Nombre Plazo para la restauración y reinicio de los servidores
Referencia Medir la capacidad de recuperación de los servidores
Escala de aceptación > media hora desde la interrupción del servicio inaceptable
< = media hora desde la interrupción del servicio aceptable
Formula de calculo % capacidad de restauración/reinicio de servidores = cantidad de

restauración/reinicio de servidores < 30 minutos / cantidad de
restauración/reinicio de servidores > 30 minutos x 100
Periodicidad Cada una hora
Responsable Equipo de QA – Técnicos de cada servicio, jefe de cada servicio
Fuente de datos Seguimiento de la actividad por JIRA, registro en el sistema de seguimiento.
Resultado esperado Se espera cumplir con el 90% de los respaldos estipulados para cada servicio.
HERRAMIENTAS
DE MEJORA CONTINUA
Asumimos que se podrá hacer uso de herramientas de mejora continua, las cuales buscaran puntos débiles en
los procesos, servicios y productos actuales. También creemos que ayudaran a señalar cuales áreas necesitan
de mejoras prioritarias o de beneficios que aporten a las mejoras del trabajo, buscando ahorrar tiempo y
mejora de las partes más críticas.
Algunas herramientas que se pueden utilizar:
 Método Kaizen – Es un método que aumenta el valor de los productos o servicios

 Diagramas de afinidad – Nos ayuda a juntar las ideas para organizar y resumir las ideas que sean
afines de forma agrupada.
 Análisis de valor – Nos ayuda a aumentar el valor de los diferentes servicios o productos.
DE SOFTWARE LICENCIADO
Asumimos que la empresa, cuenta con todas las licencias de software de terceros actualizados y hacen un
buen uso de los mismos, mantienen las actualizaciones y versiones de las herramientas definidas por la
organización.
AUDITORIAS
Para esta empresa las auditorías implicarían una herramienta de gran importancia en estas tres situaciones:
 como un requisito de efectuarlas de acuerdo con un programa y/o procedimiento para ajustarse
a lo establecido en la metodología de calidad.
 Como un elemento de entrada para la revisión del sistema de calidad de TI para los responsables
o líderes de las áreas.
 Como la metodología empleada para la evaluación de sus procesos, procedimientos, objetivos de
control y controles del sistema de gestión por las partes interesadas e incluso por parte de los
Organismos de Certificación, si deciden certificarse con algún standard.
En consecuencia, recomendamos seguir las directrices de la norma ISO 19011:2018 tanto para las auditorías
internas como las externas, sean éstas de segunda o de tercera parte.
El propósito de las auditorías será entonces, verificar la conformidad del sistema de gestión de la calidad de TI
con los requisitos establecidos en los modelos de gestión desarrollados anteriormente (ver apartado de
metodologías), la conformidad con los requisitos legales, así como la verificación de la eficaz implantación de
los procesos, procedimientos, objetivos de control y controles del Sistema de Gestión de Calidad de los
servicios de TI.
Cómo etapas de las auditorías establecemos:
 Preparación
 Ejecución
 Elaboración del informe
 Seguimiento de la eficacia de las acciones correctivas propuestas.
AUDITORÍAS INTERNAS O DE PRIMERA PARTE

Frecuencia: cada 6 meses.
Auditores: se deberá seleccionar personal con independencia de aquellos que tienen responsabilidad directa
sobre el servicio que se estará auditando.
En la actualidad la empresa no cuenta con personal capacitado para realizar estas tareas, por lo que se
recomienda que se seleccione a dos personas y se las capacite y forme lo antes posible.
Resultados: el/los auditores/es serán responsables de registrar los resultados y de transmitirlos al personal que
tenga responsabilidad en el sector auditado.
Acciones correctivas: será responsabilidad de cada jefe de servicio asegurarse que se toman acciones, sin
demoras injustificadas, para eliminar las no conformidades detectadas y sus causas. También serán
responsables de proponer e implantar las acciones correctivas apropiadas.
Seguimiento: las actividades de seguimiento servirán para la verificación y el registro tanto de la implantación
como de la eficacia de las acciones correctivas puestas en práctica. Para las acciones correctivas graves, se
realizará seguimiento a través de una nueva auditoría extraordinaria y para el resto de las no conformidades,
se deberá enviar un informe por escrito al auditor responsable.
AUDITORÍAS EXTERNAS
Se realizarán auditorías de segunda parte cada 2 años por parte de una empresa contratada para dicho
propósito. Esta empresa se hará cargo de las etapas de ejecución, elaboración del informe y seguimiento de las
acciones correctivas. La preparación será responsabilidad de DTD GAMMA.
CONCLUSIONES
Podemos concluir que la adopción de estrategias, metodologías y buenas prácticas basadas en marcos o
normas de gestión de la calidad como por ejemplo ISO/IEC e ITIL para la definición de los procesos y
responsabilidades de ejecución de los mismos, se transforman en un aliado para que la empresa continúe su
funcionamiento de manera más eficiente y con respaldo a futuro, ya que se detectarán y se planificarán todos
los aspectos necesarios donde antes no se atendían problemáticas comunes o donde carecían de orden y/o
revisión.
Con este plan buscamos adoptar ciertos beneficios para la empresa como: mejorar los controles de los
procesos, realizar auditorías regulatorias más fluidas, mejorar el sistema interno de controles para la calidad
de los productos y servicios, adoptar una nueva cultura de superación y colaboración, mejorar la formación de
los empleados y directivos y aumentar el compromiso de los trabajadores. Además, como resultados los costos
de la empresa se reducen, porque es más eficiente en su gestión y reelaboración de productos defectuosos.
La gestión de la calidad permite crear un marco para la evaluación independiente y demostrar la capacidad de
la empresa para cumplir con los requisitos planteados. También le da a la organización una ventaja competitiva
porque demuestra su confiabilidad y alta calidad de servicio. Los clientes obtienen la confianza cuando
adquieren un producto de software o servicio porque cumple con sus requisitos o necesidades, lo que hace de
la idoneidad funcional una de las características de calidad del software o servicio más importantes para
asegurar el éxito de un producto a sus usuarios.
REFERENCIAS
AXELOS Global Best Practice. (2019). ITIL Foundation ITIL 4 Edition. London, England: The Stationery Office.
Retrieved Junio 20, 2021
IT Process Wiki - The ITIL Wiki | The ITIL Process Map. (2019, Noviembre 11). Retrieved from ITIL
Implementation: https://wiki.en.it-processmaps.com/index.php/ITIL_Implementation
ITIL 4 | IT Process Wiki. (2019, Diciembre 03). Retrieved from ITIL 4: https://wiki.en.it-
processmaps.com/index.php/ITIL_4
Kempter, A. (2019, Marzo 30). IT Process Wiki - El Wiki de ITIL | IT Process Map. Retrieved from Métricas ITIL -
KPIs ITIL: https://wiki.es.it-processmaps.com/index.php/M%C3%A9tricas_ITIL_-_KPIs_ITIL
Maurya, A. (2016). Scaling LEAN - Mastering the Key Metrics for Startup Growth. New York: PORTFOLIO /
PENGUIN.
Okes, D. (2013). Performance Metrics - The Levers for Process Management (Vol. 1). (P. D. O’Mara, Ed.)
Milwaukee, Wisconsin, USA: American Society for Quality, Quality Press.
Sáenz, I. J. (2020, Noviembre 04). Youtube. Retrieved from Cursos Techcolca ITIL4 FOUNDATION [CURSO
COMPLETO]: https://www.youtube.com/watch?
v=mFjzgRFaLVM&list=PL5kUsobD8Kq3TfrDHVrjWao5dAJkYr4jq
UTEC. (2021, Junio 19). Moodle UTEC. Retrieved from Curso: Gestión de la Calidad en TI__5to Semestre
Durazno A: https://ev1.utec.edu.uy/moodle/course/view.php?id=5775

Plan de Calidad TI

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Plan de Calidad TI

Cargado por

Copyright:

Formatos disponibles

EMPRESA DE SERVICIOS CLOUD DTD GAMMA

Plan de gestión de calidad TI

CONTROL DEL DOCUMENTO

Id del documento Plan de Calidad TI-v0.2

Propietario del documento Ing. Juan Perez

Fecha de publicación 26 de junio de 2021

Último almacenamiento 26 de junio de 2021

Nombre del archivo Plan_Calidad_TI_Gamma.pdf

HISTORIA DEL DOCUMENTO

Versión Fecha Cambios

1.0 19/06/2021 Se elabora la primera versión del documento

Se elabora una segunda versión con modificaciones en:

La estructura del documento, colocamos el apartado de análisis luego de Alcance

Se completan el resto de los apartados.

Se modifica el documento s/ comentarios de la Tutora:

APROBACIONES DEL DOCUMENTO

Rol Nombre Firma Fecha

Grupo de revisión de proyecto Ing. Juan Gonzalez 26/06/2021

Líder del Proyecto Ing. Juan Rodriguez 26/06/2021

Líder de Calidad Ing. Juan Fernandez 26/06/2021

CONTROL DEL DOCUMENTO................................................................................................................................. 1

HISTORIA DEL DOCUMENTO................................................................................................................................................1

APROBACIONES DEL DOCUMENTO.....................................................................................................................................1

EXCLUSIONES, SUPUESTOS Y RESTRICCIONES.................................................................................................... 5

ANÁLISIS DE DTD GAMMA................................................................................................................................... 6

PLATAFORMA COMO SERVICIO..................................................................................................................................................17

INFRAESTRUCTURA COMO SERVICIO...........................................................................................................................................17

INDICADORES Y PRESENTACIÓN DE INFORMES......................................................................................................... 30

FRECUENCIA DE LAS REVISIONES ................................................................................................................................................31

LÍNEA BASE, OBJETIVO Y PUNTO DE REFERENCIA ...........................................................................................................................31

FUENTE DE DATOS Y FRECUENCIA DE RECOLECCIÓN ..................................................................................................................31

ACCIONES PARA TOMAR...................................................................................................................................................31

 Identificar un modelo de ciclo de vida adecuado para el problema a resolver.

EXCLUSIONES, SUPUESTOS Y RESTRICCIONES

El éxito de este proyecto supone:

 La aprobación de la propuesta de trabajo, por parte del CEO de la empresa.

 La estrategia de negocio de la empresa

ANÁLISIS DE DTD GAMMA

Los tipos de servicios que están trabajando son:

1. Software As a Service (SaaS)

DTD Gamma no ha definido políticas de calidad, tampoco ha definido su estrategia de negocio, ni

A continuación, detallaremos los puntos débiles o críticos de cada área/servicio de la empresa.

 Soporte de la infraestructura y de la empresa.

 Conocimiento extremo de todas las herramientas que se ofrecen.

Tienen pensado contratar a un arquitecto al inicio del proyecto.

Se deberá contemplar en la estrategia la necesidad de la empresa de equilibrar la estabilidad y previsibilidad

¿Por qué ITIL 4?

La estructura y los beneficios del marco ITIL ® 4

Los componentes claves del marco son:

 El modelo de cuatro dimensiones.

Las 4 dimensiones de la gestión de servicios según ITIL ® 4

Los componentes principales del SVS son:

1. la cadena de valor del servicio ITIL

Ilustración 1 Sistema de Valor del Servicio ITIL4

Las prácticas se agrupan en tres categorías:

 Prácticas generales de gestión

Prácticas generales de gestión

Prácticas de gestión de servicios

Prácticas de gestión técnica

A continuación, adjuntamos el cronograma de fases y actividades

Recomendamos a la empresa un relevamiento de activos de TI y su clasificación según la gravedad del impacto

A continuación, describiremos las etapas para llevar adelante el análisis de riesgos:

Para el análisis de riesgos consideraremos todos los recursos listados: