pegasus.javeriana.edu.copegasus.javeriana.edu.co/~CIS1030IS04/documents/Prop… · Web viewLa...

Ingeniería de Sistemas

PROPUESTA PARA TRABAJO DE GRADOTÍTULO ProSoftCol: Guía Metodológica de Mejora de Procesos de Construcción de Software Adaptada para MIPyMES_DS Colombianas

MODALIDAD Guía Metodológica

OBJETIVO GENERALAdaptar un modelo de mejora de procesos de construcción de software para micro, pequeñas y medianas empresas colombianas.

ESTUDIANTE(S)

Ximena Higuera Moriones __________________________________________Documento Celular Teléfono fijo Correo JaverianoCC10191021583 300-555-05-00 6134762 [email protected]

DIRECTOR

Ing. Rafael Andrés González Rivera __________________________________Correo Javeriano Empresa donde trabaja y [email protected] Pontificia Universidad Javeriana;

Profesor Departamento de Sistemas

5/5/2023

mailto:[email protected]

mailto:[email protected]

- <Guía Metodológica>

Contenido

1 OPORTUNIDAD O PROBLEMÁTICA............................................................................1

1.1 DESCRIPCIÓN DE LA OPORTUNIDAD O PROBLEMÁTICA...........................................11.2 FORMULACIÓN..........................................................................................................21.3 JUSTIFICACIÓN..........................................................................................................31.4 IMPACTO ESPERADO DEL PROYECTO.......................................................................4

2 DESCRIPCIÓN DEL PROYECTO..................................................................................5

2.1 OBJETIVO GENERAL..................................................................................................52.2 FASES METODOLÓGICAS Y OBJETIVOS ESPECÍFICOS................................................52.3 ENTREGABLES O RESULTADOS ESPERADOS.............................................................5

2.3.1 Área De Proceso Clave (KPA):..................................................................................52.3.2 Caso de Estudio..........................................................................................................52.3.3 Evaluación..................................................................................................................62.3.4 Validación...................................................................................................................62.3.5 Memoria de Trabajo de Grado:..................................................................................6

3 PROCESO.....................................................................................................................7

3.1 ESTUDIAR MODELOS DE MEJORA DE PROCESOS DE DESARROLLO DE SOFTWARE EXISTENTES (CMMI, MOPROSOFT, COMPETISOFT)......................................................13.2 REALIZAR ANÁLISIS CULTURAL Y ORGANIZACIONAL DE MIPYMES_DS COLOMBIANAS................................................................................................................13.3 OBTENER REQUERIMIENTOS ESPECÍFICOS DE UNA (1) MIPYME_DS COLOMBIANA EN CUANTO A PROCESOS DE SOFTWARE DE ÉSTA...........................................................13.4 ADAPTAR UN MODELO ESPECÍFICO PARA LA MIPYME_DS COLOMBIANA DE LA CUAL SE OBTUVIERON LOS REQUERIMIENTOS ESPECÍFICOS...........................................23.5 EVALUAR LA CONSISTENCIA INTERNA Y LA COMPLETITUD DEL MODELO PROPUESTO.....................................................................................................................23.6 MEDIR LA UTILIDAD POTENCIAL DEL MODELO PROPUESTO.....................................23.7 REFINAR EL MODELO PROPUESTO, A PARTIR DE LOS RESULTADOS DE LA VALIDACIÓN DEL MISMO................................................................................................3

4 GESTIÓN DEL PROYECTO..........................................................................................4

4.1 ESTIMACIÓN DE LA DURACIÓN DEL PROYECTO (ELABORACIÓN DEL CRONOGRAMA)...............................................................................................................44.2 ESTIMACIÓN DEL COSTO DEL PROYECTO (PRESUPUESTO).......................................74.3 ESTIMACIÓN DE LOS RIESGOS DEL PROYECTO (ANÁLISIS DE RIESGOS)...................8

5 MARCO TEÓRICO / ESTADO DEL ARTE..................................................................11

5.1 TRABAJOS IMPORTANTES EN EL ÁREA...................................................................11

Página i


5.1.1 MoProSoft.................................................................................................................115.1.2 CompetiSoft...............................................................................................................11

5.2 FUNDAMENTOS Y CONCEPTOS RELEVANTES PARA EL PROYECTO..........................115.2.1 Metodologías Ágiles..................................................................................................115.2.2 CMMI........................................................................................................................125.2.3 Factor Humano en Ingeniería de Software..............................................................125.2.4 People CMM.............................................................................................................135.2.5 MIPyMES..................................................................................................................13

6 REFERENCIAS Y BIBLIOGRAFÍA..............................................................................14

6.1 REFERENCIAS.........................................................................................................146.2 BIBLIOGRAFÍA PROPUESTA PARA EL DESARROLLO DEL TRABAJO DE GRADO.......16

Página ii


1 Oportunidad o Problemática

¿Por qué falla un proceso de software? Para nadie es un secreto que 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 [28]. El software es un producto muy particular, ya que es 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 [7].

Sin embargo, existen algunas aproximaciones. La manera de desarrollar software ha sufrido varios cambios a través del tiempo, y todos éstos giran en torno a la “mejor manera de hacer software”. La palabra mejor abarca todas las partes participantes en el proceso, tanto clientes como desarrolladores, usuarios, herramientas, métodos, técnicas, procesos, etc. Pues se refiere a la calidad del producto, su precio y al mismo tiempo al costo de desarrollo del mismo. Esta es la motivación para la existencia de las técnicas de mejoramiento del proceso SPI, tales como CMMI (modelo norte-americano) y SPICE (modelo europeo). Dichas técnicas son profundizadas en la Sección 5 Marco Teórico / Estado del Arte.

1.1 Descripción de la Oportunidad o ProblemáticaLos modelos de mejora de procesos de construcción de software existentes fueron desarrollados pensando en grandes empresas de cultura Norte-Americana o Europea y no Latina. Aquí se evidencian dos variables problema cuando de MIPyMES_DS Colombianas se habla: Tamaño y Cultura.

Sin embargo, el tamaño de empresas para el que fueron diseñados estos modelos también es un inconveniente para las MIPyMES_DS del resto del mundo (incluso de Estados Unidos de América y de Europa); lo que revela otra necesidad, pues la mayoría de organizaciones desarrolladoras de software del mundo están dentro de ésta categoría [27], [20] y además conforman uno de los sectores más representativos de la economía mundial [1]. Es el caso de países como Estados Unidos, Brasil, Canadá, India, China, y Finlandia, en los que las pequeñas compañías de software que cuentan con menos de 50 empleados representan hasta un 85% de las compañías de software [30], [8].

Por años, las pequeñas organizaciones de todo el mundo han buscado ayuda con su iniciativa de mejora y han hecho repetidas solicitudes de mapear y adaptar CMM a sus necesidades pues presentan bastantes inconvenientes con este modelo, como: demasiada documentación, estructura de administración no relacionada, alcance inaplicable, alto requerimiento de recursos, alto costo de entrenamientos, falta de guías y prácticas no relacionadas [6]. Estas afirmaciones son respaldadas además por el estudio que realizó el Departamento de Defensa de los Estados Unidos para determinar la aplicabilidad de CMM a las pequeñas empresas de software, que encontró que éstas enfrentan no sólo una falta de recursos sino que también deben realizar la tarea de de basar sus iniciativas de mejora de procesos en prácticas que no aplican a pequeñas empresas de software [5].

Se podría pensar entonces en un modelo distinto a CMM, como SPICE pero en general el problema radica en una de las variables mencionadas anteriormente: El tamaño. Pero, ¿Tamaño de las empresas o de los modelos existentes? En realidad, de ambos. Pues el tamaño de las MIPyMES también es una gran limitante por los recursos que demandan una implantación, ejecución y evaluación de un modelo de mejora de procesos. Recursos como esfuerzo, tiempo y presupuesto [2], [25], [1], [31], [27] son los que impiden incluso a MIPyMES_DS Norte Americanas la implementación de estos modelos [4], [31], [38], [14], [20], [27].

Esto no deja un panorama muy alegre para las Micro, Pequeñas y Medianas empresas Desarrolladoras de Software de otros países, sobre todo Latinoamericanas, ya que éstas, además de lidiar con la variable Tiempo, lidian con la variable Cultura, pues las diferencias culturales juegan un papel fundamental en el

Página 1 Preparado por el Grupo Investigación Istar- Versión 1.05 – 01/08/2010

- <Guía Metodológica>éxito o fracaso de la implantación de modelos de mejora de procesos [15]. Las MIPyMES_DS Colombianas se ven seriamente afectadas por esta ausencia de un modelo específicamente adaptado o desarrollado para ellas, que tenga en cuenta éstas dos variables: Tamaño y Cultura, como se muestra en la Ilustración 1.

Ilustración 1 - Problemática ProSoftCol

1.2 FormulaciónUn modelo de mejora de procesos de construcción de software específicamente adaptado para MIPyMES Colombianas 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; por medio de la evaluación y certificación de los mismos; como lo muestra la Ilustración 2.



Ilustración 2 - Propuesta ProSoftCol

1.3 JustificaciónTanto el Gobierno Nacional de Colombia como Fedesoft son conscientes 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, 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 a nueva dinámica de los mercados internacionales de software[8]. 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 [8] [17]; es por esto que hasta la fecha en Colombia existen 16 empresas certificadas en CMMI [8], [11].

Sin embargo, aquí se vuelve a hacer evidente la variable problema Tamaño; pues en Colombia existen alrededor de 1000 empresas desarrolladoras de software, pero sólo 20 de ellas tienen más de 20 ingenieros [16], lo que indica que un 98% son empresas muy pequeñas [20] que no hacen uso de ésta oferta tecnológica con la que cuenta el país [12], [8]. Por esto, se puede deducir que existe una necesidad de un modelo de mejoras de procesos que ayude a éstas organizaciones (MIPyMES_DS) a mejorar la calidad de sus procesos y productos para así aumentar su competitividad dentro del mercado nacional e internacional.



1.4 Impacto Esperado del ProyectoEl proyecto se inicia como un trabajo de grado para optar por el título de Ingeniero de Sistemas en la Pontificia Universidad Javeriana, se espera que los entregables de este hito se manifiesten en contribuciones al entorno (mundo real), es decir, una (1) MIPyME_DS Colombiana, solucionando su inconveniente más relevante en cuanto a procesos de software (KPA); y al conocimiento (comunidad académica) publicando un (1) artículo científico que transmita el conocimiento adquirido durante esta experiencia.

El objetivo a largo plazo es que los entregables de este hito sean la base para un proyecto más amplio en el que se pueda llegar a establecer un modelo generalizado para las MIPyMES_DS Colombianas, para lo cual es necesaria una cantidad considerable de recursos y además, de tiempo.



2 Descripción del Proyecto

Esta sección presenta la descripción general del proyecto. Cubre los aspectos más importantes para entender lo que se pretende realizar.

2.1 Objetivo generalAdaptar un modelo de mejora de procesos de construcción de software para micro, pequeñas y medianas empresas Colombianas.

2.2 Fases Metodológicas y 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.3 Entregables o Resultados Esperados

2.3.1 Área De Proceso Clave (KPA):

Modelos como CMM, SPICE y BOOTSTRAP definen típicamente los niveles de la madurez del proceso a través de la identificación y asesoría de varios atributos clave. Estudios publicados de EEUU [19] y Europa [38] reportan bastantes beneficios de negocio [3]. Por esta razón, ProSoftCol se definirá en Áreas de Proceso (conjunto de prácticas relacionadas que son ejecutadas de forma conjunta para conseguir un conjunto de objetivos), y en este hito del proyecto el entregable será 1 Área de Proceso Clave (Área de Proceso más relevante, que enmarca metas específicas que conllevan a una mejora significante).

Ésta KPA es, en términos de la metodología usada para este proyecto (Ver Sección 3 Proceso), un método basado en conceptos y modelos existentes; el cual, no cambiará ni creará un modelo, pero sí cambiará su implementación dentro de un contexto particular: Las MIPyMES_DS Colombianas.

2.3.2 Caso de EstudioEsta Área de Proceso Clave será el resultado de un caso de estudio de una (1) MIPyME_DS Colombiana, localizada en Bogotá. Luego de cumplir la Fase Metodológica 3.3 (Ver Seccción 3. Proceso)


- <Guía Metodológica>se tendrán los requerimientos específicos de ésta, y se procederá a desarrollar la KPA (Ver Sección 3 Proceso, Fase Metodológica 3.4).

