MODELO DE MEJORA BASADO EN ESTANDARIZACIÓN, REDISEÑO Y REALIMENTACIÓN DE PROCESOS...

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

3

Nota de Aceptación

Presidente del Jurado

Jurado

Jurado

Bogotá 30/10/16

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


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 17 Medición de pruebas aplicado el modelo. ....................................................... 117


Tabla 19 Cuadro comparativo entre modelos ................................................................ 119






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

http://www.fusionpartners.com.ar/servicios.html

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


Tabla 4 de seguimiento de pruebas de portales ETB.


42

Tabla 5 Seguimiento de defectos de casos de prueba de portales ETB


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


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


44

Tabla 10 Manuales para usuario final


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.


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


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


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.


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.


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


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.

82


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


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.


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.


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


90

Ilustración 14 Vista de los casos desde CLM.

Fuente 14 Vista de los casos desde CLM

Ilustración 15 Vista del ambiente


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.)


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.


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.



posterior al diseño y poder reutilizar los que se dispongan.



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.


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


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.

113

Fuente 16Creación propia

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.


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.


117

Tabla 16 Medición de pruebas situación inicial.


Tabla 17 Medición de pruebas aplicado el modelo.


118

Tabla 18 Medición de pruebas modelo inicial.


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


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


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


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



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


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


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


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


metodologia.

Base inicial para ser versionado, con

ajustes y adaptaciones a las

cambiantes necesidades de la

empresa, así como a sus recursos y

entorno


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.



posterior al diseño y poder reutilizar los que se dispongan.



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.

MODELO DE MEJORA BASADO EN ESTANDARIZACIÓN, REDISEÑO Y REALIMENTACIÓN DE PROCESOS...

Documents

Transcript of MODELO DE MEJORA BASADO EN ESTANDARIZACIÓN, REDISEÑO Y REALIMENTACIÓN DE PROCESOS...