SPEM - Software & Systems Process Engineering Metamodel Specification

Save this PDF as:
 WORD  PNG  TXT  JPG

Tamaño: px
Comenzar la demostración a partir de la página:

Download "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. 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 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

SOFTWARE & SYSTEMS PROCESS ENGINEERING METAMODEL SPECIFICATION V.20 SPEM 2.0

SOFTWARE & SYSTEMS PROCESS ENGINEERING METAMODEL SPECIFICATION V.20 SPEM 2.0 SPEM 2.0 SOFTWARE & SYSTEMS PROCESS ENGINEERING METAMODEL SPECIFICATION V.20 SPEM 2.0 Metamodelo para modelos de procesos de ingeniería de software y de ingeniería de sistemas. La idea central de SPEM

Más detalles

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola BPMN vs UML Autor: Norberto Figuerola Los Requerimientos y el Modelo del Negocio Normalmente, siempre que iniciamos un esfuerzo de desarrollo de software éste tiene como objetivo automatizar procesos del

Más detalles

Desarrollo de software

Desarrollo de software Agenda 1. Introducción 2. Aspectos Metodológicos del Desarrollo de Software 3. Aplicación Web (Modelo del Producto) 4. Modelo del proceso 5. Dos enfoques Metodológicos 6. Métodos Seleccionados 7. Evaluación

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen A través de este artículo se ofrece un panorama amplio y de alto nivel sobre la especificación y los diferentes diagramas del Lenguaje

Más detalles

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

Más detalles

PROCESOS SOFTWARE. Según esta estrategia, todo proceso debe planificarse, implantarse y evaluarse, para luego actuar sobre él.

PROCESOS SOFTWARE. Según esta estrategia, todo proceso debe planificarse, implantarse y evaluarse, para luego actuar sobre él. PROCESOS SOFTWARE MOTIVACIÓN? Con independencia de la metodología o modelo implementado, es común la estrategia para la mejora continua de la calidad, basada en el Círculo de Deming o Plan, Do, Check,

Más detalles

Diagrama de Clases. Diagrama de Clases

Diagrama de Clases. Diagrama de Clases Diagrama de Clases 1 Diagrama de Clases El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

Ingeniería de Software en SOA

Ingeniería de Software en SOA Ingeniería de Software en SOA ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Ingeniería de Software en SOA Curso 2014/2015 1 / 51 Índice 1 Directrices para la IS en SOA 2 Modelo de referencia

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

Boletín de Asesoría Gerencial* Business Process Management (BPM)

Boletín de Asesoría Gerencial* Business Process Management (BPM) Espiñeira, Sheldon y Asociados * No. 11-2009 *connectedthinking Contenido Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección

Más detalles

BPMN BPMN BPMN. BPD Objetos de flujo - Actividades. BPD (Business Process Diagram) Notación de modelado de procesos de negocio BPD

BPMN BPMN BPMN. BPD Objetos de flujo - Actividades. BPD (Business Process Diagram) Notación de modelado de procesos de negocio BPD BPMN Notación de modelado de procesos de negocio BPMN Fue desarrollado por la BPMI (Business Process Management Initiative) Objetivos: Proveer una notación entendible para cualquiera desde el analista

Más detalles

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición.

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición. Glosario Aclaraciones Los conceptos del glosario están ordenados alfabéticamente. Un concepto puede ser un único término como meta o una frase como ambiente de ingeniería de software centrado en procesos.

Más detalles

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Proceso de Negocio (Business Process) Conjunto estructurado, medible de actividades para producir un producto.

Más detalles

RESUMEN DE COBIT 4.1. Los recursos de TI identificados en COBIT se pueden definir como sigue [2]:

RESUMEN DE COBIT 4.1. Los recursos de TI identificados en COBIT se pueden definir como sigue [2]: RESUMEN DE COBIT 4.1 COBIT es un marco de trabajo y un conjunto de herramientas de Gobierno de Tecnología de Información (TI) que permite a la Gerencia cerrar la brecha entre los requerimientos de control,

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

Ingeniería de Procesos Software Francisco Ruiz