2.3.3 EvaluaciónEl director de trabajo de grado y la estudiante realizarán una evaluación de la consistencia interna del modelo (Ver Sección 3 Proceso, Fase Metodológica 3.5)

2.3.4 ValidaciónSe validará la utilidad potencial del artefacto (KPA) con la organización. (Ver Sección 3 Proceso, Fase Metodológica 3.6)

2.3.5 Memoria de Trabajo de Grado:Para la memoria utilizar la plantilla de Microsoft Word que se ha definido para la memoria de Trabajo de Grado, en el departamento de Sistemas de la Facultad de Ingeniería de la Pontificia Universidad Javeriana. La memoria es un informe general del Trabajo de Grado.



3 Proceso

La metodología que se utilizará para realizar este proyecto es la de Investigación Científica Basada en el Diseño de Sistemas de Información [18]. Este paradigma busca crear artefactos (innovaciones), clasificados en:

- Conceptos, 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.

Este paradigma trabaja sobre un marco de referencia específico, dentro del cual se llevarán a cabo las fases metodológicas de este proyecto. La Ilustración 3 muestra el marco de referencia original y la Ilustración 4 muestra su adaptación/mapeo a este proyecto.

La Investigación Científica Basada en el Diseño de Sistemas de Información consiste en tres (3) ciclos: Relevancia, Diseño y Rigor; los resultados de cada ciclo se pueden observar en la Ilustración 4 (de derecha a izquierda) como los 3 rectángulos que la conforman, así:

- El ciclo de Relevancia da como resultado el Conocimiento- El ciclo de Diseño da como resultado el Artefacto como tal (investigación)- El ciclo de Rigor da como resultado el Entorno

Dada la limitación de tiempo, en este proyecto se realizará únicamente una iteración de cada ciclo.



Ilustración 3 - Marco de Referencia Investigación Científica Basada en Diseño de Sistemas de Información [18]

Página 1


Ilustración 4 - Adaptación Marco de Referencia Investigación Científica Basada en Diseño de Sistemas de Información a ProSoftCol

Página 2

- <Guía Metodológica>A continuación, se describirá la Ilustración 4 por medio de las fases metodológicas, actividades y entregables del proyecto.

3.1 Estudiar modelos de mejora de procesos de desarrollo de software existentes (CMMI, MoProSoft, CompetiSoft)El 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 artefacto.

Para lograr el rigor se deben aplicar apropiadamente las bases y metodologías existentes, por esto, el entregable para ésta fase metodológica es un documento que contenga los aspectos más relevantes de los modelos de mejora de procesos existentes, en particular CMMI-MoProSoft-CompetiSoft, 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 Figura 4, el entregable es representado por la flecha azul emergente del Conocimiento, es decir, Conocimiento Aplicable.

3.2 Realizar análisis cultural y organizacional de MIPyMES_DS ColombianasTeniendo en cuenta que lo que hace a éste contexto diferente de aquél para el que los modelos de mejora de procesos existentes fueron pensados son 2 variables: Tamaño y Cultura (Ver Sección 1.1. Descripción de la Oportunidad o Problemática), es necesario agregar al ciclo de Rigor la obtención del conocimiento de la cultura organizacional de las MIPyMES_DS Colombianas en general, de modo que al Conocimiento Aplicable se le suma un documento que contenga las principales características de la cultura organizacional Colombiana (en empresas de software) y una comparación de ésta con la cultura organizacional Norte-Americana

3.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. En este caso, el contexto son las MIPyMES_DS Colombianas, y se elegirá una (1) de éstas para tener un caso representativo.

Para realizar el levantamiento de requerimientos específicos 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). Dicho enfoque o marco, se establece considerando que:

- Las organizaciones consisten en personas, procesos y tecnologías

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


- <Guía Metodológica>El entregable para esta fase metodológica es un documento de especificación requerimientos de la MIPyME_DS elegida, que en la Ilustración 4 es representado por la flecha azul emergente del Entorno, es decir, las Necesidades de Negocio.

3.4 Adaptar un modelo específico para la MIPyME_DS Colombiana de la cual se obtuvieron los requerimientos específicosEn el ciclo de Diseño se construirá el artefacto (ProSoftCol) que intentará satisfacer las Necesidades de Negocio (Ver Sección 3.3) de la organización, utilizando el Conocimiento Aplicable (Ver Secciones 3.1 y 3.2). El entregable para esta fase metodológica es el propio artefacto, que como se mencionó anteriormente (Ver Sección 2.3.1), 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 Figura 4, el entregable es representado en la parte superior de Investigación, como la Construcción de ProSoftCol.

3.5 Evaluar la consistencia interna y la completitud del modelo propuestoEl ciclo de Diseño tiene dos (2) fases complementarias, construcción (Ver Sección 3.4) y evaluación del artefacto, que en la Figura 4 está representada como la flecha negra emergente de la Construcción de ProSoftCol hacia la Validación de su Utilidad Potencial.

El entregable de ésta fase es la evaluación que se realizará internamente, es decir, sin tener en cuenta a las personas que conforman la organización, y se hará por medio de una lista de chequeo que mida completitud, consistencia, constitución y cumplimiento de requerimientos específicos.

3.6 Medir la utilidad potencial del modelo propuestoAl tener las Necesidades de Negocio de la organización se van a obtener unas condiciones previas al proyecto, 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 (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).

Esta medición se realizará por medio de TAM (Technology Acceptance Model), 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 del artefacto realizado [36]. 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, como se muestra en las Ilustraciones 5 y 6.



Ilustración 5 - TAM Original [22]

Sin embargo, existe también una versión modificada (validada) mucho más simple, como lo muestra la Figura 6:

Ilustración 6 - TAM Validado [22]

Para ésto se utilizará un instrumento particular, dentro de las siguientes opciones:- Encuesta- Taller- Presentación del Artefacto ante la organización- Utilización de un aspecto práctico del artefacto

La implementación del artefacto 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, el entregable de esta fase metodológica es el resultado de la Validación de la Utilidad Potencial del artefacto dentro de la organización.

3.7 Refinar el modelo propuesto, a partir de los resultados de la validación del mismo.La Validación de la Utilidad Potencial del artefacto generará una retro-alimentación que mejorará el entendimiento del problema y la forma en que el artefacto lo soluciona.

El entregable de ésta fase metodológica es un documento que contiene los puntos débiles y fuertes del artefacto 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 Figura 4 como la flecha negra emergente de la Validación de la Utilidad Potencial, hacia la Construcción de ProSoftCol.



4 Gestión del Proyecto

4.1 Estimación de la duración del Proyecto (Elaboración del Cronograma)Para la realización de este proyecto se cuenta con un total de 18 semanas, desde el 24 de Enero de 2011 hasta el 4 de Junio de 2011. Para hacer una estimación acertada se deben tener en cuenta los siguientes factores:

- El trabajo de grado se hará en individualmente (una sola estudiante)

- Dado que un crédito equivale a 48 horas de trabajo total del estudiante, en un semestre de 16 semanas (sin contar el período de pruebas finales de evaluación), un crédito implicará 3 horas semanales de trabajo del estudiante incluidas las horas presenciales y las horas autónomas. Esto implica, que a la asignatura Trabajo de Grado se le deberán dedicar como mínimo 12 horas de trabajo semanales (contando las 2 horas presenciales de la reunión con el director los días Lunes de 10 AM – 12 M).

- La estudiante que realizará el trabajo: o Inscribirá 10 créditos durante el tiempo de la realización del proyecto (2011-1), de los

cuales, 4 pertenecen a la asignatura Trabajo de Grado. o Tiene asignadas las monitorias de Especialización en Arquitectura Empresarial de

Software e Ingeniería de Software, las cuales consumen 15 horas semanales (ambas). o Empezará a trabajar 1 semana antes de iniciado el semestre académico en el proyecto.o Le dedicará 27 horas de trabajo semanales a la realización del proyecto (incluyendo las 2

horas presenciales de la reunión con el director del Trabajo de Grado), así:

Ilustración 7 - Horario Académico Ximena Higuera Moriones 2011-01

De acuerdo a la Ilustración 7, las horas de trabajo por cada día son:

Día Horas Dedicadas

Lunes 2 horas

Martes 5 horas

Miércoles 5 horas

Viernes 5 horas

Sábado 4 horas

Domingo 6 horas

Total Horas Semanales

27 horas


- <Guía Metodológica>Ilustración 8 - Horas Semanales Dedicadas al Proyecto

Esta dedicación extra de horas se llevará a cabo para evitar que los posibles riesgos (Ver Sección 4.3. Estimación de Riesgos del Proyecto) se presenten, es decir, como una mitigación anticipada.

A continuación se presenta el cronograma del proyecto:

Fase Metodológica Semanas Horas Inicio FinEstudiar modelos de mejora de procesos de desarrollo de software existentes (CMMI – MoProSoft - CompetiSoft)

3 81 Enero 17 de 2011

Febrero 12 de 2011

- Estudiar modelos de mejora de procesos de desarrollo de software existentes: CMMI.

1 27 Enero 17 de 2011

Enero 24 de 2011

- Estudiar modelos de mejora de procesos de desarrollo de software existentes: MoProSoft.

1 27 Enero 25 de 2010

Enero 31 de 2011

- Estudiar modelos de mejora de procesos de desarrollo de software existentes: CompetiSoft

1 27 Febrero 1 de 2011

Febrero 7 de 2011

Realizar análisis cultural y organizacional de MIPyMES_DS Colombianas


Febrero 12 de 2011

- Investigación cultura organizacional MIPyMES_DS Colombianas y Americanas


Febrero 12 de 2011

- Realización Informe con resultados del análisis cultural y organizacional y comparación E.E.U.U. vs Colombia

1 27 Febrero 13 de 2011

Febrero 19 de 2011

Obtener requerimientos específicos de una (1) MIPyME_DS Colombiana en cuanto a procesos de software de ésta

3 81 Febrero 20 de 2011

Marzo 12 de 2011

- Visita a la MIPyME_DS para realización trabajo de campo

2 54 Febrero 20 de 2011

Marzo 5 de 2011

- Realización documento formal S.R.S

1 27 Marzo 6 de 2011

Marzo 12 de 2011

Adaptar un modelo específico para la 6 162 Marzo Abril 23 Página 5 Preparado por el Grupo Investigación Istar- Versión 1.05 – 01/08/2010

- <Guía Metodológica>MIPyMES_DS Colombiana de la cual se obtuvieron los requerimientos específicos

13 de 2011

de 2011

- Hacer relación de conocimiento aplicable vs requerimientos específicos levantados.

1 27 Marzo 13 de 2011

Marzo 19 de 2011

- Realización de la KPA (Diseño del Artefacto)

5 135 Marzo 20 de 2011

Abril 23 de 2011

Evaluar la consistencia interna y la completitud del modelo propuesto

1 27 Abril 24 de 2011

Abril 30 de 2011

- Verificación lista de chequeo para medir completitud ProSoftCol

1 27 Abril 24 de 2011

Abril 30 de 2011

Medir la utilidad potencial del modelo propuesto

3 81 Mayo 1 de 2011

Mayo 21 de 2011

- Exposición ante MIPyME_DS del modelo propuesto y utilización de un aspecto práctico del artefacto

1 27 Mayo 1 de 2011

Mayo 7 de 2011

- Utilización en la MIPyME_DS de un aspecto práctico del artefacto

1 27 Mayo 8 de 2011

Mayo 14 de 2011

- Realización encuesta para medir utilidad potencial del modelo propuesto

1 27 Mayo 15 de 2011

Mayo 21 de 2011

Refinar el modelo propuesto, a partir de los resultados de la validación del mismo

1 27 Mayo 22 de 2011

Mayo 28 de 2011

- Elaboración documento con puntos débiles y fuertes de ProSoftCol. Los débiles deben encontrarse en forma de nuevos requerimientos.

1 27 Mayo 22 de 2011

Mayo 28 de 2011

Formalización Documento Trabajo de Grado y Memoria Trabajo de Grado

1 27 Mayo 29 de 2011

Junio 4 de 2011

Ilustración 9 - Cronograma ProSoftCol



4.2 Estimación del costo del Proyecto (Presupuesto)A continuación se muestra en la Ilustración 10 el presupuesto estimado para el proyecto ProSoftCol, que está realizado con la plantilla especificada para esto, en el Departamento de Sistemas de la Facultad de Ingeniería de la Pontificia Universidad Javeriana.

