ARTÍCULO ORIGINAL

Interpretación de las normas mexicanas para la implantación de procesos de software y evaluación de la capacidad bajo un enfoque de gestión de conocimiento

Interpreting the mexican standards for software process implementation and capacity assessment under a knowledge management approach

Brenda L. Flores Ríos^1*, María Angélica As torga Vargas², Oscar Mario Rodríguez Elias³, Jorge Eduardo Ibarra Esquer², María del Carmen Andrade²

¹instituto de Ingeniería. Universidad Autónoma de Baja California. Calle de la Normal s/n y Blvd. Benito Juárez. Col. Insurgentes Este. CP. 21280. Mexicali, Baja California. México.

²Facultad de Ingeniería, campus Mexicali. Blvd. Benito Juárez s/n. Col. Insurgentes Este. C.P. 21280. Mexicali, Baja California, México.

³División de Estudios de Posgrado e Investigación. Instituto Tecnológico de Hermosillo. Ave. Tecnológico y Periférico Poniente s/n. Col. Sahuaro. C.P. 83170. Hermosillo, Sonora. México.

^*Autor de correspondencia: teléfono: + 52 + 686 + 5664150, ext. 223, correo electrónico: brenda.flores@uabc.edu.mx (B. Flores).

(Recibido el 15 de julio de 2013. Aceptado el 04 de febrero de 2014)

Resumen

Este trabajo presenta la implicación de la Gestión de Conocimiento en la mejora de procesos al aplicar las normas mexicanas para la implantación de procesos de software (NMX-I-059-NYCE-2011) y evaluación de la capacidad de procesos (NMX-I-15504-NYCE-2010). Se caracterizan y analizan los tipos de conocimiento detectados en una empresa de desarrollo de software, los cuales permiten distinguir los dos primeros niveles de conocimiento involucrados en un proyecto de mejora de procesos basado en conocimiento.

Palabras clave: Gestión de conocimiento, mejora de procesos de software

Abstract

This paper presents the involvement of Knowledge Management in Process Improvement when applying Mexican Standards for software process implementation (NMX-I-059-NYCE-2011) and process capability assessment (NMX-I-15504-NYCE-2010). We discuss and characterize the types of knowledge found in a software development company. From this characterization, we distinguish the first two levels of knowledge involved in a software process improvement project based on knowledge.

Keywords:Knowledge management, software process improvement

Introducción

Con el propósito de mejorar la Industria mexicana de software, se ha participado activamente en establecer iniciativas de Mejora de Procesos de Software (SPI por sus siglas en inglés de Software Process Improvement) orientadas a las micro, pequeñas y medianas empresas (MIPyMES), para que adquieran una cultura de procesos basada en las mejores prácticas internacionales en Gestión e Ingeniería de Software [1]. Uno de los primeros esfuerzos fue la elaboración del modelo MoProSoft tomando como base un amplio análisis de distintos modelos y estándares internacionales [1], así como la experiencia de quienes participaron en su elaboración. La evolución de este modelo, llevó a la creación de la norma NMX-I-059-NYCE-2005 (NMX-I-059) [2] misma que establece criterios para que las MIPyMES, a través de su adopción e implantación, como Modelo de Referencia de Procesos (MRP), puedan estandarizar sus prácticas diarias y elevar la capacidad de sus procesos para ofrecer servicios y productos que alcancen niveles internacionales de competitividad [1, 3]. El proceso normativo requiere de lineamientos claramente definidos para la evaluación de los criterios de conformidad con la norma. Un estándar ampliamente utilizado es el ISO/IEC 15504 [4], el cual se tomó como base para la creación de la norma NMX-I-15504- NYCE-2010 (NMX-I-15504) [5]. Esta norma define el marco general para realizar la evaluación de la capacidad de procesos y los indicadores necesarios en una evaluación [6].

Las organizaciones mexicanas de desarrollo de software que buscan un reconocimiento oficial del cumplimiento de la NMX-I-059, lo obtienen a través de un proceso de verificación llevado a cabo por una organización avalada por la Entidad Mexicana de Acreditación como la Organización en Normalización y Certificación Electrónica (NYCE) o la empresa CERTVER [7]. Para cumplir con la NMX-I-059, se requiere un amplio entendimiento de sus requisitos. Por tal motivo, algunas organizaciones suelen contratar consultores para que las preparen y guíen en el proceso de implantación y verificación, dependiendo en gran medida del conocimiento que estos posean. La NMX-I-15504 apoya a la organización a realizar evaluaciones consistentes y confiables, reduciendo la subjetividad para lograr resultados válidos y comparables a los de la verificación oficial. Sin embargo, existen personas que desconocen su contenido o la interpretan de forma incorrecta [5].

El problema anterior, está relacionado con la baja adquisición y/o adopción de normas internacionales o nacionales, así como la consulta de fuentes de conocimiento específicas para la mejora o normalización de procesos, debido a que no es una práctica común en las organizaciones de software. Tanto un proceso de implantación de SPI. como uno de evaluación del nivel de capacidad de procesos, son fuentes importantes de conocimiento para contribuir a la SPI de una organización, cualquiera que sea, incluso, el resultado. El problema de la SPI no es la falta de estándares o MRP, sino la estrategia para implantarlos [8].

La estrategia debe de estar basada en la gestión del cambio y enfocada fundamentalmente en las personas [9], quienes deben tener tanto el conocimiento tópico relacionado a los requisitos documentados explícitamente en las normas como el conocimiento episódico referente a los esfuerzos necesarios para alcanzar el nivel de madurez deseado por la organización o elevar el nivel de madurez actual. Este es uno de los escenarios donde se observa la relación de la Gestión de Conocimiento (GC) en el campo de SPI. En un proyecto de SPI se crea conocimiento en relación a la madurez de la organización donde los procesos de software se basan en la experiencia y conocimiento de las actividades realizadas.

