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Á
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Á
3
Nota de Aceptación
Presidente del Jurado
Jurado
Jurado
4
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.
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
7
5.3 METODOLOGÍAS DE LAS EMPRESAS EN LA SITUACIÓN INICIAL. ... 53
5.4 METODOS DE VALIDACIÓN EN LA SITUACIÓN INICIAL. ... 54
5.5 ASEGURAMIENTO DE LA CALIDAD EN LA SITUACIÓN. ... 55
5.6 MODELOS EN LA SITUACIÓN INICIAL. ... 56
5.7 FACTORES INFLUYENTES EN LA CALIDAD EN LA SITUACIÓN INICIAL. ... 58
5.8 ANTECEDENTES EN LA SITUACIÓN INICIAL. ... 59
Antecedentes en ETB. ... 59
Antecedentes en TIGO. ... 60
5.8 MODELO DE LA SITUACIÓN INICIAL. ... 60
Descripción del modelo de la situación inicial. ... 60
Diagrama del modelo de la situación inicial. ... 62
6 MODELO PROPUESTO BASADO EN EL FUNDAMENTO TEÓRICO. ... 63
6.1 FUNCIÓN DEL INGENIERO INDUSTRIAL EN EL MODELO. ... 65
6.2 CARACTERÍSTICAS PROPIAS DEL TRABAJO CON DESARROLLO DE SOFTWARE EN EL MODELO. ... 66
6.3 METODOLOGÍAS DE LAS EMPRESAS EN EL MODELO. ... 68
6.4 MÉTODOS DE VALIDACIÓN EN EL MODELO. ... 70
6.5 ASEGURAMIENTO DE LA CALIDAD EN EL MODELO. ... 73
6.6 MODELOS EN EL MODELO. ... 76
6.7 FACTORES INFLUYENTES EN LA CALIDAD EN EL MODELO. ... 78
6.8 MODELO PROPUESTO. ... 80
Descripción del modelo... 80
Diagrama del modelo. ... 83
6.9 METODOLOGÍA DE LA EJECUCIÓN DEL MODELO PROPUESTO. ... 84
7. RESULTADOS. ... 88
8. DISEÑO DE LA RECOMENDACIÓN PROPUESTA. ... 91
8.1 FUNCIÓN DEL INGENIERO INDUSTRIAL EN LA RECOMENDACIÓN PROPUESTA. ... 92
8.2 LAS CARACTERÍSTICAS PROPIAS DEL TRABAJO CON DESARROLLO DE SOFTWARE EN LA RECOMENDACIÓN. ... 93
8
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
9
LISTA DE TABLAS
Tabla 1 Variables del agente herramientas tecnológicas. ... 38
Tabla 2 Casos de pruebba ETB ... 41
Tabla 3 inventario de casos de prueba de portales ... 41
Tabla 4 de seguimiento de pruebas de portales ETB. ... 41
Tabla 5 Seguimiento de defectos de casos de prueba de portales ETB ... 42
Tabla 6 Casos de prueba de Tigo Honduras ... 43
Tabla 7 Matriz de procesos con responsabilidad de TIGO-Honduras ... 43
Tabla 8 Matriz de seguimiento a empotrados ... 43
Tabla 9 Matriz de seguimiento a consultas virtuales ... 43
Tabla 10 Manuales para usuario final ... 44
Tabla 11 Cronograma ... 85
Tabla 12 Matriz de diseño de casos de prueba. ... 88
Tabla 13 Matriz consolidada de seguimiento de desarrollo. ... 89
Tabla 14 Matriz casos problema ... 89
Tabla 15 Medición de pruebas modelo inicial. ... 116
Tabla 16 Medición de pruebas modelo inicial. ... 117
Tabla 17 Medición de pruebas aplicado el modelo. ... 117
Tabla 18 Medición de pruebas modelo inicial. ... 118
Tabla 19 Cuadro comparativo entre modelos ... 119
Tabla 20 Cuadro comparativo entre modelos ... 120
Tabla 21 Cuadro comparativo entre modelos ... 122
Tabla 22 Cuadro comparativo entre modelos ... 123
Tabla 23 Cuadro comparativo entre modelos ... 125
Tabla 24 Cuadro comparativo entre modelos ... 127
10
LISTA DE GRÁFICAS
Ilustración 1Logo Fusion Partners S.A.S ... 16
Ilustración 2 Proceso experimental (Wohlin) ... 24
Ilustración 3 Investigación basada en casos de estudio. ... 25
Ilustración 4 esfuerzo Vs tiempo ... 26
Ilustración 5Factores que intervienen en la evaluación "dura" ... 29
Ilustración 6 Costo del desarrollo Vs Avance de la programación del desarrollo ... 33
Ilustración 7 Modelo en Espiral común propuesto por Boehm. ... 34
Ilustración 8 Relación entre Agentes... 47
Ilustración 9 Diagrama de flujo en los H.L.D ... 57
Ilustración 10 Proceso de pruebas de Software para el modelo inicia ... 61
Ilustración 11 Modelo de la situación inicial. ... 62
Ilustración 12 Proceso de pruebas de desarrollos de software para Entel modelo propuesto ... 82
Ilustración 13 Diagrama del modelo ... 83
Ilustración 14 Vista de los casos desde CLM. ... 90
Ilustración 15 Vista del ambiente ... 90
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.
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.
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.
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
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
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.
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
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
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
5PEÑA, Javier Parra. La ingeniería industrial en el contexto del desarrollo sostenible. Revista Tecnura, 1999, vol. 2, no 4, p. 28
6PARRA 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.
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. ()
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. ()
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
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.
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
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
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.
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.
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. ()
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
ágiles424344, 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.
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.
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 estricta5253
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.
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
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.
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.
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.
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.
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
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
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.
41
manera que sirva de influencia para considerar varias estrategias, documentos y procedimientos pueden llegar a ser un apalancamiento en las estrategias que se empiezan a crear desde cero. Por medio de un integrante del equipo que participó del proyecto en ETB se consulta información, estrategias y documentos de la experiencia obtenida en el proyecto.
Alguno de los formatos con información previamente seleccionada que podemos encontrar en el proyecto de implementación de ETB son los siguientes:
Tabla 2 Casos de pruebba ETB
Fuente tabla 2 Creación empresa Fusion Partners S.A.S
Tabla 3 inventario de casos de prueba de portales
Fuente tabla 3 Creación empresa Fusion Partners S.A.S
Tabla 4 de seguimiento de pruebas de portales ETB.
42
Tabla 5 Seguimiento de defectos de casos de prueba de portales ETB
Fuente tabla 5 Creación empresa Fusion Partners S.A.S
Antecedentes en TIGO de Honduras.
En el proyecto elaborado para Tigo en Honduras se hacía el diseño de los casos de pruebas sobre un formato prediseñado que señalaba los datos del diseñador de la matriz, los componentes, las funciones, los pasos, los resultados esperados y obtenidos.
Para cada caso de prueba se diseñaba la matriz y las hojas siguientes del documento contenían las evidencias subrayadas, enmarcadas y con los comentarios respecto de las observaciones requeridas en cada caso; además se tenía una matriz para los casos de empotrados con características muy específicas, una matriz de procesos con responsabilidad y una matriz de estado de cada matriz de casos. Durante la ejecución también debía hacerse la actualización del manual y la comparación de 2 ambientes TERRAMARK y QA para la verificación de resultados de la pruebas. Debido a la aplicación de formato para cada caso, la permanente actualización de la manuales y la toma de pantallas paso a paso resaltadas y comentadas, hacen del proceso de prueba de cada caso, un proceso agotador demorado y totalmente normalizado y estandarizado. Dos personas del equipo estuvieron integradas y las metodologías procedimentales tenían una complejidad muy semejante por lo que tenían algunas guías.
43 Tabla 6 Casos de prueba de Tigo Honduras
Fuente tabla 6 Creación empresa Fusion Partners S.A.S
Tabla 7 Matriz de procesos con responsabilidad de TIGO-Honduras
Fuente tabla 7Creación empresa Fusion Partners S.A.S
Tabla 8 Matriz de seguimiento a empotrados
Fuente tabla 8Creación empresa Fusion Partners S.A.S
Tabla 9 Matriz de seguimiento a consultas virtuales
44 Tabla 10 Manuales para usuario final
