SPEM: Software Process Engineering Metamodel
Vctor Hugo Menndez Domnguez y Mara Enriqueta Castellanos Bolaos
Facultad de Matemticas
Universidad Autnoma de Yucatn
Mrida, Mxico
{mdoming, enriqueta.c}@uady.mx
ResumenTodas las organizaciones involucradas en el
desarrollo de software necesitan establecer, gestionar y soportar
el trabajo de desarrollo. El trmino proceso de desarrollo de
software tiende a unificar todas las actividades y prcticas que
cubren esas necesidades. Modelar el proceso de software es una
forma para mejorar el desarrollo y la calidad de las aplicaciones
resultantes. De entre todos los lenguajes existentes para el
modelado de procesos, aquellos basados en productos de trabajo
son los ms adecuados. Uno de tales lenguajes es SPEM
(Software Process Engineering Metamodel). SPEM fue creado
por OMG (Object Management Group) como un estndar de alto
nivel, que est basado en MOF (MetaObject Facility) y es un
metamodelo UML (Uniform Model Language). Constituye un
tipo de ontologa de procesos de desarrollo de software. En este
artculo se ofrece una descripcin, en trminos generales, del
estndar SPEM. Tambin se destacan los cambios que ha
experimentado entre la versin 1.1 y la versin 2.0, presentando
tanto las ventajas como las desventajas encontradas entre ambas
versiones.
Palabras ClaveProceso de desarrollo de software, SPEM,
MOF, UML.
I. INTRODUCCIN
Esta seccin describe qu es un proceso de software y su
relacin con el estndar SPEM, tambin presenta la relacin de
SPEM con otros estndares definidos por OMG como UML,
MOF y XMI.
A. Procesos de Software y SPEM
Todas las organizaciones involucradas en el desarrollo de
software necesitan establecer, gestionar y soportar el trabajo de
desarrollo. El trmino proceso de desarrollo de software
tiende a unificar todas las actividades y prcticas que cubren
esas necesidades [10].
El principal objetivo de tal proceso es garantizar la
construccin de un software adecuado, conforme a sus
especificaciones y dentro de los lmites de tiempo y costo [2].
Sin embargo, es un proceso complejo conformado de mltiples
actividades que son interdependientes, incluyendo el desarrollo
tcnico, la gestin de proyectos, el control de calidad y las
actividades de soporte del cliente [17].
Modelar el proceso de software es una forma para mejorar
el desarrollo y la calidad de las aplicaciones resultantes [2]. La
Ingeniera de Procesos de Software (SPE, Software Process
Engineering) consiste en modelar, disear, mejorar y aplicar
procesos utilizando lenguajes de modelado de procesos (PML,
Process Modelling Language) [10]. De todos los lenguajes para
el modelado de procesos existentes, aquellos basados en
productos de trabajo son los ms adecuados para modelar los
procesos de desarrollo de software [11].
Uno de tales lenguajes es SPEM (Software Process
Engineering Metamodel) [12], una especificacin de OMG
(Object Management Group) que est basado en MOF
(MetaObject Facility) y es un metamodelo UML (Uniform
92 Menndez Domnguez, V., Castellanos Bolaos, M. 2015. SPEM: Software Process Engineering Metamodel
Revista Latinoamericana de Ingeniera de Software, 3(2): 92-100, ISSN 2314-2642
Model Language). Al ser SPEM un metamodelo UML, utiliza
su notacin, lo que permite visualizar, especificar, construir y
documentar sistemas orientados a objetos [5].
SPEM permite representar una familia de procesos de
desarrollo de software y sus componentes. Constituye un tipo
de ontologa de procesos de desarrollo de software [18]. Para
ello provee un conjunto de elementos de modelado de procesos
para describir cualquier proceso de desarrollo de software sin
agregar modelos o restricciones de alguna rea o disciplina
especfica, tal como gestin de proyectos o anlisis.
SPEM proporciona una sintaxis y estructura para cada
aspecto de los procesos desarrollo, incluyendo:
Roles.
Tareas.
Artefactos.
Lista de verificacin
Productos de trabajo.
Tcnicas y herramientas.
Estructuras de trabajo.
Capacidad de rastreo y refinamiento.
Ayuda sensible al contexto, gua y lineamientos.
Descripcin textual de elementos.
B. MOF, SPEM y XMI
Mientras que el propsito de SPEM es convertirse en el
lenguaje estndar para el modelado de procesos de software,
MOF pretende ser el lenguaje universal de metamodelos, capaz
de describir lenguajes tales como el mismo SPEM, UML,
modelos relacionales, etc. MOF constituye una parte de la
arquitectura estandarizada de cuatro niveles, propuesta por
OMG, convencionalmente denominados M0 - M3 [6].
Un proceso de desarrollo esto es un proceso de
produccin del mundo real como se indica en la Figura 1, es
el nivel M0. La definicin del proceso correspondiente
(Modelo) est en el nivel M1, por ejemplo cualquier proceso
genrico como el RUP o XP, u otras especificaciones
adaptadas a un proyecto dado. Sin embargo, SPEM se enfoca
en el metamodelo que se ubica en el nivel M2 y sirve como
plantilla para el nivel M1. Con el fin de evitar un nmero
infinito de niveles, OMG estableci hacer a M3 reflexivo. La
consecuencia es que MOF debe ser capaz de describirse a si
mismo [6].
XMI (XML Metadata Interchange) es la tecnologa
adoptada por la OMG para intercambiar modelos en forma
serializada. XMI especifica cmo crear esquemas XML de
modelos y se enfoca en el intercambio de metadatos de MOF,
metadatos acorde a un metamodelo MOF [9].
XMI puede ser usado para manipular el metamodelo de
SPEM de las siguientes formas [12]:
Para crear definicin de tipos de documentos SPEM.
Para transferir modelos de procesos basados en SPEM
como documentos XML, o describiendo el modelo como
una instancia directa de SPEM (Uso del DTD SPEM) o
 describiendo ste como un modelo de UML conforme al
