MODELO DE MEJORA BASADO EN ESTANDARIZACIÓN, REDISEÑO Y
REALIMENTACIÓN DE PROCESOS DE PRUEBAS DE DESARROLLOS DE
SOFTWARE PARA FUSION PARTNERS S.A.S
GABRIEL DAVID DIAZ CASTRO
LAURA TATIANA DIAZ CASTRO
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERIA
INGENIERIA INDUSTRIAL
BOGOTÁ
2016
2
MODELO DE MEJORA BASADO EN ESTANDARIZACIÓN, REDISEÑO Y
REALIMENTACIÓN DE PROCESOS DE PRUEBAS DE DESARROLLOS DE
SOFTWARE PARA FUSION PARTNERS S.A.S
GABRIEL DAVID DIAZ CASTRO
LAURA TATIANA DIAZ CASTRO
PASANTÍA EMPRESA FUSION PARTNERS
GUILLERMO ENRIQUE REAL FLOREZ
INGENIERO INDUSTRIAL
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERIA
INGENIERIA INDUSTRIAL
BOGOTÁ
2016
4
Dedicamos este trabajo a Gloria Janeth Castro quien ha sido nuestra fuente de motivación durante toda la vida.
5
AGRADECIMIENTOS
Nos gustaría que estas líneas sirvieran para expresar nuestro más profundo y sincero agradecimiento a las personas que con su ayuda han colaborado en la realización del presente trabajo, primeramente a Gloria Janeth Castro por su incondicional apoyo y colaboración; y en especial al Ing. Guillermo Enrique Real, director de este proyecto de grado, por la orientación, el seguimiento y la supervisión continúa de la misma, pero sobre todo por motivarnos e inspirarnos. Un especial reconocimiento por la oportunidad brindada a Alda Castillo y Roberto Rodríguez de la empresa Fusion Partners S.A.S., por quienes sentimos un profundo respeto, agradecimiento y cariño por el apoyo y la confianza en nosotros depositada. Quisiéramos hacer extensiva nuestra gratitud a nuestros compañeros del equipo de QA, por su colaboración en el suministro de los datos necesarios para la realización de la parte empírica de esta investigación. Y por supuesto, un sincero agradecimiento a nuestros familiares y amigos por su comprensión, colaboración y ánimo. A todos ellos, muchas gracias.
6
CONTENIDO
Pág.
1. INTRODUCCIÓN ...................................................................................................... 12
2. OBJETIVOS ................................................................................................................ 13
2.1 OBJETIVO GENERAL ........................................................................................... 13
2.2 OBJETIVOS ESPECÍFICOS ................................................................................. 13
3 PLANTEAMIENTO DEL PROBLEMA ........................................................................... 14
3.1 DEFINICIÓN DEL PROBLEMA .............................................................................. 14
3.2 JUSTIFICACIÓN .................................................................................................... 14
3.3 ALCANCE .............................................................................................................. 15
4. MARCO TEÓRICO ...................................................................................................... 16
4.1 FUNCIÓN DEL INGENIERO INDUSTRIAL ............................................................ 20
4.2 DESARROLLO DE SOFTWARE ............................................................................ 21
4.3 METODOLOGÍAS DE LAS EMPRESAS. ............................................................... 22
4.4 METODOS DE VALIDACION. ................................................................................ 23
4.5 ASEGURAMIENTO DE LA CALIDAD. ................................................................... 27
4.6 MODELOS. ............................................................................................................ 30
Los modelos de análisis............................................................................................ 31
Metodologías ágiles .................................................................................................. 31
Modelo en espiral. .................................................................................................... 33
La metodología AOPOA. .......................................................................................... 35
4.7 FACTORES INFLUYENTES EN LA CALIDAD. ...................................................... 36
4.8 ANTECEDENTES. ................................................................................................. 40
Antecedentes en ETB. .............................................................................................. 40
Antecedentes en TIGO de Honduras. ....................................................................... 42
5 SITUACIÓN INICIAL ..................................................................................................... 45
Descripción del sistema externo. .............................................................................. 45
Descripción del sistema interno. ............................................................................... 48
Análisis del sistema inicial. ....................................................................................... 50
5.1 FUNCIÓN DEL INGENIERO INDUSTRIAL EN LA SITUACIÓN INICIAL. .............. 50
5.2 CARACTERÍSTICAS PROPIAS DEL TRABAJO CON DESARROLLO DE
SOFTWARE EN LA SITUACIÓN INICIAL. ................................................................... 51
7
5.3 METODOLOGÍAS DE LAS EMPRESAS EN LA SITUACIÓN INICIAL. .................. 53
5.4 METODOS DE VALIDACIÓN EN LA SITUACIÓN INICIAL. ................................... 54
5.5 ASEGURAMIENTO DE LA CALIDAD EN LA SITUACIÓN. .................................... 55
5.6 MODELOS EN LA SITUACIÓN INICIAL. ............................................................... 56
5.7 FACTORES INFLUYENTES EN LA CALIDAD EN LA SITUACIÓN INICIAL. ......... 58
5.8 ANTECEDENTES EN LA SITUACIÓN INICIAL. .................................................... 59
Antecedentes en ETB. .............................................................................................. 59
Antecedentes en TIGO. ............................................................................................ 60
5.8 MODELO DE LA SITUACIÓN INICIAL. .................................................................. 60
Descripción del modelo de la situación inicial. .......................................................... 60
Diagrama del modelo de la situación inicial. ............................................................. 62
6 MODELO PROPUESTO BASADO EN EL FUNDAMENTO TEÓRICO. ........................ 63
6.1 FUNCIÓN DEL INGENIERO INDUSTRIAL EN EL MODELO. ................................ 65
6.2 CARACTERÍSTICAS PROPIAS DEL TRABAJO CON DESARROLLO DE
SOFTWARE EN EL MODELO. .................................................................................... 66
6.3 METODOLOGÍAS DE LAS EMPRESAS EN EL MODELO. ................................... 68
6.4 MÉTODOS DE VALIDACIÓN EN EL MODELO. .................................................... 70
6.5 ASEGURAMIENTO DE LA CALIDAD EN EL MODELO. ........................................ 73
6.6 MODELOS EN EL MODELO. ................................................................................. 76
6.7 FACTORES INFLUYENTES EN LA CALIDAD EN EL MODELO. .......................... 78
6.8 MODELO PROPUESTO. ....................................................................................... 80
Descripción del modelo............................................................................................. 80
Diagrama del modelo. ............................................................................................... 83
6.9 METODOLOGÍA DE LA EJECUCIÓN DEL MODELO PROPUESTO. .................... 84
7. RESULTADOS. ........................................................................................................ 88
8. DISEÑO DE LA RECOMENDACIÓN PROPUESTA. ............................................... 91
8.1 FUNCIÓN DEL INGENIERO INDUSTRIAL EN LA RECOMENDACIÓN
PROPUESTA. .............................................................................................................. 92
8.2 LAS CARACTERÍSTICAS PROPIAS DEL TRABAJO CON DESARROLLO DE
SOFTWARE EN LA RECOMENDACIÓN. .................................................................... 93
8.3 LAS METODOLOGÍAS DE LAS EMPRESAS EN LA RECOMENDACIÓN
PROPUESTA. .............................................................................................................. 95
8.4 LOS MÉTODOS DE VALIDACIÓN EN LA RECOMENDACIÓN PROPUESTA. 96
8
8.5 EL ASEGURAMIENTO DE LA CALIDAD EN LA RECOMENDACIÓN
PROPUESTA. ............................................................................................................ 101
8.6 LOS MODELOS EN LA RECOMENDACIÓN DE LA PROPUESTA. ................ 104
8.7 FACTORES INFLUYENTES EN LA CALIDAD EN LA RECOMENDACIÓN. ... 107
8.8 DESCRIPCIÓN DEL MODELO. ...................................................................... 111
8.9. Recomendaciones ............................................................................................... 115
Recomendaciones dirigidas a la empresa. ............................................................. 115
Recomendaciones para el lector del documento. ................................................... 115
9. COMPARACIÓN ENTRE SITUACIÓN INICIAL Y EL RESULTADO DE LA
IMPLEMENTACIÓN DEL MODELO. ............................................................................. 116
Medición de tiempo de las Pruebas. ....................................................................... 116
Cuadro comparativo de modelos. ........................................................................... 118
10. CONCLUSIONES .................................................................................................... 130
Bibliografía..................................................................................................................... 131
9
LISTA DE TABLAS
Tabla 1 Variables del agente herramientas tecnológicas. ................................................ 38
Tabla 2 Casos de pruebba ETB ....................................................................................... 41
Tabla 3 inventario de casos de prueba de portales .......................................................... 41
Tabla 4 de seguimiento de pruebas de portales ETB. ...................................................... 41
Tabla 5 Seguimiento de defectos de casos de prueba de portales ETB .......................... 42
Tabla 6 Casos de prueba de Tigo Honduras .................................................................... 43
Tabla 7 Matriz de procesos con responsabilidad de TIGO-Honduras .............................. 43
Tabla 8 Matriz de seguimiento a empotrados .................................................................. 43
Tabla 9 Matriz de seguimiento a consultas virtuales ........................................................ 43
Tabla 10 Manuales para usuario final .............................................................................. 44
Tabla 11 Cronograma ...................................................................................................... 85
Tabla 12 Matriz de diseño de casos de prueba. ............................................................... 88
Tabla 13 Matriz consolidada de seguimiento de desarrollo. ............................................. 89
Tabla 14 Matriz casos problema ...................................................................................... 89
Tabla 15 Medición de pruebas modelo inicial. ............................................................... 116
Tabla 16 Medición de pruebas modelo inicial. ............................................................... 117
Tabla 17 Medición de pruebas aplicado el modelo. ....................................................... 117
Tabla 18 Medición de pruebas modelo inicial. ............................................................... 118
Tabla 19 Cuadro comparativo entre modelos ................................................................ 119
Tabla 20 Cuadro comparativo entre modelos ................................................................ 120
Tabla 21 Cuadro comparativo entre modelos ................................................................ 122
Tabla 22 Cuadro comparativo entre modelos ................................................................ 123
Tabla 23 Cuadro comparativo entre modelos ................................................................ 125
Tabla 24 Cuadro comparativo entre modelos ................................................................ 127
10
LISTA DE GRÁFICAS
Ilustración 1Logo Fusion Partners S.A.S ......................................................................... 16
Ilustración 2 Proceso experimental (Wohlin) .................................................................... 24
Ilustración 3 Investigación basada en casos de estudio. .................................................. 25
Ilustración 4 esfuerzo Vs tiempo ...................................................................................... 26
Ilustración 5Factores que intervienen en la evaluación "dura" ......................................... 29
Ilustración 6 Costo del desarrollo Vs Avance de la programación del desarrollo .............. 33
Ilustración 7 Modelo en Espiral común propuesto por Boehm. ......................................... 34
Ilustración 8 Relación entre Agentes................................................................................ 47
Ilustración 9 Diagrama de flujo en los H.L.D .................................................................... 57
Ilustración 10 Proceso de pruebas de Software para el modelo inicia .............................. 61
Ilustración 11 Modelo de la situación inicial. .................................................................... 62
Ilustración 12 Proceso de pruebas de desarrollos de software para Entel modelo
propuesto ........................................................................................................................ 82
Ilustración 13 Diagrama del modelo ................................................................................. 83
Ilustración 14 Vista de los casos desde CLM. .................................................................. 90
Ilustración 15 Vista del ambiente ..................................................................................... 90
Ilustración 16 Proceso de pruebas de desarrollos de software para Entel modelo final. 113
Ilustración 17 Diagrama en espiral recomendado .......................................................... 114
11
GLOSARIO
HLD: (High level design), documento que presenta de manera general el diseño de
cómo suplir el requerimiento desde el programa, guiando al desarrollador en la
implementación.
LLD: (low level design), que es el documento en el que el desarrollador plasma
específicamente su implementación en el sistema para cumplir con la regla de
negocio, incluyen componentes involucrados en el desarrollo, las integraciones y
los objetos de Siebel (pantallas, applets, objetos de negocio, workflow, entre otros)
que van a verse involucrados.
Sanity: en el interactúan todas las funcionalidades y desarrollos de los sistemas,
esto se realiza con la asistencia de los desarrolladores, arquitectos y líderes de todo
el Proyecto.
Release: Se trata de ingresar los requerimientos complejos para que se integren
con otras aplicaciones y que las actualizaciones que se vayan haciendo se vean
versionadas
12
1. INTRODUCCIÓN
Este documento describe el proceso de desarrollo de la pasantía “Modelo de mejora basado en estandarización, rediseño y realimentación de procesos de pruebas de desarrollos de software para Fusion Partners S.A.S”, con el fin de cumplir con los requisitos académicos y empresariales para su sustentación y aprobación. A través del siguiente documento se pueden identificar 3 etapas principales del proyecto las cuales fueron presentadas en torno a los aspectos principales considerados durante este, para hacer entrega de un modelo de mejora basado en estandarización, rediseño y realimentación de los procesos en las pruebas de desarrollo de software para Fusion Partners S.A.S.
I. Situación Inicial, Es el estado de la empresa al iniciar las pasantías. II. Modelo propuesto, Es el modelo que se implementa en la empresa durante
el proyecto. III. Recomendación del modelo para la empresa, Es la mejora a implementar en
el modelo propuesto de acuerdo con su evolución y a las deficiencias identificadas durante su ejecución.
De igual forma, se encontrará información asociada a diversos modelos aplicables al sector del desarrollo de software y su área de calidad, comparada y realimentada con la experiencia del equipo de trabajo y la organización, en proyectos recientes desarrollados para las empresas ETB y Tigo de Honduras. Así como la información de la aplicación del modelo propuesto, con sus resultados y las observaciones para los ajustes del modelo como recomendaciones para la empresa. .
13
2. OBJETIVOS
2.1 OBJETIVO GENERAL
Proponer modelo de mejora de procesos de pruebas y realimentación de desarrollos de software, mediante la estandarización de procesos y creando manuales de procedimientos, (requerimiento de la empresa); facilitando desarrollo de pruebas, capacitación y comunicación interna, y cumpliendo los requerimientos del cliente enfocados en reducir tiempos y costos de gestión.
2.2 OBJETIVOS ESPECÍFICOS
Comprender el sistema actual mediante la definición de la estructura de procesos, los factores y variables que permiten su relacionamiento, especificando los pasos iniciales de la reestructuración. Generar una propuesta procedimental a través de la estandarización de procesos, mediante técnicas propias de la ingeniería industrial, para ser socializadas y ajustadas. Contrastar la aplicación de la propuesta desarrollada con los proyectos en ejecución, verificando su eficiencia con los indicadores y medidas de desempeño actuales de la empresa. Documentar el proyecto, cumpliendo con los requisitos académicos y empresariales para su sustentación y aprobación
14
3 PLANTEAMIENTO DEL PROBLEMA
3.1 DEFINICIÓN DEL PROBLEMA
La empresa Fusion partners S.A.S. es una consultora especializada en Customer
Relationship Management (CRM) y procesos de Order Management. Diseña,
desarrolla e implementa las soluciones tecnológicas, cuyos procesos varían
conforme a los requerimientos de cada cliente, país y proyecto, por lo que le es
exigida de manera indispensable la estandarización de cada uno de los desarrollos
que genera, de manera que cada cliente debe obtener junto con el resultado final,
los soportes de cada proceso que pueda desempeñar sobre las implementaciones;
para esto la empresa requiere aplicar un control de calidad que garantice el buen
desempeño de sus resultados y servicios mediante la aplicación de pruebas al
sistema.
Se identifica la necesidad de un modelo de mejora a los procesos y procedimientos
básicos en el desarrollo de pruebas y realimentación de desarrollos de software,
también la estandarización de procesos por medio de manuales, matrices y
diagramas; control de calidad y diseño de pruebas con sus ciclos, según
requerimiento de la empresa.
Se requiere aplicar estandarización de procesos, análisis de métodos y tiempos,
el control de calidad, diseño y propuesta de mejoras de calidad del área de pruebas
de desarrollos, aplicado a los procesos que la empresa considere necesarios, ya
sea para ETB (Colombia), para Tigo (Honduras) o Entel (Chile y/o Perú) tanto en
los ambientes de prueba como en portales y en la plataforma de producción.
3.2 JUSTIFICACIÓN
El desarrollo de este proyecto pretende resolver cuál es el modelo específico de
mejora para los procesos de pruebas de desarrollo de software dentro de la
empresa según su naturaleza, siendo la documentación de la estandarización de
procesos y procedimientos un requerimiento obligatorio del cliente (en primera
instancia) y la mejora de los procesos implicados.
Los procedimientos y comportamientos de los desarrollos al integrarse a la
plataforma presentan la necesidad de ser analizados, documentados, rediseñados
y estandarizados para el acceso y dominio general. Al Considerar que en estos
procesos se involucran consultores y ambientes de diferentes países, es necesario
15
incluir todos los casos por su magnitud, complejidad y variedad para reducir
tiempos de capacitación y garantizar la universalidad de información al igual que la
eficiencia de los procesos de pruebas.
Es por este motivo que empresarialmente urge su implementación para hacer frente
a los procesos redundantes, innecesarios, inadecuados y agotadores, así mismo
como la falta de una clara estandarización y rediseño de procesos, lo que se traduce
en un mayor tiempo, el aumento innecesario de costos de honorarios, multas por
exceder los plazos de entrega y daños en integraciones o modificaciones no
deseados en los ambientes.
Por último, la empresa considera indispensable el desarrollo de este proyecto con
mínimo dos integrantes por el tamaño de cada proyecto, la cantidad de procesos
implicados y las condiciones de ubicación geográfica de la organización y sus
clientes (Chile, Perú, Honduras y Colombia); debido a que el modelo debe ser
implementado directamente en la(s) sede(s) del (los) cliente(s) para su
socialización, verificación y posible corrección lo cual puede implicar que ambos
integrantes tengan que viajar a los países implicados.
3.3 ALCANCE
El modelo de mejora basado en estandarización, rediseño y realimentación de
procesos de pruebas de desarrollos de software para Fusion Partners S.A.S., está
dirigido y limitado a los procesos realizados por el equipo de calidad y pruebas a
desarrollos (QA) de la empresa; Asimismo la información recopilada y analizada
de los procesos iniciales, la aplicación del modelo propuesto, el análisis de
resultados y la propuesta de recomendación, están centradas en los procesos de
pruebas de desarrollos de software realizadas por el equipo de QA de la empresa.
Otros elementos limitantes del alcance de este proyecto están ligados a los
recursos disponibles, por lo que la mejora que se incluye en el modelo es una
mejora organizacional, y las solicitudes del cliente al respecto. El tiempo destinado
para el desarrollo de la totalidad de este proyecto es de 5 meses (de Junio a
Octubre del año 2016), periodo en el que los autores deben culminar el proyecto
en la empresa. Por último, la empresa considera indispensable el desarrollo de
este proyecto con mínimo dos integrantes por el tamaño de cada proyecto, la
cantidad de procesos implicados.
16
4. MARCO TEÓRICO
Fusion Partners es una consultora especializada en Customer Relationship
Management (CRM) & procesos de Order Management. Desde su diseño hasta su
implantación e integración presupone un conocimiento profundo de estos sistemas
así como de las mejores prácticas de CRM para la industria; está asegura
estrategias de calidad y entrega al tiempo.
En Fusion Partners diseñan, desarrollan e implementan las soluciones tecnológicas
más adecuadas para cada cliente. Su experiencia se basa en un equipo central de
profesionales con más de 10 años de experiencia en la implementación de sistemas
CRM en empresas de distintos lugares del mundo desde las áreas de banca,
telecomunicaciones, administración pública y Laboratorios. Su implementación es
realizada por especialistas en cada área ofreciendo un camino seguro para la
implementación de proyectos de riesgo medio/ alto, así como un menor overhead
administrativo.
Logo:
Ilustración 1Logo Fusion Partners S.A.S
Fuente 1 C.V. Empresarial
Misión:
Diseñar, desarrollar e implementar las soluciones tecnológicas más adecuadas para
cada cliente, independientemente de la plataforma o tamaño del cliente, asegurando
un camino exitoso hacia su puesta productiva.
Visión:
Ser un referente en el mercado mundial de CRM. (CX y Cloud Apps)1
1 RODRIGUEZ, Roberto, Pagina inicial empresa Fusion Partners. [En línea].Argentina; [Rev. 29 Julio 2016]. Disponible en internet: http://www.fusionpartners.com.ar
17
Valores:
El equipo de Fusion Partners es el activo más importante de la compañía, por lo
tanto el compromiso con los empleados es uno de los valores más altos, así como
la pasión por lo que hacemos, la seriedad y el esfuerzo que comprometemos en
cada proyecto.
Integridad - Soy congruente cuando pienso, comento y hago.
Compromiso - Soy comprometido cuando consistentemente y sin
desviaciones cumplo todas las promesas que hago libremente
con responsabilidad y disciplina, haciendo lo necesario para que ocurra lo
que prometí.
Empatía - Soy empático con las personas cuando asumo su posición y hago
lo necesario para entenderla buscando una solución balanceada entre sus
intereses y los míos
Calidad - Es una forma de vida, un proceso metódico y permanente que nos
permite cumplir las expectativas de nuestros clientes, haciéndolo bien a la
primera.
Entusiasmo - Soy entusiasta cuando estoy en búsqueda de retos continuos,
cada vez más ambiciosos. Me entusiasmo cuando enfrentó un desafío que
me hace evolucionar, tomar riesgos, superar mis temores y contagiar a todo
aquél que se identifique conmigo.
Flexibilidad - Soy flexible cuando me adapto a diferentes ambientes y
personas. Ser flexible me da la posibilidad de dialogar, crear alternativas y
adecuarlas al contexto presente.
Sinergia - Logro sinergia cuando uno mis esfuerzos a los de un grupo para
multiplicar nuestras fortalezas y alcanzar grandes metas, más allá de la suma
de los esfuerzos individuales.
“El éxito de nuestros clientes es nuestro éxito”2
Ubicación:
Cualquier lugar del mundo donde podamos agregar valor en base a nuestra
experiencia y capacidades.3
2 Fusion Partners. Hoja de vida corporativa. Volumen 4. Bogotá D.C. 3 p. 3 Ibíd., p. 4.
18
Página web:
La página web de la empresa es: http://www.fusionpartners.com.ar/servicios.html
Servicios:
“Si bien la empresa nació enfocada en la implementación de proyectos CRM,
actualmente cuenta con un amplio portafolio de servicios, que incluyen la orientación
para brindar exclusivamente servicios de consultoría especializada en tecnologías
de información.
Sus servicios consideran un conocimiento técnico y funcional en soluciones
tecnológicas que puedan necesitar las empresas para mejorar sustancialmente su
operación y el área de negocio. Por ello, para garantizar el éxito de la inversión y
adecuada puesta en marcha del sistema adquirido, Fusion Partners cubre todos los
elementos necesarios que involucra este tipo de iniciativas tecnologías que sólo
incluyen elementos que conjuntamente con el cliente se establecen dentro de los
siguientes parámetros:
1. Asesoría en la adquisición y licenciamiento de la solución
2. Metodología de implementación y mejores prácticas
3. Arquitectura técnica
4. Servicios profesionales de consultoría
5. Capacitación funcional y técnica
6. Soporte y mantenimiento.
Nuestras áreas de acción incluyen:
1. Preventa
2. Venta
3. Consultoría
a. Front End (CRM y Portales),
b. Integración del Contact Center (ACD, PBX, IVR, CTI, Mail Managers, Web, etc.)
c. Integración Back End (Sistemas ERP, Arquitectura EAI, Sistemas Legacy, etc.)
d. Desarrollo e Integración eBusiness
e. Desarrollos a la medida (“Llave en Mano”)
4. Capacitación
5. Soporte Técnico y Mantenimiento
Preventa: Apoyo a la culturización del cliente en la filosofía CRM, tecnologías de
ERP y Portales de Internet así como la estimación inicial de requerimientos y
19
componentes involucrados en la solución del cliente. Adicionalmente se
proporcionan demostraciones y prototipos en caso necesario.
Análisis de Solución: Certificación de alcances y estimación de recursos y tiempos
de ejecución, congelando alcances y compromisos adquiridos.
Implementación de la Solución: Cuenta con herramientas y metodología (Change
Management, Análisis, Diseño, Configuración / Customización, Construcción, Roll
Out y Soporte a Producción) especializadas en el desarrollo de las soluciones e
implementación de aplicaciones, considerando la calidad y asegurando y apoyando
la entrada en producción adecuada.
Nuestros consultores están calificados en:
Oracle Soluciones
Siebel CRM Prime
Oracle CRM On Demand
PeopleSoft Enterprise CRM (Tools and functionality)
PeopleSoft Enterprise ERP y HMS (Tools).
RightNow CX Cloud Service.
Oracle SOA Suite
Oracle AIA y PIP’s
Oracle Fusion Middleware
Oracle Business Intelligence
Oracle BRM
Oracle OSM
Herramientas de desarrollo (JDeveloper, PL-SQL, Forms, Reports, ADF, etc.)
Oracle Siebel EAI and PeopleSoft Integration Broker.
Microsoft
Microsoft Shared Point
Content Management DotNetNuke.
Desarrollo “llave en mano” en: Microsoft Silverlight.NET y Microsoft VisualStudio y
C++
Soluciones Java y Open Source
Java 8 SDK
Java 7 EE
JBoss Middleware
Netbeans
Apache projects”4
4 Fusion Partners. Hoja de vida corporativa. Volumen 4. Bogotá D.C. 5,6 p.
20
4.1 FUNCIÓN DEL INGENIERO INDUSTRIAL
Esta documentación se realiza como informe final de pasantías de ingeniería
industrial en la empresa Fusion partners, siendo una aplicación de los
conocimientos obtenidos a través de la carrera y apoyados en el siguiente marco
teórico, partiendo desde el rol del ingeniero industrial en la organización.
El rol principal del ingeniero Industrial es ser gestor de procesos dentro de las
organizaciones, generando la articulación de las diferentes áreas de la empresa
para la consecución de la metas5, aplicando el diseño, la mejora e instalación de
sistemas integrados de hombre, materiales y equipo6; en este caso será dirigido a
las funciones técnicas y administrativas (organizar, dirigir, coordinar) de la
organización7.
A parte de permitir un acercamiento a la optimización de procesos de transferencia
interna de conocimiento, al ubicar cada proceso en documentos escritos de fácil
acceso y comprensión para cualquier persona del equipo de trabajo; también se
aportará al control de la calidad teniendo en cuenta que toda organización debe
tener mecanismos para asegurar la calidad de sus productos, y para el caso
específico de la calidad del software se tienen como directivas: los estándares
(IEEE, ISO, etc.), las revisiones y auditorías, las pruebas de software, colección y
análisis de errores, administración del cambio, de proveedores, de seguridad,
educación, seguridad y administración de riesgos.8
5 PEÑA, Javier Parra. La ingeniería industrial en el contexto del desarrollo sostenible. Revista
Tecnura, 1999, vol. 2, no 4, p. 28
6 PARRA DÍAZ, Cristian Andrés; PRIETO BARRIGA, Jorge Andrés. Estudio del estado del arte y
tendencias educativas en universidades de Finlandia y Noruega en el programa de Ingeniería Civil
como parte de un análisis prospectivo para Colombia. 2014.
7 FAYOL, Henri; TAYLOR, Frederick Winslow. Administración industrial y general. Orbis, 1987. p 2,3. 8 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. p 28.
21
4.2 DESARROLLO DE SOFTWARE
Históricamente, el proceso de desarrollo de software ha resultado caro, riesgoso,
incierto y demasiado lento para las condiciones de negocio modernas.
Estos inconvenientes dieron origen al concepto de “crisis del software”9 a la que se
hace frente por medio de la ingeniería de software es la aplicación de un enfoque
sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de
software, que exige adaptabilidad y agilidad como una tecnología con varias capas
basadas en un compromiso organizacional con la calidad, de la que parten los
procesos, sobre los que se eligen los métodos y finalmente se aplican las
herramientas10.
El proceso para implementar un desarrollo de software no es una tarea fácil11, son
procesos muy intrincados y complejos12, es un tema que a cada empresa de
software le incumbe de manera radical; ya que a partir de su desarrollo se forma la
calidad y reconocimiento en la industria, la organización de recursos13, el tiempo de
entrega14 y la complejidad en los requerimientos15 hace que sea difícil de
administrar. El software es un producto transformador de información (al producir,
administrar, adquirir, modificar, desplegar o transmitir) y un vehículo para la
distribución productos (sistemas operativos, redes de comunicación, creación de
ambientes de software y herramientas de control), de lo que resulta de suma
importancia en las empresas el manejo de información16.
Las validaciones de cada requerimiento y las generales, han sido de vital
importancia tanto para empresas desarrolladoras de software como para sus
clientes, de manera que se ha recurrido a capacitaciones, cursos y conferencias de
9 PONS, Claudia; GIANDINI, Roxana Silvia; PÉREZ, Gabriela. Desarrollo de software dirigido por modelos. 2010. p 23. () 10 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. p 11. () 11 CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. Metodologías Ágiles en el Desarrollo de Software, 2003, p. 1. () 12 BUSTOS, Ricardo A. Gacitúa. Métodos de desarrollo de software: El desafío pendiente de la estandarización. Theoria, 2003, vol. 12, p 31. () 13 PINO, Francisco; GARCÍA, Félix; PIATTINI, Mario. Revisión sistemática de mejora de procesos software en micro, pequeñas y medianas empresas. Revista Española de Innovación, Calidad e Ingeniería del Software, 2006, vol. 2, no 1, p 19. () 14 BUSTOS, Ricardo A. Gacitúa. Métodos de desarrollo de software: El desafío pendiente de la estandarización. Theoria, 2003, vol. 12, p 26. () 15 CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. ()Metodologías Ágiles en el Desarrollo de Software, 2003, p 4. 16 PRESSMAN, Roger S.; TROYA, José María. Ingeniería del software. McGraw Hill, 1988. ()
22
alto nivel17 en pro del avance de este sector. Se pretende aprovechar de las
características propias del software cómo: su desarrollo a partir de intelecto, su
progresiva mejora, su no desgaste y su construcción para uso individualizado; ya
sea para software de sistemas, de aplicación, de ingeniería y ciencias, software
incrustado, de línea de productos, de aplicaciones de web o de inteligencia
artificial18.
4.3 METODOLOGÍAS DE LAS EMPRESAS.
Cada empresa debe tener una metodología personalizada de acuerdo con sus
condiciones19, en las actividades relacionadas al conocimiento implican métodos
con un nivel propio de sofisticación y formalidad para llevar a cabo el cumplimiento
de sus funciones y facilitar el manejo de información y la comunicación20; así como
la normalización de sus protocolos y procesos de producción o verificación del nivel
de calidad de sus resultados, especialmente cuando sus procesos son de software,
pues implica desde el uso de un vocabulario común (la precisión terminológica), la
definición de las unidades de medida, el consenso del conocimiento (consolidado
de la experiencia), las categorizaciones de elementos a considerar (recursos,
condiciones, herramientas, insumos, etc.), la transferencia tecnológica para el
desarrollo de conocimiento y el buen funcionamiento de la organización21;
Las metodologías dependen del área sobre la cual se desee centrar la atención para
generar mejoras o cambios, pues para cada una de las actividades y fases de los
diferentes proyectos existen tantas metodologías como proyectos u organizaciones
existan, debido a que cada uno de ellos debe diseñar su metodología
específicamente adaptada a sus requerimientos, recursos, herramientas, insumos
y plazos. Por ejemplo al final del capítulo se habla de la metodología usada para el
caso del sector de software de Barranquilla22, es una metodología muy específica
de clasificación y valoración de las características dentro del marco del desarrollo,
17 CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. Metodologías Ágiles en el Desarrollo de Software, 2003, p. () 18PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. p 6 (). 19 CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. Metodologías Ágiles en el Desarrollo de Software, 2003, p.4 () 20 BUSTOS, Ricardo A. Gacitúa. Métodos de desarrollo de software: El desafío pendiente de la estandarización. Theoria, 2003, vol. 12, p 25. 21 MUÑOZ, Coral Calero; VELTHUIS, Mario G. Piattini; DE LA RUBIA, María Ángeles Moraga. Calidad del producto y proceso software. Editorial Ra-Ma, 2010. () 22 CARUSO, Nohora Nubia Mercado; DEL CASTILLO, Edwin Puerta; NAVARRO, Katherinne Salas. Mejora de los procesos de estimación de costos de software: Caso del sector de software de Barranquilla. Revista de Ingenierías: Universidad de Medellín, 2015, vol. 14, no 27, p. 24.
23
que reúne en tres grupos los diversos niveles de las organizaciones según sus
especificaciones individuales.
En este proyecto se desarrolla el modelo entorno a los procesos de pruebas de
desarrollos, cuya principal función es la validación del cumplimiento de requisitos y
el control de calidad del proceso de producción de desarrollos, por lo que a
continuación se profundiza en los métodos o metodologías de validación usadas en
proyectos y empresas.
4.4 METODOS DE VALIDACION.
Los métodos de validación son básicamente revisiones del software usadas para
identificar defectos y errores para corregirlos antes de realizar la entrega al cliente,
ya que los desarrollos son realizados por personas, por lo que naturalmente
equivocarse y posiblemente no detectarlo, de modo que preferiblemente la revisión
la realizan otras personas; su uso se extiende incluso a la identificación de posibles
mejoras23. Las revisiones pueden realizarse informales realizadas por personal del
equipo de trabajo (reuniones casuales, desde el puesto de trabajo sin
especificaciones) o revisiones técnicas formales realizadas por especialistas que
evalúan aspectos muy específicos: lógica, estructura, estándar, uniformidad, etc.
(en reuniones, reporte y registro, orientadas al muestreo, entre otros)24.
Existen métodos de para la validación de los desarrollos empíricos (ingeniería de
software basada en la evidencia) que pueden ser: experimentos (control de
variables para comprobar efecto), encuestas (cuantitativas y cualitativas en
retrospectiva para conclusiones descriptivas) y casos de estudio(siguiendo uno o
varios atributos para establecer relaciones); y sabiendo que no existe una
metodología universal exitosa aplicable a cualquier proyecto de desarrollo de
software, ya que a cada proyecto debe adaptarse una metodología según el
contexto propio, a pesar de los múltiples esfuerzos por abarcar la mayoría de
factores a considerar en cualquier proyecto, siempre requiere esfuerzo y trabajo
adaptarlos al tamaño de cada proyecto y los cambios que los mismos pueden sufrir
en muy poco tiempo; teniendo en cuenta los recursos técnicos, recursos humanos,
tiempo de desarrollo disponible, tipo de sistema, entre muchos otros aspectos del
23 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 354. 24 IBID p 392.
24
equipo de trabajo, por lo que cada metodología debe recurrir a la sencillez en
aprendizaje y aplicación25.
Experimentos: identificar relaciones causales siguiendo un proceso con los pasos
detallados (entradas, paso-acción, salida), incluye los siguientes 5 pasos: Definición
(por qué y objetivos), Planificación (como), Operación, Análisis e interpretación y
Presentación y difusión.
Ilustración 2 Proceso experimental (Wohlin)
Fuente 2 Pressman, R. S., & Troya, J. M. (1988). Ingeniería del software (No. 001.64 P74s.). McGraw Hill.
Encuestas: Para capturar el estado de una organización tras usar una técnica o
herramienta para evaluar el impacto mediante la recolección de información de los
individuos relacionados, quienes proporcionan detalles acerca del proceso, puede
ser supervisada, se diseña con resultados esperados fijos.
Casos de uso: Incorporan cualidades como la escala, complejidad, falta de
predictibilidad y dinamismo, puede ser un caso de estudio único (extremo,
representativo o crítico) o múltiples (análogo, más sólido), puede ser embebido u
holístico. Sus etapas son diseño y planificación, recopilación de evidencias26
25 CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. Metodologías Ágiles en el Desarrollo de Software, 2003, p.6. 26 MUÑOZ, Coral Calero; VELTHUIS, Mario G. Piattini; DE LA RUBIA, María Ángeles Moraga. Calidad del producto y proceso software. Editorial Ra-Ma, 2010.
25
Ilustración 3 Investigación basada en casos de estudio.
Fuente 3 MUÑOZ, Coral Calero
La revisión puede medirse y emplearse para verificar la calidad de los desarrollos y
la eficiencia del equipo de validación, junto con la corrección de defectos y errores.
Algunos de los factores que podemos tener en cuenta en este documento como
métricas de revisión del proyecto son:
El tiempo de preparación para la revisión
El tiempo que se usa para la revisión
El tiempo promedio en detectar un error no detectado durante revisión
El tiempo dedicado a corregir los defectos detectados durante la revisión
El tiempo dedicado a corregir los defectos no detectados durante la revisión
El tamaño del trabajo (para el proyecto se considerará por pasos del caso de
uso)
Errores menores detectados durante la revisión
Errores mayores detectados durante la revisión
Errores no detectados durante la revisión
Con estas medidas puede realizarse el cálculo de:
Tiempos totales de revisión y corrección
El tiempo promedio en detectar un error no detectado durante revisión y
corrección.
Total de errores detectados
Densidad de errores, dividiendo el total de errores detectados durante la
revisión en los tiempos totales
La eficacia de las revisiones:
26
Ahorro de tiempo por error: Al tiempo promedio en detectar un error no
detectado durante revisión y corregirlo se le resta el tiempo total de revisión
y corrección.27
Entre otras posibilidades según considere el equipo de trabajo y adaptados al
proyecto.
La aplicación de métodos de validación de desarrollos, ser relaciona directamente
con la búsqueda del aseguramiento de la calidad, se aplican con el nivel de
formalidad apropiado para cada organización (roles de revisores, preparación,
estructura, seguimiento, etc.) y tipo de producto según la disponibilidad de tiempo,
capacidad y recursos; su principal efecto en el tiempo se puede apreciar en la
ilustración 4 esfuerzo Vs tiempo que representa el tiempo que toma un proyecto
cuando aplica o no revisiones o validaciones28.
Ilustración 4 esfuerzo Vs tiempo
Fuente 4 Pressman, R; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. p 360.
Para las pruebas existen estrategias que usan las características de este método
para optimizar el proceso, pues son actividades que pueden planearse por
adelantado y realizarse sistemáticamente, se deben realizar revisiones técnicas
efectivas de la documentación disponible para que al llegar el momento de realizar
la prueba sea efectiva, probar partiendo de los componentes e ir hacia las
integraciones. Las técnicas son adaptables a los enfoques, dedicar un equipo a
realizar pruebas y el incluir la depuración en el proceso de pruebas29. Debido al
tiempo en el que se desarrolla esta documentación las pruebas que se incluirán
serán muy básicas, pues el avance del proyecto no cubre en 6 meses la totalidad
de los desarrollos básicos, ni por supuesto las pruebas de integraciones o de
27 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988.p 359. 28 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. p 360. 29 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. p 384.
27
sistema. Sin embargo se pueden tener a consideración aspectos estratégicos útiles
como: la cuantificación de los requerimientos antes de iniciar, establecer
explícitamente los objetivos de las pruebas, considerar el perfil del usuario,
desarrollar un plan de pruebas de “ciclo rápido”, filtrar durante la revisión previa,
revisión técnica de diseños de pruebas y el enfoque en la mejora continua del
proceso de prueba30
4.5 ASEGURAMIENTO DE LA CALIDAD.
El proyecto se desarrolla dentro del área de calidad de la empresa en la cual se
realizan procesos de pruebas a los desarrollos de software, que realizan los
desarrolladores, por lo cual se tiene en cuenta información asociada al
aseguramiento de la calidad que pueda servir de guía y que nutra el modelo a
proponer considerándola.
Los elementos básicos del aseguramiento de la calidad incluyen los estándares
(IEEE, ISO), las revisiones técnicas, las auditorías, pruebas, colección y análisis de
errores, administración del cambio, educación, de seguridad y riesgos. Todos estos
elementos se integran para ser un apoyo que garantice la calidad del producto final
mediante tareas como planear, describir, identificar, auditar, registrar y documentar
todos los procesos a considerar, así como los errores o defectos31. Las ISO 9000
son un conjunto de normas usadas con estándar de estructura organizacional,
responsabilidades, procesos, procedimientos y recursos para implementar
administración de calidad.32
En el aseguramiento de la calidad se mide la eficacia del control de calidad en
relación con la asignación de recursos, la tasa de finalización, la eficacia de la
revisión y de las pruebas; siendo la propuesta de mejora de procesos un camino
hacia el efecto final deseado de la aplicación de esta práctica sobre la el proyecto
de la empresa, mejora en la calidad y eficiencia en los procesos; el compromiso
30 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. p 389. 31 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 371, 174. 32 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 379.
28
organizacional con la calidad implica la administración total de la calidad, six sigma
en busca de alimentar la cultura de la mejora continua33.
Según David Garvin la calidad en el software vista de manera multidimensional
posee 8 dimensiones: desempeño, características, confiabilidad, conformidad,
durabilidad, servicio, estética y percepción34; sin embargo, debido a que este
documento solo se ocupará de la calidad dentro de los límites propios de su función
dentro de la organización y debido a que los desarrollos, que están atados a las
capacidades y características propias de Siebel, se consideran únicamente
desempeño, confiabilidad, conformidad y el servicio en el modelo que se propone al
proceso de pruebas de desarrollos; estos factores serán usados para tener en
cuenta una evaluación “suave” de la calidad de los desarrollos a probar durante el
proyecto.
La calidad del desempeño evalúa si se cumple con el contenido, las
características especificadas y las funciones requeridas por el cliente dando
valor al usuario final.
La confiabilidad implica el cumplimiento de todas las características y
capacidades sin presentar fallas, que funciona cuando se requiere y está libre
de errores.
La conformidad concuerda con los estándares locales y externos relevantes,
con el diseño y condiciones deseadas.
El servicio considera la posibilidad de un mantenimiento o correcciones en
caso de ser necesario.
La evaluación “dura” evalúa factores que pueden ser medidos de forma directa
(defectos, tiempos, etc.) o de manera indirecta (usabilidad, mantenimiento,
correcciones, etc.)35
33 Ibíd. p 11. 34 Ibíd. 341. 35 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 349.
29
Ilustración 5Factores que intervienen en la evaluación "dura"
Fuente 5 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 342.
La metodología de estrategia seis sigmas para la ingeniería de software es usada
para el aseguramiento de la calidad por ser rigurosa y disciplinada en el uso de
datos estadísticos, la cual contiene las siguientes etapas:
Definir (requerimientos y metas solicitados y entregados)
Medir (procesos y resultados)
Analizar (métricas de defectos y determinar causas vitales)
Mejorar (proceso eliminando causas)
Controlar (proceso para evitar que vuelvan las causas)
Diseñar (proceso para evitar que vuelvan las causas y cumplir
requerimientos)
Verificar(modelo que evite defectos y cumpla requisitos)
La aplicación de las metodologías lleva a reducir la cantidad de interacciones entre
los agentes del sistema, evita los conflictos por recursos, reduce la redundancia en
las habilidades asociadas a cada rol o proceso, y toma en cuenta el conocimiento
previo del problema36 37
La calidad tiene su costo, que es el resultado de todo aquello a lo que se incurre
para buscarla, ya sea en tiempo o dinero y ya sea por prevención, evaluación o falla.
Si son costos de prevención incluyen las actividades de administración necesarias
para la gestión de las actividades de control y aseguramiento de la calidad, las
36 RODRÍGUEZ, Julián; TORRES, Miguel; GONZÁLEZ, Enrique. La Metodología AOPOA. Avances en Sistemas e Informática, 2007, vol. 4, no 2. () 37 PRESSMAN, Roger S.; TROYA, José María. Ingeniería del software. McGraw Hill, 1988. P 375.
30
actividades técnicas agregadas para los diseños y modelado de requerimientos, la
planeación de pruebas y capacitaciones asociadas. En cuanto a los de evaluación
están incluidas las actividades de investigación sobre los casos recurrentes,
revisiones técnicas, tomas de medidas, hacer pruebas y depurar. Finalmente los de
falla son aquellos que se eliminarían si no llega el producto con errores al cliente,
pueden ser internos (antes de ser entregado: repeticiones, efectos colaterales y
asociados) o externos (después de ser entregados: soluciones, quejas, cláusulas,
devoluciones sustituciones, garantía, reputación, etc.)38
4.6 MODELOS.
Para el desarrollo del modelo de mejora se involucran diferentes tipos de modelos
o métodos 39, sabiendo que un modelo es una abstracción formada por variables y
conceptos interrelacionados para dar una explicación coherente del funcionamiento
organizacional40, se tomará en cuenta las condiciones propias de la empresa para
ajustar métodos y modelos tomados de referencias académicas encontradas como:
representación de programas y procesos por diagramas de flujo41, metodologías
ágiles42 43 44, propuestas de mejora45, el modelo en espiral46, modelos de análisis47,
metodología AOPOA48.
Los diagramas de flujo son usados para el diseño y análisis estructurado en la
ingeniería de software para tener control intelectual sobre la complejidad de los
sistemas, por medio de modelos conceptuales útiles en la comprensión y solución
38 Ibid. P 347. () 39 PINO, Francisco; GARCÍA, Félix; PIATTINI, Mario. Revisión sistemática de mejora de procesos software en micro, pequeñas y medianas empresas. Revista Española de Innovación, Calidad e Ingeniería del Software, 2006, vol. 2, no 1, p 19. 40 RODRÍGUEZ MANCILLA, Darío. Diagnóstico organizacional. Alfaomega. Ediciones Universidad Católica de Chile, 2005. 41 BUSTOS, Ricardo A. Gacitúa. Métodos de desarrollo de software: El desafío pendiente de la estandarización. Theoria, 2003, vol. 12. P 42 42 BUSTOS, Ricardo A. Gacitúa. Métodos de desarrollo de software: El desafío pendiente de la estandarización. Theoria, 2003, vol. 12, p . 28 43 CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. Metodologías Ágiles en el Desarrollo de Software, 2003, p. 2 44 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 45 PINO, Francisco; GARCÍA, Félix; PIATTINI, Mario. Revisión sistemática de mejora de procesos software en micro, pequeñas y medianas empresas. Revista Española de Innovación, Calidad e Ingeniería del Software, 2006, vol. 2, no 1, p 19. 46 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. 47 RODRÍGUEZ MANCILLA, Darío. Diagnóstico organizacional. Alfaomega. Ediciones Universidad Católica de Chile, 2005. 48 RODRÍGUEZ, Julián; TORRES, Miguel; GONZÁLEZ, Enrique. La Metodología AOPOA. Avances en Sistemas e Informática, 2007, vol. 4, no 2.
31
de problemas; esto en forma de procedimientos, guías y criterios como métodos de
análisis o diseño estructurado para el modelamiento de procesos de transformación
de datos49. En el proyecto se usarán los diagramas de flujo para modelar la
estructura de solución de los casos de prueba en la fase de diseño y del modelo
que se propone para dar una explicación gráfica con estructuras claras y que
visualmente permitan abarcar las descripciones escritas.
Los modelos de análisis.
El Modelo de contingencia: El funcionamiento de todo el proyecto implica una
complejidad mayor a la complejidad del departamento de QA, sobre el cual
se desea aplicar el modelo de mejora desarrollado durante este documento,
pues QA será el sistema que deberá especializarse en partes para poder
reducir la complejidad de su entorno e integrarse para evitar que la fuerza
centrífuga de la diferenciación despedace este sistema dentro del entorno
del entorno del proceso que lo contiene, para lo que debe relacionarse de
manera selectiva a través del proceso, según la ley de variedad requerida de
Ashby50.
El trabajo colectivo descrito por Mintzberg y la estructura en cinco, resalta la
división del trabajo entre las tareas a ser realizadas y la coordinación de esas
tareas como trabajo colectivo en las actividades organizadas; propone
también cinco mecanismos coordinadores básicos:
o Ajuste mutuo: consiste en coordinar al equipo de trabajo con
comunicación informal
o Supervisión directa: implica un supervisor que coordina el trabajo,
pues es su responsabilidad el cumplimiento
o Estandarización de los procesos de trabajo (específica el proceso)
o Estandarización de productos (específica el resultado)
o Estandarización de destrezas y conocimientos de los
trabajadores.51
Metodologías ágiles
49 BUSTOS, Ricardo A. Gacitúa. Métodos de desarrollo de software: El desafío pendiente de la estandarización. Theoria, 2003, vol. 12, p 29 . 50 RODRÍGUEZ MANCILLA, Darío. Diagnóstico organizacional. Alfaomega. Ediciones Universidad Católica de Chile, 2005. P 3. 51 RODRÍGUEZ MANCILLA, Darío. Diagnóstico organizacional. Alfaomega. Ediciones Universidad Católica de Chile, 2005. P 3, 4.
32
incluyen valores y principios que sirven para desarrollar software en equipos de
trabajo más rápidamente y poder responder a los cambios que puedan surgir a lo
largo del proyecto; Resalta, tal como en la como lo dice Yokoi Kenji Díaz de la
fundación Turismo Con Propósito en su conferencia “mitos y verdades Japon-
colombia” acerca de las bases del éxito japonés, las personas son el principal factor
de éxito de un proyecto; en los proyectos de software resulta mejor construir un
buen equipo que dedicarse al entorno y el desarrollo de software por encima de la
documentación técnica(a menos que sea absolutamente necesaria, que sea
concisa y sin llegar a abandonarla). También resalta la importancia de la
colaboración con el cliente más que la negociación de un contrato. Se propone que
exista una interacción constante entre el cliente y el equipo de desarrollo,
incorporando lo al equipo de modo que marque la marcha del proyecto, asegure su
éxito y agilice la atención a los cambios (cambios en los requisitos, en la
tecnología, en el equipo, etc.) con una planificación flexible y abierta, no estricta52 53
Se presentan a continuación algunos de los principios propios de las metodologías
ágiles, que se tendrán en cuenta para el diseño del modelo que se presentará:
“Entregar frecuentemente software que funcione desde un par de semanas
a un par de meses, con el menor intervalo de tiempo posible entre entregas
La gente del negocio y los desarrolladores deben trabajar juntos a lo largo
del proyecto
El diálogo cara a cara es el método más eficiente y efectivo para comunicar
información dentro de un equipo de desarrollo
La atención continua a la calidad técnica y al buen diseño mejora la agilidad;
La simplicidad es esencial”.54 55
Las metodologías ágiles sólo tienen una exigencia relevante, que reside
principalmente en el factor humano, específicamente en el talento, habilidad,
adaptabilidad, competencia, colaboración, habilidad en toma de decisiones,
confianza, respeto, capacidad de resolver problemas difusos, organización propia y
enfoque común de su equipo de trabajo (a nivel individual y grupal).56
52 BUSTOS, Ricardo A. Gacitúa. Métodos de desarrollo de software: El desafío pendiente de la estandarización. Theoria, 2003, vol. 12. 53 CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. Metodologías Ágiles en el Desarrollo de Software, 2003. 54 CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. Metodologías Ágiles en el Desarrollo de Software, 2003, p. 55 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 55. 56 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 60.
33
Los procesos ágiles pretenden incursionar en los costos de programación del
proyecto, tal como se puede observar en la siguiente imagen, que enseña por medio
de las curvas de costos como el equipo de trabajo puede aplanar la curva de costos
aplicando procesos ágiles como pruebas unitarias continuas y programación por
parejas, cuando los costos normales se ven afectados por cambios significativos
que solicita el cliente a pesar que estos sean realizados en fases tardías57 Ilustración 6 Costo del desarrollo Vs Avance de la programación del desarrollo
Fuente 6 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 57.
Las pruebas unitarias continuas son pruebas que se crean con una estructura que
permita automatizarlas, para que sean repetidas muchas veces con facilidad (a
diario), que a su vez estimulan una estrategia de pruebas de regresión siempre que
se genere alguna modificación58. Las pruebas de regresión ayudan a garantizar que
los cambios que se realicen no generan comportamientos no planeados o errores
adicionales, se realizan manual o automáticamente con Software que capture los
casos de pruebas con sus resultados para ser revisados y comparados.59
Modelo en espiral.
Aplicado con las actividades estructurales generales propuestas en el libro
“Ingeniería del software. El modelo en espiral tiene un enfoque cíclico para el
57 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 7. 58 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 64. 59 Ibíd. p 395.
34
crecimiento incremental en definición e implementación con puntos de referencia de
anclaje puntual que aseguran la búsqueda constante de soluciones factibles y
mutuamente satisfactorias.60 Ilustración 7 Modelo en Espiral común propuesto por Boehm.
Fuente 7 PRESSMAN, Roger S.; TROYA, José María. Ingeniería del software. McGraw Hill, 1988. P.39
Las características del modelo en espiral incluyen que se desarrolla en una serie de
etapas iterativas, partiendo de un modelo o prototipo que se va evolucionando en
versiones cada vez más completas61, es un modelo evolutivo con un patrón de
fase62 según las actividades estructurales de un proyecto de software. Las fases o
etapas del modelo en espiral son: Comunicación, planeación, modelado,
construcción y despliegue de manera concurrente.
La fase de comunicación es de suma importancia porque es el intercambio
de información, colaborar con el cliente o todo el equipo relacionado para
entender lo máximo posible de los objetivos y requerimientos del proyecto
para así tener claridad de las características y funciones a cumplir. Es el final
de una iteración y el inicio de la iteración inmediatamente siguiente.63
La fase de planificación es el diseño de la guía de trabajo, donde se define
el proyecto en actividades técnicas a realizar, riesgos probables, recursos,
los resultados esperados y la programación de las actividades necesarias
60 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. p 397. 61 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P.39 62 Ibíd. P 31. 63 Ibíd. p 52.
35
La fase de modelado es la definición de las partes del proyecto, cómo se
relacionan entre sí, las características propias del proyecto, detalles que
permitan comprender el problema y cómo resolverlo por medio de diseños
previos.
La construcción consiste en la generación de la solución y las pruebas que
se requieren para identificar si existen errores en el modelo que se genera;
también implica el desarrollo de los diversos elementos de apoyo que sean
útiles para la aplicación del modelo (herramientas, tareas, estrategias,
actividades técnicas, etc.)
El despliegue es la aplicación, evaluación y retroalimentación que se realiza
ya sea al producto final o una entrega parcial del modelo.64
La metodología AOPOA.
AOPOA o “Aproximación Organizacional a la Programación Orientada a Objetos” se
usa para el análisis y diseño de Sistemas Multi-Agente (SMA), donde cada conjunto
mayor de actividades está formado por unos procesos iterativos que generan
artefactos que incluyen tablas y diagramas que definen un sistema multiagente
genérico que abarca:
El enfoque organizacional(descomposición en unidades autónomas que
compartan objetivos y hagan a gestión correcta de los recursos)
La fase de análisis del sistema y cada uno de sus agentes.65
AOPOA propone una descomposición gradual en roles; tomar un rol muy complejo
y dividirlo en varios más simples66 para así distinguir las tareas y las actividades en
común de cada agente, esto como una visión que se puede considerar en la
construcción del modelo a proponer.
La mejora de procesos de Software es una actividad de la calidad que implica
tiempo, recursos, medidas, y las iteraciones de un procedimiento sistémico aplicado
a los procesos para acercarse a un resultado efectivo y exitoso67, el cual se puede
64 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 13. 65 RODRÍGUEZ, Julián; TORRES, Miguel; GONZÁLEZ, Enrique. La Metodología AOPOA. Avances en Sistemas e Informática, 2007, vol. 4, no 2. P 2. 66 Ibíd. p 3. 67 TRUJILLO-CASAÑOLA, Yaimí; FEBLES-ESTRADA, Ailyn; LEÓN-RODRÍGUEZ, Giraldo. Modelo para valorar las organizaciones al iniciar la mejora de procesos de software. Ingeniare. Revista chilena de ingeniería, 2014, vol. 22, no 3, p. 413.
36
diseñar como una propuesta de modelo de mejora de procesos. La mayoría de las
propuestas de mejora radica en priorizar la implementación de las mejoras, usar
modelos de mejora existentes ajustados a las necesidades y evaluar las mejoras
que se vayan introduciendo durante el proyecto de mejora; otras un poco menos
comunes son las que están centradas en la definición, evaluación y soporte de los
procesos software; las propuestas de mejora que se aplique a nivel organizacional
es más económica pero sus resultados no se obtienen a corto plazo y las que son
a nivel técnico son más costosas pero las mejoras se ven a corto plazo68.
Diferentes investigaciones señalan el uso de indicadores en la mejora de procesos
de software que proporcionen métodos objetivos (tangibles) para caracterizar la
capacidad del proceso y evaluar el efecto de los cambios que se apliquen en cada
propuesta de mejora; teniendo en cuenta la existencia de barreras (factores críticos
negativos) y riesgos (vulnerabilidad ante potenciales impactos negativos), por lo que
la información de las experiencias de la organización y sus expertos es vital69 para
el desarrollo de este modelo y serán presentados al final de este capítulo en los
antecedentes.
4.7 FACTORES INFLUYENTES EN LA CALIDAD.
Teniendo en cuenta los problemas clave en proyectos de desarrollo de software:
complejidad de sus partes y entorno70, dificultad para estimar el tiempo requerido,
la relación no directa entre personal y avance, la dificultad en la comunicación y el
crecimiento de la entropía a través del tiempo71; se identifica la existencia de los
mismos dentro del proyecto, y considerando de primordial necesidad intervenir en
la comunicación entre las partes, se dirige este proyecto al uso de la estandarización
como mecanismo coordinador básico para fortalecer las comunicaciones72 y el uso
de marcos de referencia para pruebas; como una solución a nivel técnico, siendo
68 PINO, Francisco; GARCÍA, Félix; PIATTINI, Mario. Revisión sistemática de mejora de procesos software en micro, pequeñas y medianas empresas. Revista Española de Innovación, Calidad e Ingeniería del Software, 2006, vol. 2, no 1, p 15. 69 TRUJILLO-CASAÑOLA, Yaimí; FEBLES-ESTRADA, Ailyn; LEÓN-RODRÍGUEZ, Giraldo. Modelo para valorar las organizaciones al iniciar la mejora de procesos de software. Ingeniare. Revista chilena de ingeniería, 2014, vol. 22, no 3, p. 414. 70 RODRÍGUEZ MANCILLA, Darío. Diagnóstico organizacional. Alfaomega. Ediciones Universidad Católica de Chile, 2005. 71 BUSTOS, Ricardo A. Gacitúa. Métodos de desarrollo de software: El desafío pendiente de la estandarización. Theoria, 2003, vol. 12. 72 RODRÍGUEZ MANCILLA, Darío. Diagnóstico organizacional. Alfaomega. Ediciones Universidad Católica de Chile, 2005.
37
más costosa pero genera mejoras a corto plazo, para mejorar la relación de
cooperación interna y con el cliente73.
Los productos tecnológicos son las herramientas en que el equipo de trabajo se apoya durante el proceso de desarrollo del software, pueden ser software propietario, con licencia o libres según solicitud del cliente o preferencia del equipo de trabajo; sin embargo la empresa desarrolladora que comercializa un producto de alguna herramienta lo ofrece según su experiencia. En la propuesta de mejora de los procesos de estimación de costos de software del caso del sector de software de Barranquilla presenta categorías del agente herramientas tecnológicas donde dependiendo del puntaje obtenido durante sus revisiones de costos y beneficios se podrá clasificar en categoría alta, media o baja; estas tienen un conjunto de variables asociadas que especifican su grado de importancia dentro del modelo. Se presentan tres categorías comparadas en torno a puntos específicos, de los cuales solo tendremos en cuenta la categoría alta y los aspectos mejor calificados para tenerlos como guía de objetivos a alcanzar y recomendar dentro de la práctica. Con respecto al agente herramientas tecnológicas de categoría alta se resaltan los
siguientes aspectos:
Manejo de gestión de proyectos para apoyar la medición de avances del
cronograma de trabajo, establecer prioridad de los requerimientos.
El cliente tiene acceso a la herramienta de gestión de proyecto.
Manejo de herramientas para controlar el código que permite revertir errores
locales.
El equipo de desarrollo utiliza diferentes environments para aislar los bugs y
mantener el producto estable.
Manejo de metodologías y métodos para asegurar la calidad del producto.
Cuyas variables son presentadas en la siguiente tabla.
73 PINO, Francisco; GARCÍA, Félix; PIATTINI, Mario. Revisión sistemática de mejora de procesos software en micro, pequeñas y medianas empresas. Revista Española de Innovación, Calidad e Ingeniería del Software, 2006, vol. 2, no 1, p 19.
38
Tabla 1 Variables del agente herramientas tecnológicas.
Fuente tabla 1 CARUSO, Nohora Nubia Mercado74.
Ponderando para cada variable con mayor puntaje las siguientes escalas:
“Alcance y requerimiento: Se establecen los requisitos funcionales y no
funcionales del sistema de manera clara y específica a partir de reuniones
con el cliente y futuros usuarios. Cada requisito se debe completar en una
iteración.
Descomposición: Al tener los requisitos claros, se descomponen en
actividades o tareas y se le asigna un nivel de prioridad por parte del cliente
con el fin generar entregables en el menor tiempo posible, que tengan alto
valor para el cliente.
Estabilidad de los requerimientos: No existen cambios significativos de los
requerimientos a lo largo del ciclo de desarrollo.
Histórico de proyectos: El equipo de desarrollo cuenta con una base de datos
histórico donde se almacena información relacionada con la descripción del
requerimiento, complejidad del requerimiento, tiempo estimado de una
actividad, tiempo real de la actividad, duración general del proyecto en horas,
valor por hora dependiendo del perfil del desarrollador, etc., así como
personal con alta experiencia en proyectos similares.
Documentación: Para la empresa desarrolladora es primordial documentar la
especificación de requisitos (SRD) que contiene toda la especificación del
sistema, así como el diseño del software en herramientas disponibles para
todo el equipo. En cada sprint debe ir creciendo el manual de usuario.
Organización el equipo: La empresa cuenta con un equipo base para cumplir
las labores de la implementación de la metodología seleccionada. Los
diferentes roles dependen tanto de la metodología como de las tecnologías
74 CARUSO, Nohora Nubia Mercado; DEL CASTILLO, Edwin Puerta; NAVARRO, Katherinne Salas. Mejora de los procesos de estimación de costos de software: Caso del sector de software de Barranquilla. Revista de Ingenierías: Universidad de Medellín, 2015, vol. 14, no 27, p. 24.
39
que impliquen la arquitectura. También se pueden combinar más de un rol
en una sola persona.
Competencias del equipo de trabajo: Existencia de personal capacitado para
utilizar las diversas herramientas que van a ayudar al equipo a trabajar
conforme a la metodología seleccionada. Programas de capacitación para
elevar el nivel de competencia
Comunicación con el cliente: Constante retroalimentación por parte del
cliente del progreso del proyecto
Seguimiento: El líder del proyecto realiza reuniones diarias con el equipo para
evaluar el cronograma de trabajo. Se evalúan cumplimiento de estimados y
solución de bloqueos”75
Siendo la suma de los siguientes el 100% de las variables que se presentan en la anterior tabla, lo que implica el mejor de los escenarios y las mejores condiciones de un proyecto de mejora de procesos de software.
“Apoyo a la gestión: El equipo de desarrollo utiliza herramientas de gestión de proyectos para apoyarse en la medición de los avances en el cronograma de trabajo, prioridad de los requerimientos, histórico del proyecto, fechas de entregables, etc. El cliente tiene acceso a esta información.
Source control y Branching: El equipo de desarrollo utiliza herramientas de gestión de source control que permite revertir errores locales y el trabajo simultáneo de varios desarrolladores en una misma actividad o tarea. Igualmente poseen una estrategia para crear Branchs (nueva versión del proyecto) acorde a las necesidades del proyecto.
Environments: El equipo de desarrollo utiliza diferentes environments (al menos Development, QA y producción) para mantener aislados los bugs y el producto estable.
QA: El equipo usa métodos y tecnologías de quality assurance desde el momento que se escribe código para una tarea como TTD (test driven development) y tiene al menos un environments de pruebas.”76
75 CARUSO, Nohora Nubia Mercado; DEL CASTILLO, Edwin Puerta; NAVARRO, Katherinne Salas. Mejora de los procesos de estimación de costos de software: Caso del sector de software de Barranquilla. Revista de Ingenierías: Universidad de Medellín, 2015, vol. 14, no 27, p. 24 76 CARUSO, Nohora Nubia Mercado; DEL CASTILLO, Edwin Puerta; NAVARRO, Katherinne Salas. Mejora de los procesos de estimación de costos de software: Caso del sector de software de Barranquilla. Revista de Ingenierías: Universidad de Medellín, 2015, vol. 14, no 27, p. 24.
40
4.8 ANTECEDENTES.
Como antecedentes se usarán los manuales y matrices que existen actualmente
para cada tipo de desarrollo del proyectos, así mismo se tomará como guía la
documentación de otros proyectos que tiene la empresa, para implementar lo que
se considere útil, rescatando las estructuras y procesos que resulten más efectivas;
también se recurrirá a los conocimientos y experiencia de los consultores,
arquitectos y clientes para realimentar el modelo desde una perspectiva holística.
Se tienen en cuenta los documentos de propiedad de la empresa o del cliente final:
Versiones Iniciales de manuales de usuarios de diversos procesos (Baja o
cancelación de Contratos y/o Activos, Cambio de Sim Card Regional, eco factura
formato, Solicitud de Turno V2, Pruebas Tienda Retail, Adicionales) , modelo de
Aseguramiento de Ingreso y Recaudo, propuesta de seguimiento de pruebas PRE
QA; inventario de requerimientos y casos de prueba, matrices de casos de
prueba(para UAT en activación, desactivación, Vista 360 y empotrados), matrices
de seguimiento de pruebas, LLD's M2S de cada desarrollo(administración de reglas
de negocio, aprobar campaña asignar oferte y tratamiento a campaña , campaña
grupo control, creación y cierre de campaña, etc.) a los que el cliente nos permita
acceder.
Antecedentes en ETB.
Etb es una empresa que lleva una trayectoria importante en las
telecomunicaciones, tanto en Bogotá como en Colombia (en este último es gracias
a las recientes ofertas de LTE y de Fibra a nivel nacional); ETB ha tenido una
expansión considerable a partir de la implementación de la tecnología 4G en
Colombia llegando a ser una de las empresas pioneras y líderes a nivel nacional,
en este proceso participó la empresa Fusion Partners en el desarrollo de los
procesos de CRM en Siebel.
ETB cuenta con un equipo completo de profesionales de talla internacional,
enfocados al desarrollo del sistema de software, también cuenta con un sistema
normativo para garantizar buenas prácticas de desarrollo, que ha permitido que la
empresa sea reconocida con varios premios en los últimos años.
La participación de Fusion Partners en el proyecto de ETB debe ser considerada
en el nuevo proyecto que se está realizando para Entel en Chile y Perú, de
41
manera que sirva de influencia para considerar varias estrategias, documentos y
procedimientos pueden llegar a ser un apalancamiento en las estrategias que se
empiezan a crear desde cero. Por medio de un integrante del equipo que participó
del proyecto en ETB se consulta información, estrategias y documentos de la
experiencia obtenida en el proyecto.
Alguno de los formatos con información previamente seleccionada que podemos
encontrar en el proyecto de implementación de ETB son los siguientes:
Tabla 2 Casos de pruebba ETB
Fuente tabla 2 Creación empresa Fusion Partners S.A.S
Tabla 3 inventario de casos de prueba de portales
Fuente tabla 3 Creación empresa Fusion Partners S.A.S
Tabla 4 de seguimiento de pruebas de portales ETB.
Fuente tabla 4 Creación empresa Fusion Partners S.A.S
42
Tabla 5 Seguimiento de defectos de casos de prueba de portales ETB
Fuente tabla 5 Creación empresa Fusion Partners S.A.S
Antecedentes en TIGO de Honduras.
En el proyecto elaborado para Tigo en Honduras se hacía el diseño de los casos de
pruebas sobre un formato prediseñado que señalaba los datos del diseñador de la
matriz, los componentes, las funciones, los pasos, los resultados esperados y
obtenidos.
Para cada caso de prueba se diseñaba la matriz y las hojas siguientes del
documento contenían las evidencias subrayadas, enmarcadas y con los
comentarios respecto de las observaciones requeridas en cada caso; además se
tenía una matriz para los casos de empotrados con características muy específicas,
una matriz de procesos con responsabilidad y una matriz de estado de cada matriz
de casos. Durante la ejecución también debía hacerse la actualización del manual
y la comparación de 2 ambientes TERRAMARK y QA para la verificación de
resultados de la pruebas. Debido a la aplicación de formato para cada caso, la
permanente actualización de la manuales y la toma de pantallas paso a paso
resaltadas y comentadas, hacen del proceso de prueba de cada caso, un proceso
agotador demorado y totalmente normalizado y estandarizado. Dos personas del
equipo estuvieron integradas y las metodologías procedimentales tenían una
complejidad muy semejante por lo que tenían algunas guías.
A continuación se presentan la imágenes de las diferentes matrices que deban ser
diligenciadas o a las que se recurre en algún punto del proceso, donde se pueden
identificar los campos a diligenciar; en la parte inferior se pueden visualizar las
pestañas de las imágenes del paso a paso. También se puede visualizar una
imagen del manual de usuario que debía ser actualizado cuidando del formato.
43
Tabla 6 Casos de prueba de Tigo Honduras
Fuente tabla 6 Creación empresa Fusion Partners S.A.S
Tabla 7 Matriz de procesos con responsabilidad de TIGO-Honduras
Fuente tabla 7Creación empresa Fusion Partners S.A.S
Tabla 8 Matriz de seguimiento a empotrados
Fuente tabla 8Creación empresa Fusion Partners S.A.S
Tabla 9 Matriz de seguimiento a consultas virtuales
Fuente tabla 9 Creación empresa Fusion Partners S.A.S
45
5 SITUACIÓN INICIAL
La situación inicial presenta la información considerada para establecer un modelo
del funcionamiento del área de calidad de la empresa, para comprender el sistema
actual mediante la definición de la estructura de procesos, los factores y variables,
estos permiten el relacionamiento entre los consultores, los desarrolladores, el
cliente y las herramientas tecnológicas para el cumplimiento de los requerimientos.
También se especifican los pasos iniciales de la reestructuración del modelo de la
situación inicial en cumplimiento del primer objetivo específico.
Se presenta la descripción del entorno del sistema de pruebas que aborda el
modelo, siendo el sistema externo más directo la empresa Fusion Partners S.A.S.
en sus procesos de diseño y desarrollo, también el cliente con el que se debe
relacionar. Posteriormente se presenta la descripción del sistema sobre el cual se
implementa el modelo, que es el sistema de pruebas a desarrollos realizado por el
equipo de calidad (QA).
Se desarrolla un análisis detallado del sistema inicial visto desde las temáticas
abordadas en el marco teórico, para dimensionar la información disponible desde
los mismos aspectos y visualizar su evolución a través del desarrollo de las
prácticas en la empresa. En cumplimiento de los objetivos específicos de este
documento, principalmente a documentación del proceso y el comprender el
sistema actual mediante la definición de la estructura de procesos, los factores y
variables que permiten su relacionamiento, especificando los pasos iniciales de la
reestructuración.
Descripción del sistema externo.
El proyecto de desarrollo que Fusion Partners S.A.S. está implementando para Entel
de Chile (empresa de telecomunicaciones) consiste en la configuración de Siebel,
un C.R.M (customer request management) que gestiona la información de los
miembros suscritos a la empresa. Con este software la multinacional pretende el
cumplimiento de las necesidades y requerimientos del cliente.
Para la creación de los requerimientos, Entel, fue guiado por los expertos de la
empresa (arquitectos, administradores de ambiente, consultores) e implican
46
negociar modificaciones y correcciones para convertirse en requerimiento lógicos
implementables en el sistema (reglas de negocio).
Los requerimientos principales son determinados a partir de una serie de reuniones
entre representantes de cada departamento implicado, para especificar los detalles
esenciales del análisis de los procesos necesarios y documentar la creación del
requerimiento.
Ya determinadas las reglas de negocio, se realiza la estructuración de cada
requerimiento usando los componentes que tiene Siebel (características,
restricciones y capacidad) para ir acercando el lenguaje natural al lenguaje de
programación de alto nivel. Se genera un documento en donde se presenta de
manera general el diseño de cómo suplir el requerimiento desde el programa,
guiando al desarrollador en la implementación; este documento es conocido como
H.L.D (High level design), se realiza por partes del proyecto detallado los casos de
uso, los diagramas de secuencia, reglas de negocio, requisitos de integración,
pantallas, arquitectura de solución y su respectiva construcción.
Los H.L.D son entregados por fases al líder de proyecto, que se encarga de
asignarlos según capacidad, especialidad y experiencia de cada desarrollado; se
entrega el H.L.D que contenga los casos de uso que debe implementar para que
sirva como documento guía y sea la base para el diseño del L.L.D (low level design),
que es el documento en el que el desarrollador plasma específicamente su
implementación en el sistema para cumplir con la regla de negocio. Los L.L.D
incluyen componentes involucrados en el desarrollo, las integraciones y los objetos
de Siebel (pantallas, applets, objetos de negocio, workflow, entre otros) que van a
verse involucrados, esto con el fin de que sean registrados y al momento de que
sean nuevamente modificados no interfieran en los desarrollos en otros procesos
(antiguos o los que se crearán en un futuro).
Una vez terminada la implementación del desarrollo se realizan pruebas unitarias
para evaluar el funcionamiento del requerimiento y se envía al equipo de Q.A
(quality assurance), las características e información relacionada se presenta en la
descripción del sistema interno.
Según Álvarez77 se debe desglosar por nivel y detalle de los requerimientos como
herramienta metodológica en la producción de desarrollos, en el caso de Entel se
77 ÁLVAREZ, Juan Carlos Granja; GARCÍA, Manuel J. Barranco. Proyectos informáticos. Universidad Nacional de Educación a Distancia, UNED, 1994. P 8.
47
define el proyecto y el progreso de este por medio de matrices compartidas de
seguimiento; A continuación se denota el nivel de jerarquización del sistema
externo representado mediante el siguiente gráfico, se representa la comunicación
para la construcción del requerimiento: desde el nivel más alto se dan los
requerimientos generales y a medida que desciende en la estructura, estos se van
siendo especificados y detallados hasta la construcción completa del requerimiento
para la implementación en el software:
Ilustración 8 Relación entre Agentes
Fuente 8 Creación propia
línea negra: las relaciones
línea azul: relación de comunicación para entrega de resultados
línea roja: la comunicación para la construcción del requerimiento
El líder de proyecto es quien se encarga de distribuir los requerimientos a su equipo de trabajo y de estar al tanto de los requerimientos que se necesita desarrollar, junto con los ámbitos de negocio que se requieren según las prioridades y bases pactadas. Para la entrega de cada fase se realiza un sanity para que interactúen todas las funcionalidades y desarrollos de los sistemas, esto se realiza con la asistencia de los desarrolladores, arquitectos y líderes de todo el proyecto; previamente para su validación se hacen pruebas funcionales del proceso completo,
48
para verificar de manera general las funcionalidades creadas. Al realizar un release se trata de ingresar la menor cantidad posible de requerimientos complejos (se busca que sean sencillos) para que no se integren con otras aplicaciones y se organiza agrupando, de manera que las actualizaciones que se vayan haciendo se vean versionadas con procesos de negocio simples y determinados, en caso de ser necesario realizar una marcha atrás del sanity y así no llegue a afectar el desarrollo, el avance y la integralidad que anteriormente se tenía, comprometiendo solamente los nuevos cambios y las actualizaciones por venir.
Existen otros proyectos que otras organizaciones desarrollan y que son
complementos a las funcionalidades del sistema, estos se interrelacionan con el
software y se busca tener los parámetros de entrada y de salida que intervienen y
la forma en que estos llegan a visualizarse en la interfaz, para esto se necesita que
esos datos se encuentren configurados para que Siebel los acepte de manera
general.
Descripción del sistema interno.
El sistema interno hace referencia principalmente al área de calidad de la empresa
con sus características, relaciones, funciones, ventajas y desventajas. Se considera
este sistema el centro del modelo y la razón de ser de este proyecto. El equipo de
QA (quality assurance), es el responsable de hacer las pruebas y verificaciones de
los desarrollos, para identificar los defectos o errores que puedan generarse en las
implementaciones y así realimentar al proceso de desarrollo de modo que puedan
corregirlos antes de realizar la entrega al cliente, siendo los responsables de la
verificación de la calidad dentro de la empresa.
El proceso en el área de calidad inicia con la recepción de los HLD Y LLD por parte
del líder de pruebas, que los asigna a los integrantes de QA o consultores de
pruebas; estos dos documentos son revisados por el equipo casos por caso, se
analizan paso a paso del caso de uso que se desarrolló y verificando sus
requerimientos para probar su funcionamiento en Siebel; esperando que se ha
hecho una correcta interpretación, el equipo le solicita al líder de pruebas los
requerimientos para poder probar (datos) y se inicia el proceso de prueba que
verifique el cumplimiento de las descripciones de HLD y LLD, identificando los
errores y defectos que se presenten durante la ejecución de la prueba, estos
defectos son comunicados al líder de pruebas, quien los informa al equipo de
desarrollo y finalmente, cuando el líder es notificado se realiza una verificación del
estado exitoso y termina el proceso.
49
Presenta las siguientes ventajas:
Se reciben los requerimientos del cliente y la información por parte de los
desarrolladores, hay comunicación directa con los desarrolladores para
informar defectos por medio del líder, disponiendo de los pasos que se
deben de realizar p y encontrar los requerimientos de datos para probar los
casos
Disponer de los diagramas de flujo principales descritos en los HLD y LLD
Las pruebas son sencillas (unitarias) al ser un proyecto que está iniciando, lo
que hace pequeña la complejidad de las pruebas
Los defectos de otras implementaciones que son generados colateralmente
son poco probables, pues las restricciones sólo son las iniciales del sistema.
hay unificación en la información al darse por medio de un solo líder que se
comunica con el otro equipo, generando una única respuesta de
conocimiento grupal.
Presenta las siguientes desventajas:
Durante los procesos de desarrollo se pueden generar modificaciones del
requerimiento del cliente para adaptar al sistema, no son comunicados en
tiempo real al área de calidad, ni hay acceso a documentación que los
actualice.
La información que se recibe de ambos documentos es de baja calidad (en
la mayoría de las ocasiones) pues es incompleta, falta de claridad, sin un
orden lógico, con deficiente redacción y elaborado para uso interno del
equipo de desarrollo; por lo que presenta conceptos que no están en el
dominio del equipo de calidad y procesos propios de desarrollo, más no el
proceso para probarlos, ni como verificar su funcionamiento interno en
Siebel.
No hay contacto directo con el cliente desde QA.
No hay contacto directo de los consultores de pruebas con los
desarrolladores.
La validación de los desarrollos era extensa y poco eficiente, debido a la
identificación de requerimientos de pruebas, durante la ejecución de pruebas
y desarrollos.
La falta de un ambiente exclusivo para pruebas genera choque entre
desarrollos y pruebas, que generan de demoras.
Se realizan validaciones sin el criterio correcto.
50
Se realizan recurrentes capacitaciones de uso de herramientas nuevas y
otros procesos no establecidos por el equipo(ni la empresa), por solicitud del
cliente para un posible futuro uso, que no son documentados, generan
demora, reproceso y aumento costos; Y ya finalizada la práctica no se
usaron.
Falta de comunicación.
Falta de organización en los procesos de pruebas y estandarización.
El exceso de formalización para la comunicación interna (sin estandarización,
ni detalle apropiados).
Análisis del sistema inicial.
Inicialmente el modelo implica una relación entre el sistemas externo e interno en
mutua asistencia y trabajo colaborativo, siendo dos sistemas semicerrados entre
ellos con un único punto de contacto y comunicación: el líder de cada etapa; son el
líder de desarrollo (se encarga de la coordinación de los requerimientos y su
cumplimiento según acuerdo con Entel) y el de pruebas, juntos establecen las metas
limitadas por plazos, formatos de seguimiento (indicadores de avance, de éxito,
entre otros) y cumplimiento (nivel de cumplimiento) supervisadas por integrantes de
Entel para cumplir con los plazos determinados.
A continuación se realiza un análisis de los aspectos a impactar por medio del
modelo que se propone, basado en la revisión teórica expuesta en el marco teórico
para dimensionar bajo los mismos aspectos cada fase del proceso descrito en este
documento y así poder hacer una comparación al final del documento.
5.1 FUNCIÓN DEL INGENIERO INDUSTRIAL EN LA SITUACIÓN INICIAL.
"El objeto de estudio de la Ingeniería Industrial es el mejoramiento continuo de
sistemas productivos de bienes y servicios conformado por: recursos humanos,
tecnológicos, financieros, económicos, materiales y de información; con el fin de
incrementar la productividad y competitividad de las organizaciones". Universidad
Autónoma de Occidente, tomada del documento PROYECTO EDUCATIVO DEL
PROGRAMA DE INGENIERÍA INDUSTRIAL.
La función del ingeniero industrial en la situación inicial de la empresa debería verse
reflejado, como mínimo, en un profesional del área de calidad a nivel interno o
externo del sistema abordado, que se hiciera cargo de realizar el mejoramiento
51
continuo de los procesos y actividades propias de cada área (aunque
individualmente se intente realizar un mejoramiento); inicialmente se hacía de una
manera muy general, desde una intención implícita de querer mejorar, pero sin el
análisis de las causas de los problemas.
Posteriormente se hicieron frecuentes las fallas, porque no se realiza una atención
de manera directa a algunos problemas, que solo se resolvieron por el momento,
no se llevó un control o registro que permitiera llegar a las causas y las
consecuencias por las que son generadas.
La coordinación de las actividades a nivel interno del equipo de calidad se realiza
según la prioridad del requerimiento, para cumplir con solicitudes del sistema
externo, por eso no se planea con antelación, ni cumpliendo cronogramas
específicos; a pesar de las tareas a las que se les destinó plazos, no hay una
selección estratégica, por lo tanto solo se pretende formar una asociación entre toda
la estructura, que en la práctica vaya acomodando los requerimientos que no
pueden ser definidos completamente.
La evaluación y la consecución de las metas del equipo de calidad son realizadas
por el líder de pruebas quien lleva un formato de secuencialización del proyecto
para evaluar el progreso según los casos que se van cerrando exitosamente, los
casos de uso pendientes o si es necesario que sea intervenido inmediatamente. La
aplicabilidad del diseño e intentar generar la sincronización entre las diferentes
entidades con el sistema se evidencia en el ambiente con la prueba de los casos
de uso que se presentan; en el proyecto no existe alguien encargado en general de
conocer todas las implicaciones asociadas a los casos de pruebas y su implicación
funcional (relaciones, componentes, procesos, entre otros), con esto se hace
referencia a una persona que sea un integrador del sistema.
5.2 CARACTERÍSTICAS PROPIAS DEL TRABAJO CON DESARROLLO DE
SOFTWARE EN LA SITUACIÓN INICIAL.
Se reconoce la labor del desarrollo de software es un trabajo limitado a factores
limitantes, como el tiempo, el costo, las características del sistema de trabajo
(Siebel), los riesgos o la incertidumbre78 por la interpretación del desarrollador, el
consultor de pruebas y el cliente; por lo que puede haber demasiados caminos para
78 PONS, Claudia; GIANDINI, Roxana Silvia; PÉREZ, Gabriela. Desarrollo de software dirigido por modelos. 2010. p 23. ()
52
desarrollar un mismo flujo de trabajo, o del mismo modo de probar un requerimiento
o de tratar de aplicar alguna función; por lo que se entra a buscar medios de apoyo
que reduzcan los impactos de estos factores sobre el proyecto, iniciando con la
comunicación(mecanismo básico de coordinación) y se encuentra en el proyecto la
característica específica de tener una comunicación no es homogénea pues se da
en diferentes idiomas, horarios, expresiones y vía online.
La empresa buscó integrarse en un sólo idioma (español), en el formato estándar
para todos los países de LLD, para el manejo de la información y ,por supuesto, se
identifican los no accesos directos entre los consultores de pruebas y el equipo de
desarrollo.
Además en el estado inicial se identifica la ausencia de un enfoque sistemático,
disciplinado y cuantificable como compromiso organizacional con la calidad79 y a
pesar de contar con las herramientas necesarias y tener otras disponibles dentro de
la organización no es suficiente sin una mejora organizacional que documente los
casos que pasan por el área de calidad; se identifica la intención independiente de
cada consultor de pruebas de tomar medidas personalizadas de control de casos,
haciéndolo sin registro o control estandarizado. También hubo una repartición de
asignaciones no eficiente, basado en elecciones al azar sin criterios, a pesar de que
diferentes tipos de desarrollos y por lo tanto de pruebas (modificación, a integración,
entre otros).
Es natural pensar que las capacidades y destrezas de algunos desarrolladores
pueden centrarse más en un tipo de desarrollo que en otro, sin embargo no se tenía
en cuenta porque no había conocimiento de las facultades específicas de cada uno.
Los procesos de los casos de pruebas no estaban claramente definidos, solo se
contaba con la información brindada por el cliente (HLD) y por los desarrolladores
(LLD), lo que brinda una información de baja calidad pues era muy superficial,
incompleta y desordenada, posiblemente porque iniciando el proyecto. Sobre esta
información debía iniciarse los casos de pruebas dentro del ambiente de desarrollos,
pues no existía un ambiente adaptado a pruebas, había tiempos muertos en las
pruebas gracias a los versionamientos de la plataforma y en varias ocasiones
chocaron entre desarrollos en la plataforma, llevando a versionar nuevamente los
componentes que ya habían sido antes modificados y probados.
Durante esta documentación se trabajará alrededor de la propuesta de un modelo
de mejoras basado en estandarización, rediseño y realimentación de procesos de
79 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 11.
53
pruebas de desarrollos de software para ofrecer una respuesta a las dificultades
que puedan presentarse, especialmente a las que se dan debido a la naturaleza de
este tipo de producto y procesos. Siendo Siebel el principal sistema sobre el que se
desarrolla un software de aplicación que resuelve una necesidad específica de
negocios (incluye el procesamiento de transacciones en punto de venta, verificación
de información y relación con bases de datos en tiempo real), un software de línea
de productos que proporciona una capacidad específica para el uso de muchos
usuarios consumidores (incluye control de inventarios y administraciones de bases
de datos)80 lo que es parte de las características propias del trabajo con software.
5.3 METODOLOGÍAS DE LAS EMPRESAS EN LA SITUACIÓN INICIAL.
La empresa Fusion Partners S.A.S. tiene una metodología para cada uno de sus
proyectos, sin embargo para el proyecto que desarrolla para Entel, inicialmente no
estaba claramente definida, y por lo tanto estaba muy lejos de ser una metodología
personalizada según sus condiciones,81 protocolos, funciones y procesos.
Especialmente en el área de calidad lo métodos deberían tener su nivel propio de
sofisticación y formalidad para llevar a cabo el cumplimiento de sus funciones y
facilitar el manejo de información y la comunicación82.
En el área de calidad de la empresa había una descoordinación con el cliente para
acordar los métodos de evidenciar el correcto funcionamiento de los casos
probados, así como tampoco se acordó el acceso a la información disponible
completa; y del mismo modo la descoordinación con el equipo de desarrollos para
la consulta de los documentos.
La metodología existente consistía en coordinación indirecta de los consultores de
pruebas por medio del líder de pruebas, hacia el líder de desarrollos para que él
coordinará con el equipo de desarrollos; esto podría verse como una metodología
útil que unifica el canal de comunicación, excepto porque la mayoría de los
desarrolladores y el equipo de consultores de pruebas se encontraban en la misma
oficina, mientras que el líder de desarrollos trabajaba online desde Argentina y el de
pruebas desde Honduras. También se contaba con desarrolladores en diferentes
países (México, Cuba, Costa Rica, Honduras, Colombia, Brasil, Chile y Argentina),
horarios laborales según el país y documentación en varios idiomas (español,
80 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 7. 81 CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. Metodologías Ágiles en el Desarrollo de Software, 2003, p. 82 BUSTOS, Ricardo A. Gacitúa. Métodos de desarrollo de software: El desafío pendiente de la estandarización. Theoria, 2003, vol. 12. P 25.
54
portugués e inglés). Estas condiciones implican encontrar un método accesible para
tener la información unificada en tiempo, idioma y precisión terminológica que se
adapte en el proyecto para el desarrollo del conocimiento y el funcionamiento
correcto de la organización.
Estas condiciones conllevan a que se use el diseño de formatos en la nube, para
que se actualizados en tiempo real, usando documentos en drive e
intercomunicación por medio de Skype en grupos donde interactúen todos los
involucrados tratando de generar un lenguaje común para las actividades y
procesos, sin embargo, hace falta una mejora organizacional que también impacte
la comunicación para aspectos más complejos que no deban ser resueltos vial
Skype. La transferencia tecnológica en el equipo de trabajo del área de calidad (QA)
estaba desarrollada y conformada por conocimientos implícitos, no compartidos, ni
adaptados de las experiencias en proyectos anteriores, pero que serán
considerados para diseñar una propia metodología.
Estos parámetros conllevan a que se tenga que utilizar el diseño de formatos en la
nube que estén actualizados a tiempo real, por lo cual se utilizan documentos en
drive e intercomunicación por medio de Skype en grupos donde interactúen todos
los involucrados tratando de generar un lenguaje común para las actividades y
aspectos específicos, sin embargo hace falta más medios de comunicación para
otros aspectos los cuales la capacidad tecnológica del Skype no alcanza a tener
cubrimiento.
La metodología que la empresa intenta desarrollar y necesita del proyecto apunta a
un control de calidad por medio de reportes, avances y actualizaciones en cada una
de las actividades a desarrollar; estos métodos se han intentado implementar en el
área de desarrollo, sin embargo no hay mucha atención a en el área de pruebas,
por lo tanto la efectividad en los procesos de pruebas es muy baja ya que no hay
una estandarización que permita el avance de las pruebas más eficientemente,
especialmente porque se presentan largos tiempos de procesos. Inicialmente el
control de calidad dentro del área de QA básicamente fue la aplicación de las
pruebas para validar el estado de los desarrollos y realimentar al equipo de
desarrollo.
5.4 METODOS DE VALIDACIÓN EN LA SITUACIÓN INICIAL.
El método de validación es un procedimiento utilizado por el equipo de calidad
basado en un plan de pruebas. Para este se propuso tomar la información
encontrada en los LLD (sin realizarles ningún tipo de modificación) para validar la
55
coincidencia con la información del HLD correspondientes seguido de un análisis
del paso a paso (sin estandarización alguna). Es importante enunciar que se resaltó
el procedimiento y se identificaron los requerimientos (datos) para probar y
considerar las especificaciones en el momento de la prueba en Siebel.
En las primeras validaciones se encontraron varios tipos de errores y defectos
propios de la operación en un ambiente creado recientemente; la identificación de
estos defectos se hizo por medio del líder de pruebas, el cual comunica el estado
del ambiente al líder de desarrollo y al líder de proyecto, esto es con el fin que en
la planificación se tuvieran en cuenta los tiempos de desarrollo aparte de los ya
contemplados.
Este tipo de situaciones causaron carga laboral innecesaria para el líder de
proyecto, desde atención a las actividades principales, desconcentración y
postergación de las actividades de los desarrolladores y re-procesos. La verificación
del cumplimiento, la realización de la prueba unitaria, la modificación del
procedimiento en documentos y verificación de impactos en el caso de uso fueron
los elementos en que se tuvieron una gran afectación.
El método utilizado por el equipo de QA para las validaciones era de tipo
experimental. Es por esto que al realizar la prueba en el caso de uso para verificar
el correcto funcionamiento, la aplicabilidad del programa, los errores y
requerimientos por información desconocida se identificaron al probar el ambiente.
El cliente no se encontraba involucrado en las validaciones, ni realizó ningún tipo de
control, por lo tanto, inicialmente no se requerían evidencias de los casos, el único
seguimiento que el cliente realizaba consistía en conocer los indicadores
reportados diariamente por el líder de pruebas acerca del avance obtenido.
El equipo de desarrollo solicito evidencias de los casos que se demoran en dar
resultados debido a que en varias ocasiones se trataba de errores de interpretación
por la falta de información o contradicciones en estas. Esto demuestra que los
reprocesos y las demoras eran causados por la incompleta información, la falta de
comunicación con los desarrolladores, los defectos del sistema y los errores de los
desarrollos.
5.5 ASEGURAMIENTO DE LA CALIDAD EN LA SITUACIÓN.
En el proyecto no se han implementado estándares específicos, que impliquen unas
revisiones técnicas, al análisis de errores (estructuradas de manera procedimental);
tampoco otros elementos básicos de aseguramiento de la calidad, como procesos
de socialización de posibles mejoras, administración de cambio, educación, entre
otros. Se cuenta con un leve control de calidad pues la única evaluación que se
56
tiene implementada es la entrega diaria de casos exitosos, sin embargo, es una
medida muy superficial que no mide la eficacia de este control, a pesar de ser
importante y debe tenerse en cuenta a la hora de algún proyecto.
No se cuenta en el proyecto a nivel de pruebas con ninguna estructura, aplicación
o gráfico que esté enfocado en el aseguramiento de calidad en los procesos, debe
de existir uno que sirva a la estandarización mediante tareas sencillas y procesos
a considerar, sin embargo se tiene un diagrama secuencial que está creado junto a
cada caso de uso en los documentos del H.L.D Y L.L.D (realizados en el momento
del diseño de cada caso de uso).
El proyecto cuenta con altos costos de tipo preventivo, con unos costos medios de
evaluación y unos costos altos de fallas, esto se debe a la implementación de
nuevos desarrollos en un ambiente completamente nuevo, lo que implica que la
mayoría de componentes que tienen que modificarse, ser creados, incurren con
mayor probabilidad de error que puedan afectar el desarrollo del proceso productivo.
La estrategia que se aplicaba en el área de calidad consistió en registrar los errores
y en una lista que se enviaba al equipo de desarrollo, sobre estos casos el único
seguimiento que se realizaba era la notificación inmediata y la espera de la
confirmación de la solución, para volver a probar y reportar los problemas
encontrados en los ambientes.
Además se identifica que en la empresa el requerimiento organizacional es mayor
que el técnico, pues la empresa cuenta con apoyos técnicos de alto nivel que no
son aprovechados, o por la forma en la que se usan resultan entorpeciendo la
agilidad de los procesos internos y con el modelo este va a ser aprovechado.
5.6 MODELOS EN LA SITUACIÓN INICIAL.
En el proyecto se puede evidenciar que hay una gran variedad de modelos (o partes
parciales de ellos) tales como los diagramas de flujo que son entregados en los
documentos HLD y se usan a lo largo del proyecto ya que contienen la información
necesaria para reconocer el proceso para realizar las pruebas, la actividad y el
sistema en el que se desarrollan; sin embargo estos son muy generales y por esto
es necesario realizar matrices del paso a paso para especificar en dónde y cómo se
debe realizar.
57
Ilustración 9 Diagrama de flujo en los H.L.D
Fuente 9 H.L.D suministrado por Entel
De acuerdo con modelo de especialización dentro del equipo de Q.A no se
encontraba nada especializado, siquiera información básica accesible acerca del
modelo a implementar, lo que impedía la elaboración de un fuerte en el sistema. Es
por esto que se ve la necesidad de crear canales de comunicación entre los
integrantes del proyecto la cual no requerirá de una alta formalidad, pero sí implica
el ajuste mutuo en los procesos como la verificación de documentación.
Con respecto a las metodologías no se tiene el concepto, ni mucho menos la
implementación o el desarrollo referente a las metodologías ágiles, al modelo en
espiral o al AOPOA.
El sistema de QA cuenta con una supervisión directa, realizada por el líder de
pruebas quien es el encargado de calificar el proceso. Aunque varios de estos tienen
una estandarización de manera normalizada, se evidenció que los procesos de
trabajo, los resultados, las destrezas y conocimientos de los integrantes del equipo
deben estar completamente estandarizados.
58
Así mismo, los requerimientos necesarios para los factores como los tiempos, los
recursos, la disposición, el interés y los costos correspondientes al desarrollo de las
pruebas generan altos costos de falla y de reproceso.
La adaptación al cambio en el área de calidad es deficiente, debido al permanente
e impredecible cambio que se genera desde los requerimientos, por dificultades que
retrasan los procesos de pruebas; la empresa posee alto nivel técnico en
herramientas disponibles, pero requiere mejoras en nivel organizacional muy
importantes.
Empresarialmente urge la implementación del modelo para hacer frente a los
procesos redundantes, innecesarios, inadecuados y agotadores, a falta de una clara
estandarización y rediseño de procesos; lo que se traduce en más tiempo, aumento
innecesario en costos y honorarios, multas por exceder los plazos de entrega y
daños en integraciones o modificaciones no deseados en los ambientes. También
con respecto a las pruebas que se realizan a los desarrollos y a las
implementaciones en la plataforma de producción, al realizarse por diferentes
consultores implica un la necesidad de estandarizar y documentar los procesos para
todos los casos que puedan presentarse, para así reducir tiempos en la capacitación
de cada prueba a los diferentes consultores, teniendo en cuenta la magnitud y
variedad de casos a aplicar.
5.7 FACTORES INFLUYENTES EN LA CALIDAD EN LA SITUACIÓN INICIAL.
Los factores que dependen directamente del proceso de producción y verificación
son altamente influyentes en la calidad, en el estado inicial se evidenciaron
dificultades en la estructura informática por la elevada complejidad de sus partes,
procesos y relaciones; la principal implicación de esta dificultad está en poder
acercarse a una sinergia y que funcione óptimamente de forma holística. Existen
también otras dificultades en el proceso de pruebas de desarrollos que son difíciles
de cuantificar, para poder medirlas y calcular su mejoramiento, como el estimar el
tiempo requerido, la dificultad en la comunicación, la falta de relaciones directas
entre el personal y el avance, y el crecimiento de la entropía a través del tiempo
debido a la falta de información y la dificultad para cumplir con los plazos pactados.
En cuanto a agente de herramientas tecnológicas, las actividades de manejo de la
gestión de proyectos, la necesidad de establecer una prioridad en los
requerimientos (en el ambiente externo de desarrollo), el permitir el acceso del
cliente a la herramienta de gestión de proyecto para la supervisión y trabajo en
equipo, son elementos que impactan directamente sobre la calidad.
59
Por otra parte el equipo de desarrollo usa varios ambientes y manejo de
metodologías para asegurar la calidad del producto, de manera que a pesar de que
tiene relativamente altos costos de fallas, son pocas en comparación con otros tipos
de proyectos en los que se ha trabajado anteriormente y que se hablará de ello en
el siguiente título.
En el proyecto se encuentran objetivos claramente forjados para la calidad, tales
como el alcance y el requerimiento (se disponen de los casos de prueba funcionales
en la documentación), la estabilidad de los requerimientos (estos son solicitados
para su ejecución y validación en cada prueba a lo largo del ciclo de pruebas),
histórico de proyectos (el equipo de QA cuenta con una experiencia acreditada y
documentación donde se tiene tanto información explícita como implícita
relacionada). Se identifica la necesidad de implementar la descomposición de los
casos, a partir de la documentación se obtiene de parte del cliente (HLD) y el equipo
de desarrollo (LLD) para que el equipo de QA pueda avanzar en el proceso de
pruebas según las entregas de los desarrolladores; llevar así un seguimiento de la
documentación.
El equipo de QA cuenta con un equipo base pero susceptible a cambios bruscos
no planeados, debido a que sus consultores tienen actividades en diversas áreas
de la empresa y también se comparten con otros proyectos afectando la
programación del equipo para la realización de las actividades. Un factor que debe
ser resaltado es la existencia de personal para capacitar en el uso de las diversas
herramientas, ya que la complejidad de las actividad requiere el manejo de varias,
entre ellas está una directamente relacionada con la comunicación con el cliente;
también se tienen en cuenta varios objetivos y actividades de vital importancia que
deben ser dirigidos a los responsables, por ejemplo la documentación entregada
parcial e/o incompleta.
5.8 ANTECEDENTES EN LA SITUACIÓN INICIAL.
Antecedentes en ETB.
Uno de los integrantes del equipo de QA participó en el proyecto desarrollado para
ETB, el cual contiene actividades similares a las del proyecto de Chile y Perú visto
desde Fusion Partners S.A.S. Este se desarrolló en la ciudad de Bogotá con la
empresa de telecomunicaciones de Bogotá (E.T.B) la cual usa el C.R.M (customer
relationship management) Siebel 8.0 para la gestión completa de las ventas y los
servicios de las tecnologías de Fibra, LTE y cobre.
60
El equipo de QA de ETB cuenta con actividades, procedimientos y estrategias que
se han ido desarrollando durante 3 años de experiencia a las cuales el integrante
de nuestro equipo de trabajo tuvo acceso, pero al no ser socializadas no se lograron
integrar al presente proyecto aprovechando así las tácticas para la actual labor.
Las metodologías procedimentales en ETB tienen una alta integralidad con otros
sistemas y su complejidad es mayor, el nivel de pruebas es significativamente más
detallada y la metodología se enfoca exclusivamente en el costo de falla. El
problema surgió porque el integrante no cayó en cuenta para realizar los aportes
necesarios ya que las pautas iniciales parecían ser similares para ambos proyectos
pero no iban a terminar con procedimientos parecidos y al hacer la intervención
podría estar variando la manera de trabajo de este nuevo proyecto que deben ser
dirigidos a los responsables, por ejemplo la documentación entregada parcial e
incompleta.
Antecedentes en TIGO.
Dos personas del equipo estuvieron involucradas en el proyecto de TIGO en
Honduras, por lo que la información que pudieron suministrar fue incluida en el
marco teórico. Se documentó y considero en las metodologías procedimentales
manejadas para los modelos propuestos, a pesar que las pruebas tenían una
complejidad muy semejante a la de Entel en Chile, no se hizo la revisión de
documentación ni inspiración adoptada de la metodología aplicada en Honduras.
Sin embargo las dos personas se prestaron para brindar algunas guías necesarias
para la elaboración del modelo.
5.8 MODELO DE LA SITUACIÓN INICIAL.
Descripción del modelo de la situación inicial.
El modelo que representa la situación inicial, considera todo el análisis
anteriormente expuesto, ya que fue absolutamente necesario comprender el
sistema actual mediante la definición de la estructura de procesos, los factores y
variables que permiten su relacionamiento, especificando los pasos iniciales de la
reestructuración.
A continuación se definen los principales elementos que interactúan en el modelo:
Las entidades que se participan en el modelo de la situación inicial son el
cliente, el líder de desarrollos, el líder del equipo de pruebas, el equipo de
pruebas y los consultores de pruebas.
61
Las entradas al equipo de QA son documentaciones formales(HLD)Y (LLD),
que son entregados parcialmente y no todos al tiempo
Los procesos que se desarrollan para la prueba de los casos inician con un
acercamiento superficial a la documentación disponible para identificar sus
componentes, se procede a la repartición de los casos identificados para su
análisis, y cada consultor inicia la lectura.
Las relaciones que se dan son específicamente al interior del equipo de QA,
entre los consultores de pruebas y el líder del equipo, quien hace el punto de
contacto con el resto del equipo.
Las salidas que se generan del proceso de pruebas son los resultados de las
pruebas que son notificados vía Skype al líder del proyecto en caso de
presentar algún defecto o error.
Ilustración 10 Proceso de pruebas de Software para el modelo inicia
Fuente 10 Creación propia
62
Diagrama del modelo de la situación inicial.
Fuente 11Creación propia
Ilustración 11 Modelo de la situación inicial.
63
6 MODELO PROPUESTO BASADO EN EL FUNDAMENTO TEÓRICO.
En este capítulo se exponen los aspectos impactados con el modelo, considerando
todo el análisis expuesto en el capítulo anterior y visto desde las temáticas
abordadas en el marco teórico, ya que todas mejoras organizacionales
consideradas están basadas en el fundamento teórico; para esto se presenta a
continuación el desarrollo de un análisis detallado del sistema inicial visto desde las
temáticas abordadas en el marco teórico, para dimensionar el modelo desde los
mismos aspectos y visualizar su evolución a través del desarrollo de las prácticas
en la empresa. En cumplimiento de los objetivos específicos de este documento,
principalmente la documentación del proceso, generar una propuesta
procedimental a través de la estandarización de procesos, mediante técnicas
propias de la ingeniería industrial, para ser socializadas y ajustadas, y sobre todo,
el cumplimiento del objetivo principal que es Proponer modelo de mejora de
procesos de pruebas y realimentación de desarrollos de software, mediante la
estandarización de procesos y creando manuales de procedimientos,
(requerimiento de la empresa); facilitando desarrollo de pruebas, capacitación y
comunicación interna, y cumpliendo los requerimientos del cliente enfocados en
reducir tiempos y costos de gestión.
Siendo exigida indispensablemente la estandarización de cada uno de los
desarrollos que genera la empresa, pues cada cliente debe obtener junto con el
resultado final, los soportes documentados de cada proceso que se pueda
desempeñar sobre las implementaciones que suplen los requerimientos del cliente;
la empresa requiere aplicar un control de calidad que garantice el buen desempeño
de sus resultados y asegure los servicios ofrecidos, mediante la aplicación de
pruebas al sistema; estas pruebas deben realizarse antes de cada entrega que se
haga a Entel (Chile).
Se identificó la necesidad de un modelo de mejora a los procesos y procedimientos
básicos en el desarrollo de pruebas y realimentación de desarrollos de software,
también la estandarización de procesos por medio de manuales, matrices y
diagramas; control de calidad y diseño de pruebas con sus ciclos, según
requerimiento de la empresa, al iniciar este proyecto. Se requirió aplicar
estandarización de procesos, análisis de métodos y tiempos, el control de calidad,
diseño y propuestas de mejoras de calidad del área de pruebas de desarrollos a
los procesos que la empresa consideró necesarios para Entel (Chile) en los
ambientes de prueba.
64
Entonces la pregunta que se pretende resolver específicamente en este capítulo es:
¿cuál es el modelo específico de mejora de procesos de pruebas de desarrollo de
software para la empresa según su naturaleza?, teniendo en cuenta la
documentación de la estandarización de procesos y procedimientos como un
requerimiento obligatorio del cliente (en primera instancia), la búsqueda simultánea
de ir mejorando los procesos implicados y la inminente necesidad de analizar,
documentar, re-diseñar y estandarizar los procedimientos y comportamientos de los
desarrollos al integrarse a la plataforma para acceso y dominio general; y a su vez
considerando que en los procesos están involucrados ambientes y consultores de
diferentes países, el modelo exige incluir todos los casos (por su magnitud,
complejidad y variedad) para reducir tiempos de capacitación, garantizar la
universalidad de información y haciendo más eficientes los procesos de pruebas.
Para generar un resultado final que represente un completo uso a la empresa, desde
el suplir los requerimientos del cliente, hasta garantizar el cumplimiento en tiempos
y calidad de sus servicios dando a su equipo de calidad un modelo de mejora
efectivo.
Resultó pertinente implementar medidas de desempeño, la estandarización de
procesos de pruebas, mejorar a los procesos y/o procedimientos básicos de
pruebas y realimentación de desarrollos de software, para hacer más eficientes los
procesos pues actualmente durante la implementación de algunos desarrollos se
pueden dañar las integraciones o producir cambios no deseados en el ambiente,
durante las pruebas pueden realizarse procedimientos agotadores, redundantes,
inadecuados o innecesarios a falta de una clara estandarización de procesos y
mejora en el diseño de los mismos, lo que se traduce en más tiempo, por tanto un
aumento innecesario de costos de honorarios y multas por exceder plazos de
entrega.
A continuación se propone el modelo de mejora de procesos de pruebas y
realimentación de desarrollos de software, mediante la estandarización de procesos
y creando guías de procedimientos (requerimiento de la empresa); facilitando
desarrollo de pruebas, capacitación y comunicación interna, y cumpliendo los
requerimientos del cliente enfocados en reducir tiempos y costos de gestión. Para
iniciar fue absolutamente necesario Comprender el sistema inicial mediante la
definición de la estructura de procesos, los factores y variables que permiten su
relacionamiento, especificando los pasos iniciales de la reestructuración, lo cual se
presenta en el capítulo de situación inicial.
Este modelo genera una propuesta procedimental a través de la estandarización de
procesos, mediante técnicas propias de la ingeniería industrial, para ser
65
socializadas y ajustadas, de manera que la empresa las pueda seguir aplicando en
las siguientes fases del proyecto y otros proyectos; simultáneamente se documenta
este caso en el que adaptamos técnicas, teorías y partes de otros modelos
ajustados específicamente a esta organización, lo cual puede resultar útil para otras
organizaciones , ya sean de desarrollo de software o no.
6.1 FUNCIÓN DEL INGENIERO INDUSTRIAL EN EL MODELO.
El modelo que se propuso al iniciar la práctica pretendía inicialmente incluir el rol
del ingeniero industrial en la organización por medio de la articulación de las
diferentes áreas de la empresa para la consecución de las metas83, específicamente
las articulaciones directas del área de QA con el resto de áreas de las que depende
su buen desempeño; para la aplicación del diseño de procesos y el desarrollo
continuo de nuevas versiones del modelo de mejora de sistemas integrados de
hombre y equipo84, de procesos y procedimientos de pruebas de software ; así como
el enfoque en funciones técnicas y administrativas (organizar, dirigir, coordinar) de
la organización,85 implícitas en el modelo, relacionadas entre sí de manera que se
hagan los procesos de una manera más adecuada de cumplir las funciones propias
del área.
También al aplicarse el modelo, por medio de la inclusión del ingeniero industrial en
el proceso, permitió un acercamiento a la optimización de procesos de transferencia
interna de conocimiento, al ubicar cada proceso en documentos escritos de fácil
acceso y comprensión para cualquier persona del equipo de trabajo, que a su vez
llevó a una estandarización de los procesos y la universalidad de la información que
se manejaba a nivel organizacional.
En cumplimiento de la normalización y el garantizar la calidad, el ingeniero aporta
al control interno de la calidad con mecanismos específicos de la calidad del
software: los estándares (IEEE, ISO, etc.), las revisiones, las pruebas de software,
colección y análisis de errores86 y la realimentación al proceso de desarrollo para la
corrección de errores y defectos; Esto implica un aporte directo a la eficiencia y
eficacia de los procesos de la empresa.
83 PEÑA, Javier Parra. La ingeniería industrial en el contexto del desarrollo sostenible. Revista Tecnura, 1999, vol. 2, no 4, p. 28 84 PARRA DÍAZ, Cristian Andrés; PRIETO BARRIGA, Jorge Andrés. Estudio del estado del arte y tendencias educativas en universidades de Finlandia y Noruega en el programa de Ingeniería Civil como parte de un análisis prospectivo para Colombia. 2014. 85 FAYOL, Henri; TAYLOR, Frederick Winslow. Administración industrial y general. Orbis, 1987. p 4,5 86 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988.
66
6.2 CARACTERÍSTICAS PROPIAS DEL TRABAJO CON DESARROLLO DE
SOFTWARE EN EL MODELO.
Para el modelo propuesto se tuvo en cuenta que el proceso de desarrollo de
software resulta caro, riesgoso, incierto y lento para algunas condiciones de negocio
modernas87, por lo que se hace un acercamiento a la ingeniería de software en
cuanto a la aplicación de un enfoque sistemático, disciplinado y cuantificable al
desarrollo, operación y mantenimiento de software. Visto desde la perspectiva de
un ingeniero industrial, sabiendo que la propuesta de modelo que se diseñó exigía
adaptabilidad y agilidad en varias fases o etapas de perfeccionamiento; siempre
basando el modelo en un compromiso organizacional con la calidad, de la que
parten los procesos, sobre los que se eligen los métodos y finalmente se aplican las
herramientas88.
El modelo realiza la inserción de la perspectiva de las características propias de
proceso y producto tecnológico como: su mínimo desgaste a través del tiempo, su
adaptabilidad a los requerimientos del cliente, la posibilidad de hacerlo evolucionar
o versionar corrigiendo sus defectos, su desarrollo basado específicamente en el
intelecto del equipo de trabajo y su disponibilidad para estandarizar sus procesos
que se realizan frecuentemente mediante guías paso a paso, que pueden incluso
contener imágenes tomadas directamente de la herramienta que se esté usando.
Identificados los retos que representan las características propias del proceso para
implementar un desarrollo de software, se sabe que el modelo debe aportar a la
organización herramientas que sirvan de apoyo para avanzar aunque no es una
tarea fácil89 y tenga procesos muy intrincados y complejos90; ya que siendo el
desarrollo la razón de ser de la empresa es parte del proceso de formación de la
calidad y reconocimiento en la industria.
87 PONS, Claudia; GIANDINI, Roxana Silvia; PÉREZ, Gabriela. Desarrollo de software dirigido por modelos. 2010. p 23. 88 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 11. 89 CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. Metodologías Ágiles en el Desarrollo de Software, 2003, p. 90 BUSTOS, Ricardo A. Gacitúa. Métodos de desarrollo de software: El desafío pendiente de la estandarización. Theoria, 2003, vol. 12.
67
La aplicación del modelo implica la organización de recursos91, el tiempo de
entrega92 y la complejidad en los requerimientos93 haciendo que sea difícil de
administrar, por lo que es indispensable la intervención del ingeniero industrial; con
la propuesta del modelo que sirva específicamente para el proceso de desarrollo
para Entel, del producto transformador de información (al producir, administrar,
adquirir, modificar, desplegar o transmitir) y vehículo para la distribución productos
(sistemas operativos, redes de comunicación, creación de ambientes de software y
herramientas de control)94 que el equipo de calidad debe verificar para controlar la
calidad del mismo.
El modelo considera las funciones que se cumplen en la herramienta Siebel, toma
los datos e información disponible de cada proceso y la estandariza, conforme se
identifique en las documentaciones del sistema y la colaboración del cliente y los
desarrolladores para tener una guía clara antes de realizar las pruebas de
funcionamiento en el sistema. Se realiza las pruebas y realimenta el desarrollo
según sea necesario, así mismo actualiza y documenta usando las herramientas de
control de información y calidad. También mide su efectividad durante la gestión con
el seguimiento de tiempos y cumplimiento, como aporte a la búsqueda del
aseguramiento de la calidad y la mejora continua.
Se identifica en las características propias del sistema de funcionamiento de la
empresa fusion partners, que las mayores demoras que se presentan en los
procesos de prueba de los casos de uso se debe a falta de información o claridad
respecto a la secuencia lógica del proceso; ésta información se recibe del área de
desarrollo y de los requerimientos del cliente. El modelo pretende resolver
dificultades como esta, por medio de la aplicación de una metodología que brinde
al final del proceso la documentación total de cada proceso definiendo el paso a
paso requerido por el cliente, con los requerimientos de datos antes de iniciar las
pruebas y con la claridad suficiente para que sea de tanto uso interno de la empresa
como para el uso del cliente final. Se hace un listado de los motivos que generan
pérdidas de tiempo, retrasos en entregas, reprocesos, confusiones e imprecisiones
que afectan el proceso de pruebas:
91 PINO, Francisco; GARCÍA, Félix; PIATTINI, Mario. Revisión sistemática de mejora de procesos software en micro, pequeñas y medianas empresas. Revista Española de Innovación, Calidad e Ingeniería del Software, 2006, vol. 2, no 1, p 19. 92 BUSTOS, Ricardo A. Gacitúa. Métodos de desarrollo de software: El desafío pendiente de la estandarización. Theoria, 2003, vol. 12. 93 CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. Metodologías Ágiles en el Desarrollo de Software, 2003, p. 94 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 3.
68
Falta de documentación.
Imprecisión o falta de claridad en los procesos descritos en la
documentación.
Modificaciones no informadas de requerimientos o diseños.
Durante los procesos de desarrollo se pueden generar modificaciones del
requerimiento del cliente para adaptar al sistema, no son comunicados en tiempo
real al área de calidad, ni hay acceso a documentación que los actualice.
La información que se recibe de ambos documentos es de baja calidad (en
la mayoría de las ocasiones) pues es incompleta, falta de claridad, sin un
orden lógico, con deficiente redacción y elaborado para uso interno del
equipo de desarrollo; por lo que presenta conceptos que no están en el
dominio del equipo de calidad y procesos propios de desarrollo, más no el
proceso para probarlos, ni como verificar su funcionamiento interno en
Siebel.
No hay contacto directo con el cliente desde QA.
No hay contacto directo de los consultores de pruebas con los
desarrolladores.
La validación de los desarrollos era extensa y poco eficiente, debido a la
identificación de requerimientos de pruebas, durante la ejecución de pruebas
y desarrollos.
La falta de un ambiente exclusivo para pruebas genera choque entre
desarrollos y pruebas, que generan de demoras.
Se realizan validaciones sin el criterio correcto
Se realizan recurrentes capacitaciones de uso de herramientas nuevas y
otros procesos no establecidos por el equipo (ni la empresa), por solicitud
del cliente para un posible futuro uso, que no son documentados, generan
demora, reproceso y aumento costos; Y ya finalizada la práctica no se
usaron.
Falta de comunicación
Falta de organización en los procesos de pruebas y estandarización.
El exceso de formalización para la comunicación interna (sin estandarización,
ni detalle apropiados)
6.3 METODOLOGÍAS DE LAS EMPRESAS EN EL MODELO.
Inspirados en las metodologías usadas por esta y otras empresas del mismo sector
en otros proyectos, se pretende facilitar el manejo de información y la
69
comunicación95 dentro de la empresa, principalmente a partir del área de QA con
los demás componentes con que se relaciona dentro de la organización, para
cumplir con sus funciones principales; también se busca la normalización de sus
protocolos en procesos de pruebas de desarrollo y de verificación del nivel de
calidad de sus resultados. Se utilizan matrices en el diseño de los procesos
estandarizar cada caso de prueba (nivel de uniformidad con precisión
terminológica)96. Uso formatos específicos diseñados para cada actividad por
separado y solo implementar CLM a casos exitosos. Se propone la creación de
manuales terminada cada fase, sin embargo no el cliente no los considero
necesarios debido al uso de CLM.
El consenso del conocimiento (consolidado de la experiencia), como herramienta
para la transferencia tecnológica, el desarrollo de conocimiento y el buen
funcionamiento de la organización. Para esto se realizó la recopilación de la
información útil captada de las personas del equipo de trabajo y documentos de la
empresa en anteriores proyectos; se usa esta recopilación para apoyar el desarrollo
del nuevo proyecto en Entel y la elaboración ordenada de este modelo propuesto,
para disponer de la información de modo que pueda ser utilizada y documentada en
este informe final de pasantías.
Una de las metodologías aplicadas por otras organizaciones y en otros proyectos
son las categorizaciones de elementos a considerar (recursos, condiciones,
herramientas, insumos, etc.), que se utiliza para identificar las relaciones que se
requerían mantener, fortalecer o crear teniendo en cuenta las posibles
herramientas utilizables97. Alrededor de cada uno de estos elementos para hacer
explícita su disposición, se usan estos principios para distinguir las partes del
modelo a considerar a lo hora de diseñar el modelo inicial, el modelo propuesto y
recomendación propuesta.
La metodología a aplicar en el modelo que se propuso estaba encaminado a la
búsqueda de la eficiencia en los procesos de pruebas, lo que a su vez sirviera a
reducir los tiempos para llegar a la depuración de las pruebas y con esto reducir los
tiempos del proceso productivo; aportando a la calidad y la comunicación interna de
95 BUSTOS, Ricardo A. Gacitúa. Métodos de desarrollo de software: El desafío pendiente de la estandarización. Theoria, 2003, vol. 12. 96 MUÑOZ, Coral Calero; VELTHUIS, Mario G. Piattini; DE LA RUBIA, María Ángeles Moraga. Calidad del producto y proceso software. Editorial Ra-Ma, 2010. 97 MUÑOZ, Coral Calero; VELTHUIS, Mario G. Piattini; DE LA RUBIA, María Ángeles Moraga. Calidad del producto y proceso software. Editorial Ra-Ma, 2010.
70
la organización98, todo esto en miras a estandarizar los procesos y lograr un
acercamiento a la universalidad de la información disponible de la organización y
realizada en la parte final del proceso garantizando así que el proceso
estandarizado no sufra posteriores cambios o adaptaciones. En este proyecto se
desarrolla el modelo entorno a los procesos de pruebas de desarrollos, cuya
principal función es la validación del cumplimiento de requisitos y el control de
calidad del proceso de producción de desarrollos, adaptando los modelos
encontrados en anteriores proyectos semejantes y los propuestos teóricamente a
las condiciones y disposiciones propias de la organización.
El primer modelo se propuso en torno a la mejora de los procesos de pruebas de
desarrollos, para la validación del cumplimiento de requisitos y el control de calidad
del proceso de producción de desarrollos; a continuación se profundiza en los
métodos o metodologías de validación usadas en el modelo propuesto.
6.4 MÉTODOS DE VALIDACIÓN EN EL MODELO.
Los métodos de para la validación de los desarrollos empíricos (ingeniería de
software basada en la evidencia) que se aplican en este modelo serán:
experimentos (control de variables para comprobar efecto), que es el que ya se
venía utilizando; Además se aplicarán encuestas (cuantitativas y cualitativas en
retrospectiva para conclusiones descriptivas) y casos de estudio (siguiendo uno o
varios atributos para establecer relaciones) los cuales entrarán al final del proceso
con las medidas de tiempos y otros atributos99.
Para las pruebas se propone realizar revisiones técnicas efectivas de la
documentación disponible HLD Y LLD durante el diseño de la matriz de casos de
pruebas, con la mayor calidad y especificación posible, de manera sencilla pero
clara, para que al llegar el momento de realizar la prueba sean efectivas la mayor
cantidad posible, tal que los casos que presenten dificultades se aclaren
previamente con los desarrolladores o se consulten con el equipo de trabajo antes
de estar en la ejecución. Las técnicas que se están teniendo en cuenta es porque
son adaptables al enfoques del proyecto, pero aspirando a superar los límites de los
objetivos mínimos, y así dar valor a la empresa y sus procesos de pruebas.
El equipo de pruebas, preferiblemente se recomienda que sea fijo y que esté
destinado únicamente a esta labor para que la depuración se gestione
98 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. 99 MUÑOZ, Coral Calero; VELTHUIS, Mario G. Piattini; DE LA RUBIA, María Ángeles Moraga. Calidad del producto y proceso software. Editorial Ra-Ma, 2010.
71
continuamente, así siempre que esté disponible el equipo de desarrollo para
resolver y corregir errores o defectos se pueda hacer en el menor tiempo posible.
La cuantificación de los requerimientos y los objetivos de las pruebas se establecen
en el modelo antes de iniciarlas, también se considerar el perfil del usuario que
serán asesores en las tiendas (no necesariamente conocen sistemas de
información), esto durante el diseño de los casos de prueba en las matrices; sin
embargo debido a que los desarrollos se realizan por solicitud del cliente, están en
la primera fase y están sujetos a las características de Siebel, sólo se tiene en
cuenta la claridad de las indicaciones que se disponen. Se recomienda una revisión
técnica de parte de diferentes consultores a los casos ya diseñados, de modo que
puedan primeramente tener un acercamiento o aproximación a casos de prueba
(diferentes a los que el mismo haya diseñado) y a continuación pueda identificar
errores o imprecisiones en el diseño del caso de uso para su corrección inmediata
y previa al proceso de prueba.
El plan de pruebas es básicamente, realizarlas por orden de entregas de los
desarrolladores, preferiblemente agrupados del mismo documento (HLD y LLD), por
desarrollador o por dueño de prueba (quien diseñó el caso de prueba). Es posible
incluir el desarrollo de un plan de pruebas de “ciclo rápido”, que puede ser filtrado
durante la revisión previa, al distinguir los casos iniciales y básicos de otros casos
más complejos100, sin embargo el modelo propone el uso de la herramienta CLM
de la que dispone la organización por acuerdo con el cliente para el control en
tiempo real de los casos que están exitosos y los que no, con sus respectivos
comentarios, defectos y evidencias; esta herramienta envía un correo por defecto
o comentario a los desarrolladores, quienes ya tienen acceso a ella, para hacer
automática esta gestión y permitir que la herramienta genere el informe diario de
avance detallado.
El modelo propuesto se puso en práctica bajo una deficiencia de conocimiento
respecto a las posibles naturalezas de las pruebas (de caja, de integración,
validación, unitaria, funcional, de sistema, etc.), siguiendo los requerimientos de la
empresa en el orden en el que se nos fue dando acceso a la documentación por
parte del cliente, por lo que el plan de pruebas estaba totalmente dependiente del
orden de llegada de la información, sin la aplicación de ninguna clase de filtro o
distinción aparte del documento en el que venía la información asociada a cada
caso de prueba , que de hecho era información muy incompleta.
100 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 583.
72
Durante la aplicación también se fue evidenciando que se realizaban solo pruebas
unitarias, como método de validación tipo experimentos101, más no funcionales ni
mucho menos de sistemas, debido a que las validaciones solo era posible
realizarlas a partir de los requerimientos del cliente(HLD) y la información poco clara
brindada por los desarrolladores (LLD), es decir, que se estaban validando la
existencia de los elementos que se podían visualizar desde Siebel, sin verificar su
correcto funcionamiento interno, para lo que se requiere información más clara y
detallada de la forma correcta de validar los posibles resultados y conocer el
proceso interno con ayuda de los desarrolladores.
Para el desarrollo del modelo de pruebas se tuvo en cuenta el proceso
experimental102 basado en los pasos:
Definición: En el diseño de casos de prueba se incluye la definición de cada
caso de prueba y su objetivo junto con los pasos a seguir para completarlo
en la matriz de casos de prueba.
Planificación: para cada caso se realizaba según la disponibilidad de tiempos
de las personas del equipo de QA (los autores de este documento) y
conforme se visualiza en la matriz de seguimiento de desarrollos
(considerando sólo los casos desarrollados al 100% como casos para
programar prueba.). Su progreso también tiene seguimiento en la misma
matriz de casos de prueba.
Operación: consiste en realizar la prueba de cada caso así como todas las
validaciones posteriores necesarias, hasta llegar a hacerlos casos exitosos.
Durante la cual se toma la evidencia en el último paso del caso de prueba.
Análisis e interpretación: realizar la verificación del procedimiento descrito en
los documentos, validar los resultados de las pruebas.
Presentación y difusión: se realizan mediante la herramienta CLM con la
inclusión de las evidencias finales, comentarios y a disposición del cliente
para su seguimiento y verificación.
Algunos de los factores que se usan como métricas de revisión del proyecto son:
El tiempo que se usa para la revisión.
El tamaño del trabajo (para el proyecto se considerará por pasos del caso de
uso).
101 CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. Metodologías Ágiles en el Desarrollo de Software, 2003, 102 Ibíd.
73
Errores menores detectados durante la revisión.
Errores mayores detectados durante la revisión.
Errores no detectados durante la revisión.
Con estas medidas puede se realiza el cálculo de:
Tiempos totales de revisión y corrección.
Total de errores detectados.
Entre otras posibilidades, según considere el equipo de trabajo y conforme a la
primera etapa sobre la que se aplique del proyecto. Para el aseguramiento de la
calidad, se aplican con el nivel de formalidad apropiado para Fusion Partners S.A.S
que incluye: únicos revisores internos, preparación de casos realizada por los
mismos revisores, estructura de formatos de seguimiento unificado, seguimiento a
la gestión de defectos vía CLM y su registro en la herramienta de CLM.
6.5 ASEGURAMIENTO DE LA CALIDAD EN EL MODELO.
El modelo que se propone se desarrolla dentro del área de calidad de la empresa
en la cual se realizan procesos de pruebas a los desarrollos de software, que
realizan los desarrolladores, por lo tanto el modelo propone el desarrollo de los
elementos básicos del aseguramiento de la calidad incluyen los estándares, las
revisiones técnicas, las auditorías, pruebas, colección y análisis de errores,
administración del cambio, educación, de seguridad y riesgos.
Para incluirlos el equipo de trabajo propone el uso de matrices que sirvan para
unificar la información disponible respecto de cada caso de prueba, para verificar
su correcto funcionamiento, para estandarizar cada caso con sus componentes (tipo
de prueba, nombre, descripción, precondición y datos requeridos, pasos,
descripción del paso de prueba, resultado esperado, estado de ejecución,
comentarios y observaciones).
También el modelo se apoya en el uso de la herramienta CLM, el uso de los
diagramas de flujo que grafican cada proceso sirven para apoyar el proceso de
pruebas de los casos. Todo esto para aplicar control de calidad sobre los productos
que genera la empresa, siendo a su vez una herramienta para la transferencia
tecnológica, la administración del conocimiento, la capacitación del nuevo personal
y del personal del cliente; para reducir los tiempos y costos de los procesos de
pruebas. Se desarrolla como un producto final de estandarización, mediante tareas
sencillas como planear, describir, identificar, auditar, registrar y documentar todos
los procesos a considerar, entregados por el cliente; así como los errores o
74
defectos103 que se identifiquen y se gestionen durante los procesos de pruebas
depurando el proceso productivo.
Siendo los procesos de pruebas el centro y límite de la práctica, se tendrán en
cuenta los diversos tipos de pruebas que se requieren para el aseguramiento de la
calidad (de caja, de integración, validación, unitaria, funcional, de sistema, etc.)
básicamente para despliegue104. Para iniciar un proceso hacia el aseguramiento de
la calidad, se mide la eficacia del control de calidad en relación con la asignación
de recursos, la eficacia de la revisión y de las pruebas; siendo este modelo
propuesto de mejora de procesos un camino hacia el efecto final deseado de la
aplicación de esta práctica sobre la el proyecto de la empresa, mejora en la calidad
y eficiencia en los procesos; Sin embargo, se propone el compromiso organizacional
con la calidad implica el apoyo de la administración y busca alimentar la cultura de
la mejora continua105.
Se consideran únicamente desempeño, confiabilidad, conformidad y el servicio en
el modelo que se propone al proceso de pruebas de desarrollos, para realizar la
evaluación “suave” de la calidad de los desarrollos a probar durante el proyecto, por
medio de las revisión de requerimientos, se busca identificar: la calidad del
desempeño (cumplimiento, especificaciones y funcionamiento), la confiabilidad
(características y capacidades), la conformidad (estándares locales y externos, el
diseño y condiciones deseadas) y el servicio (mantenimiento o correcciones de ser
necesario). En cuanto a la evaluación “dura” evalúa factores que pueden ser
medidos de forma directa (defectos, tiempos, entre otros nombrados anteriormente)
como tarea realizada únicamente por el equipo de QA (pruebas o calidad),
apoyados en la herramienta de CLM (los registros durante las pruebas e informes).
La propuesta que se hace de la ejecución del modelo, tiene el enfoque en la
mejora continua del proceso de prueba. Por medio de la estandarización de
los casos se pretende lograr una optimización de los procesos, reducción de
tiempos y por tanto una reducción de costos; por lo tanto el modelo incluye
el uso de la metodología de estrategia seis sigmas para para incluirla en el
aseguramiento de la calidad considerando sus etapas, y aplicándolas de la
siguiente manera:
103 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 371-374. 104 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. 105 Ibíd. P 511.
75
Definir los requerimientos, objetivos, metas, procesos, resultados solicitados
y entregados al cliente claramente para identificarlos plenamente.
Medir los requerimientos, objetivos, metas, procesos y resultados para vigilar
cualquier anomalía que se pueda presentar, así como su causa e
identificarlos inmediatamente.
Analizar las métricas de defectos y determinar causas vitales, estas métricas
fueron definidas principalmente como tiempos.
Mejorar proceso eliminando causas, y usando las metodologías propuestas
anteriormente adaptadas de otros modelos y proyectos según sean
necesarios.
Controlar el proceso para evitar que vuelvan las causas, por medio de las
propuestas de mejora continua y el control de la calidad como cultura
organizacional aplicada.
Diseñar el proceso para evitar que vuelvan las causas y cumplir
requerimientos, tal como se propone con la aplicación del modelo aplicando
la estandarización y medición de los procesos.
Verificar el modelo reduzca defectos y haciendo seguimiento de que cumpla
con los requisitos de la organización conforme va cambiando el
requerimiento.
La aplicación de estas metodologías pretende incluir la cantidad mínima de
interacciones necesarias entre los agentes del sistema, garantizando la calidad de
las mismas, evita los conflictos por disposición de tiempo, reduce la redundancia en
las habilidades asociadas a cada rol o proceso, evita los reprocesos o demoras y
toma en cuenta el conocimiento obtenido previamente106 107 de la organización en
otros proyectos. Naturalmente esta aplicación genera un costo a la organización,
especialmente al principio de su uso debido a todo lo que se incurre ya sea en
tiempo o dinero y ya sea por prevención, evaluación o falla.
Este modelo aplica principalmente costos de prevención con la gestión de las
actividades de control y aseguramiento de la calidad, las actividades técnicas en los
diseños y modelado de requerimientos, la planeación de pruebas y su consulta con
los desarrolladores.
En cuanto a los costos de evaluación están incluidas las actividades de
investigación sobre los casos recurrentes, revisiones técnicas (ya contempladas por
106 RODRÍGUEZ, Julián; TORRES, Miguel; GONZÁLEZ, Enrique. La Metodología AOPOA. Avances en Sistemas e Informática, 2007, vol. 4, no 2. 107 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 375.
76
el cliente), tomas de medidas, hacer pruebas y depurar. Finalmente los de falla son
aquellos que se eliminarían si no llega el producto con errores al cliente, e incluso
si se depara mayor atención durante el diseño de los casos a nivel interno, antes de
subirlos a la herramienta de CLM y antes de iniciarse las pruebas, de manera que
se tenga previamente el requerimiento de datos o apoyo necesario. También en
caso de tener defectos resolverlos antes de que el proyecto sea entregado por
medio de repeticiones, efectos colaterales y asociados o externos. Todo esto para
evitar después de ser entregados, tener que incurrir en costos de soluciones,
quejas, cláusulas, devoluciones sustituciones, garantía, reputación, entre otros108.
6.6 MODELOS EN EL MODELO.
Siendo que el modelo es una abstracción formada por variables y conceptos
interrelacionados, para dar una explicación coherente del funcionamiento
organizacional109 de un sistema, se realiza la propuesta de un modelo que incluya
algunos de los modelos consultados y revisados previamente, según puedan ser
adaptados cada uno de ellos como se presenta a continuación.
Dentro del modelo se pretende el desarrollo de los diagramas de flujo para cada
caso de prueba, de manera que sirvan de guía para dar claridad al proceso de
prueba para cada caso, sin embargo durante la aplicación de identificó que el
cliente y los desarrolladores han brindado estos apoyos al proyecto junto con los
documentos HLD y LLD. Así que el modelo propuesto aplicó el uso esta
herramienta para brindar claridad, para que resulte más fácil visualizar las
relaciones y procesos implicados, y como apoyo para comprender el problema y
encontrar la solución110, así como para representar cada paso durante el proceso y
las operaciones que intervienen en el.
Teniendo en cuenta el Modelo de contingencia y la ley de variedad requerida de
Ashby este modelo implica la especialización de algunas partes del proceso de
pruebas, para reducir la complejidad del proceso completo, esta especialización
será específicamente en la documentación de los procesos y con el análisis de la
información disponible en documentos y dado caso con apoyo del equipo de trabajo,
de manera que se unifique la información111. Esto es parte del trabajo en equipo que
108 Ibíd P 347. 109 RODRÍGUEZ MANCILLA, Darío. Diagnóstico organizacional. Alfaomega. Ediciones Universidad Católica de Chile, 2005. 110 BUSTOS, Ricardo A. Gacitúa. Métodos de desarrollo de software: El desafío pendiente de la estandarización. Theoria, 2003, vol. 12. P 29. 111 RODRÍGUEZ MANCILLA, Darío. Diagnóstico organizacional. Alfaomega. Ediciones Universidad Católica de Chile, 2005. P 3.
77
se pretende motivar dentro de la organización, o como lo describe Mintzberg en la
estructura en cinco, el trabajo colectivo. Aplicado a la división del trabajo dentro del
equipo de QA para realizar las tareas y coordinar de manera organizada, se
propone el uso de mecanismos coordinadores básicos con comunicación informal y
supervisión directa para coordinar el trabajo y por supuesto la estandarización de
los procesos de trabajo112 que es la herramienta principal sobre la cual se puede
mejorar el proceso de pruebas de desarrollo.
Otro modelo que se considera aplicable es el modelo en espiral para el desarrollo
del modelo que se propone, este modelo entonces, genera la necesidad de realizar
las etapas de comunicación, planeación, modelado, construcción y despliegue de
manera concurrente. En la aplicación del modelo se usará para aportar al modelo
una mejora continua, por medio de versionamientos más ajustados y adaptados a
las cambiantes necesidades de la empresa, así como a sus recursos y entorno.
Para el diseño del modelo propuesto se considera de la metodología AOPOA, el
enfoque organizacional aplicado en el diseño como una descomposición en
unidades autónomas que compartan objetivos y hagan a gestión correcta de los
recursos, en cada etapa del proceso de manera que sirva para realizar una división
de partes del proceso con actividades comunes, o muy parecidas, junto con sus
agentes y relaciones (sin llegar a la descomposición de roles demasiado
específica).
Como el modelo de esta primera propuesta tiene por objetivo la mejora de procesos
de software, realimentando los desarrollos y los procesos propios de las pruebas;
resulta un proceso que aporta a la calidad de los resultados, implicando no solo el
proceso para realizar esta propuesta, sino también, por parte de la empresa el
disponer de tiempo, recursos, disposición, interés y los costos correspondientes o
asociados; a pesar de que de inmediato no se puedan identificar claramente las
ventajas de su aplicación a los procesos para acercarse a un resultado efectivo y
exitoso113 se requiere la continuación del proceso y de la formulación de evolutivos
del modelo, lo cual puede implicar la inclusión de modelos de mejora existentes u
otros diseñados dentro de la empresa según sus necesidades.
El modelo no pretende generar cambios inmediatos, pero sí evaluar las mejoras que
se vayan introduciendo durante el proyecto de mejora en su aplicación para ser
comparadas con las siguientes versiones de modelos que se van ajustando a las
112 Ibíd. 113 TRUJILLO-CASAÑOLA, Yaimí; FEBLES-ESTRADA, Ailyn; LEÓN-RODRÍGUEZ, Giraldo. Modelo para valorar las organizaciones al iniciar la mejora de procesos de software. Ingeniare. Revista chilena de ingeniería, 2014, vol. 22, no 3, p. 413.
78
necesidades de la empresa, puede ser comparadas cada una con el inicio de este
proceso. Para evaluar de manera objetiva el modelo se usan como indicadores los
tiempos nombrados en las metodologías, los cuales se recomienda que sean
revisados, comparados y analizados terminada la aplicación de cada modelo; así
como también se recomienda la debida documentación de cada modelo con su
evaluación para tener la información de las experiencias de la organización114 como
base útil en su proceso de crecimiento.
Sabiendo que las propuestas de mejora que se aplique a nivel organizacional es
más económica pero sus resultados no se obtienen a corto plazo115, tal como lo
plantea este modelo. No se intentó incluir mejoras de nivel técnico porque son más
costosas a pesar de que las mejoras se ven a corto plazo, porque se identifica en
la empresa el requerimiento organizacional mayor que el técnico, pues la empresa
cuenta con apoyos técnicos de alto nivel que no son aprovechados, o por la forma
en la que se usan resultan entorpeciendo la agilidad de los procesos internos.
6.7 FACTORES INFLUYENTES EN LA CALIDAD EN EL MODELO.
En el proyecto de desarrollo de software que Fusion Partners realiza para Entel de
Chile, se identificó la alta complejidad de sus partes y entorno116, dificultad
considerable para estimar el tiempo requerido y la dificultad en la comunicación117;
y considerando de primordial necesidad intervenir principalmente en la
comunicación entre las parte. Este modelo propone al proyecto el uso de la
estandarización como mecanismo coordinador básico para fortalecer las
comunicaciones118 y el uso de marcos de referencia para pruebas, que fueron
definidos como matrices de diseño de pruebas con sus evidencias en CLM, para
mejorar la relación de cooperación interna y con el cliente119 con estos apoyos en
comunicación e información. Los productos tecnológicos (herramientas) en que el
114 Ibíd. p 414. 115 PINO, Francisco; GARCÍA, Félix; PIATTINI, Mario. Revisión sistemática de mejora de procesos software en micro, pequeñas y medianas empresas. Revista Española de Innovación, Calidad e Ingeniería del Software, 2006, vol. 2, no 1, p 15. 116 RODRÍGUEZ MANCILLA, Darío. Diagnóstico organizacional. Alfaomega. Ediciones Universidad Católica de Chile, 2005. 117 BUSTOS, Ricardo A. Gacitúa. Métodos de desarrollo de software: El desafío pendiente de la estandarización. Theoria, 2003, vol. 12. 118 RODRÍGUEZ MANCILLA, Darío. Diagnóstico organizacional. Alfaomega. Ediciones Universidad Católica de Chile, 2005. 119 PINO, Francisco; GARCÍA, Félix; PIATTINI, Mario. Revisión sistemática de mejora de procesos software en micro, pequeñas y medianas empresas. Revista Española de Innovación, Calidad e Ingeniería del Software, 2006, vol. 2, no 1, p 19.
79
equipo de trabajo se apoya durante el proceso de desarrollo del software en el
proyecto para Entel son con licencia (Siebel, CLM, Zoho) y libres (drive, Skype,
Webex) por preferencia del equipo de trabajo; estas herramientas suplen la
totalidad de los requerimientos actuales.
En la propuesta de mejora de los procesos de estimación de costos de software del
caso del sector de software de Barranquilla, presenta categorías del agente
herramientas tecnológicas, de las que tendremos en cuenta los puntos específicos
de categoría alta y los aspectos mejor calificados, para tenerlos como guía de
objetivos a alcanzar y recomendar dentro de la práctica, junto con las variables
asociadas que especifican su grado de importancia dentro del modelo.
Con respecto al agente herramientas tecnológicas de categoría alta, en este caso
la empresa Fusion Partners, posee los siguientes aspectos: el manejo de gestión
de proyectos (para apoyar la medición de avances del cronograma de trabajo),
establecer prioridad de los requerimientos (pero solo en desarrollo), el cliente tiene
acceso a la herramienta de gestión de proyecto y plataforma de desarrollo, el equipo
de desarrollo utiliza diferentes ambientes (para mantener el producto estable); y
finalmente el objetivo de este modelo: el manejo de metodologías y métodos para
asegurar la calidad del producto, en lo que el modelo incluye la estandarización de
procesos y la propuesta de establecer un ambiente específicamente para pruebas
(QA)120.
Aspectos característicos que este primer modelo propuesto considera como
objetivos en la calidad del proyecto:
Alcance y requerimiento: Se establecen los casos de pruebas funcionales y
no funcionales del sistema de manera clara y específica a partir de
documentación y de ser necesario con consultas a cliente y equipo de
desarrollo.
Descomposición: Al tener los casos de prueba claros, se descomponen en
actividades o tareas a fin generar entregables en el menor tiempo posible
Estabilidad de los requerimientos: evitar cambios significativos de los
requerimientos de datos para cada prueba lo largo del ciclo de pruebas,
posterior al diseño.
Histórico de proyectos: El equipo de QA cuenta con una base de datos
histórico donde se almacena información relacionada con la descripción del
120 CARUSO, Nohora Nubia Mercado; DEL CASTILLO, Edwin Puerta; NAVARRO, Katherinne Salas. Mejora de los procesos de estimación de costos de software: Caso del sector de software de Barranquilla. Revista de Ingenierías: Universidad de Medellín, 2015, vol. 14, no 27, p. 24.
80
caso de prueba, complejidad del caso de prueba, tiempo real de la actividad,
duración general del proyecto en horas.
Documentación: es primordial documentar la especificación de casos de prueba y sus progresos con toda la especificación y evidencias en el diseño ubicado en herramientas disponibles para todo el equipo en tiempo real y preparado para la creación del manual de usuario.
Organización el equipo: El equipo de QA debe contar con un equipo base para cumplir las labores de la implementación de este modelo propuesto. Los diferentes roles se pueden combinar más de uno en una sola persona, solo se requiere un líder y consultores de pruebas, a todos se les consideran las métricas de igual manera.
Competencias del equipo de trabajo: Existencia de personal capacitado para utilizar las diversas herramientas que van a ayudar al equipo a trabajar conforme a la metodología seleccionada.
Comunicación con el cliente: Constante acceso al proceso de pruebas por parte del cliente, acceso a las plataformas en tiempo real y disposición de toda la información en CLM del progreso del proyecto
Seguimiento: El líder del equipo realiza reuniones diarias para evaluar el cronograma de trabajo. Se evalúan cumplimiento de estimados, métricas establecidas y evolución de modelo.
6.8 MODELO PROPUESTO.
Descripción del modelo.
El modelo propuesto se presenta a continuación teniendo en cuenta
categorizaciones de elementos a considerar (recursos, condiciones, herramientas,
insumos, etc.). También a continuación se presenta el sistema mediante la
definición de la estructura de procesos, los factores y variables que permiten su
relacionamiento, especificando los pasos iniciales de la reestructuración, se
presentan sus componentes:
Las entidades que se participan en el modelo actual son el cliente, el líder de
proyecto, el líder del equipo de desarrollo, el líder del equipo de pruebas, el
equipo de desarrollo y los consultores de pruebas. Ingresa al equipo de
desarrollo un líder en sitio que coordina al equipo de trabajo de desarrollo y
distribuye las tareas conforme a las especialidades y capacidades de cada
desarrollador121 para identificar las relaciones que se requerían mantener,
121 MUÑOZ, Coral Calero; VELTHUIS, Mario G. Piattini; DE LA RUBIA, María Ángeles Moraga. Calidad del producto y proceso software. Editorial Ra-Ma, 2010.
81
fortalecer o crear teniendo en cuenta las posibles herramientas utilizables;
el anterior líder de desarrollo pasa a ser el líder de proyecto.
Las entradas al equipo de QA son documentaciones formales (HLD) y (LLD), en entregas parciales del total de documentación requerida, la información relacionada con las consultas al desarrollador y la confirmación para volver a probar.
Los procesos que se desarrollan para la prueba de los casos inician con un acercamiento detallado a la documentación disponible para identificar sus componentes, se procede a la repartición de los casos identificados para su análisis, y cada consultor inicia la lectura de manera analítica y luego consulta al desarrollador directamente cualquier inconsistencia o imprecisión, inicia el diseño del caso paso a paso en las matrices para estandarizar cada caso y se identifican los requisitos de datos para el desarrollo de las pruebas de los casos en CLM, para identificar defectos y errores que son gestionados directamente con cada desarrollador y en caso de ser necesario se realimenta la matriz de pruebas. Finalmente se verifica el estado exitoso y se toman las métricas.
83
Las relaciones que se dan son entre los consultores del equipo de QA y el
equipo de pruebas, generando múltiples puntos de contacto directos para la
gestión de errores y defectos; ambos equipos con sus respectivos líderes y
los líderes de ambos equipos con el líder de proyecto y el cliente.
Las salidas que se generan del proceso de pruebas son los resultados de las
pruebas que son notificados vía Skype al desarrollador en caso de presentar
algún defecto o error, el estado final de cada prueba, la actualización de la
matriz en los espacios relacionados a la ejecución, sus anotaciones y
observaciones, las métricas del modelo y las evidencias de estados
defectuosos y exitosos.
Diagrama del modelo.
Por medio de una gráfica o tabla se puede mostrar el tiempo que tomó el desarrollo
cada etapa de este trabajo.
Fuente 13 Creación Propia
Ilustración 13 Diagrama del modelo
84
6.9 METODOLOGÍA DE LA EJECUCIÓN DEL MODELO PROPUESTO.
Para lograr los objetivos propuestos se aplicó la siguiente metodología a seguir durante la práctica se realizaron en el orden en que los desarrolladores dieron señal del inicio de pruebas o entregaron diseños de procesos.
Se dio inicio por medio de la recopilación de información disponible la cual incluyó
diseño de requerimientos, diagramas de proceso, manuales, matrices o cualquier
tipo de conocimiento explícito y la información que se pueda obtener directamente
de las personas encargadas de cada proceso para aprovechar también el
conocimiento tácito. Se hizo la continuación un acercamiento a las plataformas y
ambientes de prueba, para reconocer su funcionamiento e iniciar la aplicación de
pruebas a los desarrollos integrados para identificar los procedimientos correctos
de acuerdo con las configuraciones propias del sistema.
Se continuó con la creación y actualización de matrices de casos de prueba que
implicó revisar los HLD, LLD según requerimiento de la empresa para Entel (Chile)
en los ambientes de prueba y su funcionamiento dentro de Siebel; las matrices se
realizaron con la descripción paso a paso y la información relacionada, en vez de la
creación actualización de manuales. Las matrices se usaron para estandarizar y
rediseñar casos de pruebas de modo que permiten a cualquier persona retomar el
ciclo de pruebas en cualquier momento para continuarlo con la información incluida
en cada matriz. Esta fue la base para realizar el control de calidad sobre los
desarrollos por medio de las pruebas realizadas.
Las pruebas se desarrollaron conforme a los casos de prueba según requerimiento
de la empresa y a medida que fueron entregados los desarrollos para ser probados,
usando como guía y registro de resultado las matrices de los casos de prueba
principalmente.
Los resultados obtenidos de las pruebas de desarrollos fueron sometidos a un
análisis de las pruebas realizadas y sus resultados, que consistió en realizar una
clasificación de fallas según el punto en el que se detenga el proceso o se
encuentren fallas, tomando tiempos y resultados obtenidos de las pruebas, para
revisar el grado de efectividad de las pruebas y de los desarrollos.
Se tuvieron en cuenta sus características estadísticas más básicas para tratar de
identificar patrones o tendencias en sus resultados, cuellos de botella o partes del
proceso que presentan más fallas o demoras para así poder proponer mejoras
específicamente a los procesos de pruebas (QA).
85
Finalmente se realizó un Diseño de diagrama de procesos para definir más
fácilmente los procesos seguir por el consultor durante las pruebas de los casos, de
manera que se mejoren los métodos y se reduzcan los tiempos de prueba;
haciéndolos más efectivos y menos agotadores. Sirviendo esto como parte de las
conclusiones, recomendaciones y propuestas de mejora que se entregará a la
empresa como resultado de lo desarrollado, conforme a lo observado, analizado y
diseñado a modo de conclusiones, recomendaciones que se consideren relevantes
y propuestas de mejora para hacer los procesos efectivos.
Ésta metodología se ejecutó conforme al cronograma que se visualiza a
continuación: Tabla 11 Cronograma
Fuente tabla 11 Creación propia
La aplicación en la fase inicial fue retroalimentada por el equipo de fusion partners
y solicitud de Entel, con la inclusión de tomas de evidencias con video de cada
prueba, uso de la herramienta CLM para acceso de Entel a la revisión del estado
general de los casos e integración a matrices de coordinación de desarrolladores,
como un aporte de información propuesto por fusión.
A medida que se fue aplicando el modelo que se planteó inicialmente el equipo de
trabajo, identificó la necesidad de evaluar los resultados y hacer las correcciones
pertinentes sobre el mismo; por lo que decidió recurrir al modelo en espiral con las
actividades estructurales generales propuestas en el libro “Ingeniería del software.
86
El modelo en espiral tiene un enfoque cíclico para el crecimiento incremental en
definición e implementación con puntos de referencia de anclaje puntual que
aseguran la búsqueda constante de soluciones factibles y mutuamente
satisfactorias, que genera versiones evolutivas y se desarrollan sus etapas de
manera concurrente122.
La principal característica tomada en cuenta del modelo en espiral durante el
desarrollo de este proyecto, es la búsqueda de la continuidad por medio del ciclo
creciente de mejora, aplicable siguiendo el orden que propone de sus etapas:
comunicación, planeación, modelado, construcción, despliegue.
En la comunicación consideramos incluido el proceso de intercambio de información
y directrices entre el equipo de trabajo y con el cliente, tanto a nivel interno del área
de calidad como en el equipo del proyecto; en este intercambio de información se
pretende tener en cuenta los factores identificados desde cada etapa del proceso
para corregir, mantener o mejorar en el siguiente ciclo.
En la planeación se pretende tratar de estimar cada ciclo con mayor exactitud que
el anterior ciclo en cuanto a los tiempos, recursos y alcances del equipo de trabajo,
a pesar de que se tiene en cuenta que es altamente impredecible cada etapa del
proyecto, se pretende tener acercamiento en las partes del proceso que dependen
exclusivamente del área de calidad y pruebas. Asimismo con la programación de
actividades para el cumplimiento a tiempo del requerimiento, y con esto la búsqueda
de una aproximación previa al análisis de riesgo y los factores que puedan retrasar
el proyecto.
En cuanto al modelado del sistema de estandarización, rediseño y realimentación
de procesos de pruebas de desarrollo de software, se partió de un modelo propuesto
teniendo como base la bibliografía inicial en la propuesta del proyecto, la cual por
medio de la aplicación del modelo en espiral para su ejecución evolucionó a una
propuesta final de modelo aplicable en la empresa con mejoras adoptadas del
análisis de los resultados de la aplicación realizada. Del mismo modo, posterior a la
aplicación de este recomendación propuesta propuesto se desea que se le brinde
un seguimiento de modo que posteriormente la organización genere un próximo
modelo aún más adaptado a sus requerimientos y con nuevas correcciones basadas
en los resultados de la aplicación en busca de la mejora continua.
122 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 39, 42.
87
La construcción la tomamos como un proceso continuo en el que se propuso
cambios y mejoras sobre el modelo que se diseñó inicialmente de la situación actual,
justo antes de iniciar el despliegue o aplicación a la etapa inicial del proyecto, en
esta construcción se elaboraron todas las herramientas, accesos, documentos y
otros elementos que resultaban necesarios según el modelo para su aplicación en
la etapa. Y se repite el proceso posterior a la aplicación inicial del mismo para la
propuesta de la recomendación propuesta que se presenta en este documento al
incluir los cambios que se consideraron necesarios a partir de la experiencia de la
práctica anterior.
El despliegue fue considerado por el equipo de trabajo como la etapa en la que el
modelo con todas las herramientas y elementos construidos se ponen en uso
durante el desarrollo de la etapa del proyecto en la que se desempeñe el equipo de
trabajo; durante esta etapa se toman tiempos y nota de los diferentes elementos a
tener en cuenta a la hora de la comunicación. Sin embargo esta etapa y la de la
comunicación fueron simultáneas con la planeación del siguiente modelo y creación
de estrategias que estuvieron disponibles para las siguientes etapas123.
Este modelo aplicó durante este proyecto en la organización debido a la evidente
necesidad de realizar mejoras sobre el modelo en vista de los resultados iniciales,
independientemente de que se haya realizado la aplicación del modelo tal como se
tenía planteada, e independientemente de las recomendaciones, solicitudes y
exigencias por parte de la empresa y el cliente. se considera útil para mejorar los
procesos, la calidad de los mismos y mejorar de las condiciones laborales de los
consultores facilitando el avance en cada etapa de manera más efectiva,
reduciendo las repeticiones de los procesos, los niveles de estrés y la necesidad de
recurrir a mucha documentación para realizar un mismo proceso en diversas
ocasiones.
Debido a la falta de coordinación y de definición de los procesos fue necesario
repetir las pruebas entre 4-6 veces, porque:
Inicialmente hubo entrega de HLD atrasados, luego se recomendó el uso de
LLD, luego se recomienda omitir LLDs.
inicialmente solo se realizó seguimiento por medio de la matriz de diseño,
posteriormente se solicitaron evidencias con prints compartidas vía email
solo para casos críticos, luego se solicitó la grabación de vídeos de cada
prueba para tener claridad total de los casos, luego se solicitó incluir la
herramienta clm únicamente para seguimiento y gestión de defectos, lo cual
resultó muy lleno de protocolos (que robaba mucho tiempo) y mantenía al
123 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 13.
88
cliente al tanto de la descoordinación interna de fusion, así que solicitaron la
inclusión de evidencias paso a paso.
Finalmente el equipo de trabajo decidió continuar la gestión de defectos vía
Skype y correo, hasta tener el caso totalmente exitoso se incluye en CLM.
7. RESULTADOS.
En la implementación del modelo propuesto se identificó la disposición de
diagramas de flujo entregados por el cliente y el desarrollador, así decidió darle uso
a estos diagramas y no diseñar más.
Con respecto a la matriz de diseño de casos de prueba y seguimiento de prueba,
se diseñó un formato con todos los casos que se dispongan de un mismo HLD en
una misma hoja, y en los demás diseños. Cada caso en la matriz incluye: Id de
Prueba, Tipo de Prueba, Nombre Prueba, Descripción de Prueba, Pre-condición y
Datos Requeridos, Estado de Diseño de Caso de Prueba, Dueño de prueba, Fecha
de Diseño, PASOS, Descripción del Paso de Prueba, Resultado Esperado Estado
de Ejecución, Comentarios y Observaciones, RESPONSABLE DEL TEST,
RESPONSABLE DEV., % AVANCE, Plan De Prueba Involucrado.
Tabla 12 Matriz de diseño de casos de prueba.
Fuente tabla 12 Creación propia
También para mantener registro de los casos cuyo estado de desarrollo había sido
completado con la fecha en la que hacia disponible para ser probado se usó la matriz
de seguimiento de construcción del equipo de desarrollo ubicando al final columnas
con el estado de desarrollo y la fecha, tal como se puede visualizar a continuación:
89
Tabla 13 Matriz consolidada de seguimiento de desarrollo.
Fuente tabla 13 Creación propia
Se implementó también una matriz de casos problema, o detenidos, con la
información requerida para tratar de resolverlos totalidad como se puede visualizar
a continuación.
Tabla 14 Matriz casos problema
Fuente tabla 14 Creación propia
90
Ilustración 14 Vista de los casos desde CLM.
Fuente 14 Vista de los casos desde CLM
Ilustración 15 Vista del ambiente
Fuente 15 Creación propia
Durante la implementación del modelo propuesto, se presentaron situaciones que
entorpecieron el proceso de pruebas a desarrollos, por ejemplo algunas solicitudes
de parte del cliente en las cuales presentaban cambios inesperados; uno de ellos
fue con respecto a las evidencias que se usaron. Inicialmente se propuso el uso de
91
evidencias (resaltadas) sólo para los casos con defectos o errores; posteriormente
solicitaron las evidencias del paso final de cada caso, y poco después de estar
pasando por la mitad de los casos de pruebas, solicitaron la grabación de los casos
por medio de la herramienta web para ser usados en las capacitaciones del personal
de Entel y el personal de Fusión Partners S.AS. Ya elaborados la mayoría de los
videos fue solicitada la evidencia paso a paso en la herramienta de CLM.
Debido a que los procesos de CLM no estaban estandarizados, el equipo se vio
obligado a realizar el cambio de metodología conforme el cliente iba proponiendo.
A pesar de que en el proyecto de TIGO en honduras ya se había manejado las
evidencias paso a paso y que en ETB se había usado evidencia final así como el
uso de videos, por lo que el líder del equipo de pruebas pudo haber expuesto las
opciones disponibles o factibles para acordar la que se considere mejor y así evitar
los reprocesos, que en los peores casos ascendió a 5 o 6 repeticiones de casos
completos. También hubo demoras inesperadas debido a demoras para acceder a
documentación que estaba realizada tiempo atrás, pero no fue compartida.
Otro de los elementos importantes fue el aislamiento del equipo de QA con el resto
de la organización teniendo como único punto de contacto al líder del equipo, lo que
también promovió la llegada de los HLD con cambios muy tarde; y el ingreso de un
grupo de 8 colaboradores que debieron ser capacitados simultáneamente, pero
cada uno debió recibir seguimiento personalizado por el equipo inicial (compuesto
por los dos autores y el líder del equipo), la mitad del equipo se retiró del proyecto
en muy corto plazo.
8. DISEÑO DE LA RECOMENDACIÓN PROPUESTA.
Modelo de mejora a los procesos y procedimientos básicos en el desarrollo de
pruebas y realimentación de desarrollos de software, también la estandarización de
procesos por medio de manuales, matrices y diagramas; control de calidad y diseño
de pruebas con sus ciclos, estandarización de procesos, análisis de métodos y
tiempos, diseño y soportes documentados, control de calidad que garantice el buen
desempeño de sus resultados y asegure los servicios ofrecidos.
Suplir los requerimientos del cliente, hasta garantizar el cumplimiento en tiempos y
calidad de sus servicios dando a su equipo de calidad un modelo de mejora efectivo.
Los principales elementos sobre los que el modelo se desarrolló, se presentan a
continuación con las características sobre las cuales el modelo actúa:
92
La aplicación de pruebas al sistema. las pruebas pueden realizarse
procedimientos agotadores, redundantes, inadecuados o innecesarios a falta
de una clara estandarización de procesos y mejora en el diseño de los
mismos, lo que se traduce en más tiempo, por tanto un aumento innecesario
de costos de honorarios y multas por exceder plazos de entrega.
Documentación de la estandarización de procesos y procedimientos.
analizar, documentar, re-diseñar y estandarizar los procedimientos y
comportamientos de los desarrollos al integrarse a la plataforma para acceso
y dominio general
Medidas de desempeño para reducir tiempos de capacitación, garantizar la
universalidad de información y haciendo más eficientes los procesos de
pruebas.
Propuestas de mejoras de calidad del área de pruebas de desarrollos
mejorando los procesos implicados y la comunicación interna.
En este capítulo se presentan las técnicas, teorías y partes de otros modelos
ajustados específicamente a esta organización, y teniendo realimentación de la
aplicación del modelo propuesto, junto con las técnicas propias de la ingeniería
industrial, por lo que se revisan los mismos aspectos del capítulo anterior con las
aclaraciones y revisiones que se realizaron conforme al análisis elaborado por el
equipo de trabajo.
8.1 FUNCIÓN DEL INGENIERO INDUSTRIAL EN LA RECOMENDACIÓN
PROPUESTA.
La recomendación propuesta que se propone terminada práctica pretende
fortalecer el rol del ingeniero industrial en la organización para mantener y mejorar
la articulación de las diferentes áreas de la empresa para la consecución de las
metas124 del área de QA con el resto de áreas de las que depende su buen
desempeño; para la aplicación del rediseño de procesos y el desarrollo continuo de
nuevas versiones del modelo de mejora de sistemas integrados de hombre y
equipo125, de procesos y procedimientos de pruebas de software; así como el
mantener el enfoque en funciones técnicas y administrativas (organizar, dirigir,
124 PEÑA, Javier Parra. La ingeniería industrial en el contexto del desarrollo sostenible. Revista Tecnura, 1999, vol. 2, no 4, p. 28 125 PARRA DÍAZ, Cristian Andrés; PRIETO BARRIGA, Jorge Andrés. Estudio del estado del arte y tendencias educativas en universidades de Finlandia y Noruega en el programa de Ingeniería Civil como parte de un análisis prospectivo para Colombia. 2014.
93
coordinar) de la organización126, implícitas en el modelo, relacionadas entre sí de
manera que se hagan los procesos de una manera más adecuada a medida que
evoluciona el modelo.
También al rediseñar el modelo, debido a la evaluación realizada al final de la
aplicación como actividad propia del ingeniero industrial en el proceso, permitió una
propuesta más efectiva de optimización de procesos de transferencia interna de
conocimiento, al ubicar cada proceso en documentos escritos de acceso inmediato
y usabilidad para cualquier persona del equipo de trabajo, que a su vez hace más
efectiva la estandarización de los procesos y la universalidad de la información que
se maneje a nivel organizacional
En la recomendación propuesta se inserta al ingeniero industrial en la cultura de la
mejora constante de la calidad, cumplimiento con la normalización y el garantizar
la calidad, con mecanismos específicos de la calidad del software realimentados
con los resultados de la aplicación del modelo y la propuesta de la continuación de
crecimiento en este aspecto; e incluyendo nuevos mecanismos que conforman este
modelo: los estándares, las revisiones, las entrevistas, las pruebas de software,
colección y análisis de errores127 y la realimentación al proceso de desarrollo para
la corrección de errores y defectos, el desarrollo y rediseño de modelos de mejora
progresiva de procesos como aporte directo a la eficiencia y eficacia de los procesos
de la empresa, en su camino a la calidad total.
8.2 LAS CARACTERÍSTICAS PROPIAS DEL TRABAJO CON DESARROLLO
DE SOFTWARE EN LA RECOMENDACIÓN.
Para la recomendación propuesta que se propone se consideró que la naturaleza
del proceso de desarrollo de software (caro, riesgoso, incierto y lento) para las
condiciones de negocio128 de la empresa sólo podría generar problemas de no ser
ajustado el modelo aplicado, por lo que se hace una aplicación de las competencias
del ingeniero industrial para proponer mejoras y considerando también la ingeniería
de software (enfoque sistemático, disciplinado y cuantificable al desarrollo,
operación y mantenimiento). Este primer evolutivo del primero modelo propuesto es
una forma de acercar el proceso a una adaptabilidad y agilidad en varias fases o
etapas de perfeccionamiento, encaminando el área de QA (con más claridad) a un
modelo organizacional con la calidad en los procesos, los métodos y finalmente el
126 FAYOL, Henri; TAYLOR, Frederick Winslow. Administración industrial y general. Orbis, 1987. 127 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. 128 PONS, Claudia; GIANDINI, Roxana Silvia; PÉREZ, Gabriela. Desarrollo de software dirigido por modelos. 2010. p 23.
94
uso de las herramientas técnicas de la empresa129, de una mejor forma con mejoras
organizacionales que sirvan de apoyo para avanzar130 y facilitar procesos muy
intrincados y complejos131.
En esta recomendación propuesta que se propone aprovecha al máximo la
características propias de este tipo de proceso de su adaptabilidad a los
requerimientos del cliente, la posibilidad de hacerlo evolucionar o versionar
corrigiendo sus defectos, sobre el modelo propuesto, desarrollado específicamente
sobre el intelecto del equipo de trabajo y el desarrollo del modelo.
El modelo considera las funciones que se cumplen dentro de la herramienta Siebel,
toma los datos e información disponible de cada proceso y la estandariza conforme
se identifique en el sistema para tener una guía clara antes de realizar las pruebas
de funcionamiento en el sistema, realiza las pruebas y realimenta el desarrollo
según sea necesario, asimismo actualiza y documenta usando las herramientas de
control de información y calidad. También mide su efectividad durante la gestión con
el seguimiento de tiempos y cumplimiento, como aporte a la búsqueda del
aseguramiento de la calidad y la mejora continua.
Se identifica, en las características propias del sistema de funcionamiento de la
empresa fusion partners, que las mayores demoras que se presentan en los
procesos de prueba de los casos de uso se debe a falta de información o claridad
respecto a la secuencia lógica del proceso; esta información se recibe del área de
desarrollo y de los requerimientos del cliente. El modelo pretende resolver
dificultades como esta, por medio de la aplicación de una metodología que también
brinde al final del proceso la documentación total de cada proceso que se requirió
por el cliente, con la claridad suficiente para que sea de uso interno de la empresa
como para el uso del cliente final.
Se hace un listado de los motivos que generan pérdidas de tiempo, retrasos en
entregas, reprocesos, confusiones e imprecisiones que afectan el proceso de
pruebas, visualizados durante la aplicación del modelo:
Falta de documentación.
Imprecisión o falta de claridad en los procesos descritos en la
documentación.
129 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 11. 130 CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. Metodologías Ágiles en el Desarrollo de Software, 2003, 131 BUSTOS, Ricardo A. Gacitúa. Métodos de desarrollo de software: El desafío pendiente de la estandarización. Theoria, 2003, vol. 12.
95
Modificaciones no informadas de requerimientos o diseños.
Se identifica que las mayores demoras que se presentan en la prueba de los
casos de uso se debe a falta de información o claridad respecto a la
secuencia lógica del proceso.
8.3 LAS METODOLOGÍAS DE LAS EMPRESAS EN LA RECOMENDACIÓN
PROPUESTA.
La principal metodología sobre la que se basó la recomendación propuesta, es la
que se aplicó en el modelo propuesto, sobre el cual se verificó el resultado y las
medidas que se pueden tomar para que al ajustar otras metodologías usadas por
esta y otras empresas del mismo sector en otros proyectos, se logra una adaptación
más completa, evolucionada que garantice agilizar el manejo de información y la
comunicación132 dentro de la empresa, principalmente con el área de QA con los
demás componentes con que se relaciona dentro de la organización, para cumplir
con sus funciones principales; también se busca la normalización de sus protocolos
en procesos de pruebas de desarrollo y de verificación del nivel de calidad de sus
resultados. Se utilizan matrices en el diseño de los procesos para unificar las
informaciones recibidas y estandarizar cada caso de prueba, que facilitaran la
creación final de los manuales, en caso de ser solicitados y asume un nivel de
uniformidad inclusive desde el vocabulario común (la precisión terminológica)133,
hasta la organización de la información en formatos específicos diseñados. Se
propone la creación de manuales terminada cada fase.
El consenso del conocimiento o consolidado de la experiencia, como herramienta
para la transferencia tecnológica para el desarrollo de conocimiento, se realizó con
una mayor recopilación de la información útil captada de las propuestas del cliente,
las personas del equipo de trabajo y documentos de la empresa (otras áreas)
durante la aplicación del modelo proyectos para apoyar el desarrollo del nuevo
proyecto, y la elaboración mejorada de esta recomendación propuesta, para
disponer de la información de modo que pueda ser utilizada y documentada en este
informe final de pasantías.
La metodología a aplicar en la recomendación propuesta está encaminada a la
adaptación de la primera propuesta para acercarse a una la eficiencia en los
procesos de pruebas, garantizando un agilidad que reduzca los tiempos para llegar
132 BUSTOS, Ricardo A. Gacitúa. Métodos de desarrollo de software: El desafío pendiente de la estandarización. Theoria, 2003, vol. 12. 133 MUÑOZ, Coral Calero; VELTHUIS, Mario G. Piattini; DE LA RUBIA, María Ángeles Moraga. Calidad del producto y proceso software. Editorial Ra-Ma, 2010.
96
a la depuración de las pruebas y con esto reducir los tiempos del proceso
productivo; también aportando a la calidad y la comunicación interna de la
organización134, todo esto en miras a que la estandarización de los procesos no se
convierta en un extenuante formalismo que dilate los procesos.
Permite también un acercamiento a la universalidad de la información conciliada
directamente de las personas y realizada en la parte final del proceso garantizando
así que el proceso estandarizado no sufra posteriores cambios o adaptaciones, tal
como se propone en el modelo. En este proyecto se desarrolla el modelo entorno
a los procesos de pruebas de desarrollos, cuya principal función es la validación del
cumplimiento de requisitos y el control de calidad del proceso de producción de
desarrollos, adaptando el primer modelo propuesto, que teóricamente estaba
adaptado a las condiciones y disposiciones propias de la organización, pero que
durante su aplicación permitió visualizar algunos cambios que resultaban
necesarios para mejorar su funcionamiento.
La recomendación propuesta se propone en torno a un mejor acercamiento a la
mejora de los procesos de pruebas de desarrollos, para la validación del
cumplimiento de requisitos y el control de calidad del proceso de producción de
desarrollos, conforme a la experiencia adquirida durante la aplicación del modelo
propuesto; a continuación se profundiza en los métodos o metodologías de
validación usadas en el modelo propuesto, pero reajustadas a la empresa para
reducir los impactos negativos que se han identificado en la aplicación del mismo.
8.4 LOS MÉTODOS DE VALIDACIÓN EN LA RECOMENDACIÓN
PROPUESTA.
Los métodos de para la validación de los desarrollos empíricos (ingeniería de
software basada en la evidencia) que se aplican en este modelo serán:
experimentos (control de variables para comprobar efecto), que es el que ya se
venía utilizando; Además se aplicarán encuestas (cuantitativas y cualitativas en
retrospectiva para conclusiones descriptivas) y casos de estudio(siguiendo uno o
varios atributos para establecer relaciones) los cuales entrarán al final del proceso
con las medidas de tiempos y otros atributos135.
El modelo incluye el desarrollo de un plan de pruebas de “ciclo rápido”, que debe
ser filtrado durante la revisión previa, al distinguir los casos iniciales y básicos de
134 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. 135 MUÑOZ, Coral Calero; VELTHUIS, Mario G. Piattini; DE LA RUBIA, María Ángeles Moraga. Calidad del producto y proceso software. Editorial Ra-Ma, 2010.
97
otros casos más complejos136 y hacer un filtro posterior a las pruebas de los casos
que vienen de caja y se pueden probar sin integrar otros sistemas. Este nuevo
modelo reevalúa el uso de la herramienta CLM de la que dispone la organización
por acuerdo con el cliente para el control en tiempo real de los casos con sus
respectivos comentarios, debido a que se ha identificado dificultades con el cliente,
porque realizan continuos reclamos por los casos con defectos que ellos no
conocen, generando malestar y pérdidas de tiempo explicándoles en qué consiste
cada defecto aun cuando su participación es nula en la solución; por este motivo se
incluye la interacción con el cliente y su inclusión en el proceso de una manera más
constructiva durante la confirmación del requisito y la prueba final para verificar que
se está realizando el producto final conforme a su solicitud (esto sucede con los
casos exitosos).
A pesar que la herramienta hacer automática la gestión de defectos, enviando un
correo por defecto o comentario a los desarrolladores, y que el informe diario de
avance detallado; el último modelo propone una alternativa ágil, siguiendo los
principios de la metodología ágil, se pretende reducir los formalismos de los correos,
pues se identifica que el equipo de desarrollo solicita retroalimentación de la
información enviada por clm con una prueba en vivo. Se propone hacer la gestión
de manera inmediata y personalizada con cada desarrollador por vías más ágiles
de comunicación como lo es el chat común de todo el equipo, vía Skype o en
persona de ser posible.
La recomendación propuesta implica, bajo la experiencia de la aplicación del
primero, suplir cualquier deficiencia de conocimiento respecto a las posibles
naturalezas de las pruebas, conforme se filtran los casos (como se expuso
anteriormente) siguiendo grupos de requerimientos relacionados, lo cual exige el
total acceso a la documentación por parte del cliente en tiempo real y a sus
respectivas modificaciones que sean visibles de forma clara, por lo que el plan de
pruebas contenga la aplicación de filtros y distinciones conforme a toda la
información asociada a cada caso de prueba, que se recomienda realimentar en
colaboración con los desarrolladores para completarla.
Para esto se propone un trabajo colaborativo con el desarrollador, para lo cual se
puede “designar un tester” para cada desarrollador o equipo de desarrolladores o
designar por especialidad de cada uno en cada tipo de prueba según su naturaleza
(de caja, de integración, validación, unitaria, funcional, de sistema, etc.)
136 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 538.
98
Para la aplicación de las validaciones tipo experimento137 se considera importante
ampliar las naturalezas de las pruebas a realizar, pruebas se recomienda realizar
pruebas unitarias, funcionales, de sistemas y de regresión, de modo que se
garantice la prueba unitaria y funcional, es decir que las validaciones aseguren la
existencia de los elementos que se deben visualizar desde Siebel y verificar su
correcto funcionamiento interno, para lo que se requiere información más clara y
detallada de la forma correcta de validar los posibles resultados y conocer el
proceso interno con ayuda de los desarrolladores.
Para el desarrollo del modelo de pruebas se mantuvo el proceso experimental138
usado en el primero modelo propuesto, con pequeños ajustes en los pasos:
Definición: En el diseño de casos de prueba se incluye la definición de cada
caso de prueba y su objetivo junto con los pasos a seguir para completarlo
en la matriz de casos de prueba, incluye la participación del cliente para la
verificación en los casos que puedan presentar inconsistencias y el
cumplimiento del verdadero requerimiento solicitado.
Planificación: para cada caso se realizaba según la disponibilidad de tiempos
de las personas del equipo de QA (los autores de este documento) y
conforme se visualiza en la matriz de seguimiento de desarrollos
(considerando sólo los casos desarrollados al 100% como casos para
programar prueba.) Su progreso tiene seguimiento en una matriz de casos
de prueba aparte, que incluye todas las entregas que va realizando el equipo
de pruebas, ya que se identificó dificultad para hacer el informe general por
entregas teniendo cada caso en una matriz de casos diferentes.
Operación: consiste en realizar la prueba de cada caso así como todas las
validaciones posteriores necesarias, hasta llegar a hacerlos casos exitosos.
durante la cual se hace la toma de evidencias definida como imagen de
pantalla a pantalla (es un print por cada cambio de pantalla que implique el
caso).
Análisis e interpretación: realizar la verificación del procedimiento descrito en
los documentos, validar los resultados de las pruebas y consultarlos con el
desarrollador para verificar el correcto funcionamiento interno y visible. Así
como también el análisis de la naturaleza de cada caso para integrarlo al plan
de pruebas rápidas o distinguirlo como caso de prueba con integraciones o
subprocesos que lo catalogan como un proceso de prueba complejo.
137 CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. Metodologías Ágiles en el Desarrollo de Software, 2003, p. 138 CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. Metodologías Ágiles en el Desarrollo de Software, 2003, p.
99
Presentación y difusión: se realizan mediante la conversación privada y la
matriz de seguimiento del equipo de QA, mientras los casos no han llegado
a estar exitosos. para los casos exitosos se dará uso a la herramienta CLM
con la inclusión de las evidencias pantalla a pantalla, comentarios y a
disposición del cliente para su seguimiento y verificación, también se
realizará bajo comunicación directa e informativa del avance real de los casos
no exitosos (sin entrar en detalles con el cliente a menos que resulte
estrictamente necesario).
En cuanto a las validaciones tipo encuestas (cuantitativas y cualitativas), el modelo
propone la inclusión del cliente y de los desarrolladores en los procesos de pruebas
realizando encuestas orales útiles para verificar la correcta comprensión de la
finalidad de cada prueba, la cual puede ser validada durante el acompañamiento de
las pruebas, las encuestas de asimilación de resultados exitosos en la
implementación del proceso de pruebas puede realizarse sobre cada matriz dando
una calificación o puntuación de tipo binario para calificar que esté acercada cada
consideración incluida.
En cuanto a las validaciones tipo casos de estudio (siguiendo atributos para
establecer relaciones139 se pretende aplicar con las tomas de tiempos, como un
análisis de complejidad de casos, demoras o dificultades que pueden identificar un
requerimiento extra de atención por parte de los desarrolladores a las áreas
problemáticas del sistema que puedan estar generando demoras y resultados
indeseables.
El uso de estos tipos de validaciones se recomienda junto con el uso de algunas
métricas de revisión del proyecto, identificadas en la validación teórica:
El tiempo de preparación para la revisión.
El tiempo que se usa para la revisión.
El tiempo promedio en detectar un error no detectado durante revisión.
El tiempo dedicado a corregir los defectos detectados durante la revisión.
El tiempo dedicado a corregir los defectos no detectados durante la revisión.
El tamaño del trabajo (para el proyecto se considerará por pasos del caso de
uso).
Errores menores detectados durante la revisión.
139 CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. Metodologías Ágiles en el Desarrollo de Software, 2003,
100
Errores mayores detectados durante la revisión.
Errores no detectados durante la revisión.
Con estas medidas puede realizarse el cálculo de:
Tiempos totales de revisión y corrección
El tiempo promedio en detectar un error no detectado durante revisión y
corrección.
Total de errores detectados
Densidad de errores, dividiendo el total de errores detectados durante la
revisión en los tiempos totales
La eficacia de las revisiones:
Ahorro de tiempo por error: Al tiempo promedio en detectar un error no
detectado durante revisión y corregirlo se le resta el tiempo total de revisión
y corrección140
Entre otras posibilidades según considere el equipo de trabajo y conforme a la
aplicación del modelo propuesto. Para el aseguramiento de la calidad, se aplican
con el mismo nivel de formalidad modificando el seguimiento a la gestión de
defectos vía CLM a personalizada y del mismo modo la toma de tiempos; esto y el
conteo de efectos exige un esfuerzo extra de parte equipo de pruebas (QA), pues
se debe realizar con precisión y exactitud para que resulte provechoso y útil.
La aplicación de métodos de validación de desarrollos, ser relaciona directamente
con la búsqueda del aseguramiento de la calidad, se aplican con el nivel de
formalidad apropiado para cada organización (roles de revisores, preparación,
estructura, seguimiento, etc.) y tipo de producto según la disponibilidad de tiempo,
capacidad y recursos; su principal efecto en el tiempo se puede apreciar en la
siguiente imagen que representa el tiempo que toma un proyecto cuando aplica o
no revisiones o validaciones141.
Los métodos de validación durante la aplicación del modelo, se vieron
obstaculizados por diversas solicitudes realizados por el cliente, expuestos a través
del documento.
140 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988.p 359. 141 Ibíd. P 360.
101
8.5 EL ASEGURAMIENTO DE LA CALIDAD EN LA RECOMENDACIÓN
PROPUESTA.
Para acercarse a un producto final de calidad del proceso de pruebas de desarrollos
de software para Fusion Partners S.A.S. debe iniciarse por buscar un proceso de
calidad, sin llegar a hacer el resultado totalmente dependiente del proceso, siendo
este el referente principal, la recomendación propuesta por medio del uso del
modelo de espiral pretende la búsqueda de la mejora continua, y la incorporación
de la cultura de la calidad dentro de la empresa.
El modelo que se propuso, se desarrolla dentro del área de calidad de la empresa
en la cual se realizan procesos de pruebas a los desarrollos de software, que
realizan los desarrolladores, al igual que esta recomendación propuesta que
incluye el uso de la propuesta propone el desarrollo de los elementos básicos del
aseguramiento de la calidad (los estándares, las revisiones técnicas, las auditorías,
pruebas, colección y análisis de errores, administración del cambio, educación, de
seguridad y riesgos). De manera que se desea mantener el uso de matrices para
unificar la información disponible respecto de cada caso de prueba, para
estandarizar sus componentes (tipo de prueba, nombre, descripción, precondición
y datos requeridos, pasos, descripción del paso de prueba, resultado esperado,
estado de ejecución, comentarios y observaciones); pero para verificar su correcto
funcionamiento antes de probarlo en CLM, se considera necesario el diseño de
nuevas matrices, solo de seguimiento por entregas.
También la recomendación propuesta se apoya en el uso de la herramienta CLM
pero únicamente para la entrega de resultados exitosos con su respectiva evidencia.
En este modelo se identifica que el uso de los diagramas de flujo que grafican cada
proceso y que son entregados por cliente y desarrolladores, sirven de apoyo para
brindar claridad en información a la hora de diseñar los casos de prueba, y eliminan
la necesidad de diseñar nuevos diagramas. Todo esto se considera para aplicar
control de calidad sobre los productos que genera la empresa y conforme a las
observaciones realizadas durante la aplicación del modelo propuesto, de manera
que se conserven los elementos cuya adaptación se encuentra exitosa y se
reformulen aquellos que obstaculicen el objetivo de reducir los tiempos y costos de
los procesos de pruebas.
Se busca en esta recomendación propuesta desarrollar la metodología en la
siguiente etapa a desarrollar mediante las tareas sencillas del modelo (planear,
describir, identificar, auditar, registrar y documentar los procesos); así como los
102
errores o defectos142 que se identifiquen y se gestionen durante los procesos de
pruebas depurando el proceso productivo de una manera más directa, ágil y
efectiva, por medio de la reducción de formalismos.
Siendo los procesos de pruebas el centro y límite de la práctica, se tendrán en
cuenta los diversos tipos de pruebas que se requieren para el aseguramiento de la
calidad (de caja, de integración, validación, unitaria, funcional, de sistema, etc.)
Básicamente para despliegue143. Para iniciar un proceso hacia el aseguramiento de
la calidad, se mide la eficacia del control de calidad en relación con la asignación
de recursos, la eficacia de la revisión y de las pruebas; siendo este modelo
propuesto de mejora de procesos un camino hacia el efecto final deseado de la
aplicación de esta práctica sobre la el proyecto de la empresa, mejora en la calidad
y eficiencia en los procesos; sin embargo, se propone el compromiso organizacional
con la calidad implica el apoyo de la administración y busca alimentar la cultura de
la mejora continua144.
Para realizar la evaluación “suave” de la calidad de los desarrollos a probar durante
la siguiente etapa del proyecto con la recomendación propuesta que se propone al
proceso de pruebas de desarrollos es la inclusión de las encuestas o consultas al
cliente, se busca identificar: la calidad del desempeño (cumplimiento,
especificaciones y funcionamiento), la confiabilidad ( características y capacidades),
la conformidad ( estándares locales y externos, el diseño y condiciones deseadas)
y el servicio (mantenimiento o correcciones de ser necesario), en este modelo los
registros de CLM serán únicamente para los tiempos de prueba de los casos de
pruebas probados y exitosos; tal como en el modelo propuesto. En cuanto a la
evaluación “dura” evalúa factores que pueden ser medidos de forma directa, en este
modelo mediante la toma de tiempos y el conteo de defectos, tarea adjudicada al
equipo de pruebas como requerimiento extra que implica detalle y precisión
(defectos, tiempos, entre otros.) o de manera indirecta (usabilidad, mantenimiento,
correcciones, etc.)145, estos últimos serían evaluados con encuestas y casos de
estudio directamente con el cliente.
Esta recomendación propuesta pretende mantener el enfoque en la mejora
continua del proceso de prueba y así mejorar la optimización de los procesos para
142 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988.p 371, 374. 143 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. 144 Ibíd. P 11. 145 Ibíd P 342.
103
la reducción de costos, aun con la aplicación de la metodología de estrategia seis
sigmas en el aseguramiento de la calidad con sus etapas, aplicándolas de la
siguiente manera:
Definir los requerimientos, objetivos, metas, procesos, resultados solicitados
y entregados al cliente claramente para identificarlos plenamente. Tal como
en el modelo pero con una confirmación de parte de desarrolladores y cliente
de la correcta interpretación de la documentación.
Medir los requerimientos, objetivos, metas, procesos y resultados para
vigilar cualquier anomalía que se pueda presentar, así como su causa e
identificarlos lo más pronto posible usando el análisis de métricas e intentado
hallar relaciones.
Analizar las métricas de defectos y determinar causas vitales, estas métricas
fueron definidas principalmente como tiempos
Mejorar proceso eliminando causas, y usando la realimentación del modelo
aplicado al proyecto.
Controlar el proceso para evitar que vuelvan las causas, por medio de las
propuestas de mejora continua, el control de la calidad y la agilización de
procesos usando comunicación directa
Diseñar el proceso para garantizar el cumplimiento de requerimientos, tal
como se propone con la aplicación del modelo en espiral para los evolutivos
del modelo de mejora de procesos que se propone.
Verificar el modelo que se produzca como última evolución para que evite
defectos y cumpla con los requisitos de la organización conforme va
cambiando en entorno y requerimiento de la empresa.
La aplicación de estas metodologías pretende analizar las interacciones necesarias
entre los agentes del sistema garantizando la calidad de las mismas, evitando los
conflictos por disposición de tiempo (para formalismos), los reprocesos o demoras
por falta de información y considerar el conocimiento obtenido previamente146 147de
la organización en otros proyectos y de la aplicación del modelo en el proceso.
Se espera que esta aplicación, como la de los siguientes modelos evolutivos
generen un menor costo a la aplicación del modelo, de modo que cada nuevo
146 RODRÍGUEZ, Julián; TORRES, Miguel; GONZÁLEZ, Enrique. La Metodología AOPOA. Avances en Sistemas e Informática, 2007, vol. 4, no 2. 147 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 375.
104
despliegue de modelos sea cada vez más rentable para la empresa, especialmente
en tiempo o dinero, si mantiene el mismo equipo de QA, o conserva la mayoría, sin
embargo también cuenta con una herramienta para capacitación de nuevo personal
muy útil que también le puede servir para la reducción de costos de capacitación.
A medida que se generen evolutivo más adaptados a la necesidad de la empresa
los costos de prevención, evaluación o falla, deben verse reducidos pues la calidad
del proceso y su optimización deben llegar a un punto en el que se conviertan en
parte normal del proceso, siendo más efectivo. El logro de estos evolutivos y su
aplicación dependen especialmente de la administración si decide aceptar la
inclusión de la cultura de calidad y mejora continua en sus procesos, y
posteriormente depende de lograr que el equipo de QA esté dispuesto a adoptar las
mejoras (si identifican las ventajas para ellos como para la empresa), y finalmente
depende de la colaboración del equipo de desarrollo para acomodar sus tiempos y
voluntad a disponer para el éxito de la metodología.
Cada evolutivo al estar más adaptado y especializado a los requerimientos (Al igual
que el equipo de QA), debe presentar características fáciles de identificar como la
disposición de todos los datos o apoyo necesario antes de iniciar todas las pruebas,
la identificación y solución de todos los defectos (en lo posible) antes de entregar el
proyecto.
8.6 LOS MODELOS EN LA RECOMENDACIÓN DE LA PROPUESTA.
En la recomendación propuesta se tiene como directriz el uso del modelo para dar
una explicación coherente del funcionamiento organizacional148 de un sistema, por
lo que se usarán los modelos y métodos que se proponen en el modelo aplicado,
pero serán ajustados a las necesidades de la empresa y a la búsqueda de agilizar
su uso, aprovechando las herramientas disponibles y sus usos.
Por ejemplo, en el modelo se propone el diseño de los diagramas de flujo para cada
caso de prueba, pero se identificó durante la aplicación, que tanto el cliente como
los desarrolladores hacen la entrega de diagramas de flujo para cada proceso y que
las matrices representan de manera secuencial, que no se requería la creación de
los mismos, del mismo modo con los manuales.
148 RODRÍGUEZ MANCILLA, Darío. Diagnóstico organizacional. Alfaomega. Ediciones Universidad Católica de Chile, 2005.
105
Se puede considerar para el siguiente evolutivo, la inserción de diagramas de flujo
que sean incluidos en manuales (si el cliente está interesado en ellos en las
siguientes etapas del proyecto). En cambio, los diagramas de flujo serán usados
para representar el modelo en cada paso durante el proceso y las operaciones que
intervienen en él, para hacerlo más fácil de comprender.
La recomendación propuesta para agilizar el desarrollo de las procesos de pruebas
de desarrollos se apoya en lo que Mintzberg llama el trabajo colectivo, el cual
implica el ajuste mutuo de coordinar al equipo de trabajo con comunicación informal
(considerada la más efectiva en la metodología ágil), el conservar la estandarización
de los procesos de trabajo realizadas durante la aplicación del modelo e incluir una
estandarización de destrezas y conocimientos de los trabajadores149; la
comunicación con los desarrolladores y el cliente es la especialización que la
recomendación propuesta usa para para reducir la complejidad del proceso
completo, siguiendo la lógica del Modelo de contingencia y la ley de variedad
requerida de Ashby.
De las metodologías ágiles se pretende la inclusión de la importancia de los
individuos y sus interacciones, la búsqueda de un software que funciona, el valor de
la colaboración con el cliente y una buena respuesta al cambio traducido en
agilidad150.Para esto el modelo se diseñó considerando en la búsqueda de adaptar
las actividades de forma clara y directa para promover la fluidez del proceso151,
haciéndolo simple por medio de la promoción del diálogo cara a cara como el
método más eficiente y efectivo para comunicar información dentro del equipo de
trabajo152.
Teniendo en cuenta las condiciones de la organización y el entorno en el que se
deben desempeñar los consultores, se desearía en lo posible la comunicación de
manera personal, y en caso de ser entre dos personas que se encuentran en
diferentes países el uso adecuado de las herramientas de comunicación,
especialmente de las video llamadas de Skype. En cuanto a la respuesta adecuada
al cambio, se recomienda que el equipo de desarrollo tenga total acceso a los
requerimientos del cliente en tiempo real, o lo más pronto posible para que le sea
149 RODRÍGUEZ MANCILLA, Darío. Diagnóstico organizacional. Alfaomega. Ediciones Universidad Católica de Chile, 2005.P 3. 150 BUSTOS, Ricardo A. Gacitúa. Métodos de desarrollo de software: El desafío pendiente de la estandarización. Theoria, 2003, vol. 12. 151 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988.p 57. 152 CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. Metodologías Ágiles en el Desarrollo de Software, 2003, p.
106
posible al equipo reducir los costos los costos y tiempos por medio del uso de
pruebas unitarias continuas y ciclos de pruebas rápidas.
El modelo en espiral para el desarrollo de la recomendación propuesta que se
propone, mantiene la necesidad de realizar las etapas, tal como en el modelo
(comunicación, planeación, modelado, construcción y despliegue de manera
concurrente), siendo este modelo la aplicación del modelo como aporte a la mejora
continua, siendo un ejemplo del primer versionamiento más ajustados y adaptados
a las cambiantes necesidades de la empresa, así como a sus recursos y las
relaciones con el cliente.
En la ejecución de este modelo en espiral adoptado el uso de la metodología
AOPOA, con su enfoque organizacional aplicado en el diseño como una
descomposición en unidades autónomas, llegando a la descomposición de roles
más específica, que incluya los objetivos y haga la gestión correcta de los recursos,
en cada etapa del proceso de manera que sirva para que las actividades comunes
sean predefinidas con sus agentes.
Como esta recomendación propuesta mantiene por objetivo la mejora de procesos
de software, realimentando los desarrollos y los procesos propios de las pruebas;
es un aporte al proceso de mejora continua a la calidad de los resultados, como un
ejemplo de versionamiento del modelo ajustado que debe permitir identificar más
claramente las ventajas de su aplicación a los procesos para acercarse a un
resultado efectivo y exitoso153, que la aplicación del modelo propuesto.
Se espera que la aplicación de este primer evolutivo sea menos exigente para la
empresa en cuanto a la disponer de tiempo, recursos y los costos correspondientes
o asociados; a pesar de que resulte más exigente en disposición e interés de parte
del equipo de trabajo. En esta recomendación propuesta durante el proceso de
pasantías, se pretende identificar los cambios con respecto al principio del proyecto
como beneficios para la empresa y su cliente; por lo que se entra a evaluar las
mejoras que se introdujeron durante el proyecto de mejora en su aplicación para ser
comparadas con las siguientes versiones de modelos que se van ajustado a las
necesidades de la empresa, que será comparado con el inicio de este proceso. Para
evaluar de manera objetiva el modelo propuesto con esta recomendación propuesta
se usan como indicadores los tiempos nombrados en las metodologías del modelo,
pues a pesar de que esta recomendación propuesta presenta más indicadores,
153 TRUJILLO-CASAÑOLA, Yaimí; FEBLES-ESTRADA, Ailyn; LEÓN-RODRÍGUEZ, Giraldo. Modelo para valorar las organizaciones al iniciar la mejora de procesos de software. Ingeniare. Revista chilena de ingeniería, 2014, vol. 22, no 3, p. 413.
107
solamente se tienen del primero los tiempos los cuales fueron revisados,
comparados y analizados terminada la aplicación de cada modelo, y se presentan
en el capítulo de comparación; Esta segunda documentación también se aplicó
para cada modelo con su evaluación en el cuadro comparativo, para tener la
información de las experiencias de la organización154 como base útil en su proceso
de crecimiento y desarrollo que se espera que sea continuo.
El modelo como propuesta de mejora a nivel organizacional que se continúe
aplicando debe ser cada vez más económica de implementar, pues solo se
implementan los cambios sobre la base ya existente, y sus resultados se obtienen
a mediano o largo plazo155, tal como lo plantea este modelo. En esta segunda
versión tampoco se intentó incluir mejoras de nivel técnico porque son más
costosas a pesar de que las mejoras se ven a corto plazo, porque se identifica en
la empresa el requerimiento organizacional mayor que el técnico, pues la empresa
cuenta con apoyos técnicos de alto nivel que no requieren mayor refuerzo.
8.7 FACTORES INFLUYENTES EN LA CALIDAD EN LA RECOMENDACIÓN.
En la aplicación del modelo propuesto en el proyecto de desarrollo de software que
Fusion Partners realiza para Entel de Chile, se verificó alta complejidad de sus
partes y entorno156, dificultad considerable para estimar el tiempo requerido y
dificultad en la comunicación157; todo esto ya se había identificado antes de aplicar
el modelo propuesto en esta práctica, sin embargo se identificó también una relación
no directa entre personal vs avance, y el crecimiento de la entropía a través del
tiempo debido a la falta de información en diferentes partes del proceso de
pruebas158; de esto se considera de primordial necesidad priorizar una agilización
en la comunicación entre las partes y mejorar la relación de cooperación interna y
154 TRUJILLO-CASAÑOLA, Yaimí; FEBLES-ESTRADA, Ailyn; LEÓN-RODRÍGUEZ, Giraldo. Modelo para valorar las organizaciones al iniciar la mejora de procesos de software. Ingeniare. Revista chilena de ingeniería, 2014, vol. 22, no 3, p. 414. 155 PINO, Francisco; GARCÍA, Félix; PIATTINI, Mario. Revisión sistemática de mejora de procesos software en micro, pequeñas y medianas empresas. Revista Española de Innovación, Calidad e Ingeniería del Software, 2006, vol. 2, no 1, p 15. 156 RODRÍGUEZ MANCILLA, Darío. Diagnóstico organizacional. Alfaomega. Ediciones Universidad Católica de Chile, 2005. 157 BUSTOS, Ricardo A. Gacitúa. Métodos de desarrollo de software: El desafío pendiente de la estandarización. Theoria, 2003, vol. 12. 158 Ibíd.
108
con el cliente159 por medio de accesos directos entre desarrolladores, consultores
de pruebas y clientes, haciendo lo más como un equipo. En esta recomendación
propuesta no se recomienda la inclusión de más herramientas tecnológicas, sino
que se propone el mejor uso de las mismas, para hacer lo más efectivo posible el
proceso de pruebas de calidad, considerando la agilización del mismo como un
medio para acercarnos a una reducción del costo.
De la propuesta de mejora de los procesos de estimación de costos de software del
caso del sector de software de Barranquilla se tiene en cuenta como evolutivo del
modelo propuesto que la empresa Fusion Partners, fortalezca los siguientes
aspectos: el manejo de gestión de proyectos para realizar la medición de avances
del cronograma de trabajo del equipo de QA, establecer prioridad de los
requerimientos para el equipo de QA (inclusive la integración del plan de pruebas
rápidas), mantener el acceso del cliente a la herramienta de gestión de proyecto,
pero poner en ella solo resultados finales, junto con el manejo de metodologías y
métodos para asegurar la calidad del producto que se implementaron durante la
aplicación del modelo propuesto.
Aspectos característicos que este primer modelo propuesto considera como
objetivos en la calidad del proyecto:
Alcance y requerimiento: Se establecen los casos de ciclo rápido y para los
funcionales se confirma en comunicación directa con desarrolladores.
Descomposición: Al tener los casos de prueba claros, se descomponen en
actividades o tareas y se le asigna un nivel de prioridad por parte del cliente
con el fin generar entregables que tengan alto valor para el cliente.
Estabilidad de los requerimientos: No existen cambios significativos de los
requerimientos de datos para cada prueba lo largo del ciclo de pruebas,
posterior al diseño y poder reutilizar los que se dispongan.
Histórico de proyectos: El equipo de QA cuenta con una base de datos
histórico donde se almacena información relacionada con la descripción del
caso de prueba, complejidad del caso de prueba, tiempo real de la actividad,
duración general del proyecto en horas y puede generar tiempo estimado de
una actividad cercano al exacto.
159 PINO, Francisco; GARCÍA, Félix; PIATTINI, Mario. Revisión sistemática de mejora de procesos software en micro, pequeñas y medianas empresas. Revista Española de Innovación, Calidad e Ingeniería del Software, 2006, vol. 2, no 1, p 19.
109
Documentación: es primordial documentar la especificación de casos de
prueba y sus progresos con toda la especificación y evidencias en el diseño
ubicado en herramientas disponibles para todo el equipo en tiempo real y
preparado para la creación del manual de usuario. Pero también el modelo
implica la documentación de evolutivos del modelo y las métricas de los
mismos en comparación con el primero y el inmediatamente anterior.
Organización el equipo: El equipo de QA debe contar con un equipo base
para cumplir las labores de la implementación de este modelo propuesto.
Sólo se requieren consultores de pruebas que trabajan en equipo y se
autorregulan. Pero en caso de ingreso de personal nuevo al equipo se debe
poder brindar una capacitación ágil, completa y progresiva con las
metodologías implementadas, al principio las métricas del nuevo integrante
deben incluir observaciones al respecto para su realimentación y su
consideración a la hora de analizar los tiempos.
Competencias del equipo de trabajo: Existencia de personal dispuesto e
interesado en utilizar las diversas herramientas y aplicar detalladamente las
métricas que van a ayudar al equipo a trabajar conforme a este modelo. El
uso de las metodologías como apoyo de capacitación para nuevos y la
continuación de los versionamientos de este modelo para elevar el nivel de
competencia.
Comunicación con el cliente: Constante realimentación del proceso de
pruebas por parte del cliente, confirmación con aplicación de encuestas
según el caso, acceso a las plataformas en tiempo real y disposición de
resultados finales en CLM del progreso del proyecto. Comunicación directa.
Seguimiento: El equipo realiza reuniones diarias para evaluar el cronograma
de trabajo, cumplimiento de estimados, métricas establecidas y evolución de
modelo.
Recomendación propuesta:
Modelo de mejora basado en estandarización, rediseño y realimentación de
procesos de pruebas de desarrollos de software para Fusion Partners S.A.S
Implica tener como base el compromiso con la calidad como base del resto del
sistema, el proceso como elemento principal de desarrollo organizado y oportuno
estructurador, sobre el cual se aplican métodos técnicos (modelos, documentos,
datos, formatos, tareas, pruebas, apoyo, etc.) y finalmente las herramientas se
eligen para brindar apoyo160.
160 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 12.
110
Para la aplicación el modelo se recomienda a la empresa la búsqueda de la mejora
continua de este modelo en sus procesos por medio del modelo en espiral como un
ciclo creciente de mejora, aplicable siguiendo el orden que propone de sus etapas:
comunicación, planeación, modelado, construcción, despliegue161.
Se pretende su inclusión en la organización y sus procedimientos, sin tener que
sea completamente evidente, para que no sea visto como una tarea más a realizar
por cada uno de los consultores, sino que sea visto como un hábito útil para mejorar
los procesos y la calidad de los mismos, siendo a su vez un camino a la mejora de
las condiciones laborales al permitir a los consultores avanzar en cada etapa de
manera más efectiva y por tanto menos complicada.
En la comunicación incluir el proceso de intercambio de información y directrices
entre el equipo de trabajo y con el cliente en todo el equipo del proyecto para
corregir, mantener o mejorar en el siguiente ciclo.
En la planeación tratar de estimar cada ciclo con mayor exactitud que el anterior
ciclo los tiempos, recursos y alcances del equipo de trabajo, especialmente para
lograr un mayor acercamiento en los procesos que dependen exclusivamente del
área de calidad y pruebas, para el cumplimiento a tiempo del requerimiento, y con
esto identificar los factores que puedan retrasar el proyecto.
En cuanto al modelado del sistema de estandarización, rediseño y realimentación
de procesos de pruebas de desarrollo de software, se partirá de esta
recomendación propuesta teniendo como base para la aplicación del modelo en
espiral para su ejecución y que la organización lo evolucione a una propuesta nueva
y transitoria de modelo con mejoras adoptadas del análisis de los resultados de la
aplicación a realizar. Y si así la empresa lo dispone puede continuar el proceso en
la permanente búsqueda modelo aún más adaptado a sus requerimientos, de
manera que también cada modelo pueda ser documentado y archivado posterior a
su uso, para así también contará la organización con una transferencia tecnológica
y un recorrido útil para otras etapas o proyectos que vengan posterior a este.
La construcción es el proceso continuo en el que el equipo de trabajo proponga
cambios y mejoras sobre el modelo que se diseñe, justo antes de iniciar su
despliegue o aplicación a través de cada etapa del proyecto; en esta construcción
se deben elaborar todas las herramientas, accesos, documentos y otros elementos
161 PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. P 39.
111
que resulten necesarios según el modelo para su aplicación en la etapa. Sabiendo
que por el constante cambio de cada etapa el proceso serán frecuentemente
modificados, y personalizados a los requerimientos, recursos y capacidades que se
dispongan para cada etapa. El despliegue es la etapa en la que el modelo con todas
las herramientas y elementos construidos, se ponen en uso durante el desarrollo de
la siguiente etapa del proyecto en la que se desempeñe el equipo de trabajo;
durante esta etapa se recomienda tomar tiempos y nota de los diferentes elementos
a tener en cuenta a la hora de la comunicación. Sin embargo esta etapa y la de la
comunicación pueden ser simultáneas de modo que el equipo completo inicie un
proceso de planeación y creación de estrategias que estén disponibles para las
siguientes etapas.
Al recomendar esta forma de aplicación de la recomendación propuesta que se
propone en la organización se pretende inculcar, sin tener que hacerlo
completamente evidente, para que no sea visto como una tarea más a realizar por
cada uno de los consultores, sino que sea visto como un hábito útil para mejorar los
procesos, la calidad de los resultados y a su vez un camino a la mejora de las
condiciones laborales al permitir a los consultores avanzar en cada etapa de manera
más efectiva, reduciendo las repeticiones de los procesos, los niveles de estrés y la
necesidad de recurrir a mucha documentación para realizar un mismo proceso en
diversas ocasiones.
8.8 DESCRIPCIÓN DEL MODELO.
Los pasos iniciales de la reestructuración.
Las entidades que se participan en el modelo actual son el cliente, líder de
proyecto, líder del equipo de desarrollo, el equipo de desarrollo, líder del
equipo de pruebas, y los consultores de pruebas.
Las entradas al equipo de QA son documentaciones formales, como
entregas parciales del total de documentación requerida(HLD)Y (LLD),
también ingresan las consultas y confirmaciones de parte del cliente y el
equipo de desarrollo, por medio de comunicaciones directas
Los procesos que se desarrollan para la prueba de los casos inician con un
acercamiento detallado a la documentación disponible para identificar sus
componentes, se procede a la repartición de los casos identificados para su
análisis, y cada consultor inicia la lectura de manera analítica y luego consulta
112
al desarrollador directamente cualquier inconsistencia o imprecisión y el
estado del desarrollo en la matriz de seguimiento de desarrollos.
A continuación se inicia el diseño del caso paso a paso en las matrices para
estandarizar cada caso y se hace una verificación del requerimiento del cliente por
medio de encuesta o consulta, se identifican los requisitos de datos para el
desarrollo de las pruebas y se filtran o identifican los casos que pueden ser incluidos
en el plan de pruebas de los casos en CLM; se inician las pruebas de los casos
para identificar defectos y errores que son gestionados directamente con cada
desarrollador y en caso de ser necesario se realimenta la matriz de pruebas.
Finalmente se verifica el estado exitoso, se verifican las métricas (tiempos, defectos,
casos exitosos) y se realiza la validación en CLM en conferencia con el cliente para
que realice la verificación.
Posterior al proceso básico de pruebas se recomienda la aplicación de encuesta al
cliente para verificar y medir la calidad de los procesos desde perspectivas
cualitativas; y se inician los ciclos rápidos de pruebas cómo repeticiones posteriores
para hacer la identificación de los efectos colaterales de otras implementaciones
sobre el ambiente.
114
Con respecto a la propuesta de la aplicación del modelo en espiral para evolucionar
el modelo en la empresa los procesos fueron descritos en el capítulo y son
representados por el siguiente diagrama del modelo en espiral recomendado:
*Las relaciones que se dan son más ágiles y abiertas entre los consultores
del equipo de QA y el equipo de pruebas, generando múltiples puntos de
contacto directos para la gestión de errores y defectos, y para la confirmación
de requisitos e interpretaciones que hacen de todo el proyecto un trabajo en
equipo agilizando los procesos y buscando garantizar la calidad de los
desarrollos al cliente.
*Las salidas que se generan del proceso de pruebas son los resultados de
las pruebas que son notificados vía Skype al desarrollador en caso de
presentar algún defecto o error, el estado final de cada prueba, la
actualización de la matriz en los espacios relacionados a la ejecución, sus
anotaciones y observaciones, las métricas del modelo y las evidencias de
estados defectuosos y exitosos.
Fuente 17 Creación propia
Ilustración 17 Diagrama en espiral recomendado
115
8.9. Recomendaciones
Recomendaciones dirigidas a la empresa.
Se recomienda implementar el diseño de un manual final y en vista de las
dificultades de escritura en los diversos documentos, se recomienda la
retroalimentación de los mismos a través del proceso, de modo que sean
debidamente actualizados y documentados de modo que el producto final esté
claramente documentado facilitando así la capacitación de los clientes finales; la
inserción de diagramas de flujo que sean incluidos en manuales (si el cliente está
interesado en ellos en las siguientes etapas del proyecto.
También se recomienda la comunicación de los cambios en los requerimientos de
manera oportuna. En cuanto a la respuesta adecuada al cambio, se recomienda
que el equipo de desarrollo tenga total acceso a los requerimientos del cliente en
tiempo real, o lo más pronto posible para que le sea posible al equipo reducir los
costos los costos y tiempos por medio del uso de pruebas unitarias continuas y
ciclos de pruebas rápidas.
Recomendaciones para el lector del documento.
Al lector del documento se le recomienda la lectura total del documento para
contextualizar las metodologías aplicadas en este proyecto, pues fueron adaptadas
específicamente al caso de los procesos de pruebas de Fusion Partners en el
desarrollo del proyecto para Entel de Chile, lo que implica que el modelo aplicado
generó los resultados presentados debido a las condiciones propias de la
organización en la que implementó.
También se recomienda al lector considerar y disponer de las técnicas o ideas que
este documento le pueda brindar ya sea en una aplicación pedagógica, académica,
laboral, empresarial o de cualquier tipo; considerando que su aplicación o
implementación requiere de un esfuerzo coordinado, organizado y persistente para
culminar cada etapa, así mismo también exige la inversión de tiempo, recursos y
del interés por parte de la administración de la empresa para realizar.
116
9. COMPARACIÓN ENTRE SITUACIÓN INICIAL Y EL RESULTADO DE LA
IMPLEMENTACIÓN DEL MODELO.
A continuación se presenta la comparación entre el estado inicial de la organización
y la implementación del modelo, según todas las temáticas analizadas y sobre cada
aspecto expuesto, también se presenta la recomendación correspondiente a cada
aspecto; Esta comparación sirve a la empresa y al lector para facilitar la
comprensión del documento y dimensionar los logros que se obtuvieron a través del
proyecto; también permite presentar de manera resumida los resultados obtenidos,
desde una perspectiva cualitativa, en la aplicación del modelo y la recomendación
para que la empresa pueda evolucionar el modelo como parte de sus procesos
cotidianos.
Los casos probados antes de la implementación son los que se presentan en la
siguiente tabla:
Medición de tiempo de las Pruebas. Tabla 15 Medición de pruebas situación inicial.
Fuente tabla 15 Creación propia
117
Tabla 16 Medición de pruebas situación inicial.
Fuente tabla 16 Creación propia
Tabla 17 Medición de pruebas aplicado el modelo.
Fuente tabla 17 Creación propia
118
Tabla 18 Medición de pruebas modelo inicial.
Fuente tabla 18 Creación propia
Los casos probados antes de la implementación sumaron un total de horas de
12558,15 mientras que los casos probados con la implementación del modelo
sumaron un total de horas de 201,37, con una diferencia de: 201,37. Esta enorme
diferencia no es de extrañar debido a que varios casos de prueba gestionados sin
la implementación del modelo fueron olvidados, por semanas debido a que no se
les hizo seguimiento alguno.
9.1 FUNCIÓN DEL INGENIERO INDUSTRIAL COMPARACIÓN.
Cuadro comparativo de modelos.
Con respecto a la función del ingeniero industrial se tienen en cuenta los aspectos
relacionados con el papel que cumple en el posicionamiento en la empresa, el
manejo de la información, la calidad y la integración del sistema, en el siguiente
cuadro comparativo se presentan las diferencias analizadas desde la perspectiva
teórica en la situación inicial vs el modelo. Todos estos aspectos están expuestos
más específicamente en el capítulo de situación inicial y el capítulo de modelo
propuesto basado en el fundamento teórico.
119
Tabla 19
Fuente tabla 19 Creación propia
La recomendación que se propone se puede visualizar detalladamente en el
capítulo de diseño de la recomendación propuesta. Con respecto al posicionamiento
del ingeniero industrial en la empresa se propone fortalecerlo para mantener y
mejorar las articulaciones del área de QA, rediseñar los procesos y generar
continuamente nuevas versiones del modelo de mejora y mantener el enfoca que
en funciones técnicas -administrativas implícitas en cada versión que se realice en
busca de una manera más adecuada a medida que evoluciona el modelo. En el
manejo de la información, se recomienda que el papel del ingeniero industrial este
dirigido a la generación de evolutivos del modelo, para generar más efectividad de
la optimización de procesos de transferencia interna del conocimiento, de la
estandarización de los procesos y la universalidad de la información que se maneje
a nivel organizacional. En el área de calidad la recomendación es Insertar al
ingeniero industrial en la cultura de la mejora constante de la calidad, cumpliendo
con la normalización y el garantizar la calidad, mejora progresiva de procesos
buscando la calidad total; y con respecto a la integración del sistema, se recomienda
Inicial Modelo
No hay un profesional del area en cada
sistema que tome partida de las causas
que generan algunos problemas a nivel
general y en cada sistema.
Incluirlo para las articular el área de QA,
diseñar los procesos y generar
modelos de mejora y enfocarse en
funciones técnicas-administrativas
(organizar, dirigir, coordinar) implícitas
en el modelo en busca de una manera
más adecuada de cumplir las funciones
La coordinación de las actividades a
nivel interno del equipo de calidad se
realiza según la prioridad del
requerimiento, para cumplir con
solicitudes del sistema externo.
Al rediseñar el modelo genera un
acercamiento a la optimización de
procesos de transferencia interna de
conocimiento, la estandarización de los
procesos y la universalidad de la
información a nivel organizacional.
De manera independente todos los
integrantes del equipo toman medidas
personalizadas de control de casos, sin
registro o control estandarizado.
En la normalización y la calidad,
aporta al control interno mecanismos
específicos de la calidad del software,
haciendo mas efectivos los procesos.
No hay alguien que se encargue de
conocer, gestionar, integrar y
"orquestar" todas las actividades
referentes al proyecto u al sistema .
El ingeniero industrial se encarga de
conocer, gestionar, integrar y
"orquestar" todas las actividades
referentes a los procesos de pruebas
de desarrollos, por medio de la
adquisicion de la informacion suficiente,
modelado y propuesta de mejora.
Cuadro comparativo de modelos función del ingeniero industrial
Posicionamiento
en la empresa
Aspecto
Manejo de la
información
Calidad
Integración del
sistema
120
que el ingeniero industrial se encargue de reevaluar los procesos y procedimientos
de cada etapa de todas las actividades referentes a las pruebas de desarrollos, por
medio del versionamiento del modelo inicial propuesto para guiar a una
optimización.
9.2 METODOLOGÍA DE LA EMPRESA COMPARACIÓN.
Con respecto a las metodologías de las empresas se tienen en cuenta los aspectos
relacionados con el papel que cumple el ingeniero industrial en el manejo de la
información y comunicación, la transferencia tecnológica, el control de calidad, la
efectividad, las fuentes de información y el objetivo de la metodología en el área
de calidad de la empresa; en el siguiente cuadro comparativo se presentan las
diferencias analizadas desde la perspectiva teórica en la situación inicial vs el
modelo. Todos estos aspectos están expuestos más específicamente en el capítulo
de situación inicial y el capítulo de modelo propuesto basado en el fundamento
teórico. Tabla 20
Fuente tabla 20 Creación propia
Inicial Modelo
Comunicación no homogénea e
indirecta, formato estándar para todos
los países de LLD, no accesos directos.
Facilitar el manejo de información y la
comunicación (2 ) de QA con los
demás.
Conocimientos implícitos, no
compartidos, ni adaptados de las
experiencias en proyectos anteriores
El consenso del conocimiento de la
información útil captada de otros
proyectos anteriores en para otros
clientes
Pruebas para validar el estado de los
desarrollos y realimentar al equipo de
desarrollo
La normalización o estandarizacion de
procesos de pruebas de desarrollo y de
verificación del nivel de calidad.
(universalidad de la información) por
medio de la misma matriz de control del
proceso y seguimiento con Clm. Con la
creacion de manuales al final de todo el
proceso.
La efectividad en los procesos de
pruebas es muy baja ya que no hay una
estandarización que permita el avance
de las pruebas mas eficientemente.
La metodología a aplicar búsca la
efectividad en los procesos de
pruebas(estandarizar) realizada al final
del proceso, aportando a la calidad (5)
los formatos necesarios
La fuente de información principalmente
es la documentacion HLD Y LLD, y en
menor medida las consultas por medio
del lider de pruebas al lider de
desarrollos
La universalidad de la información
tomada de la informacion disponible
Identificar y corregir los defecto y
errores que se identifiquen durante las
pruebas.
Adaptar otros modelos tomados de la
teoria a las condiciones de la empresa
Manejo de la
informacion y
comunicación
Transferencia
tecnológica
Aspecto
Cuadro comparativo de modelos en las metodologías de las empresas
Control de
calidad
Efectividad
Fuentes de
información
Objetivo de la
metodología
121
La recomendación que se propone se puede visualizar detalladamente en el
capítulo de diseño de la recomendación propuesta. Con respecto a las metodologías
de las empresas en el manejo de la información y comunicación, se recomienda
realizar una adaptación más completa y evolucionada que garantice agilizar el
manejo de información y la comunicación (2); y en la transferencia tecnológica, se
recomienda la documentación y recopilación de la información útil captada durante
la aplicación del primer modelo del cliente, otras áreas y equipo de trabajo que
pueda ser usada en capacitaciones y contextualización de proyectos
En la metodología para el control de calidad se recomienda utilizar matrices en el
diseño de los procesos estandarizar cada caso de prueba (nivel de uniformidad con
precisión terminológica)(16), y el uso formatos específicos diseñados para cada
actividad por separado y solo implementar CLM a casos exitosos; así como también
se propone al cliente y la empresa diseñar de manuales terminada cada fase. En
cuanto a la efectividad, se recomienda la metodología de la adaptación de la primera
propuesta garantizando agilidad efectiva en el proceso de pruebas, como aporte a
la calidad (5), y evitar el formalismo excesivo en lo posible.
Las metodologías en las fuentes de información se recomiendan documentar la
universalidad de la información conciliada directamente de las personas, para
obtener la mayor precisión posible; y en cuanto al objetivo de la metodología se
recomienda adaptar el primer modelo con los cambios necesarios según los
resultados de su aplicación.
9.3 METODOS DE VALIDACIÓN - COMPARACIÓN.
La comparación de los métodos de validación tiene en cuenta los aspectos
relacionados con el plan de pruebas, la gestión de defectos, la participación del
cliente, el tipo validación, las evidencias , los reprocesos y otras demoras
relacionadas con los procesos de pruebas y realimentación de desarrollos de la
empresa, específicamente en el área de calidad. Todos estos aspectos están
expuestos más específicamente en el capítulo de situación inicial y el capítulo de
modelo propuesto basado en el fundamento teórico.
122
Tabla 21
Fuente tabla 21 Creación propia
La recomendación que se propone se puede visualizar detalladamente en el
capítulo de diseño de la recomendación propuesta. El plan de pruebas que se
recomienda implica el desarrollo de un plan de pruebas de “ciclo rápido” filtrado
durante la revisión previa (casos iniciales y básicos) y también filtrado posterior a
las pruebas (de caja y sin integrar otros sistemas). Para la gestión de defectos se
recomienda hacer la gestión de manera inmediata y personalizada con cada
desarrollador por Skype o en persona.
Se recomienda la participación del cliente Incluye la interacción con el cliente y su
inclusión en la confirmación del requisito y la prueba fina, usando el tipo validación
de experimentos (pruebas de caja, de integración, unitaria, funcional, de sistema,
etc); encuestas (cuantitativas y cualitativas al cliente y desarrolladores) y casos de
estudio (siguiendo tiempos para establecer relaciones con demoras y errores)(3).
Las evidencias que se recomiendan son pantalla a pantalla.
Con respecto a los reprocesos y otras demoras se recomienda aplicar la evolución
del modelo propuesta, que pretende reducir las demoras por formalismos
Inicial Modelo
Se desarrollo con respecto al orden que
se encontraba en los documentos sin
importar primordialidad, si estaban o no
desarrollados o si necesitaban de pre-
requisitos, hechos con un
procedimiento de paso a paso apoyado
por los documentos.
El plan de pruebas: realizarlas por
orden de entregas de los
desarrolladores,grupados del mismo
documento(HLD y LLD), por
desarrollador o por dueño de prueba
Se manejaba por medio del lider de
proyecto generando sobre carga laboral
inncecesaria y no se hacía el respectivo
seguimiento
Conoce el avance sólo por medio de
indicadores actualizados diariamente
Experimentos basados en evaluación e
inspección
Experimentos (solo pruebas
unitarias)(3) con evidencias de
resultados
No hay evidencias Finales
La falta de información o
informaciones contradictorias, a la falta
comunicación con los desarrolladores,
defectos del sistema y errores de
desarrollos
Debido a demoras en respuestas
formales via CLM se generaron
difiultades de cumplimiento de plazos y
reprocesos.
Aspecto
Cuadro comparativo de modelos en los métodos de validación
Plan de pruebas
El uso de la herramienta CLM gestion
automatica de defectos(Causo
continuos reclamos del cliente por
defectos que no entendian), control en
tiempo real de los casos que están
exitosos y los que no compartido con el
Participación del
cliente
Gestion de
defectos
Tipo validación
Evidencias
Reprocesos y
otras demoras
123
innecesarios y evitar reprocesos por medio de consultas directas con los
desarrolladores y el cliente.
9.4 ASEGURAMIENTO DE LA CALIDAD- COMPARACIÓN.
En el aseguramiento de la calidad se evalúan los aspectos en relación con la
calidad, las matrices, los diagramas de flujo, la estrategia, la evaluación "suave", la
evaluación "dura", las seis sigmas y el costo que representa la aplicación de
cada modelo a los procesos de la empresa. Todos estos aspectos están expuestos
más específicamente en el capítulo de situación inicial y el capítulo de modelo
propuesto basado en el fundamento teórico. Tabla 22
Fuente tabla 22 Creación propia
Inicial Modelo
No hay evaluación de la eficacia en el
control de calidad, no se tienen
revisiones técnicas o analisis de
errores.
Desarrollo de los elementos básicos del
aseguramiento de la calidad
No se cuenta con matrices
Uso de matriz para estandarizar y hacer
seguimiento de funcionamiento,
apoyandose en CLM para gestionar.
No se cuenta con diagramas de flujo
Crear diagramas de flujo que grafican
cada proceso sirven para apoyar el
proceso de pruebas de los casos
Reportar los errores y registrarlos en
una lista (lista sin seguimiento)
estandarización mediante tareas
sencillas y documentar todos los
procesos a considerar, e identificar y
gestionar durante las pruebas la
depuración el proceso productivo.
No se tiene evaluación estrategica con
respecto a los procesos, ni pruebas
Evaluación “suave” de la calidad de los
desarrollos a probar durante el
proyecto, por medio de las revisión de
requerimientos
No se tiene evaluación estrategica con
respecto a los procesos, ni pruebas,
solo los tiempos para llegar a casos
existosos
Evaluación “dura” mediante la toma de
tiempos y el conteo de defectos durante
las pruebas con apoyo en clm (registros
e informes)
Sin aplicación de seis sigmas
Aplicación de seis sigmas, adaptando
otros modelos segun sean necesarios,
estandarizando, con metricas y con
seguimiento.
Hay un mayor costo de tipo preventivo,
medio costo en la parte de evaluación y
costo alto de fallas
Genera un costo inicial de
implementación alto, con resultados
satisfactorios pero mejorables
considerablemente de tipo preventivos,
de evaluación y de fallas.
Aspecto
Cuadro comparativo de modelos en el aseguramiento de la calidad
Costo
Relación con la
calidad
Matrices
Diagramas de
flujo
Estrategia
Evaluación
"suave"
Evaluación
"dura"
Seis sigmas
124
La recomendación que se propone se puede visualizar detalladamente en el
capítulo de diseño de la recomendación propuesta. Con respecto a la relación de la
recomendación con la calidad, la recomendación busca mantener los elementos
básicos e incorpora modelo de espiral pretende la búsqueda de la mejora continua.
Para esto se recomienda el uso de las herramientas de la siguiente manera:
Las matrices: una para estandarizar y otra para hacer seguimiento de
funcionamiento según entregas, apoyándose en CLM para presentar
específicamente los resultados exitosos.
Los diagramas de flujo: usar los diagramas de flujo entregados por cliente y
desarrolladores como apoyo a la información recibida, para no realizar una
formalización más de lo necesario.
La estrategia que se recomienda, es depurar el proceso productivo de una manera más directa, ágil y efectiva, por medio de la reducción de formalismos; y la aplicación de las seis sigmas con verificaciones, métricas (análisis), agilización de comunicación y realimentación del primer modelo aplicado (evolutivo). Para evaluar los avances se recomienda en la evaluación "suave" de la calidad de los desarrollos a probar durante el proyecto, por medio de las encuestas o consultas al cliente; y la evaluación "dura" mediante la toma de tiempos y el conteo de defectos (CLM únicamente para casos exitosos), con encuestas y casos de estudio directamente con el cliente. La recomendación que se presenta en el documento al aplicarse genera una reducción del costo de implementación menor, debido a que ya posee como base el modelo anterior y es agilizado. Así mismo se espera que cada evolutivo genere reducción de costos de todos los tipos en los procesos de pruebas de calidad (preventivos, de evaluación y de falla).
9.5 LOS MODELOS - COMPARACIÓN.
Los modelos que se tienen en cuenta en la situación inicial y en el modelo propuesto se comparan en según los elementos identificados o no en cada una de estas etapas y la forma en la que se aplicaron, estos aspectos están expuestos más específicamente en el capítulo de situación inicial y el capítulo de modelo propuesto basado en el fundamento teórico. Los aspectos asociados para la comparación son: los diagramas de flujo, la especialización, el trabajo colectivo considerado por Mintzberg en la estructura en cinco, las metodologías ágiles, el modelo en espiral, la metodología AOPOA, los requerimientos, la generación de cambio y el tipo de mejora que representa o implica cada uno.
125
Tabla 23
Fuente tabla 23 Creación propia
La recomendación que se propone se puede visualizar completa y detalladamente
en el capítulo de diseño de la recomendación propuesta. Con respecto a los
diagramas de flujo se recomienda el uso de los que son proporcionados por el
cliente y los desarrolladores, y para el diseño de los modelos que se versionen con
el modelo en espiral, este implica un versionamiento más ajustado y adaptado a las
Inicial Modelo
Se usarán los que vienen en el H.L.D
El desarrollo de los diagramas de flujo
para cada caso de prueba y para el
diseño del modelo.
No había en ninguna parte que pueda
ser visualizada o enfocada a Q.A
Especialización en la documentación
de los procesos y con el análisis de la
información disponible
Sólo se maneja actualmente la parte de
la supervisión directa y algo del ajuste
mutuo, sin embargo hay que hacer
mucha enfasis en las estandarizaciones
Mecanismos coordinadores básicos
con comunicación informal, supervisión
directa y la estandarización de los
procesos de trabajo (6pag3)
No consideracion de este tipo de
metodologia.
Uso de las metodologías ágiles en la a
importancia sus interacciones y un
software funcional
No consideracion de este tipo de
metodologia.
Base inicial para ser versionado, con
ajustes y adaptaciones a las
cambiantes necesidades de la
empresa, así como a sus recursos y
entorno
No consideracion de este tipo de
metodologia.
Descomposición en unidades
autónomas en cada etapa del proceso
de manera para realizar división por Requiere de tiempo, recursos,
disposición, interés y los costos
correspondientes o asociados al
desarrollo de pruebas. Exige esfuerzos
derrochados del equipo de trabajo
debido a la no planeacion ni
estandarizacion de los procesos de
pruebas; genera costos de falla y
reprocesos.
Disponer de tiempo, recursos,
disposición, interés y los costos
correspondientes o
asociados;continuación del proceso y
de la formulación de evolutivos del
modelo
El cambio es permanente, impredecible
y genera dificultades que atrasan los
procesos de pruebas
No pretende generar cambios
inmediatos, por lo que se toma como
estado inicial
La empresa posee alto nivel tecnico en
herramientas disponibles, pero requiere
mejoras en nivel organizacional
No incluye mejoras de nivel técnico,
porque es mas necesariorealizar
mejoras a nivel organizacional.
Aspecto
Cuadro comparativo de modelos
Diagramas de
flujo
Especialización
Trabajo
colectivo
(Mintzberg en la
estructura en
cinco)
Genaración de
cambio
Tipo de mejora
AOPOA
Requerimientos
Metodologías
ágiles
El modelo en
espiral
126
cambiantes necesidades de la empresa, así como a sus recursos y las relaciones
con el cliente.
Para contrarrestar la complejidad, se recomienda una especialización
específicamente en la comunicación con los desarrolladores y el cliente, lo que a su
vez es un aporte a los mecanismos coordinadores básicos, con comunicación
informal (desde metodología ágil), la estandarización de los procesos,
estandarización de destrezas y conocimientos de los trabajadores, esto respecto al
trabajo colectivo (Mintzberg en la estructura en cinco).
El uso de las metodologías ágiles en la importancia de los individuos y sus
interacciones, software funcional, colaboración con el cliente y respuesta al cambio;
la aplicación de la metodología AOPOA, se recomienda con la descomposición de
roles más específica en cada etapa del proceso de manera que sirva para que las
actividades comunes sean predefinidas con sus agentes.
Con respecto a los requerimientos, la recomendación propuesta reduce el
requerimiento de tiempo, recursos y los costos correspondientes o asociados; y
mantiene o aumenta el requerimiento de disposición e interés. Es parte continuación
del proceso y de la formulación de evolutivos del modelo; y en cuanto a la
generación de cambio, no pretende generar cambios inmediatos, sin embargo se
contrasta con el primero para identificar y valorar el cambio; esto se debe a que el
tipo de mejora que representa, no incluye mejoras de nivel técnico, porque sigue
considerándose innecesario
9.6 FACTORES INFLUYENTES EN LA CALIDAD - COMPARACIÓN.
Los factores influyentes en la calidad son múltiples, e incluyen las dificultades
principales, el agente herramientas tecnológicas, los objetivos en la calidad
(Alcance y requerimiento, la descomposición, la estabilidad de los requerimientos,
el histórico de proyectos, la documentación, la organización del equipo, las
competencias del equipo de trabajo, la comunicación con el cliente y el seguimiento.
Estos aspectos están expuestos más específicamente en el capítulo de situación
inicial y el capítulo de modelo propuesto basado en el fundamento teórico.
127
Tabla 24
Inicial Modelo
Alta complejidad de sus partes,
procesos y relaciones, estimar el
tiempo requerido y la dificultad en la
comunicación, Relación no directa
entre personal vs. avance, y el
crecimiento de la entropía a través del
tiempo debido a la falta de información,
dificultad para cumplir plazos, entre
otras.
Alta complejidad de sus partes, estimar
el tiempo requerido y la dificultad en la
comunicación
Manejo de gestión de proyectos,
establecer prioridad de los
requerimientos (pero solo en
desarrollo), acceso del cliente a
herramienta de gestión de proyecto, el
equipo de desarrollo usa diferentes
environments y manejo de metodologías
y métodos para asegurar la calidad del
producto
Aplicar rediseño y estandarización de
procesos y establecer un ambiente
específicamente para pruebas (QA).
Fotalecer metodologías y métodos
para asegurar la calidad del producto.
Se disponen los casos de prueba
funcionales en la documentación.
Se establecen los casos de prueba
funcionales a partir de documentación y
consultas a cliente y equipo de
desarrollo.
No se aplica descomposicion de casos
Se descomponen en actividades o
tareas a fin generar entregables en el
menor tiempo posible
Se solicitan requerimientos para cada
prueba lo largo del ciclo de pruebas
Evitar cambios significativos de los
requerimientos de datos para cada
prueba lo largo del ciclo de pruebas,
posterior al diseño.
El equipo de QA cuenta con una
documentacion donde se almacena
información relacionada con la
descripción del caso de prueba.
El equipo de QA cuenta con una base
de datos histórico donde se almacena
información relacionada con la
descripción del caso de prueba.
Aspecto
Cuadro comparativo de modelos factores influyentes en la calidad
Objetivos en la
calidad:
Estabilidad de
los
requerimientos
Objetivos en la
calidad:Histórico
de proyectos
Agente
herramientas
tecnológicas
Dficultades
principales
Objetivos en la
calidad: Alcance
y requerimiento
Objetivos en la
calidad:
Descomposició
n
Inicial Modelo
La documentacion se obtiene de parte
del cliente (HLD) y el equipo de
desarrollo (LLD)
De la especificación de casos de
prueba y sus progresos con evidencias
en el diseño ubicado en herramientas
disponibles para todo el equipo en
tiempo real y preparado para la
creación del manual de usuario.
El equipo de QA debe cuenta con un
equipo base pero suceptible a cambios
bruscos no planeados, sus consultores
tienen actividades en diversas areas de
la empresa y tambien se comparten con
otros proyectos.
El equipo de QA debe contar con un
equipo base para cumplir las labores
de la implementación de este modelo
propuesto; solo se requiere un líder y
consultores de pruebas, a todos se les
consideran las métricas de igual
manera
Existencia de personal para capacitar
en el uso de las diversas herramientas
Existencia de personal capacitado
para utilizar las diversas herramientas
que van a ayudar al equipo a trabajar
conforme a la metodología
seleccionada.
Comunicacion indirecta por medio de
un lider en otro pais y por
documentacion entregada parcialmente
e incompleta
Constante acceso al proceso de
pruebas por parte del cliente, acceso a
las plataformas en tiempo real y
disposición de toda la información en
CLM del progreso del proyecto
El equipo avanza el proceso de
pruebas en el orden que presenta la
documentacion o en el orden de
entregas de los desarrolladores.
El líder del equipo realiza reuniones
diarias para evaluar el cronograma de
trabajo. Se evalúan cumplimiento de
estimados, métricas establecidas y
evolución de modelo.
Aspecto
Cuadro comparativo de modelos factores influyentes en la calidad
Objetivos en la
calidad:
Documentación
Objetivos en la
calidad:
Organización el
equipo
Objetivos en la
calidad:
Competencias
del equipo de
trabajo
Objetivos en la
calidad:
Comunicación
con el cliente
Objetivos en la
calidad:
Seguimiento
128
Las recomendaciones abordan de las dificultades principales la relación no directa
entre personal vs. avance, y el crecimiento de la entropía a través del tiempo debido
a la falta de información; para lo que aplica como agente herramientas tecnológicas
la medición de avances del cronograma de trabajo del equipo de QA,
establecer prioridad de los requerimientos para el equipo de QA (inclusive la
integración del plan de pruebas rápidas), mantener el acceso del cliente a la
herramienta de gestión de proyecto, pero poner en ella solo resultados finales.
La recomendación que se propone se puede visualizar completa y detalladamente
en el capítulo de diseño de la recomendación propuesta. Esta recomendación
aborda los objetivos en la calidad de la siguiente manera:
Alcance y requerimiento: Se establecen los casos de ciclo rápido y para los
funcionales, se confirma en comunicación directa con desarrolladores.
Descomposición: Se descomponen en actividades o tareas y se le asigna un
nivel de prioridad por parte del cliente para entregables de alto valor para el
cliente.
Estabilidad de los requerimientos: No existen cambios significativos de los
requerimientos de datos para cada prueba lo largo del ciclo de pruebas,
posterior al diseño y poder reutilizar los que se dispongan.
Histórico de proyectos: El equipo de QA cuenta con una base de datos
histórico donde se almacena información relacionada con la descripción del
caso de prueba y puede generar tiempo estimado de una actividad cercano
al exacto.
Documentación: De la especificación de casos de prueba y sus progresos
con evidencias en el diseño ubicado en herramientas disponibles para todo
el equipo en tiempo real y preparado para la creación del manual de usuario.
También de evolutivos del modelo y las métricas de los mismo en
comparación con el primero y el inmediatamente anterior.
Organización el equipo: El equipo de QA debe contar con un equipo base
para cumplir las labores de la implementación de este modelo propuesto.
Sólo se requieren consultores de pruebas que trabajan en equipo y se
autorregulan. En caso de ingreso de personal nuevo al equipo brindar una
capacitación ágil, completa y progresiva, al principio las métricas del nuevo
integrante deben incluir observaciones.
*Competencias del equipo de trabajo: Existencia de personal dispuesto e
interesado en utilizar las diversas herramientas y aplicar detalladamente las
métricas que van a ayudar al equipo a trabajar conforme a este modelo.
129
Comunicación con el cliente: Constante realimentación del proceso de
pruebas por parte del cliente, confirmación con aplicación de encuestas
según el caso, acceso a las plataformas en tiempo real y disposición de
resultados finales en CLM del progreso del proyecto.
Seguimiento: El equipo realiza reuniones diarias para evaluar el cronograma
de trabajo, cumplimiento de estimados, métricas establecidas y evolución de
modelo.
9.7 ANTECEDENTES - COMPARACIÓN.
Los antecedentes básicamente presentan la diferencia entre la situación inicial del
proyecto, con respecto al uso y consideración de sus antecedentes ya sea los
antecedentes disponibles del proyecto en ETB o del proyecto en TIGO de honduras.
Estos aspectos están expuestos más específicamente en el capítulo de situación
inicial y el capítulo de modelo propuesto basado en el fundamento teórico.
Con respecto al uso de los antecedentes en ETB, la recomendación es analizar las
posibles deficiencias del primer modelo que puedan compartirse con los
antecedentes a nivel de experiencias de los desarrolladores y del equipo de QA
(ambiente laboral, muy alta complejidad, no uso de matrices para diseños de casos,
etc). Con respecto a los antecedentes en TIGO de Honduras, se recomienda
analizar las posibles deficiencias del modelo aplicado que puedan compartirse con
los antecedentes a nivel de experiencias de los desarrolladores y del equipo de QA
(matrices y formatos con formalismos excesivos y demorados, falta de
comunicación por no acceso a matrices de desarrollo, ni seguimiento, etc.)
Inicial Modelo
Solo uno del equipo estuvo integrado y
las metodologias procedimentales
tenian una complejidad muy alta en
comparación con las aplicadas en
Entel.
Se hace la revisión de los documentos y
especialmente se centra la atencion en
los documentos y formatos de
seguimientos de pruebas a los que se
tenia acceso y sus caracteristicas
especificas
Dos personas del equipo estuvieron
integrados y las metodologías
procedimentales tenían una
complejidad muy semejante por lo que
tenían algunas guías
Se hace la revisión de los documentos y
especialmente se centra la atención en
los documentos y formatos de
seguimientos de pruebas a los que se
tenía acceso y sus características
específicas.
Aspecto
Cuadro comparativo de modelos en los antecedentes
de los
antecedentes en
ETB
de los
antecedentes en
tigo honduras
130
10. CONCLUSIONES
Se logró diseñar un modelo de mejoramiento de los procesos de prueba y
realimentación de desarrollo de software, mediante la estandarización de procesos
y la creación de manuales de procedimientos para la empresa Fusion Partners
S.A.S con lo que se facilitó el desarrollo de pruebas, capacitación, comunicación
interna y la satisfacción del cliente.
Mediante la estructura, factores y las variables de procesos de la organización
Fusion Partners S.A.S se identificó que la principal problemática estaba regida por
la falta de comunicación e integración de los actores que diariamente tienen dominio
sobre las plataformas y los diferentes ambientes creados para la funcionalidad de
la organización.
A partir de las técnicas de la ingeniería industrial, se creó un modelo basado en la
integración de todos los actores que participan en la elaboración de los diferentes
ambientes los cuales con ayuda de las técnicas, estructuras, tecnologías y
conocimientos logran la optimización del proceso a realizar.
Con el uso de los indicadores de control estratégico y los requerimientos de
desempeño de la empresa, se demostró que es válida la implementación de este
modelo debido a que con este se logra enfocar de manera integral y no técnica el
mejoramiento continuo, la universalidad y la implementación de canales de
comunicación para el cumplimiento de los objetivos organizacionales.
Finalmente, por medio de la práctica académica se evidencio que es necesario el
fortalecimiento del rol de ingeniero industrial dentro de estos tipos de proyectos ya
que como primera instancia hubo un gran cambio en la articulación y en el progreso
de este. Sin embargo es necesario que se haga una mayor atención a otras posibles
actividades en las cuales se puede intervenir de tal manera que la mejora sea
integral y no sólo a nivel técnico inspirados en la ideología del mejoramiento
continuo y la generación de modelos que sirvan para este y otros proyectos que se
encuentren asociados a las pruebas como los anteriormente nombrados en el
trabajo.
131
Bibliografía
Fusion Partners. Hoja de vida corporativa. Volumen 4. Bogotá D.C. 5,6 p.
RODRIGUEZ, Roberto, Pagina inicial empresa Fusion Partners.[En línea].Argentina; [Rev.
29 Julio 2016]. Disponible en internet: http://www.fusionpartners.com.ar. [En línea]
BUSTOS, Ricardo A. Gacitúa. Métodos de desarrollo de software: El desafío pendiente de
la estandarización. Theoria, 2003, vol. 12, p 25.
Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de
software. Metodologías Ágiles en el Desarrollo de Software, 2003, p .
CARUSO, Nohora Nubia Mercado; DEL CASTILLO, Edwin Puerta; NAVARRO,
Katherinne Salas. Mejora de los procesos de estimación de costos de software: Caso del
sector de software de Barranquilla. Revista de Ingenierías: Universidad de Medellín, 2015,
vol. 14, n.
FAYOL, Henri; TAYLOR, Frederick Winslow. Administración industrial y general. Orbis,
1987. p 2,3.
Fusion Partners. Hoja de vida corporativa. Volumen 4. Bogotá D.C. 3 p.
MUÑOZ, Coral Calero; VELTHUIS, Mario G. Piattini; DE LA RUBIA, María Ángeles
Moraga. Calidad del producto y proceso software. Editorial Ra-Ma, 2010.
MUÑOZ, Coral Calero; VELTHUIS, Mario G. Piattini; DE LA RUBIA, María Ángeles
Moraga. Calidad del producto y proceso software. Editorial Ra-Ma, 2010.
PARRA DÍAZ, Cristian Andrés; PRIETO BARRIGA, Jorge Andrés. Estudio del estado del
arte y tendencias educativas en universidades de Finlandia y Noruega en el programa de
Ingeniería Civil como parte de un análisis prospectivo para Colombia. 2014.
PEÑA, Javier Parra. La ingeniería industrial en el contexto del desarrollo sostenible.
Revista Tecnura, 1999, vol. 2, no 4, p. 28.
PINO, Francisco; GARCÍA, Félix; PIATTINI, Mario. Revisión sistemática de mejora de
procesos software en micro, pequeñas y medianas empresas. Revista Española de
Innovación, Calidad e Ingeniería del Software, 2006, vol. 2, no 1, p 15.
PONS, Claudia; GIANDINI, Roxana Silvia; PÉREZ, Gabriela. Desarrollo de software
dirigido por modelos. 2010. p 23.
PRESSMAN, Roger S.; TROYA, Jose Maria. Ingeniería del software. McGraw Hill, 1988. p
11.
RODRÍGUEZ, Julián; TORRES, Miguel; GONZÁLEZ, Enrique. La Metodología AOPOA.
Avances en Sistemas e Informática, 2007, vol. 4, no 2. P 2.
TRUJILLO-CASAÑOLA, Yaimí; FEBLES-ESTRADA, Ailyn; LEÓN-RODRÍGUEZ, Giraldo.
Modelo para valorar las organizaciones al iniciar la mejora de procesos de software.
Ingeniare. Revista chilena de ingeniería, 2014, vol. 22, no 3, p. 413.
Top Related