En este trabajo, se expone bajo una validación empírica la importancia de identificar y caracterizar los tipos de conocimiento involucrados en la implantación de procesos de software y evaluación de la capacidad de procesos, por medio de un caso de interpretación de normas mexicanas; así como otros factores que intervienen cuando las MIPyMES desarrolladoras de software buscan elevar la capacidad de sus procesos, y por ende, su madurez organizacional.

El artículo se organiza de la siguiente manera: se presenta un marco referencial donde se describen las normas NMX-I-059 y NMX-I-15504 como principales fuentes de conocimiento explícito [10]. Posteriormente, se describe brevemente la metodología KoFI que se siguió para el análisis de flujos de conocimiento [11] sobre un proyecto de SPI. En la cuarta sección, se describe un experimento para explorar la transdisciplinariedad de un proyecto de SPI basado en GC con el objetivo de extraer conocimiento tipo episódico y procedural. El objetivo de la transdisciplinariedad es promover descriptiva y narrativamente el conocimiento orientado a los problemas relevantemente sociales [12]. De esta forma, la sección cinco identifica, como factores clave de una estrategia de GC, las fuentes y tipos de conocimientos contenidos en un proyecto SPI para apoyar a elevar el nivel de madurez deseado por una organización mexicana. Finalmente, la sección seis presenta las conclusiones del trabajo.

Marco referencial

De acuerdo con el diagnóstico del conocimiento y uso actual de modelos de calidad realizado a 114 empresas mexicanas de desarrollo de software [13], del 86% de las empresas encuestadas sólo el 44% utilizaban como MRP a MoProSoft [14] o la norma NMX-I-059 [14], mientras que el 26% se inclinaba por MRP internacionales. Por otra parte, el 30% no refería a ningún MRP. Los resultados demostraron que las organizaciones tienen un reducido conocimiento sobre modelos de calidad de software (nacionales e internacionales), desconocen los métodos específicos para evaluar la calidad de sus productos y expresan la necesidad de contar con modelos integrales para asegurar la calidad de sus procesos [13]. Por lo anterior, esta sección presenta en detalle los requisitos normativos en conformidad con las normas NMX-I-059 y NMX-I-15504, considerando las particularidades de la industria mexicana de software.

NMX-I-059 como Modelo de Referencia de Procesos (MRP)

La Norma NMX-I-059 se integra por 4 partes: 1) Definición de conceptos y productos de software, 2) Requisitos de Procesos (MoProSoft), 3) Guía de implantación de procesos y 4) Directrices para la evaluación [2]. La parte 02 se estructura en dos secciones: La primera presenta los elementos normativos por cada uno de los 9 procesos (Tabla 1) : Categoría, Proceso, Propósito, Objetivo(s), Actividades (Prácticas Base - PB) y Productos de Trabajo (PT). Es importante enfatizar que para esta interpretación debe considerarse la trazabilidad que tiene el propósito del proceso con los objetivos y estos a su vez, con las PB y los PT. Por lo tanto, la definición de dichos elementos debe mantenerse con la finalidad de alcanzar el propósito de cada uno de los 9 procesos [15]. Los roles responsables (RP) adquieren una responsabilidad por la realización de un conjunto de actividades específicas para un proceso y del cumplimiento de sus objetivos. Además, pueden ser asumidos por una o más personas de la organización. La tabla 1 muestra la relación de los RP requeridos por la NMX-I-059. La segunda sección de la NMX-I-059/02 está definida como Apéndice A (Normativo) y estructurada por capítulos correspondientes al nivel 1 hasta el nivel 5 de capacidad de procesos. En cada capítulo se indican los Atributos de Proceso (AP), los elementos mínimos requeridos de los PT y las PB esperadas asociados por nivel. En este sentido, el cumplimiento de los AP determinará el nivel de capacidad del proceso, y el nivel de madurez de la organización será determinado por el máximo nivel de capacidad obtenido por todos los procesos.

En la figura 1, se observa en el nivel 1 de capacidad que se requiere el atributo Realización del Proceso (AP 1.1) y el indicador o logro a) El proceso alcanza los resultados definidos [16]. A partir del nivel 2 de capacidad de procesos se asocia más de un AP (AP 2.1 y AP 2.2) con más de un logro a cumplir, descritos a un alto nivel de conceptualización, lo que aumenta su complejidad de interpretación. Esto implica la necesidad de acceder directamente a la NMX-I-15504 para su consulta en detalle.

La presentación de los requisitos de la NMX-I-059/02 es una forma de cómo se transmite el conocimiento explícito [17]. Este tipo de conocimiento también está contenido en la norma NMX-I-15504, la cual especifica la evaluación y determinación de la capacidad y mejora continua de procesos de Ingeniería de Software [16]. Por otro lado, se estaría generando conocimiento tópico cuando las personas obtienen los significados o definiciones de términos directamente de los estándares, modelos o documentos. Entonces, se estaría manejando tanto conocimiento explícito y tópico para especificar cómo cada AP es común para los 9 procesos requeridos por la NMX-I-059, y describir los indicadores que deben estar presentes para institucionalizar un proceso [18] y así medir su capacidad utilizando la norma NMX-I-15504.

Atributos de proceso de la NMX-I-15504 y su evaluación