perfil UML para SPEM (Uso del DTD UML).
Transformar el metamodelo de SPEM en un documento
XML basado en el DTD MOF, para intercambio entre los
repositorios conformes a MOF.
Fig. 1. Arquitectura estandarizada propuesta por OMG.
II. ESTADO DEL ARTE
En esta seccin se describe, en trminos generales, el
estndar SPEM, tambin se presentan los cambios que han
surgido entre la versin 1.1 y la versin 2.0.
A. Software Process Engineering Metamodel, SPEM
SPEM fue creado por OMG como un estndar de alto nivel
para describir procesos utilizados en el desarrollo de software
orientado a objetos. Inicialmente fue creado como un
metamodelo independiente pero ms tarde fue reformulado
para ser un perfil (profile) UML. Esto significa que se
ajustaron los conceptos orientados a procesos para representar
conceptos orientados al modelado [8].
En la base de SPEM est la idea de que un proceso de
desarrollo de software es una colaboracin entre las entidades
activas abstractas llamadas Roles del proceso que realizan
operaciones llamadas actividades en entidades concretas,
tangibles llamadas productos de trabajo.
La Figura 2 describe un ejemplo del modelo conceptual
fundamental usando la notacin UML para una clase [9].
Fig. 4. Taxonoma de la actividad [12].
Menndez Domnguez, V., Castellanos Bolaos, M. 2015. SPEM: Software Process Engineering Metamodel
Revista Latinoamericana de Ingeniera de Software, 3(2): 92-100, ISSN 2314-2642
Fig. 2. Modelo conceptual SPEM.
Mltiples roles interactan o colaboran para intercambiar
productos de trabajo y provocar la ejecucin, o representacin
de ciertas actividades. El objetivo principal de un proceso es
traer unos productos de trabajo a un estado bien definido [10].
Para esto, un primer paso consistir en reestructurar el rol, la
actividad y el producto de trabajo. Esto nos conduce al modelo
simple mostrado en la Figura 3.
Fig. 3. Relacin de los elementos fundamentales de SPEM 1.1 [12].
Las actividades utilizan productos de trabajo con el
propsito de crear nuevos productos de trabajo. El trabajo es
realizado usualmente por personas que juegan roles. Ellos
realizan las actividades y son responsables de mantener
directamente el conjunto de productos de trabajo [8].
La mayor unidad de trabajo es una actividad (Figura 4), la
cual consta de un nmero de pasos. Estas clases describen el
trabajo que se necesita realizar. El realizador de esta unidad de
trabajo es el ProcessRole, el cual es un tipo de realizador de
procesos, los cuales consisten en un conjunto de
WorkDefinition. La gente interpreta roles para crear
WorkProduct los cuales estn asociados a WorkDefinition (y a
actividades). Las definiciones de trabajo tienen precondiciones
y poscondiciones (llamadas metas) como limitaciones.
93
 Un proceso se puede ver como una colaboracin entre roles
