CIS1030IS04 ProSoftCol: Guía Metodológica de Mejora de Procesos de Construcción de Software
Adaptada para MIPyMES_DS Colombianas
Ximena Higuera Moriones
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMAS
BOGOTÁ, D.C.
2011
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página i Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
CIS1030IS04
ProSoftCol: Guía Metodológica de Mejora de Procesos de Construcción de Software
Adaptada para MIPyMES_DS Colombianas
Autor(es):
Ximena Higuera Moriones
MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO
DE LOS REQUISITOS PARA OPTAR AL TITULO DE INGENIERO DE
SISTEMAS
Director
Ingeniero Rafael Andrés González Rivera
Página web del Trabajo de Grado
http://pegasus.javeriana.edu.co/~CIS1030IS04/
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMAS
BOGOTÁ, D.C.
Junio, 2011
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página ii Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMAS
Rector Magnífico
Joaquín Emilio Sánchez García S.J.
Decano Académico Facultad de Ingeniería
Ingeniero Francisco Javier Rebolledo Muñoz
Decano del Medio Universitario Facultad de Ingeniería
Padre Sergio Bernal Restrepo S.J.
Director de la Carrera de Ingeniería de Sistemas
Ingeniero Luis Carlos Díaz Chaparro
Director Departamento de Ingeniería de Sistemas
Ingeniero César Julio Bustacara Medina
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página iii Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Artículo 23 de la Resolución No. 1 de Junio de 1946
“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus
proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral
católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que
se vean en ellos el anhelo de buscar la verdad y la Justicia”
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página iv Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
AGRADECIMIENTOS
Quiero agradecer a las personas que hicieron posible la realización de este trabajo de grado:
A aquellos que se esforzaron y trabajaron arduamente durante muchos años para darme
educación, para que yo pudiera estudiar la carrera que yo deseaba en la universidad que
quería: mis padres Luis Heriberto Higuera y Luz Eugenia Moriones, que siempre me
apoyaron, estuvieron pendientes y orgullosos de todo mi proceso vivido a lo largo de la
carrera, y a quienes amo y admiro con todo mi ser. A ustedes les debo la dicha y la fortuna
que tengo de saber que en el futuro voy a poder vivir haciendo lo que me gusta, y siempre
con la meta de ser la mejor en ello.
A Gustavo Rodríguez, mi novio, por ese apoyo y compañía incondicional, desde las
trasnochadas en ingeniería de software hasta el día de la entrega de esta memoria. Gracias por
ser paciente, por comprender que a veces no podíamos pasar tanto tiempo juntos como
queríamos por mis obligaciones de la universidad, por estar pendiente de todo lo que yo
necesité, por la ayuda desinteresada en todo y por celebrar junto a mí los triunfos y alegrías
que obtuve durante todo este tiempo. Te amo.
Al Ing. Miguel Torres, por introducirme al mundo de la ingeniería de software y despertar en
mí ese gran interés que tengo en ésta área, por permitirme trabajar para él como monitora de
la asignatura y de la especialización en arquitectura empresarial de software, y por supuesto:
por creer en mí.
A mi director, el Ing. Rafael González por aceptar la dirección del trabajo, por el apoyo y la
guía continua durante este proceso, porque gracias a él durante la realización de este trabajo
aprendí muchas más cosas de las que me pude imaginar; realmente fue un reto y todo un
orgullo estar bajo la dirección de una persona tan culta y tan brillante.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página v Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Índice de Contenido
INTRODUCCIÓN ........................................................................................................................... 1
I - DESCRIPCION GENERAL DEL TRABAJO DE GRADO ...................................................... 2
1. OPORTUNIDAD, PROBLEMÁTICA, ANTECEDENTES .................................................................. 2
1.1. Descripción del Contexto .............................................................................................. 2
1.2. Solución a la Problemática ........................................................................................... 5
2. DESCRIPCIÓN DEL PROYECTO ................................................................................................. 5
2.1 VISIÓN GLOBAL ................................................................................................................. 5
2.2 JUSTIFICACIÓN .................................................................................................................. 6
2.3 OBJETIVO GENERAL........................................................................................................... 7
2.4 OBJETIVOS ESPECÍFICOS .................................................................................................... 7
2.5 MÉTODO QUE SE PROPUSO PARA SATISFACER CADA FASE METODOLÓGICA ......................... 7
2.5.1. Estudiar modelos de mejora de procesos de desarrollo de software existentes (CMMI,
MoProSoft, CompetiSoft) ........................................................................................................... 9
2.5.2. Realizar análisis cultural y organizacional de MIPyMES_DS Colombianas ............. 10
2.5.3. Obtener requerimientos específicos de una (1) MIPyME_DS Colombiana en cuanto a
procesos de software de ésta .................................................................................................... 10
2.5.4. Adaptar un modelo específico para la MIPyMES_DS Colombiana de la cual se
obtuvieron los requerimientos específicos ................................................................................ 10
2.5.5. Evaluar la consistencia interna y la completitud del modelo propuesto .................... 11
2.5.6. Medir la utilidad potencial del modelo .................................................................... 11
2.5.7. Refinar el modelo propuesto, a partir de los resultados de la validación del mismo . 12
II - MARCO TEÓRICO ................................................................................................................ 12
1. MARCO CONCEPTUAL .......................................................................................................... 12
1.1.1. Modelos de Mejora de Procesos de Software ........................................................... 12
1.1.2. Ingeniería de Métodos ............................................................................................ 32
1.1.3. Marco de Referencia “Forma De” .......................................................................... 36
2. MARCO CONTEXTUAL .......................................................................................................... 38
2.1.1. Las MIPyMES_DS .................................................................................................. 38
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página vi Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
2.1.2. Problemas de las MIPyMES_DS con Modelos de Mejora de Procesos de Software
Existentes 40
2.1.3. Características que debería tener un buen modelo de Mejora de Procesos de Software
para MIPyMES_DS ................................................................................................................. 41
2.1.4. Cultura Organizacional .......................................................................................... 42
2.1.5. Contexto Latinoamericano ...................................................................................... 45
III – DESARROLLO DEL TRABAJO ......................................................................................... 48
1. CICLO DE RIGOR .................................................................................................................. 49
1.1. Documento con los aspectos más relevantes de los modelos de mejora CMMI,
MoProSoft y CompetiSoft ........................................................................................................ 49
1.2. Documento con características de la cultura organizacional colombiana .................... 52
2. CICLO DE RELEVANCIA ........................................................................................................ 53
2.1. Documento con los requerimientos específicos de una MIPyME_DS Colombiana en
cuanto a procesos de software de ésta ...................................................................................... 53
3. CICLO DE DISEÑO ................................................................................................................ 56
3.1. Modelo Específico Adaptado para MIPyME_DS Colombiana de la cual se obtuvieron los
requerimientos específicos ....................................................................................................... 56
IV –REFLEXIÓN METODOLÓGICA......................................................................................... 62
V - RESULTADOS Y REFLEXIÓN SOBRE LOS MISMOS ...................................................... 63
1. VALIDACIÓN DE LA UTILIDAD POTENCIAL DE LA GUÍA .......................................................... 63
2. EVALUACIÓN DE LA COMPLETITUD Y LA CONSISTENCIA INTERNA POR PARTE DE UN EXPERTO 67
3. RESULTADOS ....................................................................................................................... 70
VI – CONCLUSIONES, RECOMENDACIONES Y TRABAJOS FUTUROS ............................ 71
1. CONCLUSIONES.................................................................................................................... 71
2. RECOMENDACIONES ............................................................................................................ 73
3. TRABAJOS FUTUROS ............................................................................................................ 74
3.1. Implementación de la Guía en Yettú Ltda. ................................................................... 74
3.2. Instanciación de la Guía en Otra Organización ........................................................... 74
3.3. Investigación y Análisis de la Cultura Organizacional de las MIPyMES_DS
Colombianas ........................................................................................................................... 75
3.4. Realización Meta-Modelos de los Modelos de Mejora de Procesos MoProSoft y
CompetiSoft............................................................................................................................. 76
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página vii Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
3.5. Propuesta para Realizar una Guía Metodológica ....................................................... 77
VII - REFERENCIAS Y BIBLIOGRAFÍA ................................................................................... 78
1. REFERENCIAS ...................................................................................................................... 78
2. BIBLIOGRAFÍA ..................................................................................................................... 93
VIII - ANEXOS.............................................................................................................................. 94
1. Glosario.......................................................................................................................... 94
2. Conocimiento Aplicable a ProSoftCol – Entregable 1 Ciclo Rigor ................................... 95
3. Análisis de la Cultura Organizacional Colombiana – Entregable 2 Ciclo Rigor ............... 95
4. Requerimientos Específicos de la Micro-Empresa Yettú Ltda. - Entregable Ciclo Relevancia
95
5. Guía Metodológica – Entregable 1 Ciclo Diseño ............................................................. 95
6. Documento de Administración de Configuración – Entregable 1 Ciclo Diseño ................. 95
7. Cuestionario Evaluación de un Experto de la Completitud y Consistencia Interna de la
Guía 95
8. Observaciones y Recomendaciones para la Guía por Parte del Experto que realizó la
evaluación ............................................................................................................................... 95
9. Cuestionario TAM – Entregable 2 Ciclo Diseño .............................................................. 95
10. Carta de Validación de la Guía y su Instanciación, por Yettú Ltda. .............................. 95
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página viii Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
ÍNDICE DE ILUSTRACIONES
ILUSTRACIÓN 1 – PROBLEMÁTICA DE PROSOFTCOL ............................................................................. 4
ILUSTRACIÓN 2 - MARCO DE REFERENCIA INVESTIGACIÓN CIENTÍFICA BASADA EN EL DISEÑO DE
SISTEMAS DE INFORMACIÓN, ADAPTADA DE [<HEVNER2003>] .................................................... 8
ILUSTRACIÓN 3 - ADAPTACIÓN MARCO DE REFERENCIA INVESTIGACIÓN CIENTÍFICA BASADA EN EL
DISEÑO DE SISTEMAS DE INFORMACIÓN A PROSOFTCOL ............................................................. 9
ILUSTRACIÓN 4 – CARACTERÍSTICAS DE LOS NIVELES DE CAPACIDAD DEL MODELO CMMI
[<KULPA2003>] ....................................................................................................................... 17
ILUSTRACIÓN 5 - REPRESENTACIÓN CONTINUA DEL MODELO CMMI, ADAPTADA DE [<CHRISSIS2003>,
<KULPA2003>] ........................................................................................................................ 18
ILUSTRACIÓN 6 - ÁREAS DE PROCESO DE CMMI CLASIFICADAS EN CATEGORÍAS, ADAPTADA DE
[<INSTITUTE2005>] ................................................................................................................. 19
ILUSTRACIÓN 7 - DESCRIPCIÓN DE LAS CATEGORÍAS DE PROCESO DEL MODELO CMMI
[<CHRISSIS2003>] .................................................................................................................... 20
ILUSTRACIÓN 8 - COMPONENTES DE LAS ÁREAS DE PROCESO DEL MODELO CMMI [<CHRISSIS2003>] 21
ILUSTRACIÓN 9 - CARACTERÍSTICAS DE LOS NIVELES DE CAPACIDAD DEL MODELO MOPROSOFT
[<OKTABA2004>] .................................................................................................................... 23
ILUSTRACIÓN 10 - NIVELES DE CAPACIDAD Y ATRIBUTOS DE PROCESO DEL MODELO MOPROSOFT
[<ITERA2006>] ........................................................................................................................ 24
ILUSTRACIÓN 11 - CALIFICACIÓN DEL NIVEL DE CAPACIDAD DEL PROCESO EN EVALPROSOFT,
ADAPTADO DE [<PIATTINI2009>, <OKTABA2004>] .................................................................... 25
ILUSTRACIÓN 12 - ESTRUCTURA DEL MODELO DE REFERENCIA DE PROCESOS DEL MODELO MOPROSOFT
[<OKTABA2005B>] .................................................................................................................. 26
ILUSTRACIÓN 13 - PATRÓN DE PROCESOS DEL MODELO MOPROSOFT [<OKTABA2005B>] ................... 27
ILUSTRACIÓN 14 - CATEGORÍAS DE PROCESOS DEL MODELO COMPETISOFT [<PIATTINI2009>]............ 29
ILUSTRACIÓN 15 - DIMENSIONES DE LOS RESULTADOS DEL MÉTODO PROPUESTO POR [<LOOSO2010>] 33
ILUSTRACIÓN 16 - RESULTADOS DEL MÉTODO PROPUESTO POR [<LOOSO2010>] Y SUS DIMENSIONES . 33
ILUSTRACIÓN 17 - TIPOS DE SUB-CONJUNTOS DE MODELO SEGÚN ...................................................... 34
ILUSTRACIÓN 18 - CADENA DE PROCESOS ORIENTADA A EVENTOS DEL MÉTODO PROPUESTO POR
[<LOOSO2010>] ....................................................................................................................... 35
ILUSTRACIÓN 19 - MARCO DE REFERENCIA WAY OF. ADAPTADA DE [<OP'TLAND2009>] .................... 37
ILUSTRACIÓN 20 - VENTAJAS Y DESVENTAJAS COMPETITIVAS DE LAS MIPYMES_DS
[<RICHARDSON2007A>, <SCALZONE2008>, <RICHARDSON2007A>, <BRODMAN1994A>,
<TECNOLOGIADECOMUNICACION2008>] ................................................................................... 39
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página ix Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
ILUSTRACIÓN 21 - CARACTERÍSTICAS QUE DEBERÍA TENER UN BUENO MODELO DE MEJORA DE
PROCESOS DE SOFTWARE PARA MIPYMES_DS [<ALEXANDRE2006>, <BRODMAN1994A>,
<HABRA1999>, <ALLEN2003>] ................................................................................................ 41
ILUSTRACIÓN 22 - FACTORES DE ÉXITO Y FRACASO QUE AFECTAN A LA IMPLANTACIÓN DE UN MODELO
SPI [<DUBE1998>, <DUBE1999>, <YAMAMURA1999>, <PHONGPAIBUL2005>,
<NGWENYAMA2003>, <FREDERIKSEN2003>]............................................................................ 44
ILUSTRACIÓN 23 - PATRÓN DE LAS PYMES LATINOAMERICANAS [<DIPAULA2008>] .......................... 46
ILUSTRACIÓN 24 - MACRO-TENDENCIAS EN CULTURA ORGANIZACIONAL DE LAS EMPRESAS
COLOMBIANAS [<MORALES2010>] ........................................................................................... 47
ILUSTRACIÓN 25 - ANÁLISIS DE 4 EMPRESAS MEDIANAS Y 69 PEQUEÑAS EN BOGOTÁ [<URIBE2007>] 48
ILUSTRACIÓN 26 - VISTA DE LOS 3 CICLOS DE LA ICBDSI .................................................................. 49
ILUSTRACIÓN 27 - TÓPICOS CONTENIDOS EN EL ENTREGABLE # 2 DEL PROYECTO ............................... 52
ILUSTRACIÓN 28 - COMPONENTES MODELADO ESTADO ACTUAL DE UNA ORGANIZACIÓN
DESARROLLADORA DE SOFTWARE ............................................................................................ 55
ILUSTRACIÓN 29 - FLUJO DEL PROCESO IRAA ................................................................................... 57
ILUSTRACIÓN 30 - ESTRUCTURA GUÍA METODOLÓGICA ..................................................................... 58
ILUSTRACIÓN 31 - META-MODELO PROSOFTCOL ............................................................................... 59
ILUSTRACIÓN 32 – RELACIÓN ENTRE EL META-MODELO DE PROSOFTCOL Y EL MARCO DE REFERENCIA
FORMA DE ............................................................................................................................... 60
ILUSTRACIÓN 33 - MODELO ADAPTADO PARA YETTÚ LTDA ............................................................... 61
ILUSTRACIÓN 34 - SÍMBOLOS PARA DESCRIBIR EL ESTADO DE UNA TAREA O PRODUCTO DE TRABAJO EN
YETTÚ LTDA............................................................................................................................ 62
ILUSTRACIÓN 35 - FACTORES MÁS IMPORTANTES EN LA EXPLICACIÓN DEL USO DE UNA TECNOLOGÍA,
SEGÚN TAM [<DAVIS1989>] .................................................................................................... 63
ILUSTRACIÓN 36 - MODELO DE ACEPTACIÓN DE LA TECNOLOGÍA TAM [<DAVIS1989>] ..................... 64
ILUSTRACIÓN 37 - AFIRMACIONES DEL MODELO DE ACEPTACIÓN TECNOLÓGICA TAM [<DAVIS1989>,
<ORANTES2011>] .................................................................................................................... 65
ILUSTRACIÓN 38 - UTILIDAD PERCIBIDA DE PROSOFTCOL Y SU INSTANCIACIÓN POR LOS DIRECTIVOS DE
YETTÚ LTDA............................................................................................................................ 66
ILUSTRACIÓN 39 - FACILIDAD DE USO PERCIBIDA DE PROSOFTCOL Y SU INSTANCIACIÓN POR LOS
DIRECTIVOS DE YETTÚ LTDA ................................................................................................... 66
ILUSTRACIÓN 40 - AFIRMACIONES DE LA EVALUACIÓN DE UN EXPERTO EN CUANTO A LA GUÍA
METODOLÓGICA ...................................................................................................................... 67
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página x Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
ILUSTRACIÓN 41 - AFIRMACIONES DE LA EVALUACIÓN DE UN EXPERTO EN CUÁNTO A LA IMPLANTACIÓN
DE UN MMPS EN UNA ORGANIZACIÓN COLOMBIANA Y AQUELLO QUE SE PROPONE EN LA GUÍA
METODOLÓGICA ...................................................................................................................... 68
ILUSTRACIÓN 42 – AFIRMACIONES DE LA EVALUACIÓN DE UN EXPERTO EN CUANTO A LA VALIDEZ DE
LAS SOLUCIONES PROPUESTAS PARA LA ORGANIZACIÓN YETTÚ LTDA. ...................................... 68
ILUSTRACIÓN 43 - MARCO DE REFERENCIA DE COMPETICIÓN DE VALORES [<QUINN1985>] ............... 75
ÍNDICE DE TABLAS
TABLA 1 - COMPARACIÓN DE LAS REPRESENTACIONES DEL MODELO CMMI, ADAPTADA DE
[<CHRISSIS2003>] .................................................................................................................... 15
TABLA 2 - CALIFICACIÓN DE LOS ATRIBUTOS DE PROCESO DE EVALPROSOFT, ADAPTADO DE
[<PIATTINI2009>, <OKTABA2004>] .......................................................................................... 24
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página xi Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
ABSTRACT
The use of Software Process Improvement techniques (SPI) by Colombian Software
Development Very Small, Small and Medium Enterprises (VSEs and SMEs) is very limited
and complex, mainly because SPI models were created thinking about large organizations
from a different culture (namely North American and European) [69, 91]. The present
document presents a method that supports the adaptation of these models to an specific
context, taking into account the Colombian VSEs and SMEs special characteristics (size,
culture and resource availability), which allows these organizations to implement these
models in a useful and simple way increasing their competitiveness and their process and
product’s quality.
RESUMEN
El uso de las técnicas existentes de mejora de procesos de construcción de software (SPI) por
parte de las MIPyMES_DS1
Colombianas es limitado y complejo, ya que los modelos de SPI
fueron creados pensando en organizaciones de gran tamaño y de culturas diferentes (como la
Norte-Americana y Europea) [69, 91]. El presente documento propone un método que
soporta la adaptación de estos modelos a un contexto específico, teniendo en cuenta las
características especiales de las MIPyMES Colombianas (tamaño, cultura y disponibilidad de
recursos), y permite a éstas organizaciones implementar estos modelos de forma provechosa
y simple, aumentando su competitividad y la calidad de sus procesos y productos.
1
Micro, pequeñas y medianas empresas desarrolladoras de software
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página xii Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
RESUMEN EJECUTIVO
El estudio previo de las variables culturales de una organización antes de iniciar la
implementación de un modelo de mejora de procesos de software (MMPS) puede hacer la
diferencia entre una implementación exitosa o una que fracasa [5]. No obstante, cuando se
crearon los modelos de mejora de procesos CMM [99], CMMI [121] y SPICE [128] (que
hoy en día son los más reconocidos mundialmente), tanto el factor cultural como la
diversidad de tamaños de empresa alrededor del mundo fueron omitidos, lo que ha
ocasionado hasta hoy en día que estos modelos no sean fácilmente aplicables a las
MIPyMES_DS [1, 3, 70, 91, 110, 35]. Para realizar un aporte a la solución de ésta
problemática, este trabajo de grado presenta un método que soporta la adaptación de dichos
modelos al contexto de las MIPyMES_DS colombianas, teniendo en cuenta sus
características especiales en términos de tamaño, cultura y disponibilidad de recursos.
Este método, como todos los demás, tiene un espíritu, un paradigma que describe la forma de
pensar que lo rige [6] que se resumió en el párrafo anterior. Por ello, propone modelar el
estado actual de una organización en términos de sus características especiales (procesos de
software, cultura organizacional y tecnología e infraestructura), teniendo en cuenta que éste
es el mejor punto de inicio para iniciar una mejora, especialmente para una organización
pequeña [55]. Se propone que la implantación de un MMPS se logra siguiendo un proceso
que se ha denominado IRAA (Identificar, Representar, Analizar y Adaptar) para cada
componente de la organización mencionado anteriormente.
Al realizar la parte IR se tendrá un modelo el estado actual de la organización; la parte AA se
debe realizar simultáneamente y en ella se deben tomar una serie de decisiones (basadas en
los resultados obtenidos de IR) en cuanto a qué MMPS adaptar, y las reducciones de rango y
profundidad a realizar sobre el MMPS seleccionado.
Para instanciar el método propuesto, se realizó un caso de estudio con una micro empresa
bogotana desarrolladora de software, es decir, que cada actividad propuesta por el método se
llevó a cabo en la organización, dando como producto final un MMPS adaptado
específicamente a la compañía.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página xiii Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Este trabajo de grado se realizó bajo el paradigma de la investigación científica basada en el
diseño de sistemas de información [57, 56], que consiste de 3 ciclos: relevancia, diseño y
rigor. En este caso, se realizó primero el ciclo de rigor, recolectando todo el conocimiento
base que podría ser aplicable al diseño del artefacto (método propuesto), en especial
información sobre los MMPS existentes. Enseguida se pasó al ciclo de relevancia, en el que
se analizó el entorno (organización de caso de estudio) y se obtuvo su estado actual y
necesidades de negocio. Por último se realizó el diseño del método, en el cual se combinaron
el conocimiento aplicable y las necesidades de la organización, dando como resultado el
método propuesto.
Debido a la limitación de tiempo de este trabajo de grado (4 meses), el método propuesto no
fue implementado en la organización de caso de estudio más si validado midiendo su utilidad
potencial con el modelo de aceptación de la tecnología (TAM) [32] con los directivos de la
organización para la que se instanció el método; igualmente, un experto realizó una
evaluación de su consistencia interna y completitud.
La validación arrojó resultados positivos al reflejar que la utilidad y facilidad de uso
percibida del método es alta. Al mismo tiempo, la evaluación reflejó que el método es
completo, aporta una solución útil para solucionar el problema planteado, y las actividades
que se proponen realizar son relevantes a la hora de implantar un MMPS en una
organización.
Esto conlleva a concluir que el trabajo realizado fue significativo y que es necesario llevar a
cabo más instanciaciones del método propuesto e implementar en la organización de caso de
estudio el MMPS adaptado (resultado de la realización del método), para lograr fortalecer su
utilidad.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 1
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
INTRODUCCIÓN
El presente documento pretende resumir todos los aspectos fundamentales de la realización
del trabajo de grado ProSoftCol: Guía Metodológica de Mejora de Procesos de Construcción
de Software Adaptada para MIPyMES_DS Colombianas, cuyo fin es soportar la adaptación
de los modelos de mejora de procesos de construcción de software a éstas, bajo la afirmación
de que es necesario tener en cuenta 2 de los factores más influyentes inciden sobre la calidad
de los procesos de desarrollo de software: el tamaño (de la organización y de los proyectos
que desarrolla) [17] y la cultura [82, 83, 84, 37, 38, 131, 101, 86, 43].
El documento está compuesto de 8 secciones, en la primera se presenta una descripción
general de éste trabajo, que profundiza en la problemática y en la solución que se propone
para ésta. En la segunda sección se expone el marco teórico que contiene la base del
conocimiento relevante para la realización de éste trabajo y se divide en conceptual y
contextual, éste último se enfoca en presentar la relevancia del trabajo en el mundo real.
Enseguida, se presenta el desarrollo del trabajo alrededor del paradigma bajo el que se realizó
(investigación científica basada en el diseño de sistemas de información o ICBDSI; ver
sección 2.5 Método que se Propuso para Satisfacer cada Fase Metodológica en I -
DESCRIPCION GENERAL DEL TRABAJO DE GRADO), describiendo los sucesos más
relevantes y demostrando como cada uno de ellos influenció el producto final. La siguiente
sección presenta una reflexión alrededor del trabajo con dicho paradigma y una comparación
de aquello que se planeó en la propuesta de trabajo de grado con aquello que realmente se
realizó. Seguido de esto se presentan las evaluaciones y validaciones del producto realizado y
los resultados que se obtuvieron luego de terminado el proceso. Por último, se presentan un
análisis de los resultados obtenidos (o conclusiones), recomendaciones para los estudiantes
que deseen realizar su trabajo de grado en un tópico similar y las nuevas ideas que surgieron
para investigación durante la realización de este proyecto. Las 2 últimas secciones presentan
las referencias citadas en éste documento y los anexos.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 2
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
I - DESCRIPCION GENERAL DEL TRABAJO DE GRADO
1. Oportunidad, Problemática, Antecedentes
1.1. Descripción del Contexto
¿Por qué falla un proceso de software? A través de los años y desde 1920 (en la ingeniería
industrial) se ha tratado de mejorar la forma en la que se llevan a cabo los procesos para la
elaboración de toda clase de productos [100], pero para el software este intento de mejora es
diferente, ya que este es un producto intangible y no existe una manera exacta (o precisa
como con los demás productos) de medir su calidad o los atributos de ésta percibidos por el
cliente [20]. Además, a medida que los sistemas de software crecen y se vuelven más
complejos se crea una necesidad de llevar a cabo un proceso de desarrollo de software que
sea bien manejado y entendido [4, 109]. No obstante, existen algunas aproximaciones como
las técnicas de mejoramiento de procesos de software (SPI por sus siglas en inglés). Las
múltiples implementaciones de éstas alrededor del mundo han probado que existen varios
beneficios, tales como asegurar la calidad del producto, reducir costos y tiempo de desarrollo,
maximizar la productividad, el éxito organizacional y la satisfacción del cliente [119]. El
beneficio más sobresaliente e importante es la calidad, ya que la calidad del producto
determina el éxito de una organización de software, y la calidad del producto está
determinada por la calidad de los procesos utilizados para desarrollarlo [121, 52, 29]. Es por
esto que las empresas deben dedicarle tiempo a la definición, adecuación y mejoramiento
continuo de sus procesos de calidad [21]; ello puede conllevar a una valoración de la misma,
con lo que se lograría:
Unir la misión de la empresa y el esfuerzo de cada una de las áreas que la integran en
una sinergia de resultados orientados a la competitividad y calidad global.
Tener procesos y procedimientos ágiles y comprensibles por todos los involucrados
[35].
Todas las empresas desarrolladoras de software de cualquier tamaño deben usar al menos un
modelo o estándar de Mejora de Procesos de Software (SPI), ya sea local o internacional [76].
Pero esto no es tan sencillo porque existen múltiples factores que inciden sobre la calidad de
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 3
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
los procesos de desarrollo de software: el tamaño (de la organización [17], de los proyectos
que se realizan [17], y del recurso humano), la cultura [82, 83, 84, 37, 38, 131, 101, 86, 43],
el nivel de educación, la tecnología, el tiempo, el esfuerzo, el recurso económico y otros que
tienen un menor impacto como la fiabilidad, la eficiencia, facilidad de mantenimiento y la
usabilidad [129].
Algunos de estos factores (no todos) se han tenido en cuenta por el Departamento de Defensa
de los Estados Unidos de América [99, 121] y del Reino Unido, y por la Organización de
Estandarización Internacional [128], por ello surgieron modelos y estándares internacionales.
Entre los más utilizados y reconocidos por el mercado se encuentran [113]: el conjunto de
Normas ISO para certificación de Calidad tales como ISO/IEC 15504-2 [128], ISO 90003,
ISO 9001:2000, y el Modelo CMMI (Capability Maturity Model Integration)[121]; pero estos
fueron creados pensando en grandes empresas de cultura Norte-Americana o Europea [69,
91]. Esto respalda la afirmación de que no todos los factores influyentes en la calidad de
procesos de desarrollo de software se han tenido en cuenta, pues al crear modelos para
empresas grandes y de 2 tipos de cultura específica, se está dejando por fuera a las micro,
pequeñas y medianas empresas, incluso de la misma cultura Americana o Europea (tamaño)
y a aquellas organizaciones que sean grandes, medianas, pequeñas o micro, no pertenecen a
ninguna de esas 2 culturas, como las latinoamericanas (cultura). La Ilustración 1 resume lo
anterior:
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 4
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ilustración 1 – Problemática de ProSoftCol
Éste tipo de empresas hoy en día y especialmente luego de los cambios económicos sufridos a
partir del año 2001, conforma uno de los sectores más representativos de la economía
latinoamericana [113] y mundial [1, 69]. Por ello, la mayoría de empresas desarrolladoras de
software alrededor del mundo son pequeñas (en países como Estados Unidos, Brasil, Canadá,
India, China, Finlandia, entre otros, las pequeñas compañías de software que cuentan con
menos de 50 empleados representan hasta un 85% de las compañías de software [106, 21]), o
micro (en Europa, las micro empresas representan un 93% número total de compañías
desarrolladoras de software, en E.E.U.U. el 56% [69] y en Australia el 88% [22]).
Tanto el Gobierno Nacional de Colombia como Fedesoft son conscientes de que debido a la
situación en la que se encuentra la industria de software en el país y a las oportunidades de
mercado que se les presentan actualmente, se debe buscar incentivar el entendimiento y la
adopción de estándares y mejores prácticas de reconocimiento internacional en las PyMES,
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 5
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
para que su adopción sea más sencilla, rápida y económica, facilitando la eventual evaluación
de estas empresas de acuerdo con las mejores prácticas internacionales para así buscar una
mejor posición y competir consistentemente en la nueva dinámica de los mercados
internacionales de software [21]. Es por esto que, específicamente respecto a los modelos de
calidad, en conjunto con la empresa privada, el Gobierno ha realizado esfuerzos para mejorar
la posición competitiva de las empresas de software colombianas. Esto se ha logrado por
medio de Proexport, que ha realizado un gran progreso en la evaluación de procesos de
acuerdo con el modelo CMMI [21, 45]; en consecuencia, hasta la fecha en Colombia existen
16 empresas que cuentan con una valoración en algún nivel de CMMI [21, 33]. Éste el
modelo más conocido y utilizado por compañías de software alrededor del mundo [86]. Sin
embargo, como se mencionó anteriormente, fue diseñado para grandes organizaciones y
aquellas valoradas en el país lo son, por lo que el sector de las MIPyMES_DS (que es
bastante grande , ya que de las 1000 empresas desarrolladoras de software existentes en
Colombia, sólo 20 tienen más de 20 ingenieros [44], es decir que un 98% son empresas muy
pequeñas [69]) no hacen uso de ésta oferta tecnológica con la que cuenta el país [34, 21].
1.2.Solución a la Problemática
Una guía metodológica de mejora de procesos de construcción de software específicamente
adaptado para MIPyMES_DS colombianas que tenga en cuenta sus características especiales,
en particular tamaño (de la organización y de los proyectos que realiza) y cultura, puede
mejorar la competitividad de éstas y a su vez mejorar la calidad de los procesos de software
de las mismas, y por ende de sus productos.
2. Descripción del Proyecto
2.1 Visión Global
Se elaboró una guía metodológica que soporta la adaptación de un modelo de mejora de
procesos de construcción de software a las MIPyMES_DS Colombianas teniendo en cuenta
sus características especiales, en especial tamaño y cultura; para que el uso de los modelos de
mejora de procesos de software existentes por parte de estas organizaciones sea provechoso,
sencillo y guiado.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 6
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
2.2 Justificación
Los modelos disponibles como CMM [99], CMMI [121], y SPICE [128] no son fácilmente
aplicables a las MIPyMES_DS porque son muy complejos, su implementación es muy
costosa y requieren de mucho tiempo [1, 3, 70, 91, 110, 35]. Además, las diferencias
culturales entre los modelos existentes y las organizaciones que desean implementarlos
juegan un rol fundamental en el éxito de la mejora de los procesos de software [39, 91], y a
menos que el proyecto de implantación de un modelo de SPI considere la brecha cultural, la
posibilidad de obtener grandes resultados es mínima [111], pues una organización rechazará
un proceso si éste no es acorde con su cultura, de la misma forma en que el cuerpo humano
no aceptará un trasplante de un órgano no compatible [132, 91].
Aparte de la diferencia entre la cultura que plantean modelos como CMM [99], CMMI [121]
y SPICE [128], y la cultura de las PyMES latinoamericanas y colombianas, existe otro fuerte
argumento para justificar la adaptación de un modelo específicamente al contexto
colombiano, este es que los marcos de referencia científicos, como obra de humanos, se
inspiran y fundamentan en contextos geográficos, culturales e históricos concretos [14] y las
afirmaciones culturales dentro de estos modelos son de origen occidental (eurocéntrico –
anglosajón), por lo que éstos necesitan una adaptación al contexto de cultura nacional de la
organización en la que sean implantados o adaptados [82]. Ninguna organización es inmune a
su entorno y si hay fuertes corrientes de inestabilidad en el contexto de operación de la
organización, esta se verá inevitablemente afectada. La aplicación de los modelos
provenientes de sin tener en cuenta estas influencias desestabilizadoras puede conducir a
graves errores [134, 14]. El contexto del mundo en desarrollo en general, y latinoamericano
en particular, presenta desafíos claros y conocidos en este sentido [55]. Esto evidencia que los
modelos existentes no deben aplicarse en forma automática, como una serie de instrucciones
completamente mecánicas.
Por ello, algunos estudios [24, 66, 71, 75, 118] recomiendan que la aplicación de modelos de
mejora de procesos de construcción de software se complemente con un marco de análisis y
gestión de cambio diseñado específicamente a partir de un diagnóstico de la organización en
cuestión [42].
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 7
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
2.3 Objetivo General
Adaptar un modelo de mejora de procesos de construcción de software para micro, pequeñas
y medianas empresas Colombianas.
2.4 Objetivos Específicos
Estudiar modelos de mejora de procesos de desarrollo de software existentes (CMMI,
MoProSoft, CompetiSoft)
Realizar análisis cultural y organizacional de MIPyMES_DS Colombianas
Obtener requerimientos específicos de una (1) MIPyME_DS Colombiana en cuanto a
procesos de software de ésta
Adaptar un modelo específico para la MIPyMES_DS Colombiana de la cual se
obtuvieron los requerimientos específicos
Evaluar la consistencia interna y la completitud del modelo propuesto
Medir la utilidad potencial del modelo
Refinar el modelo propuesto, a partir de los resultados de la validación del mismo
2.5 Método que se Propuso para Satisfacer cada Fase
Metodológica
Para realizar este proyecto se propuso trabajar bajo el paradigma de la ―investigación
científica casada en el diseño de sistemas de información‖ [57, 56]. Con este se busca crear
artefactos (innovaciones), clasificados en:
Conceptos o Constructos, que proveen el lenguaje en el que los problemas y las
soluciones son definidas. Son las bases sobre las cuales se construyen los métodos y
modelos.
Modelos, que usan los conceptos para representar una situación del mundo real.
Métodos, que definen los procesos de solución, o guías para la acción.
Instanciaciones, que muestran cómo implementar conceptos, modelos o métodos en
un sistema. Estas permiten realizar una evaluación concreta de la adaptación de un
artefacto a su propósito, y su efecto en el mundo real.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 8
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Este paradigma trabaja sobre un marco de referencia específico, dentro del cual se propuso
llevar a cabo las fases metodológicas de este proyecto. La Ilustración 2 muestra el marco de
referencia original y la Ilustración 3 muestra su adaptación/mapeo a este proyecto.
La investigación científica basada en el diseño de sistemas de información (ICBDIS)
consiste en tres (3) ciclos: relevancia, diseño y rigor; los resultados de cada ciclo se pueden
observar en la Ilustración 2 (de derecha a izquierda) como los 3 rectángulos que la
conforman, así [57, 56]:
El ciclo de Relevancia estudia el Entorno para obtener las Necesidades y
Oportunidades de Negocio y luego lo interviene para solucionar el problema
El ciclo de Diseño da como resultado el Artefacto como tal (investigación)
El ciclo de Rigor da como resultado el Conocimiento Aplicable a partir de una Base
de Conocimiento.
Dada la limitación de tiempo, en este proyecto se propuso realizar únicamente una iteración
de cada ciclo.
Ilustración 2 - Marco de Referencia Investigación Científica Basada en el Diseño de Sistemas de
Información, adaptada de [57]
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 9
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ilustración 3 - Adaptación Marco de Referencia Investigación Científica Basada en el Diseño de Sistemas
de Información a ProSoftCol
A continuación, se describirá la Ilustración 3 por medio de las fases metodológicas,
actividades y entregables del proyecto.
2.5.1. Estudiar modelos de mejora de procesos de desarrollo de software
existentes (CMMI, MoProSoft, CompetiSoft)
La base del conocimiento provee los materiales para la investigación (cimientos), es decir,
teorías, marcos de referencia, instrumentos, conceptos, modelos, métodos e instanciaciones
sobre las cuales se regirá el diseño del artefacto [57]. Para lograr el rigor se deben aplicar
apropiada y transparentemente las bases y metodologías existentes [124], por esto, se propuso
que el entregable para ésta fase metodológica fuera un documento que contuviera los
aspectos más relevantes de los modelos de mejora de procesos existentes, en particular
CMMI [121], MoProSoft [89] y CompetiSoft [103], ya que son muy similares y los dos
últimos son instanciaciones del primero para contextos similares al contexto particular en el
que se encuentra este proyecto. En la Ilustración 3, el entregable es representado por la flecha
azul emergente del conocimiento, es decir, conocimiento aplicable.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 10
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
2.5.2. Realizar análisis cultural y organizacional de MIPyMES_DS
Colombianas
Aquello que hace al contexto de éste proyecto diferente de aquél para el que los modelos de
mejora de procesos existentes son 2 variables principales: tamaño y cultura. Teniendo en
cuenta lo anterior, es necesario agregar al ciclo de rigor la obtención del conocimiento de la
cultura organizacional de las MIPyMES_DS colombianas en general. De aquí se desprende
que al conocimiento aplicable se le añada un documento que contenga las principales
características de la cultura organizacional colombiana (en empresas desarrolladoras de
software).
2.5.3. Obtener requerimientos específicos de una (1) MIPyME_DS Colombiana
en cuanto a procesos de software de ésta
El entorno define el contexto del problema [57]. En este caso, el contexto son las
MIPyMES_DS colombianas, y se propuso elegir una (1) de éstas para tener un caso
representativo y realizar un levantamiento de sus requerimientos específicos. Para ello es
necesario enmarcar o dirigir las actividades de investigación (trabajo de campo/caso de
estudio) a las necesidades de negocio de dicha organización (esto asegura relevancia) [57].
Se propuso que el entregable para esta fase metodológica fuera un documento de
especificación requerimientos de la MIPyME_DS elegida, en la Ilustración 3 es representado
por la flecha azul emergente del entorno, es decir, las necesidades de negocio.
2.5.4. Adaptar un modelo específico para la MIPyMES_DS Colombiana de la
cual se obtuvieron los requerimientos específicos
En el ciclo de diseño se construirá el artefacto (ProSoftCol) que intentará satisfacer las
necesidades de negocio (ver sección 2.5.3) de la organización, utilizando el conocimiento
aplicable (ver secciones 2.5.1 y 2.5.2). Se propuso que el entregable para esta fase
metodológica fuera el propio artefacto, que es un método basado en conceptos y modelos
existentes, instanciado para esta MIPyME_DS Colombiana, de la cual se obtuvieron los
requerimientos específicos. En la Ilustración 3, el entregable es representado en la parte
superior de investigación, como la construcción de ProSoftCol.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 11
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
2.5.5. Evaluar la consistencia interna y la completitud del modelo propuesto
El ciclo de diseño tiene dos (2) fases complementarias: construcción (ver sección 2.5.4) y
evaluación del artefacto. Ésta última está representada en la Ilustración 3 con la flecha negra
emergente de la construcción de ProSoftCol hacia la validación de su utilidad potencial. Se
propuso que el entregable de ésta fase fuera una evaluación interna, es decir, sin tener en
cuenta a las personas que conforman la organización del caso de estudio, y se hará por medio
de una lista de chequeo que mida completitud, consistencia y constitución del artefacto
diseñado.
2.5.6. Medir la utilidad potencial del modelo
Al tener las necesidades de negocio de la organización se van a obtener unas condiciones
previas a la implementación del artefacto, pero dada la limitación de tiempo no se podrán
medir completamente las condiciones posteriores, por lo que se medirá la utilidad potencial
del artefacto, ya que la investigación científica basada en el diseño de sistemas de
información siempre busca evaluar los artefactos con respecto a la utilidad que proveen
solucionando los problemas del mundo real [57].
Se propone realizar esta medición por medio del Modelo de Aceptación de la Tecnología
(TAM por sus siglas en inglés) [32], que provee una representación informativa de los
mecanismos mediante los cuales las decisiones de diseño influencian la aceptación del
usuario y es útil para predecir y evaluar la aceptación del usuario de la guía metodológica
ProSoftCol [122].
Este modelo plantea que la utilidad percibida y la facilidad de uso percibida determinan la
intención de un individuo de usar un artefacto, y a la vez que la utilidad percibida está
directamente impactada por la facilidad de uso percibida. En la sección 0 En esta sección se
presentarán primero los resultados de la validación de la utilidad potencial de la guía y de su
instanciación, seguida de los resultados de la evaluación de un experto acerca de la
completitud y la consistencia interna de la guía y por último, con base en ellos se presentarán
los resultados obtenidos de la realización de éste trabajo de grado.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 12
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Validación de la Utilidad Potencial de la Guía de V - RESULTADOS Y REFLEXIÓN
SOBRE LOS MISMOS, se describirá con mayor profundidad éste modelo.
Para esto se propuso utilizar un instrumento particular, dentro de las opciones de: encuesta,
taller, presentación de la guía metodológica ante la organización o utilización de un aspecto
práctico de la guía.
La implementación de la guía metodológica como tal está fuera del alcance de este proyecto
de investigación, su aplicación hace parte de un proceso de consultoría. Por esta razón, se
propuso que el entregable de esta fase metodológica fuera el resultado de la validación de la
utilidad potencial de la guía metodológica y su instanciación dentro de la organización del
caso de estudio.
2.5.7. Refinar el modelo propuesto, a partir de los resultados de la validación
del mismo
La validación de la utilidad potencial de la guía metodológica y su implementación generará
una retro-alimentación que mejorará el entendimiento del problema y la forma en que ésta lo
soluciona [124]. Se propuso que el entregable de ésta fase metodológica fuera un documento
que contenga los puntos débiles y fuertes de la guía y su instanciación. Estos puntos débiles
se convierten en nuevos requerimientos para un diseño posterior (en otro hito). La refinación
se representa en la Ilustración 3 como la flecha negra emergente de la validación de la
utilidad potencial, hacia la construcción de ProSoftCol.
II - MARCO TEÓRICO
1. Marco Conceptual
1.1.1. Modelos de Mejora de Procesos de Software
La definición de un Modelo de Mejora de Procesos de Software (MMPS) permite desarrollar
modelos que soporten diversas aproximaciones a la mejora de procesos. Con tal que un
modelo contenga los elementos esenciales de los procesos eficaces para una o más disciplinas
y describa una trayectoria evolutiva de mejora, permitiendo transformar desde procesos ad-
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 13
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
hoc y no maduros a procesos disciplinados y maduros con calidad y eficacia mejorada, se
considera un MMPS [28].
A continuación se describirán los 3 modelos de mejora de procesos de software que se
tomaron como base para el desarrollo de este proyecto. Cada modelo se describirá de la
siguiente manera:
Representación
Los MMPS permiten aproximarse a la mejora de procesos y evaluaciones con
representaciones diferentes, ya sea continua (midiendo capacidad) o escalonada (midiendo
madurez) [28].
Capacidad: Rango de resultados esperados que pueden lograrse siguiendo un
proceso [29].
Madurez: Grado en el que una organización tiene explícita y consistentemente los
procesos desplegados que están documentados, gestionados, medidos, controlados y
mejorados continuamente [29].
Método o Modelo de Evaluación
Los métodos de evaluación de los modelos de mejora de procesos de software (MMPS)
brindan los criterios de evaluación que comunican aquellos requisitos necesarios para
alcanzar un nivel de capacidad, o madurez.
Categorías de Procesos
El desarrollo y mantenimiento de software se lleva a cabo a través de una serie de actividades
realizadas por equipos de trabajo. La Ingeniería de Software se ha dedicado a identificar las
mejores prácticas para realizar estas actividades recopilando las experiencias exitosas de la
industria de software a nivel mundial. Estas prácticas se han organizado por áreas de
aplicación, y se han dado a conocer como áreas clave de procesos, en caso de CMM [99], o
como procesos de software en ISO/IEC 15504 [128].
En los MMPS los procesos afines son agrupados en categorías
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 14
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Patrón de Procesos
Es un esquema de elementos que sirve para la documentación de los procesos, es decir, para
conocer los elementos que los componen y cómo se describen.
Para el caso de esta guía metodológica es clave conocer el patrón de procesos, ya que con
base en éstos se realizan los meta-modelos de los MMPS, esto se aclarará en la sección 1.1.2
Ingeniería de Métodos.
CMMI
Capability Maturity Model Integration es un modelo para mejora o evaluación de los
procesos de desarrollo y mantenimiento de sistemas y productos de software creado por el
Software Engineering Institute (SEI), diseñado para integrar la gran cantidad de modelos que
han sido creados a través de los años por ésta y otras organizaciones [68]. Provee un conjunto
de prácticas reconocidas por la industria para la productividad, desempeño y costo de
desarrollo de software [127], su objetivo es el logro de procesos óptimos repetibles en el
desarrollo de software. En la actualidad hay 3 áreas de interés cubiertas por los modelos de
CMMI, éstas son desarrollo (CMMI-DEV), adquisición (CMMI-SVC) y servicios (CMMI-
ACQ). Así mismo, 4 cuerpos de conocimiento (BOK por sus siglas en inglés) están cubiertos
cuando se planea mejorar los procesos con CMMI: Ingeniería de sistemas, ingeniería de
software, desarrollo integrado de productos y procesos, y proveedores.
CMMI está estructurado de la siguiente manera [68]:
Niveles de Madurez (Representación Escalonada) o Niveles de Capacidad
(Representación Continua).
Áreas de Proceso:
o Las áreas de proceso son un clúster de las buenas prácticas en un área, que
cuando se implementan colectivamente satisfacen un conjunto de metas
consideradas importantes para tener una mejora relevante [29]. Todas las
áreas de proceso de CMMI son comunes tanto a la representación continua
como a la escalonada [28].
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 15
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
o Sus componentes están agrupados en 3 categorías: Requeridos, esperados e
informativos (Ver Ilustración 7)
La Tabla 1 ilustra las principales diferencias entre las 2 representaciones del modelo CMMI:
Representación Escalonada Representación Continua
La organización selecciona las áreas de
proceso según los niveles de madurez
La organización selecciona las áreas de proceso y
los niveles de capacidad según sus objetivos de
mejora de procesos
La mejora se mide utilizando niveles de
madurez, que:
Miden la madurez de un conjunto de procesos en toda la organización
Se califican de 1 a 5
La mejora se mide utilizando niveles de
capacidad, que:
Miden la madurez de un proceso particular en toda la organización
Se califican de 0 a 5
Los niveles de madurez se usan para establecer un objetivo y realizar el
seguimiento de la mejora de procesos
Los perfiles de nivel de capacidad se usan para establecer un objetivo y realizar el seguimiento del
rendimiento de la mejora de procesos.
Tabla 1 - Comparación de las Representaciones del Modelo CMMI, adaptada de [29]
Como se puede observar en la Tabla 1, la representación escalonada propone conjuntos
predefinidos de áreas de proceso para definir el camino de mejora, mientras que la continua
permite a la organización elegir el enfoque de sus esfuerzos de mejora de procesos mediante
la elección de aquellas áreas de proceso, o conjuntos de área de proceso interrelacionadas,
que benefician más a la organización y a sus objetivos de negocio [29], ofreciendo más
libertad en el orden de mejora y una medida para la capacidad de los procesos [73]; Por ello
podría ser más aplicable a pequeñas empresas [2] y por eso se ha elegido esta representación
de dicho modelo como base de este proyecto.
Representación Continua
Usa niveles de capacidad y permite a la organización elegir un área particular de proceso y
mejorar en ella. Provee libertad para escoger el orden de mejora que se adapte mejor a los
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 16
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
objetivos de negocio de la organización [100]. Un nivel de capacidad se enfoca en madurar la
habilidad de una organización para realizar, controlar y mejorar su desempeño en un área de
proceso. Existen 6 niveles de capacidad [68], cada uno de ellos es descrito en la Ilustración 4:
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 17
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ilustración 4 – Características de los Niveles de Capacidad del Modelo CMMI [68]
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 18
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Método de Evaluación
Para alcanzar un nivel de capacidad se deben cumplir las prácticas específicas del área de
proceso en la que se quiere alcanzar dicho nivel y además deben ser implementadas todas las
prácticas genéricas que existen para dicho nivel de capacidad. Las prácticas genéricas
pertenecen a muchas áreas de proceso y no sólo a una, de modo que incluso en esta
representación hay conexión y relación entre las áreas de proceso (así la organización escoja
una sola para mejorar); tal como lo muestra la Ilustración 5:
Ilustración 5 - Representación Continua del Modelo CMMI, adaptada de [29, 68]
En la Ilustración 8 se describe cada uno de los componentes de la Ilustración 5.
Categorías de Procesos
Para dar soporte a las organizaciones que eligen la representación continua, las áreas de
proceso son clasificadas en 4 categorías, y cada área de proceso pertenece exclusivamente a
una categoría dependiendo de la funcionalidad que desempeña, tal y como lo muestra la
Ilustración 6 :
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 19
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ilustración 6 - Áreas de Proceso de CMMI Clasificadas en Categorías, adaptada de [58]
Cada categoría tiene áreas de proceso fundamentales y progresivas (las fundamentales deben
ser implementadas antes que las progresivas para garantizar el cumplimiento de los pre-
requisitos); la excepción es la categoría de Ingeniería, en la que las áreas de proceso son
recursivas [29].
A continuación, la Ilustración 7 muestra una descripción de cada una de las categorías de
proceso de CMMI:
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 20
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ilustración 7 - Descripción de las Categorías de Proceso del Modelo CMMI [29]
Patrón de Procesos
A continuación en la Ilustración 8 se describen los componentes de las áreas de proceso [29],
a su vez esta descripción representa el patrón de procesos de CMMI:
Gestión de Procesos
Actividades transversales a los
proyectos, relacionados con la definición,
planificación, despliegue,
implementación, monitoreo y control,
evaluación, medición y mejora de procesos
Gestión de Proyectos
Actividades de gestión de proyectos
relacionadas con la planificación,
monitorización, y control de proyectos.
Ingeniería
Actividades de desarrollo y de
mantenimiento . Cualquier disciplina
técnica implicada en el proceso de desarrollo del producto (en este caso software) pueda usarlas para la mejora
de procesos.
Soporte
Actividades que soportan y apoyan el
desarrollo del producto y su mantenimiento.
Trata los procesos que se usan en el contexto
de la ejecución de otros procesos y aquellos que
están orientados al proyecto.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 21
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ilustración 8 - Componentes de las Áreas de Proceso del Modelo CMMI [29]
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 22
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
MoProSoft
El Modelo de Procesos para la Industria del Software: MoProSoft fue desarrollado a solicitud
de la Secretaría de Economía, que inició el Programa para el Desarrollo de la Industria de
Software: PROSOFT, para servir como base de la Norma Mexicana de la Industria de
Desarrollo y Mantenimiento de Software bajo el convenio con la Facultad de Ciencias de la
Universidad Autónoma de México; y con el objetivo de fortalecer la industria del software en
México [89, 93].
Dentro de las estrategias de PROSOFT existe una sexta (6) que estipula "alcanzar niveles
internacionales en capacidad de procesos", para esto fue necesaria una definición de un
modelo de procesos y evaluación apropiado para la industria del software mexicana que
debería cumplir con los siguientes requerimientos:
Específico para desarrollo y mantenimiento de software
Fácil de entender
Definido como conjunto de procesos
Práctico y fácil de aplicar, sobre todo en organizaciones pequeñas
Orientado a mejorar los procesos para contribuir a los objetivos de negocio y no
simplemente ser un marco de referencia de certificación
Debe de tener un mecanismo de evaluación o certificación, que indique un estado real
de una organización durante un período de vigencia específico.
Aplicable como norma mexicana
Ser la base para alcanzar evaluaciones exitosas con otros modelos, tales como ISO
9000 : 2000 ó CMMI v1.1
La razón del establecimiento de los requerimientos anteriores es que la industria del software
en México es en su mayoría pequeña y mediana, el 90% de las empresas desarrolladoras de
software se encuentran en dichas categorías y además son volátiles, cuentan con pocos
recursos y tienen procesos no estandarizados que dependen del personal que los ejecuta [92].
MoProSoft está fundamentado en ISO 9000:2000, SW-CMM y el reporte técnico ISO/IECTR
15504, por lo que la adopción de este modelo habilita la obtención de un certificado ISO
9000 y reduce la brecha para la obtención de una valoración en CMMI Nivel 2 [92].
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 23
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Capacidades de Procesos
Este modelo consta de una sola representación y utiliza niveles de capacidad de procesos
[90], de forma similar a la representación continua de CMMI.
La capacidad de un proceso se evalúa en niveles en una escala de 0 a 5, así como lo muestra
la Ilustración 9:
Ilustración 9 - Características de los Niveles de Capacidad del Modelo MoProSoft [88]
La medición de capacidad se obtiene a través de un conjunto de Atributos de Procesos, que se
usan para determinar cuándo un proceso ha alcanzado una capacidad; cada atributo mide un
aspecto particular de un proceso [88].
Modelo de Evaluación
En el 2005 se estableció la norma mexicana NMX-059-NYCE bajo el nombre: Tecnología de
la Información-Software-Modelos de procesos y de evaluación para desarrollo y
mantenimiento de software, que consta de 4 partes [93]: Definición de Conceptos y
Productos, Requisitos de Procesos: MoProSoft, Guía de Implantación de Procesos,
Directrices para la Evaluación: EvalProSoft.
Esta parte 4 del estándar provee un método para evaluar una organización y establecer un
perfil de su nivel de capacidad para los 9 procesos implementados y un nivel de capacidad de
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 24
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
la madurez [107]. Los niveles de capacidad alcanzables y sus atributos de proceso están
divididos en una escala de 6 niveles como lo muestra la Ilustración 10:
Ilustración 10 - Niveles de Capacidad y Atributos de Proceso del Modelo MoProSoft [61]
En la Tabla 2 se encuentra la escala con la que se califica el grado de cumplimiento de un
atributo del proceso:
Letra Calificación % de Alcance
N No Alcanzado 0% hasta el 15% del alcance
P Parcialmente Alcanzado >15% hasta el 50% del alcance
A Ampliamente Alcanzado >50% hasta el 85% del alcance
C Completamente Alcanzado >85% hasta el 100% del alcance
Tabla 2 - Calificación de los Atributos de Proceso de EvalProSoft, adaptado de [103, 88]
Por último, el nivel de capacidad que se alcanza es derivado de la calificación de la Tabla 2,
para lo que se toma como referencia la Ilustración 11.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 25
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ilustración 11 - Calificación del Nivel de Capacidad del Proceso en EvalProSoft, adaptado de [103, 88]
Esto quiere decir que para alcanzar un nivel de capacidad n en un proceso se necesita cumplir
con los atributos del nivel n con una calificación de "Ampliamente Avanzado - A" y además
cumplir con los atributos de proceso del nivel n-1 con una calificación de "Completamente
Alcanzado - C" [88].
El proceso de Gestión de Procesos, en la categoría de Gestión define, implanta, controla y
mejora los procesos de la organización, por lo que el nivel de capacidad de los demás
procesos de la organización dependen del nivel de capacidad de éste proceso. Es por esto que
el nivel de madurez de capacidades de la organización se define como el nivel de capacidad
del proceso de Gestión de Procesos [88].
Categorías de Procesos
Para definir la estructura de este modelo se realizó un análisis de la estructura de las empresas
mexicanas desarrolladoras de software, en el que se concluyó que "en la mayoría de
empresas, incluso en las micro con menos de 10 personas, la alta dirección toma las
decisiones acerca del rumbo de los negocios, la dirección media es responsable del control de
recursos y proyectos, y el sector operacional desarrolla los proyectos" [91].
Teniendo en cuenta estos resultados, MoProSoft tiene 3 categorías: Alta Dirección, Gerencia,
y Operación que abarcan 9 procesos en total, como lo muestra la Ilustración 12:
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 26
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ilustración 12 - Estructura del Modelo de Referencia de Procesos del Modelo MoProSoft [90]
Patrón de Procesos
Es un esquema de elementos que describe la forma en que se documentan los procesos y está constituido por 3 partes: Definición
general del proceso, prácticas y guías de ajuste [90], en la Ilustración 13 se pueden observar éstos:
Esta es una característica que le da un distintivo a éste modelo; su objetivo principal es organizar las actividades de los ejecutivos de las PyMES introduciendo prácticas de
administración y de ingeniería de software modernas [107]. También dirige y recibe reportes de
la categoría de Gerencia [91] y se ha demostrado que el compromiso de las personas que caben
dentro de esta categoría juega un papel crucial en la implementación de un modelo de mejora
de procesos de software [107]. Contiene sólo un proceso: Gestión de Negocio.
Está alineada con las metas de negocio de la categoría de alta dirección; también con la
categoría de operación ya que provee elementos para el desempeño de procesos operacionales,
recibe y evalúa la información que dichos procesos generan, e informan a alta dirección acerca
de los resultados [91]. Contiene 3 procesos: Gestión de Procesos, Gestión de Proyectos, y
Gestión de Recursos. Esta última contiene 3 sub-procesos: Recursos Humanos y Ambiente de
trabajo, Bienes Servicios e Infraestructura, y Conocimiento de la Organización.
Dirige las prácticas de los proyectos de desarrollo y mantenimiento de software, se alinea con
la categoría de gerencia entregando reportes y productos de software generados [91]. Es
conformada por 2 procesos: Administración de Proyectos Específicos y Desarrollo y Mantenimiento de Software.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 27
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ilustración 13 - Patrón de Procesos del Modelo MoProSoft [90]
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 28
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
CompetiSoft
En 2005 investigadores y practicantes reconocieron la importancia de un marco de mejora y
certificación para las MIPyMES, y se propuso CompetiSoft: Mejora de Procesos para
Fomentar la Competitividad de la Pequeña y Mediana Industria del Software de
Iberoamérica, como un modelo. Este se construyó sobre las prácticas de las iniciativas
latinoamericanas como MoProSoft y Brazilian Process Improvement Model; Métrica v3 de
España fue tenido en cuenta también [1]. Los requerimientos que debía cumplir CompetiSoft
fueron:
Fácil de entender
Fácil de aplicar
No costoso en su adopción
Ser la base para alcanzar evaluaciones exitosas con otros modelos o norma, tales
como ISO 9000 : 2000 o CMM v1.1
Su objetivo general es incrementar el nivel de competitividad de las PyMES Iberoamericanas
productoras de software mediante la creación y difusión de un marco metodológico común
que, ajustado a sus necesidades específicas, pueda llegar a ser la base sobre la que establecer
un mecanismo de evaluación y certificación de la industria del software reconocido en toda
Iberoamérica. Como objetivo específico relevante existe uno que nunca se había planteado en
un proyecto de éste tipo: "Definir la cultura de procesos mediante la formación de
investigadores, docentes y profesionales" [103].
Modelo de Capacidad de Procesos
La capacidad de un proceso se evalúa de 0 a 5, en donde cada número se asocia a un nivel al
igual que en el modelo MoProSoft (Ver Ilustración 9 - Características de los Niveles de
Capacidad del Modelo MoProSoft ).
La medición de capacidad se obtiene a través de un conjunto de Atributos de Proceso (AP),
los cuales se utilizan para determinar cuándo un proceso ha alcanzado una capacidad. Cada
atributo mide un aspecto particular de un proceso [103].
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 29
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Modelo de Evaluación
Este modelo de evaluación está basado en EvalProSoft, el modelo de evaluación de
MoProSoft, para más información diríjase a la página 23.
Categorías de Procesos
Éste modelo se puede ver como una evolución del modelo de referencias de procesos de
MoProSoft [91], pues su estructura es casi igual. La única diferencia es la existencia de 1
proceso más dentro de la categoría de Operación: Mantenimiento de Software, para un total
de 10 procesos. Las categorías de proceso siguen siendo las mismas: Alta dirección, gerencia
y operación; esto porque se asume que esa estructura general de las empresas mexicanas
desarrolladoras de software aplica a las organizaciones iberoamericanas.
Si se toman en cuenta la Ilustración 12 y la Ilustración 14 se notará que tal vez ni siquiera sea
"un proceso más" lo que se hizo con CompetiSoft, sino más bien la separación del proceso
"Desarrollo y Mantenimiento de Software" en "Desarrollo de Software" y "Mantenimiento de
Software", respectivamente.
Ilustración 14 - Categorías de Procesos del Modelo CompetiSoft [103]
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 30
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
A continuación, se describe el único proceso que diferencia al modelo de referencia de
procesos de CompetiSoft con el de MoProSoft:
Mantenimiento de Software
Tiene como objetivo llevar a cabo de forma ágil los cambios solicitados a un producto se
software de tal forma que no se pierda la consistencia, y que cumpla con las necesidades del
cliente [103]. Por eso se dice que es clave separar mantenimiento de desarrollo, ambos tienen
naturalezas y características diferentes tal vez este sea uno de los aportes más significativos
de CompetiSoft). Al separar el mantenimiento se hizo notorio que muchas técnicas,
herramientas y modelos de proceso, no son aplicables a éste [91].
Se desarrolló un proceso de mantenimiento adoptando técnicas de Scrum y Mantema, en las
que se divide este proceso en 2 niveles:
Básico
o Mantenimiento Urgente
o Mantenimiento No Urgente
o Mantenimiento Perfectivo
Avanzado
o Mantenimiento Adaptativo
o Mantenimiento Preventivo
Un ejemplo de estos niveles es: Una petición de modificación puede ser una solicitud de
cambio (perfectivo, adaptativo y preventivo) o un informe de problema correctivo urgente, o
no urgente.
Este proceso tiene varias ventajas:
Permite los cambios durante el camino, y considera una retroalimentación constante
con el cliente junto con una entrega rápida y periódica de atención a las peticiones de
mantenimiento que permita cumplir con los niveles de servicio solicitados.
Considera el mecanismo para recibir, alcanzar y dar seguimiento a las peticiones de
modificación. Las peticiones se atienden por grupos en ciclos, los cuales se clasifican
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 31
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
en planificable y no planificable. Cada ciclo es conocido como SprintM, que está
basada en Sprint de Scrum [103].
Patrón de Procesos
Este es casi igual al de MoProSoft (Ver Ilustración 13 - Patrón de Procesos del Modelo
MoProSoft ), con la diferencia que se excluyen algunos elementos. A continuación se
enuncian las diferencias entre los patrones de proceso de MoProSoft y CompetiSoft en cada
una de las partes de éstos: Definición general del proceso, prácticas y guías de ajuste [103]:
Definición General del Proceso: Se excluye el elemento ―Referencias Bibliográficas
(presente en MoProSoft).
Prácticas: Difiere del patrón de procesos de MoProSoft en que cambia el nombre de
"Roles Involucrados y Capacitación" a "Roles Involucrados y Competencias"; no
incluye "Incorporación a la Base del Conocimiento", "Capacitación", "Situaciones
Excepcionales" y "Lecciones Aprendidas".
Aportes Significativos
CompetiSoft presenta como aporte para las organizaciones que están iniciando su mejora de
procesos 2 cuestionarios de auto-asesoría:
Cuestionario de Autoevaluación de Procesos: Permite realizar una autoevaluación
de algunos procesos de CompetiSoft como:
o Gestión de Procesos
o Gestión de Recursos
o Gestión de Recursos Humanos
o Gestión de Recursos Bienes, Servicios e Infraestructura
o Desarrollo y Mantenimiento de Software
Tiene una serie de preguntas genéricas (identificadas por un color de acuerdo al nivel
de capacidad al que corresponde en el modelo), las posibles respuestas son cerradas
(SI/NO) [102]
Cuestionario de Administración de Proyectos Específicos: Aborda las 4 fases del
proceso de Administración de Proyectos Específicos: Planificación, Realización,
Evaluación y Control, y Cierre. Cada pregunta tiene asociada un conjunto de posibles
respuestas, abiertas o cerradas, en caso de cerrada debe ser única, cada respuesta
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 32
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
obtenida establece el camino a seguir en el cuestionario; cada pregunta corresponde a
un nivel de capacidad [102]
1.1.2. Ingeniería de Métodos
Los métodos describen un acercamiento sistemático a la solución de problemas, y un
problema está definido como una discrepancia entre un estado actual y uno deseado [10]. Sin
embargo, es ampliamente aceptado que un método universal que pueda ser usado para
cualquier situación sin ser modificado no es factible [19, 67, 64, 65].
La ingeniería de métodos es una disciplina de ingeniería para diseñar, construir y adaptar
métodos, técnicas y herramientas para el desarrollo de sistemas de información [15].
Los métodos apropiados para resolver determinados problemas deben ser seleccionados,
adaptados o diseñados dependiendo de las características específicas de una situación [10].
En la comunidad de la ingeniería de métodos el término que define esto es un método
situacional, que es una generación de un método específico para una situación particular
[15].Su enfoque es precisamente hacer los métodos genéricos aplicables a ciertos escenarios
[130].
Ya que es posible documentar métodos en forma de modelos, (podría pensarse en que el
método es la vista dinámica y el método es la vista estática un algo [10]); la afirmación de
que un método debe ser adaptado a las características especiales de una situación o contexto
es aplicable también a los modelos de referencia. Y de la misma forma, es posible afirmar
que la ingeniería de métodos abarca la adaptación de modelos a situaciones especiales.
Un modelo de referencia está definido como un modelo conceptual genérico que es útil
cuando se está desarrollando un modelo de información individual para una clase específica;
éste presenta formalmente el estado del arte y las mejores prácticas y se considera como un
ejemplo para un modelo corporativo [130, 41]. Por su naturaleza genérica, éstos necesitan ser
extendidos y/o configurados para ser adaptados en cualquier situación de aplicación [130].
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 33
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Looso [74] propone un método estructurado para aplicación de un modelo de referencia de
mejores prácticas (ITIL, COBIT, CMMI) y ya que los modelos de mejora de procesos de
software (MMPS) son modelos de referencia, éste es aplicable a este proyecto.
Este método propone una serie de actividades, cada una de ellas conlleva a resultados que son
modelos y se dividen en 2 dimensiones. La Ilustración 15 muestra éstas 2 dimensiones y sus
componentes:
Ilustración 15 - Dimensiones de los Resultados del Método Propuesto por [74]
La Ilustración 16 ofrece una vista general de los resultados del método propuesto por [74] y
sus dimensiones:
Ilustración 16 - Resultados del Método Propuesto por [74] y sus Dimensiones
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 34
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
En cuanto a la primera dimensión de la (Modelo y Meta-Modelo), para adaptar un modelo
de mejora de procesos de software (MMPS) a una compañía es posible realizar reducciones
de rango y de profundidad, siendo estas [74]:
Rango del Modelo: Componentes Meta-modelo
Profundidad del Modelo: Componentes del Modelo.
Cada una de estas reducciones dar origen a un sub-conjunto, como lo muestra la Ilustración
17:
Ilustración 17 - Tipos de Sub-conjuntos de Modelo según
En la Ilustración 16, Ilustración 17, e Ilustración 18 se presenta el término de meta-modelo.
Un meta-modelo es un modelo de un modelo, es decir, una abstracción de alto nivel de un
modelo [46]; para adaptar un MMPS es fundamental comprender primero el meta-modelo de
éste [46, 74].
La Ilustración 18 muestra el flujo de cadena de procesos orientada a eventos de éste método.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 35
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ilustración 18 - Cadena de procesos orientada a eventos del método propuesto por [74]
A continuación, se describirá cada proceso de la Ilustración 18:
En la comunidad mundial de ingeniería de software existen muchos Modelos de Mejora de
Procesos de Software (MMPS), entre los más conocidos están CMMI [121] y SPICE [128],
de modo que el primer paso debe ser seleccionar uno de éstos para adaptarlo a la
organización. Enseguida se deben realizar las reducciones de rango y de profundidad del
modelo seleccionado (cada una de éstas es opcional, no obstante, si no se hace ninguna de las
2 no se estaría realizando una adaptación del modelo seleccionado si no que se implementaría
tal y como es).
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 36
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Al seleccionar los componentes del meta-modelo que se adaptarán, se está haciendo una
reducción del rango del MMPS (ver Ilustración 17), y esta selección dará como resultado el
meta-modelo del modelo oficial de la compañía.
Los componentes del MMPS hacen alusión a los procesos como tal, esto implica que al hacer
una selección de los componentes del MMPS elegido que se desean adaptar, además de estar
realizando una reducción de la profundidad del modelo, se están seleccionando aquellos
procesos específicos en los que se desea mejorar, lo que dará como resultado el modelo
oficial de la compañía.
Puede suceder (y regularmente será así) que luego de lograr la mejora en un proceso
específico, se quiera continuar con dicha mejora en otro proceso (una nueva reducción de la
profundidad del MMPS original). En este caso, solo será necesario realizar esa nueva
reducción (seleccionar otro proceso), tal y como se muestra en la parte inferior de la
Ilustración 18.
1.1.3. Marco de Referencia “Forma De”
Una guía metodológica es más que una colección de actividades, entregables y técnicas.
Además contiene un ―espíritu‖, un paradigma que describe la forma de pensar plasmada en el
proyecto [6]. El funcionamiento de una guía metodológica puede ser descrito en términos de
―Way Of‖ [117, 116](en español ―Forma De‖); utilizando este marco de referencia es posible
caracterizar cada guía metodológica por su modo de pensamiento, modelamiento, conceptos,
administración y trabajo [81], en otras palabras, permite anatomizarla o estudiarla en sus
partes [94].
La Ilustración 19 muestra los ―Ways Of‖ o ―Formas De‖ con las que se puede describir y
representar una guía metodológica:
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 37
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ilustración 19 - Marco de Referencia Way Of. Adaptada de [94]
A continuación se presenta una breve descripción de cada componente del marco de
referencia Way Of (Forma De):
Way of Thinking – Forma de Pensar
Hace alusión a los lineamientos filosóficos detrás del método, plantea la perspectiva del
dominio del problema y hace explícitas las suposiciones y principios en los que se basa el
método [94, 6, 81, 31].
Way of Working – Forma de Trabajar
Define las tareas, incluyendo sub-tareas y su orden, a desarrollar como parte del proceso.
Provee lineamientos o guías y sugerencias de cómo éstas tareas deben ser realizadas [94, 31,
116].
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 38
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Way of Modelling – Forma de Modelar
Provee información de los conceptos de modelamiento, junto con sus relaciones y
propiedades. Estructura los modelos y provee un lenguaje para expresarlos [94, 31].
Way of Controlling – Forma de Controlar
Es el aspecto administrativo, busca determinar cómo se controla y se evalúa el proceso, por
ejemplo: el orden en que deben ser ejecutadas ciertas actividades [94, 6].
Way of Supporting – Forma de Soportar/Apoyar
Se refiere a las técnicas, herramientas y ayudas de trabajo que soportan la ejecución del
proceso, no necesariamente tienen que ser tecnológicas [94, 6].
2. Marco Contextual
2.1.1. Las MIPyMES_DS
¿Pueden las micro y pequeñas organizaciones aplicar las mismas técnicas de ingeniería de
software (aquellas que aplican las grandes organizaciones y que se encuentra en la literatura),
dadas sus características específicas y sus limitaciones? Este sigue siendo el debate [106]
hasta hoy en día.
Motivación de las MIPyMES_DS para implementar un Modelo de Mejora de Procesos
de Software
Las MIPyMES_DS están comprometidas a desarrollar un software con calidad y a enfocarse
en crear una cultura organizacional basada en la calidad [133]. Además, la reducción de
costes a medio-largo plazo, adoptando buenas prácticas de gestión de proyectos y de ciclo de
vida del software, así como la disminución de las tasas de error gracias a nuevas prácticas de
testing para minimizar los trabajos extra de garantía y mantenimiento [35] son beneficios
bastante llamativos de implementar un modelo de SPI. Sin embargo, el gancho y lo que
realmente motiva a las MIPyMES_DS es la competencia, ya sea con las grandes empresas de
desarrollo de software o con las de su misma categoría (competencia por clientes). La forma
más confiable que tiene una MIPyME_DS de mejorar su eficiencia y ser más productiva,
alcanzando así los niveles de calidad exigidos por el comercio exterior, es introducir un
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 39
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
modelo de calidad que se ajuste a las necesidades de la organización. Por ello, es necesario
aplicar un modelo de procesos que asegure obtener los niveles de calidad requeridos por el
mercado para ser eficiente, pero que por otro lado no resulte excesivamente burocrático, que
se convierta en gigantesco e inflexible, o que termine resultando muy costoso y desmotivador
para el equipo de desarrollo [113, 129].
¿Por qué apostarle al SPI en MIPyMES_DS?
Las organizaciones pequeñas difieren de las grandes en muchos factores, sin embargo aquí es
clave centrarse en lo que concierne a SPI, ya que esta requiere consideraciones especiales por
algunas restricciones tanto materiales como humanas [112]. A continuación se presentan las
ventajas y desventajas de las MIPyME_DS:
Ilustración 20 - Ventajas y Desventajas Competitivas de las MIPyMES_DS [106, 113, 106, 17, 35]
Desventajas Ventajas
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 40
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
2.1.2. Problemas de las MIPyMES_DS con Modelos de Mejora de Procesos
de Software Existentes
Enseguida, se profundiza en los problemas que presentan modelos como CMM [99] y CMMI
[121] a la hora de intentar adaptarlos a organizaciones pequeñas.
CMM
En general, los factores por los cuales CMM no es aplicable (sin ser modificado o adaptado) a
las MIPyMES_DS alrededor del mundo [16, 4, 23, 53] son:
Prácticas no aplicables a pequeños proyectos, que son los que prevalecen en las
pequeñas organizaciones [17, 23, 18, 96, 110, 129].
La existencia de 25 roles organizacionales, que en una MIPyME_DS no existen
porque no hay personal suficiente (y de hecho tampoco son necesarios tantos roles)
[72, 96].
Falta de recursos, disponibilidad de dinero, personal y tiempo [17, 110].
La estructura de administración que es implícita en CMM no coincide con la de las
organizaciones pequeñas, pues el administrador es en muchos casos responsable de
más de 1 proyecto, o puede tener responsabilidades tanto técnicas como
administrativas [17].
CMMI
Los problemas existentes con la versión anterior de este modelo no se solucionaron en esta
nueva. Los factores por los que CMMI no es aplicable las MIPyMES_DS [48, 51, 47, 35]
alrededor del mundo son:
Alto costo de evaluación de CMMI, incluyendo esfuerzo, tiempo y dinero [76, 52, 9,
39, 69, 91, 110, 132].
Falta de especificación en el modo en que las prácticas deberían implementarse
[108].
Demasiada exigencia y autoridad en el modelo [68, 109].
Requiere una forma distinta de pensar y que el personal haga otro tipo de tareas
diferentes al que está acostumbrado [72].
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 41
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Iniciativas tomadas para darle solución a los problemas
Desde inicios del siglo XXI la comunidad de Ingeniería de Software (industria e
investigadores) ha expresado un interés especial en la Mejora de Procesos de Software para
PyMES [104]. Como resultado de este creciente interés, se han desarrollado trabajos
específicamente enfocados en el problema de SPI para empresas pequeñas [3, 30, 126] y
algunos en particular sobre CMM/CMMI [51, 98, 16]. Estos trabajos intentan sortear las
dificultades de dos formas principalmente: o bien proponiendo un nuevo modelo basado en el
original pero más simple, o realizando una interpretación del modelo de forma que sea más
acorde al contexto de las empresas pequeñas [109], tales como CMM Dinámico [Laryd2000],
PRISMS [4], OWPL [3], LOGOS [18], RAPID, SPINI, MARES, SPIRE [106]. Sin embargo,
ninguna iniciativa ha logrado establecerse totalmente como estándar para las MIPyMES_DS,
solo en México MoProSoft [89] se estableció como norma nacional.
2.1.3. Características que debería tener un buen modelo de Mejora de
Procesos de Software para MIPyMES_DS
La Ilustración 21 muestra las necesidades que las MIPyMES_DS han establecido para que
sean incluidas con mayor prioridad en un modelo de SPI.
Ilustración 21 - Características que debería tener un bueno modelo de Mejora de Procesos de Software para
MIPyMES_DS [3, 17, 53, 4]
Entendibilidad Sencillez Bajo costo en su
aplicación
Estrecha relación con modelos de
calidad interncionales
Mayor detalle Inclusión de varios
ejemplos
Inclusión de plantillas
Adaptación del vocabulario a términos más entendibles
Alineación de los objetivos de negocio con áreas de proceso
a mejorar
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 42
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Cómo lograr el éxito
Muchos casos de programas de SPI presentan factores de éxito [11, 30, 39, 51] entre los que
están el compromiso de la alta gerencia, la adecuada documentación de los procesos, la
visibilidad de las mejoras realizadas por parte de toda la organización [109], uso de métricas
y revisión a nivel gerencial [47] y uso de diversidad y creatividad de recursos humanos
involucrados en proyectos de software [40].
¡La cultura importa!
Las diferencias culturales juegan un rol fundamental en el éxito de la mejora de los procesos
de software [39, 91], y a menos que el proyecto de implantación de un modelo de SPI
considere la brecha cultural, la posibilidad de obtener grandes resultados es mínima [111], ya
que la organización rechazará un proceso si éste no es acorde con su cultura, de la misma
forma en que el cuerpo humano no aceptará un trasplante de un órgano no compatible [132,
91]. Es por esto que es necesario ampliar el conocimiento en este ámbito y profundizar en la
importancia que ésta tiene en la implantación de un modelo de mejora de procesos de
software.
2.1.4. Cultura Organizacional
"La cultura de una organización es una estructura cognitiva y social. Sus miembros
comparten creencias y entendimientos, basados en valores comunes y un cuerpo de
conocimiento compartido que guía sus acciones" [79].
La cultura organizacional puede ser vista en términos del modelo de Schein [114], que
manifiesta 3 niveles:
Artefactos: Estructuras y procesos organizacionales visibles (resultados tangibles de
las actividades).
Creencias y Valores: Principios sociales, estrategias, filosofías, estándares, y metas.
Éstos tienen un valor intrínseco.
Supuestos: Aquellas cosas que se dan por sentado, percepciones y pensamientos.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 43
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Importancia de la Cultura Organizacional en la Implantación de un Modelo de Mejora
de Procesos de Software
La investigación en cuanto al tema de la cultura y SPI la señala como un factor que influencia
la adopción e implementación de éste [82, 83], ya que cada organización tiene una cultura
intrínseca y arraigada a través del tiempo, por lo que una implementación de procesos de
mejora de software puede impactar de una forma imprevista la sinergia que ya estaba
arraigada en una u otra organización [5]. Además, la mejora de procesos de software (SPI)
involucra cambios organizacionales complejos de prácticas de ingeniería y administración
[84], sobre todo en:
Planificación de proyectos
Control de calidad en los procesos básicos de la organización
Reestructuración de grupos de trabajo
Cambios de roles y responsabilidades
Gestión de nuevas capacidades y conocimiento tecnológico.
Debido a esto se pueden presentar diferentes reacciones en las personas que la conforman,
principalmente por el rechazo al cambio y a la mejora por el miedo a perder el empleo [80].
Desde el principio se deben buscar los focos de resistencia y proceder de manera cautelosa,
conversando y mostrando que no existen razones para estar confusos o asustarse [111].
Es aún más recomendable realizar un modelo de la cultura organizacional de la organización
en la que se planea implantar el modelo de SPI; esta solución es poco popular y esto se debe a
que los estudios relacionados con dinámicas sociales tienen poca precisión percibida pero, sin
estos estudios es muy poco probable que se logre entender la cultura organizacional. Por esto
es necesario incorporar en la implantación de SPI aspectos de la cultura de la organización
donde se implementará, basados en la idea de que la cultura de una organización determina lo
que se podrá y no se podrá realizar cuando se plantean los cambios [42].
En lo que concierne a cultura, se han planteado los factores de éxito y fracaso que afectan a la
implantación de un modelo SPI, como lo muestra la Ilustración 22:
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 44
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ilustración 22 - Factores de Éxito y Fracaso que Afectan a la Implantación de un modelo SPI [37, 38, 131,
101, 86, 43]
Como se menciona en la primera atribución al fracaso de la implantación de SPI, la cultura
que proponen los modelos de mejora de procesos (SPI) es implícita, por esto se propone que
éstos puedan promover una cultura propia que sea más explícita [12].
CMM-CMMI y la Cultura Organizacional
Cuando se inicia la implementación de un proceso de mejoras basado en alguno de los
modelos CMM/CMMI, los cambios propiciados por el modelo deben ocurrir en tantas
dimensiones de la organización que seguramente se producirá un choque con su cultura [42,
82].
La cantidad de fracasos en la implementación de CMM es muy alta, llegando al 70% [42].
Varias investigaciones han mostrado que buena parte de este porcentaje se debe a que el
modelo no contempla los aspectos sociales ni antropológicos de las organizaciones que
intentan llevar a cabo un proceso de mejoras [86, 5], por esto debe ser complementado con
teorías sociales [87].
•Un alineamiento entre los valores del modelo de mejora de procesos y la cultura organizacional
•La cultura administrativa
•Una cultura organizacional que promueva la satisfacción de los empleados
•La adaptación cultural de los modelos de mejora de procesos de construcción de software
Éxito
•Una falta de alineamiento entre la cultura organizacional y la cultura (aunque implícita) de los modelos de mejora de procesos
•La habilidad de una cultura de reproducirse por sí misma y la resistencia al cambio
Fracaso
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 45
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
2.1.5. Contexto Latinoamericano
SPI en Latinoamérica
Las PyMES Latinoamericanas emplean la mayor parte de los recursos laborales de sus países
[36], es el caso de México, en donde éstas representan el 80% de las compañías [55].
Por muchos años la producción de software en Latinoamérica se ha hecho de una forma
artesanal en vez de una industrial o ingenieril. Sólo hasta hace unos años las compañías
consideraron los métodos de ingeniería de software siendo sus metas principales el desarrollo
de software de calidad y un aseguramiento de la misma. Sin embargo, la implementación
exitosa de modelos como CMM, SPICE o ISO 9000 generalmente no es posible dentro del
contexto de PyMES desarrolladoras de software en Latinoamérica por factores como el
impacto cultural, pues factores culturales como la resistencia al cambio por parte de los
empleados y las áreas administrativas hacen que sea más difícil para las pequeñas
organizaciones implementar dichos modelos [55].
Cultura Organizacional de PyMES_DS Latinoamericanas
Las PyMES tienen características comunes (que se encuentran dentro de un contexto legal,
cultural y estructural) en toda Latinoamérica. En la gran mayoría de estas existe un patrón:
Centran en poca gente las diferentes actividades de negocios y tienen flexibilidad en los roles
que ejerce el personal [36]. Este patrón se evidencia en la Ilustración 23:
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 46
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ilustración 23 - Patrón de las PyMES Latinoamericanas [36]
Contexto Colombiano
En Colombia se distinguen 4 tipos de empresas relacionadas con tecnologías de información:
Desarrolladoras de Software
Comercializadoras y distribuidoras de productos informáticos
Proveedoras de accesos y servicios de Internet
Productos de Hardware
Según la naturaleza del negocio del software, es posible para una economía como la
colombiana emerger como un país exportador. Los referentes mundiales así lo demuestran,
pues tal industria no está limitada únicamente para los países de gran poderío económico
[97]. En particular, el interés para este proyecto se centra en la industria del desarrollo de
software, que tiene peso económico para Colombia [97].
SPI en Colombia
Las compañías Colombianas están más interesadas en la implementación de disciplinas
relacionadas con mejora en procesos de ingeniería (requerimientos, análisis y diseño,
construcción de software y pruebas). Están menos interesadas en disciplinas relacionadas con
mejora en procesos de administración (planeación, seguimiento y control) y procesos de
soporte (aseguramiento de calidad, administración de configuración y de requerimientos
[104].
La falta de formalidad en las relaciones y
roles entre los individuos que
interactúan entre sí.
Falta de formalidad en el desarrollo de
software.
Flujo de trabajo flexible regido por las
necesidades del momento.
Su estructura plana de organización.
Máximo 2 o 3 niveles de jerarquía
Roles intercambibles (funciones informales)
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 47
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Cultura Organizacional en Colombia
En Colombia existen tres niveles de empresas: En el primero se hace lo más básico (contratar
gente, pagar y despedir) poco se preocupan por formación, evaluación, proyección de
carreras, la mayoría de empresas colombianas se encuentran aquí. Hay un segundo nivel que
además de hacer lo básico bien se preocupan, por ejemplo, por conseguir talentos (capacidad
y competencia) que se necesita para hacer las tareas. Y un tercer grupo, que son las más pocas
firmas, han entendido que se debe construir un tejido social donde la gente dentro de la
organización se vuelve muy importante y se considera que a partir de ésta se consigue ventaja
competitiva [25]. Las macro-tendencias de las empresas en Colombia en cuanto a cultura
organizacional se presentan en la Ilustración 24:
Ilustración 24 - Macro-tendencias en Cultura Organizacional de las empresas Colombianas [78]
Hay que resaltar que estas macro-tendencias pertenecen a las empresas colombianas en
general, no se concentran en el nicho de las PyMES y mucho menos de las MIPyMES_DS,
ya que no existen muchos estudios de la cultura organizacional en ellas. En el 2007 fue
• La ejecución y los resultados en la toma de decisiones se hacen por parte de los directivos, el ejercicio de la autoridad se fundamenta en la estructura jerárquica de los jefes.
• La organización tiene claramente definidos sus objetivos estratégicos.
Racionalización de la estructura y su
dinámica
• El liderazgo que existe está basado en una buena comunicación, equidad y delegación de las tareas donde cada uno asume sus responsabilidades y su desempeño es orientado por el líder.
Liderazgo orientado a resultados
• Las personas no están satisfechas con el horario, las condiciones de trabajo y la poca estabilidad laboral, afectando el rendimiento y cumplimiento de los objetivos. Los programas de capacitación no satisfacen sus necesidades personales, ni laborales, produciendo baja motivación e insuficiente identidad con la organización
Insuficiente identidad con la organización
• La organización es consciente de la importancia de la tecnología e innovación en los procesos para que éstos sean más eficientes y se puedan alcanzar los objetivos estratégicos.
Orientación al cambio para la eficiencia
• Existe poca comunicación entre jefe y empleados, no se refleja el trabajo en equipo; lo que hace que los empleados tengan poca participación en actividades sociales y culturales. El salario es el factor motivador, no existe reconocimiento por su trabajo.
Limitación de política de desarrollo humano
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 48
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
publicado uno [123], en el que se analizaron 4 empresas medianas y 69 pequeñas en la ciudad
Bogotá y se evidenció lo siguiente:
Ilustración 25 - Análisis de 4 Empresas Medianas y 69 Pequeñas en Bogotá [123]
Lo anterior evidencia que incluso dentro de un mismo país las diferencias culturales entre las
grandes empresas y las PyMES existen, pues éstas últimas tienen características únicas y
diferenciadoras (sin importar al país al que pertenezcan), tal y como se evidencia en la
Ilustración 20 - Ventajas y Desventajas Competitivas de las MIPyMES_DS .
III – DESARROLLO DEL TRABAJO
Como se mencionó en la Sección 2.5 de I - DESCRIPCION GENERAL DEL TRABAJO DE
GRADO , el paradigma bajo el que se trabajó fue el de la investigación científica basada en el
diseño de sistemas de información que consiste en tres (3) ciclos: relevancia, diseño y rigor
[57, 56]. Éste paradigma busca crear artefactos (innovaciones), y en el caso de este proyecto,
el artefacto es un método instanciado basado en conceptos y modelos existentes (para mayor
información sobre éstos términos, ver Sección 2.5 Método que se Propuso para Satisfacer
cada Fase Metodológica).
Éstos 3 ciclos pueden ser vistos como engranajes, tal y como lo muestra la Ilustración 26.
Esto se debe a que cada vez que se modifique algo en un ciclo, algo se modificará o moverá
Cu
ltu
ra
Org
an
iza
cio
na
l P
yM
ES
Bogota
nas
La toma de decisiones es asignada usualmente a la junta directiva o personal directivo de las organizaciones,
dejando poca autonomía al personal técnico
Tienen alta informalidad en el manejo de la gestión de las empresas
Cuentan con instrumentos formales que soportan la estructura (manuales de procesos, funciones o
procedimientos) pero algunos están desactualizados
Se trabaja con estructura funcional
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 49
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
en el otro, es decir que todos se influencian entre ellos. Esto se evidenciará en la descripción
que se presenta a continuación de la forma en la que este proyecto se llevó a cabo.
Ilustración 26 - Vista de los 3 Ciclos de la ICBDSI
1. Ciclo de Rigor
Como se mencionó en las Secciones 2.5.1 y 2.5.2 de I - DESCRIPCION GENERAL DEL
TRABAJO DE GRADO, los entregables propuestos de este ciclo fueron 2, a continuación se
describe la realización de cada uno.
1.1. Documento con los aspectos más relevantes de los modelos de
mejora CMMI, MoProSoft y CompetiSoft
El objetivo al realizar una recolección de información acerca de éstos 3 modelos era
entenderlos por completo, para luego en el momento de tener los requerimientos específicos
de la MIPyME_DS del caso de estudio poderlos aplicar al diseño de la guía, es decir, el
artefacto en términos de la ciencia del diseño.
Para realizar este documento se consultaron como fuentes principales los documentos
oficiales en los que se describe cada modelo, a excepción del caso de CMMI precisamente
porque como se concluyó luego de realizar la investigación, es un modelo muy extenso, pero
Diseño
Relevancia
Rigor
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 50
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
también muy completo, y por esto su entendimiento consume bastante tiempo. Para esto, la
organización que lo desarrolló (SEI) ha realizado varios textos (que fueron consultados) para
―ayudar‖ a entenderlo e implementarlo de una forma mejor. Este modelo en particular tiene
las siguientes características:
Ha sido utilizado para guiar el desarrollo de software, un ejemplo es CMMI-DEV
V1.2 [2]
Es el modelo más conocido [76] y utilizado por compañías de software alrededor del
mundo [86]
Es el modelo más completo [2]
Se basa en las mejores prácticas [2]
Tiene aceptación internacional en la comunidad de ingeniería de software [2]
Es el referente principal para los programas de mejoramiento [109]
Los clientes tienen confianza en éste por su amplia descripción de buenas prácticas y
su trascendencia [2]
Luego de notar lo extensivo del modelo CMMI y del tiempo que toma entenderlo, se
concluye que ProSoftCol comparte algunos de los requerimientos o lo que eran las
características esperadas de MoProSoft, como [89]:
Específico para desarrollo y mantenimiento de software
Fácil de entender
Definido como conjunto de procesos
Práctico y fácil de aplicar, sobre todo en organizaciones pequeñas.
Orientado a mejorar los procesos para contribuir a los objetivos de negocio.
Tener claridad y lograr un entendimiento de MoProSoft fue útil para reducir un poco más el
marco de ProSoftCol, a saber qué se quería lograr y qué no específicamente, pues MoProSoft
está dirigido a pequeñas o medianas empresas o áreas internas de organizaciones muy
grandes de desarrollo y/o mantenimiento de software [107, 89]; ProSoftCol en cambio, es
dirigido especialmente a micro y pequeñas empresas de desarrollo de software; con esto no se
está dejando por fuera al sector de las organizaciones medianas, simplemente se hace mayor
énfasis en las micro y pequeñas porque en Colombia existen organizaciones medianas que
han obtenido una valoración significativa en CMMI, lo que evidencia que tal vez éstas no
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 51
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
tengan tantos inconvenientes con la implementación de éste modelo, como si los tienen las
micro y pequeñas empresas.
Lo más rescatable de esta iteración del ciclo de rigor es que se logró realizar una
identificación con una organización X que algún día decide mejorar sus procesos y
documentarse al respecto. Probablemente ésta organización acudiría a CMMI (por las
características mencionadas anteriormente) pero surgirían muchos interrogantes, dudas y
sería necesaria una gran inversión de tiempo para entender el modelo y más aún para tener
una idea de cómo aplicarlo a la organización. Mientras se realizaba la investigación, la
pregunta constante fue: ¿Cómo aplicar todo esto a una MIPyME_DS colombiana? De modo
que las preguntas que surgieron en el camino serían las mismas que dicha organización X se
haría, y la respuesta o guía para resolverlas será el aporte del artefacto: ProSoftCol.
El grado de complejidad de la realización de este entregable fue elevado, pues al iniciar con
CMMI no estaba claro de qué forma explicar la estructura del modelo: ¿explicar qué es un
área de proceso primero y luego las 2 representaciones? o ¿al revés? Sin embargo, el grado de
complejidad fue bajando y mucho, tan sólo en el modelo MoProSoft, ya que éste es mucho
más claro en su estructura y sólo tiene una representación, no 2 como CMMI. Lo que más
ayudó en su comprensión fue la asimilación con la estructura de una empresa para definir las
categorías de procesos y dentro de ellas cada proceso. Comprender CompetiSoft no fue para
nada difícil, teniendo en cuenta que es casi igual a MoProSoft en su estructura, solo que
enfatiza más en algunos aspectos como el mantenimiento de software y métricas. Tomar
dichas categorías (Alta Dirección - Gerencia - Operación) puede llegar a ser muy útil para el
entendimiento de un modelo. Sin embargo, a pesar de que se han realizado algunas
implementaciones de CompetiSoft en PyMES Iberoamericanas [1], es claro que el objetivo de
este proyecto no se ha cumplido; las razones son desconocidas, pero la hipótesis es que hace
falta algo más, algo como una guía más cercana a cada tipo de organización.
El resultado de esta iteración se encuentra en el Anexo: 2 - Conocimiento Aplicable a
ProSoftCol – Entregable 1 Ciclo Rigor.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 52
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
1.2. Documento con características de la cultura organizacional
colombiana
La realización de éste documento estuvo más centrada desde un principio en justificar de una
forma más profunda la necesidad del artefacto a diseñar: ProSoftCol. Para esto fue necesario
consultar múltiples fuentes, en su gran mayoría artículos científicos que respaldaran de
distintas formas la hipótesis de este proyecto: ―es necesario tener en cuenta los factores de
cultura y tamaño de las organizaciones para que la implementación de un modelo de mejora
de procesos de software (MMPS) sea exitosa‖. El resultado de esta investigación se encuentra
contenido en su gran mayoría en la Sección 2 Marco Contextual de II - MARCO TEÓRICO.
La Ilustración 27 muestra los tópicos investigados:
Ilustración 27 - Tópicos Contenidos en el Entregable # 2 del Proyecto
El resultado de esta iteración se encuentra en el Anexo: 3 - Análisis de la Cultura
Organizacional Colombiana – Entregable 2 Ciclo Rigor.
Importancia de las MIPyMES_DS
Problemas de las MIPyMES_DS con
modelos de Mejora de Procesos de Software
existentes
Factores que influencian la
implantación de un modelo SPI
Cultura Organizacional Cultura Organizacional y su relación con SPI
Contexto Latinoamericano en
cuanto a SPI y Cultura Organizacional
Contexto Colombiano en cuanto a SPI y
Cultura Organizacional
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 53
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
2. Ciclo de Relevancia
Como se mencionó en la Sección 2.5.3 de I - DESCRIPCION GENERAL DEL TRABAJO
DE GRADO, el entregable para este ciclo fue uno, a continuación se describe su proceso de
realización:
2.1. Documento con los requerimientos específicos de una MIPyME_DS
Colombiana en cuanto a procesos de software de ésta
El primer paso fue la elección de la MIPyME_DS que iba a ser el caso de estudio del
proyecto fue la micro-empresa Bogotana Yettú Ltda. Esta elección fue en particular
provechosa para el proyecto, pues en esta organización la mayoría sus procesos de software
no son formales.
Para medir si en realidad existirá una mejora en uno o varios procesos, es necesario que la
organización defina cuáles son sus procesos actuales (formales o informales) para poder
identificar sus necesidades de mejora: este es el mejor punto de inicio especialmente para una
organización pequeña [55]. Por ello, desde el principio del proyecto (durante el ciclo de rigor)
empezaron a surgir las dudas de cómo hacer el diagnóstico, cómo obtener la ―foto‖ del estado
inicial de la organización. ¿Con un SCAMPI [120]? No, porque esto equivaldría casi a un
proyecto de consultoría para la organización cliente en términos de valorar sus capacidades
actuales de madurez; pero luego de la primera iteración del ciclo de rigor se obtuvo una
ayuda para resolver este interrogante: El Cuestionario de Administración de Proyectos
Específicos de CompetiSoft [103] (ver sección CompetiSoft, Aportes Significativos en II -
MARCO TEÓRICO), enmarcándolo no sólo en un proyecto específico sino generalmente en
los proyectos que ha llevado a cabo la organización. Esto porque el objetivo es mejorar un
proceso de software en específico, no de gestión de recursos humanos o de infraestructura de
la organización (como el Cuestionario de Autoevaluación de Procesos), y éste hace más
énfasis en el ciclo de vida de un proyecto de software.
Una vez obtenida la información necesaria, surgió el otro interrogante: ¿cómo representar los
requerimientos específicos? ¿Diagramas de actividad, secuencia, etc.? Tal vez, pero la idea es
representarlos de manera que la necesidad de mejora de procesos de desarrollo de software
sea más explícita (representar el problema). De modo que se opta por representarlos en
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 54
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
términos de algún modelo base (CMMI, MoProSoft, CompetiSoft), y ya que el cuestionario
pertenece al modelo CompetiSoft, se representaron en función de éste. A la hora de
representar los requerimientos específicos en términos de CompetiSoft se utilizó un ―plus‖
del cuestionario, cada pregunta hace relación a un Nivel de Capacidad del Proceso (0-
Incompleto,1-Realizado, 2-Gestionado, 3-Establecido, 4-Predecible, 5-Optimizado) donde el
valor 0 se asocia al nivel de capacidad más bajo y significa que no alcanza el propósito del
proceso; y el valor 5 se asocia al nivel de capacidad más alto y significa que se logran las
metas del negocio actuales y proyectadas a través de la optimización y mejora continua del
proceso. Dicha medición de capacidad se realiza mediante el modelo de evaluación:
EvalProSoft (ver sección Modelo de Evaluación, MoProSoft en II - MARCO TEÓRICO).
Por lo anterior, fue posible realizar un diagnóstico (aunque informal) del proceso
Administración de Proyectos Específicos en Yettú Ltda.
Adicionalmente, para cada fase que describe el Cuestionario de Administración de Proyectos
Específicos se realizó un mapa mental, en el que se especifica qué prácticas se llevan a cabo
en la organización y cuáles no.
En las sesiones de entrevistas con la organización se observaron varias características, como
por ejemplo que todo depende totalmente de las 2 cabezas de la organización. Esto hace que
Yettú Ltda. sea un caso representativo delas características comunes de una pequeña empresa
nueva, pero ¿cómo saber qué diferencia a una micro-empresa desarrolladora de software
Bogotana de una micro-empresa desarrolladora de software de Los Ángeles, California? Se
hizo evidente que era necesario buscar algo del contexto que fuera específico de Colombia: la
cultura organizacional.
La corriente cultural de la Metodología de los Sistemas Blandos (SSM) [27] permite realizar
un análisis de ésta, por medio de talleres y entrevistas con los miembros de la organización.
Además, para la ICBDSI es necesario enmarcar o dirigir las actividades de investigación a las
necesidades de negocio de la organización. Dicho enfoque o marco, se establece
considerando que [57, 56]:
Las organizaciones consisten en personas, procesos y tecnologías
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 55
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Las personas tienen roles, capacidades y características que los ayudan a percibir las
necesidades de negocio de la organización en la que se encuentran (o de la que hacen
parte).
Se deben evaluar las estrategias de negocio, estructura, procesos y cultura de la
organización.
Las necesidades de negocio se posicionan relativamente a la infraestructura
tecnológica existente en la organización.
Por estas razones, a este entregable se le añadieron 2 componentes: cultura organizacional y
tecnología, presentando de cada una de ellas su estado actual. Logrando así, modelar el estado
actual de la organización con los componentes que se muestran en la Ilustración 28:
Ilustración 28 - Componentes Modelado Estado Actual de una Organización Desarrolladora de Software
El resultado de esta iteración se encuentra en el Anexo: 4 Requerimientos Específicos de la
Micro-Empresa Yettú Ltda. - Entregable Ciclo Relevancia.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 56
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
3. Ciclo de Diseño
Este ciclo da como resultado el artefacto, para este proyecto la guía metodológica y su
instanciación en la organización del caso de estudio Yettú Ltda. Su desarrollo se explica a
continuación:
3.1. Modelo Específico Adaptado para MIPyME_DS Colombiana de la
cual se obtuvieron los requerimientos específicos
En este punto del proyecto, de acuerdo a lo planeado ya se tenía todo lo necesario empezar a
diseñar ProSoftCol. Sin embargo, surgió un nuevo interrogante, ¿cómo se construye una guía
metodológica? En la ICBDSI es común utilizar ingeniería de métodos cuando el resultado del
diseño o artefacto es un método o un modelo; y como se mencionó anteriormente, ProSoftCol
es un método (ya que no se cambia el modelo, pero si su implementación dentro de un
contexto particular) basado en conceptos y modelos existentes.
Además, como se mencionó en la Sección 1.1 (Documento con los aspectos más relevantes de
los modelos de mejora CMMI, MoProSoft y CompetiSoft), el proceso vivido (acciones
realizadas) a lo largo de los ciclos de rigor, relevancia y diseño era lo que se debía plasmar en
la guía metodológica. Esto se intentó realizar con casos de uso, pero no fue posible porque no
hay un sistema que interactúe directamente con el actor (en este caso la persona que realiza la
guía), o que brinde alguna ―respuesta‖.
Es aquí donde se evidencia la afirmación anterior de que los ciclos de la ICBDSI son como
engranajes, pues al moverse hacia el ciclo de diseño fue necesario moverse de nuevo en el
ciclo de rigor, y se realizó una segunda iteración del ciclo de rigor para encontrar una forma
en la que se pudiera tanto diseñar el método (o guía metodológica) como representarlo. El
resultado de esta iteración no fue un entregable formal, pero se puede visualizar en este
documento en las Secciones de II - MARCO TEÓRICO: 1.1.2 Ingeniería de Métodos y 1.1.3
Marco de Referencia ―Forma De‖.
En la sección 1.1.2 se presentó un método para la aplicación de modelos de referencia de
mejores prácticas, propuesto por [74] y que sugiere qué hacer para aplicar un MMPS a una
organización más no especifica cómo hacerlo.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 57
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Después de analizar este método y compararlo con lo que se pretendía lograr luego de diseñar
el artefacto, se concluyó que era necesario indicar ese ―cómo‖ y que ya se contaba con la
forma de hacerlo: teniendo en cuenta el estado actual de la organización en cuanto a procesos
de software, cultura organizacional y tecnología. Para estos componentes (procesos de
software, cultura organizacional y tecnología) en los ciclos de rigor y relevancia se realizaron
2 actividades: Identificar y Representar su estado actual.
Se propone entonces que con base en los resultados de estas 2 actividades se proceda a
aplicar el método propuesto por [74]. ¿Y dónde está el cómo? Precisamente la actividad o
fase de Adaptar un MMPS debe hacerse a la par con un Análisis de los resultados de
Identificar y Representar. Esto se denominó como el proceso IRAA, y se muestra en la
Ilustración 29:
Ilustración 29 - Flujo del Proceso IRAA
La Ilustración 30 muestra el mapeo del proceso IRAA con los componentes mencionados
anteriormente, y a la vez, el lugar que toman dentro de la guía las actividades del método
propuesto por [74]:
I •Identificar
R •Representar
A-A •Analizar Adaptar
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 58
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ilustración 30 - Estructura Guía Metodológica
En este punto del ciclo, ya se sabía cómo diseñar la guía, quedaba un interrogante: ¿Cómo describirla? En la Sección 1.1.3 se presentó
el Marco de Referencia ―Forma De‖, que permite anatomizar una guía metodológica o estudiarla en sus partes [94]. ProSoftCol fue
descrita y representada utilizando este marco de referencia.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 59
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Como se mencionó en la sección 1.1.2 de II - MARCO TEÓRICO, es posible documentar
métodos o guías metodológicas en forma de modelos [10]. La guía metodológica es la vista
dinámica y el método es la vista estática de la adaptación de modelos de mejora de procesos
de software a MIPyMES_DS colombianas. Por esta razón, se propuso un meta-modelo, es
decir, un modelo de la guía metodológica, que la define y la especifica como un conjunto de
ciertos componentes, en como lo muestra la Ilustración 31:
Ilustración 31 - Meta-modelo ProSoftCol
La relación entre el meta-modelo de la guía y el marco de referencia de ―Forma De‖ se
muestra en la Ilustración 32.
La Forma de Pensar y la Forma de Modelar de un método están muy ligadas, pues éstas
determinan qué es lo que será modelado [94]. Es por esto que la Forma de Pensar enmarca a
la guía metodológica y está fuera del meta-modelo, y la Forma de Modelar es el lenguaje
utilizado para generar el modelo del estado actual de una organización. En pocas palabras, la
Forma de Pensar de esta guía es que es necesario tener en cuenta los factores especiales de las
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 60
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
MIPyMES_DS Colombianas (tamaño, cultura, recursos) para lograr implantar un modelo de
mejora de procesos existente, de modo que aquello que debe modelarse son los factores
especiales de la organización y su estado actual .
Ilustración 32 – Relación entre el Meta-Modelo de ProSoftCol y el Marco de Referencia Forma De
Para modelar esto se establecen unos Objetivos medidos por Indicadores (Forma de
Controlar), dichos objetivos son cumplidos o alcanzados por medio de la realización de
ciertas Actividades (Forma de Trabajar), que a la vez están compuestas de otras Actividades,
que pueden ser llamadas Tareas o Sub-Actividades, cuya realización es soportada por uno o
más Recursos (Forma de Soportar) y genera uno o más Resultados. Cada Resultado
corresponderá a una Forma de Modelar y será una porción de aquello que se modelará
(factores especiales de la organización y su estado actual). Para el caso particular de esta guía
metodológica, los Indicadores (Forma de Controlar) son los productos de trabajo de cada
actividad o sub-actividad, esto porque un modelo tan mundialmente aceptado como lo es
CMMI [121] mide el logro de sus metas de ésta forma.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 61
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Como el artefacto de diseño además debe ser instanciado, la guía presenta el caso ilustrativo
de su uso en la microempresa Yettú Ltda. evidenciando la ejecución de cada actividad de la
Ilustración 30 en ésta organización.
Finalmente, el resultado de la implementación de la guía es un modelo adaptado
especialmente a Yettú Ltda. del modelo seleccionado para este caso: CMMI [121] , luego de
una reducción de su rango y de su profundidad, como lo muestra la Ilustración 33:
Ilustración 33 - Modelo Adaptado para Yettú Ltda
La reducción de la profundidad dio como resultado el proceso de Administración de la
Configuración para iniciar la mejora, y la reducción del rango dio como resultado la
satisfacción de uno de los requerimientos de la Ilustración 21 - Características que debería
tener un bueno modelo de Mejora de Procesos de Software para MIPyMES_DS : Adaptación
del vocabulario a términos más entendibles. Planteando un meta-modelo adaptado de CMMI
con términos más claros (aquellos con los que se define el modelo de ciclo de vida del
software), teniendo en cuenta que las organizaciones que están adaptando el modelo son
desarrolladoras de software, por lo que estarán más que familiarizadas con éste modelo.
Este documento indica además cuáles tareas y actividades de las requeridas y sugeridas por
CMMI se llevan a cabo en la organización, y sugiere una forma de realizar aquellas que
Reducción Profundidad
CMMI
Reducción Rango CMMI
Modelo de Administración de la Configuración para Yettú Ltda.
adaptado de CMMI
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 62
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
todavía no se llevan a cabo haciendo alusión a los requerimientos específicos que fueron
levantas para la organización, como lo muestra la Ilustración 34:
Ilustración 34 - Símbolos para Describir el Estado de una Tarea o Producto de Trabajo en Yettú Ltda.
La guía metodológica se encuentra en el Anexo 5: Guía Metodológica – Entregable 1 Ciclo
Diseño; y su instanciación en Yettú Ltda en el Anexo: 6 Documento de Administración de
Configuración.
IV –REFLEXIÓN METODOLÓGICA
El paradigma bajo el que se trabajó ICBDSI [57, 56] fue totalmente benéfico para la
realización del trabajo de grado. No obstante, querer ofrecer todos los resultados que deberían
surgir de un proyecto realizado bajo dicho paradigma fue ambicioso. Por ejemplo, en
principio se quiso generar una teoría de diseño, pues el atributo distintivo del diseño y la
acción es que se enfocan en ―cómo hacer algo‖: cómo diseñar y desarrollar un artefacto [63];
pero dada la limitante de tiempo no fue posible generarla.
De las 15 actividades propuestas a realizar, se llevaron a cabo 14. La actividad faltante fue
―Elaboración de un documento con puntos débiles y fuertes de ProSoftCol. Los débiles deben
encontrarse en forma de nuevos requerimientos‖, que corresponde al séptimo objetivo
específico (ver sección 2.5.7 Refinar el modelo propuesto, a partir de los resultados de la
validación del mismo en I - DESCRIPCION GENERAL DEL TRABAJO DE GRADO). Esto
porque esta actividad se está realizando en este documento, al reflejar los resultados tanto de
la evaluación como de la validación y al reflexionar acerca de ellos (ver sección 1
Conclusiones en VI – CONCLUSIONES, RECOMENDACIONES Y TRABAJOS
FUTUROS).
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 63
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Adicionalmente, la guía y su instanciación serán refinadas en el momento en que sean
sometida a evaluación por parte de los jurados y éstos realicen comentarios y/o sugerencias
para mejorarlas.
V - RESULTADOS Y REFLEXIÓN SOBRE LOS MISMOS
En esta sección se presentarán primero los resultados de la validación de la utilidad potencial
de la guía y de su instanciación, seguida de los resultados de la evaluación de un experto
acerca de la completitud y la consistencia interna de la guía y por último, con base en ellos se
presentarán los resultados obtenidos de la realización de éste trabajo de grado.
1. Validación de la Utilidad Potencial de la Guía
Tal y como se mencionó en la Sección 2.5.6 de I - DESCRIPCION GENERAL DEL
TRABAJO DE GRADO, esta medición se realizó utilizando el Modelo de Aceptación de la
Tecnología TAM [32]. Este modelo es una teoría de los sistemas de información que modela
cómo los usuarios llegan a aceptar y utilizar una tecnología, y sugiere que cuando a los
usuarios se les presenta una nueva tecnología, una serie de factores influyen en su decisión
sobre cómo y cuándo la van a utilizar, en particular:
Ilustración 35 - Factores más Importantes en la explicación del Uso de una Tecnología, según TAM [32]
Este modelo predice la aceptación tecnológica basándose en las dos variables presentadas
en la Ilustración 35: utilidad y facilidad de uso percibida, las cuales sirven de base para
determinar las actitudes enfocadas al uso del sistema. Estas 2 influencian la actitud hacia
• El grado en que una persona cree que el uso de un determinaro artefacto mejora su rendimiento en el trabajo
Utilidad Percibida
• El grado en que una persona cree que utilizando un artefacto en particular, podrá liberarse del esfuerzo que le convlleva realizar un trabajo
Facilidad de Uso Percibida
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 64
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
el uso del artefacto (AU), que a su vez influencia la intención de uso (IU), que
posteriormente influencian el uso actual del artefacto (UAA). La Ilustración 36 muestra
este modelo y la Ilustración 37 describe cada una de las afirmaciones de éste.
Ilustración 36 - Modelo de Aceptación de la Tecnología TAM [32]
TAM es una adaptación del modelo psicológico de la Teoría de la Acción Razonada (por sus
siglas en inglés) para el ámbito de la ingeniería de software, y puede ser utilizado para
evaluar o validar un artefacto que va a ser implementado [32]; este es un uso frecuente en las
investigaciones cuyo resultado es un artefacto o prototipo que requiere ser validado de alguna
forma, considerando que este artefacto no ha sido implementado todavía (como en la
ICBDSI).
En consecuencia, para este caso de la guía metodológica y su instanciación en la organización
del caso de uso, la utilidad potencial de éstos puede ser medida con TAM. Para ello se utilizó
el cuestionario que provee el modelo y además se solicitó a la organización su opinión de
ambos productos (la guía y su instanciación, es decir, el modelo de administración de la
configuración adaptado para Yettú Ltda luego se seguir todo el proceso propuesto por la
guía).
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 65
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ilustración 37 - Afirmaciones del Modelo de Aceptación Tecnológica TAM [32, 95]
La respuesta del cuestionario se encuentra en el Anexo 9: Cuestionario TAM – Entregable 2
Ciclo Diseño y la opinión de los directivos de la organización en el Anexo 10: Carta de
Validación de la Guía y su Instanciación, por Yettú Ltda.
El cuestionario resuelto demuestra que la Utilidad Percibida (UP) y la Facilidad de Uso
Percibida (FUP) de ProSoftCol por los directivos de la organización es bastante alta
(promedio de 6-7 en una escala de 1 a 7). La Ilustración 38 describe la Utilidad Percibida de
ProSoftCol y su instanciación por los directivos de Yettú Ltda:
A1. Las Variables Externas (VE) tendrán una influencia positiva en la Utilidad Percibida (UP)
A2. Las Variables Externas (VE) tendrán una influencia positiva en la Facilidad de Uso Percibida (FUP)
A3. La percepción de la Facilidad de Uso (FUP) tendrá una influencia positiva en la Utilidad Percibida
A4. La percepción de la Facilidad de Uso (FUP) tendrá una influencia positiva sobre la Actitud Hacia el Uso (AU).
A5. La Facilidad de Uso Percibida (FUP) del artefacto, tendrá una influencia positiva sobre la Actitud Hacia el Uso (AU)
A6. La Utilidad Percibida (UP) tendrá una influencia positiva sobre la Intención de Uso (IU)
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 66
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ilustración 38 - Utilidad Percibida de ProSoftCol y su Instanciación por los Directivos de Yettú Ltda.
La Ilustración 39 describe la Facilidad de Uso Percibida de ProSoftCol y su instanciación, por
los directivos de Yettú Ltda.
Ilustración 39 - Facilidad de Uso Percibida de ProSoftCol y su Instanciación por los Directivos de Yettú
Ltda
En cuanto al modelo adaptado, concuerdan en que CMMI es el MMPS ideal para adaptar a la
organización y en que tanto los requerimientos específicos levantados como la idea de utilizar
un Entorno de Desarrollo Colaborativo para satisfacerlos es excelente. Adicionalmente, se
afirma que es un modelo útil, fácil de entender y completo.
Uti
lid
ad
Perc
ibid
a (
UP
).
Usa
r P
roS
oft
Col
y s
u
inst
anci
ació
n e
n Y
ettú
(m
od
elo d
e A
dm
inis
trac
ión
de
la C
on
figu
raci
ón
)...
Ayudaría a los directivos de Yettú Ltda. hacer sus tareas más rápido
Mejoraría el desempeño del trabajo de los directivos de Yettú Ltda.
Incrementaría la productivdad de los directivos de Yettú Ltda.
Aumentaría la efectividad en el trabajo de los directivos de Yettú Ltda.
Facilitaría la realización del trabajo de los directivos de Yettú Ltda.
Sería útil para realizar el trabajo de los direcitvos de Yettú Ltda.
Faci
lid
ad
de
Uso
Per
cib
ida
(FU
P)
Aprender a utilizar ProSoftCol y su instanciación sería fácil para los directivos de Yettú Ltda.
La interacción con ProSoftCol y su instanciación sería clara y entendible para los directivos de Yettú Ltda.
Los directivos de Yettú Ltda encuentran a ProSoftCol y a su instanciación flexible para interactuar con ellos
Sería fácil para los directivos de Yettú Ltda ser expertos en el uso de ProSoftCol y su instanciación
Los directivos de Yettú Ltda encuentran a ProSoftCol y su instanciación fácil de usar
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 67
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
2. Evaluación de la Completitud y la Consistencia Interna por
parte de un Experto
La evaluación de la guía metodológica fue realizada por Maria Mercedes Corral Strassman,
Ingeniera de Sistemas y Computación de la Universidad de Los Andes; Maestría en
Comunicación de datos, University College London de la Universidad de Londres; PDD de
Inalde. Directora de Proyectos en el Banco de la República; consultora en Gerencia de
proyectos, desarrollo e implantación de sistemas en entidades del sector financiero y sector
gobierno; Gerente de TI de Asobancaria.. Profesora Universitaria en áreas de Ingeniería de
software y Gerencia de proyectos. Actualmente Consultora en Gerencia de Proyectos para
Gómez Project & Training y Profesor de la Universidad Javeriana.
Dicha evaluación estuvo enfocada en medir la completitud y la consistencia de la guía
metodológica y de su instanciación en Yettú Ltda. para ello se realizó un cuestionario que fue
respondido por Maria Mercedes que a la vez realizó una serie de comentarios y sugerencias
alrededor de éstos.
La Ilustración 40 presenta las afirmaciones referentes a la guía metodológica:
Ilustración 40 - Afirmaciones de la Evaluación de un Experto en cuanto a la Guía Metodológica
A continuación, la Ilustración 41 presenta las afirmaciones referentes a la relevancia y
utilidad de las actividades propuestas en la guía para la implantación de un MMPS en una
organización.
La problemática que pretende solucionar es relevante para la comunidad de ingeniería de software
Es relevante para la comunidad de ingeniería de software
Es fácil de entender
Es completa
Aporta una solución útil a la problemática
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 68
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ilustración 41 - Afirmaciones de la Evaluación de un Experto en cuánto a la Implantación de un MMPS en
una Organización Colombiana y aquello que se propone en la Guía Metodológica
La Ilustración 42 presenta las afirmaciones referentes a la validez de las soluciones
propuestas para la organización Yettú Ltda.
Ilustración 42 – Afirmaciones de la Evaluación de un Experto en Cuanto a la Validez de las Soluciones
Propuestas para la Organización Yettú Ltda.
Los comentarios y sugerencias que Maria Mercedes Corral realizó en torno al trabajo de
grado son:
Es relevante realizar una identificación y representación del estado actual de la organización en cuanto a procesos de software, cultura organizacional y tecnología e infraestructura
Es útil y relevante analizar el estado actual de la organización en cuanta procesos de software, cultura organizacional y tecnología e infraestructura para lograr adaptar un modelo de mejora de procesos a ésta
Es útil realizar un levantamiento de requerimientos específicos de procesos de software de la organización
Soluciones Propuestas para Yettú Ltda
Los requerimientos específicos levantados para la organización son relevantes y su satisfacción les ayudaría a lograr una mejora en sus procesos de software
La instanciación de la guía (documento de Administración de la Configuración para Yettú Ltda) es útil a la organización, fácil de entender y completo.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 69
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
―Una vez realizada la revisión de los documentos presentados se puede determinar que el
trabajo cumple a completitud las expectativas de un trabajo de grado por lo tanto según mi
criterio personal, el trabajo es aprobado.”
Algunos comentarios y recomendaciones adicionales a la guía pueden servir de complemento
al trabajo presentado:
El modelo de implementación – IRAA, presenta claridad y lineamientos alcanzables
por la organización donde se esté utilizando, se necesita es contar con el compromiso de la misma en realizar su mejora de procesos continuamente con el fin
de crecer en sus niveles de calidad en la construcción de software.
Es bien interesante como se define el meta modelo de ProColSoft y adicionalmente la
relación establecida entre el meta modelo y el marco de referencia. Es totalmente
claro y específico el logro de la mejora de proceso.
La guía propone que la estructura de una organización de desarrollo de software se
puede modelar con unos componentes básicos entre los cuales está la planeación
estratégica, sin embargo hay que considerar que este tipo de empresas por lo general no han tenido en su concepción un análisis de planeación estratégica, lo cual
obligaría a pensar en ayudar a realizar dicha planeación con el fin de llegar a un
modelo más robusto.
Igualmente puede suceder con los otros componentes adicionales, procesos de
software, infraestructura tecnológica y estructura organizacional, propuestos en la
estructura del modelo. Por lo tanto el pensar en una mejora de procesos de software, obliga a documentar y formalizar en general los procesos de la organización.
Un punto a considerar frente a la utilidad de la guía en el medio colombiano, es la revisión de las empresas de software en el rango de Mipymes que realmente tengan
dentro de sus objetivos y políticas buscar permanentemente una mejora de procesos
y que adicionalmente estén interesadas en lograr unos altos niveles de calidad de software que les permita competir en mercados nacionales e internacionales.
La competencia internacional a nivel de desarrollo de software hace que sea más
difícil lograr una penetración de mercado de las MiPymes_DS en Colombia y otras regiones. Los nichos de mercado a los cuales deben llegar estas organizaciones son
mercados de empresa pequeña que requieren de desarrollos de software agiles,
flexibles, portables, económicos, de calidad y es obvio que las empresas grandes no pueden ser las proveedoras de servicio de este nicho de mercado.
El mercado para estas MiPymes_DS busca contar con calidad en sus desarrollos de
software y en sus servicios, por lo cual el disponer de metodologías adaptadas al tamaño de la organización puede permitir fortalecer la relación con sus proveedores
de software, sin embargo los procesos deben ser muy ágiles en su implementación
debido al tiempo de exigencia que le presenta el mismo mercado.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 70
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Como conclusión, creo que es una necesidad de mercado para estas MiPymes_DS
Colombianas, tener un modelo de mejora de proceso que les permita robustecer su
servicio y que este modelo esté enmarcado en estándares internacionales adaptados al tamaño de la empresa, a la cultura y a las necesidades del medio en el cual se
están desarrollando.
El piloto realizado sobre la entidad Yettú, muestra de alguna manera la situación que se puede encontrar en varias organizaciones MiPymes_DS colombianas, lo cual
abre la posibilidad de emprender proyectos en temas de estrategia, procesos y
tecnología sobre este tipo de organizaciones, lo cual a la vez llevaría a establecer una mejora de procesos en varias ramas entre ellas construcción de software.
Dichas recomendaciones y sugerencias serán tenidas en cuenta para el trabajo futuro con la
guía metodológica (ver secciones 3.1 Implementación de la Guía en Yettú Ltda. y 3.2
Instanciación de la Guía en Otra Organización en VI – CONCLUSIONES,
RECOMENDACIONES Y TRABAJOS FUTUROS).
La respuesta del cuestionario se encuentra en el Anexo: 7 - Cuestionario Evaluación de un
Experto de la Completitud y Consistencia Interna de la Guía y las observaciones y
sugerencias en el Anexo 8 - Observaciones y Recomendaciones para la Guía por Parte del
Experto que realizó la evaluación.
3. Resultados
De acuerdo con la validación de la utilidad potencial y evaluación de la guía metodológica y
su instanciación, estos son los resultados obtenidos:
ProSoftCol cumple con los requerimientos que comparte con MoProSoft (ver sección
1.1 - Documento con los aspectos más relevantes de los modelos de mejora CMMI,
MoProSoft y CompetiSoft en III – DESARROLLO DEL TRABAJO), estos son:
o Fácil de entender
o Definido como conjunto de procesos
o Práctico y fácil de aplicar en organizaciones pequeñas
La instanciación de la guía (Anexo 6- Documento de Administración de
Configuración – Entregable 1 Ciclo Diseño) satisface algunas de las necesidades que
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 71
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
las MIPyMES_DS han establecido para que sean incluidas con mayor prioridad en un
MMPS. Éstas son:
o Entendibilidad [3]
o Bajo costo en su aplicación [3], pues el proceso elegido a mejorar es barato
de soportar tecnológicamente por la infraestructura de Yettú Ltda. porque ya
cuentan con un Sistema de Control de Versiones (SVN) en un repositorio,
dependiendo del sistema operativo de cada equipo (ver Anexo 5 - Guía
Metodológica – Entregable 1 Ciclo Diseño).
o Tener estrecha relación con los modelos de calidad internacionales [3], pues
es una adaptación del modelo CMMI [121]
o Adaptación del vocabulario a términos más entendibles [53], pues su meta-
modelo es descrito con aquellos componentes con los que se define el
modelo de ciclo de vida del software), teniendo en cuenta que las
organizaciones que están adaptando el modelo son desarrolladoras de
software, por lo que estarán más que familiarizadas con éste modelo.
ProSoftCol ayudaría a las MIPyMES_DS colombianas a navegar el proceso de la
elección de ―por dónde empezar‖ una mejora de procesos de software, de una forma
adaptada a sus condiciones, especificando qué hacer y cómo hacerlo.
VI – CONCLUSIONES, RECOMENDACIONES Y TRABAJOS
FUTUROS
1. Conclusiones
Existen 3 justificaciones sólidas (y de distintas áreas del conocimiento) para adaptar
un MMPS al contexto colombiano: La primera es la diferencia entre el tamaño y la
cultura de los modelos existentes y el tamaño de las empresas que dominan el
mercado de software nacional y su cultura. La segunda es que desde el punto de vista
de la sociología, los marcos de referencia como obra de humanos, se inspiran y
fundamentan en contextos geográficos concretos, por lo que la aplicación de éstos sin
tener en cuenta las influencias inestabilizadoras que se pueden presentar debido a que
ninguna organización es inmune a su entorno, puede conducir a graves errores [14].
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 72
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Y la tercera, desde el punto de vista de la ingeniería de métodos, es la afirmación de
que un método universal que pueda ser usado para cualquier situación sin ser
modificado no es factible [19, 67, 64, 65]; por el contrario, los métodos apropiados
para resolver determinados problemas deben ser seleccionados, adaptados o
diseñados dependiendo de las características específicas de una situación [10].
ProSoftCol, como guía metodológica que soporta la adaptación de un MMPS a las
MIPyMES_DS colombianas teniendo en cuenta sus características especiales, en
particular tamaño y cultura, presenta un aporte relevante a la solución de la
problemática de que el uso de los MMPS existentes por parte de las MIPyMES_DS
colombianas es limitado y complejo principalmente porque estos fueron creados
pensando en organizaciones de gran tamaño y de culturas diferentes con la (Norte-
Americana y Europea) [69, 91].
El interés por la mejora de procesos de construcción de software en PyMES
latinoamericanas ha aumentado en los últimos años. Esta es la razón de la existencia
de modelos como CompetiSoft [103], y de la realización de proyectos de asesoría en
la implementación del modelo CMMI-DEV a PyMES_DS colombianas, por parte de
la Red Colombiana de Calidad de Software [125]. Sin embargo, sigue siendo un
―asunto sin resolver‖ ya que hasta hoy en día no existe un modelo estándar específico
para MIPyMES_DS Latinoamericanas que tenga aceptación y reconocimiento
mundial y tampoco un método aplicable a todas las MIPyMES_DS para que éstas
puedan adaptar los MMPS existentes.
Utilizar el marco de referencia ―Forma De‖ [117, 116] para describir y representar
una guía metodológica facilita tanto su realización como su comprensión.
La ingeniería de métodos [15] juega un papel fundamental en la adaptación de los
modelos de mejora de procesos de software, ya que su enfoque es precisamente hacer
los métodos genéricos aplicables a ciertos escenarios [130], y un método puede ser
documentado en forma de modelo [10].
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 73
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
La identificación de los meta-modelos de los MMPS existentes facilitan su
entendimiento y por ende la comparación entre éstos, lo cual es clave a la hora de
adaptar un MMPS a una organización de un contexto específico.
Tal y como se había supuesto desde el incio del proyecto, existe la posibilidad de que
en la instanciación de la guía se encuentre una organización que no tenga claros su
planeación estratégica definida. En un principio se planteó como algo bueno para este
trabajo de grado, pues se podría pensar en una actividad, proceso, o método que
ayude a las organizaciones colombianas a definir estos aspectos; y como lo reveló la
evaluación del experto, es necesario brindar soporte para que las organizaciones
desarrolladoras de software definan su planeación estratégica, no es algo que se
pueda asumir que todas tienen (como se hizo en la guía metodológica).
Representar el estado actual de una organización en cuanto a procesos de software,
cultura organizacional y tecnología e infraestructura es útil para adaptar un MMPS a
ésta, pues proporciona una serie de criterios por los cuales se debe regir la elección
del modelo a adaptar, la selección de procesos a mejorar y la reducción a realizar del
rango del modelo original.
El Modelo de Aceptación de la Tecnología TAM [32] es sencillo de utilizar y de
interpretar.
2. Recomendaciones
Para cualquier trabajo de grado o proyecto de investigación de ingeniería de sistemas
que se enfoque en el área de sistemas de información es recomendable trabajar bajo
el mismo paradigma de la investigación científica basada en el diseño de sistemas de
información, ya que ―una característica que distingue a los sistemas de información
de otros campos es que se preocupa o tiene relación con el uso de artefactos en
sistemas humano - máquina. Es una disciplina que está en la situada en la
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 74
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
intersección del conocimiento de las propiedades de los objetos físicos (máquinas) y
del comportamiento humano‖ [63, 50, 49] y la ICBDSI lidia con ello de una forma
adecuada y coherente.
Si se trabaja con la ICBDSI se debe profundizar y documentarse sobre ésta antes de
realizar o iniciar el proyecto, para tener claridad sobre qué y cómo se realizará.
Es prudente revisar muy bien el alance de un proyecto junto con el director de éste,
así como enfocarlo al grado de resultado que debería presentar.
3. Trabajos Futuros
3.1. Implementación de la Guía en Yettú Ltda.
La implementación de la guía metodológica como tal estuvo fuera del alcance de este
proyecto, pues esto implica que la organización debe realizar todas las actividades y tareas
propuestas en el Anexo 6 - Documento de Administración de Configuración – Entregable 1
Ciclo Diseño, lo cual toma un tiempo considerable.
Al realizar dichas actividades se podrá realizar una comparación del estado anterior la
implementación de la guía (lo que es el estado actual de la organización ahora) y el estado
posterior (lo que es un estado futuro); y se podrá medir si realmente existió una mejora en el
proceso de Administración de Configuración.
3.2. Instanciación de la Guía en Otra Organización
En la evaluación experta de la guía se especificó: ―Un punto a considerar frente a la
utilidad de la guía en el medio colombiano, es la revisión de las empresas de software en
el rango de MIPyMES que realmente tengan dentro de sus objetivos y políticas buscar
permanentemente una mejora de procesos y que adicionalmente estén interesadas en
lograr unos altos niveles de calidad de software que les permita competir en mercados
nacionales e internacionales‖ (ver Anexo 8 - Observaciones y Recomendaciones para la
Guía por Parte del Experto que realizó la evaluación). En efecto, para hacer más sólida la
guía metodológica, ésta debe ser instanciada en más organizaciones que estén interesadas en
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 75
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
mejorar sus procesos de software, obteniendo los requerimientos específicos de cada una de
éstas y así lograr establecer o formular meta-requerimientos e ir transformando la guía en un
meta-diseño que los satisfaga.
3.3. Investigación y Análisis de la Cultura Organizacional de las
MIPyMES_DS Colombianas
Teniendo en cuenta que la solución que propone esta guía metodológica a la problemática es
tener en cuenta los factores especiales de las MIPyMES_DS en especial la cultura, es
evidente que es necesario realizar una comparación entre la cultura organizacional que
plantean los modelos como CMM, o CMMI versus la que existe en las MIPyMES_DS
colombianas; aunque en este documento se realizó una, dicha comparación será más sólida si
se hace dentro de un marco de referencia común.
La gran mayoría de estudios que han buscado identificar la cultura implícita en CMM/CMMI
han utilizado el Marco de Referencia de Competición de Valores [105], que identifica 4 tipos
de cultura organizacional. La Ilustración 43 muestra algunas características de cada tipo de
cultura:
Ilustración 43 - Marco de Referencia de Competición de Valores [105]
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 76
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Utilizando este marco de referencia es posible establecer perfiles culturales de CMMI.
Existen estudios que muestran que los tipos de cultura racionalista (market) y jerárquico son
los que dominan [87, 54, 7, 8, 13, 62]. Esto es porque los modelos CMM y CMMI en su
esencia llevan a las organizaciones que lo aplican a una cultura racionalista (market) y a
medida que se alcanzan los niveles superiores de madurez en éstos se van presentando
características de cultura jerárquica [86].
De esto se desprende la necesidad de realizar un estudio para establecer el perfil cultural de
las MIPyMES_DS colombianas dentro de este marco de referencia, para así fortalecer la
afirmación de que la cultura que plantean modelos como CMMI y la colombiana difieren.
3.4. Realización Meta-Modelos de los Modelos de Mejora de Procesos
MoProSoft y CompetiSoft
Existen propuestas para representar todos los marcos de referencia como meta-modelos
conceptuales ya que utilizándolos se pueden demostrar formas de mejorar dichos marcos de
referencia y además configurarlos de acuerdo a las necesidades específicas de una empresa o
industria; además de esta forma sería mucho más fácil realizar una comparación entre los
diferentes marcos de referencia a un nivel abstracto [46].
La popularidad de ciertos modelos de mejora de procesos es benéfica cuando se trata de
encontrar sus meta-modelos. Por lo general estos no son ofrecidos por los autores oficiales
del modelo, por ejemplo, el Software Engineering Institute no ofrece un meta-modelo de
CMMI [121] así como la ISO no frece un meta-modelo de SPICE [128]. Sin embargo, varios
investigadores se han dado a la tarea de realizar sus meta-modelos, es el caso de [73] que
propone meta-modelos para SPICE y para la representación continua de CMMI, y de [85, 77]
que también proponen meta-modelos para CMMI [121].
No obstante, debido a que los modelos de mejora de procesos de software son creados en la
práctica y son dados para utilizarlos en la práctica [46], es posible que no exista un meta-
modelo explícito del modelo que se desea adaptar, como en el caso de MoProSoft [89] y
CompetiSoft [103]. Esto evidencia una necesidad de la realización de los meta-modelos de
éstos MMPS y para ello se pueden utilizar sus patrones de procesos y algunas técnicas de
elaboración de meta-modelos como las que proponen [115] y [46].
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 77
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
3.5. Propuesta para Realizar una Guía Metodológica
Durante la realización de ésta trabajo de grado (como se describió en la sección 3.1 - Modelo
Específico Adaptado para MIPyME_DS Colombiana de la cual se obtuvieron los
requerimientos específicos de III – DESARROLLO DEL TRABAJO) surgió un interrogante:
¿cómo describir una guía metodológica?
El documento de directrices para el trabajo de grado en ingeniería de sistemas en la Pontificia
Universidad Javeriana [59] no proporciona información suficiente sobre esto, y la plantilla
para propuesta de trabajo de grado de ingeniería de sistemas sólo brinda una definición: ―una
guía define en términos generales, pasos para llevar a cabo algo‖ [60]. Esto no deja un
panorama muy alegre para los estudiantes que se disponen a realizar una guía metodológica
como producto de su trabajo de grado, pues hay una brecha bastante amplia.
La forma en la que se abarcó este problema o interrogante en éste trabajo de grado (utilizando
ingeniería de métodos y el marco de referencia ―Forma De‖, ver secciones 1.1.2 Ingeniería de
Métodos y 1.1.3 Marco de Referencia ―Forma De‖) es una base para desarrollar un método
que soporte la realización de guías metodológicas, especificando cómo deben ser descritas y
de cuáles elementos deben estar compuestas (meta-modelo). Dicho método podría ser útil
para las asignaturas de Seminario Metodología de Investigación y Trabajo de Grado en el
departamento de ingeniería de sistemas, tal vez de la misma forma en la que la ―Propuesta
metodológica para la construcción de la bibliografía más relevante en ingeniería de sistemas‖
[26] lo es hoy en día.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 78
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
VII - REFERENCIAS Y BIBLIOGRAFÍA
1. Referencias
[1] A. Aguirre, C. Pardo, W. Pantoja, M. Maria, and F. Pino, ―Reporte de experiencias de
la aplicación de competisoft en cinco mipymes colombianas,‖ Revista Escuela de Ingeniería
de Antioquia, vol. 13, pp. 107–122, Julio 2010.
[2] M. Y. al Tarawneh, M. S. Abdullah, and A. B. M. Ali, ―A proposed methodology for
establishing software process development improvement for small software development
firms,‖ Procedia Computer Science, vol. 3, pp. 893 – 897, 2011, world Conference on
Information Technology. [Online]. Available: http://www.sciencedirect.com/science/article/-
B9865-527GFKD-12/2/913f8b1a5fdb02a7106b94ed3853afd6
[3] S. Alexandre, A. Renault, and N. Habra, ―Owpl: A gradual approach for software
process improvement in smes,‖ in Proc. 32nd EUROMICRO Conf. Software Engineering and
Advanced Applications SEAA ’06, 2006, pp. 328–335.
[4] P. Allen, M. Ramachandran, and H. Abushama, ―Prisms: an approach to software
process improvement for small to medium enterprises,‖ in Proc. Third Int Quality Software
Conf, 2003, pp. 211–214.
[5] J. R. Analabon, ―SpanishLas causas mas comunes de falla en la implantación de
mejoras en software,‖ Universidad Santiago de Chile, Departamento de Ingeniería
Informática, Tech. Rep., November 2005.
[6] M. Aydin, ―Determining an appropriate approach to the implementation of a wfms,‖
in Information Systems Development, O. Vasilecas, W. Wojtkowski, J. Zupancic,
A. Caplinskas, W. Wojtkowski, and S. Wrycza, Eds. Springer US, 2005, pp. 515–525,
10.1007/0-387-28809-0_44. [Online]. Available: http://dx.doi.org/10.1007/0-387-28809-0_44
[7] J. Bach, ―The immaturity of cmm,‖ American Programmer, vol. 7, no. 9, pp. 13–18,
September 1994.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 79
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
[8] ——, ―Enough about process: what we need are heroes,‖ vol. 12, no. 2, pp. 96–98,
1995.
[9] J. Batista and A. D. de Figueiredo, ―Spi in a very small team: a case with cmm,‖
Software Process: Improvement and Practice, vol. 5, no. 4, pp. 243–250, 2000.
[10] J. Becker, R. Knackstedt, D. Pfeiffer, and C. Janiesch, ―Configurative method
engineering: On the applicability of reference modeling mechanisms in method engineering,‖
in Proceedings of the13th Americas Conference on Information Systems. AMCIS, 2007.
[11] M. Blanco, ―Propuesta estratégica para el mejoramiento de procesos de software en
organizaciones pequeñas de desarrollo de software,‖ Master’s thesis, Universidad de los
Andes, 2007.
[12] B. Boehm, ―Unifying software engineering and systems engineering,‖ Computer,
vol. 33, no. 3, pp. 114–116, 2000.
[13] T. B. Bollinger and C. McGowan, ―A critical look at software capability
evaluations,‖ vol. 8, no. 4, pp. 25–41, 1991.
[14] F. O. Borda, Ante la crisis del país: Ideas-acción para el cambio. Ancora Editores,
2003, vol. 1.
[15] S. Brinkkemper, ―Method engineering: engineering of information systems
development methods and tools,‖ Information and Software Technology, vol. 38, no. 4, pp.
275 – 280, 1996, method Engineering and Meta-Modelling. [Online]. Available: http://-
www.sciencedirect.com/science/article/B6V0B-3VTJK0G-Y/2/-
4211ed8ea0fdafa25ee5b90754e89ea1
[16] J. Brodman and D. Johnson, ―Tailoring the cmm for small businesses, small
organizations, and small projects,‖ IEEE Software Process Newsletter, vol. 8, pp. 239–259,
1997.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 80
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
[17] J. G. Brodman and D. L. Johnson, ―What small business and small organizations say
about the cmm: experience report,‖ in ICSE ’94: Proceedings of the 16th international
conference on Software engineering. Los Alamitos, CA, USA: IEEE Computer Society Press,
1994, pp. 331–340.
[18] ——, ―A software process improvement approach tailored for small organizations
and small projects (tutorial),‖ in ICSE ’97: Proceedings of the 19th international conference
on Software engineering. New York, NY, USA: ACM, 1997, pp. 661–662.
[19] F. P. Brooks, Jr., ―No silver bullet essence and accidents of software engineering,‖
Computer, vol. 20, no. 4, pp. 10–19, 1987.
[20] B. Bruegge, Ingeniería de Software Orientada a Objetos, primera edición ed., P. E.
S.A., Ed., 2002.
[21] L. F. Campo, ―Modelos de capacidad y madurez y la industria del software en
colombia,‖ Revista Generación Digital, vol. 7, pp. 22–25, 2008.
[22] A. P. Cater-Steel, ―Process improvement in four small software companies,‖ in Proc.
Australian Software Engineering Conf, 2001, pp. 262–272.
[23] ——, ―Low-rigour, rapid software process assessments for small software
development firms,‖ in Proc. Australian Software Engineering Conf, 2004, pp. 368–377.
[24] F. Cattaneo, A. Fuggetta, and D. Sciuto, ―Pursuing coherence in software process
assessment and improvement,‖ Software Process: Improvement and Practice, vol. 6, no. 1,
pp. 3–22, 2001. [Online]. Available: http://dx.doi.org/10.1002/spip.131
[25] T. Celis. (2011, Febrero) SpanishEn colombia predomina la cultura organizacional
jerarquica. Web. La Republica. [Online]. Available: http://www.larepublica.com.co/-
archivos/ALTAGERENCIA/2011-02-01/en-colombia-predomina-la-cultura-organizacional-
jerarquica_120661.php
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 81
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
[26] O. J. Chavarro and R. J. Barros, ―Propuesta metodológica para la construcción de la
bibliografía más relevante en ingeniería de sistemas,‖ in II Congreso Colombiano de
Computación, 2007.
[27] P. Checkland and J. Sholes, Soft Systems Methodology in Action. Wiley, 1999.
[28] M. Chrissis, M. Konrad, and S. Shrum. (2009) SpanishCmmi: Guía para la
integración de procesos y la mejora de productos. [Online]. Available: http://-
www.sei.cmu.edu/library/assets/cmmi-dev-v12-spanish.pdf
[29] M. B. Chrissis, M. Konrad, and S. Shrum, CMMI:Guidelines for Process Integration
and Product Improvement, Pearson, Ed. Addison Wesley, 2003.
[30] K. C. Dangle, P. Larsen, M. Shaw, and M. V. Zelkowitz, ―Software process
improvement in small organizations: a case study,‖ vol. 22, no. 6, pp. 68–75, 2005.
[31] F. Daoudi and S. Nurcan, ―A benchmarking framework for methods to design
flexible business processes,‖ Software Process: Improvement and Practice, vol. 12, no. 1, pp.
51–63, 2007. [Online]. Available: http://dx.doi.org/10.1002/spip.304
[32] F. Davis, ―Perceived usefulness, perceived ease of use, and user acceptance of
information technology,‖ MIS Quarterly: Management Information Systems, vol. 13, no. 3,
pp. 319–339, September 1989. [Online]. Available: http://www.scopus.com/record/-
display.url?view=basic&eid=2-s2.0-55249087535&origin=resultslist&sort=plf-
f&src=s&sid=mUTDoFEvocUHIQzvPpfaMM7%3a510&sot=aut&sdt=a&sl=34&s=AU-
ID%28%22Davis%2c+Fred+D.%22+7202374889%29&relpos=19&relpos=19
[33] U. T. R. C. de Calidad de Software RCCS. Red colombiana de calidad de software.
[Online]. Available: http://rccs.cidlisuis.org/
[34] C. de Comercio de Bogotá, Balance Tecnológico Cadena Productiva Desarrollo de
Software en Bogotá y Cundinamarca, D. de Publicaciones Cámara de Comercio de Bogotá,
Ed. Cámara de Comercio de Bogotá, 2006.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 82
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
[35] I. N. de Tecnología de Comunicación. (2008, Abril) SpanishEstudio sobre la
certificación de la calidad como medio para impulsar la industria de desarrollo del software
en españa. INTECO. [Online]. Available: www.inteco.es/file/gSrX5MKzk-
K5f1Ez5MwRMA
[36] G. Di Paula, D. Parada, M. Pérez, and L. Mendoza, ―Agilidad y disciplina del
proceso de desarrollo de software para las pequeñas y medianas empresas (pymes) y las
cooperativas en latinoamérica. caso: Venezuela,‖ in VII Jornadas Iberoamericanas de
Ingeniería del Software e Ingeniería del Conocimiento, 2008.
[37] L. Dube, ―Teams in packaged software development: The software corp. experience,‖
Information Technology & People, vol. 11, no. 1, pp. 36–61, 1998.
[38] L. Dube and D. Robey, ―Software stories: three cultural perspectives on the
organizational practices of software development,‖ Accounting Management and Information
Technologies, vol. 9, pp. 223–259, 1999.
[39] T. Dyba, ―An empirical investigation of the key factors for success in software
process improvement,‖ vol. 31, no. 5, pp. 410–424, 2005.
[40] ——, ―Factors of software process improvement success in small and large
organizations: an empirical study in the scandinavian context,‖ in ESEC/FSE-11:
Proceedings of the 9th European software engineering conference held jointly with 11th
ACM SIGSOFT international symposium on Foundations of software engineering. New
York, NY, USA: ACM, 2003, pp. 148–157.
[41] P. Fettke and P. Loos, ―Classification of reference models: a methodology and its
application,‖ Information Systems and E-Business Management, vol. 1, pp. 35–53, 2003,
10.1007/BF02683509. [Online]. Available: http://dx.doi.org/10.1007/BF02683509
[42] G. . R. J. Forradellas, Patricia & Pantaleo. SpanishEl modelo cmm/cmmi - cómo
garantizar el éxito del proceso de mejoras en las organizaciones, superando los conflictos y
tensiones generados por su implementación. [Online]. Available: www.it-mentor.com.ar/pdf/-
CMMCulturaOrg.pdf
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 83
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
[43] H. D. Frederiksen and J. Rose, ―The social construction of the software operation:
reinforcing effects in metrics programs,‖ Scand. J. Inf. Syst., vol. 15, pp. 23–37, January
2003. [Online]. Available: http://portal.acm.org/citation.cfm?id=958052.958055
[44] S. M. Gallardo. (2005) EspañolCara y sello impacto del tlc en la ingeniería de
sistemas. Magazine. ACIS. [Online]. Available: http://www.acis.org.co/index.php?id=395
[45] ——. (2005) EspañolEl tlc bajo la lente de fedesoft. Magazine. ACIS. [Online].
Available: http://www.acis.org.co/index.php?id=388
[46] M. Goeken and S. Alter, ―Towards conceptual metamodeling of it governance
frameworks approach - use - benefits,‖ in System Sciences, 2009. HICSS ’09. 42nd Hawaii
International Conference on, 2009, pp. 1–10.
[47] E. Gonzalez, Claudia & Olivares. (2008, Febrero) SpanishCmmi por medio de
moprosoft. Internet. Software Guru. [Online]. Available: http://www.sg.com.mx/-
index.php?option=com_content&task=view&id=654
[48] R. Grady, Successful Software Process Improvement. Prentice Hall, 1997.
[49] S. Gregor, ―Design theory in information systems,‖ Australian Journal of
Information Systems, vol. Special Issue, pp. 14–22, 2002.
[50] ——, ―Building theory in the sciences of the artificial,‖ in Proceedings of the 4th
International Conference on Design Science Research in Information Systems and
Technology, ser. DESRIST ’09. New York, NY, USA: ACM, 2009, pp. 4:1–4:10.
[51] F. Guerrero and Y. Eterovic, ―Adopting the sw-cmm in a small it organization,‖ IEEE
Software, vol. 21, pp. 29–35, 2004.
[52] M. Habib, S. Ahmed, A. Rehmat, M. J. Khan, and S. Shamail, ―Blending six sigma
and cmmi - an approach to accelerate process improvement in smes,‖ in Proc. IEEE Int.
Multitopic Conf. INMIC 2008, 2008, pp. 386–391.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 84
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
[53] N. e. a. Habra, ―EnglishSoftware process improvement in small organizations using
gradual evaluation schema,‖ EnglishIn Proceedings of the International Conference on
Product Focused Software Process Improvement, pp. 102–110, June 1999.
[54] B. Hansen, J. Rose, and G. Tjornehoj, ―Prescription, description, reflection: the shape
of the software process improvement field,‖ International Journal of Information
Management, vol. 24, no. 6, pp. 457 – 472, 2004. [Online]. Available: http://-
www.sciencedirect.com/science/article/B6VB4-4DNW6P4-3/2/-
a0ede45f9eddee12a10d60d1b43aab00
[55] E. Herrera and R. Trejo, ―A methodology for self-diagnosis for software quality
assurance in small and medium sized industries in latin america,‖ The Electronic Journal of
Information Systems in Developing Countries, vol. 15, no. 4, pp. 1–13, 2003.
[56] A. R. Hevner, S. T. March, J. Park, and S. Ram, ―Design science in information
systems research,‖ MIS Quarterly, vol. 28, no. 1, pp. 75–105, March 2004.
[57] A. R. Hevner and S. T. March, ―The information systems research cycle,‖ Computer,
vol. 36, pp. 111–113, 2003.
[58] S. E. Institute. (2005) EnglishCapability maturity model integration (cmmi)
ovewview. Web. Carnegie Mellon. [Online]. Available: http://elsmar.com/pdf_files/cmmi-
overview05.pdf
[59] G. ISTAR. (2008, Julio) EspañolDirectrices para el trabajo de grado en la carrera de
ingeniería de sistemas. Pontificia Universidad Javeriana.
[60] ——. (2010, Agosto) EspañolPlantilla para propuesta de trabajo de grado. Pontificia
Universidad Javeriana.
[61] Itera. (2006) SpanishMoprosoft. Web Page. Itera IT Business Process. [Online].
Available: http://www.iteraprocess.com/-
index.php?option=com_content&task=view&id=23&Itemid=44
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 85
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
[62] D. L. Johnson and J. G. Brodman, ―Applying cmm project planning practices to
diverse environments,‖ vol. 17, no. 4, pp. 40–47, 2000.
[63] D. Jones and G. Shirley, ―The anatomy of a design theory,‖ Journal of the
Association for Information Systems, vol. 8, no. 5, 2008.
[64] F. Karlsson and P. J. Ågerfalk, ―Method configuration: adapting to situational
characteristics while creating reusable assets,‖ Information and Software Technology, vol. 46,
no. 9, pp. 619 – 633, 2004. [Online]. Available: http://www.sciencedirect.com/science/-
article/B6V0B-4BHY5B2-1/2/b2e18197e92226aa9acca19da1cb3960
[65] F. Karlsson and K. Wistrand, ―Combining method engineering with activity theory:
theoretical grounding of the method component concept,‖ European Journal of Information
Systems, vol. 15, pp. 82–90, 2006.
[66] T. C. Kasse and P. A. Mcquaid, ―Entry strategies into the process improvement
initiative,‖ Software Process: Improvement and Practice, vol. 4, no. 2, pp. 73–88, 1998.
[67] K. Kautz and P. A. Nielsen, ―Understanding the implementation of software process
improvement innovations in software organizations,‖ Information Systems Journal, vol. 14,
no. 1, pp. 3–22, January 2004.
[68] M. Kulpa and K. Johnson, Interpreting the CMMI: A Process Improvement
Approach, C. Press, Ed. Auerbach Publications, 2003.
[69] C. Y. Laporte, S. Alexandre, and A. Renault, ―Developing international standards for
very small enterprises,‖ Computer, vol. 41, no. 3, pp. 98–101, 2008.
[70] C. Y. Laporte, J. marc Desharnais, P. D, M. M. Abouelfattah, J. claude Bamba,
A. Renault, N. Habra, and P. D, ―Initiating software process improvement in small
enterprises: Experiment with microevaluation framework,‖ in University of Iceland, 2005,
p. 27.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 86
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
[71] C. Y. Laporte and S. Trudel, ―Addressing the people issues of process improvement
activities at oerlikon aerospace,‖ Software Process: Improvement and Practice, vol. 4, no. 4,
pp. 187–198, 1998. [Online]. Available: http://dx.doi.org/10.1002/(SICI)1099-
1670(199812)4:4<187::AID-SPIP108>3.0.CO;2-F
[72] A. Laryd, T. Orci, and A. L. T. Orci, ―Dynamic cmm for small organizations,‖ in
Umeå University, 2000.
[73] M. Lepasaar and T. Makinen, ―Integrating software process assessment models using
a process meta model,‖ in Engineering Management Conference, 2002. IEMC ’02. 2002
IEEE International, vol. 1, 2002, pp. 224 – 229 vol.1.
[74] S. Looso, ―Towards a structured application of it governance best practice reference
models,‖ AMCIS 2010 Proceedings, 2010. [Online]. Available: http://aisel.aisnet.org/-
amcis2010/61
[75] D. Moitra, ―Managing change for software process improvement initiatives: a
practical experience-based approach,‖ Software Process: Improvement and Practice, vol. 4,
no. 4, pp. 199–207, 1998. [Online]. Available: http://dx.doi.org/10.1002/(SICI)1099-
1670(199812)4:4<199::AID-SPIP107>3.0.CO;2-D
[76] P. Mongkolnam, U. Silparcha, N. Waraporn, and V. Vanijja, ―A push for software
process improvement in thailand,‖ in Proc. Asia-Pacific Software Engineering Conf. APSEC
’09, 2009, pp. 475–481.
[77] A. Monzón. (2006, Marzo) SpanishAqap-160 vs. cmmi. Web. Military Transport
Aircract Division. [Online]. Available: http://www.calidaddelsoftware.com/documentos/-
II%20Semana%20CMMI/03-%20EADS-CASA.pdf
[78] S. Morales. (2010, Marzo) SpanishCaracterización de la cultura organizacional en
empresas colombianas. Web. Universidad del Rosario. [Online]. Available: http://-
repository.urosario.edu.co/bitstream/10336/1789/3/1032375920-2010.pdf
[79] G. Morgan, Images of Organization, 2nd ed., N. Park, Ed. SAGE Publications, 1996.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 87
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
[80] P. M. Muchinsky, ―Psicología aplicada al trabajo,‖ Thomson, pp. 3–21, 2002.
[81] N. Mulira, Implementing Inter-Organisational Service Systems: An approach for
emerging networks in volatile contexts. Delft University of Technology, 2007.
[82] S. Muller, P. Nielsen, and M. Bolsden, ―An examination of culture profiles in a
software organizacion implementing spi,‖ in ECIS 2008 Proceedings, 2008. [Online].
Available: http://aisel.aisnet.org/ecis2008/235
[83] S. D. Muller, P. Kraemmergaard, and L. Mathiassen, ―Managing cultural variation in
software process improvement: A comparison of methods for subculture assessment,‖
vol. 56, no. 4, pp. 584–599, 2009.
[84] S. D. Muller, L. Mathiassen, and H. H. Balshoj, ―Software process improvement as
organizational change: A metaphorical analysis of the literature,‖ Journal of Systems and
Software, vol. 83, no. 11, pp. 2128 – 2146, 2010, interplay between Usability Evaluation and
Software Development. [Online]. Available: http://www.sciencedirect.com/science/article/-
B6V0N-509XPN8-6/2/6d63e997e7df29a9d31ddbfc201fd38b
[85] D. Mustat, V. Castaño, J. A. Calvo-Manzano Villalon, and J. Garbajosa, ―Mature: A
model driven based tool to automatically generate a language that supports cmmi process
areas specification,‖ in Systems, Software and Services Process Improvement: 17th European
Conference, vol. 99. Springer Berlin Heidelberg, September 2010, pp. 48–59. [Online].
Available: http://dx.doi.org/10.1007/978-3-642-15666-3_5
[86] O. Ngwenyama and P. A. Nielsen, ―Competing values in software process
improvement : An assumption analysis of cmm from an organizational culture perspective,‖
IEEE Transactions on Engineering Management, vol. 50, no. 1, pp. 100–112, February 2003.
[87] P. A. Nielsen and J. Norbjerg, ―Assessing software processes: low maturity or
sensible practice,‖ Scand. J. Inf. Syst., vol. 13, pp. 51–67, June 2001. [Online]. Available:
http://portal.acm.org/citation.cfm?id=565431.565434
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 88
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
[88] H. Oktaba, C. Alquicira, A. Su Ramos, F. López, J. Palacios, and C. Pérez,
SpanishMétodo de Evaluación de procesos para la Industria del Software EvalProSoft,
Universidad Nacional Autónoma de México Std. 1.1, 2004. [Online]. Available: http://-
materias.utags.edu.mx/claroline/backends/-
download.php?url=L0FydGljdWxvcy9FdmFsUHJvU29mdHYxMS5wZGY%3D&cidReset=t
rue&cidReq=CALS_IVET
[89] H. Oktaba, C. Alquicira, A. Su Ramos, A. Martinez, A. Quintanilla, M. Ruvalbaca,
F. Lopez, M. Rivera, M. Orozco, Y. Fernandez, and M. Flores, ―Modelo de procesos para la
industria de software moprosoft,‖ no. 1.3. Universidad Nacional Autonoma de Mexico,
Agosto 2005. [Online]. Available: http://www.comunidadmoprosoft.org.mx/-
COMUNIDAD_MOPROSOFTADM/Documentos/V1.3_MoProSoft.pdf
[90] H. Oktaba, C. Alquicira, A. Su Ramos, A. Martinez, A. Quintanilla, M. Ruvalbaca,
F. López, M. Rivera, M. Orozco, Y. Fernandez, and M. Flores, Modelo de Procesos para la
Industria del Software MoProSoft por Niveles de Capacidad de Procesos, Universidad
Nacional Autónoma de México Std. 1.3, Agosto 2005. [Online]. Available: http://-
www.comunidadmoprosoft.org.mx/COMUNIDAD_MOPROSOFTADM/Documentos/-
V_1.3_MoProSoft_por_niveles_de_capacidad_de_procesos.pdf
[91] H. Oktaba, F. Garcia, M. Piattini, F. Ruiz, F. J. Pino, and C. Alquicira, ―Software
process improvement: The competisoft project,‖ Computer, vol. 40, no. 10, pp. 21–28, 2007.
[92] H. e. a. Oktaba. (2005) Moprosoft: Modelo de procesos para la industria de software.
[93] H. Oktaba. (2008, Mayo) Moprosoft sin fronteras. Universidad Nacional Autónoma
de México.
[94] M. Op’ t Land, E. Proper, M. Waage, J. Cloo, C. Steghuis, M. Op ’t Land, E. Proper,
M. Waage, J. Cloo, and C. Steghuis, ―The results of enterprise architecting,‖ in Enterprise
Architecture, ser. The Enterprise Engineering Series, J. Dietz, E. Proper, J. Tribolet,
T. Halpin, J. Hoogervorst, M. Op ’t Land, R. G. Ross, and R. Winter, Eds. Springer Berlin
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 89
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Heidelberg, 2009, pp. 49–83, 10.1007/978-3-540-85232-2_4. [Online]. Available: http://-
dx.doi.org/10.1007/978-3-540-85232-2_4
[95] S. Orantes, ―Viabilidad del "modelo de aceptación de la tecnología" en las empresas
mexicanas. una aproximación a las actitudes y percepciones de los usuarios de las tecnologías
de la información,‖ Revista Digital Universitaria, vol. 12, no. 1, Enero 2011.
[96] S. Otoya and N. Cerpa, ―An experience: a small software company attempting to
improve its process,‖ in Proc. Software Technology and Engineering Practice STEP ’99,
1999, pp. 153–160.
[97] J. Parra, ―Factores críticos de Éxito e hipótesis sobre la industria del software en
colombia. consideraciones textuales y académicas,‖ Revista Avances en Sistemas e
Informática, vol. 5, pp. 185–193, 2008.
[98] M. Paulk, ―Using the cmm in small organizations,‖ in The Joint 1998 Proceedings of
the Pacific Northwest Software Quality Conference and the Eighth International Conference
on Software Quality, Portland, Oregon., 1998, pp. 350 – 361.
[99] M. Paulk, W. Curtis, M. Chrissis, and K. C. Weber, ―Capability maturity model for
software version 1.1.‖ Carnegie Mellon Software Engineering Institute, Tech. Rep., February
1993. [Online]. Available: http://www.sei.cmu.edu/library/abstracts/reports/93tr024.cfm
[100] J. Persse, Process Improvement Essentials, M. O’Brien and T. Apandi, Eds. O’Reilly,
September 2006.
[101] M. Phongpaibul and B. Boehm, ―Improving quality through software process
improvement in thailand: initial analysis,‖ in Proceedings of the third workshop on Software
quality, ser. 3-WoSQ. New York, NY, USA: ACM, 2005, pp. 1–6. [Online]. Available:
http://doi.acm.org/10.1145/1083292.1083299
[102] M. Piattini, H. Oktaba, F. Pino, M. Orozco, and C. Alquicira, ―Competisoft: Mejora
de procesos para fomentar la competitividad de la pequeña y mediana industria del software
de iberoamérica,‖ CYTED Ciencia y Tecnología para el Desarrollo, Tech. Rep. 0.2,
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 90
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Diciembre 2006. [Online]. Available: http://artemisa.unicauca.edu.co/~ecaldon/docs/spi/-
COMPETISOFT_v02_27-11_2315.pdf
[103] ——, Competisoft: Mejora de Procesos Software para Pequeñas y Medianas
Empresas y Proyectos, Ra-Ma, Ed. AlfaOmega, 2009.
[104] F. J. Pino, F. Garcia, and M. Piattini, ―Key processes to start software process
improvement in small companies,‖ in SAC ’09: Proceedings of the 2009 ACM symposium on
Applied Computing. New York, NY, USA: ACM, 2009, pp. 509–516.
[105] R. E. Quinn, M. R. McGrath, P. J. Frost, L. F. Moore, M. R. Luis, C. C. Lundberg,
and J. Martin, The transformation of organizational cultures: A competing values
perspective. Sage Publications, Inc, 1985, pp. 315–334. [Online]. Available: http://-
search.epnet.com/login.aspx?direct=true&db=psyh&an=1986-97980-
016&loginpage=login.asp&site=ehost
[106] I. Richardson and C. Gresse, ―Why are small software organizations different?‖ IEEE
Software, vol. 24, 2007.
[107] B. L. F. Rios, M. A. A. Vargas, J. M. O. Espinoza, and M. d. C. Peralta, ―Experiences
on the implementation of moprosoft and assessment of processes under the nmx-i-059/02-
nyce-2005 standard in a small software development enterprise,‖ in Proc. Mexican Int. Conf.
Computer Science ENC ’08, 2008, pp. 323–328.
[108] O. Rodriguez, A. Martinez, V. Garcia, J. Favela, and M. Piattini, ―Modeling and
analysis of knowledge flows in software processes trough the extension of the software
process engineering metamodel,‖ Internationa Journal of Software Engineering and
Knowledge Engineering, vol. 19, no. 2, pp. 185–211, 2009.
[109] F. Romero and M. Blanco, ―Mejoramiento de procesos de software en pequeñas
empresas: Algunas experiencias en el caso colombiano,‖ Paradigma en construcción de
software, vol. 2, pp. 1–6, 2008.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 91
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
[110] H. Saeidian and N. Carr, ―Characterizing a software process maturity model for small
organizations,‖ ACM SIGICE Bulletin, vol. 23, no. 1, pp. 2–11, 1997.
[111] A. Salinas, ―Obstáculos en la gestión de proyectos en tecnologías de información y
comunicación - tics y posibles soluciones,‖ Master’s thesis, Universidad Pontificia
Bolivariana, 2007.
[112] G. Santos, M. Montoni, J. Vasconcellos, S. Figueiredo, R. Cabral, C. Cerdeiral, A. E.
Katsurayama, P. Lupo, D. Zanetti, and A. R. Rocha, ―Implementing software process
improvement initiatives in small and medium-size enterprises in brazil,‖ in Proc. 6th Int.
Conf. the Quality of Information and Communications Technology QUATIC 2007, 2007, pp.
187–198.
[113] P. Scalzone. (2008, Marzo) EspañolLa calidad y las pymes de la industria del
software. Web page. [Online]. Available: http://www.vemn.com.ar/Blog/post/La-Calidad-y-
las-PyMes-de-la-Industria-del-Software.aspx
[114] E. Schein, Organizational Culture and Leadership: A Dynamic View, Jossey-Bass,
Ed. Proquest Info & Learning, October 1992.
[115] R. Schuette and T. Rotthowe, ―The guidelines of modeling - an approach to enhance
the quality in information models,‖ in Conceptual Modeling - ER 98, ser. Lecture Notes in
Computer Science, T.-W. Ling, S. Ram, and M. Li Lee, Eds. Springer Berlin / Heidelberg,
1998, vol. 1507, pp. 240–254, 10.1007/978-3-540-49524-6_20. [Online]. Available: http://-
dx.doi.org/10.1007/978-3-540-49524-6_20
[116] P. S. Seligmann, G. M. Wijers, and H. G. Sol, ―Analyzing the structure of I.S.
methodologies, an alternative approach,‖ in Proceedings of the First Dutch Conference on
Information Systems, R. Maes, Ed., Amersfoort, The Netherlands, EU, 1989.
[117] H. G. Sol, Information systems development: a problem-solving approach. New
York, NY, USA: John Wiley & Sons, Inc., 1992, pp. 151–161. [Online]. Available: http://-
portal.acm.org/citation.cfm?id=133549.133567
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 92
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
[118] D. Stelzer and W. Mellis, ―Success factors of organizational change in software
process improvement,‖ Software Process: Improvement and Practice, vol. 4, no. 4, pp. 227–
250, 1998.
[119] M. Sulayman and E. Mendes, ―Quantitative assessments of key success factors in
software process improvement for small and medium web companies,‖ in SAC ’10:
Proceedings of the 2010 ACM Symposium on Applied Computing. New York, NY, USA:
ACM, 2010, pp. 2319–2323.
[120] A. M. I. Team, ―Standard cmmi appraisal method for process improvement scampi,‖
Software Engineering Institute, Tech. Rep., 2001.
[121] C. P. Team, ―Cmmi for development, version 1.2,‖ Carnegie Mellon Software
Engineering Institute, Tech. Rep., August 2006. [Online]. Available: http://-
www.sei.cmu.edu/reports/06tr008.pdf
[122] Y. University. (2003) Theories used in research, technology acceptance model.
Appalacian State University. [Online]. Available: http://www.istheory.yorku.ca/-
Technologyacceptancemodel.htm
[123] R. P. Uribe, ―Estructura y cultura organizacional en la pyme colombiana: Análisis en
empresas bogotanas,‖ Cuadernos de Administración, vol. 38, pp. 73–85, 2007.
[124] V. Vaishnavi and W. Kuechler. (2004) EnglishDesign research in information
systems. Web Page. [Online]. Available: http://desrist.org/design-research-in-information-
systems
[125] R. L. Villalba and L. E. Díaz, ―Aprendizaje y aplicación del modelo cmmi -dev en
pymes de sofware colombianas. la experiencia rccs,‖ Revista GTI, vol. 9, no. 24, 2011.
[Online]. Available: http://revistas.uis.edu.co/index.php/revistagti/article/view/1462
[126] C. G. von Wangenheim, A. Anacleto, and C. F. Salviano, ―Helping small companies
assess software processes,‖ vol. 23, no. 1, pp. 91–98, 2006.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 93
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
[127] M. West, Real Process Improvement Using the CMMI, C. Press, Ed. Auer, 2004.
[128] WG10, ―Iso/iec 15504 software process improvement and capability determination,‖
International Organization of Standardization, Tech. Rep., 2003.
[129] C. Whuendy, ―Modelo de capacidad de madurez del software y su influencia en las
mejoras de calidad del software,‖ in Trabajo de Graduación, 2004. [Online]. Available:
http://biblioteca.usac.edu.gt/tesis/08/08_5776.pdf
[130] R. Winter and J. Schelp, ―Reference modeling and method construction: a design
science perspective,‖ in Proceedings of the 2006 ACM symposium on Applied computing, ser.
SAC ’06. New York, NY, USA: ACM, 2006, pp. 1561–1562. [Online]. Available: http://-
doi.acm.org/10.1145/1141277.1141638
[131] G. Yamamura, ―Process improvement satisfies employees,‖ vol. 16, no. 5, pp. 83–85,
1999.
[132] S. Zahran, Software Process Improvement : Practical Guidelines for Businees
Success / S. Zahran. Harlow, Inglaterra : Addison-Wesley, 1998. [Online]. Available: http://-
148.201.96.14/dc/ver.aspx?ns=000098365
[133] L. Zhang and Y. Li, ―Software process improvement for small organizations based on
cmmi/tsp/psp,‖ in School of Computer Science, Henan Polytechnic University, 2007, pp.
1213–1216. [Online]. Available: http://www.bmtfi.net/upload/product/201001/-
1264727480s3xvkd4g.pdf
[134] Z. Zhiying, ―Cmm in uncertain environments,‖ Commun. ACM, vol. 46, pp. 115–119,
August 2003. [Online]. Available: http://doi.acm.org/10.1145/859670.859679
2. Bibliografía
Debido a que la bibliografía consultada para el desarrollo trabajo es muy extensa (449
referencias) ésta se ha publicado en la página web del trabajo de grado en un archivo BibTex
en la sección de documentos.
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 94
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
VIII - ANEXOS
1. Glosario
Actividad: Conjunto de tareas o sub-actividades que se realizan para cumplir un
objetivo [20].
Herramienta: Es un medio para soportar una parte de un proceso, o de una o más
técnicas [15, 130].
Ingeniería de Métodos: Es una disciplina de ingeniería para diseñar, construir y
adaptar métodos, técnicas y herramientas para el desarrollo de sistemas de información [15]. Su enfoque es hacer los métodos genéricos aplicables a ciertos
escenarios [130].
Método: Es un acercamiento para llevar a cabo un proyecto de desarrollo de sistemas, basado en una forma específica de pensar; consiste de direcciones y roles y
está estructurado en una forma sistemática [15].
Meta-Método: Lineamientos guías para un método. Ir de lo situacional a lo genérico
[130].
Meta-Modelo: Es un modelo de un modelo [46].
Modelo: Lineamientos de las mejores prácticas que han sido encontradas y aplicadas
por organizaciones altamente funcionales y exitosas [68].
Modelo de Mejora de Procesos de Software: Lineamientos de mejores prácticas
que especifican qué hacer (más no cómo) para lograr una mejora de los procesos de construcción de software en una organización [68]
Modelo de Referencia: Es un modelo conceptual genérico que puede ser utilizado en
cierto dominio. Permite la re-utilización de conocimiento [130]
Proceso: Grupo de actividades llevadas a cabo hacia un objetivo específico [20]
SCAMPI: Standard CMMI Appraisal Method for Process Improvement [120]
SSM: Soft Systems Methodology, en español Metodología de los Sistemas Blandos [27]
Tarea: Representa la pieza más pequeña de trabajo. Su realización produce artefactos
y consume recursos [20].
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Proyecto de Investigación
Página 95
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Técnica: Es un procedimiento, posiblemente con una notación prescrita, para llevar a
cabo una actividad [15]
2. Conocimiento Aplicable a ProSoftCol – Entregable 1 Ciclo Rigor
3. Análisis de la Cultura Organizacional Colombiana – Entregable 2 Ciclo
Rigor
4. Requerimientos Específicos de la Micro-Empresa Yettú Ltda. -
Entregable Ciclo Relevancia
5. Guía Metodológica – Entregable 1 Ciclo Diseño
6. Documento de Administración de Configuración – Entregable 1 Ciclo
Diseño
7. Cuestionario Evaluación de un Experto de la Completitud y Consistencia
Interna de la Guía
8. Observaciones y Recomendaciones para la Guía por Parte del Experto
que realizó la evaluación
9. Cuestionario TAM – Entregable 2 Ciclo Diseño
10. Carta de Validación de la Guía y su Instanciación, por Yettú Ltda.