La NMX-I-15504 constituye una fuente de conocimiento explícito integrada por 5 partes, de las cuales la parte 02 es normativa y el resto son informativas [19]. La capacidad de los procesos está definida por un marco de mediciones en una escala ordinal de 6 niveles que representa el incremento de capacidad de los procesos implementados desde el punto mínimo en el que no se alcanza el propósito del proceso (Nivel 0 - Incompleto), hasta el punto máximo en el que se alcanzan las metas actuales y proyectadas para la innovación de procesos (Nivel 5 - Optimización). La evaluación de la capacidad considera un conjunto de AP. Para cada AP, la medida de capacidad se basa en la medición de los Indicadores de Atributo de Proceso (IAP) que integran Prácticas Genéricas (PG), Recursos Genéricos (RG) y Productos de Trabajo Genéricos (PTG) [4, 6].

La figura 2 especifica que los 9 procesos requeridos por la NMX-I-059 se refieren a la dimensión del proceso. El objetivo de esta dimensión es medir el rendimiento de cada proceso considerando los Indicadores del Desempeño (ID): PB realizadas y los PT obtenidos. Por otro lado, la dimensión de la capacidad considera: 1) PG realizadas, 2) RG utilizados y 3) los PTG obtenidos en el proceso para los niveles de capacidad definidos por la NMX-I-15504 [20]. De esta manera, los AP y sus IAP son conocimiento tópico y explícito para realizar la evaluación objetiva al proveer un mayor detalle de cada AP.

La figura 3 muestra un ejemplo resumido del AP 2.2 Administración del PT. El nivel de descripción del AP se volvió más específico al asociar sus tres indicadores, lo cual permitió obtener una mejor interpretación en comparación con el ejemplo de la Figura 1. En la misma figura, se muestra que a cada logro del AP le corresponde una PG que brinda una guía para su implantación siendo el principal indicador de la capacidad del proceso. La La lista de RG son aquellos que se pueden utilizar para la ejecución del proceso y su disponibilidad indica el potencial para cumplir el AP. Por último, se listan los PTG y las características que deben contener como resultado de la ejecución de las PG. Éstas se presentan en el apéndice B de la NMX-I-15504 como una guía para los atributos, con el fin de proporcionar evidencia objetiva [18] que soporte la evaluación de un proceso específico [20].

Para evaluar el logro del AP es necesario asignarle una calificación en una escala porcentual de medición (Tabla 2), con base en los IAP y su ampliación de nivel 1 a partir de los ID. Cada proceso debe ser evaluado hasta el mayor nivel de capacidad definido en el alcance de la evaluación, por lo que el nivel de capacidad del proceso se determina mediante la combinación de la calificaciones de los AP [19].

De acuerdo con la NYCE y CERTVER, en los últimos 6 años, de las organizaciones que han solicitado una verificación oficial en conformidad con la NMX-I-059, 68% han sido verificadas oficialmente en nivel 1 de madurez, 30% en nivel 2 y 2% en nivel 3 [21]. En esta distribución, aparecen organizaciones que se verificaron en nivel 1 y posteriormente obtuvieron nivel 2. Se detecta que no se incrementó el número de organizaciones verificadas en nivel 3 de 2009 a 2012 y una disminución en el número de solicitudes por año. De los datos anteriores, se observa que no todas las organizaciones mexicanas que han implementado un programa de SPI, apoyadas en la norma NMX-I-059, han solicitado una verificación oficial. Este hecho hace que dichas organizaciones no generen conocimiento episódico como resultado del proceso de verificación una vez que las personas aprendieron a través de la experiencia [22] generada de la aplicación del conocimiento existente. Además, el conocimiento episódico se reforzaría al conocer el dictamen del nivel de capacidad de cada uno de los procesos implantados e identificar los hallazgos y oportunidades de mejora con el objetivo de que la organización pueda ser más competitiva en el mercado.

Metodología para el análisis de fuentes y tipos de conocimiento en la implantación de un proyecto de mejora de procesos de software

La identificación de fuentes y tipos de conocimiento se logró siguiendo una metodología enfocada al análisis de flujos de conocimiento (KoFI) [11], la cual propone una serie de técnicas y métodos para apoyar en la identificación de necesidades de conocimiento en procesos organizacionales [10, 11]. KoFI especifica que para apoyar el análisis de flujos de conocimiento primero se requiere modelar, global y detalladamente, el proceso organizacional para lo cual propone el uso de una adaptación de la técnica de gráfica rica [10]. Esta gráfica se utiliza como modelado global en la identificación del conocimiento requerido y generado durante las actividades, así como las fuentes de conocimiento donde éste es obtenido o almacenado. En un siguiente nivel de detalle, se utiliza la notación de SPEM-KF [23].

La figura 4 muestra el modelado global para representar el enfoque de ciclo de conocimiento [24] especificando las fuentes de conocimiento [10], representadas por la normas NMX-I-059 y NMX-I-15504, los Roles, la Base de Conocimiento (BC) como Repositorio de activos de conocimiento y los PT utilizados y generados durante toda la implantación. Dichas fuentes también apoyan los flujos de experiencias y tipos de conocimientos, porque durante el proyecto de SPI se crean significados compartidos y lecciones aprendidas por los RP que son utilizados para planear y especificar acciones de mejora. El Grupo consultor representa el trabajador de conocimiento, debido a que crea, aplica y distribuye el conocimiento durante el proyecto [25]. El enfoque de ciclo de conocimiento apoya la identificación formal de los elementos involucrados y las conexiones de los flujos de conocimiento en el análisis de procesos [24], en este caso procesos de software [10]. Además, dicho enfoque representa el conocimiento requerido y generado por las actividades [23]. La adquisición y creación de conocimiento es el punto que plantea mayor dificultad al momento de diseñar o actualizar el modelo conceptual o implementar la BC [26]. Sin embargo, tanto las lecciones aprendidas como la configuración del software, registros, reportes, planes y otros documentos son elementos necesarios que deben de almacenarse en la BC.

