Plan de gestion de la calidad en TI de Utec Universidad Tecnologica

UTEC Universidad Tecnológica

Plan de gestión de la Calidad en TI

Integrantes

Florencia Alderete Matias Viana Marco Funes Andrés González

DURAZNO LTI REVISIONES

Fecha Versión Descripción Autor 21/05/2024 1.0 Plan de Calidad Grupo 8 22/05/2024 1.1 Plan de Calidad Grupo 8 31/05/2024 2.0 Plan de Calidad Matias

ÍNDICE POR PUNTO

PROPÓSITO 3 GESTION 4 DOCUMENTACIÓN 5 ESTRATEGIA DEL PLAN DE CALIDAD 15 RESPONSABILIDADES DE DIRECCIÓN. 16 ACTIVIDADES DE SQA. 17 GESTIÓN DE MÉTRICAS. 17 GESTIÓN DE CAMBIO (SCM) 19 REVISIONES Y AUDITORÍAS 21 HERRAMIENTAS, TECNICAS y METODOLOGIAS. 22 COMUNICACIÓN: 22 GLOSARIO 25 MAPA DE PROCESOS. 26 MAPA CONCEPTUAL (PRE-PROCESOS). 27 ENLACES ÚTILES 27

PROPÓSITO

El propósito de este plan es especificar cómo el aseguramiento de la calidad del software va a ser implementado al caso de la empresa DTD ALFA para su aplicación de Core Banking. El objetivo del Aseguramiento de la Calidad (Software Quality Assurance) es entregar a la administración una visibilidad adecuada del proceso utilizado y los productos construidos mediante acciones planificadas y sistemáticas que aseguren la calidad de dichos procesos y productos. Este plan describe las actividades a realizar por el SQA y define un conjunto de estándares a seguir para lograr el objetivo descrito anteriormente. En este caso el software a analizar consiste en el servicio de una Institución Financiera, que permita brindar servicios de:

• CMCD BANKING:
  • Cuentas corrientes y ahorros
  • Depósitos a plazos
  • Préstamos comerciales
  • Préstamos personales
  • Giros y remesas familiares
  • Garantías
  • Cajas y tesoro
  • Clientes
  • Contabilidad
  • Cumplimiento
• CMCD TRACE:
  • Control y prevención de los riesgos asociados a Lavado de Activos y Financiación del Terrorismo (SARLAFT).
  • Listas restrictivas (internas y externas).
  • Alertas en tiempo real.
  • Perfil de clientes
  • Reportes de cumplimiento
• CMCD MICROFINANCE:
  • Cuentas de ahorros
  • Depósitos a plazos
  • Prestamos pymes
  • Giros y remesas familiares
  • Garantías
  • Cajas y tesoro
  • Clientes
  • Contabilidad
  • Cumplimiento

GESTION

Organización

Las líneas de trabajo dentro de la organización que están más relacionadas con la calidad del software son: Proyectos (que regulan la aplicación de mejoras al sistema), las áreas pertenecientes al sistema (Core Banking, Trace y MicroFinanzas) y Soporte (es quien brinda las soluciones de infraestructura al sistema).

Actividades

Temas cubiertos por el Plan

Los temas cubiertos en el siguiente Plan tienen que ver con necesidades de ajuste organizacional, de flujos de trabajo y del desarrollo de los sistemas, que de no realizarse pueden peligrar el correcto funcionamiento de los sistemas y un mal servicio a los usuarios. Se hace especial énfasis en el entregable que incluye:

• Especificación de Puntos a Mejorar (Mapa Conceptual).
• Descripción de la Arquitectura y Alcance del Sistema.

Quedan exceptuados del análisis de este Plan los siguientes puntos:

• Estructura de la organización.
• Cantidad de recursos disponibles en cada área.
• Interacción entre las diferentes áreas o su reestructuración.
• Ventas, facturación, administración, contabilidad y capital humano.
• Arquitectura, herramientas de desarrollo y gestión.

Actividades de calidad a realizarse

