Índice

PRÓLOGO

INTRODUCCIÓN

CAPÍTULO I. MARCO TEÓRICO

CAPÍTULO II. MARCO CONCEPTUAL DE LA GESTIÓN DEL CONOCIMIENTO EN PROCESOS SOFTWARE

CAPÍTULO III. MODELO DECLARATIVO DE PROCESOS DE CONOCIMIENTO

CAPÍTULO IV. CONCLUSIONES Y TRABAJO FUTURO

REFERENCIAS BIBLIOGRÁFICAS

LEGALES

Universidad Autónoma de Baja California

Brenda Leticia Flores Ríos

Modelo de evolución de

la gestión del conocimiento en mipymes, de acuerdo con el nivel de madurez en un programa de mejora de procesos de software

Prólogo de Alberto Mexía Sánchez

Selección Anual para el Libro Universitario

DEDICATORIA

A Jorge Humberto, Eduardo Arturo y Jorge E., con todo mi amor.

A mi mamá Yolanda, por compartir mis sueños y metas,

en especial, en cada instante de este proyecto.

AGRADECIMIENTOS

Esta obra fue evaluada y recibió recomendaciones e importantes contribuciones de los doctores Óscar Mario Rodríguez Elías, del Instituto Tecnológico de Hermosillo, Sonora; Sara Ojeda Benítez, Gabriel López Morteo, Guillermo Licea, Félix Fernando González Navarro y José Martín Olguín, de la Universidad Autónoma de Baja California; y de Francisco J. Pino, de la Universidad del Cauca, Colombia.

PRÓLOGO

Desde hace algunos años, la industria de desarrollo de software en México ha adoptado distintos modelos de procesos en la búsqueda de mayor competitividad como es el caso del CMMI (Capability Maturity Model Integration) o la NMX-I-059-NYCE-2011 (MoProSoft), entre otros. Esto ha llevado a las organizaciones a implementar diversas estrategias al adoptar estos modelos enfrentando retos que van desde la resistencia al cambio en procesos, roles y paradigmas, hasta la decisión de ejecutar los proyectos de manera interna o mediante un apoyo de consultoría. Pero, definitivamente, uno de los grandes problemas que se presentan durante un programa de mejora, tiene que ver con la gestión del conocimiento.

El presente libro surge a partir de la tesis doctoral que la Dra. Brenda Leticia Flores Ríos realizó en la Universidad Autónoma de Baja California y que se caracterizó por su cercanía con organizaciones que presentaban diversas etapas de implantación de sus modelos de procesos.

La obra cuenta con varias características de alto valor para sus lectores, empezando por la fundamentación teórica que presenta conceptos de “carácter complejo y multifacético” —como ella misma los define— acerca de la gestión de conocimiento y su relación con la ingeniería de software, desarrollados con un enfoque sencillo y didáctico que permite a un espectro más amplio de lectores explorar su contenido. El lenguaje y sintaxis utilizados muestran una rigurosidad científica, lo cual genera gran valor en un contenido robusto y certero dirigido tanto para investigadores en el área de ingeniería de software e ingeniería de procesos, como para las empresas de desarrollo que requieran conocer y ahondar sobre la gestión del conocimiento durante la implementación de un proyecto de mejora de procesos. Su referencia bibliográfica es cuidadosamente elegida y documentada durante cada capítulo. Constantemente se presentan esquemas, gráficos y cuadros de información que resumen y describen las ideas principales de manera original, lo que facilita el entendimiento de ideas de alta complejidad y valor, mostrando, además, la dedicación y cuidado que caracteriza la investigación completa.

La Dra. Flores pone especial atención en los distintos tipos de conocimiento que se desarrollan dentro de las organizaciones; hace énfasis en cómo la adecuada transferencia del conocimiento, capacidades y experiencias pueden llegar a ser la pieza clave para la innovación y competitividad en una industria que evoluciona constantemente, desarrollando la idea de que a través de la institucionalización de los procesos gerenciales, operativos y de gestión de conocimiento se alcanzarían de manera más contundente los niveles de competitividad globalizados que se requieren hoy en día.

Lo anterior representa un gran reto para cualquier organización, sobre todo en términos del flujo de conocimiento, por lo que se analiza detalladamente la implementación de modelos, como el SECI (socialización, exteriorización, combinación e interiorización), además del modelo de ciclo de conocimiento, explorando los problemas y riesgos propios de cualquier organización cuyas capacidades dependen intrínsecamente del conocimiento y experiencia de sus integrantes. Siendo esto, en mi opinión, una de las aportaciones más valiosas de su investigación, ya que se basa en el estudio de cómo el conocimiento tácito de los individuos, al ser gestionado adecuadamente, mejora las capacidades de resolución de problemas y ejecución de los procesos de la organización de una manera más eficaz y eficiente, derivado en conocimiento explícito.

Como resultado de su investigación, la Dra. Flores realiza una serie de contribuciones de alto valor; un ejemplo de ello es el marco para la descripción de procesos de conocimiento cuya característica principal radica en la implantación que se realizó durante las estancias de investigación en empresas de desarrollo de software que permitieron validar sus hipótesis.

Otra aportación de gran relevancia es el modelo bidimensional para la descripción de flujos de conocimiento. La información documentada y generada presenta la oportunidad de desarrollar diversas líneas de investigación, desde la validación empírica del modelo hasta investigaciones más profundas desde el punto de vista de los procesos y los roles involucrados.

Por último, el presente libro ofrece distintas aristas según sea el enfoque que lo atraiga hacia su lectura, ya sea un ávido de conocimiento, un investigador en busca de respuestas, un experto en mejora de procesos o un emprendedor en busca de la mejora continua, gracias a su enfoque orientado hacia la investigación aplicada y a la cercanía con que la autora trabajó durante sus estancias de investigación en micro y pequeñas empresas de software de la región noroeste de México.

Ing. Alberto Mexía Sánchez

Director de Certui

INTRODUCCIÓN

Las organizaciones contienen elementos estáticos y dinámicos que, mutuamente, intervienen en el grado o nivel en el cual el conocimiento se adquiere y se utiliza (Claver, Pertusa & Zaragoza, 2008). Cuando éstas aplican habitualmente los principios de gestión del conocimiento con el objetivo de lograr una adaptación al ambiente cambiante o globalizado, logran identificar y capturar conocimientos para su posterior transferencia y reutilización (Kamsu et al., 2008).

Partiendo del hecho de que la ingeniería de software[1] utiliza intensamente el conocimiento, es de suponer el impacto de la gestión del conocimiento en esta disciplina (Dingsøyr, Bjornson & Shull, 2009).

Una organización dedicada al desarrollo de software es una entidad altamente intensiva en uso de conocimiento, por lo que la transferencia del aprendizaje es crítica para ella. Asimismo, un proceso de software es también un proceso de adiestramiento intensivo de conocimiento organizacional y necesita ser apoyado con técnicas de gestión del conocimiento (Wan et al., 2009). De esta forma, la aplicación de la gestión del conocimiento en el campo de desarrollo de software permite conocer cómo la experiencia en desarrollos previos es interiorizada por los roles participantes y utilizada para reducir costos y defectos, mejorar la calidad de los productos (Dingsøyr & Conradi, 2002) y apoyar el proceso de desarrollo de software (Landes et al., 1999).

A nivel mundial, la industria del software está formada por micros, pequeñas y medianas empresas (mipymes), que suponen ser cerca de 90% de los negocios formales y que generan entre 40% y 50% del empleo total (Calvo Manzano et al., 2008). En este sentido, y para ayudar a las mipymes en sus esfuerzos de mejora, el Instituto de Ingeniería de Software (SEI, por las siglas en inglés) introdujo el enfoque de mejora de procesos de software (SPI, por las siglas de software process improvement).

Por otro lado, la Organización Internacional para la Estandarización (ISO, por las siglas en inglés) definió, en su junta plenaria de Helsinki, que dentro del subcomité 7 de ingeniería de software y sistemas (SC7) se creara el grupo de trabajo (WG24) llamado SC7-WG24. Este grupo fue el responsable de la descripción de un marco común para los perfiles evaluables de las pequeñas y medianas organizaciones (VSE, por las siglas de Very Small Enterprises), debido a que se ha reportado que a las mipymes o VSE les resulta difícil relacionar las normas ISO con sus necesidades de negocio (Laporte et al., 2008). Separar los perfiles de las VSE con menos de diez empleados y aquellas con más de diez y hasta veinticinco empleados, fue la primera categoría de interés para el WG24 (Laporte et al., 2008).

En este libro se resalta la importancia de aplicar dentro de una mipyme o VSE técnicas y enfoques de gestión del conocimiento como parte de un proyecto de SPI y como resultado de la integración de estrategias, recursos, procesos y roles orientados al conocimiento, más elementos activos relevantes como lecciones aprendidas, mejores prácticas y experiencias. Algunos beneficios reportados son la reducción de tiempo y costo del desarrollo de un producto de software, el incremento de la calidad y de las capacidades de toma de decisión (Dingsøyr, 2009). Por lo anterior, se considera que la transdisciplinariedad de un proyecto de SPI, con base en gestión del conocimiento, promoverá la mejora continua de los procesos, la identificación de recursos o herramientas de aprendizaje, la aplicación de métodos o técnicas apropiados o recomendados para la generación, transferencia y evolución de las enseñanzas adquiridas.

En este apartado se presenta la introducción al trabajo a desarrollar, la problemática detectada dentro del contexto de gestión del conocimiento y mejora de procesos de software, la cual brinda las bases para definir los objetivos específicos. Se exponen también las fases de la metodología utilizada y se detallan las aportaciones o resultados obtenidos en las actividades realizadas.

PLANTEAMIENTO DEL PROBLEMA

Se define a la mejora de procesos como el esfuerzo continuo para saber acerca del sistema de causas en un proceso y usar este conocimiento en el cambio y mejora del proceso con el objetivo de reducir su variación, complejidad e incrementar la satisfacción del cliente (Moen et al., 1999). En este sentido, la mejora de procesos va encaminada a mantener estables los procesos que permitan obtener los resultados esperados (Capote et al., 2008).

La mejora de procesos, asociada en el contexto de la industria de software, ha llegado a ser un tema de interés para practicantes e investigadores (Dyba, 2000; Hall et al., 2002; Niazi et al., 2005). Actualmente, las grandes organizaciones desarrolladoras de software (más de 200) y las mipymes no sólo miden la calidad del producto terminado, sino también desean medir la calidad del proceso en el que se desarrollan sus productos de software (Pino et al., 2006). Es por ello que implementan modelos de calidad para apoyar su planificación, control y mejora de sus procesos (Bohem, 1998).

El proceso de SPI es continuo y evolutivo, con ciclos repetitivos a través de las fases de evaluación actual de las prácticas de software, identificación y priorización de mejoras y procesos, implementación e institucionalización de mejoras, y evaluación de experiencias de mejoras (McFeeley, 1996). Es así como un proyecto de SPI, dentro de una organización, es la aproximación a la mejora sistemática y continua de la capacidad de sus procesos para producir y entregar software de calidad (Arent & Nørbjerg, 2000).

Según Dyba (2003), la diferencia fundamental entre las mipymes y las grandes empresas, se centra en las respectivas aproximaciones o visiones de los programas de SPI que se llevan a cabo en cada tipo de organización. En las grandes empresas se despliegan sus buenas prácticas a través del establecimiento de modelos de referencia y evaluación de procesos, procedimientos estandarizados, guías y reglas establecidas, entre otros. Por el contrario, las mipymes obtienen sus mejores resultados derivados de la creatividad y la dedicación extraordinaria del recurso humano involucrado en el proyecto de SPI. Esto implica que las mipymes deben esforzarse en conseguir la participación de su recurso humano y en explorar su conocimiento (Mas & Amengual, 2005).

En las mipymes, gestionar el conocimiento relacionado a la SPI requiere de tiempo (entre 18 a 24 meses), recursos y esfuerzo (Pino et al., 2007), debido a que el conocimiento relacionado con los procesos se define y gestiona de manera formal mediante el uso de modelos de referencia de procesos. La evidencia de la realización de las actividades es almacenada en una base y/o repositorio de conocimiento. En ocasiones, buscan apoyo de un consultor para la formalización y puesta en marcha de un proyecto de SPI, donde en los primeros ciclos de mejora, el generar o actualizar el conocimiento almacenado en el repositorio, les requiere hacer cambios significativos en las actividades que realizan a diario (Heredia García, 2012). Es frecuente que dentro de una mipyme existan recursos humanos portadores de conocimiento o con la experiencia suficiente para resolver un determinado problema, pero si se desconocen estas capacidades, difícilmente serán aprovechadas. Este problema está relacionado con el desaprovechamiento del conocimiento. Con frecuencia, las organizaciones no saben lo que realmente saben (Tiwana, 2000; Rodríguez Elías, 2007) o se centran en los aspectos técnicos, los recursos tecnológicos, las máquinas y herramientas, entre otra infraestructura.

Asimismo, se han reportado algunos factores por lo que los proyectos de SPI fallan, entre ellos se encuentran que: a) el grupo de mejora hace un inadecuado uso de prácticas, con interpretaciones erróneas o inadecuadas de los modelos de referencia o evaluación de procesos utilizados (Morales Bustamante, 2011); b) los activos intangibles generados en cada ciclo de mejora son almacenados en una base de conocimiento sin la debida gestión para la contribución efectiva en la toma de decisiones en futuros ciclos o proyectos de SPI; o c) la comunicación poco efectiva entre la alta dirección, el grupo de mejora y/o toda la organización, genera un desconocimiento de los requisitos, objetivos y el alcance del proyecto de SPI (Analabon, 2005).

Aun cuando existen normas y modelos de referencia y evaluación de procesos, tanto internacionales (CMMI, ISO 29110, ISO/IEC 15504, entre otros) como nacionales (NMX-I-059 y NMX-I-15504), para estandarizar, normalizar y medir los procesos organizacionales (Poveda Bautista et al., 2008), no son una práctica común para que las mipymes desarrolladoras de software las adquieran y/o adopten como fuentes de conocimiento específicas. Su adquisición o uso les permitiría mejorar e institucionalizar sus procesos.

Según Niazi et al. (2005), los problemas de las mejoras de procesos software no son la falta de estándares o modelos, sino la estrategia y los mecanismos para implantarlos. La estrategia debe de estar basada en la gestión del cambio y enfocada fundamentalmente en las personas (Bayoda et al., 2010), quienes deben de conocer los activos de conocimiento existentes en su organización para alcanzar el nivel de competitividad deseado o elevar su nivel de madurez actual.

El nivel de madurez se refiere al máximo grado que una organización puede obtener por todos los procesos evaluados. Los procesos se acompañan de una evolución de recursos de infraestructura y agentes humanos desempeñando roles. Las funciones y responsabilidades que asumen los roles varían en relación con el grado de capacidad de los procesos, siendo más y mayores a medida que se avanza de nivel. De esta forma, se esperaría que una organización madura de desarrollo de software tendría un alto estándar en la capacidad de procesos, conocimiento y recursos, lo cual le permitiría gestionar exitosamente los procesos asociados con el desarrollo, mantenimiento y soporte de productos de software. Este es uno de los escenarios donde se observa la relación de la gestión del conocimiento en el campo de SPI. En un proyecto de SPI se esperaría la generación, transferencia y reutilización del conocimiento en relación con la madurez de la organización, donde tanto los procesos organizacionales como los de desarrollo de software, se basan en el aprendizaje obtenido de las actividades de planeación, gestión, evaluación y control.

El reto es apoyar a las mipymes en la definición de un modelo de referencia de procesos de conocimiento que se correlacione con el grado de madurez de la organización y, por ende, al nivel de capacidad de procesos.

CONTEXTO DE MEJORA DE PROCESOS A NIVEL NACIONAL

En 2003, en México se definió el Modelo de Procesos para la Industria de Software (Moprosoft) (NMX-I-059, 2011) y el Método de Evaluación (Evalprosoft). La evolución de Moprosoft llevó a la creación de la norma NMX-I-059-NYCE-2005 (NMX-I-059, 2011), misma que establece criterios para que las mipymes, a través de su adopción e implantación como modelo de referencia, puedan estandarizar sus prácticas diarias y elevar la capacidad de sus procesos para ofrecer servicios y productos que alcancen niveles internacionales de competitividad (Oktaba et al., 2008; NMX-I-059/01, 2005).

De acuerdo con el diagnóstico del conocimiento y uso actual de modelos de calidad realizado a 114 empresas mexicanas de desarrollo de software (Gutiérrez Gasca et al., 2008), de 86% de las empresas encuestadas, sólo 44% utilizaban como modelo de referencia de procesos a Moprosoft (Oktaba, 2006) o a la norma NMX-I-059 (NMX-I-059, 2011); mientras que 26% se inclinaban por modelos de referencia internacionales. Por otra parte, 30% no refería a ningún modelo de referencia y/o evaluación de procesos. Los resultados demostraron que las organizaciones tienen un reducido conocimiento sobre los 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 (Gutiérrez Gasca et al., 2008).

Del reporte anterior, nos centraremos en 44% de las empresas que utilizan Moprosoft o la norma NMX-I-059 para exponer algunas características o particularidades de la industria mexicana.

La NMX-I-059 se integra por cuatro 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 (NMX-I-059, 2011).

En la primera parte de la norma se define a la base de conocimiento como el repositorio de los productos de trabajo, tales como: planes, productos de software, reportes, registros, lecciones aprendidas y otros documentos. Un producto de trabajo es un artefacto asociado con la ejecución de un proceso, por consiguiente, su naturaleza debe variar dependiendo del propósito del proceso. La sección 3.2.1.6 de esta norma especifica que la base de conocimiento opcionalmente puede contener conocimiento tecnológico, terminología, conceptos, metodologías y bibliotecas de reúso. Además, el inciso 3.2 de dicha parte, contiene la lista de los 70 productos de trabajo que son de tipo de entrada o salida, y el apéndice A de la parte 2 permite a las mipymes utilizarlo como guía para la construcción de su base de conocimiento conforme avanza de un nivel de madurez a otro. Sin embargo, para conocer la dependencia de los roles encargados de producirlos, validarlos y evolucionarlos, es necesario recurrir a la parte 3 de la norma.

En el taller de prácticas de uso de la NMX-I-059, impartido en 2008 en el estado de Baja California, ante una comunidad conformada por profesores y empresarios de la tecnología de la información,[2] se observó que no es fácil el manejo simultáneo de las cuatro partes de la NMX-I-059 y que, en ocasiones, se complica realizar la dependencia entre los activos de procesos. Asimismo, al realizar cada uno los nueve procesos requeridos, se analizó que los recursos de infraestructura y la capacitación necesaria, descritos para cada actividad, no proporcionan una descripción detallada de los atributos óptimos para llevar a cabo cada recurso por nivel de capacidad. Tampoco se encuentran las especificaciones de los tipos de herramientas existentes que podrían ser utilizadas, tanto para cada proceso, como el necesario según el nivel de capacidad (Gastélum Ramírez, 2011).

Otro problema que se ha detectado, en algunas organizaciones, es la generación de productos de trabajo directos, como parte de una cultura de gestión de documentos o por las indicaciones de un servicio de consultoría. Los roles que ejecutan los procesos son definidos a partir de considerar que, con el hecho de contar con los productos de trabajo, se da cumplimiento a la realización del propósito de las prácticas base (definidas en un modelo de referencia de procesos) (ISO/IEC 15504-5, 2006), acotando así algunos riesgos inherentes a una evaluación y reduciendo sus debilidades (Flores Ríos et al., 2013). Esto se debe a que los productos de trabajo que resulten de realizar las prácticas base, son la evidencia complementaria de la realización y desempeño del proceso.

Las organizaciones mexicanas dedicadas al 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 es la Organización en Normalización y Certificación Electrónica (NYCE) o la empresa Certver (2012). En el proceso de verificación, los evaluadores confirman que los roles conocen y comprenden el propósito del proceso, y realizan las actividades necesarias para las prácticas base, generando y utilizando sus productos de trabajo.

En la segunda parte de la norma, se especifica que los niveles de capacidad de procesos alcanzados y sus atributos se ubican en una escala de cinco niveles (ISO/IEC 15504, 2006). El nivel uno se asocia al nivel de capacidad y conocimiento más bajo, indicando que la organización logra el propósito del proceso. Por otro lado, el valor más alto es cinco, significando un logro en las metas del negocio proyectadas a través de la optimización y mejora continua.

De acuerdo a los datos publicados por la NYCE, en 2008, en los primeros seis meses de ese año, el número de organizaciones verificadas en el nivel uno se incrementó a 960% con respecto a los dos años anteriores. A partir del siguiente nivel de capacidad, implica que cualquier proceso debe ser planeado, institucionalizado, supervisado y adaptado para cumplir con los objetivos del proceso y producir los productos de trabajo que se identifican, documentan y controlan adecuadamente (ISO/IEC 15504-5, 2006). Sin embargo, a algunas mipymes se les dificulta cumplir con estas técnicas o, simplemente, no logran una verificación exitosa. En la consulta realizada en diciembre de 2013, a nivel nacional, existen alrededor de cinco mipymes con nivel tres de madurez, y cero para los siguientes dos niveles.

Paralelamente a los esfuerzos de la industria mexicana de software, el grupo D.21-Mejora de Procesos, utilizó Moprosoft como base para la definición del modelo Competisoft, para fomentar la mejora y competitividad de las pequeñas y medianas empresas iberoamericanas de la industria de software (Oktaba et al., 2008). Posteriormente, en el año de 2010, Moprosoft se utilizó para realizar el reporte técnico de la norma ISO/IEC 29110, presentando las guías sobre la implementación de perfiles de VSE (Campos Valdovinos & Oktaba, 2012). Algunas organizaciones que cuentan con una cultura de procesos basada en Moprosoft o Competisoft están utilizando la norma ISO/IEC 29110, con el objetivo de tener competitividad y posicionamiento internacional (Campos Valdovinos & Oktaba, 2012).

PREGUNTAS DE INVESTIGACIÓN

Si bien la implantación de la gestión de conocimiento como un proceso transversal de apoyo a una mipyme o VSE que busca elevar su nivel de madurez, también se ha dado dentro de proyectos ya puestos en marcha (Capote et al., 2008; Wan et al., 2011). El reto de esta investigación es identificar y analizar qué tipo de conocimiento adquirido o desarrollado por algunas organizaciones puede ser representado y transferido, de manera que sirva a otras que aún no han obtenido la cultura de calidad y/o implementado un proyecto de SPI con base en el conocimiento. El enfoque fundamentado en los recursos, enfatiza que los beneficios no están en repetir las prácticas de otras organizaciones, sino en explotar las diferencias existentes entre ellas, mediante el desarrollo, protección y explotación de los recursos, capacidades y conocimiento. Por tal motivo, se considera necesario responder a las siguientes interrogantes: ¿se requiere de un modelo de procesos de conocimiento que ayude a las organizaciones de software a elevar su nivel de implementación de gestión de conocimiento? ¿Cuáles son las estrategias, mecanismos o enfoques de la gestión de conocimiento que pueden estar involucrados, o que son requeridos, en un proyecto de SPI con base en el conocimiento?

OBJETIVOS

El objetivo de esta investigación es diseñar un marco de trabajo que guíe la realización de la gestión del conocimiento de los procesos software, bajo intervención, durante un proyecto de mejora realizado por una organización tipo mipyme. De tal forma que, dicho marco, facilite la implementación del proyecto.

OBJETIVOS ESPECÍFICOS

Los objetivos específicos que se proponen son:

1. Aplicar la metodología Knowledge Flow Identification (KoFI) para el análisis del flujo del conocimiento de las entidades de proceso software.

2. Definir los elementos necesarios del marco de trabajo de gestión del conocimiento en procesos de software.

3. Analizar cómo los activos intangibles son representados, implementados, administrados y disponibles dentro de la base de conocimiento de una organización.

4. Validar, por medio de un caso práctico, una de las partes del marco de trabajo definido.

METODOLOGÍA DE INVESTIGACIÓN

Este trabajo se justifica ampliamente por la relevancia y pertinencia de la necesidad de encontrar relaciones transdisciplinarias entre las ciencias cognitivas y las ciencias de la computación, en beneficio de las organizaciones desarrolladoras de software. Se demanda la disciplina de gestión de conocimiento para generar propuestas para mejorar las prácticas de SPI, que se adapten a las características de las mipymes.

La metodología se basa en la transdisciplinariedad, como la unidad de la ciencia para la correlación del conocimiento teórico, metodológico o epistemológico. La investigación transdisciplinaria implica ver un problema en un nivel descriptivo, normativo e interactivo, en el que se favorece la generación de conocimiento sobre procesos y estrategias para mejorar prácticas sociales o de relevancia en aspectos socio-técnicos.

Este libro refiere 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 estándares o modelos de referencia de procesos, como la NMX-I-059.

Se presenta un modelo circular de investigación transdisciplinaria con la combinación de la metodología KoFI (por su acrónimo en inglés de Knowledge Flow Identification). KoFI define los lineamientos para la identificación y análisis de flujos de conocimiento en los procesos organizacionales, y su aplicación también es un proceso iterativo e incremental que puede retroalimentar de una fase a cualquier otra del modelo propuesto (figura 1).

A continuación, se describen cada una de las etapas del modelo de la figura 1, las cuales corresponden a la forma en la que se realizó el trabajo. El cumplimiento de cada objetivo específico, así como los resultados y conclusiones que se fueron depurando debido al flujo circular de la metodología.

Como primera actividad, se partió de una investigación documental y exploratoria (Hernández Sampieri et al., 2008). Por la actualidad del tema de SPI, la investigación documental se orientó a la búsqueda y análisis de artículos y reportes publicados en revistas especializadas, bibliotecas digitales y normas internacionales. Por otro lado, la investigación de tipo exploratoria se llevó a cabo con la asistencia a congresos nacionales e internacionales, cursos, estancias de investigación y seminarios especializados en los temas a tratar.