Ilustración 10 - Presopuesto ProSoftCol

Los detalles de este presupuesto pueden encontrarse en el archivo adjunto HigueraMorionesXimena_TG_Presupuesto.xlsx.



4.3 Estimación de los riesgos del Proyecto (Análisis de riesgos)A continuación se presentará el análisis de riesgos del proyecto ProSoftCol, pues en esta etapa (Ante-Proyecto) se es consciente de los riesgos y vulnerabilidades a las que se está expuesto a enfrentar un Trabajo de Grado.

Probabilidad del Riesgo:

Valor Descripción

Probabilidad de Ocurrencia

0.1 Muy Bajo Sería sorprendente si este evento ocurre

0.3 Bajo Probablemente no ocurra

0.5 Medio Como puede ocurrir, puede que no ocurra

0.7 Alto Probablemente ocurra

0.9 Muy Alto Sería sorprendente si este evento no ocurre

Ilustración 11 - Probabilidad del Riesgo [40]

La Ilustración 11 explica cómo se analizará la probabilidad de riesgo, mostrando que este tendrá un valor numérico con el que se calculará una descripción del significado de cada valor y una descripción que servirá para explicar cómo se puede clasificar un evento [40].

Impacto del Riesgo:La Ilustración 12 muestra el impacto del riesgo dentro de éste proyecto, y sus consecuencias en 4 ámbitos importantes dentro del desarrollo del proyecto, como lo son: Alcance, Calidad, Cronograma y Costo. Los valores aquí mostrados no son exactos, pues esta valoración es cualitativa en parte [40].

Objetivos Muy Bajo(0.05) Bajo(0.1) Medio(0.2) Alto(0.4) Muy Alto(0.8)

Costo Aumento del costo insignificante

Aumento del costo menor al 5%

Aumento del costo entre 5 y 10%

Aumento del costo entre 10-20%

Mas del 20% de incremento en el costo

Calendario Cambios insignificantes dentro del calendario

Menos del 5% de la planificación cambia

Cambia la planificación del 4-6% +

Cambio del cronograma entre 7 y 10% +

Más del 10% de aumento del calendario

Alcance El alcance del proyecto no cambia

Cambios muy pequeños al alcance del proyecto

Cambios notables al alcance del proyecto

Cambios en el alcance negativos para el cliente

El alcance es insuficiente el proyecto es inútil

Calidad La disminución de la calidad es nula

Aplicaciones muy exigentes se ven afectadas

Requiere reducción de calidad

Reducción de calidad inaceptable para el cliente

El proyecto es inservible.


- <Guía Metodológica>Ilustración 12 Impacto del Riesgo [40]

Probabilidad Vs ImpactoProbabilidad \ Impacto

Muy Bajo Bajo Medio Alto Muy Alto

Muy Bajo Tolerable Tolerable Tolerable Tolerancia Media

Tolerancia Media

Bajo Tolerable Tolerable Tolerancia Media

Tolerancia Media

Tolerancia Media

Medio Tolerable Tolerancia Media

Tolerancia Media

Tolerancia Media

Intolerable

Alto Tolerancia Media

Tolerancia Media

Tolerancia Media

Intolerable Intolerable

Muy Alto Tolerancia Media

Tolerancia Media

Intolerable Intolerable Intolerable

Ilustración 13 Probabilidad Vs Impacto Riesgos [40]

La Ilustración 13 muestra la tolerancia que se tendrá en el proyecto ProSoftCol para cada riesgo, dependiendo de su probabilidad y de su impacto.

A continuación, la Ilustración 14 muestra la identificación de riesgos que se puedan presentar durante el proyecto ProSoftCol y a su vez su probabilidad, impacto y tolerancia.

Riesgo Probabilidad Impacto Tolerancia Prevención Contingencia

Tiempo designado para ciclo de Rigor no es suficiente

Bajo (0.3) Medio (0.2) Tolerancia Media

Añadidura de 15 horas extra de trabajo semanal en el cronograma.

Redefinición tiempos de planeación para cumplir ciclo

Tiempo designado para ciclo de Relevancia no es suficiente

Bajo (0.3) Alto (0.4) Tolerancia Media



Tiempo designado para ciclo de Diseño no es suficiente

Medio (0.5) Alto (0.4) Tolerancia Media



Mala planeación en Cronograma

Medio (0.5) Muy Alto (0.8)

Intolerable Añadidura de 15 horas extra de trabajo semanal en el cronograma.

Realización de un nuevo cronograma dentro de las 4 primeras semanas del proyecto.

Tiempo de reunión semanal con director no suficiente

Bajo (0.3) Medio (0.2) Tolerancia Media

Planeación de temas a tratar en reuniones por parte de estudiante.

Consultar con director si es posible realizar


- <Guía Metodológica>una reunión más semanal.

Baja disponibilidad por parte del director

Muy Bajo (0.1)

Muy Alto (0.8)

Tolerancia Media

Confirmación de temas de interés y áreas de investigación preferidas por director

Charlas y consultas acerca del interés por el proyecto

Baja disponibilidad por parte de la estudiante

Muy Bajo (0.1)

Muy Alto (0.8)

Tolerancia Media

Escogencia tema de trabajo de grado dentro de área de interés

Retiro asignatura Trabajo de Grado

Pérdida de documentación

Bajo (0.3) Muy Alto (0.8)

Intolerable Ubicación de toda la documentación en Repositorio DropBox

Utilización de información registrada en DropBox

No se encuentra MIPyME_DS para realizar caso de estudio

Bajo (0.3) Muy Alto (0.8)

Intolerable Plazo máximo para conseguir MIPyME_DS vence Enero 7 de 2011. Búsqueda iniciada desde este semestre.

Utilizar encuestas u otro tipo de elemento para obtención de requerimientos y validación de utilidad potencial

Disponibilidad de MIPyME_DS para caso de estudio es poca

Medio (0.5) Muy Alto (0.8)

Intolerable Confirmación previa con MIPyME_DS del trabajo que se llevará a cabo (presentación propuesta).

Demostrar a MIPyME_DS los beneficios que puede obtener con este modelo

Pérdida o robo de equipo propio

Bajo (0.3) Bajo (0.1) Tolerable Ubicación de toda la información y documentación en Repositorio DropBox

Utilizar equipos disponibles Universidad Javeriana.

Ilustración 14 - Riesgos ProSoftCol



5 Marco Teórico / Estado del Arte

5.1 Trabajos Importantes en el área

5.1.1 MoProSoftLos intentos de México para mejorar su industria del software conllevaron al desarrollo de Modelo de Procesos para la Industria del Software (MoProSoft) en el año 2002 [1]. Este modelo se construyó sobre las prácticas de CMMI, ISO 9000-2000 y PMBOK, y en 2005 fue aprobado por el Gobierno Mexicano junto con EvalProSoft (método de evaluación y asesoría) como un estándar NMX-059-NYCE- 2005.

Su estructura se basa en la forma en la que las empresas desarrolladoras de software mexicanas están conformadas y se divide en 3: Alta Dirección (prácticas de administración), Dirección Media (prácticas de proceso, proyecto y administración alineadas con metas de alta dirección) y Operaciones (prácticas de desarrollo y mantenimiento de software). Los procesos de MoProSoft se relacionan unos con otros, en la medida en que la salida de un producto es la entrada de otro

5.1.2 CompetiSoftEn 2005, investigadores y practicantes reconocieron la importancia de un marco de mejora y certificación para las MIPyMES, y se propuso CompetiSoft como un modelo para Iberoamérica. Este modelo se construyó sobre las prácticas de las iniciativas Lationamericanas como MoProSoft y Brazilian Process Improvement Model [1].

La estructura del modelo de referencia de procesos se divide en 6: Administración del Proceso (Cuestionario de auto-asesoría que ayuda a las organizaciones en su primer contacto con la mejora y madurez de sus procesos); Administración del Proyecto (Métricas e Indicadores básicos que se pueden alinear a objetivos de procesos); Desarrollo (Basado en lineamientos para desarrollo de requerimientos, análisis y diseño, pruebas y construcción); Mantenimiento (Proceso adaptado de Scrum y Mantema, que tiene 2 niveles: básico, que se concentra en lo urgente y avanzado, que se concentra en lo preventivo); Administración del Negocio (Alineación objetivos de negocio con tecnología de información) y Administración de Recursos (Guía realizada en base a experiencias de otras empresas).

5.2 Fundamentos y conceptos relevantes para el proyecto

5.2.1 Metodologías ÁgilesLos ingenieros de sistemas llevan años buscando un proceso ágil, efectivo y eficiente para organizar las actividades e interacciones de los proyectos de software [33]. El desarrollo de software ágil se ha presentado como una solución a ésta búsqueda desde el 2001 cuando se desarrolló y formuló el “Agile Manifesto” que expone las siguientes premisas:

- Personas y su interacción son más importantes que los procesos y las herramientas- Es más importante el software funcionando que la documentación excesiva- Es mejor crear un ambiente de colaboración y confianza entre el cliente y el desarrollador que

refinar el contrato para prever todos los casos- Es preferible responder al cambio que seguir un plan

Extreme Programming es un modelo de proceso ágil, que se concentra en la producción disciplinada de código y se basa en simplicidad, comunicación, retroalimentación y coraje [21].



5.2.2 CMMIEs un modelo de mejoramiento del proceso que provee un conjunto de prácticas reconocidas por la industria para la productividad, desempeño, costo y satisfacción del cliente en los procesos de ingeniería de sistemas y procesos de desarrollo de software [37]; su objetivo es el logro de procesos óptimos repetibles en el desarrollo de software [34].

Este modelo ayuda a separar funciones organizacionales, establecer metas de mejora así como sus prioridades, proveer una guía para un proceso de calidad y proveer un punto de referencia para evaluar dichos procesos [7]. Existen dos tipos de representaciones:

- Representación Escalonada

Usa niveles de madurez y conjuntos predefinidos de áreas de proceso para definir el camino de mejora. Existen 5 niveles en los que se puede encontrar una organización:

1. Inicial : No hay planeación, estimaciones de costos ni administración. 2. Controlado : Es intuitivo, el proceso depende de los individuos.3. Definido : Cualitativamente se tiene un proceso definido e institucionalizado. 4. Cuantitativamente Controlado : Además de estar definido e institucionalizado

(cualitativamente), el proceso se puede medir. 5. Optimizado : Se realiza retroalimentación para mejorarlos procesos [9].

- 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 objetivos de mejora de la organización [28].

5.2.3 Factor Humano en Ingeniería de SoftwareLas técnicas existentes de mejora de procesos de software hacen énfasis en los procesos o en la tecnología, dejando de lado uno de los 3 vértices del triángulo que contiene los componentes los que cada compañía debe enfocarse (Ilustración 7) para mejorar su desempeño: Las personas [29], [26], [13], [10], [35], [24].

Ilustración 15 - Triángulo Mejora de ProcesosPágina 12 Preparado por el Grupo Investigación Istar- Versión 1.05 – 01/08/2010


Este punto de vista, dio como resultado a un modelo específicamente para las personas: People CMM.

5.2.4 People CMMEs un modelo de calidad para el “lado humano” del desarrollo de software [10]. Los objetivos estratégicos de P-CMM son 3: Mejorar la capacidad de las organizaciones de software incrementando la capacidad de su personal; Asegurar que la capacidad de desarrollo de software sea un atributo de de la organización en vez de que lo sea sólo de algunos individuos y alinear la motivación de los individuos con la de la organización [29].

Está compuesto por 5 niveles de madurez (Inicial, Gestionado, Definido, Predecible, En Optimización), estos describen: la evolución de una organización desde un estado inicial caracterizado por una gestión “ad hoc” hasta un estado de innovación y mejora continua de las prácticas de gestión de las personas [32]. Este modelo fue publicado en 1995 y desde entonces ha sido implementado en varias empresas como Intel, Citibank, U. S. Army, Boeing, Ericcson, IBM, Samsung y Pfizer [32].

5.2.5 MIPyMESSe entiende por micro, pequeña y mediana empresa (Artículo 2, Ley 905 de 2004), toda unidad de explotación económica, realizada por persona natural o jurídica, en actividades empresariales, agropecuarias, industriales, comerciales o de servicios, rural o urbana, que responda a dos (2) de los siguientes parámetros:

- Micro Empresa:o Planta de personal de hasta diez (10) trabajadores, oo Activos totales de hasta 501 salarios mínimos legales mensuales vigentes.