Las tareas a ser llevadas a cabo deberán reflejar las evaluaciones a realizar, los estándares a seguir, los productos a revisar, los procedimientos a seguir en la elaboración de los distintos productos y los procedimientos para informar de los defectos detectados a sus responsables y realizar el seguimiento de los mismos hasta su corrección. Las actividades que se realizarán son:

• Revisar la situación actual de la compañía.
• Revisar los ajustes que se crean convenientes de los procesos.
• Realizar Revisión Técnica Formal (RTF).
• Asegurar que las desviaciones son documentadas, bajo un procedimiento establecido.

Revisar cada producto

En esta actividad se revisan los productos que se definieron como claves para verificar en el Plan de calidad. Se debe verificar que no queden correcciones sin resolver en los informes de revisión previos, si se encuentra alguna no resuelta, debe ser incluida en la siguiente revisión. Se revisan los productos contra los estándares, utilizando la checklist definida para el producto. Se debe identificar, documentar y seguir la pista a las desviaciones encontradas y verificar que se hayan realizado las correcciones.

Revisar el ajuste al proceso

En esta actividad se revisan los productos que se definieron como claves para verificar el cumplimiento de las actividades definidas en el proceso. Con el fin de asegurar la calidad en el producto final del desarrollo, se deben llevar a cabo revisiones sobre los productos. Esta información se obtiene del documento otorgado por los docentes y del Plan de GCTI. Como salida se obtendrá el Informe de revisión de SQA correspondiente a la evaluación de ajuste al Proceso, este informe debe ser distribuido a los responsables de las actividades y se debe asegurar de que son conscientes de desviaciones o discrepancias encontradas.

Realizar Revisión Técnica Formal (RTF)

El objetivo de la RTF es descubrir errores en la función, la lógica o la implementación de cualquier producto del software, verificar que satisface sus especificaciones, que se ajusta a los estándares establecidos, señalando las posibles desviaciones detectadas. Es un proceso de revisión riguroso, su objetivo es llegar a detectar lo antes posible, los posibles defectos o desviaciones en los productos que se van generando a lo largo del desarrollo. Por esta característica se adopta esta práctica para productos que son de especial importancia. En la reunión participan el responsable de SQA e integrantes de los equipos que realizan el desarrollo de los sistemas de la compañía.

Asegurar que las desviaciones son documentadas

Las desviaciones encontradas en las actividades y en los productos deben ser documentadas y ser manejadas de acuerdo a un procedimiento establecido. Se debe chequear que los responsables de cada plan los modifiquen cada vez que sea necesario, basados en las desviaciones encontradas.

DOCUMENTACIÓN

Propósito

Identificación de la documentación relativa a desarrollo, Verificación, Validación, uso y mantenimiento del software. Establecer como los documentos van a ser revisados para chequear consistencia: se confirman criterio e identificación de las revisiones. Especificación de indicadores/métricas. El documento de especificación de indicadores deberá describir, de forma clara y precisa, cada uno de los indicadores esenciales del sistema. El cliente deberá obtener como resultado del proyecto una especificación adecuada a sus necesidades en el área de alcance del proyecto, de acuerdo al compromiso inicial del trabajo y a los cambios que este haya sufrido a lo largo del proyecto, que cubra aquellos aspectos que se haya acordado detallar con el cliente. Los requerimientos de calidad del producto abarcan tanto asuntos generales de los sistemas de TI, como puntuales de la realidad planteada y son los que tienen incidencia sobre la calidad en el uso y se detallan a continuación:

Indicadores asociados al trabajo de la compañía.

1. Tiempo de respuesta del soporte

   El tiempo de respuesta evalúa directamente el nivel de compromiso de los empleados. Es importante estar alerta. El tiempo medio de respuesta debe ser rápido para que el servicio final sea satisfactorio. Al fin y al cabo, aunque la demanda esté resuelta, si el servicio tarda demasiado el cliente tiende a estar un poco insatisfecho.

2. First Call Resolution

   FCR no es más que resolver un problema luego de la primera llamada. Mide el número medio de tickets (llamadas) resueltos en cuanto el usuario contacta con el agente de soporte. Este indicador de TI es importante porque contribuye a mejorar la satisfacción del cliente final y a reducir el costo medio del servicio.

