1. INTRODUCCIÓN

Un aspecto relevante en el contexto de la industria de software y la adopción de modelos de proceso software es saber si la complejidad de un modelo es adecuada para su adopción en la organización. Sí bien se han desarrollado estudios sobre la medición de proceso software como (Mitani et al., 2007), (Oliveira, Oliveira, & Belchior, 2006), (Slavek, Lukić, & Köhler, 2012), y (Ram, Rodriguez, & Oivo, 2018), ninguno de ellos evalúa la complejidad del modelo como tal. En contraste se tiene que: (i) en (Rossi & Brinkkemper, 1996) se introduce el concepto de complejidad cognitiva como una medida del grado de complejidad conceptual en función de los factores de complejidad; (ii) en (Perepletchikov, Ryan, & Tari, 2013) se propone un modelo jerárquico de la complejidad cognitiva de productos de trabajo, tareas y metodología; y (iii) en (García, Piattini, Ruiz, Canfora, & Visaggio, 2006), se propone métricas relacionadas al proceso software y un marco para el modelado y evaluación de proceso software. En ese contexto, se reconoce que una organización que logra determinar la complejidad cognitiva de un modelo o metodología, podrá: estimar con mayor fiabilidad el esfuerzo para su implementación o tomar decisiones en el caso de una selección entre múltiples opciones.

De otro lado, la publicación de la ISO/IEC 29110 en el 2011 (ISO/IEC, 2016), representa un hito importante en la industria de software pues está pensada para las pequeñas organizaciones (empresas, áreas, unidades organizacionales, entre otras). Una de las características de esta Norma es que presenta dos procesos (Implementación de Software y Gestión de Proyecto) que son “más ligeros” y que se afirma más adecuado al tamaño de la organización (ISO/IEC, 2011). En particular, para el caso del proceso definido de Gestión de Proyecto, también se dice que es más ligero que una implementación completa de la Guía de los fundamentos para la dirección de proyectos del PMI (referida en la industria como PMBOK de Project Management Body of Knowledge) (PMI, 2017). Sin embargo, en la revisión bibliográfica no se ha encontrado un análisis comparativo de la ISO/IEC 29110-5-1-2 con alguna implementación completa del PMBOK desde la perspectiva de la complejidad cognitiva.

En este artículo se analiza de manera comparada los modelos de gestión de proyectos (en el contexto de la industria de software) de la ISO/IEC 29110-5-2 y una implementación basada en el PMBOK a partir de la determinación de las métricas de complejidad cognitiva. En lo que sigue, el artículo se organiza de la siguiente manera: en la Sección 2, se presenta un marco de referencia; en la Sección 3, se presentan las métricas construidas para realizar esta evaluación; en la Sección 4, se muestran los resultados de las mediciones y el análisis correspondiente; y en la Sección 5, presenta la discusión final y trabajo futuro.

2. MARCO DE REFERENCIA

El presente estudio se ha realizado tomando como base el concepto y métricas de complejidad cognitiva adaptados en su aplicación a procesos de la gestión de proyectos. A continuación se presentan: la complejidad cognitiva, métricas asociadas y la gestión de proyectos.

2.1. Complejidad Cognitiva

En (Perepletchikov et al., 2013) se presenta un modelo de calidad para metodologías de desarrollo de software, como se observa en la Figura 1, organizado en 3 perspectivas, 7 características y 22 sub-características. El Modelo define (descompone) la calidad en 3 perspectivas, siendo relevante para nuestro estudio el relacionado al artefacto estructurado. Dicha perspectiva contiene una característica de comprensibilidad y 3 sub-características de complejidad cognitiva, con sus métricas asociadas. Las sub características de la complejidad cognitiva, siguiendo la notación de los autores, son: (i) S.C.1.1. Complejidad cognitiva del producto de trabajo que presenta 6 métricas; (ii) S.C.1.2 Complejidad cognitiva de las tareas que presenta 4 métricas; y (iii) S.C.1.3 Complejidad cognitiva de la metodología que presenta 14 métricas. De las métricas establecidas en las sub características de la perspectiva de artefacto estructurado (Perepletchikov et al., 2013), el criterio que se ha tomado como referencia es considerar solo aquellas que tienen relación directa con la construcción de un valor único final de complejidad cognitiva como se observa en la Tabla 1. En particular se puede identificar que M6 de la S.C.1.1 está en función de M1, M2 y M3 de la misma S.C.1.1; esta forma de agregar las métricas como distancia euclidiana es definida por los autores a partir del trabajo de Rossi y Brinkkemper, que se presenta en la Sección 2.2.

