CIS1030IS04 - Trabajos de Grado de la facultad de...

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


BOGOTÁ, D.C.

Junio, 2011

http://pegasus.javeriana.edu.co/~CIS1030IS04/


Página ii Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008

PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA


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


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”


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.


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


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


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


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


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


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


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


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.


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.


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.


Página 2


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


Página 3


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:


Página 4


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,


Página 5


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.


Página 6


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


Página 7


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.


Página 8


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]


Página 9


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.


Página 10


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.


Página 11


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.


Página 12


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-


Página 13


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


Página 14


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


Página 15


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


Página 16


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:


Página 17


Ilustración 4 – Características de los Niveles de Capacidad del Modelo CMMI [68]


Página 18


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.


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 :


Página 19


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:


Página 20


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.


Página 21


Ilustración 8 - Componentes de las Áreas de Proceso del Modelo CMMI [29]


Página 22


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


Página 23


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


Página 24


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.


Página 25


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


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:


Página 26


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.


Página 27


Ilustración 13 - Patrón de Procesos del Modelo MoProSoft [90]


Página 28


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


Página 29


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.


É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]


Página 30


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


Página 31


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


Página 32


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


Página 33


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


Página 34


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.


Página 35


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


Página 36


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:


Página 37


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


Página 38


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


Página 39


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


Página 40


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


Página 41


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


Página 42


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.


Página 43


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:


Página 44


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


Página 45


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:


Página 46


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)


Página 47


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


Página 48


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


Página 49


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


Página 50


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


Página 51


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.


Página 52


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


Página 53


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


Página 54


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


Página 55


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.


Página 56


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.


Página 57


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


Página 58


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.


Página 59


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


Página 60


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.


Página 61


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


Página 62


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


Página 63


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


Página 64


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


Página 65


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)


Página 66


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


Página 67


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


Página 68


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.


Página 69


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


Página 70


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


Página 71


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


Página 72


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


Página 73


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


Página 74


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


Página 75


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]


Página 76


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


Página 77


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.


Página 78


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.


Página 79


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


Página 80


[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


Página 81


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


Página 82


[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


Página 83


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


Página 84


[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


Página 85


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


Página 86


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


Página 87


[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


Página 88


[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


Página 89


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,


Página 90


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.


Página 91


[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


Página 92


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


Página 93


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


Página 94


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


Página 95


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.

CIS1030IS04 - Trabajos de Grado de la facultad de...

Documents

Transcript of CIS1030IS04 - Trabajos de Grado de la facultad de...