3. Disponibilidad del sistema

   Tener el sistema disponible es sinónimo de que los flujos funcionen normalmente. Siempre que el sistema esté fuera del aire la empresa puede sufrir pérdidas, aunque la inestabilidad sea por poco tiempo.

4. Cumplimiento del Service Level Agreement (SLA)

   El SLA demuestra la calidad de los niveles de servicio. El indicador SLA evalúa el porcentaje de incidencias, las resoluciones propuestas y cuál es el nivel de eficacia. El sistema SLA gestiona las expectativas y la satisfacción general, identificando las fallas y otros problemas de rendimiento. El indicador de cumplimiento de los acuerdos de nivel de servicio (SLA) mide si estos recursos se utilizan adecuadamente, garantizando la mejora del proceso. Debido a que el Departamento de Soporte posee un SLA con cada uno de sus clientes, es importante medir su efectividad.

5. Tiempo medio entre fallas y tiempo medio de reparación

   El tiempo medio entre fallas mide el tiempo invertido en pensar en el funcionamiento de las máquinas. La fórmula para calcular este indicador es: Tiempo de disponibilidad - tiempo de inactividad / número de fallos. El resultado será igual al tiempo medio entre fallas. Tambien es importante mencionar el tiempo medio de reparación, que indica el tiempo que el equipo necesita invertir para resolver una llamada. Esto nos ayudará a medir la forma en la que las diferentes áreas del sistema responden ante fallas y optimizar tiempos.

6. Tickets de soporte cerrados por un empleado

   Este indicador mide cuántos tickets de soporte fueron cerrados por cada empleado del equipo. Este indicador de TI es esencial para identificar problemas como las brechas en el rendimiento de los empleados, formación ineficaz y falta de estándares de scripts de llamada. Cuanto más alto sea el ticket medio, mejor será el índice de productividad y las entregas de cada empleado. Si bien este indicador es naturalmente para el departamento de soporte, en el caso planteado es aplicable a las tres áreas del sistema, ya que parte de su trabajo consta en resolución de fallas.

7. Número de proyectos con beneficios probados

   La realización de los proyectos debe ser adecuada a los objetivos de la empresa. Por tanto, no basta con evaluar la cantidad de proyectos, sino si realmente aportan beneficios a la organización. Este indicador será aplicado al Departamento de Proyectos.

Métrica

Objetivo Atributo Primitivas Responsable Tiempo de respuesta del soporte El tiempo de respuesta evalúa directamente el Tiempo que transcurre entre la solicitud de tiempo ideal nivel de soporte y la respuesta. estándar para diferentes tipos de consultas para poder realizar la comparación. los empleados. El tiempo medio de respuesta debe ser rápido para que el servicio final sea satisfactorio. First Call Resolution Mide el número medio de tickets (llamadas) Cantidad de cantidad de tickets totales resueltos / resueltos en llamada Cantidad de cuanto el usuario tickets resueltos ante una única contacta con el agente de soporte llamada Disponibilidad del sistema Medición del Minuto de del Minutos totales del día / Minutos de disponibilidad del sistema Responsables de las diferentes áreas Cumplimiento del Service Level Agreement (SLA) El indicador SLA Conformidad de Porcentaje de Responsables de evalúa el porcentaje de incidencias, las resoluciones propuestas y cuál es el nivel de eficacia. Para medirlo se realizarán encuestas periódicas a los clientes sobre el servicio. Tiempo medio entre fallas y tiempo medio de reparación El tiempo medio entre fallas mide el tiempo en Tiempo entre medio fallas. Tiempo de Responsable soporte. de disponibilidad - invertido Tiempo medio de reparación tiempo inactividad de / Responsable Soporte. de de tiempo de disponibilidad del sistema disponibilidad sistema. cada cliente frente a su SLA. las diferentes áreas. cumplimiento, informado por el cliente, del cumplimiento del SLA. Responsable Soporte. tickets resueltos ante una única Se deberá estipular un compromiso de