SPEM - Software & Systems Process Engineering Metamodel Specification

1. ALCANCE: El propsito de ste documento es proporcionar una definicin comprensible del

meta-modelo de ingeniera de procesos de software y de sistemas (SPEM 2.0). ste sirve como
una gua para entender las semnticas de ste Meta-modelo, as como sus aplicaciones
directas para todas las actividades de modelado de procesos y mtodos. EL objetivo consiste
en acomodar una amplia gama de procesos, y no excluirlos por tener demasiadas
caractersticas o limitaciones. El meta-modelo utiliza UML como una notacin y toma un
enfoque orientado a objeto.
2. CONFORMIDAD: sta especificacin define tres puntos de conformidad para SPEM 2.0. Las
implementaciones son animadas a cumplir con uno de estos puntos de conformidad si su
objetivo es garantizar el xito en el intercambio de datos con otros implementadores del
punto de cumplimiento. Adems, para estos puntos de cumplimiento, la especificacin
proporciona la libertad a los implementadores de escoger cualquier combinacin de paquetes
de meta-modelo y fusin de paquetes que deseen implementar. Sin embargo, si el
intercambio de datos es u objetivo importante para un implementador, se alienta la
implementacin de estos puntos de cumplimiento.
SPEM 2.0 est definido como meta-modelo as como un perfil de UML 2. Si el perfil UML 2 de
SPEM 2.0 es utilizado por el implementador, entonces el mismo punto de cumplimiento aplica
en el sentido que los estereotipos se introducen en el mismo captulo de especificacin como
sus clases de meta-modelo respectivo. Por lo tanto un punto de cumplimiento incluye todos
los estereotipos definidos en los captulos que han sido listados para la inclusin en la
definicin de cada punto de cumplimiento a continuacin. Sin embargo, slo un perfil incluye
todos los estereotipos es proporcionado como parte de sta especificacin (OMG document
ad/06-11-05).
La especificacin proporciona esquemas XMI individual para todos los tres puntos de
cumplimiento (OMG document ad/06-11-04). Los puntos de cumplimiento listados aqu estn
definidos por la inclusin y unin de paquetes de meta-modelo especficos. La siguiente
seccin 2.1 y 2.2 proporcionan una visin de conjunto a todos los paquetes de meta-modelo
disponibles en SPEM 2.0. La seccin 2.3 a la seccin 2.5 definen los tres puntos de
cumplimiento. Finalmente, la seccin 2.6 discute otros escenarios de implantacin noconforme que podra ser til para pblicos especficos de SPEM 2.0
2.1. PRINCIPIOS DE DISEO Y EMBALAJE GENERAL DE META-MODELO SPEM 2.0: El metamodelo SPEM 2.0 es un modelo MOF 2 basado en MOF que reutiliza otras especificaciones
OMG. SPEM 2.0 reutiliza la biblioteca de infraestructura UML 2 [infraestructura UML 2.0]
siempre que sea posible. Los conceptos claves y estructuras as como los clasificadores y
paquetes han sido reutilizados directamente sub- clasificando clases SPEM 2.0 de estos. Un
implementador SPEM 2.0 debe utilizar tambin el intercambio de diagrama UML 2.0 para la
presentacin de varios tipos de diagramas tal como se presenta a travs de los ejemplos de
ste documento y se resume en el captulo 15.

Dentro del paquete llamado "SPEM" se encontrar la arquitectura actual del meta-modelo
SPEM como se ilustra en la figura 2.1 SPEM 2.0 aplica el paquete de infraestructura UML 2
unido al mecanismo para construir gradualmente el meta-modelo, proporcionando paquetes
de meta-modelo opcionales o unidades modulares como bloques de construccin para un
implementador de especificacin. En otras palabras un implementador o adoptante puede
optar por utilizar diferentes niveles de capacidades, nmeros de conceptos, y niveles de
formalismo para expresar sus procesos usando o realizando slo ciertos paquetes de sta
arquitectura. Se definen las tres secciones ms comunes como los puntos de cumplimiento
de SPEM 2.0, pero tambin se discuten otras posibilidades de combinar los paquetes de metamodelo para abordar las necesidades ms especficas del modelado de procesos.
2.2. DESCRIPCIN DE LA ARQUITECTURA DEL META-MODELO SPEM 2.0: SPEM 2.0 es usado
para definir los procesos de desarrollo de sistemas y software y sus componentes. El alcance
de SPEM est intencionalmente limitado a los elementos mnimos necesarios para definir
cualquier proceso de desarrollo de sistemas y software sin adicionar caractersticas
especficas para disciplinas o dominio particulares de desarrollo (e.g. gestin de proyectos).
El objetivo es acomodar una amplia gama de mtodos de desarrollo y procesos de diferentes
estilos, antecedentes culturales, niveles de formalismo, modelos de ciclos de vida y
comunidades. Sin embargo, el enfoque de SPEM 2.0 es proyectos de desarrollo. SPEM 2.0 no
pretende ser un lenguaje de modelado de procesos genrico, ni siquiera proporcionar sus
propios conceptos de modelado de comportamiento. SPEM 2.0 ms bien define la habilidad
para el implementador escoger el enfoque de modelado de comportamiento genrico que
mejor se adapte a sus necesidades. Este tambin proporciona estructuras especficas para
mejorar esos modelos de comportamiento genrico que son caractersticos para definir
procesos de desarrollo. En otras palabras, SPEM 2.0 se centra en proporcionar las estructuras
de informacin adicional que se necesitan para modelado de procesos con actividades UML
2.0 BPMN / BPDM para describir un proceso de desarrollo actual.
El Meta-modelo SPEM 2.0 est estructurado dentro de siete paquetes de meta-modelo
principales como se ilustra en la figura 2.1. La estructura divide el modelo dentro de unidades
lgicas. Cada unidad se extiende a las unidades de las que sta depende, proporcionando
estructuras adicionales y capacidades a los elementos definidos a continuacin. En general,
EL paquete UML 2.0 une mecanismos de unin de paquetes realiza una extensin de la
unidad de modelado de capacidades por unidad. Como resultado, las unidades definidas en
una capa inferior pueden ser realizadas por un subconjunto de implementacin SPEM 2.0 sin
las unidades del nivel superior. En muchos casos, las clases de meta-modelo estn
introducidas en un paquete de nivel inferior lo ms simple posible, y estn entonces
extendidas en unidades de nivel superior va el mecanismo de unin de paquete con
relaciones y propiedades adicionales para realizar procesos ms complejos modelando
requerimientos.

Figura 2.1 Estructura del meta-modelo SPEM 2.0

Los paquetes ilustrados en la figura 2.1 proporcionan las siguientes capacidades:

Core: (Ncleo): El paquete de meta-modelo de ncleo contiene las clases y abstracciones del
meta-modelo que construyen la base para las clases en todos los dems paquetes de metamodelo. En otras palabras, todas las clases comunes entre todos los niveles de cumplimiento
que definen el ncleo de SPEM 2.0 han sido ubicadas aqu. El ncleo define principalmente
las clases para dos capacidades SPEM 2.0: (1.) La posibilidad que un usuario SPEM 2.0 cree
calificaciones definidas por el usuario para clases SPEM 2.0 permitiendo a los usuarios
distinguir diferentes clases de instancias de clase de SPEM 2.0. (2.) Un conjunto de clases
abstractas para definir trabajo expresado como procesos SPEM 2.0. Todas las clases SPEM 2.0
que se derivan de estas clases estn designadas a asociar a las clases de comportamiento de
modelos de comportamiento. (e.g. pueden ser asignadas como estereotipos a actividades o
vnculos UML 2.0 para clasificadores de comportamiento )

