Caso de éxito: MDE en Procesos

Realizado con dos empresas participantes en SoftAragón a través del Cheque Tecnológico ARAID

Las pequeñas y medianas empresas son claves en la economía global, y la industria del software no es una excepción, siendo este tipo de empresas un amplio porcentaje de la totalidad. Estas organizaciones, al igual que las grandes empresas, necesitan establecer unas prácticas de ingeniería del software, si bien es necesario adaptarlas a su especial configuración.

Desde comienzos de los años 90, la comunidad de la Ingeniería del Software ha expresado un interés especial en el ámbito de la Mejora de Procesos Software (MPS), evidenciado por el gran número de iniciativas relacionadas con MPS, tales como CMM, CMMI, ISO 15504, ISO 12207 e ISO 9000, por citar algunas.

En los últimos años, desde las administraciones públicas se ha favorecido la adopción de este tipo de estándares por parte de las empresas de software, a través de distintos canales de subvención y financiación. Esto ha motivado que modelos como CMMI, anteriormente casi desconocidos por la industria o relegados a grandes organizaciones, sean utilizados como referencia para la definición y mejora de procesos de software.

Todas estas iniciativas vienen fundamentadas en la premisa de que la calidad del producto desarrollado viene determinada por la calidad de los procesos utilizados durante su implementación, algo que está ampliamente extendido en la industria manufacturera y conocido como Calidad Total. De alguna manera lo que se persigue es industrializar las prácticas de las empresas de forma que los éxitos sean cada vez más repetibles y conocer las causas de los fracasos.

Al trabajar en este ámbito, lo que se produce es la incorporación del término proceso de software en las organizaciones. Una buena definición de proceso de software establece el mismo como “el conjunto de pasos parcialmente ordenado, con el conjunto de artefactos, recursos humanos y informáticos, estructuras organizacionales y restricciones, cuyo objetivo es producir y mantener los productos de software requeridos”. Esta definición resalta la complejidad y el número de factores que influyen en el desarrollo de software, debido a que no todo se puede automatizar, y existen muchos aspectos que dependen de la comunicación, coordinación y cooperación entre personas dentro de las organizaciones.

Por lo tanto, uno objetivo difícil para una empresa de software consiste en encontrar la forma de describir y gestionar las actividades, recursos y restricciones de sus propios procesos, teniendo en cuenta todas estas características. Una vez documentados, los procesos de software se convierten en importantes activos de la organización.

Una vez que se detecta la necesidad de describir los procesos, la tendencia habitual por su facilidad es hacerlo en lenguaje natural. Sin embargo, esta opción no está carente de múltiples inconvenientes asociados. La comprensión y la formación son dos de los aspectos más relevantes en este caso. En el primer caso, algo escrito en un lenguaje natural puede no reflejar todos los entresijos propios de lo que pretende describir, perdiéndose, por tanto, partes de su significado. Esto es algo que no ocurre con un lenguaje formal, y es la causa por la que se establece una diferenciación entre los mismos. En el segundo caso, la capacidad de formar, y posteriormente desplegar y asegurar el seguimiento de los procesos definidos disminuye en la medida en la que su comprensión no es completa. Si bien los propios modelos de referencia de procesos disponen de mecanismos para disminuir estos efectos colaterales, no son del todo óptimos.

Una de las formas de atajar estos problemas es la utilización de un lenguaje de modelado para la descripción de procesos software. Con lo que se facilita enormemente las cuestiones anteriormente descritas.

Objetivos planteados

Las organizaciones habían iniciado su recorrido en la mejora de procesos software hace ya varios años. Durante este tiempo habían alcanzado distintas certificaciones, destacando los niveles 2 y 3 del modelo CMMI.

En este nivel el número de procesos abordados por la organización es bastante amplio, puesto que tienen que establecer y mantener todos aquellos procesos que recojan las prácticas exigidas por las áreas de proceso de niveles 2 y 3 dentro del modelo CMMI. Una vez alcanzado estos niveles de madurez, el objetivo fundamental de las empresas consistía en mantenerlos, para que todo el esfuerzo invertido no se evaporara con el tiempo.

Una de las cuestiones que se ha observado después de la tensión hasta la certificación ha sido una relajación en las obligaciones tanto a nivel de usuario de procesos como a nivel de aseguramiento de los mismos, con el riesgo que supone de pérdida de conocimiento después del logro alcanzado.