Ingeniería de Procesos Software Francisco Ruiz Ingeniería de Procesos Software Francisco Ruiz Universidad de Cantabria Calidad de Procesos y Productos Software Julio-2010 Objetivos Conocer los principios e importancia de la IPS. Comprender el interés

Más detalles

Planeación del Proyecto de Software:

Planeación del Proyecto de Software: Apéndice A. Cuestionarios del Sistema Evaluador Nivel2. Requerimientos de Administración: Goal 1: Los requerimientos del sistema asociados a software están bien controlados y existe un estándar para los

Más detalles

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre Cenditel, Mayo 2011 Licencia de Uso Copyright (c) 2010, Alvarez J., Solé S., Briceño R., Fundación CENDITEL. La Fundación CENDITEL

Más detalles

Gestión y Desarrollo de Requisitos en Proyectos Software

Gestión y Desarrollo de Requisitos en Proyectos Software Gestión y Desarrollo de Requisitos en Proyectos Software Ponente: María Jesús Anciano Martín Objetivo Objetivo Definir un conjunto articulado y bien balanceado de métodos para el flujo de trabajo de Ingeniería

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software Tabla de Contenidos PARTE I INTRODUCCIÓN Capítulo 1: Evolución Los hitos en la evolución histórica del Desarrollo de Software Problemas y soluciones... Fallas, malas estimaciones

Más detalles

DISEÑO DE COMPONENTES DE SOFTWARE *

DISEÑO DE COMPONENTES DE SOFTWARE * DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP * Resumen del capítulo 10 de libro de [Pressman 2010] V:18-11-2008 (c) P. Gomez-Gil, INAOE.

Más detalles

Definición de PMO Características de una PMO

Definición de PMO Características de una PMO Definición de PMO Existen varios conceptos de una oficina de proyectos (PMO) una de ella la define como una unidad organizacional, física o virtual, especialmente diseñada para dirigir y controlar el desarrollo

Más detalles

Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos requeridos para crearlos (ejemplo: el compilador) Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción

Más detalles

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Jorge Bozo jbozo@inf.ucv.cl Escuela de Ingeniería Informática Universidad Católica de Valparaíso Valparaíso, Chile

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software IX Contenidos Prólogo... XIX Prefacio... XXI Guía de lectura...xxiii Parte I - Introducción Capítulo 1 - Evolución 1.1 Introducción... 2 1.2 Los hitos en la evolución histórica del desarrollo de software...

Más detalles

Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002. Introducción al Diseño de Software

Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002. Introducción al Diseño de Software Principio de Diseño Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002 Introducción al Diseño de Software Qué es el diseño? Representación ingenieril

Más detalles

GeneXus BPM Suite X. Última actualización: 01 de Setiembre de 2008

GeneXus BPM Suite X. Última actualización: 01 de Setiembre de 2008 Última actualización: 01 de Setiembre de 2008 Copyright Artech Consultores S. R. L. 1988-2008. Todos los derechos reservados. Este documento no puede ser reproducido en cualquier medio sin el consentimiento

Más detalles

Eclipse Process Framework Composer EPFC, es un editor de procesos gratuito que sirve para editar fragmentos de método, procesos o metodologías y

Eclipse Process Framework Composer EPFC, es un editor de procesos gratuito que sirve para editar fragmentos de método, procesos o metodologías y Eclipse Process Framework Composer EPFC, es un editor de procesos gratuito que sirve para editar fragmentos de método, procesos o metodologías y generar automáticamente la documentación en formato para

Más detalles

Entidad Formadora: Plan Local De Formación Convocatoria 2010

Entidad Formadora: Plan Local De Formación Convocatoria 2010 Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto.

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICES En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICE 1. Herramientas Las herramientas que se usaron en el análisis, desarrollo

Más detalles

Arturo Cepeda Pérez. Software Engineering Tutor

Arturo Cepeda Pérez. Software Engineering Tutor Software Engineering Tutor M A N U A L D E U S U A R I O Tabla de contenidos 1. Software Engineering Tutor... 1 2. Entorno... 2 2.1. Vista Modelo... 3 2.2. Vista Diagrama... 4 2.3. Vista Propiedades...

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo

Más detalles

Herramientas de Software que posibilitan el BPM

