Conocimiento Base ProSoftCol Ximena Higuera Moriones Este documento pretende que todo el conocimiento que pueda ser aplicable al proyecto ProSoftCol:Guía Metodológica de Mejora de Procesos de Construcción de Software Adaptada para MIPyMES_DS Colombianas quede descrito y bien establecido. Se presentan los 3 modelos que serán la base para el proyecto: CMMI, MoProSoft y CompetiSoft. Para cada modelo se especicará su precedencia o justicación de existencia, su estructura, sus patrones de proceso y sus aportes a ProSoftCol (aunque esto último no hace parte del conocimiento base). Introducción Para entender el alcance de los modelos de mejora de procesos presentados aquí, es necesario tener claro 2 conceptos: Modelo y Proceso. Un modelo es considerado un lineamiento con las mejores prácticas que han sido encontradas y aplicadas por organizaciones altamente funcionales y exitosas; no contiene una secuencia de pasos necesarios para implementar un programa de mejora de procesos, simplemente dice "esto es algo bueno para hacer " [1]. Para el Software Engineering Institute existen 3 dimensiones en las que una organización puede enfocar una mejora: Personas, Procedimientos y Métodos, y Herramientas y Equipos. Lo que encierra a éstas 3 dimensiones se llama proceso, el proceso que se usa dentro de una organización y que permiet alinear la forma en la que se dirige la organización, ya que provee una forma de incorporar el conocimiento de "cómo hacer mejor las cosas". Enfocarse en los procesos permite lidiar con el cambio constante y trabajar de una forma más inteligente (no más dura ni exhaustiva). Con esto se llega a una armación que se ha sostenido por años: "La calidad de un sistema o de un producto está altamente inuenciada por la calidad del proceso que se utiliza para desarrollarlo y mantenerlo y ésta es la premisa fundamental de CMMI [2]. 1 2 CMMI Capability Maturity Model Integration es un modelo para mejora o evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software creado por el Software Engineering Institute (SEI), diseñado para integrar la gran cantidad de modelos que han sido creados a través de los años por ésta y otras organizaciones [1]. Provee un conjunto de prácticas reconocidas por la industria para la productividad, desempeño y costo de desarrollo de software [3] , su objetivo es el logro de procesos óptimos repetibles en el desarrollo de software. En la actualidad hay 3 áreas de interés cubiertas por los modelos de CMMI, éstas son Desarrollo, Adquisición y Servicios. CMMI for Development (CMMI-DEV) • Modelo de referencia que cubre el desarrollo y mantenimiento de las actividdes de aplicación a productos y servicios. • Prácticas ◦ ◦ ◦ ◦ ◦ Proyectos Procesos Ingeniería de Sistemas Ingenieria de Software Ingeniería de Hardware CMMI for Services (CMMI-SVC) • Guías para reducir costos y mejorar la calidad CMMI for Acquisition (CMMI-ACQ) • Mejora de gestión de abastecimiento de servicios y productos • Adquirir soluciones que satisfagan necesidades de la organización Disciplinas de CMMI Actualmente 4 Bodies of Knowledge (Cuerpos de Conocimiento) estan cubiertas cuando se planea mejorar los procesos con CMMI [2]: Ingeniería de Sistemas: Cubre el desarrollo de los sistemas, puede o no incluir software. Ingenieria de Software: Cubre el desarrollo de sistemas de software. Desarrollo Integrado de Productos y Procesos: Es un acercamiento sistemático que logra una colaboración de los stakeholders relevantes a través de la vida del producto para satisfacer las necesidades, expectativas y requerimientos del cliente. 3 Proveedores: Cubre la adquisición de productos que se realiza por medio de los proveedores. Estructura de CMMI CMMI está estructurado de la siguiente manera [1] : Niveles de Madurez (Representación Escalonada) o Niveles de Capacidad (Representación Continua) Áreas de Proceso: Sus componentes están agrupados en 3 categorías • Requeridos • Esperados • Informativos Metas: Genéricas y Especícas Características Comunes Prácticas: Genéricas y Especícas Representación Escalonada Usa niveles de madurez y conjuntos predenidos de áreas de proceso para denir el camino de mejora [2]. Un nivel de madurez signica el desempeño que puede ser esperado de una organización, por ejemplo: organizacionez con nivel de madurez 1 tienen procesos ad-hoc y organizaciones con nivel de madurez 2 tienen una gestión de proyectos básicas. Existen 5 niveles de madurez, y cada uno consuste de varias áreas de proceso [1]: 1 - Inicial Las organizaciones no tienen un proceso estructurado, su desarrollo es caótico y ad-hoc; los presupuestos y el calendario se exceden con frecuencia y la calidad del producto no puede ser predicha. En términos generales no hay absolutamente nada estructurado, y se podría decir que encontrarse en este nivel es algo no deseado, por esto ninguna organización busca obtener una valoración en un nivel de madurez 1 de CMMI. 2 - Controlado Los procesos básicos de gestión son llevados a cabo y además son seguidos y documentados. Es intuitivo, el proceso depende de los inviduos. 4 3 - Denido La organización tiene un conjunto propio de procesos estándar. Las siguientes características de los procesos son claramente denidas: Propósito, entradas, criterios de entrada, actividades, roles, medidas, pasos de vericación, saludas y criterios de salida. La diferencia entre este nivel y el 2 es que en éste los procesos son descritos en más detalle y más rigurosamente. Además, este nivel es más sosticado y organizado, ya se ha desarrollado una identidad de la organización. 4 - Cuantitativamente Controlado La organización controla sus procesos con estadísticas y otras técnicas cuantitativas. La calidad del producto, del servicio y el desempeño del proceso son entendidos en términos estadísticos y son controlados durante el ciclo de vida del proceso. Se concentra en el uso de métricas para tomar decisiones, para medir si hay progreso dentro de la organización y si algún producto mejora. Meintras que en el nivel anterior (3) los procesos son cualitativamente predecibles, aquí son cuantitativamente predecibles. 5 - Optimizado Los procesos son constantemente mejorados, basándose en un entendimiento común de las causas de variación de los mismos. Todas las personas son miembros productivos del equipo, los defectos son reducidos y el producto es entregado a tiempo y con presupuesto planeado. Cómo Alcanzar un Nivel de Madurez Si se quiere alcanzar un nivel de madurez n, se deben satisfacer todas las metas del nivel n-1 y del nivel n. Cada nivel consiste de una cierta cantidad de áreas de proceso (no siempre es la misma cantidad), y cada área de proceso tiene metas para ser cumplidas, que a la vez tienen prácticas asociadas como l muestra la Figura 1. 5 Fig. 1: Representación Escalonada CMMI [1, 2] 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 negocio de la organización [4]. Un nivel de capacidad se enfoca en madurar la habilidad de una organización para realizar, controlar y mejorar su desempeño en un área de proceso. Existen 6 niveles de capacidad [1]: 0 - Incompleto Un proceso incompleto no implementa en su totalidad las prácticas ni genéricas ni especícas del nivel de capacidad 1. Es semejante al nivel 1 de madurez en la representación escalonada. 1 - Desarrollado Es un proceso que se espera que desarrolle todas las prácticas genéricas y especícas de este nivel. Signica que se está haciendo algo, pero no se puede probar si está funcionando o no. 2 - Controlado Se tienen algunas métricas que son constantemente recolectadas y aplicadas. 6 Un proceso controlado es planeado, ejecutado, monitoreado y controlado para proyectos individuales, grupos o procesos que alcanzan un propósito dado. Controlar o administrar los procesos logra tanto los objetivos del modelo para el proceso, tanto como otros objetivos como costo, calendario y calidad. 3 - Denido En este punto existe una forma organizacional de hacer el trabajo, de hacer las cosas, que diere de la forma en que las otras organizaciones lo hacen. Esta forma de hacer las cosas debe estar documentada y medida; las personas deben estar entrenadas en ella y los resultados deben ser rastreados. 4 - Cuantitativamente Controlado Es un proceso denido que es controlado por medio de técnicas estadísticas. Calidad del producto, del servicio, desempeño del proceso y otros objetivos de negocio son entendidos en términos estadísticos y son controlados durante todo el ciclo de vida. 5 - Optimizado Es un proceso que está cuantitativamente controlado y además mejorado, basándose en un entendimiento de las causas comunes de las variaciones del proceso que sean relevantes para el mismo. Se enfoca en mejorar continuamente el desempeño del proceso, a través de mejoras incrementales e innovadoras. Tanto el proceso denido como el conjunto de procesos estándares de la organización son objetivos de mejora. Cómo Alcanzar un Nivel de Capacidad Para alcanzar un nivel de capacidad se deben cumplir las prácticas especícas del área de proceso en la que se quiere alcanzar dicho nivel y además deben ser implementadas todas las prácticas genéricas que existen para dicho nivel de capacidad. Las prácticas genéricas pertenecen a muchas áreas de proceso y no sólo a una, de modo que incluso en esta representación hay conexión y relación entre las áreas de proceso (así la organización escoja una sóla para mejorar) ; tal como lo ilustra la Figura 2. 7 Fig. 2: Representación Continua CMMI [2, 1] La Tabla 1 ilustra las principales diferencias entre la representación escalonada y la continua Tab. 1: Comparación Representaciones CMMI [2] Representación Escalonada Representación Continua La organización selecciona las áreas de proceso según los niveles de madurez La organización selecciona las áreas de proceso y los niveles de capacidad según sus objetivos de mejora de procesos. La mejora se mide utilizando ni- La mejora se mide utilizando ni- veles de madurez, que: veles de capacidad, que: Moden la madurez de un Miden la madurez de un conjunto de procesos en to- proceso particular en toda da la organización la organización Se calican de 1 a 5 Se calican de 0 a 5 Los niveles de madurez se usan para establecer un objetivo y realizar el seguimiento de la mejora de procesos. Los perles de nivel de capacidad se usan para establecer un objetivo y realizar el seguimiento del rendimiento de la mejora de procesos. 8 Componentes Áreas de Proceso Las áreas de proceso son un clúster de las buenas prácticas en un área, que cuando se implementan colectivamente satisfacen un conjunto de metas consideradas importantes para tener una mejora relevante [2] . Para dar soporte a las organizaciones que eligen la representación continua, las áreas de proceso son clasicadas en 4 categorías, y cada área de proceso pertenece exclusivamente a una categoría dependiendo de la funcionalidad que desempeña; dichas categorías se pueden observar en la columna 2 de la Figura 3. A su vez, cada categoría tiene áreas de proceso fundamentales y progresivas (las fundamentales deben ser implementadas antes que las progresivas para garantizar el cumplimiento de los pre-requisitos); la excepción es la categoría de Ingeniería, en la que las áreas de proceso son recursivas. Esto se puede observar en la columna 4 de la Figura 3 [2, 1]. Para aquellas organizaciones que escogen la representación escalonada se establecen los niveles de madurez, que sirven como fronteras del proceso, por ejemplo: las áreas de proceso del nivel 2 no pertenecen al nivel 3 y viceversa (esto no indica que no exista relación entre ellas) ; esto quiere decir que en la representación escalonada un área de proceso pertenece a un único nivel de madurez; en la columna 3 de la Figura 3 estos se distinguen por diferentes colores (verde para el nivel de madurez 2, amarillo para el 3, rosa para el 4, y azul para el 5). Si una organización quisiera alcanzar el nivel de madurez 2 deberá implementar todas las áreas de proceso de color verde. Fig. 3: Áreas de Proceso y sus Categorías - Niveles de Madurez CMMI [2, 5] 9 PATRÓN DE PROCESOS A continuación se describen los componentes de las áreas de proceso [2] , a su vez esta descripción representa el patrón de procesos de CMMI (la forma en la que se documenta un área de proceso): Requeridos Describen lo que una organización debe alcanzar para satisfacer un área de proceso, dicho logro debe ser visiblemente implementado en los procesos de la organización. Los componentes requeridos de CMMI son: Metas Especícas: Describen las características únicas que deben ser tenidas en cuenta para satisfacer un área de proceso. Metas Genéricas: Describen las características que deben ser tenidas en cuenta para institucionalizar los procesos que implementan un área de proceso. Aparecen al nal del área de proceso y se llaman así porque la misma declaración aparece en múltiples áreas de proceso. El cumplimiento de metas es utilizado en las evaluaciones como base para decidir si el área de proceso ha sido alcanzada o satisfecha. Esperados Describen lo que una organización típicamente implementaría para alcanzar un componente requerido, aquí se incluyen: Prácticas Especícas: Describen las actividades que son consideradas importantes en el logro de la meta especíca asociada a dicha práctica. Prácticas Genéricas: Describen las actividades que son consideradas importantes en el logro de una meta genérica asociada a dicha práctica. Aparecen al nal del área de proceso y son llamadas así porque la misma práctica aparece en varias áreas de proceso. Guían a aquellos que implementan las mejoras o realizan las evaluaciones. Informativos Proveen detalles que ayudan a la organización a empezar a pensar en cómo alcanzar los componentes esperados y requeridos. Son: Declaración de Propósito: Describe el propósito de un área de proceso. Notas Introductorioas: Describe los conceptos más importantes en el área de proceso. Áreas de Proceo Relacionadas: Lista las referencias a las áreas de proceso relacionadas y reeja las relaciones de alto nivel entre las áreas de proceso. 10 Sub-Prácticas: Es una descripción detallada que provee una guía para interpretar e implementar una práctica especíca. Productos de Trabajo: Listan las salidas o una muestra de las salidas de una práctica especíca. Amplicaciones de la Disciplina: Es una pieza de información que es relevante para una disciplina en particular. Elaboraciones de Práctica Genérica: Aparece después de una práctica genérica en un área de proceso para proveer una guía de cómo dicha práctica genérica debería ser aplicada en dicha área de proceso. Títulos de Meta y Práctica: Son los títulos de los componentes requeridos y esperados. Notas de Meta y Práctica: Es texto que puede proveer más detalle acerca de algo. Apoyo a Componentes Informativos Ejemplos: Aclara un concepto o una actividad. Notas: Es texto que provee más detalle. Ampliaciones de la Disciplina: Es una pieza de información que es relevante a una disciplina en particular. Referencias: Es un apuntador a información adicional. La Figura 4 muestra una relación de todos los componentes anteriormente descritos. 11 Fig. 4: Componentes Áreas de Proceso CMMI[2, 1] Desgloce Áreas de Proceso A continuación se muestra una breve descripción de cada área de proceso del modelo, clasicadas en su categoría y además en su tipo: fundamental o progresiva [2, 5, 1] : Gestión de Procesos Contiene las actividades del proyecto cruzadas relacionadas con la denición, planeacióm, despliegue, implementación, monitoreo, control, evaluación, medición y evaluación de los procesos. Áreas Fundamentales Proveen a la organización la capacidad de documentarse y compartir las mejores prácticas. Denición de Procesos Organizacionales Establece y mantiene el conjunto de proceso estándar de la organización, basándose en las necesidades del proceso y los objetivos de la organización. Enfoque de Procesos Organizacionales Ayuda a la organización a planear e implementar la mejora de procesos organizacionales basándose en un entendimiento de las fortalezas y debilidades de los procesos actuales de ésta. 12 Entrenamiento Organizacional Identica las necesidades de entrenamiento estratégico de la organización y también las necesidades de entrenamiento táctico. Áreas Progresivas Desempeño del Proceso Organizacional Brinda objetivos cuantitativos para el desempeño de la calidad del proceso desde los objetivos de negocio de la organización. La organización provee las métricas y debe analizarlas para desarrollar un entendimiento de la calidad del producto, del servicio y desempeño de procesos. Innovación y Desempeño Organizacional Selecciona y despliega nuevas mejoras. Gestión de Proyectos Cubre las actividades relacionadas con planeación, monitoreo y control del proyecto. Áreas Fundamentales Dirigen las actividades relacionadas con establecer y mantener el plan del proyecto, compromisos, monitorear los progresos versus el plan, tomar acciones correctivas y administrar los acuerdos con los proveedores. Planeación del Proyecto Incluye: Desarrollar el plan del proyecto Involucrar a los stakeholders Adquirir compromiso con el plan La planeación comienza con los requerimientos que denen el producto y el proyecto. Monitoreo y Control del Proyecto Incluye el monitoreo de las actividades y el tomar acciones correctivas. El plan especica el nivel de monitoreo que hay que tener y la frecuencia de las retroalimentaciones. 13 Administración de Acuerdos con Proveedores Maneja las necesidades que existen dentro del proyecto de obtener porciones de trabajo que seran producidas por proveedores. Una vez el componente de un producto es identicado y el proveedor que lo producirá es seleccionado, el acuerdo es establecido y mantenido (monitoreado). Áreas Progresivas Dirigen actividades como establecer un proceso denido que es adaptado del conjunto de procesos estándar de la organización, como coordinación y colaboración con stakeholders relevantes (incluyendo proveedores), administración de riesgos, etc. Cada área de proceso progresiva de la categoría de gestión de proyectos depende de la habilidad de planear, monitorear y controlar el proyecto. Las áreas de proceso fundamentales de ésta misma categoría proveen esta habilidad. Administración de Riesgos Desarrolla e implementa una estrategia proactiva para identicar, evaluar, priorizar y manejar riesgos del proyecto. Administración Cuantitativa del Proyecto Aplica técnicas estadísticas cuantitativas para manejar el desempeño del proceso y la calidad del producto. Administración Integrada del Proyecto Adapta los procesos organizacionales al proyecto y establece la visión compartida del mismo. Ingeniería Cubre las actividades de desarrollo y mantenimiento que son compartidas a través de las disciplinas de ingeniería. Integra procesos de Ingeniería de Sistemas y de Software. Desarrollo de Requerimientos Identica las necesidades del cliente y las traduce a requerimientos del producto, estos son analizados para producir una solución conceptual de alto nivel. Administración de Requerimientos Maneja y administra los requerimientos de los productos del proyecto y de los componentes del producto. Identica inconsistencias entre los requerimientos y el plan de proyecto y productos de trabajo. 14 Soluciones Técnicas Su propósito es desarrollar, diseñar e implementar soluciones para los requerimientos del producto. Integración del Producto Combina los componentes del producto y se asegura que éste (cuando esté integrado) funcione correctamente. Vericación Asegura que los productos de trabajo seleccionados cumplan con sus requerimientos, asegura también que las cosas se hayan hecho bien. Validación Asegura que el producto cumple con lo que se esperaba de éste, asegura que se esté haciendo lo correcto de acuerdo a los requerimientos. Soporte Cubre las actividades que soportan/apoyan el desarrollo del producto y su mantenimiento. Áreas Fundamentales Mediciones y Análisis Establece un programa de métricas para proveer resultados objetivos que puedan ser utilizados para la toma de decisiones y para el establecimiento de acciones correctivas. Aseguramiento de la Calidad y del Producto Proporciona prácticas para evaluar objetivamente los procesos, productos y servicios. Administración de la Conguración Apoya a todas las áreade proceso estableciendo y manteniendo la integridad de todos los productos de trabajo utiliznado la identicación de conguración, control de conguración, y auditorías de conguración. Áreas Progresivas Análisis Causal y Resolución Identica las causas de los defectos y de otros problemas, y toma acciones para prevenir que ocurran en el futuro. 15 Análisis de Decisiones y Resolución Apoya a todas las áreas de procso determinando cuales sucesos deben ser sometidos a una evaluación de proceso y luego aplicando dicha evaluación a éstos. CMMI en las Organizaciones CMMI es considerado el modelo de mejora de procesos más comprensible y más conocido [6]. Sin embargo, las organizaciones pueden ver este modelo de 2 formas: 1. Vista de la Valoración 2. Vista de Mejora de Procesos Si una organización ve este modelo con ojos de "valoración" se enfocará en satisfacer los requerimientos mínimos que se deben cumplir para pasar la prueba o evaluación SCAMPI. Por el contrario, si se tiene una vista de una mejora real, la organización se enfocará en lo que es mejor para sí misma y lo que necesitan para mejorar. La experiencia establece que las organizaciones que tienen la vista 1 fallarán en el intento, especialmente en "satisfacer" el modelo por la falta de institucionalización del mismo. Tal vez la vista 2 requiera trabajar duro, pero es el único camino a la mejora. CMMI tiene 2 problemas para las organizaciones: Su interpretación y las decisiones organizacionales. Este modelo fue escrito para cubrir muchas organizaciones y muchos proyectos distintos, por eso puede llegar a ser ambiguo. Sin embargo, esto también puede ser visto como una ventaja, ya que permite denir a cada organización cómo hacer las cosas y lo que quiere obtener de sus acciones [1] . 16 MoProSoft El Modelo de Procesos para la Industria del Software: MoProSoft fue desarrollado a solicitud de la Secretaría de Economía, que inició el Programa para el Desarrollo de la Industria de Software: PROSOFT , para servir como base de la Norma Mexicana de la Industria de Desarrollo y Mantenimiento de Software bajo el convenio con la Facultad de Ciencias de la Universidad Autónoma de México ; y con el objetivo de fortalecer la industria del software en México [7, 8] . Dentro de las estrategias de PROSOFT existe una sexta (6) que estipula "alcanzar niveles internacionales en capacidad de procesos" , para esto fue necesaria una denición de un modelo de procesos y evaluación apropiado para la industria del software mexicana que debería cumplir con los siguientes requerimientos: Especíco para desarrollo y mantenimiento de software Fácil de entender Denido como conjunto de procesos Práctico y fácil de aplicar, sobre todo en organizaciones pequeñas Orientado a mejorar los procesos para contribuir a los objetivos de negocio y no simplemente ser un marco de referencia de certicación Debe de tener un mecanismo de evlauación o certicación, que indique un estado real de una organización durante un período de vigencia especíco. Aplicable como norma mexicana Ser la base para alcanzar evaluaciones exitosas con otros modelos, tales como ISO 9000 : 2000 ó CMMI v1.1 La razón del establecimiento de los requerimientos anteriores es que la industria del software en México es en su mayoría pequeña y mediana, el 90 % de las empresas desarrolladoras de software se encuentran en dichas categorías y además son volátiles, cuentan con pocos recursos y tienen procesos no estandarizados que dependen del personal que los ejecuta [9] . Luego de hacer un estudio de los modelos existentes y una comparación de sus características versus aquellas deseadas para el modelo, el resultado fue que ningún modelo satisfacía los requerimientos; se opta entonces por crear uno, tomando como base algunas características de éstos. MoProSoft está fundamentado en ISO 9000:2000, SW-CMM y el reporte técnico ISO/IECTR 15504 , por lo que la adopción de este modelo habilida la obtención de un certicado ISO 9000 y reduce la brecha para la obtención de una valoración en CMMI Nivel 2 [9] . Después de 5 años de implantación como norma, este modelo ha permitido a las organizaciones seguir un camino más claro y denido en su búsqueda de la mejora continua de procesos de software, 17 pues cubre en gran medida los requisitos de CMMI y de ISO/IEC 12207 así como el 80 % de los requisitos denidos por el grupo WG24 [8]. Estructura Este modelo consta de una sóla representación y utiliza niveles de capacidad de procesos [10], de forma similar a la representación continua de CMMI. Modelo de Capacidades de Procesos La capacidad de un proceso se evalúa en niveles en una escala de 0 a 5, así [11]: 0 - Incompleto El proceso no esta implantado o falla en alcanzar el propósito del proceso. 1 - Realizado El proceso implantado logra su propósito 2 - Administrado El proceso Realizado se implanta de manera administrada y sus productos de trabajo están apropiadamente establecidos, controlados y mantenidos. 3 - Establecido El proceso Administrado es implantado mediante el proceso denido, el cual es capaz de lograr los resultados del proceso. 4 - Predecible El proceso Establecido opera dentro de límites para lograr sus resultados. 5 - Optimizado El proceso Predecible es continuamente mejorado para lograr las metas de negocio actuales y futuras relevantes. Cómo Alcanzar un Nivel de Capacidad La medición de capacidad se obtiene a través de un conjunto de Atributos de Procesos, que se usan para determinar cuándo un proceso ha alcanzado una capacidad; cada atributo mide un aspecto particular de un proceso [11]. 18 Patrón de Procesos Es un esquema de elementos que describe la forma en que se documentan los procesos y está constituido por 3 partes : Denición general del proceso, prácticas y guías de ajuste [10]. Denición General del Proceso Proceso: Nombre del proceso, precedido por el acrónimo establecido en la denición de los elementos de la estructura del modelo de procesos. Categoría: Nombre de la categoría a la que pertenece el proceso y el acrónimo entre paréntesis. Propósito: Objetivos generales medibles y resultados esperados del proceso. Descripción: Descripción general de las activiades y productos que componen el ujo de trabajo del proceso. Objetivos: Objetivos especícos cuya nalidad es asegurar el cumplimiento del propósito del proceso. Indicadores: Denición de los indicadores para evaluar la efectividad del cumplimiento de los objetivos del proceso. Metas Cuantitativas: Valor numérico o rango de satisfacción por indicador. Responsabilidad y Autoridad: Responsabilidad es el rol principal responsable por la ejecución del proceso. Autoridad es el rol responsable por validar la ejecución del proceso y el cumplimiento de su propósito. Sub-procesos: Lista de procesos de los cuales se compone el proceso en cuestión. Este es opcional. Procesos Relacionados: Nombres de los procesos relacionados. Entradas: Para cada entrada nombre del producto o recurso, y fuente. Salidas: Para cada salida nombre del producto generado y utilizado en el propio proceso, descripción y destino. Productos Internos: Para cada producto generado y utilizado en el propio proceso, nombre y descripción. Referencias Bibligrácas: Bibliografía que sustenta el proceso. Prácticas Roles Involucrados y Capacitación Identicación de roles involucrados y capacitación requerida. 19 Actividades Se asocian los objetivos y describen las tareas y roles responsables. Diagrama de Flujo de Trabajo Diagrama de actividades UML, donde se especican las actividades del ujo de trabajo y los productos. Vericaciones y Validaciones Se denen las vericaciones y validaciones asociadas a los productos generados en las actividades que se mencionan. En la vericación como en la validación se identican los defectos que deben corregirse antes de continuar con las actividades posteriores. La validación de un producto puede ser interna (dentro de la organización) o externa (por el cliente) con la nalidad de obtener su autorización. Incorporación a la Base del Conocimiento Se establecen los productos y el momento a partir del cual estarán bajo control en la base del conocimiento de la organización. Recursos de Infraestructura Se especica para cada actividad los requerimientos de herramientas de software y hardware. Mediciones Mediciones que se establecen para evaluar los indicadores del proceso. Capacitación Denición de las reglas para proporcional la capacitación necesaria a los roles involucrados en el proceso. Situaciones Excepcionales Denición de los mecanismos para el manejo de las situaciones excepcionales durante la ejecución del proceso. Lecciones Aprendidas Denición de los mecanismos para aprovechar las lecciones aprendidas durante la ejecución el proceso. 20 Guías de Ajuste Descripción de posibles modicaciones al proceso que no deben afectar los objetivos del mismo. Modelo de Referencia de Procesos Para denir la estructura de este modelo se realizó un análisis de la estructura de las empresas mexicanas desarrolladoras de software, en el que se concluyó que "en la mayoría de empresas, incluso en las micro con menos de 10 personas, la alta dirección toma las decisiones acerca del rumbo de los negocios, la dirección media es responsable del control de recursos y proyectos, y el sector operacional desarrolla los proyectos" [12]. Teniendo en cuenta estos resultados, MoProSoft tiene 3 categorías: Alta Dirección (Top Management), Gerencia (Middle Management), y Operación (Opperations), que abarcan 9 procesos en total, como lo ilustra la Figura 5 . Fig. 5: Diagrama de Categorías de Procesos MoProSoft[10] ALTA DIRECCIÓN Esta es una característica que le da un distintivo a éste modelo;su objetivo principal es organizar las actividades de los ejecutivos de las PyMES introduciendo prácticas de administración y de ingeniería de software modernas [13]. 21 También dirige y recibe reportes de la categoría de Gerencia [12] y se ha demostrado que el compromiso de las personas que caben dentro de esta categoría juega un papel crucial en la implementación de un modelo de mejora de procesos de software [13]. Gestión del Negocio Su propósito es establecer la razón de ser de la organización, sus objetivos y las condiciones para lograrlos. Habilita a la organización para responder a un ambiente de cambio, y a sus miembros para trabajar en función de los objetivos establecidos [9]. GERENCIA Está alineada con las metas de negocio de la categoría de alta dirección; también con la categoría de operación ya que provee elementos para el desempeño de procesos operacionales, recibe y evalúa la información que dichos procesos generan, e informan a alta dirección acerca de los resultados [12]. Gestión de Procesos Su propósito es establecer los procesos de la organización en función de los procesos requeridos identicados en el plan estratégico. Busca denir, planear e implantar las actividades de mejora en los éstos [10]. Gestión de Proyectos Su propósito es asegurar que los proyectos contribuyan al cumplimiento de los objetivos y estrategias de la organización [10]. Gestión de Recursos Su nalidad es apoyar el cumplimiento de los objetivos del plan estratégico de la organización. Así como conseguir y dotar la organización de los recursos humanos, infraestructura, ambiente de trabajo y proveedores [7]. Incluye 3 sub-procesos: • Recursos Humanos y Ambiente de Trabajo: Busca proporcionar los recursos humanos adecuados para cumplir las responsabilidades asignadas dentro de la organización, así como la evaluación del ambiente de trabajo. • Bienes, Servicios e Infraestructura: Su propósito es proporcionar proveedores de bienes, servicios e infraestructura que satisfagan los requisitos de adquisición de los procesos y proyectos de la organización. 22 • Conocimiento de la Organización: Su n es mantener disponible y administrar la base del conocimiento que contiene la información y los productos generados por la organización. OPERACIÓN Dirige las prácticas de los proyectos de desarrollo y mantenimiento de software, se alinea con la categoría de gerencia entregando reportes y productos de software generados [12]. Administración de Proyectos Especícos Su propósito es establecer y llevar a cabo sistémicamente las actividades que permitan cumplir con los objetivos de un proyecto en tiempo y costo esperados. Desarrollo y Mantenimiento de Software Su propósito es la realización sistémica de las actividades de análisis, diseño, construcción, integración y pruebas de productos de software nuevos o modicados cumpliendo con los requerimientos especícos. La Figura 6muestra la relación entre los 9 procesos de este modelo: Fig. 6: Diagrama de Relación entre Procesos MoProSoft[10] Modelo de Evaluación Una vez se realizó el modelo se hizo la misma vericación del cumplimiento de las características deseadas, dando como resultado que todavía hacía falta la 23 "Evaluación con vigencia" que fuera "Aplicable como norma" [9]. Por esto fue denido EvalProSoft en el 2003, basado en ISO/IEC 15504-2. En el 2005 se estableció la norma mexicana NMX-059-NYCE bajo el nombre: Tecnología de la Información-Software-Modelos de procesos y de evaluación para desarrollo y mantenimiento de software, que consta de 4 partes [8]: 1. Denición de Conceptos y Productos 2. Requisitos de Procesos: MoProSoft 3. Guía de Implantación de Procesos 4. Directrices para la Evaluación: EvalProSoft Esta parte 4 del estándar provee un método para evaluar una organización y establecer un perl de su nivel de capacidad para los 9 procesos implementados y un nivel de capacidad de la madurez [13]. Los niveles de capacidad alcanzables y sus atributos de proceso están divididos en una escala de 6 niveles como lo muestra la Figura 7. Fig. 7: Niveles de Capacidad y Atributos de Proceso MoProSoft [14] A continuación en la Tabla 2 se muestra la escala con la cual es calicado el grado de cumplimiento de un atributo de proceso: Tab. 2: Calicación Atributos de Proceso MoProSoft [11] Letra Calicación Porcentaje % de Alcance N No Alcanzado 0 - 15 % del alcance > 15 % hasta el 50 % del alcance P Parcialmente Alcanzado A Ampliamente Alcanzado > 50 % hasta 85 % del alcance C Completamente Alcanzado > 85 % hasta el 100 % del alcance 24 Por último, el nivel de capacidad que se alcanza es derivado de la calicación de la Tabla 2, para lo que se toma como referencia la Figura 8 . Fig. 8: Calicación del Nivel de Capacidad del Proceso MoProSoft[11] Esto quiere decir que para alcanzar un nivel de capacidad n en un proceso se necesita cumplir con los atributos del nivel n con una calicación de "Ampliamente Avanzado - A" y además cumplir con los atributos de proceso del nivel n-1 con una calicación de "Completamente Alcanzado - C" [11] . El proceso de Gestión de Procesos, en la categoría de Gestión dene, implanta, controla y mejora los procesos de la organización, por lo que el nivel de capacidad de los demás procesos de la organización dependen del nivel de capacidad de éste proceso. Es por esto que el nivel de madurez de capacidades de la organización se dene como el nivel de capacidad del proceso de Gestión de Procesos [11]. Aportes a ProSoftCol Es claro que este modelo presenta múltiples ventajas si de su posible adaptación a PyMES se trata: Categorías de Procesos Estas categorías corresponden a los niveles organizacionales de administración, que es común en muchas organizaciones. Sin embargo, esto es válido para el contexto mexicano, no se puede asegurar que para el colombiano. El aporte que brinda es el de "pensar" en el término de categoría de proceso y de alinearlo a la estructura de las organizaciones colombianas de desarrollo de software. 25 Procesos Integrados y Relacionados Esto no es nuevo en un modelo, ya que en CMMI todos los procesos tienen relaciones establecidas. El aporte consiste en la reducción del número de procesos de 22 a 9. Conocimiento de la Organización Este proceso administra una base de conocimiento, que controla y asegura la disponibilidad de los productos de trabajo a través de un mecanismo común. El aporte es el de "pensar" en algo similar para ProSoftCol, un repositorio común para la organización. Distinción en Administraciones Se distingue entre la administración a nivel de proyecto : Administración de Proyecto Especíco en la categoría de Operación; y la gestión del portafolio de proyectos de la organización: Gestión de Proyectos en la categoría de Gestión. El aporte que hace es el de separar estas administraciones para tener más claridad sobre las actividades y tareas de cada una, pues en una MIPyME_DS a veces la persona encargada de éstos 2 tipos de administración es la misma. 26 CompetiSoft En 2005 investigadores y practicantes reconocieron la importancia de un marco de mejora y certicación para las MIPyMES, y se propuso CompetiSoft : Mejora de Procesos para Fomentar la Competitividad de la Pequeña y Mediana Industria del Software de Iberoamérica, como un modelo. Este se construyó sobre las prácticas de las iniciativas latinoamericanas como MoProSoft y Brazilian Process Improvement Model; Métrica v3 de España fue tenido en cuenta también [15]. En la Figura 9 se ilustra la visión general de este modelo: Fig. 9: Visión General de CompetiSoft[12] Los requerimientos que debía cumplir CompetiSoft fueron: Fácil de entender Fácil de aplicar No costoso en su adopción Se la base para alcanzar evaluaciones exitosas con otros modelos o norma, tales como ISO 9000 : 2000 o CMM v1.1 Su objetivo general es incrementar el nivel de competitividad de las PyMES Iberoamericanas productoras d esoftware mediante la creación y difusión de un marco metodológico común que, ajustado a sus necesidades especícas, pueda llegar a ser la base sobre la que establecer un mecanismo de evaluación y certicación de la industria del software reconocido en toda Iberoamérica. Como objetivo especíco relevante existe uno que nunca se había planteado en un proyecto de éste tipo: "Denir la cultura de procesos mediante la formación de 27 investigadores, docentes y profesionales" [16]. Valela pena resaltar que CompetiSoft no es sólo un modelo de referencia, este proyecto se divide en 3 partes [17]: Modelo de Referencia de Procesos Modelo de Evaluación Modelo de Mejora Estructura Este modelo, al igual que MoProSoft, sólo tiene una representación que mide la capacidad de los procesos[16] . Modelo de Capacidad de Procesos La capacidad de un proceso se evalúa de 0 a 5, en donde cada número se asocia a un nivel (al igual que en MoProSoft) , así [16] : 0 - Incompleto El proceso no está implantado o falla en alcanzar el propósito del proceso. 1 - Realizado El proceso implantado logra su propósito. 2 - Administrado El proceso Realizado se implanta de manera administrada y sus productos de trabajo estan apropiadamente establecidos, controlados y mantenidos. 3 - Establecido El proceso Administrado es implantado mediante el proceso denido, el cual es capaz de lograr los resultados del proceso. 4 - Predecible El proceso Establecido opera dentro de límites para lograr sus resultados. 5 - Optimizado El proceso Predecible es continuamente mejorado para lograr las metas de negocio actuales y futuras relevantes. 28 Cómo Alcanzar un Nivel de Capacidad La medición de capacidad se obtiene a través de un conjunto de Atributos de Proceso (AP), los cuales se utilizan para determinar cuándo un proceso ha alcanzado una capacidad. Cada atributo mide un aspecto particular de un proceso [16]. Patrón de Procesos El patrón de procesos es un esquema de elementos que sirve para la documentación de los procesos. Este es casi igual al de MoProSoft ( para ver la denición de cada elemento dirigirse a Patrón de Procesos de MoProSoft en la página 18), con la diferencia que se excluyen algunos elementos. Está constituido por 3 partes: Denición general del proceso, Prácticas, y Guías de ajuste [16]. Denición General del Proceso Proceso Categoría Propósito Descripción Objetivos Indicadores Metas Cuantitativas Responsabilidad y Autoridad Sub-Procesos Procesos Relacionados Entradas Salidas Productos Internos En este modelo se excluye el elemento "Referencias Bibliográcas" (presente en MoProSoft). 29 Prácticas Roles Involucrados y Competencias Actividades Diagrama de Flujo de Trabajo Vericaciones y Validaciones Recursos de Infraestructura Mediciones Diere del patrón de procesos de MoProSoft en que cambia el nombre de "Roles Involucrados y Capacitación" a "Roles Involucrados y Competencias"; no incluye "Incorporación a la Base del Conocimiento", "Capacitación", "Situaciones Excepcionales" y "Lecciones Aprendidas". Guías de Ajuste Descripción de posibles modicaciones al proceso que no deben afectar los objetivos del mismo. Modelo de Referencia de Procesos Este modelo se puede ver como una evolución del modelo de referencias de procesos de MoProSoft [12], pues su estructura es casi igual. La única diferencia es la existencia de 1 proceso más dentro de la categoría de Operación: Mantenimiento de Software, para un total de 10 procesos. Las categorías de proceso siguen siendo las mismas: Alta dirección, gerencia y operación; esto porque se asume que esa estructura general de las empresas mexicanas desarrolladoras de software aplica a las organizaciones iberoamericanas. Si se toman en cuenta las Figuras y 10 se notará que tal vez ni siquiera sea "un proceso más" lo que se hizo con CompetiSoft, sino más bien la separación del proceso "Desarrollo y Mantenimiento de Software" en "Desarrollo de Software" y "Mantenimiento de Software", respectivamente. 30 Fig. 10: Diagrama de Categorías de Procesos CompetiSoft[16] ALTA DIRECCIÓN Establece la razón de ser de la organización, lo que desea ser y las estrategias para serlo, con la ayuda de un plan estratégico[12]. Gestión de Negocio Su propósito es alinear los objetivos de negocio con su tecnología de información [16]. GERENCIA Se encarga de crear planes de acción para instrumentar las estrategias en cuanto a proyectos, procesos y recursos necesarios para alcanzar los objetivos estratégicos. Monitorea y retroalimenta a la categoría de operación y a su vez, retroalimenta a la de alta dirección[16]. 31 Gestión de Procesos El aporte más signicativo, y una diferencia con la gestión de procesos de MoProSoft, es un cuestionario de auto-asesoría que ayuda a las organizaciones en su primer contacto con las asesorías y mejoras de su madurez de procesos[12]. Gestión de Proyectos Se seleccionan métricas e indicadores básicos que se pueden alinear a los objetivos de los procesos, en especial a la administración de proyectos especícos[12, 16]. Gestión de Recursos Este, al igual que MoProSoft tiene 3 sub-procesos: Gestión de Recursos Humanos Gestión de Bienes e Infraestructura Gestión de Conocimiento Trata de crear una guía para las organizaciones a partir de la experiencia de otras[12]. OPERACIÓN Se encarga de llevar a cabo de los proyectos de desarrollo y mantenimiento de software establecidos en la categoría de gerencia[12]. Administración de un Proyecto Especíco Se enfoca en cumplir con los compromisos establecidos con el cliente en tiempo y costo[12]. Desarrollo de Software Se basa en lineamientos para desarrollo de requerimientos, análisis y diseño, pruebas y construcción, para facilitar su aplicación en pequeñas organizaciones. Las características más sobresalientes de este proceso son[12]: Técnicas Especícas y Productos de Trabajo Se sugieren herramientas de trabajo Recomendación de bibliografía Provee ejemplos de aplicación 32 Mantenimiento de Software Tiene como objetivo llevar a cabo de forma ágil los cambios solicitados a un producto se software de tal forma que no se pierda la consistencia, y que cumpla con las necesidades del cliente [16]. Por eso se dice que es clave separar mantenimiento de desarrollo, ambos tienen naturalezas y características diferentes ( tal vez este sea uno de los aportes más signicativos de CompetiSoft). Al separar el mantenimiento se hizo notorio que muchas técnicas, herramientas y modelos de proceso, no son aplicables a éste [12]. Se desarrolló un proceso de mantenimiento adoptando técnicas de Scrum y Mantema, en las que se divide este proceso en 2 niveles: Básico • Mantenimiento Urgente • Mantenimiento No Urgente • Mantenimiento Perfectivo Avanzado • Mantenimiento Adaptativo • Mantenimiento Preventivo Un ejemplo de estos niveles es: Una petición de modicación puede ser una solicitud de cambio (perfectivo, adaptativo y preventivo) o un informe de problema correctivo urgente, o no urgente. Este proceso tiene varias ventajas: Permite los cambios durante el camino, y considera una retroalimentación constante con el cliente junto con una entrega rápida y periódica de atención a las peticiones de mantenimiento que permita cumplir con los niveles de servicio solicitados. Considera el mecanismo para recibir, alcanzar y dar seguimiento a las peticiones de modicación. Las peticiones se atienden por grupos en ciclos, los cuales se clasican en planicable y no planicable. Cada ciclo es conocido como SprintM, que está basada en Sprint de Scrum [16]. La Figura 11 muestra la relación existente entre los 10 procesos de este modelo. 33 Fig. 11: Diagrama de Relación entre Procesos de CompetiSoft [16] Modelo de Evaluación Este modelo de evaluación está basado en EvalProSoft, el modelo de evaluación de MoProSoft. Para diseñar este modelo se tuvo en cuenta un problema que es general a las organizaciones: las métricas. El medir algo correctamente y utilizar dichas medidas para el bien de la organización puede llegar a ser subjetivo o ambiguo, especialmente si la organización es pequeña. Sin embargo, desde que se diseñó CMMI se trató de "hacerlo simple" [1]. Por esto, la meta era denir un conjunto de medidas para estimar la capacidad y desempeño de los procesos de software que redujera la subjetividad del proceso y a la vez lo hiciera más formal. En este modelo existen 2 tipos de medida: Capacidad Usa los indicadores de un atributo de proceso para evaluar la capacidad de los procesos de la organización de 0 a 5. Desempeño Basado en propósito, descripción, productos de trabajo, y actividades del modelo de referencia CompetiSoft. Propone utilizar como marco general para la evaluación a la norma internacional ISO/IEC 15504 : Performing an Assessment. 34 Este modelo exactamente igual al de MoProSoft, para más detalle sobre la evaluación en CompetiSoft diríjase a Modelo de Evaluación de MoProSoft en la página 22 . Modelo de Mejora PmCompetiSoft está basado en Agile SPI, y dene los elementos necesarios para conducir la mejora de procesos en una pequeña organización de software de una forma ágil, económica, con pocos recursos y en poco tiempo [12]. Está basado en un enfoque iterativo e incremental ( altamente inuenciado por eXtreme Programming ), de tal forma que se pueda tener una entrega temprana y continua de mejoras que den visibilidad de los resultados a la categoría de Alta Dirección. El proceso de mejora continua considera ciclos de mejora en donde cada uno incluye las actividades de instalación, diagnóstico, formulación de mejoras, ejecución de mejoras y revisión de ciclo [12]. Aportes a ProSoftCol El aporte más grande para ProSoftCol es el cuestionario de auto-asesoría en la Administración de Proyectos Especícos, pues es muy completo y además considera las posibles respuestas (SI/NO) y dependiendo de esto se genera un ujo de preguntas. Las métricas utilizadas en Gestión de Proyectos y las técnicas de estimación también son un aporte, porque son para PyMES y en este proyecto se ha hecho énfasis en la importancia de las mediciones. 35 Conclusiones El objetivo al realizar una recolección de información acerca de éstos 3 modelos era entenderlos por completo, para luego en el momento de tener los requerimientos especícos de una MIPyME_DS poderlos aplicar al diseño de la guía, es decir, el artefacto en términos de la ciencia del diseño. Decidí adentrar más en CMMI porque aunque yo creía conocerlo en su totalidad, me percaté que no era así y que por el contrario me tomó bastante tiempo entenderlo completamente. Tener claridad y lograr un entendimiento de MoProSoft me ayudó a reducir un poco más el marco de ProSoftCol, a saber qué quiero y que no quiero especícamente. Luego de documentarme sobre CMMI y de darme cuenta que se han escrito libros para "ayudar a entender el modelo" me dije: Yo no quiero esto, quiero algo que una persona pueda entender una vez lo haya leído. De modo que ProSoftCol comparte algunos de los requerimientos o lo que eran las características esperadas de MoProSoft, como: Especíco para desarrollo y mantenimiento de software Fácil de entender Denido como conjunto de procesos Práctico y fácil de aplicar, sobre todo en organizaciones pequeñas. Orientado a mejorar los procesos para contribuir a los objetivos de negocio. MoProSoft está dirigido a pequeñas o medianas empresas o áreas internas de organizaciones muy grandes de desarrollo y/o mantenimiento de software [13, 7] ; ProSoftCol es dirigido a micro, pequeñas y medianas empresas de desarrollo de software que no cuenten con procesos establecidos. Lo que más rescato de esta iteración del ciclo de Rigor es que yo me podría identicar con una organización X que un día decide mejorar sus procesos y documentarse al respecto. Probablemente acudiría a CMMI (como yo lo hice en principio) pero surgirían muchos interrogantes, dudas y sería necesaria una gran inversión de tiempo para entender el modelo y más aún para tener una idea de cómo aplicarlo a la organización. Mientras yo realizaba mi investigación, tenía en mente esto: ¾Cómo aplicar todo esto a una MIPyME_DS Colombiana? De modo que las preguntas que me surgieron en el camino serían las mismas que una organización X se haría, y la respuesta o guía para resolverlas será el aporte de mi artefacto, de ProSoftCol. Me atrevo a decir que una forma de medir la claridad y facilidad de entendimiento de cada modelo es la que yo experimenté: buscando fuentes de información de dichos modelos (se hizo en la asignatura Seminario Metodología de la Información), y luego haciendo un ltro de la información contenida en dichas fuentes para tomar lo que se consideró relevante y no repetitivo. Luego se organizó toda la información y plasmarla en este documento de manera que fuera clara y que se entendiera a profundidad cada modelo y cómo está conformado. El grado de complejidad de esta tarea fue elevado, pues al iniciar con 36 CMMI no sabía de qué forma explicar la estructura del modelo: ¾explicar qué es un área de proceso primero y luego las 2 representaciones? o ¾al revés? Finalmente debo decir que todavía no estoy convencida de que cualquier persona que lea este documento entienda completamente el modelo CMMI. El grado de complejidad fue bajando y mucho, tan sólo en el modelo MoProSoft, ya que éste es mucho más claro en su estructura y sólo tiene una representación, no 2 como CMMI. Lo que más me ayudó fue la asimilación con la estructura de una empresa para denir las categorías de procesos y dentro de ellas cada proceso. Comprender CompetiSoft no fue para nada difícil, teniendo en cuenta que es casi igual a MoProSoft en su estructura, solo que enfatiza más en algunos aspectos como el mantenimiento de software y métricas. Tomar dichas categorías ( Alta Dirección - Gerencia - Operación ) puede llegar a ser muy útil para el entendimiento de un modelo. Sin embargo, a pesar de que se han realizado algunas implementaciones de CompetiSoft en PyMES Iberoamericanas [15], es claro que el objetivo de este proyecto no se ha cumplido; las razones son desconocidas para mí, pero en mi opinión hace falta algo más, algo como una guía más cercana a cada tipo de organización. 37 Referencias [1] M. Kulpa and K. Johnson, Approach, C. Press, Ed. Interpreting the CMMI: A Process Improvement Auerbach Publications, 2003. CMMI:Guidelines for Process Integration and Product Improvement, Pearson, Ed. Addison Wesley, 2003. [2] M. B. Chrissis, M. Konrad, and S. Shrum, [3] M. West, Real Process Improvement Using the CMMI, C. Press, Ed. Auer, 2004. Process Improvement Essentials, M. O'Brien and T. Apandi, Eds. [4] J. Persse, O'Reilly, September 2006. [5] M. Chrissis, M. Konrad, and S. Shrum. (2009) Cmmi: Guía para la integración de procesos y la mejora de productos. [Online]. Available: http://www.sei.cmu.edu/library/assets/cmmi-dev-v12-spanish.pdf [6] P. Mongkolnam, U. Silparcha, N. Waraporn, and V. Vanijja, A push for software process improvement in thailand, in Proc. Asia-Pacic Software Engineering Conf. APSEC '09, 2009, pp. 475481. [7] H. Oktaba, C. Alquicira, A. Su Ramos, A. Martinez, A. Quintanilla, M. Ruvalbaca, F. Lopez, M. Rivera, M. Orozco, Y. Fernandez, and M. Flores, Modelo de procesos para la industria de software moprosoft, no. 1.3. Universidad Nacional Autonoma de Mexico, Agosto 2005. [Onli- ne]. Available: http://www.comunidadmoprosoft.org.mx/COMUNIDAD_ MOPROSOFTADM/Documentos/V1.3_MoProSoft.pdf [8] H. Oktaba. (2008, Mayo) Moprosoft sin fronteras. Universidad Nacional Autónoma de México. [9] H. e. a. Oktaba. (2005) Moprosoft: Modelo de procesos para la industria de software. [10] H. Oktaba, C. Alquicira, A. Su Ramos, A. Martinez, A. Quintanilla, M. Ruvalbaca, F. López, M. Rivera, México Std. M. Orozco, Y. Fernandez, Modelo de Procesos para la Industria del Software MoProSoft por Niveles de Capacidad de Procesos, Universidad and M. Flores, Nacional Autónoma Available: de 1.3, Agosto 2005. [Online]. http://www.comunidadmoprosoft.org.mx/COMUNIDAD_ MOPROSOFTADM/Documentos/V_1.3_MoProSoft_por_niveles_de_ capacidad_de_procesos.pdf [11] H. Oktaba, C. Alquicira, A. Su Ramos, F. López, J. Pa- Método de Evaluación de procesos para la Industria del Software EvalProSoft, Universidad Naciolacios, nal and Autónoma C. Pérez, de México Std. 1.1, 2004. [Online]. Available: http://materias.utags.edu.mx/claroline/backends/download.php?url= 38 L0FydGljdWxvcy9FdmFsUHJvU29mdHYxMS5wZGY%3D&cidReset= true&cidReq=CALS_IVET [12] 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. 2128, 2007. [13] 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 ENC '08, 2008, pp. 323328. Proc. Mexican Int. Conf. Computer Science [14] Itera. (2006) Moprosoft. Web Page. Itera IT Business Process. [Online]. Available: http://www.iteraprocess.com/index.php?option=com_ content&task=view&id=23&Itemid=44 [15] 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. 107122, Julio 2010. Competisoft: Mejora de Procesos Software para Pequeñas y Medianas Empresas y Proyectos, Ra-Ma, Ed. AlfaOmega, 2009. [16] M. Piattini, H. Oktaba, F. Pino, M. Orozco, and C. Alquicira, [17] H. Oktaba. (2009, Noviembre) Una aportacion latina a estandares internacionales para la industria de software.