- Pequeña Empresa:o Planta de personal entre once (11) y cincuenta (50) trabajadores, oo Activos totales por valor entre quinientos uno (501) y menos de cinco mil (5000) salarios

mínimos mensuales legales vigentes.- Mediana Empresa:

o Planta de personal entre cincuenta y uno (51) y doscientos (200) trabajadores, oo Activos totales por valor entre cinco mil uno (5001) a treinta mil (30000) salarios mínimos

mensuales legales vigentes [23].

Tal como lo muestra la Ilustración 8:

Categoría De Empresas

Valor De Activos No. De Trabajadores

Microempresa Hasta 500 smlmv equivalentes a $204.000.000

Hasta 10

Pequeña Entre 501 y 5000 smlmv equivalentes a $204.408.000 y $2040.000.000

Entre 11 y 50

Mediana Entre 5001 y 30.000 equivalentes a $2040.408.000 y 12.240.000.000

Entre 51 y 200

Ilustración 16 - Clasificación MIPyMES



6 Referencias y Bibliografía

6.1 Referencias- [1] Andrés Aguirre, Cesar Pardo, Wilson Pantoja, Mejia Maria, and Francisco. Pino. Reporte de experiencias

de la aplicación de competisoft en cinco mipymes colombianas. Revista Escuela de Ingeniería de Antioquia, 13:107–122, Julio 2010.

- [2] 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, pages 328–335, 2006.

- [3] 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, pages 211–214, 2003.

- [4] J. Batista and António Dias de Figueiredo. Spi in a very small team: a case with cmm. Software Process: Improvement and Practice, 5(4):243–250, 2000.

- [5] Judith G. Brodman and Donna 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, pages 331–340, Los Alamitos, CA, USA, 1994. IEEE Computer Society Press.

- [6] Judith G. Brodman and Donna L. Johnson. 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, pages 661–662, New York, NY, USA, 1997. ACM.

- [7] B. Bruegge. Ingeniería de Software Orientada a Objetos. Primera edición, 2002.

- [8] Luis Felipe Campo. Modelos de capacidad y madurez y la industria del software en colombia. Revista Generación Digital, 7:22–25, 2008.

- [9] Mary Beth Chrissis, Mike Konrad, and Sandy Shrum. CMMI:Guidelines for Process Integration and Product Improvement. Addison Wesley, 2003.

- [10] William; Miller Sally Curtis, Bill; Hefley. The people capability maturity model: Guidelines for improving the workface.

- [11] Union Temporal: Red Colombiana de Calidad de Software RCCS. Red colombiana de calidad de software.

- [12] Cámara de Comercio de Bogotá. Balance Tecnológico Cadena Productiva Desarrollo de Software en Bogotá y Cundinamarca. Cámara de Comercio de Bogotá, 2006.

- [13] T. DeMarco and T. Lister. Peopleware: Productive projects and teams, 1999.

- [14] T. Dyba. An empirical investigation of the key factors for success in software process improvement. 31(5):410–424, 2005.

- [15] T. Dyba, N. B. Moe, and E. M. Mikkelsen. An empirical investigation on factors affecting software developer acceptance and utilization of electronic process guides. In Proc. 10th Int Software Metrics Symp, pages 220–231, 2004.

- [16] Sara M. Gallardo. Cara y sello impacto del tlc en la ingeniería de sistemas. Magazine, 2005.


- <Guía Metodológica>- [17] Sara M. Gallardo. El tlc bajo la lente de fedesoft. Magazine, 2005.

- [18] Alan R. Hevner and Salvatore T. March. The information systems research cycle. Computer, 36:111–113, 2003.

- [19] H. Krasner. The Payoff for Software Process Improvement: What it is and How to Get It. IEE Computer Society Press, 1999.

- [20] C. Y. Laporte, S. Alexandre, and A. Renault. Developing international standards for very small enterprises. Computer, 41(3):98–101, 2008.

- [21] Craig Larman. Agile and Iterative Development: A Manager’s Guide. Addison Wesley, 2003.

- [22] Qingxiong. Ma and Liping Liu. The technology acceptance model: A meta-analysis of empirical findings. Journal of Organizational and End User Computing, 16:59–72, 2004.

- [23] Industria y Turismo Ministerio de Comercio. Mipymes portal empresarial colombiano. Web, 2005.

- [24] E. Mnkandla and B. Dwolatzky. Balancing the human and the engineering factors in software development. In Proc. 7th AFRICON Conf AFRICON in Africa, volume 2, pages 1207–1210, 2004.

- [25] 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, pages 475–481, 2009.

- [26] Van Nostrand. The Psychology of Computer Programming. 1971.

- [27] H. Oktaba, F. Garcia, M. Piattini, F. Ruiz, F. J. Pino, and C. Alquicira. Software process improvement: The competisoft project. Computer, 40(10):21–28, 2007.

- [28] James Persse. Process Improvement Essentials. O’Reilly, September 2006.

- [29] Ameen Pulikkalakath. Seminar report on people capability maturity model. Master’s thesis, Cochin University of Science and Technology, 2007.

- [30] Ita Richardson and Christiane. Gresse. Why are small software organizations different? IEEE Software, 24, 2007.

- [31] Hossein Saeidian and Natsu Carr. Characterizing a software process maturity model for small organizations. ACM SIGICE Bulletin, 23(1):2– 11, 1997.

- [32] SpaceMinds. People capability maturity model, 2010.

- [33] Consuelo Toro, Victor & Franky. Procesos Ágiles y programación extrema, 2010.

- [34] M. Torres. Software process improvement. Presentation, Marzo 2010.

- [35] Richard & Boehm Barry Turner. People factors in software management: Lessons from comparing agile and plan - driven methods., 2003.

- [36] York University. Theories used in research, technology acceptance model, 2003.

- [37] Michael West. Real Process Improvement Using the CMMI. Auer, 2004.

- [38] Sami Zahran. Software Process Improvement : Practical Guidelines for Businees Success / S. Zahran. Harlow, Inglaterra : Addison-Wesley, 1998.


- <Guía Metodológica>- [40] ANSI, Guía de los Fundamentos de la Dirección de Proyectos. PMBOK tercera edición. Newtown

Square, Pennsylvania: 2000

6.2 Bibliografía Propuesta para el desarrollo del Trabajo de Grado- [1] J. Persse, Process Improvement Essentials. O’Reilly, September 2006.

- [2] B. Bruegge, Ingeniería de Software Orientada a Objetos. primera- edición ed., 2002.

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

- [4] C. Y. Laporte, S. Alexandre, and A. Renault, “Developing international standards for very small enterprises,” Computer, vol. 41, no. 3, pp. 98–101, 2008.

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

- [6] I. Richardson and C. Gresse, “Why are small software organizations different?,” IEEE Software, vol. 24, 2007.

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

- [8] J. G. Brodman and D. L. Johnson, “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), pp. 661–662, ACM,1997.

- [9] 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), pp. 331–340, IEEE Computer Society Press,1994.

- [10] 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, pp. 328–335, 2006.

- [11] 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, pp. 475–481, 2009.

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

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

- [14] S. Zahran, Software Process Improvement : Practical Guidelines for Businees Success / S. Zahran. Harlow, Inglaterra : Addison-Wesley,1998.

- [15] T. Dyba, “An empirical investigation of the key factors for success in software process improvement,” IEEE Transactions on Software Engineering, vol. 31, no. 5, pp. 410–424, 2005.



- [16] T. Dyba, N. B. Moe, and E. M. Mikkelsen, “An empirical investigation on factors affecting software developer acceptance and utilization of electronic process guides,” in Proc. 10th Int Software Metrics Symp, pp. 220–231, 2004.

- [17] S. M. Gallardo, “El tlc bajo la lente de fedesoft.” Magazine, 2005.

- [18] U. T. R. C. de Calidad de Software RCCS., “Red colombiana de calidad de software.”

- [19] S. M. Gallardo, “Cara y sello impacto del tlc en la ingeniería de sistemas.” Magazine, 2005.

- [20] C. de Comercio de Bogotá, Balance Tecnológico Cadena Productiva Desarrollo de Software en Bogotá y Cundinamarca. Cámara de Comercio de Bogotá, 2006.

- [21] H. Krasner, The Payoff for Software Process Improvement: What it is and How to Get It. IEE Computer Society Press, 1999.

- [22] 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, pp. 211–214, 2003.

- [23] A. R. Hevner and S. T. March, “The information systems research cycle,” Computer, vol. 36, pp. 111–113, 2003.

- [24] Y. University, “Theories used in research, technology acceptance model,” 2003.

- [25] Q. Ma and L. Liu, “The technology acceptance model: A meta analysis of empirical findings,” Journal of Organizational and End User Computing, vol. 16, pp. 59–72, 2004.

- [26] C. Toro, Victor & Franky, “Procesos Ágiles y programación extrema,” 2010.

- [27] C. Larman, Agile and Iterative Development: A Manager’s Guide. Addison Wesley, 2003.

- [28] M. West, Real Process Improvement Using the CMMI. Auer, 2004.

- [29] M. Torres, “Software process improvement.” Presentation, Marzo 2010.

- [30] M. B. Chrissis, M. Konrad, and S. Shrum, CMMI:Guidelines for Process Integration and Product Improvement. Addison Wesley, 2003.

- [31] A. Pulikkalakath, “Seminar report on people capability maturity model,” Master’s thesis, Cochin University of Science and Technology, 2007.

- [32] V. Nostrand, The Psychology of Computer Programming. 1971.

- [33] T. DeMarco and T. Lister, “Peopleware: Productive projects and teams,” 1999.

- [34] W. M. S. Curtis, Bill; Hefley, “The people capability maturity model: Guidelines for improving the workface.”



- [35] R. . B. B. Turner, “People factors in software management: Lessons from comparing agile and plan - driven methods.,” 2003.

- [36] E. Mnkandla and B. Dwolatzky, “Balancing the human and the engineering factors in software development,” in Proc. 7th AFRICON Conf AFRICON in Africa, vol. 2, pp. 1207–1210, 2004.

- [37] SpaceMinds, “People capability maturity model,” 2010.- [38] I. y. T. Ministerio de Comercio, “Mipymes portal empresarial colombiano.”Web, 2005.

- [39] C. Tie-jun and C. Jin, “Determinants of innovation capability in small and medium enterprises: an empirical analysis from china,” in Proc. IEEE Int. Engineering Management Conf, pp. 283–286, 2006.

- [40] I. Aaen, A. Börjesson, and L. Mathiassen, “Spi agility: How to navigate improvement projects,” Software Process: Improvement and Practice, vol. 12, pp. 267–281, 2007.

- [41] P. Abrahamsson, “Commitment development in software process improvement: critical misconceptions,” in Proc. 23rd Int. Conf. Software Engineering ICSE 2001, pp. 71–80, 2001.

- [42] S. T. Acuna, N. Juristo, and A. M. Moreno, “Emphasizing human capabilities in software development,” IEEE Software, vol. 23, no. 2, pp. 94–101, 2006.

- [43] K. Alagarsamy, S. Justus, and K. lyakutti, “Implementation specification for software process improvement supportive knowledge management tool,” IET Software, vol. 2, no. 2, pp. 123–133, 2008.

- [44] J. Arent and J. Norbjerg, “Software process improvement as organizational knowledge creation: a multiple case analysis,” in Proc. 33rd Annual Hawaii Int System Sciences Conf, 2000.

- [45] P. G. Armour, “The business of software: the laws of software process,” Commun. ACM, vol. 44, no. 1, pp. 15–17, 2001.

- [46] B. S. Arturo, M. A. Jaime, A. R. J. Francisco, and G. G. E. Maria, “Developing large scale learning objects for software engineering process model,” in Proc. Mexican Int Computer Science (ENC) Conf, pp. 203–208, 2009.

- [47] L. Augustin, D. Bressler, and G. Smith, “Accelerating software development through collaboration,” in Proc. 24rd Int. Conf. Software Engineering ICSE 2002, pp. 559–563, 2002.

- [48] J. Azar, R. K. Smith, and D. Cordes, “Value-oriented requirements prioritization in a small development organization,” IEEE Software, vol. 24, no. 1, pp. 32–37, 2007.

- [49] N. Baddoo and T. Hall, “De-motivators for software process improvement: an analysis of practitioners’ views,” J. Syst. Softw., vol. 66, no. 1, pp. 23–33, 2003.

- [50] I. S. Bajwa, A. Samad, S. Mumtaz, R. Kazmi, and A. Choudhary, “Bpm meeting with soa: A customized solution for small business enterprises,” in Proc. Int. Conf. Information Management and Engineering ICIME ’09, pp. 677–682, 2009.