2.2. Métricas de Rossi y Brinkkemper

En (Rossi & Brinkkemper, 1996) se presenta un conjunto de métricas para el evaluar la complejidad de técnicas y métodos para el desarrollo de sistemas en función de objeto, propiedad y relación. A partir de dicha definición se generan tres métricas como factores de complejidad individual (Rossi & Brinkkemper, 1996) que permiten determinar la complejidad conceptual (ver Tabla 2). Para llegar a dichas métricas se establece que los elementos: Objeto, Propiedad y Relación-rol se conceptualizan como un espacio tridimensional y la medición como un punto en cada eje correspondiente a cada elemento. Por tal razón, la métrica propuesta por los autores se determinar como una distancia (euclidiana) del vector que definen en conjunto los valores de Objeto, Propiedad y Relación-rol.

2.3. Métricas de García y Otros

En (García et al., 2006), como parte del marco para el modelado y evaluación de procesos software (FMESP, por sus siglas en inglés de Framework for the Modeling and Evaluation of Software Processes), se proponen 12 métricas relacionados al proceso de software. Para la presente investigación se consideraron de (García et al., 2006) las siguientes 4 métricas que se han precedido en su identificación con la letra G, tal como se observa en la Tabla 3.

2.4. Trabajos Relacionados

El enfoque métrico de complejidad conceptual fue aplicado en varias investigaciones como: en el método de medición de la complejidad del modelo de gestión de casos y notación (Marin, Lotriet, & Van Der Poll, 2014); en la evaluación de eficiencia de proyectos de desarrollo de software (Cao, Gu, & Thompson, 2012); en (Erickson & Siau, 2005) se desarrolla una medición de complejidad de la técnica UML en la práctica; en (Erickson & Siau, 2004) se destaca la importancia de la complejidad teórica y práctica de un método de desarrollo de sistemas; y, en (Zhang, Kishore, Sharman, & Ramesh, 2007) se realiza una comparación de complejidades entre varios diagramas de UML y un lenguaje de modelado de integración ágil.

2.5. Gestión de Proyecto en la ISO/IEC 29110-5-1-2

La ISO/IEC 29110-5-1-2 (ISO/IEC, 2011) publicada en enero del 2011, es el perfil básico en ingeniería de software y comprende los procesos de Gestión de Proyectos (GP) e Implementación de Software (IS). Estos procesos comprenden prácticas que se basan en la ISO/IEC 12207:2008 (procesos de ciclo de vida del software) y los contenidos de los productos de software desarrollados en la ISO/IEC 15289:2006 pero seleccionadas y adaptadas para pequeñas organizaciones (ISO/IEC, 2011), considerando que una pequeña organización tienen hasta 25 personas en desarrollo de software (ISO/IEC, 2016).

Con respeto al flujo de información del proceso de gestión de proyectos de la ISO/IEC 29110-5-1-2 (ver Figura 2), este contiene entregables de entrada, salida e internos que permiten la interacción entre las 4 actividades (ISO/IEC, 2011): (i) planeación del proyecto; (ii) ejecución del plan de proyecto; (iii) evaluación y control del plan de proyecto; y (iv) cierre del proyecto. Así mismo (ISO/IEC, 2011), cada tarea tiene productos de entradas y productos de salida; los productos de entrada tienen como fuente una entidad o proceso externo; y los productos de salida tienen como destino una entidad o proceso externo.

2.6. Gestión de Proyecto del PMBOK

