SPEM - Software & Systems Process Engineering Meta-model Specification

1. ALCANCE: El propósito de éste documento es proporcionar una definición comprensible del

meta-modelo de ingeniería de procesos de software y de sistemas (SPEM 2.0). Éste sirve como una guía para entender las semánticas de éste Meta-modelo, así como sus aplicaciones directas para todas las actividades de modelado de procesos y métodos. EL objetivo consiste en acomodar una amplia gama de procesos, y no excluirlos por tener demasiadas características o limitaciones. El meta-modelo utiliza UML como una notación y toma un enfoque orientado a objeto.

2. CONFORMIDAD: Ésta especificación 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. Además, para estos puntos de cumplimiento, la especificación proporciona la libertad a los implementadores de escoger cualquier combinación de paquetes de meta-modelo y fusión de paquetes que deseen implementar. Sin embargo, si el intercambio de datos es u objetivo importante para un implementador, se alienta la implementación 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 capítulo de especificación como sus clases de meta-modelo respectivo. Por lo tanto un punto de cumplimiento incluye todos los estereotipos definidos en los capítulos que han sido listados para la inclusión en la definición de cada punto de cumplimiento a continuación. Sin embargo, sólo un perfil incluye todos los estereotipos es proporcionado como parte de ésta especificación (OMG document ad/06-11-05).

La especificación proporciona esquemas XMI individual para todos los tres puntos de cumplimiento (OMG document ad/06-11-04). Los puntos de cumplimiento listados aquí están definidos por la inclusión y unión de paquetes de meta-modelo específicos. La siguiente sección 2.1 y 2.2 proporcionan una visión de conjunto a todos los paquetes de meta-modelo disponibles en SPEM 2.0. La sección 2.3 a la sección 2.5 definen los tres puntos de cumplimiento. Finalmente, la sección 2.6 discute otros escenarios de implantación no-conforme que podría ser útil para públicos específicos de SPEM 2.0 2.1. PRINCIPIOS DE DISEÑO Y EMBALAJE GENERAL DE META-MODELO SPEM 2.0: El meta-modelo 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 también el intercambio de diagrama UML 2.0 para la presentación de varios tipos de diagramas tal como se presenta a través de los ejemplos de éste documento y se resume en el capítulo 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 construcción para un implementador de especificación. En otras palabras un implementador o adoptante puede optar por utilizar diferentes niveles de capacidades, números de conceptos, y niveles de formalismo para expresar sus procesos usando o realizando sólo ciertos paquetes de ésta arquitectura. Se definen las tres secciones más comunes como los puntos de cumplimiento de SPEM 2.0, pero también se discuten otras posibilidades de combinar los paquetes de meta-modelo para abordar las necesidades más específicas del modelado de procesos. 2.2. DESCRIPCIÓN 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 mínimos necesarios para definir cualquier proceso de desarrollo de sistemas y software sin adicionar características específicas para disciplinas o dominio particulares de desarrollo (e.g. gestión de proyectos). El objetivo es acomodar una amplia gama de métodos 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 genérico, ni siquiera proporcionar sus propios conceptos de modelado de comportamiento. SPEM 2.0 más bien define la habilidad para el implementador escoger el enfoque de modelado de comportamiento genérico que mejor se adapte a sus necesidades. Este también proporciona estructuras específicas para mejorar esos modelos de comportamiento genérico que son característicos para definir procesos de desarrollo. En otras palabras, SPEM 2.0 se centra en proporcionar las estructuras de información 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 lógicas. Cada unidad se extiende a las unidades de las que ésta depende, proporcionando estructuras adicionales y capacidades a los elementos definidos a continuación. En general, EL paquete UML 2.0 une mecanismos de unión de paquetes realiza una extensión 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 implementación SPEM 2.0 sin las unidades del nivel superior. En muchos casos, las clases de meta-modelo están introducidas en un paquete de nivel inferior lo más simple posible, y están entonces extendidas en unidades de nivel superior vía el mecanismo de unión de paquete con relaciones y propiedades adicionales para realizar procesos más 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: (Núcleo): El paquete de meta-modelo de núcleo contiene las clases y abstracciones del meta-modelo que construyen la base para las clases en todos los demás paquetes de meta-modelo. En otras palabras, todas las clases comunes entre todos los niveles de cumplimiento que definen el núcleo de SPEM 2.0 han sido ubicadas aquí. El núcleo 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 están designadas a asociar a las clases de comportamiento de modelos de comportamiento. (e.g. pueden ser asignadas como estereotipos a actividades o vínculos UML 2.0 para clasificadores de comportamiento )

Estructura de Proceso: Éste paquete define la base para todos los modelos de procesos. Este soporta la creación de modelos de proceso simple y flexible. su núcleo de estructura de datos es un desglose o descomposición de actividades anidadas que mantienen listas de referencia a la realización de clases de rol así como clases de producto de trabajo de entrada y salida para cada actividad. Además, este proporciona mecanismos para la reutilización de procesos tal como el enlace dinámico de patrones de proceso que permite a los usuarios ensamblar procesos con conjuntos de actividades vinculadas dinámicamente. Estas estructuras son usadas para representar procesos básicos y de alto nivel que no están documentados