- <Guía Metodológica>- [51] S. Bandinelli, A. Fuggetta, L. Lavazza, M. Loi, and G. Pietro Picco, “Modeling and improving an

industrial software process,” IEEE Trans. Softw. Eng., vol. 21, no. 5, pp. 440–454, 1995.

- [52] G. M. Bao, M. L. Zheng, J. Yang, and Z. R. Yang, “The selection of technological sources in chinese smes,” in Proc. IEEE Int. Engineering Management Conf, vol. 1, pp. 302–306, 2004.

- [53] V. R. Basili and J. Reiter, R. W., “An investigation of human factors in software development,” Computer, vol. 12, no. 12, pp. 21–38, 1979.

- [54] V. R. Basili and H. D. Rombach, “Tailoring the software process to project goals and environments,” in ICSE ’87: Proceedings of the 9th 8 international conference on Software Engineering, (Los Alamitos, CA, USA), pp. 345–357, IEEE Computer Society Press, 1987.

- [55] R. Baskerville and J. Pries-Heje, “Knowledge capability and maturity in software management,” SIGMIS Database, vol. 30, no. 2, pp. 26–43, 1999.

- [56] R. Baskerville, B. Ramesh, L. Levine, and J. Pries-Heje, “Highspeed software development practices: What works, what doesn’t,” IT Professional, vol. 8, no. 4, pp. 29–36, 2006.

- [57] S. B. Basri and R. V. O’Connor, “Organizational commitment towards software process improvement an irish software vses case study,” in Proc. Int Information Technology (ITSim) Symp. in, vol. 3, pp. 1456–1461, 2010.

- [58] S. Beecham, T. Hall, and A. Rainer, “Software process improvement problems in twelve software companies: An empirical analysis,” Empirical Softw. Engg., vol. 8, no. 1, pp. 7–42, 2003.

- [59] E. Bellini and C. lo Storto, “Cmm implementation and organizational learning: Findings from a case study analysis,” in Proc. Technology Management for the Global Future PICMET 2006, vol. 3, pp. 1256–1271, 2006.

- [60] N. Bevan and M. Azuma, “Quality in use: incorporating human factors into the software engineering lifecycle,” in Proc. Third IEEE Int. Software Engineering Standards Symp. and Forum ’Emerging Int. Standards’. ISESS 97, pp. 169–179, 1997.

- [61] A. Boden, B. Nett, and V. Wulf, “Coordination practices in distributed software development of small enterprises,” in Proc. Second IEEE Int. Conf. Global Software Engineering ICGSE 2007, pp. 235–246, 2007.

- [62] B. W. Boehm, Software Engineering Economics. Prentice Hall, 1981.- [63] Z. Bosnjak, O. Grljevic, and S. Bosnjak, “Crisp-dm as a framework for discovering knowledge in small

and medium sized enterprises’ data,” in Proc. 5th Int. Symp. Applied Computational Intelligence and Informatics SACI ’09, pp. 509–514, 2009.

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

- [65] F. P. Brooks, Jr., “No silver bullet essence and accidents of software engineering,” Computer, vol. 20, no. 4, pp. 10–19, 1987.

- [66] M. Buckley and R. Chillarege, “Discovering relationships between service and customer satisfaction,” in Proc. Conf. Int Software Maintenance, pp. 192–201, 1995.



- [67] A. Calio, M. Antiero, and G. Bux, “Software process improvement by object technology (essi pie 27785-spot),” in Proc. Int Software Engineering Conf, pp. 641–647, 2000.

- [68] J. A. Calvo-Manzano Villalon, G. Cuevas Agustin, T. San Feliu Gilabert, De Amescua Seco, L. Garcia Sanchez, and M. Perez Cota “Experiences in the application of software process improvement in smes,” Software Quality Control, vol. 10, no. 3, pp. 261–273, 2002.

- [69] G. Canfora, F. Garcaa, M. Piattini, F. Ruiz, and C. A. Visaggio, “Applying a framework for the improvement of software process maturity,” Softw. Pract. Exper., vol. 36, no. 3, pp. 283–304, 2006.

- [70] J. Capote, C. Llantén, C. Collazos, and C. Pardo, “Gestión del conocimiento en un programa de mejora de procesos de software en mipymes: Kmspi model,” Revista Facultad de Ingeniería de la Universidad de Antioquia, vol. 50, pp. 205–218, 2009.

- [71] V. Casey and I. Richardson, “A practical application of the ideal model,” Software Process: Improvement and Practice, vol. 9, pp. 123–132, 2004.

- [72] A. Cater-Steel, M. Toleman, and T. Rout, “Process improvement for small firms: An evaluation of the rapid assessment-based method,” Inf. Softw. Technol., vol. 48, no. 5, pp. 323–334, 2006.

- [73] A. P. Cater-Steel, “Low-rigour, rapid software process assessments for small software development firms,” in Proc. Australian Software Engineering Con pp. 368–377, 2004.

- [74] A. P. Cater-Steel, “Process improvement in four small software companies,” in Proc. Australian Software Engineering Conf, pp. 262–272, 2001.

- [75] K. Cedillio, “Accelerating cmmi implementation with psp and tsp in a small organization,” March 2008.

- [76] S.-C. Chen and A. H. I. Lee, “Performance measurement of smes’ employees by fuzzy multi-criteria decision theory,” in Proc. Int Computer Communication Control and Automation (3CA) Symp, vol. 2, pp. 110–113, 2010.

- [77] G. Coleman, “An empirical study of software process in practice,” in Proc. 38th Annual Hawaii Int. Conf. System Sciences HICSS ’05, 2005.

- [78] R. Conradi and A. Fuggetta, “Improving software process improvement,” IEEE Softw., vol. 19, no. 4, pp. 92–99, 2002.

- [79] R. Cruz Mendoza, M. Morales Trujillo, M. Morgado C, H. Oktaba, G. E. Ibarguengoitia, F. J. Pino, and M. Piattini, “Supporting the software process improvement in very small entities through e-learning: The hepale! project,” in Proc. Mexican Int Computer Science (ENC) Conf, pp. 221–231, 2009.

- [80] B. Curtis, “Guest editor’s introduction: The global pursuit of process maturity,” IEEE Softw., vol. 17, no. 4, pp. 76–78, 2000.

- [81] B. Curtis, W. E. Hefley, S. Miller, and M. Konrad, “Developing organizational competence,” Computer, vol. 30, no. 3, pp. 122–124, 1997.


- <Guía Metodológica>- [82] K. C. Dangle, P. Larsen, M. Shaw, and M. V. Zelkowitz, “Software process improvement in small

organizations: a case study,” IEEE Software, vol. 22, no. 6, pp. 68–75, 2005.

- [83] M. K. Daskalantonakis, “Achieving higher sei levels,” IEEE Softw., vol. 11, no. 4, pp. 17–24, 1994.

- [84] V. F. Del Maschi, M. M. Spinola, I. A. Costa, A. L. Esteves, and W. Vendramel, “Practical experience in customization of a software development process for small companies based on rup processes and msf,” in Proc. Portland Int Management of Engineering and Technology Center for, pp. 2440–2457, 2007.

- [85] A. Delgado, F. Ruiz, and I. Garcia, “Mejora continua de procesos de negocio basada en pmcompetisoft integrando bpmm,” in Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, vol. 4, 2010.

- [86] R. L. Della Volpe, F. S. M. Nobre, M. S. P. Pessoa, and M. Spinola, “The role of software process improvement into total quality management: an industrial experience,” in Proc. IEEE Engineering Management Society, pp. 29–34, 2000.

- [87] M. Diaz Ley, F. Garcia, and M. Piattini, “Implementing software measurement programs in non mature small settings,” Software Process and Product Measurement: international Conference, vol. 4895, pp. 154–167, 2008.

- [88] M. Diaz and J. Sligo, “How software process improvement helped motorola,” IEEE Softw., vol. 14, no. 5, pp. 75–81, 1997.

- [89] M. Diaz-Ley, F. Garcia, and M. Piattini, “Implementing a software measurement program in small and medium enterprises: a suitable framework,” IET Software, vol. 2, no. 5, pp. 417–436, 2008.

- [90] M. Diaz-Ley, F. Garcia, and M. Piattini, “Mis-pyme software measurement maturity model-supporting the definition of software measurement programs,” in PROFES ’08: Proceedings of the 9th international conference on Product-Focused Software Process Improvement, (Berlin, Heidelberg), pp. 19–33, Springer-Verlag, 2008.

- [91] J. Dorr, S. Adam, M. Eisenbarth, and M. Ehresmann, “Implementing requirements engineering processes: Using cooperative self-assessment and improvement,” IEEE Software, vol. 25, no. 3, pp. 71–77, 2008.

- [92] J. Duarte, Factores Determinantes y Críticos en Empresas de Servicios, Para la Obtención de Ventajas Competitivas Sostenibles y Transferibles a Estrategias de Globalización: Un Análisis de la Industria del Software. PhD thesis, Universidad Autónoma de Barcelona, Noviembre 2004.

- [93] F. Duvivier and E. Guichard, “Worst-case spice model generation for a process in development using athena, atlas, utmost and spayn,” in Proc. 13th Int Microelectronics Conf. ICM 2001, pp. 11–18, 2001.

- [94] T. Dyba, “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), pp. 148–157, ACM, 2003.

- [95] T. Dyba, “An instrument for measuring the key factors of success in software process improvement,” Empirical Softw. Engg., vol. 5, no. 4 pp. 357–390, 2000.


- <Guía Metodológica>- [96] T. Dybå, “Improvisation in small software organizations,” IEEE Softw., vol. 17, no. 5, pp. 82–87, 2000.-- [97] C. Ebert, “Technical controlling and software process improvement,” J. Syst. Softw., vol. 46, no. 1, pp.

25–39, 1999.

- [98] N. Ehsan, A. Perwaiz, J. Arif, E. Mirza, and A. Ishaque, “Cmmi / spice based process improvement,” in Proc. IEEE Int Management of Innovation and Technology (ICMIT) Conf, pp. 859–862, 2010.

- [99] K. El Emam and A. Birk, “Validating the iso/iec 15504 measures of software development process capability,” J. Syst. Softw., vol. 51, no. 2, pp. 119–149, 2000.

- [100] K. El Emam, B. Shostak, and N. H. Madhavji, “Implementing concepts from the personal software process in an industrial setting,” in Proc. Conf. the Fourth Int Software Process, pp. 117–130, 1996.

- [101] A. El Sheikh and H. Tarawneh, “A survey of web engineering practice in small jordanian web development firms,” in ESEC-FSE ’07: 9 Proceedings of the the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering, (New York, NY, USA), pp. 481– 490, ACM, 2007.

- [102] K. E. Emam, Spice: The Theory and Practice of Software Process Improvement and Capability Determination. Los Alamitos, CA, USA: IEEE Computer Society Press, 1997.

- [103] I. Erfurth and W. R. Rossak, “A look at typical difficulties in practical software development from the developer perspective–a field study and a first solution proposal with upex,” in Proc. 14th Annual IEE Int. Conf. and Workshops the Engineering of Computer-Based Systems ECBS ’07, pp. 241–248, 2007.

- [104] M. E. Fayad, M. Laitinen, and R. Ward, “Software engineering in the small,” Communications of the ACM, vol. 43, no. 3, pp. 115–118, 2000.

- [105] G. Fernandez and J. Triañes, “Modelo de mejora de proceso de software para pymes iso/iec 29110,” 2008.

- [106] A. Ferreira and R. Machado, “Software process improvement in multimodel environments,” in ICSEA ’09: Proceedings of the 2009 Fourth International Conference on Software Engineering Advances, (Washington, DC, USA), pp. 512–517, IEEE Computer Society, 2009.

- [107] R. G. Fordham, “Software process maturity: is level five enough?,” in ICSE ’99: Proceedings of the 21st international conference on Software engineering, (New York, NY, USA), p. 611, ACM, 1999.

- [108] D. Foty, “The spice fet models: pitfalls and prospects (are you an educated model consumer?),” in Proc. rd Design Automation, 1996.

- [109] A. Fuller, P. Croll, and O. Garcia, “Why software engineering is riskier than ever,” in Proc. Second Asia-Pacific Conf. Quality Software, pp. 113–119, 2001.