También se ha evidenciado que una de las causas de este seguimiento atenuado de los procesos se basa en la cantidad de información que es necesario gestionar, puesto que el número de procesos a los que se ha llegado es lo suficientemente amplio, y las relaciones entre los mismos también añaden complejidad al asunto. Corría el riesgo que todo el trabajo realizado se convirtiera en un típico manual de calidad olvidado en la biblioteca de activos de la organización.

Para evitarlo se puso en marcha este proyecto, cuyo principal objetivo era modelar los procesos de software de la organización, realizando a su vez un análisis estructural de los mismos y detectando inconsistencias. Además, se pretende disponer de acceso a estos procesos de una manera más ágil que la proporcionada por un conjunto de documentos textuales.

Enfoque del trabajo realizado

Una vez que hemos expuesto la necesidad de modelar los procesos de software, para lo cual es necesario disponer de un lenguaje de modelado. En el dominio de la ingeniería del software y en el momento en el que se realizó este proyecto, existían dos lenguajes principalmente, la ISO/IEC 24744:2007 y SPEM 2.0.

ISO/IEC 24744:2007, Software Engineering Meta-model for Development Methodologies, es un estándar internacional que define un meta-modelo para el desarrollo de metodologías. Está centrado en el desarrollo de software pero puede ser aplicado en metodologías de otros dominios. SPEM 2.0, Software & System Process Engineering Meta-Model, es una especificación OMG (Object Management Group), que proporciona un lenguaje para el desarrollo de metodologías.

La idea central subyacente en ambos lenguajes consiste en decir quién (rol) realiza qué (tarea) para, a partir de unas entradas (productos de trabajo) obtener unas salidas (productos de trabajo). Los dos persiguen el mismo objetivo, por lo que proporcionan los conceptos necesarios para modelar, documentar, presentar, gestionar, intercambiar procesos y métodos de desarrollo, si bien es cierto que existen una serie de diferencias que nos han hecho decantarnos por uno de ellos por delante del otro.

Algo que hemos observado es que SPEM 2.0 es bastante más amplio y estructuralmente más complejo que ISO 24744, albergando mayor número de elementos. Una de las causas podría ser que SPEM 2.0 cumple las condiciones para ser un Profile UML 2.0, y poder hacer así uso de las capacidades que esto proporciona en cuanto al soporte de herramientas. Otra causa podría ser el hecho de que se trata de un estándar más industrial, favorecido y alentado por las principales empresas de herramientas de desarrollo, con lo que atiende a múltiples intereses comerciales, mientras que ISO 24744 ha sido desarrollado en un ambiente más académico. Esto hace que SPEM 2.0 sea ya soportado por varias herramientas, tanto libres como comerciales, algo que no podemos decir de ISO 24744, que no dispone de una herramienta que lo soporte, al menos hasta el inicio de este proyecto, por lo que la utilización de SPEM 2.0 está mucho más extendida y consolidada en el ámbito de la Ingeniería del Software.

Esta última razón ha sido determinante en la elección del metamodelo SPEM 2.0, y la adopción de la aplicación EPFC (Eclipse Process Framework Composer) para el modelado de los procesos. Se trata de una herramienta extensible para la creación, configuración y publicación de procesos, sujeta a la licencia Eclipse, y que ha sido utilizada por el Instituto Tecnológico de Aragón en proyectos anteriores.

Implementación

Una de las principales características de SPEM 2.0 es la propuesta de una clara separación entre los contenidos de método y su posible uso dentro de un proceso específico. En el ámbito de la ingeniería del software, como en el caso de otras ingenierías, se dispone en la literatura de estándares de desarrollo, buenas prácticas, métodos, guías, etc., de las que cualquier organización puede hacer uso para definir sus procesos de desarrollo. SPEM 2.0 ofrece la capacidad de utilizar todos estos elementos e introducirlos de forma estandarizada a modo de biblioteca, lo que se conoce como contenidos de método. También se incluyen en esta categoría todos los esfuerzos realizados y documentados por la organización en la estandarización, guías desarrolladas de forma específica, etc. Toda esta información se caracteriza por no disponer de una componente temporal, es decir, es independiente del momento en el que la empresa ha establecido que va a hacer uso de ello. Es el concepto de Proceso de SPEM 2.0 el que recoge esta componente temporal, incorporando el ciclo de vida de desarrollo como un elemento fundamental para el desarrollo de metodologías.