Herramientas de Software que posibilitan el BPM Qué es BPM? BPM (Business Process Management) no es solamente una tecnología, sino en términos generales, una disciplina gerencial que trata a los procesos como bienes tangibles que contribuyen al desempeño

Más detalles

IBM Rational Software Architect V8.0.1 ofrece nuevos e innovadores enfoques para desarrollar arquitecturas de solución

IBM Rational Software Architect V8.0.1 ofrece nuevos e innovadores enfoques para desarrollar arquitecturas de solución con fecha de 14 de diciembre de 2010 IBM Rational Software Architect V8.0.1 ofrece nuevos e innovadores enfoques para desarrollar arquitecturas de solución Tabla de contenidos 1 Visión general 1 Fecha

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

MANUAL DE REFERENCIA

MANUAL DE REFERENCIA GOBIERNO DE CHILE MINISTERIO DE HACIENDA Dirección de Presupuestos MANUAL DE REFERENCIA GUÍA PARA IMPLEMENTACIÓN ISO 9001:2000 SISTEMA DE CAPACITACIÓN Versión 05 Diciembre 2008 INDICE Introducción... 3

Más detalles

Modelo de calidad IT Mark

Modelo de calidad IT Mark Modelo de calidad IT Mark Agenda de Trabajo 1. Área de Calidad 2. Introducción IT Mark 3. Proceso del Negocio 3.1 Ten Square. 3.2 Evaluación 3.3 Evidencias 3.4 Presentación de resultados. 4. Proceso de

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S4 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

Más detalles

Implantación y Aceptación del Sistema

Implantación y Aceptación del Sistema y Aceptación del Sistema 1 y Aceptación del Sistema ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD IAS 1: ESTABLECIMIENTO DEL PLAN DE IMPLANTACIÓN...5 Tarea IAS 1.1: De finición del Plan de... 5 Tarea IAS

Más detalles

Casos de Uso Diagramas de Casos de Uso. Universidad de los Andes Demián Gutierrez Abril 2011 1

Casos de Uso Diagramas de Casos de Uso. Universidad de los Andes Demián Gutierrez Abril 2011 1 Casos de Uso Diagramas de Casos de Uso Universidad de los Andes Demián Gutierrez Abril 2011 1 Casos de Uso ( Qué es un caso de uso?) Caso de Uso? 2 Casos de Uso ( Qué es un caso de uso?) Un caso de uso

Más detalles

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reutilizable Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Objetivos Para explicar los beneficios del software reutilizable y algunos de sus problemas Para discutir

Más detalles

BPM: Articulando Estrategia, Procesos y Tecnología

BPM: Articulando Estrategia, Procesos y Tecnología BPM: Articulando Estrategia, Procesos y Tecnología Resumen: La competitividad es el imaginario que dirige las acciones empresariales en la actualidad. Lograr condiciones que permitan competir con mayores

Más detalles

Inventario de Ne gocio

Inventario de Ne gocio Gobierno Corporativo, Gestión del Riesgo y Gestión del Cumplimiento, son las tres visiones que integralmente conforman el marco conceptual ORCA Software GRC Suite. La plataforma provee mecanismos para

Más detalles

Sinopsis de la gestión de programas de acuerdo con el estándar del Project Management Institute 1

Sinopsis de la gestión de programas de acuerdo con el estándar del Project Management Institute 1 Sinopsis de la gestión de s de acuerdo con el estándar del Project Management Institute Conceptos básicos Qué es un? Es un grupo de proyectos gestionados de modo coordinado para obtener beneficios y el

Más detalles

WebRatio. Otro camino para el BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. Otro camino para el BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio Otro camino para el BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 El BPM El BPM (Business Process Management) no es solo una tecnología, además a grandes rasgos es una disciplina

Más detalles

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio). 1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

MODELADO DE OBJETOS DE DATOS

MODELADO DE OBJETOS DE DATOS Manual Página Web MODELADO DE OBJETOS DE DATOS MANUALES ESPECIALES Documento: Manual Páginas Web (SemanticWebBuilder). Fecha de Elaboración: Marzo de 2009. INFOTEC CONACYT FIDEICOMISO. Página i Glosario

Más detalles

BOLETÍN DE NOVEDADES Barcelona, junio de 2008