La información fue complementada con la asistencia a dos cursos de actualización disciplinaria, adicionales a los acreditados en el programa de maestría y doctorado en ciencias e ingeniería de la Universidad Autónoma de Baja California. El primero se realizó bajo el nombre de Introduction to the Capability Maturity Model Integration Version 1.2, el cual fue ofertado por el Instituto de Ingeniería de Software de la Universidad Carnegie Mellon. El segundo curso consistió en un taller titulado Project Management Workshop, el cual abordó temas relacionados con las mejores prácticas y lecciones aprendidas recopiladas por el Project Management Institute. Los conocimientos adquiridos en este último curso fueron puestos en práctica para realizar un análisis comparativo de la norma ISO/IEC 10006, con los estándares relacionados a la mejora de procesos de software (Flores Ríos et al., 2009).

Desde el inicio del proyecto se utilizó la metodología KoFI como apoyo a la creación de un mapa de conocimiento para la investigación transdisciplinaria, obteniendo en las siguientes iteraciones, la identificación y análisis de flujos de conocimiento relevantes en el marco conceptual de gestión de conocimiento en procesos software. Las fases que se siguieron en la metodología KoFI fueron: 1) la especificación del proceso a analizar; 2) el modelado del proceso con un enfoque en flujos de conocimiento; 3) la identificación de fuentes y tipos de conocimiento; y 4) la identificación de la forma en la que el conocimiento fluye dentro del grupo de trabajo detectando problemas que puedan estar afectando dicho flujo (Rodríguez Elías & Martínez García, 2011).

La metodología KoFI permitió identificar el conocimiento que es aplicado o requerido durante la realización de los procesos de conocimiento o toma de decisiones, las fuentes donde el conocimiento es almacenado u obtenido, así como los mecanismos utilizados para localizar las fuentes y transferir conocimiento.

En 2010 se realizó una estancia en el grupo IDIS (Investigación y Desarrollo de Ingeniería de Software) de la Universidad del Cauca, Colombia, para analizar los flujos de generación y transferencia de conocimiento en las entidades de proceso software. Dichas entidades se definen por el conjunto de actividades que son realizadas para lograr el propósito de un proceso.[3] El modelado y análisis obtenido fue sometido a registro como modelo de utilidad, ante el Instituto Nacional de Derecho de Autor (Flores Ríos et al., 2013).

Por otro lado, se efectuaron diversas visitas a las tres mipymes verificadas oficialmente en el estado, y se realizaron dos estancias de investigación en el año 2009 y 2013, en una empresa que empezó su implantación de proyecto de SPI.

En el estado de Baja California existen siete organizaciones con nivel uno y dos de madurez, siendo una de las entidades con más bajo nivel de verificaciones oficiales. El objetivo de las entrevistas semiestructuradas fue para conocer el contexto empresarial local y su experiencia en proyectos de SPI, considerando los atributos de procesos de nivel de capacidad uno y dos (Gastélum Ramírez & Flores Ríos, 2010; Olguín Espinoza et al., 2012).

Con el objetivo de analizar la propuesta de interpretar las fuentes y tipos de conocimiento en un proyecto de SPI, se llevó a la práctica, por medio del análisis, dos casos ejemplo.

La primera empresa (mipyme A), obtuvo en 2008 su primera verificación por parte de NYCE (Flores Ríos et al., 2008). Durante el cierre de su proyecto de SPI, se detectó la necesidad de incrementar el conocimiento procedural y tópico de los responsables de procesos, para la interpretación de cada uno de los atributos de las metodologías y los indicadores requeridos por el nivel dos de capacidad. En 2009, la mipyme A estableció un nuevo convenio con la Universidad Autónoma de Baja California, para crear un proyecto de SPI orientado a obtener el nivel dos de madurez y alineado a la par con su planeación estratégica. En 2010, obtuvo el cumplimiento de los nueve procesos y elementos requeridos de conformidad con la NMX-I-059/02 para adquirir el nivel dos. La contribución práctica de este caso de estudio, permitió identificar los tipos de conocimiento que se adquirieron y verificar, empíricamente, si el conjunto de actividades de control y mejora de procesos dependieron de evaluar objetivamente la capacidad de procesos definida en la NMX-I-15504 y así determinar, bajo un enfoque de gestión de conocimiento, la madurez organizacional de la empresa, según los requisitos para el nivel dos de capacidad, establecidos por la NMX-I-059. Asimismo, se analizó cómo los tipos de conocimientos podrían estar asociados implícitamente con los niveles de capacidad de procesos, ayudando a distinguir y definir un modelo bidimensional recomendado en la implantación de proyectos de SPI, con base en gestión del conocimiento.

Por otro lado, la segunda empresa (Mipyme B) es una microempresa con cinco años de antigüedad, el nivel de estudios de sus recursos humanos es de licenciatura y posgrado, dedicándose al desarrollo de sistemas de software a la medida y análisis de procesos. Desde 2009, la Mipyme B ha ajustado sus procesos bajo la norma NMX-I-059 con la finalidad de elevar la capacidad de sus procesos, considerando que en el futuro pueda ser verificada oficialmente. Uno de los escenarios que se analizaron fue la presencia de los procesos de exteriorización y combinación con la implementación de un proyecto de mediana complejidad, haciendo uso de un sistema de soporte (Olguín Espinoza et al., 2012).

En un nuevo ciclo de la metodología, se ocupó de la definición de los elementos del marco de trabajo propuestos como parte de un proyecto de SPI, con base en el conocimiento; las características sobresalientes de cada uno de ellos se expondrán más adelante, en los capítulos II y III.

ESTRUCTURA

El resto de libro está organizado de la siguiente manera:

El capítulo I está enfocado a las áreas de gestión de conocimiento y mejora de procesos de software y un acercamiento a la transdisciplinariedad entre ambas.

En el capítulo II se presentan los resultados de la aplicación de la metodología KoFI, para cada una de sus fases. En este capítulo se exponen los modelos bajo la extensión del metamodelo para procesos de ingeniería de software (SPEM-KF), los cuales permiten analizar la transferencia y creación de conocimiento en las entidades procesos de software, para contar con dos enfoques de flujos de conocimiento.

El capítulo III aborda el enfoque del ciclo de vida de la gestión del conocimiento, para considerar los procesos de conocimiento del marco declarativo propuesto. El marco se apoya de los elementos definidos por el estándar ISO/IEC 24774 y de las entidades proceso software, presentadas en el capítulo I.

Las conclusiones generales sobre el impacto de la transdisciplinariedad, detectado en este trabajo junto a las actividades sugeridas a realizar para dar continuidad a la investigación, se exponen en el capítulo IV.

1 La IEEE en el estándar 610-1990, define a la ingeniería de software como la aplicación de un método sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento de software.

2 La tecnología de la información se refiere al uso de las computadoras y su software para convertir, almacenar, proteger, transmitir y recuperar la información.

3 El resultado de la colaboración se encuentra en el capítulo II, en el apartado “Análisis de flujos de conocimiento del modelo SECI con entidades proceso software”.

CAPÍTULO I. MARCO TEÓRICO

En la introducción se expuso la importancia de determinar cuáles procesos o estrategias de gestión del conocimiento pueden apoyar a las organizaciones de desarrollo de software a promover la mejora continua de sus actividades, enfatizando la generación y reutilización del conocimiento dentro de un proyecto de mejora de procesos de software (SPI, por sus siglas en inglés). Por tal motivo, este capítulo presenta conceptos, enfoques, taxonomías y modelos que definen cómo el conocimiento fluye y/o se crea en las organizaciones. Posteriormente, se exponen las características sobre el área de mejoras de proceso, y el trabajo relacionado a la transdisciplinariedad entre la gestión de conocimiento y la SPI.

EL CONOCIMIENTO

Para gestionar el conocimiento, primero es necesario especificar qué se entiende como tal y cómo puede clasificarse. Existen una amplia variedad de definiciones del término conocimiento (Hejduk, 2005), algunas de ellas son derivadas desde el contenido o estructura del conocimiento mismo, y otras desde su representación (Robillard, 1999) o de acuerdo al contexto donde se utilizan (Syazwan-Abdullah et al., 2006). A continuación, se presentan sus definiciones desde cuatro enfoques:

1. Davenport & Prusak (2000) señalan que el conocimiento es una mezcla fluida de experiencias estructuradas, valores, información contextual e internalización experta que provee un marco para evaluar e incorporar nuevas experiencias e información. Esto se origina y aplica en la mente de quienes lo poseen.
El conocimiento se puede entender como el proceso de comunicación determinado por la teoría de comunicación en torno al sujeto (persona), objeto, medio y el mensaje. Esta teoría específica que al momento de que el sujeto recibe el mensaje propio del objeto, a través de un medio, en algún código, éste es filtrado por sus capacidades cognitivas y los modelos de conocimiento (Pavez Salazar, 2000).

2. Visión desde el proceso. El conocimiento se presenta en torno al proceso de valor agregado (Fleming, 2008), asociado al nivel de independencia del contexto y el nivel de entendimiento de los elementos de la cadena informacional. Niel Fleming (2008) representa a los datos como el nivel más bajo, seguido por la información (representando el ¿cuál?, el ¿quién?, el ¿cuándo? y ¿dónde?), el conocimiento (significa el ¿cómo?) y la sabiduría (el ¿por qué?) (Pavez Salazar, 2000; Bellinger, 2004).

3. Desde una visión organizacional, el conocimiento es un flujo en el que se mezclan las experiencias, valores importantes, información contextual y puntos de vista de expertos, que facilitan un marco de análisis para evaluar e incorporar nuevas experiencias e información. El conocimiento que es o puede ser valioso para una organización, por lo general, está integrado no sólo en documentos o repositorios, sino también en rutinas, procesos, prácticas o normas. De esta forma, el conocimiento se encuentra en libros, sistemas de archivos, bases de datos, bases de conocimiento, sistemas de información e incluso, en la mente de las personas (Holz, 2003). Autores como Alavi & Leidner (2001) consideran que el conocimiento tiene poco valor sino se comparte o fluye; debido a que éste es fundamental para que una organización sea capaz de crear y mantener ventajas competitivas.

El grupo de enfoques presentado, se caracteriza por definir cómo es posible obtener información y conocimiento a partir de un contexto individual y organizacional; lo siguiente será conocer cuáles son los principales tipos de conocimiento.

TAXONOMÍAS

Una taxonomía o dominio se refiere a representar un conjunto de conocimientos en forma jerárquica con referencias cruzadas entre conceptos. Esto significa que los distintos tipos de conocimiento presentan características taxonómicas relacionadas unas con otras. Rao (2005) especifica que las taxonomías son una técnica ampliamente usada debido a que facilitan la organización y descripción del conocimiento.

El cuadro 1 presenta algunas taxonomías de tipos de conocimientos que se han propuesto por diversos autores (Robillard, 1999; Nonaka & Takeuchi, 1995). Las apreciaciones para cada tipo son derivadas desde el contenido o estructura de los mismos y, otras, desde su representación (Robillard, 1999). La utilidad de diferenciar y especificar los diferentes tipos de conocimiento radica en comparar las ventajas que se derivan de cada uno de ellos (Segarra Ciprés, 2009) y entender cómo se relacionan unos con otros (Shadbolt & Milton, 1999). De esta forma, las combinaciones de características taxonómicas otorgan al conocimiento un recurso estratégico de ventaja competitiva en el desarrollo de capacidades de gestión para las organizaciones.

El conocimiento teórico o declarativo es estático, con base en hechos (eventos), propiedades de las personas, objetos y sus relaciones entre ellos. Su análisis fue considerado por G. Ryle (1945) como una aplicación que hizo entre el conocer qué y el conocer cómo. El conocer qué o conocimiento teórico, involucra el conocimiento conscientemente accesible que puede ser articulado. Este conocimiento es caracterizado por la habilidad de una persona en aprender a través de instrucción explícita, el recitado de las reglas y la atención a sus movimientos. También se relaciona con el conocimiento tópico o semántico, el cual se refiere al significado de las palabras, como las definiciones en el diccionario o libros de texto (Robillard, 1999).

El conocimiento corporizado surgió como una oposición al conocimiento teórico, el cual sostiene que cuando una persona adquiere una habilidad se adquiere una comprensión correspondiente, que provoca la articulación (González, 2004). Esto significa que las actividades son aprendidas a través de la experiencia y las habilidades de una persona (conocimiento episódico), una vez que los conocimientos tópico y técnico son adquiridos (Robillard, 1999).

En 1966, Michael Polanyi (1966) argumentó que los seres humanos adquieren conocimiento creando y organizando activamente sus propias experiencias. Dicho autor justificó que para crear conocimiento era necesaria la interacción continua del conocimiento explícito y el conocimiento tácito, siendo el pionero en tal categorización. La distinción entre el conocimiento explícito y el conocimiento tácito fue retomada en la primera publicación de Nonaka, en 1991, quien formuló la teoría del aprendizaje organizacional, centrándola en la conversión entre ambos tipos de conocimientos (Nonaka, 1991).

El conocimiento explícito se refiere a aquel conocimiento que puede ser articulado, codificado y comunicado de forma simbólica y/o con un lenguaje natural. Nonaka & Konno (1998) establecen que el conocimiento explícito puede ser expresado, por lo general, en palabras y números, y compartido en forma de datos, fórmulas científicas, procedimientos codificados o principios universales (Nonaka & Takeuchi, 1999). El conocimiento explícito puede ser encontrado en los archivos y fólderes de una organización, bases de datos, documentos, artículos de investigación, libros, código de software, mensajes de correo electrónico, procedimientos y procesos escritos (Stein, 1995; Vasandani, 1995).

A diferencia del conocimiento explícito, el conocimiento tácito es aquel conocimiento personal que no es fácil de plantear a través del lenguaje formal, por lo que resulta difícil de transmitir y compartir con otros (Nonaka & Konno, 1998). Este tipo de conocimiento tiene sus raíces en las acciones y experiencia individual, así como en los ideales, valores, emociones, intuición, ideas y aspectos subjetivos de cada persona. Sin embargo, el conocimiento tácito puede integrar tanto elementos cognitivos,[4] como aspectos técnicos, es decir: conocimiento declarativo. El componente técnico (o conocimiento procedural) expresa el conocer cómo se lleva a cabo una tarea y las habilidades no formales y difíciles de definir dentro de un contexto específico. Una vez aprendido este conocimiento, no se olvida (Robillard, 1999).

Autores como Ambrosini & Bowman (2001) y Stenmark (2001), hacen énfasis en las implicaciones que se derivan de la naturaleza tácita del conocimiento debido a que: a) por su característica es difícil de imitar, sustituir o transferir, convirtiéndolo en un recurso crítico para la organización; b) la dificultad de explicar en palabras el conocimiento que poseen las personas; c) la capacidad de utilizar el conocimiento tácito sin tener que documentarlo, porque no tiene un beneficio directo a nivel individual; y d) la existencia del riesgo de perder el conocimiento tácito al hacerlo explícito.

A pesar de que las teorías administrativas existentes, hasta finales de la década de 1980, señalaban la importancia del conocimiento para las organizaciones, había pocos estudios acerca de la forma en que se creaba el conocimiento en el interior de las organizaciones y entre ellas (Nonaka & Takeuchi, 1995). Esta situación creó un especial interés en analizar procesos para la adquisición, acumulación, transferencia y utilización del conocimiento existente y la creación de nuevo conocimiento a partir del conocimiento tácito. Se necesitaba entender cómo las organizaciones definían nuevos métodos, procesos o productos, utilizando diferentes tipos de conocimiento y cómo generaban nuevo conocimiento (tácito o explícito) para desempeñar sus actividades. Asimismo, el investigar si la evolución o madurez organizacional se debía a que las organizaciones adoptaban, generaban y transmitían el conocimiento tácito de sus miembros en la realización e institucionalización de sus procesos (Nelson & Winter, 1982).

En el siguiente apartado se presentan los procesos de creación y conversión del conocimiento organizacional, a partir del conocimiento tácito y explícito, y su evolución desde el nivel individual hasta el nivel interorganizacional (Hedlund & Nonaka, 1993).

MECANISMOS DE CREACIÓN DEL CONOCIMIENTO

Desde el punto de vista de Nonaka & Takeuchi (1995), el conocimiento tácito y el conocimiento explícito no son entidades separadas, sino complementarias. Existe una interacción e intercambio entre ellos cuando los individuos realizan actividades creativas. El modelo de creación del conocimiento organizacional[5] se fundamenta en el supuesto de que el conocimiento se crea y expande a través de la interacción social de conocimiento tácito y conocimiento explícito (Polanyi, 1966). A dicha interacción se le conoce como procesos de conversión o creación del conocimiento.

A lo largo de tres décadas, varios autores plantearon diversos mecanismos de creación de conocimiento organizacional, tal como se muestra en el cuadro 2. Para la teoría de la organización, con base en el conocimiento, éste es el recurso con más importancia estratégica (Kogut & Zander, 1992). Los procesos de la dimensión epistemológica (socialización, exteriorización, combinación e interiorización), constituyen el motor de la creación del conocimiento (Nonaka, 1991). También son los mecanismos con los cuales el conocimiento individual es interiorizado tanto en la persona como en la organización (Spender, 1996). Asimismo, esta dimensión apoya la identificación del proceso de cinco fases (ciclos), a través de las cuales se crea el conocimiento en la dimensión ontológica (Nonaka & Takeuchi, 1995).

A nivel general, los análisis de creación del conocimiento se han apoyado —directa o indirectamente— en las dimensiones epistemológica y ontológica. A continuación, se presentan los elementos del contexto en los que se desenvuelven los procesos de creación para ambas dimensiones.

a) Dimensión epistemológica

La dimensión epistemológica define cuatro mecanismos o procesos del modelo de creación de conocimiento organizacional, derivados de la interacción entre el conocimiento tácito y el conocimiento explícito, y viceversa (figura 2). Dicho modelo también es conocido como espiral del conocimiento o modelo SECI, por las siglas de los procesos de: Socialización, Exteriorización, Combinación e Interiorización.

El objetivo del modelo SECI es brindar un entendimiento de cómo las organizaciones crean el conocimiento para que ellas maximicen la administración, aplicación y transferencia del mismo, a través de diversos patrones de creación y expansión (Flores Ríos & Rodríguez Elías, 2009). En el cuadro 3 se presentan las principales características de cada uno de los procesos del modelo SECI, junto con su descripción. Específicamente, la segunda columna de dicho cuadro presenta el mecanismo de conversión utilizado y el tipo de conocimiento generado por cada proceso del modelo SECI. En el proceso de socialización se producen los conocimientos armonizados, como modelos mentales y habilidades técnicas compartidas; la exteriorización genera conocimiento conceptual; la combinación de ambos origina conocimiento sistémico y la interiorización crea conocimiento operacional acerca de la administración de proyectos, el uso de nuevos recursos y la implantación de políticas (Nonaka & Takeuchi, 1995).

El cuadro 3 también especifica las actividades que pueden apoyar cada uno de los procesos y el tipo de tecnología recomendada por Marwick (2001). Este autor presentó el modelo SECI como un marco de trabajo para ejemplificar el rol e impacto de la tecnología de la información en la creación y transferencia del conocimiento organizacional, por medio de los cuatro procesos mostrados en la figura 2; esto se justifica debido a que una estrategia efectiva de la gestión de conocimiento requiere de una integración apropiada de iniciativas organizacionales, sociales y de tecnología para ayudar a las organizaciones actuales en la resolución de problemas. Por ejemplo, para ser más efectiva la exteriorización se pueden aplicar técnicas como diálogos entre los miembros del equipo, respuestas a preguntas o narración apoyados de tecnología de newsgroups, flujo de trabajo o sistemas colaborativos. Cuando las personas se dirigen a repositorios para consultar sus demandas de conocimiento sobre alguna documentación o productos de trabajo disponibles electrónicamente, se presenta la conversión de un conocimiento explícito a otro explícito. La captura de este tipo de conocimiento de una manera persistente puede ser por medio de un reporte, correo electrónico o portales web (Flores Ríos & Rodríguez Elías, 2009). Es importante cuidar, además de la recuperación de la información, el entendimiento, el uso y la no sobresaturación de la misma. Por otro lado, la generación del conocimiento organizacional se establece mediante el apoyo que la organización otorga a las fuentes de conocimiento, tales como individuos, grupos, equipos, áreas y departamentos, entre otros. Esto significa que la creación del conocimiento, representado por el modelo SECI, es un proceso en espiral que se inicia en un nivel individual hasta lo interorganizacional, conocido como dimensión ontológica. Enseguida, se presenta cómo la escala de interacción del conocimiento tácito y explícito se incrementa conforme avanza por los niveles ontológicos.

b) Dimensión ontológica

A diferencia de la dimensión epistemológica que se centra en la transferencia de conocimiento tácito y explícito. Esta dimensión se centra en los niveles de las entidades creadoras de conocimiento individual, grupal, organizacional e interorganizacional (figura 3). En una primera fase, el conocimiento es creado de manera individual, debido a que las organizaciones apoyan a los individuos creativos o proveen los contextos que se necesitan para que se cree conocimiento tácito. Esto significa que son los individuos los que poseen el conocimiento para articularlo y transmitirlo, como parte de la red de conocimiento de la organización (Nonaka & Takeuchi, 1999). Esta agregación de unidades organizacionales también podría apoyarse en pequeños equipos, grupos de trabajo, departamentos y hasta alianzas de negocios o redes (Pérez Soltero, 2007).

La figura 3 muestra las dimensiones epistemológica y ontológica en las que se presenta la creación del conocimiento, donde la escala de interacción del conocimiento tácito y explícito se incrementa conforme avanza por los niveles ontológicos (Nonaka & Takeuchi, 1995). De esta forma, la creación del conocimiento organizacional es un proceso que inicia en el nivel individual y se mueve hacia delante, pasando por comunidades de interacción cada vez mayores. La socialización se inicia generalmente con la creación de un campo de interacción, el cual permite que los miembros compartan sus experiencias y modelos mentales. La exteriorización comienza a partir de una reflexión colectiva de significados, el conocimiento conceptual se crea cuando los miembros expresan el conocimiento tácito que resultaba difícil de comunicar. La combinación da comienzo con la distribución por redes de conocimiento y el conocimiento existente de otras secciones de la organización, representada por nuevos productos o servicios. Por último, el conocimiento operacional se origina en aprender haciendo.

El rol de la organización en el proceso de creación de conocimiento es el de proveer el contexto apropiado para facilitar las actividades grupales y la creación y acumulación de conocimiento desde el nivel individual. Es así como una organización que aprende es una organización experta en crear, adquirir y transmitir conocimiento (Garvin, 2000).

Las diversas taxonomías y modelos presentados en este apartado permitieron exponer cómo un determinado tipo de conocimiento tiene un mayor o menor grado de complejidad, de especificidad, de dependencia o independencia, de carácter tácito o explícito y/o de individual u organizacional. Robillard (1999) concibe al conocimiento como un concepto multidimensional, siendo las dimensiones comunes a todos los tipos de conocimiento. Por todo lo anterior, consideramos que el conocimiento —en sus diversas taxonomías—, contenido en las organizaciones de desarrollo de software, es un elemento estratégico que les permitirá ser generadoras de nuevo conocimiento o desarrolladoras de proyectos de conocimiento para mejorar la capacidad de sus procesos software.

GESTIÓN DEL CONOCIMIENTO

Cuando el conocimiento se administra a través de un período de tiempo —que tiene que ver tanto con las relaciones humanas como con las prácticas de negocios y la tecnología de la información— se dice que se presenta la gestión del conocimiento (Benjamins et al., 1998). Karl Wiig fue el primero en utilizar el concepto de gestión del conocimiento, en 1986. Posteriormente, Nonaka & Takeuchi (1991) publicaron su primer artículo sobre este tema en la Harvard Business Review, atrayendo más discusión sobre esta tesis.

Algunos autores especifican que la gestión del conocimiento no es un término con una definición generalizada (Firestone, 2001), puesto que, como proceso, se identifica con los proyectos en los cuales se aplica. Sin embargo, algunas definiciones que se pueden encontrar son:

Es el proceso sistemático de buscar, organizar, filtrar y presentar la información con el objetivo de mejorar la comprensión de las personas en un área específica de interés. (Davenport & Prusak, 2001).

Es el proceso sistémico y específico de una organización, cuya finalidad es adquirir, organizar y comunicar tanto el conocimiento tácito como el conocimiento explícito, para que otros puedan hacer uso de éste y así ser más productivos en su trabajo. (Alavi & Leidner, 2001).

Es la colección de metodologías y estrategias para la reingeniería de procesos organizacionales para fomentar el flujo del conocimiento entre una organización y las personas. (Kolp, 2002).

Es una red dirigida, persistente y multipropósito de interacciones entre agentes humanos, a través de la cual, éstos administran, dirigen, gobiernan, controlan, coordinan, planean, organizan a otros agentes, componentes y actividades en el proceso de conocimiento básico, con el objetivo de planear, dirigir, unificar, mantener, mejorar, adquirir y transmitir la base de conocimiento de una organización. (Firestone, 2001).

Un elemento común en las definiciones de la gestión del conocimiento se centra en facilitar y gestionar las actividades relacionadas a su creación, captura, transformación y uso (Ordoñez et al., 2007; Martí, 2006). Su función, por lo tanto, consiste en capturar, organizar, actualizar y compartir el conocimiento creado y, posteriormente, ser utilizado por el recurso humano (Capote et al., 2008) con el fin de realizar de mejor manera el trabajo necesario para completar procesos específicos dentro de la organización (Rodríguez Elías, 2007).