En la figura 4 , los tipos de conocimiento se identifican por medio de llaves [10]. Cuando los RP obtienen significados o definiciones directamente de las normas NMX-I-059 y NMX-I-15504 generan conocimiento tópico o semántico y al mismo tiempo hacen uso de conocimiento explícito. Estos tipos de conocimiento se aprecian claramente cuando los RP pueden consultar la primera parte de la NMX-I-059 para revisar las descripciones de los 70 PT y/o la primera parte de la NMX-I-15504 con los conceptos relacionados al proceso de evaluación.

A diferencia del conocimiento tópico, el conocimiento episódico consiste de la experiencia de los roles con el conocimiento mismo, donde las actividades para cada uno de los procesos son aprendidas a través de la experiencia, una vez que el conocimiento tópico y técnico son adquiridos [27]. Por ejemplo, algunos autores señalan que el proceso es una abstracción de prácticas llevadas a cabo en varios proyectos diferentes por personas diferentes, así es posible generar conocimiento continuamente y mejorar el proceso desde la experiencia ganada [28]; es decir, generar y transmitir conocimiento episódico. Por otro lado, se generaría conocimiento técnico o procedural al incluir las habilidades no formales de los roles y el conocer cómo se lleva a cabo una determinada actividad por medio de la práctica [10].

Partiendo de que un ciclo de mejora se entiende como un conjunto de actividades encaminadas a obtener un beneficio en una organización [29] es de relevancia conocer cómo los conocimientos episódico, tópico y/o procedural pueden apoyar en gran medida el logro de un proyecto de SPI. Para esto, se utilizó como una unidad experimental el desarrollo de un proyecto de SPI en una empresa mexicana de desarrollo de software. La Figura 4 también muestra las tres etapas en las que consistió el desarrollo del proyecto de SPI: 1) Diagnóstico de procesos en función de los requisitos normativos; 2) Establecimiento de la Estrategia de implantación con base en las necesidades de mejora; y 3) Evaluación de los resultados obtenidos y mejora de los procesos implantados. Para lograr un nivel 2 de madurez, dicha implantación se realizó a través de tres ciclos de mejora. Esta metodología de implementación de SPI en un caso de estudio junto al ciclo de conocimiento, se alinea al proceso de transdisciplinariedad al identificar y estructurar los tipos y fuentes de conocimientos relacionados a los niveles 1 y 2 de capacidad de procesos, o si en la ausencia de conocimiento como se establecen estrategias de creación y transferencia de conocimiento para alcanzar el objetivo estratégico.

Proyecto de mejora de procesos de software en una empresa mexicana

La empresa de este caso de estudio, en el 2008, obtuvo su primera verificación por parte de NYCE [30]. Durante el cierre del proyecto, se detectó la necesidad de incrementar el conocimiento procedural y tópico de los RP para la interpretación de cada uno de los AP y los indicadores requeridos por el nivel 2 de capacidad. En el 2009, la empresa estableció un nuevo convenio con el Grupo consultor para crear un proyecto de SPI para el nivel 2 de madurez alineado con su planeación estratégica.

Se estableció un calendario con las sesiones de trabajo para recoger los datos y evidencias de todos los procesos requeridos desglosadas en 2 hr/sem/mes. Entre el Grupo consultor y el Responsable de GPR (RGP), se realizó una evaluación para verificar la implementación completa de los 9 procesos para el nivel 1. La evaluación de nivel 2 fue realizada totalmente por el Grupo consultor participando el RGP como observador. La metodología del proyecto de SPI que se siguió consistió en las tres etapas descritas a continuación.

Diagnóstico de procesos

Aún cuando, el RGP tenía amplio conocimiento tópico sobre el modelo MoProSoft [1] y la NMX-I-059, no había utilizado la NMX-I-15504, por lo que se inició con su capacitación en la implantación del nivel de capacidad de acuerdo a la NMX-I-059 y el método de evaluación. Como los sujetos experimentales tienen un importante efecto en los resultados, se motivó y brindó capacitación tópica y técnica, con las tareas propias de los 9 procesos asignados, a las 5 personas que forman el equipo de trabajo.

En el primer ciclo de mejora, se utilizó conocimiento explícito al especificar los requerimientos de nivel 2 de capacidad según la NMX-I-059. El propósito de nivel 2 es que el proceso realizado se implemente de manera administrada (planeado, supervisado y ajustado) y sus PT están apropiadamente establecidos, controlados y mantenidos [15]. Dado que cada nivel está basado en la capacidad anterior, adicional a las PB y los 34 PT de nivel 1 [31], se sumaron las PB y los PT requeridos para el nivel 2. Cabe destacar que la cantidad de PT para nivel 2 puede variar significativamente dependiendo la metodología de desarrollo de software que aplique la empresa, lo que incrementa el volumen y complejidad de la información y PT.

Como resultado de este ciclo, se obtuvo que la organización ya realizaba algunas PB de nivel 2 de capacidad lo que le permitía obtener sus respectivos PT por proceso. Se identificaron los 4 proyectos de software sobre los que se aplicaría la verificación oficial de acuerdo al número de proyectos sugeridos en la parte 04 de la NMX-I-059 [32].

Implantación del proyecto de mejora

En el siguiente ciclo de mejora, se orientó a los RP a que identificaran cuáles IAP (PG, RG y PTG) ya se ejecutaban o contaban como práctica diaria de sus procesos. Como resultado, del diagnóstico se comunicó el grado de cumplimiento de los IAP para su ajuste o implantación. Todos los RP conocieron la pertinencia de adoptar las prácticas faltantes, lo que permitió establecer un proceso incremental para mejorar constantemente los resultados deseados.