para alcanzar cierta meta u objetivo. Para dirigir su
representacin, podemos restringir la orden en la cual las
actividades deben ser, o pueden ser ejecutadas. Tambin es
necesario definir la "forma" del proceso en un determinado
tiempo, y la estructura del ciclo de vida en trminos de fases y
de iteraciones (Figura 5) [10]:
Phase (Fase): es una especializacin de WorkDefinition
tal que su condicin previa define los criterios de entrada
de la fase y su meta (a menudo llamada milestone) define
los criterios de la salida de la fase. Las fases son definidas
con una restriccin adicional de secuencialidad, que sus
representaciones sean ejecutadas con una serie de fechas
de tiempos de programacin (milestone) que
normalmente toman un mnimo (o ningn) traslape de sus
actividades en el tiempo.
Lifecycle (Ciclo de vida): El ciclo de vida de un proceso
es definido como una secuencia de fases que alcanzan una
meta especfica. Este define el comportamiento de un
proceso completo que ser representado en un proyecto o
un programa dado.
Iteration (Iteracin): Una Iteracin es un componente
WorkDefinition que se caracteriza por tener el menor
milestone.
SPEM tambin define elementos que son importantes para
organizar otros elementos del proceso desde el punto de vista
de la creacin, ensamble y uso (Tabla I). Los paquetes estn
relacionados a la divisin de una o ms descripciones de
procesos en una parte autocontenida. Estos subelementos,
denominados componentes de proceso, son porciones
autocontenidas e internamente consistentes que pueden ser
reutilizados con otros componentes de proceso para ensamblar
un proceso completo. Pueden importar un conjunto no
arbitrario de elementos de definicin de procesos [10].
Los principales elementos de SPEM son los siguientes [12]:
WorkProduct (Producto de Trabajo): es cualquier
elemento producido, consumido, o modificado por un
proceso. Esto puede ser una pieza de informacin, un
documento, un modelo, cdigo fuente y dems. Un
WorkProduct describe una clase de producto de trabajo
producido en un proceso.
Fig. 5. Taxonoma del ciclo de vida [12].
94 Menndez Domnguez, V., Castellanos Bolaos, M. 2015. SPEM: Software Process Engineering Metamodel
Revista Latinoamericana de Ingeniera de Software, 3(2): 92-100, ISSN 2314-2642
WorkDefinition (Definicin de trabajo): es un tipo de
operacin que describe el trabajo que se ejecuta en un
proceso. Este trabajo puede ser Activity, Phase, Iteration
y LifeCycle.
Activity (Actividad): es la principal subclase de
WorkDefinition. Esta describe una parte del trabajo
desarrollado por un ProcessRole: las tareas, operaciones y
acciones que son desempeadas por un rol o las que el rol
puede asistir. Una Actividad se puede componer de
elementos atmicos llamados pasos.
ProcessPerformer (Ejecutor de Proceso): define la
ejecucin para un conjunto de definiciones de trabajo en
un proceso. ProcessPerformer es una representacin
abstracta del representante del proceso completo o uno de
sus componentes.
ProcessRol (Rol de Proceso): define responsabilidades
sobre productos de trabajo especficos y define los roles
que ejecutan y asisten en actividades especficas.
ProcessPackage (Paquete de Procesos): al igual que en
UML, puede contener procesos propios e importar
elementos de definicin de procesos. Las actividades y
definiciones de trabajo son contenidos respectivamente,
por Roles de proceso y Ejecutores de proceso; Las
mquinas de estado son contenidas por Productos de
trabajo y sus propios estados y transiciones. Los grafos de
actividad pueden ser contenidos por Paquetes,
Clasificadores o caractersticas de comportamiento; Otros
elementos de SPEM pueden ser contenidos por Paquetes.
Guidance (Gua): pueden ser asociados con los elementos
de SPEM, para proporcionar informacin ms detallada a
los ejecutores acerca de los elementos asociados. Los
tipos de gua dependen de la familia de procesos y pueden
ser por ejemplo: Guas, Tcnicas, Mtricas, Ejemplos,
Perfiles UML, Tutoriales, Listas de comprobacin,
Plantillas, etctera.
ProcessComponent (Componente de Proceso): es una
porcin de descripcin de proceso que es consistente
internamente y puede ser reutilizado por otros
ProcessComponent para ensamblar un proceso completo.
 Process (Proceso): es un ProcessComponent que es capaz