BOLETÍN DE NOVEDADES Barcelona, junio de 2008 BOLETÍN DE NOVEDADES Barcelona, junio de 2008 Introducción El objeto de este documento es presentar y describir brevemente las principales actuaciones en los últimos meses de Carver en algunos de sus clientes,

Más detalles

El Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo de Software El Proceso de Desarrollo de Software Ciclos de vida Métodos de desarrollo de software El Proceso Unificado de Desarrollo de Software 1 Fases principales del desarrollo de software Captura de requisitos:

Más detalles

MANUAL DE REFERENCIA

MANUAL DE REFERENCIA GOBIERNO DE CHILE MINISTERIO DE HACIENDA Dirección de Presupuestos MANUAL DE REFERENCIA GUÍA PARA IMPLEMENTACIÓN ISO 9001:2000 SISTEMA DE EVALUACIÓN DE DESEMPEÑO Versión 05 Diciembre 2008 INDICE 1 Definición

Más detalles

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE 3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE Software Configuration Management (SCM) es una disciplina de la Ingeniería de Software que se preocupa de [Ber92] [Ber84] [Bou98] [Mik97]: Identificar y documentar

Más detalles

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR En este capítulo se describe el análisis y diseño de un sistema, denominado e-commerce Constructor, el cual cumple con los siguientes objetivos: Fungir

Más detalles

Sinopsis de la gestión de portafolios de acuerdo con el estándar del Project Management Institute 1

Sinopsis de la gestión de portafolios de acuerdo con el estándar del Project Management Institute 1 Sinopsis de la gestión de portafolios de acuerdo con el estándar del Project Management Institute 1 Conceptos básicos Qué es un portafolio? Es una colección de proyectos, programas y otras actividades

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

Interoperabilidad de Fieldbus

Interoperabilidad de Fieldbus 2002 Emerson Process Management. Todos los derechos reservados. Vea este y otros cursos en línea en www.plantwebuniversity.com. Fieldbus 201 Interoperabilidad de Fieldbus Generalidades Qué es interoperabilidad?

Más detalles

El modelo de ciclo de vida cascada, captura algunos principios básicos:

El modelo de ciclo de vida cascada, captura algunos principios básicos: Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software. El primer ciclo de vida del software, "Cascada",

Más detalles

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Introducción Este documento recopila las preguntas, opiniones y respuestas que se produjeron en un pequeño curso sobre las