Para la GC explícito, la empresa desarrolló una BC bajo un ambiente Web, tipo intranet, donde cada RP podía encontrar los PT generados y relevantes a las PB que realizaba. Así mismo, la BC contaba con las propiedades de control de acceso, rastreo de modificaciones, conteo del estado de la configuración y capacidad de almacenamiento.

Evaluación y mejora de procesos implantados

Los conocimientos tipo tópico y procedural generados en la etapa 1 del proyecto contribuyeron a mejorar el instrumento de evaluación [29] al incluir los IAP de acuerdo al marco de mediciones y, por lo tanto, evaluar el logro de la capacidad de procesos [20]. Los estándares internacionales relacionados con métodos de evaluación, definen el marco para realizar la evaluación y los indicadores pero no especifican de manera explícita los modelos simbólicos o matemáticos que ayuden a determinar el valor del rendimiento o capacidad de un proceso [6]. Por lo que el alcance de este trabajo, tanto en la especificación de medidas de desempeño y capacidad no se considera algún peso de diferenciación entre los ID e IAP. Un trabajo de investigación a futuro será aproximarse a los pesos de estos indicadores.

Para obtener la Medición del Desempeño del Proceso (MDP) y la Medición de la Capacidad del Proceso (MCP) se definió un modelo matemático. Los indicadores de desempeño (ID) al igual que los IAP fueron evaluados asignando la calificación de acuerdo a la escala porcentual correspondiente al logro demostrado (Tabla 2). La MDP considera que cada proceso contiene más de una PB y PT. Que las PB tienen actividades y que estas actividades pueden tener tareas. Que los PT tienen elementos, que estos elementos a su vez pueden ser un PT. Por lo tanto, la calificación otorgada a cada ID es el resultado del promedio de las calificaciones asignadas a cada uno de los elementos contenidos en ellos: . Por otro lado, en la MCP se observó que cada AP tiene asociado más de un logro (Figuras 1 y 3). Cada logro tiene una PG, cada PG requiere de uno o más RG y PTG. Estos tres IAP, a su vez, tienen elementos o características a evaluar. Por lo tanto, la calificación otorgada a cada PG es el resultado del promedio de las calificaciones asignadas a cada uno de los elementos contenidos en cada IAP: La calificación del AP es el promedio del logro: . En la tabla 3 se muestra un ejemplo resumido de la evaluación del AP. 2.2, con sus IAP asociado al Logro a).

Análisis e interpretación de resultados

Se recopilaron los valores del número de PB y PT realizados, correspondientes a las variables independientes, para su procesamiento. El equipo de trabajo desempeñó un total de 28 PB y 50 PT correspondientes al ajuste de sus procesos. El Grupo consultor emitió un informe del perfil de capacidad de procesos y un reporte de hallazgos. El RGN y RGP revisaron los resultados y disminuyeron los riesgos encontrados en aquellos procesos en los que se observaron ciertos hallazgos o una calificación inferior al 50%. Se institucionalizó, a través de verificaciones y validaciones, que lo que se realizaba en cualquiera de los 9 procesos era correcto. Por otro lado, aunque ya se contaba con plantillas para los PT se añadieron mecanismos para su definición, requisitos, identificación, revisión, disponibilidad, control e integración mediante una BC más completa, que apoyó también el cumplimiento de los AP al propiciar la GC explícito.

Ejecución de mejoras y evaluación final

Tanto las sesiones de mejora de procesos, que eran aplicables a corto plazo, como las evaluaciones permitieron aumentar el conocimiento episódico del equipo de trabajo. En el 2010, se auditó el cumplimiento de los 9 procesos y elementos requeridos de conformidad con la NMX-I-059/02 para el nivel 2. La verificación se realizó en tres días y fue realizada por un único verificador quien hizo entrega el dictamen de conformidad y los hallazgos encontrados, así como una serie de conclusiones útiles para el mantenimiento y SPI. Posterior a la verificación oficial, la empresa ha promovido la mejora continua de los procesos requeridos y otros métodos de trabajo como en el área de finanzas, enfatizando la generación y utilización del conocimiento. Está determinada en seguir avanzando en su nivel de madurez y tener un posicionamiento internacional.

Tipos y fuentes de conocimientos detectados

Uno de los aspectos más importantes en una iniciativa de GC es la categorización y análisis del conocimiento y los activos de conocimiento requeridos. De esta forma, la GC relacionada en proyectos de SPI promueve la mejora continua de los procesos y métodos, enfatizando la generación y utilización del conocimiento relevante. Por tal motivo, es necesario caracterizar las fuentes y tipos de conocimiento contenidos en proyectos de SPI para establecer e integrar estrategias adecuadas de GC para una MIPyME de desarrollo de software.

Caracterización de fuentes y tipos de conocimientos

Tomando la clasificación para los tipos de conocimiento de Rodríguez-Elias y Martínez [11], se asociaron las fuentes y tipos de conocimientos presentados en las secciones anteriores (Tabla 4 ):

• Conocimiento obtenido de la fuente. El conocimiento se genera a partir de la fuente para la realización de las actividades. En este caso, el conocimiento explícito presentado en los elementos de la NMX-I-059, los AP de la NMX-I-15504 y los PT requeridos para los niveles de capacidad corresponden a este tipo de conocimiento.

• Conocimiento almacenado en alguna fuente. Debido a la importancia de almacenar los activos de conocimiento de la organización y tenerlos disponibles para los diferentes RP, el conocimiento almacenado se centra en el conocimiento explícito y episódico.Para esto, se utilizan herramientas de apoyo a la GC para almacenar, buscar y recuperar eficientemente dichos tipos de conocimiento. La BC contiene los activos de conocimiento que los RP necesitan consultar antes de realizar las PB y los PT generados por la ejecución de las PB. Los RP deben conocer cualquier conocimiento episódico, procedural o tópico almacenado en la BC, para disminuir la posibilidad de incurrir en problemas recurrentes y transmitir conocimiento entre un grupo de trabajo [15].

