Embed Size (px)
Citation preview
FACULTAD DE INGENIERÍA
Carrera de Ingeniería Informática y de Sistemas
AUTOMATIZACIÓN DE LOS PROCESOS DE ASEGURAMIENTO DE LA CALIDAD EN APOYO AL PROYECTO NUEVO CORE BANCARIO DEL BANCO
DE LA NACIÓN
Trabajo de Suficiencia Profesional para optar el Título Profesional
de Ingeniero de Informático y de Sistemas
DANIEL TORRES PINEDA
Asesor:
Ing. Gisella Yrene Figueroa Tejada
Lima - Perú
2018
ÍNDICE GENERAL
INTRODUCCIÓN 1
DESARROLLO 3
Generalidades de la Empresa 3
Datos generales. 3
Nombre o razón social de la empresa. 3
Ubicación de la empresa (dirección, teléfono y mapa de ubicación). 3
Giro de la empresa. 3
Tamaño de la empresa (micro, pequeña, mediana o grande). 4
Breve reseña histórica de la empresa. 4
Organigrama de la empresa. 4
Misión y visión. 4
Productos y clientes. 5
Premios y certificaciones. 5
Planteamiento del Problema Abordado 5
Caracterización del área en que se participó. 5
Antecedentes y definición del problema. 6
Objetivos: general y específico. 7
Justificación. 8
Alcances y limitaciones. 8
Marco Teórico 10
Desarrollo del Proyecto 15
Breve resumen. 15
Metodología. 15
Roles y responsabilidades. 17
Seguimiento y control. 18
Reuniones de seguimiento. 19
Procesos automatizados. 19
Implementación de IBM Rational Quality Manager. 32
Análisis y Resultados 36
Impacto del nuevo proceso de certificación sobre el de gestión de desarrollos. 36
Atención de servicios de certificación. 38
Atención de defectos. 41
Vinculación de artefactos de prueba con servicio de certificación. 48
Vinculación de artefactos de prueba con el registro de un defecto. 51
CONCLUSIONES 53
RECOMENDACIONES 54
REFERENCIAS BIBLIOGRÁFICAS 55
ANEXOS 56
LISTA DE FIGURAS
Contenido Pág.
Figura 1. Mapa de ubicación de la empresa QBAN Consulting SAC. 3
Figura 2. Organigrama de QBAN Group. 4
Figura 3. Diagrama causa-efecto del anterior proceso de certificación de producto. 7
Figura 4. Ciclo de vida BPM. 15
Figura 5. Magic Quadrant for Intelligent Business Process Management Suites 16
Figura 6. Flujo de trabajo del Proceso de Certificación de Producto. 19
Figura 7. Diagrama de Estados del Proceso de Certificación de Producto. 20
Figura 8. Flujo de trabajo del Sub-Proceso Planificación. 21
Figura 9. Flujo de trabajo del Sub-Proceso Revisión. 21
Figura 10. Flujo de trabajo del Sub-Proceso Diseño de Pruebas. 22
Figura 11. Flujo de trabajo del Sub-Proceso Despliegue . 23
Figura 12. Flujo de trabajo del Sub-Proceso Ejecución de Pruebas. 24
Figura 13. Flujo de trabajo del Sub-Proceso Seguimiento y Control de Pruebas. 25
Figura 14. Flujo de trabajo del Sub-Proceso Devolución. 25
Figura 15. Flujo de trabajo de Actividad de Certificación. 26
Figura 16. Diagrama de estados de la Actividad de Certificación. 26
Figura 17. Fragmento del flujo de trabajo de Gestión de Mantenimientos. 27
Figura 18. Definición de Tipo y Motivo de Defectos. 28
Figura 19. Definición de Resolución de Defectos. 28
Figura 20. Definición de Efecto de Defectos. 29
Figura 21. Definición de Modo de Defectos. 29
Figura 22. Definición de Actividad de Inserción de Defectos. 29
Figura 23. Diagrama de Estados del Proceso de Gestión de Defectos. 30
Figura 24. Flujo de trabajo del Proceso de Gestión de Defectos. 31
Figura 25. Diagrama de despliegue de IBM Rational Quality Manager. 32
Figura 26. Plantilla de plan de pruebas. 33
Figura 27. Plantilla de caso de pruebas. 33
Figura 28. Plantilla de suite de pruebas. 34
Figura 29. Adaptador de IBM Rational Functional Tester. 34
Figura 30. Adaptador de IBM Rational Performance Tester. 35
Figura 31. Fragmento del manual de usuario. 36
Figura 32. Servicios de certificación atendidos durante el 2016. 39
Figura 33. Servicios de certificación atendidos durante el 2017. 40
Figura 34. Servicios de Certificación atendidos por Gestor de Pruebas durante el 2016. 40
Figura 35. Servicios de Certificación atendidos por Gestor de Pruebas durante el 2017. 40
Figura 36. Servicios de certificación no actualizados del 2017. 41
Figura 37. Defectos registrados por tipo durante el 2016. 43
Figura 38. Motivos por tipo de Defecto “Datos” en el 2016. 43
Figura 39. Efectos más recurrentes por Defecto en el 2016. 43
Figura 40. Modos de ocurrencia por Defecto en el 2016. 44
Figura 41. Actividad de Inserción más recurrente por Defecto en el 2016. 44
Figura 42. Defectos registrados por tipo durante el 2017. 44
Figura 43. Motivos por tipo de Defecto “Datos” en el 2017. 45
Figura 44. Efectos más recurrentes por Defecto en el 2017. 45
Figura 45. Modos de ocurrencia por Defecto en el 2017. 45
Figura 46. Actividad de Inserción más recurrente por Defecto en el 2017. 46
Figura 47. Defectos pendientes de actualización de estado del 2017. 47
Figura 48. Ingreso de complejidad y prioridad. 48
Figura 49. Ingreso de fechas planificadas de atención en sección ejecución del formulario.
48
Figura 50. Ingreso de fechas planificadas de certificación por etapas. 48
Figura 51. Vinculación de plan de pruebas en sección enlaces del formulario. 49
Figura 52. Adición de un nuevo plan de pruebas al formulario. 49
Figura 53. Ingreso de datos mínimos del plan de pruebas desde el formulario de IBM
Rational ClearQuest. 50
Figura 54. Enlace (link) del plan de pruebas creado y relacionado al formulario del servicio
de certificación en la sección enlaces. 50
Figura 55. Secciones del plan de pruebas en IBM Rational Quality Manager. 50
Figura 56. Creación de un defecto desde la ejecución de un caso de pruebas. 51
Figura 57. Comunicación con IBM Rational ClearQuest para selección del tipo de registro
DefectoQA. 51
Figura 58. Autenticación con IBM Rational ClearQuest para enlazar el formulario de Defecto
al registro de ejecución del caso de pruebas. 51
Figura 59. Formulario de Defecto de IBM Rational ClearQuest rellenado con información
obtenida de IBM Rational Quality Manager. 52
LISTA DE TABLAS
Contenido Pág.
Tabla 1 Tiempo promedio de la certificación en días por año del 01/01/2010 al 16/03/2016.
37
Tabla 2 Tiempo promedio de la certificación en días por año del 17/03/2016 al 01/12/2017.
37
Tabla 3 Tiempo promedio por etapa de la certificación en días por año del 17/03/2016 al
01/12/2017. 38
Tabla 4 Extracto de listado de defectos generados por servicios de certificación. 42
Tabla 5 Listado de defectos por tipo y motivo registrados durante el 2017. 47
LISTA DE ANEXOS
Contenido Pág.
Anexo 1. Procedimiento Certificación de Producto Software (2010) 57
Anexo 2. Informe de Evaluación de Procesos 81
1
INTRODUCCIÓN
El presente Informe de Experiencia Profesional busca demostrar las capacidades y
competencias profesionales adquiridas a lo largo de mi experiencia laboral enmarcado en la
atención de un proyecto exitoso.
La problemática que se abordó trata sobre la no contemplación del detalle del proceso de
Certificación de Producto dentro del proceso automatizado de Ciclo de Vida del Software, lo
cual ocasionaba no tener visibilidad de la carga ingresada a la Sección Calidad de
Soluciones perteneciente a la Sub-Gerencia de Aseguramiento y Calidad de la Gerencia de
Informática del Banco de la Nación. No se tenían registrado los tiempos reales de atención,
ni visibilidad del avance o de la etapa en que se encontraba la atención de la Certificación.
Además, no se podía garantizar el cumplimiento del proceso definido. Únicamente se
registraba el inicio y fin de pruebas sin mayor detalle dentro del proceso de Ciclo de Vida de
Software.
El no tener visibilidad de la carga ingresada al área, no permitía realizar la planificación
oportuna para poder dimensionar la carga de trabajo de los recursos de pruebas.
El no tener registro de tiempos reales incurridos por etapa, no permitía medir los
esfuerzos involucrados para la atención de la Certificación ni mucho menos identificar
oportunidades de mejora sobre posibles tiempos muertos o sobre la reducción de tiempos
excesivos.
El no tener el proceso automatizado al detalle, mediante un flujograma que identifique los
estados por los que pasa el proceso, no permitía garantizar que se esté cumpliendo como
se ha definido.
Para poder atender la problemática, se implementó una solución basada en procesos
con metodología BPM, en donde se requirió analizar y evaluar los procesos existentes de la
Sección Calidad de Soluciones, plantear el rediseño de los mismos, modelarlos en base a
las necesidades actuales, automatizarlos de manera personalizada con una herramienta
capaz de brindar seguimiento y control en entiempo real, además de poder optimizarlos sin
mucho esfuerzo cuando se requiriera, como lo es IBM Rational ClearQuest, la cual además
ya se encontraba en uso para la automatización del proceso de Ciclo de Vida de Software
para la Gestión de Proyectos y Mantenimientos. Adicionalmente, durante la implementación
se presentó la necesidad de crear nuevos procesos para la Gestión de Defectos y Gestión
2
de Incidencias y que éstos tuvieran la capacidad de relacionarse con el nuevo proceso de
Certificación de Producto.
Parte de las necesidades por atender fue la de mejorar la gestión de artefactos de
pruebas, y para ello se utilizó la herramienta IBM Rational Quality Manager cuyas licencias
ya habían sido adquiridas por el cliente, pero no es encontraba implementado, por lo que se
procedió con la definición de la arquitectura de la solución, instalación y configuración de los
servidores de aplicaciones y base de datos, así como la creación de las áreas de proyecto y
la personalización de las plantillas de los artefactos de prueba.
Finalmente, se indicó la necesidad de vincular los artefactos de pruebas gestionados por
IBM Rational Quality Manager con los procesos automatizados de Certificación de Producto
y Gestión de Defectos en IBM Rational ClearQuest, en donde el mayor ahorro de tiempo se
dio durante la ejecución de pruebas y el registro de defectos.
3
DESARROLLO
Generalidades de la Empresa
Datos generales.
La empresa QBAN Consulting, dedicada a la mejora de procesos de negocio y a la
ingeniería de software, cuenta con más de 10 años de experiencia dentro de los cuales han
desarrollado proyectos en importantes empresas del sector Financiero, Gobierno e
Industria. Cuenta con 22 empleados (entre personal administrativo y técnico), tiene una
cobertura de mercado local y es Business Partner de IBM como Partner Advance desde el
año 2006.
Nombre o razón social de la empresa.
QBAN Consulting SAC
Ubicación de la empresa (dirección, teléfono y mapa de ubicación).
Dirección: Calle Tacna 330, Miraflores. Teléfono: 719-1616. Ubigeo: 039252.
Figura 1. Mapa de ubicación de la empresa QBAN Consulting SAC. (Google, 2017).
Recuperado de https://goo.gl/maps/2RrpihG4TN72.
Giro de la empresa.
Consultoría de Sistemas
4
Tamaño de la empresa (micro, pequeña, mediana o grande).
Pequeña empresa. Cuenta con 1 Gerente General, 1 Gerente de Operaciones, 1 Gerente
de Finanzas, 1 Contador, 2 Jefes de Proyecto y 16 Consultores.
Breve reseña histórica de la empresa.
La empresa fue fundada el 23 de marzo del 2006, orientada inicialmente para impartir
capacitación y consultoría sobre Ingeniería de Software y en la actualidad se dedica al
rediseño y automatización de procesos.
Organigrama de la empresa.
Figura 2. Organigrama de QBAN Group. (QBAN Consulting, 2017)
Misión y visión.
Misión.
La empresa QBAN Consulting tiene como misión “Apoyar en la mejora de procesos
relacionados al ciclo de vida del software y la formación de competencias del talento
humano que permita el éxito y la calidad de los productos desarrollados por nuestros
clientes”.
Visión.
Asimismo, tiene como visión “Ser reconocida como la empresa líder en la mejora de
procesos relacionados al ciclo de vida y el aseguramiento de la calidad de productos
5
software. Ser considerado como el centro de referencia para la formación de competencias
del talento humano, relacionado con el desarrollo y mantenimiento del software y servicios
relacionados”.
Productos y clientes.
Productos.
Los productos que ofrece son: “IBM Rational ClearQuest, IBM Rational ClearCase, IBM
Rational Functional Tester, IBM Rational Performance Tester, IBM Rational DOORS Next
Generation, IBM Rational Quality Manager, IBM Rational Team Concert e IBM UrbanCode”.
Clientes.
Tiene como clientes a “Banco de la Nación, Banco Ripley, CMAC Cusco, COFIDE,
Congreso de la República, Contraloría General de la República, Grupo Añaños, Interbank,
Novatronic, ONPE, OSINERGMIN, Poder Judicial, Sedapal, SENASA, SUNAT, SUTRAN y
UPeU”.
Premios y certificaciones.
Certificaciones.
Ha obtenido las certificaciones “IBM Certified Solution Designer - IBM Rational Unified
Process V7.0, IBM Rational IT Solution Sales Professional v2, IBM Certified Solution
Designer - Rational Functional Tester for Java, IBM Certified Administrator -- Rational UCM
Fundamentals, IBM Certified Deployment Professional - Rational RequisitePro, IBM Certified
Specialist - Rational ClearQuest v7.1, IBM Security AppScan Solution Sales Professional v1,
IBM Certified Specialist - Tivoli AppScan Standard Edition”.
Planteamiento del Problema Abordado
Caracterización del área en que se participó.
La Sección Calidad de Soluciones perteneciente a la Sub-Gerencia de Aseguramiento y
Calidad, que a su vez pertenece a la Gerencia de Informática del Banco de la Nación
(cliente).
6
Antecedentes y definición del problema.
Antecedentes.
El Banco de la Nación adquirió licencias de software Rational de IBM en la LP N° 0012-
2008-BN; para el apoyo a la Metodología del Ciclo de Vida del Software y la implementación
de los procesos planteados en la Norma Técnica Peruana NTP-ISO 12207:2004.
Así mismo el Banco de la Nación inició el Proyecto Nuevo Core Bancario el cual abarcó
cambios en la infraestructura y sistemas financieros que debían ser probados por los
Analistas de la Sección de Calidad de Soluciones, los cuales se interrelacionan con otros
procesos de las demás divisiones de la Gerencia de Informática del Banco de la Nación.
La Gerencia de Informática ya poseía un proceso automatizado (workflow) para la
gestión del Ciclo de Vida del Software utilizando herramientas IBM, especialmente Rational
ClearQuest y Rational RequisitePro, dentro del cual sólo se tenía visibilidad del inicio y fin
de las pruebas, es decir, que al no estar automatizado el proceso de certificación de
software presentaba falencias tales como: (1) incapacidad de realizar seguimiento a las
etapas incurridas durante la certificación, refiere a que no se podía tener certeza del
cumplimiento del proceso definido, (2) no visibilidad del esfuerzo e información inherente
por cada etapa de Certificación en relación al recurso humano o artefacto de software
requerido, (3) imposibilidad de plantear mejoras al proceso al no tener información
registrada para obtención de métricas; no se tenía retroalimentación, (4) no visibilidad de la
carga acumulada real por Analista de Calidad, (5) desconocimiento de la cantidad de
iteraciones realizadas por fallos encontrados y de la etapa de su ocurrencia, e (6)
imposibilidad de identificar el tipo de defectos encontrados más recurrentes debido a que
sólo se llevaba un registro manual de los mismos en una plantilla de Microsoft Word.
Problema.
En relación con la atención de proyectos y mantenimientos, se observaron registros cuyo
tiempo de atención de la etapa de pruebas no coincidía con el tiempo y esfuerzo real
efectuado por los Analistas de Calidad, ya que al no haber sido contemplado el detalle del
“Procedimiento de Certificación de Productos Software” (ubicado en el Anexo 1) dentro de la
automatización del Ciclo de Vida del Software, se identificó que se tuvieron gestiones
manuales diversas no registradas en la herramienta además de no poder garantizar si se
estaría cumpliendo el proceso definido de Certificación o si se estuvieran realzando otras
actividades ajenas al mismo.
7
Por lo tanto, al no tener los registros de inicio y fin de las etapas inmersas en la
Certificación, no podrían ser datos fidedignos y menos tomarlos como información confiable
para obtención de métricas reales.
Una solución viable para la corrección del problema analizado fue la de realizar el
rediseño del proceso “Certificación de Productos Software” como conclusión del “Informe de
Evaluación de Procesos” (ubicado en el Anexo 2) y su posterior automatización en la misma
herramienta IBM Rational ClearQuest. Cabe mencionar que el proceso anterior no había
sido automatizado.
Para representar las posibles causas que estaban involucradas en el origen de la
problemática, se visualiza en la Figura 3 el diagrama causa-efecto que sirvió de guía para el
re-modelamiento del proceso de certificación y de esta manera garantizar que el proyecto
pudiese cubrir las necesidades planteadas.
Figura 3. Diagrama causa-efecto del anterior proceso de certificación de producto.
Fuente: Elaboración propia.
Objetivos: general y específico.
Objetivo del proyecto.
El objetivo general del proyecto consistió en identificar los beneficios de automatizar los
procesos inmerso en el Aseguramiento de la Calidad (el proceso de Certificación de
Producto, el proceso de Gestión de Defectos e incidentes) con la herramienta IBM Rational
ClearQuest, partiendo de la evaluación del proceso actual y posterior entrega y aceptación
del modelo mejorado a ser automatizado.
8
Objetivo específico (1): Definir e implementar una solución que permita crear,
personalizar, resguardar y reutilizar artefactos de prueba.
Objetivo específico (2): Poder vincular los procesos automatizados con los artefactos de
prueba resguardados en el repositorio de la solución implementada.
Justificación.
Justificación del proyecto.
El proyecto permite a la Sección Calidad de Soluciones tener la capacidad de
gobernabilidad sobre sus procesos, es decir, al ser el dueño de sus procesos, tiene el poder
de analizar, diseñar y mejorar el proceso de manera continua para luego implementar las
mejoras identificadas.
La automatización de los procesos le permite tener visibilidad sobre las peticiones de
Certificación ingresadas al área con el fin de poder evaluar el esfuerzo conllevado para la
atención de cada petición, además de poder dimensionar la carga de trabajo por Analista de
Calidad para saber en tiempo real la capacidad de atención global; así como poder definir
las fechas planificadas de ingreso a cada etapa por petición.
Adicionalmente, al poder registrar los defectos encontrados permite obtener información
crítica para la mejora de calidad, debido a que al categorizar los defectos más recurrentes
es posible evidenciar las principales falencias que presentan los equipos de desarrollo.
El sistema, al poder registrar los tiempos reales consumidos por atención de peticiones,
permite identificar oportunidades de mejora al reducir los tiempos de atención si fuera
posible, dependiendo de los factores de retraso que pudieran encontrarse con la
información registrada. Se tendría una retroalimentación constante.
Alcances y limitaciones.
Alcances.
El proyecto incluía:
Etapa 1: Conceptualización del nuevo modelo de Procesos de la Sección Calidad de
Soluciones.
Evaluación (Assessment) de los Procesos actuales de las Sección de Calidad de
Soluciones.
9
Relevamiento de las características de los procesos actuales de la Sección.
Elaboración del Nuevo Modelo de los Procesos de la Sección.
Validación del modelo de procesos propuesto para la Sección
Validación del modelo de procesos por las Secciones con las que interactúa la
Sección Calidad de Soluciones, incluyendo a: Desarrollo, Infraestructura, Producción y
Seguridad Informática.
Etapa 2: Implementación de los Procesos a través de Flujos de Trabajo Automatizados.
Desarrollo de la solución a nivel de la herramienta IBM Rational ClearQuest de los
Flujos de Trabajo e Implementación de la solución.
Incorporación de Buenas Prácticas en uso de herramientas de pruebas de software
con las que cuenta ya el Banco de la Nación.
Incorporación de las Buenas Prácticas de Gestión sugeridas en la evaluación previa
(Assessment) de los Procesos actuales realizada en la etapa 1.
Incorporación de Consultas y Reportes Estadísticos de Gestión de los Procesos.
Etapa 3: Capacitación y Acompañamiento.
Capacitación en los Procesos de la Sección Calidad de Soluciones por un total de
dieciséis (16) horas.
Acompañamiento en la ejecución de los Procesos de la Sección Calidad de
Soluciones por un total de veinte (20) horas.
Limitaciones.
El proyecto debía tener una duración máxima de 120 días calendarios (04 meses)
desde la fecha de inicio del proyecto 07 de mayo, debiendo terminar antes del 03 de
septiembre del 2015.
El proyecto no comprendía la ejecución de pruebas de aplicaciones y/o hardware.
El proyecto seguiría una metodología establecida por la empresa consultora para
aseguramiento de calidad.
La automatización de los procesos debería realizarse mediante la herramienta de
gestión de cambio IBM Rational CleatQuest.
Los procesos automatizados deberían integrarse con la herramienta de gestión de
activos de pruebas IBM Rational Quality Manager.
Las plantillas de los artefactos de pruebas deberían alinearse a las buenas prácticas
mencionadas en ISTQB.
10
Marco Teórico
Basado en la NTP ISO/IEC 12207 2006 2° Edición.
Los procesos automatizados de certificación de producto, gestión de defectos y gestión de
incidentes, se encuentran alineados al cumplimiento del proceso de aseguramiento de
calidad el cual es definido como “un proceso para proporcionar la seguridad apropiada de
que los productos y procesos software del ciclo de vida del proyecto son conformes con sus
requerimientos especificados y se adhieren a los planes establecidos”. (Comisión de
Reglamentos Técnicos y Comerciales-INDECOPI, 2006)
Metodología para el Ciclo de Vida del Software NTP-ISO/IEC 12207.
Fue adaptada de la NTP 12207 e implementada aplicando RUP. “Integración y pruebas del
software”. (Banco de la Nación, 2006), es la sección dedicada al Aseguramiento de la
Calidad de Software.
International Software Testing Qualifications Board.
Las etapas, mecanismos de control y artefactos de pruebas que fueron definidos en los
procesos automatizados de certificación de producto, gestión de defectos y gestión de
incidentes, tuvieron como lineamientos varios puntos del Programa de Estudio de Nivel
Básico de Probador Certificado de ISTQB, partiendo del proceso básico de pruebas el cual
resalta que “La parte más visible del proceso de pruebas es la ejecución de pruebas. No
obstante, para ser efectivos y eficientes, los planes de pruebas también deben indicar el
tiempo necesario para planificar las pruebas, diseñar los casos de prueba, preparar la
ejecución y evaluar los resultados”. (Müller et al, 2010).
IEEE Standard Classification for Software Anomalies 1044 – 2009.
Este estándar proporciona un enfoque uniforme para la clasificación de anomalías de
software, independientemente de cuándo se originan o cuándo son encontrados dentro del
ciclo de vida del proyecto, producto o sistema. Los datos de clasificación pueden utilizarse
para diversos fines, incluido el análisis causal de defectos, la gestión de proyectos y la
mejora de procesos de software (Software & Systems Engineering Committee, 2010).
OSLC.
Es una comunidad abierta, propuesta originalmente en 2008, para definir un conjunto de
especificaciones que permitan la integración del desarrollo de software. Ha evolucionado, y
11
continúa evolucionando, a áreas tales como Administración del ciclo de vida de la aplicación
(ALM), Administración del ciclo de vida del producto (PLM), Operaciones de TI y más. La
intención es hacer la vida más fácil para los usuarios de herramientas y los proveedores de
herramientas, facilitando que las herramientas trabajen juntas (Wikipedia, 2019.
Recuperado de https://en.wikipedia.org/wiki/Open_Services_for_Lifecycle_Collaboration).
Ampliación de Rational Quality Manager utilizando servicios OSLC.
Definición de IBM Knowledge Center (s.f.):
Open Services for Lifecycle Collaboration (OSLC) es una comunidad que está
estandarizando el modo en que interactúan las herramientas de ciclo de vida. IBM®
Rational Quality Manager soporta la especificación de compartición de datos OSLC
como proveedor de dominio de Gestión de calidad y como consumidor de otros
dominios en el portafolio de Rational.
La compartición de datos OSLC entre dominios se basa en un conjunto común de
recursos, formatos y servicios arquitecturales REST.
La compartición de datos soporta estas transacciones:
Creación de enlaces basada en el protocolo HTTP.
Identificación de recursos por URI.
Recuperación de información que utiliza tipos de soporte estándares en el sector.
(Recuperado de https://ibm.co/2GUTysd).
BPM.
Definición de Garimella, Lees, & Williams (2008):
Business Process Management (BPM) es un conjunto de métodos, herramientas y
tecnologías utilizados para diseñar, representar, analizar y controlar procesos de
negocio operacionales. BPM es un enfoque centrado en los procesos para mejorar el
rendimiento que combina las tecnologías de la información con metodologías de
proceso y gobierno. BPM es una colaboración entre personas de negocio y
tecnólogos para fomentar procesos de negocio efectivos, ágiles y transparentes.
Efectividad de los procesos.
BPM asume el paradigma de gestión de las actividades empresariales a través de un
entorno de procesos operacionales. El término procesos de negocio puede sonar
poco claro, pero no se equivoque; es un término preciso.
12
Un proceso de negocio es el conjunto de todas las tareas y actividades
coordinadas formalmente, dirigidas tanto por personas como por equipos, que lleva a
conseguir un objetivo organizativo específico. Un ejemplo de proceso de negocio es
cumplimentar un pedido. El acto del cliente solicitando un producto inicia un proceso
para registrar el pedido, aprobar su crédito y desencadenar la producción y entrega.
BPM se esfuerza en maximizar la efectividad de los procesos de negocio de las
siguientes maneras:
Determina el proceso óptimo para las condiciones actuales.
Hace funcionar el proceso tan efectivamente como sea posible.
Posibilita decisiones y controles en busca de la eficiencia continua.
Transparencia de los procesos.
Con BPM, puede visualizar de forma directa todos los elementos del diseño de los
procesos como el modelo, flujo de trabajo, reglas, sistemas y participantes, así como
su rendimiento en tiempo real, incluyendo eventos y tendencias. Permite a las
personas de negocios gestionar de forma directa la estructura y flujo de los procesos y
realizar el seguimiento de los resultados, así como de las causas.
Agilidad en los procesos.
BPM proporciona agilidad en los procesos al minimizar el tiempo y el esfuerzo
necesarios para traducir necesidades e ideas empresariales en acción. Permite a las
personas de negocios definir procesos de forma rápida y precisa a través de los
modelos de proceso. Les posibilita realizar análisis de futuro en escenarios
empresariales. Les otorga derecho para configurar, personalizar y cambiar flujos de
transacciones modificando las reglas de negocio. Directamente convierte diseños de
procesos en ejecución, integrando sistemas y construyendo aplicaciones sin
necesidad de código y sin fisuras.
Motores de Negocio BPM.
Cuatro motores de negocio fundamentales motivan la adopción de BPM.
Mejora de un proceso o subproceso: las compañías implementan BPM como una
forma de mejorar determinados procesos. Normalmente, no se trata de entornos de
procesos completos o cadenas de valor, sino subprocesos dentro de una cadena de
13
valor. En estos casos, BPM ofrece una solución más rápida. Esto sirve también como
experiencia piloto con BPM.
BPM(S) para CPI (Continuous Process Improvement): debido a la relación
sinérgica entre BPM y las metodologías para la mejora continua de los procesos como
Lean, Six Sigma, SCOR, TQM y otras, muchas compañías que se han embarcado en
una iniciativa CPI implementan BPMS como tecnología complementaria y habilitadora
de su programa CPI.
BPM para SOA: muchas organizaciones de TI han adoptado arquitecturas
orientadas a servicios (SOA) y están descubriendo servicios para la integración de la
próxima generación. BPM aprovecha directamente las SOA y, junto con la
combinación de la Suite BPM, constituye un sistema de mayor valor.
Transformación de negocio: BPM, como combinación de tecnología BPM y
métodos CPI, representa el entorno más completo, extenso y holístico para
representar la transformación empresarial estratégica.
Gestión de proyectos de BPM.
Un proyecto BPM es un nuevo tipo de proyecto empresarial. Es en parte proceso y en
parte tecnología. A veces es un proyecto de mejora, y a veces un completo rediseño.
El alcance puede ser tan corto como un único proceso o tan largo como un flujo
entero de valor. Un proyecto BPM es rápido, pero no impreciso. A diferencia de un
programa empresarial o un proyecto de desarrollo de software típico, los proyectos
BPM se implementan de forma frecuente, en cortos ciclos de tiempo.
Gestión de procesos.
Una vez que un proceso se realiza conforme a las especificaciones, su objetivo es
mantenerlo ahí indefinidamente (hasta que la siguiente mejora quede justificada).
Bank of America declaró una vez de forma célebre que su objetivo no era completar
un millón de transacciones con éxito, sino completar una sola transacción con éxito, y
luego repetirla un millón de veces. Eso es gestión de procesos.
Una vez implementado, un modelo de proceso se orquesta mediante un motor en
tiempo de ejecución, que facilita la ejecución coherente y oportuna de los servicios y
proporciona la transformación de valor añadido de entradas e información en salidas y
14
resultados. El rendimiento del proceso se mide en tiempo real y el proceso
implementado es objeto de supervisión para ver si el rendimiento se ajusta a las
especificaciones. Se realiza el seguimiento y se registran el volumen, la velocidad y
los errores.
Mejora de los procesos.
Todos los procesos se degradan con el tiempo. Al final, se desgastan y se rompen, y
otras variaciones comunes y por diversas causas, se llevan lo mejor de ellos. En otros
casos, surgen nuevas necesidades empresariales o nuevas tecnologías. Incluso un
proceso que se ejecute perfectamente un millón de veces al día puede quedar
obsoleto.
Metodologías de mejora de los procesos, como Lean y Six Sigma, pueden corregir
los defectos en los procesos y al mismo tiempo mejorar su efectividad. Los métodos
CPI son una parte esencial de BPM (p.1-37).
15
Desarrollo del Proyecto
Breve resumen.
El servicio de Automatización de los Procesos de Aseguramiento de la Calidad de la
Sección Calidad de Soluciones del Banco de la Nación basados en la NTP 12207, estuvo
soportado con la herramienta de gestión de cambio IBM Rational ClearQuest y con la suite
de herramientas de pruebas, tales como IBM Rational Quality Manager, IBM Rational
Functional Tester, IBM Rational Performance Tester e IBM Rational Appscan, para su
implementación.
Metodología.
La Metodología BPM fue la empleada para el desarrollo del proyecto basada en el ciclo de
vida BPM, el cual inicia por la identificación, modelamiento y análisis del proceso actual,
luego se da a conocer el modelamiento del proceso mejorado, para que posterior a la
validación y aceptación de este, se implemente, ejecute y finalmente se monitoree para
poder encontrar oportunidades de mejora continua (Becker & Roremann, 2001).
Figura 4. Ciclo de vida BPM (Becker & Roremann, 2001).
16
Georgakopoulo et al (1995), manifestaron en su publicación de “Una visión general de la
gestión del flujo de trabajo: Del modelado de procesos a la infraestructura de
automatización de flujo de trabajo” que:
Las empresas comerciales de hoy en día deben lidiar con la competencia global,
reducir el costo de hacer negocios y desarrollar rápidamente nuevos servicios y
productos. Para abordar estos requisitos, las empresas deben reconsiderar y optimizar
constantemente la forma en que hacen negocios y en que cambien sus sistemas de
información y aplicaciones para respaldar los procesos evolutivos de negocio. La
tecnología de flujo de trabajo facilita esto proporcionando metodologías y software para
dar soporte a (i) los modelamientos de procesos de negocio para capturar procesos de
negocio como especificaciones de flujo de trabajo, (ii) reingeniería de procesos de
negocio para optimizar procesos específicos y (iii) automatización de flujo de trabajo
para generar implementaciones de flujo de trabajo a partir de especificaciones de flujo
de trabajo (p.119-153).
Dentro de los 3 tipos de herramientas que se pueden utilizar para automatizar los
modelos de procesos, se optó por la del motor de procesos, en el cual se configuran los
procesos de la organización de manera rápida por lo que su mantenimiento y actualización
es fácil. El motor de procesos interpreta las actividades, roles y reglas de negocio para que
sean aplicadas según el modelo definido. No requiere de una alta especialización técnica
para su implementación, por lo que al requerir modificaciones podrían ser realizadas por el
personal del área de procesos. El uso de IBM Rational ClearQuest además de ser una de
las exigencias dadas para la implementación de los procesos automatizados, calzaba con el
tipo de motor de procesos y además se encontraba como uno de los productos líderes en el
mercado como se aprecia en la Figura 5.
Figura 5. Magic Quadrant for Intelligent Business Process Management Suites (Gartner,
2015)
17
Roles y responsabilidades.
Los roles participantes por parte del cliente fueron:
Líder del proyecto. Tuvo como responsabilidades:
Evaluar las presentaciones de avance del proyecto.
Evaluar el cumplimiento de los hitos del proyecto.
Recibir y evaluar las solicitudes de cambio.
Tomar decisiones de alto nivel del proyecto.
Comité de seguimiento. Tuvo como responsabilidades:
Apoyar al equipo de trabajo con el cumplimiento de reuniones.
Exigir al equipo de trabajo el cumplimiento de hitos del proyecto.
Coordinar reuniones periódicas de seguimiento del avance del proyecto.
Validar los entregables del proyecto.
Analista de calidad. Tuvo como responsabilidades:
Brindar información de los procesos de la Sección de Calidad de Soluciones
Recibir el conocimiento del uso de las herramientas de gestión y ejecución de
pruebas.
Validar los nuevos procesos para la Sección de Calidad de Soluciones.
Los roles participantes por parte de la consultora fueron:
Gestor de proyecto. Tuvo como responsabilidades:
Desarrollar el Plan de Gestión del Proyecto
Realizar las presentaciones de avance del proyecto.
Cumplir con los hitos del proyecto.
Coordinar las actividades del equipo de trabajo.
Especialista en procesos. Tuvo como responsabilidades:
Evaluar los procesos actuales de la Sección de Calidad de Soluciones.
Elaborar nuevo modelo de los procesos de la Sección de Calidad de Soluciones.
Cumplir con el alineamiento de los procesos a la NTP 12207.
Capacitar en la adopción de los procesos modelados.
18
Líder técnico del proyecto. Tuvo como responsabilidades:
Diseñar la topología de la solución.
Implementar la arquitectura propuesta.
Configurar los Workflows propuestos.
Brindar capacitación en el uso de la solución.
Cabe mencionar que el equipo por parte de la consultora estuvo integrado por 3
personas. Yo fui el gestor de proyecto, pero también ejercí el rol de especialista en procesos
y de líder técnico, las otras 2 personas ejercieron los roles de especialista de procesos y
técnicos.
Seguimiento y control.
Se definió para el proyecto 3 etapas para su desarrollo, las cuales fueron secuenciales y
mandatorios respecto a su predecesor, es decir, no se podía iniciar la siguiente etapa si no
se tenía la conformidad respectiva de la etapa en ejecución:
Etapa 1: Conceptualización del nuevo modelo de Procesos de la Sección Calidad de
Soluciones.
Etapa 2: Implementación de los Procesos a través de Flujos de Trabajo Automatizados.
Etapa 3: Capacitación y Acompañamiento.
Se creó una matriz de riesgos para anticipar imprevistos, plantear acciones de
mitigación, saber el posible impacto y la probabilidad de su ocurrencia.
Durante la ejecución del proyecto se fue alimentando una matriz de lecciones aprendidas
que quedó como aporte para la consultora.
El proyecto que inicialmente debía tener una duración máxima de 120 días y terminar el
03 de septiembre, se prolongó hasta el 20 de noviembre debido a que el personal asignado
al comité de seguimiento tuvo carga laboral no contemplada por atenciones de pruebas
críticas, y además por haber tenido una ampliación en el alcance del proyecto para cubrir el
modelamiento y automatización del proceso de gestión de defectos.
19
Reuniones de seguimiento.
En coordinación con el comité de seguimiento se propuso tener 1 reunión por semana para
validar el avance según lo indicado en cronograma y por cada fin de reunión se exponían
los acuerdos u observaciones en actas de reunión.
Cada cumplimiento de hito según cronograma quedaba plasmado en actas de
aceptación.
Procesos automatizados.
Certificación de producto.
Fue el proceso principal que se automatizó, debido a que cubrió todas las instancias en las
que se incurren para lograr la certificación de producto software o hardware.
Figura 6. Flujo de trabajo del Proceso de Certificación de Producto (Elaboración propia).
20
Figura 7. Diagrama de Estados del Proceso de Certificación de Producto (Elaboración
propia).
El esfuerzo se centró en remodelar todos los flujos de trabajo y redefinir el procedimiento
total, para luego automatizarlo en la herramienta IBM Rational ClearQuest integrado con
IBM Quality Manager para la gestión de artefactos de prueba.
Para el subproceso de Planificación, el problema principal fue la no visibilidad de
proyectos / mantenimientos que venían de la subgerencia de Desarrollo ya que el proceso
de ciclo de vida del software no contemplaba la participación de la sección Calidad de
Soluciones desde un inicio, sino cuando Desarrollo culminaba con sus entregables. Por lo
que se propuso involucrar a la etapa de Planificación de Pruebas a que iniciara desde la
planificación de actividades de Desarrollo, para saber anticipadamente la carga de
atenciones que se iba a tener en un futuro, además de poder plantear objetivamente la
estrategia de pruebas y esfuerzo que conllevaría, por lo que daba la posibilidad de crear
actividades requeridas a ser atendidas por cada etapa posterior de Revisión, Diseño de
Pruebas, Despliegue y Ejecución de Pruebas.
21
Figura 8. Flujo de trabajo del Sub-Proceso Planificación (Elaboración propia).
El subproceso de Revisión inicia luego de que se promovieran los cambios de Desarrollo
a Certificación. Durante la revisión de documentación, daba la posibilidad de generar
defectos y además a solicitud del Comité de Seguimiento, se nos indicó que dentro del flujo
se permitiera continuar a la siguiente etapa a pesar de que existieran defectos abiertos.
Figura 9. Flujo de trabajo del Sub-Proceso Revisión (Elaboración propia).
22
El subproceso de Preparación dio la posibilidad de incluir tanto actividades para las
etapas de Diseño de Pruebas como de Despliegue, ya que podían ejecutarse en paralelo.
La etapa de Diseño de Pruebas era nueva para la Sección Calidad de Soluciones,
debido a que los Analistas de Calidad no diseñaban los casos de prueba, sino los
Desarrolladores. Se les dio la posibilidad de crear casos de prueba, suites de prueba y
scripts de prueba, todos asociados a un plan de pruebas definido durante la etapa de
Planificación.
Figura 10. Flujo de trabajo del Sub-Proceso Diseño de Pruebas (Elaboración propia).
La etapa de Despliegue incluía validaciones de documentos de despliegue, y del
resultado de este, por lo que si no fueran exitosos podrían generarse defectos y a diferencia
de la etapa de Revisión, al existir defectos abiertos imposibilita el continuar con la siguiente
etapa; así como la de asignar actividades a otras áreas de soporte como la de
Infraestructura o Seguridad Informática para la realización del despliegue.
23
Figura 11. Flujo de trabajo del Sub-Proceso Despliegue (Elaboración propia).
El subproceso de Ejecución de Pruebas dio la posibilidad de ejecutar casos de prueba
como también suites de prueba, evaluar los resultados y dependiendo de los mismos
generar defectos o certificar el caso / suite ejecutado. Todos los artefactos de pruebas
mencionados también se relacionan al Plan de Pruebas. A solicitud del Comité de
Seguimiento, se nos solicitó que las pruebas de aceptación (ya sea de usuario, operativa,
contractual o normativa) siempre fueran ejecutadas luego de haberse certificado todos los
demás casos / suites de pruebas asignadas.
24
Figura 12. Flujo de trabajo del Sub-Proceso Ejecución de Pruebas (Elaboración propia).
El subproceso de Seguimiento y Control dio la posibilidad de definir o redefinir los
criterios de evaluación de progreso, definir informes y definir controles de prueba. Dichos
controles son ejecutados dentro de las herramientas de soporte IBM Rational ClearQuest e
IBM Rational Quality Manager de manera automática.
25
Figura 13. Flujo de trabajo del Sub-Proceso Seguimiento y Control de Pruebas
(Elaboración propia).
El subproceso de Devolución dio la posibilidad de evidenciar la devolución de los
operadores de Producción a Certificación por algún tipo de observación y dependiendo de la
magnitud de la observación podría subsanarse y certificar el producto o rechazarlo
completamente.
Figura 14. Flujo de trabajo del Sub-Proceso Devolución (Elaboración propia).
Actividad.
Para poder reflejar los responsables, tiempos incurridos y estados de las actividades
registradas por cada etapa de pruebas, se creó y automatizó también un flujo de trabajo. En
donde el gestor de pruebas es el responsable del registro y validación de cumplimiento, y
los analistas revisores, diseñadores de pruebas, gestores de entorno y testers serían los
responsables de la ejecución de las actividades.
26
Figura 15. Flujo de trabajo de Actividad de Certificación (Elaboración propia).
Figura 16. Diagrama de estados de la Actividad de Certificación (Elaboración propia).
Gestión de proyectos y mantenimientos.
Es el principal proceso de la Gerencia de Informática, dado que involucra a varios roles de
las Sub Gerencias de Desarrollo de Sistemas, Aseguramiento de la Calidad, Infraestructura
y Comunicaciones, y Operaciones TI y está automatizado íntegramente en IBM Rational
ClearQuest.
27
El cambio puntual que se realizó fue la de excluir las actividades relacionadas a la
Sección Calidad de Soluciones dado que se verían con mayor detalle en el proceso de
Certificación de Producto, y en su lugar sólo referenciar los momentos específicos en que
se integran ambos procesos.
El caso del registro del Servicio de Certificación se exige durante la planificación de
actividades de Desarrollo y luego cuando culminan, el estado del proyecto / mantenimiento
queda con el estado “En Certificación” y el resto de la gestión de certificación lo realiza el
proceso de Certificación de Producto. Finalmente, si el proceso de Certificación de Producto
culmina como “Certificado”, el proyecto / mantenimiento también se actualiza como
“Certificado”, en caso contrario queda como “Rechazado”.
Figura 17. Fragmento del flujo de trabajo de Gestión de Mantenimientos (QBAN Consulting,
2008).
Gestión de defectos.
Se tomó como base la definición de Defecto obtenida de la IEEE Standard Classification for
Software Anomalies, en donde se le define como “la imperfección o deficiencia en un
producto, en donde no llega a cumplir con sus requerimientos o especificaciones, y que
necesita ser reparado o reemplazado” (Software & Systems Engineering Committee, 2010).
28
Dentro de los atributos más resaltantes definidos para el formulario del Defecto se puede
mencionar al tipo, motivo, resolución, efecto, modo y actividad de inserción. Las siguientes
figuras del 18 al 22 son fragmentos del documento “QBC–BN–MOD–001
Prototipos_Gestión_de_Defectos_ADS Nº 0001-2015-BN” en donde fueron definidos los
atributos.
Figura 18. Definición de Tipo y Motivo de Defectos (Elaboración propia).
Figura 19. Definición de Resolución de Defectos (Elaboración propia).
29
Figura 20. Definición de Efecto de Defectos (Elaboración propia).
Figura 21. Definición de Modo de Defectos (Elaboración propia).
Figura 22. Definición de Actividad de Inserción de Defectos (Elaboración propia).
30
Se definió un workflow personalizado que cubría varias casuísticas planteadas por el
Comité de Seguimiento para el registro y atención de defectos.
Se dio la posibilidad de que el proceso pudiera ser iniciado desde el entorno de IBM
Rational ClearQuest para generación de defectos ajenos a una ejecución de pruebas y
también que pudiera ser iniciado desde el entorno de IBM Rational Quality Manager durante
la ejecución de un caso de pruebas, en donde el defecto incluía información como el detalle
de los pasos ejecutados e indicaba el paso en donde no cumplió con el resultado esperado,
así como tener adicionado vínculos (links) del resultado de ejecución, caso de prueba y plan
de prueba, enriqueciendo de información al Desarrollador que fuera a atender el defecto
que se le asignara.
Figura 23. Diagrama de Estados del Proceso de Gestión de Defectos (Elaboración propia).
31
Figura 24. Flujo de trabajo del Proceso de Gestión de Defectos (Elaboración propia).
Gestión de incidentes.
Sólo requerían tener la capacidad de registrar incidentes que podían ocurrir durante la
certificación de un producto, dado que muchos de estos incidentes podían impactar en el
cumplimiento de fechas planificadas y de esta forma guardar una bitácora de incidentes
32
como sustento del cambio de fechas. La gestión de incidentes sólo contuvo dos estados de
atención “Registrado” y “Cerrado”.
Implementación de IBM Rational Quality Manager.
Despliegue de la solución.
La solución fue desplegada en 1 servidor virtual de aplicación y 1 servidor virtual de base de
datos. Dentro del servidor de aplicación se instaló el WebSphere Application Server, el Jazz
Team Server (plataforma de la solución colaborativa), IBM Rational Quality Manager y el
servidor de licencias flotantes. Dentro del servidor de base de datos se crearon 3 bases de
datos, 1 para el Jazz Team Server, 1 para IBM Rational Quality Manager y 1 para el Data
Warehouse.
Figura 25. Diagrama de despliegue de IBM Rational Quality Manager (Elaboración propia).
El diagrama de despliegue forma parte del manual de instalación y configuración de Jazz
que fue parte de los entregables del proyecto, el cual va desde la instalación y configuración
33
de las aplicaciones, creación de las bases de datos, hasta la configuración para la
comunicación entre el servidor de IBM Rational Quality Manager con el servidor de IBM
Rational ClearQuest mediante OSLC Links.
Personalización de los artefactos de prueba.
Las plantillas de los artefactos de prueba que fueron personalizadas en IBM Quality
Manager fueron: plan de pruebas, caso de pruebas y suite de pruebas. El objetivo era, no
sólo cubrir el contenido de sus plantillas vigentes que tenían en MS Word, sino
enriquecerlas con información relevante y actualizada sobre las pruebas que se pudieran
tener en curso de manera automática, como por ejemplo tener dentro del plan de prueba los
resultados de la ejecución de los casos de prueba.
Figura 26. Plantilla de plan de pruebas (Elaboración propia).
Figura 27. Plantilla de caso de pruebas (Elaboración propia).
34
Figura 28. Plantilla de suite de pruebas (Elaboración propia).
La conformidad de la personalización de las plantillas de los artefactos de prueba por
parte del comité de seguimiento se vio reflejada en las actas de aceptación.
Integración con herramientas.
IBM Rational Quality Manager tiene la capacidad de integrarse con herramientas de
pruebas, como IBM Rational Functional Tester para la realización de pruebas
automatizadas y con IBM Rational Performance Tester para la realización de pruebas de
rendimiento, mediante un adaptador integrado en las mismas herramientas. La
configuración de los adaptadores y la vinculación de los scripts generados en ambas
herramientas para ser ejecutados desde IBM Rational Quality Manager se encuentra en el
manual de usuario que fue parte de los entregables del proyecto.
Figura 29. Adaptador de IBM Rational Functional Tester (Elaboración propia).
35
Figura 30. Adaptador de IBM Rational Performance Tester.
Secuencia de pasos por proceso.
La secuencia de pasos fue agrupada por etapa y escenarios en el caso del proceso de
certificación de producto, en el caso del proceso de gestión de defectos sólo por escenarios,
y en el caso del proceso de gestión de incidencia sólo constó de 3 pasos dado que sólo tuvo
2 estados.
Dentro de la secuencia de pasos se detallan las acciones realizadas por rol de acuerdo a
la etapa y su interacción con cada herramienta. El detalle se encuentra en el manual de
usuario que fue parte de los entregables del proyecto.
36
Figura 31. Fragmento del manual de usuario (Elaboración propia).
Análisis y Resultados
Impacto del nuevo proceso de certificación sobre el de gestión de desarrollos.
En relación con las atenciones de Certificación de Software dentro del proceso de Gestión
de Proyectos y Mantenimientos, se tuvo la precaución de que el nuevo proceso de
Certificación de Producto no perjudicara al seguimiento y control de los Proyectos y
Mantenimientos que ya se tenían en curso.
Para poder evidenciar esto, se tomaron 2 muestras de desarrollos en estado “procesado”
(estado final de un pase a producción). La primera va desde enero del 2010 hasta el 16 de
marzo del 2016, y la segunda va del 17 de marzo del 2016 al 01 de diciembre del 2017.
37
Tabla 1
Tiempo promedio de la certificación en días por año del 01/01/2010 al 16/03/2016.
Año Cantidad de Desarrollos Tiempo Promedio de la Certificación en Días
2010 807 7.5
Mantenimiento 798 7.1
Proyecto 9 34.4
2011 688 11.2
Mantenimiento 680 10.6
Proyecto 8 62.0
2012 527 10.8
Mantenimiento 520 10.6
Proyecto 7 29.3
2013 491 10.2
Mantenimiento 480 9.3
Proyecto 11 47.3
2014 521 8.4
Mantenimiento 514 8.3
Proyecto 7 20.7
2015 421 11.7
Mantenimiento 412 11.6
Proyecto 9 17.8
2016 88 8.0
Mantenimiento 86 8.1
Proyecto 2 6.5
Total 3543 9.7
Nota: Datos obtenidos anteriores a la implementación (Elaboración propia).
Tabla 2
Tiempo promedio de la certificación en días por año del 17/03/2016 al 01/12/2017.
Año Cantidad de Desarrollos Tiempo Promedio de la Certificación en Días
2016 182 12.8
Mantenimiento 177 12.8
Proyecto 5 12.2
2017 447 7.6
Mantenimiento 440 7.5
Proyecto 7 9.3
Total 629 9.1
Nota: Datos obtenidos posteriores a la implementación (Elaboración propia).
Se demuestra que se continuaron registrando los proyectos y mantenimientos de manera
regular posterior a la implementación del proceso de Certificación de Producto y
adicionalmente que se tuvo una reducción de 59% en el tiempo promedio de certificación
entre el 2016 y el 2017.
38
Atención de servicios de certificación.
Al tener un flujo de trabajo automatizado para el Servicio de Certificación se pudo obtener
un mayor control sobre las peticiones solicitadas a la Sección Calidad de Soluciones, así
como saber el estatus en tiempo real de las mismas.
La siguiente muestra evidencia el tiempo promedio incurrido por cada etapa de la
certificación del producto en días, del 17 de marzo del 2016 al 01 de diciembre del 2017.
Tabla 3
Tiempo promedio por etapa de la certificación en días por año del 17/03/2016 al 01/12/2017.
Año Atención Total Planificación Revisión Preparación Ejecución
2016 12.1 0.1 4.8 5.7 0.1
Marzo 12.8 0.0 4.2 5.8 0.2
Abril 14.5 0.2 5.0 8.6 0.0
Mayo 14.4 0.4 5.7 5.7 0.0
Junio 12.1 0.0 5.5 6.3 0.0
Julio 12.4 0.0 6.7 4.0 0.0
Agosto 13.6 0.0 4.8 7.4 0.0
Setiembre 11.8 0.1 5.4 4.7 0.0
Octubre 12.9 0.0 4.8 5.8 0.0
Noviembre 8.4 0.0 3.4 4.1 0.0
Diciembre 9.4 0.0 4.0 4.2 0.3
2017 7.0 0.1 1.9 3.1 1.8
Enero 7.9 0.2 4.3 2.7 0.3
Febrero 5.4 0.0 2.3 2.7 0.0
Marzo 6.6 0.1 2.7 3.2 0.5
Abril 5.5 0.1 2.3 2.4 0.2
Mayo 6.1 0.3 1.8 2.9 1.3
Junio 7.9 0.1 1.1 3.7 3.1
Julio 7.8 0.0 0.9 3.4 3.5
Agosto 8.3 0.1 1.3 3.7 3.3
Setiembre 6.6 0.0 0.7 3.0 2.9
Octubre 7.5 0.0 1.7 3.7 2.1
Noviembre 5.7 0.0 1.2 2.6 1.9
Diciembre 2.2 0.0 0.2 1.0 1.0
Total 8.7 0.1 2.9 4.0 1.2 Nota: Datos obtenidos posteriores a la implementación (Elaboración propia).
Se pudo identificar que el mayor tiempo incurrido en ambos años se da en la etapa de
preparación teniendo un tiempo promedio de 5.7 días durante el 2016 y 3.1 días durante el
2017, dicha etapa contempla el diseño de pruebas e instalación como actividades en
39
paralelo. Así mismo, la segunda etapa que incurre en mayor tiempo es la de revisión con
4.8 días durante el 2016 y 1.9 días durante el 2017. Cabe decir que para ambas etapas se
tuvo una reducción del 54% y 39.5% respectivamente por año. En relación con el tiempo de
planificación no se tuvo diferencia considerable entre ambos años, sin embargo, para la
etapa de ejecución se tuvo un aumento del 180% esto debido a que se identificó que los
Tester no estaban realizando el cambio de estado oportunamente para el inicio de la
ejecución en la herramienta y sólo lo registraban al terminarla, es por ello que los tiempos
de inicio y fin de ejecución en la herramienta eran casi el mismo, y la corrección aplicada se
dio a fines del 2016. Finalmente, el tiempo promedio de atención total del 2016 fue de 12.1
días y del 2017 fue de 7 días, teniendo una reducción del 57.8% en relación con el año
anterior.
Además de poder crear consultas personalizadas en IBM Rational ClearQuest sobre las
atenciones de los Servicios de Certificación, tiene la capacidad de poder exportarlas a Excel
para la generación de tablas dinámicas (como las evidencias mostradas anteriormente) o
gráficos más sofisticados que fueran requeridos como los siguientes.
Figura 32. Servicios de certificación atendidos durante el 2016 (Elaboración propia).
0
10
20
30
40
50
10 1018
10 7 71 6 7 4
20 17
1826
20
41
18
3138
18
Servicios Certificados y Rechazados por Mes Durante el 2016
Certificado
Rechazado
40
Figura 33. Servicios de certificación atendidos durante el 2017 (Elaboración propia).
Figura 34. Servicios de Certificación atendidos por Gestor de Pruebas durante el 2016
(Elaboración propia).
Figura 35. Servicios de Certificación atendidos por Gestor de Pruebas durante el 2017
(Elaboración propia).
0
10
20
30
40
50
60
70
6 5 7 8 9 14 7 11 8 5 6
53
35
5838 39
5348
54
3759
45
Servicios Certificados y Rechazados por Mes Durante el 2017
Certificado
Rechazado
23 12 11 1 1 2 2
209
64
1 10
50100150200250
Cer
tifi
cad
o
Re
chaz
ado
Cer
tifi
cad
o
Re
chaz
ado
Cer
tifi
cad
o
Cer
tifi
cad
o
Re
chaz
ado
Cer
tifi
cad
o
Re
chaz
ado
Cer
tifi
cad
o
Re
chaz
ado
ecangalaya eperez jpeña kpoma mdavila mnicho
2016
Servicios Certificados y Rechazados por Gestor de Pruebas Durante el 2016
147
20 3 1 21 1
194
33
102
2752
40
50100150200250
Cer
tifi
cad
o
Re
chaz
ado
Cer
tifi
cad
o
Re
chaz
ado
Cer
tifi
cad
o
Re
chaz
ado
Cer
tifi
cad
o
Re
chaz
ado
Cer
tifi
cad
o
Re
chaz
ado
Cer
tifi
cad
o
Re
chaz
ado
eperez jpeña kpoma mdavila mhilario mnicho
2017
Servicios Certificados y Rechazados por Gestor de Pruebas Durante el 2017
41
IBM Rational ClearQuest también puede generar gráficos de barras, de tendencias o de
antigüedad en el que se demuestra la inactividad de registros al no haber tenido cambios de
estado en un periodo de tiempo.
Figura 36. Servicios de certificación no actualizados del 2017 (Elaboración propia).
En la Figura 36, se visualizan la cantidad de Servicios de Certificación que no han sido
actualizados desde hace unos meses atrás, teniendo como referencia de la muestra
registros tomados al 01 de diciembre del 2016, que va de antigüedad de 0 a 1mes, 1 a 2
meses y así consecutivamente hasta llegar de 11 meses a más. En este caso se presentan
Servicios de Certificación cuyo estado no ha cambiado entre 1 y 2 meses de antigüedad,
teniendo 1 “Revisión Iniciada”, 2 en “Ejecución con Defectos”, 10 en “Ejecución Iniciada” y
11 en “Preparación Iniciada”, además de presentarse un Servicio cuyo estado no ha sido
actualizado hace más de 10 meses y se encuentra en estado “Planificación Terminada”.
Atención de defectos.
Al tener un flujo de trabajo automatizado para la Gestión de Defectos, se pudo evidenciar
todas las interacciones ocurridas entre el tester que registra y valida el defecto y los
desarrolladores quienes los atienden y sobre todo en tiempo real.
42
Tabla 4
Extracto de listado de defectos generados por servicios de certificación.
Desarrollos Servicios de Certificación
Defectos
2017-P0553 3
2017-S0564 3
2017-P0541 3
2017-S0553 3
2017-P0218 10
2017-S0192 3
2017-D000588 1
2017-D000589 1 2017-D000628 1
2017-S0334 7
2017-D000535 1
2017-D000536 1
2017-D000537 1
2017-D000587 1
2017-D000602 1
2017-D000621 1
2017-D000644 1
Nota: Datos obtenidos posteriores a la implementación (Elaboración propia).
En la Tabla 4, se puede ver un extracto de la cantidad de Defectos generados por
Servicio y su relación con los Desarrollos. Por ejemplo, se evidencia la relación de padre –
hijo entre el proyecto 2017-P0218 y los servicios de Certificación 2017-S0192 y 2017-
S0334. Lo mismo ocurre con los defectos generados por cada servicio de Certificación, por
ejemplo, el servicio 2017-S0192 tiene relacionado como hijos a los defectos 2017-D000588,
2017-D000589 y 2017-D000628.
Así mismo mediante la consulta exportada a Excel, se pudo obtener información sobre la
cantidad de defectos registrados por tipo de defecto, los motivos más recurrentes por tipo
de defecto, los efectos más recurrentes por defecto y la actividad de inserción más
recurrente por defecto.
Las figuras del 37 al 41 corresponden a defectos registrados durante el 2016.
43
Figura 37. Defectos registrados por tipo durante el 2016 (Elaboración propia).
Figura 38. Motivos por tipo de Defecto “Datos” en el 2016 (Elaboración propia).
Figura 39. Efectos más recurrentes por Defecto en el 2016 (Elaboración propia).
450
6 6
85 88
0
50
100
150
200
250
300
350
400
450
500
Datos Descripción Estándares Interface Lógica
2016
Defectos por Tipo Durante el 2016
129
1
195
7
108
10
0
50
100
150
200
250
Documentofaltante /incorrecto
Relación decardinalidadincorrecta en
modelo dedatos
Tipo de datoincorrecto
Uso denombre de
variableincorrecta
Valor faltante/ incorrecto
Variables convalor inicial no
asignado
Datos
2016
Motivos más Recurrentes por Tipo de Defecto "Datos" en el 2016
3 38
506
1 1275
0100200300400500600
Capacidad deServicio
Estándares Funcionalidad Rendimiento Seguridad Usabilidad
2016
Efectos más Recurrentes por Defectos en el 2016
44
Figura 40. Modos de ocurrencia por Defecto en el 2016 (Elaboración propia).
Figura 41. Actividad de Inserción más recurrente por Defecto en el 2016 (Elaboración
propia).
Las figuras del 42 al 46 corresponden a defectos registrados durante el 2017.
Figura 42. Defectos registrados por tipo durante el 2017 (Elaboración propia).
95
531
90
100200300400500600
Ausente Errado Extra
2016
Modos de Ocurrencia por Defecto en el 2016
113
10 8
274
42
0
50
100
150
200
250
300
Codificación Configuración Diseño Documentación Requerimiento
2016
Actividad de Inserción más Recurrente por Defecto en el 2016
567
1437
154
85
20
100
200
300
400
500
600
Datos Descripción Estándares Interface Lógica Sintaxis
2017
Defectos por Tipo Durante el 2017
45
Figura 43. Motivos por tipo de Defecto “Datos” en el 2017 (Elaboración propia).
Figura 44. Efectos más recurrentes por Defecto en el 2017 (Elaboración propia).
Figura 45. Modos de ocurrencia por Defecto en el 2017 (Elaboración propia).
168 166
13
203
17
0
50
100
150
200
250
Documentofaltante /incorrecto
Tipo de datoincorrecto
Uso de nombrede variableincorrecta
Valor faltante /incorrecto
Variables convalor inicial no
asignado
Datos
2017
Motivos más Recurrentes por Tipo de Defecto "Datos" en el 2017
4
99
615
6 8
127
0
100
200
300
400
500
600
700
Capacidad deServicio
Estándares Funcionalidad Rendimiento Seguridad Usabilidad
2017
Efectos más Recurrentes por Defectos en el 2017
179
662
18
0100200300400500600700
Ausente Errado Extra
2017
Modos de Ocurrencia por Defecto en el 2017
46
Figura 46. Actividad de Inserción más recurrente por Defecto en el 2017 (Elaboración
propia).
La información mostrada en los gráficos permite evidenciar las debilidades más
resaltantes que padecen los equipos de Desarrollo y que fue constante para ambos años
2016 y 2017, por ejemplo, el tipo de defecto recurrente fue “Datos”, el efecto más
impactante de los fallos encontrados fue en “Funcionalidad”, el modo de ocurrencia más
reiterado fue “Errado”, y la actividad de desarrollo en la que se insertaron más defectos fue
en “Documentación”.
Para dar a conocer los motivos más recurrentes por tipo de defecto registrados durante
el 2017, sólo se tuvo que exportar la consulta para luego crear una tabla dinámica. De esta
forma se evidenció en la Tabla 5 que la mayor cantidad de defectos fue del tipo “Datos”, su
motivo más recurrente fue “valor faltante / incorrecto” al haberse registrado 203 defectos;
para el tipo de defecto “interface” el motivo más recurrente fue “diseño de interfaz de
módulo o implementación incorrecta” al haberse registrado 88 defectos; y para el tipo de
defecto “lógica” el motivo más recurrente fue “secuencia de operaciones incorrecta” al
haberse registrado 25 defectos.
223
95
17
324
116
0
50
100
150
200
250
300
350
Codificación Configuración Diseño Documentación Requerimiento
2017
Actividad de Inserción más Recurrente por Defecto en el 2017
47
Tabla 5
Listado de defectos por tipo y motivo registrados durante el 2017.
Tipos de Defecto Motivos
Defectos
Datos 567
Documento faltante / incorrecto 168
Tipo de dato incorrecto 166
Uso de nombre de variable incorrecta 13
Valor faltante / incorrecto 203
Variables con valor inicial no asignado 17
Descripción 14
Definición o descripción del artefacto no guardar relación con el contenido 14
Estándares 37
No cumple con el estándar del departamento de informática 37
Interfaz 154
Diseño de interfaz de módulo o implementación incorrecta 88
Diseño del reporte incorrecto 8
Mensaje incorrecto o incompleto enviado o mostrado 21
Omisión de un campo de entrada requerido en la pantalla de ingreso de datos 9
Parámetros insuficientes o incorrectos 28
Lógica 85
Definición ambigua de una regla de negocio en la especificación 7
Falta de lógica para probar o responder a una condición de error 18
Omisión de la respuesta del sistema en un diagrama de secuencia 4
Omisión de una cláusula condicional 7
Operador u operando incorrecto en la expresión 20
Secuencia de operaciones incorrecta 25
Valor ingresado no se compara con un rango válido 4
Sintaxis 2
Presentar error de sintaxis en el código 2
Total 859
Nota: Datos obtenidos posteriores a la implementación (Elaboración propia).
Figura 47. Defectos pendientes de actualización de estado del 2017 (Elaboración propia).
48
En la Figura 47, se visualizan los Defectos cuyos estados no han sido actualizados en
rangos de 0 a 1 mes, de 1 a 2 meses y así sucesivamente hasta llegar de 11 meses a más,
y por cada rango de tiempo se muestra la cantidad de defectos cuyo estado no ha sido
actualizado.
Vinculación de artefactos de prueba con servicio de certificación.
Dentro del mismo formulario del servicio de certificación además de ingresar toda la
información sobre complejidad, prioridad, fechas de atención planificadas, fechas
planificadas por inicio de etapa y el registro de actividades y defectos, también se le puede
vincular artefactos de prueba como el plan de pruebas.
Figura 48. Ingreso de complejidad y prioridad (Elaboración propia).
Figura 49. Ingreso de fechas planificadas de atención en sección ejecución del formulario
(Elaboración propia).
Figura 50. Ingreso de fechas planificadas de certificación por etapas (Elaboración propia).
49
Figura 51. Vinculación de plan de pruebas en sección enlaces del formulario (Elaboración
propia).
Dentro de la lista de artefactos a relacionar tiene la capacidad de realizarlo con cualquier
tipo de artefacto de prueba que contenga IBM Rational Quality Manager, inclusive si aún no
se hubiera creado, desde el mismo formulario en IBM Rational ClearQuest es posible crear
un plan de pruebas por ejemplo con información mínima solicitada, para que luego el detalle
fuera llenado en la interfaz de IBM Rational Quality Manager.
Figura 52. Adición de un nuevo plan de pruebas al formulario (Elaboración propia).
50
Figura 53. Ingreso de datos mínimos del plan de pruebas desde el formulario de IBM
Rational ClearQuest (Elaboración propia).
Figura 54. Enlace (link) del plan de pruebas creado y relacionado al formulario del servicio
de certificación en la sección enlaces (Elaboración propia).
Posteriormente al ingresar a IBM Rational Quality Manager abrimos el plan de pruebas
creado desde el formulario de IBM Rational ClearQuest para llenar todo el detalle requerido
como objetivos del plan, objetivos de calidad, criterios de entrada, criterios de salida,
análisis de riesgo, estrategia de pruebas, equipo de pruebas, entorno de pruebas,
herramienta de pruebas e hitos.
Figura 55. Secciones del plan de pruebas en IBM Rational Quality Manager (Elaboración
propia).
51
Vinculación de artefactos de prueba con el registro de un defecto.
Durante la ejecución de un caso de pruebas en IBM Rational Quality Manager es posible
registrar un defecto al encontrar un resultado distinto al esperado dentro de uno de los
pasos del script de pruebas y que al momento de realizarlo de manera automática se rellene
el formulario del defecto con los enlaces al plan de pruebas, caso de pruebas, script de
pruebas y registro de ejecución, y que además en el campo de descripción también se
rellena automáticamente con el texto de los pasos previos que fueron ejecutados
satisfactoriamente hasta el paso en que se obtuvo un resultado errado.
Figura 56. Creación de un defecto desde la ejecución de un caso de pruebas (Elaboración
propia).
Figura 57. Comunicación con IBM Rational ClearQuest para selección del tipo de registro
DefectoQA (Elaboración propia).
Figura 58. Autenticación con IBM Rational ClearQuest para enlazar el formulario de Defecto
al registro de ejecución del caso de pruebas (Elaboración propia).
52
Figura 59. Formulario de Defecto de IBM Rational ClearQuest rellenado con información
obtenida de IBM Rational Quality Manager (Elaboración propia).
Una vez instanciado el formulario del nuevo defecto, sólo queda ingresar la información
restante de los campos personalizados obligatorios como se muestra en la Figura 59 y al
ser campos de tipo lista, agiliza bastante el tiempo incurrido en la generación del defecto
durante la ejecución de un caso de pruebas.
53
CONCLUSIONES
En relación al objetivo general, se concluye que a partir del Informe de Evaluación de
Procesos se pudo evidenciar las falencias del Proceso de Certificación de Producto
Software que tenía la sección Calidad de Soluciones. Por ello fue necesario el rediseño del
proceso de Certificación y su posterior automatización para lograr tener visibilidad sobre las
peticiones de Certificación ingresadas al área, poder dimensionar la carga de trabajo por
Analista de Calidad, poder obtener mediciones reales de esfuerzo incurrido por etapa de
pruebas, poder registrar defectos para identificar las principales falencias que se presentan
durante la construcción del software, y con toda la información obtenida tener la capacidad
de identificar oportunidades de mejora a todo el proceso de manera constante.
En relación al objetivo específico 1, se concluye que se pudo implementar la solución de
gestión y personalización de artefactos de prueba con IBM Rational Quality Manager la cual
se integra con IBM Rational ClearQuest mediante OSLC Links. Además, se configuraron los
conectores para su integración con las herramientas IBM Rational Functional Tester e IBM
Rational Performance Tester para el diseño y ejecución de pruebas automatizadas y de
rendimiento.
En relación al objetivo específico 2, se concluye que ambas soluciones le permitieron a la
sección Calidad de Soluciones que tenga la capacidad de gobernabilidad sobre sus
procesos de Certificación de Producto, Gestión de Defectos y Gestión de Incidentes,
además de gestionar todos sus artefactos de prueba y poder vincularlos de ser requerido a
cualquiera de los formularios de los procesos automatizados con la finalidad de enriquecer
la información registrada.
54
RECOMENDACIONES
Se debería capacitar al personal de pruebas para diseñar casos de prueba dado que,
hasta antes del rediseño del Proceso de Certificación de Producto, los equipos de
Desarrollo eran quienes los diseñaban.
Se debería capacitar al personal de pruebas para el diseño y ejecución de pruebas de
rendimiento, automatizadas y de seguridad web, debido a que contaban con herramientas
que podían realizar dichos tipos de pruebas, pero no las estaban usando.
Se debería crear un laboratorio de pruebas para gestionar, calendarizar y ejecutar
pruebas automatizadas, pruebas de rendimiento y pruebas de seguridad sobre aplicaciones
web.
Se debería designar un rol por persona para optimizar la ejecución de sus funciones y
así se dejará de tener sobrecarga de trabajo por recurso, dado que se tiende a asociar más
de un rol por persona.
Se debería definir y crear repositorios de versionamiento, tanto para la entrega y
evolución de cambios de los artefactos generados por Desarrollo, como por los artefactos
de pruebas generados por la sección Calidad de Soluciones.
55
REFERENCIAS BIBLIOGRÁFICAS
Banco de la Nación. (2006). Integración y Pruebas del Software. En Metodología Para el
Ciclo de Vida del Software NTP-ISO/IEC 12207 (págs. (3.4-1 - 3.4-11)). Lima.
Becker, K., & Roremann, M. (2001). Business Process Lifecycle Management. White Paper.
Comisión de Reglamentos Técnicos y Comerciales-INDECOPI. (2006). Proceso de
aseguramiento de la calidad. En NORMA TÉCNICA PERUANA NTP-ISO/IEC 12207
(pág. 55). Lima: 2ª Edición.
Cruz, P. (2017). Organigrama de QBAN Group. Lima, Perú.
Garimella, K., Lees, M., & Williams, B. (2008). Introducción a BPM para Dummies. Indiana:
Wiley Publishing, Inc.
Gartner. (Marzo de 2015). Magic Quadrant for Inteligent Business Process Management
Suites.
Georgakopoulos, D., Hornick, M., & Sheth, A. (1995). An Overview of Workflow
Management: From Process Modeling to Workflow Automation Infrastructure. En
Distributed and Parallel Databases (págs. p.119-153). Boston: Kluwer Academic
Publishers.
Google. (2017). Google Maps. Obtenido de https://goo.gl/maps/2RrpihG4TN72
IBM Knowledge Center. (s.f.). IBM Knowledge Center. Obtenido de Ampliación de Rational
Quality Manager utilizando servicios OSLC:
https://www.ibm.com/support/knowledgecenter/es/SSYMRC_6.0.5/com.ibm.rational.t
est.qm.doc/topics/r_oslc_services.html
Müller, T., Black, R., Eldh, S., Graham, D., Olsen, K., Pyhäjärvi, M., . . . Verma, R. (2010).
Programa de Estudio de Nivel Básico. International Software Qualifications Board
2010.
QBAN Consulting. (2008). Workflow de Gestion de Mantenimientos. Lima, Lima, Perú.
QBAN Consulting. (2017). Organigrama de QBAN Group. Lima, Lima, Perú.
Software & Systems Engineering Committee. (2010). Definiciones. En IEEE Standard
Classfication for Software Anomalies (pág. 5). New York: IEEE Std 1044 - 2009.
Software & Systems Engineering Committee. (2010). IEEE Standard Classfication for
Software Anomalies. New York: IEEE Std 1044 - 2009.
Wikipedia. (15 de Enero de 2019). Wikipedia. Obtenido de Open Services for Lifecycle
Collaboration:
https://en.wikipedia.org/wiki/Open_Services_for_Lifecycle_Collaboration
ANEXOS
Anexo 1.
Procedimiento Certificación de Producto Software (2010)
DEPARTAMENTO DE INFORMÁTICA PROCESO: CERTIFICACIÓN DE PRODUCTOS
SOFTWARE
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 1 de 23
CERTIFICACIÓN DE PRODUCTOS SOFTWARE
NOMBRE DEL ÁREA CÓDIGO DEL PROCEDIMIENTO TÉCNICO OPERATIVO
• Sección Calidad de Soluciones • BN – PR - 01 - 003 – 01
NOMBRE DEL SUB PROCESO FECHA DE APROBACIÓN
• Certificación de Productos Software • Agosto – 2011
UNIDAD ORGÁNICA A CARGO DEPARTAMENTO A CARGO TIPO DE PROCEDIMIENTO
• División de Producción • Informática • Crítico
OBJETIVO DEL PROCEDIMIENTO
• Contar con procedimientos para la certificación de productos software desarrollados por la División Desarrollo de Sistemas de Información y/o Proveedores Externos de software.
• Establecer el flujo de actividades para el desarrollo del procedimiento de certificación de productos software, desde su planificación, ejecutando los niveles de configuración y evaluación, hasta la certificación final.
• Identificar y establecer las funciones y/o responsabilidades de los participantes en el procedimiento de certificación de productos software.
CLIENTES/USUARIOS INTERNOS CLIENTES/USUARIOS EXTERNOS
• Todos los Departamentos del BN que utilizarán los sistemas de información
• Proveedores que desarrollan soluciones de software a solicitud del Banco de la Nación.
APLICATIVO Y/O SOFTWARE
• IBM Rational Clear Quest
• IBM Requisite Pro
REQUISITOS Y/O FORMULARIOS
• Revisión conjunta de pruebas unitarias de la División Desarrollo de Sistemas de Información
DOCUMENTOS NORMATIVOS RELACIONADOS
• Circular, BN-CIR-2400 Nº 103-01 “Gestión de Procedimientos Internos Técnicos – Operativos del Departamento de Informática”.
• Manual de Organización y Funciones del Departamento de Informática, aprobado con Resolución de Gerencia General EF/92-2000 N° 008–2009, de fecha 2009.03.16.
• Directiva BN-DIR-2400-147-01 Rev.0 “Ciclo de Vida del Software”
• Lineamiento BN-PR-01-001-01 “Lineamientos del Comité Calidad de Soluciones de Informática”
• Procedimiento BN-PR-01-002-01 “Procedimiento del Comité de Calidad de Soluciones de Informática”
• Elementos Web (Java, .Net)
• Microsoft Office
• Elementos Host
DEPARTAMENTO DE INFORMÁTICA PROCESO: CERTIFICACIÓN DE PRODUCTOS
SOFTWARE
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 2 de 23
CERTIFICACIÓN DE PRODUCTOS SOFTWARE
DESCRIPCIÓN DE LA ACTIVIDAD RESPONSABLE PUNTO
DE CONTROL
PLANIFICACIÓN
(A.1) Aceptar el ingreso del Mantenimiento / Proyecto a la Sección Calidad de Soluciones, mediante la actualización del estado del mismo en el IBM Rational Clear Quest como ‘En_certificación. Continúa Numeral (A.2).
Analista de Planificación
(A.2) Revisar y analizar los documentos RUP relacionados al mantenimiento / proyecto en el Requesite Pro
Analista de Planificación
□
◊ (A.2.1) Documentación Completa: Numeral (A.3).
(A.2.2) Documentación Incompleta: Numeral (A.5).
(A.3) Asignar al Analista de Pruebas1 a través del IBM Rational Clear Quest. El estado del mantenimiento se actualiza como ‘Asignado a Pruebas’. Continúa Numeral (A.2).
Analista de Planificación
(A.4) Asignar las actividades de prueba. El estado del mantenimiento se mantiene como ‘Asignado a Pruebas’. Continúa en numeral (B.1). Fin sub-proceso planificación.
Analista de Planificación
□
(A.5) Coordina con el Analista de Desarrollo de Sistemas la modificación y/o actualización de la documentación. Continúa Numeral (A.6).
Analista de Planificación
(A.6) Actualiza y/o modifica la documentación observada por el Analista de Planificación en el Requisite Pro. Continúa numeral (A.2).
Analista de Desarrollo
DESPLIEGUE
(B.1) Iniciar las actividades de despliegue, con el apoyo del Analista de pruebas de ser necesario, mediante la actualización del estado del mantenimiento en el IBM Rational Clear Quest como ‘Iniciado’, el cual fuera asignado en el punto (A.3). Continúa Numeral (B.2).
Analista de Planificación
(B.2) Validar, con el apoyo del Analista de pruebas de ser necesario, los artefactos RUP relacionados al mantenimiento y/o proyecto en el
Requesite Pro. Analista de Planificación
□
◊
1 : La asignación de pruebas es notificada al Analista de Pruebas de forma automática a través
del IBM Rational Clear Quest
DEPARTAMENTO DE INFORMÁTICA PROCESO: CERTIFICACIÓN DE PRODUCTOS
SOFTWARE
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 3 de 23
(B.2.1) Con observaciones. Numeral (B.3)
(B.2.2) Sin observaciones: Numeral (B.5)
(B.3) Solicitar, con el apoyo del Analista de pruebas de ser necesario, la corrección de las observaciones. Continúa Numeral (B.4).
Analista de Planificación
(B.4) Actualizar documentación de acuerdo a las observaciones realizadas por el Analista de Planificación o Analista de Pruebas. Continúa Numeral (B.2).
Analista de Desarrollo
(B.5) Verificar, con el apoyo del Analista de pruebas de ser necesario, la existencia de los elementos a desplegar.
Analista de Planificación
□
◊
(B.5.1) Con observaciones. Numeral (B.6)
(B.5.2) Sin observaciones: Numeral (B.8)
(B.6) Solicitar, con el apoyo del Analista de pruebas de ser necesario, la corrección de las observaciones. Continúa Numeral (B.7).
Analista de Planificación
(B.7) Actualizar los elementos de acuerdo a las observaciones realizadas por el Analista de Planificación o Analista de Pruebas. Continúa Numeral (B.5).
Analista de Desarrollo
(B.8) Coordinar, con el apoyo del Analista de pruebas de ser necesario, con la División Infraestructura y Comunicaciones, y con la
División Desarrollo de S. I. la ejecución del despliegue.
Analista de Planificación
□
◊
(B.8.1) Plataforma Host y Open: Despliega los elementos en los ambientes Host y Open de certificación. Continúa en numeral (B.9)
(B.8.2) Plataforma Mainframe: Despliega los elementos en el ambiente Mainframe de certificación. Continúa en numeral (B.9)
(B.8.3) Plataforma Open: Despliega elementos en el servidor de aplicaciones web de certificación (Java o .Net). Continúa en numeral (B.9)
(B.9) Evaluar, con el apoyo del Analista de pruebas de ser necesario, el despliegue Open / Host
Analista de Planificación □
◊ (B.9.1) Es correcta: Continúa en el numeral (B.10)
(B.9.2) Es incorrecta: Continúa en el numeral (B.11)
(B.10) Comunicar al Analista de pruebas para dar inicio a las Pruebas Previas. Ir al numeral (C.1) Fin del sub-proceso de despliegue.
Analista de planificación
DEPARTAMENTO DE INFORMÁTICA PROCESO: CERTIFICACIÓN DE PRODUCTOS
SOFTWARE
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 4 de 23
(B.11) Coordinar, con el apoyo del Analista de pruebas de ser necesario, con la División Infraestructura y Comunicaciones, y con la División Desarrollo de Sistemas de Información la realización del despliegue. Continua en el Numeral (B.12) y (B.13)
Analista de Planificación □
(B.12) Brindar apoyo para la realización del despliegue en el ambiente de certificación. Continua en el Numeral (B.2)
Analista de Desarrollo □
(B.13) Brindar apoyo en la ejecución de actividades para la realización del despliegue en el ambiente de certificación. Continua en el Numeral (B.2)
Analista de Infraestructura □
PRUEBAS PREVIAS
(C.1) Iniciar las actividades de pruebas previas. Continua en el Numeral (C.2)
Analista de Pruebas
(C.2) Validar la Solicitud de Cambio con los requisitos para la configuración del ambiente de pruebas. Continua en el Numeral (C.3)
Analista de Pruebas □
(C.3) Verificar y analizar los artefactos RUP relacionados al Mantenimiento/Proyecto disponibles en el Requisite Pro. Continua en el Numeral (C.4)
Analista de Pruebas □
(C.4) Preparar los datos de prueba para complementar la configuración del ambiente de pruebas. Continua en el Numeral (C.5)
Analista de Pruebas □
(C.5) Evalúa la complejidad de la prueba
Analista de Pruebas □
◊ (C.5.1) Es compleja2: Continúa en el numeral (C.11)
(C.5.2) No es compleja: Continúa en el numeral (C.6)
(C.6) Ejecutar pruebas previas. Continua en el Numeral (C.7) Analista de Pruebas □
(C.7) Redactar informe de pruebas previas. (Anexo 3.1). Continúa en numeral (C.8)
Analista de Pruebas
(C.8) Evalúa Resultado de las pruebas previas ejecutadas.
Analista de Pruebas □
◊ (C.8.1) Éxito: Continúa en el numeral (C.9)
(C.8.2) Fracaso: Continúa en el numeral (C.12)
2 La complejidad se define de acuerdo al criterio del Analista de Pruebas en base a la
complejidad en la configuración del ambiente de pruebas y, la complejidad de la ejecución de la
prueba.
DEPARTAMENTO DE INFORMÁTICA PROCESO: CERTIFICACIÓN DE PRODUCTOS
SOFTWARE
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 5 de 23
(C.9) Evaluar realización de pruebas previas no funcionales
Analista de Pruebas □
◊ (C.9.1) No realizar: Continúa Numeral (C.10)
(C.9.2) Realizar: Continúa Numeral (C.13)
(C.10) Finalizar actividades de prueba previas del mantenimiento / proyecto. Continúa en numeral (D.1). Fin sub-proceso Pruebas Previas
Analista de Pruebas
(C.11) Coordinar elaboración de plan de pruebas. Continúa en
numeral (C.6) Analista de Pruebas
□
(C.12) Evalúa ciclos de prueba
Analista de Pruebas □
◊ (C.12.1) Cumple 3° ciclo: Continúa numeral (C.15)
(C.12.2) No cumple 3° ciclo: Continúa numeral (C.17)
(C.13) Ejecutar pruebas previas no Funcionales. (C.14) Analista de Pruebas □
(C.14) Redactar Informe de Pruebas previas no funcionales.
Analista de Pruebas
□
◊
(C.14.1) No se encontraron observaciones críticas: Continúa numeral (C.10)
(C.14.2) Se encontraron observaciones críticas: Continúa numeral (C.12)
(C.15) Finalizar actividades de prueba previa del mantenimiento / proyecto. Continúa numeral (C.16)
Analista de Pruebas
(C.16) Rechazar el mantenimiento / proyecto, actualizando su estado en el IBM Rational Clear Quest como ‘Rechazado’. Fin del procedimiento.
Analista de Planificación
(C.17) Solicitar corrección de las observaciones. Continúa numeral (C.18)
Analista de Pruebas
(C.18) Realizar la corrección de las observaciones. Continúa en el numeral (B.3)
Analista de desarrollo de sistemas
□
PRUEBAS DE ACREDITACIÓN
(D.1) Citar al usuario experto. Continua numeral (D.2) Analista de pruebas
(D.2) Ejecutar pruebas funcionales y/o no funcionales en presencia del usuario experto. Continua numeral (D.3)
Analista de pruebas
DEPARTAMENTO DE INFORMÁTICA PROCESO: CERTIFICACIÓN DE PRODUCTOS
SOFTWARE
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 6 de 23
(D.3) Redactar resultado de pruebas (Anexo 3.2)
Analista de pruebas
◊ (D.3.1) Pruebas exitosas: Continua numeral (D.4)
(D.3.2) Pruebas no exitosas: Continua numeral (C.12)
(D.4) Redactar revisión conjunta (Anexo 3.3) y encuesta de satisfacción (Anexo 3.4). Continua numeral (D.5)
Analista de pruebas
(D.5) Adjuntar documentación firmada por el área solicitante en el IBM Rational Clear Quest. Continua numeral (D.6)
Analista de pruebas
(D.6) Finalizar actividades de pruebas a través de la actualización del estado del mantenimiento / proyecto en el IBM Rational Clear Quest como ‘Finalizado’. Continua numeral (D.7)
Analista de pruebas
(D.7) Comunicar finalización al Analista de Planificación. Fin del sub-proceso de Pruebas de Acreditación. Continúa numeral (E.1).
Analista de pruebas
PASE A PRODUCCIÓN
(E.1) Certificar el mantenimiento / proyecto, mediante la actualización del estado en el IBM Rational Clear Quest, como ‘Certificado’. Continua numeral (E.2)
Analista de planificación
(E.2) Evaluar el impacto del pase a producción, con el apoyo del Analista de DSI.
Analista de pruebas
□
(E.2.1) Impacto alto: Continúa numeral (E.3)
(E.2.2) Impacto normal: Continúa numeral (F.1) Fin del sub-proceso de Pase a Producción.
(E.3) Coordinar con la Sección Operaciones y Control de Plataformas, con el apoyo del Analista de Desarrollo. Continúa numeral (F.1)
Analista de pruebas □
SEGUIMIENTO Y CONTROL3
(F.1) Consultar al usuario con quien se realizaron las pruebas en el ambiente de certificación con la finalidad de informarse sobre la existencia de inconvenientes o incidentes.
Analista de pruebas
□
◊
(F.1.1) Incidente: Continúa Numeral (F.2)
(F.1.2) Sin incidente: Continúa numeral (F.5)
(F.2) Registrar en aplicativo IBM Rational Clear Quest, como una nota del mantenimiento y/o proyecto, el incidente descrito por el usuario.
Analista de pruebas
3 Este sub-proceso se ejecuta cuando se realizan pases a producción de mantenimientos y/o
proyectos
DEPARTAMENTO DE INFORMÁTICA PROCESO: CERTIFICACIÓN DE PRODUCTOS
SOFTWARE
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 7 de 23
Continúa numeral (F.3)
(F.3) Identificar si el incidente está relacionado al desarrollo del aplicativo o a la infraestructura del mismo. Continúa numeral (F.4)
Analista de pruebas □
(F.4) Notificar al área identificada sobre el incidente reportado. Fin del sub-proceso de Seguimiento y Control
Analista de pruebas
(F.5) Registra en el aplicativo IBM Rational Clear Quest, como una nota del mantenimiento y/o proyecto, el funcionamiento normal descrito por el usuario. Fin del sub-proceso de Pase a Producción
Analista de pruebas
LEYENDA ABREVIATURAS UTILIZADAS
Origen de Procedimiento
T.I. Tecnología de Información
Operación / Sistema RUP Estándar utilizado para el análisis, implementación y
documentación de sistemas orientados a objetos
Documento: Entrante / Saliente
S. I. Sistemas de Información
□ Evaluación / Análisis DSI Desarrollo de Sistemas de Información
◊ Condicional
Correo electrónico
Fin del Procedimiento
DEPARTAMENTO DE INFORMÁTICA PROCESO: CERTIFICACIÓN DE PRODUCTOS
SOFTWARE
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 8 de 23
ANEXOS
ANEXO 1: DEFINICIÓN DE TÉRMINOS
- Acreditación: Proceso a través del cual el usuario experto, previo cumplimiento de los requerimientos especificados en la Solicitud de Cambio y/o requerimiento de proyecto nuevo, autoriza a la Sec. Calidad de Soluciones la certificación del producto software.
- Ciclo de prueba: Un ciclo de prueba incluye la ejecución de una, alguna o todas las pruebas
planificadas para el producto software. Cada ciclo de prueba está asociado a una versión del producto, y cada nuevo ciclo de prueba implicará una nueva versión de uno o más componentes del sistema, y al culminarla se emitirá un informe que describa los problemas y/u observaciones encontrados durante su ejecución.4
- Elementos de despliegue: Involucra el software a certificar y componentes relacionados
necesarios para la configuración del ambiente de pruebas.
- IBM Rational Clear Quest: Aplicativo utilizado para controlar los mantenimientos y/o proyectos de desarrollo de aplicaciones durante todo el ciclo de vida, desde su nacimiento (a través de un requerimiento) hasta su puesta en producción.
- IBM Requisite Pro: Aplicativo utilizado como repositorio de información de los mantenimientos y/o
proyectos desarrollados por el Banco y/o terceros.
- Pruebas no funcionales: Involucra la realización de distintos tipos de pruebas orientadas a analizar la estructura interna de los productos software para evaluar su comportamiento bajo determinados escenarios.
- Requisite Pro: Aplicativo utilizado para el almacenamiento de la documentación relacionada a los
mantenimientos y/o proyectos de desarrollo de aplicaciones.
4 Las observaciones encontradas durante cada ciclo de prueba se detallan en el IBM Rational
Clear Quest.
DEPARTAMENTO DE INFORMÁTICA PROCESO: CERTIFICACIÓN DE PRODUCTOS
SOFTWARE
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 9 de 23
ANEXO 2: ROLES
ROL SUB-PROCESO RESPONSABILIDADES
ANALISTA DE PLANIFICACIÓN
PLANIFICACIÓN DE PRUEBAS
Revisión y análisis de los documentos RUP asociados a los pases a certificación validación de la documentación presentada.
Asignación de los analistas de pruebas.
Asignación de las actividades de prueba a los analistas de prueba designados.
Coordinaciones con la División DSI.
Realiza la devolución de los mantenimientos que se encuentren con observaciones y/o errores a la División DSI.
Herramienta de trabajo: Uso del Aplicativo IBM Rational Clear Quest para la asignación de analistas de prueba, actividades de prueba y devolución de mantenimientos y/o proyectos a la Div. DSI.
DESPLIEGUE
Validación de los artefactos RUP relacionados al despliegue del mantenimiento y/o proyecto en el ambiente de certificación.
Verificación de la existencia de los elementos a desplegar en el ambiente de certificación.
Coordinaciones con la División Desarrollo de Sistemas de Información.
Despliegue de las librerías, programas, archivos, etc. del ambiente de desarrollo al ambiente de certificación, de los mantenimientos y/o proyectos a implementarse en ambiente host.
Despliegue de los componentes que los mantenimientos y/o proyectos a implementarse en ambiente Open.
Evaluación del despliegue ejecutado con la finalidad de comprobar su correcto funcionamiento.
Herramienta de trabajo: Uso del Aplicativo IBM Rational Clear Quest para la actualización de las actividades de despliegue (Desde el inicio hasta su finalización) de los mantenimientos y/o proyectos asignados por el analista de planificación.
PASE A PRODUCCIÓN
Certificación de los mantenimientos y/o proyectos.
Realiza la devolución de los mantenimientos que se encuentren con observaciones y/o errores a la División Desarrollo de Sistemas de Información.
ANALISTA DE PRUEBAS
PRUEBAS PREVIAS
Verifica y analiza los artefactos RUP relacionados por la prueba asignada por el Analista de Planificación.
Valida la solicitud de cambio con los requisitos para la configuración del ambiente certificación
Prepara los datos que serán utilizados durante la ejecución de pruebas
Elabora el plan de pruebas
Ejecuta las pruebas previas funcionales y/o especiales.
Elabora los formatos ‘Pruebas Previas’ funcionales
Elabora informe de pruebas previas especiales
Realiza la evaluación de los ciclos de pruebas.
Coordina la corrección de observaciones y/o errores con la División Desarrollo de Sistemas de Información.
Herramienta de trabajo: Uso del Aplicativo IBM Rational Clear Quest para la actualización de las actividades de prueba (Desde el inicio hasta su finalización) de los mantenimientos y/o proyectos asignados por el analista de planificación.
PRUEBAS DE ACREDITACIÓN
Coordinar con el (los) usuario(s) experto(s) la fecha de realización de las pruebas de acreditación.
Ejecuta las pruebas de acreditación en presencia del usuario experto.
Elabora el formato ‘Resultado de Pruebas’
DEPARTAMENTO DE INFORMÁTICA PROCESO: CERTIFICACIÓN DE PRODUCTOS
SOFTWARE
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 10 de 23
Elabora el formato ‘Revisión Conjunta’
Realiza encuesta de satisfacción a el (los) usuario (s).
Comunica finalización de pruebas al analista de planificación.
Herramienta de trabajo: Uso del Aplicativo IBM Rational Clear Quest para la actualización de las actividades de prueba (Desde el inicio hasta su finalización) de los mantenimientos y/o proyectos asignados por el analista de planificación. Así mismo, para adjuntar los documentos que acreditan las pruebas realizadas y la aceptación del usuario experto.
PASE A PRODUCCIÓN
Evaluación del impacto del pase a producción.
Coordinar con la Sección Operaciones y Control de Plataformas las consideraciones a tomar al pasar a producción mantenimientos y/o proyectos cuyo impacto sea alto.
SEGUIMIENTO Y CONTROL
Coordina con el (los) usuario (s) experto las incidencias que se pudieron presentar al utilizar el mantenimiento y/o proyecto.
Identifica si el incidente es de Infraestructura Tecnológica o de Programación del aplicativo.
Coordina la solución de las incidencias con las áreas responsables.
ANALISTA DE DESARROLLO
PLANIFICACIÓN Actualiza y/o modifica la documentación observada por el Analista de
Planificación en el Requisite Pro
DESPLIEGUE Apoyo en la realización del despliegue en el ambiente certificación.
PRUEBAS PREVIAS
Corrección de observaciones encontradas por el Analista de Pruebas durante el Sub-Proceso Pruebas Previas
Apoyo al Analista de Pruebas en la elaboración del pase a producción
PASE A PRODUCCIÓN
Apoyo en las coordinaciones de pase a producción realizadas con la Sec. Operaciones y Control de Plataformas.
ANALISTA DE INFRAESTRUCTURA Y COMUNICACIONES
DESPLIEGUE Apoyo en la ejecución de actividades para la realización del despliegue
en el ambiente de certificación
SEGUIMIENTO Y CONTROL
Tomar acciones sobre los incidentes relacionados a Infraestructura y Comunicaciones
ANALISTA DE LA SECCIÓN OPERACIONES Y CONTROL DE PLATAFDRMAS
PASE A PRODUCCIÓN
Coordinar con la Sección Calidad de Soluciones la realización del pase a producción de las certificaciones de impacto alto.
DEPARTAMENTO DE INFORMÁTICA PROCESO: CERTIFICACIÓN DE PRODUCTOS
SOFTWARE
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 11 de 23
ANEXO 3: FORMATOS 3.2. FORMATO: PRUEBAS PREVIAS
DEPARTAMENTO DE INFORMÁTICA PROCESO: CERTIFICACIÓN DE PRODUCTOS
SOFTWARE
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 12 de 23
DEPARTAMENTO DE INFORMÁTICA PROCESO: PRODUCCIÓN
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 13 de 23
3.3. FORMATO: RESULTADO DE PRUEBAS
DEPARTAMENTO DE INFORMÁTICA PROCESO: PRODUCCIÓN
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 14 de 23
DEPARTAMENTO DE INFORMÁTICA PROCESO: PRODUCCIÓN
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 15 de 23
3.4. FORMATO: REVISIÓN CONJUNTA
DEPARTAMENTO DE INFORMÁTICA PROCESO: PRODUCCIÓN
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 16 de 23
3.5. FORMATO: ENCUESTA DE SATISFACCIÓN
DEPARTAMENTO DE INFORMÁTICA PROCESO: PRODUCCIÓN
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 17 de 23
ANEXO 4: FLUJOGRAMAS FLUJOGRAMA: CERTIFICACIÓN DE PRODUCTOS SOFTWARE
FI
N
DEPARTAMENTO DE INFORMÁTICA PROCESO: PRODUCCIÓN
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 18 de 23
DEPARTAMENTO DE INFORMÁTICA PROCESO: PRODUCCIÓN
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 19 de 23
DEPARTAMENTO DE INFORMÁTICA PROCESO: PRODUCCIÓN
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 20 de 23
DEPARTAMENTO DE INFORMÁTICA PROCESO: PRODUCCIÓN
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 21 de 23
DEPARTAMENTO DE INFORMÁTICA PROCESO: PRODUCCIÓN
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 22 de 23
DEPARTAMENTO DE INFORMÁTICA PROCESO: PRODUCCIÓN
DIVISIÓN PRODUCCIÓN Fecha Actualización: 09/09/2010 Página 23 de 23
Anexo 2.
Informe de Evaluación de Procesos
Adjudicación Directa Selectiva Nº 0001-2015-BN Servicio para la automatización de los procesos de
aseguramiento de la calidad de la Sección Calidad de Soluciones en apoyo al proyecto Nuevo Core Bancario
del BN y basado en la norma NTP 12207
Informe de Evaluación de Procesos
Historial de Cambios
Versión Historia de Modificaciones Autor de
Modificaciones
Fecha de
Modificación
1.0 Creación del documento Daniel Torres 19/05/2015
Documento: Informe Fecha de Creación: 19/05/2015
Título: Informe de Evaluación de Procesos Versión: 1.0 Página 2 de 8
Proyecto: ¡Error! Nombre desconocido de propiedad de documento. Código:
¡Error! Nombre
desconocido de
propiedad de documento.
Realizado por: ¡Error! Nombre
desconocido de propiedad de documento.
Revisado por: ¡Error! Nombre
desconocido de propiedad de documento.
Aprobado por: ¡Error! Nombre
desconocido de propiedad de documento.
Cliente:
INDICE
1. INTRODUCCIÓN ..................................................................................................................................... 3
2. RESUMEN DE LA EVALUACIÓN POR SUB-PROCESO ............................................................................... 3
2.1 SUB-PROCESO: PLANIFICACIÓN .................................................................................................... 3 2.1.1 Observaciones ..................................................................................................................... 3 2.1.2 Oportunidades de Mejora ................................................................................................... 3
2.2 SUB-PROCESO: DESPLIEGUE ........................................................................................................ 4 2.2.1 Observaciones ..................................................................................................................... 4 2.2.2 Oportunidades de Mejora ................................................................................................... 5
2.3 SUB-PROCESO: PRUEBAS PREVIAS ............................................................................................... 5 2.3.1 Observaciones ..................................................................................................................... 5 2.3.2 Oportunidades de Mejora ................................................................................................... 6
2.4 SUB-PROCESO: PRUEBAS DE ACREDITACIÓN................................................................................ 6 2.4.1 Observaciones ..................................................................................................................... 6 2.4.2 Oportunidades de Mejora ................................................................................................... 6
2.5 SUB-PROCESO: PASE A PRODUCCIÓN .......................................................................................... 7 2.5.1 Observaciones ..................................................................................................................... 7 2.5.2 Oportunidades de Mejora ................................................................................................... 7
2.6 SUB-PROCESO: SEGUIMIENTO Y CONTROL ................................................................................... 7 2.6.1 Observaciones ..................................................................................................................... 7 2.6.2 Oportunidades de Mejora ................................................................................................... 7
3. CONCLUSIONES ..................................................................................................................................... 8
Documento: Informe Fecha de Creación: 19/05/2015
Título: Informe de Evaluación de Procesos Versión: 1.0 Página 3 de 8
Proyecto: ¡Error! Nombre desconocido de propiedad de documento. Código:
¡Error! Nombre
desconocido de
propiedad de documento.
Realizado por: ¡Error! Nombre
desconocido de propiedad de documento.
Revisado por: ¡Error! Nombre
desconocido de propiedad de documento.
Aprobado por: ¡Error! Nombre
desconocido de propiedad de documento.
Cliente:
1. Introducción
El presente documento constituye el informe final del resultado de la evaluación de los
procesos inmersos en el actual PROCEDIMIENTO DE CERTIFICACIÓN DE PRODUCTOS
SOFTWARE de la Sección Calidad de Soluciones de la División de Informática del Banco de
la Nación, específicamente con respecto a los sub-procesos:
✓ Planificación
✓ Despliegue
✓ Pruebas Previas
✓ Pruebas de Acreditación
✓ Pase a Producción
✓ Seguimiento y Control
Este requerimiento responde a la necesidad de identificar oportunidades de mejora derivadas
de inconvenientes o problemas en dichos sub-procesos, que pudieran dificultar la culminación
exitosa de los proyectos y mantenimientos atendidos por la Sección Calidad de Soluciones.
Se realizó la evaluación en base a los lineamientos de la norma NTP 12207 en relación a los
Procesos de Apoyo del Ciclo de Vida (Aseguramiento de Calidad, Verificación y Validación) y
las recomendaciones del Comité Internacional de Cualificación de Pruebas de Software
(International SoftwareTesting Qualifications Board - ISTQB).
2. Resumen de la Evaluación por Sub-Proceso
2.1 Sub-Proceso: Planificación
2.1.1 Observaciones
➢ No se contemplan actividades de planificación, salvo la de asignación de recurso.
➢ Presenta una actividad que se debería dar posterior a la planificación que es la de revisión de documentación total.
➢ No se evidencia una actividad en la que se incurra para la definición de estrategia de pruebas.
➢ No se evidencia una actividad en que se incurra para la evaluación y determinación de riesgos del proyecto de pruebas y del producto a probar.
➢ No se evidencia una actividad en la que se incurra para la estimación de esfuerzos.
➢ No se evidencia una actividad en la que se incurra para el registro de fechas estimadas de atención.
2.1.2 Oportunidades de Mejora
✓ Se recomienda replantear las actividades incurridas para el sub-proceso de
Documento: Informe Fecha de Creación: 19/05/2015
Título: Informe de Evaluación de Procesos Versión: 1.0 Página 4 de 8
Proyecto: ¡Error! Nombre desconocido de propiedad de documento. Código:
¡Error! Nombre
desconocido de
propiedad de documento.
Realizado por: ¡Error! Nombre
desconocido de propiedad de documento.
Revisado por: ¡Error! Nombre
desconocido de propiedad de documento.
Aprobado por: ¡Error! Nombre
desconocido de propiedad de documento.
Cliente:
planificación.
✓ Se recomienda incurrir en actividades de:
o Definición de estrategia de pruebas. Para definir y redifinir los planes y diseños de prueba en base al objetivo de las pruebas y a la evaluación de los riesgos del proyecto de prueba.
o Evaluación y determinación de los riesgos del proyecto y del producto. Riesgos del proyecto, para medir la capacidad del éxito del proyecto de pruebas, tomando en cuenta factores de organización y aspectos técnicos. Riesgos del producto, para reconocer las posibles áreas de fallo en el software o sistema que impacten en la calidad del producto, además de dar a conocer dónde empezar a probar y dónde probar más.
o Estimación de esfuerzos. En donde se puede realizar en base a dos enfoques:
▪ Basado en métricas: estimar el esfuerzo de las pruebas en base a métricas de proyectos anteriores o similares o en base a valores típicos.
▪ Basado en expertos: estimar tareas en base a las estimaciones hechas por el propietario de la tarea o por los expertos.
o Así como depender de factores tales como:
▪ Las características del producto: La calidad de la especificación y demás información utilizada para los modelos de prueba, el tamaño del producto y la fiabilidad y seguridad de los requisitos detallados en la documentación.
▪ Las carácterísticas del proceso de desarrollo: Metodología de desarrollo de software, calidad de artefactos entegados y posible presión temporal.
▪ El resultado de las pruebas: el número de defectos y la cantidad de cambios necesarios.
✓ Se recomienda crear un borrador del Plan de Pruebas Maestro / Plan de Pruebas de Nivel. Este documento luego se irá enriqueciendo en la etapa de Diseño de Pruebas.
✓ Se recomienda el rediseño total del sub-proceso.
2.2 Sub-Proceso: Despliegue
2.2.1 Observaciones
➢ Presenta actividad “Verificar la existencia de los elementos a probar” que es propia del proceso de apoyo Gestión de la Configuración, sin embargo no hace referencia a dicho proceso ni los criterios de evaluación que darían como resultado observaciones a ser atendidas por desarrollo.
➢ La actividad “Coordinar con la División Infraestructura y Comunicaciones y con la División Desarrollo de S. I”, no indica en qué consiste la coordinación. Adicionalmente, en la práctica, esta actividad es condicionada dado que no siempre se requiere el apoyo de la División Infraestructura y Comunicaciones para el despliegue, y no se requiere el apoyo de la División Desarrollo de S. I., dado que el
Documento: Informe Fecha de Creación: 19/05/2015
Título: Informe de Evaluación de Procesos Versión: 1.0 Página 5 de 8
Proyecto: ¡Error! Nombre desconocido de propiedad de documento. Código:
¡Error! Nombre
desconocido de
propiedad de documento.
Realizado por: ¡Error! Nombre
desconocido de propiedad de documento.
Revisado por: ¡Error! Nombre
desconocido de propiedad de documento.
Aprobado por: ¡Error! Nombre
desconocido de propiedad de documento.
Cliente:
responsable del despliegue de la solución en el entorno de pruebas, es un miembro de la Sección Calidad de Soluciones.
➢ Luego de la actividad “Evaluar despliegue Open/Host”, si el resultado fue “incorrecto” se indica continuar con la actividad “Coordinar con la División Infraestructura y Comunicaciones y con la División Desarrollo de S. I”, pero no indica en qué consiste la coordinación. Así mismo, en la práctica, no es una actividad que siempre impacte a ambas divisiones.
➢ Para la ejecución de las actividades correspondientes a la Sección Calidad de Soluciones figura como responsable el rol Analista de Planificación, sin embargo, en la práctica se le llama Desplegador.
➢ En la práctica también se realizan coordinaciones con la sección Seguridad Informática de forma condicionada si el despliegue lo requiriera, pero esto no se grafica en el modelo ni se menciona en la descripción de las actividades.
➢ No se evidencia una actividad o llamada a la creación de defectos, para los casos en que no se cumplan las validaciones de manera satisfactoria.
2.2.2 Oportunidades de Mejora
✓ Se recomienda tener una gestión de la configuración con políticas y estandares de versionado definidos y estos estén apoyados con una herramienta de control de versiones.
✓ Se recomienda redefinir actividades que reflejen la realidad de atención del área de Calidad y su interacción con otras áreas durante la etapa de despliegue según se cumplan las condiciones de dependencia.
✓ Se recomienda tener definido un rol que se use en la práctica más acorde a las actividades incurridas.
✓ Se recomienda la implementación de una gestión de defectos en donde se registren defectos encontrados durante las validaciones realizadas a la documentación y/o despliegue.
2.3 Sub-Proceso: Pruebas Previas
2.3.1 Observaciones
➢ Presenta actividad “Validar la Solicitud de Cambio con los requisitos para la implementación del ambiente”, pero no se evidencia ninguna compuerta de desición ante el resultado de la validación.
➢ Presenta actividad “Verificar y analizar los arteafactos RUP”, pero no se evidencia ninguna compuerta de decisión ante el resultado de la verificación.
➢ Presenta actividad “Coordinar elaboración de plan de pruebas” como resultado que se trata de una prueba compleja. Esto no debería corresponder dado que hace referencia a una actividad incurrida en las etapas de Planificación y/o Diseño de Pruebas (que actualmente no presenta). Además no presenta alguna actividad
Documento: Informe Fecha de Creación: 19/05/2015
Título: Informe de Evaluación de Procesos Versión: 1.0 Página 6 de 8
Proyecto: ¡Error! Nombre desconocido de propiedad de documento. Código:
¡Error! Nombre
desconocido de
propiedad de documento.
Realizado por: ¡Error! Nombre
desconocido de propiedad de documento.
Revisado por: ¡Error! Nombre
desconocido de propiedad de documento.
Aprobado por: ¡Error! Nombre
desconocido de propiedad de documento.
Cliente:
adicional que se tenga que realizar dada la complejidad, puesto que continua con la ejecución de las pruebas, caso similar al no haberse encontrado complejidad.
➢ Presenta actividades sobre atención de correcciones por resultados fallidos, asumiendo que siempre la responsabilidad de atención sea asignada a la División de Desarrollo de S.I. y que al no haber un discriminante sobre tipos de defectos ó el impacto que pueda tener con respecto a las pruebas totales planificadas, todas las atenciones cumplen hasta 3 ciclos de devoluciones dado que si ingresara por cuarta vez sería rechazada la certificación. Esto debería darse dentro de una gestión de defectos en donde se contemplen diversos posibles escenarios y donde no siempre la División de Desarrollo de S.I. sea la responsable de la atención.
➢ No presenta ninguna actividad que genere defectos.
2.3.2 Oportunidades de Mejora
✓ Se recomienda que se tengan compuertas de desición que evidencien acciones distintas en base al resutado de actividades de validación y/o verificación.
✓ Se recomienda tener mejor identificadas las actividades incurridas por etapa.
✓ Se recomienda la implementación de una gestión de defectos en donde se registren defectos encontrados durante las validaciones realizadas a los artefactos (documentos, fuentes, compilados, programas, etc), de acuerdo a la revisión, nivel o tipo de prueba realizado.
✓ Se recomienda el refinamiento del sub-proceso.
2.4 Sub-Proceso: Pruebas de Acreditación
2.4.1 Observaciones
➢ Presenta actividad “Ejecutar pruebas funcionales / no funcionales”, pero las pruebas
de aceptación no sólo se dan para validar requisitos funcionales / no funcionales, sino para “Evaluar la buena disposición de un sistema para su despliegue y uso, a pesar de no constituir necesariamente el último nivel de prueba (ISTQB, 2010)”. Podría darse en distintos momentos del ciclo de vida, por ejemplo, puede darse para validar la usabilidad de un componente durante las pruebas de componente(1), o para validar una nueva mejora funcional antes de las pruebas de sistema(2).
➢ En el modelo no se contempla pruebas de aceptación operativas, contractual y normativa, pese a que en la práctica si realizan pruebas de aceptación contractual que toma como base los criterios de aceptación previstos en un contrato realizado a proveedores externos de desarrollo y pruebas de aceptación normativa que toma como base cualquier normativa de obligado cumplimiento.
➢ Presenta actividades sobre atención de correcciones por resultados fallidos, asumiendo que siempre la responsabilidad de atención sea asignada a la División de Desarrollo de S.I. y que al no haber un discriminante sobre tipos de defectos / errores / fallos / incidencias ó el impacto que pueda tener con respecto a las pruebas totales planificadas, todas las atenciones cumplen hasta 3 ciclos de devoluciones dado que
Documento: Informe Fecha de Creación: 19/05/2015
Título: Informe de Evaluación de Procesos Versión: 1.0 Página 7 de 8
Proyecto: ¡Error! Nombre desconocido de propiedad de documento. Código:
¡Error! Nombre
desconocido de
propiedad de documento.
Realizado por: ¡Error! Nombre
desconocido de propiedad de documento.
Revisado por: ¡Error! Nombre
desconocido de propiedad de documento.
Aprobado por: ¡Error! Nombre
desconocido de propiedad de documento.
Cliente:
si ingresara por cuarta vez sería rechazada la certificación. Esto debería darse dentro de una gestión de incidencias en donde se contemplen diversos posibles escenarios y donde no siempre la División de Desarrollo de S.I. sea la responsable de la atención.
2.4.2 Oportunidades de Mejora
✓ Se recomienda incluir las actividades incurridas para la ejecución de una prueba de
aceptación dentro de la etapa de “Ejecución de Pruebas”, dado que es un nivel de prueba más y no define una etapa dentro del ciclo de vida de Certificación de producto.
✓ Se recomienda incluir dentro de las actividades incurridas para la ejecución de una prueba de aceptación, aquellas que indiquen que tipo de prueba de aceptación estaría siendo ejecutado, dado que además de usuario existen las operativas, contractuales y normativas.
✓ Se recomienda la implementación de una gestión de defectos en donde se registren defectos encontrados durante las validaciones definidas en los documentaos de aceptación (funcionales, contratos, normas, despliegue).
2.5 Sub-Proceso: Pase a Producción
2.5.1 Observaciones
➢ Presenta actividades posteriores a la certificación de un producto.
➢ Presenta actividad “Evaluar impacto de pase a producción” que debería ser propio de un comité de gestión de pases producción.
2.5.2 Oportunidades de Mejora
✓ Se recomienda retirar este sub-proceso como parte de las etapas incurridas para la
certificación de un producto, debido a que define actividades posteriores a la certificación.
✓ Se recomienda solicitar la creación de un comité de gestión de pases a producción, en donde dicho comité debería ser responsable de la evaluación del motivo e impacto de que los mantenimientos / proyectos pasen a un entorno productivo y que estén alineados con los requisitos del negocio. Dicho comité debería pertenecer a la División de Producción como un órgano de apoyo o estar dentro de la sección responsable de despliegues en entornos productivos.
2.6 Sub-Proceso: Seguimiento y Control
2.6.1 Observaciones
➢ Presenta actividades posteriores a la certificación de un producto.
Documento: Informe Fecha de Creación: 19/05/2015
Título: Informe de Evaluación de Procesos Versión: 1.0 Página 8 de 8
Proyecto: ¡Error! Nombre desconocido de propiedad de documento. Código:
¡Error! Nombre
desconocido de
propiedad de documento.
Realizado por: ¡Error! Nombre
desconocido de propiedad de documento.
Revisado por: ¡Error! Nombre
desconocido de propiedad de documento.
Aprobado por: ¡Error! Nombre
desconocido de propiedad de documento.
Cliente:
➢ Presenta actividades de seguimiento funcional para validar impacto posterior a un pase a producción.
➢ No se encuentra automatizado dentro del ciclo de vida.
2.6.2 Oportunidades de Mejora
✓ Se recomienda incorporar un actividad de validación de astisfacción de pase post-producción dentro del Workflow de Gestión de Mantenimientos / Proyectos.
(1) Pruebas de Componente: Tienen por objetivo localizar defectos y comprobar el funcionamiento de módulos de software, programas,
objetos, clases, etc., que puedan probarse por separado; se llevan a cabo mediante acceso al código objeto de las pruebas. Pueden
incluir pruebas funcionales y no funcionales, de robustez y estructurales.
(2) Pruebas de Sistema: Refieren al comportamiento de todo un sistema/producto. El entorno de pruebas debe ser una replica muy
similar al entorno productivo, pueden incluir pruebas basadas en riesgos y/o especificaciones de requisitos, procesos de negocio,
casos de uso u otras descripciones de texto de alto nivel.
3. Conclusiones
➢ La evaluación realizada ha puesto en evidencia que existen múltiples oportunidades
de mejora en todos los sub-procesos que han sido evaluados.
➢ Es necesaria la adecuación de los sub-procesos con las actividades realizadas en la práctica que no se ven reflejados en los modelos actuales de la Sección Calidad de Soluciones a fin de incorporar en ellos los detalles de ejecución reales.
➢ Se presentan actividades cuya ocurrencia no es adecuada en relación a la etapa en que se realizan.
➢ Los sub-procesos actuales sólo se enfocan a la certificación de software faltando además la certificación de hardware.
➢ No se contemplan actividades de gestión de la configuración.
➢ No se contempla una gestión de defectos.
➢ No presenta etapas de Revisión y Diseño de Pruebas.
➢ Se debería redefinir el objetivo del sub-proceso Seguimiento y Control y enfocarlo al seguimiento y control de las actividades y entregables realizados durante el ciclo de vida de Certificación.
➢ No se tiene un marco metodológico propio que de soporte a los sub-procesos de la Sección Calidad de Soluciones.
➢ No se tiene una gestión de la configuración asociada a un requerimiento de cambio y/o corrección para garantizar la trazabilidad y control sobre los artefactos ingresados y atendidos por la Sección Calidad de Soluciones.