- [110] T. Galinac, “Empirical evaluation of selected best practices in implementation of software process improvement,” Inf. Softw. Technol., vol. 51, no. 9, pp. 1351–1364, 2009.

- [111] F. Garcia, M. Piattini, F. Ruiz, G. Canfora, and C. A. Visaggio, “Fmesp:- framework for the modeling and evaluation of software processes,” J. Syst. Archit., vol. 52, no. 11, pp. 627–

639, 2006.



- [112] I. Garcia, C. Pacheco, and J. Calvo-Manzano, “Using a web-based tool to define and implement software process improvement initiatives in a small industrial setting,” IET Software, vol. 4, no. 4, pp. 237–251, 2010.

- [113] I. Garcia, C. Pacheco, and D. Cruz, “Adopting an ria-based tool for supporting assessment, implementation and learning in software process improvement under the nmx-i-059/02-nyce-2005 standard in small software enterprises,” in Proc. Eighth ACIS Int Software Engineering Research, Management and Applications (SERA) Conf, pp. 29–35, 2010.

- [114] I. Garcia and L. E. Suarez, “Determining practice achievement in project management using a two-phase questionnaire on small and medium enterprises,” in Proc. Int. Conf. Software Engineering Advances ICSEA 2007, p. 75, 2007.

- [115] G. A. Garcia-Mireles and I. Rodriguez-Castillo, “Software engineering area curricular evaluation method based in moprosoft,” in Proc. Mexican Int Computer Science (ENC) Conf, pp. 272–279, 2009.

- [116] A. Garg, D. P. Goyal, and A. S. Lather, “The influence of the best practices of information system development on software smes; a research scope,” Int. J. Bus. Inf. Syst., vol. 5, no. 3, pp. 268–290, 2010.

- [117] P. Gawrysiak, H. Rybinski, L. Skonieczny, and P. Wiech, “Ami-sme: An exploratory approach to knowledge retrieval for sme’s,” in Proc. ICAS07 Autonomic and Autonomous Systems Third Int. Conf, p. 65, 2007.

- [118] V. Giannikopoulou, I. Hatzakis, and A. Zafeiropoulos, “A technology enhanced flexible learning approach for smes,” in Proc. IEEE 18th Int Symp. Personal, Indoor and Mobile Radio Communications PIMRC 2007, pp. 1–5, 2007.

- [119] B. Giraldo, “Estadísticas de la microempresa en colombia, análisis comparativo 1990-2005,” Abril 2007.

- [120] E. M. Gray and W. L. Smith, “On the limitations of software process assessment and the recognition of a required re-orientation for global process improvement,” Software Quality Control, vol. 7, no. 1, pp. 21–34, 1998.

- [121] T. Grechenig and W. Zuser, “Creating organic software maturity attitudes (cosma) selected principles and activities for software maturity in small and medium software enterprises,” in QSIC ’04: Proceedings of the Quality Software, Fourth International Conference, (Washington, DC, USA), pp. 134–143, IEEE Computer Society, 2004.

- [122] T. Grechenig and W. Zuser, “Creating organic software maturity attitudes (cosma) selected principles and activities for software maturity in small and medium software enterprises,” in Proc. Fourth Int. Conf. Quality Software QSIC 2004, pp. 134–143, 2004.

- [123] G. C. Green, A. R. Hevner, and R. Webb Collins, “The impacts of quality and productivity perceptions on the use of software process improvement innovations,” Inf. Softw. Technol., vol. 47, no. 8, pp. 543–553, 2005.

- [124] P. Grind, “Cmmi en colombia,” Noviembre 2008.



- [125] V. Gruhn, “Process-centered software engineering environments, a brief history and future challenges,” Ann. Softw. Eng., vol. 14, no. 1-4, pp. 363–382, 2002.

- [126] P. Grunbacher, “A software assessment process for small software enterprises,” in Proc. 23rd EUROMICRO Conf. EUROMICRO 97. ’New Frontiers of Information Technology’, pp. 123–128, 1997.

- [127] P. Grünbacher, “A software assesment process for small software enterprises,” IEEE ASSP Magazine, pp. 123–128, 1997.

- [128] L.-C. G. R. d. A. S. A. Guzmán, J. G. and G. C. Agustín, “Guzmán, j. g., lópez-cortijo garcía, r., de amescua seco, a. and agustín, g. c,” Software Process: Improvement and Practice, vol. 11, pp. 261–268, 2006.

- [129] 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, pp. 386–391, 2008.

- [130] N. Habra, S. Alexandre, J.-M. Desharnais, C. Y. Laporte, and A. Renault, “Initiating software process improvement in very small enterprises,” Inf. Softw. Technol., vol. 50, no. 7-8, pp. 763–771, 2008.

- [131] N. e. a. Habra, “Software process improvement in small organizations using gradual evaluation schema.”

- [132] T. Hall, A. Rainer, N. Baddoo, and S. Beecham, “An empirical study of maintenance issues within process improvement programmes in the software industry,” in Proc. IEEE Int Software Maintenance Conf, pp. 422–430, 2001.

- [133] H. A. B. Hansen, C. Koch, and A. Pleman, “Small is beautiful: customer driven software development,” in Proc. Technology and Innovation Management Management of Engineering and Technology PICMET ’99. Portland Int. Conf, vol. 1, 1999.

- [134] A. M. J. Hass, J. Johansen, and J. Pries-Heje, “Does iso 9001 increase software development maturity?,” in Proc. 24th Euromicro Conf, vol. 2, pp. 860–866, 1998.

- [135] O. Hazzan, “Teaching the human aspect of software engineering – a case study,” in SIGCSE ’01: Proceedings of the thirty-second SIGCSE technical symposium on Computer Science Education, (New York, NY, USA), pp. 124–128, ACM, 2001.

- [136] J. Herbsleb, D. Zubrow, D. Goldenson, W. Hayes, and M. Paulk, “Software quality and the capability maturity model,” Commun. ACM, vol. 40, no. 6, pp. 30–40, 1997.

- [137] J. D. Herbsleb and D. R. Goldenson, “A systematic survey of cmm experience and results,” in Proc. 18th Int Software Engineering Conf, pp. 323–330, 1996.

- [138] J. D. Herbsleb and D. R. Goldenson, “A systematic survey of cmm experience and results,” in ICSE ’96: Proceedings of the 18th international conference on Software engineering, (Washington, DC, USA), pp. 323–330, IEEE Computer Society, 1996.

- [139] M. M. Hinkle, “Software quality, metrics, process improvement, and cmmi: An interview with dick fairley,” IT Professional, vol. 9, no. 3, pp. 47–51, 2007.



- [140] D. J. Hoch, S. K. Lindner, C. R. Roeding, and G. Purkert, Secrets of Software Success: Management Insights from 100 Software Firms around the World. Boston, MA, USA: Harvard Business School Press, 1999.

- [141] C. Hofer, “Software development in austria: results of an empirical study among small and very small enterprises,” in Proc. 28th Euromicro Conf, pp. 361–366, 2002.

- [142] J. M. Hogan, G. Smith, and R. Thomas, “The real world software process,” in Proc. Ninth Asia-Pacific Software Engineering Conf, pp. 366–375, 2002.

- [143] R. V. Horvat, I. Rozman, and J. Györkös, “Managing the complexity of spi in small companies,” Software Process: Improvement and Practice, vol. 5, pp. 45–54, March 2000.

- [144] A. Hualde and R. Gomis, “Pyme de software en la frontera norte de méxico: Desarrollo empresarial y construcción institucional de un cluster,” Problemas del Desarrollo: Revista Latinoamericana de Economía, vol. 38, p. 20, Julio-Septiembre 2007.

- [145] D. B. Huang and W. Zhang, “Cmmi in medium & small enterprises: Problems and solutions,” in Proc. 2nd IEEE Int Information Management and Engineering (ICIME) Conf, pp. 171–174, 2010.

- [146] W. S. Humphrey, Introduction to the team software process. Essex,UK, UK: Addison-Wesley Longman Ltd., 2000.

- [147] W. S. Humphrey, Managing technical people: innovation, teamwork, and the software process. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1996.

- [148] A. Hurtado and C. Bastarrica, “Simep-sw hacia una línea de procesos Ágiles agile spsl.” Mayo 2005.

- [149] S. M. Hwang and H. G. Yeom, “Analysis of relationship among iso/iec 15504, cmmi and k-model,” in Proc. 10th ACIS Int. Conf. Software Engineering, Artificial Intelligences, Networking and Parallel/Distributed Computing SNPD ’09, pp. 306–309, 2009.

- [150] F. Ilyas and R. Malik, “Adhering to cmm level 2 in medium size software organizations in pakistan,” in Proc. 7th Int. Multi Topic Conf. INMIC 2003, pp. 434–439, 2003.

- [151] F. F. C. de la Industria del Software y Tecnologías Relacionadas.

- [152] J. J. Jiang, G. Klein, H.-G. Hwang, J. Huang, and S.-Y. Hung, “An exploration of the relationship between software development process maturity and project performance,” Inf. Manage., vol. 41, no. 3, pp. 279–288, 2004.

- [153] L. Jing, “Application of cmmi in innovation management,” in Proc. Int. Conf. Wireless Communications, Networking and Mobile Computing WiCom 2007, pp. 4966–4969, 2007.

- [154] O. Kalayci, “Seven success factors for cmmi based process improvement,” in 7th Annueal CMMI Technology Conference and User Group Sponsored by NDIA & SEI, 2007.


- <Guía Metodológica>- [155] K. Kautz, “Making sense of measurement for small organizations,” IEEE Softw., vol. 16, no. 2, pp. 14–

20, 1999.

- [156] K. Kautz, “Software process improvement in very small enterprises: does it pay off?,” Software Process: Improvement and Practice, vol. 4, pp. 209–226, 1998.

- [157] K. Kautz, H. W. Hansen, and K. Thaysen, “Applying and adjusting a software process improvement model in practice: the use of the ideal model in a small software enterprise,” in Proc. Int Software Engineering Conf, pp. 626–633, 2000.

- [158] K. Kautz and P. A. Nielsen, “Understanding the implementation of software process improvement innovations in software organizations,” Information Systems Journal, vol. 14, pp. 3–22, January 2004.

- [159] K. Kautz and F. Ramzan, “Software quality management and software process improvement in denmark,” in Proc. 34th Annual Hawaii Int System Sciences Conf, 2001.

- [160] T. Kilpi, “Product management challenge to software change process: preliminary results from three smes experiment.,” Software Process: Improvement and Practice, vol. 3, pp. 165–175, 1997.

- [161] J. A. Kim, S. Y. Choi, and T.-H. Kim, “Management environment for software process improvement,” in Proc. Int. Symp. Computer Science and its Applications CSA ’08, pp. 292–296, 2008.

- [162] B. A. Kitchenham, “Evaluating software engineering methods and tool part 1: The evaluation context and evaluation methods,” SIGSOFT Softw. Eng. Notes, vol. 21, no. 1, pp. 11–14, 1996.

- [163] M. Klas, F. Elberzhager, R. van Lengen, T. Schulz, and J. Goebbels, “A framework for the balanced optimization of quality assurance strategies focusing on small and medium sized enterprises,” in Proc. 35 th

Euromicro Conf. Software Engineering and Advanced Applications SEAA ’09, pp. 335–342, 2009.

- [164] M. Kulpa and K. Johnson, Interpreting the CMMI: A Process Improvement Approach. Auerbach Publications, 2003.

- [165] P. Kuvaja, J. Palo, and A. Bicego, “Tapistry—a software process improvement approach tailored for small enterprises,” Software Quality Control, vol. 8, no. 2, pp. 149–156, 1999.

- [166] S. Land, “Results of the ieee survey of software engineering standards users,” in ISESS ’97: Proceedings of the 3rd International Software Engineering Standards Symposium (ISESS ’97), (Washington, DC, USA), p. 242, IEEE Computer Society, 1997.

- [167] 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, p. 27, 2005.

- [168] A. Laryd, T. Orci, and A. L. T. Orci, “Dynamic cmm for small organizations,” in Umeå University, 2000.

- [169] Z. Lei, R. Shouju, F. Procopio Garcia, and L. Zuzhao, “Multiple-value decision supporting application in software production facing global market,” in Proc. IEEE Int Systems, Man, and Cybernetics Conf, vol. 1, pp. 346–351, 2000.

- [170] N. G. Lester, F. G. Wilkie, D. McFall, and M. P. Ware, “Investigating the role of cmmi with expanding company size for small- to mediumsized enterprises,” J. Softw. Maint. Evol., vol. 22, no. 1, pp. 17–31,2010.