• Conocimiento de los roles. Se refiere al conocimiento que aportan las personas para desempeñar su rol y de esta forma realizar las actividades asignadas a un proceso determinado. Este tipo de conocimiento se observa según el nivel de experiencia de los roles en el manejo de estándares para la mejora y evaluación de procesos. También se refiere a los conceptos y/o definiciones significativas que los roles ya conocen sobre algún tema.

• Conocimiento obtenido por los roles. Es el conocimiento que obtienen los roles al desempeñar las actividades del proceso. Por ejemplo, el conocimiento tópico adquirido por los RP en el manejo de la NMX-I-059/02 para las PB y PT y su relación explícita a los AP de la NMX-I-15504. El conocimiento técnico o procedural que el rol usa al crear plantillas para los PT. También, el conocimiento episódico se observa cuando los roles expresan sus experiencias o lecciones aprendidas durante un proceso de verificación oficial para garantizar la capacidad de sus procesos.

Contribución práctica del caso de estudio

El caso de estudio permitió identificar los tipos y fuentes de conocimiento, verificar empíricamente si el conjunto de actividades de control y mejora de procesos dependen de evaluar, objetivamente, la capacidad de procesos definida en la NMX-I-15504 y así determinar la transdisciplinariedad bajo un enfoque de GC y la madurez organizacional según lo requerido para el nivel 2 de capacidad por la NMX-I-059. Otro aspecto fue el manejo de vocabulario, lenguaje y la forma en la que el Grupo consultor transfirió entre los RP el conocimiento explícito, permitiendo a los RP plantear nuevas características funcionales a la BC que utilizaban. Es así, como consideramos que una MIPyME que desee implementar un programa de SPI basado en GC requerirá contar con conocimiento técnico o procedural al especificar las fases (o ciclos) del proyecto, del conocimiento episódico generado y almacenado en la BC detectando los activos de conocimientos y fuentes de conocimiento relacionados a los ciclos anteriores. Y todo aquel conocimiento explícito, tópico o semántico que pueda ser útil para crear, compartir y transmitirlo con todo el equipo de trabajo.

Posterior al proyecto, el Grupo consultor desarrolló la herramienta automatizada para la Autoevaluación los requisitos y Atributos de Procesos de software (AURAP), la cual considera como conocimiento explícito, los requisitos de la NMX-I-059 con los AP definidos en la NMX-I-15504 para los 5 niveles de capacidad de procesos [5]. La herramienta brinda fiabilidad en los resultados y calificaciones obtenidas permitiendo tomar decisiones ante los hallazgos detectados.

Implicaciones en el nivel de conocimiento relacionado a la dimensión de capacidad

A partir de la clasificación de los tipos de conocimiento (Tabla 4) y el modelo determinístico se analizó cómo éstos podrían estar asociados implícitamente con los niveles de capacidad de procesos, ayudando a distinguir y definir los niveles de conocimientos necesarios para los proyectos de SPI basados en GC. Tomando en cuenta a Palma, Paniagua, Martín y Marín [26] quienes especifican que el nivel de conocimiento se sitúa sobre algo simbólico, como resultado de los procesos que operan en dicho nivel, especificaremos los tipos de conocimientos detectados en los niveles de capacidad manejados en el caso de estudio.

En la dimensión de capacidad, si una organización tiene procesos de nivel 0 significa que el conocimiento no es utilizado, generado o almacenado. El nivel 1 de capacidad indicaría la existencia de conocimiento explícito obtenido por las fuentes al identificar los requisitos en las normas mexicanas y la creación de conocimiento tópico y procedural por parte de los RP al aprender a generar y utilizar los PT al ejecutar las PB. Al final de cada ciclo del proyecto de mejora de nivel 2 de capacidad, la MIPyME contará con nuevo conocimiento explícito almacenado en alguna fuente, conocimiento episódico obtenido y transmitido por los RP y demás activos de conocimiento almacenados en la BC para futuros proyectos (Figura 5). De esta forma, los niveles de capacidad de procesos se constituyen por diferentes tipos de conocimiento que los RP adquieren, procesan, utilizan, almacenan o transmiten para determinar qué acciones tomar para lograr la calidad de sus procesos. Esto significaría que un nivel 5 de capacidad indicaría que todos los tipos de conocimiento estarían disponibles para todos los RP que deseen hacer uso de ellos por medio de una adecuada tecnología de GC (recursos de infraestructura, intranet y varias BC eficientes para el cumplimiento de los ID y IAP), con el propósito de que la organización logre la innovación y optimización de los procesos. En este nivel de capacidad, una organización mexicana obtendrá su madurez cuando el proceso de Gestión de Negocio cumpla con los requisitos normativos de nivel 5 y los 8 procesos restantes alcancen el nivel 4 de capacidad [16].

La figura 5 también especifica cómo el nivel de conocimiento del nivel 1 servirá como punto de partida para la reutilización del conocimiento dentro de la organización; es decir, el contar con diversos tipos de conocimientos que puedan ser aplicables a distintos problemas se puede interpretar como la utilización del mismo nivel de conocimiento para distintas instancias de los niveles inferiores [26].

Conclusiones

