SPEM - Software & Systems Process Engineering Metamodel Specification

Transcripción

1 SPEM - Software & Systems Process Engineering Metamodel 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/ ). La especificación proporciona esquemas XMI individual para todos los tres puntos de cumplimiento (OMG document ad/ ). 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 noconforme que podría ser útil para públicos específicos de SPEM PRINCIPIOS DE DISEÑO 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 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.

2 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 metamodelo para abordar las necesidades más específicas del modelado de procesos 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.

3 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 metamodelo. 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

4 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

5 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

6 El punto de cumplimiento "SPEM Completo" comprende todos los siete paquetes del metamodelo 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 PUNTOS DE CUMPLIMIENTO "PROCESO SPEM CON COMPORTAMIENTO Y CONTENIDO":

7 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 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 metamodelo 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

8 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 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 metamodelo 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

9 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, plugins 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. [Infraestructura UML 2] OMG, Especificaciones de la infraestructura UML 2. [Diagramas UML 2] OMG, Lenguaje de Modelado Unificado Versión 2 Intercambio de Diagrama 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 metamodelo de Ingeniería de procesos de software y sistemas. La especificación de SPEM 1.0 fue

10 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

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

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

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

14 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 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 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

15 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).

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

17 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 MANTENIMIENTO CONSTANTE DE MUCHOS PROCESOS DE DESARROLLO ALTERNATIVO Figura 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

18 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 MUCHOS DE LOS DIFERENTES MODELOS DE CICLO DE VIDA

19 Figura 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 VARIABILIDAD DE PROCESO FLEXIBE Y EXTENSIBILIDAD DEL MECANISMO PLUG-IN

20 Figura 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 plugins 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 PATRONES DE PROCESO REUTILIZABLE DE MEJORES PRÁCTICAS PARA EL MONTAJE DE PROCESO RAPIDO

21 Figura 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 COMPONENTES DE PROCESO REUTILIZABLE Y REMPLAZABLE REALIZANDO LOS PRINCIPIOS DE ENCAPSULACIÓN