- [171] C. Li, H. Li, and M. Li, “A software factory model based on iso9000 and cmm for chinese small organizations,” in Proc. Second Asia-Pacific Conf. Quality Software pp. 288–292, 2001.


- <Guía Metodológica>- [172] S. Licorish, A. Philpott, and S. G. MacDonell, “Supporting agile team composition: A prototype tool for

identifying personality (in)compatibilities,” in Proc. ICSE Workshop Cooperative and Human Aspects Software Engineering CHASE ’09, pp. 66–73, 2009.

- [173] K. R. Linberg, “Software developer perceptions about software project failure: a case study,” J. Syst. Softw., vol. 49, no. 2-3, pp. 177–192, 1999.

- [174] T. LLC, “Empresas cmmi,” 2010.

- [175] H. v. Loon, Process Assessment and ISO/IEC 15504: A Reference Book. Secaucus, NJ, USA: Springer-Verlag New York, Inc., 2007.

- [176] H. v. Loon, Process Assessment and Improvement: A Practical Guide for Managers, Quality Professionals and Assessors (The Kluwer International Series in Engineering and Computer Science). Secaucus, NJ, USA: Springer-Verlag New York, Inc., 2004.

- [177] A. Luqman, “Implementation and analysis of cmmi’s configuration management process area; applicable to "defined"level - 3,” in Proc. First Int. Conf. Information and Communication Technologies ICICT 2005, pp. 296–301, 2005.

- [178] J. M. Luzuriaga, R. Martínez, and A. Cechich, “Setting spi practices in latin america: an exploratory case study in the justice area,” in ICEGOV ’08: Proceedings of the 2nd International Conference on Theory and Practice of Electronic Governance, (New York, NY, USA), pp. 172–177, ACM, 2008.

- [179] T. Makinen, T. Varkoi, and H. Jaakkola, “Assessment of a software process assessment process,” in Proc. Portland Int. Conf. Management of Engineering and Technology PICMET ’01, vol. 1, 2001.

- [180] B. Marilyn and D. Donna, CMMI Assesments: Motivating Positive Change. Addison Wesley Professional, 2005.

- [181] F. Marschall, “Experiences with introducing a new software process model at t-systems,” in Proc. 33rd EUROMICRO Conf. Software Engineering and Advanced Applications, pp. 281–288, 2007.

- [182] G. Martinez, “Mapeo de cmmi con moprosoft,” Noviembre 2004.

- [183] F. Mc Caffery, P. S. Taylor, and G. Coleman, “Adept: A unified assessment method for small software companies,” IEEE Software, vol. 24, no. 1, pp. 24–31, 2007.

- [184] F. McCaffery and G. Coleman, “Lightweight spi assessments: what is the real cost?,” Software Process: Improvement and Practice, vol. 14, pp. 271–178, 2009.

- [185] F. McGovern, “Managing software projects with business-based requirements,” IT Professional, vol. 4, no. 5, pp. 18–23, 2002.

- [186] D. Mishra and A. Mishra, “Efficient software review process for small and medium enterprises,” IET Software, vol. 1, no. 4, pp. 132–142, 2007.

- [187] M. H. N. M. Nasir, R. Ahmad, and N. H. Hassan, “Resistance factors in the implementation of software process improvement project,” in Proc. Int. Symp. Information Technology ITSim 2008, vol. 4, pp. 1–10, 2008.


- <Guía Metodológica>- [188] C. Montangero, J.-C. Derniame, B. A. Kaba, and B. Warboys, “The software process: Modelling and

technology,” in Software Process: Principles, Methodology, Technology, (London, UK), pp. 1–14, Springer-Verlag, 1999.

- [189] M. A. Montoni, A. R. Rocha, and K. C. Weber, “Mps.br: a successful program for software process improvement in brazil,” Software Process: Improvement and Practice, vol. 14, pp. 289–300, 2009.

- [190] M. Montoni, G. Santos, A. R. Rocha, K. C. Weber, and E. E. de Araujo, “Mps model and taba workstation: Implementing software process improvement initiatives in small settings,” in Proc. Fifth Int. Workshop Software Quality WoSQ’07: ICSE Workshops 2007, p. 4, 2007.

- [191] S. D. Muller, P. Kraemmergaard, and L. Mathiassen, “Managing cultural variation in software process improvement: A comparison of methods for subculture assessment,” IEEE Transactions on Engineering Management, vol. 56, no. 4, pp. 584–599, 2009.

- [192] B. Mutafeljia and H. Stromberg, Process Improvement with CMMI v1.2 and ISO Standards. Auerbach Publications, 2009.

- [193] K. Nelson, M. Buche, and H. Nelson, “Structural change and change advocacy: A study in becoming a software engineering organization,”in HICSS ’01: Proceedings of the 34th Annual Hawaii International Conference on System Sciences ( HICSS-34)-Volume 8, (Washington, DC, USA), p. 8047, IEEE Computer Society, 2001.

- [194] M. Niazi and M. A. Babar, “Identifying high perceived value practices of cmmi level 2: An empirical study,” Inf. Softw. Technol., vol. 51, no. 8, pp. 1231–1243, 2009.

- [195] M. Niazi, D. Wilson, and D. Zowghi, “A maturity model for the implementation of software process improvement: an empirical study,” J. Syst. Softw., vol. 74, no. 2, pp. 155–172, 2005.

- [196] M. Niazi, D. Wilson, and D. Zowghi, “A model for the implementation of software process improvement: a pilot study,” in Proc. Third Int Quality Software Conf, pp. 196–203, 2003.

- [197] U. Nikula, P. Oinonen, and L. Hannola, “Extending process improvement into a new organizational unit,” in Proc. Australian Software Engineering Conf. ASWEC ’09, pp. 267–276, 2009.

- [198] F. O’Hara, “European experiences with software process improvement,” in ICSE ’00: Proceedings of the 22nd international conference on Software engineering, (New York, NY, USA), pp. 635–640, ACM, 2000.

- [199] H. Oktaba, “Una aportación latina a estándares internacionales para la industria de software,” Noviembre 2009.

- [200] H. Oktaba, “Moprosoft sin fronteras,” Mayo 2008.

- [201] H. Oktaba, “Proyección internacional de moprosoft,” Julio 2008.

- [202] H. e. a. Oktaba, “Modelo de procesos para la industria de software moprosoft,” 2005.

- [203] H. e. a. Oktaba, “Moprosoft: Modelo de procesos para la industria de software,” 2005.



- [204] A. Omran, “Agile cmmi from smes perspective,” in Proc. 3rd Int. Conf. Information and Communication Technologies: From Theory to Applications ICTTA 2008, pp. 1–8, 2008.

- [205] 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, pp. 153–160, 1999.

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

- [207] D. J. Paulish and A. D. Carleton, “Case studies of software-process improvement measurement,” Computer, vol. 27, no. 9, pp. 50–57, 1994.

- [208] 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., pp. 350 – 361, 1998.

- [209] M. C. Paulk, “How iso 9001 compares with the cmm,” IEEE Softw., vol. 12, no. 1, pp. 74–83, 1995.

- [210] O. Pedreira, M. Piattini, M. R. Luaces, and N. R. Brisaboa, “A systematic review of software process tailoring,” SIGSOFT Softw. Eng. Notes, vol. 32, no. 3, pp. 1–6, 2007.

- [211] F. Pettersson, M. Ivarsson, T. Gorschek, and P. Ohman, “A practitioner’s guide to light weight software process assessment and improvement planning,” J. Syst. Softw., vol. 81, no. 6, pp. 972–995, 2008.

- [212] S. L. Pfleeger, N. Fenton, and S. Page, “Evaluating software engineering standards,” Computer, vol. 27, no. 9, pp. 71–79, 1994.

- [213] M. Piattini, H. Oktaba, F. Pino, M. Orozco, and C. Alquicira, Competisoft: Mejora de Procesos Software para Pequeñas y Medianas Empresas y Proyectos. AlfaOmega, 2009.

- [214] F. J. Pino, F. García, and M. Piattini, “Software process improvement in small and medium software enterprises: a systematic review,” Software Quality Control, vol. 16, no. 2, pp. 237–261, 2008.

- [215] 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), pp. 509–516, ACM, 2009.

- [216] F. J. Pino, F. Garcia, and M. Piattini, “A support tool for rapid software process assessment,” IEEE (Revista IEEE America Latina) Latin America Transactions, vol. 5, no. 4, pp. 218–223, 2007.

- [217] F. J. Pino, F. Garcia, F. Ruiz, and M. Piattini, “Adaptation of the standards iso/iec 12207:2002 and iso/iec 15504:2003 for the assessment of the software processes in developing countries,” IEEE (Revista IEEE America Latina) Latin America Transactions, vol. 4, no. 2, pp. 85–92, 2006.

- [218] F. J. Pino, J. A. Hurtado Alegria, J. C. Vidal, F. Garcia, and M. Piattini in ICSP ’09: Proceedings of the International Conference on Software Process, (Berlin, Heidelberg).

- [219] F. J. Pino, C. Pardo, F. García, and M. Piattini, “Assessment methodology for software process improvement in small organizations,” Inf. Softw. Technol., vol. 52, no. 10, pp. 1044–1061, 2010.


- <Guía Metodológica>- [220] M. Polo, M. Piattini, and F. Ruiz, “Using a qualitative research method of building a software

maintenance methodology,” Softw. Pract. Exper., vol. 32, no. 13, pp. 1239–1260, 2002.

- [221] J. P. Potterveld, “Process documentation and improvement-a transition to the it world,” in Proc. IEE Colloquium IT Support for Business Process Re-Engineering, 1996.

- [222] S. Qin, “Managing process change in software organizations: Experience and reflection,” Software Process: Improvement and Practice, vol. 12, pp. 429–435, 2007.

- [223] A. A. M. Qyser, S. Ramachandram, and M. A. Ashraf, “An evolutionary software product development process for small and medium enterprises (smes),” in Proc. 4th Int. Conf. Emerging Technologies ICET 2008, pp. 298–303, 2008.

- [224] A. A. M. Qyser, S. Ramachandram, and A. Farhan, “A staged capability improvement model for software small and medium enterprises (smes),” in Proc. IEEE Asia-Pacific Services Computing Conf. APSCC ’08, pp. 724–729, 2008.

- [225] S. Ragaisis, S. Peldzius, and J. Simenas, “Mapping cmmi-dev maturity levels to iso/iec 15504 capability profiles,” in TELE-INFO’10: Proceedings of the 9th WSEAS international conference on Telecommunications and informatics, (Stevens Point, Wisconsin, USA), pp. 13–18, World Scientific and Engineering Academy and Society (WSEAS), 2010.

- [226] K. Rautiainen, L. Vuornos, and C. Lassenius, “An experience in combining flexibility and control in a small company’s software product development process,” in Proc. Int. Symp. Empirical Software Engineering ISESE 2003, pp. 28–37, 2003.

- [227] I. Richardson, “Spi models: What characteristics are required for small software development companies?,” in ECSQ ’02: Proceedings of the 7th International Conference on Software Quality, (London, UK), pp. 100–113, Springer-Verlag, 2002.

- [228] I. Richardson, “Software process matrix: a small company spi model,” Software Process: Improvement and Practice, vol. 6, pp. 157–165, September 2001.

- [229] I. Richardson and C. Gresse von Wangenheim, “Guest editors’ introduction: Why are small software organizations different?,” IEEE Software, vol. 24, no. 1, pp. 18–22, 2007.

- [230] 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, pp. 323–328, 2008.

- [231] L. Rivas, M. Perez, L. E. Mendoza, and A. Griman, “Towards a selection model for software engineering tools in small and medium enterprises (smes),” in Proc. Third Int. Conf. Software Engineering Advances ICSEA ’08, pp. 264–269, 2008.

- [232] A. R. C. da Rocha, M. Montoni, K. C. Weber, and E. E. R. de Araujo, “A nationwide program for software process improvement in brazil,” in Proc. 6th Int. Conf. the Quality of Information and Communications Technology QUATIC 2007, pp. 167–176, 2007.

- [233] 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,” International Journal of Software Engineering and Knowledge Engineering, vol. 19, no. 2, pp. 185–211, 2009.



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

- [235] K. Ronkko, O. Lindeberg, and Y. Dittrich, “’bad practice’ or ’bad methods’ are software engineering and ethnographic discourses incompatible?,” in Proc. Int Empirical Software Engineering Symp. n, pp. 204–210, 2002.