Si bien la implantación de proyectos de SPI bajo MRP, internacionales o nacionales, es un camino que ya emprendieron algunas organizaciones, el reto de las investigaciones es analizar cuál tipo de conocimiento es capturado, recuperado y almacenado para compartir, divulgar o representarse [10], de tal manera que las MIPyMES que aún no han adquirido una cultura de calidad se apoyen de ellos. En este trabajo nos referimos al aspecto normativo como la preparación general de las MIPyMES para tomar en cuenta los diversos tipos de conocimiento que poseen al ejecutar procesos definidos en la NMX-I-059. De esta forma, consideramos que una parte esencial de un proyecto de SPI es el conocimiento, en sus diversas clasificaciones, como factor de éxito que les permite a las organizaciones desarrolladoras de software ser generadoras de nuevo conocimiento o proyectos de conocimiento, llevándolas a elevar su madurez organizacional.

La disponibilidad de los RP para incorporar, generar y transferir todo aquel conocimiento derivado de la SPI no era una práctica común. Se analizó cómo los RP adquirieron nuevo conocimiento tópico, en el manejo de las normas NMX-I-059 y la NMX-I-15504. Así mismo, la empresa constató que para realizar una evaluación objetiva es fundamental poseer conocimiento explícito, procedural y episódico acerca del marco de medición de los indicadores de desempeño e IAP. En el estado de Baja California no existen aún otras organizaciones con nivel 2 de madurez y sólo 2 cuentan con nivel 1, siendo una de las entidades con más bajo nivel de verificaciones oficiales, por lo que se está haciendo el esfuerzo de que el resultado de este caso de estudio sea una variable de respuesta para verificar los efectos de las variaciones que se provocan en otras investigaciones empírica

El proyecto de SPI representó un importante desafío y esfuerzo a la empresa del caso de estudio, similar al que otras han experimentado [33], por lo que consideramos puede ser de utilidad a la industria de software y/o otros investigadores: como parámetros, las normas para implantación de procesos de software y evaluación de la capacidad de procesos, y como otros factores clave, los tipos y fuentes de conocimiento detectados (Tabla 4) para los dos primeros niveles de conocimiento relacionados en un proyecto de SPI basado en GC.

Debido a que los resultados parciales son alentadores, como trabajo futuro se desea continuar con la caracterización de los tipos de conocimientos y sus mecanismos involucrados en la definición del nivel de conocimiento para los siguientes niveles de la dimensión de capacidad, los cuales permitan a las MIPyMES establecer estrategias adecuadas para implementar proyectos de SPI basados en GC.

Referencias

1. H. Oktaba, M. Piattini. Software Process Improvement for Small and Medium Enterprises. 1^st. ed. Ed. IGI Global. NewYork, USA. 2008. pp. 394.         [ Links ]

2. NMX-I-059/01 -NYCE-2005. Tecnología de la Información - Software - Modelos de Procesos y Evaluación para el Desarrollo y Mantenimiento de Software. Parte 01, Definición de Conceptos y Productos (MoProSoft). 1^a ed. Ed. NYCE, DF. México, México. 2005. pp.36.         [ Links ]

3. Programa de Desarrollo del Sector de Servicios de Tecnologías de Información (PROSOFT 2.0). Ed. Secretaría de Economía. México, 2008. Disponible en:http://www.prosoft.economia.gob.mx/doc/prosoft20.pdf. Consultado: marzo de 2013.         [ Links ]

4. ISO/IEC 15504-2:2003. Information Technology - Process Assessment - Part 2 Performing an Assessment. International Standards. 1^st ed. Ed. ISO/ IEC. Geneva, Switzerland. 2003. pp. 16.         [ Links ]

5. J. Morales, M. Astorga, B. Flores, G. López, J. Ibarra. AURAP una Herramienta para la Autoevaluación de Requisitos y Atributos de Procesos de Software Definidos en las Normas NMX-I-059-NYCE-2005 y NMX-I-006-NYCE-2006. In Proc. of Congreso Internacional de Investigación e Innovación en Ingeniería de Software. Guadalajara, Jalisco. México. 2012. pp. 175-181.         [ Links ]

6. F. Pino, F. García, M. Serrano, M. Piattini. ''Medidas para estimar el rendimiento y Capacidad de los Procesos de Software de Conformidad con el Estándar ISO/IEC 15504-5:2006''. Revista Española de Innovación Calidad e Ingeniería del Software. Vol. 2. 2006. pp. 17-29.         [ Links ]

7. CERTVER. Disponible en: http://www.certver.com. Consultado: Diciembre 2012.         [ Links ]

8. M. Niazi, D. Wilson, Zowghi. ''A Framework for Assisting the Design of Effective Software Process Improvement Implementation Strategies''. Journal of Systems and Software. Vol. 78. 2005. pp. 204-222.         [ Links ]

9. S. Bayoda, J. Calvo, G. Cuevas, T. San Feliu. ''Taxonomía de Factores Críticos para el Despliegue de Procesos Software''. Revista Española de Innovación, Calidad e Ingeniería del Software. Vol. 6. 2010.         [ Links ]

10. B. Flores, S. Gastélum, O. Rodriguez. Modeling Knowledge Flows in Software Projects Management Processes. In Proc. of International Conference on Knowledge Management and Information Sharing (KMIS). Valencia, Spain. 2010. pp. 213-217.         [ Links ]

11. O. Rodríguez, A. Martínez. Diseño de Sistemas y Estrategias de Gestión del Conocimiento: Un Enfoque Metodológico Orientado a Procesos y Flujos de Conocimiento. 1^a ed. Ed. Académica Española. Saarbrücken, Alemania. 2011. pp. 236.         [ Links ]

12. C. Pohl, G. Hirsch. ''Methodological Challenges of Transdisciplinary Research''. Natures Sciences Sociétés. Vol. 16. 2008. pp. 111-121.         [ Links ]