textualmente. Las estructuras son ideales para el ensamble ad-hoc de procesos, especialmente la representación 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 estático, permitiendo la anidación 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 más bien proporciona "enlaces" a existente modelos de comportamiento definidos externamente, habilitando la reutilización 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 definición del producto de trabajo desde el paquete de contenido de método puede ser vinculado a un modelo de máquina de estado que representa su ciclo de vid típico. El capítulo 7 muestra ejemplos para los modelos de procesos que utilizan el perfil UML 2 definido en ésta especificación para una presentación consistente para tales modelos UML 2, además de los "enlaces" definidos en este paquete de comportamiento de procesos del meta-modelo.

Contenido Gestionado: Los procesos de desarrollo están en muchos casos no sólo representados como modelos, sino documentados y gestionados como descripciones de lenguaje natural. Para muchos enfoques y métodos de desarrollo de software, documentación humano- disponible proporciona orientación comprensible para las mejores prácticas de desarrollo es más importante que los modelos precisos. En otras palabras, la viabilidad de las técnicas y métodos expresados con éstas prácticas 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-evaluación constante y adopción en lugar de una estricta secuencia de actividades. Por ejemplo, para los equipos de desarrollo ágil modernos, las mejores prácticas de desarrollo de software son comunicadas a través de tutoría y descripciones breves de prácticas en formatos white paper en lugar de modelos definidos formalmente. Ellos asumen que ciertos valores y una cultura de desarrollo (en otras palabras la ingeniería social requerida para el desarrollo ágil) no puede ser formalizada con modelos, sino que pueden ser capturados solamente en documentación de lenguaje natural. El paquete de meta-modelo de contenido gestionado introdujo conceptos para la gestión del contenido textual de tal descripción. Estos conceptos pueden utilizarse de forma independiente o en combinación con conceptos de estructura de procesos. Por ejemplo, un proceso basado en SPEM 2.0 podría estar compuesto únicamente de un conjunto de instancias de las orientaciones de meta- clase definiendo las mejores prácticas de desarrollo en formato Whitepaper. Esto podría estar también compuesto de una combinación de estos elementos guías con una estructura de proceso usando relaciones definidas en el paquete meta-modelo de contenido gestionado que permite asociar elementos guías con elementos de estructura de procesos.

Contenido de Método: El paquete contenido de método 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 específicos de desarrollo. Adiciona conceptos para definir ciclos de vida y los elementos de contenido de

método reutilizable independiente del procedimiento que proporciona una base de conocimiento documentado de los métodos de desarrollo de software, técnicas y realizaciones concretas de las mejores prácticas. El contenido de método comprende las explicaciones textuales paso a paso, describiendo como se logran los objetivos de desarrollo fino-granular específicos por cuales roles y con cuales recursos y resultados, independiente de la ubicación de estos pasos dentro de un ciclo de vida de desarrollo específico. Los procesos reutilizaran estos elementos de contenido de método y los relacionara dentro de secuencias parcialmente ordenadas que se adaptan a tipos específicos de proyectos (ver 6.3.1,' Una clara separación de las definiciones del contenido de método desde la aplicación de procesos de desarrollo de contenido de método' para más detalle). Un usuario SPEM 2.0 pueden definir contenido de método como una guía general y construir una base de conocimiento de métodos de desarrollo sin crear un proceso, pero adicionando un poco más de estructura para su contenido proporcionado por las meta- clases genéricas definidas en el paquete de contenido administrado. Estas estructuras seleccionadas para el paquete de contenido de método se han derivado de las mejores prácticas de la industria. Los procesos de desarrollo pueden basarse el contenido de método reutilizable (como se define en el proceso con el paquete meta-modelo métodos), ellos también pueden ser independientes del contenido de método (simplemente usando el paquete de meta-modelo estructura de procesos), definiendo de éste modo procesos ad-hoc que no están basados en métodos reutilizables.

Procesos con Métodos: el paquete de meta-modelo procesos con métodos define nuevas y redefine estructuras existentes para la integración de procesos definidos con conceptos del paquete meta-modelo Estructura de Procesos con instancias de conceptos del paquete de meta-modelo Contenido de Método. Mientras el contenido de método define métodos fundamentales y técnicas para el desarrollo de software, los procesos ubican estos métodos y técnicas dentro del contexto de un modelo de ciclo de vida comprendido. Por ejemplo, de fases e hitos. Al aplicar el contenido de método, como las tareas, roles y productos de trabajo a una parte específica de los procesos, clases de referencia (referido como un uso de contenido de método en ésta especificación) son creadas que puedan almacenar los cambios individuales para sus clases de contenido de método referenciadas. Estos cambios expresan como y cuáles partes del método serán aplicadas en ese punto particular en el proceso.