Desde el punto de vista del proceso de socialización, el objetivo es compartir el conocimiento tácito. Sin embargo, este proceso, por sí mismo, es una forma limitada de creación de conocimiento. La dificultad para compartir conocimiento tácito contribuye al inconveniente de imitar capacidades que podrían proveer ventaja competitiva a una organización (Wan et al., 2011). Por tal motivo, aparte del modelo SECI, existen otras teorías que sustentan a la gestión de conocimiento, tales como la teoría de la pirámide informacional y la teoría de recursos y capacidades (Carrión & Ortiz de Urbina, 2012).

La teoría de la pirámide informacional observa el conocimiento entorno al proceso de valor agregado, asociado a elementos de una cadena informacional: datos, información y conocimiento Rodríguez Elías (2007). Lo llama modelo D-I-C por las iniciales de cada uno de esos elementos. Alavi & Leidner (2001) definen a los datos como números crudos y hechos. La información es un conjunto de datos procesados y se transforma en conocimiento una vez procesada en la mente del individuo y luego, nuevamente, en información, una vez articulado o comunicado a otras personas mediante textos, formatos electrónicos, comunicaciones orales (conocimiento tácito) o escritas (conocimiento explícito). El objetivo es informar a quien los recibe, para tener un efecto de juicio (Davenport & Prusak, 2000). El conocimiento se refiere a la información con valor agregado (Davenport & Prusak, 1997) que el individuo posee en su mente, personalizada y subjetiva, relacionada con hechos, procedimientos, conceptos, interpretaciones, ideas, observaciones, juicios y elementos que pueden ser o no útiles, precisos o estructurales.

La teoría de recursos y capacidades se define como el apoyo en el proceso de un análisis estratégico, el cual se forma por tres partes: misión y objetivos, análisis externo y análisis interno. El análisis de recursos y capacidades busca identificar el potencial de estos elementos que posee la organización a los que puede acceder y se enmarca dentro del análisis estratégico interno (Mintzberg, 1993). Por lo tanto, esta teoría es una herramienta que permite determinar gestionar, mejorar y medir las fortalezas y debilidades internas de la organización.

Según esta teoría, el desarrollo de capacidades distintas es la única forma de conseguir ventajas competitivas sostenibles. Es importante señalar que los recursos son intangibles y las capacidades suelen estar basadas en la información y el conocimiento.

El conocimiento puede verse como un recurso o activo intangible que brinda la capacidad de usar información y aplicarla en la solución de un problema, realizando una toma de decisión o actividades (Carlsson, 2002) propias de la organización (Itami, 1987, citado en Nonaka & Takeuchi, 1995). El conocimiento es visto como una capacidad (Alavi & Leidner, 2001) cuando se ofrece una explicación sobre la naturaleza y estructura de las capacidades organizacionales. Esto sucede cuando los individuos combinan su conocimiento tácito para crear una capacidad organizacional (Lloria, 2000). Aaker (1989) determinó que las organizaciones poseen activos, habilidades y capacidades. Se entiende como activo a algo, una marca o un punto de comercialización, que es mejor que la competencia; mientras que una habilidad es algo que el personal de una organización hace mejor que sus competidores.

El modelo de creación del conocimiento se asocia a el enfoque con base en recursos, debido a que se centra en: 1) cómo las organizaciones han adquirido ventajas competitivas; 2) las habilidades de la organización más que en las individuales; 3) el rol de la alta dirección como participante fundamental; y 4) cómo se propicia la innovación y lo que sucede dentro de la organización (Nonaka & Takeuchi, 1999).

Por otro lado, el enfoque de perspectivas de conocimiento definido por Alavi & Leidner (2001) también se asocia al modelo SECI y a la teoría de pirámide informacional. Las diferentes vistas del conocimiento propuestos por los autores, permiten liderar diferentes percepciones de la gestión de conocimiento. Si el conocimiento es visto como un objeto, o es comparado con el acceso a la información, entonces la gestión de conocimiento debería enfocarse en la construcción y administración de stocks de conocimiento. Por otro lado, si el conocimiento es un proceso, entonces implica que la gestión del conocimiento se centre en el flujo del conocimiento y en los procesos de creación, intercambio y distribución del conocimiento. La percepción del conocimiento como una capacidad sugiere una perspectiva de gestión del conocimiento centrada en las competencias básicas, entendimiento de la ventaja estratégica, del saber-cómo (teoría de recursos y capacidades) y la creación del capital intelectual (Alavi & Leidner, 2001).

La figura 4 muestra el flujo de los procesos del modelo SECI en la relación al modelo D-I-C. En el nivel más bajo del flujo unidireccional, representado con líneas punteadas, se encuentran los datos debido a que por sí solos carecen de significado. Las colecciones de datos representan información de acuerdo a la medida de asociación o relaciones existentes entre ellos, para generar discernimiento. El conocimiento comprende estrategias, prácticas, métodos o enfoques. Y una vez validado y orientado hacia un objetivo, genera inteligencia o sabiduría (Bellinger, 2004). Alavi & Leidner (2001) especifican que un individuo puede comunicar su conocimiento tácito para procesar, utilizar e interiorizar la información, por lo que vuelve a transformar dicho conocimiento (socialización). Mientras más alto sea el nivel de conocimiento tácito que posea un individuo se infiere que éste posee una combinación más amplia de visión, principios, información, contexto y experiencia.

En la misma figura se observa una jerarquía con flujo inverso. El conocimiento puede tener una transición regresiva a la información y de ésta a los datos. De ahí la importancia de distinguir a cada uno en sus respectivas categorías (Hernández Silva & Martí Lahera, 2006). Tuomi (1999) argumenta que los datos existen como una solución a un problema práctico, donde el conocimiento se descontextualiza y estructura de acuerdo a una semántica. El proceso de exteriorización, entonces, involucra la formalización del conocimiento al convertirlo en información y datos para su almacenamiento y manejo como productos o cosas. Este conocimiento explícito permite crear el proceso de combinación y es visto bajo la perspectiva de un objeto.

Hasta este punto se han presentado descripciones generales de la gestión del conocimiento, los tipos de conocimiento y las dimensiones para explicar cómo éste fluye dentro de las organizaciones. Es importante señalar que si bien la implantación de la gestión del conocimiento como un proceso transversal de apoyo a una organización que busca altos niveles de madurez (Anaya et al., 2007) es un camino que ya emprendieron algunas empresas, el reto de las investigaciones actuales es analizar cuál conocimiento y sus mecanismos (métodos, técnicas y herramientas), pueden ser capturados, creados, identificados, representados, recuperados y compartidos, de manera que sirvan de apoyo a las organizaciones que aún no han adquirido la cultura de calidad (Capote et al., 2008), mejora de procesos e innovación. Recientemente, algunas empresas de desarrollo de software, particularmente micro, pequeñas y medianas (mipymes), han hecho esfuerzos por aprovechar los beneficios de la gestión del conocimiento en sus actividades, con el fin de reducir los tiempos y costos de sus procesos, a la par de aumentar la calidad de sus productos (Rodríguez Elías, 2003).

GESTIÓN DEL CONOCIMIENTO EN MICRO, PEQUEÑAS Y MEDIANAS ORGANIZACIONES

Investigaciones de la gestión del conocimiento se han centrado en los procesos y estructuras de las organizaciones, particularmente, en la transferencia de conocimiento tácito y explícito, la cultura organizacional, el aprendizaje y las tecnologías para almacenar e intercambiar conocimiento para mejorar la productividad y ventas, reducir costos e incrementar la calidad e innovación (Klugeet al., 2001; Quintas, 2002; O’Dell et al., 2003; Edvardsson, 2009; Jashapara, 2011 citado por Durst & Runar, 2012).

Las mipymes poseen características particulares debido a algunos factores como (Mas y Amengual, 2005):

1. Proyectos. El número de proyectos que suelen manejar de manera simultánea, suele ser pequeño. Si tienen problemas con alguno de ellos, representan un porcentaje muy alto de re-trabajo o de inversión de recursos.

2. Recursos humanos. Se conforman de pequeños grupos y equipos de desarrollo. Simultáneamente, los empleados pertenecen a diferentes grupos o equipos de dirección, de gestión o de desarrollo, entre otros. La misma persona tiene que estar capacitada para llevar a cabo diversas actividades. No disponen de especialistas en temas concretos y necesitan de asesores o personal capacitado para la realización de actividades.

3. Recursos económicos. Los costos derivados de las asesorías o auditorías externas que se realizan con varios consultores o auditores, suelen ser económicamente inviables para estas empresas. Además, una mipyme dedica pocos recursos y esfuerzo a programas de innovación y desarrollo (I+D) debido a que requieren inversión de dinero, tiempo, recursos y el retorno de inversión se produce a muy largo plazo (Garzás et al., 2009).

La falta de experiencia y de recursos financieros, frecuentemente, origina que el conocimiento tácito se mantenga en la mente de las personas y/o de algunos miembros clave que tienen experiencia en proyectos previos, en lugar de que el conocimiento esté físicamente almacenado o compartido a través de ciertos sistemas o herramientas de gestión del conocimiento. Así, el proceso de transferencia de conocimiento tácito sólo puede ocurrir en los pasillos de las mipymes (Wong & Aspinwall, 2004) o en conversaciones informales como las fiestas o celebraciones (Durst & Wihelm, 2012). De esta forma, las actividades, procesos y estrategias relacionadas a la gestión del conocimiento, tales como el intercambio y conversión de los aprendizajes, les requiere a las mipymes de tiempo y un cierto nivel de confianza (Durst & Runar, 2012). Los problemas de pérdida y desaprovechamiento de las experiencias adquiridas también pueden ser por el desconocimiento de la existencia de las fuentes de conocimiento y, en algunos casos, de la rotación de su recurso humano dentro de la misma empresa o que estos se muevan a otras (Rodríguez Elías, 2003).

Esta investigación, se centra, al igual que otros autores (Wiig, 1997; McAdam & Reid, 2001; Wong & Aspinwall, 2004; citados por Durst & Runar, 2012) en identificar y analizar cómo los diversos enfoques de flujo de conocimiento (entre ellos el modelo SECI) tienen un profundo impacto en la madurez de las mipymes. Particularmente, estamos interesados en analizar cómo se relaciona la capacidad de los procesos de software con los procesos relacionados con la identificación, creación, almacenamiento, difusión, aplicación e innovación del conocimiento, para hacer frente a los retos empresariales, nacionales e internacionales.

GESTIÓN DEL CONOCIMIENTO EN INGENIERÍA DE SOFTWARE

En el estándar 610-1990 del Instituto de Ingeniería Eléctrica y Electrónica (IEEE), se define a la ingeniería de software como la aplicación de un método sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento de software. Se considera que el éxito de un proyecto de software se visualiza bajo dos dimensiones: la del cliente, medida a través de la relación del producto final a los requisitos funcionales y no funcionales, junto con el valor adquisitivo para el negocio (costo/beneficio); y la del desarrollador, medida a través de la satisfacción del cliente y la productividad del desarrollo (Pfleeger, 2001). Esta última dimensión apoya la iniciativa de que la ingeniería de software es un proceso altamente basado en conocimientos, cuyos principales productos y recursos están representados en capital intelectual (Capote et al., 2008). De ahí el interés de las organizaciones de desarrollo de software por proveer métodos que ayuden a una buena gestión del conocimiento (Aurum et al., 2003), para elevar su madurez.

Dentro de la organización de desarrollo de software, el conocimiento es representado por los activos intangibles, los cuales se refieren al capital humano, capital estructural y capital cliente. Dichos activos generan un perfil de competitividad para la organización (Gil Montelongo et al., 2009). En diversos trabajos se ha detectado una caracterización de los activos de conocimiento al referirse a las lecciones aprendidas, buenas y mejores prácticas, reglas heurísticas y la generación continua de ideas o experiencias que agregan innovación a los procesos de la organización (Anaya et al., 2007). Los activos de conocimiento son interiorizados por los roles participantes y utilizados para reducir los costos y defectos mejorando la calidad de los productos (Dingsøyr & Conradi, 2002). Se ha documentado que la reutilización de activos de conocimiento es una técnica eficiente para transmitir conocimiento entre un equipo de desarrollo de software (Flores Ríos & Rodríguez Elías, 2009).

Existen diversos trabajos centrados en la relación de la gestión del conocimiento en procesos de desarrollo de software, la mayoría de los cuales se enfocan la reutilización de activos de conocimiento, con el objetivo de mejorar la calidad de los productos actuales o nuevos, las fases de ciclo de vida del software o facilitar la reutilización de conocimiento explícito representado por artefactos o documentos de software (Althoff et al., 2002; Dingsøyr & Conradi, 2002). Sin embargo, algunos problemas, como la falta de documentación, representan también un problema en la transferencia de conocimiento entre los diversos roles participantes. Esto hace evidente la necesidad de establecer mecanismos que les permitan disminuir la pérdida y desaprovechamiento de todo aquel conocimiento que pueda ser útil para el desarrollo de sus actividades.

Otro aspecto detectado se ha relacionado con la adquisición y/o adopción de normas o modelos nacionales o internacionales, así como la consulta de fuentes de información específicas (conocimiento tópico) para el desarrollo de software y mejora de procesos, no es una práctica común en las micro y pequeñas organizaciones. Según Niazi et al. (2005) el problema no es la falta de documentación específica o explícita de estándares o modelos de referencia, sino la falta de una estrategia para implementarlos dentro de las organizaciones. La estrategia debe de estar basada en la gestión del cambio y enfocada, principalmente, en el recurso humano (Bayoda et al., 2010), quienes deben de conocer los activos de conocimiento para alcanzar el nivel de capacidad de procesos deseado o elevarlo hacia niveles superiores, tomando en cuenta todas las fuentes de conocimiento existentes en la organización.

Algunas investigaciones resaltan que el éxito en los proyectos de mejora de procesos depende tanto de la captura del conocimiento tácito como del conocimiento explícito (Nonaka & Krogh, 2009; Anand et al., 2010). Un ejemplo de ello es la vinculación de algunas mipymes y grupos de investigación colombianos para la definición de una propuesta orientada al modelado y a la gestión del conocimiento en las organizaciones orientadas al conocimiento. Esta contribución se basa en modelos de motivación, estructura, procesos, recursos humanos y competencias, junto con una caracterización de activos de conocimiento (González & Joaquí, 2007).

MEJORA DE PROCESOS DE SOFTWARE

Una práctica que a partir de finales de los años noventa ha tomado gran fuerza en la comunidad de ingeniería de software (industria, practicantes e investigadores) es la mejora de procesos de software (SPI). Desde entonces, las organizaciones (grandes, medianas y pequeñas) han demostrado interés en mejorar tanto sus procesos organizacionales como de software. Siguiendo este enfoque, diversas instituciones internacionales relacionadas a estándares de procesos, presentaron y utilizan su propia terminología para referirse al término proceso.

El IEEE define un proceso como una acción a tomar para la realización de una tarea dada (IEEE std-610, 1990).

Por otro lado, ISO 9001 define un proceso como un conjunto de recursos interrelacionados y actividades, los cuales transforman entradas en salidas. Por recursos se refiere al recurso humano, recursos financieros, equipos, técnicas y métodos (Stelzer & Melis, 1999) que son necesarios para realizar las actividades y tareas en función de un objetivo específico (Olson et al., 1989).

El Software Engineering Institute (SEI) presenta a un proceso como un conjunto de actividades, métodos, prácticas y transformaciones, que la gente usa para desarrollar y mantener software, y generar productos de trabajo asociados a planes de proyecto, diseño de documentos, código, pruebas y manuales de usuario (SEI, 1995).

El legado de la reingeniería de procesos ha sido la interpretación de una organización como un conjunto de procesos, donde la asociación de cada uno de ellos involucra información y recursos de conocimiento (Davenport, 1993; Berztiss, 2002). Kolp (2002) relaciona a la gestión del conocimiento con la reingeniería de procesos, al definirla como una colección de metodologías y estrategias con el objetivo de fomentar el flujo del conocimiento entre una organización y su recurso humano. Se podría inferir que las organizaciones exitosas que mejoran sus procesos, al mismo tiempo incrementan y elevan su conocimiento.

DEFINICIÓN

La mejora de procesos se refiere al esfuerzo continuo para conocer acerca del sistema de causas en un proceso y, con este conocimiento, propiciar cambios y mejoras al reducir su variación y complejidad (Moen et al., 1999). Mehner et al. (1998) definen a la mejora de procesos como una colección integrada de procedimientos, herramientas y capacitación, con el propósito de incrementar la calidad del producto o desarrollar la productividad del equipo, reduciendo el tiempo de desarrollo.

En este sentido, la SPI es un esfuerzo planeado, gestionado y controlado que tiene como objetivo incrementar la capacidad de los procesos de desarrollo de software de una organización (Oktaba et al., 2008). Se recomienda que la SPI sea implementada por proyecto (Humphrey, 1989; Herbsleb & Goldernson, 1996). Según Humphrey, los seis principios básicos de la SPI son (Humphrey, 1989):

1. Los cambios significativos deben de empezar desde la alta dirección.

2. Todo el personal debe de estar involucrado.

3. El cambio efectivo requiere de un objetivo y del conocimiento del proceso actual.

4. El cambio es continuo.

5. Los cambios del proceso software no se mantendrán sin un esfuerzo consciente y refuerzos periódicos.

6. La SPI requiere de inversión.

Por otro lado, Aaen et al. (2001) especifican que las mejoras de procesos de software se centran en: 1) la gestión de actividades de mejora; 2) el enfoque para guiar las iniciativas de mejoras; y 3) la perspectiva usada para centrar la atención en los objetivos de las mejoras. Uno de los factores a considerar es la importancia de que la alta dirección asigne a miembros de la organización responsabilidades para planear, ejecutar, controlar y supervisar los recursos necesarios en el proyecto de SPI.

En la última década, las organizaciones han utilizado proyectos de SPI como una estrategia para el aseguramiento de la calidad de sus productos de software, misma que es determinada por la calidad de sus procesos (Guerrero & Etevoric, 2004) utilizados para desarrollarlos y mantenerlos (Oktaba et al., 2008). Por ejemplo, las mipymes aseguran la calidad de sus productos de software a través de la mejora de la capacidad de sus procesos, debido a la imagen que desean proyectar y/o a la necesidad de hacer sus proyectos unidades administrativas eficaces y eficientes (Oktaba et al., 2008). La imagen es un factor importante en los objetivos de negocio donde el interés es mantener el mercado local y tratar de establecer una posición en el mercado global cuando se desea exportar software. Un elemento clave es que la SPI es un proceso evolutivo en el cual las mejoras son implementadas acrecentadamente a través del tiempo, en lugar de hacerlo en algunas transformaciones dramáticas. Las mejoras incrementadas son continuas y acumulativas (Mathiassen et al., 2001) y, algunas veces, tensas. Ahora bien, para llevar a cabo una iniciativa de SPI en una organización es necesario involucrar (figura 5) un modelo para guiar la mejora, un modelo para la evaluación de procesos y un modelo de referencia de procesos a seguir (Pino et al., 2007).

- El modelo para guiar la mejora describe la infraestructura, actividades, ciclo de vida y consideraciones prácticas para guiar el programa de la SPI en la organización. Algunos ejemplos son: PmCompetisoft, Processus (Pino et al., 2007), Mesopyme, Impact.

- El modelo de referencia de procesos describe qué actividades son reconocidas como las mejores prácticas que una organización puede implementar para el desarrollo de software con calidad (Oktaba, 2008). El modelo de referencia es también usado para proveer una base común para diferentes modelos y métodos, asegurando que la evaluación sea realizada en un contexto común (Pino et al., 2006). Algunas propuestas existentes son: Moprosoft (Oktaba, 2006), MR-MPS, Competisoft. Adaptación de estándares como CMM, CMMI, ISO 15504, ISO 9001, ISO 12207.

- El modelo/método de evaluación de procesos específica la evaluación formal para obtener un resultado cuantitativo que caracterice el estado de la capacidad del proceso o la madurez de la organización. Sigue, posteriormente, un marco de trabajo de la medición para la aplicación de los atributos de proceso, los cuales describen las características mesurables de la capacidad del proceso a evaluar. En este sentido, el cumplimiento de los atributos determinará el nivel de capacidad del proceso y el nivel de madurez de la organización será determinado por el resultado de la evaluación de todos los niveles de capacidad de los procsos evaluados. Ejemplos de tales métodos son Evalprosoft (Oktaba, 2006), Rapid, Mares, Spire, Adept, MA-MPS, entre otros.

Autores como Saiedian & Carr, 1997; Hareton & Terence, 2001; Staples et al., 2007 (citados por Garzás et al., 2009) confirman que CMMI e ISO/IEC 15504 están orientados a grandes organizaciones y no abordan explícitamente las necesidades de las mipymes o de los grupos y equipos de desarrollo (Garzás et al., 2009). En este sentido, se han presentado iniciativas nacionales e internacionales, orientadas expresamente a las características de estas organizaciones.[6]

ENTIDADES DE PROCESO SOFTWARE

El estándar de propósito general ISO/IEC 24774:2007 (ingeniería de software y sistemas -administración de ciclo de vida-guía para la descripción de procesos), específica los elementos usados para describir un procedimiento para cualquier modelo de referencia de procesos, incluyendo sus técnicas de implementación y de evaluación. Los elementos que se mencionan son: título, propósito, tareas, actividades y salidas.

Con el cuadro 4 y un modelo que guíe la mejora del proceso, se tendría la guía necesaria para articular todas las actividades relacionadas con un proyecto de SPI. Asimismo, al integrar más elementos (entidades) de forma explícita como recursos y activos de conocimiento, se consideraría el conocimiento que surge desde y hacia todo el recurso humano involucrado en el proyecto de mejora, el cual podría ser almacenado y distribuido facilitando su acceso de forma concisa, verídica y actualizada, en cualquier nivel de capacidad del proceso. En el siguiente apartado se analizan cuáles entidades de procesos software se utilizarían en el proyecto de SPI con base en la gestión del conocimiento.

En la industria del software, un proceso software se refiere al conjunto de herramientas, métodos y prácticas que se usan para producir un producto de software. Autores como Paulk et al. (1995) definen un proceso software como un conjunto de actividades, métodos, prácticas y transformaciones que el recurso humano usa para el desarrollo y mantenimiento de software y los productos asociados, como planes de proyectos, documentos de diseño, código, casos de prueba o manuales de usuario. Una vez que los nuevos o mejorados procesos software son creados, el siguiente paso es su implementación dentro de la organización (Pouya, 2001).

Aun cuando diferentes proyectos requieren procesos con características específicas, es posible establecer un conjunto de activos (entidades) de procesos software que deberán estar presentes en todos los procesos del proyecto de la organización. Este conjunto de activos es llamado proceso software estándar (Falbo & Bertollo, 2009). Dicho modelo puede estar especializado al considerar algunos tipos de software, paradigmas o dominios de aplicación, obteniendo así un proceso software especializado.

Ante el rápido desarrollo y diversidad de estándares de software para diferentes dominios, la comparación de elementos de los modelos de procesos software son cruciales para su entendimiento, análisis y evolución (Podorozhny et al., 2003). Por tal motivo, el cuadro 5 presenta por nomenclatura los principales elementos de estándares y modelos de referencia de procesos para obtener los nombres propuestos de las entidades de proceso software. Aun cuando ISO 9001 no es un estándar orientado a software, se ha seleccionado por ser implementado en algunas organizaciones de desarrollo de software y es utilizado ampliamente por otros modelos de procesos.

Un medio útil para representar los nombres de las entidades de proceso software, obtenidas del cuadro 5, es el modelado de procesos. La versión gráfica de un modelo de procesos es más intuitivo, menos ambiguo y más fácil de verificar que el lenguaje natural (Wen et al., 2011). Este tipo de modelado, además, permite identificar el conocimiento que entra y sale de las actividades de una organización, las fuentes de conocimiento obtenido o almacenado, y para analizar cómo fluye el conocimiento (Rodríguez et al., 2004; Bera et al., 2005) en la identificación de las entidades de procesos software.

La figura 6 presenta una adaptación de las principales entidades de proceso software propuesta por Falbo & Bertollo (2009) y representadas bajo la simbología SPEM (por sus siglas en inglés de Software Process Engineering Metamodel). La base del modelado en SPEM define un conjunto de elementos de trabajo (tales como actividades) que son clasificados como definiciones de trabajo, que a su vez se conocen como producto de trabajo. También define una colaboración entre entidades activas abstractas, llamadas roles del proceso, que realizan las operaciones llamadas actividades, en entidades tangibles y concretas (productos de trabajo). Con base en los elementos de SPEM y la homologación de nomenclatura de elementos del cuadro 5 se obtuvieron las entidades de proceso software que se utilizarán en este trabajo, mismas que se visualizan en la figura 6.

La entidad de actividad es fundamental para cualquier modelo de proceso software. Las actividades pueden presentarse en diversos niveles, desde una tarea elemental hasta fases del proceso de desarrollo. En la figura 5 se observa que por cada actividad del proceso software se deben de definir sus sub-actividades, pre-actividades, procedimientos (métodos, técnicas y plantillas para documentos), artefactos o productos de trabajo de entrada y salida, y recursos requeridos. Un producto de trabajo es una pieza de información que puede ser producida, modificada o usada por el proceso y puede integrar otros productos.

Durante la definición de un proceso software es importante precisar cómo las actividades se llevarán a cabo. Así que se establecen los procedimientos que serán adoptados para el cumplimiento de las actividades. Existen tres categorías de procedimientos: métodos, técnicas y plantillas. Un método es el modo de decir o hacer, con orden, modo de proceder, hábito o costumbre, que cada uno tiene y observa (RAE, 2012). También, el método es un procedimiento sistemático que define un flujo de trabajo de actividades y heurísticas para desempeñar una o más acciones que producen un resultado de valor observable (Falbo & Bertollo, 2009). Por otro lado, la técnica se relaciona con la pericia o habilidad para usar los procedimientos o recursos, o ejecutar cualquier tarea para conseguir algo. Además, la técnica se refiere el conjunto de medios o instrumentos por los cuales se realiza una actividad de modo menos rígido y detallado que un método, en el sentido que no describe a las actividades. Por último, las plantillas para documentos son patrones a seguir en el desarrollo de artefactos, estableciendo un estándar de formato entre los documentos.