13. E. Gutiérrez, A. Gutiérrez, A. Pérez, L. Márquez. ''Acerca de la Implementación de los Modelos de Calidad en la Construcción de Software en México''. Revista Digital Universitaria. Vol. 9. 2008. pp. 3-21.         [ Links ]

14. H. Oktaba. MoProSoft ®: A Software Process Model for Small Enterprises. 1^st Research Workshop for Process Improvement in small settings. Pittsburgh. USA. 2005. pp. 93-101.         [ Links ]

15. NMX-I-059/03-NYCE-2005. Tecnología de la Información - Software - Modelos de Procesos y Evaluación para el Desarrollo y Mantenimiento de Software. Parte 03, Guía de Implantación de procesos. 1^aed. Ed. NYCE. México DF., México. 2005. pp.104.         [ Links ]

16. NMX-I-05 9/02-NY CE-2011. Tecnología de la Información - Software - Modelos de Procesos y Evaluación para el Desarrollo y Mantenimiento de Software. Parte 02, Requisitos de Procesos (MoProSoft). 2^a ed. Ed. NYCE. México DF., México. 2011. pp. 62.         [ Links ]

17. Nonaka, H. Takeuchi. ''The Knowledge-creation Company: How Japanese Companies Create the Dynamics of Innovation''. 1^st ed. Ed. Oxford University Press. New York, USA. 1995. pp. 304.         [ Links ]

18. J. Garzás, C. Fernández, M. Piattini. ''Una aplicación de la Norma ISO/IEC 15504 para la Evaluación por Niveles de Madurez de Pymes y Pequeños Equipos de Desarrollo''. Revista Española de Innovación, Calidad e Ingeniería del Software. Vol. 5. 2009. pp. 88-98.         [ Links ]

19. NMX-I-15 504/02-NY CE-2010. Tecnología de la Información - Evaluación de los Procesos — Parte 02: Realización de una evaluación. 1^a. ed. Ed. NYCE. México DF., México. 2010. pp. 47-62.         [ Links ]

20. NMX-I-15504/05-N Y CE-2010. Tecnología de la Información - Evaluación de los Procesos - Parte 05: Ejemplo de un Modelo de Evaluación de los Proceso. 1^a ed. Ed. NYCE. México DF., México. 2010. pp. 79-100.         [ Links ]

21. Normalización y Certificación en Electrónica (NYCE). Lista de empresas dictaminadas. Disponible en: http:// www.nyce.org.mx/. Consultado: Mayo 2012.         [ Links ]

22. B. Flores, O. Rodríguez. ''Interpretación de la Gestión de Proyectos de Software desde un Enfoque de la Gestión del Conocimiento''. Libro Electrónico de Avances en Tecnologías de la Información. 1^a ed. Ed. Alfaomega. Ensenada, México. 2009. pp. 245-251.         [ Links ]

23. O. Rodriguez, A. Martínez, A. Vizcaíno, J. Favela, M. Piattini. ''Modeling and Analysis ofKnowledge Flows in Software Processes Through the Extension of the Software Process Engineering Metamodel''. International Journal of Software Engineering and Knowledge Engineering. Vol. 19. 2009. pp. 185-211.         [ Links ]

24. C. Choo, R. Johnston. ''Innovation in the Knowing Organization: a case Study of an e-commerce Initiative''. Journal of Knowledge Management. Vol. 8. 2004. pp. 77-92.         [ Links ]

25. C. Salviano. ''A Modeling View of Process Improvement, Software Process Improvement and Capability Determination''. SPICE 2011. 1^st ed. Ed. Springer. Dublin, Ireland. 2011. pp. 16-27.         [ Links ]

26. J. Palma, E. Paniagua, F. Martín, R. Marín. ''Ingeniería del Conocimiento. de la Extracción al Modelado del Conocimiento''. Revista Iberoamericana de Inteligencia Artificial. Vol. 11. 2000. pp. 46-72.         [ Links ]

27. P. Robillard. ''The Role of Knowledge in Software Development''. Communications of the ACM. Vol. 42. 1999. pp. 87-92.         [ Links ]

28. L. Scott, R. Jeffery, L. Carvalho, J. D'Ambra, P Rutherford. Practical Software Process Improvement -The IMPACT Project. In Proc. of the Australian Software Engineering Conference. Washington, USA. 2001. pp. 182-189.         [ Links ]

29. H. Oktaba, M. Piattini, J. Pino, M. Orozco, C. Alquicira. COMPETISOFT: Mejora de Procesos Software para Pequeñas y Medianas Empresas y Proyectos. 1^a ed. Ed. Alfaomega Ra-Ma. Madrid, España. 2008. pp. 284.         [ Links ]

30. B. Flores, M. Astorga, J. Olguín, M. 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. of the Mexican International Conference on Computer Science. Los Alamitos, USA. 2008. pp. 323-328.         [ Links ]

31. A. Astorga, B. Flores, G. Chávez, M. Lam, A. Justo. ''Lecciones Aprendidas en la Implantación de MoProSoft en una empresa escolar: caso AvanTI''. Revista Ibérica de Sistemas y Tecnologías de la Información. Vol. 6. 2010. pp. 73-86.         [ Links ]

32. NMX-I-059/04-NYCE-2011. Tecnología de la Información - Software - Modelos de Procesos y Evaluación para el Desarrollo y Mantenimiento de Software. Parte 04, Directrices para la evaluación de procesos (EvalProSfot). 2^a ed. Ed. NYCE. México DF., México. 2011. 18 pp.         [ Links ]

33. J. Cukier. ''Problemas de las Pymes en el Nivel 2 de Madurez. Una Muestra Sesgada''. Revista Española de Innovación Calidad e Ingeniería del Software. Vol. 4. 2008. pp. 20-32.         [ Links ]