La Guía PMBOK es un conjunto de buenas prácticas reconocidas que son ampliamente aplicadas por profesionales de la gestión de proyectos para la gestión exitosa de proyectos en todo el mundo (Merquida & Antonia, 2014). Estas buenas prácticas de gestión cubren todo el ciclo de vida de un proyecto (Mas & Mesquida, 2013). Esta Guía (PMI, 2017) contiene 5 grupos de procesos para la dirección de proyectos: (i) grupo de procesos de inicio; (ii) grupo de proceso de planificación; (iii) grupo de procesos de ejecución; (iv) grupo de procesos de monitoreo y control; y (v) grupo de procesos de cierre; y establece 10 áreas de conocimiento: (i) .integración, (ii) alcance, (iii) cronograma, (iv) costos, (v) calidad, (vi) recursos, (vii) comunicaciones, (viii) riesgos, (ix) adquisiciones, y (x) interesados. La estructura contenido en el PMBOK (PMI, 2017) identifica para cada área de conocimiento un conjunto de procesos relacionados como por ejemplo, para el área de conocimiento 4. Gestión de la Integración del Proyecto, donde se identifica 7 procesos, de los cuales se presentan 3 a continuación: 4.1 Desarrollar el Acta de Constitución del Proyecto; 4.2 Desarrollar el Plan para la Dirección del Proyecto; y 4.3 Dirigir y gestionar el Trabajo del Proyecto. Y por último, cada proceso se caracteriza a través de sus entradas, salidas y en conjunto las herramientas y técnicas.

MÉTRICAS PARA EL ANÁLISIS COMPARATIVO

En esta sección se presenta la selección y desarrollo de las métricas para el estudio comparativo. Estas métricas se presentan de manera agrupadas por las sub características tal como se define en el modelo de (Perepletchikov et al., 2013). Las sub características son: (i) complejidad conceptual de las actividades y proceso; (ii) complejidad de las dependencias; y (iii); complejidad cognitiva de la metodología. Para nuestro estudio se ha considerado identificar las métricas definidas para calcular la complejidad cognitiva con el prefijo Z y un correlativo quedando desde Z1 hasta la Z12, los que se presentan a continuación:

a. Complejidad estructural del entregable. Para determinar las métricas a utilizar para esta complejidad, se ha tomado como referencia (Perepletchikov et al., 2013), (Göpferich, 2009) y (Arthur & Stevens, 1989). La métrica se basa en la descomposición de la comprensibilidad aplicado a un entregable (tipo documento) como: (i) coherencia entre títulos y contenidos, (ii) organización en secuencia lógica dirigida por los títulos, (iii) la amplitud del contenido determinada por la estructura del documento o índice; y, (iv) profundidad del contenido determinada por la estructura del documento (índice). Las métricas de Z1 a Z5 se presentan en la Tabla 4 y se obtienen de un instrumento que incluye las estructuras de los documentos asociados a cada propuesta. Para la calificación se utiliza una escala de Likert.