Es posible que la denominación dentro del propio estándar resulte algo confusa puesto que denomina contenido de método a lo que habitualmente denominamos proceso, y llama proceso a lo que en nuestro lenguaje sería metodología.

El trabajo ha consistido fundamentalmente en extraer de la documentación recogida en la librería de activos de las organizaciones, la información para poder ser representada de acuerdo con el lenguaje establecido, fundamentalmente en lo que se refiere a tareas, roles, productos de trabajo y guías. Esto nos ha permitido detectar las inconsistencias y fallos estructurales existentes en los mismos, a pesar de haber pasado con éxito el proceso de certificación. Durante esta transformación hemos mantenido como categorías las áreas de proceso de CMMI para facilitar su elaboración.

También se ha detectado la falta de adopción del concepto de ciclo de vida de la metodología, algo derivado de la utilización de un modelo de buenas prácticas como única referencia para la definición de una metodología. Se ha puesto mucho hincapié en la definición e institucionalización de acuerdo con los requisitos establecidos por el modelo CMMI, pero no queda claramente definido el ciclo de vida que se va a seguir, como parte fundamental de la metodología de las organizaciones. CMMI habla del ciclo de vida, pero no le otorga la importancia que realmente debería tener en una organización de software.

Esto es algo que hemos trabajado, incorporando un concepto que existe en SPEM 2.0, que es el de fase, a los procesos de las organizaciones. Con ello conseguimos que, a partir de las tareas desglosadas en la descripción previa, configurar patrones de capacidad, como un conjunto de tareas que siempre se presentan unidas, y a partir de ahí incorporar estos patrones en el lugar más adecuado dentro de las fases del ciclo de vida de la metodología. Hemos adoptado la misma denominación de fases utilizada en RUP (Proceso Unificado de Desarrollo): inicio, elaboración, implementación y transición.

Conclusiones y Trabajos Futuros

A continuación se van a detallar las principales conclusiones del trabajo realizado.

Por un lado, cabe destacar el importante esfuerzo en la transformación de todos los procesos definidos dentro de la empresa en elementos de SPEM 2.0, lo que ha permitido detectar errores dentro de la estructura previa. Si bien es cierto que abordarlo a posteriori de la certificación de CMMI nos ha producido una cierta sensación de re-trabajo, también es cierto que todo lo que ya se había conseguido ha permitido que los conceptos y las asociaciones hayan sido más claras, facilitando parte de la tarea.

Como resultado tangible del proyecto se dispone de una metodología, puesta en marcha, y, aunque como toda metodología se trata de algo vivo que será necesario ir ajustando en función de las evoluciones de la empresa, incorporando información y documentación cuando sea necesario, la infraestructura ya ha quedado establecida, con lo que el núcleo del trabajo ya se ha hecho.

Otro de los aspectos a destacar es la falta de importancia del ciclo de vida cuando tratamos los procesos de desarrollo desde un punto de vista teórico, únicamente para cumplir los requisitos establecidos por el modelo CMMI. Esto es algo de lo que adolecen todas las empresas que comienzan su trabajo en procesos de la misma forma. Desde aquí nos gustaría destacar este hecho para que sea tenido en cuenta por las nuevas organizaciones que comiencen en la definición de sus procesos, trabajando también el aspecto de metodología de los mismos.

Por último, si que nos gustaría destacar que, aunque SPEM 2.0 ha sido el lenguaje utilizado por ser un estándar, resulta muy complejo y extremadamente arduo de gestionar debido a la gran cantidad de conceptos que alberga. Esto hace que su adopción por parte de las empresas sea bastante pequeña, a pesar incluso de disponer de una herramienta de soporte como puede ser EPFC. Tampoco esta herramienta es trivial y la curva de aprendizaje es lo suficientemente elevada como para que pequeñas organizaciones se planteen su uso. Sería, pues, importante plantear una considerable simplificación del lenguaje para facilitar su uso, siempre y cuando fuera acompañada de algún tipo de herramienta de soporte. Esto se plantea como un posible trabajo futuro.