Los recursos son agrupados en tres categorías (Falbo & Bertollo, 2009):

1. Recursos humanos. Se refiere a los agentes humanos representando ciertos roles para la realización de una actividad.

2. Recursos de hardware. Incluyen cualquier equipo de hardware requerido para el desempeño de una actividad.

3. Recursos de software. Se relacionan a cualquier producto de software que es usado como complemento de una actividad. En este contexto, las herramientas CASE (Computer Aided Software Engineering) se consideran un subtipo de este tipo de recursos.

Por lo anterior, las entidades del proceso software (cuadro 5) se definen según el conjunto de actividades que serán realizadas para el logro del propósito de un proceso, los recursos requeridos (roles de software y de hardware), los productos de trabajo de entrada y salida, los procedimientos adoptados (métodos, técnicas, plantillas) y el modelo de ciclo de vida que será usado (Falbo & Bertollo, 2009). Dichas entidades se especifican como elementos básicos o primarios de una estructura estática (figura 7) y son necesarios en la evaluación de procesos (Kruchten, 1998; NMX-I-059, 2011). Sin embargo, existen otros elementos que también intervienen en un programa de SPI, tal como se muestra en el cuadro 6, el cual proporciona una plantilla para capturar el conocimiento tácito. Un problema especial con el conocimiento tácito es que por su naturaleza no es fácil de articular y, por lo tanto, de medir (Busch et al., 2003).

El patrón de procesos del cuadro 6 se complementa con el cuadro 7, el cual permite especificar los roles involucrados, su forma de participación y los tipos de conocimiento requeridos o que poseen para guiar el proyecto de SPI (¿qué conocimiento existe?). Las observaciones que se capturen y registren se relacionarán con los métodos y técnicas que los roles utilizan en la ejecución de las actividades y qué tienen que ver más con su conocimiento episódico y procedural (¿dónde?, ¿cuándo? y ¿cómo se utilizó el conocimiento?). Asimismo, se puede especificar el conocimiento explícito al referirse a nombres de los métodos y estándares utilizados por los roles, o de los productos de trabajo que se incorporarán a la base de conocimiento (¿cuál conocimiento existe y se usa?). El ¿qué? responde identificando los procesos de la organización; el ¿cuál? se refiere a los activos de conocimiento que contribuyen al éxito en la ejecución de los procesos; el ¿dónde? y ¿cuándo? se capturan para especificar descriptores de tiempo y localización del activo de conocimiento.

Dado que el enfoque de este trabajo es la aplicación de estrategias de gestión del conocimiento en un proyecto de SPI, se utilizarán las entidades de proceso software descritas en este apartado para especificar que:

La gestión del conocimiento es la disciplina que provee de métodos, técnicas y recursos orientados a apoyar a que los roles involucrados en el proyecto de SPI hagan uso de los activos de conocimiento documentados para facilitar el flujo de conocimiento y realizar —de la mejor manera— las actividades de los procesos requeridos por el modelo de referencia, logrando así el propósito de los mismos.

Esta definición propuesta se apoya en el patrón de los cuadros 6 y 7, pero es importante analizar:

- ¿Cuál es el conocimiento generado por la actividad, que es requerido por otra del mismo proceso u otro(s) proceso(s)? Cuando el conocimiento es almacenado en un producto de trabajo, recurso de software o en una base de conocimiento (fuente de conocimiento), sirve como canal de transmisión de conocimiento entre las actividades. De lo contrario, se presenta un problema de riesgo o pérdida de conocimiento (Rodríguez Elías & Martínez, 2011).

- ¿Cuál es el conocimiento obtenido por los roles? Los roles poseen conocimiento tácito, procedural, técnico o episódico para realizar las actividades asignadas. Cuando éste se utiliza para la definición de una plantilla, generación de productos de trabajo, manejo de un recurso de software o en la definición de lecciones aprendidas o mejores prácticas, entonces se difunde o comparte con otros roles o se almacena en alguna fuente de conocimiento para futuros usos.

- ¿Cuál es el conocimiento almacenado u obtenido de un producto de trabajo o definido en algún procedimiento, método o técnica? Éste conocimiento puede ser requerido por un rol para la realización de la actividad, por lo que la fuente sirve como canal para compartir o convertir conocimiento explícito (Rodríguez Elías & Martínez, 2009).

Dichos cuestionamientos sirven como base en la identificación de los elementos, temas o tópicos de conocimientos involucrados en el análisis de flujos de conocimientos. Este análisis se presentará a mayor detalle en el siguiente capítulo.

GESTIÓN DEL CONOCIMIENTO EN LA MEJORA DE PROCESOS DE SOFTWARE

Las prácticas de desarrollo de software están basadas en el conocimiento y competencias de los practicantes y administradores (Arent & Norbjerg, 2000). Mathiassen et al. (2001) enfatizan que los esfuerzos de la SPI dependen del conocimiento tácito de los practicantes en una organización. Por ejemplo, en equipos pequeños de desarrollo de software, la calidad del propio equipo es de suma importancia para lograr resultados favorables, ya que altos niveles de habilidades, experiencia y capacidades (conocimiento tácito) generan calidad en los productos que ellos desarrollan (Sommerville, 2002).

A continuación, se presentan algunos trabajos relacionados, argumentando la relación de gestión del conocimiento en la mejora de conocimientos de software (SPI):

El concepto de Nonaka & Takeuchi (1995) ha sido usado en algunos casos de éxito de SPI (Arent & Nørbjerg, 2000; Arent et al., 2001). Arent & Nørbjerg (2000) analizaron cómo el proceso de creación de conocimiento organizacional puede ayudar iniciativas de mejora, en varios niveles organizacionales (Pouya, 2001). El primer paso en el esfuerzo de mejoras de proceso, se centró en la creación del conocimiento con relación a la madurez actual de las prácticas de la organización de software. Los esfuerzos de mejora creaban nuevos procesos de software con base en la experiencia y el conocimiento de las actividades de software de los practicantes.

Alavi & Leidner (2001) presentan un enfoque pragmático que permite clasificar el conocimiento, identificando los tipos de conocimiento que son útiles a una pequeña empresa desarrolladora de software. Mathiassen et al (2001), estudiaron las mejoras desde la perspectiva de creación del conocimiento. Los autores argumentan que la idea general de mejoras de proceso software es hacer explícito el conocimiento y compartirlo en diferentes niveles de la organización. La teoría de creación del conocimiento organizacional (Nonaka & Takeuchi, 1995) fue usada inicialmente en un esfuerzo para conocer la madurez actual de las prácticas de software. Se identificaron los tipos de conocimiento de quiénes, dónde, cuándo y cómo los crearon, durante las actividades de mejora.

Kautz & Nielsen (2001) estudiaron el rol de la transferencia de conocimiento en la implementación de SPI y el desarrollo de un marco de trabajo práctico que pueda ayudar a los agentes de cambio a entender la implementación de mejoras del proceso. Baskerville & Pries-Heje (1999) investigaron y sugirieron cómo la gestión del conocimiento puede ser usada para desarrollar un conjunto de áreas clave de procesos, como un complemento a las pequeñas y medianas organizaciones, con prácticas del Modelo de Capacidad de Madurez (CMM por las siglas en inglés de Capability Maturity Model).

Anaya et al., (2007) realizaron una caracterización de los activos de competencia o activos intangibles —relevantes a una empresa de desarrollo de software— y objetos de conocimiento (González & Joaquí, 2007). Los autores han contribuido a la definición de una propuesta para el modelado y la gestión del conocimiento en organizaciones orientadas a este fin, con base en modelos de motivación, estructura, procesos, recursos humanos y competencias. Dicho modelo conceptual es un referente para la construcción de una base de conocimiento para la empresa que desee gestionar el aprendizaje generado y evolucionar, tanto en el proceso de ingeniería como en los procesos de gestión y apoyo (Capote et al., 2008).

Pino et al. (2007) presentaron una revisión sistémica sobre las propuestas de mejora de procesos en veinte casos de estudio. En el documento se especifica que la mayor concentración de las propuestas de mejoras (71%) radica en guiar un proyecto; priorizar la implementación de estos progresos; utilizar estándares o modelos de perfeccionamientos existentes, ajustándolos a las necesidades; y evaluar los avances introducidos por el programa de SPI. Es importante resaltar que el tercer tipo del cuadro 8, representado por 11%, muestra que para soportar acciones de mejoras, se propone suministrar herramientas técnicas e instalaciones que apoyen actividades relacionadas con procesos, tales como plantillas de documentos, técnicas y el uso de la gestión del conocimiento (Oktaba et al., 2008; Pino et al., 2007).

Los estudios presentados anteriormente, indican que los puntos relacionados con la creación, modificación y distribución del conocimiento, tienen importantes roles en las iniciativas de mejoras. Sin embargo, se requiere comprender dónde y cómo utilizar las estrategias de la gestión del conocimiento, así como experimentar y desarrollar diferentes perspectivas de ésta, dentro de la práctica de la SPI (Pouya, 2001).

CONCLUSIONES

Las dos primeras secciones presentan cómo los conceptos de conocimiento y gestión del conocimiento son de carácter complejo y multifacético, atribuible (entre otros aspectos) a la demanda de la literatura existente y a la diversidad de disciplinas que abordan la temática (Alavi & Leidner, 2001). Específicamente, para la disciplina de ingeniería de software, el desarrollo de software implica la conjugación de conocimientos, experiencias y esfuerzos de los roles, así como de metodologías, recursos y tiempo disponibles para garantizar el éxito del desarrollo del proyecto. La revisión de literatura de las secciones permitió establecer un marco conceptual para el análisis de flujos de conocimiento en organizaciones, tipo mipymes desarrolladoras de software.

Como se mencionó al inicio de este capítulo, este trabajo se centra en abordar la problemática de cómo el conocimiento tácito de los individuos y el conocimiento explícito de una mipyme dedicada al desarrollo de software, son generados, almacenados y utilizados para mejorar la capacidad de sus procesos, la calidad de los productos (Dingsøyr & Conradi, 2002) y, de esta forma, elevar su nivel de madurez. Tomando en cuenta que el proceso de combinación en los productos de trabajo no extiende por sí mismo la base de conocimiento de una organización (Nonaka & Takeuchi, 1995), la creación de conocimiento organizacional debe ser, entonces, una interacción continua y evolución de los procesos de creación y conversión de conocimiento del modelo SECI.[7]

En el siguiente capítulo se aplicará la metodología KoFI para conocer si dichos elementos, en conjunto, promueven condiciones apropiadas para la generación de procesos mejorados y, al mismo tiempo, evolucionan el conocimiento contenido en las organizaciones de desarrollo de software, particularmente, en las mipymes.

4 Cognoscitivo, del latín congnoscere, conocer. Cognitivo se refiere a lo perteneciente o relativo al conocimiento.

5 El conocimiento organizacional es definido como la capacidad de una organización para generar nuevo conocimiento, diseminarlo entre sus miembros y materializarlo en productos, servicios o sistemas (Alavi & Leidner, 2001).

6 Ver en el capítulo I, el apartado “Gestión del conocimiento en micro, pequeñas y medianas organizaciones”.

7 Asimismo, se deberán considerar las entidades de proceso software definidas en el capítulo I, en el apartado “Entidades de proceso software”, las cuales interactúan con las capacidades, la cultura y el ambiente de la organización.

CAPÍTULO II. MARCO CONCEPTUAL DE LA GESTIÓN DEL CONOCIMIENTO EN PROCESOS SOFTWARE

El principal objetivo de una estrategia o sistema de la gestión del conocimiento es facilitar y mejorar el flujo de aprendizajes (Borghoff & Pareschi, 1998) para permitir la transferencia de capacidades y experiencias, de donde residen a donde se necesitan; a través del tiempo, el espacio y la distribución geográfica (Nissen, 2002). De acuerdo a Rodríguez Elías (2007) existen tres enfoques con respecto al flujo de conocimiento: 1) el proceso de creación del conocimiento (Nonaka & Takeuchi, 1995); 2) el conocimiento como un recurso para brindar la capacidad de utilizar información para la toma de decisiones; y 3) las actividades que componen los procesos de la gestión del conocimiento.

El primer enfoque, conocido también como modelo SECI o modelo de espiral del conocimiento, tiene como objetivo brindar entendimiento sobre cómo las organizaciones administran, aplican y transfieren conocimiento a través de cuatro procesos de creación.

El segundo enfoque se relaciona con el ciclo del conocimiento (Choo, 1999), el cual identifica como campos de uso y creación de información a la percepción del medio ambiente, la generación del conocimiento y la acción (como toma de decisiones).

El último enfoque se relaciona con la dimensión de la actividad del conocimiento, integrando seis actividades para el flujo centrado a la aplicación, transferencia y evolución del conocimiento, denominado por Rodríguez Elías (2007) como modelo integral.

Una vez identificados dichos enfoques, en este capítulo se aplicará la metodología Knowledge Flow Identification (KoFI) para identificar y analizar los flujos de conocimiento relacionados a los procesos SOFTWARE bajo intervención, durante un proyecto de mejora de procesos. Las características que KoFI brinda son (Rodríguez Elías, 2007): obtener la información necesaria para estructurar las fuentes de conocimiento para la organización, identificar la infraestructura tecnológica que apoya los procesos y que interviene en el flujo del conocimiento, y obtener los requisitos para diseñar sistemas o estrategias de gestión del conocimiento, centrados en mejorar el flujo de los aprendizajes relevantes para las actividades a realizar (Maier & Remus, 2002).

Debido a que la aplicación de la metodología KoFI es un proceso iterativo e incremental, este capítulo sólo abordará los dos primeros enfoques de flujos de conocimiento, por lo que el análisis de la dimensión de la actividad del conocimiento se presentará hasta el siguiente capítulo.

IDENTIFICACIÓN DE FLUJOS DE CONOCIMIENTO (KOFI)

El término flujo de conocimiento se refiere al conocimiento que es transferido de una persona o lugar, a otro. El receptor lo relaciona con su propio modelo mental y crea su propia interpretación del conocimiento original que ha recibido (Laihonen, 2006). Dentro de las características de flujos de conocimiento sobresalen (Guo & Wang 2008): su atributo dinámico (Nissen & Levitt, 2002), el comportamiento no lineal de su flujo y, en ocasiones, la complejidad de medirlo y ser aislado (Schutte & Snyman, 2006). Por otro lado, Gupta & Govidarajan (2000) definen a los flujos de conocimiento como la transferencia del saber cómo, la cual consiste en la experiencia que tiene valor estratégico para una organización. Tomando la naturaleza de la dimensión epistemológica (Nonaka & Takeuchi, 1995), se determinó que los procesos de creación y transferencia de conocimiento serán los que se utilicen bajo inspección para la primera fase de la metodología KoFI (figura 8).

La primera fase de KoFI está encargada de la especificación del (los) proceso(s) bajo inspección que posteriormente será(n) modelado(s), considerando un enfoque en los flujos de conocimiento. La segunda fase se compone de cuatro etapas de análisis. Las dos primeras identifican las fuentes y tipos de conocimiento para, posteriormente, analizar la forma de cómo el conocimiento fluye dentro del grupo de trabajo, detectando problemas que puedan estar afectando dicho flujo. Por último, la tercera fase específica los recursos de infraestructura que se involucran en el flujo de conocimiento (Rodríguez Elías, 2007).

Primeramente, se aplicarán los enfoques de flujo de conocimiento (modelo SECI y el ciclo de conocimiento) relacionados a un proyecto de SPI.[8] De tal forma que los resultados de cada una de las fases posteriores brindará a los responsables de procesos o al equipo de mejora, información sobre enfoques y estrategias de gestión del conocimiento, la cual será útil en la implementación de un programa de mejoras, en una organización de desarrollo de software.

En el capítulo anterior se presentaron a detalle los procesos involucrados en el modelo SECI, correspondiente a la dimensión epistemológica,[9] por lo que enseguida se presentan las características generales para el ciclo de conocimiento.

El ciclo de conocimiento sirve como un paso inicial para comenzar a identificar los elementos involucrados y las direcciones (conexiones) de los flujos de conocimiento en el análisis de procesos, en este caso de software. En este enfoque, la percepción se obtiene mediante la creación y uso de diversas fuentes de conocimiento que sirven para los flujos de experiencias (figura 9). La percepción conduce a la creación de significados compartidos o modelos mentales que son utilizados para planear y tomar decisiones. Las conexiones representan el conocimiento requerido y generado por las actividades, así como las fuentes de información o conocimiento de donde éste es obtenido o almacenado (Rodríguez Elías, 2007).

MODELADO DE FLUJOS DE CONOCIMIENTO

Como se presentó en la figura 8, la fase de modelado de la metodología KoFI se divide en dos niveles de abstracción. El primero, para identificar las características de los procesos en términos generales (modelado global) y el segundo, para definir a más detalle los distintos elementos que participan en los procesos (modelado detallado).

MODELADO GLOBAL PARA ENFOQUES DE FLUJO DE CONOCIMIENTO

Se utilizará la técnica de gráfica rica adaptada para el modelado global, debido a que brinda una visión general y de alto nivel de los enfoques de flujo de conocimiento seleccionados (Rodríguez Elías, 2007). Los elementos de dicha técnica diagramática incluyen (figura 10): actividad(es), persona(s), rol(es) o grupos de personas que intervienen en el proceso, conexiones para relacionar actividades con los distintos elementos del proceso, conocimiento y fuentes de información y de conocimiento donde éste es obtenido o almacenado.

El cuadro 9 presenta las categorías de las fuentes de información o conocimiento definidas por Rodríguez Elías (2007) y su asociación directa con las entidades proceso software.[10] La identificación del tipo de conocimiento existente para algunas de ellas se describirá en la siguiente etapa.

La necesidad de describir el conocimiento requerido por el rol para realizar la actividad asignada se observa claramente en el patrón del cuadro 6. Por tal motivo, es importante clasificar con más detalle el conocimiento requerido por alguna fuente (Rodríguez Elías, 2007):

1. Conocimiento del rol. Se refiere a los temas de conocimiento que aportan las personas para desempeñar su rol y realizar las actividades asignadas. Su representación se realiza cuando se conectan los temas por medio de una flecha dirigida desde el rol hacia ellos. Este conocimiento se relaciona con la experiencia en implantaciones anteriores (conocimiento episódico y tácito), conocimiento en el manejo de los modelos o estándares dedicados a la mejora de procesos (conocimiento tópico, procedural o técnico). Por ejemplo, el responsable de la gestión de procesos cuenta con experiencia en la implantación de programas o proyectos de SPI, disponibilidad de tiempo para el seguimiento o evaluación del programa de mejora y se apoya de fuentes de conocimiento como documentación de estándares o modelos que guían la mejora, modelos de referencia y evaluación de procesos.

2. Conocimiento obtenido por el rol. Es el conocimiento que obtienen los roles al desempeñar las actividades del proceso (conocimiento procedural y episódico), por lo que las flechas se dirigen de los temas de conocimiento hacia el rol. En este caso, se relaciona a las situaciones excepcionales y/o lecciones aprendidas que el rol detectó al ejecutar las actividades del proceso o utilizar o generar los productos de trabajo.

3. Conocimiento requerido por la actividad. Se refiere al conocimiento requerido por los roles para desempeñar una actividad o proceso asignado. La flecha de conexión será desde los temas de conocimiento hacia la actividad donde son requeridos. Esto sucede cuando el rol utiliza modelos de referencia de procesos con la especificación explícita de las actividades a desempeñar, los productos de trabajo asociados a cada tarea y el nivel de capacidad del proceso. También serán de ayuda las plantillas o formatos institucionalizados en la organización o técnicas recomendadas para la realización de las actividades.

4. Conocimiento generado por la realización de la actividad. Como su nombre lo indica este conocimiento se obtiene una vez que el rol aprende las actividades asignadas a través de la experiencia y repetición de la misma, por lo que desarrolla o fortalece sus habilidades. El sentido de la flecha va desde la actividad hacia los temas de conocimiento. Este conocimiento se relaciona explícitamente con los productos de trabajo de salida presentados en el cuadro 5.

5. Conocimiento obtenido de alguna fuente. Representa las fuentes de conocimiento o información que son entrada para la realización de las actividades. Se utiliza una flecha dirigida de la fuente a los temas de conocimiento, para indicar que dicho conocimiento se genera o crea a partir del uso de la fuente. En este caso, todos los productos de trabajo o procedimientos serán conocimiento explícito de entrada para realizar las tareas.

6. Conocimiento almacenado en alguna fuente. A diferencia del conocimiento obtenido por la entrada del uso de alguna fuente de información o conocimiento, el conocimiento almacenado es que se genera como producto de trabajo de salida para ser guardado en alguna fuente. La dirección de la flecha va desde los temas de conocimiento hasta las fuentes de conocimiento. Este conocimiento explícito servirá para la construcción de una base de conocimiento conforme se avanza de nivel de capacidad de procesos. La dependencia con el conocimiento tácito de los roles servirá para producir, validar y evolucionar todo lo que se almacene en la(s) fuente(s) de información o conocimiento.

De acuerdo con Rao (2005) una estrategia de gestión de conocimiento es la definición de taxonomías que permitan clasificar y organizar el conocimiento, así como las fuentes de donde se obtiene o donde se almacena o dirige (cuadro 9). Las taxonomías deben de reflejar las relaciones y dependencias entre los conceptos de conocimiento, de manera de que el rol realice las actividades definidas en los procesos, apoyado de los procedimientos y recursos con que se cuente. Por tal motivo, la figura 11 muestra la asociación de los seis tipos de conocimiento descritos y las conexiones (relaciones y dependencias) relacionados a las entidades proceso software, como fuentes de conocimiento bajo el modelado de gráfica rica adaptada.

Las dos llaves permiten especificar algún tipo de conocimiento involucrado en cualquier actividad de un proceso, mientras que las conexiones son flechas continuas donde éstas apuntan hacia los elementos del ciclo del conocimiento con que se relacionan. Esta asociación se puede observar en la figura 12 utilizando la estructura estática de las entidades proceso software y su complemento para la especificación y captura del conocimiento por los roles y actividades.

Para ejemplificar lo anterior, en la figura 13 se observa como trabajador de conocimiento al rol responsable de gestión de proyectos, quien interactúa con el responsable de administración de proyectos específicos, para realizar, en conjunto, alguna actividad utilizando su propio conocimiento, y/o haciendo uso de las fuentes de conocimiento que le puedan ser relevantes, tales como la contenida en los documentos ISO 10006, Swebok o Pmbok (Flores Ríos & Rodríguez Elías, 2010). Dentro de las fuentes de conocimiento se incluye como herramienta de soporte a la base de conocimiento. Una vez que los productos de trabajo han sido identificados y creados se requerirá una forma de acceso para su administración efectiva, por ejemplo, una intranet.

En un proyecto de SPI se mantiene y administra una base de conocimiento, en la cual se almacenan todos los productos de trabajo y activos del conocimiento utilizados y generados durante cada ciclo de mejora. El problema en sí es cómo contribuir de manera organizada con esta base de conocimiento, para que todos los roles interesados en determinados temas, puedan acceder y encontrar la información necesaria sobre los ciclos de mejora anteriores (Capote et al., 2008) y que les sea útil para los actuales o próximos. Oktaba et al. (2008) exponen la importancia de contar con una base de experiencias (o base de conocimiento) desde el principio del programa SPI, y en todos los niveles organizacionales, sin tomar en cuenta la calidad de los recursos o productos almacenados, puesto que todos son y serán útiles. Esto sucede sólo para el nivel cero y uno de capacidad de procesos, debido a que resulta poco perceptible la aplicación de atributos de proceso, ya que el propósito del nivel está basado sólo en los indicadores de las actividades y la creación de los productos de trabajo. Sin embargo, a partir del nivel dos (y superiores) de capacidad de procesos (de los modelos de referencia como CMMI, Moprosoft o Competisoft) se asocia más de un atributo de proceso con más de un logro a cumplir, por lo que se requiere, además del conocimiento explícito generado por la actividad o el almacenado en la base de conocimiento, el conocimiento tácito, técnico, tópico, procedural y episódico de los roles, mismo que es requerido por las diferentes actividades para lograr el propósito del proceso (Flores Ríos et al., 2013).

Por todo lo anterior, la gráfica rica adaptada de la figura 14 sugiere que los procesos de creación de conocimiento del modelo SECI y del ciclo del conocimiento, no son procesos aislados uno del otro, sino que se encuentran interrelacionados, debido a que la aplicación del conocimiento permite también incrementar el ya existente (Rodríguez Elías, 2007). El escenario de dicha figura también involucra a las entidades de procesos software donde el trabajador de conocimiento (rol responsable de gestión de proyectos) crea y usa conocimiento explícito (procesos de combinación e interiorización); y transmite conocimiento tácito a otros roles o lo documenta en productos de trabajo (procesos de socialización y exteriorización) al desempeñar sus actividades diarias, haciendo uso de fuentes de conocimiento (roles, métodos, técnicas, plantillas, recursos de software o productos de trabajo), que no sólo le ayuden a realizar dichas actividades, sino que, también, le permitan tener la capacidad para resolver problemas inesperados, hacer toma de decisiones correctas e incrementar sistemáticamente el conocimiento. Este escenario, a un nivel más detallado, permitirá detectar los diferentes tipos de conocimiento involucrados en cada entidad de proceso software, por lo que se analizará en las siguientes fases de la metodología KoFI.