b. Complejidad conceptual de las actividades y proceso. Para determinar esta complejidad se utilizó como referencia las métricas, criterios y filosofía usados en la definición desarrollada en (Rossi & Brinkkemper, 1996) y las propuestas de (Perepletchikov et al., 2013) y (García et al., 2006). Las métricas definidas para nuestro estudio se presentan en la Tabla 4 y se describen a continuación: (i) la métrica Z6, considerando lo de (Perepletchikov et al., 2013), se define por analogía a partir de la métrica M1 de la SC1.2 (Ver Tabla 1); (ii) la métrica Z7, considerando lo de (García et al., 2006), se definió a partir de la métrica G1; y la métrica Z8 se obtuvo de las métrica G4 (que incluye dos métricas parciales como se observa en la Sección 2.3; (iii) la métrica Z9, basado en (Rossi & Brinkkemper, 1996), se obtuvo de la métrica R4 de la Tabla 2. La métrica Z10 que representa la complejidad del proceso se obtienen de la sumatoria de las métricas anteriores y que está relacionada a con la M7 de la SC.1.3 (ver Tabla 1).

c. Complejidad de las dependencias. Dentro de esta complejidad se definió la métrica Z11 que se basó en lo definido en (García et al., 2006) como la métrica de número de dependencias descrito en la Tabla 3.

d. Complejidad cognitiva de la metodología. Para determinar la complejidad cognitiva de la metodología se usó el concepto espacio tridimensional del trabajo de (Rossi & Brinkkemper, 1996). Para dicho espacio se utilizó de base el Entregable, Proceso y Dependencias siendo las métricas respectivas: (i) C’(En), complejidad estructural del entregable; (ii) C’(P), complejidad total del proceso y (iii) ND(P), número de dependencias de los entregables con todas las actividades. En la Tabla 4 se presenta la fórmula establecida para la métrica Z12 que es la complejidad cognitiva de la metodología.

RESULTADOS

En esta sección se presenta los resultados de las mediciones de complejidad cognitiva a través de las métricas establecidas, ver Tabla 4, para la ISO/IEC 29110-5-1-2 y una implementación completa del PMBOK.

a. Complejidad Cognitiva en la Gestión de Proyectos de la ISO/IEC 29110-5-1-2. Se tomó como base la Sección 9 Descripción de Producto del documento de la ISO (ISO/IEC, 2011).

Las métricas de complejidad estructural del entregable obtenidas fueron. Z1 = 64, Z2 = 64, Z3 = 64, Z4 = 64, y a partir de ello se obtiene Z5 = 64 Estas métricas a través de una evaluación por parte de expertos temáticos y usuarios avanzados.

Las métricas de complejidad conceptual total por actividades y de proceso obtenidas se presentan en la Tabla 5, donde se calcula por cada actividad las métricas Z6, Z7, Z8 y Z9. Siendo Z9 obtenida en función a Z6, Z7 y Z8. El valor de Z10 se obtiene de la suma de los valores parciales de Z9, lo que da un total de Z10=78.7.

La métrica de dependencias por proceso, identificado como Z11, se calcula analizando entradas y salidas en la Figura 2, obteniendo el siguiente resultado: Z11=14 entradas +13 salidas = 27.

Finalmente, la complejidad cognitiva de la ISO/IEC 29110-5-1-2, se establece en Z12=104.97

b. Complejidad cognitiva de una implementación completa PMBOK. Se tomó como base una implementación desarrollada por una empresa consultora de dirección de proyectos en el sector de tecnologías de información. Por acuerdos de confidencialidad el nombre de la empresa se mantendrá en reserva. Considerando la manera en que trabaja la Consultora, se realizó el análisis por grupos de procesos del PMBOK.

Las métricas de complejidad estructural del entregable obtenidas fueron. Z1 = 90, Z2 = 90, Z3 = 90, Z4 = 89, y a partir de ello se obtiene Z5 = 89.75.

Las métricas de complejidad conceptual total por actividades y de proceso obtenidas se presentan en la Tabla 6, donde se calcula por cada actividad las métricas Z6, Z7, Z8 y Z9. El valor de Z10 se obtiene de la suma de los valores parciales de Z9, lo que da un total de Z10=420.9.

La métrica de dependencias por proceso, es decir Z11= 99, esta se obtiene del conteo realizado en el gráfico de interacciones entre procesos de la dirección de proyectos de la tercera sección página 53 del PMBOK.

Finalmente, la complejidad cognitiva del PMBOK, se determina según la métrica Z12 igual a 441.6.

Discusión y Trabajo Futuro

En este artículo se obtuvieron los resultados de un análisis de complejidad cognitiva, determinándose que el proceso de gestión de proyectos de la ISO/IEC 29110-5-1-2 obtuvo una complejidad cognitiva de 104.97 y para el caso de la implementación basada en el PMBOK se obtuvo una complejidad cognitiva de 441.6. Estos resultados evidencian que la ISO/IEC 29110-5-1-2 es menos compleja en comparación con la implementación completa basada PMBOK, e implica además que el esfuerzo de implementar un modelo basado en la ISO/IEC 29110-5-1-2 es menor que una implementación completa basada en el PMBOK.

De otro lado, para el caso de definir una metodología basada en PMBOK, se puede utilizar la complejidad cognitiva para evaluar su facilidad y esfuerzo de adopción en una organización.

Además, esta investigación propone métricas para medir la complejidad estructural de los entregables, traduciéndose como la complejidad cognitiva. Como trabajo futuro se propone realizar una medición de la complejidad cognitiva de los procesos de desarrollo de software de las pequeñas empresas en comparación con la ISO/IEC 12207. Asimismo resulta interesante contar con una herramienta de software para automatizar el cálculo de estas métricas de complejidad para la comparación de modelos.

NOTAS BIOGRÁFICAS

Agradecimientos

Este trabajo ha sido desarrollado gracias al apoyo brindado por el Departamento de Ingeniería de la Pontificia Universidad Católica del Perú, en el marco de la movilidad académica de la Red Peruana de Universidades.

Referencias

Arthur, J. D., & Stevens, K. T. (1989). Assessing the adequacy of documentation through document quality indicators. Conference on Software Maintenance, 40–49.

Cao, Q., Gu, V. C., & Thompson, M. A. (2012). Using complexity measures to evaluate software development projects: A nonparametric approach. Engineering Economist, 57(4), 274–283. https://doi.org/10.1080/0013791X.2012.729878

Erickson, J., & Siau, K. (2004). Theoretical and practical complexity of modeling methods. Communications of the ACM, 50(8), 46–51. https://doi.org/10.1145/1278201.1278205

Erickson, J., & Siau, K. (2005). Toward Practical Measures of Complexity in Real Time Modeling Methods. 11th Americas Conference on Information Systems, 3067–3074.

García, F., Piattini, M., Ruiz, F., Canfora, G., & Visaggio, C. A. (2006). FMESP: Framework for the modeling and evaluation of software processes. Journal of Systems Architecture, 52(11), 627–639. https://doi.org/10.1016/j.sysarc.2006.06.007

Göpferich, S. (2009). Comprehensibility assessment using the Karlsruhe Comprehensibility Concept. The Journal of Specialised Translation, (11), 12–38. Retrieved from http://www.jostrans.org/issue11/art_goepferich.pdf

ISO/IEC. (2011). ISO/IEC TR 29110-5-1-2:2011 Software Engineering -- Lifecycle Profiles for Very Small Entities (VSEs) -- Part 5-1-2: Management and Engineering Guide: Generic Profile Group: Basic Profile. Retrieved from https://www.iso.org/standard/51153.html

ISO/IEC. (2016). ISO/IEC TR 29110-1:2016 Systems and software engineering -- Lifecycle profiles for Very Small Entities (VSEs) -- Part 1: Overview. Retrieved from https://www.iso.org/standard/62711.html

Marin, M. A., Lotriet, H., & Van Der Poll, J. A. (2014). Measuring Method Complexity of the Case Management Modeling and Notation (CMMN). 209–216. https://doi.org/10.1145/2664591.2664608

Mas, A., & Mesquida, A. L. (2013). Software project management in small and very small entities | Gestión de proyectos de software en pequeñas y micro empresas. Iberian Conference on Information Systems and Technologies, CISTI, 406–412.

Merquida, A.-L., & Antonia, M. (2014). A project management improvement program according to ISO/IEC 29110 and PMBOK. Journal of Software: Evolution and Process. https://doi.org/10.1002/smr.1665

Mitani, Y., Matsumura, T., Barker, M., Tsuruho, S., Inoue, K., & Matsumoto, K. (2007). Proposal of a Complete Life Cycle In-Process Measurement Model Based on Evaluation of an In-Process Measurement Experiment Using a Standardized Requirement Definition Process. https://doi.org/10.1109/ESEM.2007.27

Oliveira, J. M. M. De, Oliveira, K. B. De, & Belchior, A. D. (2006). Measurement Process : A Mapping Among CMMI-SW , ISO / IEC 15939 , IEEE Std 1061 , Six Sigma and PSM. 15939(2002).

Perepletchikov, M., Ryan, C., & Tari, Z. (2013). An Analytical Framework for Evaluating Service-Oriented Software Development Methodologies. https://doi.org/10.4304/jsw.8.7.1642-1659

PMI. (2017). Guía de los Fundamentos para la Dirección de Proyectos.

Ram, P., Rodriguez, P., & Oivo, M. (2018). Software Process Measurement and Related Challenges in Agile Software Development : A Multiple Case Study.

Rossi, M., & Brinkkemper, S. (1996). Complexity metrics for systems development methods and techniques. Information Systems, 21(2), 209–227. https://doi.org/10.1016/0306-4379(96)00012-9

Slavek, N., Lukić, I., & Köhler, M. (2012). Software process measuring model [Model mjerenja softverskog procesa]. Tehnicki Vjesnik, 19(1), 11–17. Retrieved from http://www.scopus.com/inward/record.url?eid=2-s2.0-84859181540&partnerID=40&md5=870159bb67251643fecf0dab02b9beb5

Zhang, H., Kishore, R., Sharman, R., & Ramesh, R. (2007). Agile Integration Modeling Language (AIML): A conceptual modeling grammar for agile integrative business information systems. Decision Support Systems, 44(1), 266–284. https://doi.org/10.1016/j.dss.2007.04.009