de mantenerse aislado de principio a fin. El proceso se
distingue de un componente de proceso normal porque no
est pensado para ser accedido por otros componentes.
Discipline (Disciplina): es una especializacin particular
de Package que divide las actividades dentro de un
proceso de acuerdo a un tema comn. El particionamiento
de actividades de esta forma implica que la gua asociada
(Guidance) y la salida de WorkProduct se categoriza
similarmente en un tema. La inclusin de una actividad en
una Disciplina es representada por la dependencia de
Categoras, con una restriccin adicional de que toda
Actividad es categorizada por exactamente una
Disciplina.
TABLA I. ESTEREOTIPOS GRFICOS DE LOS ELEMENTOS SPEM
Elemento Estereotipo UML
Activity
Document
Guide
Process
Phase
Process Package
Rol
WorkProduct
WorkDefinition
Model
Los diagramas UML pueden ser utilizados para presentar
diferentes perspectivas de un modelo de procesos de software,
siendo las ms tiles:
Fig. 6. Diagrama de caso de uso [12].
Menndez Domnguez, V., Castellanos Bolaos, M. 2015. SPEM: Software Process Engineering Metamodel
Revista Latinoamericana de Ingeniera de Software, 3(2): 92-100, ISSN 2314-2642
Diagramas de clase que permiten la representacin de los
siguientes aspectos de un proceso de software: herencia,
dependencia, asociaciones, Comentarios y guas.
Diagramas de paquete, que permiten la representacin de
procesos, componentes, paquetes y disciplinas. Las
anidaciones son permitidas.
Diagramas de caso de uso, que muestra las relaciones
entre los roles del proceso y las definiciones del trabajo
principal (Figura 6).
Diagramas de secuencia, que ilustran los patrones de
interaccin entre las instancias del modelo SPEM.
Diagramas de estado, que presentan el funcionamiento de
los elementos del modelo SPEM. Se permite la anidacin
y el paralelismo pero no indicadores de historial.
Diagramas de actividad, que describen la secuencia de
actividades con sus productos de entrada y de salida, as
como los estados de flujo (Figura 7).
Algunos diagramas y notaciones utilizados por UML han
sido excluidos de SPEM y no tienen ningn significado.
B. Diferencias entre SPEM 1.1 y 2.0
A pesar de ser liberada desde 2002 y tener una revisin en
el 2005 (SPEM 1.1), son pocas las implementaciones de SPEM
1.x en herramientas comerciales, y las que existen lo soportan
de forma parcial. La causa de esta situacin parece ser lo difcil
que result su implementacin, adems que algunos elementos
de la semntica son ambiguos [13]. La industria apenas est
reconociendo la importancia de SPEM en el mercado de las
herramientas metodolgicas y tcnicas.
La revisin de SPEM, pretende resolver esta situacin.
SPEM 2.0 es definido como un metamodelo as como un perfil
de UML 2. SPEM 2.0 utiliza el mecanismo ofrecido por la
infraestructura de UML para mezclar paquetes que
gradualmente construyen el metamodelo. Proporciona unidades
modulares que pueden ser usados como bloques de
construccin para una especificacin [13].
95
 Fig. 7. Diagrama de actividades [12].