Estructura de Proceso: ste paquete define la base para todos los modelos de procesos. Este
soporta la creacin de modelos de proceso simple y flexible. su ncleo de estructura de datos
es un desglose o descomposicin de actividades anidadas que mantienen listas de referencia
a la realizacin de clases de rol as como clases de producto de trabajo de entrada y salida
para cada actividad. Adems, este proporciona mecanismos para la reutilizacin de procesos
tal como el enlace dinmico de patrones de proceso que permite a los usuarios ensamblar
procesos con conjuntos de actividades vinculadas dinmicamente. Estas estructuras son
usadas para representar procesos bsicos y de alto nivel que no estn documentados

textualmente. Las estructuras son ideales para el ensamble ad-hoc de procesos,

especialmente la representacin de procesos giles y enfoques de equipos auto-organizados.

Comportamiento de Proceso: El concepto de paquete de estructura de procesos representa

un proceso como una estructura de desglose esttico, permitiendo la anidacin de actividades
y definir dependencias predecesoras entre ellas. El paquete de meta-modelo de
comportamiento de proceso permite extender estas estructuras con modelos de
comportamiento. Sin embargo, este no define su propio enfoque de modelado de
comportamiento, sino que ms bien proporciona "enlaces" a existente modelos de
comportamiento definidos externamente, habilitando la reutilizacin de estos enfoque s
desde otro OMG o especificaciones de terceros. Por ejemplo, un proceso definido con los
conceptos de estructura de proceso pueden ser enlazados a diagramas de actividad UML 2
que representa el comportamiento de tales procesos; o una definicin del producto de
trabajo desde el paquete de contenido de mtodo puede ser vinculado a un modelo de
mquina de estado que representa su ciclo de vid tpico. El captulo 7 muestra ejemplos para
los modelos de procesos que utilizan el perfil UML 2 definido en sta especificacin para una
presentacin consistente para tales modelos UML 2, adems de los "enlaces" definidos en
este paquete de comportamiento de procesos del meta-modelo.

Contenido Gestionado: Los procesos de desarrollo estn en muchos casos no slo

representados como modelos, sino documentados y gestionados como descripciones de
lenguaje natural. Para muchos enfoques y mtodos de desarrollo de software,
documentacin humano- disponible proporciona orientacin comprensible para las mejores
prcticas de desarrollo es ms importante que los modelos precisos. En otras palabras, la
viabilidad de las tcnicas y mtodos expresados con stas prcticas es en muchos casos
percibida para proporcionar un valor mayor que la obediencia estricta a un proceso definido
formalmente. Las razones para esto son que muchos enfoques de desarrollo ven el desarrollo
de software como un proceso creativo que requiere re-evaluacin constante y adopcin en
lugar de una estricta secuencia de actividades. Por ejemplo, para los equipos de desarrollo
gil modernos, las mejores prcticas de desarrollo de software son comunicadas a travs de
tutora y descripciones breves de prcticas en formatos white paper en lugar de modelos
definidos formalmente. Ellos asumen que ciertos valores y una cultura de desarrollo (en otras
palabras la ingeniera social requerida para el desarrollo gil) no puede ser formalizada con
modelos, sino que pueden ser capturados solamente en documentacin de lenguaje natural.
El paquete de meta-modelo de contenido gestionado introdujo conceptos para la gestin del
contenido textual de tal descripcin. Estos conceptos pueden utilizarse de forma
independiente o en combinacin con conceptos de estructura de procesos. Por ejemplo, un
proceso basado en SPEM 2.0 podra estar compuesto nicamente de un conjunto de
instancias de las orientaciones de meta- clase definiendo las mejores prcticas de desarrollo
en formato Whitepaper. Esto podra estar tambin compuesto de una combinacin de estos
elementos guas con una estructura de proceso usando relaciones definidas en el paquete
meta-modelo de contenido gestionado que permite asociar elementos guas con elementos
de estructura de procesos.

Contenido de Mtodo: El paquete contenido de mtodo del meta-modelo proporciona los

conceptos para usuarios y organizaciones SPEM 2.0 para construir una base de conocimiento
de desarrollo que es independiente de los proceso documentas y proyectos especficos de
desarrollo. Adiciona conceptos para definir ciclos de vida y los elementos de contenido de

mtodo reutilizable independiente del procedimiento que proporciona una base de