MODELADO DETALLADO PARA LAS ENTIDADES PROCESO SOFTWARE

En el capítulo anterior se especificó que el estándar base de los modelos de procesos de software, en SPEM, son los elementos de rol, actividad y producto de trabajo. El modelado global de la figura 11 es ahora presentado a un nivel de detalle bajo la notación de los íconos utilizados para los demás elementos que componen un modelo en SPEM y utilizando el enfoque de ciclo de conocimiento (figura 15). El ciclo de conocimiento ha sido examinado como un conjunto discreto de actividades que se realizan dentro de las organizaciones (Choo & Johnston, 2004). Sin dejar de reconocer el valor de cada elemento por separado, la dinámica de las diferentes conexiones entre ellos genera el mayor potencial para la creación del conocimiento y el valor de las organizaciones (Choo, 1998).

En el modelo de la figura 15, la percepción se refiere a los significados compartidos que forman la misión y visión de la organización, y enmarca el análisis de oportunidades y amenazas especificadas en el plan estratégico para un periodo específico. La creación de nuevo conocimiento involucra todos los procesos de creación de conocimiento dependiendo del nivel de madurez de la organización. Las actividades son realizadas por los roles, quienes son responsables del uso, generación y almacenamiento de los aprendizajes en diversas fuentes de información y conocimiento. Sus interpretaciones, estructuradas por reglas o rutinas, guían las decisiones según las prioridades de la organización. Por ejemplo, dentro de un proyecto de SPI los roles establecen, actualizan, corrigen, verifican y validan procedimientos, métodos, productos de trabajo o plantillas requeridos por los procesos y el nivel de capacidad.

Es así como una organización va adquiriendo madurez cuando innova y aprende, dependiendo de su habilidad para implementar, gestionar, establecer y controlar una serie interrelacionada de procesos en los cuales los roles realizan actividades bajo su percepción y significado de lo que está sucediendo en el entorno. Además, se identifican, analizan, definen y establecen oportunidades de mejora continua, derivadas de nuevos recursos o fuentes de conocimiento para alcanzar los objetivos actuales y futuros.

Debido a que la optimización e innovación de procesos no es algo sencillo o fácil para las pequeñas organizaciones de software (Mas & Amengual, 2005) o supone la inversión de dinero, tiempo y recursos, así como la alta complejidad de las recomendaciones (Pino et al., 2007) y especificaciones de los modelos de referencia de procesos; se analizarán y modelarán todos los procesos de creación del conocimiento involucrados en las entidades proceso software con el propósito de detectar y definir los flujos de conocimiento, y sus conexiones, necesarios en un marco de trabajo de gestión de conocimiento que apoye la implementación de un programa de SPI. Los modelos resultantes estarán representados en la notación de la extensión de SPEM llamada SPEM-KF (Rodríguez Elías et al., 2009). El propósito general de SPEM-KF es: 1) modelar los conceptos de conocimiento (KConcept) relacionados con los tipos o temas de conocimiento (KTopic) y fuentes de conocimiento (KSource) que están involucrados en las actividades del proceso. KTopic es usado para representar temas o tópicos de conocimiento requeridos o generados por las actividades, así como aquel aprendizaje que es almacenado u obtenido de las fuentes de conocimiento. KSource se utiliza para identificar a estas fuentes, así como para clasificar sus categorías (KSourceCategory) y sus tipos (KSourceKind); 2) identificar y modelar cómo fluye el conocimiento a través de las actividades o la forma en que las fuentes específicas están siendo usadas o modificadas en la ejecución del proceso. Groupknowledge representa grupos de fuentes, áreas o temas de conocimiento o habilidades de los roles; y 3) modelar la transferencia de conocimiento entre las fuentes (KnowledgeTransfer). KnowledgeTransfer indica el conocimiento que es transferido entre las distintas fuentes dentro de una actividad o flujo de trabajo determinado. Cada fuente se conecta con el tema de conocimiento que aporta u obtiene durante la transferencia por medio de relaciones tipo KnowsAbout.

La simbología de SPEM-KF se muestra en la figura 16, y es usada en conjunto con los elementos propuestos por la especificación SPEM (Rodríguez Elías & Martínez, 2011). Asimismo, la figura 17 presenta el metamodelo de fuentes y tipos de conocimientos por el elemento KConcept para definir el propósito y objetivos del proceso. En cada categoría de fuente de conocimiento (KSourceCategory) se pueden definir diversos tipos (KSourceKind). Por otro lado, cada KSource tiene una o más localizaciones para especificar explícitamente el lugar donde la fuente se localiza (Rodríguez Elías et al., 2009) y otras características correspondientes a las categorías de fuentes de conocimiento (cuadro 9). Estos elementos se utilizarán en el siguiente apartado para modelar los flujos de conocimiento, bajo los enfoques del modelo de creación del conocimiento y su ciclo, en las entidades proceso software involucradas en un programa de SPI.

ANÁLISIS DE FLUJOS DE CONOCIMIENTO

La fase de análisis de la metodología KoFI está estructurada por las siguientes etapas: la identificación y clasificación de las principales fuentes y tipos de conocimiento que intervienen en el proceso bajo inspección, y la identificación de problemas en el flujo de conocimiento. En el cuadro 9 se presentó, en un primer nivel, las categorías de identificación y clasificación de fuentes de conocimiento (KSourceCategory). Ahora, se utilizarán el metamodelo de fuentes y tipos de conocimiento y el diagrama de transferencia de conocimiento, entre distintas fuentes para analizar los procesos de creación del conocimiento involucrados en las entidades proceso software.

IDENTIFICACIÓN Y CLASIFICACIÓN DE FUENTES DE CONOCIMIENTO

Un modo conveniente de organizar y describir las fuentes de conocimiento específicas del metamodelo de la figura 17, es utilizando una plantilla o un marco para la descripción del conocimiento, el cual se divide en secciones de conocimiento y/o segmentos de conocimiento (Wiig et al., 1999). La existencia de un marco, brinda a los usuarios actuales y potenciales, un mayor entendimiento del conocimiento que está disponible (OICT, 2002).

El marco del cuadro 10 es una adaptación de la propuesta de Rodríguez Elías (2007), para representar la descripción de las fuentes de conocimiento y en ella se consideran elementos de localización y forma del marco de Wiig et al. (1999). El objetivo es capturar conocimiento tácito y explícito para generar conocimiento explícito, especificando el nombre de las fuentes, su localización y su asociación a un tipo de formato y soporte físico, en caso de que aplique (Rodríguez Elías, 2007).

Jackson (2005) menciona que en un entorno donde el conocimiento esté poco estructurado y el trabajo no es rutinario, el contar con descripciones de conocimiento permite usar índices para encontrar fuentes de conocimientos específicas (por ejemplo, personas). Al utilizar un marco, la organización podrá registrar la instrucción específica que poseen los roles, haciendo una referencia cruzada con la descripción de las fuentes de conocimiento. Esto permitirá que las competencias que tiene un trabajador de conocimiento puedan ser identificadas apropiadamente, siendo actualizadas en función de los objetivos específicos de la alta dirección de una organización o después de una auditoría de conocimiento (OICT, 2002).

En la figura 17 del metamodelo, también se muestra cómo cada KConcept se puede relacionar a cierto nivel de conocimiento (KLevel) o experiencia de los roles sobre temas específicos o de alguna otra fuente. Estos elementos se relacionan directamente con la categoría de personas (entidad rol) y la segunda parte de la plantilla de fuentes de conocimiento. En el cuadro 10 se hace uso de los cinco niveles de experiencia o conocimiento propuestos por Dalkir (2011). La descripción de dichos niveles se muestra en el cuadro 11, y debe realizarse con base en las necesidades de la organización donde se vaya a aplicar (Rodríguez Elías, 2007).

Para ejemplificar la identificación de las fuentes de conocimiento de esta fase de análisis, se presenta la figura 18. Esta figura muestra la asociación de la estructura estática de las entidades proceso software con las categorías de fuentes de conocimiento (cuadro 9) y su descripción. El mapa de la figura 18 es una demostración visual de la información capturada y sus relaciones (por medio de líneas punteadas) que permiten el estudio del conocimiento por observadores o usuarios con experiencia en múltiples niveles de detalle. Un mapa también puede servir como vínculo a fuentes de conocimiento más detalladas o como apuntadores al conocimiento implícito (Barquin & Bennet, 2001).

Asimismo, los tipos de conocimientos identificados en la figura 12 permiten inferir que es necesario identificar más tipos (taxonomía) de conocimientos involucrados para cada una de las entidades, mostrando la importancia y las relaciones entre las fuentes de conocimiento y su dinámica. Esto se analizará con mayor detalle en la siguiente etapa de análisis.

IDENTIFICACIÓN Y CLASIFICACIÓN DE TIPOS DE CONOCIMIENTO

En la segunda etapa de análisis se hace uso de taxonomías para clasificar los tipos de conocimiento (Rodríguez Elías et al., 2009). Particularmente, el metamodelo de fuentes y tipos de conocimientos de la figura 17 se utiliza como base para la clasificación de tipos de conocimientos. Según Rodríguez Elías (2007), los niveles de abstracción se separan en categorías de conocimiento (KCategory) que son usadas para organizar y clasificar KArea relacionadas. Las áreas se pueden organizar, a su vez, en áreas más especializadas o con temas de conocimiento específico (KSubject). Estos describen el conocimiento sobre un conjunto de elementos que pueden ser definidos como una unidad básica de conocimiento o pueden estar constituidos por temas más específicos. Este nivel de clasificación de tipos de conocimiento dependerá del nivel de detalle y abstracción que se requiera en una organización.

Siguiendo este modelo conceptual se identificarán los distintos tipos de conocimientos involucrados en las entidades proceso software. El cuadro 12 presenta el marco para la descripción de temas de conocimiento. Su utilización permitirá identificar fácilmente, los temas de conocimiento que resulten más relevantes para las actividades y roles del proceso. Según Rodríguez Elías (2007), en una primera iteración de análisis, las actividades se describen en términos generales. Después, en los siguientes ciclos, éstas se podrán especificar a mayor detalle según los resultados de las etapas de definición y modelado de flujos de conocimiento de KoFI. Al realizar esta actividad, se debe de considerar el nivel del manejo de conocimiento, es decir, quién lo posee o accede a él con qué frecuencia, de modo que una estrategia de gestión del conocimiento pueda ser diseñada en función de las características de los temas y tipos de conocimiento.

Como uno de los enfoques de flujos de conocimiento utilizados en este trabajo es el modelo SECI, será necesario identificar y localizar el conocimiento tácito y explícito junto con el nivel de manejo de conocimiento (figura 19). En un programa SPI, el primer nivel estaría relacionado con la especificación descriptiva y explícita de las actividades del proceso, y el uso y generación de productos de trabajo definidos en un modelo de referencia de procesos. En la figura 19 se identifica que el conocimiento tácito pertenece a los roles, y la técnica que ellos utilizan para realizar las actividades es según su experiencia y habilidades, lo que ocasiona que también posean conocimiento procedural, episódico y declarativo (saber qué). Asimismo, se estaría generando conocimiento tópico cuando los roles obtienen significados o definiciones de términos directamente de los estándares o documentos (Flores Ríos & Rodríguez Elías, 2010). Por otro lado, el conocimiento explícito se detecta en toda la especificación del proceso, el uso de métodos y/o técnica (conocimiento procedural) que describen el flujo de trabajo de las actividades. El conocimiento explícito es fácilmente comunicado por medio de las plantillas, los productos de entrada y salida que se definen (tópico y procedural), generan, utilizan o incorporan a la base de conocimiento. Ésta última, considerada como fuente de conocimiento (entidad recurso). Puede ser el caso de que se necesiten otros tipos de conocimiento para poder aplicar el qué se está describiendo, por lo que los roles registrarán sus observaciones, información o aprendizaje, y el tipo de relación que exista entre ellos, generando conocimiento explícito.

Los siguientes niveles de manejo de conocimiento se relacionan con la estrategia para implementar el programa de mejora. La estrategia debe de estar basada en la gestión del cambio y enfocada fundamentalmente en las personas (Bayoda et al., 2010). Una vez que se aplica el conocimiento tópico se obtiene conocimiento tácito sobre cómo los conceptos aprendidos se pueden aplicar para resolver alguna situación o problemática. De esta forma, la aplicación reiterada de los conceptos en casos prácticos genera experiencia del saber cómo adaptar los conocimientos adquiridos para resolver casos similares. Así, los roles conocerán tanto las ventajas y esfuerzos necesarios para alcanzar el nivel de madurez de la organización o elevar el nivel de capacidad de procesos, considerando los requisitos solicitados en las normas o modelos (conocimiento tópico o técnico), los ¿cómo? (conocimiento procedural), así también, la captura de conocimiento tácito o episódico sobre un tema específico. Todas las relaciones expuestas anteriormente se presentan en la figura 20 con una línea punteada entre la estructura estática de las entidades proceso software con el marco de definición de tipos de conocimiento.

Considerando que el objetivo de las dos primeras etapas de análisis de flujos de conocimientos es obtener un mapa, se elaboró la figura 21. Este mapa involucra las categorías de fuentes de conocimiento, información sobre fuentes, tipos, dependencias, áreas, temas y demás aspectos presentados en la descripción de fuentes y tipos de conocimiento. La figura 21 presenta la asociación integral que existiría entre el mapa de conocimiento con la estructura estática de las entidades proceso software. Ahora bien, la tercera y cuarta etapa de análisis se centrarán en la identificación de flujos existentes entre los dos enfoques utilizados (modelo SECI y ciclo de conocimiento) y las entidades proceso software, para identificar los posibles problemas o situaciones que puedan afectar dicho flujo.

IDENTIFICACIÓN DE FLUJOS DE CONOCIMIENTO

En la tercera etapa de análisis de la metodología KoFI se identifica el conocimiento que es aplicado o requerido durante la realización de las actividades o toma de decisiones, las fuentes donde es almacenado u obtenido, así como los mecanismos utilizados para localizar las fuentes y transformar este conocimiento. Como ya lo hemos analizado,[11] para la identificación de flujos de conocimiento, Rodríguez Elías et al. (2009) proponen utilizar simbología de SPEM-KF. Los modelos sirven de apoyo en la identificación de problemas y requisitos para definir estrategias o diseñar sistemas (recursos de software) para resolver los problemas (Cox et al., 2005) o necesidades de conocimiento detectadas. En este sentido, el diagrama de transferencia de conocimiento permite resaltar y visualizar los flujos de conocimiento más relevantes, las actividades donde se presenta la transferencia, así como el conocimiento que se aporta y obtiene de cada fuente (Rodríguez Elías, 2007).

La figura 22 visualiza el modelado detallado para la identificación de flujos por medio de un diagrama de transferencia de conocimiento. Dicho diagrama también apoyaría al analista a detectar el conocimiento que no es almacenado en los productos de trabajo o recursos de software, y la relevancia que tiene cada entidad de proceso software dentro del proceso de creación y del ciclo de conocimiento, ambos, como enfoques de flujos de conocimiento.

Suponiendo que las organizaciones de desarrollo de software cuentan con las entidades proceso software y realizan actividades de un proyecto de SPI, entonces es importante identificar los flujos de los procesos con base en el conocimiento, los cuales, les permitan definir e implementar estrategias o iniciativas para elevar su nivel de gestión del conocimiento. Aun cuando la identificación de problemas y el análisis de herramientas de soporte al flujo del conocimiento corresponden a la cuarta etapa de análisis y la última fase de la metodología KoFI, se integrarán en el análisis, debido a que es importante considerar la infraestructura tecnológica que apoya al proceso como parte integral de una estrategia de gestión del conocimiento (Marwick, 2001). Es necesario aclarar que algunas de las tecnologías se desarrollaron bajo esquemas distintos a la de gestión del conocimiento, sin embargo, considerando las características y bondades que poseen, son consideradas como parte esencial de los mecanismos que apoyan los procesos de flujo de conocimiento (Rodríguez Elías, 2003).

Por tal motivo, se espera que el identificar flujos que se relacionan en cada proceso de creación de conocimiento, se podría retroalimentar a las organizaciones con la información obtenida del análisis, especificándole el tipo de recursos de software y hardware que requieren para complementar la base de conocimiento, dependiendo su nivel de madurez y nivel de gestión del conocimiento.

IDENTIFICACIÓN DE PROBLEMAS EN EL FLUJO DE CONOCIMIENTO

La última etapa de análisis del proceso se centra en identificar los problemas específicos que puedan afectar el flujo de conocimiento, para encontrar estrategias de solución. En este punto se pueden presentar dos situaciones: 1) la decisión de desarrollar o adquirir un nuevo sistema para abordar problemas detectados; o 2) utilizar los ya existentes, posiblemente modificándolos o adaptándolos (Rodríguez Elías, 2008). Para el primer caso, la metodología puede dejar de aplicarse, mientras que, para el segundo, la metodología KoFI brinda un marco de ayuda para identificar el rol de las herramientas o infraestructura como habilitadoras del flujo de conocimiento.

ANÁLISIS DE HERRAMIENTAS DE SOPORTE AL FLUJO DE CONOCIMIENTO

La fase final de la metodología KoFI consiste en aplicar un marco de trabajo para identificar las características de las herramientas o sistemas, por medio de su dominio de aplicación (uso, alcance y dominio de conocimiento), la estructura del conocimiento tácito y conocimiento explícito identificado, y las etapas que constituyen el flujo de conocimiento desde dónde es creado hacia dónde es transmitido o almacenado (Rodríguez Elías et al., 2008). Las etapas constituyen el proceso integrado, definido por Rodríguez Elías (2007).

ANÁLISIS DE FLUJOS DE CONOCIMIENTO DEL MODELO SECI, CON ENTIDADES PROCESO SOFTWARE

En este apartado se analizarán los flujos de conocimiento involucrados en los cuatro procesos de creación y conversión de conocimiento, presentados específicamente en el cuadro 3, y tomando como referencia la figura 23.

SOCIALIZACIÓN: DE CONOCIMIENTO TÁCITO A CONOCIMIENTO TÁCITO

El proceso de socialización (del tipo KnowledgeTransfer) consiste en compartir ampliamente experiencias, modelos mentales o habilidades técnicas (conocimiento tácito) entre roles con una cultura común, para crear más conocimiento tácito y realizar sus actividades efectivamente. Las fuentes de conocimiento (KSource) para este proceso son los roles, recursos, procedimientos y productos de trabajo, aunque este último a menor escala por estar relacionado con el conocimiento explícito. La característica del proceso de socialización es cuando un rol puede adquirir conocimiento tácito directamente de otros roles a través de la observación, imitación, colaboración y la práctica directa; en algunas ocasiones, sin usar un lenguaje verbal. Sin embargo, a un rol le resultará difícil generar conocimiento tácito cuando no hace uso o comparte verbal o directamente su experiencia.

Otra forma de intercambiar o compartir conocimiento tácito es por medio de la localización de expertos (Ackerman, 1998; Girgensohn, et al., 1996), dependiendo el nivel de experiencia o dominio en temas de conocimiento (KLevel) que éstos posean (cuadro 10). El facilitar el acceso a personas con experiencia especializada, según su nivel y dominio en métodos y técnicas y/o uso de ciertas plantillas, permitirá a los roles desempeñar las actividades según la interacción que tengan con ellos. Algunos recursos que se utilizan para localizar expertos son el perfil de una persona, un formato lleno con el nivel o el concepto de conocimiento, preguntas previamente respondidas o asociaciones entre nombre-documento (Marwick, 2001).

Aun cuando el proceso de socialización involucra sólo la utilización y conversión de conocimiento tácito, la categoría de documentos también se detecta en este proceso en un nivel menor. Algunas veces, los roles incrementan su conocimiento tácito cuando otros roles les interpretan el llenado de algunas plantillas de documentos o les mencionan aspectos sobre los productos de trabajo que utilizan en sus actividades. Este escenario se puede ejemplificar cuando una organización de software cuenta con personal con poca experiencia y/o posee procesos inestables o no documentados, solicitando la intervención de consultores expertos para que brinden ayuda en la identificación de causas o circunstancias que originan problemas en el desempeño de las actividades. La organización puede revisar una lista de perfiles de consultores con años de experiencia o nivel de conocimiento en ciertos temas o áreas dentro de su base de datos, intranet o un portal de conocimiento. Dicho nivel corresponderá al dominio o experiencia en métodos, técnicas, en el manejo de plantilla, recursos de software o hardware (cuadro 11).

Se recomienda el uso de reuniones informales de equipo y colaboración (asíncrona y síncrona) para llevar a cabo discusiones y retroalimentaciones detalladas para resolver problemas difíciles relacionados con los proyectos. En dichas reuniones puede participar cualquier rol que esté interesado en el proyecto con disponibilidad para trabajar en equipo. También se puede hacer un foro para el diálogo creativo como medio para compartir experiencias y fomentar la confianza mutua entre el equipo de trabajo.

Cuando los roles socializan, utilizan diversos recursos de software y hardware, dichos recursos se relacionan, como sistemas de información y herramientas dentro de la categoría de fuentes de conocimiento. Algunos ejemplos de herramientas de software que permiten el intercambio de conocimiento, experiencia, confianza e información en ciertas actividades específicas son los portales de conocimiento, sistemas de tele/videoconferencias, mensajería instantánea, entre otros. Por otro lado, los roles se apoyan de cierta tecnología tales como los videoteléfonos, aparatos de videoconferencias, tableros electrónicos o tecnología groupware como recursos de hardware.

Las fuentes de conocimiento detectadas para el proceso de socialización apoyan los flujos de experiencias y conocimiento debido a que durante un programa de SPI se crean significados compartidos entre los roles participantes, tales como el equipo de mejora o el grupo consultor o evaluador de procesos. El conocimiento tácito generado se utilizará para planear y especificar acciones de mejora para los siguientes ciclos o niveles de capacidad de procesos y se relaciona con el conocimiento técnico, procedural y episódico.

Algunos problemas básicos que se pueden presentar cuando sólo existe conocimiento tácito dentro de las organizaciones son:

- Riesgo de pérdida de conocimiento. En la medida de que las organizaciones dependan más del conocimiento tácito estarán con un mayor riesgo de pérdida del mismo. Esto es debido a que este conocimiento radica en los roles y si éstos dejan de trabajar en la organización se llevan su conocimiento consigo (Rus & Lindvall, 2002; Rodríguez Elías, 2003). Puede presentarse el escenario de que algunos roles olvidan lo que aprendieron en proyectos anteriores y vuelven a repetir errores al desempeñar sus nuevas actividades, o que necesiten largos periodos para adquirir o generar conocimiento tácito debido a largas curvas de aprendizaje (Rus & Lindvall, 2002).

- Desperdicio de conocimiento existente. Algunas organizaciones no saben que cuentan con roles con niveles de experiencia o dominio de conocimiento en otras actividades, quienes podrían ayudar a solucionar ciertos problemas, por lo que al no saber que ellos existen, desaprovechan su conocimiento tácito existente.

- No se identifica a todas las personas relevantes. Si bien en la práctica se interactúan con los miembros del equipo de trabajo, las reuniones no suelen ser planificadas ni periódicas o no participan todas las personas o roles involucrados (Cukier, 2008).

La recomendación para reducir el riesgo de pérdida de conocimiento es el uso de la plantilla para la descripción de fuentes y tipos de conocimiento (cuadros 10 y 12), capturando el conocimiento tácito y propiciando la exteriorización del mismo. Se podría inferir que este tipo de problemas suceden en las organizaciones desarrolladoras de software con bajo nivel de madurez.

EXTERIORIZACIÓN: DE CONOCIMIENTO TÁCITO A CONOCIMIENTO EXPLÍCITO

La exteriorización es el proceso esencial a través del cual el conocimiento tácito de un rol puede ser articulado de forma explícita para generar conceptos (figura 25); es decir, se responde a la pregunta sobre si el conocimiento que alguna fuente posee fue aportado por algún rol. Para esto, los roles utilizan analogías, metáforas (Choo, 1999), conceptos, hipótesis, historias o modelos, para percibir o entender intuitivamente una cosa, hecho o situación, imaginando otra, simbólicamente. Es así como por medio de la conceptualización, elicitación y articulación, en colaboración o reflexión colectiva entre los roles, una parte del conocimiento tácito se convierte en explícito. En los modelos creados no debe de haber contradicciones y todos los conceptos y las proposiciones deben expresarse usando un lenguaje sistemático y una lógica coherente.

Por su naturaleza, el conocimiento tácito es difícil de convertir en conocimiento explícito (Marwick, 2001). Sin embargo, si no se presenta la exteriorización, los roles que poseen el conocimiento tácito clave y dejan de estar disponibles en la organización, se llevan consigo su conocimiento (Rus & Lindvall, 2002). Para hacer más efectivo este proceso se utilizan herramientas de software del tipo de newsgroups, groupware, wikis, flujo de trabajo o sistemas colaborativos; y tecnología para el modelado o generación de gráficos o tecnología audiovisual. Por ejemplo, se utilizan recursos de software que permiten guardar el intercambio de información entre roles o generan líneas de código a través de la elaboración de modelos.

Una vez que el conocimiento es explícito, los roles con problemas similares pueden encontrar soluciones al consultar la fuente de información. Para este caso, la plantilla para la definición de tipos de conocimiento (figura 20) cuenta con una sección dedicada a la especificación de las fuentes de conocimiento donde se puede obtener o consultar más conocimiento. Así, los roles consultan las anotaciones o registros de otros roles que se encontraron con la misma situación, especificando el nivel de experiencia que éste posee como experto o maestro; o cuando se definen los nombres de los productos de trabajo y recursos recomendados, facilitando su recuperación o acceso a ellos.