SPEM 2.0 est estructurado en siete paquetes de
metamodelos principales. La estructura divide el modelo en
unidades lgicas. Cada unidad extiende la unidad de la que
depende, proporcionando estructuras y capacidades adicionales
a los elementos definidos [13]:
1) Core: contiene las clases y abstracciones del metamodelo
que constituyen la base para crear todas las clases de los
dems paquetes.
2) Process Structure: Establece la base para todos los
modelos de proceso y soporta la creacin de estos en una
forma fcil y flexible (Figura 8).
3) Process Behavior: Representa un proceso como una
estructura esttica, permitiendo anidar actividades y
definir dependencias entre ellos.
4) Managed Content: Establece conceptos para la gestin
de descripciones y contenido textual que apoyen a los
conceptos de un proceso.
5) Method Content: Permite la construccin de una base de
conocimientos del desarrollo definiendo conceptos del
ciclo de vida y mtodos, tcnicas y las mejores prcticas.
6) Process with Methods: Define estructuras para integrar
procesos definidos con Process Structure con conceptos
de Method Content.
7) Method Plugin: Introduce conceptos para disear y
gestionar repositorios de procesos reutilizables.
Las principales caractersticas y mejoras de SPEM 2.0 con
respecto a sus versiones previas son [13]:
96 Menndez Domnguez, V., Castellanos Bolaos, M. 2015. SPEM: Software Process Engineering Metamodel
Revista Latinoamericana de Ingeniera de Software, 3(2): 92-100, ISSN 2314-2642
Al basarse en UML 2.0 toma ventaja de su nueva
funcionalidad en la mejora de las tcnicas y capacidades
del modelado de procesos.
Define un nuevo esquema XML SPEM, basado en MOF
2.0. Los esquemas XML proporcionan una mayor riqueza
y control que en el DTD de XMI SPEM 1.1.
Proporciona una gua para la migracin de modelos de
procesos de SPEM 1.1 a SPEM 2.0.
Considera la retroalimentacin de las primeras
implementaciones para identificar inconsistencias
relacionadas la funcionalidad y practicidad de SPEM 1.1.
Define extensiones para que SPEM utilice herramientas
de automatizacin de procesos.
Establece una relacin ms estrecha con otros estndares
adicionales a UML como Business Process Definition
Meta-model y Business Process Runtime Interfaces.
Define extensiones al metamodelo de procesos que
pueden ser usados tanto en los procesos de desarrollo de
software como en los procesos de ingeniera de sistemas.
La Figura 9 presenta un diagrama de clases en SPEM 2.0,
muestra que la tarea "Use Case Analysis" tiene entradas y
salidas que son obligatorias y opcionales y que son
desempeadas por dos roles: "Designer", que es el rol principal
y "System Analyst", que es opcional. Los estereotipos pueden
tener representaciones grficas y textuales. Para mantener
compatibilidad con SPEM 1.1, la mayora de los estereotipos
tienen su contraparte (Figura 10), sin embargo, dado que
SPEM 2.0 introduce nuevos conceptos, no todos tienen su
equivalente en SPEM 1.1 (Tabla II).
 Fig. 8. Taxonoma del paquete Process Structure [13].

Fig. 9. Diagrama de clases UML 2 usando el perfil SPEM 2.0 [13].

Fig. 10. El mismo diagrama de clases pero en SPEM 1.1 [13].

Menndez Domnguez, V., Castellanos Bolaos, M. 2015. SPEM: Software Process Engineering Metamodel 97
Revista Latinoamericana de Ingeniera de Software, 3(2): 92-100, ISSN 2314-2642
 Es importante indicar que la Figura 10 no resulta vlida
para SPEM 1.1, debido a que las definiciones de trabajo
(WorkDefinition) tienen que ser modeladas como operaciones
de los roles. En cambio, en SPEM 2.0, las tareas y actividades
son representadas con el estereotipo Actividad.
Para clarificar ms la definicin de procesos, SPEM 2.0
utiliza diagramas de clases, de actividades y de estado (Figura
11).
TABLA II. COMPARATIVA ENTRE LOS PERFILES SPEM 1.1 Y SPEM 2.0
Estereotipo SPEM 1.1 SPEM 2.0
Activity
Category
Guidance
ProcessComponent
Rol
Step
Como resultado de las nuevas capacidades para la creacin
y gestin de procesos, las principales partes de la
especificacin estn implementadas, por ejemplo en Eclipse
Process Framework. Numerosas organizaciones y compaas
han anunciado que modelarn sus procesos con esta tecnologa
(Armstrong Process Group, Open Group, Number Six
Software, y Telelogic). Y otras compaas (como IBM, DSDM
Consortium) han desarrollado productos comerciales.
III. LECCIONES APRENDIDAS
OMG propone el Metamodelo de Procesos de Ingeniera
del Software (Software Process Enginnering Metamodel
SPEM) para describir un proceso concreto de desarrollo de
software o una familia de procesos de desarrollo de software
relacionados. El propsito de SPEM es convertirse en un
lenguaje estndar para el modelado de procesos de software.
SPEM permite modelar los procesos de desarrollo de
software de una organizacin permitiendo as una
comunicacin efectiva y la aceptacin por todo el equipo de
desarrollo. Es un punto de referencia a partir del cual se puede
mejorar, gestionar y automatizar todo el proceso de desarrollo.
Los resultados de su utilizacin son procesos bien definidos
Fig. 11. Diagrama de estados [13].
98 Menndez Domnguez, V., Castellanos Bolaos, M. 2015. SPEM: Software Process Engineering Metamodel
Revista Latinoamericana de Ingeniera de Software, 3(2): 92-100, ISSN 2314-2642
que ayudan a mejorar la calidad, disminuir los costos y cumplir
las metas.
SPEM est estructurado como un perfil UML y emplea
muchos de sus diagramas (paquetes, casos de uso, clases,
actividades, secuencias, diagramas de estado), excluye algunos
elementos (nodos, componentes, etctera) y agregan nuevos
estereotipos (conos).
El estndar SPEM est muy relacionado con UML, debido
a que ambos estn basados en la especificacin MOF. SPEM se
ubica en el metamodelo que est en el nivel M2 y sirve como
plantilla para el nivel M1 de las cuatro capas arquitectnicas de
abstraccin definidas por la OMG.
El estndar SPEM 1.1 est construido dentro del paquete
base de SPEM, el cual es un subconjunto de UML 1.4. Los
elementos bsicos, relaciones, y estructuras son definidos en el
paquete base. Todos los otros elementos SPEM son definidos
en relacin a los elementos del paquete base a travs de
herencia. Debido a esta situacin, SPEM es definido como un
perfil (profile) UML en la documentacin de SPEM.
El uso de SPEM permite una descripcin abstracta de los
elementos fundamentales del proceso de software (artefactos,
roles, actividades, etc.) y la descripcin de cmo ellos estn
relacionados con otros, facilitando su uso por el equipo de
desarrollo. A nivel conceptual, la principal idea de la
representacin de procesos basados en SPEM es la relacin
entre tres elementos bsicos: roles de procesos que son
responsables y ejecutan actividades que consumen y producen
productos de trabajo.
El modelado de procesos puede ser utilizado a diferentes
escalas, la ms simple: un proceso de software existente en una
compaa debera ser modelado para una representacin y
entendimiento ms claro. En el otro extremo, una gran
compaa puede desear controlar una biblioteca de contenidos
de procesos de software adems que nuevos procesos pueden
ser creados combinando y personalizando procesos
componentes, ya sea desarrollados internamente o por terceros.
Se pretende que SPEM permita el intercambio entre
herramientas UML y repositorios basados en MOF para el
desarrollo de aplicaciones. Existen trabajos relacionados a esta
temtica [19] [2].Tambin existen herramientas para el
modelado de procesos de trabajo, lo que permite representar
todos los elementos del proceso y favorecer la comunicacin
de los involucrados. Esto trae como consecuencia un modelado
sencillo y fcil de modificar.
 SPEM ofrece numerosas ventajas: como por ejemplo ser