Más detalles

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el Capitulo II. Análisis de herramientas y tecnologías de desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el lenguaje de Modelo de Objetos llamado UML (Unified

Más detalles

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

Más detalles

Interacción Persona - Ordenador

Interacción Persona - Ordenador Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición

Más detalles

Evolución histórica 60 -. Metodologías

Evolución histórica 60 -. Metodologías TEMA 1 INTRODUCCIÓN Historia Evolución de las técnicas de programación Qué es orientado a objetos? Factores cruciales que miden la calidad del software Externos Internos La familia Orientada a objetos

Más detalles

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar Gobierno Municipal del Cantón Bolívar Versión: Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Plan de Desarrollo de Software Universidad

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Metodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web

Metodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web Metodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web J.Corral-García, D.Cortés-Polo, C.Gómez-Martín, J.L.González-Sánchez

Más detalles

Figure 7-1: Phase A: Architecture Vision

Figure 7-1: Phase A: Architecture Vision Fase A Figure 7-1: Phase A: Architecture Vision Objetivos: Los objetivos de la fase A son: Enfoque: Desarrollar una visión de alto nivel de las capacidades y el valor del negocio para ser entregado como

Más detalles

MARCO DE REFERENCIA SISTEMAS DE INFORMACIÓN PARA LA GESTIÓN DE TI EN EL ESTADO COLOMBIANO

MARCO DE REFERENCIA SISTEMAS DE INFORMACIÓN PARA LA GESTIÓN DE TI EN EL ESTADO COLOMBIANO MARCO DE REFERENCIA PARA LA GESTIÓN DE TI EN EL ESTADO COLOMBIANO SISTEMAS DE INFORMACIÓN PLANEACIÓN Y GESTIÓN DE SIS-INF 80. Definición Estratégica de los SIS-INF Las entidades deben, en la Arquitectura

Más detalles

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC304_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

ISO 9001:2015 Principales cambios

ISO 9001:2015 Principales cambios ISO 9001:2015 Principales cambios ISO 9001: 2015 se basa en el Anexo SL - la nueva estructura de alto nivel. Se trata de un marco común para todos los sistemas de gestión ISO. Esto ayuda a mantener la

Más detalles

VISUAL SALE, EL SOFTWARE DE VENTAS MÁS INNOVADOR DEL MERCADO

VISUAL SALE, EL SOFTWARE DE VENTAS MÁS INNOVADOR DEL MERCADO , EL SOFTWARE DE VENTAS MÁS INNOVADOR DEL MERCADO Olvídese de CRM para la fuerza de ventas y utilice una herramienta desarrollada por Vendedores para Vendedores. Visual Sale nace como la respuesta a la

Más detalles

Contenido Qué es Joomla?... 2 Tipos de extensiones... 4 Referencias... 8

Contenido Qué es Joomla?... 2 Tipos de extensiones... 4 Referencias... 8 Contenido Qué es Joomla?... 2 Qué es un sistema de gestión de contenidos (CMS)?... 2 Principales caracteristicas... 2 Multilenguaje... 2 Extensibilidad... 2 Gestion de contenido... 2 Frontend Edición...

Más detalles

Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos

Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos Autora: Vasquez Pilar María Directora: Dra. Giandini Roxana Codirectora: Mg. Bazán Patricia Agenda Introducción.

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Técnica de modelado de objetos (I) El modelado orientado a objetos es una técnica de especificación semiformal para

Más detalles

CMMI (Capability Maturity Model Integrated)

CMMI (Capability Maturity Model Integrated) CMMI (Capability Maturity Model Integrated) El SEI (software engineering institute) a mediados de los 80 desarrolló el CMM (modelo de madurez de la capacidad de software). CMMI: CMM integrado, una mezcla

Más detalles

Guía Presentación DIPAC-3.0

Guía Presentación DIPAC-3.0 Código:GP-001 Edición: 2 8 de marzo de 2014 8 de marzo de 2014 INDICE GENERAL INTRODUCCION... 3 OBJETIVOS... 3 ALCANCE... 3 ESTRUCTURA DEL DOCUMENTO... 3 PRESENTACIÓN... 4 INTRODUCCIÓN... 4 ORIGEN Y MOTIVACIONES...

Más detalles

BPMN básico. Clase Modelos de Procesos. Javier Bermudez (jbermude@uc.cl)

BPMN básico. Clase Modelos de Procesos. Javier Bermudez (jbermude@uc.cl) BPMN básico Clase Modelos de Procesos Javier Bermudez (jbermude@uc.cl) Para qué modelar? Para sacar el mejor provecho a los artefactos creados por el hombre 2 BPMN Historia Mayo 2004: BPMI Lanza propuesta

Más detalles

BPM en la práctica Transitando del BPA al BPM con una metodología probada. Diego Karbuski - Diciembre 2012

BPM en la práctica Transitando del BPA al BPM con una metodología probada. Diego Karbuski - Diciembre 2012 BPM en la práctica Transitando del BPA al BPM con una metodología probada. Diego Karbuski - Diciembre 2012 Qué es BPM? BPM no solo es tecnología informática. Es una disciplina de gestión empresarial impulsada

Más detalles

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,

Más detalles

6 Anexos: 6.1 Definición de Rup:

6 Anexos: 6.1 Definición de Rup: 6 Anexos: 6.1 Definición de Rup: Es un producto del proceso de ingeniería de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización del desarrollo.

Más detalles

SOLUCIÓN SITUACIÓN ACTUAL

SOLUCIÓN SITUACIÓN ACTUAL SITUACIÓN ACTUAL La necesidad de las organizaciones de ser más competitivas en un mercado dinámico ha generado estructuras organizacionales complejas y exigentes en términos de calidad y eficiencia. Sobre

Más detalles

Patrones de software y refactorización de código

Patrones de software y refactorización de código Patrones de software y refactorización de código Introducción y antecedentes de los patrones de software Los patrones permiten construir sobre la experiencia colectiva de ingenieros de software habilidosos.

Más detalles

PRESENTACIÓN CMMI: (CAPABILITY MATURITY MODEL INTEGRATION)

PRESENTACIÓN CMMI: (CAPABILITY MATURITY MODEL INTEGRATION) PRESENTACIÓN CMMI: (CAPABILITY MATURITY MODEL INTEGRATION) INDICE 1. Introducción 2. Estructura CMMI 3. Nivel 2 4. Nivel 3 5. Nivel 4 6. Nivel 5 7. Bibliografía INTRODUCCIÓN Qué es y por qué usar CMMI?

Más detalles

SOFTWARE PLANNING PROJECTS UNDER THE PMI GUIDELINES PLANEACION DE PROYECTOS DE SOFTWARE BAJO LINEAMIENTOS DEL PMI. MSc. Mauricio Rojas Contreras

SOFTWARE PLANNING PROJECTS UNDER THE PMI GUIDELINES PLANEACION DE PROYECTOS DE SOFTWARE BAJO LINEAMIENTOS DEL PMI. MSc. Mauricio Rojas Contreras Recibido: 06 de agosto de 2009 Aceptado: 21 de octubre de 2009 SOFTWARE PLANNING PROJECTS UNDER THE PMI GUIDELINES PLANEACION DE PROYECTOS DE SOFTWARE BAJO LINEAMIENTOS DEL PMI MSc. Mauricio Rojas Contreras

Más detalles

RECOMENDACIONES PARA EL DESARROLLO DE UNA POLÍTICA DE SOFTWARE LIBRE

RECOMENDACIONES PARA EL DESARROLLO DE UNA POLÍTICA DE SOFTWARE LIBRE CENTRO DE EXCELENCIA DE SOFTWARE LIBRE DE CASTILLA-LA MANCHA JUNTA DE COMUNIDADES DE CASTILLA LA MANCHA. RECOMENDACIONES PARA EL DESARROLLO DE UNA POLÍTICA DE SOFTWARE LIBRE Autor del documento: Centro

Más detalles

Figure 9-1: Phase C: Information Systems Architectures

Figure 9-1: Phase C: Information Systems Architectures FASE C Figure 9-1: Phase C: Information Systems Architectures Objetivos Los objetivos de la Fase C son: Desarrollar la arquitectura de sistemas de información objetivo (datos y aplicaciones), que describe

Más detalles

Introducción. Enfoque de Control de CobiT Los Procesos del Modelo Mapeo de los Procesos

Introducción. Enfoque de Control de CobiT Los Procesos del Modelo Mapeo de los Procesos CobiT 75.46 Administración i ió y Control de Proyectos II Abril de 2008 Agenda Presentación Introducción Pi Principios ii dl del Modelo dl Enfoque de Control de CobiT Los Procesos del Modelo Mapeo de los

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN... 4 Tarea 1.1: Análisis de la Necesidad del... 4 Tarea 1.2: Identificación

Más detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN...4 Tarea 1.1: Análisis de la Necesidad del...4 Tarea 1.2: Identificación

Más detalles

SISTEMAS DE PLANEACIÓN DE RECURSOS EMPRESARIALES 2008

SISTEMAS DE PLANEACIÓN DE RECURSOS EMPRESARIALES 2008 2.1 FACTORES SEGÚN ERP s Propuesta metodológica para la gestión del conocimiento durante la implantación de sistemas ERP Propuesta metodológica La propuesta metodológica aquí desarrollada parte de un modelo

Más detalles

ISO 19103. Lenguaje de Esquema Conceptual

ISO 19103. Lenguaje de Esquema Conceptual ISO 19103 Lenguaje de Esquema Conceptual La ISO 19103 establece normas y guías para la adopción y uso de un Lenguaje de Esquema Conceptual (CSL) para desarrollar modelos o esquemas de información geográfica,

Más detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

implantación Fig. 1. Ciclo de vida tradicional

implantación Fig. 1. Ciclo de vida tradicional 1. Ciclo de vida tradicional de los sistemas de software En ingeniería de software, la descripción tradicional del ciclo de vida del software está basada en un modelo conocido como el modelo de cascada

Más detalles