Otras técnicas aceptadas y utilizadas dentro de la ingeniería de software para la exteriorización, son el transmitir lecciones aprendidas (Basili & Caldiera, 1995) o mejores prácticas, utilizando historias o eventos pasados para determinadas situaciones o eventos. El rol posee conocimiento episódico al identificar sus aciertos y dificultades que se le presentan al realizar sus actividades diarias que pueden modificar, parcialmente, el proceso, pero sin afectar los objetivos del mismo. La plantilla del cuadro 6, presentada en el capítulo anterior, permite hacer anotaciones y capturar este conocimiento explícito generado por la realización de la actividad (figura 25).

Algunos de los problemas más comunes por la falta de exteriorización del conocimiento son:

- No todos los miembros del equipo conocen las políticas adecuadas a su rol (Cukier, 2008).

- No siempre se explicita al responsable del proceso. No se presenta evidencia del compromiso de los roles identificados (Cukier, 2008).

COMBINACIÓN: DE CONOCIMIENTO EXPLÍCITO A CONOCIMIENTO EXPLÍCITO

La combinación se refiere al proceso de sistematización de conceptos en el que el rol se dirige a repositorios para satisfacer sus demandas de capacitación, para generar y modificar conocimiento explícito a partir de otro explícito (figura 26). La búsqueda, como la actividad más importante para la manipulación del conocimiento, es encontrar los materiales o contenidos relevantes (Marwick, 2001) en documentos, minutas de juntas o conversaciones por teléfono, base de conocimiento o en la red interna de la organización (intranet). Las herramientas deben facilitar el digerir grandes cantidades de información y enseñanzas que puedan existir en un repositorio (Rodríguez Elías, 2007).

Se recomienda utilizar resúmenes de documentos escritos de manera coherente, usando un lenguaje natural. Está técnica podría reducir la carga de los roles interesados en encontrar los documentos correctos para desempeñar alguna actividad. Sin embargo, puede darse el caso que el acceso a un tema o área de conocimiento de algunos documentos puede estar restringido según las políticas de la organización.

Por otro lado, la figura 26 muestra como el proceso de combinación implica el uso de plantillas, recursos de software y hardware para administrar y buscar colecciones de conocimiento explícito bien establecido, almacenado y persistente para generar más conocimiento explícito. Se pueden utilizar algunos medios, tales como formatos de reportes o presentaciones, correos electrónicos, páginas y sitios web (portales) para que el conocimiento explícito esté disponible para el resto de la organización o una amplia audiencia (Marwick, 2001). Los sitios web o intranets utilizan índices de búsqueda, agentes inteligentes y/o mapas de conocimiento para localizar o buscar ciertos documentos o textos en un dominio específico. También pueden medir y registrar métricas sobre la interacción de los roles en los documentos, como en las bases de datos bibliográficas o sistemas de recuperación de información o documentos electrónicos.

Las corporaciones con bajo nivel de organización y control de conocimiento explícito, pueden presentar algunos de los siguientes problemas:

- Falta (o baja) calidad de los productos de trabajo. Las organizaciones no cuentan con plantillas o productos de trabajo, y cuando las tienen, éstas pueden estar incompletas, de difícil acceso, no actualizadas e, incluso, no corresponden a la realidad de las actividades que se realizan diariamente (Rodríguez Elías, 2007).

- No se definen los requisitos para generar productos de trabajo. Este aspecto se presenta cuando no se tiene una especificación formal o la definición de requisitos para la documentación de los procesos y/o productos de trabajo producidos por la realización de la actividad. Por ejemplo, por la falta de una plantilla específica para la descripción de los proyectos de software se generan diversos formatos para los proyectos, sin la oportunidad de capturar o reutilizar conocimiento explícito de los proyectos relacionados.

- Los productos de trabajo no se identifican o controlan. No todos los productos relevantes al proceso están bajo la gestión de configuración. No siempre existe aseguramiento de la calidad para todos los productos de trabajo relevantes (Cukier, 2008).

- No se genera evidencia de revisiones de los productos de trabajo involucrados. No todos los productos de trabajo pasan por un proceso de revisión y validación.

Por todo lo anterior, se considera que el proceso de combinación es un factor estratégico y de competitividad entre las organizaciones desarrolladoras de software, debido a que es necesario que éstas generen y cuenten con más información y conocimiento explícito a partir del ya existente. Esta situación se observa cuando la alta dirección o grupo directivo específica y combina los conceptos de negocio o visiones corporativas para ciertos productos, definidos en el plan estratégico. Posteriormente, los gerentes de niveles medios los descifrarán y pondrán en operación para generar más conocimiento explícito, que después retroalimentarán y presentarán ante la alta dirección por medio de informes, reportes de actividades o catálogos de documentos, haciendo uso de su intranet.

INTERIORIZACIÓN: DE CONOCIMIENTO EXPLÍCITO A CONOCIMIENTO TÁCITO

Para que el conocimiento explícito se vuelva tácito es de gran ayuda que el conocimiento se verbalice o exprese en historiales orales. Cuando se aprende y socializa, al hacer reiteradamente una actividad, el conocimiento explícito se convierte en conocimiento tácito, procedural y declarativo.

La documentación explícita ayuda a los individuos a interiorizar lo que han experimentado, por lo que éstos enriquecen su conocimiento tácito. De esta forma, los productos de trabajo facilitan la transferencia de conocimiento explícito a otros roles, permitiendo que experimenten, indirectamente, las vivencias de otros, es decir, que las reexperimenten. Leer o escuchar una mejor práctica o lección aprendida de éxito, hace que algunos miembros de la organización sientan el realismo y la esencia de la historia. La experiencia que tuvo lugar en el pasado puede convertirse en conocimiento tácito (learning by doing). De esta forma, cuando el conocimiento tácito se comparte con otros se vuelve parte de la cultura organizacional y se avanza de nivel en la dimensión ontológica (figura 3).

Cuando se tienen equipos multifuncionales o autodirigidos de desarrollo de software se permite que sus miembros aprendan e interioricen una amplia gama de experiencias más allá del trabajo diario o de la función en la que están especializados. El conocimiento operacional generado en cada uno jugaría un papel importante debido a las capacidades y prácticas al implementar nuevos procesos, métodos o estrategias, como parte del desarrollo de proyectos de software.

Aunque la mayoría de las organizaciones reconoce la importancia del proceso de interiorización, el establecimiento de estrategias para generar nuevo conocimiento tácito se les dificulta, debido a cómo el conocimiento explícito está presentado; por ejemplo, la falta de documentación, plantillas o formatos no estructurados para la fácil representación del conocimiento explícito. Por lo anterior, las iniciativas de mejoras de proceso software, además de crear y compartir conocimiento tácito, deben de considerar que el proceso de interiorización es complejo y está en continuo crecimiento, dependiendo del nivel de conocimiento explícito que éstas posean, conforme avanzan en los niveles ontológicos, desde un nivel individual hasta el nivel interorganizacional. Por otro lado, existe una carencia de herramientas que apoyen la conversión de conocimiento explícito a tácito. La mayoría se orienta a apoyar los procesos de socialización, exteriorización y combinación (Rodríguez Elías, 2007).

IDENTIFICACIÓN GLOBAL DE FLUJOS Y PERSPECTIVAS DE CONOCIMIENTO

El modelo de la figura 28 integra los procesos de conversión del conocimiento a partir de los tipos de conocimiento tácito y explícito, activos de conocimiento y las entidades proceso software. El conocimiento armonizado producido en el proceso de socialización se relaciona a los roles que interactúan y comparten modelos mentales y habilidades técnicas, dependiendo del nivel de experiencia (cuadro 10). A partir del proceso de exteriorización, el conocimiento conceptual se genera de la reflexión de conceptos, hipótesis, procedimientos, especificación de formatos, plantillas o modelos. Cuando el conocimiento explícito produce más conocimiento explícito se genera el conocimiento sistémico, a través de la distribución del que se encuentra almacenado en los productos de trabajo, recursos de software (como la base de conocimiento, los repositorios de proyectos, la configuración de software, entre otros). Por último, el conocimiento operacional se genera de la interiorización del conocimiento de los roles a partir del conocimiento explícito asociado a la experiencia. Se recomienda que para que este escenario sea efectivo, los productos de trabajo y procedimientos deberán registrar, describir y almacenar los activos de conocimiento para que los roles, por medio de los recursos de software y hardware, los recuperen e interpreten facilitando la transferencia y generación de nuevo conocimiento. En este sentido, esta sección presenta las características de las tecnologías, herramientas, métodos y técnicas que mejor se adaptan y benefician de cada proceso dinámico de creación del conocimiento, a través de un ciclo continuo y acumulativo.

Para conocer la situación actual de una organización, con respecto al flujo del conocimiento, se identifican las fuentes y tipos de conocimiento requeridos y generados por los principales procesos de conversión (modelo SECI), qué tipo de conocimiento está fluyendo y cuál no (Aurum et al., 2003), y los canales por medio de los cuales fluye (Rodríguez Elías, 2007).

La asociación de procesos del modelo SECI y perspectivas de conocimiento (Alavi & Leidner, 2001) fueron presentadas en la figura 4. Sin embargo, estos elementos se retoman para identificar los flujos de conocimiento involucrados en las entidades proceso software dentro de su estructura estática (figura 29). Algunas de las preguntas que se detectan a partir de la relación de los elementos de dicha figura se presentan en el cuadro 13.

Con frecuencia, en las organizaciones existen tecnologías y herramientas (como los recursos de hardware y software) de uso común, que de alguna manera brindan apoyo a las actividades de gestión del conocimiento (Lindvall & Rus, 2003) y a la realización de los procesos de mejora de proceso software. Es probable que, en un proyecto de mejora de procesos, se proporcionen o adquieran nuevos recursos y se les especifique a los roles ciertos cambios en la forma en la que realizan sus actividades o se propongan mejoras en el flujo del conocimiento, con el propósito de lograr la capacidad de los procesos.

Cuando los roles se oponen, manifiestan su resistencia o requieren de invertir más tiempo, puede deberse a una carencia de conocimiento tácito o explícito en la organización de software. Esta situación se relaciona con la perspectiva del conocimiento visto como una capacidad, por lo que se expone que el nivel de conocimiento involucrado en la dimensión epistemológica se relaciona directamente con el nivel de capacidad de procesos y, por ende, con el nivel de madurez de la organización de software. Esta relación y su validación empírica se abordarán ampliamente en el análisis de niveles de madurez en gestión del conocimiento en el siguiente capítulo.

CONCLUSIONES DEL CAPÍTULO

Este capítulo presenta los resultados del modelado (global y detallado) y análisis de dos enfoques de flujos de conocimiento (modelo SECI y ciclo del conocimiento) aplicados a las entidades de proceso software. Para cada uno de los análisis se adaptaron marcos o plantillas, como estructuras estáticas, con el propósito de capturar, transferir y difundir el conocimiento que posee una organización de software, de una forma entendible, por las personas que pudieran utilizarlo en un momento determinado, propiciando la percepción del entorno, la creación de conocimiento y toma de decisiones. Por entendible, asumimos que el conocimiento explícito se estructura y formaliza para que un trabajador especializado pueda utilizarlo o almacenarlo en la base de conocimiento.

Es importante resaltar que el conocimiento que posee la organización, sobre un dominio en particular, debe ser igual al contenido en los marcos (adquirido de los roles), así como de las diversas fuentes de conocimiento y del modelado, por lo que es importante la verificación y validación pertinente para evitar interpretaciones erróneas. Por otro lado, en los cuatro procesos de creación de conocimiento se caracterizan los flujos de conocimiento existentes en las entidades de proceso software, especificando la utilización de recursos de hardware o software que permiten alcanzar los objetivos al implementar una estrategia de gestión del conocimiento.

Este capítulo nos permitió considerar el modelado de procesos con enfoque en el análisis de flujo de conocimiento, para clasificar y estructurar los tipos y fuentes involucrados en un proyecto de SPI, con base en la gestión del conocimiento. Los modelos resultantes son un apoyo en el análisis de flujo o nivel que caracterizan a los productos de trabajo y los activos de conocimiento, como lecciones aprendidas, buenas y mejores prácticas para los primeros niveles de capacidad de procesos, según la norma ISO/IEC 15504-5 (Flores Ríos et al., 2013). Los atributos de procesos para los niveles de capacidad se analizarán en función a los niveles de madurez de gestión del conocimiento, en el siguiente capítulo.

8 Ver en capítulo I, el apartado “Entidades de proceso software”.

9 Ver en capítulo I, el apartado “Mecanismos de creación del conocimiento”.

10 Ver en el capítulo I, el apartado “Entidades de proceso software”.

11 Ver en el capítulo II, el apartado “Modelado de flujos de conocimiento”.

CAPÍTULO III. MODELO DECLARATIVO DE PROCESOS DE CONOCIMIENTO

Como el capítulo anterior se centró en la utilización de los enfoques de flujos de conocimiento, modelo SECI y el conocimiento como un recurso para la toma de decisiones (Choo & Johnston, 2004); este capítulo abordará un tercer enfoque relacionado a los procesos que componen el ciclo de vida de gestión del conocimiento, por medio de un marco para la descripción de los procesos que llevan a él. Para tal motivo, se retoma cómo el conocimiento tácito y explícito son mutuamente complementarios en el modelo SECI (Nonaka & Takeuchi, 1995), para apoyar la interacción dinámica entre los procesos de conocimiento que realizarán los roles. Se analizará como ambos tipos no son recursos estáticos, sino que varían en función de la etapa del ciclo de vida de la gestión del conocimiento en la que se encuentren y/o de su aplicación. De esta forma, la puesta en marcha de estos procesos ayuda a las organizaciones a aplicar, transferir y evolucionar conocimiento para la generación de productos y/o prestación de servicios, con el propósito de obtener ventajas competitivas (Claver Cortés et al., 2008).

DESCRIPCIÓN DEL MARCO DE PROCESOS DE CONOCIMIENTO

Una buena estrategia de gestión del conocimiento consiste en la definición de los procesos clave, ya que ellos permiten orientar los esfuerzos de análisis a los aspectos de mayor impacto en la organización (Pérez Soltero, 2007). Un ejemplo es la formalización de procesos donde se presenta una definición clara de las actividades y relaciones que les permiten a los roles ser más eficientes en su desempeño, debido a la conversión del conocimiento tácito en explícito (Lee & Choi, 2003). La formalización puede hacerse por medio de plantillas, patrón de procesos (como la presentada en el cuadro 5) o marcos descriptivos (OICT, 2002), los cuales permiten transmitir, utilizar e interpretar el conocimiento declarativo, presentado en secciones y/o segmentos de conocimiento (Wiig et al., 1999).

En este capítulo se propone un marco para la descripción de procesos de conocimiento (figura 30 y cuadro 14) considerando el propuesto por el estándar ISO/IEC 24774, correspondiente al patrón de procesos del cuadro 4 y la estructura estática de las entidades de proceso software, definidos en el capítulo I.

Se recomienda que una organización considere el valor de los procesos de conocimiento en su cultura e implementación de estrategias de gestión del conocimiento y, al mismo tiempo, los integre a las actividades de compartir, comunicar y promover, haciendo uso de una infraestructura donde todos los roles participen (Muzumdar, 1998). Según Pérez Soltero (1997), el identificar estos procesos asegura la naturaleza y los tipos del conocimiento existentes en la organización, favoreciendo la solución de nuevos problemas para aplicar las mejores prácticas de trabajo, entre otras ventajas.

INICIALIZAR EL PROGRAMA DE GESTIÓN DE CONOCIMIENTO EN UN PROYECTO DE MEJORA DE PROCESOS DE SOFTWARE

Este libro propone un programa de gestión del conocimiento con base en los procesos del modelo integral de ciclo de vida de gestión del conocimiento, definidos por Rodríguez Elías & Martínez García (2011). La figura 31 muestra los procesos de conocimiento y la manera en que éste fluye en la organización a partir de la transferencia y conversión del conocimiento tácito y explícito. Estos procesos son de importancia para determinar qué tan eficiente se identifica, almacena, comparte, recupera, utiliza y crea el conocimiento dentro de la organización (Pérez Soltero, 2007). Asimismo, se deben de tomar en cuenta las valoraciones objetivas y subjetivas para medir el impacto e importancia del conocimiento en los procesos del ciclo de vida.

Rodríguez (2006) señala que se deben de establecer tres fases básicas en la implantación de procesos de cualquier programa de gestión del conocimiento: 1) diagnóstico; 2) desarrollo del programa; y 3) evaluación del conocimiento y seguimiento de los resultados. Por lo que para el programa de gestión del conocimiento propuesto se han clasificado los procesos de conocimientos en tres fases, tal como se presentan en la figura 32. En la primera fase se identifican las fuentes y tipos de conocimiento, así como el dominio de aplicación del mismo. La segunda y tercera fase están relacionadas a la dimensión de los procesos de conocimiento con siete procesos centrados en la aplicación, transferencia, medición y evolución del conocimiento. En las siguientes secciones se presentarán a detalle las tres fases de este programa, como apoyo a un proyecto de mejora de procesos de software.

FASE 1. IDENTIFICACIÓN DEL CONOCIMIENTO EXISTENTE

En el capítulo anterior se definieron los marcos para la identificación de las fuentes, tipos y temas de conocimiento (cuadro 10 y cuadro 12). Dichos marcos servirán como productos de trabajo de entrada para los dos procesos relacionados a esta fase. El objetivo es conocer las fuentes y tipos de conocimiento, la importancia y dominio de aplicación que tienen en los procesos requeridos por un modelo de referencia de procesos. De esta forma, el conocimiento identificado será posteriormente almacenado en el repositorio o base de conocimiento, de manera que pueda ser transferido entre los roles (Heredia García, 2012) y aplicado en los procesos de conocimiento de las dos fases restantes.

Proceso: Identificar las fuentes y tipos de conocimiento

Como primera fase se identifican las fuentes y tipos de conocimiento para saber qué, con quién y dónde se encuentran localizados. Las fuentes pueden ser productos y activos de conocimiento, detectados de manera parcial o totalmente en la organización, pero necesarios para realizar las actividades de cada proceso de conocimiento.

Por otro lado, en el cuadro 15 se especifica al trabajador de conocimiento como el rol involucrado en el proceso. Este rol consiste en un equipo técnico, administrativo y de apoyo altamente interesado en la generación del conocimiento y responsable de la gestión del mismo (Alagarsamy et al., 2007). Es el encargado de empaquetar el conocimiento con el apoyo de controles como los estándares, guías, políticas, normas y/o material de capacitación para generar más conocimiento explícito, al proponer modelos formales e informales que garanticen la calidad tanto del proceso como del producto de software.

Proceso: Identificar el dominio de aplicación del conocimiento

El conocimiento de un dominio específico se representa por medio de distintos niveles de formalización, desde un conocimiento explícito expresado en un lenguaje natural hasta reglas o modelos lógicos (Baumeister et al., 2011). También puede ser de tipo tácito, el cual reside en los roles participantes. En el cuadro 11 se presentó cómo cada concepto de conocimiento se categoriza en cinco niveles de experiencia o conocimiento, según el nivel de conocimiento de los roles sobre dominios específicos.

La fase 1 permite formalizar y capturar las fuentes y tipos de conocimiento existentes en la organización, haciendo uso de los cuadros 10 y 12. Además, se especifican las interrelaciones de éstos entre la descomposición del dominio de aplicación.

Supongamos que se desean identificar los tipos de conocimiento y dominio de aplicación asociados a la actividad de establecer o actualizar el producto de trabajo del plan de gestión de proyectos. Dicho producto depende de la cartera de proyectos y considera a los proyectos internos, externos y a las oportunidades de proyectos. Las tareas requerirían de conocimiento procedimental sobre la elaboración de dicho plan. También es preciso recurrir a su definición y conocer su relevancia (conocimiento declarativo-tópico). Con la experiencia que el responsable de gestión de proyectos posea en la generación del plan, se tendría conocimiento declarativo-episódico. En caso de que el dominio de conocimiento sea básico se recomendarán técnicas de apoyo a la gestión del conocimiento, como la colaboración con otros gestores con un nivel de aplicación del conocimiento superior (Flores Ríos & Rodríguez Elías, 2009).

FASE 2. DESARROLLO DEL PROGRAMA DE GESTIÓN DEL CONOCIMIENTO EN UN PROYECTO DE MEJORA DE PROCESOS DE SOFTWARE (SPI)

Si el grado de madurez o cambio organizacional es proporcional a la contribución y dedicación de sus roles en un proyecto de mejora de procesos de software (Alagarsamy et al., 2007), entonces esta proporción puede ser aplicada en la implementación de un programa de gestión del conocimiento ante un proyecto de mejoras, debido a que consideramos que los procesos de conocimiento involucrados en la segunda fase son los indispensables para cumplir las estrategias definidas para un programa de gestión del conocimiento.

En el capítulo I se presentó, desde una perspectiva ontológica, cómo la creación del conocimiento comienza por el individuo y se desarrolla continuamente en todos los niveles de la organización. Sin embargo, dicho proceso de creación no debe verse como un proceso secuencial, sino como la interacción dinámica entre el conocimiento tácito y explícito (Dalkir, 2011), es decir, desde una dimensión epistemológica. Los flujos de conocimientos involucrados en esta dimensión se analizaron posteriormente en el capítulo II, utilizando la simbología SPEM-KF. Por ejemplo, la figura 24 visualiza el modelo de creación de conocimiento tácito a partir de otro conocimiento tácito (socialización), mientras el proceso de creación de conocimiento explícito a partir de otro explícito (combinación), se visualiza en la figura 26.

Los cinco procesos de conocimiento de la fase 2 (figura 33) ayudarán a las organizaciones a analizar la eficiencia del flujo de conocimiento como un paso previo a la medición y evolución del conocimiento. Estos dos procesos corresponden a la fase tres.

Proceso: Crear/generar/adquirir conocimiento

El primer proceso de la fase 2 corresponde a la identificación y adquisición del conocimiento (cuadro 17). Estas actividades están reportadas como las que más tiempo consumen (Pérez Soltero, 2007). El conocimiento identificado y/o adquirido no tiene que haber sido creado recientemente, sólo se requiere que sea nueva adquisición para los roles. Por otro lado, la adquisición de conocimiento es también una problemática a tratar, debido a que los expertos poseen información y conocimiento estructurado de una forma cognitivamente compleja, por lo que su carácter es totalmente de tipo tácito. En el cuadro 17 se recomiendan algunas técnicas, tecnología y sistemas de apoyo para facilitarles a los roles la creación y generación de nuevo conocimiento que pueden utilizar en la ejecución de las actividades de mejora de procesos de software.

Proceso: Exteriorizar conocimiento

En el capítulo anterior se define ampliamente cómo el proceso de exteriorización permite, a partir del conocimiento tácito, la articulación explícita del conocimiento para generar conceptos, hechos o situaciones.[12] Se presenta el modelado del proceso por medio de flujos (figura 25) y se especifican las técnicas y tecnologías aceptadas y utilizadas en Ingeniería de software.

Es por ello que, en la figura 31, la exteriorización está muy relacionada con el proceso de generar conocimiento, capturar, codificar y organizar el conocimiento con el objetivo de facilitar su almacenamiento y manejo (Davenport & Prusak, 2001). Asimismo, este proceso permite enriquecer el conocimiento organizacional mediante contribuciones provenientes de la ejecución de los proyectos (Heredia García, 2012).

Proceso: Almacenar conocimiento

En las organizaciones de software, el conocimiento explícito se identifica en forma de productos de trabajo, archivos, fólderes, bases de datos, artículos de investigación y difusión, libros de normas o estándares, código de software, mensajes de correo electrónico, procedimientos y procesos escritos (Rodríguez Elías & Martínez García, 2011). El proceso de almacenar conocimiento se refiere a gestionar conocimiento explícito utilizando depósitos de conocimiento (Davenport y Prusak, 2001), repositorios de documentos, bases de datos, memoria organizacional, entre otros. El objetivo es almacenar conocimiento en ellos y valorar si la organización proporciona mecanismos sencillos para que los roles tengan la posibilidad de contribuir con nuevo conocimiento o si, por el contrario, es necesario adquirir alguna tecnología o recursos de software para su utilización (Heredia García, 2012).

Se ha observado como prácticas de algunas mipymes la adecuación y generación de productos de trabajo directos como parte de un servicio de consultoría o una cultura de gestión de documentos o almacenamiento de conocimiento explícito (Flores Ríos et al., 2013).

En ocasiones, los roles consideran que si generan los productos de trabajo y almacenan conocimiento explícito, darán cumplimiento a la realización del propósito de las actividades (prácticas base), definidas en un modelo de referencia de procesos, acotando algunos riesgos inherentes a una medición del conocimiento y reduciendo sus debilidades al llenar plantillas para los productos que hagan constatar los resultados del proceso de mejora. Sin embargo, en el proceso de verificación oficial de procesos se analiza que los roles conozcan y comprendan el propósito del proceso, realicen las actividades necesarias para las prácticas base y generen productos como evidencia de la realización y desempeño del proceso. Sin embargo, a partir del nivel dos de capacidad definida por el ISO/IEC 15504, implica que cualquier proceso debe ser planeado, supervisado y adaptado para cumplir con los objetivos del proceso y producir productos de trabajo que se identifican, documentan, almacenan y controlan adecuadamente.

Estás técnicas básicas corresponden al atributo de administración del producto de trabajo (ISO/IEC 15504-5, 2006), donde el proceso de almacenar conocimiento puede apoyar el análisis del flujo de conocimiento explícito, el cual es requerido para obtener el grado del cumplimiento del atributo de proceso. En este proceso es importante cuidar la recuperación de la información, la no sobresaturación de conocimiento explícito requerido por las actividades y el nivel de capacidad del proceso (Flores Ríos et al., 2013).

Proceso: Transferir conocimiento