independiente de la metodologa o tecnologa, estar basado en
UML, adems de favorecer la comunicacin y el entendimiento
de las partes involucradas en el proceso. Sin embargo tambin
presenta algunas desventajas: como por ejemplo una semntica
ambigua por estar basada en lenguaje natural.
La versin 1.1 ofrece una sintaxis rigurosa pero formaliza
parcialmente la semntica, lo que origina algunas
ambigedades y no ofrece ayuda sobre cmo construir un
modelo de proceso. El nuevo SPEM basado en MOF 2.0
proporciona una semntica ms precisa.
IV. CONCLUSIONES
SPEM es un estndar para el modelado de procesos de
software propuesto por OMG en 2002. Es un lenguaje basado
en UML que es independiente de la metodologa empleada. Su
objetivo es hacer un estndar para el modelado de procesos de
desarrollo de software que unifique a la industria.
El uso de SPEM permite una descripcin abstracta de los
elementos fundamentales del proceso de software (artefactos,
roles, actividades, etc.) y la descripcin de cmo ellos estn
relacionados con otros, facilitando su uso por el equipo de
desarrollo [16].
En general, sus principales caractersticas son [14] [16] [1]
[7] [5]:
Independiente de la metodologa. SPEM es un
metamodelo para definir procesos, desde los cuales otros
procesos pueden ser construidos. La eleccin de la
metodologa de desarrollo que influir el tipo de proceso
es independiente de SPEM.
Basado en UML. SPEM usa una orientacin basada en
objetos y la notacin UML que es familiar a muchos
profesionales del desarrollo de software.
Independiente de la tecnologa. SPEM proporciona una
abstraccin completa del proceso desde la infraestructura
de implementacin. Esto significa que puede modelar los
procesos que mejor soporten la metodologa seleccionada,
sin preocuparse en la tecnologa de implementacin.
Orienta en la automatizacin de procesos. Los beneficios
de automatizar los procesos de desarrollo de software
pueden ser obtenidos si estos procesos son modelados
apropiadamente. SPEM est basado en estndares
abiertos lo que permite usar una solucin automatizada de
procesos de cualquier vendedor que soporte el estndar.
Incrementa la aceptacin del desarrollador. La aceptacin
del equipo es clave para una efectiva implementacin y
manejo de cualquier proceso. SPEM ofrece una vista
comprensiva y documentada de los procesos, de forma
que los miembros de un equipo de desarrollo puedan
entender y utilizar.
Se han hecho trabajos para automatizar flujos de trabajo en
WFMS (WorkFlow Management System) utilizando SPEM
[19]: Los procesos de software son modelados utilizando
SPEM, entonces el metamodelo es transformado a la forma de
XPDL (la interfaz estndar para la definicin de procesos que
separa la definicin de un flujo de trabajo de su ejecucin) por
un motor de transformacin, finalmente el modelo XPDL
resultante es entregado a un motor XPDL como Shark.
Usar SPEM no es fcil porque la especificacin es muy
general y no proporciona directivas sobre cmo usarla.
Adems, su semntica est expresada en lenguaje natural, lo
que origina la construccin de modelos de procesos que a
veces son inconsistentes debido a la carencia de una definicin
formal de los conceptos. Se ha definido una especializacin de
SPEM que utiliza OCL para definir los conceptos claramente y
Menndez Domnguez, V., Castellanos Bolaos, M. 2015. SPEM: Software Process Engineering Metamodel
Revista Latinoamericana de Ingeniera de Software, 3(2): 92-100, ISSN 2314-2642
expresar su semntica formalmente, sea a nivel metamodelo o
a nivel de proceso [2].
La especificacin SPEM versin 1.1 publicada en enero de
2005 no ha tenido una gran aceptacin posiblemente a la falta
de informacin para ponerlo en prctica, adems que slo es
compatible con MOF 1.4 (la ltima versin es la 2.0). Otro
punto en contra es que el metamodelo carece de una semntica
precisa. La versin 2.0 est en proceso de revisin y se espera
que resuelva esta situacin y tenga una gran influencia prctica
[10] [15].
REFERENCIAS
[1] M. Alanen, J. Lilius, I. Porres y D. Truscan, Realizing a Model
Driven Engineering process, Techreport, Turku Centre for
Computer Science, 2003. Recuperado de http://www.tucs.fi/
publications/attachment.php?fname=TR565.pdf
[2] B. Combemale, A. Caplain, X. Crgut y B. Coulette, Towards a
rigorous use of SPEM, ICEIS'06, Paphos(Cyprus), INSTICC,
2006. Recuperado de http://www.combemale.net/research/phd/
2006/iceis250406-CCCC-poster401.pdf
[3] B. Combemale, S. Rougemaille, X. Crgut, F. Migeon, M.
Pantel, C. Maurel y B. Coulette. Towards a rigorous
metamodeling, MDEIS'06, Paphos (Cyprus), INSTICC, 2006.
Recuperado de http://www.combemale.net/research/phd/2006/
mdeis230406-CRCMPMC.pdf
[4] N. Debnath, D. Riesco, M. P. Cota, J. B. Garcia Perez-Schofield
y D. R. M. Uva, D.R.M. Supporting the SPEM with a UML
extended workflow metamodel, Computer Systems and
Applications, IEEE, 2006, pp. 1151 1154. Recuperado de
http://ieeexplore.ieee.org/iel5/10748/33913/01618499.pdf
[5] E. Domiczi, Customizing UML for software development
process, Nordic Workshop on UML based Software
Development, Ronneby (Sweden), 2003. Recuperado de
http://www.ipd.bth.se/consistencyUML/NordicWorkshop/papers
/Customizing%20UML%20for%20Software%20Development%
20Process.pdf
[6] M.-P. Gleizes, T. Millan y G. Picard, ADELFE: using SPEM
notation to unify agent engineering process and methodology,
Rapport interne IRIT no IRIT/2003-10-R, 2003. Recuperado de
http://www.pa.icar.cnr.it/~cossentino/FIPAmeth/docs/rapport20
03-10-R.pdf
[7] C. Gonzalez-Perez, T. Mcbride y B. A Henderson-Sellers,
Metamodel for assessable software development
methodologies, Software Quality Journal, vol. 13, 2005, pp.
195214, Springer Science + Business Media. Recuperado de
http://www.springerlink.com/content/qm2u82716304v055/fullte
xt.pdf
[8] B. Henderson-Sellers y C. A. Gonzlez-Prez, A comparison of
four process metamodels and the creation of a new generic
standard, Information and Software Technology, 47, 2005, pp.
4965. Recuperado de http://linkinghub.elsevier.com/retrieve
/pii/S0950584904000850.
[9] J. Hurtado y C. Bastarrica, Hacia una Lnea de Procesos giles
Agile SPsL, Universidad del Cauca, 2005. Recuperado de
http://www.dcc.uchile.cl/~cecilia/papers/AgileSPsL.pdf
[10] A. Jrvi y T. Mkil, Observations on modeling software
processes with SPEM process components, Proceedings of The
9th Symposium on Programming Languages and Software
Tools, 2005. Recuperado de http://www.tucs.fi/publications
/attachment.php?fname=inpJaMa05a.pdf
[11] T. Mkil, A. Jrvi, Spemmet A tool for modelling software
processes with SPEM, Proceedings of the 9th International
Conference on Information Systems Implementation and
Modelling (ISIM '06), Perov (Czech Republic), 2006.
Recuperado de http://ftp.informatik.rwth-aachen.de/Publications
/CEUR-WS/Vol-180/paper09.pdf
[12] Object Management Group (OMG), Software Process
Engineering Metamodel (SPEM) Specification, version 1.0
(formal/2002-11-14), 2002. Recuperado de http://www.omg.org
99
[13] Object Management Group (OMG), Software Process
Engineering Metamodel (SPEM) Specification, version 2.0
RFP (ad/2004-11-04), 2004. Recuperado de http://www.omg.org
[14] OSELLUS, SPEM A standards-based approach for modeling
software development processes, 2005. Recuperado de
http://www.osellus.com/erms/resourceDetail.php?action=resour
ce&rid=12
[15] J. M. Rib y X. Franch, A precedence-based approach for
proactive control in software process modeling, Proceedings of
the 14th international Conference on Software Engineering and
Knowledge Engineering (SEKE '02), Ischia (Italy), ACM Press,
27, pp. 457-464, 2002. Recuperado de
http://doi.acm.org/10.1145/568760.568839
[16] A. Sampaio, A. Vasconcelos y P. Falcone, Towards reconciling
quality and agility in Web application development,
International Workshop on Web Quality (WQ'04), International
Conference on Web Engineering (ICWE04), Munich
(Germany), 2004. Recuperado de http://www.elet.polimi.it/
conferences/wq04/final/paper02.pdf
[17] W. Shengjun, J. Longfei y J. Chengzhi, Represent Software
Process Engineering Metamodel in Description Logic,
Proceedings of World Academy of Science, Engineering and
Technology, vol. 11, 2006, pp.109-113. Recuperado de
http://staff.icar.cnr.it/staff/ruffolo/public_html/progetti/projects/
23.Semantic%20BPM-%20in%20OntoDLP/Represent%20Soft
ware%20Process%20Engineering%20Metamodel%20in%20DL
--v11-20.pdf
[18] Y. Wautelet, M. Kolp y Y. Achbany, S-Tropos: An iterative
SPEM-Centric software project management process, 2006.
Recuperado de http://www.isys.ucl.ac.be/staff/youssef/Articles
/WP_SPEM.pdf
[19] F. Yuan, M. Li y Z. Wan, SPEM2XPDL: Towards SPEM
Model Enactment. Software Engineering Research and
Practice, 2006, pp. 240-245. Recuperado de
http://ww1.ucmss.com/books/LFS/CSREA2006/SER5202.pdf

Vctor Hugo Menndez Domnguez es Doctor en

Tecnologas Informticas Avanzadas por la
Universidad de Castilla-La Mancha (UCLM),
Espaa; tiene un Mster en Tecnologas
Informticas por la misma institucin. Adems,
cuenta con una Especializacin en Docencia y una
Licenciatura en Ciencias de la Computacin por
parte de la Universidad Autnoma de Yucatn (UADY), Mxico. Es
profesor titular en la Facultad de Matemticas de la UADY. Su
trabajo de investigacin se centra en temas relacionados con la
representacin del conocimiento y el aprendizaje, as como la gestin
de Objetos de Aprendizaje y Repositorios.

Mara Enriqueta Castellanos Bolaos es Maestra

en Gestin de Tecnologa de Informacin por la
Universidad Anhuac Mayab, Mxico, con lneas
de especialidad en Ingeniera de Software, Redes
de Computadoras y Seguridad de Sistemas.
Adems, cuenta con una Especializacin en
Docencia y una Licenciatura en Ciencias de la
Computacin por parte de la Universidad Autnoma de Yucatn
(UADY), Mxico. Es profesora de tiempo completo en la Facultad de
Matemticas de la UADY. Su trabajo de investigacin se centra en
temas relacionados con la gestin del conocimiento y la Ingeniera
Web.

100 Menndez Domnguez, V., Castellanos Bolaos, M. 2015. SPEM: Software Process Engineering Metamodel
Revista Latinoamericana de Ingeniera de Software, 3(2): 92-100, ISSN 2314-2642