conocimiento documentado de los mtodos de desarrollo de software, tcnicas y
realizaciones concretas de las mejores prcticas. El contenido de mtodo comprende las
explicaciones textuales paso a paso, describiendo como se logran los objetivos de desarrollo
fino-granular especficos por cuales roles y con cuales recursos y resultados, independiente
de la ubicacin de estos pasos dentro de un ciclo de vida de desarrollo especfico. Los procesos
reutilizaran estos elementos de contenido de mtodo y los relacionara dentro de secuencias
parcialmente ordenadas que se adaptan a tipos especficos de proyectos (ver 6.3.1,' Una clara
separacin de las definiciones del contenido de mtodo desde la aplicacin de procesos de
desarrollo de contenido de mtodo' para ms detalle). Un usuario SPEM 2.0 pueden definir
contenido de mtodo como una gua general y construir una base de conocimiento de
mtodos de desarrollo sin crear un proceso, pero adicionando un poco ms de estructura para
su contenido proporcionado por las meta- clases genricas definidas en el paquete de
contenido administrado. Estas estructuras seleccionadas para el paquete de contenido de
mtodo se han derivado de las mejores prcticas de la industria. Los procesos de desarrollo
pueden basarse el contenido de mtodo reutilizable (como se define en el proceso con el
paquete meta-modelo mtodos), ellos tambin pueden ser independientes del contenido de
mtodo (simplemente usando el paquete de meta-modelo estructura de procesos),
definiendo de ste modo procesos ad-hoc que no estn basados en mtodos reutilizables.
Procesos con Mtodos: el paquete de meta-modelo procesos con mtodos define nuevas y
redefine estructuras existentes para la integracin de procesos definidos con conceptos del
paquete meta-modelo Estructura de Procesos con instancias de conceptos del paquete de
meta-modelo Contenido de Mtodo. Mientras el contenido de mtodo define mtodos
fundamentales y tcnicas para el desarrollo de software, los procesos ubican estos mtodos
y tcnicas dentro del contexto de un modelo de ciclo de vida comprendido. Por ejemplo, de
fases e hitos. Al aplicar el contenido de mtodo, como las tareas, roles y productos de trabajo
a una parte especfica de los procesos, clases de referencia (referido como un uso de
contenido de mtodo en sta especificacin) son creadas que puedan almacenar los cambios
individuales para sus clases de contenido de mtodo referenciadas. Estos cambios expresan
como y cules partes del mtodo sern aplicadas en ese punto particular en el proceso.
Plug-in de Mtodo: El paquete de meta-modelo Plug-in de Mtodo introduce conceptos
para 'disear' y de mantener la gestin, a gran escala, reutilizable y repositorios o
bibliotecas configurables de contenido de mtodo y procesos. Los conceptos introducidos
en este paquete permiten la organizacin de diferentes partes de una biblioteca basado en
diferentes capas de inters similares a las arquitecturas en capas de software. Con
conceptos como Plug-in de mtodo, componente de procesos, y variabilidad, se pueden
definir procesos que son extendidos granularmente con ms y ms capacidades. Los
usuarios pueden seleccionar las capacidades de proceso que estn interesados mediante la
definicin de las denominadas configuraciones de mtodo. Solamente estas capacidades
seleccionadas aparecern dentro de estas configuraciones al usuario final, permitiendo a los
autores de proceso definir procesos consistentes y fciles de mantener para los diferentes
pblicos que son configurables para las necesidades de usuarios finales especficos.
2.3 PUNTO DE CUMPLIMIENTO "SPEM COMPLETO":
Pblico: Proceso a gran escala y proveedores de herramientas de biblioteca de mtodo

El punto de cumplimiento "SPEM Completo" comprende todos los siete paquetes del metamodelo de SPEM descritos en 2.2, 'Descripcin de la arquitectura del meta-modelo SPEM 2.0'
La figura 2.2 muestra que los puntos de cumplimiento crean un espacio de nombres llamado
"SPEM2-Completo" que combina el nivel cumplimiento LM de la biblioteca de infraestructura
UML 2, perfiles UML 2, as como los paquetes de meta-modelo SPEM 2.0 Plug-in de mtodo y
comportamiento de procesos, los cuales se combinan transitivamente en todos los otros
paquetes del meta-modelo (ver la figura 2.1). Estos siete paquetes del meta-modelo estn
descritos en al captulo 8 al 14 de sta especificacin.

Figura 2.2. Definicin del punto de cumplimiento "SPEM Completo"

Este punto de cumplimiento es recomendado para implementadores que necesitan todas las
capacidades definidas en ste meta-modelo. Est dirigido a todos proveedores de
herramientas CASE que deseen proporcionar soporte a las grandes bibliotecas de escala del
contenido de mtodo textual y modelos de proceso reutilizable. La atencin se centra en la
gestin de muchos procesos para organizaciones multi-niveles complejas que administran
procesos interrelacionados. Tambin es el punto de cumplimiento que combina el paquete
de perfiles de la infraestructura UML 2.0, la cual proporciona un mecanismo de extensibilidad
ms completo que los mecanismos de extensibilidad light proporcionados por el mismo SPEM
2.0. Mientras SPEM 2.0 proporciona la capacidad de definir instancias de un tipo de clase que
permite asociar semnticas a instancias de clase meta, los perfiles de UML permiten adems
que crear y gestionar instancias de aplicacin de estereotipo que pueden guardar valores de
propiedad definidos por el usuario definido para los estereotipos con la instancia de
estereotipo. Los implementadores de SPEM completo deben proporcionar ambos
mecanismos de extensibilidad o un mapeo de estereotipos de perfil UML a tipos SPEM 2. Los
otros niveles de cumplimiento definidos en la especificacin no requieren realizar perfiles
porque los mecanismos de extensibilidad de peso ligero de SPEM deben ser suficientes para
los pblicos listados, pero los implementadores tienen la opcin de hacerlos para estos niveles
tambin.
Las herramientas CASE mencionadas en 6.5 'Declaracin de prueba de concepto y
disponibilidad comercial' implementa estos puntos de cumplimiento.
2.4. PUNTOS DE CUMPLIMIENTO "PROCESO SPEM CON COMPORTAMIENTO Y
CONTENIDO":

Pblico: SPEM 1.x compatible con versiones anteriores y proveedores de herramientas

enfocadas al modelo
Los puntos de cumplimiento "Contenido y proceso de comportamiento SPEM" comprende
cuatro de los paquetes del meta-modelo SPEM descritos en 2.2. 'Descripcin de la
arquitectura del Meta-modelo SPEM 2.0'. La figura 2.3 muestra que los puntos de
cumplimiento crean un espacio de nombre llamado "Proceso- Comportamiento - Contenido
SPEM2 " que combina los niveles de cumplimiento LM de la biblioteca de infraestructura UML
2 as como el paquete de meta-modelo contenido gestionado SPEM 2.0 (Capitulo 11) y
comportamiento de proceso (Captulo 10), el cual se combina transitivamente en (ver figura
2.1) estructura de proceso (captulo 9) y ncleo (Captulo 8).

Figura 2.3. Definicin del punto de cumplimiento "Proceso con comportamiento y

contenido SPEM"
Este punto de cumplimiento est recomendado para implementadores que desean centrarse
en los aspectos de modelado de SPEM. Su objetivo es el pblico que se enfoca en un proceso
a la vez y trabajan principalmente en representaciones de proceso de modelo como
estructuras de desglose de trabajo o diagramas de flujo. Aunque este punto de cumplimiento
proporciona la capacidad para documentar los procesos textualmente usando los conceptos
de contenido gestionado, sta audiencia no requiere las capacidades de contenido de mtodo
o plug-in de mtodo para proporcionar la descripcin de mtodo reutilizable, ni requieren los
conceptos de variabilidad que permiten diferentes configuraciones de modelos de variable y
texto.
Este punto de cumplimiento es tambin muy cerrado para capturar las capacidades de las
especificaciones predecesoras de SPEM 1.x y no comprende las capacidades introducidas en
SPEM 2.0 para bases de desarrollo de conocimiento de contenido de mtodo, escalar, y
variabilidad.
2.5. PUNTOS DE CUMPLIMIENTO "CONTENIDO DE MTODO SPEM":
Pblico: Documentador de mtodo y autores de libro, proveedor de base de conocimiento
organizacional
EL mtodo de cumplimiento "Mtodo SPEM" comprende tres de los paquetes del metamodelo SPEM descrito en seccin 2.2. Figura 2.4. muestra que el punto de cumplimiento crea
un espacio de nombre llamado "Contenido de mtodo SPEM 2" que combina el nivel de

cumplimiento LM de la biblioteca de infraestructura UML2 as como el contenido de mtodo

del paquete del meta-modelo (Captulo 12) la cual se combina transitivamente en (Captulo
11) y Ncleo (Captulo 8).

Figura 2.4. Definicin del punto de cumplimiento "Contenido de Mtodo SPEM"

ste punto de cumplimiento est recomendado para implementadores quines se enfocan
principalmente en la gestin de la documentacin de descripciones de mtodos de desarrollo,
tcnicas, y mejores prcticas. Las implementaciones de ste nivel pueden ser usados para
crear bases de conocimiento de desarrollo as como servir de estructura para los sistemas de
informacin basados en wiki y otros sistemas de informacin colaborativos.
La audiencia tpica de ste nivel en muchos casos no necesita o quiere los modelos de proceso
formal como una representacin para su contenido. Ellos proporcionan descripciones de sus
mtodos con un conjunto mnimo de conceptos (que podra ser incluso un subconjunto de
conceptos disponibles en ste punto de cumplimiento) tales como un producto de trabajo,
tarea y definiciones de rol, o incluso conceptos gua menos formales tales como directrices o
white papers que representen adecuadamente su vista gil de comunicar su desarrollo del
conocimiento.
ste punto de cumplimiento es tambin ideal para para libros y autores de informe tcnico
que podran argumentar su publicacin de mtodos de desarrollo, tcnicas, o mejores
prcticas con una documentacin basad en contenido de mtodo semi-formal de SPEM
proporcionando un formato reutilizable e intercambiable de su contenido usando estos
conceptos SPEM.
2.6. OTROS ESCENARIOS DE IMPLEMENTACION SPEM 2.0:
La seccin 2.2 a 2.5 especifica tres puntos de cumplimiento de la definicin de los niveles ms
tpicos para que los implementadores escojan. Sin embargo, como los paquetes de metamodelo proporcionan gradualmente ms capacidades a lo largo de las competencias
combinadas, muchas otras combinaciones de los paquetes de meta-modelo son posibles y
pueden proporcionar valor para otros propsitos. Por Ejemplo, se podra escoger para
implementar las siguientes combinaciones: (Todas estas combinaciones necesitaran incluir el
paquete ncleo. Por esto no ha sido enumerados explcitamente a continuacin).

Estructura de Proceso y Comportamiento de Proceso: Un implementador podra escoger

proporcionar una solucin de modelado pura para SPEM 2.0 o una solucin en la cual la
capacidad de la infraestructura UML 2 de adjuntar comentarios a cada elemento de modelo

es suficiente. El implementador no se da cuenta por lo tanto del paquete de contenido

gestionado que proporciona documentacin adicional as como de las capacidades de
categorizacin de contenido.
Estructura de Proceso y Contenido Gestionado: Esta combinacin no incluye
comportamiento de proceso. Si un implementador quiere enfocarse solamente en
representaciones de la estructura de desglose de los procesos, pero quiere documentar y
publicar los modelos de proceso con documentacin textual, el implementador puede
escoger implementar esos dos paquetes de meta-modelo solamente. Como un resultado,
cada elemento de proceso (Seccin 9.1) de una estructura de desglose de proceso puede ser
documentado con descripciones de contenido textual (Seccin 11.1). Adems, los elementos
guas textuales (Seccin 11.4) tales como listas de chequeo, plantillas, ejemplos, directrices y
mtricas (Seccin 11.5) pueden ser creados y enlazados sistemticamente a estos elementos
de proceso.
Estructura de Proceso, Comportamiento de Proceso y Plug-in de mtodo: Si el enfoque de
un implementador est en proporcionar bibliotecas de modelos de proceso reutilizable sin
documentar estos modelos de proceso, el implementador podra optar por combinar la
estructura de proceso y los paquetes comportamiento del meta-modelo con los paquetes de
plug-in de mtodo. Esto permitir al implementador definir bibliotecas (Seccin 14.3) de
procesos reutilizables (Seccin 9.1) as como extensiones de proceso dinmico usando
variabilidad (Seccin 14.10) y organizar estos procesos y extensiones en plug-ins
configurables (Seccin 14.1 y Seccin 14.2).
Procesos con Mtodos, Estructura de Procesos, Contenido de Mtodo, Contenido
Gestionado: Esta combinacin sera de inters para un implementador que podra querer
proporcionar una realizacin a pequea escala de SPEM 2.0. El implementador podra estar
interesado en utilizar completamente la separacin del contenido de mtodo de los procesos,
pero no necesita las capacidades de variabilidad, ni gestionar las bibliotecas de mtodo, plugins de mtodo, y configuraciones definidos en el paquete del meta-modelo Plug-in de mtodo.

3. REFERENCIAS NORMATIVAS: Los siguientes documentos normativos contienen disposiciones

que, mediante su referencia en ste texto, constituyen disposiciones de sta norma. Para las
referencias fechadas, modificaciones posteriores o revisiones de cualquiera de estas
publicaciones no son aplicables.
[MOF 2] OMG, Facilidad del meta-objeto Versin 2. www.omg.org/mof
[Infraestructura UML 2] OMG, Especificaciones de la infraestructura UML 2.
www.omg.org/uml
[Diagramas UML 2] OMG, Lenguaje de Modelado Unificado Versin 2 Intercambio de
Diagrama. www.omg.org/uml
4. TRMINOS Y DEFINICIONES: No hay definiciones formales en sta especificacin estos son
tomados de otros documentos.
5. SMBOLOS: No hay smbolos definidos en sta especificacin.
6. INFORMACIN ADICIONAL
6.1 ANTECEDENTES Y JUSTIFICACIN: sta es la tercera especificacin definida para el metamodelo de Ingeniera de procesos de software y sistemas. La especificacin de SPEM 1.0 fue

lanzada en 2002 (reporte FTF Final en mayo 2002). SPEM 1.1. Incorporo actualizaciones
menores que fueron lanzadas formalmente en el 2005 (Reporte FTF Final en marzo de 2004).
SPEM 1.x. se defini como ambos un meta-modelo independiente construido sobre UML 1.4,
y un perfil UML y se acompaa por un DTD XML. El meta-modelo usa UML 1.4 como una
notacin y toma un enfoque orientado a objetos para representar el comportamiento de los
desarrolladores como sus operaciones. SPEM 1.x vio una baja utilizacin. Desde su emisin,
pocas implementaciones se han lanzadas y estas no se han reconocido por los analistas
industriales que tambin fallaron en reconocer su importancia a la metodologa y mercado de
herramientas de proceso. All ha habido un nmero de bajo perfil o adoptantes casuales de la
especificacin as como pocas implementaciones comerciales. Se sospecha que la facilidad de
adopcin ha sido un problema y algunas de las semnticas de SPEM 1.x fueron ambiguas y
difciles de entender por los adoptantes y por lo tanto no usados en sus prcticas.
Ahora que las revisiones importantes al subyacente estndar UML han sido desarrolladas en
UML 2, son muchos los beneficios que se cosecharon en SPEM. UML 2 incluye nuevas
caractersticas tales como tcnicas de modelado mejoradas grandemente, y capacidad de
intercambio de grficos, las cules son de uso obvio en modelado de proceso. Adems, UML
2 est organizado de una forma ms modular para permitir especificaciones relacionadas para
reutilizar solamente las partes necesaria del meta-modelo UML. La capacidad de aprovechar
estas caractersticas, as como la capacidad para trabajar con las herramientas UML 2 son
potentes mejoras a SPEM 2.0. Adems, No haba retroalimentacin especfica de los
implementadores de SPEM 1.x que se han dirigido para hacer modelos de procesos de SPEM
ms fcil de adoptar y automatizar. sta especificacin trata los siguientes requerimientos del
RFP:
o
o

o
o

o
o

Actualizar SPEM para cumplir con UML 2, tomando ventaja de la nueva funcionalidad
para mejorar las capacidades y tcnicas de modelado de proceso.
Definir un nuevo esquema SPEM XML, basado en MOF. Los esquemas XML
proporcionan una mayor riqueza y control ms all de lo que est disponible en el DTD
XMI de SPEM 1.1.
Proporcionar orientacin sobre la migracin de modelos de procesos existentes de
SPEM 1.1 a SPEM 2.0.
Reacciones de los primeros implementadores para abordar las inconsistencias
identificadas y preocupaciones con respecto a la viabilidad y la cobertura funcional de
SPEM 1.1.
Definir extensiones a SPEM que sern de utilidad para procesar herramientas de
automatizacin.
Alinear SPEM con la evolucin y las nuevas normas que no sean UML; especficamente,
el meta-modelo de definicin de procesos de negocio y las interfaces en tiempo de
ejecucin de proceso de negocio se pueden usar en conjunto con SPEM para
proporcionar un mayor valor a la comunidad de usuarios.
Introducir extensiones del meta-modelo procesos que pueden ser usadas igualmente
en procesos de desarrollo de software y procesos de ingeniera de sistemas.

6.2 INTRODUCCIN GENERAL A SPEM 2.0: A lo largo de la industria del software hay un
montn de grandes ideas y conocimiento disponible acerca de cmo desarrollar software
eficientemente. Hoy en da, Los equipos de desarrollo necesitan y tienen acceso a un amplio

rango de informacin. No slo necesitan adquirir informacin detallada acerca de tecnologas

especficas de desarrollo tales como Java, Java EE, Eclipse, tecnologas SOA, .Net, as como
diversos entornos e desarrollo y herramientas, sino que tambin necesitan descifrar como
organizar sus trabajos a lo largo de las mejores prcticas de desarrollo como gil, iterativa,
centrado en la arquitectura, desarrollo de software manejando riesgos y calidad.
Algunos problemas que las organizaciones de desarrollo enfrentan cuando ellos salen en que
sus desarrolladores encuentren esa informacin para ellos mismo son:
o

Los miembros del equipo no tendrn acceso sencillo y centralizado al mismo cuerpo de
informacin cuando ellos la necesitan, es decir, diferentes desarrolladores pueden
confiar en diferentes fuentes y versiones de la misma informacin.
Es difcil combinar e integrar los contenidos y procesos de desarrollo que se ponen a
disposicin en su propio formato de propietario, como todo libro y publicacin presenta
el contenido y proceso de mtodo usando una representacin y un estilo de
presentacin diferente.
Es difcil definir un enfoque de desarrollo sistemtico y organizado que es del tamao
adecuado a sus necesidades, es decir, se dirige a su cultura especfica, prcticas
estandarizadas, y requerimientos de cumplimiento.

El meta-modelo de Ingeniera de Procesos de Sistemas y Software (SPEM) es un meta-modelo

de ingeniera de procesos as como el marco conceptual, el cual proporciona los conceptos
necesarios para modelar, documentar, presentar, gestionar, intercambiar y promulgar
mtodos de desarrollo y procesos. Una implementacin de ste modelo est dirigida a los
ingenieros de proyecto, conductores de proyecto, gerentes de programa y proyecto quines
son responsables de mantener e implementar procesos para sus organizaciones de desarrollo
o proyectos individuales.

Figura 6.1. Marco Conceptual de Uso de SPEM 2.0

La figura 6.1 presenta un marco conceptual para el uso de una implementacin SPEM 2.0:

Proporcionar una representacin estandarizada y bibliotecas gestionadas de contenido de

mtodo reutilizable: Los desarrolladores necesitan entender los mtodos y prcticas claves
de desarrollo de software. Ellos necesitan familiarizarse con las tareas de desarrollo bsico,
tales como la forma de obtener y gestionar los requerimientos, como hacer el anlisis y
diseo, la manera de implementar un diseo o caso de prueba, como probar las
implementaciones contra los requerimientos, como administrar el alcance del proyecto y los
cambios, y as sucesivamente. As mismo, deben entender los productos de trabajo tales como
crear tareas, as como las habilidades que se requieren. SPEM 2.0 tiene como objetivo apoyar
a los profesionales de desarrollo en el establecimiento de una base de desarrollo de capital
intelectual para el desarrollo de software y sistemas que les permita gestionar y desplegar su
contenido usando un formato estandarizado. Dicho contenido se puede licenciar, adquirir y
ms importante, su contenido consistente en su propia cosecha. Por ejemplo, definiciones de
mtodo, whitepapers, directrices, plantillas, principios, mejores prcticas, procedimientos
internos, regulaciones, material de entrenamiento, o cualquier otra descripcin general de
cmo desarrollar software. Esta base de conocimiento se puede usar como referencia y para
la educacin y constituir la base para los procesos de desarrollo. (Vase el inciso siguiente).
Apoyar el desarrollo sistemtico, gestin y desarrollo de procesos de desarrollo: Los equipos
de desarrollo necesitan definir cmo aplicar sus mtodos de desarrollo y mejores prcticas a
lo largo del ciclo de vida del proyecto. En otras palabras, necesitan definir o seleccionar
procesos de desarrollo. Por ejemplo, los mtodos de gestin de requerimientos tienen que
ser aplicados en una manera durante las fases iniciales de un proyecto, donde el enfoque se
centra ms en la obtencin de las necesidades y requerimientos de los interesados
(Stakeholders) y el alcance de una visin. Los mismos mtodos tienen que ser realizados de
una manera diferente durante las fases posteriores. Donde el enfoque se centra en la gestin
de actualizaciones y cambios de requerimientos y la realizacin de anlisis del impacto de los
cambios de estos requerimientos. Los mismos mtodos de requerimientos tambin pueden
aplicarse de manera diferente si el proyecto desarrolla un nuevo sistema o mantiene un
sistema existente as como depende de los equipos y su distribucin. Un modelo de proceso
de desarrollo necesita soportar expresar estas diferencias. Los equipos tambin necesitan un
claro entendimiento de como las diferentes tareas dentro de los mtodos se relacionan entre
s. Por ejemplo, como el mtodo de gestin de cambio impacta el mtodo de gestin de
requerimiento, as como el mtodo de prueba de regresin durante todo el ciclo de vida.
SPEM 2.0 soporta la creacin sistemtica de procesos basados en contenido de mtodo
reutilizable. El contenido de mtodo independiente del ciclo de vida se puede colocar dentro
de uno especfico para un ciclo de vida de desarrollo especfico. Tales procesos se pueden
representar como flujos de trabajo y/o estructuras de desglose (descomposicin). Dentro de
estos procesos el contenido de mtodo reutilizado puede entonces refinarse para su contexto
especfico. SPEM 2.0 tambin proporciona la base conceptual para los ingenieros de procesos
y gerentes de proyecto para seleccin, diseo y rpido montaje de los procesos para sus
proyectos de desarrollo concretos. La visin de SPEM es que los vendedores puedan vender
con sus catlogos de implementacin SPEM 2.0 de procesos predefinidos para situaciones
tpicas de proyecto que se pueden ser adaptar a necesidades individuales. Dentro de estos
catlogos, la implementacin ofrece bloques de construccin de procesos o patrones de
procesos que representan procesos de referencia para disciplinas, tecnologas o estilos de
desarrollo especficos. Estos patrones de proceso forman un conjunto de herramientas para
ensamblar rpidamente los procesos basados en las necesidades especficas del proyecto.

Apoyar el despliegue de slo el contenido de mtodo y el proceso necesario para definir las
configuraciones del contenido de mtodo y procesos: Ningn proyecto de desarrollo es
exactamente como otro y el mismo proceso de desarrollo nunca se ejecuta dos veces. Los
marcos de referencia para procesos de desarrollo tales como CMMI definen diferentes
niveles de madurez de los procesos. Cada nivel implica caractersticas diferentes para la
definicin de proceso as como la promulgacin en una organizacin o proyecto para cada
nivel. Por ejemplo, CMMI define un "proceso gestionado" como actividades realizadas que se
pueden reconocer como implementaciones de prcticas de desarrollo. Tal proceso tiene
ciertas caractersticas: Es planificado y ejecutado de acuerdo a polticas, emplea a personas
calificadas, cuenta con recursos suficientes para producir salidas controladas, involucra
stakeholders relevantes, es monitoreado, controlado, y revisado; y se evala la adherencia a
su descripcin de proceso. Por el contrario, un "proceso definido" es un proceso gestionado
que se adapta desde el conjunto de procesos estndar de la organizacin de acuerdo a las
directrices de adaptacin de la organizacin. Un proceso definido tiene una descripcin del
proceso de mantenimiento y contribuye productos de trabajo, medidas, y otra informacin
de mejora de procesos a los activos de proceso de la organizacin. Las nociones de actividad
de uso, configurabilidad, y variabilidad para procesos de desarrollo (as como contenido de
mtodo) en SPEM 2.0 exactamente frente a las necesidades de los procesos definidos. Estos
conceptos proporcionan capacidades para la reutilizacin de procesos o patrones de
procesos, para modelar variabilidad (es decir, los procesos que forman parte de las partes
alternativas configurables) y para adaptar permitir a los usuarios definir sus propias
extensiones, omisiones, y puntos de variabilidad o procesos estndar reutilizados. Por lo
tanto, el escenario de uso de SPEM es que las organizaciones puedan proporcionar bibliotecas
de procesos y mtodos reutilizables usando las capacidades descritas en los dos primeros
puntos. Los jefes de equipo pueden seleccionar y disear el contenido de mtodo y procesos
que ellos requieren. A continuacin pueden describir estas selecciones y personalizaciones
con un mtodo de configuracin de SPEM. Que pueden desplegar a sus equipos solo
proporcionando el contenido que ellos realmente necesitan.
Apoyar la promulgacin de un proceso para proyectos de desarrollo: Una definicin de
proceso slo proporciona valor si impacta y dirige el comportamiento de los equipos de
desarrollo. Los procesos as como las necesidades del mtodo de contenido dirigidas estarn
disponibles en el concepto de trabajo diario de los directores de proyecto, jefes tcnicos y
desarrolladores. Por lo tanto, es necesario desplegar en formatos que estn listos para su
promulgacin con los sistemas de procesos de promulgacin de las elecciones del equipo.
Los sistemas de promulgacin comunes son proyectos y sistemas de planeacin de recursos,
sistemas de seguimientos de trabajos pendientes, y motores de flujo de trabajo. SPEM 2.0
proporciona estructuras de definicin de proceso que permiten a los ingenieros de proceso
expresar como un proceso debe ser promulgado dentro de estos sistemas. Por ejemplo, los
procesos de definicin de proceso SPEM 2.0 puede incluir informacin que indique que las
definiciones de modelado de trabajo se repiten varias veces en un proyecto (iteraciones de
modelado) o que puede haber mltiples ocurrencias de definiciones de trabajo que pueden
ser realizados en paralelo.
Aunque, el meta-modelo SPEM 2.0 se ha diseado entorno al apoyo para este marco de
trabajo, muchos otros escenarios tiles pueden ser realizados tambin. Por ejemplo, el
captulo 2 define diferentes puntos de cumplimiento y analiza diferentes escenarios de
aplicacin que podra realizar una variacin de los escenarios representados en la figura 6.1.

6.3 NUEVAS CAPACIDADES CLAVE DE SPEM 2.0: Adems de abordar los requisitos RFP
enumerados anteriormente, sta especificacin proporciona las siguientes nuevas
capacidades para los autores de proceso.
6.3.1. Una clara separacin de las definiciones de contenido de mtodo desde la aplicacin
de proceso de desarrollo de contenido de mtodo: Como se indica en la seccin 6.2, SPEM
2.0 separa el contenido de mtodo reutilizable de su aplicacin en los procesos. El contenido
de mtodo proporciona explicaciones paso a paso, describiendo como los objetivos
especficos de desarrollo se logran independiente de la colocacin de estos pasos dentro un
ciclo de vida de desarrollo. Los procesos toman estos elementos de contenido de mtodo y
los relaciona dentro de unas secuencias ordenadas parcialmente que se adaptan a proyectos
de tipo especfico.
Por ejemplo, un proyecto de desarrollo de software que desarrolla una aplicacin desde cero
lleva a cabo tareas de desarrollo tales como "encontrar actores y casos de uso", "Visin de
desarrollo", o "Diseo de casos de uso" similarmente a un proyecto que ampla un sistema de
software existente. Sin embargo, los dos proyectos realizarn las tareas en diferentes puntos
en el tiempo con un nfasis diferente, es decir, realizaran los pasos de estas tareas
diferentemente, asumirn diferentes entradas, y quizs aplicarn variaciones y adiciones
individuales.

Figura 6.2 - Aplicar el mismo contenido de mtodo (Izquierdo) en diferentes procesos

(derecha) y diferentes partes de la estructura de descomposicin del mismo proceso
(superior-derecha).
La figura 6.2 representa un ejemplo de una implementacin SPEM 2.0. Esto demuestra que
SPEM 2.0 permite a cada proceso sobre el lado derecho referenciar el contenido de mtodo
comn, como las definiciones de roles, tareas y productos de trabajo, as como la orientacin
general de un pool de contenido de mtodo comn representada a la derecha. Estas
referencias dan cuenta de la trazabilidad de los procesos a su contenido de mtodo
subyacente, permitiendo que los cambios en los mtodos se reflejen en todos los procesos
que lo usan. Por otra parte, SPEM 2.0 permite an remplazar ciertos mtodos relacionados
al contenido dentro de un proceso as como definir relaciones especficas de proceso

individuales para cada elemento de proceso (as como desglose de trabajo y nuevas relaciones
a productos de trabajo y roles).

Figura 6.3. Definicin de contenido de mtodo vs la Aplicacin de contenido de mtodo en

un proceso.
La figura 6.3. (tomada del proceso unificado) muestra la diferencia entre contenido de mtodo
y proceso representndolos como dos dimensiones diferentes. El contenido de mtodo
describe como el desarrollo del trabajo es realizado y categorizado por disciplinas en este
ejemplo. Cada disciplina est compuesta de definiciones de tareas (no visible en figura 6.3)
que proporciona descripciones paso a paso de cmo los objetivos especficos de desarrollo se
logran. En un proceso, las definiciones de tareas se seleccionan del contenido de mtodo y se
ubican dentro de flujos de trabajo como usos de tarea listos para instanciacin. La
instanciacin asignara recursos para realizar el trabajo y asignar productos de trabajo real
como las entradas y salidas de las tareas. Los grficos de la carga de trabajo de la figura 6.3
muestra el esfuerzo del trabajo para cada disciplina en el tiempo (de izquierda a derecha).

Figura 6.4. Una presentacin alternativa para el Contenido de Mtodo vs Proceso.

La figura 6.4 muestra una presentacin alternativa (tomado de Fujitsu Macroscope) para la
separacin del contenido de mtodo de los procesos. Muestra como la definicin y estructura
del contenido de mtodo comn (entregables y roles clave) son usados por una variedad de
procesos estndar. U n proceso determina el alcance y nivel de detalle de los entregables y
organiza su produccin por roles clave.

Figura 6.5. Terminologa clave definida en esta especificacin Mapeada a el contenido de

mtodo vs proceso.
La figura 6.5 proporciona una visin general de cmo los conceptos claves definidos en esta
especificacin estn posicionados para representar el contenido de mtodo o proceso. El
contenido de mtodo est expresado principalmente usando definiciones del producto de
trabajo, definiciones de rol, definiciones de tarea, y guas. Las guas como directrices,
whitepapers, listas de chequeo, ejemplos o hojas de ruta, estn definidas en la interseccin
del mtodo de contenido y el proceso, porque las guas pueden ser definidas para
proporcionar los antecedentes ( fondo) para el contenido de mtodo as como para procesos
especficos (por ejemplo, tutoriales de proceso ejemplarmente). Sobre el lado derecho del
diagrama, se ven los elementos usados para representar procesos en SPEM 2.0. El elemento
principal es la actividad que se puede anidar a estructuras de desglose definidas as como
relacionadas entre s para definir un flujo de trabajo. Las actividades tambin gestionan
referencias al contenido de mtodo. Estas referencias estn representadas por coincidencia
de 'uso' de conceptos. Las actividades son usadas para definir procesos.
6.3.2. MANTENIMIENTO CONSTANTE DE MUCHOS PROCESOS DE DESARROLLO
ALTERNATIVO

Figura 6.6 - Un proceso con variaciones: La sustitucin de una actividad

representada en color azul y actividades suprimidas en color gris.
La meta de SPEM 2.0 no es slo soportar la representacin de un proceso de desarrollo
especfico o el mantenimiento de varios procesos no relacionados. Sino proporcionar a los
ingenieros de proceso mecanismos para gestionar efectiva y consistentemente todas las
familias de procesos relacionados.
SPEM 2.0 utiliza un conjunto extendido de relaciones para reutilizar y variabilidad para darse
cuenta de la herencia y semnticas como aspectos de orientacin as como conceptos para
patrones de proceso y el as llamado plug-in de mtodo. Este permite a un ingeniero de

proceso mantener familias consistentes de procesos, que por un lado son especficos a un tipo
especfico de proyecto y por otro lado tambin son variaciones del mismo mtodo base y
contenido de proceso. Los resultados son diferentes variantes de procesos especficos
basados en el mismo ncleo de contenido de mtodo y estructuras de proceso pero aplicados
con diferentes niveles de detalle y escala; por ejemplo, variantes de proceso para proyectos
de desarrollo a grande escala vs pequeos proyectos.

Figura 6.7. Un proceso con un paso opcional. (Define Modelos propios)

La figura 6.7 muestra otro ejemplo de proceso (tomado de Fujitsus Macroscope)
representando diferentes variantes en el mismo proceso. Este representa un segmento de
proceso que contiene un elemento de proceso opcional para definir modelos propios. Los
elementos opcionales pueden ser mostrados u ocultados con el botn de activacin + / - en
la parte superior izquierda, el cual los adiciona o remueve de una instancia de proceso
concreta. Las circunstancias exactas de aplicar o no el elemento opcional est documentado
en la descripcin de proceso.
6.3.3. MUCHOS DE LOS DIFERENTES MODELOS DE CICLO DE VIDA

Figura 6.8 - Dos procesos con modelos de ciclo de vida diferente. Una estructura SPEM 2.0
comn para representar cualquiera de estos ciclos de vida.
Una especificacin genrica del meta-modelo para procesos de desarrollo necesita tener que
ser capaz de soportar diferentes variedades e incluso combinaciones de modelos de ciclo de
vida como cascada, iterativo, incremental, evolutivo y as sucesivamente para la planeacin
basada en procesos.
El meta-modelo SPEM 2.0 est diseado para dar cabida a mltiples enfoques. Este
proporciona un conjunto amplio de atributos de personalizacin para especificar la gua
temporal para los elementos de proceso, permitiendo que estos sean mapeados a planes de
proyecto que se realizan basados en el modelo de ciclo de vida subyacente del proceso. Por
ejemplo, el mapeo permitir que un proceso iterativo genere un plan que proporciona un
nmero de iteraciones definidas por el usuario, necesarias para una situacin de proyecto
especfico.
Adicionalmente, SPEM 2.0 proporciona alternativa, pero mantuvo constantemente,
formalizaciones de presentacin de proceso tales como estructuras de desglose vs diagramas
de flujo. Esto permite al ingeniero de proceso escoger la presentacin de su preferencia que
mejor se ajusta al modelo de ciclo de vida utilizado.

Figura 6.9. Un proceso gil en macroscpico. ste se compone de tres subprocesos, cada
uno de los cuales sigue uno modelo de ciclo de vida diferente.

6.3.4. VARIABILIDAD DE PROCESO FLEXIBE Y EXTENSIBILIDAD DEL MECANISMO PLUG-IN

Figura 6.10. Ejemplo para un plug-in de mtodo extendiendo contenido de mtodo y

procesos con capacidades adicionales.
SPEM 2.0 define plug-ins de mtodo proporcionando capacidades para adaptar y personalizar
contenido de mtodo sin modificar directamente el contenido original. En cambio, los plugins slo definen las diferencias (aportes, sustituciones, supresiones) en relacin al original.
SPEM 2.0 soporta mecanismos de plug-in para el contenido de mtodo as como los procesos
representados como estructuras de desglose.
SPEM 2.0 es compatible con la definicin de las contribuciones y sustituciones en una
estructura de desglose sin modificarlo directamente, sino mediante la creacin de un plug-in
a la misma.

6.3.5. PATRONES DE PROCESO REUTILIZABLE DE MEJORES PRCTICAS PARA EL MONTAJE

DE PROCESO RAPIDO

Figura 6.11. Un patrn de proceso aplicado tres veces a un proceso; cada uno con
modificaciones individuales.
Los patrones de proceso de SPEM 2.0 son bloques de construccin reutilizables para crear nuevos
procesos de desarrollo. Seleccionar y aplicar un patrn de proceso se puede hacer en una de
varias maneras posibles.

Un patrn se puede aplicar en una copia sofisticada y modificar la operacin, lo cual permite
al ingeniero de proceso personalizar individualmente el contenido del patrn a sus
necesidades durante la aplicacin del patrn.
SPEM 2.0 soporta la aplicacin de patrones a travs de los mecanismos de actividad de uso,
lo cual es una forma de reutilizar las estructuras de proceso de actividades que re-ocurren
comnmente. Las actividades se pueden factorizar dentro de patrones que se pueden aplicar
una y otra vez en un proceso. Las actividades de uso definen clases de relaciones de modo
que cuando el patrn est siendo revisado o actualizado, todos los cambios se reflejan
automticamente en todos los procesos que aplican ese patrn.

6.3.6. COMPONENTES DE PROCESO REUTILIZABLE Y REMPLAZABLE REALIZANDO LOS

PRINCIPIOS DE ENCAPSULACIN

Figura 6.12. Componentes de proceso conectados va puertos de producto de trabajo.

Ciertas situaciones en un proyecto de desarrollo de software pueden requerir que las partes del
proceso permanezcan indecisas o sean decididas por el equipo de ejecucin en s mismo. (por
ejemplo en situaciones de externalizacin).
SPEM 2.0 proporciona un concepto de componente que cuenta con puertos para declarar
entradas y salidas de producto de trabajo, que permite al usuario tratar la definicin real del
trabajo que producen las salidas como una "caja negra". En cualquier momento durante un
proyecto, el componente "realizacin" detalla el trabajo que puede ser adicionado al proceso.
El enfoque de componentes tambin permite diferentes estilos o tcnicas de hacer el trabajo para
ser remplazado con otros. Por ejemplo, una salida de cdigo de software de un componente se
puede producir con desarrollo orientado al modelo o la tcnica de centrado en el cdigo. El
concepto de componente encapsula el trabajo real y permite al equipo de desarrollo escoger la
tcnica apropiada. ste permite al equipo completar la realizacin del componente con la eleccin
de las actividades que producen las salidas requeridas.
6.4. FORMALISMO DE ESPECIFICACIN
Esta especificacin documenta el meta-modelo de ingeniera de procesos de sistemas y software
2.0 (meta-modelo SPEM 2.0) y el perfil UML 2 del meta-modelo de ingeniera de procesos de
sistemas y software (perfil SPEM 2.0).
El meta-modelo de ingeniera de proceso SPEM 2.0 describe las estructuras necesarias para
mantener y expresar formalmente el contenido de mtodo de desarrollo y los procesos, es decir,
describe un lenguaje y esquema de representacin para contenidos de mtodo y procesos. Un
meta-modelo por s mismo es expresado usando lenguaje de meta-modelo (es decir, un metameta-modelo). El MOF (especificacin de modelado - Meta-Object Facility) estndar [MOF 2.0]
proporciona un lenguaje aplicando y extendiendo el UML [UML 2], es decir, describe cmo usar
UML 2 para describir meta-modelos. En ste sentido, MOF basado en UML 2 es usado para
describir el UML 2 en una manera bootstrapping.

Figura 6.13. Capas del modelo para UML y SPEM 2.0

El meta-modelo SPEM 2.0 es un MOF 2.0 (Meta-Object Facility) compatible con el metamodelo
Este documento proporciona un MOF 2.0 compatible con la especificacin del meta-modelo del
meta-modelo SPEM 2.0 como se representa en el lado izquierdo de la figura 6.13. Se pueden ver
las diferentes capas de instanciacin del formalismo usado para sta especificacin. Un modelo
definido sobre una capa superior define el lenguaje que se utilizar en la capa inferior siguiente.
MOF es el lenguaje universal que se puede usar sobre cualquier capa, pero en nuestro caso es
instanciado desde la capa M3 por SPEM 2.0 sobre la capa M2. El meta-modelo UML 2 en s mismo,
como se representa sobre el lado derecho de la capa M2, instancia MOF 2 definido sobre la capa
M3 en la misma forma. "Una biblioteca de mtodo" es un ejemplo de una instancia concreta del
meta-modelo SPEM 2.0 usando SPEM 2.0 como un esquema para representar su contenido. En
ese sentido, "la biblioteca de mtodo" representa un modelo de mtodo. Por ejemplo, SPEM 2.0
define los conceptos de roles, tareas y artefactos as como las relaciones entre ellos.
La biblioteca de mtodo A sobre la capa M1 proporciona instancias concretas de roles y artefactos
desde la capa 2 tal como "analista de sistemas" y "caso de uso" como se ve en la figura 6.14. "el
caso de uso" es una instancia directa de la meta-clase "artefacto", la cual es una instancia de la
meta-meta- clase "clase" desde la capa M3. Una instancia de caso de uso que uno cree durante

un proyecto de desarrollo tal como "catlogo de navegacin" para un sistema de ventas basado
en web ahora ser una instancia de la clase "clase de uso" sobre la capa M0.
El meta-modelo SPEM 2.0 reutiliza partes UML 2
El meta-modelo SPEM 2.0 describe todas las estructuras y atributos necesarios para representar
los mtodos y procesos basados en SPEM 2.0. Sin embargo, SPEM 2.0 no define todos los
elementos desde el principio, pero actualmente reutiliza elementos del meta-modelo UML 2. La
figura 6.13 muestra una dependencia sobre la capa M2 de SPEM 2.0 a UML 2. Esta dependencia
expresa que las partes del SPEM 2.0 estn basadas en las definiciones del UML 2. Por ejemplo, los
elementos de ncleo de SPEM 2.0 tales como "Elemento de proceso" y "paquete de mtodo" se
han derivado a travs de la especializacin de clases de la biblioteca de infraestructura de UML 2
heredando las relaciones que permiten la definicin de paquetes y elementos encapsulables.
SPEM 2.0 tambin reutiliza paquetes de la superestructura UML 2 tal como paquetes de
actividades UML 2.
El meta-modelo UML 2 tiene una implementacin de referencia
El meta-modelo SPEM 2.0 puede ser directamente instanciado para una implementacin, es decir,
una herramienta CASE puede representar todas las clases de la capa M2 como clases Java y tablas
de bases de datos. Aunque el meta-modelo MOF de SPEM 2.0 est definido en UML, una instancia
del modelo (es decir, un proceso o mtodo concreto) se puede representar independiente del
UML.

Figura 6.14. Instanciaciones ejemplares de las capas de modelado.

El perfil SPEM 2.0 es un perfil UML 2 que proporciona una representacin alternativa al metamodelo SPEM 2.0
Adems de representar una biblioteca de mtodo como "Biblioteca de mtodo A" con estas
estructuras, creando su propia implementacin de estas clases (por ejemplo, usando las clases
javas mencionadas anteriormente) se puede tambin decidir representar las clases de la capa M1
con una herramienta de modelado UML 2 tal como Magic Draw o el modelador de Software
racional de IBM. En este caso, se puede utilizar clases de la superestructura UML sobre la capa M2
y ampliar estas con los mecanismos de extensin UML 2 oficial, proporcionando perfiles con
estereotipos y restricciones OCL como se representa en el lado derecho de la figura 6.13. Por
ejemplo, en el lado derecho de la figura 6.14 se puede ver una declaracin de estereotipo para un
artefacto ampliando el concepto de clase de UML 2. Una instancia en la capa M1 sera una clase
UML 2 que tiene este estereotipo asignado. Una instancia M0 seguira el mismo aspecto. La nica
diferencia es la representacin formalizada usada para el meta-modelo (M2) y el modelo M1.

La ventaja del enfoque de perfil es que no necesita desarrollar herramientas CASE para mantener
mtodos y procesos, pero podra usar una herramienta de modelado UML 2 genrica para hacerlo.
La desventaja de ste enfoque es que tal herramienta de modelado UML 2 sera muy genrica y
que todas las reglas de estructuracin especficas definidas en el meta-modelo SPEM 2.0 como
simples relaciones necesitaran ser forzadas con complicadas restricciones OCL, limitando al
usuario mucho ms que cuando modela con UML. Por ejemplo, restringir el nmero de
asociaciones que una tarea puede tener con roles cuando un estereotipo especfico es aplicado
forza la restriccin simple de un rol de ejecucin principal para una tarea. Forzar todas las reglas
bsicas de SPEM 2.0 en restricciones OCL resultara en que el usuario de la herramienta trata con
interacciones y mensajes de error OCL muy genricos, lo que resulta en una mala experiencia de
usuario.
SPEM 2.0 define un meta-modelo as como un perfil UML
Sin embargo, la especificacin proporciona definiciones para ambas representaciones:

El meta-modelo SPEM 2.0: define todas las estructuras y reglas de estructuracin y est en s
misma completa. Este ha sido especificado como un modelo MOF y reutiliza algunas clases
clave de la infraestructura UML 2. Este tambin define la notacin de diagramas de proceso
especfico.
El perfil UML de SPEM 2.0: define un conjunto de estereotipos UML 2 que permiten presentar
mtodos y procesos SPEM 2.0 usando el UML 2. Sin embargo, la definicin de estos
estereotipos en esta especificacin slo cubren su presentacin, pero se basa en el metamodelo SPEM 2.0 para todas las definiciones y restricciones semnticas. En otras palabras,
esta versin del perfil no contiene ninguna restriccin OCL, sino que depende de las
semnticas del meta-modelo SPEM 2.0 para definir todas sus restricciones.

Cada seccin de definicin de conceptos se define ambas representaciones.

6.5. DECLARACIN DE PRUEBA DE CONCEPTO Y DISPONIBILIDAD COMERCIAL
Las partes principales de sta especificacin que se han implementado son de libre acceso en el
cdigo abierto en el marco de proceso de Eclipse (www.eclipse.org/epf/). Ver anexo C para varios
estudios de caso modelando procesos de fuentes y dominios diferentes que se han creado usando
sta tecnologa. Hay varias organizaciones y compaas que han anunciado que van a modelar
sus procesos libres o comerciales con sta tecnologa. Algunas de stas son Process Group, Open
Group, Number Six Software, y Telelogic.
Hay tambin un producto comercial disponible de IBM que se ha construido en la parte superior
de sta implementacin de cdigo abierto. Un gran nmero de procesos comerciales de IBM
Software Group, IBM Rational, IBM Tivoli, and IBM Global Services as como Sierra Systems y el
consorcio DSDM han estado modelando con sta implementacin y estn o estarn disponibles
para la compra. Ver anexo C para ejemplos de estos procesos.
Otros autores de sta especificacin tales como Adaptive y Fujitsu han expresado su intencin de
implementar sta especificacin y representar sus procesos con los conceptos de sta
especificacin dentro de un ao despus de la adopcin.

6.6. CAMBIOS A LAS ESPECIFICACIONES OMG ADOPTADAS

Esta especificacin sustituye completamente la especificacin SPEM adoptada versin 1.1, formal
05-01-06
6.7. COMO LEER ESTA ESPECIFICACIN
Aunque los captulos se organizan de una manera lgica y se puede leer secuencialmente, sta es
una especificacin de referencia destinada a ser leda de una manera no secuencial. Por
consiguiente, las extensas referencias cruzadas son proporcionadas para facilitar la navegacin y
bsqueda. El captulo 2.1. proporciona una descripcin detallada a la organizacin del metamodelo SPEM y su presentacin en los captulos siguientes. Los captulos 7 al 14 siguen sta
estructura y presentan el contenido de los paquetes del meta-modelo uno por uno. Los captulos
15 al 18 proporcionan informacin bsica adicional para el meta-modelo tales como ejemplos
para diagramas de proceso, como usar SPEM 2.0 como un perfil del modelo UML 2, etc.
6.8. AGRADECIMIENTOS
Las siguientes empresas presentaron parte de sta especificacin:

Adaptive Ltd.
Fujitsu & Fujtsu Consulting
Fundacion European Software Institute
International Business Machines Corporations
Softeam

Las siguientes empresas apoyaron sta especificacin:

Alcatel
Armstrong Process Group, Inc.
Aubry Conseil
BAE Systems
Borland Software Corporation
Capgemini
EDS
HP
Kabira
Laboratoire d'Informatique Paris 6 LIP6
Lockheed Martin
MEGA
MetaMatrix
Mitre
Number Six Software
Sierra Systems
SINTEF ICT
Telelogic
Unisys