Introducción a SPEM

¿Alguna vez ha intentado documentar un proceso de desarrollo de software? ¿Por dónde se comienza? ¿Hay algún estándar o recomendación en la industria? Para cualquiera que haya realizado estas tareas, se dará cuenta que no es fácil y en general uno termina usando los recursos disponibles sin mucha guía: procesadores de texto, herramientas de ayuda en línea, wikis, diagramadores de procesos, etc. La documentación de los procesos de desarrollo de software no es sencilla: ¿cómo documentar adecuadamente un proceso de desarrollo de software con el objetivo que sea entendido claramente por un equipo y la documentación sirva como un apoyo en la implementación y seguimiento del proceso descrito?

A lo largo de los años diversos autores y organizaciones han tratado de definir y comunicar procesos de desarrollo: desde Royce con el Modelo en Cascada de 1970 hasta los métodos ágiles más recientes. Probablemente la propuesta más estructurada, y que con su publicación en 1998, mostró el nivel de detalle que se puede lograr con la descripción de un proceso de desarrollo fue el “Proceso Unificado” (Unified Process).

Este trabajo inició años antes, en 1987 cuando Ivar Jacobson en Suecia creó Objectory y fue adoptado por Ericsson, después Objectory AB fue adquirida por Rational Software Corporation en 1995 (Ambler, 2005). En 1996, se integra el “Rational Approach” con “Objectory Process v.3.8” para crear el “Rational Objectory Process 4.0” y que posteriormente se convertiría en 1998 en RUP 5.0 (Kruchten, 2000). De su documentación destacan el nivel de detalle que tiene y la integración de sus elementos: artefactos, roles, tareas, fases, etc. Esto permitió que se entendiera fácilmente como un producto y tuvo gran aceptación junto con UML. Sin embargo, muchas veces se omite un aspecto valioso del Proceso Unificado: cuenta con un modelo general y con un framework que permite su extensibilidad y soporte por medio de herramientas. Este modelo se basa en conceptos básicos que permiten la definición de procesos más complejos y detallados:

• Roles: Es un conjunto de habilidades, competencias y responsabilidades (el “quién”).
• Tareas y Actividades: Describe una unidad de trabajo que se asigna a un rol para lograr un resultado significativo (el “cómo”).
• Productos de Trabajo (artefactos): Es un resultado significativo de un proceso (el “qué”).
• Procesos: Definen las estructuras de trabajo secuenciales que deben realizarse para desarrollar un sistema, normalmente compuestos por diversos flujos de trabajo y fases (el “cuándo”).

Los conceptos clave que organizan el marco de trabajo son:

• Contenido Metodológico. Es la información en el proceso, la propiedad intelectual de “cómo” realizar ciertas tareas y productos. La explicación detallada de cómo lograr metas específicas, independientemente de su colocación en un proceso.
• Guías. Es un concepto que engloba todas las formas de contenido cuyo propósito principal es proveer explicaciones adicionales e ilustraciones de apoyo: plantillas, herramientas, listas de verificación (checklists), etc.
• Método o Metodología. Es la combinación de un proceso y contenido metodológico (la forma en que los combinamos nos define el enfoque particular para desarrollar un proyecto).

El framework original del Proceso Unificado evolucionó al “Method Framework” que forma la base del “Software & Systems Process Engineering Meta-Model Specification” (SPEM) v.2.0 [3]. SPEM es un “meta-modelo” y un perfil de UML 2.0, que se usa para definir procesos de desarrollo de software y sistemas junto con sus componentes. Es decir, es un esquema estandarizado de describir procesos de desarrollo administrado por el OMG.

Al enfrentar este tipo de proyectos de ingeniería de software, vale la pena revisar SPEM como un marco teórico y las herramientas que lo soportan. Ver Figura 1.

Figura 1. Method Framework.

Referencias

1. Ambler, S. (2005). History of the Unified Process. Obtenido de Enterprise Unified Process: http://www.enterpriseunifiedprocess.com/essays/history.html
2. Kruchten, P. (2000). The Rational Unified Process, An Introduction. Addison-Wesley Professional.
3. Object Management Group. (2008). Software & Systems Process Engineering Meta-Model Specification Version 2.0. MA: Object Management Group.