Proceso ágil para la gestión de la

configuración de software en micro,

pequeñas y medianas empresas de software

Trabajo de Grado

Carlos Eduardo Orozco Garcés

Juan Sebastián Vásquez Cantero

Director: PhD. César Jesús Pardo Calvache1

Codirector: PhD. Francisco José Pino Correa2

Universidad del Cauca

Facultad de Ingeniería Electrónica y Telecomunicaciones
Departamento de Sistemas
1
Grupo de I+D en Tecnologías de la información (GTI)
2
Grupo de I+D en Ingeniería de Software (IDIS)
Popayán, noviembre de 2017
 Proceso ágil para la gestión de la
configuración de software en micro,
pequeñas y medianas empresas de software

Trabajo de Grado

Carlos Eduardo Orozco Garcés

Juan Sebastián Vásquez Cantero

Director: PhD. César Jesús Pardo Calvache1

Codirector: PhD. Francisco José Pino Correa2

Universidad del Cauca

Facultad de Ingeniería Electrónica y Telecomunicaciones
Departamento de Sistemas
1
Grupo de I+D en Tecnologías de la información (GTI)
2
Grupo de I+D en Ingeniería de Software (IDIS)
Popayán, noviembre de 2017
Agradecimientos.
El trabajo que se llevó a cabo durante los últimos dos años no fue un esfuerzo
individual, muchas personas participaron de manera directa o indirecta en este
proyecto y quiero agradecer a todas esas personas.

Inicialmente quiero agradecer a nuestro codirector Francisco Pino por darnos la

oportunidad de iniciar con este proyecto y por su constante apoyo e interés durante
todo el proceso. A nuestro director César Pardo por aceptarnos como tesistas, por
dedicar de manera activa e incondicional su tiempo, experiencia y conocimientos en el
área con el único objetivo de lograr que hiciéramos el mejor trabajo posible. Los dos
han sido un modelo por seguir que nos han permitido mejorar académica y
profesionalmente, y que nos han permitido realizar la mejor versión posible de este
proyecto.

A mi familia: por ser el soporte que me ha permitido continuar durante toda la carrera,
por su apoyo incondicional y por la paciencia que han tenido durante todos estos años.
A mi madre por ser el pilar que me ha enseñado que el estudio es el regalo más
importante que una persona puede recibir, a mis hermanos por apoyarme durante todo
el proceso, y especialmente a mi hermano Edward Orozco por ser la persona que me
ha permitido llegar hasta este punto. Sin su apoyo seguramente no habría logrado
culminar este trabajo (ni esta carrera).

A mi compañero de tesis Sebastián Vásquez, por su excelente trabajo y por su

constante apoyo durante la realización y revisión de todos los artefactos r elacionados
al proyecto.

A todos los profesores que hicieron parte durante los últimos cinco años de carrera y
nos enseñaron las bases y los conocimientos necesarios para desempeñar un
excelente trabajo fuera de la universidad. Además, quiero agradecer de manera
especial a los ingenieros Wilson Libardo Pantoja, Wilson Alfredo Ortega, Sandra
Lorena Buitrón y Daniel Eduardo Paz por participar en la evaluación de la propuesta y
por su valiosa realimentación durante la sesión de debate, lo cual permitió crear una
propuesta mucho más sólida.

A mis compañeros de trabajo por permitirme hacer parte de su equipo y por su

constante apoyo y colaboración durante todo el proceso. Agradezco por el último año y
medio en el cual he aprendido muchas cosas de cada uno de ellos, por brindarme su
conocimiento y experiencia sin los cuales no hubiera logrado definir aspectos críticos
de este proyecto. Además, quiero agradecer especialmente a los ingenieros Víctor
Carvajal, María Amparo Hormiga, José Milciades Ordoñez Argote, Francisco Ramírez,
Julián Andrés Zúñiga y Laura Pérez por expresar su interés en participar en la
evaluación de la propuesta y por su valiosa realimentación durante la sesión de
debate, lo cual permitió crear una propuesta mucho más sólida.

Finalmente, quiero agradecer a Isabel Lozano por su apoyo incondicional, por ser una
parte fundamental de mi proceso de aprendizaje durante los últimos diez años, por su
constante interés en este proceso, por acompañarme en este viaje durante los últimos
tres años y por ser la razón que me inspira cada día a ser un mejor profesional y una
mejor persona. Este trabajo y todos mis proyectos futuros son dedicados a ella.

Carlos Eduardo Orozco, Popayán, Cauca.

Octubre de 2017.
Es importante reconocer el acompañamiento recibido en cada uno de los pasos dados
durante el desarrollo de este proceso educativo que finaliza con la realización de este
trabajo de grado. Son muchos los motivos por los que quisiera agradecer, y muchas
las personas a quienes quisiera reconocer la valiosa colaboración brindada, sin su
apoyo incondicional no hubiera sido posible llevar a cabo todo lo propuesto.

En primer lugar, quiero agradecer a mi familia, mi gran soporte: por su constante

apoyo y acompañamiento durante este proceso, realmente han sido fund amentales
para alcanzar todas las metas propuestas. En especial, quiero agradecer a mi padre,
por su perseverancia, interés e incansables esfuerzos realizados para brindarme todo
lo necesario y así culminar exitosamente esta carrera; quiero dedicar y agradecer
especialmente este triunfo a él. De igual manera quiero agradecer a mi madre, pilar
fundamental para mi crecimiento como persona y gran modelo a seguir. A mis amados
hermanos, sus consejos, experiencias compartidas e incondicional apoyo han
representado el motor que me ha impulsado durante todos estos años.

A mis docentes: a nuestro director, ingeniero César Pardo, por su valiosa guía durante
la realización de este trabajo, su profesionalismo, sabiduría, compromiso y total
disposición fueron fundamentales para la exitosa culminación de este proceso.
Asimismo, a nuestro codirector, ingeniero Francisco Pino, por su guía y motivación en
momentos difíciles del proyecto, su apoyo representó una base sólida para la
realización de este trabajo. A todos y cada uno de los docentes que compartieron
conmigo su conocimiento, experiencia y sabiduría durante estos años del desarrollo de
mi carrera. Igualmente agradezco a los docentes que nos apoyaron en la validación de
nuestro trabajo; sus apreciaciones fueron muy importantes para construir una
propuesta más sólida y acorde a los objetivos trazados.

A mi compañero de tesis, Carlos Orozco, por su dedicación, su compromiso y su

responsabilidad en la realización de nuestro trabajo. Fue un excelente compañero y
agradezco la oportunidad que me brindó al trabajar hombro a hombro a su lado en la
consecución de este triunfo compartido.

A todas aquellas personas que, directa o indirectamente, participaron en este proceso,

a quienes se encuentran cerca o lejos y siempre me brindaron su apoyo, a quienes, en
muy poco tiempo, hicieron mucho, a quien sigue presente y a quien ya no está, a todo
aquel que aportó durante este largo camino: ¡gracias, sin ustedes no todo hubiera sido
posible!

Finalmente, quiero agradecer a la Universidad del Cauca, alma mater a la cual me

enorgullece pertenecer. Sé que no pude haber escogido una mejor institución para
poner en sus aulas la calidad de mi educación.

A todos ellos, este triunfo y los frutos que de él provengan.

Sebastián Vásquez, Popayán, Cauca.

Octubre de 2017.
Tabla de contenido.
Capítulo I. Introducción. ...........................................................................................................................................1
1.1 Problemática y justificación............................................................................................................................ 1
1.2 Objetivos. ..................................................................................................................................................... 3
1.2.1 Objetivo general.................................................................................................................................... 3
1.2.2 Objetivos específicos............................................................................................................................. 3
1.3 Estrategia de la investigación. ....................................................................................................................... 3
1.4 Estructura del documento. ............................................................................................................................. 4
Capítulo II. Marco teórico y estado del arte................................................................................................................6
2.1 Marco teórico................................................................................................................................................ 6
2.1.1 Proceso de desarrollo de software. ........................................................................................................ 6
2.1.2 Importancia de la gestión de la configuración en el proceso de desarrollo de software............................... 6
2.1.3 Modelos propuestos. ............................................................................................................................. 7
2.1.3.1 CMMI-DEV v1.3. ........................................................................................................................... 7
2.1.3.2 IEEE 828-2012.............................................................................................................................. 8
2.1.3.3 ISO/IEC 15504. ............................................................................................................................. 9
2.1.3.4 ISO/IEC 29110. ........................................................................................................................... 10
2.2 Revisión sistemática de la literatura. ............................................................................................................ 10
2.2.1 Enfoque de la pregunta. ...................................................................................................................... 11
2.2.2 Pregunta de la investigación. ............................................................................................................... 11
2.2.3 Planeación de la revisión sistemática de la literatura . ............................................................................ 11
2.2.4 Resultados de la revisión sistemática de la literatura. ............................................................................ 12
2.2.4.1 Estudios relacionados que involucran modelos.............................................................................. 13
2.2.4.2 Estudios relacionados con enfoques ágiles. .................................................................................. 14
2.2.4.3 Estudios relacionados que relacionan otros procesos. ................................................................... 16
2.3 Aportes. ..................................................................................................................................................... 16
Capítulo III. Armonización de modelos para la gestión de la configuración. ...............................................................18
3.1 Análisis de modelos. ................................................................................................................................... 18
3.1.1 Proceso para llevar a cabo la armonización de múltiples modelos. ......................................................... 18
3.1.1.1 Método para llevar a cabo la homogeneización de modelos. .......................................................... 18
3.1.1.1.1 Adquisición de conocimiento concerniente a los modelos involucrados. .................................. 19
3.1.1.1.2 Análisis estructural y terminología......................................................................................... 19
3.1.1.1.3 Identificación de los requerimientos. ..................................................................................... 20
3.1.1.1.4 Análisis de resultados. ......................................................................................................... 21
3.1.2 Método para llevar a cabo la comparación de modelos. ......................................................................... 25
3.1.2.1 Diseñar la comparación. .............................................................................................................. 25
3.1.2.2 Llevar a cabo la comparación....................................................................................................... 26
3.1.2.2.1 ISO/IEC 15504 vs CMMI-DEV.............................................................................................. 27
3.1.2.2.2 ISO/IEC 15504 vs IEEE 828-2012. ....................................................................................... 28
3.1.2.2.3 ISO/IEC 15504 vs el paquete de implementación de SCM basado en la norma ISO/IEC 29110.
........................................................................................................................................................ 30
3.1.2.2.4 ISO/IEC 15504 vs propuestas que involucran elementos ágiles. ............................................. 31
3.1.2.3 Análisis de correspondencia entre modelos................................................................................... 33
3.1.3 Método para la llevar a cabo la integración de modelos. ........................................................................ 35
3.1.3.1 Diseñar la integración. ................................................................................................................. 36
3.1.3.2 Establecer los criterios de integración. .......................................................................................... 36
3.1.3.3 Llevar a cabo la integración.......................................................................................................... 36
3.1.3.4 Análisis de resultados. ................................................................................................................. 38
3.2 Sesgos de la armonización de los modelos analizados.................................................................................. 39
Capítulo IV. SCMOnto: Ontología para soportar la gestión de la confi guración de software. .......................................40
4.1 Motivación para la definición de SCMOnto............................................................................................... 40
4.2 Diseño y propuesta de la ontología. ........................................................................................................ 41
4.2.1 Metodología empleada para la definición de la ontología. ................................................................. 41
4.2.2 Presentación de la propuesta.......................................................................................................... 42
4.2.3 Discusión....................................................................................................................................... 49
4.3 Validación teórica de la ontología............................................................................................................ 49
4.4 Ejemplo de aplicación de la ontología...................................................................................................... 51
Capítulo V. Progresconfig. .....................................................................................................................................52
5.1 Definición del proceso. ........................................................................................................................... 52
5.1.1 Alcance del proceso. ...................................................................................................................... 52
5.1.2 Plantilla para la definición de proceso. ............................................................................................. 52
5.1.3 Términos genéricos........................................................................................................................ 53
5.1.4 Definición de roles.......................................................................................................................... 54
5.1.4.1 Identificación de roles. ............................................................................................................ 54
5.1.4.2 División de roles por tipo de empresa. ..................................................................................... 55
5.1.5 Definición de niveles de capacidad para Progresconfig..................................................................... 56
5.1.6 Visión general de la propuesta. ....................................................................................................... 57
5.1.7 Caracterización del proceso para la gestión de la configuración de software. ..................................... 59
5.2 Análisis del grado de agilidad del proceso. .............................................................................................. 91
5.2.1 Análisis de alcance del proceso. ..................................................................................................... 91
 5.2.2 Análisis de grado de agilidad del proceso. ....................................................................................... 92
5.2.3 Análisis de caracterización de valores ágiles.................................................................................... 93
5.2.4 Análisis de caracterización del proceso de software. ........................................................................ 94
Capítulo VI. Evaluación de la propuesta. .................................................................................................................96
6.1 Grupo Focal........................................................................................................................................... 96
6.2 Estructura teórica del método. ................................................................................................................ 96
6.3 Realización del grupo focal..................................................................................................................... 96
6.3.1 Planeación de la investigación. ....................................................................................................... 97
6.3.1.1 Definición del problema de investigación.................................................................................. 97
6.3.1.2 Preparación del material utilizado en la aplicación del grupo focal. ............................................ 97
6.3.1.2.1 Fase de definición del protocolo. ..................................................................................... 97
6.3.1.2.2 Definición de elementos empleados para llevar a cabo el grupo focal. ............................... 98
6.3.1.2.3 Fase de definición de elementos empleados para llevar a cabo el grupo focal. ................... 98
6.3.1.2.4 Definición de métodos de análisis de información derivado del grupo focal......................... 98
6.3.1.3 Fase de definición de grupos de discusión. .............................................................................. 98
6.3.1.3.1 Método de selección de participantes. ............................................................................. 98
6.3.1.4 Fase de conducción de la sesión de debate. .......................................................................... 101
6.3.1.4.1 Conducción de la sesión de debate. .............................................................................. 101
6.3.1.4.2 Captura de información. ................................................................................................ 102
6.3.1.5 Fase de análisis de información obtenida y reporte de resultados. ........................................... 103
6.3.1.5.1 Análisis de información. ................................................................................................ 103
6.3.1.5.2 Reporte de resultados................................................................................................... 103
6.4 Sesgos de la evaluación....................................................................................................................... 115
Capítulo VII. Conclusiones y lecciones aprendidas. ...............................................................................................116
7.1 Análisis de los objetivos de investigación............................................................................................... 116
7.2 Conclusiones. ...................................................................................................................................... 117
7.3 Lecciones aprendidas. ......................................................................................................................... 118
7.4 Vías de trabajo futuro........................................................................................................................... 119
7.5 Contribuciones en el área de la ingeniería de software. .......................................................................... 120
7.5.1 Contribución en la divulgación de conocimiento. ............................................................................ 120
7.5.2 Contribuciones de la investigación ................................................................................................ 120
Bibliografía..........................................................................................................................................................122
Anexos. ..............................................................................................................................................................125
Anexo 1: Agenda para la sesión de debate aplicado a Progresconfig............................................................ 125
Anexo 2: Cuestionario aplicado a los participantes del grupo focal................................................................ 126
Anexo 3: Ficha de Asistencia del grupo focal............................................................................................... 148
Anexo 4: Protocolo para llevar a cabo el grupo focal.................................................................................... 159
Anexo 5: Caracterización del proceso evaluado durante los grupos focales................................................... 161

Índice de tablas.
Tabla 1. Niveles de capacidad definidos en CMMI-DEV............................................................................................. 8
Tabla 2. Niveles de madurez definidos por CMMI-DEV. ............................................................................................. 8
Tabla 3. Palabras clave y sinónimos. ...................................................................................................................... 11
Tabla 4. Cadenas de búsqueda básicas.................................................................................................................. 12
Tabla 5. Clasificación por cantidad de publicaciones anuales. .................................................................................. 12
Tabla 6. Categorización de estudios por modelos, estándares o metodologías utilizadas para soportar o apoyar SCM.12
Tabla 7. Clasificación del tamaño de las empresas según el número de empleados. ................................................. 13
Tabla 8. Actividades propuestas en [33]. ................................................................................................................. 15
Tabla 9. Actividades propuestas en [34]. ................................................................................................................. 15
Tabla 10. Cuadro comparativo a alto nivel de atributos asociados a cada modelo...................................................... 19
Tabla 11. Plantilla utilizada para la comparación de elementos de proceso a alto nivel. Tomado y traducido de [38]. ... 20
Tabla 12. Comparación de modelos a alto nivel utilizando CSPE.............................................................................. 21
Tabla 13. Actividades asociadas a CMMI-DEV........................................................................................................ 22
Tabla 14. Actividades asociadas a IEEE 828-2012. ................................................................................................. 23
Tabla 15. Actividades asociadas a ISO/IEC 15504. ................................................................................................. 23
Tabla 16. Actividades asociadas a ISO/IEC 29110. ................................................................................................. 23
Tabla 17. Salidas asociadas a ISO/IEC 15504......................................................................................................... 23
Tabla 18. Salidas asociadas a IEEE 828-2012. ....................................................................................................... 24
Tabla 19. Ítems de configuración definidos por cada modelo. ................................................................................... 25
Tabla 20. Tabla de comparación entre modelos. Tomado de [41]. ............................................................................ 26
Tabla 21. Plantilla de comparación entre modelos. Tomado de [44]. ......................................................................... 26
Tabla 22. Comparación de actividades entre la norma ISO/IEC 15504 y CMMI -DEV. ................................................ 27
Tabla 23. Comparación de actividades entre la norma ISO/IEC 15504 y la IEEE 828-2012........................................ 29
Tabla 24. Comparación de actividades entre la norma ISO/IEC 15504 y la ISO/IEC 29110 propuesta en [25]. ............ 30
Tabla 25. Comparación de actividades entre la norma ISO/IEC 15504 y las actividades propuestas en [33]. ............... 31
Tabla 26. Comparación de actividades entre la norma ISO/IEC 15504 y las actividades propuestas en [34]. ............... 32
Tabla 27. Correspondencia entre actividades definidas en la norma ISO/IEC 15504 contra todos los modelos. ........... 34
Tabla 28. Escala de relación entre modelos. Adaptado de [44]. ................................................................................ 34
Tabla 29. Relación cuantitativa entre m odelos......................................................................................................... 35
Tabla 30. Relación cualitativa entre modelos........................................................................................................... 35
Tabla 31. Plantilla de términos de integración. Tomado de [41]................................................................................. 36
Tabla 32. Plantilla de aspectos para escribir una práctica unificada. Tomado de [41]. ................................................ 36
Tabla 33. Plantilla de unificación de prácticas entre modelos. Adaptado de [41]. ....................................................... 37
Tabla 34. Actividades integradas. ........................................................................................................................... 38
Tabla 35. Cantidad de actividades integradas.......................................................................................................... 38
Tabla 36. Especificación de requerimientos de SCMOnto. ....................................................................................... 42
Tabla 37. Fuentes utilizadas para la definición de SCMOnto. ................................................................................... 42
Tabla 38. Conceptos utilizados en SCMOnto........................................................................................................... 46
Tabla 39. Términos extraídos de [55]. ..................................................................................................................... 46
Tabla 40. Términos extraídos de [43]. ..................................................................................................................... 46
Tabla 41. Relaciones utilizadas en SCMOnto. ......................................................................................................... 47
Tabla 42. Plantilla para la definición del proceso. Adaptado de [42]. ......................................................................... 53
Tabla 43. Términos genéricos. ............................................................................................................................... 53
Tabla 44. Acrónimos. ............................................................................................................................................. 53
Tabla 45. Identificación de roles. ............................................................................................................................ 54
Tabla 46. Roles propuestos que participan de manera directa en el proceso. ............................................................ 55
Tabla 47. Roles propuestos que participan de manera indirecta en el proceso. ......................................................... 55
Tabla 48. Roles definidos para una empresa grande o mediana. .............................................................................. 55
Tabla 49. Roles definidos para una empresa pequeña. ............................................................................................ 55
Tabla 50. Roles definidos para una microempresa................................................................................................... 56
Tabla 51. Progresconfig. ........................................................................................................................................ 90
Tabla 52. Descripción de la primera dimensión para la evaluación de agilidad. Tomado de [61]. ................................ 91
Tabla 53. Evaluación de la primera dimensión aplicado a Progresconfig. .................................................................. 92
Tabla 54. Plantilla utilizada para la evaluación de la segunda dimensión. Tomado de [61].......................................... 93
Tabla 55. Evaluación de la segunda dimensión aplicada a Progresconfig.................................................................. 93
Tabla 56. Descripción de la tercera dimensión para la evaluación de agilidad. Tomado de [61]. ................................. 94
Tabla 57. Evaluación de la tercera dimensión aplicada a Progresconfig. ................................................................... 94
Tabla 58. Plantilla utilizada para la evaluación de la cuarta dimensión. Tomado de [61]. ............................................ 95
Tabla 59. Evaluación de la cuarta dimensión aplicada a Progresconfig. .................................................................... 95
Tabla 60. Elementos del protocolo para llevar a cabo el grupo focal. ........................................................................ 97
Tabla 61. Elementos definidos para llevar a cabo el grupo focal. .............................................................................. 98
Tabla 62. Perfil de los participantes que asistieron al grupo focal llevado a cabo en la Universidad del Cauca........... 100
Tabla 63. Perfil de los participantes que asistieron al grupo focal llevado a cabo en LA EMPRESA. ......................... 101
Tabla 64. Protocolo llevado a cabo para realizar el grupo focal............................................................................... 101
Tabla 65. Aspectos de mejora dentro del alcance del proyecto. .............................................................................. 104
Tabla 66. Aspectos de mejora fuera del alcance del proyecto................................................................................. 104
Tabla 67. Transcripción de observaciones realizadas a la primera pregunta............................................................ 106
Tabla 68. Transcripción de observaciones realizadas a la cuarta pregunta.............................................................. 108
Tabla 69. Transcripción de observaciones realizadas a la quinta pregunta. ............................................................. 108
Tabla 70. Transcripción de observaciones realizadas a la sexta pregunta. .............................................................. 109
Tabla 71. Transcripción de observaciones realizadas a la séptima pregunta. .......................................................... 110
Tabla 72. Transcripción de observaciones realizadas a la octava pregunta. ............................................................ 111
Tabla 73. Transcripción de observaciones realizadas a la novena pregunta. ........................................................... 111
Tabla 74. Transcripción de observaciones realizadas a la décima pregunta. ........................................................... 112
Tabla 75. Comparación entre la propuesta evaluada en los grupos focales y la versión refinada del proceso. ........... 114
Tabla 76. Resumen de artículos escritos durante el desarrollo del proyecto. ........................................................... 120
Tabla 77. Agenda de trabajo utilizada para la sesión realizada en la Universidad del Cauca. ................................... 125
Tabla 78. Agenda de trabajo utilizada para la sesión realizada en LA EMPRESA. ................................................... 125
Tabla 79. Protocolo definido para la sesión realizada en la Universidad del Cauca. ................................................. 159
Tabla 80. Protocolo definido para la sesión realizada en LA EMPRESA. ................................................................. 160
Tabla 81 . Progresconfig versión 1.0. .................................................................................................................... 177

Índice de figuras.
Figura 1. Representación gráfica mediante diagramas UML de los conceptos y relaciones de SCMOnto. ................... 48
Figura 2. Segmento extraído de la instancia de SCMOnto utilizando Protégé. ........................................................... 50
Figura 3. Niveles de capacidad propuestos. ............................................................................................................ 56
Figura 4. Descripción del problema......................................................................................................................... 57
Figura 5. Visión general de la propuesta. ................................................................................................................ 58
Figura 6. Sesión de debate llevada a cabo en la Universidad del Cauca. ................................................................ 102
Figura 7. Sesión de debate llevada a cabo en LA EMPRESA. ................................................................................ 102
Figura 8. Cantidad de participantes que respondieron cada opción de cada pregunta. ............................................. 105
Figura 9. Tendencia de los resultados de la primera pregunta. ............................................................................... 105
Figura 10. Tendencia de los resultados de la segunda pregunta............................................................................. 106
Figura 11. Tendencia de los resultados de la tercera pregunta. .............................................................................. 107
Figura 12. Tendencia de los resultados de la cuarta pregunta. ............................................................................... 107
Figura 13. Tendencia de los resultados de la quinta pregunta................................................................................. 108
Figura 14. Tendencia de los resultados de la sexta pregunta.................................................................................. 109
Figura 15. Tendencia de los resultados de la séptima pregunta. ............................................................................. 110
Figura 16. Tendencia de los resultados de la octava pregunta................................................................................ 110
Figura 17. Tendencia de los resultados de la novena pregunta............................................................................... 111
Figura 18. Tendencia de los resultados de la décima pregunta. .............................................................................. 112
Capítulo I. Introducción.
Este capítulo presenta una descripción detallada sobre la motivación de este trabajo
de investigación, los objetivos definidos, la estrategia utilizada para realizar la
investigación y la descripción de la solución propuesta. Finalmente, se presenta la
estructura del documento en el cual se describe el contenido de cada capítulo a alto
nivel.

1.1 Problemática y justificación.

Actualmente, las micro, pequeñas y medianas empresas (en adelante MiPyMEs)
lideran la infraestructura industrial y comercial en la gran mayoría de países, incluso,
distintos expertos economistas han observado que la salud y crecimiento comercial de
la economía mundial depende principalmente del desempeño y actividades
económicas que este tipo de empresas realizan [1]. Asimismo, las MiPyMEs
desarrolladoras de software (en adelante MiPyMEs_DS) son el grupo de empresas
más importante a nivel internacional, incluso algunos países basan su crecimiento
económico en la producción de software, un ejemplo de estos países son: India e
Irlanda [2], [3]. Particularmente, en el ámbito nacional, el informe de caracterización de
los sectores relacionados a la: Teleinformática, Software y Tecnologías de la
Información realizado en el año 2015, muestra que, en Colombia, de un total de 4016
empresas encuestadas, un 87,72% son MiPyMEs, un 3,38% pertenecen a la categoría
de grandes empresas y el 8,88% restante no presentan información con respecto al
tipo de empresa involucrado en el estudio. Con lo anterior, se observa una tendencia
significativa hacia la preponderancia de las MiPyMEs en comparación con el número
de las grandes empresas [4].

Según [5], las MiPyMEs se enfrentan a distintos retos en virtud de su tamaño y

características particulares, de los cuales se pueden destacar la: (i) escasez y acceso
restringido a fuentes de financiamiento, (ii) poca disponibilidad de recursos humanos,
(iii) niveles limitados de capacitación y desarrollo tecnológico, entre otros. A causa de
lo anterior, las MiPyMEs tienen una capacidad limitada para la implementación de
proyectos de mejora y adopción de procesos de desarrollo [6]. En consecuencia, es
posible encontrar que las MiPyMEs presentan procesos caóticos, y que en su mayoría
son definidos de manera informal [6].

En particular, las MiPyMEs_DS se enfrentan a retos específicos dada la naturaleza

compleja del software y el alto nivel de incertidumbre en los proyectos que llevan a
cabo, por lo cual, se hace necesario establecer modelos que faciliten las actividades
relacionadas a la gestión de los cambios y los artefactos involucrados durante el
proceso de desarrollo, así como: especificación de requerimientos, documentación de
las actividades relacionadas al análisis y diseño, gestión de la configuración del código
fuente, gestión de las pruebas de software, gestión en el despliegue del producto,
gestión de los cambios derivados del mantenimiento, entre otros [7]. Para esto, se
hace necesaria la adopción de mejores prácticas que faciliten la gestión de la
configuración en los proyectos software. La gestión de la configuración (en adelante
CM1) que se puede definir como: el control de la evolución de sistemas complejos [7],
nació originalmente para llevar a cabo el control de los cambios en procesos
relacionados con la manufactura de hardware y el área industrial [8]. En particular, el
auge de la industria del software trajo consigo una adaptación de la gestión de la
configuración, conocida actualmente como gestión de la configuración de software

1
Gestión de la configuración del nombre original en inglés, Configuration Management.

1
(SCM2) la cual es posible definir como: el proceso cuyo objetivo es la identificación de
la configuración del software en un punto discreto del tiempo, y el control sistemático
de los cambios de la configuración identificados con el propósito de mantener la
integridad y trazabilidad durante el ciclo de vida del software [9].
Para producir y mantener software de alta calidad, a bajo costo y de forma efectiva,
son fundamentales los procesos utilizados en su desarrollo, entre los que se encuentra
el control de los cambios para mantener la integridad del producto, para esto, SCM
actúa como el esqueleto que lo hace posible. Por lo tanto, aplicar SCM permite
mantener la trazabilidad del código fuente, documentación, problemas, cambios
solicitados y cambios que se han realizado sobre el producto [7].

Según [10], actualmente las empresas desarrolladoras de software se enfrentan a

diferentes desafíos funcionales relacionados con SCM, entre ellos: control de
versiones, control de la configuración para modelos de datos complejos, gestión de
repositorios y áreas de trabajo (workspace) en entornos distribuidos, gestión de la
configuración para proyectos web, desarrollo en paralelo [11], entre otros. Además, es
posible mencionar problemas no funcionales entre los que se encuentran: lograr una
mayor escalabilidad, disponibilidad y eficiencia [10]. Debido a esto, se han definido
diferentes modelos para dar soporte al proceso de SCM, entre los más conocidos y
utilizados se destacan: IEEE3 828-2012 [12], CMMI-DEV [13], ISO4 10007:2003 [14] e
ISO/IEC 5 15504 [15], modelos que han sido pensados para dar soporte a grandes
empresas y con características diferentes a las de las MiPyMEs_DS, donde la
aplicación de estos modelos requeriría una gran: inversión económica, esfuerzo,
tiempo y recursos, aspectos que como se mencionó anteriormente, son limitado s en
este tipo de empresas [5]. Asimismo, debido al creciente interés en las MiPyMEs_DS,
se ha definido la norma ISO/IEC 29110 [16], la cual menciona la importancia de
facilitar y soportar CM en MiPyMEs_DS, sin embargo, no define de manera detallada
cómo soportar esta área, actualmente la norma sólo describe procesos para un perfil
básico, en el cual es posible encontrar un paquete de implementación que menciona
CM en un alto nivel de abstracción, y no existe hasta ahora un conjunto de mejores
prácticas que permitan establecer los lineamientos para definir un proceso de manera
formal.

La carencia de un perfil completo que pueda ser adoptado por MiPyMEs_DS, trae
como consecuencia una fuerte tendencia hacia el uso incompleto e informal de SCM a
través del uso de herramientas para solucionar problemas específicos como el control
de versiones y la integración continua, y aunque es claro que el propósito de las
herramientas para SCM es facilitar la gestión, coordinación, intercambio y cambios en
los artefactos software [17], se debe tener en cuenta que SCM es una de las
capacidades fundamentales que debería tener lugar en cualquier pr oyecto de
desarrollo de software [11], por lo tanto, no debería ser limitado solo al uso de
herramientas, que en muchos casos no proveen el control total sobre su configuración.

Por otra parte, en la última década se ha identificado una fuerte y creciente tendencia
hacia la adopción de metodologías ágiles en los proyectos que llevan a cabo las
MiPyMEs_DS, esto debido a dos razones principales: (i) fracaso con marcos
tradicionales debido al bajo porcentaje de éxito en los proyectos desarrollados con

2
Gestión de la configuración de softw are del nombre en inglés, Softw are Configuration Management.
3
Instituto de Ingeniería Eléctrica y Electrónica del nombre original en inglés, Institute of Electrical and
Electronics Engineers, conocida por las siglas IEEE.
4
Organización Internacional de Normalización del nombre original en inglés, International Organization for
Standardization, conocida por las siglas ISO.
5
Comisión Electrotécnica Internacional del nombre original en inglés, International Electrotechnical
Commission.

2
base en metodologías tradicionales (o plan-drive methods) [17], (ii) la versatilidad y
beneficios que las metodologías ágiles proporcionan a los equipos de trabajo, y las
que principalmente se centran en la mejora de: la productividad, calidad, alineación
entre cliente y equipo, resultados anticipados (time to market), rápido retorno de la
inversión (return on investment - ROI), flexibilidad y adaptación a los cambios, entre
otros.
Las empresas, independientemente de su tamaño, se enfrentan a diferentes retos
comunes basados en diferentes características, tales como: su capacidad, nivel de
madurez, tamaño y poder adquisitivo, por lo cual se hace pertinente la necesidad de
plantear si SCM se puede aplicar de manera exitosa en MiPyMEs_DS. En este
sentido, es necesario definir un proceso de SCM compacto, con conceptos claros y de
fácil implementación en MiPyMEs_DS con un enfoque ágil, y que cumpla con
características específicas como: (i) fácil implementación, (ii) bajo coste tanto en
recursos como en tiempo, (iii) poca carga documental, (iv) definiciones claras, (v)
adaptación al cambio en la industria y (vi) escalabilidad.

Teniendo en cuenta lo anterior, en este proyecto se presenta un proceso ágil para la

gestión de la configuración de software que pueda ser adoptado por micro, pequeñas y
medianas empresas desarrolladoras de software mediante un conjunto de
definiciones, actividades, tareas, roles, productos de trabajo y salidas. Además, el
proceso presentado es definido a través de un modelo de capacidad con el objetivo de
apoyar a las empresas para que adopten el proceso de manera gradual de acuerdo
con sus características y necesidades específicas.

1.2 Objetivos.
1.2.1 Objetivo general.
Definir un proceso ágil para la gestión de la configuración de software adaptado a las
características y necesidades de MiPyMEs, el cual proporcione una definición clara
que apoye la implantación de las prácticas de gestión de la configuración en el
proceso de desarrollo de software en las MiPyMEs_DS.

1.2.2 Objetivos específicos.

OE1. Llevar a cabo una revisión bibliográfica detallada en el área de gestión de la
configuración de software que permita identificar las iniciativas, soluciones, trabajos
relacionados y herramientas utilizadas para soportar la gestión de la configuración de
software.
OE2. Definir un proceso ágil para la gestión de la configuración de software que
describa un conjunto de actividades, tareas y roles que facilite el trabajo en este tipo
de entornos.
OE3. Evaluar el proceso propuesto a través de su aplicación en un grupo focal (focus
group) como técnica cualitativa de estudio.

1.3 Estrategia de la investigación.

Para llevar a cabo la ejecución del proyecto propuesto, se utilizó el método
Investigación-Acción con múltiples ciclos de forma lineal [18]. La evaluación de la
propuesta fue llevada a cabo a través de un grupo focal (focus group) [19], [20].
Teniendo en cuenta las fases y actividades propuestas por esta metodología, para el
desarrollo de esta propuesta se llevaron a cabo 4 ciclos de investigación, a
continuación, se describen los ciclos y las actividades que se llevaron a cabo de
manera secuencial e incremental para el desarrollo del proyecto.

3
  Ciclo 1. Análisis conceptual: En esta fase se llevó a cabo la investigación
acerca del estado actual del arte acerca de la gestión de la configuración de
software, esto, con el objetivo de poder identificar, estudiar, entender y
comparar las iniciativas, problemáticas, soluciones y trabajos relacionados en
el área. Asimismo, la realización de esta fase permitió identificar y estudiar las
propuestas y soluciones existentes y los elementos sensibles a tener en cuenta
para la definición de la solución.
o Actividad 1.1: Revisión del estado del arte sobre SCM.
o Actividad 1.2: Profundización: Estudio de las características, similitudes
y diferencias en las soluciones hasta ahora propuestas para SCM.
 Ciclo 2. Elaboración de la propuesta: En esta fase se llevó a cabo la
definición del proceso para la gestión de la configuración de software bajo un
enfoque ágil para MiPyMEs.
o Actividad 2.1: Análisis de la información: Se realizó un análisis de los
artefactos, actividades, roles y prácticas para SCM definidos por IEEE
828-2012 [12], CMMI-DEV [13], ISO 10007:2003 [14], ISO/IEC 15504
[15] e ISO/IEC 29110 [16].
o Actividad 2.2: Definición del proceso: Se realizó la definición de un
proceso ágil para la gestión de la configuración de software adaptado a
las características y necesidades de MiPyMEs_DS.
 Ciclo 3. Evaluación de la propuesta: La evaluación de la propuesta se llevó a
cabo mediante el uso de un grupo focal (focus group) como técnica cualitativa
de estudio. El grupo focal se realizó a través de la reunión de un grupo de
expertos que evaluaron la propuesta.
o Actividad 3.1. Planificación: Se llevó a cabo la capacitación,
coordinación, organización y diseño del grupo focal.
o Actividad 3.2. Acción: Se ejecutó el grupo focal teniendo en cuenta la
planificación y diseño planteado en la actividad anterior.
o Actividad 3.3. Observación: Se recogen los datos sobre la ejecución e
intervención del grupo focal.
o Actividad 3.4. Reflexión: Se generó un reporte como resultado de la
reflexión y el análisis de los datos obtenidos durante la ejecución del
grupo focal. Asimismo, se llevó a cabo la realimentación y evaluación
del aprendizaje obtenido.
 Ciclo 4. Documentación y socialización: Este ciclo se llevó a cabo de
manera transversal al proyecto. En esta fase se realizaron las siguientes
actividades:
o Actividad 4.1: Elaboración de monografía: Se elaboró la monografía
teniendo en cuenta los anexos que resultaron durante la realización del
trabajo de grado o documento final.
o Actividad 4.2: Elaboración de artículo: Se elaboró un artículo de
investigación que describe los resultados obtenidos durante la
realización y aplicación de la propuesta.
o Actividad 4.3: Sustentación: Se presentaron y sustentaron los
resultados obtenidos durante el desarrollo del proyecto.

1.4 Estructura del documento.

El trabajo de investigación está dividido en siete (7) capítulos, los cuales se describen
de manera resumida a continuación:

El Capítulo II. Marco teórico y estado del arte, presenta la descripción de modelos
existentes identificados que dan soporte a la gestión de la configuración de software.

4
Además, en este capítulo se presenta el análisis de la revisión sistemática y/o trabajos
relacionados, el cual incluye: propuestas, iniciativas y trabajos relacionados con el
área de SCM. Finalmente, se presenta un análisis de los resultados obtenidos en la
revisión sistemática y los aportes que presenta el proyecto de investigación en el área
de la ingeniería de software y en la industria local de desarrollo de software.

En el Capítulo III. Armonización de modelos para la gestión de la configuración , se

realiza un análisis de los modelos seleccionados a partir de la revisión del marco
teórico mediante la aplicación de un proceso de armonización de múltiples modelos
para obtener como resultado un modelo integrado. Además, este capítulo presenta de
manera sistemática cada una de las diferentes técnicas utilizadas para llevar a cabo la
armonización mediante métodos de homogeneización, comparación e integración, que
permitieron obtener como resultado un modelo armonizado que incluye los elementos
necesarios para la definición de un proceso formal para la gestión de la configuración
de software.

El Capítulo IV. SCMOnto: Ontología para soportar la gestión de la configuración de

software presenta la definición e implementación de una ontología relacionada a la
gestión de la configuración de software. Inicialmente se presenta el estado del arte
resumido para la definición de la ontología. Finalmente, se presenta la solución
propuesta y la validación teórica realizada para apoyar la definición de un proceso
completo.

El Capítulo V. Progresconfig. presenta la definición formal del proceso ágil para la

gestión de la configuración para MiPyMEs_DS. Este capítulo presenta una visión
general del proceso y su caracterización formal a través de un conjunto de
definiciones, actividades, tareas, roles, productos de trabajo, salidas y un modelo
general de capacidad escalonado para su implementación en una microempresa o en
una pequeña y mediana empresa (en adelante PyME). Además, se presenta la
evaluación de agilidad del proceso propuesto a través de la aplicación de un método
para la evaluación de agilidad de modelos.

El Capítulo VI. Evaluación de la propuesta, presenta la evaluación del proceso a través

de un grupo focal. Inicialmente, se realiza una descripción a alto nivel de la técnica
utilizada y cada una de sus actividades relacionadas. Finalmente, se realiza el análisis
de los resultados obtenidos durante el grupo focal.

El Capítulo VII. Conclusiones y lecciones aprendidas describe las conclusiones

obtenidas a partir del trabajo de investigación, las lecciones aprendidas y las posibles
vías de investigación futuras. Además, se presenta el resumen de cómo se cumplieron
los objetivos de investigación y los aportes investigativos del proyecto en el área de la
ingeniería de software.

De manera complementaria, como resultado de este trabajo se presentarán los

siguientes artefactos: (i) monografía del trabajo de grado, (ii) anexos, (ii) artículo
técnico y (iv) un disco compacto con todos los artefactos mencionados anteriormente
en formato digital.

5
 Capítulo II. Marco teórico y
estado del arte.
Este capítulo presenta el estado del arte actual en el área de la gestión de la
configuración de software a través de la descripción y el estudio de las propuestas
existentes en el área de interés. Además, se presenta el análisis y revisión de una
revisión sistemática de la literatura que busca conocer las propuestas, iniciativas y
trabajos relacionados al área de la gestión de la configuración de software. El objetivo
para seguir con el desarrollo de la revisión sistemática es conocer el estado actual en
esta el área para identificar los aspectos que no se han trabajado y que pueden servir
como líneas de investigación futura. Los trabajos relacionados encontrados se
clasifican y analizan teniendo en cuenta las tendencias de publicación, los modelos
utilizados y el uso de metodologías ágiles.

2.1 Marco teórico.

La ejecución de este proyecto se lleva a cabo tomando como ideas principales
factores como: (i) la categorización por tipo de empresa según su tamaño en el
contexto nacional e internacional, (ii) comparación de los modelos existentes que
proponen aproximaciones o perfiles para la gestión de la configuración de software,
(iii) llevar a cabo la revisión sistemática de la literatura para conocer el estado actual
del área de la gestión de la configuración, (iv) análisis de las propuestas encontradas
para la posterior definición de un proceso para la gestión de la configuración de
software basado en las fortalezas y carencias en los modelos existentes que pueda
ser adoptado de manera exitosa en MiPyMEs_DS a través de un conjunto de
actividades, roles, tareas y productos de salida.

2.1.1 Proceso de desarrollo de software.

Actualmente, cada vez más empresas están comprendiendo que la calidad de sus
productos y servicios depende de cómo están definidos sus procesos y cómo los
llevan a cabo durante el desarrollo de software, por ello, las empresas tienden a seguir
estándares o modelos de referencia para mejorar la calidad de sus productos. En
general, existen varios modelos y estándares que involucran como área de proceso la
gestión de la configuración, entre los que se encuentran IEEE 828-2012 [12], CMMI-
DEV [13], ISO 10007:2003 [14], ISO/IEC 15504 [15] o la ISO/IEC 29110 [16]. Teniendo
en cuenta lo anterior, una empresa desarrolladora de software que desee mejorar la
calidad de sus productos mediante la adopción de mejores prácticas establecidas por
estos modelos debe enfrentarse a la tarea de decidir cuál de estos modelos o
estándares es el que mejor se adapta a sus necesidades y características.

2.1.2 Importancia de la gestión de la configuración en el

proceso de desarrollo de software.
La gestión de la configuración de software permite llevar a cabo un control sistemático
de los cambios en el sistema durante todo el proceso de desarrollo, y en general, no
importa qué tan grande pueda llegar a ser un proyecto, SCM tiene un efecto crítico en
la calidad. Una buena gestión de la configuración permite llevar un control minucioso
de los cambios en todo el sistema con el paso del tiempo, lo cual asegura que la
integridad del software nunca se verá comprometida, por lo cual, la implementación de

6
SCM en los proyectos de software trae varios beneficios a corto y largo plazo, entre los
más importantes:

 Integridad del sistema a lo largo de todo el proceso del desarrollo.

 Reducción de costos en mantenimiento [7].
 Mayor control de la incertidumbre y de la complejidad del producto.
 Trazabilidad completa del sistema.
 Escalabilidad de todo el sistema a través del tiempo [7].
 Ayuda a minimizar el impacto de los cambios financieros y de planeación.
Además, provee una mayor productividad de los recursos existentes [7].
La importancia del buen uso de SCM se puede ser sintetizada en la siguiente premisa:
“Llevar a cabo una mala gestión de la configuración de software puede paralizar
un proyecto” [21].

2.1.3 Modelos propuestos.

A continuación, se realiza una descripción de cada uno de los modelos para
determinar el nivel de detalle en el que ha sido definida la gestión de la configuración
para cada uno de ellos.

2.1.3.1 CMMI-DEV v1.3.

El modelo CMMI-DEV [13] describe un conjunto de buenas prácticas de desarrollo
aplicables a productos y servicios. CMMI-DEV está basado principalmente en el
modelo de Fundación del CMMI (CMF), el cual es un conjunto de 16 áreas de proceso,
metas y prácticas genéricas comunes a cualquier modelo asociado a CMMI. CMMI-
DEV describe 22 áreas de proceso, de las cuales 16 son denominadas áreas de
proceso centrales y entre las que se encuentra la gestión de la configuración.

En general, este modelo fue pensado para ser adaptado en empresas con un nivel de
capacidad y madurez establecido que están en busca de estandarizar sus procesos.
Sin embargo, a pesar de su enfoque tradicional, CMMI-DEV resalta la importancia de
la gestión de la configuración en entornos ágiles debido a que éstos normalmente se
enfrentan a cambios frecuentes dentro de su desarrollo, compilación e integración
continua. Además, resalta la importancia de definir un rol responsable para llevar a
cabo el seguimiento de la implementación de CM. Asimismo, se dice que los equipos
ágiles pueden quedar realmente atascados si no se define un proceso automatizado
de CM basado en scripts, chequeos de integridad y supervisión de estado, y si no se
implementa CM como un conjunto único de servicios refiriéndose a CM como un único
proceso establecido.

Es importante destacar que CMMI-DEV a pesar de ser un modelo pensado para

empresas grandes involucra conceptos ágiles en sus definiciones, entre algunos de los
elementos que describe CMMI-DEV se encuentran:

 Historias de usuario.
 Pila de iteraciones.
Una de las características fundamentales que tiene CMMI-DEV es la categorización de
las empresas por aspectos que ellos definen como niveles de capacidad y madurez:

Los niveles de capacidad se aplican al logro de mejora de procesos de una empresa

en áreas de proceso individuales. Estos niveles son un medio para mejorar

7
incrementalmente los procesos correspondientes a un área de proceso definida.
CMMI-DEV propone cuatro niveles de capacidad numerados de 0 a 3, a continuación,
en la Tabla 1 se presentan los niveles de capacidad definidos por CMMI-DEV.

No. Niv el. Descripción.

0 Incompleto. Un proceso incompleto es un proceso que no se realiza o se realiza parcialmente.
1 Realizado. Un proceso realizado es un proceso que realiza el trabajo necesario para producir productos de
trabajo; Los objetivos específicos del área de proceso se satisfacen.
2 Gestionado. Un proceso administrado es un proceso realizado que se planifica y ejecuta De acuerdo con un
conjunto de políticas.
3 Definido. Un proceso definido es un proceso administrado que está adaptado del conjunto de procesos
estándar de la empresa de acuerdo con las directrices de adaptación de la empresa.
Tabla 1. Niveles de capacidad definidos en CMMI-DEV.

Por otro lado, los niveles de madurez se aplican al logro de mejora de procesos de una
empresa en múltiples áreas de proceso. Estos niveles son un medio para mejorar los
procesos correspondientes a un conjunto dado de áreas de proceso. Los cinco niveles
de madurez propuestos por CMMI-DEV se numeran del 1 al 5. A continuación, en la
Tabla 2 se presentan los niveles de madurez definidos por CMMI-DEV:

No. Niv el. Descripción.

1 Inicial. Los procesos generalmente son caóticos y ad hoc.
2 Gestionado. Los proyectos han asegurado que los procesos se planifiquen y ejecuten De
acuerdo con un conjunto de políticas.
3 Definido. Los procesos e stán bien caracterizados y comprendidos. Además, se describen
normas, procedimientos, herramientas y métodos para lleva rlos a cabo.
4 Gestionado a través de La empresa y los proyectos establecen objetivos cuantitativos para medir la
métodos cuantitativ os. calidad y el rendimiento de los procesos y los utilizan como criterios en la
gestión de proyectos.
5 Optimizado. La empresa mejora continuamente sus procesos basándose en una
comprensión cuantitativa de sus objetivos de negocio y necesidades de
desempeño
Tabla 2. Niveles de madurez definidos por CMMI-DEV.

El área de proceso para la gestión de la configuración definido por CMMI-DEV se

encuentra dentro del segundo nivel de madurez.

2.1.3.2 IEEE 828-2012.

El modelo IEEE 828-10212 [12] es un estándar internacional desarrollado por la IEEE
que establece los requerimientos mínimos para llevar a cabo CM en sistemas e
ingeniería del software. Este estándar define: cuáles actividades de CM deben ser
llevadas a cabo, cuando deben suceder en el ciclo de vida del software y cuales
recursos o planeación son requeridos.

IEEE 828-2012 fue la culminación de un conjunto de documentos que han sido

publicados a través de las últimas dos décadas. En general, el estándar ha
evolucionado desde su primera aproximación con la IEEE 1042-1987 [22], seguido por
revisiones técnicas posteriores como la IEEE 828-1990 [23], IEEE 828-1998 [24], IEEE
828-2005 [25] y finalmente la IEEE 828-2012 [12], la cual sigue vigente desde su fecha
de publicación.

La IEEE 828-2012 plantea un plan para llevar a cabo el área de gestión de la

configuración que define siete (7) procesos de bajo nivel y 2 casos especiales en los
que se debe aplicar dicho plan. Los 7 procesos de bajo nivel son: planeación de CM,
gestión de CM, identificación de la configuración, control de cambios en la
configuración, reporte de estado de la configuración, auditoría de la configuración y
gestión de la configuración de los lanzamientos y los casos especiales: control de los
proveedores y control de interfaces.

8
A continuación, se da una descripción corta de cada uno de los procesos que define la
IEEE-828 2012, la cual se puede observar en la tabla.

 Planeación de CM: El propósito de la planeación de CM es producir y

comunicar planes de CM efectivos y viables. Asimismo, identificar las
actividades y tareas requeridas para gestionar la configuración del producto,
como se especificó en los requerimientos, como fue concebido al inicio del
proyecto o en cualquier otro punto de su ciclo de vida.
 Gestión de CM: El propósito de la gestión de CM es implementar, monitorear,
controlar, y mejorar los servicios de CM. Esto incluye determinar el estado de
las actividades de CM para asegurar que las actividades y tareas propias de
CM se estén llevando a cabo De acuerdo con los planes y calendarios, dentro
de los recursos dispuestos y satisfaciendo los objetivos técnicos.
 Identificación de la configuración: El propósito de este proceso es identificar
cuáles serán los ítems de configuración (CI) contemplados dentro del sistema
estableciendo un criterio de selección, determinar esquemas de nombrado y
descripción de dichos CI De acuerdo con sus características físicas y técnicas.
 Configuración de control de cambios: El propósito de este proceso es
mantener la integridad del producto en todos sus estados, desde la
identificación de sus requerimientos, hasta alcanzar un producto totalmente
validado, sin perder de vista los cambios que podría llegar a necesitar el
sistema después de haber liberado una versión específica y en producción.
 Reporte de estado de la configuración: En cuanto a ese proceso, si bien el
propósito general de CM es mantener el seguimiento de aquellos bienes que
han sido designados como CI, el propósito del reporte de estado mantener los
informes que contienen información crítica sobre dichos elementos, además de
archivos y toda información que sea considerada de importancia por el equipo
de desarrollo o el equipo de gestión.
 Auditoría de la configuración: El objetivo de la auditoría de la configuración
es evaluar objetivamente la integridad del producto, tanto en un aspecto
funcional (procesos de desarrollo utilizados en él) como en un aspecto físico
(cambios en el producto y cómo fueron aplicados).
 Gestión del lanzamiento: El propósito de esta área de proceso es asegurar
que los entregables (incluyendo documentación y materiales auxiliares) sea
entregado a las partes interesadas. Dentro de este contexto se define
“lanzamiento” como una versión de un software o sistema bajo el control de CM
que está actualmente disponible para una parte del público en particular.

2.1.3.3 ISO/IEC 15504.

La norma ISO/EC 15504 [15] es un estándar internacional desarrollado por el proyecto
SPiCE6 para la evaluación de proceso del software. La norma ISO/IEC 15504 define
un área de proceso completo sobre gestión de la configuración cuyo propósito es:
establecer y mantener la integridad de todos los ítems de configuración en un proceso
o proyecto y hacerlos disponibles a las partes involucradas. La ISO/IEC 15504 define
un conjunto de actividades para llevar a cabo la adopción de un proceso de gestión de
la configuración y sus respectivas salidas.

6
Determinación de la Capacidad de Mejora del Proceso de Softw are, del inglés Softw are Process
Improvement Capability Determination, conocido por las siglas SPiCE

9
En general, la norma ISO/IEC 15504, así como el modelo CMMI-DEV, definen
diferentes niveles de capacidad y madurez en una empresa. En general, la ISO/IEC
15504 define 5 niveles de capacidad:

 Nivel 0: Incompleto.
 Nivel 1: Realizado.
 Nivel 2: Gestionado.
 Nivel 3: Establecido.
 Nivel 4: Predecible.
 Nivel 5: Optimizado.

Asimismo, la norma ISO/IEC 15504 define un conjunto de niveles de madurez.

Actualmente, el proceso de gestión de la configuración de software está catalogado en
el segundo nivel de madurez definido por la norma ISO/IEC 15504.

2.1.3.4 ISO/IEC 29110.

La norma ISO/IEC 29110 es un conjunto de estándares internacionales y reportes
técnicos, cuyo objetivo es ser aplicado en cualquier fase dentro del ciclo de vida del
desarrollo de software para generar productos de mayor calidad. Esta norma está
dirigida a ser utilizada por VSE7 cuya definición es equivalente a la de PyME, las
cuales no tienen experiencia en la adaptación de estándares existentes como
ISO/IEC/IEEE 12207 [26] o ISO/IEC/IEEE 15288 [27] para las necesidades específicas
de sus proyectos.

Actualmente, la norma ISO/IEC 29110 propone lo que denominan paquete de

implementación, el cual menciona un conjunto de procesos específicos dentro de un
perfil básico que puede ser adoptado por las empresas, sin embargo, la ISO/IEC
29110 aún no cuenta con un paquete que soporte la gestión de la configuración de
software.

A pesar que la ISO/IEC 29110 no define un perfil para el soporte de la gestión de la

configuración, en [28], se ha propuesto un paquete de implementación para la gestión
de la configuración adaptado a la norma ISO/IEC 29110 que puede ser utilizado en
MiPyMEs desarrolladoras de software, en el cual se han definido un conjunto de
tareas, roles, productos, artefactos, plantillas y herramientas para facilitar la adopción
de un proceso para la gestión de la configuración.

Debido a que no existe un paquete de implementación definido por la ISO/IEC 29110

propuesto de manera formal, se utiliza el paquete de implementación propuesto en
[28] como una aproximación para su comparación con otros modelos para este trabajo
de investigación, en adelante mencionado como “paquete de implementación de SCM
basado en la norma ISO/IEC 29110”.

2.2 Revisión sistemática de la literatura.

Esta sección muestra los parámetros definidos para llevar a cabo la revisión
sistemática de la literatura, tales como: (i) enfoque de la pregunta, (ii) problema
planteado, (iii) pregunta de la investigación a resolver, (iv) planeación de la revisión de
la literatura y (v) resultados de la revisión de la literatura.

7
Very Small Entities por sus siglas en inglés, conocido por las siglas VSE.

10
2.2.1 Enfoque de la pregunta.
La revisión sistemática de la literatura tiene como objetivo y foco principal encontrar las
propuestas, soluciones y trabajos relacionados con la gestión de la configuración de
software que involucren micro, pequeñas y medianas empresas de software.

2.2.2 Pregunta de la investigación.

La revisión sistemática surge bajo la necesidad de responder la siguiente pregunta:
¿Qué trabajos, propuestas e iniciativas relacionadas con la gestión de la
configuración bajo un enfoque de desarrollo ágil se han desarrollado para
PyMEs desarrolladoras de software?

2.2.3 Planeación de la revisión sistemática de la

literatura.
La revisión sistemática de la literatura se llevó a cabo mediante la selección de
estudios primarios sometidos a juicio de expertos. El criterio de selección de las
fuentes de búsqueda está basado sobre las fuentes que están relacionadas con el
tema de la revisión sistemática y que además se encuentren disponibles y puedan ser
acezadas por motores de búsqueda en línea. De la misma manera el listado de
fuentes está apoyado bajo la recomendación y experiencia de expertos, quienes listan
las fuentes sobre las que se realizó dicha revisión.

El procedimiento está basado en el modelo de desarrollo de software Iterativo

Incremental. El proceso iterativo se realiza en la búsqueda, extracción y visualización
de los resultados en cada una de las fuentes de búsqueda seleccionadas. Por su parte
el proceso incremental se desarrolla porque el procedimiento de selección de los
estudios se ejecuta sucesiva o iterativamente en cada una de las fuentes de manera
que el informe de la revisión irá creciendo y evolucionando cada vez más hasta
completar y obtener el reporte final de la revisión.

A continuación, en la Tabla 3 se muestra un resumen de los principales términos y

palabras clave utilizados para resolver la pregunta planteada en la revisión
sistemática.

No. Palabras clav e. Sinónimo.

1 Software. Program, system.
2 Configuration. Structure, outline, composition.
3 Management. Board, administration.
4 Configuration Management. CM, Change Management.
5 Software Configuration Management.
SCM, Software Change Management.
6 Process. Operation, proceeding, mechanism, development.
7 Model. Standard, model, framework, technology, methodology,
approach.
Tabla 3. Palabras clave y sinónimos.

Realizando combinaciones de los conectores lógicos “AND” y “OR” sobre las palabras
clave identificadas, se realizó una primera búsqueda con el prototipo in icial de cadena
de búsqueda sobre una fuente. Obteniendo así la siguiente cadena de búsqueda
básica que se aprecia en la Tabla 4.

No. Cadena de búsqueda básica.

1 (Agile OR Agility OR Software OR agile methodologie s OR Agile Software Development OR Software
Engineering)
AND

11
 (Configuration management OR change management OR CM OR Software Configuration Management OR
SCM)
AND
(Standards OR Models OR Methodologies OR Methodology OR Process OR Framework)
AND
(Software Process Improvement OR Improvement OR Improving)
Tabla 4. Cadenas de búsqueda básicas.

Las cadenas de búsqueda fueron adaptadas al ejecutar la revisión en cada uno de los
motores de búsqueda seleccionados.

2.2.4 Resultados de la revisión sistemática de la

literatura.
A continuación, se presentan los hallazgos evidenciados a partir de la revisión
sistemática llevada a cabo con el fin de analizar el estado actual de la literatura en el
campo de SCM. Para ello, se analizó si los trabajos relacionados han sido aplicados
en MiPyMEs y la forma en la que esto fue llevado a cabo según principios, enfoques,
prácticas y normas, entre otros. Además, se hizo un análisis para determinar si los
estudios realizados mencionan o utilizan metodologías ágiles para soportar o apoyar
SCM.

En total, se identificaron doce (12) estudios relacionados al área de SCM. A

continuación, en la Tabla 5 presenta la clasificación por cantidad de publicaciones
anuales relacionadas a SCM.

Año de publicación. Conteo. Referencia.

2004 1 [34]
2007 1 [30]
2008 1 [31]
2010 1 [35]
2011 2 [11], [36]
2013 2 [7], [32]
2014 1 [37]
2015 2 [33], [38]
2016 1 [29]
Tabla 5. Clasificación por cantidad de publicaciones anuales.

La Tabla 6 muestra la clasificación de estudios relacionados según los modelos o

estándares utilizados para soportar SCM. Sin embargo, es necesario tener en cuenta
que un estudio puede mencionar uno o varios modelos, por lo cual, es posible que la
cantidad total de estudios por modelo sea superior a la cantidad de estudios
identificados.

Modelos integrados a SCM. Conteo. Referencia.

CMMI-DEV 5 [7], [29]–[32]
ISO 10007:2003 3 [11], [29], [30]
IEEE 828-2012 1 [30]
SCRUM 1 [33]
8
XP 1 [34]
Tabla 6. Categorización de estudios por modelos, estándares o metodologías
utilizadas para soportar o apoyar SCM.

En la Tabla 7 se presenta la clasificación de las empresas software según su tamaño

de acuerdo con la cantidad de empleados, además se muestra la cantidad de estudios
relacionados a SCM hallados para cada una de las categorías. Sin embargo, es

8
Programación Extrema del nombre en inglés, Extreme Programming.

12
necesario tener en cuenta que un estudio puede mencionar uno o varios tipos de
empresa, por lo cual, es posible que la cantidad total de estudios por tipo de empresa
sea superior a la cantidad de estudios identificados. La clasificación se realiza de
acuerdo con la definición de pequeña y mediana empresa definida por la unión
europea establecida en el reglamento número 651/2014 [39], esta descripción se
complementó agregando la definición de microempresa propuesto en [40].

Tamaño. Cantidad de estudios. Cantidad de empleados.

Grande. 10 Mayor o igual a 250.
Mediana. 4 Mayor o igual a 50 y menor a 250.
Pequeña. 5 Mayor o igual a 10 y menor a 50.
Micro. No se encontró. Menor a 10.
Tabla 7. Clasificación del tamaño de las empresas según el número de empleados.

A continuación, se presenta un resumen con los aportes más importantes de los

trabajos analizados, teniendo en cuenta las clasificaciones realizadas anteriormente.

2.2.4.1 Estudios relacionados que involucran modelos.

 The impact of effective configuration management usage in software
development firms in Sri Lanka [7].

En [7], los autores realizan un estudio cualitativo mediante el uso de cuestionarios con
el fin de recolectar información sobre cómo las compañías grandes, medianas y las
denominadas casas desarrolladoras de software en Sri Lanka hacen uso de CM en su
proceso de desarrollo a través del uso de prácticas e implementación de modelos
como CMMI-DEV [13]. Al final del estudio, los autores concluyen que los equipos de
desarrollo de software en Sri Lanka tienen un modelo sólido para CM; las empresas
que implementan prácticas de SCM tienden a tener una ventaja significativa con
respecto a otros países. Por otro lado, los productos que desarrollan son escalables,
menos costosos y de fácil mantenimiento en el tiempo.

 Managing change in the delivery of complex projects: Configuration

management, asset information and big data [29].

En [29], los autores realizan un marco comparativo en el cual muestran las similitudes
y diferencias en la implementación de CM en tres empresas grandes con procesos
maduros y complejos (CERN, Airbus, Crossrail). CERN sigue el modelo propuesto por
CMMI-DEV [13], Airbus tiene un nivel de madurez alto en gestión de la configuración
(siendo este proceso de alta prioridad) utilizando ISO 10007 [14], y Crossrail utiliza
ISO 10007 [14] para soportar CM. Realizado el estudio, los autores concluyen que: a
pesar que las empresas tienen procesos bien definidos para CM, existen
discrepancias con respecto al manejo de definiciones.

 Odyssey-SCM: An integrated software configuration management infrastructure

for UML models [30].

En [30], los autores proponen un modelo en el cual redefinen algunos aspectos

propios de SCM como ítems de configuración, repositorios, control de versiones y
solicitudes de cambios, desde un punto de vista conceptual para adaptarlos a modelos
UML 9. El estudio está soportado por los modelos propuestos en IEEE 828-2012 [12],
CMMI-DEV [13] e ISO 10007:2003 [14].

9
Lenguaje de Modelado Unificado, del inglés Unified Modeling Language.

13
  Improving change management in software development: Integrating
traceability and software configuration management [31].

En [31], se presenta una solución para CM apoyada por procesos de trazabilidad y

teniendo en cuenta el proceso de gestión de la configuración soportado por CMMI-
DEV [13]. Los autores presentan un estudio de caso en una empresa grande llamada
HospCom, la cual desarrolla sistemas gestores de telecomunicaciones y de televisión
para hospitales y se caracteriza por estar certificada como CMMI nivel 3. Como
resultado, los autores presentan una integración de los dos procesos (definidos a partir
de trazabilidad y SCM) enfocados en la evolución de los artefactos software mediante
el uso de herramientas utilizadas en gestión de la configuración, utilizando además
una herramienta propia que han llamado Tracer para soportar procesos de
trazabilidad.

 ADVICE: A virtual environment for Engineering Change Management [35].

En [35], los autores proponen soluciones para empresas que requieren llevar a cabo
un buen proceso de SCM en sistemas con un nivel de complejidad, incertidumbre y
volumen de información altos. En general, en los tres estudios llevados a cabo se
evidencia la adopción de modelos para soportar SCM como CMMI-DEV, IEEE 828-
2012 e ISO 10007, además, los tres estudios involucran empresas grandes con un
nivel de madurez definido y con niveles de complejidad altos en su proceso de
desarrollo.

2.2.4.2 Estudios relacionados con enfoques ágiles.

Durante el desarrollo de la revisión sistemática fueron encontrados estudios
relacionados que tomaron como estudio de caso empresas grandes y MiPyMEs. Sin
embargo, no fueron encontradas iniciativas o propuestas para llevar a cabo SCM en
microempresas (ver clasificación definida en la Tabla 7). Además, los estudios que
involucran MiPyMEs abordan el estudio de SCM a través de su uso o aplicación en
entornos de desarrollo con un enfoque ágil, tratando de establecer relaciones,
similitudes y diferencias entre la adopción de metodologías ágiles y el uso de SCM en
los proyectos.

 Adaptable Software Configuration Management: An Investigation on Australian

Agile Software Development Organizations [32].

En [32] se realiza un estudio en empresas desarrolladoras de software australianas en

el cual buscan determinar el nivel de relación entre la adopción de enfoques ágiles
para soportar el proceso de desarrollo y el uso de prácticas de SCM en los proyectos
de software. Los autores concluyen que las empresas han iniciado un proceso
paulatino de adopción de prácticas de SCM en sus proyectos independientemente de
su tamaño, pero todavía no existen definiciones formales que permitan establecer una
relación directa entre el enfoque ágil y SCM.

 A Managed Approach of Interaction Between Agile Scrum and Software

Configuration Management System [33].

En [33], los autores señalan que dos tercios de los proyectos software fallan por el uso
incorrecto de SCM y proponen una lista de chequeo con un conjunto de buenas

14
prácticas que pueden ser utilizadas en los proyectos de desarrollo que siguen un
enfoque ágil. A continuación, en la Tabla 8 se describe la lista de chequeo propuesta
por los autores:

No. Descripción.
1 Fijar cambios y hacer seguimiento del problema.
2 Introducir integración continua al proceso de desarrollo.
3 Imponer desarrollo distribuido eficiente.
4 Realizar buenas prácticas de mezcla (merge) e integración continua.
Tabla 8. Actividades propuestas en [33].

 Software configuration management practices for eXtreme programming teams.

[34]

En [34] se realiza un estudio sobre el uso de prácticas de SCM en equipos de trabajo

que usan Extremme Programming como metodología de desarrollo. Durante el
estudio, los autores llevan a cabo un estudio de caso que involucra equipos de
desarrollo pequeños. Como conclusión, los autores recomiendan el uso de SCM es
importante para que un proyecto de desarrollo sea exitoso, por lo cual, los equipos de
desarrollo deben adoptar prácticas de SCM de manera implícita. Además, los autores
identifican que los equipos de desarrollo tienden a seguir SCM de manera incompleta
mediante el uso de refactorización incremental, uso de herramientas de control de
versiones y el uso de metodologías de trabajo basadas en copiar -unir (copy-merge).
Finalmente, los autores definen un conjunto de actividades que deberían ser tomadas
en cuenta para hacer uso de SCM en equipos de trabajo pequeños que utilizan XP, en
la Tabla 9 se describe cada una de las actividades propuestas en el estudio:

No. Descripción.
1 Refactorización incremental.
2 Análisis de impacto de refactorizaciones.
3 Usar modelo de trabajo copiar-unir.
4 Análisis de impacto de historias como parte de la reunión de planeación.
5 Proceso de auditoría física en lanzamiento.
6 Definir los ítems de configuración y su estructura.
7 Seguimiento al cambio de las historias.
8 Escribir comentarios apropiados al subir cambios.
9 Automatizar y optimizar el proceso de lanzamiento.
10 Usar una herramienta para el control de versiones.
11 Usar una herramienta para la construcción.
12 Mantener el repositorio limpio.
Tabla 9. Actividades propuestas en [34].

 An empirical study of lean and agile influences in software configuration

management [37].

En [37] se realiza una investigación para determinar cómo impacta el tamaño de las
empresas en la utilización de procesos de SCM en entornos adaptables de desarrollo
de software. Los autores presentan una revisión de la literatura relacionada para
aclarar los conceptos que se involucran directamente en el estudio, algunos de estos
son: SCM como proceso y framework, Lean Thinking y trazabilidad de software. Como
resultado, los autores concluyen que el tamaño de la empresa no impacta
directamente en la decisión de adoptar o no procesos y práctica propias de SCM en
entornos adaptables de desarrollo de software, es decir, en todos los tamaños de
empresa deberían incluirse procesos de SCM puesto que representan aportes
significativos en cuanto a rendimiento, organización y costos.

15
2.2.4.3 Estudios relacionados que relacionan otros
procesos.
Durante la revisión sistemática se encontraron estudios relacionados que mencionan
otras áreas como trazabilidad, enfoques directamente relacionados a la industria de
código abierto y enfoque dirigido por modelos, lo cual plantea nuevas áreas de
investigación y puntos que deberían ser tomados en cuenta para la creación de un
proceso completo de SCM

 Software Configuration Management Issues with Industrial Opensourcing [11].

En [11] se presentan algunos de los problemas a los que se enfrenta SCM en las
empresas desarrolladoras de software que utilizan plataformas o herramientas de
código abierto. Los autores definen diferentes tópicos de participación de la industria
en proyectos software de código abierto, entre los que se encuentran: (i) service
participation, (ii) development participation, (iii) owner participation, (iv) as-is usage y
(v) modified usage. Durante el estudio, los autores advierten que uno de los grandes
problemas en la industria es la integración continua y los problemas de control de
versiones asociados con los cambios y unión de distintas versiones del proyecto.
Además, en la mayoría de los proyectos software se realiza desarrollo en paralelo y
existe una posibilidad de que se genere un alto número de ramificaciones. Como
conclusión, los autores advierten la necesidad de integrar SCM al proceso de
desarrollo en la industria de código abierto mediante la definición de un proceso
definido y herramientas para el manejo de versiones.

 To Branch or Not to Branch? [36].

En [36] se realiza un trabajo de investigación en una empresa llamada Océ

Technologies, en el cual pretenden entender cómo se está trabajando SCM respecto a
control de versiones y cambios en los artefactos software en dicha empresa. Como
conclusión, los autores resaltan el valor que agrega la utilización de herramientas que
automaticen y reduzcan los tiempos de unión (merge) dentro de los desarrollos.
Finalmente, los autores advierten que el uso de herramientas puede ser
contraproducente si los desarrolladores no hacen un buen uso de estas.

 Models for Implementation of Software Configuration Management [38].

En [38], los autores definen como un problema el uso inadecuado de SCM, y cómo en
consecuencia, este ha sido reducido a un conjunto de prácticas para solucionar
problemas específicos. Los autores presentan una propuesta para la implementación
de configuración del software integrado con el enfoque dirigido por modelos (model-
driven), el cual fue concebido para facilitar la reutilización de elementos software ya
implementados. Finalmente, concluye identificando la necesidad de continuar
investigando sobre la aplicación y definición de modelos para CM.

2.3 Aportes.
A partir de los antecedentes y análisis de la revisión sistemática de la literatura, se
puede observar que ya existen propuestas que intentan dar solución a SCM en
grandes, medianas y pequeñas empresas, los cuales se pueden observar en la Tabla
7. Sin embargo, no existen estudios realizados específicamente para MiPyMEs.

16
Teniendo en cuenta lo anterior, con el desarrollo de este trabajo se pueden identificar
los siguientes aportes:

1. Este proyecto de investigación aporta en el área de mejora de procesos de

software a través de la descripción de un proceso formal para soportar la
gestión de la configuración de software en MiPyMEs_DS. Además, pretende
contribuir con un proceso mediante el cual la comunidad educativa y empresas
desarrolladoras de software de la región podrán llevar a cabo la aplicación de
SCM en sus proyectos a través de una solución que pueda ser aplicada en
MiPyMEs.
2. Definición de una ontología para la gestión de la configuración que tiene como
objetivo definir de manera clara los conceptos y terminología utilizados para la
definición del proceso mencionado en el apartado anterior.
3. Establecer un proceso que permita a las MiPyMEs_DS adoptar prácticas de la
gestión de la configuración de manera gradual e incremental adaptado a las
características propias asociadas a las micro, pequeñas y medianas empresas,
con el objetivo final de ser adoptado de una manera natural.
4. Llevar a cabo un grupo focal que cuenta con la participación de expertos en el
área de la gestión de la configuración y metodologías ágiles para evaluar la
propuesta desarrollada en este proyecto de investigación. Asimismo, el grupo
focal se lleva a cabo con actores que hacen parte de la comunidad académica
y actores que llevan varios años trabajando en la industria local, lo cual dará
una perspectiva completa desde los dos puntos de vista que permitirá realizar
una evaluación objetiva del proceso propuesto.
5. En el área investigativa, este proyecto realiza aportes mediante: (i) la
realización y análisis posterior de una literatura en la integración de modelos
para la gestión de la configuración enfocado a las MiPyMEs bajo un enfoque
ágil, (ii) la definición de un proceso ágil para la gestión de la configuración de
software adaptado a las características y necesidades de MiPyMEs y (iii)
recomendaciones a la comunidad académica e industria en la implementación
de los modelos utilizados y extensión de los resultados obtenidos

17
 Capítulo III. Armonización de
modelos para la gestión de la
configuración.
Este capítulo presenta un análisis de alto nivel de los modelos y estándares
presentados en el capítulo anterior: CMMI-DEV, IEEE 828-2012, ISO/IEC 15504 y el
paquete de implementación basado en la norma ISO/IEC 29110, el cual permite
identificar el nivel de detalle de los modelos estudiados para construir el proceso
unificado. Asimismo, se lleva a cabo un proceso de armonización donde se realizan
actividades de homogeneización, comparación e integración de los modelos
analizados. A partir de los resultados obtenidos relacionados con aspectos comunes o
diferenciadores se llevó a cabo la definición del proceso denominado Progresconfig, el
cual será descrito en detalle en el Capítulo V. Progresconfig.

3.1 Análisis de modelos.

En el capítulo anterior se realizó la descripción de cada una de las propuestas,
soluciones, estudios relacionados y modelos para soportar SCM. Una vez conocido el
marco teórico y el estado del arte en torno a SCM, se realiza un análisis más detallado
para determinar los aspectos relevantes que se mencionan en cada uno de estos y
que deberían ser tomados en cuenta para la definición posterior de un proceso de
SCM, o aquellos aspectos que no son mencionados o tomados en cuenta y que
deberían integrarse al proceso.

3.1.1 Proceso para llevar a cabo la armonización de

múltiples modelos.
En general, cada uno de los modelos y propuestas identificados definen su propia
estructura, características comunes y aspectos que los diferencian del resto, por lo
cual, es importante realizar un análisis detallado para identificar dichos aspectos.

Para la definición de un proceso que soporte SCM en MiPyMEs_DS, se ha decidido

realizar un proceso de armonización de múltiples modelos a través de la aplicación del
proceso de armonización HPROCESS10 propuesto en [41], el cual define un conjunto
de actividades mínimas que deben ser consideradas para armonizar múltiples modelos
a través de la identificación, homogeneización, comparación e integración de
diferentes modelos para obtener como resultado los elementos necesarios para la
definición de un modelo unificado. Las actividades llevadas a cabo para el proceso de
armonización serán descritas en cada uno de los apartados siguientes previo a su
aplicación.

3.1.1.1 Método para llevar a cabo la homogeneización

de modelos.
Según [41], las empresas se enfrentan a dificultades al momento de elegir y aplicar un
conjunto de modelos para soportar uno o varios procesos, por lo cual deciden que es

10
Proceso de Armonización, del inglés Harmonization Process.

18
mejor aplicar de manera parcial uno o varios modelos para solucionar problemas
específicos. En general, los modelos identificados cuentan con un grado de
heterogeneidad que impide a las empresas desarrolladoras de software decidir cuál de
estos utilizar para soportar SCM en su proceso de desarrollo.

De acuerdo con lo anterior, se hace necesario seguir un método de homogeneización

que permita identificar qué información correspondiente a cada modelo que debe ser
relacionada y organizada para definir un modelo unificado. Para ello, se decide aplicar
HoMethod11, el cual permite llevar a cabo la homogeneización de múltiples modelos
mediante la aplicación de cuatro (4) actividades las cuales se muestran a continuación:
(i) Adquisición de conocimiento concerniente a los modelos involucrados, (ii) Análisis
estructural y terminología, (iii) Identificación de requerimientos, (iv) Identificación de la
correspondencia y (v) Análisis de resultados.

3.1.1.1.1 Adquisición de conocimiento concerniente a

los modelos involucrados.
Previo a llevar a cabo la ejecución de la armonización de los modelos, se realiza un
análisis relacionando cada uno de los atributos que son propuestos en estos, así
como: nombre, aproximación, número de páginas, organización que desarrolló el
modelo, versión, entre otros. En la Tabla 10 se observa un cuadro comparativo a alto
nivel de abstracción de los atributos que identifican a CMMI-DEV v1.3, IEEE 828-2012,
ISO/IEC 15504 v2.3 e ISO/IEC 29110 v2.0.

Atributo. CMMI-DEV. IEEE 828-2012. ISO/IEC 15504. ISO/IEC 29110.

Nombre. Capability Maturity Standard for Software Process Systems and software
Model Integration Configuration Improvement engineering – Lifecycle
for Development Management in Capability profiles for Very Small
(CMMI-DEV) Systems and Determination SPiCE Entities (VSEs)
Software Engineering
(IEEE)

Aproximación. Desarrollo de Ingeniería de Ingeniería de Ingeniería de software.

software. software software.
Número de 482. 81 184. 62.
páginas.
Organización. SEI Software IEEE Institute of ISO International ISO International
Engineering Electrical and Organization for Organization for
Institute. Electronics Engineers Standardization. Standardization.
Niv el de detalle Área de proceso Estándar para la Área de proceso Proceso mencionado
de CM. definida. gestión de la definida. dentro de un paquete de
configuración implementación, CM no ha
sido definido de manera
formal.
Versión. 1.3 Final 2.3 2.0
Tabla 10. Cuadro comparativo a alto nivel de atributos asociados a cada modelo.

3.1.1.1.2 Análisis estructural y terminología.

El proceso de armonización propone llevar a cabo un análisis exhaustivo de la
estructura y las palabras clave o terminología utilizada en cada uno de los modelos.
Sin embargo, en este trabajo se presenta una aproximación diferente a través de la
definición de una ontología para resolver las ambigüedades existentes entre los
modelos y dar un conjunto de definiciones que van a soportar el proceso de SCM
propuesto, la definición de la ontología se puede observar con más detalle en el
siguiente capítulo.

11
Método de homogeneización, del inglés Homogeneization Method.

19
3.1.1.1.3 Identificación de los requerimientos.
Una vez que el análisis ha comenzado, es posible identificar los aspectos más
importantes que deben ser tenidos en cuenta para la creación de un proceso unificado.
Para ello, es necesario definir los elementos que van a ser comparados para la
definición del proceso. Asimismo, se describen los parámetros necesarios para
soportar el proceso con un nivel suficiente de detalle sin ser considerado demasiado
complejo o pesado.

De acuerdo con la definición del patrón de procesos propuesto por el proyecto

COMPETISOFT [42], un proceso debe contener un conjunto de definiciones,
actividades, roles asociados a cada actividad, tareas, entradas, artefactos de salida
asociados a cada actividad y diagramas de flujo asociados a cada una de las
actividades. Para llevar a cabo la identificación de cada uno de los elementos
mencionados anteriormente, se lleva a cabo a la aplicación de una estructura común
de elementos de proceso (CSPE, por sus siglas en inglés), cuyo objetivo es cruzar los
elementos comunes en cada uno de los modelos estudiados en una matriz
comparativa con el fin de obtener una estructura que permita identificar los ele mentos
comunes para su posterior comparación e integración. CSPE es definida a partir de los
elementos de proceso definidos en PrMO [43] y que es descrito de manera más
detallada en [41].

CSPE se compone por cuatro (4) secciones: (i) descripción, (ii) roles y recursos, (iii),
control e (iv) información adicional. Además, cada sección incluye un conjunto de
elementos que componen cada sección, y finalmente incluye cada uno de los modelos
que se van a comparar. A continuación, en la Tabla 11 se muestra la plantilla utilizada
para la comparación de elementos de proceso.

Sección. Elementos. Modelo A. Modelo B. Modelo N.

Sección 1: Descripción (SD) SD1. Categoría de proceso.
SD2. Proceso.
SD3. Actividades.
SD1. Tareas.
Sección 2: Roles y Recursos (SRR) SRR1. Roles.
SRR2. Herramientas.
Sección 3: Control (SC) SC1. Artefactos.
SC2. Objetivos.
SC3. Métricas.
Sección 4: Información adicional SIA1. Procesos relacionados.
(SIA) SIA2. Métodos.
Tabla 11. Plantilla utilizada para la comparación de elementos de proceso a alto nivel.
Tomado y traducido de [38].

En la Tabla 12 se hace una categorización a alto nivel de los modelos estudiados

utilizando una versión adaptada de CSPE que incluye dos elemento s adicionales a la
plantilla definida en CSPE, esta adaptación se realiza siguiendo el patrón de procesos
definido por COMPETISOFT, así como:

 Artefactos de salida (SD 1.3): Es importante identificar si las actividades

asociadas a cada modelo definen artefactos de salida, los cuales son el
resultado de aplicar cada actividad de manera satisfactoria.
 Elementos ágiles (SIA 3.2.): Para cumplir con el objetivo de proponer un
proceso que incluya aspectos ágiles, se hace necesario validar si los modelos
estudiados mencionan o aplican elementos ágiles para soportar su proceso de
SCM. La identificación de elementos ágiles permite evaluar si las propuestas
existentes pueden ser aplicadas de manera efectiva en MiPyMEs_DS.

20
A continuación, en la Tabla 12, se muestra la comparación de alto nivel de abstracción
entre CMMI-DEV v1.3, IEEE 828-2012, ISO/IEC 15504 y el paquete de
implementación de SCM basado en la norma ISO/IEC 29110. Como resultado de la
comparación, es posible conocer aquellos elementos de proceso que son definidos en
cada uno de los modelos.

IEEE 828-2012

ISO/IEC 15504

ISO/IEC 29110
CMMI-DEV 1.3
No. Sección. Elementos.

SD 1.1. CM como área proceso. X X X

1 Descripción (SD) SD 1.2. Actividades. X X X X
SD 1.3. Artefactos de salida. X X
SD 1.4. Tareas. X X
SRH 2.1. Roles. X X
2 Roles y herramientas (SRH) SRH 2.2. Herramientas. X
SRH 2.3. Ítems de configuración. X X X X
3 Información adicional (SIA) SIA 3.1. Áreas de proceso relacionadas. X X
SIA 3.2. Elementos ágiles X
Tabla 12. Comparación de modelos a alto nivel utilizando CSPE.

3.1.1.1.4 Análisis de resultados.

Posterior a la comparación de los elementos asociados a cada modelo, se hace un
análisis de cada uno de los aspectos identificados en la Tabla 12. A continuación, se
presenta un análisis de cada uno de los elementos comparados:

 CM como área de proceso: En general, todos los modelos estudiados a

excepción del paquete de implementación de SCM basado en la norma
ISO/IEC 29110 definen CM como un área de proceso definida.
 Actividades: Todos los modelos proponen dar soporte a SCM con diferentes
niveles de abstracción. CMMI-DEV define un conjunto de objetivos específicos
(Specific Goals), los cuales a su vez están conformados por actividades (o
prácticas) asociadas. La IEEE 828-2012 define un conjunto de actividades y
tareas o sub prácticas asociadas a cada actividad. De manera opuesta, La
norma ISO/IEC 15504 y el paquete de implementación de SCM definen un
conjunto de actividades, pero cada actividad no es propuesta con nivel de
detalle suficiente y claro para ser adoptado de manera satisfactoria.
 Artefactos de salida: La IEEE 828-2012 y la norma ISO/IEC 15504 proponen
un conjunto artefactos de salida asociados a cada uno de los componentes
principales que pertenecen a CM y que son el resultado de la implementación
de cada uno de estos a través de sus actividades asociadas.
 Tareas: La IEEE 828-2012 y el paquete de implementación de SCM basado en
la norma ISO/IEC 29110 dividen sus actividades a través de la definición de
tareas o pasos que deben ser seguidos para alcanzar de manera satisfactoria
cada actividad relacionada.
 Roles: CMMI-DEV solo menciona de manera general la necesidad que existe
en definir un rol de “Manager” o “Mantainer”, el cual sería el encargado de
llevar a cabo las tareas relacionadas con prácticas de gestión de la
configuración para asegurar que el proceso se está llevando a cabo de ma nera
correcta. Sin embargo, CMMI-DEV no define características o actividades
asociadas a dicho rol. Por otro lado, el paquete de implementación de SCM
basado en la norma ISO/IEC 29110 propone un conjunto de seis (6) roles en su
propuesta para soportar SCM, los cuales se mencionan a continuación:

21
 administrador del proyecto, analista, cliente, diseñador, equipo de trabajo y
líder técnico.
 Herramientas: El paquete de implementación de SCM basado en la norma
ISO/IEC 29110 propone el uso de herramientas para control de versiones y
repositorios de trabajo para el control de los ítems de configuración.
 Ítems de configuración: En general, todos los modelos estudiados utilizan el
concepto de producto de trabajo o ítem de configuración (IC), los cuales se
refieren a artefactos que necesitan ser identificados durante el proceso de
desarrollo. Además, los ítems de configuración propuestos en cada uno de los
modelos están directamente relacionados a los artefactos utilizados para el
desarrollo de software en cada una de sus etapas: análisis, diseño,
implementación, pruebas, entre otros.
 Áreas de proceso relacionadas: CMMI-DEV y la IEEE 828 2012 mencionan
que su proceso de gestión de la configuración de software puede ser
complementado a través de la aplicación de otras áreas de proceso como el
control de la trazabilidad y la gestión documental.
 Elementos ágiles: CMMI-DEV menciona que en el futuro deberían ser
tomados en cuenta artefactos y elementos que son agregados de enfoques
ágiles. Sin embargo, CMMI-DEV no realiza una descripción en profundidad que
permita identificar su proceso como ágil. Además, el proceso definido en
CMMI-DEV menciona productos de trabajo como historias de usuario y roles
como el dueño del producto, pero solo se hace a manera informativa.

Con el objetivo de facilitar la comprensión y conocimiento de los elementos descritos

en los modelos estudiados, en la Tabla 13, Tabla 14, Tabla 15 y Tabla 16 se presentan
en detalle las actividades de CMMI-DEV, IEEE-828-2012, ISO/IEC 15504 y el paquete
de implementación de SCM, respectivamente.

Componente. Activ idad.

Establecer líneas base. SP 1.1 Identificar los ítems de configuración.
SP 1.2 Establecer un sistema para la gestión de la configuración.
SP 1.3 Crear o lanzar las líneas base.
Seguimiento y control de cambios. SP 2.1 Seguir los requisitos de cambio.
SP 2.2 Control de los ítems de la configuración.
Establecer la integridad. SP 3.1 Establecer registros de gestión de la configuración.
SP 3.2 Realizar auditorías de configuración funcional.
Tabla 13. Actividades asociadas a CMMI-DEV.

Componente. Activ idad.

Planeación de CM. 6.2.1 Desarrollar un plan de CM.
Gestión de CM. 7.2.1 Gestionar la implementación del plan de CM.
7.2.2 Monitorear las actividades de CM.
Identificación de la 8.2.1 Establecer la estructura y jerarquía de los ítems de configuración.
configuración. 8.2.2 Identificar los ítems de configuración.
8.2.3 Describir los ítems de configuración
8.2.4 Nombrar los ítems de configuración.
8.2.5 Asegurar que los ítems de configuración se guardan en el repositorio.
Configuración de control 9.2.1 Establecer una infraestructura para el control de cambios.
de cambios. 9.2.2 Establecer criterios para la evaluación de los cambios y las autoridades
responsables.
9.2.3 Establecer el formulario para las peticiones de cambios.
9.2.4 Controlar los cambios de todos los ítems de configuración.
9.2.5 Verificar la disposición aprobada de las solicitudes de cambio.
Reporte de estado de la 10.2.1 Verificar el estado de la configuración necesaria para los ítems de
configuración. configuración.
10.2.2 Verificar que los mecanismos para la gestión de la configuración están definidos
correctamente para soportar las necesidades de la información.
10.2.3 Reporte de todos los ítems de configuración.
10.2.4 Reporte de estado de los ítems de configuración.
10.2.5 Informar las discrepancias de las auditorias.
Auditoría de la 11.2.1 Realizar auditorías de configuración funcional.
configuración. 11.2.2 Realizar auditorías de configuración física.
11.2.3 Realizar la auditoría de configuración de las líneas base.

22
 11.2.4 Registrar e informar las no conformidades.
11.2.5 Verificar la resolución de discrepancias.
Control de interfaces. 12.2.1 Identificar la clave del producto de las interfaces.
12.2.2 Controlar las especificaciones de las interfaces.
Configuración de 13.2.1 Incluir el manejo y la adquisición de ítems de configuración en el plan para la
prov eedores. gestión de la configuración.
13.2.2 Colocar los ítems adquiridos bajo gestión de la configuración.
Gestión del lanzamiento. 14.2.1 Delinear los requisitos generales.
14.2.2 Definir la política de liberación.
14.2.3 Definir la planeación de las liberaciones,
14.2.4 Definir el contenido de la versión a liberar.
14.2.5 Definir el formato de lanzamiento y distribución.
14.2.6 Definir el seguimiento de las liberaciones.
14.2.7 Entregar los lanzamientos aprobados.
14.2.8 Archivar.
Tabla 14. Actividades asociadas a IEEE 828-2012.

Activ idad.
Acrónimo. Descripción.
SUP.8. BP1 Desarrollar una estrategia de gestión de la configuración.
SUP.8. BP2 Identificar los elementos de la configuración.
SUP.8. BP3 Establecer un sistema para la gestión de la configuración.
SUP.8. BP4 Establecer una estrategia para la gestión de las ramificaciones.
SUP.8. BP5 Establecer las líneas de base.
SUP.8. BP6 Mantener la descripción de los elementos de configuración.
SUP.8. BP7 Controlar modificaciones y lanzamientos.
SUP.8. BP8 Mantener el historial de los ítems de la configuración.
SUP.8. BP9 Informar el estado de la configuración.
SUP.8. BP10 Verificar la información de los elementos configurados.
SUP.8. BP11 Administrar las copias de seguridad, almacenamiento, archivos, manipulación y
distribución de los elementos de la configuración.
Tabla 15. Actividades asociadas a ISO/IEC 15504.

Activ idad.
Acrónimo. Descripción.
CM.1 Identificación de los ítems de configuración.
CM.2 Inicializar el sistema de gestión de la configuración.
CM.3 Registrar las solicitudes de cambios o requerimientos.
CM.4 Añadir ítems de configuración a la línea de base.
CM.5 Añadir registros de rastreo al sistema de gestión de la configuración.
CM.6 Hacer respaldo del repositorio del proyecto.
CM.7 Restaurar respaldo del repositorio del proyecto.
CM.8 Liberar la configuración del software.
Tabla 16. Actividades asociadas a ISO/IEC 29110.

Con el objetivo de facilitar la comprensión y conocimiento de los elementos descritos

en los modelos estudiados, en la Tabla 17 y Tabla 18 se presentan en detalle los
elementos de salida asociados a las actividades en los modelos ISO/IEC 15504 y la
IEEE 828-2012, respectivamente.

Salida.
No. Descripción.
1 Una estrategia para la gestión de la configuración es desarrollada.
2 Las modificaciones y lanzamientos de los ítems de configuración son controlados.
3 Las modificaciones y lanzamientos son puestos a disposición de las partes afectadas.
4 El estado de los ítems de configuración y las solicitudes de cambios son guardados y reportados.
5 Se asegura la integridad y la consistencia de los ítems de configuración.
6 El almacenamiento, manejo y distribución de los ítems de configuración es controlado
7 Todos los ítems generados por un proceso o proyecto son identificados, definidos y establecidos en una línea
base De acuerdo con la estrategia definida para la gestión de la configuración.
Tabla 17. Salidas asociadas a ISO/IEC 15504.

Componente. Salida.
Planeación de CM.  El alcance de los trabajos para el proyecto de CM se define.
 La viabilidad de alcanzar los objetivos del proyecto de CM con los recurso s y
restricciones disponibles se evalúa.
 Se identifican las tareas que deben realizarse para llevar a cabo el trabajo.
 Se identifican los recursos necesarios para realizar el trabajo.

23
  Las tareas por realizar y los recursos necesarios para realizar el trabajo se
clasifican y calculan.
 Se identifican las interfaces entre elementos del proyecto CM y otros proyectos
externos.
 Se desarrollan planes para la ejecución del proyecto de CM.
 Los planes para la ejecución de CM se activan.
Gestión de CM.  Se obtienen los recursos para realizar el proyecto de CM.
 El progreso del proyecto de CM es monitoreado y reportado.
 Las interfaces entre elementos del proyecto CM y con otros proyectos es
monitoreado.
 Las acciones para corregir las desviaciones del plan y evitar la repetición de los
problemas identificados en el proyecto CM se toma cuando los objetivos del
proyecto no se alcanzan.
 Los objetivos del proyecto CM se alcanzan y se registran.
Identificación de la  La configuración del producto es definida.
configuración.  Los ítems de configuración requeridos son identificados.
 Las líneas base internas y externas son establecidas.
Configuración de  Las peticiones de cambios en los ítems de configuración son clasificados y
control de cambios. registrados.
 Las solicitudes de cambio de los ítems de configuración se evalúan utilizando
criterios definidos.
 Los cambios aprobados en los ítems de configuración se implementan.
 Los cambios de los ítems de configuración se verifican.
 Los cambios sin éxito de los ítems de configuración se revierten o se remedian.
Reporte de estado de la  Las necesidades de información del CM se identifican.
configuración.  Los informes de CM se preparan De acuerdo con los criterios defi nidos.
 Los informes de CM se ponen a disposición de las partes afectadas.

Auditoría de la  El alcance y el propósito de cada auditoría de CM se define.

configuración.  Se garantiza la objetividad y la imparcialidad de la realización de las auditorías
de CM y la selección de auditores.
 La conformidad de las configuraciones funcional, física, de línea de base y de
liberación a los requisitos es determinado.
 Las no conformidades se registran.
 Las no conformidades se comunican a los responsables de la acción correctiva
y la resolución.
 Las acciones correctivas para las no conformidades son verificadas.
Control de interfaces.  Las interfaces de CM son definidas.
 Las interfaces de CM son monitoreadas.
Gestión del  El contenido de la versión se define.
lanzamiento.  Se identifican requisitos de formato de liberación.
 Las emisiones se montan.
 Los lanzamientos son entregados.
 Los lanzamientos al final del ciclo de vida son archivados.
 La información de la liberación se comunica a las partes afectadas.

Tabla 18. Salidas asociadas a IEEE 828-2012.

Con el objetivo de facilitar la comprensión y conocimiento de los elementos descritos

en los modelos estudiados, en la Tabla 19 se presentan en detalle los ítems de
configuración relacionados cada uno de los modelos:

Modelo. Ítems de configuración.

CMMI-DEV 1. Hardware y equipos.
2. Bosquejos.
3. Especificación de producto.
4. Configuraciones de herramientas.
5. Código fuente y librerías.
6. Compiladores.
7. Herramientas de pruebas y scripts.
8. Registros de instalación.
9. Archivos de producto.
10. Publicaciones técnicas de producto.
11. Planes.
12. Descripciones de procesos.
13. Requerimientos.
14. Documentación de arquitectura y diseño de datos.
15. Planes de línea de productos, procesos y activos fundamentales.

24
IEEE 828- 1. Especificaciones.
2012 2. Especificaciones de interfaz.
3. Diseños.
4. Código fuente.
5. Compilaciones.
6. Datos de compilación.
7. Elementos relacionados con la base de datos, tales como: disparadores, esquemas,
secuencias de comandos de SQL, etc.
8. Pruebas unitarias y pruebas de cobertura, y los estándares que se utilizaron para crear
dichos elementos.
9. Bosquejos de diseño.
10. Modelos de referencia.
11. Modelos o prototipos basados en la línea de base.
12. Manuales de mantenimiento operación.
ISO/IEC 1. Plan para la gestión de la configuración.
15504 2. Documentos de requerimientos, diseño y arquitecturas.
3. Entornos de desarrollo de software.
4. Plan de desarrollo de software.
5. Acuerdos con proveedores.
6. Planes para el aseguramiento de la calidad.
7. Código fuente y documentación de las unidades de software.
8. Código fuente, revisión y documentación de pruebas unitarias.
9. Manuales de usuario.
ISO/IEC 1. Plan del proyecto.
29110 2. Especificación de requerimientos.
3. Listas de verificación.
4. Solicitud de cambio.
5. Especificación de requerimientos.
6. Manual de usuario.
7. Diseño de software.
8. Registro de rastreo.
9. Repositorio del proyecto.
10. Casos y procedimientos de prueba.
11. Configuración de software.
12. Componentes de software.
13. Documentación del proyecto.
14. Código fuente y binarios.
15. Herramientas de trabajo (IDE, librerías, plugins, etc.)
16. Grabaciones de audio/video, actas de reuniones, etc.

Tabla 19. Ítems de configuración definidos por cada modelo.

3.1.2 Método para llevar a cabo la comparación de

modelos.
Posterior a realizar una categorización de los modelos que permitan identificar los
elementos de proceso que contiene cada uno, es necesario realizar una comparación
entre los modelos que permita realizar un mapeo para determinar el nivel de relación
entre los elementos definidos en cada una de las propuestas. Para realizar el proceso
de comparación se sigue el método de comparación utilizado en [41], el cual es
denominado por el autor MaMethod12 y es adaptado para realizar una comparación a
alto nivel de las actividades definidas para la gestión de la configuración de software
en cada uno de los modelos estudiados durante la etapa de homogeneización. El
proceso de comparación se divide en tres (3) actividades: (i) analizar los modelos, (ii)
diseñar la comparación y (iii) llevar a cabo la comparación.

3.1.2.1 Diseñar la comparación.

El análisis previo en la etapa de homogeneización permitió encontrar que cada uno de
los modelos estudiados comprende un conjunto determinado de actividades, las
cuáles serán el parámetro de entrada para la comparación de los modelos. A

12
Método de Mapeo, del inglés Mapping Method.

25
continuación, en la Tabla 20 se muestra la plantilla utilizada para llevar a cabo la
comparación entre los diferentes modelos.

Dirección del mapeo: De Modelo A hacia el Modelo B.

Elementos de proceso mapeados: Actividades

Pregunta del mapeo: ¿Qué actividades definidas por el Modelo A soportan actividades específicas del modelo B?

Objetiv o del mapeo: Determinar qué actividades del Modelo A tienen una relación cercana a algunas actividades
específicas propuestas por el Modelo B.
Modelo B
Modelo A Proceso A
Actividad 1 Actividad 2 Actividad 3 Actividad m
Actividad 1
Actividad 2
Actividad 3
Actividad n
Tabla 20. Tabla de comparación entre modelos. Tomado de [41].

Para realizar el proceso de comparación se utilizó una plantilla que permita realizar un
cruce que involucre las actividades definidas en cada uno de los modelos y propuestas
relacionadas. En la Tabla 21 se muestra la plantilla definida para realizar la
comparación de modelos que se utiliza en este proyecto de investigación.

Dirección del mapeo: De Modelo A hacia el Modelo B.

Elementos de proceso mapeados: Actividades Modelo A

Actividad m
Pregunta del mapeo: ¿Qué actividades definidas por el Modelo A soportan actividade s

Actividad 1

Actividad 2

Actividad 3
específicas del modelo B?

Objetiv o del mapeo: Determinar qué actividades del Modelo A tienen una relación cercana a
algunas actividades específicas propuestas por el Modelo B.

Activ idad 1
Modelo B

Activ idad 2
Activ idad 3
Activ idad n
Tabla 21. Plantilla de comparación entre modelos. Tomado de [44].

3.1.2.2 Llevar a cabo la comparación.

Posterior a identificar cada una de las actividades relacionadas a los modelos
estudiados se lleva a cabo la comparación utilizando como modelo base de
comparación la norma ISO/IEC 15504, debido a que es un estándar internacional que
ha tomado mucha importancia y además es tomado como modelo de referencia por
una gran número de empresas desarrolladoras de software alrededor del mundo [45].

Además de realizar una comparación con cada uno de los modelos, se realizó una
comparación entre las actividades definidas por la norma ISO/IEC 15504 y las
actividades propuestas en los estudios “A Managed Approach of Interaction Between
Agile Scrum and Software Configuration Management System” [33] y “Software
configuration management practices for eXtreme programming teams” [34], los cuales
son estudios relacionados que fueron descritos en el estado del arte y proponen un
conjunto de prácticas que según los autores deberían ser tenidos en cuenta para
soportar SCM.

A continuación, Tabla 22, Tabla 23, Tabla 24, Tabla 25 y Tabla 26 se presentan las
comparaciones entre: (i) la norma ISO/IEC 15504 y CMMI-DEV, (ii) ISO/IEC 15504 y la
IEEE 828-2012, (iii) ISO/IEC/15504 y el paquete de implementación de SCM basado

26
 en la norma ISO/IEC 29110, (iv) ISO/IEC 15504 y el estudio “A Managed Approach of
Interaction Between Agile Scrum and Software.

3.1.2.2.1 ISO/IEC 15504 vs CMMI-DEV.

Dirección del mapeo: De la norma
ISO/EC 15504 hacia el modelo CMMI- ISO/IEC 15504
DEV.

SUP.8. B11: Administrar las copias de seguridad,

SUP.8. B10: Verificar la información de los elementos

almacenamiento, archivos, manip ulació n y distribución de lo s

SUP.8.BP4: Establecer una estrategia para la gestión de las
SUP.8.BP1: Desarrollar una estrategia de gestión de la

SUP.8.BP6: Mantener la descripción de los elementos de

SUP.8.BP8: Mantener el historial de los ítems de la

SUP.8.BP3: Estable cer un sistema para la gestión de la
Elementos de proceso mapeados:

SUP.8.BP2: Identificar los elementos de la configuración .

Actividades

SUP.8.BP7: Controlar modificaciones y lanzamientos.

SUP.8.BP9: Informar el estado de la configuración.

Pregunta del mapeo: ¿Qué actividades
definidas por la norma ISO/EC 15504
soportan actividades específicas de
CMMI-DEV?

SUP.8.BP5: Establecer las líneas de base.

Objetiv o del mapeo: Determinar qué
actividades de la norma ISO/EC 15504
tienen una relación cercana a algunas

elementos de la configuración.
actividades específicas propuestas por
CMMI-DEV.

ramificaciones.

configuración.
configuración.

configuración.

configuración.

configurados
SP 1.1. Identificar los ítems de la X
configuración.
SP 1.2. Establecer un sistema para X
la gestión de la configuración.
SP 1.3. Crear o lanzar las líneas X
CMMI-DEV

base.
SP 2.1. Seguir los requisitos de X X
cambio.
SP 2.2. Control de los ítems de la
configuración
SP 3.1. Establecer registros de X X
gestión de la configuración.
SP 3.2. Realizar auditorías de X
configuración funcional.
Tabla 22. Comparación de actividades entre la norma ISO/IEC 15504 y CMMI-DEV.

27
 3.1.2.2.2 ISO/IEC 15504 vs IEEE 828-2012.
Dirección del mapeo: De la norma
ISO/EC 15504 hacia el modelo IEEE 828- ISO/IEC 15504
2012.

SUP.8. B10: Verificar la información de los elementos

SUP.8. B11: Administrar las copias de seguridad,

SUP.8.BP6: Mantener la descripción de los elementos de

almacenamiento, archivos, manip ulació n y distribución de lo s

SUP.8.BP4: Establecer una estrategia para la gestión de las
SUP.8.BP1: Desarrollar una estrategia de gestión de la

SUP.8.BP8: Mantener el historial de los ítems de la

SUP.8.BP3: Estable cer un sistema para la gestión de la
Elementos de proceso mapeados:

SUP.8.BP2: Identificar los elementos de la configuración.

Actividades

SUP.8.BP7: Controlar modificaciones y lanzamientos.

Pregunta del mapeo: ¿Qué actividades

SUP.8.BP9: Informar el estado de la configuración.

definidas por la norma ISO/EC 15504
soportan actividades específicas de IEEE
828-2012?

SUP.8.BP5: Establecer las líneas de base.

Objetiv o del mapeo: Determinar qué
actividades de la norma ISO/EC 15504
tienen una relación cercana a algunas
actividades específicas propuestas por

elementos de la configuración.
IEEE 828-2012.

ramificaciones.
configuración.

configuración.

configuración.

configuración.

configurados
6.2.1. Desarrollar un plan de CM. X
7.2.1. Gestionar la implementación X
de del plan de CM (CMP).
7.2.2. Monitorear las actividades de
CM.
8.2.1. Establecer la estructura y X
jerarquía de los ítems de
configuración.
8.2.2. Describir los ítems de la X
configuración.
8.2.3. Nombrar los ítems de la X
configuración.
8.2.4. Asegurar que los ítems de la X
configuración se guardan en el
repositorio.
8.2.5. Asegurar que los ítems de la X
configuración se guardan en el
repositorio.
IEEE 828-2012

9.2.1. Establecer una infraestructura X X

para el control de cambios.
9.2.2. Establecer criterios para la X X
evaluación de los cambios y las
autoridades responsables.
9.2.3. Establecer el formulario para X X X
las peticiones de cambios.
9.2.4. Controlar los cambios de X X X
todos los ítems de configuración.
9.2.5. Verificar la disposición X X
aprobada de las solicitudes de
cambio.
10.2.1. Verificar el estado de la X X
información necesaria para los
ítems de configuración.
10.2.2. Verificar que los X
mecanismos para la gestión de la
configuración están definidos
correctamente para soportar las
necesidades de información.
10.2.3. Reporte de todos los ítems X
de configuración.
10.2.4. Reporte de estado de los X
ítems de configuración.

28
 10.2.5. Informar las discrepancias X
de las auditorías.
11.2.1. Realizar auditorías de X
configuración funcional.
11.2.2. Realizar auditorías de X
configuración física.
11.2.3. Realizar la auditoría de X
configuración de línea base.
11.2.4. Registre e informe las no
conformidades.
11.2.5. Verificar la resolución de
discrepancias.
12.2.1 Identificar la clave del
producto de las interfaces.
12.2.2 Controlar las
especificaciones de las interfaces.
13.2.1 Incluir el manejo y la
adquisición de ítems en el plan para
la gestión de la configuración.
13.2.2 Colocar los ítems adquiridos
bajo CM.
14.2.1. Delinear los requisitos X
generales.
14.2.2 Definir la política de
liberación.
14.2.3 Definir la planificación de la X
liberación.
14.2.4 Definir el contenido de la X
versión.
14.2.5. Definir el formato de X
lanzamiento y la distribución.
14.2.6 Definir el seguimiento de la X
liberación.
14.2.7. Entregar los lanzamientos
aprobados.
14.2.8. Archivar.

Tabla 23. Comparación de actividades entre la norma ISO/IEC 15504 y la IEEE 828-
2012.

29
 3.1.2.2.3 ISO/IEC 15504 vs el paquete de
implementación de SCM basado en la norma ISO/IEC
29110.
Dirección del mapeo: De la norma
ISO/EC 15504 hacia el paquete de ISO/IEC 15504
implementación de SCM propuesto en

los

los

SUP.8. B11: Administrar las copias de seguridad,

la

la
SUP.8.BP1: Desarrollar una estrategia de gestió n de

SUP.8.BP3: Establecer un sistema para la gestión de

SUP.8.BP8: Mantener el historial de los ítems de la

y
[28]

SUP.8.BP9: Informar el estado de la configuración.

distribución de los elementos de la configuración.

para
de

de
de

manipulación
modificacio nes
Elementos de proceso mapeados:
Actividades

elementos

SUP.8.BP5: Establecer las líneas de base.

información
descripción
SUP.8.BP4: Estable cer una estrategia
Pregunta del mapeo: ¿Qué actividades
definidas por la norma ISO/EC 15504
soportan actividades específicas del
paquete de implementación de SCM?

los

archivos,
gestión de las ramificaciones.

la
elementos de configuración.
SUP.8.BP6: Mantener la

Controlar
Objetiv o del mapeo: Determinar qué

SUP.8. B10: Verificar

SUP.8.BP2: Identificar

elementos configurados
actividades de la norma ISO/EC 15504
tienen una relación cercana a algunas
actividades específicas propuestas en el

almacenamiento,
la configuración.

la configuración.
paquete de implementación de SCM.
configuración.

configuración.
lanzamientos.
SUP.8.BP7:
CM.1: Identificación de los ítems X
de configuración.
Paquete de implementación de SCM
basado en la norma ISO/IEC 29110

CM.2: Inicializar el sistema de X

gestión de la configuración.
CM.3: Registrar las solicitudes de X
cambios o requerimientos.
CM.4: Añadir ítems de X X
configuración a la línea de base.
CM.5: Añadir registros de rastreo X
al sistema de gestión de la
configuración.
CM.6: Hacer respaldo del X X
repositorio del proyecto.
CM.7: Restaurar respaldo del
repositorio del proyecto.
CM.8: Liberar la configuración X
del software.
Tabla 24. Comparación de actividades entre la norma ISO/IEC 15504 y la ISO/IEC
29110 propuesta en [25].

30
 3.1.2.2.4 ISO/IEC 15504 vs propuestas que involucran
elementos ágiles.
Dirección del mapeo: De la norma ISO/EC
15504 hacia el estudio relacionado A ISO/IEC 15504
Managed Approach of Interaction Between

SUP.8. B11: Administrar las copias de seguridad, almacenamiento, archivos,

Agile Scrum and Software Configuration
Management System [33].

Elementos de proceso mapeados:

Actividades

SUP.8.BP4: Establecer una estrategia para la gestión d e las ramificaciones.

Pregunta del mapeo: ¿Qué actividades

SUP.8.BP6: Mantener la descripción de los elementos de configuración.

definidas por la norma ISO/EC 15504

SUP.8.BP3: Establecer un sistema para la gestión de la configuración.

SUP.8.BP1: Desarrollar una estrategia de gestión de la configuración.
soportan actividades específicas en el

SUP.8. B10: Verificar la información de los elementos configurados

SUP.8.BP8: Mantener el historial de los ítems de la configuración.
estudio relacionado A Managed Approach of

manipulación y distribución de los elementos de la configuración.

Interaction Between Agile Scrum and
Software Configuration Management System
[33]?
SUP.8.BP2: Identificar los elementos de la configuración.

SUP.8.BP7: Controlar modificaciones y lanzamientos.

Objetiv o del mapeo: Determinar qué

SUP.8.BP9: Informar el estado de la configuración.

actividades de la norma ISO/EC 15504
tienen una relación cercana a algunas
actividades específicas propuestas en el

SUP.8.BP5: Establecer las líneas de base.

estudio relacionado A Managed Approach of
Interaction Between Agile Scrum and
Software Configuration Management System
[33].

Notación: Por la naturaleza independiente

de la propuesta definida en A Managed
Approach of Interaction Between Agile
Scrum and Software Configuration
Management System [33], se define la
notación P.[33].X, donde:

 P: Propuesta.
 [33]: Referencia al estudio
relacionado.
 X: Número del ítem.
P.[33].1: Fijar cambios y hacer X
propuestas en [33]

seguimiento del problema.

Actividades

P.[33].2: Introducir integración X

continua al proceso de desarrollo.
P.[33].3: Imponer desarrollo
distribuido eficiente.
P.[33].4: Realizar buenas prácticas X
de mezcla (merge) e integración
continua.
Tabla 25. Comparación de actividades entre la norma ISO/IEC 15504 y las actividades
propuestas en [33].

31
Dirección del mapeo: De la norma ISO/EC
15504 hacia el estudio relacionado Software ISO/IEC 15504
configuration management practices for

SUP.8. B11: Administrar las copias de seguridad, almacenamiento, archivos,

eXtreme programming teams [34].

SUP.8.BP4: Establecer una estrategia para la gestión de las ramificaciones.

Elementos de proceso mapeados:
Actividades

SUP.8.BP6: Mantener la descripción de los elementos de configuración.

SUP.8.BP3: Establecer un sistema para la gestión de la configuración.
SUP.8.BP1: Desarrollar una estrategia de gestión de la configuración.
Pregunta del mapeo: ¿Qué actividades

SUP.8. B10: Verificar la información de los elementos configurados

SUP.8.BP8: Mantener el historial de los ítems de la configuración.
definidas por la norma ISO/EC 15504

manipulación y distribución de los elementos de la configuración.

soportan actividades específicas en el
estudio relacionado Software configuration
management practices for eXtreme

SUP.8.BP2: Identificar los elementos de la configuración.

programming teams [34]?

SUP.8.BP7: Controlar modificaciones y lanzamientos.

SUP.8.BP9: Informar el estado de la configuración.

Objetiv o del mapeo: Determinar qué
actividades de la norma ISO/EC 15504
tienen una relación cercana a algunas

SUP.8.BP5: Establecer las líneas de base.

actividades específicas propuestas en el
estudio relacionado Software configuration
management practices for eXtreme
programming teams [34].

Notación: Por la naturaleza independiente

de la propuesta definida en el estudio
relacionado Software configuration
management practices for eXtrem e
programming teams [34], se define la
notación P.[34].X, donde:

 P: Propuesta.
 [34]: Referencia al estudio
relacionado.
 X: Número del ítem.
P.[34].1: Refactorización X
incremental.
P.[34].2: Análisis de impacto de X
refactorizaciones.
P.[34].3: Usar modelo de trabajo
copiar-unir.
Actividades propuestas en [34]

P.[34].4: Análisis de impacto de

historias como parte de la reunión
de planeación.
P.[34].5: :Proceso de auditoría X
física en lanzamiento.
P.[34].6: Definir los ítems de X
configuración y su estructura.
P.[34].7: Seguimiento al cambio de X X
las historias.
P.[34].8: Escribir comentarios X
apropiados al subir cambios.
P.[34].9: Automatizar y optimizar el X
proceso de lanzamiento.
P.[34].10: Usar una herramienta X
para el control de versiones.
P.[34].11: Usar una herramienta X
para la construcción.
P.[34].12: Mantener el repositorio X
limpio.
Tabla 26. Comparación de actividades entre la norma ISO/IEC 15504 y las actividades
propuestas en [34].

32
3.1.2.3 Análisis de correspondencia entre modelos.
Posterior a realizar la comparación entre la norma ISO/IEC 15504 con cada uno de los
modelos definidos y con las propuestas analizadas en el capítulo anterior, se realizó
un análisis de correspondencia que permitió observar cómo cada actividad definida en
la norma ISO/IEC 15504 es soportada por actividades propuestas en el resto de
modelos. A continuación, en la Tabla 27 se muestra la correspondencia entre cada
uno de los modelos:

Activ idades definidas por modelo o propuesta

ISO/IEC 15504 CMMI-DEV IEEE Paquete de A Managed Softw are

828 - implementación Approach of configuration
2012 basado en la Interaction management
norma ISO/IEC Between Agile practices for
29110 Scrum and eXtreme
Softw are programming
Configuration teams
Management
System
SUP.8.BP1: 6.2.1.
Desarrollar una 7.2.1.
estrategia de gestión
de la configuración.
SUP.8.BP2: Identificar SP 1.1. 8.2.1. CM.1. P.[34].6.
los elementos de la 8.2.2.
configuración. 8.2.3.
8.2.4.
SUP.8.BP3: SP 1.2. CM.2. P.[34].10.
Establecer un sistema
para la gestión de la
configuración
SUP.8.BP4: P.[33].2. P.[34].8.
Establecer una P.[33].4. P.[34].12.
estrategia para la
gestión de las
ramificaciones.

SUP.8.BP5: SP 1.3. 8.2.5. P.[34].11.

Establecer las líneas
de base.
SUP.8.BP6: Mantener
la descripción de los
elementos de
configuración.
SUP.8.BP7: Controlar SP 2.2. 9.2.1. CM.3. P.[33].1. P.[34].1.
modificaciones y 9.2.2 CM.4. P.[34].9.
lanzamientos. 9.2.3. CM.5.
9.2.4. CM.8.
9.2.5.
10.2.1.
14.2.1.
14.2.3.
14.2.4.
14.2.5.
14.2.6.
14.2.8
SUP.8.BP8: Mantener SP 2.1. 9.2.1. CM.3. P.[34].7.
el historial de los ítems SP 3.1. 9.2.2 CM.5.
de la configuración. 9.2.3.
9.2.4.
SUP.8.BP9: Informar 9.2.3.
el estado de la 9.2.4.
configuración. 10.2.3.
10.2.4.
10.2.5.
SUP.8. B10: Verificar 9.2.5.
la información de los 10.2.1.
elementos
configurados.

33
SUP.8. B11: SP 3.2. 10.2.2. P.[34].5.
Administrar las copias 11.2.1. P.[34].9.
de seguridad, 11.2.2.
almacenamiento, 11.2.3.
archivos, manipulación
y distribución de los
elementos de la
configuración.
Tabla 27. Correspondencia entre actividades definidas en la norma ISO/IEC
15504 contra todos los modelos.

A partir de la información obtenida durante la comparación entre modelos y

propuestas, se realizó un análisis de relación entre los modelos siguiendo una versión
adaptada de las escalas propuestas en [44]. Asimismo, con el fin de expresar el grado
de relación entre el modelo base y el resto de modelos o propuestas, se definió una
escala discreta de comparación que representa el nivel de relación entre los modelos
comparados. Cada uno de los elementos representados en la escala está asociado a
un conjunto de valores a nivel cualitativo y cuantitativo que utiliza un rango de
porcentajes.

Cada porcentaje se calcula dividiendo el número de prácticas específicas de un

modelo que están relacionadas a una actividad del modelo base sobre el número total
de actividades definidas en el modelo base (si el número de actividades relacionadas
al modelo base es superior al número de actividades propuestas por el modelo base,
se determina que el nivel de relación es del 100%). Se debe destacar que los valores
obtenidos representan la medida en que una actividad en un modelo es abordada
mediante las actividades descritas en el modelo base. Por lo tanto, el grado de
relación sólo se expresa a través de la escala discreta. En la Tabla 28, se muestra la
escala de relación entre modelos definida para el análisis.

Acrónimo. Descripción. Porcentaj e.

FR Fuertemente relacionados 86% a 100%
GR En gran parte relacionados 51% a 85%
PR Parcialmente relacionados 16% a 50%
DR Débilmente relacionados 1% a 15%
No relacionados 0%
Tabla 28. Escala de relación entre modelos. Adaptado de [44].

A partir de la información obtenida en la Tabla 27, se hace el cálculo correspondiente

para encontrar el nivel de relación entre las actividades definidas por el modelo base y
cada uno de los modelos comparados. En la Tabla 29, se muestra la relación
cuantitativa obtenida entre el modelo base y el resto de modelos y propuestas basados
en la escala definida anteriormente.

Activ idades definidas en los modelos y propuestas

ISO/IEC 15504 CMMI- IEEE 828 ISO/IEC Propuesta Propuesta

DEV - 2012 29110 [33] [34]
SUP.8.BP1: Desarrollar una estrategia de gestión 0% 18.18% 0% 0% 0%
de la configuración.
SUP.8.BP2: Identificar los elementos de la 9.09% 36.36% 9.09% 0% 9.09%
configuración.
SUP.8.BP3: Establecer un sistema para la gestión 9.09% 0% 9.09% 0% 9.09%
de la configuración
SUP.8.BP4: Establecer una estrategia para la 0% 0% 0% 18.18% 18.18%
gestión de las ramificaciones.
SUP.8.BP5: Establecer las líneas de base. 9.09% 9.09% 0% 0% 9.09%

SUP.8.BP6: Mantener la descripción de los 0% 0% 0% 0% 0%

elementos de configuración.
SUP.8.BP7: Controlar modificaciones y 9.09% 100% 36.36% 9.09% 18.18%
lanzamientos.
SUP.8.BP8: Mantener el historial de los ítems de 18.18% 36.36% 18.18% 0% 9.09%
la configuración.

34
SUP.8.BP9: Informar el estado de la 0% 45.45% 0% 0% 0%
configuración.
SUP.8. B10: Verificar la información de los 0% 18.18% 0% 0% 0%
elementos configurados.
SUP.8. B11: Administrar las copias de seguridad, 9.09% 36.36% 0% 0% 18.18%
almacenamiento, archivos, manipulación y
distribución de los elementos de la configuración.
Tabla 29. Relación cuantitativa entre modelos.

A continuación, la Tabla 30 muestra la relación cualitativa entre el modelo base y cada

uno de los modelos o propuestas comparadas.

Activ idades definidas por modelo o propuesta

ISO/IEC 15504 CMMI- IEEE ISO/IEC Propuesta Propuesta

DEV 828 - 29110 [33] [34]
2012
SUP.8.BP1: Desarrollar una estrategia de gestión de PR
la configuración.
SUP.8.BP2: Identificar los elementos de la DR PR DR DR
configuración.
SUP.8.BP3: Establecer un sistema para la gestión DR DR DR
de la configuración
SUP.8.BP4: Establecer una estrategia para la PR PR
gestión de las ramificaciones.
SUP.8.BP5: Establecer las líneas de base. DR DR DR

SUP.8.BP6: Mantener la descripción de los

elementos de configuración.
SUP.8.BP7: Controlar modificaciones y DR FR PR DR PR
lanzamientos.
SUP.8.BP8: Mantener el historial de los ítems de la PR PR PR DR
configuración.
SUP.8.BP9: Informar el estado de la configuración. PR

SUP.8. B10: Verificar la información de los PR

elementos configurados.
SUP.8. B11: Administrar las copias de seguridad, DR PR PR
almacenamiento, archivos, manipulación y
distribución de los elementos de la configuración.
Tabla 30. Relación cualitativa entre modelos.

3.1.3 Método para la llevar a cabo la integración de

modelos.
Posterior a llevar a cabo los métodos de homogeneización y comparación, se planteó
realizar un último proceso de integración para describir los elementos de proceso
necesarios que deberían ser tenidos en cuenta para la definición de un proceso de
SCM. La integración de los modelos permite obtener como resultado un conjunto de
elementos unificados.

Para llevar a cabo una integración, fue necesario aplicar el método denominado
IMethod13, el cual tiene como objetivo obtener de manera sistemática los elementos de
proceso integrados en múltiples modelos. IMethod menciona cinco (5) actividades que
se deben llevar a cabo para realizar el método, las cuales son: (i) diseñar la
integración, (ii) definir/establecer un criterio de integración, (iii) llevar a cabo la
integración, (iv) analizar los resultados de la integración y (v) presentar el modelo
integrado.

13
Método de integración, del inglés Integration Method.

35
3.1.3.1 Diseñar la integración.
La integración es propuesta tomando como base las actividades definidas en el
modelo base y las actividades relacionadas que fueron cruzadas a partir de la
comparación con el resto de modelos y trabajos relacionados.

3.1.3.2 Establecer los criterios de integración.

Los criterios de integración definidos para este proyecto de investigación son aquellos
que fueron propuestos en [41] para llevar a cabo el proceso de integración. En la Tabla
31 se presentan los criterios utilizados para llevar a cabo la integración de actividades:

Término. Descripción.
Integración, Cuando los elementos en una práctica b no pertenecen a una práctica a.
Complemento y
Unión.
Rechazado. Cuando la descripción de una práctica a de un modelo A no es considerada para su
integración en una práctica b de un modelo B.
No está contenido. Cuando no existe relación entre las descripciones de las prácticas d e los dos modelos
Complej idad. Hace referencia a la información descrita en una práctica, es decir, cuáles pueden ser
descompuestas en varias: actividades, tareas, roles, etc. La cantidad de elementos y sus
relaciones determinan el nivel de granularidad d e una práctica/modelo.
Tabla 31. Plantilla de términos de integración. Tomado de [41].

Finalmente, es necesario definir un criterio de correspondencia para escribir cada una

de las actividades unificadas siguiendo un formato que permita describir las
actividades resultantes de manera clara. En la Tabla 32 se muestra la plantilla definida
en el método de integración para el análisis de correspondencia entre las actividades
resultantes de aplicar el método de integración.

Id Tipo de correspondencia Método

1 Si la práctica a de un Modelo A satisface completamente la Práctica a es mantenida, se registran los
práctica b de un modelo B. resultados de la acción tomada.
2 Si la práctica a de un Modelo A satisface parcialmente la Requerimientos de la práctica b son modificados.
práctica b de un modelo B.
3 Si la práctica a de un Modelo A no satisface la práctica b de Práctica b de un Modelo B es añadida a la práctica
un modelo B. a de un Modelo A.
Tabla 32. Plantilla de aspectos para escribir una práctica unificada. Tomado de [41].

3.1.3.3 Llevar a cabo la integración.

A continuación, se muestra el resultado después de llevar a cabo la integración de
cada actividad asociada a la norma ISO/IEC 15504 con cada uno de los modelos de
manera secuencial. Sin embargo, debido a la naturaleza del trabajo llevado a cabo, se
planteó realizar una integración en conjunto entre la norma ISO/IEC 15504 y todos los
modelos y propuestas relacionadas, de tal manera que la salida obtenida fuera una
actividad completa que involucre a todos los modelos y estudios relacionados.
Además, y junto a los asesores del proyecto, se tomó esta decisión por la facilidad de
certificación en el modelo ISO/IEC 15504, por ser el más detallado y debido a que es
uno de los modelos más utilizado a nivel mundial por MiPyMEs_DS.

La plantilla para la definición de las actividades integradas se compone por un

identificador único para cada actividad, una descripción corta de la actividad unificada,
el conjunto de modelos y propuestas que se van a integrar y las actividades
relacionadas a cada modelo que se tuvieron en cuenta par a la integración de cada
actividad. La plantilla para la definición de las actividades integradas se presenta en la
Tabla 33:

36
ID Activ idad unificada Modelo Activ idad o
propuesta
Identificador Descripción de la actividad unificada entre los Modelos A, Modelo Actividad 1
único. B, X etc. A. Actividad 2
Actividad n
Modelo Actividad 1
B. Actividad 2
Actividad n

Modelo Actividad 1
X. Actividad 2
Actividad n
Tabla 33. Plantilla de unificación de prácticas entre modelos. Adaptado de [41].

A continuación, en la Tabla 34 se presentan las actividades unificadas:

ID Activ idad unificada Modelo Activ idad o

propuesta
GCSA.A1 Descripción: CMMI-DEV. SP 1.1.
Desarrollar una estrategia de IEEE 828 – 2012. 8.2.1.
gestión de la configuración. 8.2.2.
8.2.3.
8.2.4.
Paquete de implementación de SCM basado en la CM.1.
norma ISO/IEC 29110.
Propuesta [33] N/A
Propuesta [34] P.[34].6.
GCSA.A2 Descripción: CMMI-DEV. SP 1.1.
Identificación de la IEEE 828 - 2012. 8.2.1.
configuración. 8.2.2.
8.2.3.
8.2.4.
Paquete de implementación de SCM basado en la CM.1.
norma ISO/IEC 29110.
Propuesta [33] N/A
Propuesta [34] P.[34].6.
GCSA.A3 Descripción: CMMI-DEV. SP 1.2.
Establecer las líneas de SP 1.3.
base. IEEE 828 - 2012. 8.2.5.
Paquete de implementación de SCM basado en la C.M.2.
norma ISO/IEC 29110.
Propuesta [33] N/A
Propuesta [34] P.[34].6.
P.[34].11.
GCSA.A4 Descripción: CMMI-DEV. N/A
Establecer una estrategia IEEE 828 - 2012. N/A
para la modificación de los Paquete de implementación de SCM basado en la N/A
ítems de configuración. norma ISO/IEC 29110.
Propuesta [33] P.[33].2.
P.[33].4.
Propuesta [34] P.[34].8.
P.[34].12.
GCSA.A5 Descripción: CMMI-DEV. N/A
Mantener la descripción de IEEE 828 - 2012. N/A
los ítems de configuración.
Paquete de implementación de SCM basado en la N/A
norma ISO/IEC 29110.
Propuesta [33] N/A
Propuesta [34] N/A
GCSA.A6 Descripción: CMMI-DEV. SP 2.1.
Controlar la modificación de SP 2.2.
los ítems de configuración. SP 3.1.
IEEE 828 - 2012. 9.2.1.
9.2.2.
9.2.3.
9.2.4.
9.2.5.
14.2.1.
14.2.3.
14.2.4.
14.2.5.

37
 14.2.6.
14.2.8
Paquete de implementación de SCM basado en la CM.3.
norma ISO/IEC 29110. CM.4.
CM.5.
CM.8.
Propuesta [33] P.[34].1.
P.[34].9.
Propuesta [34] P.[34].7.
GCSA.A7 Descripción: CMMI-DEV. SP 3.2.
Proceso de monitoreo. IEEE 828 - 2012. 10.2.2.
11.2.1.
11.2.2.
11.2.3.
Paquete de implementación de SCM basado en la N/A
norma ISO/IEC 29110.
Propuesta [33] N/A
Propuesta [34] P.[34].5.
Tabla 34. Actividades integradas.

3.1.3.4 Análisis de resultados.

Después de aplicar el método de integración a las actividades relacionadas a cada uno
de los modelos que fueron estudiados, se realizó un análisis cuantitativo que permitió
identificar el número de actividades relacionadas a cada propuesta con relación al
resultado obtenido en la integración.

Tomando como criterio de análisis la cantidad total de actividades relacionadas a cada

actividad unificada, se observa a priori que la actividad GCSA.A6 fue integrada como
resultado de la relación entre veinte (20) actividades relacionadas, lo cual permite
identificar que dicha actividad es la que ha sido descrita en mayor detalle en cada uno
de los modelos o estudios relacionados. Por otro lado, las actividades unificadas
GCSA.A1, GCSA.A2 y GCSA.A7 con un total de siete (7) actividades relacionadas
representan las actividades que han sido descritas con un nivel intermedio de detalle,
seguido por la actividad unificada GCSA.A4 con un total de cuatro (4) actividades
relacionadas, y finalmente la actividad unificada GCSA.A5 no contiene ninguna
actividad relacionada a los modelos y estudios relacionados, por lo cual es necesario
definir la actividad en términos del modelo base.

A continuación, en la Tabla 35 se muestra la cantidad de actividades relacionadas a

cada modelo o propuesta con relación al resultado de aplicar el método de integración
y el total de actividades integradas para la definición de cada actividad integrada.

Activ idad CMMI- IEEE Paquete de implementación Propuesta Propuesta Total

Unificada DEV 828- basado en la norma ISO/IEC 29110 [33] [34]
2012
GCSA.A1 1 4 1 0 1 7
GCSA.A2 1 4 1 0 1 7
GCSA.A3 2 1 1 0 2 6
GCSA.A4 0 0 0 2 2 4
GCSA.A5 0 0 0 0 0 0
GCSA.A6 3 11 4 2 1 20
GCSA.A7 2 4 0 0 1 7
Tabla 35. Cantidad de actividades integradas.

Las actividades propuestas que se obtuvieron como resultado de aplicar los métodos
de homogeneización, comparación e integración serán descritas con mayor detalle en
el Capítulo V. Progresconfig.

38
3.2 Sesgos de la armonización de los modelos
analizados.
Debido a la naturaleza del estudio realizado para la definición del proceso existe un
grado de subjetividad que debe ser considerado para el análisis de los resultados
obtenidos. Por lo cual, para llevar a cabo este trabajo de investigación se ha
disminuido el grado de subjetividad mediante la aplicación de técnicas de análisis
cuantitativas para cada una de las etapas de armonización. Asimismo, las fases de
armonización y posterior definición del proceso han sometidas a validación de dos
expertos en el área de mejora de procesos y armonización de múltiples modelos, los
cuales hacen parte de este trabajo de investigación como asesores externos y han
realizado la validación de las actividades y la toma de decisiones en la definición del
proceso.

39
 Capítulo IV. SCMOnto:
Ontología para soportar la
gestión de la configuración de
software.
En este capítulo se presenta SCMOnto: una ontología para soportar la gestión de la
configuración de software. Esta ontología nace como solución al problema que
representa la heterogeneidad y ambigüedad detectada en los términos relacionados a
la gestión de la configuración de software en los modelos armonizados en el capítulo
anterior.

4.1 Motivación para la definición de SCMOnto.

Según [46], una ontología es una especificación explícita de una conceptualización
alrededor de un área de conocimiento. De esta manera, cuando el conocimiento de un
área de dominio específica es representado formalmente, el conjunto de objetos que
pueden ser representados y relacionados en él es llamado “universo del discurso”, y
es el principal insumo para el diseño y realización de una ontología. En particular, una
de las principales motivaciones para diseñar y definir SCMOnto es construir un
universo del discurso totalmente estructurado, claro y unificado alrededor de la gestión
de la configuración.

Por otra parte, es necesario resaltar la importancia de las ontologías en el campo de la

investigación en general y aplicada a la informática. De acuerdo con [47], las
ontologías se han utilizado especialmente de manera fructífera en el área de la
informática debido a que brindan beneficios como:

 Permiten reutilizar y compartir el conocimiento de manera organizada,

brindando un protocolo específico y único de comunicación y entendimiento de
un universo del discurso en particular.
 Unifican conceptos de un mismo campo del conocimiento definidos a través de
diferentes investigaciones y estudios, de manera que provee una base sólida
para la representación del conocimiento en dicha área facilitando: trabajos
futuros, la recuperación de información, su integración e interoperabilidad de
fuentes heterogéneas de conocimiento.
Además, el análisis ontológico brinda una estructura al conocimiento debido a que
establece un dominio de términos y relaciones que conforman el núcleo del área de
investigación, así, sin ontologías no podría existir un vocabulario definido para
representar el conocimiento de manera formal [48].

Posterior al análisis del marco teórico, estado del arte y después de aplicar el proceso
de armonización de modelos y propuestas relacionadas que utilizan SCM, se
evidenció que existe heterogeneidad y ambigüedad en las definiciones existentes, por
lo cual, fue necesario llevar a cabo la definición de una ontología que permita aclarar
todos los conceptos que no son claros y que sirva como base para la creación de un
proceso unificado, el cual es caracterizado en el siguiente capítulo.

40
4.2 Diseño y propuesta de la ontología.
A continuación, se presenta SCMOnto, una ontología que unifica los conceptos
relacionados a la gestión de la configuración de software desde la perspectiva de la
gestión de proyectos software.

Los conceptos y términos utilizados para la definición de SCMOnto que no representan

definiciones propias de esta investigación, han sido extraídos y/o adaptadas d e los
modelos relacionados a la gestión de la configuración de software que fueron objeto
de estudio durante la realización del marco teórico y estado del arte, tales como:
CMMI-DEV [13], IEEE 828-2012 [12] e ISO/IEC 15504 [49]. Asimismo, la Tabla 37
muestra el consolidado de fuentes de conocimiento utilizadas para la definición de
SCMOnto; es posible evidenciar que se han incluido diferentes fuentes de
conocimiento además de los modelos anteriormente mencionados, esto debido a que
fueron fundamentales para contextualizar el uso de la ontolo gía y la identificación de
relaciones entre conceptos.

4.2.1 Metodología empleada para la definición de la

ontología.
En la actualidad, existe un amplio abanico de metodologías que proponen un enfoque
sistemático para el diseño y definición de ontologías, así como: Methontology [50], A
Translation Approach to Portable Ontology Specifications [51], Ontology-based
knowledge management [52], REFSENO (Representation Formalism for Software
Engineering Ontologies) [53], entre otros. Después de realizar la revisión de dichas
propuestas y estudiar su posible aplicación a la definición de SCMOnto, se decidió
utilizar REFSENO [53] tomando en cuenta los siguientes criterios:

 REFSENO, a pesar de estar basada en Methontology, una metodología

ampliamente utilizada para la definición de ontologías de diferentes campos del
conocimiento propone una adaptación específica para su aplicación para el
diseño de ontologías de ingeniería del software.
 REFSENO define diferentes mecanismos de análisis y presentación de la
solución a nivel de conceptos, atributos y relaciones. Esto es posible debido a
que REFSENO propone tres tablas para representar dichos elementos:
glosario de conceptos, atributos y relaciones.
 A diferencia de otros enfoques, REFSENO provee numerosas técnicas para el
análisis de la consistencia de la ontología e instancias a nivel de
implementación. Además, REFSENO permite realizar una caracterización entre
los niveles de conocimiento conceptual y de contexto específico; de esta
manera, REFSENO representa una alternativa más intuitiva para lectores que
no estén familiarizados con lógica de predicado de primer orden o similares.
REFSENO define cuatro (4) etapas que se deben seguir para llevar a cabo la
definición de una ontología:

1. Planeación.
2. Especificación de los requerimientos de la ontología.
3. Conceptualización (equivalente al diseño de la ontología)
4. Implementación (representación y almacenamiento de la conceptualización
previa utilizando una herramienta computacional).

41
4.2.2 Presentación de la propuesta.
Con el fin de llevar a cabo un proceso organizado de definición de SCMOnto, fue
necesario hacer una especificación de requerimientos que representa los elementos
necesarios para identificar aspectos relevantes de la ontología a desarrollar. A
continuación, en la Tabla 36 se presenta la especificación de requerimientos de
SCMOnto.

Concepto Valor
Dominio Gestión de la configuración de software.
Autores Juan Sebastián Vásquez Cantero, Carlos Eduardo Orozco Garcés, César Je sús Pardo
Calvache, Francisco José Pino Correa.
Propósito Unificar y clarificar los términos relacionados a la gestión de la configuración de
software, sus relaciones y posibles contextos de utilización impulsando así la
divulgación del conocimiento.
Niv el de formalidad Semi-formal (MOF: Modelo y representación mediante tablas propuestas en
REFSENO).
Alcance Se ha desarrollado la ontología SCMOnto (del inglés, Software Configuration
Management Ontology)
Fuentes de conocimiento Ver Tabla 37.
Tabla 36. Especificación de requerimientos de SCMOnto.

SCMOnto ha sido propuesta utilizando principalmente MOF (Meta–object facility) junto

a una representación gráfica utilizando diagramas UML (Unified Modeling Language).
Además, la representación gráfica es complementada mediante la representación
textual semi-formal basada en el formalismo REFSENO.

La definición de SCMOnto fue realizada adaptando el flujo de trabajo propuesto por

REFSENO para que represente solo los elementos más importantes en un modelo
simplificado. A continuación, se describen los aspectos que no se han tenido en
cuenta para la definición de SCMOnto:

 No se consideraron los constructores REFSENO que hacen referencia a

aspectos de la etapa de implementación física de una ontología, tales como
tablas de instancias o funciones de similitud.
 Algunos elementos que REFSENO pretende identificar, como el valor por
defecto y el valor de inferencia e inferido, han sido omitidos dada la falta de
información sobre esos ítems.
Para llevar a cabo la definición de SCMOnto, es necesario relacionar un conjunto de
fuentes de conocimiento que son los elementos de entrada para la aplicación de la
ontología. A continuación, en la Tabla 37 se presenta el consolidado de fuentes de
conocimiento utilizadas como insumo para SCMOnto y que proveen toda la
información necesaria para llevar a cabo la definición y desarrollo de la misma.

No. Fuente. Referencia

relacionada.
1 IEEE 828-2012. [12]
2 CMMI-DEV. [13]
3 Evolving a Software Configuration Management Ontology. [54]
4 Uma Ferramenta de Gerência de Configuração Integrada a um Ambiente de [55]
Desenvolvimento de Software.
5 ISO/IEC 15504. [49]
6 A reference ontology for harmonizing Process reference models. [56]
7 An ontology for the harmonization of multiple standards and models [57]
Tabla 37. Fuentes utilizadas para la definición de SCMOnto.

Además de las fuentes de conocimiento mencionadas anteriormente, SCMOnto utiliza

dos sub-ontologías que aportan conceptos y relaciones entre conceptos a su definición
para complementar el contexto de la gestión de la configuración desde la perspectiva

42
del proyecto y en calidad de área de proceso; estas sub-ontologías han sido
presentadas en los estudios relacionados: A reference ontology for harmonizing
Process reference models (PrMO) [56] y en Evolving a Software Configuration
Management Ontology (EvSCMO) [54]. Como resultado, SCMOnto ha sido diseñada a
partir de 3 componentes básicos:

1. Recolección y definición de términos a través de los modelos

seleccionados tras la revisión sistemática de la literatura (CMMI-DEV [13],
IEEE 828-2012 [12] e ISO/IEC 15504 [51]): Este es el principal componente
para la definición de SCMOnto, representa el trabajo realizado al identificar y
establecer los conceptos a incluir en la ejecución de este proyecto.
2. PrMO [56]: Es la sub-ontología utilizada para incluir términos propios de la
armonización de múltiples modelos y mejora de procesos software (SPI 14 ).
Además, los términos incluidos a partir de esta sub-ontología representan el
enlace a una posible versión extendida que muestre SCM desde la perspectiva
del área de proceso.
3. EvSCMO [49]: Sub-ontología de gestión de la configuración de software que
presenta la evolución y actualización de la ontología definida en Uma
Ferramenta de Gerência de Configuração Integrada a um Ambiente de
Desenvolvimento de Software [55], una ontología definida de carácter
netamente técnico. Este trabajo relacionado representa el enlace a una posible
versión extendida que muestre a la GCS desde la perspectiva técnica del
desarrollo de software en conjunción con los términos propios de la perspectiva
del proyecto.
Las definiciones precisas de los conceptos incluidos en SCMOnto son presentadas en
la Tabla 38, en la Tabla 39 y en la Tabla 40, las cuales han sido organizadas en cuatro
(4) columnas de la siguiente manera: la primera y segunda columna muestran el
término que será descrito y su súper concepto respectivamente; dichos súper
conceptos son términos que representan una generalización de otro concepto, motivo
por el cual también están descritos en estas tablas. Asimismo, la tercera y cuarta
columna muestran la definición del término y la fuente relacionada de donde este se
extrajo en caso de no ser una definición propia de la propuesta. Particularmente, la
cuarta columna posee un dominio definido de los posibles valores que podría tomar; a
continuación, se describe dicho dominio:

1. Tomado de [<<Referencia>>]: Indica que la definición del término ha sido

utilizada exactamente como fue definida en la fuente (referencia), es decir, no
se realizó modificación alguna o se alteró su contenido.
2. Adaptado de [<<Referencia>>]: Indica que la definición mostrada en la
segunda columna es una adaptación de la definición original extraída de la
fuente (referencia) indicada.
3. Definición propia: Indica que la definición mostrada en la segunda columna
representa una nueva propuesta a partir de la investigación realizada.
Los conceptos presentados en la Tabla 38, la Tabla 39 y la Tabla 40 han sido
organizados en diferentes tablas debido a que se han categorizado según el
componente básico del cual han sido extraídos: (i) Recolección y definición de
términos a través de los modelos seleccionados tras la r evisión sistemática de la
literatura, (ii) PrMO [56] y (iii) EvSCMO [49].

14
SPI del inglés, Softw are Process Improvement

43
La Tabla 41 presenta las relaciones identificadas entre los términos utilizados en la
definición de SCMOnto. La estructura de esta tabla está conformada por 3 columnas:
nombre, que indica el nombre que se le ha dado a la relación; conceptos, que presenta
los conceptos que se han relacionado; y descripción, una breve descripción de la
relación presentada.

Las tablas mencionadas anteriormente conforman el resumen de la representación

formal basada en REFSENO para la caracterización de SCMOnto a través de la
descripción de sus conceptos. Adicionalmente, la Figura 1 muestra la representación
gráfica de los conceptos y las relaciones de SCMOnto mediante la utilización de la
notación de diagramas UML.

Términos utilizados en SCMOnto

Término Súper Definición Fuente
concepto
Auditoría Revisión objetiva de un producto o un conjunto de productos de Tomado de
Concepto
(Audit) trabajo con respecto a un criterio específico. [13]
Auditoría de
configuración Auditoría realizada para verificar que uno o más elementos de
Adaptado
(Configuration Auditoría configuración que conforman una línea base cumplen con una
de [13]
audit) norma o requisito especificado.

Auditoría de Auditoría realizada para verificar que un ítem de configuración

configuración física
Auditoría de (por ejemplo, un elemento software) es consistente con la Adaptado
(physical configuración documentación técnica que lo define. de [12]
configuration
audit)
Auditoría de Auditoría realizada para verificar que: (i) el desarrollo de un ítem
configuración de configuración ha sido completado satisfactoriamente, (ii) que
funcional Auditoría de el ítem ha logrado el desempeño y las características Adaptado
(functional configuración funcionales especificadas en la identificación de la config uración de [12]
configuration funcional, y (iii) que es operacional, con documentos de
audit) soportes completos y satisfactorios.
Autoridad de
gestión de la Persona o grupo designado como responsable de asegurar que
configuración las actividades de gestión de la configuración son planeadas y Tomado de
Persona
(configuration llevadas a cabo correctamente. Es el responsable de la [12]
management implementación del proceso.
authority)
Base de datos de Tipo específico de repositorio para todo tipo de información
gestión de la relacionada a gestión de la configuración, usualmente es usado
configuración un almacén de datos para registrar atributos de ítems de Adaptado
Repositorio
(Configuration configuración y las relaciones entre los mismos durante todo de de [12]
Management su ciclo de vida.
Database)
Comisión de Grupo de personas responsables de la evaluación y aprobación,
control de la
o desaprobación, de los cambios propuestos a determinados Tomado de
configuración Persona ítems de configuración y de asegurar la implementación de [12]
(Configuration dichos cambios.
control board)
Construcción Versión operacional de un sistema o componente que incorpora
(Build) un subconjunto de capacidades que el producto final proveerá.
En software, este término hace referencia al procesamiento de Adaptado
Concepto archivos fuente de manera similar a la compilación; en de [12]
hardware, este término hace referencia al ensamblado un objeto
físico.
Contabilidad de Elemento de gestión de la configuración que consiste en el
estado de registro y reporte de información necesaria para gestionar
configuración efectivamente una configuración. Tomado de
Concepto
(Configuration Esta información incluye el estado de la configuración aprobada, [13]
Status el estado de los cambios propuestos en la configuración y el
Accounting) estado de implementación de los cambios aprobados.
Control de la Elemento de gestión de la configuración que consiste en la
configuración evaluación, coordinación, aprobación o no aprobación, e Tomado de
(Configuration Concepto implementación de cambios a los ítems de configuración
[13]
Control) después del normal establecimiento de su identificación de la
configuración.
Elemento software Componente identificable de un producto software como: Adaptado
Concepto
(Softw are ítem) códigos fuente, códigos de control, datos de control o de [12]

44
 colecciones de estos mismos.
Evaluación
Utilizada para revisar o verificar actividades y productos de
objetiva Adaptado
Concepto trabajo con respecto a un criterio predefinido para minimizar la
(Obj ectiv ely de [13]
subjetividad y la parcialidad del revisor.
ev aluate)
Gestión de entrega Gestión de todas las acti vidades alrededor de la entrega de una
de software o más versiones de software a uno o más clientes, incluyendo Tomado de
Concepto
(Softw are release identificación, empaquetado, y entrega de los elementos del [12]
management) producto.
Gestión de la Disciplina que aplica dirección y vigilancia técnica y
configuración administrativa para: (i) Identificar y documentar las
(Configuration características físicas y funcionales de un ítem de configuración, Tomado de
Management) Concepto (ii) controlar los cambios en sus características, (iii) registrar y
[12], [13]
reportar el procesamiento de cambios y el estado de
implementación, y (iv) verificar el cumplimiento de los
requerimientos especificados.
Identificación de la Elemento de gestión de la configuración que consiste en la
configuración selección de los ítems de configuración para un producto,
Tomado de
(Configuration Concepto asignando identificadores únicos a ellos, y registrando sus
[13]
identification) características físicas y funcionales en documentación técnica.

Ítem de
Conjunto de productos de trabajo designados para gestión de la
configuración Tomado de
Concepto configuración y tratados como una sola entidad en el proceso de
(Configuration [12], [13]
gestión de la configuración.
Item)
Ítem de
Elemento individual que controlar dentro de la gestión de la
configuración
configuración que hace parte de un ítem de configuración más
constituyente Tomado de
Concepto grande, tal como un modelo de referencia, prototipo hardware o
(Constituent [12]
una versión de software.
configuration
ítem)
Lanzamiento Versión entregada de una aplicación que pudiera incluir toda o
(Release) parte de la funcionalidad objetivo, y que además se encuentra Adaptado
Concepto
disponible para una porción más amplia de público. de [2]

Línea base Conjunto de especificaciones o productos de trabajo que han

(Baseline) sido revisados y aceptados formalmente, los cuales sirven como
Adaptado
base para futuros desarrollos, y pueden ser cambiad os solo a
Concepto de [12],
través de procedimientos de control de cambios. Este término
[13]
también podría referirse a una versión concreta de un ítem de
configuración que ha sido revisada y aprobada.
Línea de producto Grupo de productos/servicios que comparten un conjunto de
/ servicio características en común, siendo este un conjunto administrado
(Product line) de características que satisfacen necesidades específicas de un Adaptado
Concepto
mercado o misión en específico y que, además, se desarrollan a de [13]
partir de un conjunto común de activos básicos de la empresa y
de manera predefinida.
Persona - Recurso Cualquier sujeto que realiza o desempeña un rol determinado
(person - dentro de la organización software; por ejemplo: Tester,
Definición
resource) Concepto desarrollador, analista, miembro de comisión de control de la
propia
configuración, autoridad de gestión de la configuración, director
de proyecto, entre otros.
Petición de cambio Propuesta formal de modificación de un ítem de configuración
(Change de cualquier manera. Esta petición debe ser lo suficientemente Definición
Concepto
Request) detallada para que sea entendida fácilmente y no genere propia
ambigüedad para sus revisores y/o desarrolladores.
Plan de Plan que describe las partes de funcionalidad del sistema que
lanzamiento serán implementadas en cada entrega, así como razón
(Release plan) fundamental de cada una de las mismas. Este plan incluye Adaptado
Concepto
referencias a la descripción de los contenidos de la entrega, de [12]
calendario de entregas, impacto de entregas y notificaciones de
entrega.
Producto Producto de trabajo del equipo de proyecto. Puede estar
(Product) destinado a ser entregado al usuario final o puede ser llevado a Adaptado
Concepto cabo como producto de trabajo interno del proyecto. de [13]

Repositorio Colección de todos los artefactos relacionados a software Tomado de

Concepto
(Repository) pertenecientes a un sistema. [12]
Requerimiento de Resultado de la elicitación, consolidación y resolución de
cliente conflictos entre las necesidades, expectativas, restricciones, e Tomado de
Concepto
(Customer interfaces de los interesados relevantes del producto de tal [13]
requirement) manera que sea aceptable para el cliente.
Técnico de Encargado de materializar las peticiones de cambio que han
Definición
configuración Persona sido aprobadas por la comisión de control de la configuración. propia
(Configuration Es el responsable visible de la correcta realización de una

45
 Technical) petición de cambio aprobada.
Tabla 38. Conceptos utilizados en SCMOnto.

Términos extraídos de Uma Ferramenta de Gerência de Configuração [55]

Término Súper Definición Fuente
concepto
Versión Variación de un elemento de configuración desarrollado posteriormente sin
Adaptado
(v ersión) Concepto las restricciones o limitaciones impuestas inicialmente. Por ejemplo: Versión
de [55]
1.0 de un documento, versión 6.0 de una herramienta CASE.
Tabla 39. Términos extraídos de [55].

Términos extraídos de: A reference ontology for harmonizing process reference models [43]
Término Súper Definición Fuente
concepto
Categoría de
proceso Tomado
Concepto Una categoría de proceso comprende procesos interrelacionados.
(Process de [43]
category)
Modelo de
Conjunto de conceptos medibles y las relaciones entre ellos que
calidad Tomado
Concepto proporcionan la base para especificar requisitos de calidad y evaluar la
(Quality de [43]
calidad de las entidades de una clase de entidad dada.
model)
Proceso Conjunto coherente de políticas, estructuras organ izativas, tecnologías,
(Process) procedimientos, propósitos, objetivos y productos de trabajo que son Tomado
Concepto
necesarios para diseñar, desarrollar, implementar y mantener un producto de [43]
de software.
Tabla 40. Términos extraídos de [43].

Relaciones entre conceptos utilizadas en SCMOnto

Nombre Conceptos Descripción
Un repositorio almacena muchas versiones. Una
Almacena Repositorio – Versión versión es almacenada en un repositorio.
Contabilidad de estado
La contabilidad de estado de configuración es
Almacenada en de configuración –
almacenada en una Base de datos de CM.
Base de datos de CM
Un lanzamiento es almacenado en un
Lanzamiento –
Almacenado en repositorio. Un repositorio puede almacenar
Repositorio
muchos lanzamientos.
Auditoría – Evaluación Una auditoría se basa en una evaluación
Basada en objetiva objetiva.
Identificación de la
La identificación de la configuración clasifica a
Clasifica configuración –
muchos elementos software.
Elemento software
Control de la
El control de la configuración controla los ítems
Controla configuración – Ítem de
de configuración.
configuración.
Gestión de la El proceso de Gestión de la configuración (CM)
configuración –
Define define una autoridad de CM. Una autoridad de
Autoridad de gestión de CM es definida por el proceso de CM.
la configuración
CM define uno o más planes de lanzamiento.
CM – Plan de
Define Uno o más planes de lanzamientos son
lanzamiento
definidos dentro del proceso de CM
Una auditoría es almacenada en una Base de
Auditoría – Base de
Es almacenada en datos de CM. Una base de datos de CM puede
datos de CM almacenar muchas auditorías.
El rol de autoridad de CM es el responsable de
Autoridad de gestión de
la correcta implementación del proceso. El
Es responsable de la configuración –
proceso es responsabilidad de la autoridad de
Proceso
CM.
El proceso de CM establece una o más líneas
Establece CM – Línea base base. Una línea base es establecida por el
proceso de CM
El proceso de CM establece un control de la
CM – Control de la
Establece configuración. Un control de la configuración es
configuración
establecido por un proceso de CM.
La identificación de la configuración es
CM - Identificación de
Establece establecida por CM. CM establece la
la configuración
identificación de la configuración
CM establece un área de Contabilidad de
CM – Contabilidad de
Establece estado de configuración. El área de contabilidad
estado de configuración de estado de configuración es establecida por

46
 CM.
La comisión de control de la configuración
Comisión de control de evalúa de cero a muchas peticiones de cambio
Ev alúa la configuración – para aprobarlas o no. Una petición de cambio es
Petición de cambio evaluada por una comisión de control de la
configuración.
Un plan de lanzamiento genera lanzamientos.
Plan de lanzamiento –
Genera Un lanzamiento es generado por un plan de
lanzamiento lanzamiento.
Un proceso genera de uno a muchos productos.
Genera Proceso – Producto Un producto es generado por un y solo un
proceso.
La gestión de entrega de software es quien
Gestión de entrega de gestiona a uno o más productos. Los productos
Gestiona software – Producto son gestionados por la gestión de entrega de
software.
Identificación de la
La identificación de la configuración identifica a
Identifica configuración – Ítem de
los ítems de configuración.
configuración
CM incluye una o más a auditorías dentro del
Incluye CM – Auditoría proceso. Una o más auditorías son incluidas
dentro de un proceso de CM
Un técnico de configuración lleva a cabo una o
Técnico de
muchas peticiones de cambio. Una petición de
Llev a a cabo configuración – Petición
cambio es llevada a cabo por un técnico de
de cambio
configuración.
Un plan de lanzamiento planea la gestión de
Plan de lanzamiento –
entrega de software. La gestión de entrega de
Planea Gestión de entrega de
software es planeada por uno o más planes de
software
lanzamiento.
Una línea base puede ser un proceso. Un
Puede ser Línea base – Proceso proceso puede ser tomado como una línea
base.
Una petición de cambio puede ser realizada
Petición de cambio – sobre uno o más ítems de configuración. Un
Se realiza sobre Ítem de configuración ítem de configuración puede recibir cero o más
peticiones de cambio.
Una persona es quien solicita una petición de
Persona – Petición de
Solicita cambio. Una petición de cambio es solicitada por
cambio
una y solo una persona.
Producto – Un producto soluciona uno o más requerimientos
Soluciona requerimiento de del cliente. Un requerimiento del cliente puede
cliente ser solucionado por uno o más productos.
Tabla 41. Relaciones utilizadas en SCMOnto.

Con el objetivo de presentar la Figura 1 en un espacio más acorde a sus dimensiones

y tamaño, ha sido ubicada en modo apaisado ocupando la totalidad de la siguiente
página de este documento.

47
 Versión
1..1 Auditoría de configuración
0..* Almacena funcional
0..*
Repositorio
0..*
Auditoría de configuración física
Convenciones
Construccion (Build) 1..1
Base de datos de gestión

48
de la configuración 1..1 SCMonto
Convenciones
0..*
Almacenado en EvSCMO PrMO
1..* Auditoría de configuración
Lanzamiento (release) 1..1
1..1
1..1 Almacenada en
0..* 1..*
Contabilidad de estado Es almacenada en
de configuración
Auditoría Evaluación
1..1 Objetiva

Figura 1. Representación gráfica mediante diagramas UML de los

Genera 1..1
Plan de lanzamiento 1..*
1..1 1..*
1..*
1..* 1..1 Se basa en
Planea
Gestión de entrega de software
1..1 1..1
1..1 Incluye
Define Establece
1..1 Gestión de la configuración 1..1 Autoridad de gestión de la configuración

conceptos y relaciones de SCMOnto.

Gestiona Requerimiento de cliente Define 1..1
1..*
1..1 1..1 1..1
Establece Establece Establece
1..1
Es responsable de
1..1 1..1
Identificación de la Control de la configuración
1..* 1..1 configuración
Soluciona Identifica
Línea de producto/servicio
1..* 1..1
1..* 1..1 1..1
Producto
1..* 1..* Clasifica Controla 1..1 Área de proceso
Proceso 1..*
Genera Pertenece a
1..* 1..*
Comisión de control 0..*
de la configuración 0..* 0..*
Ítem de configuración 1..1 1..*
1..1 0..*
1..* Está relacionado con
0..1
1..1
0..1 Evalúa 0..* Línea base 1..1
0..1 Define
1..* 1..1
Elemento software
Modelo de calidad
0..* 1..1
Puede ser
Petición de cambio 0..*
0..*
Se realiza sobre Elemento de configuración
constituyente
0..* 1..* Técnico de configuración
1..1
Lleva a cabo
1..1
Solicita Persona
1..*
4.2.3 Discusión.
Algunos de los términos que conforman la propuesta de SCMOnto merecen un análisis
especial para clarificar su contexto de utilización e inclusión dentro de esta ontología.
En este apartado se realiza el análisis y definición de dichos términos especiales, tales
como: Producto, Técnico de Configuración, Autoridad de gestión de la configuración y
Comisión de control de la configuración.

 Producto: De acuerdo con PrMO [43], un producto está definido como el

conjunto de artefactos a ser desarrollados, entregados y mantenidos en un
proyecto. A pesar de esto, la definición utilizada en SCMOnto ha sido extraída
de CMMI [13], esto debido a que su aplicación dentro del contexto de la gestión
de la configuración pudiera brindar una mayor utilidad explicitando que un
producto puede ser un entregable a cliente o puede ser utilizado como insumo
interno del proyecto. Es importante aclarar que la definición brindada por PrMO
es complementaria y no excluyente a la definición utilizada en esta propuesta.
 Técnico de configuración: El técnico de gestión de la configuración es una
especialización del concepto „Persona‟. Se ha definido como un rol especial
para todo aquel miembro de proyecto que se vea involucrado en la
modificación, actualización y/o alteración de un ítem de configuración tras la
aprobación de una petición de cambio. Es importante reflexionar acerca de la
naturaleza de este rol, debido a que dentro del proyecto es desempeñado por
diferentes personas en diferentes instantes de tiempo, esto en función de sus
aptitudes y los ítems de configuración que tengan bajo su responsabilidad, así,
no representa un rol estático dentro de la organización.
 Autoridad de gestión de la configuración: A nivel de proyecto, es el rol
responsable de la correcta planeación e implementación del proceso de gestión
de la configuración. La autoridad de gestión de la configuración personifica al
experto, es visto como el mentor y orientador del proceso de GCS, y no como
la persona encargada de la toma de decisiones de manera arbitraria.
 Comisión de control de la configuración: La comisión de control de la
configuración es otra de las especializaciones del concepto „Persona‟ que se
han definido en SCMOnto. Este rol es desempeñado por un grupo de personas
encargadas del estudio de cada una de las peticiones de cambio que surjan
para un ítem de configuración dentro del proyecto; son los responsables de
aprobar o rechazar dichas peticiones y de asegurar su realización en caso de
resultar aprobadas. Es un rol especialmente importante ya que define el rumbo
y estado actual de cada uno de los ítems de configuración mediante la
aprobación de las líneas base destinadas a despliegue en ambientes de
producción [12].

4.3 Validación teórica de la ontología.

Como método de evaluación de la ontología definida, se decidió realizar una validación
teórica mediante la instanciación de SCMOnto utilizando un software de
procesamiento del lenguaje OWL 15 de manera similar a la técnica de validación
utilizada en [41]. Como herramienta de modelado y validación se utilizó Protégé [58],
debido a su frecuente utilización para la construcción y representación de ontologías,
sin perder de vista que ofrece un amplio abanico de plugins gráficos que apoyan la
correcta visualización de contenidos.

15
Lenguaje de ontologías w eb, del nombre en inglés Web Ontology Language

49
La Figura 2 muestra un segmento de la instancia de SCMOnto creada utilizando
Protégé. Las entidades instanciadas han sido creadas tomando como base al proceso
presentado en el siguiente capítulo. En la Figura 2 también es posible observar cómo
algunos de los conceptos representados tienen influencia directa o indirecta en otros
conceptos mediante la correcta representación de las relaciones anteriorme nte
definidas y descritas en la Tabla 41, lo que permite apreciar que la ontología definida
provee un correcto soporte a la representación de los conceptos utilizados en este
dominio, más concretamente en el universo del discurso relacionado a la gestión de la
configuración de software. Las líneas punteadas representan las relaciones entre
conceptos, asimismo, las líneas continuas representan herencia entre conceptos, por
ejemplo: el concepto de línea base es una especialización del concepto ítem de
configuración.

Figura 2. Segmento extraído de la instancia de SCMOnto utilizando Protégé.

Para la construcción de la representación mostrada en la Figura 2, se utilizó el plugin

gráfico GraphViz [59], base para la visualización de ontologías en Protégé; también fue
necesario complementar dicha representación con el plugin gráfico OntoGraf [60],
responsable de la creación visual de las entidades, así como de sus relaciones.

El segmento extraído de la instancia creada a partir de SCMOnto presentado en la

Figura 2, es el relacionado al control de la configuración, uno de los principales
componentes de la gestión de la configuración de software a nivel de control de los
artefactos y estados generados a partir del proceso de desarrollo de un producto, esto
realizado desde la perspectiva del proyecto.

Como complemento a esta validación, se desarrolló un ejemplo teórico de aplicación

de SCMOnto mostrado a continuación.

50
4.4 Ejemplo de aplicación de la ontología.
A continuación, se presenta un ejemplo teórico de aplicación de algunos de los
conceptos incluidos en SCMOnto. Dichos conceptos se podrán apreciar en letra
cursiva:

Una MiPyME_DS fuertemente interesada en incrementar la calidad de sus productos,

ha fijado su atención en la inclusión de mejores prácticas en su proceso de desarrollo
de software, esto bajo la motivación de llevar a cabo procesos más controlados,
organizados y de acuerdo con estándares y modelos de calidad reconocidos
internacionalmente que brinden características de madurez a su empresa. De esta
manera ha decidido adoptar prácticas propias de gestión de la configuración de
software.

Así, inicialmente la empresa deberá identificar: (i) elementos de proceso primordiales

que constituyen a la gestión de la configuración, tales como Identificación de la
configuración y Control de la configuración, y (ii) aquellos artefactos en los que se
basará dicha área de proceso, así como: líneas base, ítems de configuración, y sus
respectivos repositorios, entre otros.

Una vez realizada una primera aproximación a la gestión de la configuración mediante

la identificación de elementos mencionada anteriormente, se deberán llevar a cabo
acciones relacionadas al control de dichos elementos críticos dentro del proceso. La
correcta gestión de estos artefactos es llevada a cabo a través del componente de la
GCS llamado Control de la configuración. Este componente comprende, como
principal elemento, al subproceso de petición de cambios, subproceso que define cada
una de las fases que una petición de cambio deberá atravesar desde su concepción,
hasta su posible implementación sujeta a aprobación por parte de la Comisión de
control de la configuración. Con relación a esto, es importante destacar la importancia
de la designación de los roles involucrados, tales como el técnico de configuración,
encargado de materializar cada una de las peticiones de cambio que hayan sido
aprobadas; y la autoridad de gestión de la configuración, persona responsable de la
correcta implementación del proceso. En especial, la autoridad de gestión de la
configuración cobra importancia debido a que representa al mentor y guía durante todo
el proceso de adopción de las mejores prácticas que define la gestión de la
configuración de software.

Finalmente, una MiPyME_DS que haya implementado un área de proceso tan

importante para su crecimiento como la relacionada a la GCS, muy probablemente
estará interesada en monitorear y evaluar constantemente el grado de cumplimiento
que sus artefactos están teniendo con respecto a las prácticas que propone esta
disciplina. Para llevarlo a cabo, la principal herramienta que la empresa tendrá serán
los dos tipos de auditoría de configuración que la GCS incluye: la auditoría de
configuración física y la auditoría de configuración funcional, ambas son utilizadas con
el propósito de verificar el estado y proceso de evolución de los artefactos
involucrados durante el proceso de construcción de software y el grado de
correspondencia con respecto a su documentación.

51
 Capítulo V. Progresconfig.
En este capítulo se presenta el proceso ágil para la gestión de la configuración de
software que puede ser implementado por MiPyMEs_DS como solución a la propuesta
planteada al inicio de este trabajo de investigación. Asimismo, y tomando como base
las actividades obtenidas durante la integración de los modelos que fueron objeto de
estudio en el Capítulo III. Armonización de modelos para la gestión de la configuración
se describe un proceso formal a través de un conjunto de definiciones, actividades,
tareas, artefactos de entrada y salida relacionados a cada actividad, y diagramas de
flujo relacionados a cada actividad tomando como base el patrón de procesos
propuesto por COMPETISOFT [42]. Además, este capítulo presenta la propuesta de
un conjunto de niveles de capacidad aplicables al proceso que servirán como guía
para que las empresas puedan adoptar el proceso de manera más sencilla.

5.1 Definición del proceso.

5.1.1 Alcance del proceso.

Progresconfig es un proceso para soportar la configuración de software aplicable en
micro, pequeñas y medianas empresas desarrolladoras de software. Sin embargo, se
debe tener en cuenta que el proceso puede ser aplicado si la empresa cuenta por lo
menos con tres (3) recursos para soportar los roles mínimos definidos por el proceso.
Además, el proceso propuesto ha sido definido originalmente para su aplicación
durante el proceso de desarrollo de software en empresas que fabriquen líneas
independientes de desarrollo, es decir, no ha sido definido para soportar líneas de
producción.

5.1.2 Plantilla para la definición de proceso.

Para la definición del proceso, se utiliza como base el patrón de procesos propuesto
por COMPETISOFT, la cual es adaptada agregando una nueva fila que representa el
nivel de capacidad en el cual se encuentra cada actividad según los niveles de
capacidad propuestos en este trabajo de investigación. En Tabla 42, se presenta la
plantilla utilizada para la definición del proceso:

Identificador. Acrónimo que representa el identificador único del proceso

Proceso. Nombre de proceso, precedido por el acrónimo establecido en la definición de
los elementos de la estructura del modelo de procesos.
Categoría. Nombre de la categoría a la que pertenece el proceso
Propósito. Objetivos generales medibles y resultados esperados de la implantación
efectiva del proceso.
Descripción. Descripción general de las actividades y productos que componen el flujo de
trabajo del proceso.
Obj etiv os. Objetivos específicos cuya finalidad es asegurar el cumplimiento del propósito
del proceso. Los objetivos se identifican como O1, O2, etc.
Responsabilidad y autoridad. Responsabilidad es el rol principal responsable por la ejecución del proceso.
Autoridad es el rol responsable por validar la ejecución del proceso y el
cumplimiento de su propósito.
Procesos relacionados. Nombre de los procesos relacionados.

Roles Inv olucrados y Competencias.

Abrev iatura. Rol. Competencias.

Abreviatura del rol Nombre del Descripción de las funciones y responsabilidades definidas para el rol.
rol

Activ idades

52
 Identificador de la activ idad 1. Nombre de la activ ida d 1
Niv el de capacidad Indica la clasificación de la actividad con respecto al nivel de
capacidad propuesto: (i) esencial, (ii) complementario, (iii) realizado.
Entradas:
Descripción de las entradas definidas para la actividad.
Responsables: Acrónimo que representa el Tareas: Descripción de cada una de las tareas asociadas a una
responsable asociado a una tarea. actividad.
Roles inv olucrados Descripción de la tarea 1
Roles inv olucrados Descripción de la tarea 2
Salidas
Descripción de las salidas defi nidas para la actividad
Diagrama de fluj o:
Diagrama que representa el flujo que sigue la actividad para ser realizada.
Tabla 42. Plantilla para la definición del proceso. Adaptado de [42].

5.1.3 Términos genéricos.

Además de los conceptos y relaciones definidos en la ontología descrita en el capítulo
anterior, en esta sección se definen algunos conceptos que son comunes a todos los
modelos y que son denominados términos genéricos, los cuales son tomados en
cuenta como referencia durante la definición del proceso. En la Tabla 43 se describen
los términos genéricos utilizados para la descripción del proceso y la referencia de la
cual fueron tomados:

Término Descripción Fuente

Proceso. Conjunto coherente de políticas, estructuras organizativas, tecnologías, Tomado de
procedimientos, propósitos, objetivos y productos de trabajo que son necesarios para SCMOnto
diseñar, desarrollar, implementar y mantener un producto de software.
Activ idad. Este concepto compromete un conjunto de tareas o acciones llevadas a cabo para Tomado de
producir, mantener y respaldar los objetivos del proceso. Una actividad incluye: [43]
procedimientos, estándares, políticas y objetivos para crear y modificar un conjunto d e
ítems de configuración.
Tarea. Es un elemento de proceso que define el trabajo hecho por uno o más roles. Una Tomado de
tarea es asociada con un conjunto de entradas y salidas. [43]
Sub-tarea. Cuando una tarea es compleja se divide en sub -tareas. Tomado de
[43]
Rol. Describe un conjunto o grupo de responsabilidades, deberes y habilidades requeridos Tomado de
para realizar una actividad específica. [43]
Recurso. Un recurso es un activo que el negocio necesita tener. En el campo de la ingeniería Tomado de
del software hay dos recurso s de principal importancia: Los desarrolladores y las SCMOnto
herramientas.
Herramienta. Las herramientas que automatizan la ejecución de ciertas actividades. Tomado de
[43]
Tabla 43. Términos genéricos.

De manera adicional, se definen los acrónimos utilizados para la creación del proceso,
los cuales sirven como apoyo para facilitar la descripción de cada uno de los
elementos de proceso involucrados en la caracterización. En la Tabla 44 se muestran
los acrónimos utilizados y su significado.

Acrónimo Significado
GCSA Gestión de la Configuración de Software Ágil:
Ax Actividad.
Tx Tarea
STx Sub tarea
Ex Entrada
Sx Salida
Tabla 44. Acrónimos.

53
5.1.4 Definición de roles.

5.1.4.1 Identificación de roles.

Para la definición de un proceso que involucre aspectos ágiles, fue necesario definir un
conjunto de roles que cumplan las funciones necesarias para llevar a cabo el proceso
en una empresa. Para ello, se decidió tomar como base los roles definidos en el
paquete de implementación de SCM basado en la norma ISO/IEC 29110. Además, se
identificaron los roles definidos en otros modelos de referencia y metodologías de
desarrollo como SCRUM y XP. Finalmente, se realizó una comparación para
determinar la correspondencia entre los roles definidos.

En la Tabla 45, se describen los roles identificados en el paquete de implementación

de SCM basado en la norma ISO/IEC 29110, los roles establecidos en SCRUM y XP,
para su posterior análisis con el objetivo de identificar similitudes entre los roles
propuestos.

Acrónimo Paquete de implementación de SCM basado en la norma ISO/IEC SCRUM XP

29110
AP Administrador del proyecto N/A N/A
Analista
DT Diseñador Development Developer
Equipo de trabajo Team
LT Líder técnico Scrum Master Coach
CL Cliente Stakeholder N/A
DP Dueño del producto Product Owner Manager
Tabla 45. Identificación de roles.

Durante el cruce entre los roles definidos en el paquete de implementación SCM

basado en la norma ISO/IEC 29110 con los roles propuestos por SCRUM y XP, se
detectó que SCRUM y XP proponen un rol equivalente que representa al dueño del
producto (Product Owner), el cual no es definido en el paquete de implementación de
SCM basado en la norma ISO/IEC 29110. Sin embargo, debido a que la propuesta
propone un enfoque ágil y este rol es de gran importancia para estos marcos de
trabajo, se decidió incluir un rol llamado “Dueño del producto”, el cu al es el equivalente
al Product Owner definido en SCRUM y el Manager definido en XP.

Para la definición del proceso fue necesario proponer un rol que sea responsable de
conocer el proceso y asegure que el proceso se está llevando a cabo de manera
correcta siguiendo los lineamientos propuestos, por lo cual, se propuso el rol
denominado “Experto en configuración”, el cual sería el equivalente al Líder técnico
propuesto en el paquete de implementación de SCM basado en la norma ISO/IEC
29110, al Scrum Master propuesto en SCRUM, y al Coach propuesto en XP.

Además de la identificación de roles que se relacionan de manera directa con el ciclo

de vida del proyecto, se definieron dos roles extra que fueron identificados durante el
desarrollo de la ontología presentada en el capítulo anterior y que hacen parte del
proceso de gestión de la configuración de software, los cuales son: el técnico de
configuración y la comisión de control de la configuración, Como resultado se
definieron los roles que se pueden ver en la Tabla 46:

54
 Acrónimo. Rol.
AP Administrador del proyecto.
ED Equipo de desarrollo.
DP Dueño del producto.
EC Experto en configuración.
TC Técnico de configuración
CCC Comisión de control de la configuración
Tabla 46. Roles propuestos que participan de manera directa en el proceso.

Para la definición de roles, también se identificaron aquellos recursos que no

participan de manera directa en el proceso pero que pueden iniciar una tarea de
petición de cambio. Como resultado, se identificaron dos (2) roles externos, los cuales
son: el cliente y los interesados, los cuales se pueden observar en la Tabla 47.

Acrónimo Rol.
IN Interesado.
CL Cliente.
Tabla 47. Roles propuestos que participan de manera indirecta en el proceso.

En total, se definieron cinco (5) roles que son comunes a cualquier proceso
involucrado al ciclo de vida del software en una empresa desarrolladora de software,
tres (3) roles que se relacionan directamente a actividades relacionadas con gestión
de la configuración y que son considerados de vital importancia para llevar a cabo el
proceso de manera correcta, y finalmente dos (2) roles que no participan de manera
directa en el proceso.

5.1.4.2 División de roles por tipo de empresa.

Un aspecto importante que se debió tener en consideración para la definición de los
roles fue la clasificación por tipo de empresa de acuerdo con la cantidad de recursos
humanos disponibles (ver Tabla 7). Por definición, es posible que una PyME o una
microempresa no tenga la cantidad de recursos suficientes para soportar todos los
roles propuestos, por lo cual fue conveniente identificar los roles necesarios que una
empresa debería contemplar para lograr aplicar el proceso. Como resultado, en la
Tabla 48, Tabla 49 y la Tabla 50 se describen los roles que deberían ser identificados
en una empresa de acuerdo con su tamaño para aplicar el proceso.

Tamaño. Cantidad de Roles Descripción

empleados. propuestos
Grande. Mayor o igual a 250. AP Una empresa grande o mediana contempla los suficientes
Mediana. Mayor o igual a 50 y ED recursos humanos para identificar todos los roles propuestos
menor a 250. DP para la aplicación del proceso.
EC
TC
CCC
Tabla 48. Roles definidos para una empresa grande o mediana.

Tamaño. Cantidad de Roles Descripción

empleados. propuestos
Pequeña. Mayor o igual a ED Una empresa pequeña puede prescindir de un dueño del producto.
10 y menor a 50. EC En su lugar, el rol propuesto para el dueño del producto puede ser
TC realizado por un miembro del equipo de desarrollo, por ejemplo: los
CCC analistas pueden actuar como dueño del producto.

El rol de administrador del proyecto puede ser llevado a cabo por el

experto en configuración designado por la empresa.
Tabla 49. Roles definidos para una empresa pequeña.

Tamaño. Cantidad de Roles Descripción

empleados.
Micro. Menor a 10. ED Debido a las características específicas de las MiPyMEs, se recomienda que
EC existan por lo menos tres (3) recursos disponibles, de los cuales:

55
 CCC  El equipo de desarrollo es conformado por todos los recursos
disponibles.
 El experto en configuración también puede cumplir con las tareas
asignadas al administrador del proyecto.
 La comisión de control de la configuración estaría conformada por
un miembro del equipo de desarrollo y el experto en configuración.
 El técnico de configuración puede ser cualquiera de los miembros
del equipo de desarrollo.
 Uno de los miembros del equipo de desarrollo debe cumplir con las
funciones soportadas por el dueño del producto, con el fin de
identificar y validar las solicitudes de cambio de los interesados y el
cliente.

Tabla 50. Roles definidos para una microempresa.

5.1.5 Definición de niveles de capacidad para

Progresconfig.
Según [13], los niveles de capacidad se aplican al logro de mejora de procesos de una
empresa en áreas de proceso individuales. Estos niveles son un medio para mejorar
incrementalmente los procesos correspondientes a un área de proceso definida. Para
la definición de Progresconfig han sido propuestos 3 niveles de capacidad: (i) esencial,
(ii) complementario y (iii) realizado. Los niveles definidos representan la segmentación
del conjunto de actividades que una empresa debería adoptar de manera incremental
para implementar el proceso propuesto en este documento. A continuación, se
describe cada uno de los niveles de capacidad propuestos:

 Nivel 1. Esencial: El nivel esencial es aquel que establece prácticas para

adoptar las actividades básicas que una empresa requiere para planear una
estrategia de gestión de la configuración e identificar todos los elementos que
son sensibles a configuración en un proyecto.
 Nivel 2. Complementario: El nivel complementario establece estrategias y
políticas para llevar a cabo el control de los cambios asociados a cada uno de
los ítems de configuración que han sido identificados dentro del proyecto.
 Nivel 3. Realizado: El nivel realizado es aquel que define prácticas para llevar
a cabo procesos de evaluación y auditoría para controlar la calidad y
trazabilidad de los ítems de configuración, con el fin de mantener la integridad
del sistema con el paso del tiempo.
A continuación, en la Figura 3 se puede observar una descripción simplificada de los
niveles de capacidad propuestos.

Figura 3. Niveles de capacidad propuestos.

Los niveles de capacidad han sido propuestos como guía para permitir a las empresas
identificar el nivel de implementación de Progresconfig. Debido a las diferentes
características que tienen las MiPyMEs_DS, es posible que el proceso deba ser

56
adoptado de manera incremental, por lo cual, Progresconfig ofrece la oportunidad de
adoptar un conjunto de actividades para que la adopción del proceso sea llevada a
cabo de una manera natural.

5.1.6 Visión general de la propuesta.

La propuesta ha sido diseñada para permitir a una empresa desarrolladora de software
aplicar un proceso de gestión de la configuración de software. A continuación, en la
Figura 4, se presenta una abstracción del problema que pretende solucionar la
propuesta:

Figura 4. Descripción del problema.

Como resultado de realizar una revisión detallada de la literatura y el estado del arte,
aplicar el proceso de armonización de múltiples modelos, la definición de una
ontología para soportar la gestión de la configuración de software, la caracterización
de roles por tipo de empresa y la definición de tres (3) niveles de capacidad se obtuvo
como resultado la caracterización del proceso. A continuación, en la Figura 5 se
presenta una abstracción a alto nivel de la propuesta.

57
Figura 5. Visión general de la propuesta.

58
5.1.7 Caracterización del proceso para la gestión de la
configuración de software.
Identificador GCSA
Proceso. Gestión de la configuración de software.
Categoría. Operación (OPE)
Propósito. Establecer y mantener la integridad de todos los ítems de configuración
identificados de un proyecto y ponerlos a disposición de las partes
interesadas a través de su identificación, control, seguimiento y aud itoria.
Obj etiv os. O1: Identificar todos los ítems de configuración que hacen parte del
proyecto.
O2: Establecer los criterios de integridad de los ítems de configuración a
través de la definición de una (o varias) línea base durante el ciclo de vida
de un proyecto de software.
O3: Llevar a cabo el control sistemático de los cambios llevados a cabo en
los ítems de configuración que pertenecen a una línea base a través de
solicitudes de cambio.
O4: Mantener la trazabilidad de los ítems de configuración relacionados a
una línea base a través de su actualización y registro.
O5: Llevar a cabo procedimientos de monitoreo para asegurar la
integridad de los ítems de configuración con el paso del tiempo.
Responsabilidad y autoridad. Líder de calidad del proyecto.
Procesos relacionados. 1. Seguimiento y control de proyectos.
2. Planeación de proyectos.

Roles Inv olucrados y Competencias

Descripción de los roles identificados durante la fase de análisis y homogeneización de modelos, ver Tabla 46.
Abrev iatura Rol Competencias

AP Administrador del Recurso encargado de la definición, planificación, y

proyecto. supervisión del proyecto que se va a llevar a cabo desde el
punto de vista administrativo.
ED Equipo de desarrollo. Recursos con los conocimientos técnicos necesarios para
llevar a cabo el desarrollo del proyecto en cualquiera de
su s fase s. Se consideran miembros del equipo de
desarrollo:
 Analistas.
 Desarrolladores de software.
 Tester.
 Administrador de bases de datos.
 Técnicos en infraestructura.
Nota: El técnico de configuración que se presenta como un
rol con sus propias características también es considerado
un miembro del equipo de desarrollo.
EC Experto en El experto en configuración representa la autoridad de
configuración. gestión de la configuración durante el desarrollo del
proyecto. Es el recurso responsable de conocer el proceso
en gestión de la configuración y asegurar que el equipo de
desarrollo lo lleva a cabo de manera correcta.

Nota 1: Para proyectos que involucren marcos de trabajo

bajo aspectos ágiles, un experto en configuración debería
también ser capaz de dar soporte a dichas metodologías,
es decir, debería ser el encargado de asegurar que
cualquiera de dichas metodologías se cumpla. El experto
en configuración es el recurso equivalente al Scrum Master
definido en SCRUM o al Coach definido en XP.
CCC Comisión de control de Recurso(s) responsable(s) de la evaluación de los cambios
la configuración propuestos a determinados ítems de configuración. Si
dichos cambios son aprobados, la CCC también deberá
asegurar su realización.

Se recomienda que esta comisión esté conformada por un

miembro del equipo de desarrollo (ED), el responsable del
ítem de configuración a modificar y el Experto en
Configuración (EC).
TC Técnico de Recurso encargado de llevar a cabo los cambios
configuración propuestos en las peticiones de cambio aprobadas por la
CCC. Este rol es designado por el CCC cuando se aprueba
una petición de cambio.

59
DP Dueño del producto. Es el recurso responsable de transmitir al equipo de
desarrollo la visión y el conocimiento sobre el producto que
se desea implementar desde el punto de vista del negocio.

El dueño del producto es el representante de los

interesados y es el enlace que permite transmitir sus
solicitudes e inconformidades al equipo de desarrollo.
Además, el dueño del producto es el agente responsable
de priorizar y validar cada uno de los requerimientos,
inconformidades y solicitudes de cambio del cliente desde
la visión del producto.
IN Interesado. Persona o conjunto de personas que no hacen parte del
proceso técnico de desarrollo pero que deben ser tomados
en cuenta. Se consideran interesados:
 Director del proyecto.
 Gerentes del proyecto.
 Expertos en el negocio.
 Expertos en el producto.
CL Cliente. Es el usuario final del producto que se va a implementar y
el público objetivo que va a utilizar el producto en su fase
de producción.

Activ idades.

GCSA.A1. Desarrollar una estrategia de gestión de la configuración.

Niv el de capacidad: Esencial

Entradas: N/A
Responsables. Tareas.
AP, EC T1: Crear un PGCS 16

Descripción:
1. Inicio del flujo.
2. Definir la plantilla que se va a utilizar para la construcción de un plan formal
para llevar a cabo la gestión de la configuración de software.
3. Identificar los aspectos en el proyecto sensibles a gestión de la configuración.
4. Identificar las actividades que se van a llevar a cabo durante el proceso de
gestión de la configuración del proyecto.
5. Definir un repositorio para almacenar el PGCS.
6. Actualizar el repositorio con el PGCS.
7. Hacer el PGCS disponible a las partes interesadas.
8. Fin del flujo.
Nota 1: El experto en configuración en conjunto con el administrador del proyecto deben
identificar y considerar los aspectos relevantes que deben ser incluidos en el PG CS. Se
deben tener en cuenta aspectos como: propósito, alcance del proyecto, responsables,
actividades, asignación de recursos, e stimación de costos, dependencias con actividades
relacionadas a otros procesos en el proyecto, etc.
AP, EC T2: Identificar los responsables asociados a cada actividad definida en el PGCS.

Descripción:
1. Inicio del flujo.
2. Identificación de todas las actividades contenidas en el plan.
3. Identificación de las competencias de cada recurso.
4. Definir los recursos responsables de cada actividad durante el proceso de
desarrollo.
5. Asignar los recursos responsables de cada actividad.
6. Fin del flujo.

Nota 1: Para MiPyMEs_DS, es muy importante la identificación de las capacidades y

competencias de los recursos que van a participar durante el desarrollo del proyecto.
Debido a la limitante de recursos humanos en MiPyMEs_DS (ver Tabla 7), se debe
considerar realizar un estudio previo de los recurso s que permitirá asignar tareas a estos
dependiendo de sus capacidades para aprovechar al máximo los recursos disponibles.
Salidas:
A1. S1: Plan para la gestión de la configuración del proyecto.
A1. S2: Identificación de los recursos necesarios para llevar a cabo las actividades asociadas a la gestión de la
configuración.
Diagrama de fluj o:

16
Plan de Gestión de la Configuración de Softw are, del inglés Softw are Configuration Management Plan

60
61
62
 GCSA.A2. Identificación de la configuración.

Niv el de capacidad: Esencial

Entradas:
A1. S1
A1. S2
Responsables. Tareas
EC T1: Definir los repositorios para llevar el control de los IC.

Descripción:
1. Inicio del flujo.
2. Definir los repositorios para almacenar IC de análisis y diseño.
3. Definir los repositorios para almacenar los IC de desarrollo e implementación.
4. Definir los repositorios para almacenar los IC externos al proyecto.
5. Fin del flujo.
Nota 1: Para IC de análisis y diseño, es recomendable definir repositorios agrupados por
su s características, por ejemplo: crear un repositorio para el control de los casos de uso y
sus diferentes versiones con el paso del tiempo.

Para IC de desarrollo e implementación, se recomienda la adopción de herramientas para

el control de versiones e integración continua, y la creación de repositorios para llevar a
cabo el control y la trazabilidad de los ítems de configuración, tales como: herramientas
utilizadas por el equipo de desarrollo, documentación técnica, ramas liberadas para
desarrollo, pruebas, producción, etc.

Nota 3: Para MiPyMEs_DS, es recomendable asignar a un miembro del equipo de

desarrollo como responsable de administrar los repositorios o los documentos definidos
para llevar el control de los ítems de configuración en paralelo a sus tareas.
Por ejemplo:

 Un analista puede ser responsable de mantener el repositorio de casos de uso.

 El DBA puede ser responsable de llevar el control del diccionario de datos del
proyecto y de mantener las bases de datos relacionadas al proyecto.
Un desarrollador puede ser el responsable de mantener las líneas base, el sistema de
integración continua y de administrar el repositorio donde se almacenen las versiones de
una o varias líneas base.
EC, ED T2: Describir los ítems de configuración (IC)

Descripción:
1. Inicio del flujo.
2. Definir un esquema de nombrado para el IC.
3. Seleccionar el IC sensible a configuración
4. Describir la función de cada IC.
5. Clasificar el IC a través de criterios funcionales.
5.1. Se valida si el IC es de análisis y diseño.
5.2. Se valida si el IC es de desarrollo e implementación.
5.3. Se valida si el IC es externo.
5.4. Se asigna un prefijo único a cada categoría de IC para identificar su
criterio funcional.
5.5. Continúa en el paso 7 del flujo principal.
6. Asignar un identificador único al IC.
7. Identificar el responsable del IC.
8. Documentar el IC.
9. Almacenar el IC en el repositorio relacionado.
10. Fin del flujo.
Nota 1: Se recomienda categorizar los IC a través de criterios funcionales, por ejemplo:
 IC de análisis y diseño: Bosquejos, especificaciones de producto,
requerimientos, prototipos, documentación de arquitectura y diseño de datos,
casos de uso o historias de usuario, listas de chequeo, criterios de aceptación,
manuales técnicos, manuales de instalación, manuales de usuario etc.
 IC de desarrollo e implementación: Código fuente, librerías, compilaciones,
herramientas y entornos de desarrollo (IDE, librerías, plugin, etc.), herramientas
de prueba, scripts, repositorios, casos de prueba, etc.
 IC externos: Son los artefactos que no tienen relación directa con el proyecto,
por ejemplo: servicios externos, artefactos dependientes de otros proyectos,
etc.
Nota 2: Para identificar de manera detallada cuáles elementos pueden ser considerados
como IC se recomienda ver la Tabla 19.

Nota 3: La clasificación por criterios funcionales permite identificar de manera clara e

inequívoca cada IC. Por ejemplo: El caso de uso X se identifica con el prefijo AD_IDX,
donde:

63
 AD: Análisis y diseño.
IDX: Identificador propio del IC.

Nota 4: Se recomienda que el IC sea identificado con elementos como: identificador del
IC, nombre del IC, descripción del IC, recurso responsable, identificador de los IC
dependientes del IC actual, etc.
EC T3: Identificar dependencias entre IC.

Descripción:
1. Inicio del flujo.
2. Seleccionar el IC.
3. Identificar los elementos impactados si ocurre un cambio en el IC.
4. Actualizar la documentación relacionada al IC.
5. Actualizar el IC en el repositorio relacionado.
6. Fin del flujo

EC T4: Estandarizar los IC.

Descripción:
1. Inicio del flujo.
2. Seleccionar el IC.
3. Identificar los IC que cumplen funciones parecidas.
4. Definir un formato unificado para los IC con funciones parecidas.
5. Continúa en GCSA.A2.T2.
6. Fin del flujo.
Nota 1: Es posible que durante la identificación de los IC existan diferentes IC que
cumplen funciones parecidas o cumplen la misma función, por ejemplo:
 Varios desarrolladores pueden utilizar matrices de pruebas diferentes para
realizar las mismas pruebas funcionales.
 Cada analista puede decidir utilizar un formato para la documentación de los
casos de uso.

Salidas:
A2. S1: Identificación de ítems de configuración.
A2. S2: Clasificación de los ítems de configuración.
A2. S3: Definición de repositorios para almacenar los ítems de configuración.
A2. S4: Identificación de dependencia entre ítems de configuración.
Diagrama de fluj o:

64
65
66
67
68
 GCSA.A3. Establecer las líneas base.

Niv el de capacidad: Complementario

Entradas:
A2. S2
Responsables Tareas
ED, EC T1: Identificar una línea base.

Descripción:
1. Inicio del flujo.
2. Solicitar autorización del EC para la identificación de una línea base.
Si el EC autoriza la identificación de una línea base.
2.1. Identificar los IC que constituyen una línea base (ver GCSA.A2.T2).
2.2. Definir el repositorio donde se almacenará la línea base.
2.3. Asignar un responsable a la línea base.
2.4. Actualizar el repositorio relacionado.
2.4. Hacer la línea base disponible a todas las partes interesadas.
2.5. Continúa en el paso 3 del flujo.
Si el EC rechaza la identificación de una línea base.
2.1. Continúa en el paso 3 del flujo.
3. Fin del flujo.
Nota 1: Una línea base es por definición un IC por lo cual, también se puede considerar
que las líneas bases sean categorizadas a través de criterios funcionales, es decir, una
línea base puede estar conformada por un conjunto de IC de análisis y diseño o IC de
desarrollo e implementación. Por ejem plo:

 Línea base de análisis y diseño: Una línea base que está conformada por un
conjunto de IC de análisis y diseño.
 Línea base de desarrollo e implementación: Una línea base que está
conformada por un conjunto de IC de desarrollo e implementación.
Salidas:
A3. S1: Descripción de las líneas base.
A3. S2: Definición de repositorios para almacenar las líneas base.
Diagrama de fluj o:

69
70
 GCSA.A4. Establecer una estrategia para la modificación de los ítems de configuración.

Niv el de capacidad: Complementario

Entradas:
A3. S1
Responsables Tareas
EC T1: Definir una política para el control de versiones de las líneas base.

Descripción:
1. Inicio del flujo.
2. Definir los criterios para crear nuevas líneas base o nuevas versiones de una
línea base existente.
3. Documentar los criterios definidos a través de una política de control de
versiones.
4. Definir el repositorio para almacenar la política de control de versiones.
5. Actualizar el repositorio relacionado.
6. Hacer la política disponible a todas las partes interesad as.
7. Fin del flujo.
Nota 1: Para MiPyMEs_DS, es recomendable asignar a un miembro del equipo de
desarrollo como responsable de administrar el repositorio y la creación de nuevas
versiones de una línea base.
ED T2: Identificar herramientas para controlar los cambios en los IC de análisis y diseño.

Descripción:
1. Inicio del flujo.
2. Identificar herramientas controlar los cambios en los IC de análisis y diseño.
3. Asociar los IC afectados a las herramientas definidas.
4. Fin del flujo.
ED T3: Identificar herramientas para controlar los cambios en los IC de desarrollo e
implementación.

Descripción:
1. Introducir un sistema de integración continua.
2. Definir convenciones para los comentarios asociados a los cambios que se van
a subir a los repositorios de código fuente durante el proceso de desarrollo.
3. Introducir herramientas para automatizar la creación de nuevas versiones de
una línea base.
4. Actualizar los IC de desarrollo e implementación en las herramientas definidas.
5. Fin del flujo.
ED T4: Definir criterios para la unión (merge) entre líneas base.

Descripción:
1. Inicio del flujo.
2. Definir los criterios para llevar a cabo la unión entre líneas base.
3. Definir la frecuencia para llevar a cabo la unión entre líneas base.
4. Definir una estrategia para controlar los conflictos entre líneas base.
5. Fin del flujo
Nota 1: Se recomienda que la unión entre líneas base se realice en periodos cortos de
tiempo para evitar que existan conflictos.
Salidas:
A4. S1: Política para el control de versiones.
A4. S2: Definición herramientas para controlar los IC de análisis y diseño.
A4. S3: Definición de herramientas para controlar los cambios en IC de desarrollo e implementación
A4. S4: Definición de política para la unión de líneas base.
Diagrama de fluj o:

71
72
73
74
GCSA.A5. Mantener la descripción de los ítems de configuración.

75
Niv el de capacidad: Complementario.
Entradas:
A2. S2
A4. S2
Responsables. Tareas
EC T1: Identificar los ítems de configuración constituyentes (ICC)

Descripción:
1. Inicio del flujo.
2. Identificar el IC demasiado complejo.
3. Dividir el IC en ICC.
4. Definir el ICC (ver GCSA.A2.T2).
5. Actualizar el IC en el repositorio relacionado.
6. Hacer el IC actualizado disponible a las partes interesadas.
7. Fin del flujo.

Salidas:
A5. S1: ICC documentados y relacionados.
Diagrama de fluj o:

76
 GCSA.A6. Controlar la modificación de los ítems de configuración.

Niv el de capacidad Complementario

77
Entradas:
N/A
Responsables. Tareas
EC T1: Definir herramientas para controlar las solicitudes de cambios en los IC.

Descripción:
1. Inicio del flujo.
2. Identificar los criterios que se deben tener en cuenta para realizar una solicitud
de cambio
3. Identificar herramientas que permitan controlar las solicitudes de cambio
realizadas por el equipo de desarrollo, por el cliente o por los interesados.
4. Definir los responsables de administrar las herramientas para el control de las
solicitudes de cambio.
5. Fin del flujo.
Nota 2: Una herramienta para controlar las peticiones de cambio debería considerar
elementos tales como: descripción del motivo de cambio, recurso que solicita el cambio,
recurso asignado a la evaluación del cambio, IC afectado, prioridad, etc.
EC T2: Definir una política de liberación y lanzamiento.

Descripción:
1. Inicio del flujo.
2. Definir los criterios que se deben cumplir para liberar una línea base a la
siguiente cadena del flujo durante el proceso de desarrollo.
3. Definir un responsable que garantice el cumplimiento de los criterios definidos.
4. Documentar los criterios definidos.
5. Definir repositorio para al macenar la política de liberación.
6. Almacenar la política en el repositorio correspondiente.
7. Hacer la política de liberación y lanzamiento disponible a las partes
interesadas.
8. Fin del flujo.

Nota 1: Para empresas que siguen modelo de desarrollo en cascada (Análisis, Diseño,
Desarrollo, Pruebas, Lanzamiento, Producción, Mantenimiento) se puede seguir una
política de liberación lineal que establezca los criterios necesarios para pasar de una fase
del proceso a otra. Por ejemplo: Definir los criterios que se d eben cumplir para que una
línea base de desarrollo pueda ser liberada a pruebas.

Nota 2: Para empresas que siguen el modelo iterativo incremental, espiral o guiado por
prototipos, se recomienda definir una política de liberaciones parciales e incrementale s
cuyo parámetro de control sean listas de listo o de hecho que deben ser cumplidas para
la liberación de una fase a la que sigue.
ED, CCC, TC T3: Identificar la solicitud de cambio solicitada por un miembro del equipo de desarrollo.

Descripción:
1. Inicio del flujo.
2. El miembro del equipo de desarrollo identifica el IC afectado.
3. El miembro del equipo de desarrollo solicita el cambio a través de la
herramienta definida.
4. El miembro del equipo de desarrollo asigna la petición de cambio a la comisión
de control de la configuración.
5. La comisión de control de la configuración valida el cambio solicitado
Si el cambio es aprobado.
5.1. La comisión de control de la configuración asigna un técnico de
configuración para que implemente el cambio solicitado.
5.2. El técnico de configuración realiza el cambio solicitado.
5.3. El técnico de configuración actualiza los IC afectados en los repositorios
relacionados.
5.4. Continúa en el paso 6 del flujo.
Si el cambio es rechazado.
5.1. La comisión de control de la configuración notifica al miem bro del equipo
de desarrollo que la solicitud de cambio ha sido rechazada.
5.2. Continúa en el paso 6 del flujo.
6. Se actualiza la petición de cambio en el repositorio o la plataforma definida.
7. Fin del flujo.

Nota 1: La comisión de control de la configuración debería considerar categorizar las

peticiones de cambio De acuerdo con la fase del proceso de desarrollo en la cual sean
solicitadas y establecer criterios de prioridad, por ejemplo: Una solicitud de cambio
realizada durante la fase de producción es de prioridad alta y debería ser evaluada antes
que otras solicitudes que sean relacionadas a la fase de análisis, desarrollo o
mantenimiento.

Nota 2: Priorizar las peticiones de cambio es importante para evitar cuellos de botella en

78
 el proceso de desarrollo del proyecto.
DP, CCC, TC T4: Identificar la solicitud de cambio solicitada por los interesados o por el cliente.

Descripción:
1. Inicio del flujo.
2. El dueño del producto identifica el cambio solicitado por el interesado o por el
cliente.
3. El dueño del producto evalúa el impacto del cambio solicitado.
4. El dueño del producto solicita el cambio a través de las plataformas definidas.
5. El dueño del producto asigna la petición de cambio a la comisión de control de
la configuración.
6. La comisión de control de la configuraci ón valida el cambio solicitado.
Si el cambio es aprobado.
6.1. La comisión de control de la configuración asigna un técnico de
configuración encargado de realizar el cambio.
6.2. El técnico de configuración realiza el cambio solicitado.
6.3. El técnico de configuración actualiza los IC afectados en los repositorios
relacionados.
6.4. Continúa en el paso 7 del flujo.
Si el cambio es rechazado.
6.1. La comisión de control de la configuración notifica al dueño del producto
que el cambio ha sido rechazado.
6.2. Continúa el paso 7 del flujo.
7. Se actualiza la petición de cambio en el repositorio o la plataforma definida.
8. Fin del flujo.

Nota 1: La comisión de control de la configuración debería considerar categorizar las

peticiones de cambio de acuerdo con la fase del proceso de desarrollo en la cual sean
solicitadas y establecer criterios de prioridad, por ejemplo: Una solicitud de cambio
realizada durante la fase de producción es de prioridad alta y debería ser evaluada antes
que otras solicitudes que sean relacionadas a la fase de análisis, desarrollo o
mantenimiento.

Nota 2: Priorizar las peticiones de cambio es importante para evitar cuellos de botella en
el proceso de desarrollo del proyecto.
Salidas
A6. S1: Plantilla para la solicitud de cambios.
A6. S2: Creación del repositorio para controlar las solicitudes de cambio.

79
Diagrama de fluj o:

80
81
82
83
 GCSA.A7. Proceso de monitoreo.

Niv el de capacidad Realizado.

Entradas:
N/A
Responsables. Tareas
EC T1: Definir criterios para llevar a cabo una evaluación física y funcional.

Descripción:
1. Inicio del flujo.
2. Definir los criterios para llevar a cabo una evaluación física.
2.1. Definir el repositorio para almacenar los documentos de evaluación física.
2.2. Definir los criterios de evaluación para el IC puesto bajo una evaluació n física
a través de una lista de chequeo.
2.3. Definir la frecuencia en la que se deben llevar a cabo la evaluación física de
los IC.
2.4. Definir la plantilla de reporte para informar los resultados de una evaluación
física.
2.5. Actualizar los artefactos generados en el repositorio relacionado.
2.6. Continúa en el paso 4 del flujo principal.
3. Definir los criterios para llevar a cabo una evaluación funcional de las líneas base.
3.1. Definir el repositorio para almacenar los documentos de evaluación funcional.
3.2. Definir la plantilla de evaluación para la evaluación funcional.
3.3. Definir los criterios de evaluación para el IC puesto bajo una evaluación
funcional.
3.4. Definir la frecuencia en la que se deben llevar a cabo la evaluación funcional
de los IC.
3.5. Definir la plantilla de reporte para informar los resultados de una evaluación
funcional.
3.6. Actualizar los artefactos generados en el repositorio relacionado.
3.7. Continúa en el paso 4 del flujo principal.
4. Hacer los repositorios relacionados disponibles a las partes interesadas.
5. Fin del flujo.

ED, EC T2: Llevar a cabo la evaluación física de los IC.

Descripción:
1. Inicio del flujo.
2. El experto en configuración (EC) identifica el ítem de configuración a evaluar.
3. Se designa un miembro del equipo de desarrollo para llevar a cabo la evaluación
del IC afectado.
4. Se valida que el ítem de configuración aprueba los criterios definidos para el
proceso de evaluación física.
Si el IC aprueba los criterios definidos para la ev aluación.
4.1. El miembro del equipo de desarrollo designado documenta los resultados de
la validación.
4.2. Continúa en el paso 5 del flujo.
Si el IC no aprueba los criterios definidos para la ev aluación.
4.1. El miembro del equipo de desarrollo designado documenta las no
conformidades detectadas.
4.2. Continúa en el paso 5 del flujo.

5. El miembro del equipo de desarrollo informa al experto en configuración los

resultados de la validación a través de la plantilla de reporte definida.
6. El experto en configuración actualiza el repositorio relacionado con los resultados
de la validación.
7. Fin del flujo.
Nota 1: Para MiPyMEs_DS, es recomendable asignar a un miembro del equipo de desarrollo
con conocimiento en el dominio del proyecto que no haya participado en el proceso de
construcción y definición de los ítems de configuración para re alizar una validación objetiva.

Nota 2: Si la empresa cuenta con recursos económicos suficientes, se puede designar un

auditor externo que realice la evaluación física de los IC.
ED, EC T3: Llevar a cabo la evaluación funcional de las líneas base.

Descripción:
1. Inicio del flujo.
2. El experto en configuración identifica la línea base a evaluar.
3. Se designan los miembros del equipo de desarrollo necesarios para llevar a cabo
la evaluación del IC afectado.
4. Se valida que la línea base aprueba los criterios definidos para el proceso de

84
 evaluación funcional.
Si la línea base aprueba los criterios definidos para la ev aluación.
4.1. Los miembros del equipo de desarrollo designados documentan los resultados
de la validación.
4.2. Continúa en el paso 5 del flujo.
Si la línea base no aprueba los criterios definidos para la ev aluación.
4.1. Los miembros del equipo de desarrollo designados documentan las no
conformidades detectadas.
4.2. Continúa en el paso 5 del flujo.

5. Los miembros del equipo de desarrollo informan al experto en configuración los

resultados de la validación a través de la plantilla de reporte definida.
6. El experto en configuración actualiza el repositorio relacionado con los resultados
de la validación.
7. Fin del flujo.

Nota 1: Para MiPyMEs_DS, es recomendable asignar a un miembro d el equipo de desarrollo

con mayor experiencia en los detalles técnicos para realizar una validación objetiva de las
líneas base. Además, se pueden plantear estrategias de evaluación mediante criterios como:
evaluación de arquitectura, metodologías de desarrollo, criterios de calidad, usabilidad,
rendimiento, seguridad, etc. Las evaluaciones pueden ser llevadas a cabo por uno o varios
miembros del equipo de desarrollo expertos en los diferentes criterios definidos para la
evaluación.

Nota 2: Si la empresa cuenta con recursos económicos suficientes, se puede designar un

auditor externo que realice la evaluación funcional.
EC, ED T4: Definición y administración de respaldos.

Descripción:
1. Inicio del flujo.
2. Identificar IC críticos.
3. Definir un repositorio para almacenar los respaldos.
4. Establecer mecanismos para la recuperación de información crítica que ha sido
respaldada.
5. Designar un técnico de configuración para llevar a cabo la creación y
administración de los respaldos.
6. El técnico de configuración crea respaldos de los IC críticos.
7. El técnico de configuración actualiza el repositorio relacionado.
8. Fin del flujo.
EC, TC T5: Resolver no conformidades detectadas en la evaluación física y funcional de los IC.

Descripción:
1. Inicio del flujo.
2. Identificar el ítem de configuración inconsistente.
3. Se designa a un técnico de configuración para resolver las no conformidades del
ítem de configuración inconsistente.
4. El técnico de configuración aplica los cambios al IC inconsistente.
5. El técnico de configuración actualiza los repositorios relacionados.
6. El técnico de configuración notifica al experto en configuración que el cambio ha
sido realizado.
7. El experto en configuración identifica el ítem de configuración que ha sido
actualizado.
Si el IC requiere ev aluación física continua en GCSA.A7. T2
Si el IC requiere ev aluación funcional continua en GCSA.A7. T3
8. Fin del flujo.
Salidas
A7. S1: Reporte de ev aluación física de los IC.
A7. S2: Reporte de ev aluación funcional de los IC.
A7. S3: Creación de repositorios y respaldos.
A7. A4: Reporte de no conformidades.
Diagrama de fluj o:

85
86
87
88
89
Tabla 51. Progresconfig.

90
5.2 Análisis del grado de agilidad del proceso.
Según [61], se dice que un método de desarrollo de software es ágil cuando cumple
con las siguientes características: es enfocado en las personas, orientado a la
comunicación, flexible (listo para adaptarse al cambio esperado o inesperado en
cualquier momento), veloz (fomenta el desarrollo rápido e iterativo del producto en
liberaciones pequeñas), ligero (se centra en el acortamiento de plazos y costos y sobre
la mejora de la calidad), adaptativo (responde adecuadamente a los cambios
esperados e inesperados), y enfocado en la mejora continua (se centra en la mejora
durante y después del desarrollo del producto).

Para cumplir con el objetivo de crear un proceso ágil para soportar SCM, es necesario
realizar una evaluación para determinar el grado de agilidad con el cual fue definido.
Para ello, se utiliza como método de evaluación el framework propuesto en [61]
denominado 4-DAT, el cual permite realizar una evaluación cuantitativa y cualitativa
del grado de agilidad en un método o en un proceso. 4-DAT aplica una evaluación a
través de cuatro dimensiones (alcance del método, caracterización de agilidad,
caracterización de valores ágiles y caracterización de proceso de software). A
continuación, se hace a evaluación de agilidad siguiendo cada una de las dimensiones
definidas.

5.2.1 Análisis de alcance del proceso.

La primera dimensión es utilizada para evaluar de manera cualitativa los aspectos
referentes al alcance del método a evaluar desde el punto de vista de factores
generales. Como resultado, se obtiene una representación cualitativa de los diferentes
aspectos a evaluar. La primera dimensión está diseñada para realizar una evaluación
basada en preguntas relacionadas a aspectos generales del método, así como:
tamaño del proyecto, tamaño del equipo, estilo de desarrollo, estilo de codificación,
entornos relacionados, cultura de negocio y mecanismos de abstracción. A
continuación, en la Tabla 52 se presenta la plantilla definida por 4-DAT para llevar a
cabo la evaluación:

Dimensión 1 (Alcance del método)

Alcance Descripción del método
Tamaño del proyecto. ¿El método especifica soporte para proyectos pequeños, medianos o grand es?
Tamaño del equipo. ¿El método soporta pequeños o grandes equipos (equipos múltiples o individuales)?
Estilo de desarrollo. ¿Cuáles estilos desarrollo son soportados (iterativo, rápido, etc.)?
Estilo de codificación. ¿El método especifica un estilo de codificación (simple o complejo)?
Entorno tecnológico. ¿Cuáles entornos tecnológicos (herramientas, compiladores, etc.) son especificados?
Entorno físico. ¿Cuáles entornos físicos (centralizados o distribuidos) son especificados?
Cultura de negocio. ¿Qué tipo de cultura de negocio (colaborativa, cooperativa o no colaborativa) es
especificada?
Mecanismo de ¿El método especifica algún mecanismo de abstracción (orientado a objetos, orientado a
abstracción. los agentes)?
Tabla 52. Descripción de la primera dimensión para la evaluación de agilidad. Tomado
de [61].

Los resultados de la evaluación de la primera dimensión a Progresconfig indican de

manera general que el proceso es apto para proyectos pequeños y medianos, utiliza
un enfoque iterativo e incremental y está definido para equipos de trabajo pequeños y
medianos en términos de cantidad de personas involucradas. Sin embargo, debido a
que es un proceso definido para la gestión de la configuración de software no
menciona o recomienda algún estilo de codificación en particular. Además, el proceso
requiere de un enfoque de realimentación rápida, está definido inicialmente para
equipos centralizados y con una cultura empresarial cooperativa y colaborativa.

91
Se puede concluir de manera cualitativa que el proceso es adecuado para equipos de
trabajos medianos o pequeños donde los requisitos tienden a ser cambiantes y la
incertidumbre puede aumentar con el tiempo. A continuación, en la Tabla 53 se
muestra el resultado de la evaluación a la primera dimensión realizada al proce so
definido en este proyecto de investigación.

Dimensión 1 (Alcance del método)

Alcance. Progresconfig.
Tamaño del proyecto.  Proyectos pequeños y medianos (Ver Tabla 7)
Tamaño del equipo.  Equipos pequeños y medianos (Ver Tabla 7)
Estilo de desarrollo.  Iterativo, desarrollo incremental y cooperativo.
Estilo de codificación.  El proceso recomienda el uso de desarrollo soportado por técnicas de calidad
de código.
Entorno tecnológico.  Herramientas de integración continúa.
 Repositorios de código fuente y documentación.
 Herramientas para el control de versiones.
 Requiere realimentación rápida.
Entorno físico.  Equipos centralizados.
Cultura de negocio.  Colaborativa.
 Cooperativa.
Mecanismo de  Orientado a la comunicación.
abstracción.  Orientado a las personas.

Tabla 53. Evaluación de la primera dimensión aplicada a Progresconfig.

5.2.2 Análisis de grado de agilidad del proceso.

La segunda dimensión es utilizada para evaluar el proceso desde la perspectiva de
agilidad, y ha sido medido en términos de cinco variables: flexibilidad (FY), velocidad
(SD), ligereza (LS), enfocado en la mejora continua (LG) y adaptabilidad (RS). La
evaluación de la segunda dimensión se hace utilizando la escala binaria (1 si existe el
factor, 0 si no está definido). La evaluación se lleva a cabo en las fases y prácticas
definidas en el proceso o modelo a evaluar y su relación con los factores definidos
anteriormente. Debido a la naturaleza del proceso definido, la evaluación se realiza
solo a través de la medición del grado de agilidad de las actividades definidas en él.
Además, agrega una última fila en la cual se muestra el resultado obtenido en términos
de porcentaje para realizar el análisis posterior. En la Tabla 54 se muestra la plantilla
definida para la evaluación de la segunda dimensión.

Grado de agilidad en el método X

Método X Criterios de agilidad.
Fases FY SD LS LG RS Total
Fase 1 0o 1 0o 1 0o 1 0o 1 0o 1 [ ]
Fase 2 0o 1 0o 1 0o 1 0o 1 0o 1 [ ]
Fase n 0o 1 0o 1 0o 1 0o 1 0o 1 [ ]
Total. [ ] [ ] [ ] [ ] [ ] [ ]
Grado de agilidad. [ ] [ ] [ ] [ ] [ ] Total, dividido por el número de
celdas.

Prácticas FY SD LS LG RS Total
Práctica 1 0o 1 0o 1 0o 1 0o 1 0o 1 [ ]
Práctica 2 0o 1 0o 1 0o 1 0o 1 0o 1 [ ]
Práctica 3 0o 1 0o 1 0o 1 0o 1 0o 1 [ ]
Práctica m 0o 1 0o 1 0o 1 0o 1 0o 1 [ ]
Total. [ ] [ ] [ ] [ ] [ ] [ ]
Grado de agilidad. [ ] [ ] [ ] [ ] [ ] Total, dividido por el número de
celdas.

92
Tabla 54. Plantilla utilizada para la evaluación de la segunda dimensión. Tomado de
[61].

Posterior al análisis del proceso desde la perspectiva de la segunda dimensión, es

posible obtener una evaluación cuantitativa en términos del grado de agilidad que
permite medir el grado de agilidad de cada actividad del proceso de manera individual.
A partir de los resultados observados en la Tabla 55, se identifica que el proceso
propuesto es flexible (listo para adaptarse al cambio esperado o inesperado en
cualquier momento) en un 85,71%, veloz (fomenta el desarrollo rápido e iterativo del
producto en liberaciones pequeñas) en un 71,42%, ligero (se centra en el acortamiento
de plazos y costos y sobre la mejora de la calidad) en un 85,71%, adaptativo
(responde adecuadamente a los cambios esperados e inesperados) 85,71%, y
enfocado en la mejora continua (se centra en la mejora durante y después del
desarrollo del producto) en un 85,71%. En general, el proceso tiene un grado de
agilidad de un 83,85%.

Gracias a los resultados obtenidos en la evaluación de la segunda dimensión, se

puede concluir que el proceso cumple con las expectativas propuestas para los
aspectos a evaluar. Sin embargo, es necesario revisar las actividades GCSA.A1,
GCSA.A2, y GCSA.A7, los cuales tuvieron una calificación porcentual menor con
relación al resto de actividades.

A continuación, en la Tabla 55 se muestra el resultado de la evaluación a la segunda

dimensión realizada al proceso definido en este proyecto de investigación.

Grado de agilidad en Progresconfig.

Progresconfig. Criterios de agilidad.
Activ idades. FY SD LS LG RS Total
GCSA.A1 Desarrollar una estrategia de gestión de 0 1 1 0 1 3
la configuración.
GCSA.A2. Identificación de la configuración. 1 0 1 1 1 4
GCSA.A3. Establecer las líneas de base. 1 1 1 1 1 5
GCSA.A4. Establecer una estrategia para la 1 1 1 1 1 5
modificación de las líneas de base.
GCSA.A5. Mantener la descripción de los ítems de 1 1 1 1 1 5
configuración.
GCSA.A6. Controlar modificaciones y lanzamientos 1 1 1 1 1 5
GCSA.A7. Proceso de monitoreo. 1 0 0 1 0 2
Total. 6 5 6 6 6 29
Grado de agilidad. 6/7 5/7 6/7 6/7 6/7 29/
(35)
Grado de agilidad % 85,71% 71,42% 85,71% 85,71% 85,71% 83,85%
Tabla 55. Evaluación de la segunda dimensión aplicada a Progresconfig.

5.2.3 Análisis de caracterización de valores ágiles.

La evaluación de la tercera dimensión tiene como objetivo medir cualitativamente el
nivel de soporte de los valores ágiles en las diferentes prácticas o actividades
asociadas al método o proceso a evaluar. Para llevar a cabo la evaluación d e la
tercera dimensión se utiliza la plantilla definida en 4-DAT, la cual se puede observar en
la Tabla 56:

Dimensión 3 (Caracterización de v alores ágiles)

Valores ágiles. Descripción del método.
Indiv iduos e interacción sobre los procesos y ¿Cuáles prácticas valoran a las personas y la interacción sobre los
las herramientas. procesos y las herramientas?
Softw are funcional sobre gran cantidad de ¿Cuáles prácticas valoran el software de trabajo sobre la cantidad
documentación. de documentación?
Colaboración del cliente sobre contratos y ¿Cuáles prácticas valoran la colaboración del cliente sobre la
negociación. negociación del contrato?
Responder al cambio sobre seguir un plan. ¿Cuáles prácticas valoran la respuesta al cambio sobre el

93
 seguimiento de un plan?
Mantener el proceso ágil. ¿Cuáles prácticas ayudan a mantener el proceso ágil?
Mantener el proceso rentable. ¿Cuáles actividades ayudan a mantener el proceso rentable?
Tabla 56. Descripción de la tercera dimensión para la evaluación de agilidad. Tomado
de [61].

Posterior al análisis del proceso desde la perspectiva de la tercera dimensión, es

posible obtener una evaluación cualitativa en términos de los valores ágiles definidos
en 4-DAT aplicados al proceso.

En general, la actividad GCSA.A6 permite que exista interacción con las partes
interesadas externas gracias a la definición de un rol de dueño de producto que
cumple la función de ser un canal de comunicación entre los clientes y los interesados
con el equipo de desarrollo para llevar a cabo la petición, evaluación y aplicación de
las solicitudes de cambio realizadas por el cliente o un interesado.

Por otro lado, el proceso define un conjunto de artefactos documentales para llevar a
cabo algunas actividades relacionadas. Sin embargo, el proceso recomienda la
automatización de varios artefactos a través de herramientas y plataformas para
gestionar su uso. Además, las actividades GCSA.A2, GCSA.A3, GCSA.A4, GCSA.A5
y GCSA.A6 fueron definidas para responder al cambio y mantener la integridad de los
artefactos involucrados con el paso del tiempo. Finalmente, la actividad GCSA.A1,
tiene como objetivo principal identificar todos los aspectos relevantes del proyecto para
llevar a cabo la gestión de la configuración de manera adecuada y rentable para la
empresa. A continuación, en la Tabla 57 se muestra la evaluación a la tercera
dimensión realizada al proceso definido en este proyecto de investigación, la
descripción del método describe la actividad o actividades que so portan cada uno de
los valores ágiles evaluados en la tercera dimensión.

Dimensión 3 (Caracterización de v alores ágiles)

Valores ágiles. Descripción del método.
Indiv iduos e interacción sobre los procesos y las herramientas. GCSA.A6
Softw are funcional sobre gran cantidad de documentación. GCSA.A4
Colaboración del cliente sobre contratos y negociación. GCSA.A6
Responder al cambio sobre seguir un plan. GCSA.A2
GCSA.A3
GCSA.A4
GCSA.A5
GCSA.A6
Mantener el proceso ágil. GCSA.A2
GCSA.A4
GCSA.A5
GCSA.A6
GCSA.A7
Mantener el proceso rentable. GCSA.A1
Tabla 57. Evaluación de la tercera dimensión aplicada a Progresconfig.

5.2.4 Análisis de caracterización del proceso de

software.
La cuarta dimensión permite realizar una evaluación cualitativa de las prácticas
propuestas en el proceso y como pueden ser utilizados para soportar otros procesos
afines. En la Tabla 58, se puede observar la plantilla definida para llevar a cabo la
evaluación de la cuarta dimensión presentada en 4-DAT.

Dimensión 4 (Caracterización del proceso de softw are)

Procesos. Descripción del método.
Proceso de desarrollo. ¿Cuáles prácticas cubren el ciclo de vida principal del proceso y
de las pruebas (Garantizar la calidad)?
Proceso de gestión del proyecto. ¿Cuáles prácticas cubren la gestión general del proyecto?

94
Proceso de gestión de configuración de ¿Cuáles prácticas cubren el proceso para garantizar la gestión
softw are/Proceso de soporte. de la configuración?
Proceso de gestión del proceso. ¿Cuáles prácticas cubren el proceso que es requerido para
gestionar el proceso en sí mismo?
Tabla 58. Plantilla utilizada para la evaluación de la cuarta dimensión. Tomado de [61].

Posterior al análisis del proceso desde la perspectiva de la cuarta dimensión, es

posible obtener una evaluación cualitativa en términos de los diferentes procesos de
software propuestos en [61] aplicados en el proceso a evaluar.

Los resultados indican que el proceso propuesto está definido para dar soporte a todo
el ciclo de vida del desarrollo de software en cada una de sus fases. Además, la
actividad GCSA.A1 tiene como objetivo principal la creación y actualización de los
artefactos necesarios para llevar a cabo la gestión del proceso en sí mismo y la
gestión del proyecto que va a aplicar el proceso. Finalmente, se concluye que el
proceso evaluado está diseñado para facilitar la adopción de la gestión de la
configuración de software en las empresas desarrolladoras de software.

A continuación, en la Tabla 59 se muestra la evaluación a la cuarta dimensión

realizada al proceso definido en este proyecto de investigación.

Dimensión 4 (Caracterización del proceso de softw are)

Procesos. Descripción del método.
Proceso de desarrollo. Todas las actividades fueron definidas para soportar el ciclo de vida durante el
proceso de desarrollo de software.
Proceso de gestión del La actividad GCSA.A1 propone las tareas necesarias que se deben llevar a cabo para
proyecto. gestionar el proceso de gestión de la configuraci ón mediante la definición y aplicación
de un plan que aplica durante la ejecución de todo el proyecto
Proceso de gestión de El proceso en sí mismo fue propuesto para soportar la gestión de la configuración de
configuración de software.
softw are/Proceso de
soporte.
Proceso de gestión del La actividad GCSA.A1 propone las tareas necesarias que se deben llevar a cabo para
proceso. gestionar el proceso de gestión de la configuración mediante la definición y aplicación
de un plan que aplica durante la ejecución de todo el proyecto. Además, se define el
rol de experto en configuración, el cual es el responsable de conocer y garantizar que
el proceso se lleva a cabo de manera correcta.
Tabla 59. Evaluación de la cuarta dimensión aplicada a Progresconfig.

95
 Capítulo VI. Evaluación de la
propuesta.
En este capítulo se presentan los resultados de la evaluación del proceso para la
gestión de la configuración propuesto. La evaluación se llevó a cabo empleando el
método de grupo focal (focus group) para evaluar el proceso definido en el capítulo
anterior. Inicialmente se describe el proceso seguido para llevar a cabo el grupo focal,
y posteriormente se describe paso a paso la aplicación del grupo focal para la
evaluación de la propuesta realizada con la participación de expertos que pertenecen
a la industria local del desarrollo de software y miembros del sector académico.
Finalmente se presenta el análisis de los resultados obtenidos tras la aplicación del
grupo focal.

6.1 Grupo Focal.

Según [62], un grupo focal se refiera a una discusión planeada cuidadosamente y que
es diseñada para obtener información relevante sobre las percepciones personales de
aquellos que participan en el grupo, los cuales son seleccionados mediante la
identificación de características individuales relacionadas al tema de interés para la
investigación. El grupo focal es un método rápido que permite obtener realimentación
rápida de los interesados y proporciona información valiosa de carácter cualitativo
sobre el tema que se va a evaluar.

6.2 Estructura teórica del método.

El procedimiento utilizado para llevar a cabo el grupo focal sigue los lineamientos
definidos en [19], el cual está orientado a la aplicación del grupo focal dentro de la
ingeniería del software como método para la validación de propuestas teóricas a partir
del juicio de expertos en el área a evaluar. La estructura definida se compone por
cuatro (4) fases, las cuales se describen a continuación:

1. Planeación de la investigación: Se establecieron los elementos de contenido

y procedimiento que fueron aplicados durante la sesión de debate.
2. Definición de los grupos de discusión: Se definieron los criterios para la
selección de los participantes que fueron parte de la sesión de debate.
3. Conducción de la sesión de debate: Se ejecutaron los procedimientos
establecidos en la fase de planeación con el grupo de discusión seleccionado.
4. Análisis de la información y reporte de resultados: Se obtuvo la información
de valor a partir de los productos de trabajo generados en la sesión de debate.

6.3 Realización del grupo focal.

Posterior a la caracterización de Progresconfig en el capítulo anterior, se generó una
versión inicial la cual fue sometida a juicio de expertos mediante la aplicación de un
grupo focal. A partir de los resultados obtenidos en el grupo focal, el proceso fue
refinado y adaptado con el fin de generar una versión actualizada y mejorada, la cual
se puede ver en la Tabla 51. A continuación, se presenta cada una de las fases
llevadas a cabo para la aplicación del grupo focal.

96
6.3.1 Planeación de la investigación.

6.3.1.1 Definición del problema de investigación.

El grupo focal se aplicó con el objetivo de:

Evaluar el proceso ágil para la gestión de la configuración de software

(Progresconfig).

Para llevar a cabo la evaluación del proceso se utilizó como base la caracterización del
proceso definido en la Tabla 51, el cual describe un conjunto de definiciones,
actividades, entradas, salidas, tareas, roles y diagramas de flujo relacio nados al
proceso.

6.3.1.2 Preparación del material utilizado en la

aplicación del grupo focal.
En esta etapa se definieron todos los artefactos que deberían ser diligenciados por los
actores que iban a participar en el grupo focal, los artefactos fueron : (i) listado de
preguntas sobre la evaluación del proceso propuesto, y (ii) ficha de asistentes al grupo
focal. Asimismo, se definieron los procedimientos que utilizaron durante la sesión de
debate y la técnica definida para obtener la información más importante que fue
utilizada para el análisis posterior. Estos artefactos son de utilidad para realizar una
evaluación objetiva y documentar de manera formal la propuesta.

6.3.1.2.1 Fase de definición del protocolo.

A continuación, en la Tabla 60 se presentan los aspectos que corresponden al
protocolo definido para llevar a cabo la sesión de debate.

No. Elemento. Descripción.

1 Fecha de Fecha en la cual se llevó a cabo el grupo focal.
realización.
2 Hora de inicio. Hora exacta en la cual inició el grupo focal.
3 Hora de Hora exacta en la cual terminó en grupo focal.
finalización.
4 Lugar. Lugar donde se llevó a cabo el grupo focal,
5 Activ idad. Actividad que se va a llevar a cabo durante el grupo focal.
6 Tema que tratar. Tema relacionado que se va a debatir durante el grupo focal.
7 Moderador. Actor encargado de asegurar que los participantes no se desvían de los objetivos
definidos para la realización del grupo focal.
8 Relator. Actor encargado de obtener toda la información relevante y asegurar la aplicación de los
artefactos durante el grupo focal.
9 Superv isor. Actor encargado de presentar el grupo focal y supervisar que se lleva de manera
adecuada.
10 Participantes. Personas que van a evaluar el tema a tratar, participan de la sesión de debate y
diligencian los artefactos definidos por el grupo investigador.
11 Obj etiv o general. Objetivo principal que se define previo a la realización del grupo focal.
12 Objetiv os Conjunto de objetivos relacionados a cada actividad realizada durante el grupo focal que
específicos. garantizan el cumplimiento del objetivo general.
Tabla 60. Elementos del protocolo para llevar a cabo el grupo focal.

La definición del protocolo para la ejecución del grupo focal se hizo siguiendo las
recomendaciones definidas en [19]. El protocolo utilizado durante el grupo focal se
puede ver en el Anexo 4: Protocolo para llevar a cabo el grupo focal.

97
6.3.1.2.2 Definición de elementos empleados para llevar
a cabo el grupo focal.
A continuación, en la Tabla 61 se presentan todos los artefactos utilizados para llevar
a cabo la sesión de debate, su descripción y el anexo que tiene asociado en el
documento.

No. Documento. Descripción. Anexo asociado.

1 Agenda de trabaj o Documento que indica las actividades que Anexo 1: Agenda para la
el equipo investigador va a llevar a cabo sesión de debate aplicado
para la aplicación del grupo focal. a Progresconfig.
2 Preguntas Cuestionado con un conjunto de preguntas Anexo 2: Cuestionario
relacionadas al de carácter cualitativo que debe ser aplicado a los participantes
proceso propuesto diligenciado por los participantes del grupo del grupo focal.
de debate
3 Ficha de asistencia Documento formal que indica la Anexo 3: Ficha de
información básica de cada participante asistencia del grupo focal.
para validar su asistencia al grupo focal
4 Protocolo para Documento donde se describen las Anexo 4: Protocolo para
llev ar a cabo la actividades protocolarias llevadas a cabo llevar a cabo el grupo focal.
sesión. por el grupo investigador para llevar a
cabo la sesión de debate.
5 Documento que Documento que presenta la Anexo 5: Caracterización
presenta el proceso caracterización del proceso propuesto por del proceso evaluado
propuesto. el grupo investigador. durante los grupos focales.
Tabla 61. Elementos definidos para llevar a cabo el grupo focal.

6.3.1.2.3 Fase de definición de elementos empleados

para llevar a cabo el grupo focal.
Uno de los aspectos más importantes durante la ejecución del grupo focal es el debate
realizado entre los participantes, por ello, se decidió grabar en audio el debate para
capturar la mayor cantidad de información. Además, existió un miembro del equipo
que cumplió el rol de documentador y que tuvo la función de tomar apunte de las
apreciaciones y comentarios relevantes de cada uno de los participantes. Por otra
parte, cada participante diligenció un cuestionario con preguntas relacionadas al
proceso propuesto, la plantilla del cuestionario se puede ver en el Anexo 2:
Cuestionario aplicado a los participantes del grupo focal.

6.3.1.2.4 Definición de métodos de análisis de

información derivado del grupo focal.
Posterior a llevar a cabo la sesión de debate, los moderadores y el supervisor del
grupo focal deben realizar un análisis de la información obtenida a partir de la
extracción de la información más relevante que fue capturada.

6.3.1.3 Fase de definición de grupos de discusión.

6.3.1.3.1 Método de selección de participantes.
La selección del grupo de participantes del grupo focal fue una actividad realizada por
el grupo investigador, a través de las siguientes actividades.

 Definición del perfil de cada participante: La definición del perfil se lleva a

cabo a través de cuatro (4) criterios: (i) personas con conocimiento en el
proceso de gestión de la configuración de software, (ii) personas con

98
 experiencia en la industria local del desarrollo de software, (iii) personas con
conocimiento en la aplicación de metodologías ágiles y (iv) personas
interesadas en conocer sobre la gestión de la configuración de software.
 Identificación de participantes potenciales: A partir de la condición de
perfiles identificados, se identificaron aquellas personas que cumplían con las
características mencionadas anteriormente.

Debido a la diversidad y la cantidad de participantes involucrados, se realizaron dos

sesiones de debate en momentos y lugares separados siguiendo el mismo protocolo y
presentando la misma caracterización del proceso sin dar a conocer a los participantes
que eran parte de un grupo independiente.

El primer grupo fue conformado por miembros expertos en el área de la ingeniería de

software que trabajan como docentes en la Universidad del Cauca. El segundo grupo
fue conformado por miembros de una empresa desarrolladora de software local, la
cual por motivos de confidencialidad en adelante se tratará como “LA EMPRESA”, la
cual lleva más de una década en la industria y se dedica actualmente a proveer
soluciones informáticas en el área de la salud. A continuación, en la Tabla 62 y la
Tabla 63, se presenta la descripción del perfil profesional de cada uno de los
participantes que hicieron parte de la evaluación de la propuesta en los grupos focales
que se llevaron a cabo:

No. Ocupación. Cargo Actual. Experiencia laboral. Estudios realizados.

1 Ingeniero de Docente en la  Análisis de requisitos funcionales.  Pregrado en ingeniería
Sistemas Universidad del  Desarrollo de software. de sistemas.
Cauca  Docente en la Universidad del  Especialista en
Cauca. gerencia de proyectos.
 Especialista en gerencia de  Estudiante de maestría
proyectos. en computación.
 Curso s de arquitectura
de aplicaciones web.
 Curso de análisis de
requerimientos.

2 Ingeniero de Docente en la  Análisis de requisitos funcionales.  Pregrado en ingeniería

Sistemas Universidad del  Líder de desarrollo. de Sistemas.
Cauca  Líder de calidad y configuración.  Especialista en redes
 Coordinador de tecnología. de comunicación.
 Gerente de proyectos en  Especialista. en
tecnología. sistemas gerenciales
 Coordinador de interfaces. de ingeniería
 14 años de experiencia.  Magíster en
computación.
 Auditor ICONTEC.
 Certificación en testing
ágil.
 Estudiante de
doctorado.
3 Ingeniero de Docente en la  Experiencia en la mejora de  Pregrado en ingeniería
Sistemas Universidad del procesos software en pequeñas de sistemas.
Cauca empresas.  Curso s de calidad de
 Experiencia en la evaluación del software.
proyecto COMPETISOFT y la  Curso s de algoritmia y
norma ISO/IEC 15504. programación.
 Experiencia como parte del
equipo de gestión de la
configuración en proyectos
software.
 Experiencia en desarrollo de
software.
4 Ingeniero de Docente en la  Docente en ingeniería de  Pregrado en ingeniería
Sistemas Universidad del software. de sistemas.
Cauca  Desarrollador de software.  Magíster en
 Consultor en arquitectura de computación.
software y HCI.

99
  Experiencia en la evaluación de
proyectos COMPETISOFT.
 Docente en cursos de ingeniería
de software para cursos de
especialización.
Tabla 62. Perfil de los participantes que asistieron al grupo focal llevado a cabo en la
Universidad del Cauca.

No. Ocupación. Cargo Actual. Experiencia laboral. Estudios realizados.

1 Ingeniero de Sistemas Consultor de  9 años de experiencia  Pregrado en ingeniería
proyectos. participando en diferentes de sistemas.
roles dentro del proceso de  Especialización en
ingeniería de software. gerencia de proyectos
 Auditor interno de informáticos.
proyectos.  Certificación como
PMP.
 Certificación en ISTQB
Foundation.
 Auditor interno SENA.
 Gestión de riesgos.
2 Ingeniero de Sistemas Gerente  Experiencia en la  Pregrado en ingeniería
técnico. implementación de los de Sistemas.
modelos (CMMI-DEV e
ISO/IEC 15504) en la
empresa en la cual trabaja
actualmente
3 Ingeniero Electrónico Administrador  Desarrollo de software en  Pregrado en ingeniería
y Telecomunicaciones de bases de java. electrónica y
datos.  Gestión y administración de telecomunicaciones
servidores y bases de  Master en dirección de
datos. empresas tecnológicas
 Experiencia en desarrollo
de software en el sector de
la salud.
 Scrum Master.
4 Estudiante de Desarrollador  Desarrollo de software.  Estudiante de último
ingeniería de sistemas de software.  Análisis de requerimientos semestre de ingeniería
funcionales. de sistemas.
 Conocimiento en la norma
ISO/IEC 15504.
 Conocimiento avanzado en
Delphi.
5 Ingeniero Electrónico Coordinador de  13 años de experiencia en  Pregrado en ingeniería
y Telecomunicaciones desarrollo. desarrollo de software. electrónica y
 Experiencia en dirección de telecomunicaciones
proyectos informáticos.  Especialización en
gestión de las TIC.
 PMP certificado.
6 Ingeniero de Sistemas Coordinador de  Participación en el proceso  Pregrado en ingeniería
desarrollo de certificación de la norma de sistemas.
ISO/IEC 15504 para el  Magister en
proceso de gestión de la administración de
configuración. empresas con
 Experiencia en especialidad en
construcción, diseño y dirección de
desarrollo de software. proyectos.
 Participación en proceso de
certificación en CMMI v 1.3
para los procesos de
arquitectura, construcción
de productos software y
gestión de la configuración.
 Dirección y coordinación de
equipos de desarrollo.
 Experiencia en la aplicación
de procesos de desarrollo
de software.
 Experiencia en desarrollo
multi-capa, Delphi, java,
Maven, jpa, ejb.

100
Tabla 63. Perfil de los participantes que asistieron al grupo focal llevado a cabo en LA
EMPRESA.

6.3.1.4 Fase de conducción de la sesión de debate.

6.3.1.4.1 Conducción de la sesión de debate.
La ejecución del debate fue coordinada por el moderador y el supervisor, y efectuada
por los participantes. Para tal fin se hizo uso del planeamiento, materiales, y demás
artefactos resultantes de la primera fase. Además, debido a la naturaleza del estudio
llevado a cabo, el grupo investigador decidió realizar dos grupos focales con el objetivo
de obtener realimentación de expertos que están actualmente en el sector académico
y de expertos que participan actualmente de manera activa en la industria local de
desarrollo de software. A continuación, en la Tabla 64 se presentan las actividades
llevadas a cabo en cada una de las sesiones de debate:

No. Descripción. Hora

Desde Hasta
1 Agradecimiento a los participantes por asistir a la sesión.
2 Presentación del grupo investigador realizada por el sup ervisor.
 Discutir para que se utilizarán los resultados.
 Indicar por qué fueron seleccionados los participantes.
3 Presentación de la propuesta (Progresconfig)
4 Discusión realizada por los participantes para expresar sus apreciaciones sobre las
actividades definidas en el proceso propuesto.
5 Refrigerio.
6 Discusión realizada por los participantes para expresar sus apreciaciones sobre las
actividades definidas en el proceso propuesto.
7 Los participantes responden la encuesta definida por el grupo investigador.
8 Los participantes llenan la ficha de asistencia.
9 Agradecimientos a los participantes realizado por el grupo investigador.
10 Cierre de sesión.
Tabla 64. Protocolo llevado a cabo para realizar el grupo focal.

Además, cada uno de los debates se llevó a cabo utilizando los materiales para la
captura de información definidos previamente. En la Tabla 61 se presentan los
elementos utilizados durante la sesión de debate.

101
 Figura 6. Sesión de debate llevada a cabo en la Universidad del Cauca.

Figura 7. Sesión de debate llevada a cabo en LA EMPRESA.

6.3.1.4.2 Captura de información.

El relator es el actor encargado de obtener la información relevante durante el grupo
focal, registrando de manera sistemática los conceptos, características y aportes de
mayor importancia ofrecidos por cada uno de los participantes durante cada una de las
actividades debatidas durante la sesión de debate. Asimismo, se utilizaron las técnicas
de captura de información definidos durante la fase de definición de métodos de
captura.

102
6.3.1.5 Fase de análisis de información obtenida y
reporte de resultados.
6.3.1.5.1 Análisis de información.
Posterior a la aplicación de los grupos focales se llevó a cabo el análisis de los
artefactos obtenidos durante la sesión de debate, entre los cuales se encuentran:
análisis del cuestionario realizado a los participantes, análisis del audio registrado
durante las sesiones y la clasificación de los aportes realizados por los participantes.

6.3.1.5.2 Reporte de resultados.

A continuación, se presentan las actividades llevadas a cabo para analizar la
información obtenida durante los grupos focales.

6.3.1.5.2.1 Observaciones extraídas de la relatoría.

La información extraída durante las sesiones de debate se realizó siguiendo de
manera secuencial las siguientes actividades: (i) Transcripción de la información
registrada en el soporte de audio grabado durante las sesiones de debate y (ii)
clasificación de los aportes y observaciones realizados por los participantes. Como
resultado, se identificaron los aspectos positivos durante la evaluación y los aportes
que presentan oportunidades de mejora para la propuesta. A continuación, se
presentan los aspectos positivos identificados durante las sesiones de debate:

 La propuesta es innovadora y propone una solución para la gestión de la

configuración de software que no se ha contemplado.
 El proceso es aplicable a las empresas locales en la industria de desarrollo de
software.
 Las actividades son coherentes y claras.
 Las tareas son claras y están definidas de acuerdo con la actividad que tiene
asociada.
 La definición de niveles de capacidad es acertada y permite a las empresas
realizar una adopción gradual del proceso de manera escalonada.
Además, se presentan los aportes realizados por los participantes que presentan
oportunidades de mejora para la propuesta. Los aspectos que representan aspectos
de mejora que se encuentran dentro del alcance de la propuesta se representan con el
signo (+) y se han incluido en la versión final de la propuesta, y los aspectos de mejora
que deben considerarse pero que no hacen parte del alcance del proyecto se
representan con el signo (-). A continuación, en la Tabla 65 y la Tabla 66 se describen
cada uno de los aspectos identificados que representan aspectos de mejora aplicables
dentro del alcance del proyecto y aquellos que están por fuera de los objetivos
definidos pero que deben tenerse en cuenta:

Aspecto de Descripción
mej ora
(+) Es necesario realizar una categorización de los roles con un nivel mayor de detalle para identificar
los roles mínimos que deberían tenerse en cuenta por tipo de empresa.
(+) Debería definirse una tarea de estandarización de los ítems de configuración.
(+) El proceso de auditoría debería ser considerado un proceso de monitoria de los ítems de
configuración y de las líneas base.
(+) Deberían describirse las tareas relacionadas a la monitoria del proceso con un nivel mayor de
detalle.
(+) Debería definirse una tarea que identifique la frecuencia en la cual deben ser llevadas a cabo las

103
 evaluaciones físicas y funcionales a los ítems de configuración.
(+) Debería realizarse un análisis que permita identificar si un rol puede ser desempeñado por diferentes
recursos.
(+) Es necesario revisar las tareas descritas y su correspondencia con los diagramas de flujo para
identificar posibles inconsistencias en la documentación.
(+) Debería revisarse las tareas de petición de cambios y establecer criterios de prioridad que permitan
evaluar las peticiones de manera más rápida y evitar cuellos de botella.
(+) Se debería hacer una clasificación de las líneas base De acuerdo con criterios funcionales de la
misma manera que se hace con los ítems de configuración.
Tabla 65. Aspectos de mejora dentro del alcance del proyecto.

Aspecto de Descripción
mej ora
(-) Descripción de plantillas, herramientas y tutoriales para apoyar la adopción del proceso.
(-) Definición de guías de adaptación del proceso de acuerdo con el tipo de empresa que requiera
implementar el proceso.
(-) Definición de métricas e indicadores derivados del proceso de monitoreo para llevar a cabo las tareas
de auditoría externa y evaluar el cumplimiento del proceso.
(-) Mapear los niveles de capacidad definidos con los niveles propuestos por CMMI -DEV y la norma
ISO/IEC 15504 para realizar un análisis de correspondencia a detalle entre la propuesta y los modelos
relacionados.
(-) Debería contemplarse una adaptación del proceso aplicado a líneas de producción de software.
Tabla 66. Aspectos de mejora fuera del alcance del proyecto.

A partir de los resultados obtenidos en las sesiones de debate, el grupo investigador

realizó un análisis de las observaciones y sugerencias identificadas, obteniendo como
resultado un proceso de realimentación incremental que permitió proponer la versión
final de la propuesta que se puede ver en la Tabla 51.

6.3.1.5.2.2 Análisis de los cuestionarios.

Para llevar a cabo la evaluación se realizó una sesión de debate conformada por
cuatro (4) expertos invitados que trabajan en la Universidad del Cauca. Además, se
realizó otra sesión de debate conformada por (6) expertos invitados que trabajan de
manera activa en la industria local de desarrollo de software. Al final de cada sesión de
debate, el grupo investigador entregó una encuesta a cada uno de los participantes
para evaluar los aspectos más relevantes de la propuesta de manera cualitativa. Los
cuestionarios respondidos por cada participante se presentan en el disco compacto
anexo a este documento.

El análisis de los cuestionarios se realizó identificando la cantidad de participantes que

respondieron cada opción definida para cada pregunta y realizando un análisis
cuantitativo de las respuestas obtenidas en cada una de las preguntas. Además, el
análisis cuantitativo fue complementado con un análisis cualitativo que permitió
identificar la razón que pudo motivar a los participantes elegir una opción con respecto
a otra. Cada pregunta tiene dos opciones posibles (Si, No), y en algunas preguntas se
pide al participante describir por qué eligió una pregunta con una descripción corta. El
cuestionario utilizado durante las sesiones de debate se presenta en el Anexo 2:
Cuestionario aplicado a los participantes del grupo focal.

6.3.1.5.2.2.1 Análisis de cada pregunta.

A continuación, en la Figura 8 se presenta la cantidad de participantes que
respondieron cada opción para todas las preguntas de manera general.

104
 10 10 10
10 9 9
9 8 8
8 7
7 6 6
6
5 4 4
4 3
3 2 2
2 1 1
1 0 0 0
0

Si No

Figura 8. Cantidad de participantes que respondieron cada opción de cada pregunta.

Luego de obtener los resultados globales en las respuestas de cada uno de los
participantes fue posible realizar un análisis detallado que permitió identificar los
factores más relevantes por cada pregunta. A continuación, se presenta el análisis de
cada pregunta de acuerdo con los resultados obtenidos y las observaciones realizadas
por los participantes durante las sesiones de debate:

 Pregunta 1: De acuerdo con su experiencia ¿Considera importante aplicar un

proceso de gestión de la configuración de software en un proyecto de
desarrollo?
De acuerdo con los resultados de la encuesta realizada, se logró determinar que los
diez (10) participantes involucrados en el estudio respondieron que SÍ es importante
aplicar un proceso de gestión de la configuración de software en un proyecto de
desarrollo y consideran que la gestión de la configuración de software es un área de
proceso que no se aplica en gran medida en las empresas de la ciudad. A
continuación, en la Figura 9 se pueden observar los resultados obtenidos en la primera
pregunta.
10
10
9
8
7 6
6
5 4
4
3
2
1 0 0 0
0
Si No Si No Si No
Global Universidad del LA EMPRESA
Cauca
Figura 9. Tendencia de los resultados de la primera pregunta.

105
  Pregunta 2: ¿Considera que el proceso propuesto puede ser aplicado en una
empresa desarrolladora de software?

De acuerdo con los resultados de la encuesta realizada, se logró determinar que de

los diez (10) participantes, nueve (9) consideran que el proceso SI puede ser aplicado
en una empresa desarrolladora de software. Sin embargo, un (1) participante
considera que el proceso no sería aplicable de acuerdo con la distribución de roles
propuestos. Además de los nueve (9) participantes que respondieron SI, cinco (5)
indicaron que debería realizarse una caracterización de los roles con un nivel mayor
de detalle para identificar los roles necesarios que deberían ser tomados en cuenta por
tipo de empresa, es decir, deberían definirse los roles mínimos que deberían ser
considerados por tipo de empresa para la adopción del proceso. En la Figura 10 se
pueden observar los resultados obtenidos en la segunda pregunta.

10 9
9
8
7 6
6
5
4 3
3
2 1 1
1 0
0
Si No Si No Si No
Global Universidad del LA EMPRESA
Cauca
Figura 10. Tendencia de los resultados de la segunda pregunta.
Además, en la Tabla 67 se presentan las observaciones textuales realizadas por los
participantes en la respuesta de esta pregunta:

Participante. Observ ación.

1 Debería considerarse el tamaño de la empresa junto con la can tidad de roles y actividades para crear
una adaptación más flexible y viable.
2 Es importante considerar los tamaños de las empresas y roles que fueron propuestos.
3 Creo que se puede aplicar, pero con guías de adaptación dependiendo del tamaño de la PyM E.
4 Pienso que podrían definirse menos roles o acoplar los existentes, ya que podría n no tenerse todos en
una microempresa.
5 Se tendría problema en micro. ¿Cómo distribuir los roles si se tienen solamente tres empleados?
6 Deben establecer un alcance explícito para la propuesta. Por ejemplo: Son necesarios mínimo 5
personas para cubrir los roles propuestos.
Tabla 67. Transcripción de observaciones realizadas a la primera pregunta.

 Pregunta 3: ¿Considera que las actividades propuestas en el proceso son

apropiadas y aplicables por una empresa desarrolladora de software?
De acuerdo con los resultados de la encuesta realizada, se logró determinar que los
diez (10) participantes involucrados en el estudio consideran que las actividades
propuestas SÍ son adecuadas y se podrían aplicar en una empresa desarrolladora de
software que pretenda adoptar el proceso. En la Figura 11 se pueden observar los
resultados obtenidos en la tercera pregunta.

106
 10
10
9
8
7 6
6
5 4
4
3
2
1 0 0 0
0
Si No Si No Si No
Global Universidad del LA EMPRESA
Cauca
Figura 11. Tendencia de los resultados de la tercera pregunta.

 Pregunta 4: ¿Considera que el proceso ha contemplado elementos de agilidad

que puedan ser adoptados por una empresa desarrolladora de software?
De acuerdo con los resultados obtenidos de la encuesta realizada, ocho (8) de los
participantes involucrados consideran que SÍ se han contemplado elementos de
agilidad durante la definición de la propuesta. Sin embargo, dos (2) participantes
consideran que no se han definido aspectos ágiles con el suficiente nivel de detalle y
proponen que deberían desarrollarse guías de adaptación que permita a los diferentes
tipos de empresa adoptar el proceso de manera más adecuada. En la Figura 12 se
pueden observar los resultados obtenidos de la cuarta pregunta.

10
9 8
8
7 6
6
5
4
3 2 2 2
2
1 0
0
Si No Si No Si No
Global Universidad del LA EMPRESA
Cauca
Figura 12. Tendencia de los resultados de la cuarta pregunta.

Además, en la Tabla 68 se presentan las observaciones textuales realizadas por los

participantes en la respuesta de esta pregunta:

Participante. Observ ación.

1 Aunque se contemplan los roles, podrían tratar de acoplar algunas actividades si es posible.
2 Se sugiere tener en cuenta guías de adaptación que hagan más liviano e l proceso.
3 En lo ágil no hay procesos, se definen políticas, la gente se comunica, se auto organiza sin tener un
proceso.
4 Se habla bastante de formatos y plantillas.

107
 No se tiene en cuenta la auto organización de los equipos, Las tareas son asignadas por una
comisión.
La comisión se puede convertir en un cuello de botella.
5 Revisar las actividades asumidas por el CCC debido a que puede generar cuellos de botella al
momento de proponer y asignar cambios.
Tabla 68. Transcripción de observaciones realizadas a la cuarta pregunta.

 Pregunta 5: ¿Considera que los roles propuestos en el proceso pueden ser

asumidos en su totalidad por los recursos humanos disponibles en una
empresa desarrolladora de software?
De acuerdo con los resultados obtenidos de la encuesta realizada, cuatro (4) de los
participantes involucrados consideran que los roles propuestos son adecuados y
pueden ser asumidos por los recursos humanos disponibles en una empresa
desarrolladora de software. Sin embargo, seis (6) participantes indicaron que la
cantidad de roles propuestos para el proceso no pueden ser asumidos por una
microempresa. Además, los seis (6) participantes que contestaron NO, consideran
necesario que se realice una caracterización de los roles por tipo de empresa para
identificar los roles mínimos que permitan a una empresa adoptar el proceso de
manera adecuada. En la Figura 13 se pueden observar los resultados obtenidos de la
quinta pregunta.

10
9
8
7 6
6
5 4
4 3 3
3 2 2
2
1
0
Si No Si No Si No
Global Universidad del LA EMPRESA
Cauca
Figura 13. Tendencia de los resultados de la quinta pregunta.

Además, en la Tabla 69 se presentan las observaciones textuales realizadas por los

participantes en la respuesta de esta pregunta:

Participante. Observ ación.

1 Deberían integrarse las funciones en menos roles y dar una propuesta de roles por nivel de capacidad.
2 Esos roles serían asumidos por los mismos desarrolladores.
3 Considero que la adaptación de roles debe ser más flexible o simplificada.
4 Es posible que una microempresa no contemple roles como director de proyectos, técnico de
configuración o dueño del producto.
5 Sí, pero se debe tener en cuenta que una persona puede tener varios roles.
6 Aunque pueden ser asumidas, quizá en las micro no puedan ser asumidos en su totalidad, por eso
sería ideal acoplar algunos roles.
7 En una empresa con tres empleados se ve difícil su aplicación según los roles requeridos.
8 Si es una pequeña o mediana empresa existen recursos humanos que puedan asumi r los roles y
actividades. Para una microempresa no existen los recursos humanos para asumir los roles.
Especialmente no hay personal disponible para la comisión de gestión de la configuración y equipo de
desarrollo.
9 Los roles propuestos tienen responsabilidades importantes que tal vez una VSE no sean factibles de
lograr.
Tabla 69. Transcripción de observaciones realizadas a la quinta pregunta.

108
  Pregunta 6: ¿Considera usted que las tareas relacionadas a cada actividad del
proceso son adecuadas?
De acuerdo con los resultados de la encuesta realizada, ocho (8) de los participantes
involucrados en el estudio consideran que las tareas relacionadas a cada actividad SÍ
son adecuadas y consistentes con respecto a sus actividades asociadas. Sin embargo,
dos (2) participantes indicaron que algunas tareas podrían fusionarse. Además, un (1)
participante que contestó SI, indicó que deberían incluirse tareas de estandarización
para apoyar la identificación de los ítems de configuración. En la Figura 14 se pueden
observar los resultados obtenidos en la sexta pregunta.

10
9 8
8
7 6
6
5
4
3 2 2 2
2
1 0
0
Si No Si No Si No
Global Universidad del LA EMPRESA
Cauca
Figura 14. Tendencia de los resultados de la sexta pregunta.

Además, en la Tabla 70 se presentan las observaciones textuales realizadas por los

participantes en la respuesta de esta pregunta:

Participante. Observ ación.

1 La actividad de identificación de los IC debería contener una tarea de estandarización de los ítems de
configuración.
2 La mayoría son adecuadas, pero se deben revisar otras que se pueden fusionar o hacer más ágiles.
3 Se recomienda revisar los comentarios dados para ajustar algunas actividades de forma, fusiones, no
necesarias.
Tabla 70. Transcripción de observaciones realizadas a la sexta pregunta.

 Pregunta 7: ¿Los diagramas presentados describen de forma clara el flujo del

proceso y sus actividades?
De acuerdo con los resultados de la encuesta realizada, se logró determinar que
nueve (9) participantes involucrados en el estudio consideran que los diagramas
presentados en el proceso SÍ son claros y describen cada actividad de manera
consistente. Sin embargo, un (1) participante que contestó NO y un (1) participante
que contestó SÍ, consideran que debería realizarse una revisión para identificar
inconsistencias entre la documentación del proceso y los diagramas presentados para
evitar ambigüedades que lleven al lector a confusiones. En la Figura 15 se pueden
observar los resultados obtenidos en la séptima pregunta.

109
 10 9
9
8
7 6
6
5
4 3
3
2 1 1
1 0
0
Si No Si No Si No
Global Universidad del LA EMPRESA
Cauca
Figura 15. Tendencia de los resultados de la séptima pregunta.
Además, en la Tabla 71 se presentan las observaciones textuales realizadas por los
participantes en la respuesta de esta pregunta:

Participante. Observ ación.

1 Yo entendí los diagramas en el momento de la explicación de los chicos, cuando los leí tuve vacíos.
2 Utilizar los mismos nombres en elementos de proceso.
Tabla 71. Transcripción de observaciones realizadas a la séptima pregunta.

 Pregunta 8: ¿Considera que el proceso propuesto carece de algún aspecto

importante?
De acuerdo con los resultados de la encuesta realizada, se logró determin ar que
cuatro (4) participantes involucrados en el estudio indicaron que el proceso no carece
de aspectos importantes que se deban tener en cuenta. Sin embargo, seis (6)
participantes consideran que debería realizarse una descripción más detallada del
proceso de monitoria para posteriormente definir métricas e indicadores que puedan
ser útiles en procesos de auditoría externa, y un (1) participante indicó que sería
importante definir los requisitos mínimos que debería considerar una empresa para
aplicar el proceso. Además, los participantes también recomiendan que el proceso
debiera complementarse con la definición de plantillas, guías y herramientas para
apoyar la adopción del proceso. En la Figura 16 se pueden observar los resultados
obtenidos en la octava pregunta.

10
9
8
7 6
6
5 4 4 4
4
3 2
2
1 0
0
Si No Si No Si No
Global Universidad del LA EMPRESA
Cauca
Figura 16. Tendencia de los resultados de la octava pregunta.

110
Además, en la Tabla 72 se presentan las observaciones textuales realizadas por los
participantes en la respuesta de esta pregunta:

Participante. Observ ación.

1 Sería bueno incluir gráficas que ayuden a complementar los procesos. Hay una diferencia entre lo que
se lee y la explicación de los chicos.
2 Detallar el proceso de monitoria con ítems de evaluación o frecuencias, etc.
3 Podría ser conveniente agregar formatos de plantillas. También podría ser profundizar más en la parte
de seguimiento y control que es uno de los puntos críticos como proyecto.
4 Definir cuáles son los requisitos mínimos que debería tener la empresa que desee aplicar el proceso.
Dotarla de elementos ágiles.
5 Como trabajo futuro se deben plantear métricas que permitan saber si su proceso funciona
correctamente. No puedes mejorar lo que no se ha medido. Se debe aclarar el alcance del proceso en
cuanto a proceso de desarrollo y/o mantenimiento de software.
6 Alcance de auditoría más claro, tal vez monitoreo.
Roles por niveles de capacidad.
Tabla 72. Transcripción de observaciones realizadas a la octava pregunta.

 Pregunta 9: De acuerdo con su experiencia ¿Considera que el proceso puede

aplicarse con éxito en un proyecto de desarrollo de software?
De acuerdo con los resultados de la encuesta realizada, se logró determinar que los
diez (10) participantes involucrados en el estudio consideran que el proceso SÍ puede
ser aplicado en una empresa desarrolladora de software de manera exitosa. Sin
embargo, de los diez (10) participantes, un (1) participante indicó que el proceso
puede complementarse con la definición de plantillas, guías y herramientas de apoyo.
En la Figura 17 se pueden observar los resultados obtenidos en la novena pregunta.
10
10
9
8
7 6
6
5 4
4
3
2
1 0 0 0
0
Si No Si No Si No
Global Universidad del LA EMPRESA
Cauca
Figura 17. Tendencia de los resultados de la novena pregunta.

Además, en la Tabla 73 se presentan las observaciones textuales realizadas por los

participantes en la respuesta de esta pregunta:

Participante. Observ ación.

1 Aunque faltaría un documento que soporte el detalle de las actividades, ejemplos y plantillas. Una
buena herramienta software no estaría de más. Igual un video tutorial.
Tabla 73. Transcripción de observaciones realizadas a la novena pregunta.

 Pregunta 10: ¿Considera que los niveles de capacidad propuestos para

soportar el proceso son adecuados?
De acuerdo con los resultados de la encuesta realizada, se logró determinar que siete
(7) participantes involucrados en el estudio consideran que los niveles de capacidad SÍ

111
son adecuados y aplicables. Sin embargo, tres (3) participantes indicaron que el nivel
esencial debería contemplar más tareas para no limitarlo solo a la identificación de los
IC en el proyecto. Además, un (1) que contestó SI, indicó que deberían prop onerse
indicadores y métricas a partir de los resultados de las evaluaciones. En la Figura 18
se pueden observar los resultados obtenidos en la décima pregunta.

10
9
8 7
7 6
6
5
4 3 3
3
2 1
1 0
0
Si No Si No Si No
Global Universidad del LA EMPRESA
Cauca
Figura 18. Tendencia de los resultados de la décima pregunta.

Además, en la Tabla 74 se presentan las observaciones textuales realizadas por los

participantes en la respuesta de esta pregunta:

Participante. Observ ación.

1 Eso es bueno, ayuda a adoptar el proceso de manera incremental.
2 Es importante definir algunos indicadores que permitan medir el cumplimiento el proceso
principalmente en el nivel 3.
3 Es importante ubicar estos niveles de capacidad como se mapean con los propuestos por ejemplo con
ISO/IEC 15504.
4 Pienso que es ideal, porque es más factible ser alcanzados por las pequeñas empresas.
5 La complejidad del proceso está bien dividida, un nivel esencial indica una identificación de los IC y un
nivel más avanzado incluye el manejo y control de cambios e incluye todo. Además, un proceso de
auditoría y generación de líneas base.
6 El nivel esencial solo se limita a identificar elementos que pueden cambiar. Para que la gestión de la
configuración exista se deben incluir otras tareas básicas.
7 El nivel esencial únicamente identifica todos los elementos sensibles de configuración y designa los
responsables, por lo tanto, se establece únicamente la planeación, pero no se ejecuta el proceso para
controlar y gestionar los cambios. Si es un proceso esencial mínimo se deben gestionar y controlar los
cambios de forma básica.
8 Podría revisarse la posibilidad de ajustar unos roles para cada nivel.
El nivel 1 requiere una actividad que asegure de manera mínima el control de configuración. Esta tarea
está en el nivel 2.
Tabla 74. Transcripción de observaciones realizadas a la décima pregunta.

6.3.1.5.2.3 Comparación entre la propuesta evaluada y

la versión refinada.
Como resultado de aplicar los grupos focales, fue posible obtener realimentación de
cada uno de los participantes, lo cual permitió crear una versión refinada del proceso.
A continuación, en la Tabla 75 se presentan las diferencias entre la primera versión del
proceso y la versión final que resultó de aplicar los aspectos de mejora identificados
durante el análisis de resultados.

112
 Primera v ersión del proceso. Versión final del proceso.
Define un conjunto de roles que aplican de manera Se incluye el apartado En el cual se realiza una
independiente al tipo de empresa. caracterización por tipo de empresa con el objetivo de
identificar los roles necesarios que deberían tenerse en
cuenta para la adopción del proceso dependiendo del
tipo de empresa.
No existe una visión general de la propuesta que permita Se incluye el apartado En el cual se realiza una
ver el problema de manera global. descripción a alto nivel del problema a atacar, y
posteriormente se realiza una abstracción a alto nivel de
todos los artefactos propuestos para la definición del
proceso.
La actividad 2 del proceso (GCSA.A2) Se compone por Durante los grupos focales se detectaron las siguientes
las siguientes tareas: acciones de mejora aplicables a la actividad 2 del
proceso.
T1: Identificar los ítems de configuración (IC)
T2: Describir cada IC.  Las tareas T1 y T2 del proceso original pueden
T3: Definir los repositorios para llevar el control de los IC. unificarse en una sola actividad.
 La tarea T3 debería ser la primera tarea
categorizada en la actividad debido a que
deberían identificarse previamente las
herramientas y repositorios para almacenar los
IC
 Es necesario identificar las dependencias entre
IC y estandarizar los IC para evitar
inconsistencias.
 Es necesario indicar qué aspectos deberían
tenerse en cuenta para la definición de un IC.
Como resultado, La actividad 2 del proceso se modificó y
como resultado se definió la actividad con las siguientes
tareas:

T1: Definir los repositorios para llevar el control de los IC.

T2: Describir los ítems de configuración (IC)
T3: Identificar dependencias entre IC.
T4: Estandarizar los IC.
La actividad 3 del proceso (GCSA.A3) Se compone por Durante los grupos focales se detectaron las siguientes
tres tareas: acciones de mejora aplicables a la actividad 3 del
proceso.
T1: Definir los elementos que constituyen una línea base.
 Se recomienda que las líneas base sean
categorizadas a través de criterios funcionales
siguiendo el mismo patrón para la identificación
de los IC.
Como resultado, La actividad 3 del proceso se modificó y
como resultado se definió la actividad con las siguientes
tareas:

T1: Identificar una línea base.

La tarea T1 incluye recomendaciones en las que se

indica al lector que debería categorizar las líneas base
mediante criterios funcionales.
La actividad 4 del proceso (GCSA.A4) Se compone por Durante los grupos focales se detectaron las siguientes
las siguientes tareas: acciones de mejora aplicables a la actividad 4 del
proceso.
T1: Definir una política para el control de versiones de las
líneas base.  Es necesario establecer tareas para controlar
T2: Definir una estructura para el control de versiones los conflictos derivados de la unión entre líneas
para los IC de análisis y diseño. base en el proyecto.
T3: Definir una estructura para el control de versiones
para los IC de desarrollo e implementación. Como resultado, se agregó en la actividad 4 del proceso
una nueva tarea que identifica los aspectos necesarios
para tener en cuenta para controlar la unión entre líneas
base. Finalmente, la actividad 3 se compone por las
siguientes tareas:

T1: Definir una política para el control de versiones de las

líneas base.
T2: Identificar herramientas para controlar los cambios en
los IC de análisis y diseño.
T3: Identificar herramientas para controlar los cambios en
los IC de desarrollo e implementación.
T4: Definir criterios para la unión (merge) entre líneas
base.

113
La actividad 6 del proceso (GCSA.A6) Se compone por Durante los grupos focales se detectaron las siguientes
las siguientes tareas: acciones de mejora aplicables a la actividad 6 del
proceso.
T1: Definir una plantilla para las solicitudes de cambio.
T2: Definir herramientas para gestionar las solicitudes de  La tarea T2 crea doble trabajo debido a que el
cambio en los IC. proceso propone que se definan plantillas y
T3: Definir una política de liberación y lanzamiento. posteriormente se identifiquen herramientas
T4: Definir un protocolo para las solicitudes de cambio para soportar dichas plantillas.
realizadas por un miembro del equipo de desarrollo o el
experto en configuración.
T5: Definir un protocolo para las solicitudes de cambio Como resultado, se eliminó la tarea T2 del proceso.
Además, se modificaron las tareas T4 y T5 de la
realizadas por los interesados o por un cliente.
propuesta original quitando l as referencias a la tarea T2.
Finalmente, la actividad 6 se compone por las siguientes
tareas:

T1: Definir herramientas para controlar las solicitudes de

cambios en los IC.
T2: Definir una política de liberación y lanzamiento.
T3: Identificar la solicitud de cambio solicitada por un
miembro del equipo de desarrollo.
T4: Identificar la solicitud de cambio solicitada por los
interesados o por el cliente.

Las tareas T3 y T4 incluyen una recomendación para

indicar al lector que las peticiones pueden ser
categorizadas a través de criterios de prioridad para
evitar cuellos de botella.
La actividad 7 del proceso (GCSA.A7) Se compone por Durante los grupos focales se detectaron las siguientes
las siguientes tareas: acciones de mejora aplicables a la actividad 7 del
proceso.
T1: Definir criterios para llevar a cabo una auditoría física
y funcional.  El proceso de auditoría debería ser
T2: Llevar a cabo la auditoría física de los IC. considerado un proceso de monitoreo del
T3: Llevar a cabo la auditoría funcional de las líneas proceso.
base.  Se recomienda realizar un análisis previo para
T4: Definición y administración de respaldos. definir la frecuencia en la cual se llevarían a
T5: Re solver no conformidades en el proceso de cabo las evaluaciones de los IC y las líneas
auditoría. base.
Como resultado, la actividad 7 cambió de nombre y se
denominó Proceso de monitoreo. Además, se
modificaron todas las referencias a auditoría por
evaluación para indicar al lector que la actividad tiene
como propósito evaluar el proceso. Adicionalmente, las
tareas T1 y T2 incluyen una sub-tarea para identificar la
frecuencia con la que se debe llevar a cabo la evaluación
de los IC. Finalmente, la actividad 7 se compone por las
siguientes tareas:

T1: Definir criterios para llevar a cabo una evaluación

física y funcional.
T2: Llevar a cabo la evaluación física de los IC.
T3: Llevar a cabo la evaluación funcional de las líneas
base.
T4: Definición y administración de respaldos.
T5: Re solver no conformidades en la evaluación física y
funcional.
Existen inconsistencias entre los pasos definidos para Se validaron las tareas y su correspondencia con los
cada tarea de la actividad y los diagramas de flujo diagramas para crear una versión consistente que
propuestos. represente de manera clara el proceso a través de pasos
o de diagramas de flujo sin ambigüedad.
El proceso no indica al lector el alcance del proceso. Se incluye una descripción en el apartado 5.1 En la cual
se indica al lector los aspectos que se deberían tener en
cuenta para la adopción del proceso y sus limitaciones.
Tabla 75. Comparación entre la propuesta evaluada en los grupos focales y la versión
refinada del proceso.

114
6.4 Sesgos de la evaluación.
Debido a la naturaleza del estudio realizado para para la evaluación de la propuesta,
existe un grado de subjetividad que debe ser considerado para el análisis de los
resultados obtenidos posteriormente. Por lo cual, para llevar a cabo este trabajo de
investigación se ha disminuido el grado de subjetividad mediante la aplicación de
técnicas de análisis cuantitativas para cada uno de los artefactos obtenidos. Asimismo,
los cuestionarios diligenciados por cada uno de los participantes fueron sometidos a
validación de expertos en el área de mejora de procesos, los cuales hacen parte de
este trabajo de investigación como asesores externos y han realizado la validación de
las actividades y el análisis de los resultados obtenidos a partir de la evaluación de la
propuesta.

115
 Capítulo VII. Conclusiones y
lecciones aprendidas.
7.1 Análisis de los objetivos de investigación.
Para llevar a cabo este trabajo de investigación se definieron un conjunto de objetivos
que fueron cumplidos de manera sistemática siguiendo todas las actividades descritas
en este documento. A continuación, se presenta un resumen para indicar cómo se
logró cumplir con cada uno de los objetivos propuestos:

 OE1. Llevar a cabo una revisión bibliográfica detallada en el área de gestión de

la configuración de software que permita identificar las iniciativas, soluciones,
trabajos relacionados y herramientas utilizadas para soportar la gestión de la
configuración de software.
El Capítulo II. Marco teórico y estado del arte, describe los principales trabajos e
iniciativas relacionadas al área de la gestión de la configuración de software y su
aplicación en micro, pequeñas y medianas empresas desarrolladoras de software.
Esto se llevó a cabo mediante la aplicación de una revisión sistemática de la literatura
y el análisis del estado del arte relacionado al área de estudio. Como resultado, fue
posible identificar las propuestas y trabajos relacionados que contribuyeron a la
definición de la propuesta presentada.

 OE2. Definir un proceso ágil para la gestión de la configuración de software

que describa un conjunto de actividades, tareas y roles que facilite el trabajo en
este tipo de entornos.
El Capítulo III. Armonización de modelos para la gestión de la configuración, presenta
el proceso de armonización llevado a cabo para identificar los elementos de proceso
necesarios que deberían ser tomados en cuenta para la caracterización del proceso.
Este capítulo tuvo como objetivo establecer los elementos necesarios que fueron
usados como soporte para la definición de la propuesta.

El Capítulo IV. SCMOnto: Ontología para soportar la gestión de la configuración de

software, presenta la motivación y definición de una ontología que no hace parte de los
objetivos propuestos en este trabajo de investigación pero que se llevó a cabo para
identificar la terminología relacionada al área con el objetivo de soportar de manera
formal el modelo unificado obtenido en el Capítulo III y que sirvió como base para la
definición del proceso.

El Capítulo V. Progresconfig. presenta la caracterización del proceso ágil para la

gestión de la configuración de software a través de un conjunto de definiciones,
actividades, tareas, roles, entradas, salidas y diagramas de flujo siguiendo el patrón de
procesos propuesto por COMPETISOFT. Además, la propuesta está apoyada
mediante un conjunto de niveles de capacidad que fueron propuestos para apoyar la
adopción del proceso de manera incremental. Finalmente, el proceso fue sometido a
una evaluación de agilidad para validar su porcentaje de agilidad.

116
  OE3. Evaluar el proceso propuesto a través de su aplicación en un grupo focal
(focus group) como técnica cualitativa de estudio.
El Capítulo VI. Evaluación de la propuesta, describe de manera completa la definición
y ejecución del método de evaluación. Además, la evaluación fue aplicada mediante la
ejecución de dos grupos focales con el objetivo de obtener realimentación desde
diferentes puntos de vista. Posteriormente se llevó a cabo el análisis de los resultados
obtenidos, y finalmente se creó una versión actualizada del proceso tomando como
base la realimentación recibida durante las sesiones de debate.

La evaluación de la propuesta fue realizada mediante la aplicación de un grupo focal

conformado por docentes de la Universidad del Cauca expertos en el área de la
ingeniería de software, y otro grupo focal conformado por miembros expertos en el
área que participan de manera activa en la industria de desarrollo de software local.

 Objetivo principal: Definir un proceso ágil para la gestión de la configuración

de software adaptado a las características y necesidades de MiPyMEs, el cual
proporcione una definición clara que apoye la implantación de las prácticas de
gestión de la configuración en el proceso de desarrollo de software en las
MiPyMEs_DS.
Como resultado de cumplir cada uno de los objetivos específicos propuestos, el
objetivo principal fue cumplido de manera satisfactoria. Finalmente, se lograron
establecer las bases conceptuales y los elementos necesarios para la definición de un
proceso para soportar la gestión de la configuración de software aplicable en micro,
pequeñas y medianas empresas desarrolladoras de software, su posterior validación a
criterio de expertos mediante la aplicación de dos grupos focales y la validación de su
grado de agilidad. Además, se llevó a cabo la definición de una ontología con la que se
pretende aportar una solución a la ambigüedad de la terminología relacionada con la
gestión de la configuración de software.

7.2 Conclusiones.
En este trabajo de investigación se ha presentado la propuesta de un proceso para
soportar la gestión de la configuración de software en micro, pequeñas y medianas
empresas de software, el cual propone un conjunto de definiciones, actividades, roles
y productos de trabajo para guiar la adopción del proceso en empresas
desarrolladoras de software. Como resultado del trabajo realizado para la definición de
un proceso ágil para soportar la gestión de la configuración de software, se concluye:

El protocolo de investigación aplicado para la identificación y análisis del estado del

arte por medio de una revisión sistemática resultó efectivo. Como resultado se logró
conocer las propuestas y trabajos relacionados al área. Además, se llevó a cabo su
posterior análisis mediante un proceso de armonización que permitió de manera
organizada identificar los elementos sensibles a ser integrados y poder definir la
propuesta del proceso para la gestión de la configuración. Asimismo, se llevó a cabo la
definición de una ontología, con la cual se definieron los elementos, conceptos y
relaciones necesarios para tener en cuenta en el dominio estudiado. La ontología
diseñada permite solucionar la ambigüedad de la terminología identificada en el
análisis del estado del arte.

La aplicación de un grupo focal como método de evaluación fue adecuada gracias a la

diversidad de los participantes involucrados. Gracias a ello, fue posible aplicar dos
grupos focales simultáneos: (i) con participantes expertos en el área de la ingeniería
del software que pertenecen a la academia y (ii) por un grupo de participantes

117
expertos pertenecientes a la industria local del desarrollo de software. Sin embargo,
debido a la naturaleza de la evaluación que se llevó a cabo y el grado de subjetividad
involucrado en el criterio de los expertos involucrados, fue posible identificar que la
evaluación pudo ser llevada a cabo mediante un criterio de evaluación más amplio que
permitiera obtener un nivel de realimentación con mayor grado de detalle y que no
fuera limitado a respuestas de si/no.

Teniendo en cuenta las recomendaciones de los asesores del proyecto se tomó la

decisión de utilizar la norma ISO/IEC 15504 como modelo base para la definición del
proceso tomando en cuenta tres factores: (i) facilidad que tienen las empresas para
llevar a cabo la certificación por medio de esta norma, (ii) por tener el suficiente nivel
de detalle con relación a buenas prácticas, artefactos de entrada y salida, descripción
de elementos de proceso, entre otros, y (iii) por ser uno de los modelos más utilizados
a nivel mundial por MiPyMEs_DS. Como resultado, fue posible definir una propuesta
ágil aplicable a MiPyMEs_DS que puede ser adoptada por las empresas
desarrolladoras de software.

A partir del análisis de la información obtenida en la revisión sistemática y el análisis

de las propuestas existentes, se concluye que existen múltiples propuestas para
soportar la gestión de la configuración de software, sin embargo, el grado de
heterogeneidad y ambigüedad en las definiciones existentes representa un
inconveniente para las empresas desarrolladoras de software, y como resultado, no
pueden adoptar el proceso de manera satisfactoria. Además, durante el análisis de
propuestas existentes no fue posible identificar propuestas que involucren de manera
directa MiPyMEs_DS.

7.3 Lecciones aprendidas.

Durante el proceso de definición de la propuesta surgieron varios inconvenientes
relacionados con la falta de definiciones claras y la heterogeneidad en los modelos y
propuestas existentes. Por lo cual fue necesario llevar a cabo la definición de una
ontología para soportar el proceso a través de un conjunto de definiciones claras y su
posterior validación teórica.

De igual manera, debido a la heterogeneidad de las propuestas existentes, fue

necesario aplicar un proceso que permitiera armonizar los elementos presentes en
múltiples modelos. Como resultado, se obtuvo un proceso unificado que involucra
aspectos relevantes de cada una de las propuestas estudiadas durante el desarrollo
de este proyecto.

Otro aspecto importante que representó un problema durante la definición de la

solución propuesta fue la caracterización por tipo de empresa que podría llegar a
utilizar el proceso definido, por lo cual se realizó la definición de un conjunto de niveles
de capacidad para permitir que cualquier tipo de empresa independientemente de su
tamaño pueda aplicar el proceso propuesto de manera incremental.

Finalmente, durante la evaluación de la propuesta se identificaron varios aspectos de

mejora que permitieron refinar la propuesta. En general, durante la evaluación
surgieron inconvenientes relacionados a la definición de los roles propuestos en el
proceso y su poca flexibilidad en escenarios que no se habían tenido en cuenta. Por lo
cual, fue necesario realizar una caracterización detallada de los roles para permitir que
el proceso fuera adoptado independientemente de la cantidad de empleados
existentes en una empresa que desee adoptar el proceso.

118
Además, a pesar del carácter cualitativo en el cuestionario presentado a los
participantes y a partir de los comentarios realizados por los evalua dores, fue posible
identificar que la evaluación pudo ser llevada a cabo con un nivel mayor de detalle, por
lo cual, se pueden plantear criterios de evaluación más amplios en cada una de las
preguntas para obtener un nivel mayor de detalle en las respuesta s y evitar que sean
limitadas a respuestas si/no.

7.4 Vías de trabajo futuro.

Durante el transcurso del proyecto, y como resultado de la caracterización y posterior
evaluación de la propuesta se identificaron varios aspectos que abren vías de trabajo
futuro que pueden abordarse. A continuación, se presentan las líneas de investigación
relacionadas:

1. Actualización del estado del arte relacionado al área de estudio: Como se

ha mencionado anteriormente, se realizó una revisión sistemática de la
literatura para conocer el estado del área de la gestión de la configuración de
software. Sin embargo, es necesario llevar a cabo una nueva revisión
sistemática en la que se puedan incluir nuevos trabajos relacionados al área.
2. Garantizar una validación de la propuesta más robusta: Actualmente, la
propuesta ha sido validada a través del análisis de su agilidad y mediante la
evaluación de expertos mediante la realización de dos grupos focales. Sin
embargo, se puede extender su evaluación a través de su aplicación en una
empresa de software piloto como estudio de caso.
3. Extender la definición de la propuesta:
a. Definir métricas para evaluar el proceso: Como resultado de la
evaluación de la propuesta, se identificó que es necesario definir
métricas que permitan generar indicadores a partir de la información
obtenida en la actividad de monitoreo. Además, es necesario crear
indicadores para soportar los procesos de auditoría externos.
b. Extender la aplicabilidad del proceso: Analizar la propuesta y validar
su aplicabilidad para empresas que poseen dominios de desarrollo de
software donde predominan las líneas de producción.
4. Actualizar y extender la ontología: Realizar estudios relacionados para
identificar aspectos que no se tuvieron en cuenta para la definición de la
ontología
5. Conocer el estado actual de la gestión de la configuración de software en
las empresas locales:
a. Realizar un estudio de las empresas locales: Durante la evaluación
de la propuesta se identificó que actualmente en la ciudad existe un
número limitado de empresas que aplican un proceso de gestión de la
configuración de software. Por lo cual, se plantea realizar un estudio
detallado en las empresas desarrolladoras de software locales para
identificar cómo llevan a cabo este proceso.

119
7.5 Contribuciones en el área de la ingeniería de
software.

7.5.1 Contribución en la divulgación de conocimiento.

Durante el desarrollo del proyecto, se obtuvieron como resultado un conjunto de
artefactos, entre los que se encuentran: (i) realización y análisis de resultados de la
revisión sistemática en el área de la gestión de la configuración de software, (ii)
definición de una ontología para soportar el proceso de gestión de la configuración de
software, (iii) definición de un proceso ágil para soportar la gestión de la conf iguración
de software en MiPyMEs_DS, (iv) análisis de agilidad de la propuesta mediante el
framework 4-DAT, (v) evaluación y posterior análisis de resultados a la propuesta
mediante la aplicación de dos grupos focales con la participación de expertos en el
área académica y la industria local de desarrollo de software.

Tomando en cuenta lo anterior, durante el desarrollo del proyecto se escribieron tres

artículos que fueron enviados a eventos o revistas nacionales para su validación y
publicación. A continuación, en la Tabla 76 se presenta el resumen de los artículos
que fueron escritos y enviados a diferentes eventos:

No. Artículo. Ev ento o rev ista.

CACIED 2017.
1 Estado del arte de la gestión de la configuración de software. Aceptado.
2 Progresconfig. Un proceso para soportar la gestión de la configuración de software. Aceptado.
3 SCMOnto: Hacia una ontología para la gestión de la configuración de software. Aceptado.
Tabla 76. Resumen de artículos escritos durante el desarrollo del proyecto.

7.5.2 Contribuciones de la investigación

Las contribuciones a la investigación realizadas en este trabajo de pregrado son de
varios tipos: (i) contribución al conocimiento en el área de la gestión de la
configuración de software y (ii) contribución en la mejora de procesos en la ingeniería
de software. A continuación, se describe en detalle cada una de las contribuciones
realizadas:

1. Contribución al conocimiento en el área de la gestión de la configuración

de software:
a. La revisión sistemática relacionada al área de la gestión de la
configuración de software permitió descubrir que las propuestas
existentes no han sido definidas para su aplicación en microempresas.
Como resultado, la revisión sistemática permitió identificar las
propuestas existentes en el área que fueron utilizadas para proponer
una solución aplicable a micro, pequeñas y medianas empresas de
software.
b. La definición de una ontología relacionada a la gestión de la
configuración de software provee los conceptos y relaciones entre
conceptos necesarios para soportar un proceso de manera homogénea
y sin ambigüedad.
2. Contribución en la mejora de procesos en la ingeniería de software:
a. El proceso propuesto provee un conjunto de definiciones, actividades,
tareas, roles, entradas, salidas y diagramas de flujo relacionados al
proceso adaptados a las características de las micro, pequeñas y
medianas empresas desarrolladoras de software.

120
b. El proceso está soportado a través de la aplicación de una evaluación
de agilidad para garantizar que el proceso está definido mediante un
enfoque ágil.
c. El proceso fue definido a través de un conjunto de niveles de capacidad
con el objetivo de facilitar su adopción por micro, pequeñas y medianas
empresas desarrolladoras de software.

121
 Bibliografía.
[1] E. A. Jetter, J. Kraaijenbrink, H.-H. Schröder, and F. Wijnhoven, “Knowledge
integration-the practice of knowledge management in small and medium
enterprises,” in Physica-Verlag Heidelberg, 2006.
[2] R. Heeks, “Indian IT Sector Statistics,” United Kingdom, 2015.
[3] M. M. Group, “Irish salary and benefits guide,” 2015. [Online]. Available:
goo.gl/tSX57F.
[4] Fedesoft, “Caracterización del sector teleinformatica, software y TI en
Colombia,” 2015. [Online]. Available: goo.gl/py5JWm.
[5] R. Regalado Hernández, “Las MiPyMEs en Latinoamérica,” 2007. [Online].
Available: goo.gl/6MiTxe.
[6] C. Y. Laporte and R. V. O‟Connor, “A Multi-case Study Analysis of Software
Process Improvement in Very Small Companies Using ISO/IEC 29110,” in
European Conference on Software Process Improvement, 2016, pp. 30–44.
[7] P. N. G. Perera et al., “The impact of effective configuration management usage
in software development firms in Sri Lanka,” in Proceedings of the 8th
International Conference on Computer Science and Education, 2013.
[8] J. K. Buckle, Software Configuration Management. California: Macmillan
Education, 1982.
[9] M. Ben Menachem, “Software Configuration Management Guidebook,”
Washington, D.C, 1995.
[10] J. Estublier, “Software Configuration Management: A Road Map,” in Proceedings
of the Conference on The Future of Software Engineering, 2000.
[11] L. Bendix, T. Kojo, and J. Magnusson, “Software Configuration Management
Issues with Industrial Opensourcing,” in IEEE Sixth International Conference on
Global Software Engineering Workshop, 2011, pp. 85–89.
[12] S. Engineering, S. Committee, and I. Computer, “IEEE Standard for
Configuration Management in Systems and Software Engineering IEEE
Computer Society,” 2012. [Online]. Available: goo.gl/K33e7y.
[13] Software Engineering Institute, “CMMI for Development, Version 1.3,” 2010.
[Online]. Available: goo.gl/bbyt4z.
[14] ISO 10007, “Quality management systems. Guidelines for configuration
management,” 2003. [Online]. Available: goo.gl/qHsRqR.
[15] ISO/IEC 15504-2, “Information technology - Process assessment - Part 2:
Performing an assessment,” 2003. [Online]. Available: goo.gl/oG5Ccu.
[16] ISO/IEC 29110-2-1, “Software engineering -- Lifecycle profiles for Very Small
Entities (VSEs),” 2015.
[17] R. C. W. D. D. John R. Rymer, Dave West, Mike Gilpin with Jeffrey S.
Hammond, “Lean software is agile, fit-to-purpose, and efficient,” 2008.
[18] T. Wood-Harper, “Research methods in information systems: Using action
research,” in Research Methods in Information Systems, 1985, pp. 169–191.
[19] M. Mendoza, C. González, and F. J. Pino, “Focus group como proceso en
ingeniería de software: Una experiencia desde la práctica,” DYNA, vol. 80, no. 1,
pp. 51–60, 2013.
[20] D. W. Stewart and P. N. Shamdasani, “Focus groups: Theory and practice,” in
Applied Social Research Methods Series, 1998, vol. 20.
[21] M. Jones and U. Mortensen, “ESA PSS-05-09 Guide to Software Configuration
Management,” in ESA Software Engineering Standards, 1994, no. 1, p. 74.
[22] S. Engineering, S. Committee, and I. Computer, “IEEE Guide to Software
Configuration Management.” [Online]. Available: goo.gl/nFGgVL.
[23] S. Engineering, S. Committee, and I. Computer, “IEEE Standard for Software
Configuration Management Plans,” 1990. [Online]. Available: goo.gl/odAHh8.

122
[24] S. Engineering, S. Committee, and I. Computer, “IEEE Standard for Software
Conguration Management Plans,” 1998. [Online]. Available: goo.gl/c9gQkJ.
[25] S. Engineering, S. Committee, and I. Computer, “IEEE Standard for Software
Configuration Management Plans,” 2005. [Online]. Available: goo.gl/e3o8rZ.
[26] ISO/IEC/IEEE 12207, “Systems and software engineering - Software life cycle
processes,” 2008. [Online]. Available: goo.gl/Fdt2sV.
[27] ISO/IEC/IEEE 15288, “Systems and software engineering -- System life cycle
processes,” 2015. [Online]. Available: goo.gl/qJw2fG.
[28] A. O. Calero and A. Rojas, “Paquete de implementación del proceso gestión de
la configuración del estándar ISO/IEC 29110 para MiPyMEs del sector de
desarrollo de software,” p. 16, 2012.
[29] J. Whyte, A. Stasis, and C. Lindkvist, “Managing change in the delivery of
complex projects: Configuration management, asset information and „big data,‟”
in International Journal of Project Management, 2016, vol. 34, no. 2, pp. 339–
351.
[30] L. Murta, H. Oliveira, C. Dantas, L. G. Lopes, and C. Werner, “Odyssey-SCM:
An integrated software configuration management infrastructure for UML
models,” in Science of Computer Programming, 2007, vol. 65, no. 3, pp. 249–
274.
[31] K. Mohan, P. Xu, L. Cao, and B. Ramesh, “Improving change management in
software development: Integrating traceability and software configuration
management,” Decis. Support Syst., vol. 45, no. 4, pp. 922–936, 2008.
[32] U. K. Durrani, J. Richardson, and J. Lenarcic, “Adaptable Software Configuration
Management: An Investigation on Australian Agile Software Development
Organizations,” Lect. Notes Softw. Eng., vol. 1, no. 1, pp. 66–70, 2013.
[33] A. Gupta and D. Zhdanov, “a Managed Approach of Interaction Between Agile
Scrum and Software Configuration Management System,” Adv. Inf. Technol.
Manag., vol. 36, no. 4, pp. 1109–1130, 2015.
[34] U. Asklund, L. Bendix, and T. Ekman, “Software configuration management
practices for eXtreme programming teams,” Welcome to 11th Nord. Work. …,
no. April, 2004.
[35] V. Kocar and A. Akgunduz, “ADVICE: A virtual environment for Engineering
Change Management,” Comput. Ind., vol. 61, no. 1, pp. 15–28, 2010.
[36] R. Premraj, A. Tang, N. Linssen, H. Geraats, and H. van Vliet, “To Branch or Not
to Branch?,” in Proceedings of the 2011 International Conference on Software
and Systems Process, 2011, pp. 81–90.
[37] U. Durrani, Z. Pita, J. Richardson, and J. Lenarcic, “An empirical study of lean
and agile influences in software configuration management,” in Proceedings -
Pacific Asia Conference on Information Systems, 2014.
[38] A. Bartusevics and L. Novickis, “Models for Implementation of Software
Configuration Management,” Procedia Comput. Sci., 2014.
[39] Unión Europea, “Reglamento 651/2014 de la comisión del 17 de junio de 2014,
por el que se declaran determinadas categorías de ayudas compatibles con el
mercado interior en aplicación de los artículos 107 y 108 del tratado texto
pertinente a efectos del EEE,” D. Of. la Unión Eur., pp. 70–71, 2014.
[40] Unión Europea, “Recomendación de la comisión del 6 de mayo de 2003 sobre la
definición de microempresas, pequeñas y medianas empresas,” D. Of. la Unión
Eur., pp. 36–41, 2003.
[41] C. Jesús and P. Calvache, “A Framework to Support the Harmonization between
Multiple Models and Standards,” University of Castilla, 2012.
[42] Competisoft, “Mejora de Procesos para Fomentar la Competitividad de la
Pequeña y Mediana Industria del Software de Iberoamérica,” 2008.
[43] C. Pardo, F. García, F. J. Pino, M. Piattini, and M. T. Baldassarre, “PrMO: An
Ontology of Process-reference Models,” pp. 393–406, 2012.
[44] F. J. Pino, M. T. Baldassarre, M. Piattini, and G. Visaggio, “Harmonizing maturity

123
 levels from CMMI-DEV and ISO / IEC 15504,” J. Softw. Maint. Evol. Res. Pract.,
no. September 2009, pp. 279–296, 2010.
[45] F. J. Pino, F. García, and M. Piattini, “Software process improvement in small
and medium software enterprises: a systematic review,” pp. 237 –261, 2008.
[46] T. R. Gruber, “Towards principles for the design of ontologies used for
knowledge sharing,” in Int. J. Human-Computer Studies, 1995, pp. 907–928.
[47] G. E. Barchini and M. M. Álvarez, “Dimensiones e indicadores de la calidad en
una ontología,” Av. en Sist. e Informática, vol. 7, no. 1, pp. 29–38, 2010.
[48] R. E. Grandy, “What Are Models and Why Do We Need Them ?,” Sci. Educ., vol.
12, pp. 773–777, 2003.
[49] A. Catherine and A. Aldana, “Guía para pymes desarrolladoras de software,
basada en la norma ISO/IEC 15504,” 2011.
[50] M. Fernández-López, A. Gómez-Pérez, and N. Juristo, “METHONTOLOGY:
From Ontological Art Towards Ontological Engineering,” AAAI-97 Spring Symp.
Ser., vol. SS-97-06, pp. 33–40, 1997.
[51] T. R. Gruber, “A translation approach to portable ontology specifications,”
Knowledge Acquisition, vol. 5, no. 2. pp. 199–220, 1993.
[52] D. Fensel et al., “Ontology-based knowledge management,” Computer (Long.
Beach. Calif)., vol. 35, no. 11, pp. 56–59, 2002.
[53] C. Tautz and C. G. Von Wangenheim, “REFSENO: A Representation Formalism
for Software Engineering Ontologies,” 1998.
[54] L. D. O. Arantes, R. D. A. Falbo, and G. Guizzardi, “Evolving a Software
Configuration Management Ontology,” 2007.
[55] V. Nunes and R. Falbo, “Uma Ferramenta de Gerência de Configuração
Integrada a um Ambiente de Desenvolvimento de Software,” V Simpósio Bras.
Qual. Softw., no. January 2006, pp. 231–247, 2006.
[56] C. J. Pardo-calvache, F. O. García-rubio, and M. Piattini-, “A reference ontology
for harmonizing process- reference models Una ontología de referencia para la
armonización de modelos de referencia de procesos,” Rev. Fac. Ing. Univ.
Antioquia 2014, pp. 29–42, 2014.
[57] C. Pardo, F. J. Pino, F. García, M. Piattini, and M. T. Baldassarre, “An ontology
for the harmonization of multiple standards and models,” Comput. Stand.
Interfaces, vol. 34, no. 1, pp. 48–59, 2012.
[58] “The Protégé Ontology Editor and Knowledge Acquisition System.” [Online].
Available: goo.gl/vQvpvo.
[59] “GraphViz: Graphviz-Graph Visualization Software.” [Online]. Available:
https://goo.gl/c5r6B9
[60] S. Falconer, “OntoGraf.” [Online]. Available: https://goo.gl/7qCmqH
[61] A. Qumer, “An evaluation of the degree of agility in six agile methods and its
applicability for method engineering,” vol. 50, pp. 280–295, 2008.
[62] J. Kontio, L. Lehtola, and J. Bragge, “Using the focus group method in software
engineering: obtaining practitioner and user experiences,” 2004 Int. Symp.
Empir. Softw. Eng. ISESE 2004, pp. 271–280, 2004.

124
 Anexos.
Anexo 1: Agenda para la sesión de debate aplicado a
Progresconfig.
Proceso ágil para la gestión de la configuración de
software en micro, pequeñas y medianas empresas de
software
Agenda de trabajo.
La sesión de debate es coordinada por el moderador y el supervisor, y e fectuada por
los participantes. Para ello, se hace uso de los artefactos obtenidos durante la etapa
de planeación. A continuación, se describe la agenda llevada a cabo para las sesiones
de debate.

No. Descripción. Hora

Desde Hasta
1 Agradecimiento a los participantes por asistir a la sesión. 17:00 17:05
2 Presentación del grupo investigador realizada por el supervisor. 17:05 17:15
 Discutir para que se utilizarán los resultados.
 Indicar por qué fueron seleccionados los participantes.
3 Presentación de la propuesta (Progresconfig) 17:15 17:30
4 Discusión realizada por los participantes para expresar sus apreciaciones sobre las 17:30 18:00
actividades definidas en el proceso propuesto.
5 Refrigerio. 18:00 18:10
6 Discusión realizada por los participantes para expresar sus apreciaciones sobre las 18:10 18:30
actividades definidas en el proceso propuesto.
7 Los participantes responden la encuesta definida por el grupo investigador. 18:30 18:40
8 Los participantes llenan la ficha de asistencia. 18:40 18:45
9 Agradecimientos a los participantes realizado por el grupo investigador. 18:45 18:50
10 Cierre de sesión. 18:50 19:00
Tabla 77. Agenda de trabajo utilizada para la sesión realizada en la Universidad del
Cauca.

No. Descripción. Hora

Desde Hasta
1 Agradecimiento a los participantes por asistir a la sesión. 16:00 16:05
2 Presentación del grupo investigador realizada por el supervisor. 16:05 16:15
 Discutir para que se utilizarán los resultados.
 Indicar por qué fueron seleccionados l os participantes.
3 Presentación de la propuesta (Progresconfig) 16:15 16:30
4 Discusión realizada por los participantes para expresar sus apreciaciones sobre las 16:30 17:00
actividades definidas en el proceso propuesto.
5 Refrigerio. 17:00 17:10
6 Discusión realizada por los participantes para expresar sus apreciaciones sobre las 18:10 17:30
actividades definidas en el proceso propuesto.
7 Los participantes responden la encuesta definida por el grupo investigador. 18:30 17:40
8 Los participantes llenan la ficha de asistencia. 18:40 17:45
9 Agradecimientos a los participantes realizado por el grupo investigador. 18:45 17:50
10 Cierre de sesión. 18:50 18:00
Tabla 78. Agenda de trabajo utilizada para la sesión realizada en LA EMPRESA.

125
Anexo 2: Cuestionario aplicado a los participantes del
grupo focal.
Proceso ágil para la gestión de la configuración de
software en micro, pequeñas y medianas empresas de
software
Encuesta final: Grupo focal.

Tema: Evaluación de Progresconfig: proceso ágil para la gestión de la configuración

de software en micro, pequeñas y medianas empresas de software.

Marque con una X la opción que considere adecuada.

1. De acuerdo con su experiencia ¿Considera importante aplicar un proceso de

gestión de la configuración de software en un proyecto de desarrollo? Sí __ No
__
2. ¿Considera que el proceso propuesto puede ser aplicado en una empresa
desarrolladora de software? Sí __ No __

3. ¿Considera que las actividades propuestas en el proceso son aprop iadas y

aplicables por una empresa desarrolladora de software? Sí __ No __

4. ¿Considera que el proceso ha contemplado elementos de agilidad que puedan

ser adoptados por una empresa desarrolladora de software? Sí __ No __

5. ¿Considera que los roles propuestos en el proceso pueden ser asumidos en su

totalidad por los recursos humanos disponibles en una empresa desarrolladora
de software? Sí __ No __
6. ¿Considera usted que las tareas relacionadas a cada actividad del proceso son
adecuadas? Sí __ No __

Si la respuesta es negativa, indique la razón:

_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
7. ¿Los diagramas presentados describen de forma clara el flujo del proceso y
sus actividades? Sí __ No __

8. ¿Considera que el proceso propuesto carece de algún aspecto importante? Sí

__ No __

Si la respuesta es afirmativa, indique que aspectos considera que se deberían

agregar al proceso:
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

9. De acuerdo con su experiencia, ¿Considera que el proceso puede aplicarse

con éxito en un proyecto de desarrollo de software? Sí __ No __

126
 Si la respuesta es negativa, indique por qué:
_______________________________________________________________
_______________________________________________________________
______________________________________________________________

10. ¿Considera que los niveles de capacidad propuestos para soportar el proceso
son adecuados? Sí __ No __ ¿Por qué?

_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

127
Cuestionario diligenciado por el participante 1:

128
129
Cuestionario diligenciado por el participante 2:

130
131
Cuestionario diligenciado por el participante 3:

132
133
Cuestionario diligenciado por el participante 4:

134
135
Cuestionario diligenciado por el participante 5:

136
137
Cuestionario diligenciado por el participante 6:

138
139
Cuestionario diligenciado por el participante 7:

140
141
Cuestionario diligenciado por el participante 8:

142
143
Cuestionario diligenciado por el participante 9:

144
145
Cuestionario diligenciado por el participante 10:

146
147
Anexo 3: Ficha de Asistencia del grupo focal.
Proceso ágil para la gestión de la configuración de software en
micro, pequeñas y medianas empresas de software.
Ficha de asistencia.

Tema: Evaluación Progresconfig: proceso ágil para la gestión de la configuración de

software en micro, pequeñas y medianas empresas de software.

Datos de l participante.

Nombre:
_____________________________________________________________________

Profesión/Ocupación:
_____________________________________________________________________

Experiencia relacionada a la ingeniería de software y mejora de pr ocesos:

_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________

Perfil: Nivel de escolaridad, interés en el área, estudios realizados y cursos

relacionados a la ingeniería del software.

_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________

148
 Ficha de asistencia diligenciada por los participantes del grupo focal realizado
en LA EMPRESA.

149
150
151
152
153
154
 Ficha de asistencia diligenciada por los participantes del grupo focal realizado
en la Universidad del Cauca

155
156
157
158
Anexo 4: Protocolo para llevar a cabo el grupo focal.
Proceso ágil para la gestión de la configuración de
software en micro, pequeñas y medianas empresas de
software.
Protocolo del grupo focal.

Objetivo general:
 Evaluar la propuesta (Progresconfig) de acuerdo con el grado de
aceptación o rechazo por parte de los participantes en aspectos como:
aplicabilidad a MiPyMEs, grado de agilidad y aporte al área de mejora de
procesos en desarrollo de software.

Objetivos específicos:
 Presentar una primera aproximación al proceso Progresconfig a un grupo
experto en procesos de desarrollo de software.
 Interiorizar las apreciaciones brindadas por el equipo experto evaluador.
 Llevar a cabo proceso de realimentación con la información obtenida de los
participantes durante la sesión.
A continuación, en la Tabla 79 y la Tabla 80, se presenta el protocolo utilizado en las
dos sesiones de debate.

Elemento. Descripción.
Fecha de 04 de octubre del 2017
realización.
Hora de inicio. 17:00
Hora de 18:50
finalización.
Lugar. Universidad del Cauca - Facultad de ingeniería electrónica y telecomunicaciones
Activ idad. Evaluación de la propuesta desarrollada por los estudiantes de ingeniería de sistemas Carlos
Eduardo Orozco Garcés y Juan Sebastián Vásquez Cantero.
Tema que tratar. Evaluación de Progresconfig: Proceso ágil para soportar la gestión de la configuración de software
en micro, pequeñas y medianas empresas desarrolladoras de software.
Moderador. Carlos Eduardo Orozco
Relator. Juan Sebastián Vásquez Cantero
Superv isor. César Jesús Pardo Calvache
Participantes.  Ing. Sandra Lorena Buitrón Ruiz.
 Ing. Wilson Alfredo Ortega Ordóñez.
 Ing. Wilson Libardo Pantoja Yépez.
 Ing. Daniel Eduardo Paz Perafán.
Objetiv o  Evaluar la propuesta (Progresconfig) de acuerdo con el grado de aceptación o rechazo
general. por parte de los participantes en aspectos como: aplicabilidad a MiPyMEs, grado de
agilidad y aporte al área de mejora de procesos en desarrollo de software.

Objetiv os  Presentar una primera aproximación al proceso Progresconfig a un grupo experto en

específicos. procesos de desarrollo de software.
 Interiorizar las apreciaciones brindadas por el equipo experto evaluador.
 Llevar a cabo proceso de realimentación con la información obtenida de los
participantes durante la sesión.

Tabla 79. Protocolo definido para la sesión realizada en la Universidad del Cauca.

159
 Elemento. Descripción.
Fecha de 05 de octubre del 2017
realización.
Hora de inicio. 16:00
Hora de 17:58
finalización.
Lugar. SITIS SAS.
Activ idad. Evaluación de la propuesta desarrollada por los estudiantes de ingeniería de sistemas Carlos
Eduardo Orozco Garcés y Juan Sebastián Vásquez Cantero.
Tema que tratar. Evaluación de Progresconfig: Proceso ágil para soportar la gestión de la configuración de software
en micro, pequeñas y medianas empresas desarrolladoras de software.
Moderador. Carlos Eduardo Orozco
Relator. Juan Sebastián Vásquez Cantero
Superv isor. César Jesús Pardo Calvache
Participantes.  Alberto Balcázar (Estudiante de último semestre de Ingeniería de Sistemas)
 Ing. Víctor Carvajal.
 Ing. María Amparo Hormiga.
 Ing. José Milciades Ordoñez Argote.
 Ing. Francisco Ramírez.
 Ing. Julián Andrés Zúñiga.
Objetiv o  Evaluar la propuesta (Progresconfig) de acuerdo con el grado de aceptación o rechazo
general. por parte de los participantes en aspectos como: aplicabilidad a MiPyMEs, grado de
agilidad y aporte al área de mejora de procesos en desarrollo de software.
Objetiv os  Presentar una primera aproximación al proceso Progresconfig a un grupo experto en
específicos. procesos de desarrollo de software.
 Interiorizar las apreciaciones brindadas por el equipo experto evaluador.
 Llevar a cabo proceso de realimentación con la información obten ida de los
participantes durante la sesión.

Tabla 80. Protocolo definido para la sesión realizada en LA EMPRESA.

160
Anexo 5: Caracterización del proceso evaluado durante
los grupos focales.
Proceso ágil para la gestión de la configuración de
software en micro, pequeñas y medianas empresas.
A continuación, se presenta la caracterización detallada de las actividades propuestas
para Progresconfig.

Niveles de capacidad
Para la definición de Progresconfig han sido propuestos 3 niveles de capacidad: (i)
esencial, (ii) complementario y (iii) realizado. Los niveles definidos representan la
segmentación del conjunto de actividades que una empresa debería adoptar de
manera incremental para implementar el proceso propuesto en este documento.

A continuación, se describe brevemente cada uno de los niveles de capacidad

propuestos:

 Nivel 1. Esencial: Establece prácticas para adoptar las actividades básicas

que una empresa requiere para planear una estrategia de gestión de la
configuración e identificar todos los elementos que son sensibles a
configuración en un proyecto.
 Nivel 2. Complementario: Establece estrategias y políticas para llevar a cabo
el control de los cambios asociados a cada uno de los ítems de configuración
que han sido identificados dentro del proyecto.
 Nivel 3. Realizado: Define prácticas para llevar a cabo procesos de evaluación
y auditoría para controlar la calidad y trazabilidad de los ítems de configuración,
con el fin de mantener la integridad del sistema con el paso del t iempo.

Caracterización del proceso para la gestión de la

configuración de software.
Identificador GCSA
Proceso. Gestión de la configuración de software.
Categoría. Operación (OPE)
Propósito. Establecer y mantener la integridad de todos los ítems de co nfiguración
identificados de un proyecto y ponerlos a disposición de las partes
interesadas a través de su identificación, control, seguimiento y auditoría.
Obj etiv os. O1: Identificar todos los ítems de configuración que hacen parte del
proyecto.
O2: Establecer los criterios de integridad de los ítems de configuración a
través de la definición de una (o varias) línea base durante el ciclo de vida de
un proyecto de software.
O3: Llevar a cabo el control sistemático de los cambios llevados a cabo en
los ítems de configuración que pertenecen a una línea base a través de
solicitudes de cambio.
O4: Mantener la trazabilidad de los ítems de configuración relacionados a
una línea base a través de su actualización y registro.
O5: Llevar a cabo procedimientos de auditoría para asegurar la integridad de
los ítems de configuración con el paso del tiempo.
Responsabilidad y autoridad. Líder de calidad del proyecto.
Procesos relacionados. 1. Seguimiento y control de proyectos.
2. Planeación de proyectos.
Roles Inv olucrados y Competencias
Abrev iatura Rol Competencias

161
AP Administrador del Recurso encargado de la definición, planificación, y
proyecto. supervisión del proyecto que se va a llevar a cabo desde el
punto de vista administrativo.
ED Equipo de desarrollo. Recursos con los conocimientos técnicos necesarios para
llevar a cabo el desarrollo del proyecto en cualquiera de sus
fases. Se consideran miembros del equipo de desarrollo:
 Analistas.
 Desarrolladores de software.
 Tester.
 Administrador de bases de datos.
 Técnicos en infraestructura.
Nota: El técnico de configuración que se presenta como un rol
con sus propias características también es considerado un
miembro del equipo de desarrollo.
EC Experto en configuración. El experto en configuración representa la autoridad de gestión
de la configuración durante el desarrollo del proyecto. Es el
recurso responsable de conocer el proceso en gestión de la
configuración y asegurar que el equipo de desarrollo lo lleva a
cabo de manera correcta.

Nota 1: Para proyectos que involucren marcos de trabajo bajo

aspectos ágiles, un experto en configuración debería también
ser capaz de dar soporte a dichas metodologías, es decir,
debería ser el encargado de asegurar que cualquiera de
dichas metodologías se cumpla. El experto en configuración es
el recurso equivalente al Scrum Master definido en SCRUM o
al Coach definido en XP.
CCC Comisión de control de la Recurso(s) responsable(s) de la evaluación de los cambios
configuración propuestos a determinados ítems de configuración. Si dichos
cambios son aprobados, la CCC también deberá asegurar su
realización.

Se recomienda que esta comisión esté conformada por un

miembro del equipo de desarrollo (ED), el responsable del
ítem de configuración a modificar y el Experto en
Configuración (EC).
TC Técnico de configuración Recurso encargado de llevar a cabo los cambios propuestos
en las peticiones de cambio aprobadas por la CCC. Este rol es
considerado transitorio debido a que existe únicamente
mientras haya peticiones de cambio aprobadas por realiza r.
IN Interesado. Persona o conjunto de personas que no hacen parte del
proceso técnico de desarrollo pero que deben ser tomados en
cuenta. Se consideran interesados:
 Director del proyecto.
 Gerentes del proyecto.
 Expertos en el negocio.
 Expertos en el producto.
DP Dueño del producto. Es el recurso responsable de transmitir al equipo de desarrollo
la visión y el conocimiento sobre el producto que se desea
implementar desde el punto de vista del negocio.

El dueño del producto es el representante de los in teresados y

es el enlace que permite transmitir sus solicitudes e
inconformidades al equipo de desarrollo. Además, el dueño del
producto es el agente responsable de priorizar y validar cada
uno de los requerimientos, inconformidades y solicitudes de
cambio del cliente desde la visión del producto.
CL Cliente. Es el usuario final del producto que se va a implementar y el
público objetivo que va a utilizar el producto en su fase de
producción.

Activ idades.

GCSA.A1. Desarrollar una estrategia de gestión de la configuración.

Niv el de capacidad: Esencial

Entradas: N/A
Responsables. Tareas.
AP, EC T1: Definir un formato para la creación de un PGCS

Descripción:
1. Inicio del flujo.
2. Definir la plantilla que se va a utilizar para la construcción de un plan formal para

162
 llevar a cabo la gestión de la configuración de software.
3. Identificar los aspectos en el proyecto sensibles a gestión de la configuración.
4. Identificar las actividades que se van a llevar a cabo durante el proceso de gestión
de la configuración del proyecto.
5. Crear el PGCS.
6. Definir y actualizar el repositorio definido para almacenar el PGCS.
7. Socializar y hacer disponible el PGCS a las partes interesadas.
8. Fin del flujo.
Nota 1: El experto en configuración en conjunto con el administrador del proyecto deben
identificar y considerar los aspectos relevantes que deben ser incluidos en el PGCS. Se deben
tener en cuenta aspectos como: propósito, alcance del proyecto, responsables, actividades,
asignación de recursos, estimación de costos, dependencias con actividades relacionadas a
otros procesos en el proyecto, etc.
AP, EC T2: Identificar los responsables asociados a cada actividad definida en el PGCS.

Descripción:
1. Inicio del flujo.
2. Identificación de todas las actividades contenidas en el plan.
3. Identificación de las competencias de cada recurso.
4. Definir los recursos responsables de cada actividad durante el proceso de desarrollo.
5. Asignar los recursos responsables de cada actividad.
6. Fin del flujo.

Nota 1: Para MiPyMEs_DS, es muy importante la identifica ción de las capacidades y

competencias de los recursos que van a participar durante el desarrollo del proyecto. Debido a
la limitante de recursos humanos en MiPyMEs_DS, se debe considerar realizar un estudio
previo de los recursos que permitirá asignar tareas a estos dependiendo de sus capacidades
para aprovechar al máximo los recursos disponibles.
Salidas:
A1. S1: Plan para la gestión de la configuración del proyecto.
A1. S2: Identificación de los recursos necesarios para llevar a cabo las actividades aso ciadas a la gestión de la configuración.
Diagrama de fluj o:

163
 GCSA.A2. Identificación de la configuración.

Niv el de capacidad: Esencial

Entradas:
A1. S1
A1. S2
Responsables. Tareas
EC T1: Identificar los ítems de configuración (IC)

Descripción:
1. Inicio del flujo.
2. Identificar los IC que pertenecen al proyecto que deben ser gestionados y
controlados.
3. Seleccionar los IC que serán puestos bajo una configuración.
4. Documentar los IC seleccionados para configuración.
5. Identificar los IC que no tienen relación directa con el proyecto pero que deben ser
controlados.
6. Documentar los IC externos para configuración.
7. Fin del flujo.
Nota 1: Se recomienda categorizar los IC a través de criterios funcionales, por ejemplo:

 IC de análisis y diseño: Bosquejos, especificaciones de producto, requerimientos,

prototipos, documentación de arquitectura y diseño de datos, casos de uso o
historias de usuario, listas de chequeo, criterios de aceptación, manuales técnicos,
manuales de instalación, manuales de usuario etc.
 IC de desarrollo e implementación: Código fuente, librerías, compilaciones,
herramientas y entornos de desarrollo (IDE, librerías, plugin, etc.), herramientas de
prueba, scripts, repositorios, casos de prueba, etc.
 IC externos: Son los artefactos que son utilizados que no tienen relación directa con
el proyecto, por ejemplo: servicios externos, artefactos dependientes de otros
proyectos, etc.
EC, ED T2: Describir cada IC.

Descripción:
1. Inicio del flujo.
2. Definir un esquema de nombrado para el IC.
3. Describir la función de cada IC.
4. Describir un prefijo único para identificar cada CI mediante criterios funcionales.
5. Clasificar el IC a través de criterios funcionales.
5.1. Se valida si el IC es de análisis y diseño.
5.2. Se valida si el IC es de desarrollo e implementació n.
5.3. Se valida si el IC es externo.
5.4. Se asigna un prefijo único a cada categoría de IC para identificar su criterio
funcional.
6. Asignar un identificador único a cada IC.
7. Identificar el responsable de cada IC.
8. Identificar las dependencias del IC actual con otro s IC.

164
 9. Documentar el IC.
10. Fin del flujo.

Nota 1: La clasificación por criterios funcionales permite identificar de manera clara e

inequívoca cada IC. Por ejemplo: El caso de uso X se identifica con el prefijo AD_IDX, donde:

AD: Análisis y diseño.

IDX: Identificador propio del IC.
ED T3: Definir los repositorios para llevar el control de los IC.

Descripción:
1. Inicio del flujo.
2. Definir los repositorios para almacenar IC de análisis y diseño.
3. Definir los repositorios para almacenar los IC de desarrollo e impl ementación.
4. Definir los repositorios para almacenar los IC externos al proyecto.
5. Fin del flujo.
Nota 1: Para IC de análisis y diseño, es recomendable definir repositorios agrupados por sus
características, por ejemplo: crear un repositorio para el control de los casos de uso y sus
diferentes versiones con el paso del tiempo.

Para IC de desarrollo e implementación, se recomienda la adopción de herramientas para el

control de versiones e integración continúa, y la creación de repositorios para llevar a cabo el
control y la trazabilidad de los ítems de configuración, tales como: herramientas utilizadas por
el equipo de desarrollo, documentación técnica, ramas liberadas para desarrollo, pruebas,
producción, etc.

Nota 3: Para MiPyMEs_DS, es recomendable asignar a un miembro del equipo de desarrollo

como responsable de administrar los repositorios o los documentos definidos para llevar el
control de los ítems de configuración en paralelo a sus tareas.
Por ejemplo:

 Un analista puede ser responsable de mantener e l repositorio de casos de uso.

 El DBA puede ser responsable de llevar el control del diccionario de datos del
proyecto y de mantener las bases de datos relacionadas al proyecto.
 Un desarrollador puede ser el responsable de mantener las líneas base, el sistema
de integración continua y de administrar el repositorio donde se almacenen las
versiones de una o varias líneas base.
Salidas:
A2. S1: Identificación de ítems de configuración.
A2. S2: Clasificación de los ítems de configuración.
A2. S3: Definición de repositorios para almacenar los ítems de configuración.
Diagrama de fluj o:

165
 GCSA.A3. Establecer las líneas base.

Niv el de capacidad: Complementario

Entradas:
A2. S2
Responsables Tareas
ED, EC T1: Definir los elementos que constituyen una línea base.

Descripción:
1. Inicio del flujo.
2. Solicitar autorización del EC para la identificación de una línea base.
Si el EC autoriza la identificación de una línea base.
2.1. Sigue el flujo en el paso 3.
2.2. Identificar los IC que constituyen una línea base (ver GCSA.A2.T2).
2.3. Definir una convención de nombrado para identificar la línea base.
2.4. Definir los repositorios donde se almacenará línea base.
2.5. Asignar un responsable a la línea base.
2.6. Socializar y publicar la línea base a todas las partes interesadas.
Si el EC rechaza la identificación de una línea base.
2.1. Sigue el flujo en el paso 3.
3. Fin del flujo.
Salidas:
A3. S1: Descripción de las líneas base.
A3. S2: Definición de repositorios para almacenar las líneas base.

166
Diagrama de fluj o:

GCSA.A4. Establecer una estrategia para la modificación de las líneas base

Niv el de capacidad: Complementario

Entradas:
A3. S1
Responsables Tareas
EC T1: Definir una política para el control de versiones de las líneas base.

Descripción:
1. Inicio del flujo.
2. Definir el repositorio para las diferentes versiones de las líneas base.
3. Definir los criterios para crear nuevas líneas base o nuevas versiones de una línea
base existente.
4. Definir un documento de control de versiones.
5. Asignar un responsable para crear nuevas versiones de las líneas base.
6. Actualizar el repositorio definido.
7. Fin del flujo.
Nota 1: Para MiPyMEs_DS, es recomendable asignar a un miembro del equipo de desarrollo
como responsable de administrar el repositorio y la creación de nuevas versiones de una línea
base.
ED T2: Definir una estructura para el control de versiones para los IC de análisis y diseño.

Descripción:
1. Inicio del flujo.
2. Identificar las herramientas para el almacenamiento de todos los IC de análisis y
diseño.
3. Introducir herramientas para llevar el control de la trazabilidad de los IC de análisis y
diseño.
4. Actualizar los IC de análisis y diseño en las herramientas definidas.
5. Fin del flujo.
ED T3: Definir una estructura para el control de versiones para los IC de desarrollo e
implementación.

Descripción:
1. Introducir un sistema de integración continua.
2. Definir convenciones para los comentarios asociados a los cambios que se van a
subir a los repositorios de código fuente durante el proceso de desarrollo.
3. Introducir herramientas para automatizar la creación de nuevas versiones de una
línea base.
4. Actualizar los IC de desarrollo e implementación en las herramientas definidas.
5. Fin del flujo.
Salidas:
A4. S1: Política para el control de versiones.
A4. S2: Definición de repositorios para mantener la trazabilidad de las líneas base.
Diagrama de fluj o:

167
 GCSA.A5. Mantener la descripción de los ítems de configuración.

Niv el de capacidad: Complementario.

168
Entradas:
A2. S2
A4. S2
Responsables. Tareas
EC T1: Identificar los ítems de configuración constituyentes (ICC)

Descripción:
1. Inicio del flujo.
2. Identificar el IC demasiado complejo.
3. Dividir el IC en ICC.
4. Definir el ICC (ver GCSA.A2.T2).
5. Actualizar el IC en el repositorio relacionado.
6. Socializar y publicar el IC actualizado a las partes interesadas.
7. Fin del flujo.
Salidas:
A5. S1: ICC documentados y relacionados.
Diagrama de fluj o:

GCSA.A6. Controlar modificaciones y lanzamientos.

Niv el de capacidad Complementario

Entradas:
N/A
Responsables. Tareas
EC T1: Definir una plantilla para las solicitudes de cambio.

Descripción:
1. Inicio del flujo.
2. Identificar los criterios que se deben tener en cuenta para la solicitud de un cambio.
3. Definir el repositorio para almacenar las peticiones de cambio.
4. Crear la plantilla para el control de cambios.
5. Actualizar el repositorio.
6. Hacer la plantilla disponible a todas las partes interesadas.
7. Fin del flujo.
Nota 1: La definición de una plantilla debería considerar elementos como: descripción del
cambio, estado actual del cambio, línea base o ítem de configuración afectado, dependencias
afectadas, recurso que solicita el cambio, recurso que aprueba o rechaza el cambio, fecha en
que se solicita el cambio, etc.

EC T2: Definir herramientas para gestionar las solicitudes de cambios en los IC.

Descripción:
1. Inicio del flujo.
2. Identificar herramientas que permitan llevar la trazabilidad de las solicitudes de
cambio solicitadas por el equipo de desarrollo, el dueño del producto o una parte
interesada.
3. Adaptar la plantilla definida para las solicitudes de cambios al uso de las
herramientas definidas.
4. Definir los responsables de administrar las herramientas para el control de las
solicitudes de cambio.
5. Fin del flujo.
EC T3: Definir una política de liberación y lanzamiento.

169
 Descripción:
1. Inicio del flujo.
2. Definir los criterios que se deben cumplir para liberar una línea base a la siguiente
cadena del flujo durante el proceso de desarrollo.
3. Definir un responsabl e que garantice el cumplimiento de los criterios definidos.
4. Documentar los criterios definidos.
5. Definir repositorio para almacenar la política de liberación.
6. Almacenar la política en el repositorio correspondiente.
7. Hacer la política de liberación y lanzamiento disponible a las partes interesadas.
8. Fin del flujo.

Nota 1: Para empresas que siguen modelo de desarrollo en cascada (Análisis, Diseño,
Desarrollo, Pruebas, Lanzamiento, Producción, Mantenimiento) se puede seguir una política
de liberación lineal que defina los criterios necesarios para pasar de una fase del proceso a
otra. Por ejemplo: Definir los criterios que se deben cumplir para que una línea base de
desarrollo pueda ser liberada a pruebas.

Nota 2: Para empresas que siguen el modelo iterativo in cremental, espiral o guiado por
prototipos, se recomienda definir una política de liberaciones parciales e incrementales cuyo
parámetro de control sean listas de listo o de hecho que deben ser cumplidas para la liberación
de una fase a la que sigue.
DP, CCC, TC T4: Definir un protocolo para las solicitudes de cambio realizadas por un miembro del equipo
de desarrollo o el experto de configuración.

Descripción:
1. Inicio del flujo.
2. Identificar el cambio solicitado por el miembro del equipo de desarrollo.
3. El miembro del equipo de desarrollo diligencia el formato de control de cambios o
solicita el cambio a través de las plataformas definidas.
4. El miembro del equipo de desarrollo asigna la petición de cambio a la comisión de
control de la configuración.
5. La comisión de control de la configuración evalúa el cambio solicitado.
Si el cambio es aprobado:
5.1. La comisión de control de la configuración asigna un técnico de configuración
para que implemente el cambio solicitado.
5.2. El técnico de configuración realiza el cambio solicitado.
5.3. El técnico de configuración actualiza los IC afectados en los repositorios
relacionados.
5.4. Continúa en el paso 6 del flujo.
Si el cambio es rechazado:
5.1. La comisión de control de la configuración notifica al miembro del equipo de
desarrollo que la solicitud de cambio ha sido rechazada.
5.2. Continúa en el paso 6 del flujo.
6. Se actualiza la petición de cambio en el repositorio o la plataforma definida.
7. Fin del flujo.
DP, CCC, TC T5: Definir un protocolo para las solicitudes de cambio realizadas por los interesados o por un
cliente.

Descripción:
1. Inicio del flujo.
2. El dueño del producto identifica el cambio solicitado por el interesado o por el cliente.
3. El dueño del producto evalúa el impacto del cambio solicitado.
4. El dueño del producto diligencia el formato de control de cambios o solicita el cambio
a través de las plataformas definidas.
5. El dueño del producto asigna la petición de cambio a la comisión de control de la
configuración.
6. La comisión de control de la configuración evalúa el cambio solicitad o.
Si el cambio es aprobado.
6.1. La comisión de control de la configuración asigna un técnico de configuración
encargado de realizar el cambio.
6.2. El técnico de configuración realiza el cambio solicitado.
6.3. El técnico de configuración actualiza los IC afectados en los repositorios
relacionados.
6.4. Continúa en el paso 7 del flujo.
Si el cambio es rechazado:
6.1. La comisión de control de la configuración notifica al dueño del producto que el
cambio ha sido rechazado
6.2. Continua el paso 7 del flujo.
7. Se actualiza la petición de cambio en el repositorio o la plataforma definida.
8. Fin del flujo.
Salidas
A6. S1: Plantilla para la solicitud de cambios.
A6. S2: Creación del repositorio para controlar las solicitudes de cambio.
Diagrama de fluj o:

170
171
 GCSA.A7. Proceso de auditoria

Niv el de capacidad Realizado.

Entradas:
N/A
Responsables. Tareas
EC T1: Definir criterios para llevar a cabo una auditoría física y funcional.

Descripción:
1. Inicio del flujo.
2. Definir los criterios para llevar a cabo una auditoría física.
2.1. Definir el repositorio para almacenar los documentos de auditoría física.
2.2. Definir la plantilla de evaluación para la auditoría física.
2.3. Definir los criterios de evaluación para el IC puesto bajo una auditoría física.
2.4. Definir la plantilla de reporte para informar los resultados de una auditoría física.
2.5. Actualizar los artefactos generados en el repositorio relacionado.
2.6. Continúa en el paso 4 del flujo principal.
3. Definir el repositorio para los documentos de auditoría funcional.

172
 3.1. Definir el repositorio para almacenar los documentos de auditoría funcional.
3.2. Definir la plantilla de evaluación para la auditoría funcional.
3.3. Definir los criterios de evaluación para el IC puesto bajo una auditoría funcional.
3.4. Definir la plantilla de reporte para informar l os resultados de una auditoría
funcional.
3.5. Actualizar los artefactos generados en el repositorio relacionado.
3.6. Continúa en el paso 4 del flujo principal.
4. Hacer los repositorios relacionados disponibles a las partes interesadas.
5. Fin del flujo.
ED, EC T2: Llevar a cabo la auditoría física de los IC.

Descripción:
1. Inicio del flujo.
2. El experto en configuración (EC) identifica el ítem de configuración a evaluar.
3. Se designa un miembro del equipo de desarrollo para llevar a cabo la auditoría del
IC afectado.
4. Se valida que el ítem de configuración aprueba los criterios definidos para el proceso
de auditoría física.

Si el IC aprueba los criterios definidos para la ev aluación.

4.1. El miembro del equipo de desarrollo designado documenta los resultados de la
validación.
4.2. Continúa en el paso 5 del flujo.

Si el IC no aprueba los criterios definidos para la ev aluación.

4.1. El miembro del equipo de desarrollo designado documenta las no
conformidades detectadas.
4.2. Continúa en el paso 5 del flujo.

5. El miembro del equipo de desarrollo informa al experto en configuración los

resultados de la validación a través de la plantilla de reporte definida.
6. El experto en configuración actualiza el repositorio relacionado con los resultados de
la validación.
7. Fin del flujo.
Nota 1: Para MiPyMEs_DS, es recomendable asignar a un miembro del equipo de desarrollo
con conocimiento en el dominio del proyecto que no haya participado en el proceso de
construcción y definición de los ítems de configuración para realizar una validación objetiva.
ED, EC T3: Llevar a cabo la auditoría funcional de las líneas base.

Descripción:
1. Inicio del flujo.
2. El experto en configuración identifica la línea base a evaluar.
3. Se designan los miembros del equipo de desarrollo necesarios para llevar a cabo la
auditoría del IC afectado.
4. Se valida que la línea base aprueba los criterios definidos para el proceso de
auditoría funcional.

Si la línea base aprueba los criterios definidos para la ev aluación:

4.1. Los miembros del equipo de desarrollo designados documentan los resu ltados
de la validación.
4.2. Continúa en el paso 5 del flujo.

Si la línea base no aprueba los criterios definidos para la ev aluación:

4.1. Los miembros del equipo de desarrollo designados documentan las no
conformidades detectadas.
4.2. Continúa en el paso 5 del flujo.

5. Los miembros del equipo de desarrollo informan al experto en configuración los

resultados de la validación a través de la plantilla de reporte definida.
6. El experto en configuración actualiza el repositorio relacionado con los resultados de
la validación.
7. Fin del flujo.

Nota 1: Para MiPyMEs_DS, es recomendable asignar a un miembro del equipo de desarrollo

con mayor experiencia en los detalles técnicos para realizar una validación objetiva de las
líneas base. Además, se pueden plantear estrategias de auditoría mediante criterios como:
evaluación de arquitectura, metodologías de desarrollo, criterios de calidad, usabilidad,
rendimiento, seguridad, etc. Las auditorías pueden ser llevadas a cabo por uno o varios
miembros del equipo de desarrollo expertos en los diferentes criterios definidos para la
evaluación.
EC, ED T4: Definición y administración de respaldos.

Descripción:
1. Inicio del flujo.
2. Identificar IC críticos.

173
 3. Definir un repositorio para almacenar los respaldos.
4. Establecer mecanismos para la recuperación de información crítica que ha sido
respaldada.
5. Designar un técnico de configuración para llevar a cabo la creación y administración
de los respaldos.
6. El técnico de configuración crea respaldos de los IC críticos.
7. El técnico de configuración actualiza el repositorio relacionado.
8. Fin del flujo.
EC, TC T5: Resolver no conformidades en el proceso de auditoría.

Descripción:
1. Inicio del flujo.
2. Identificar el ítem de configuración inconsistente.
3. Se designa a un técnico de configuración para resolver las no conformidades del
ítem de configuración inconsistente.
4. El técnico de configuración aplica los cambios al IC inconsistente.
5. El técnico de configuración actualiza los repositorios relacionados.
6. El técnico de configuración notifica al experto en configuración que el cambio ha sido
realizado.
7. El experto en configuración identifica el ítem de configuración que ha sido
actualizado.

Si el ítem de configuración requiere auditoría física continua en GCSA.A7.T2.

Si el ítem de configuración requiere auditoría funcional continua en

GCSA.A7.T3.

8. Fin del flujo.

Salidas
A7. S1: Reporte de auditoría física de los IC.
A7. S2: Reporte de auditoría funcional de los IC.
A7. S3: Creación de repositorios y respaldos.
A7. A4: Reporte de no conformidades.
Diagrama de fluj o:

174
175
176
Tabla 81 . Progresconfig versión 1.0.

177