En ocasiones, las organizaciones enfrentan problemas para distribuir y colocar, a disposición de sus miembros, el conocimiento que ellos necesitan. Generalmente, el conocimiento se transfiere mediante acciones personales y desde un punto de distribución hacia uno o varios grupos específicos de individuos, entre y dentro de los grupos y equipos de trabajo o entre individuos (Pérez Soltero et al., 2013).

En la figura 31 se observa cómo este proceso de transferencia se lleva a cabo de dos maneras, entre el conocimiento tácito a otro tácito (socialización) y entre conocimiento explícito para generar más conocimiento explícito (combinación). Asimismo, la transferencia se interrelaciona con los procesos crear, almacenar y recuperar conocimiento.

El inconveniente para transferir conocimiento tácito contribuye a la dificultad de imitar capacidades (Wan et al., 2011), a la cultura y experiencia personal que no es fácil de transmitir y compartir con otros.[13] Por otro lado, el proceso de combinación involucra la conversión del conocimiento explícito consultando otras fuentes formales de conocimiento, combinándolas o reconfigurándolas para crear nuevo conocimiento explícito.[14]

Proceso: Interiorizar y recuperar conocimiento

Además de ser parte del modelo SECI, este proceso se refleja en el ciclo de conocimiento de Choo (1999), debido a que permite que los roles apliquen su conocimiento tácito para tomar alguna decisión correcta, solucionar un problema inesperado o incrementar sistemáticamente su conocimiento. El conocimiento tácito se representa en distintos formatos, analizando si la forma de representarlo es comprensible y de utilidad (Heredia García, 2012) para que los demás roles o trabajadores de conocimiento ejecuten sus actividades. Una vez recuperado dicho conocimiento, se requiere del filtrado e interpretación del mismo, por tal motivo, estas actividades también se visualizan en la figura 31. La parte “Interiorización: de conocimiento explícito a conocimiento tácito”, del capítulo II, especifica las características generales de este proceso.

FASE 3. EVALUACIÓN DEL CONOCIMIENTO Y SEGUIMIENTO DE RESULTADOS

La tercera y última fase consiste en evaluar o medir el valor de las iniciativas asociadas con las prácticas de la gestión del conocimiento en relación con su aporte al desarrollo y madurez organizacional. Asimismo, los resultados se presentan a los roles involucrados en el proyecto de SPI para dar seguimiento e impacto de las estrategias de gestión del conocimiento en dicho proyecto.

Proceso: Medición del conocimiento

Como se expuso anteriormente, el programa de gestión del conocimiento está apoyado en el modelo integral del ciclo de vida de la gestión, evaluando o midiendo cada uno de los procesos de conocimiento, por lo que se recomienda determinar cuáles de los procesos concentran (suman) mayores ponderaciones según los criterios de medición. Los criterios también se acompañan de valoraciones subjetivas y/o objetivas para medir el impacto de los procesos de conocimiento. Una de las actividades del proceso de medición es la generación de un informe individual para cada proceso (cuadro 18) o un informe integral para un grupo de procesos, correspondientes a cada una de las tres fases del programa. Asimismo, es recomendable apoyarse en los productos o activos de conocimiento que se generaron en cada proceso.

El formato de criterios de medición para los procesos de conocimiento, con base en el trabajo definido por Pérez Soltero (2007) & Wan et al., (2011), permite capturar información y conocimiento de parte de los roles de un proyecto de SPI. El formato incluye: 1) la definición de variables directamente relacionadas a los procesos de conocimiento, dependiendo la fase a la que corresponden; y 2) el valor de la variable, definido por una escala tipo Likert (Hernández Sampieri et al., 2008) donde se incluyen los criterios: totalmente de acuerdo (TD); de acuerdo (D); ni acuerdo ni desacuerdo (N); desacuerdo (DA); y totalmente en desacuerdo (TDA). A continuación, se presenta la estructura y contenido de dicho formato.

CRITERIOS DE MEDICIÓN PARA UN PROGRAMA DE GESTIÓN DEL CONOCIMIENTO EN UN PROYECTO DE MEJORA DE PROCESOS DE SOFTWARE.

1. Datos generales

Área/departamento ______________________

Antigüedad en años en la organización _____________

Nombre del rol ________________________________

Antigüedad en años en su rol/puesto _______________

2. Instrucciones

Escriba una X en la opción que considere que responde cada criterio solicitado.

Abreviaturas:

TD: Totalmente de acuerdo. D: De acuerdo. N: Ni acuerdo ni en desacuerdo.

DA: Desacuerdo. TDA: Totalmente en desacuerdo.

Para conocer la madurez de una organización de software, se recomienda realizar mediciones y autoevaluaciones a los procesos como parte del proyecto SPI. En esta actividad es importante el uso de herramientas o recursos de software que proporcionen información, indicadores y evaluación del conocimiento explícito, reduciendo la subjetividad de los roles con el propósito de lograr resultados válidos, útiles y comparables a la evaluación final (Morales Bustamante, 2013). Es importante que los recursos de software y hardware faciliten el manejo del volumen y complejidad de la información y proporcionen resultados objetivos relacionados a la capacidad del proceso, así como también se identifiquen fortalezas y debilidades para establecer planes de acción que le permitan mejorar sus procedimientos. Actualmente, el formato de criterios de medición está en formato de texto, pero se espera ajustarlo a un recurso de software, el cual brinde más ventajas en el conocimiento de los resultados alcanzados para la aplicación y evolución efectiva de estrategias de gestión del conocimiento en el proyecto de SPI.

Proceso: Aplicar y evolucionar el conocimiento

La importancia de la gestión del conocimiento es asegurar que el conocimiento de una organización se aplique de manera productiva para su beneficio (Probst et al., 2001; Grant, 1996; Rodríguez Elías & Martínez García, 2011). En el capítulo I se puntualizó cómo la aplicación de estrategias de gestión del conocimiento, en el campo de desarrollo de software, ha sido de beneficio por ser disciplinas intensivas en el aprendizaje.

Por ejemplo, en un proyecto de SPI existen diversos elementos como el plan estratégico de la alta dirección, políticas y la cultura organizacional, que inciden en la aplicación de nuevo conocimiento. La aplicación y análisis continuo de éste dependerá de la periodicidad con la que se defina el seguimiento a la implementación de estrategias de la gestión del conocimiento (Pérez Soltero et al., 2013). Por otro lado, cuando los roles se oponen o manifiestan su resistencia a nuevas formas de realizar las actividades o requieren de invertir más recursos y conocimiento tácito para la realización de las mismas, puede deberse a una carencia de conocimiento tácito o explícito en la organización de software. Esta situación se relaciona con el nivel de conocimiento involucrado en la dimensión epistemológica y, al mismo tiempo, con el nivel de capacidad de procesos de la organización de software.

En este apartado se definieron siete procesos de conocimientos involucrados en un programa de gestión del conocimiento. Cada proceso representa un flujo de conocimiento que hace que el conocimiento se mueva dinámicamente dentro de una organización (Pérez Soltero, 2007). Por tal motivo, también es de relevancia para una organización contar con un modelo que represente los procesos de conocimiento, ayudándole a fortalecer su capacidad de procesos (Álvarez Castañón & Páramo Ricoy, 2011) y, al mismo tiempo, elevar su madurez organizacional.

MODELO BIDIMENSIONAL PARA EL ANÁLISIS DE FLUJOS DE CONOCIMIENTO

Los flujos de los procesos de conocimiento del marco declarativo están interrelacionados por la precedencia de los mismos; es decir, algunos de ellos deben completarse primero antes de que otros puedan comenzar con eficacia. De aquí que los flujos de conocimiento se puedan medir con respecto al tiempo (Nissen, 2006). En este apartado se utiliza el modelo extendido de Nissen & Levitt (2002) como base de la propuesta de un diseño factorial tipo 2^2 para el análisis de flujos de conocimiento, involucrados en un programa de gestión del conocimiento relacionado a un proyecto de mejora de procesos de software. Las dos siguientes secciones explican a detalle este planteamiento.

MODELO EXTENDIDO DE FLUJOS DE CONOCIMIENTO

De acuerdo con Nissen & Levitt (2002), la dimensión epistemológica y ontológica son los planteamientos más conocidos sobre flujos de conocimiento en el contexto de aprendizaje organizacional. Dichas dimensiones, descritas en el capítulo I, fueron presentadas en un modelo extendido de flujos de conocimiento como parte de los procesos cíclico e iterativo por los que las organizaciones desarrollan nuevos conocimientos (figura 34). En la figura 34 se observa como el flujo lineal representa la manera en la cual las organizaciones informan y capacitan a sus recursos humanos utilizando conocimiento explícito y el proceso de interiorización. Por otro lado, el flujo cíclico refleja una dinámica más compleja al describir un ciclo de creación, distribución y evolución del conocimiento dentro de un grupo de trabajo (Pérez Soltero, 2007). Es así como el modelo extendido representa la continua creación y desarrollo de conocimiento como factor principal de competitividad organizacional.

La intersección de las dimensiones, presentada en la figura 34, se visualiza como complementaria para la gestión eficiente y eficaz del conocimiento. Por lo que se requiere definir marcos y modelos complementarios e interdependientes para la aplicación de estrategias de gestión del conocimiento en escenarios de desarrollo y mantenimiento de software, mejora de procesos, innovación de procesos, entre otras actividades, puntualizando la transdisciplinariedad entre gestión del conocimiento e ingeniería de software.

DISEÑO DEL MODELO BIDIMENSIONAL

Como primera actividad, se analizó cómo los tipos de conocimiento involucrados en un proyecto SPI están asociados implícitamente con los niveles uno y dos de capacidad de procesos, definidos en ISO/IEC 15504 (2011). Palma et al., (2000) especifican que el nivel de conocimiento se sitúa sobre algo simbólico, como resultado de los procesos que operan en dicho nivel. De esta forma, era necesario conocer los tipos de conocimientos detectados en los primeros niveles de capacidad de procesos.

En la dimensión de capacidad, si una organización de software tiene procesos de nivel cero, significa que el conocimiento no es utilizado, generado o almacenado. El nivel uno 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 roles al aprender a generar y utilizar los productos de trabajo al ejecutar las actividades (conocimiento explícito). Al final de cada ciclo del proyecto de mejora de nivel dos de capacidad, la mipyme contará con nuevo conocimiento explícito almacenado en alguna fuente, conocimiento episódico obtenido y transmitido por los roles, y demás activos almacenados en la base de conocimiento para futuros proyectos. De esta forma, los niveles de capacidad de procesos se constituyen por diferentes tipos de conocimiento que los roles adquieren, procesan, utilizan, almacenan o transmiten para determinar qué acciones tomar para lograr la calidad de sus procesos. Esto significaría que un nivel cinco de capacidad de procesos, según el ISO/IEC 15504 o NMX-I-059, indicaría que todos los tipos de conocimiento estarían disponibles para todos los roles que deseen hacer uso de ellos por medio de una adecuada tecnología de gestión del conocimiento (recursos de infraestructura, intranet y varias base de conocimiento eficientes para el cumplimiento de los indicadores y atributos), con el propósito de que la organización logre la innovación y optimización de los procesos.

Este resultado preliminar, señala que una mipyme que desee implementar un programa de SPI con base en la gestión del conocimiento, 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 base de conocimiento, detectando los activos y fuentes de conocimiento relacionados a los ciclos anteriores; así como todo aquel conocimiento explícito, tópico o semántico que pueda ser útil para crear, compartir y transmitir a todo el equipo de trabajo.

Partiendo del hecho de que los flujos de conocimiento de tipo tácito son más lentos y locales que el conocimiento explícito, debido a que la creación de éste requiere más tiempo que el uso del conocimiento a lo largo de la dimensión del proceso de gestión (Nissen, 2006), la siguiente actividad se orientó a diseñar un modelo bidimensional que caracterice la dinámica de flujos de conocimiento. El modelo propuesto (figura 35) es una dimensión menor al modelo extendido de Nissen & Levitt (2002), donde el eje “y” esté relacionado al nivel de implementación de gestión del conocimiento (por medio del conocimiento tácito y explícito) y el eje “x” corresponde a la dimensión de los siete procesos de conocimiento descritos en el apartado anterior.

La dimensión de los procesos de conocimiento está relacionada a los procesos de las fases dos y tres del modelo propuesto (figura 32). Se observa una asociación continua que va desde los procesos sencillos realizados por los roles, hasta procesos intensivos en conocimiento o muy complejos, que requieren de niveles de dominio de expertos. Por esta razón, el sentido de la flecha hacia abajo indica la utilización del conocimiento tácito de los expertos, mientras la gestión de nuevo conocimiento explícito es en sentido ascendente.

Carver (2001) define que el flujo de conocimiento se puede observar en diferentes tipos, dos de ellos son el longitudinal y el circular. La figura 37 muestra cómo el flujo longitudinal implica la transferencia de conocimiento de arriba hacia abajo; mientras que el flujo de conocimiento del tipo circular es asociado con un ciclo iterativo, donde el conocimiento de los roles es compartido, transferido e incrementado por el proceso. El flujo de conocimiento circular, por lo general, es intensivo y altamente tácito, por lo que se relaciona al proceso de socialización.

DISEÑO FACTORIAL 2^2 DEFINIDO

Cuando en un experimento son variados los factores de interés, se recomienda usar un diseño factorial. Por experimento factorial se entiende que en cada réplica completa del experimento se investiga el efecto de diversas condiciones de experimentación y sus interacciones en el desarrollo y mejoramiento de procesos. Los diseños factoriales 2^2, también conocidos como planes de experiencia, son ampliamente utilizados en experimentos cuantitativos y cualitativos, representando dos niveles. Los niveles son: superior (alto, +) e inferior (bajo, -). La representación geométrica es un cuadrado con 2^2 = 4 corridas, formando los vértices del cuadrado.

En el diseño 2^2 , los efectos de interés son los efectos A, B y la interacción de los factores AB. Donde A es igual a los procesos de conocimiento y B es el nivel de implementación de gestión del conocimiento. Para estimar el efecto principal de A, se calcula el promedio de las observaciones cuando A está en el nivel más alto y se resta de éste el promedio de las observaciones, donde A está en el nivel más bajo. De manera similar se calcula el efecto de B y AB.

Un diseño 2^2 se ajusta a un modelo de regresión, donde los factores A y B se representan con las variables codificadas x_1 y x_2, la interacción AB se representa con el término del producto cruzado del modelo x_1x_2.

Es importante resaltar que - representa los parámetros de los coeficientes de variación parcial para cada una de las variables independientes. Por ejemplo, las variables independientes podrían estar asociadas al nivel de dominio de conocimiento de los roles, el nivel de posición tecnológica en el uso de herramientas y sistemas como apoyo a la gestión del conocimiento o el nivel de capacidad de procesos de la organización. El identificar aquellos factores o variables sobre los cuales las mipymes articulan el éxito de un proyecto de SPI, con base en la gestión del conocimiento, es un tema de gran interés (Alagarsamy et al., 2007). Queda fuera del alcance de este trabajo la interpretación práctica del modelo de regresión bajo la experimentación de un caso de estudio.

CONCLUSIONES DEL CAPÍTULO

Hasta este punto, se ha expuesto cómo el conocimiento (en sus diversos tipos) es un elemento estratégico para las mipymes desarrolladoras de software, propiciándolas a ser generadoras de nuevo conocimiento o desarrolladoras de programas de conocimiento para mejorar la capacidad de sus procesos de software. Como elemento de un marco de trabajo para la implantación de un proyecto de SPI con base en el conocimiento, se presenta un marco declarativo compuesto por tres fases y descrito por siete procesos de conocimiento. Para cada proceso se pueden hacer propuestas de estrategias de gestión, de manera inmediata.

Una contribución principal es el modelo bidimensional para la descripción de flujos de conocimiento relacionados al nivel de implementación de conocimiento explícito y tácito en la dimensión de los procesos de la gestión. Se observa cómo los conocimientos tácito y explícito tienen un menor y mayor grado de especificidad, de dependencia y de carácter individual, dependiendo el nivel de implementación con los procesos relacionados a la identificación, creación, almacenamiento, transferencia, aplicación e innovación del conocimiento.

Aun cuando el modelo bidimensional propuesto no utiliza una dimensión para la dimensión ontológica como el modelo extendido de Nissen & Levitt (2002), también se indica cómo por medio de varios ciclos de mejora de un proyecto de SPI, la organización implementa e institucionaliza las prácticas de mejora de desarrollo y mantenimiento de software, creando nuevo conocimiento a nivel organizacional. Este conocimiento es adquirido inicialmente a nivel individual por los roles participantes de los procesos y, posteriormente, expandiéndolo a nivel organizacional para ser aplicado en nuevos proyectos. De igual manera, se propicia la innovación y mejora continua de procesos como resultado de un alto nivel de implementación de conocimiento explícito y la participación de un grupo de expertos como fuente de conocimiento tácito directa.

12 Ver en el capítulo II, el apartado “Exteriorización: de conocimiento tácito a conocimiento explícito”.

13 El apartado “Socialización: de conocimiento tácito a conocimiento tácito”, del capítulo II, presenta las recomendaciones para reducir la pérdida de conocimiento tácito, propiciando la exteriorización del mismo.

14 La tecnología que apoya este proceso se especificó en el capítulo II, en el apartado: “Combinación: de conocimiento explícito a conocimiento explícito”.

CAPÍTULO IV. CONCLUSIONES Y TRABAJO FUTURO

En este capítulo se exponen las conclusiones y aportaciones específicas para este proyecto de investigación, así como las actividades recomendadas como trabajo futuro. Las conclusiones se expresan con el sentido de resaltar la importancia de aplicar enfoques de flujo de conocimiento en una mipyme desarrolladora de software, como parte de un proyecto de mejora de procesos de software. Es de particular valor, para este tipo de empresas, el adoptar iniciativas de gestión del conocimiento que no requieran la implementación de cambios significativos en la ejecución de sus procesos (Rodríguez Elías & Martínez García, 2011), requeridos por los modelos de referencia de procesos o según el nivel de madurez deseado.

CONCLUSIONES

La naturaleza del conocimiento y su nivel de desarrollo hacen necesario distinguir diversos modelos para su gestión. En el capítulo I se expuso el carácter complejo y multifacético del término conocimiento (ver cuadros 1 y 3, y figuras 3 y 4) y se estableció la evidencia de la transdisciplinariedad entre la ingeniería del conocimiento y la ingeniería del software, al presentar el marco conceptual y el trabajo relacionado entre ambas disciplinas. Se especificó que en un proyecto de mejoras de procesos software se emplea tanto conocimiento declarativo y procedimental, como conocimiento explícito y tácito, para alcanzar las metas del proyecto (Flores Ríos & Rodríguez Elías, 2009). También, se definieron las entidades proceso software (figura 7) que se manejaron en toda la investigación y fueron la base para la descripción de procesos de conocimiento. La definición de dichos procesos se hizo en términos de nombre del proceso, fuentes de conocimiento, trabajador y actividades, productos, técnicas, tecnología y herramientas de gestión del conocimiento recomendada (capítulo III).

Con el objetivo de validar el uso y beneficios de la metodología KoFL, en este documento se observó la aportación de esta metodología al identificar el tipo de conocimiento requerido y aplicado en el análisis de flujos de conocimiento de las entidades proceso software, bajo los enfoques del modelo SECI y del ciclo de conocimiento. Se presentaron diversos modelos detallados, bajo la simbología de la extensión del metamodelo para procesos de ingeniería de software SPEM-KF, con el propósito de que sean de utilidad para los responsables de procesos y se propicie la percepción del entorno, la creación de nuevo conocimiento y la toma de decisión. Tanto la percepción, creación de conocimiento y toma de decisión, como elementos esenciales del ciclo de conocimiento, deberán de considerar el mayor número de entidades.

Debido a que se realiza el análisis de la transferencia de conocimiento de la entidad de donde reside a la(s) entidad(es) donde se necesita(n), se resalta la interacción completa, lo cual es de valor para todas las entidades independientemente del proceso de conocimiento. Por ejemplo, en un proyecto de SPI los roles crean y transmiten conocimiento para la ejecución de sus actividades, por lo tanto, requieren de procesos de conocimiento que les ayuden en dicha ejecución, dependiendo el nivel de capacidad de procesos y, al mismo tiempo, les permitan incrementar sistemáticamente el conocimiento actual o nuevo. Este escenario permite reducir el desaprovechamiento y/o riesgo de pérdida de los activos de conocimiento de la organización.

Posterior a la definición del marco declarativo para los procesos de conocimiento (capítulo III), se decidió diseñar un modelo para el análisis de flujos de conocimiento que considerara visualmente los tres enfoques utilizados en los capítulos I y II, sumados a las características de los niveles de capacidad de procesos; por ejemplo, los definidos por las normas ISO/IEC 15504 o NMX-I-059. Utilizando el enfoque de dinámica de flujos de conocimiento (Nissen, 2006), se realizaron diversos planteamientos como modelos bidimensionales y tridimensionales, pero se concluyó que el modelo resultante debía considerar el mismo número de dimensiones que se plantean en el modelo de evaluación de procesos de un proyecto de SPI, bajo la norma ISO/IEC 15504.

Aun cuando el estudio de modelos de madurez de gestión del conocimiento no fue considerado como objetivo de este trabajo, se valoró si estos modelos podían apoyar la construcción del modelo declarativo de procesos de conocimiento. Un modelo de madurez de la gestión de conocimiento describe las etapas de crecimiento que se espera que una organización realice a través del desarrollo de técnicas de gestión. El resultado de los modelos de madurez de la gestión del conocimiento con base en el modelo de referencia de procesos CMMI, fue representado por medio de un modelo bidimensional donde la intersección del nivel de implementación de la gestión del conocimiento y el nivel de énfasis del conocimiento aplicado, especifican el nivel de madurez organizacional (Flores Ríos et al., 2011). Esto nos mostró que el nivel de implementación de la gestión del conocimiento podría ser representado por los dos tipos de conocimiento involucrados en el modelo SECI y, por otro lado, el nivel de énfasis correspondería a los procesos de conocimiento del modelo declarativo. Las características de los atributos de procesos se analizarían intrínsecamente en la interacción entre ambos puntos. El modelo gráfico fue incluido como elemento importante del modelo declarativo para la interpretación visual que se derive de la aplicación del programa de gestión del conocimiento en un proyecto de mejoras del proceso software.[15]

En la búsqueda de un soporte para la implementación práctica del modelo SECI y del ciclo de conocimiento, así como las prácticas de mejoras del proceso, se seleccionó la infraestructura de fábrica de experiencias. La gestión de calidad que se especifica en dicha infraestructura es una estrategia de gestión enfocada a aumentar la calidad de los productos de software, incrementar el grado de satisfacción de los clientes y mejorar procesos internos, todas éstas de relevancia en un proyecto de SPI. Una vez que se revisaron las características de dicha infraestructura, se integraron y modelaron, bajo la simbología SPEM-KF, los elementos de los dos enfoques, representando una aportación teórica como modelo ampliado.

Por otro lado, la utilidad práctica se presentó por medio de una organización que se rige bajo los procesos requeridos por la norma mexicana NMX-I-059. Una vez que la acción de mejora se ejecuta dentro de la organización se van realizando, al mismo tiempo, las actividades de los procesos requeridos y recolectando los tipos de conocimientos existentes y generados, de manera que se almacenen en la base de conocimiento o experiencia como parte de sus actividades diarias, facilitando la recuperación y acceso al conocimiento explícito existente (Flores Ríos & Rodríguez Elías, 2010).

APORTACIONES

A continuación, se listan las principales contribuciones de esta investigación: 1) la caracterización de los diversos tipos y fuentes de conocimiento involucrados en un proyecto de mejora de procesos de software, con base en el conocimiento; 2) la identificación de un marco, con base en las entidades de proceso software, para definir los elementos de los procesos de conocimiento; 3) la definición de un modelo bidimensional para el análisis de flujos de conocimiento relacionando el nivel de implementación de conocimiento con la dimensión de procesos de conocimiento; y 4) la adaptación de la infraestructura de fábricas de experiencias como una estructura base para las organizaciones dedicadas al desarrollo y mantenimiento de software con iniciativas en crear, almacenar y reutilizar sus activos de conocimiento para elevar su nivel de madurez. Todo lo anterior constituye el marco de trabajo para un proyecto de mejora de proceso, con base en el conocimiento, dando cumplimiento al objetivo general de la investigación, el cual es el diseño de un marco de trabajo para guiar la realización de la gestión del conocimiento en los procesos software bajo intervención, durante un proyecto de mejora de procesos de software.

En el capítulo III se presenta, como parte del marco declarativo, la definición de los siete procesos de conocimiento, agrupados en tres fases de implantación. Es relevante mencionar que, para el proceso de medición de conocimiento, se especificaron los criterios de evaluación para determinar el impacto en los procesos de conocimiento relacionados indirectamente en un modelo de referencia de procesos. Dependiendo los resultados de la medición se pueden aplicar, de manera inmediata, estrategias de gestión del conocimiento en paralelo a la realización de las actividades del proyecto de mejora de procesos de software.

Se plantea que, por medio de varios ciclos de mejoras de proceso, el modelo bidimensional contribuya a que la organización implemente e institucionalice prácticas de mejora de desarrollo y mantenimiento de software, cuando crea nuevo conocimiento desde un nivel individual hasta un nivel organizacional. De esta forma, el modelo bidimensional (figura 35) incluye tanto la dimensión epistemológica (Nonaka & Takeuchi, 1995) como la dimensión ontológica (Nonaka & Takeuchi, 1999). En la primera dimensión se propicia la innovación y mejora continua de procesos, como resultado de un alto nivel de implementación de conocimiento explícito (proceso de combinación) y la participación de un grupo de expertos, como fuente de conocimiento tácito directa, por medio de los procesos de socialización y exteriorización. Por otro lado, desde la perspectiva ontológica, el conocimiento es adquirido a nivel individual a través de los procesos de interiorización y socialización y, posteriormente, transferido y expandido a nivel organizacional para ser aplicado y evolucionado en nuevos proyectos.