- [236] T. P. Rout and A. Tuffley, “Harmonizing iso-iec 15504 and cmmi,” Softw. Process, vol. 12, no. 4, pp. 361–371, 2007.

- [237] K. Sakamoto, K. Nakakoji, Y. Takagi, and N. Niihara, “Toward computational support for software process improvement activities,” in Proc. Int Software Engineering Conf, pp. 22–31, 1998.

- [238] J. Saldaña Ramos, J. Garcia Guzman, A. d. Amescua Seco, and Sanz Esteban, “A study of reported practical experiences about tsp implementations,” Software Process: Improvement and Practice, vol. 13, pp. 397–409, 2008.

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

- [240] G. Santos, M. Montoni, J. Vasconcellos, S. Figueiredo, R. Cabral, 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, pp. 187–198, 2007.

- [241] L. Scott, R. Jeffery, L. Carvalho, J. D’Ambra, and P. Rutherford, “Practical software process improvement - the impact project,” in Proc. Australian Software Engineering Conf, pp. 182–189, 2001.

- [242] D. Sellier, M. Mannion, G. Benguria, and G. Urchegui, “Introducing software product line engineering for metal processing lines in a small to medium enterprise,” in Proc. 11th Int. Software Product Line Conf. SPLC 2007, pp. 54–62, 2007.

- [243] G. Seshagiri, “Continuous process improvement-why wait till level 5?,” in Proc. Twenty-Ninth Hawaii Int System Sciences Conf., vol. 1, pp. 681–692, 1996.

- [244] A. Shaikh, A. Ahmed, N. Memon, and M. Memon, “Strengths and weaknesses of maturity driven process improvement effort,” in Proc. Int. Conf. Complex, Intelligent and Software Intensive Systems CISIS ’09, pp. 481–486, 2009.

- [245] Z. Q. Shang, “The convergence problem in spice,” in Proc. IEE Colloquium SPICE: Surviving Problems in Circuit Evaluation, 1993.

- [246] B. Shen and T. Ruan, “A case study of software process improvement in a chinese small company,” in Proc. Int Computer Science and Software Engineering Conf, vol. 2, pp. 609–612, 2008.

- [247] D. B. Simmons, “Communications: a software group productivity dominator,” Softw. Eng. J., vol. 6, no. 6, pp. 454–462, 1991.


- <Guía Metodológica>- [248] R. Sison, “Investigating the effect of pair programming and software size on software quality and

programmer productivity,” in Proc. Asia- Pacific Software Engineering Conf. APSEC ’09, pp. 187–193, 2009.

- [249] M. Sivashankar, A. M. Kalpana, and A. E. Jeyakumar, “A framework approach using cmmi for spi to indian sme’s,” in Proc. Int Innovative Computing Technologies (ICICT) Conf, pp. 1–5, 2010.

- [250] M. Staples and M. Niazi, “Systematic review: Systematic review of organizational motivations for adopting cmm-based spi,” Inf. Softw. Technol., vol. 50, no. 7-8, pp. 605–620, 2008.

- [251] M. Staples, M. Niazi, R. Jeffery, A. Abrahams, P. Byatt, and R. Murphy, “An exploratory study of why organizations do not adopt cmmi,” J. Syst. Softw., vol. 80, no. 6, pp. 883–895, 2007.

- [252] J. Stats, D. Oxley, and P. O’ Toole, “Identifying and managing risks for software process improvement,” 2007.

- [253] M. Stiglic, M. Verlic, P. Povalej, A. Strmecki, and D. Dinevski, “Elearning for sme employees — a case study on e-learning quality,” in Proc. ITI 2009 31st Int. Conf. Information Technology Interfaces ITI ’09, pp. 467–472, 2009.

- [254] 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), pp. 2319–2323, ACM, 2010.

- [255] V. Suma and T. Nair, “Enhanced approaches in defect detection and prevention strategies in small and medium scale industries,” in Proc.Third Int. Conf. Software Engineering Advances ICSEA ’08, pp. 389–393, 2008.

- [256] M. Suula, T. Makinen, and T. Varkoi, “An approach to characterize a software process,” in Proc. Portland Int. Conf. Management of Engineering & Technology PICMET 2009, pp. 1103–1109, 2009.

- [257] S. Suwanya and W. Kurutach, “An analysis of software process improvement for sustainable development in thailand,” in Proc. 8th IEEE Int. Conf. Computer and Information Technology CIT 2008, pp. 724–729, 2008.

- [258] D. Taylor and G. McGraw, “Adopting a software security improvement program,” IEEE Security & Privacy, vol. 3, no. 3, pp. 88–91, 2005.

- [259] A. Tellez and P. Gomez, “Metodología de desarrollo para la mejora de procesos de software a través del desarrollo dirigido por pruebas,” in Memorias del 3er coloquio interdisciplinario de Doctorado, Universidad Popular Autónoma del Estado de Puebla, México, 2010.

- [260] H. E. Thomson and P. Mayhew, “Approaches to software process improvement,” Software Process: Improvement and Practice, vol. 3, pp. 3–17, 1997.

- [261] A. Tosun, A. Bener, and B. Turhan, “Implementation of a software quality improvement project in an sme: A before and after comparison,” in Proc. 35th Euromicro Conf. Software Engineering and Advanced Applications SEAA ’09, pp. 203–209, 2009.

- [262] G. Tovstiga, D. W. Birchall, and E. Tulugurova, “Determinants of enterprise performance in small technology-intensive enterprises: Intellectual capital and innovation capability in the firm,” in Proc. Portland Int Management of Engineering and Technology Center for, pp. 550–553, 2007.



- [263] M. Umarji and C. Seaman, “Predicting acceptance of software process improvement,” in HSSE ’05: Proceedings of the 2005 workshop on Human and social factors of software engineering, (New York, NY, USA), pp. 1–6, ACM, 2005.

- [264] P. Upadhyay and P. K. Dan, “An explorative study to identify the critical success factors for erp implementation in indian small and medium scale enterprises,” in Proc. Int. Conf. Information Technology ICIT ’08, pp. 295–299, 2008.

- [265] J. Vahaniitty, K. Rautiainen, and C. Lassenius, “Small software organizations need explicit project portfolio management,” IBM Journal of Research and Development, vol. 54, no. 2, 2010.

- [266] E. C. Vargas, H. Oktaba, S. Guardati, and A. L. Laureano, “Agents, case-based reasoning and their relation to the mexican software process model (moprosoft),” in Proc. 31st Annual Int. Computer Software and Applications Conf. COMPSAC 2007, vol. 2, pp. 326–334, 2007.

- [267] T. Varkoi, T. Makinen, and H. Jaakkola, “Process improvement priorities in small software companies,” in Proc. Technology and Innovation Management Management of Engineering and Technology PICMET ’99. Portland In Conf, vol. 1, 1999.

- [268] T. K. Varkoi and T. K. Makinen, “Case study of cmm and spice comparison in software process assessment,” in Proc. Int. Conf. Pioneering New Technologies: Management Issues and Challenges in the Third Millennium Engineering and Technology Management IEMC ’98, pp. 477–482, 1998.

- [269] M. de la Villa, M. Ruiz, and I. Ramos, “Modelos de evaluación y mejora de procesos: Análisis comparativo,” Ceur Workshop Proceedings, vol. 120, pp. 4–4, 2004.

- [270] R. Villarroel, Y. Gomez, R. Gajardo, and O. Rodriguez, “Implementation of an improvement cycle using the competisoft methodological framework and the tutelkan platform,” in Proc. Int Chilean Computer Science Society (SCCC) Conf. of the, pp. 97–104, 2009.

- [271] A. Vladimirescu, “Spice-the third decade,” in Proc. Bipolar Circuits and Technology Meeting the 1990, pp. 96–101, 1990.

- [272] A. J. Walker, “Level 5 process capability achievement: A case study from software engineering research management,” Software Process: Improvement and Practice, vol. 8, pp. 51–62, 2003.

- [273] D. Wall, J. McHale, and M. Pomeroy-Huff, “Case study: Accelerating process improvement by integrating the tsp and cmmi,” in Software Engineering Process Management, June 2007.

- [274] Q. Wang and M. Li, “Measuring and improving software process in china,” in Proc. Int Empirical Software Engineering Symp, 2005.

- [275] Y. Wang and Y. Wang, “Software process in software project management,” in Proc. Int Computer Science and Software Engineering Conf, vol. 2, pp. 594–596, 2008.

- [276] C. G. von Wangenheim, A. Anacleto, and C. F. Salviano, “Helping small companies assess software processes,” IEEE Software, vol. 23, no. 1, pp. 91–98, 2006.

- [277] C. Wei and X. Meimei, “Software company process management and process audit research,” in Proc. Int. Conf. Management and Service Science MASS ’09, pp. 1–4, 2009.


- <Guía Metodológica>- [278] F. G. Wilkie, F. Mc Caffery, D. McFall, N. Lester, and E. Wilkinson, “A low-overhead method for

software process appraisal,” Softw. Process, vol. 12, no. 4, pp. 339–349, 2007.

- [279] F. G. Wilkie, D. McFall, and F. McCaffery, “An evaluation of cmmi process areas for small- to medium-sized software development organizations,” Software Process: Improvement and Practice, vol. 10, pp. 189–201, 2005.

- [280] D. N. Wilson, T. Hall, and N. Baddoo, “A framework for evaluation and prediction of software process improvement success,” J. Syst. Softw., vol. 59, no. 2, pp. 135–142, 2001.

- [281] E. V. Woodward, R. Bowers, V. S. Thio, K. Johnson, M. Srihari, and J. Bracht, “Agile methods for software practice transformation,” IBM Journal of Research and Development, vol. 54, no. 2, 2010.

- [282] Y. Xiaoguang, W. Xiaogang, L. Linpin, and C. Zhuoning, “Research on organizational-level software process improvement model and its implementation,” in Proc. Int. Symp. Computer Science and Computational Technology ISCSCT ’08, vol. 2, pp. 285–289, 2008.

- [283] R. Xu, Y. Xue, P. Nie, Y. Zhang, and D. Li, “Research on cmmi-based software process metrics,” in Proc. First Int. Multi-Symp.s Computer and Computational Sciences IMSCCS ’06, vol. 2, pp. 391–397, 2006.

- [284] Z. Yanyan and X. Renzuo, “A human factors fault tree analysis method for software engineering,” in Proc. IEEE Int. Conf. Industrial Engineering and Engineering Management IEEM 2008, pp. 1971–1975, 2008.

- [285] C. Yoo, J. Yoon, B. Lee, C. Lee, J. Lee, S. Hyun, and C. Wu, “A unified model for the implementation of both iso 9001:2000 and cmmi by isocertified organizations,” J. Syst. Softw., vol. 79, no. 7, pp. 954–961,2006.

- [286] H. Younessi and D. D. Grant, “Using the cmm to evaluate student se projects,” in Proc. Int Software Engineering: Education and Practice Conf, pp. 386–391, 1996.13

- [287] B. Yu, Y. Liu, J. Hu, and K. Lin, “A service-oriented crm for smes based on the enterprise level customer,” in Proc. Int. Conf. Management and Service Science MASS ’09, pp. 1–4, 2009.

- [288] L. Zhang and Y. Li, “Software process improvement for small organizations based on cmmi/tsp/psp,” in School of Computer Science, Henan Polytechnic University, pp. 1213–1216, 2007.

- [289] P. Zhang and D. Tian, “A study on the growth ability of the small medium enterprises based on fuzzy comprehensive evaluation,” in Proc. Int Management and Service Science (MASS) Conf, pp. 1–4, 2010.

- [290] X. Zhao, Z. He, F. Gui, and S. Zhang, “Research on the application of six sigma in software process improvement,” in Proc. IIHMSP ’08 Int Intelligent Information Hiding and Multimedia Signal Processing Conf, pp. 937–940, 2008.

- [291] R. Zurina, R. M. Ali, and S. Ibrahim, “An ispa model evaluation based on critical success factors and selected criteria to support malaysia’s sme environment,” in Proc. 2nd Int Software Engineering and Data Mining (SEDM) Conf, pp. 225–230, 2010.


pegasus.javeriana.edu.copegasus.javeriana.edu.co/~CIS1030IS04/documents/Prop… · Web viewLa...

Documents

Transcript of pegasus.javeriana.edu.copegasus.javeriana.edu.co/~CIS1030IS04/documents/Prop… · Web viewLa...