Plug-in de Método: El paquete de meta-modelo Plug-in de Método introduce conceptos para 'diseñar' y de mantener la gestión, a gran escala, reutilizable y repositorios o bibliotecas configurables de contenido de método y procesos. Los conceptos introducidos en este paquete permiten la organización de diferentes partes de una biblioteca basado en diferentes capas de interés similares a las arquitecturas en capas de software. Con conceptos como Plug-in de método, componente de procesos, y variabilidad, se pueden definir procesos que son extendidos granularmente con más y más capacidades. Los usuarios pueden seleccionar las capacidades de proceso que están interesados mediante la definición de las denominadas configuraciones de método. Solamente estas capacidades seleccionadas aparecerán dentro de estas configuraciones al usuario final, permitiendo a los autores de proceso definir procesos consistentes y fáciles de mantener para los diferentes públicos que son configurables para las necesidades de usuarios finales específicos. 2.3 PUNTO DE CUMPLIMIENTO "SPEM COMPLETO": Público: Proceso a gran escala y proveedores de herramientas de biblioteca de método

El punto de cumplimiento "SPEM Completo" comprende todos los siete paquetes del meta-modelo de SPEM descritos en 2.2, 'Descripción 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 método 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 están descritos en al capítulo 8 al 14 de ésta especificación.

Figura 2.2. Definición 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 método textual y modelos de proceso reutilizable. La atención se centra en la gestión de muchos procesos para organizaciones multi-niveles complejas que administran procesos interrelacionados. También es el punto de cumplimiento que combina el paquete de perfiles de la infraestructura UML 2.0, la cual proporciona un mecanismo de extensibilidad más 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 semánticas a instancias de clase meta, los perfiles de UML permiten además que crear y gestionar instancias de aplicación 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 especificación no requieren realizar perfiles porque los mecanismos de extensibilidad de peso ligero de SPEM deben ser suficientes para los públicos listados, pero los implementadores tienen la opción de hacerlos para estos niveles también. Las herramientas CASE mencionadas en 6.5 'Declaración de prueba de concepto y disponibilidad comercial' implementa estos puntos de cumplimiento. 2.4. PUNTOS DE CUMPLIMIENTO "PROCESO SPEM CON COMPORTAMIENTO Y CONTENIDO":

Público: 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. 'Descripción 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 (Capítulo 10), el cual se combina transitivamente en (ver figura 2.1) estructura de proceso (capítulo 9) y núcleo (Capítulo 8).

Figura 2.3. Definición 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 público 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 método o plug-in de método para proporcionar la descripción de método reutilizable, ni requieren los conceptos de variabilidad que permiten diferentes configuraciones de modelos de variable y texto. Este punto de cumplimiento es también 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 método, escalar, y variabilidad. 2.5. PUNTOS DE CUMPLIMIENTO "CONTENIDO DE MÉTODO SPEM": Público: Documentador de método y autores de libro, proveedor de base de conocimiento organizacional EL método de cumplimiento "Método SPEM" comprende tres de los paquetes del meta-modelo SPEM descrito en sección 2.2. Figura 2.4. muestra que el punto de cumplimiento crea un espacio de nombre llamado "Contenido de método SPEM 2" que combina el nivel de

cumplimiento LM de la biblioteca de infraestructura UML2 así como el contenido de método del paquete del meta-modelo (Capítulo 12) la cual se combina transitivamente en (Capítulo 11) y Núcleo (Capítulo 8).