Durante una estancia de investigación en una mipyme de la región, que tiene experiencia en desarrollo de sistemas de gestión de documentos (Olguín Espinoza et al., 2012), se observó como el responsable de procesos recomienda a su equipo de trabajo los activos de conocimiento (mejores prácticas y lecciones aprendidas), los recursos de software (de tipo intranet) y los métodos que les permiten —según sus objetivos estratégicos— crear y transferir el conocimiento explícito de la organización y, al mismo tiempo, los capacita en la gestión de los productos de trabajo como evidencia de la realización de sus actividades, requeridas a un nivel dos de capacidad de procesos. En este nivel se desea que los activos de conocimientos sobre la realización de actividades (prácticas base) se transformen de intangibles a explícitos, por lo que se requiere de indicadores de atributos de procesos para su representación, gestión y disponibilidad dentro de la organización. Tomando en cuenta este escenario, se diseñaron formalmente los modelos de conceptos de conocimiento que apoyaron el análisis de conocimiento explícito para los niveles uno y dos de capacidad de procesos (Flores Ríos et al., 2013). Se identificó que el nivel de implementación de conocimiento explícito, para los procesos de conocimiento (exteriorizar, almacenar y transferir), se relaciona directamente con las características correspondientes al atributo de proceso AP 2.2 (administración de productos de trabajo) definido en la norma ISO/IEC 15504-5 (Flores Ríos et al., 2013).

Los modelos generados del análisis de flujo de conocimiento en entidades proceso software, expuestos en el capítulo II, fueron registrados en el Instituto Nacional del Derecho de Autor, con número 03-2013-110110433400-01. El registro representa una colaboración interinstitucional entre la Universidad Autónoma de Baja California, el Instituto Tecnológico de Hermosillo y la Universidad del Cauca, Colombia. Los demás productos corresponden a publicaciones en revistas, congresos internacionales y nacionales, así como la participación en consorcios doctorales.

TRABAJO FUTURO

Como continuación de la investigación realizada, se plantean las siguientes líneas de acción:

1. Validar empíricamente las tres fases del modelo propuesto para la implantación de procesos de conocimiento en un proyecto de mejora de procesos de software, por medio de una(s) mipyme(s) desarrolladora de software. La organización a seleccionar deberá poseer como perfil un equipo de trabajo que tenga acceso a fuentes de conocimiento directas, cuente con conocimiento episódico en la implantación de los procesos requeridos en cualquier nivel de capacidad de procesos o, al menos, que uno de sus roles haya participado en un proceso de verificación oficial. Además de abarcar ampliamente los factores de éxito recomendados en la literatura sobre la implantación de proyectos de mejora de proceso software.

2. Investigar, desde un enfoque de flujo de conocimiento, el tipo y dominio de aplicación de conocimiento involucrado y/o requerido para el atributo de proceso AP 2.1 (gestión de la realización), según la norma ISO/IEC 15504-5. Así como la identificación de aquellos procesos de conocimiento de la fase dos, que sean más recomendados o tengan un mayor impacto en el cumplimiento de los atributos AP 2.1 y AP 2.2. El resultado ampliaría la relación de estrategias de gestión de conocimiento involucradas en un proyecto de mejora del proceso software, con base en el conocimiento.

3. Analizar el flujo de conocimiento tácito del responsable del proyecto de implantación del proceso de mejora, en una mipyme desarrolladora de software. En algunos casos, su nombre se conoce como responsable de gestión de procesos. Se definiría, a nivel de dominio e implementación de conocimiento, una caracterización de dicho rol como trabajador de conocimiento para los procesos que mejor apoyen las actividades requeridas por un modelo de referencia, dependiendo del nivel de madurez deseado.

4. Definir los parámetros del modelo de regresión lineal presentado en el capítulo III para medir el impacto de las estrategias de gestión del conocimiento, en un proyecto de mejora de proceso de software. Alagarsamy et al., (2007) recomiendan especificar el esfuerzo del proyecto en horas, y el del conocimiento en función al nivel de madurez de la organización.

5. Realizar otros análisis de flujo de conocimiento existente en las prácticas de mejora para cada proceso de la infraestructura de fábricas de experiencias, dependiendo del nivel de madurez de la organización, definido por la NMX-I-059.

15 Ver figura 35.

REFERENCIAS BIBLIOGRÁFICAS

Ackerman, M. S. (1994). Augmenting the organizational memory: A field study of answer garden. ACM Transactions on information systems. Proc. Intl. Conference on Computer-Supported Cooperative Work (pp. 243-252). Nueva York: ACM.

Alagarsamy, K., Justus, S. & Iyakutti, K. (2007). The knowledge based software process improvement program: a rational analysis. Software engineering advances, 2007. ICSEA 2007. International Conference (pp. 61-61). Francia: IEEE.

Alavi, M. & Leidner, D. E. (2001). Review: knowledge management and knowledge management systems: conceptual foundations and research issues. MIS Quarterly, 25 (1), 107-136.

Althoff, K. D. & Pfahl, D. (2002). Integrating experience-based knowledge management with sustained competence development. Managing software engineering knowledge. Springer: Verlag.

Álvarez Castañón, L. D. C. & Páramo Ricoy, M. T. (2011). Una valoración de la gestión del conocimiento para el desarrollo organizacional en empresas locales manufactureras del estado de Guanajuato. Memorias del XVI Congreso Internacional de Contaduría, Administración e Informática. México: UNAM.

Anaya, R., Cechich, A. & Henao, M. (2007). A Model to classify knowledge assets of a process oriented development. En H. Oktaba & M. Piattini (eds.). Software process improvement for small and medium enterprises: techniques and case studies (pp. 280-295). Nueva York : Information Science Reference.

Arent, J. & Nørbjerg, J. (2000). Software process improvement as organizational knowledge creation: a multiple case analysis. Proceedings of the 33rd Hawaii International Conference on System Sciences (HICSS) (pp. 40-45). Estados Unidos: IEEE.

Armbrecht, F. M. R., Chapas, R. B., Chappelow, C. C., Farris, G. F., Friga, P. N., Hartz, C.A., …Whitwell, G. E. (2001). Knowledge management. Research and development. Research Technology Management, 44 (4), 28-48.

Aurum, A., Jeffery, R., Wohlin, C. & Handzic, M. (eds.). (2003). Managing software engineering knowledge. Berlín, Alemania: Springer.

Barquin, R., Bennet, A. & Remez S. (2001). Knowledge management: the catalyst for electronic government. Vienna, Virginia: Management Concepts.

Basili, V. R. & Caldiera, G. (1995). Improve software quality by reusing knowledge & experience. Sloan management review, 37 (1), 55-64.

Baumeister, J., Reutelshoefer, J. & Puppe, F. (2011). Engineering intelligent systems on the knowledge formalization continuum. International Journal of Applied Mathematics and Computer Science, 21 (1), 27-39.

Bayoda, S., Calvo-Manzano, J., Cuevas, G. & San Feliu, T. (2010). Taxonomía de factores críticos para el despliegue de procesos software. Revista española de innovación, calidad e ingeniería del software, 6 (3), 6-24.

Benjamins, V. R., Dieter Fensel & Gómez Pérez, A. (1998). Knowledge management through ontologies. En U. Reimer (ed). Proceedings of the Second International Conference of Practicall Aspects of Knowledge Management. Suiza

Boehm, B. (1998). Using the WinWin spiral model: a case study. Computer, 31 (7), 33-44.

Borghoff, U. M. & Pareschi, R. (eds.). (1998). Information technology for knowledge management. Berlín, Alemania: Springer.

Calvo-Manzano, J. A., Cuevas, G., Feliu, T. S. & Serrano, A. (2008). Process asset library to support software process improvement in small settings. Proceedings of the 15th. European Systems and Software Process Improvement and Innovation (EuroSPI). Software process improvement, 16, 25-35.

Campos Valdovinos, Y. & Oktaba, H. (2012). Desarrollo de una herramienta de autoevaluación para el cumplimiento de ISO/IEC 29110:5-1-2. Perfil básico. Congreso Internacional de Investigación e Innovación en Ingeniería de Software (pp. 182-184).

Capote, J., Llanten Astaiza, C. J., Pardo Calvache, C. J., González Ramírez, A. de J. & Collazos, C. A. (2008). Gestión del Conocimiento como apoyo para la mejora de procesos software en las micro, pequeñas y medianas empresas. Revista Ingeniería e investigación, 28 (1), 137-145.

Carnegie Mellon University (2010). CMMI® for Development, Version 1.3, CMMI-DEV V1, Software Engineering Institute, Pittsburgh, Pensilvania: Autor.

Carver J. (2001). Knowledge flow. Recuperado el 15 de octubre de 2013, de http://www.seradigm.com

Certver. (2012). Recuperado el 19 de diciembre de 2012, de http://www.certver.com

Choo, C. W. (1999). La organización inteligente: el empleo de la información para dar significado, crear conocimiento y tomar decisiones. México: Oxford University Press.

Choo, C. W. & Johnston, R. (2004). Innovation in the knowing organization: A case study of and e-commerce initiative. Journal of Knowledge Management, 8 (6), 77-92.

Claver Cortés, E., Pertusa Ortega, E. M., & Zaragoza-Sáez, P. C. (2008). Diseño organizativo y knowledge performance: un estudio empírico. Intangible capital, 4 (3), 166-190.

Cox, K., Hall, J. G. & Rapanotti, L. (2005). A roadmap of problem frames research. Information and software technology, 46 (14), 891-902.

Cukier, J. J. (2008). 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, 4 (2), 20-32.

Dalkir, K. (2011). Knowledge management in theory and practice (2da. ed.). Estados Unidos: The MIT Press.

Davenport, T. & Prusak, P. (2001). Conocimiento en acción: como las organizaciones manejan lo que saben (J. M. Moreno trad.). Buenos Aires: Pearson Education.

Dingsøyr, T. & Conradi, R. (2002). A survey of case studies of the use of knowledge management in software engineering. International journal of software engineering and knowledge engineering, 12 (4), 391-414.

Dingsøyr, T., Bjornson, F. O. & Shull, F. (2009). What do we know about knowledge management? Practical implications for software engineering. Software, IEEE, 26 (3), 100-103.

Dyba, T. (2000). An instrument for measuring the key factors of success in software process improvement. Empirical software engineering, 5, 357-90.

Dyba, T. (2003). Software process improvement success in small and large organizations: an empirical study in the Scandinavian context. AGM Sigsoft software engineering notes, 28 (5), 158-157.

Falbo, R. A. & Bertollo, G. (2009). A software process ontology as a common vocabulary about software processes. International journal of business process integration and management, 4, 239-250.

Flores Ríos, B. L., Astorga Vargas, M. A., Olguín Espinoza, J. M. & Peralta, M. D. C. (2008). 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. Ninth Mexican International Conference on Computer Science (pp. 323-328). México: IEEE.

Flores Ríos, B. L. & Rodríguez Elías, O. M., (2009), Interpretación de la gestión de proyectos de software desde un enfoque de la gestión del conocimiento. Proc. of the XXII Congreso Nacional y VIII Congreso Internacional de Informática y Computación (pp. 21-23). Ensenada, B. C.: ANIEI.

Flores Ríos, B. L. & Rodríguez Elías, O. M. (2010). Experience factory infrastructure as a basis for knowledge management in a software process improvement program. En R. A. Aguilar Vera et al. (eds.), Ingeniería de software e ingeniería del conocimiento: tendencias de investigación e innovación tecnológica en Iberoamérica (p.p. 174-183). México: Alfaomega.

Flores Ríos, B. L., Rodríguez Elías, O. M. & Olguín-Espinoza, M. (2009). Comparative analysis of the ISO 10006 to other standards and guidelines related to software project management. Research on computing science: advances in computer science and artificial intelligence. Instituto Politécnico Nacional, 43, 55-67.

Flores Ríos, B. L., Rodríguez Elías, O. M. & Pino, F. J. (2011). Research on CMM based knowledge management maturity models. Memorias del 4to. Congreso Internacional en Ciencias Computacionales (Cicomp 2011) (pp. 145-152). México: UABC.

Flores Ríos, B. L., Rodríguez Elías, O. M. & Pino, F. J. (2013). Administración del producto de trabajo como gestión de conocimiento explícito de conformidad con el estándar ISO/IEC 15504. Congreso Internacional de Investigación e Innovación en Ingeniería de Software (pp. 29-36). México: Conisoft.

Gastélum Ramírez, S. & Flores Ríos, B. (2010). Análisis de taxonomías de herramientas CASE y su asociación con los procesos relacionados al desarrollo y mantenimiento de software. Ibero-American Symposium on Software Engineering and Knowledge Engineering (JIISIC) (pp. 185-193). México: Alfaomega.

Gastélum Ramírez, S. (2011). Categorización de recursos de infraestructura tecnológica de los procesos operativos y nivel 2 de capacidad de procesos de la NMX-I-059-NYCE-2005 (tesis de maestría). México: Universidad Autónoma de Baja California.

Girgensohn, A., Lee, A. & Schlueter K. (1996). Experience in developing collaborative applications using the World Wide Web ‘Shell’. Seventh ACM Conference on Hypertext (pp. 246-255). Washington D. C.: ACM.

Grant, R. M. (1996). Toward a knowledge-based theory of the firm. Strategic management journal, 17, 109-122.

Guo, J. M. & Wang, Y. L. (2008). Context modeling for knowledge flow. Proceedings of 2008 IEEE. INTERNATIONAL CONFERENCE ON INFORMATION REUSE AND INTEGRATION, IEEE IRI-2008 (pp. 330-335). Piscataway, N. J.: IEEE.

Gupta, A. & Govindarajan, V. (2000). Knowledge flows within multinational corporations. Strategic management journal, 21, 473-96.

Gutiérrez Gasca, E., Gutiérrez Tornes, A. F., Pérez Rojas, A. & Márquez López, L. F. (2008). Acerca de la implementación de los modelos de calidad en la construcción de software en México. Revista digital universitaria, 9, 3-21.

Hall, T., Rainier, A. & Baddoo, N. (2002). Implementing software process improvement: an empirical study. Software process improvement and practice, 7 (1), 3-15.

Heredia García, A. (2012). Itaka. Gestión interactiva del conocimiento en organizaciones de desarrollo de software (tesis doctoral). Madrid: Escuela Politécnica Superior. Universidad Carlos III.

Hernández Sampieri, R., Fernández Collado, C., & Baptista Lucio, P. (2008). Fundamentos de metodología de la investigación. México: Editorial Mc Graw-Hill.

Humphrey, W. S. (1989). Managing the software process. Estados Unidos: Reading, MA: Addison-Wesley.

ISO/IEC 15504-5:2006, Information technology-process assessment, part 5: An exemplar process assessment model.

Jackson, M. (2005). Problem frames and software engineering. Information and Software Technology, 47 (14), 903-912.

Kamsu Foguem, B., Coudert, T., Béler, C. & Geneste, L. (2008). Knowledge formalization in experience feedback processes: An ontology-based approach. Computers in Industry, 59 (7), 694-710.

Laihonen, H. (2006). Knowledge flows in self-organizing processes. Journal of Knowledge Management, 10 (4), 127-135.

Landes, D., Schneider, K. & Houdek, F. (1999). Organizational learning and experience documentation in industrial software projects. International Journal Human-Computer Studies, 51, 643-661.

Laporte, C. Y., Renault, A. & Alexandre, S. (2008). The application of international software engineering standards in very small enterprises. Software Quality Professional, ASQ, 10 (3), 42-70.

Lee, H., & Choi, B. (2003). Knowledge management enablers, processes, and organizational performance: an integrative view and empirical examination. Journal of Management Information Systems, 20 (1), 179-228.

Lindvall, M. & Rus, I. (2003). Knowledge management for software organizations. En A. Aurum et al. (eds.), Managing software engineering knowledge (pp. 73-94). Berlín: Springer.

Makosky, L. (2000). Overview knowledge mapping approach. Proceedings of the Knowledge Management Brighton Workshop at the University of Sussex (pp. 42-44). Reino Unido: Bellanet International Secretariat.

Maier, R., & Remus, U. (2002). Defining process-oriented knowledge management strategies. Knowledge and process management, 9 (2), 103-118.

Marwick, A. D. (2001). Knowledge management technology. IBM Systems journal, 40 (4), 814-830.

Mas, A. & Amengual, E. (2005). La mejora de los procesos de software en las pequeñas y medianas empresas (Pyme). Un nuevo modelo y su aplicación a un caso real. Revista española de innovación, calidad e ingeniería del software. 1 (2), 7-29.

Mathiassen, L. & Pourkomeylian, P. (2003). Managing knowledge in a software organization. Journal of knowledge management, 7 (2), 63-80.

McFeeley, B. (1996). Ideal: A user’s guide for software process improvement (No. CMU/SEI-96-HB-001). Pittsburgh, Pennsylvania: Carnegie-Mellon Univ. Software Engineering Institute.

Moen, R. D., Nolan, T. W. & Provost, L. P. (1999). Improving quality through planned experimentation (2da. ed.). Nueva York: McGraw Hill.

Morales Bustamante, J. P. (2013). AURAP: Herramienta para la autoevaluación de requisitos de procesos establecidos en la NMX-I-059-NYCE-2011 considerando los atributos de procesos de la NMX-I-15504-NYCE-2010 (tesis de maestría). México: UABC.

Muzumdar M. (1998). Organizational knowledge management frameworks and a case study, UMI dissertation. Estados Unidos: Kent State University.

Niazi, M., Wilson, D., Zowghi, D. (2005). A framework for assisting the design of effective software process improvement implementation strategies. Journal of systems and software, 78 (2), 204-222.

Nissen, M. E. (2006). Harnessing knowledge dynamics: Principled organizational knowing and learning. Londres: Irm Press.

Nissen, M. E. & Levitt, R. (2002). Dynamic models of knowledge flow dynamics. Recuperado el 15 de octubre de 2013, de http://cife.stanford.edu/online.publications/WP076.pdf.

NMX-I-059/01-NYCE-2005. (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). México: NYCE.

NMX-I-059/02-NYCE-2011. (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). México: NYCE.

Nonaka, I. (1994). A Dynamic theory of organizational knowledge creation. Organization Science, 5 (1), 14-37.

Nonaka, I. & Takeuchi, H. (1995). The knowledge creating company. How japanese companies create the dynamics of innovation. Reino Unido: Oxford University Press.

Nonaka, I. & Takeuchi, H. (1999). La organización creadora del conocimiento: cómo las compañías japonesas crean la dinámica de la innovación. México: Oxford University Press.

Office of Information and Communications Technology OICT. (2002). Information management inventory guideline, Issue No. 1.0. Sydney, Australia: Autor.

Oktaba, H. (2006). Moprosoft: a software process model for small enterprises. Proceedings of the 1st. International Research Workshop for Process Improvement in Small Settings (pp. 93-101). Pittsburgh: Carnegie Mellon University.

Oktaba, H., Piattini, M., Pino, F. J., Orozco, M. J. & Alquicira, C. (2008). Competisoft, mejora de procesos software para pequeñas y medianas empresas y proyectos. España: Ra-Ma.

Olguín-Espinoza, J. M., Mexía Sánchez, A., Flores Ríos, B. L. & Juárez Curiel, M. (2012). Adopción de un sistema de solicitudes como mecanismo de comunicación con el cliente en una mipyme desarrolladora de software. Congreso Internacional de Investigación e Innovación en Ingeniería de Software (pp. 222-227). México: Conisoft.

Palma, J. T., Paniagua, E., Martín, F. & Marín, R. (2000). Ingeniería del conocimiento. De la extracción al modelado del conocimiento. Revista iberoamericana de inteligencia artificial, 11, 46-72.

Paulk, M. C., Weber, C. V., Curtis, B. & Chrissis, M. B. (1995). The capability maturity model: Guidelines for improving the software process. Boston: Addison Wesley.

Pérez Soltero, A. (1997). Modelo para la representación de una memoria organizacional utilizando herramientas computacionales de internet (tesis de maestría). Monterrey, Nuevo León: Instituto Tecnológico y de Estudios Superiores de Monterrey (ITESM).

Pérez Soltero, A. (2007). Modelo para la auditoría del conocimiento considerando los procesos clave de la organización y utilizando tecnologías basadas en conocimiento (tesis doctoral). Murcia: Universidad de Murcia.

Leal Soto, V., Barceló Valenzuela, M. & León Duarte, J. A. (2013). Un diagnóstico de la gestión del conocimiento en las Pymes del sector restaurantero para identificar áreas de mejora en sus procesos productivos. Intangible capital, 9 (1), 153-183.

Pino, F. J., García, F. O., Ruiz F. & Piattini, M. (2006). Adaptación de las normas ISO/IEC 12207:2002 e ISO/IEC 15504:2003 para la evaluación de la madurez de procesos software en países en desarrollo. Revista IEEE América Latina, 4 (2), 17-24.

Pino, F. J., Vidal, J. C. García, F. & Piattini, M. (2007). Modelo para la implementación de mejora de procesos en pequeñas organizaciones software. En X. Franch (ed.). Actas de la XII Jornadas de Ingeniería Software y Bases de Datos JISBD (pp. 326-336). España: International Thomson.

Poveda Bautista, R., González Cruz, M. C. & Gómez-Senent Martínez, E. (2008). Fundamentos de la dirección y gestión de proyectos. México: Limusa.

Probst, G., Raub, S. & Romhardt, K. (2001). Administre el conocimiento: los pilares del éxito. México: Pearson Educación.

Rao, M. (ed.). (2005). Knowledge management tools and techniques: practitioners and experts evaluate KM solutions. Amsterdam: Elsevier.

Robillard, P. N. (1999). The role of knowledge in software development. Communications of the ACM, 42 (1), 87-92.

Rodríguez Valencia, J. (2006). Dirección moderna de organizaciones (1ra ed.). México: Editorial Thomson.

Rodríguez Elías, O. M. (2003). Administración del conocimiento como soporte al proceso de mantenimiento de software (tesis de maestría). Ensenada, Baja California: CICESE.

Rodríguez Elías, O. M. & Martínez García, A. I. (2011). Diseño de sistemas y estrategias de gestión del conocimiento: Un enfoque metodológico orientado a procesos y flujos de conocimiento. España: Editorial Académica Española.

Rodríguez Elías, O. M. (2007) Metodología para el diseño de sistemas de administración del conocimiento: su aplicación en mantenimiento de software (tesis doctoral). Ensenada, Baja California: CICESE.

Rus, I. & Lindvall, M. (2002). Knowledge management in software engineering. IEEE Software, 19 (3), 26-38.

Schutte, M. & Snyman, M. (2006). Knowledge flow elements within a context - a model. South african journal of information management, 8 (2).

Tiwana, A. (2000). The knowledge management toolkit: Practical techniques for building a knowledge management system. Estados Unidos : Prentice Hall.

Wan, J., Wan, D., Luo, W. & Wan, X. (2011). Research on explicit and tacit knowledge interaction in software process improvement project. Journal of software engineering and applications, 4, 335-344.

Wiig K.M., Hoog R. & Van Der Spek R. (1999). Supporting knowledge management: a selection of methods and techniques. Expert systems with applications, 13 (1), 15-27.

LEGALES

Esta investigación fue dictaminada por pares académicos

Flores Ríos, Brenda Leticia.

Modelo de evolución de la gestión del conocimiento en mipymes, de acuerdo con el nivel de madurez en un programa de mejora de procesos de software [recurso electrónico] / Brenda Leticia Flores Ríos ; prologuista Alberto Mexía Sánchez.-- Mexicali, Baja California : Universidad Autónoma de Baja California, 2017.

1 recurso en línea.-- (Selección Anual para el Libro Universitario)

ISBN 978-607-607-390-2

1. Administración industrial—Procesamiento de datos. 2. Sistemas de información en administración. I. Mexía Sánchez, Alberto, pról. II. Universidad Autónoma de Baja California. III. t. IV. s.

HD30.2 F567 2017

©D.R. 2017 Brenda Leticia Flores Ríos

Las características de esta publicación son propiedad de la

Universidad Autónoma de Baja California.

Departamento de Editorial. Av. Reforma 1375.

Col. Nueva. C.P. 21100. Mexicali, Baja California, México.

Teléfono: (686) 552-1056.

Correo electrónico: editorial@uabc.edu.mx

www.uabc.mx

ISBN 978-607-607-390-2

Coordinación editorial: Laura Figueroa Lizárraga.

Diseño de portada: José Guadalupe Martínez Alvarado.

Formación electrónica: Alejandra E. Mercado Motta

Edición: Rafael Rodríguez y Elba Cortez.

Imagen de portada: “Cabeza del conocimiento”, de Jorge Humberto Ibarra Flores y Zarella Rubio Padilla.

Universidad Autónoma de Baja California

Dr. Juan Manuel Ocegueda Hernández

Rector

Dr. Alfonso Vega López

Secretario general

Dra. Blanca Rosa García Rivera

Vicerrectora Campus Ensenada

Dr. Ángel Norzagaray Norzagaray

Vicerrector Campus Mexicali

Dra. María Eugenia Pérez Morales

Vicerrectora Campus Tijuana

Dr. Hugo Edgardo Méndez Fierros

Secretario de Rectoría e Imagen Institucional

Table of Contents

PRÓLOGO

INTRODUCCIÓN

CAPÍTULO I. MARCO TEÓRICO

CAPÍTULO II. MARCO CONCEPTUAL DE LA GESTIÓN DEL CONOCIMIENTO EN PROCESOS SOFTWARE

CAPÍTULO III. MODELO DECLARATIVO DE PROCESOS DE CONOCIMIENTO

CAPÍTULO IV. CONCLUSIONES Y TRABAJO FUTURO

REFERENCIAS BIBLIOGRÁFICAS

LEGALES