Figura 2.4. Definición del punto de cumplimiento "Contenido de Método SPEM" Éste punto de cumplimiento está recomendado para implementadores quiénes se enfocan principalmente en la gestión de la documentación de descripciones de métodos de desarrollo, técnicas, y mejores prácticas. Las implementaciones de éste nivel pueden ser usados para crear bases de conocimiento de desarrollo así como servir de estructura para los sistemas de información basados en wiki y otros sistemas de información colaborativos. La audiencia típica de éste nivel en muchos casos no necesita o quiere los modelos de proceso formal como una representación para su contenido. Ellos proporcionan descripciones de sus métodos con un conjunto mínimo de conceptos (que podría 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 guía 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 también ideal para para libros y autores de informe técnico que podrían argumentar su publicación de métodos de desarrollo, técnicas, o mejores prácticas con una documentación basad en contenido de método 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 sección 2.2 a 2.5 especifica tres puntos de cumplimiento de la definición de los niveles más típicos para que los implementadores escojan. Sin embargo, como los paquetes de meta-modelo proporcionan gradualmente más 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 propósitos. Por Ejemplo, se podría escoger para implementar las siguientes combinaciones: (Todas estas combinaciones necesitarían incluir el paquete núcleo. Por esto no ha sido enumerados explícitamente a continuación).

Estructura de Proceso y Comportamiento de Proceso: Un implementador podría escoger proporcionar una solución de modelado pura para SPEM 2.0 o una solución 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 documentación adicional así como de las capacidades de categorización de contenido.

Estructura de Proceso y Contenido Gestionado: Esta combinación 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 documentación textual, el implementador puede escoger implementar esos dos paquetes de meta-modelo solamente. Como un resultado, cada elemento de proceso (Sección 9.1) de una estructura de desglose de proceso puede ser documentado con descripciones de contenido textual (Sección 11.1). Además, los elementos guías textuales (Sección 11.4) tales como listas de chequeo, plantillas, ejemplos, directrices y métricas (Sección 11.5) pueden ser creados y enlazados sistemáticamente a estos elementos de proceso.

Estructura de Proceso, Comportamiento de Proceso y Plug-in de método: Si el enfoque de un implementador está en proporcionar bibliotecas de modelos de proceso reutilizable sin documentar estos modelos de proceso, el implementador podría optar por combinar la estructura de proceso y los paquetes comportamiento del meta-modelo con los paquetes de plug-in de método. Esto permitirá al implementador definir bibliotecas (Sección 14.3) de procesos reutilizables (Sección 9.1) así como extensiones de proceso dinámico usando variabilidad (Sección 14.10) y organizar estos procesos y extensiones en plug-ins configurables (Sección 14.1 y Sección 14.2).

Procesos con Métodos, Estructura de Procesos, Contenido de Método, Contenido Gestionado: Esta combinación sería de interés para un implementador que podría querer proporcionar una realización a pequeña escala de SPEM 2.0. El implementador podría estar interesado en utilizar completamente la separación del contenido de método de los procesos, pero no necesita las capacidades de variabilidad, ni gestionar las bibliotecas de método, plug-ins de método, y configuraciones definidos en el paquete del meta-modelo Plug-in de método.

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 Versión 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 Versión 2 Intercambio de

Diagrama. www.omg.org/uml

4. TÉRMINOS Y DEFINICIONES: No hay definiciones formales en ésta especificación estos son tomados de otros documentos.

5. SÍMBOLOS: No hay símbolos definidos en ésta especificación.

6. INFORMACIÓN ADICIONAL 6.1 ANTECEDENTES Y JUSTIFICACIÓN: Ésta es la tercera especificación definida para el meta-modelo de Ingeniería de procesos de software y sistemas. La especificación 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 acompaña por un DTD XML. El meta-modelo usa UML 1.4 como una notación y toma un enfoque orientado a objetos para representar el comportamiento de los desarrolladores como sus operaciones. SPEM 1.x vio una baja utilización. Desde su emisión, pocas implementaciones se han lanzadas y estas no se han reconocido por los analistas industriales que también fallaron en reconocer su importancia a la metodología y mercado de herramientas de proceso. Allí ha habido un número de bajo perfil o adoptantes casuales de la especificación así como pocas implementaciones comerciales. Se sospecha que la facilidad de adopción ha sido un problema y algunas de las semánticas de SPEM 1.x fueron ambiguas y difíciles de entender por los adoptantes y por lo tanto no usados en sus prácticas. Ahora que las revisiones importantes al subyacente estándar UML han sido desarrolladas en UML 2, son muchos los beneficios que se cosecharon en SPEM. UML 2 incluye nuevas características tales como técnicas de modelado mejoradas grandemente, y capacidad de intercambio de gráficos, las cuáles son de uso obvio en modelado de proceso. Además, UML 2 está organizado de una forma más modular para permitir especificaciones relacionadas para reutilizar solamente las partes necesaria del meta-modelo UML. La capacidad de aprovechar estas características, así como la capacidad para trabajar con las herramientas UML 2 son potentes mejoras a SPEM 2.0. Además, No había retroalimentación específica de los implementadores de SPEM 1.x que se han dirigido para hacer modelos de procesos de SPEM más fácil de adoptar y automatizar. Ésta especificación trata los siguientes requerimientos del RFP: o Actualizar SPEM para cumplir con UML 2, tomando ventaja de la nueva funcionalidad

para mejorar las capacidades y técnicas de modelado de proceso. o Definir un nuevo esquema SPEM XML, basado en MOF. Los esquemas XML

proporcionan una mayor riqueza y control más allá de lo que está disponible en el DTD XMI de SPEM 1.1.

o Proporcionar orientación sobre la migración de modelos de procesos existentes de SPEM 1.1 a SPEM 2.0.

o 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.

o Definir extensiones a SPEM que serán de utilidad para procesar herramientas de automatización.

o Alinear SPEM con la evolución y las nuevas normas que no sean UML; específicamente, el meta-modelo de definición de procesos de negocio y las interfaces en tiempo de ejecución de proceso de negocio se pueden usar en conjunto con SPEM para proporcionar un mayor valor a la comunidad de usuarios.

o Introducir extensiones del meta-modelo procesos que pueden ser usadas igualmente en procesos de desarrollo de software y procesos de ingeniería de sistemas.

6.2 INTRODUCCIÓN GENERAL A SPEM 2.0: A lo largo de la industria del software hay un montón de grandes ideas y conocimiento disponible acerca de cómo desarrollar software eficientemente. Hoy en día, Los equipos de desarrollo necesitan y tienen acceso a un amplio

rango de información. No sólo necesitan adquirir información detallada acerca de tecnologías específicas de desarrollo tales como Java, Java EE, Eclipse, tecnologías SOA, .Net, así como diversos entornos e desarrollo y herramientas, sino que también necesitan descifrar como organizar sus trabajos a lo largo de las mejores prácticas 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 información para ellos mismo son: o Los miembros del equipo no tendrán acceso sencillo y centralizado al mismo cuerpo de

información cuando ellos la necesitan, es decir, diferentes desarrolladores pueden confiar en diferentes fuentes y versiones de la misma información.

o Es difícil combinar e integrar los contenidos y procesos de desarrollo que se ponen a disposición en su propio formato de propietario, como todo libro y publicación presenta el contenido y proceso de método usando una representación y un estilo de presentación diferente.

o Es difícil definir un enfoque de desarrollo sistemático y organizado que es del tamaño adecuado a sus necesidades, es decir, se dirige a su cultura específica, prácticas estandarizadas, y requerimientos de cumplimiento.

El meta-modelo de Ingeniería de Procesos de Sistemas y Software (SPEM) es un meta-modelo de ingeniería de procesos así como el marco conceptual, el cual proporciona los conceptos necesarios para modelar, documentar, presentar, gestionar, intercambiar y promulgar métodos de desarrollo y procesos. Una implementación de éste modelo está dirigida a los ingenieros de proyecto, conductores de proyecto, gerentes de programa y proyecto quiénes 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 implementación SPEM 2.0:

Proporcionar una representación estandarizada y bibliotecas gestionadas de contenido de método reutilizable: Los desarrolladores necesitan entender los métodos y prácticas claves de desarrollo de software. Ellos necesitan familiarizarse con las tareas de desarrollo básico, tales como la forma de obtener y gestionar los requerimientos, como hacer el análisis y diseño, la manera de implementar un diseño 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 más importante, su contenido consistente en su propia cosecha. Por ejemplo, definiciones de método, whitepapers, directrices, plantillas, principios, mejores prácticas, procedimientos internos, regulaciones, material de entrenamiento, o cualquier otra descripción general de cómo desarrollar software. Esta base de conocimiento se puede usar como referencia y para la educación y constituir la base para los procesos de desarrollo. (Véase el inciso siguiente).

Apoyar el desarrollo sistemático, gestión y desarrollo de procesos de desarrollo: Los equipos de desarrollo necesitan definir cómo aplicar sus métodos de desarrollo y mejores prácticas a lo largo del ciclo de vida del proyecto. En otras palabras, necesitan definir o seleccionar procesos de desarrollo. Por ejemplo, los métodos de gestión de requerimientos tienen que ser aplicados en una manera durante las fases iniciales de un proyecto, donde el enfoque se centra más en la obtención de las necesidades y requerimientos de los interesados (Stakeholders) y el alcance de una visión. Los mismos métodos tienen que ser realizados de una manera diferente durante las fases posteriores. Donde el enfoque se centra en la gestión de actualizaciones y cambios de requerimientos y la realización de análisis del impacto de los cambios de estos requerimientos. Los mismos métodos de requerimientos también 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 distribución. Un modelo de proceso de desarrollo necesita soportar expresar estas diferencias. Los equipos también necesitan un claro entendimiento de como las diferentes tareas dentro de los métodos se relacionan entre sí. Por ejemplo, como el método de gestión de cambio impacta el método de gestión de requerimiento, así como el método de prueba de regresión durante todo el ciclo de vida. SPEM 2.0 soporta la creación sistemática de procesos basados en contenido de método reutilizable. El contenido de método independiente del ciclo de vida se puede colocar dentro de uno específico para un ciclo de vida de desarrollo específico. Tales procesos se pueden representar como flujos de trabajo y/o estructuras de desglose (descomposición). Dentro de estos procesos el contenido de método reutilizado puede entonces refinarse para su contexto específico. SPEM 2.0 también proporciona la base conceptual para los ingenieros de procesos y gerentes de proyecto para selección, diseño y rápido montaje de los procesos para sus proyectos de desarrollo concretos. La visión de SPEM es que los vendedores puedan vender con sus catálogos de implementación SPEM 2.0 de procesos predefinidos para situaciones típicas de proyecto que se pueden ser adaptar a necesidades individuales. Dentro de estos catálogos, la implementación ofrece bloques de construcción de procesos o patrones de procesos que representan procesos de referencia para disciplinas, tecnologías o estilos de desarrollo específicos. Estos patrones de proceso forman un conjunto de herramientas para ensamblar rápidamente los procesos basados en las necesidades específicas del proyecto.

Apoyar el despliegue de sólo el contenido de método y el proceso necesario para definir las configuraciones del contenido de método y procesos: Ningún 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 características diferentes para la definición de proceso así como la promulgación en una organización o proyecto para cada nivel. Por ejemplo, CMMI define un "proceso gestionado" como actividades realizadas que se pueden reconocer como implementaciones de prácticas de desarrollo. Tal proceso tiene ciertas características: Es planificado y ejecutado de acuerdo a políticas, emplea a personas calificadas, cuenta con recursos suficientes para producir salidas controladas, involucra stakeholders relevantes, es monitoreado, controlado, y revisado; y se evalúa la adherencia a su descripción de proceso. Por el contrario, un "proceso definido" es un proceso gestionado que se adapta desde el conjunto de procesos estándar de la organización de acuerdo a las directrices de adaptación de la organización. Un proceso definido tiene una descripción del proceso de mantenimiento y contribuye productos de trabajo, medidas, y otra información de mejora de procesos a los activos de proceso de la organización. Las nociones de actividad de uso, configurabilidad, y variabilidad para procesos de desarrollo (así como contenido de método) en SPEM 2.0 exactamente frente a las necesidades de los procesos definidos. Estos conceptos proporcionan capacidades para la reutilización 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 estándar reutilizados. Por lo tanto, el escenario de uso de SPEM es que las organizaciones puedan proporcionar bibliotecas de procesos y métodos reutilizables usando las capacidades descritas en los dos primeros puntos. Los jefes de equipo pueden seleccionar y diseñar el contenido de método y procesos que ellos requieren. A continuación pueden describir estas selecciones y personalizaciones con un método de configuración de SPEM. Que pueden desplegar a sus equipos solo proporcionando el contenido que ellos realmente necesitan.

Apoyar la promulgación de un proceso para proyectos de desarrollo: Una definición de proceso sólo proporciona valor si impacta y dirige el comportamiento de los equipos de desarrollo. Los procesos así como las necesidades del método de contenido dirigidas estarán disponibles en el concepto de trabajo diario de los directores de proyecto, jefes técnicos y desarrolladores. Por lo tanto, es necesario desplegar en formatos que están listos para su promulgación con los sistemas de procesos de promulgación de las elecciones del equipo. Los sistemas de promulgación comunes son proyectos y sistemas de planeación de recursos, sistemas de seguimientos de trabajos pendientes, y motores de flujo de trabajo. SPEM 2.0 proporciona estructuras de definición 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 definición de proceso SPEM 2.0 puede incluir información que indique que las definiciones de modelado de trabajo se repiten varias veces en un proyecto (iteraciones de modelado) o que puede haber múltiples ocurrencias de definiciones de trabajo que pueden ser realizados en paralelo. Aunque, el meta-modelo SPEM 2.0 se ha diseñado entorno al apoyo para este marco de trabajo, muchos otros escenarios útiles pueden ser realizados también. Por ejemplo, el capítulo 2 define diferentes puntos de cumplimiento y analiza diferentes escenarios de aplicación que podría realizar una variación de los escenarios representados en la figura 6.1.

6.3 NUEVAS CAPACIDADES CLAVE DE SPEM 2.0: Además de abordar los requisitos RFP enumerados anteriormente, ésta especificación proporciona las siguientes nuevas capacidades para los autores de proceso. 6.3.1. Una clara separación de las definiciones de contenido de método desde la aplicación de proceso de desarrollo de contenido de método: Como se indica en la sección 6.2, SPEM 2.0 separa el contenido de método reutilizable de su aplicación en los procesos. El contenido de método proporciona explicaciones paso a paso, describiendo como los objetivos específicos de desarrollo se logran independiente de la colocación de estos pasos dentro un ciclo de vida de desarrollo. Los procesos toman estos elementos de contenido de método y los relaciona dentro de unas secuencias ordenadas parcialmente que se adaptan a proyectos de tipo específico. Por ejemplo, un proyecto de desarrollo de software que desarrolla una aplicación desde cero lleva a cabo tareas de desarrollo tales como "encontrar actores y casos de uso", "Visión de desarrollo", o "Diseño de casos de uso" similarmente a un proyecto que amplía un sistema de software existente. Sin embargo, los dos proyectos realizarán las tareas en diferentes puntos en el tiempo con un énfasis diferente, es decir, realizaran los pasos de estas tareas diferentemente, asumirán diferentes entradas, y quizás aplicarán variaciones y adiciones individuales.

Figura 6.2 - Aplicar el mismo contenido de método (Izquierdo) en diferentes procesos (derecha) y diferentes partes de la estructura de descomposición del mismo proceso

(superior-derecha).

La figura 6.2 representa un ejemplo de una implementación SPEM 2.0. Esto demuestra que SPEM 2.0 permite a cada proceso sobre el lado derecho referenciar el contenido de método común, como las definiciones de roles, tareas y productos de trabajo, así como la orientación general de un pool de contenido de método común representada a la derecha. Estas referencias dan cuenta de la trazabilidad de los procesos a su contenido de método subyacente, permitiendo que los cambios en los métodos se reflejen en todos los procesos que lo usan. Por otra parte, SPEM 2.0 permite aún remplazar ciertos métodos relacionados al contenido dentro de un proceso así como definir relaciones específicas 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. Definición de contenido de método vs la Aplicación de contenido de método en un proceso.

La figura 6.3. (tomada del proceso unificado) muestra la diferencia entre contenido de método y proceso representándolos como dos dimensiones diferentes. El contenido de método 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 cómo los objetivos específicos de desarrollo se logran. En un proceso, las definiciones de tareas se seleccionan del contenido de método y se ubican dentro de flujos de trabajo como usos de tarea listos para instanciación. La instanciación asignaría recursos para realizar el trabajo y asignar productos de trabajo real como las entradas y salidas de las tareas. Los gráficos 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 presentación alternativa para el Contenido de Método vs Proceso.

La figura 6.4 muestra una presentación alternativa (tomado de Fujitsu Macroscope) para la separación del contenido de método de los procesos. Muestra como la definición y estructura del contenido de método común (entregables y roles clave) son usados por una variedad de procesos estándar. U n proceso determina el alcance y nivel de detalle de los entregables y organiza su producción por roles clave.

Figura 6.5. Terminología clave definida en esta especificación Mapeada a el contenido de método vs proceso.

La figura 6.5 proporciona una visión general de cómo los conceptos claves definidos en esta especificación están posicionados para representar el contenido de método o proceso. El contenido de método está expresado principalmente usando definiciones del producto de trabajo, definiciones de rol, definiciones de tarea, y guías. Las guías como directrices, whitepapers, listas de chequeo, ejemplos o hojas de ruta, están definidas en la intersección del método de contenido y el proceso, porque las guías pueden ser definidas para proporcionar los antecedentes ( fondo) para el contenido de método así como para procesos específicos (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 también gestionan referencias al contenido de método. Estas referencias están 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 sustitución de una actividad representada en color azul y actividades suprimidas en color gris.

La meta de SPEM 2.0 no es sólo soportar la representación de un proceso de desarrollo específico 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 semánticas como aspectos de orientación así como conceptos para patrones de proceso y el así llamado plug-in de método. Este permite a un ingeniero de

proceso mantener familias consistentes de procesos, que por un lado son específicos a un tipo específico de proyecto y por otro lado también son variaciones del mismo método base y contenido de proceso. Los resultados son diferentes variantes de procesos específicos basados en el mismo núcleo de contenido de método 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 pequeños proyectos.

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

La figura 6.7 muestra otro ejemplo de proceso (tomado de Fujitsu’s 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 botón de activación + / - 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 descripción 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 común para representar cualquiera de estos ciclos de vida.

Una especificación genérica 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 planeación basada en procesos. El meta-modelo SPEM 2.0 está diseñado para dar cabida a múltiples enfoques. Este proporciona un conjunto amplio de atributos de personalización para especificar la guía 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 número de iteraciones definidas por el usuario, necesarias para una situación de proyecto específico. Adicionalmente, SPEM 2.0 proporciona alternativa, pero mantuvo constantemente, formalizaciones de presentación de proceso tales como estructuras de desglose vs diagramas de flujo. Esto permite al ingeniero de proceso escoger la presentación de su preferencia que mejor se ajusta al modelo de ciclo de vida utilizado.

Figura 6.9. Un proceso ágil en macroscópico. É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 método extendiendo contenido de método y procesos con capacidades adicionales.

SPEM 2.0 define plug-ins de método proporcionando capacidades para adaptar y personalizar contenido de método sin modificar directamente el contenido original. En cambio, los plug-ins sólo definen las diferencias (aportes, sustituciones, supresiones) en relación al original. SPEM 2.0 soporta mecanismos de plug-in para el contenido de método así como los procesos representados como estructuras de desglose. SPEM 2.0 es compatible con la definición de las contribuciones y sustituciones en una estructura de desglose sin modificarlo directamente, sino mediante la creación de un plug-in a la misma. 6.3.5. PATRONES DE PROCESO REUTILIZABLE DE MEJORES PRÁCTICAS PARA EL MONTAJE DE PROCESO RAPIDO

Figura 6.11. Un patrón de proceso aplicado tres veces a un proceso; cada uno con modificaciones individuales.

Los patrones de proceso de SPEM 2.0 son bloques de construcción reutilizables para crear nuevos procesos de desarrollo. Seleccionar y aplicar un patrón de proceso se puede hacer en una de varias maneras posibles.

Un patrón se puede aplicar en una copia sofisticada y modificar la operación, lo cual permite

al ingeniero de proceso personalizar individualmente el contenido del patrón a sus necesidades durante la aplicación del patrón.

SPEM 2.0 soporta la aplicación de patrones a través de los mecanismos de actividad de uso, lo cual es una forma de reutilizar las estructuras de proceso de actividades que re-ocurren comúnmente. 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 patrón está siendo revisado o actualizado, todos los cambios se reflejan automáticamente en todos los procesos que aplican ese patrón.

6.3.6. COMPONENTES DE PROCESO REUTILIZABLE Y REMPLAZABLE REALIZANDO LOS PRINCIPIOS DE ENCAPSULACIÓN

Figura 6.12. Componentes de proceso conectados vía 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 ejecución en sí mismo. (por ejemplo en situaciones de externalización).

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 definición real del trabajo que producen las salidas como una "caja negra". En cualquier momento durante un proyecto, el componente "realización" detalla el trabajo que puede ser adicionado al proceso. El enfoque de componentes también permite diferentes estilos o técnicas de hacer el trabajo para ser remplazado con otros. Por ejemplo, una salida de código de software de un componente se puede producir con desarrollo orientado al modelo o la técnica de centrado en el código. El concepto de componente encapsula el trabajo real y permite al equipo de desarrollo escoger la técnica apropiada. Éste permite al equipo completar la realización del componente con la elección de las actividades que producen las salidas requeridas.

6.4. FORMALISMO DE ESPECIFICACIÓN

Esta especificación documenta el meta-modelo de ingeniería de procesos de sistemas y software 2.0 (meta-modelo SPEM 2.0) y el perfil UML 2 del meta-modelo de ingeniería de procesos de sistemas y software (perfil SPEM 2.0). El meta-modelo de ingeniería de proceso SPEM 2.0 describe las estructuras necesarias para mantener y expresar formalmente el contenido de método de desarrollo y los procesos, es decir, describe un lenguaje y esquema de representación para contenidos de método y procesos. Un meta-modelo por sí mismo es expresado usando lenguaje de meta-modelo (es decir, un meta-meta-modelo). El MOF (especificación de modelado - Meta-Object Facility) estándar [MOF 2.0] proporciona un lenguaje aplicando y extendiendo el UML [UML 2], es decir, describe cómo 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 meta-modelo

Este documento proporciona un MOF 2.0 compatible con la especificación 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 instanciación del formalismo usado para ésta especificación. 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 método" 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 método" representa un modelo de método. Por ejemplo, SPEM 2.0 define los conceptos de roles, tareas y artefactos así como las relaciones entre ellos.

La biblioteca de método 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 "catálogo de navegación" 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 métodos 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 están basadas en las definiciones del UML 2. Por ejemplo, los elementos de núcleo de SPEM 2.0 tales como "Elemento de proceso" y "paquete de método" se han derivado a través de la especialización de clases de la biblioteca de infraestructura de UML 2 heredando las relaciones que permiten la definición de paquetes y elementos encapsulables. SPEM 2.0 también reutiliza paquetes de la superestructura UML 2 tal como paquetes de actividades UML 2.

El meta-modelo UML 2 tiene una implementación de referencia

El meta-modelo SPEM 2.0 puede ser directamente instanciado para una implementación, 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 método 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 representación alternativa al meta-modelo SPEM 2.0

Además de representar una biblioteca de método como "Biblioteca de método A" con estas estructuras, creando su propia implementación de estas clases (por ejemplo, usando las clases javas mencionadas anteriormente) se puede también 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 extensión 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 declaración de estereotipo para un artefacto ampliando el concepto de clase de UML 2. Una instancia en la capa M1 sería una clase UML 2 que tiene este estereotipo asignado. Una instancia M0 seguiría el mismo aspecto. La única diferencia es la representación 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 métodos y procesos, pero podría usar una herramienta de modelado UML 2 genérica para hacerlo. La desventaja de éste enfoque es que tal herramienta de modelado UML 2 sería muy genérica y que todas las reglas de estructuración específicas definidas en el meta-modelo SPEM 2.0 como simples relaciones necesitarían ser forzadas con complicadas restricciones OCL, limitando al usuario mucho más que cuando modela con UML. Por ejemplo, restringir el número de asociaciones que una tarea puede tener con roles cuando un estereotipo específico es aplicado forza la restricción simple de un rol de ejecución principal para una tarea. Forzar todas las reglas básicas de SPEM 2.0 en restricciones OCL resultaría en que el usuario de la herramienta trata con interacciones y mensajes de error OCL muy genéricos, lo que resulta en una mala experiencia de usuario.

SPEM 2.0 define un meta-modelo así como un perfil UML

Sin embargo, la especificación proporciona definiciones para ambas representaciones:

El meta-modelo SPEM 2.0: define todas las estructuras y reglas de estructuración 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 también define la notación de diagramas de proceso específico.

El perfil UML de SPEM 2.0: define un conjunto de estereotipos UML 2 que permiten presentar métodos y procesos SPEM 2.0 usando el UML 2. Sin embargo, la definición de estos estereotipos en esta especificación sólo cubren su presentación, pero se basa en el meta-modelo SPEM 2.0 para todas las definiciones y restricciones semánticas. En otras palabras, esta versión del perfil no contiene ninguna restricción OCL, sino que depende de las semánticas del meta-modelo SPEM 2.0 para definir todas sus restricciones.

Cada sección de definición de conceptos se define ambas representaciones.

6.5. DECLARACIÓN DE PRUEBA DE CONCEPTO Y DISPONIBILIDAD COMERCIAL

Las partes principales de ésta especificación que se han implementado son de libre acceso en el código 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 tecnología. Hay varias organizaciones y compañías que han anunciado que van a modelar sus procesos libres o comerciales con ésta tecnología. Algunas de éstas son Process Group, Open Group, Number Six Software, y Telelogic.

Hay también un producto comercial disponible de IBM que se ha construido en la parte superior de ésta implementación de código abierto. Un gran número 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 implementación y están o estarán disponibles para la compra. Ver anexo C para ejemplos de estos procesos.

Otros autores de ésta especificación tales como Adaptive y Fujitsu han expresado su intención de implementar ésta especificación y representar sus procesos con los conceptos de ésta especificación dentro de un año después de la adopción.

6.6. CAMBIOS A LAS ESPECIFICACIONES OMG ADOPTADAS

Esta especificación sustituye completamente la especificación SPEM adoptada versión 1.1, formal 05-01-06

6.7. COMO LEER ESTA ESPECIFICACIÓN

Aunque los capítulos se organizan de una manera lógica y se puede leer secuencialmente, ésta es una especificación de referencia destinada a ser leída de una manera no secuencial. Por consiguiente, las extensas referencias cruzadas son proporcionadas para facilitar la navegación y búsqueda. El capítulo 2.1. proporciona una descripción detallada a la organización del meta-modelo SPEM y su presentación en los capítulos siguientes. Los capítulos 7 al 14 siguen ésta estructura y presentan el contenido de los paquetes del meta-modelo uno por uno. Los capítulos 15 al 18 proporcionan información básica 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 especificación:

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

Las siguientes empresas apoyaron ésta especificación: 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