Combinando Modelos de Procesos y Activos Reutilizables en una Transición poco Invasiva hacia las Líneas de Producto de Software
|
|
- Alfonso Nieto Espinoza
- hace 8 años
- Vistas:
Transcripción
1 Combinando Modelos de Procesos y Activos Reutilizables en una Transición poco Invasiva hacia las Líneas de Producto de Software Orlando Avila-García, Antonio Estévez García, E. Victor Sánchez Rebull José Luis Roda García Open Canarias, S.L. Universidad de La Laguna Santa Cruz de Tenerife Santa Cruz de Tenerife España España orlando,aestevez,vsanchez@opencanarias.com jlroda@ull.es Resumen Existen tres modelos de adopción/creación de líneas de producto de software: proactivo, extractivo y reactivo. Mientras los dos primeros pueden implicar costes y tiempo de adopción prohibitivos, el tercero plantea una alternativa con menos costes de adopción, lo que se denomina una transición poco invasica hacia la ingeniería basada en líneas de producto. En este artículo proponemos un método reactivo, basado en la combinación de activos reutilizables y procesos de software. Nuestro método permite la automatización progresiva y distribuida de las tareas de un proceso de software hasta llegar a su completa automatización. 1. Introducción La celebración en 1968 de la conferencia NA- TO sobre Ingeniería del Software marca el nacimiento de dicha disciplina [19]. La principal motivación para su celebración fue la creciente necesidad de producir sistemas de software más grandes, complejos y ables, de una manera más controlada y eciente. Con ello se afrontaba lo que se denominó entonces la crisis del software, la imposibilidad de las tecnologías de software de aquella época para satisfacer las demandas de la industria. En dicha conferencia se trataron temas de diseño, producción, precio, y servicios asociados al software. En el debate abierto sobre la producción de software surgieron dos ideas reveladores: la propuesta por R. W. Bremer, sobre la necesidad de utilizar entornos de producción controlados por maquinaria, lo que fue llamado por primera vez factoría de software [4], y la presentada por M. D. McIlroy, sobre las grandes ventajas que ofrece la creación y ensamblaje de componentes reutilizables [18]. Estas ideas son el exponente de dos importantes principios de factoría: automatización y reutilización, respectivamente. Es importante considerar que desde el principio se tuvo en cuenta que, en el caso del software, no usamos estos principios para producir en masa réplicas exactas de un mismo producto (problema que no existe en el caso del software), sino productos similares o variantes de un mismo producto a bajo coste y en menos tiempo [18]. Numerosas aproximaciones han venido ofreciendo aportaciones sobre estos y otros principios complementarios de factoría aplicados al software [8]. Uno de las aproximaciones más importantes lleva el nombre de Líneas de Producto de Software [7], paradigma enriquecido en los últimos años por la Ingeniería Dirigida por Modelos [24]. Esta aproximación se basa en la idea de producir familias (o variantes similares) de productos de software a partir de un conjunto de activos reutilizables (denomi-
2 nados assets) de una forma prescrita. Desarrollar un producto de la línea es más una cuestión de ensamblaje y conguración de activos que de creación. Para cada línea de producto debe haber una guía predenida o plan de producción que especica el proceso exacto de obtención de cada producto. Esta aproximación ofrece así tecnologías para llevar a cabo reutilización y automatización en los procesos de software. La dicotomía entre ingeniería de dominio e ingeniería de aplicación es esencial en la aproximación de Líneas de Producto de Software [7]; es más, es la base de cualquier intento de reutilización y automatización en procesos de software [10]. Mientras en la ingeniería de dominio creamos un conjunto de activos para reutilizar y automatizar en un dominio de aplicación especíco, en la ingeniería de aplicación los usamos para producir, en dicho dominio, productos de software de mayor calidad, empleando menos coste y tiempo. En 2002, Krueger propuso la distinción entre tres modelos de adopción/creación de líneas de producto de software [6]: proactivo, extractivo y reactivo. El modelo proactivo es el más clásico; propone un gran esfuerzo e inversión iniciales en una ingeniería de dominio exhaustiva, donde se establece el dominio (o ámbito) exacto de los productos que pertenecerán a la línea, para luego crear los activos a partir de los cuales producirlos. Este modelo, aunque más exhaustivo, puede requerir tiempos y costes de adopción prohibitivos para una empresa; es la llamada barrera de adopción [6, 15]. Un modelo de adopción extractivo plantea la utilización, durante la ingeniería de dominio, de ingeniería inversa de los productos ya existentes en el dominio para obtener conocimiento más preciso sobre éste más rápidamente. Esta aproximación resulta en una reducción considerable de coste y tiempo en el desarrollo de activos (ver un ejemplo en [26]). La tercera alternativa es el modelo de adopción reactivo, en el que no establecemos desde un principio el dominio de la línea de producto, sino que iremos ampliando bajo demanda el ámbito de los productos de la misma, creando los correspondientes activos. Bajo demanda signica que incluiremos nuevos productos a medida que aparezca la necesidad de producirlos. La creación de activos es por tanto más incremental y progresiva que con los modelos de adopción anteriores (ver un ejemplo en [5]). Este tipo de modelo de adopción permite una transición poco invasiva desde una ingeniería de software convencional, centrada en un único producto, a una ingeniería basada en líneas de producto, centrada en la producción de variantes de productos. Estas transiciones poco invasivas ofrecen dos ventajas principales [15]: la rápida consecución del ROI (Return-of- Investment); y la posibilidad de seguir con los procesos de desarrollo normales de la empresa. En este artículo proponemos un método reactivo para realizar una transición poco invasiva hacia la ingeniería basada en líneas de producto de software. Esta aproximación está pensada para aquellas empresas que quieran automatizar sus procesos de desarrollo, en dominios de aplicación especícos, a través de la creación de líneas de producto de software. Para ello, ofrecemos una solución basada en un desarrollo iterativo y desacoplado de activos, que permite automatizar, progresivamente, las tareas a lo largo del ciclo de desarrollo. En otras palabras, este método permite automatizar la toma de decisiones en los procesos de software a medida que se establece la invarianza de las mismas en el dominio de aplicación en cuestión. Nuestro método se basa en la utilización de dos estándares OMG (Object Management Group) 1 : RAS (Reusable Asset Specication) [21], Especicación de Activos Reutilizables, que permite identicar, describir y empaquetar activos de manera estándar; y SPEM (Software Process Engineering Metamodel) [22], Metamodelo de Ingeniería de Procesos de Software, que dene un lenguaje estándar de modelado de procesos de software. Esta línea de investigación tuvo su origen en un estudio que exploraba las sinergias entre Líneas de Producto de Software, Ingeniería 1 OMG es la misma organización que da soporte a MDA (Model-Driven Architecture) [20], su aproximación a la Ingeniería Dirigida por Modelos [24] (ver sección 2.1)
3 Dirigida por Modelos e Ingeniería de Procesos de Software [2]. En aquel estudio, establecimos que las líneas de producto de software aplicadas al mantenimiento de familias de modelos facilitan enormemente la Ingeniería Dirigida por Modelos. El presente estudio muestra cómo esta clase de líneas de producto puede ser encapsulada en activos reutilizables, hasta que consiguen automatizar completamente una tarea de desarrollo. En la Sección 2 explicamos la base conceptual de nuestro método. A continuación presentamos un caso de estudio (Sección 3) del método. Finalizamos con un repaso a trabajos relacionados (Seccion 4) y con las conclusiones (Seccion 5). 2. Antecedentes A continuación ofrecemos un repaso a algunas tecnologías en las que se basa nuestro método, en concreto la especicación de activos reutilizables (RAS) y el metamodelo de procesos de software (SPEM). Sin embargo, antes que nada, ofrecemos una perspectiva histórica de la sinergia entre reutilización y automatización, en la que se basa nuestro método Perspectiva Histórica En esta sección repasamos cómo las ideas de reutilización y automatización en los procesos de softare han ido convergiendo a lo largo de la historia hasta llegar a su sinergia en las líneas de producto de software. Esta descripción no trata de ser exhaustiva; sólo trata de ofrecer una introducción a la combinación de activos reutilizables y procesos de software 2. Desde 1968 [19], el término factoría de software ha sido usado para hacer hincapié en diferentes técnicas de factoría [12]: aspectos organizativos, como división del trabajo en roles y especialización; métricas y procesos de software rigurosos y altamente maduros; reutilización, en diferentes etapas de la producción; entornos y herramientas de automatización; entrenamiento y aprendizaje, a través de 2 Para un estudio más en profundidad sobre el concepto de reutilización referirse a [13, 25]; sobre el concepto de automatización ver [8, 10] la gestión del conocimiento; y exibilidad, para producir variantes de los productos. Todas éstas son facetas de la aplicación de ideas de factoría a la producción de software [8]. Aunque estas técnicas no son mutuamente excluyentes, no fue hasta nales del siglo XX que se desarrollaron sus sinergias y las tecnologías necesarias para combinarlarlas efectivamente. Se realizaron importantes estudios sobre los cambios organizativos necesarios para una ecaz implantación de un programa de reutilización [25]. Se estableció que estos cambios pasan por la creación de un nuevo rol, el analista o ingeniero de dominio, encargado de identicar, capturar, empaquetar y organizar, para su posterior reutilización, conocimiento sobre cómo se llevan a cabo las distintas tareas de producción en dominios de aplicación especícos [23]. Los trabajos en metaprogramación empezaron a ofrecer sus frutos aportando nuevas técnicas para crear generadores de aplicaciones y capturar en ellos los secretos de la producción de software en dominios especícos [10]. Se llega así a reveladores estudios sobre reutilización que concluyen que la identicación, conguración (o especialización) e integración de artefactos reutilizables requiere de herramientas de automatización, como generadores de aplicaciones o sistemas de transformación, y del uso de lenguajes de muy alto nivel de abstracción [13, 12]. A nales del siglo XX aparece el concepto de Líneas de Producto de Software [7], formalizando la sinergia entre las diferentes técnicas de fábrica de software. Este paradigma propone la producción de familias (variantes similares) de productos a partir de un conjunto de activos (assets) siguiendo planes de producción predenidos. Los activos reutilizables son artefactos con puntos de variabilidad así como (meta)información y/o procesos asociados que describen cómo especializarlos para diferentes contextos de uso [17]. Por otro lago, se apunta a la importancia de que los planes de producción o procesos de desarrollo altamente precisos, preferiblemente automáticos, tengan tiempos y costes de ejecución predecibles. Más recientemente, la Ingeniería Dirigida por Modelos (Model-Driven Engineering,
4 MDE) [24] ha venido a ofrecer una prometedora técnica para implementar planes de producción más automáticos y exibles. MDE propone la denición de todo artefacto producido y/o (re)utilizado durante el proceso de desarrollo como un modelo formal, facilitando su manipulación a través de transformaciones. No sólo MDE da soporte a las Líneas de Producto de Software, sino que lo contrario es también cierto. Recientemente han sido presentados estudios sobre las ventajas de utilizar líneas de producto de software para mantener familias de modelos [9, 2, 3] Para nalizar decir que, en la actualidad, de- nimos un activo reutilizable (asset) como la solución a un problema recurrente en el desarrollo de software. Debe tener, preferiblemente, puntos de variabilidad que deben ser con- gurados por el consumidor del activo con el n de congurarlo o especializarlo para un contexto de uso determinado. Para una reutilización efectiva, la (meta)información de conguración del activo debe ser precisa, normalmente en forma de especicación de proceso o secuencia de pasos que pueda ser ejecutada de manera, preferiblemente, automática Modelado de Activos Reutilizables La especicación de activos reutilizables (Reusable Asset Specication, RAS) [21] permite identicar, describir y empaquetar un activo de manera estándar, cumpliendo los requisitos para una reutilización efectiva descritos en la sección anterior. Con RAS, un activo es una colección cohesiva de artefactos; de hecho, se almacena como un chero comprimido que empaqueta un conjunto de cheros, cada uno representando uno de estos artefactos. Un artefacto es cualquier producto de trabajo creado durante un proceso de desarrollo, como casos de uso, diagramas de clases, código fuente, cheros de conguración XML, etc., que resuelven problemas recurrentes en el desarrollo de software. Estos artefactos, por lo general, aceptarán cierta variabilidad, por lo que contarán con puntos de variabilidad o extensión que podrán ser congurados para adaptarlos a las características del problema concreto (contexto) donde aplicarlos. Figura 1: Ejemplo de modelo SPEM, donde un rol A ejecuta una tarea, consumiendo (in) el artefacto 1 y produciento (out) el artefacto 2. La tarea tiene asociado un elemento de guía para asistir al rol en su ejecución. La (meta)información que describe el activo es un modelo que conforma con el metamodelo RAS. Este modelo se empaqueta junto al resto de artefactos, dentro del chero comprimido que representa al activo. Este modelo contiene la identicación y clasicación del activo, la descripción de sus artefactos, sus puntos de variabilidad y cómo congurarlos Modelado de Procesos de Software Los procesos de desarrollo de software se han vuelto tan complejos que es necesario el uso de lenguajes formales para modelarlos [11]. SPEM (Software Process Engineering Metamodel) [22] es un lenguaje de modelado estándar que permite describir tales procesos. El metamodelo de SPEM es muy extenso, permitiendo el modelado de muchos aspectos y problemas del proceso de desarrollo. Sin embargo, en este estudio nos centraremos en el modelado de tareas, sin ni siquiera utilizar relaciones de secuencia o prioridad entre las mismas. Las tareas, ejecutadas por roles, consumen artefactos de entrada y producen artefactos de salida (ver Figura 1). Ejemplos de artefactos son modelos de casos de uso, diagramas de clases, código fuente, cheros de conguración XML, etc. Una tarea puede tener asociado elementos de guía que ayuden al rol a desempeñarla. Estos elementos pueden ir desde ejemplos y guías hasta plantillas y activos reutilizables [22, p.126].
5 Figura 2: Ejemplo de modelo SPEM que describe la fase de análisis de un proceso de software en una empresa X. El analista A es el encargado de estudiar las actas de reunión con el cliente, y crear el diagrama de casos de uso del sistema que cumple con los requerimientos del mismo. El analista B recibe los casos de uso y, según su experiencia, crea el diagrama de clases del sistema. Figura 3: El proceso stándar de la empresa ha sido mejorado mediante la inclusión de un elemento de guía para que se asista en la tarea de creación de casos de uso. 3. Caso de Estudio Supongamos una empresa X que desarrolla software para la administración electrónica. Supongamos que tiene un proceso desarrollo estándar para todos sus proyectos, un extracto (fase de análisis) del cual vemos en la Figura 2 modelado con SPEM. La empresa desea adoptar una aproximación de líneas de producto de software en sus desarrollos, con el n de potenciar la reutilización y automatización en sus procesos de software. En este caso de estudio mostraremos cómo, haciendo uso de nuestro método, la empresa podrá abordar una transición poco invasiva hacia las líneas de producto de software, es decir, sin perturbar la ejecución de sus proyectos de desarrollo. Para facilitar la comprensión del caso de estudio, mostraremos un ejemplo centrado en la fase de análisis (Figura 2). En este ejemplo, el analista A identica y organiza progresivamente en forma de activo RAS el conocimiento sobre la creación de casos de uso en un dominio especíco, para facilitar su reutilización efectiva, hasta llegar a una completa automatización de la tarea Creación del Activo El proceso de software de la Figura 2 es actualizado para contener un elemento de guía, en concreto un activo, que representa el paquete de conocimiento que el analista A va desarrollando sobre la creación de modelos de casos de uso en un dominio especíco (ver Figura 3). A medida que el analista A va encontrando similitudes entre los modelos de casos de uso que va creando en los diferentes proyectos, deberá ir empaquetándolas en el activo. La familia de modelos (o variantes) será organizada en forma de línea de producto de software 3. Para ello, el creador del activo describirá el proceso de conguración del activo como el plan de producción de una línea de producto de software. Téngase en cuenta que el analista A no estará abordando la creación directa de la línea de productos de software de su empresa, sino la creación de una línea de productos para generar la familia de modelos creados habitualmente al desempeñar esa tarea. El procedimiento será el siguiene. Cuando el analista A deba crear un modelo de casos de uso, inspeccionará el activo en busca de un modelo que cubra sus requerimientos. Para ello hará uso de la línea de productos para modelos contenida en el activo. Si ninguno de los miembros de la línea satisface sus necesidades, deberá crear un modelo por su cuenta, a partir del miembro que más se adecúe a ellas. Cuando termine la tarea de creación del modelo, deberá realizar ingeniería de dominio para incluir la nueva variante en la línea de producto, y capturarla así a partir de entonces dentro del activo. A partir de ese momento, el proceso 3 Para más detalles sobre cómo crear líneas de producto de software para mantener familias de modelos ver [3]; para una descripción más completa sobre la implementación de la línea de producto para modelos de casos de uso ver [1].
6 Figura 4: El ingeniero de dominio, que crea la línea de producto para casos de uso, debe especicar el modelo de cracterísticas de los miembros de la línea, una plantilla de modelos a partir de la cual generarlos, y una transformación de modelos que realice automáticamente tal especialización. de conguración del activo permitirá generar la nueva variante de modelos de casos de uso, para ser aplicada siempre que se repitan las condiciones que originaron su aparición. Es importante tener en cuenta que, como toda línea de productos, ésta que crea el analista debe tener un dominio. En caso contrario, sería muy dicil establecer similitudes entre las variantes de modelos que se desea agrupar, esencial para producirlos a partir de un mismo conjunto de activos. En este caso suponemos que el analista A lleva analizando aplicaciones en el dominio de los sistemas de gestión de solicitudes (en adelante referidos como RMS: Request Management Systems) en la administración electrónica. Ha establecido que muchos de los modelos de casos de uso que sirven para describirlos siguen unos patrones y comparten similitudes. Es por ello que decide automatizar la creación de estos modelos en el dominio RMS. Creación del Proceso de Conguración El analista A deberá ir acomodando las variantes de modelos casos de uso que va creando dentro del activo 4. Para ello deberá llevar 4 No tiene por qué ser el propio creador del produc- Figura 5: Plan de producción de la línea de producto para modelos de casos de uso. El analista tiene que seleccionar una serie de características del modelo de características, en lo que se llama con- guración de características. Esta conguración es la entrada de una transformación de modelos que especializa la plantilla para obtener el modelo de casos de uso. a cabo ingeniería de dominio para crear los activos y plan de producción de la línea de productos para modelos de casos de uso. La Figura 4 muestra en SPEM el proceso a seguir. Por un lado crea el modelo de características que caracteriza la familia de modelos de casos de uso, y una plantilla de modelos a partir de la cual generarlos. Asimismo, crea una transformación de modelos para especializar automáticamente la plantilla cuando queramos obtener un miembro concreto de la línea. La Figura 5 muestra el plan de producción de la línea de producto para modelos de casos de uso en el dominio RMS. Cuando un analista de casos de uso la quiere ejecutar, sólo tiene que seleccionar una serie de características opcionales y alternativas del modelo de características (que dene la familia de modelos), en lo que se llama conguración de características del producto a generar. Esta conguración es la entrada de una transformación de modelos que automáticamente especializa una plantilla de modelos para obtener el modelo de casos de uso concreto deseado. Es preciso notar que este plan de producción será el proceso de conguración del activo de to el que tenga que acomodarlo en el activo. Para ello la organización podría designar un analista de dominio, más experto en la creación de líneas de producto de software [25, 16].
7 Figura 6: Editor de modelos RAS de nuestro plugin de Eclipse para la manipulación de activos RAS. En la sección solución (solution) se encuentra modelada la descripción de los artefactos contenidos en el activo. En la sección uso (usage) se mantiene la información de las actividades o procesos de conguración del activo para diferentes contextos. En este caso, sólo hay modelada una actividad; en concreto, el plan de producción (modelado en SPEM) de la línea de producto para modelos de casos de uso. casos de uso que está siendo desarrollado. Empaquetado del Activo Siguiendo la especicación RAS, para empaquetar el activo necesitamos realizar varias acciones. En primer lugar, deberemos modelar la (meta)información del activo, incluidos los procesos de conguración que un consumidor del mismo debe ejecutar para obtener soluciones para contextos diferentes. La Figura 6 muestra dicho modelo, que conforma con el metamodelo RAS; este modelo es serializado en un chero con el nombre de manifest.rmd y empaquetado junto al resto de - cheros/artefactos del activo. Figura 7: Vista de navegación de proyectos ras de nuestro plugin de Eclipse para la manipulación de activos RAS. El proyecto es un chero comprimido con una serie de cheros que representan artefactos del activo. El primer artefacto es un directorio, que contiene el resto de artefactos necesarios para ejecutar la línea de producto de modelos de casos de uso: tres artefactos de entrada al proceso (rms.cbfm, rmscbfm2uml.atc, rmsuml_template.uml) más la denición en SPEM del proceso en sí (SPLCasosUsoRMS.spem, Figura 5). El activo también contiene el modelo del activo (manifest.rmd), conteniendo su (meta)información, y el metamodelo de RAS (ras.ecore).
8 Figura 8: Ejemplo de modelo SPEM que describe la nueva fase de análisis del proceso de la empresa de desarrollo de software objeto de nuestro estudio. La libertad del analista A ha sido restringida, ya que sólo puede seleccionar un miembro de la línea de producto para modelos de casos de uso. La tarea queda así restringida a la mera selección de características que identican el problema que el analista quiere solucionar. La segunda parte del análisis permanece inalterada, con el analista B recibiendo el modelo de casos de uso producido por el analista A. En segundo lugar debemos empaquetar los tres artefactos creados durante la ingeniería de dominio de la Figura 4, junto con la especicación del proceso de conguración, que en este caso es el modelo SPEM de la Figura 5. Dentro del activo, junto a estos cuatro artefactos, empaquetaremos también el modelo del activo (manifest.rmd) así como el metamodelo RAS (ras.ecore). Este último no es necesario, pero es una buena práctica que aumenta la compatibilidad entre herramentas RAS. La Figura 6 muestra el contenido del activo RAS Automatización de la Tarea Hasta ahora, el proceso de desarrollo de la empresa se ha visto modicado únicamente por la inclusión de un elemento de guía, en este caso un activo reutilizable. Al ser modelado como elemento de guía es opcional, es decir, el rol puede hacer o no uso de él cuando ejecuta la tarea. Esto le da la libertad al primero de decidir si alguna de las variantes del activo satisface sus necesidades, es decir, si alguno de los contextos para los que el activo dispone de conguración se asemeja lo suciente a su problema. La gran ventaja de tener los procesos de con- guración del activo descritos con SPEM es que podemos sacarlos y ensamblarlos con planes de producción más amplio. Por ejemplo, la Figura 8 nos muestra cómo el proceso de conguración del activo, que es en realidad el plan de producción de una línea de producto para modelos de casos de uso, ha sido desempaquetado del mismo e integrado en el proceso de software de la empresa. De esta manera, la etapa de creación de casos de uso ha sido sustituida por un plan de producción automático y obligatorio. En esta situación, hemos eliminado la libertad del analista A de decidir si usar o no alguna de las variantes ofrecidas por el activo reutilizable, sino que le obligamos a utilizar una de ellas. Ahora, el analista no puede crear cualquier modelo de casos de uso, sino que únicamente puede seleccionar una de las variantes de la línea seleccionando las características que lo identican. Fíjese que el rol que crea los casos de uso es ahora denominado Analista RMS (ver Figura 8); esto enfatiza el cambio de responsabilidades del analista. Con ello ganamos dos cosas: obligar a seguir patrones y buenas prácticas de modelado que los analistas realizando esa tarea han ido estableciendo progresivamente (mientras se creaba el activo); y centralizar el conocimiento para ayudar a nuevos analistas a aprender a realizar dicha tarea. 4. Trabajos relacionados Una aproximación poco invasiva a la creación de líneas de producto de software es presentada en [14, 5]. Aunque plantea una incorporación incremental de productos a la línea, no plantea la automatización incremental del proceso de desarrollo, ni abordar la reutilización y automatización de tareas de manera desaco-
9 plada. En esta aproximación, la incorporación de productos a una línea de producto de software es incremental, pero su automatización no lo es; la incorporación de un nuevo producto se aborda creando toda infraestructura necesaria para su generación automática desde el principio. El Desarrollo Basado en Activos (Asset Based Development), en cambio, sí que plantea la creación desacoplada de activos [16]. Sin embargo, hasta la fecha, la combinación de estos activos para automatizar un proceso de software no ha sido aclarada convenientemente. 5. Conclusiones En este artículo proponemos un método reactivo para llevar a cabo transiciones poco invasivas hacia la ingeniería basada en líneas de producto de software. Esta aproximación está pensada para aquellas empresas que quieran automatizar sus procesos de desarrollo, en dominios de aplicación especícos, a través de la creación de líneas de productos de software. El método se basa en un desarrollo iterativo y desacoplado de activos que permite automatizar, progresivamente, las tareas a lo largo del ciclo de desarrollo. Estos activos van capturando el conocimiento de los roles sobre la resolución de problemas en diferentes etapas del desarrollo. Con ello, a la larga se automatiza la toma de decisiones en los procesos de software, a medida que se establece que las mismas son invariantes en dominios de aplicación especícos. Nuestro método se basa en la combinación de RAS (Reusable Asset Specication) [21], especicación de activos reutilizables y SPEM (Software Process Engineering Metamodel) [22], metamodelo de ingeniería de procesos de software. Mediante un ejemplo hemos mostrado cómo la combinación del empaquetado de activos con RAS y el modelado de procesos con SPEM puede llevar a una automatización progresiva de las tareas en el proceso de desarrollo de la empresa. Referencias [1] O. Avila-García and M. D. D. Fabro. AMW use case: Mapping features to models. Technical Report MST-9, Open Canarias, S.L., Apr [2] O. Avila-García, A. E. García, V. S. Rebull, and J. L. R. García. Integrando modelos de procesos y activos reutilizables en una herramienta mda. In JISBD 2006: Proceedings of the XI Jornadas de Ingeniería del Software y Bases de Datos, pages , Barcelona, Spain, Oct CIMNE. [3] O. Avila-García, A. E. García, V. S. Rebull, and J. L. R. García. Using software product lines to manage model families in model-driven engineering. In SAC 2007: Proceedings of the 2007 ACM Symposium on Applied Computing, track on Model Transformation, pages ACM Press, Mar [4] R. W. Bremer. Machine-controlled production environment. In P. Naur and B. Randell, editors, Software Engineering: Report on a conference sponsored by the NATO Science Committee, Garmish, Germany, 7th to 11th October 1968, pages Scientic Aairs Division, NA- TO, [5] R. Buhrdorf, D. Churchett, and C. W. Krueger. Salion's experience with a reactive software product line approach. In PFE 2003: Software Product-Family Engineering, 5th International Workshop, volume 3014 of LNCS, pages Springer, Nov [6] P. Clements and C. W. Krueger. Being proactive pays o / eliminating the adoption barrier. IEEE Software, pages 2831, July/August [7] P. Clements and L. Northrop. Software Product Lines: Practices and Patterns. Addison Wesley, Aug 2001.
10 [8] M. A. Cusumano. The software factory: A historical interpretation. IEEE Software, 6(2):2330, [9] K. Czarnecki and M. Antkiewicz. Mapping features to models: A template approach based on superimposed variants. In Proceedings of GPCE 2005, volume 3676 of LNCS, pages Springer- Verlag, [10] K. Czarnecki and U. Eisenecker. Generative Programming: Methods, Tools, and Applications. Addison-Wesley, [11] J.-C. Dermiane and F. Oquendo. Key issues and new challenges in software process technology. UPGRADE: The European Journal for the Informatics Professional, V(5):1116, Oct [12] M. L. Griss. Software reuse: from library to factory. IBM Systems Journal, 32(4):548566, [13] C. W. Krueger. Software reuse. ACM Comput. Surv., 24(2):131183, [14] C. W. Krueger. Easing the transition to software mass customization. In PFE '01: Revised Papers from the 4th International Workshop on Software Product- Family Engineering, pages , London, UK, Springer-Verlag. [15] C. W. Krueger. New methods behind a new generation of software product line successes. Technical Report # , BigLever Software, Inc., Feb [16] G. Larsen. Model-driven development, assets and reuse. IBM Systems Journal, 45(3), [17] J. D. McGregor. Product production. Journal of Object Technology, 3(10):89 98, Nov/Dec [18] M. D. McIlroy. Mass produced software components. In P. Naur and B. Randell, editors, Software Engineering: Report on a conference sponsored by the NA- TO Science Committee, Garmish, Germany, 7th to 11th October 1968, pages Scientic Aairs Division, NA- TO, [19] P. Naur and B. Randell, editors. Software Engineering: Report on a conference sponsored by the NATO Science Committee, Garmish, Germany, 7th to 11th October Scientic Aairs Division, NATO, [20] OMG. MDA guide version Technical Report omg/ , Jun Available at [21] OMG. Reusable asset specication. Technical Report ptc/ , Jun Available at [22] OMG. Software Process Engineering Meta-model 2.0. Technical Report ad/ , Apr Available at [23] R. Prieto-Díaz. Domain analysis: an introduction. SIGSOFT Softw. Eng. Notes, 15(2):4754, [24] D. C. Schmidt. Model-Driven Engineering. IEEE Computer, 39(2):4147, Feb [25] W. Tracz. Confessions of a Used Program Salesman: Institutionalizing Software Reuse. Addison Wesley, Reading, Massachusetts, USA, [26] S. Trujillo, D. Batory, and O. Díaz. Feature refactoring a multi-representation program into a product line. In GPCE 2006: Proceedings of the 5th International Conference on Generative Programming and Component Engineering, pages , New York, NY, USA, Oct ACM Press.
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 detallesSOFTWARE & 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 detallesUNIDAD 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 detallesModificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere.
UNIVERSIDAD DE CARABOBO FACULTAD DE CIENCIA Y TECNOLOGÍA DIRECCION DE EXTENSION COORDINACION DE PASANTIAS Modificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere. Pasante:
Más detallesCiclo de vida y Metodologías para el desarrollo de SW Definición de la metodología
Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología La metodología para el desarrollo de software es un modo sistemático de realizar, gestionar y administrar un proyecto
Más detalles<Generador de exámenes> Visión preliminar
1. Introducción Proyecto Final del curso Técnicas de Producción de Sistemas Visión preliminar Para la evaluación de algunos temas de las materias que se imparten en diferentes niveles,
Más detallesEl 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 detallesProceso 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 detallesDE VIDA PARA EL DESARROLLO DE SISTEMAS
MÉTODO DEL CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS 1. METODO DEL CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS. El desarrollo de Sistemas, un proceso
Más detallesPRODUCTIVIDAD DE PROYECTOS DE DESARROLLO DE SOFTWARE: FACTORES DETERMINANTES E INDICADORES
PRODUCTIVIDAD DE PROYECTOS DE DESARROLLO DE SOFTWARE: FACTORES DETERMINANTES E INDICADORES Raúl Palma G. y Guillermo Bustos R. Escuela de Ingeniería Industrial Universidad Católica de Valparaíso Casilla
Más detallesApp para realizar consultas al Sistema de Información Estadística de Castilla y León
App para realizar consultas al Sistema de Información Estadística de Castilla y León Jesús M. Rodríguez Rodríguez rodrodje@jcyl.es Dirección General de Presupuestos y Estadística Consejería de Hacienda
Más detallesLA LOGÍSTICA COMO FUENTE DE VENTAJAS COMPETITIVAS
LA LOGÍSTICA COMO FUENTE DE VENTAJAS COMPETITIVAS Los clientes compran un servicio basandose en el valor que reciben en comparacion con el coste en el que incurren. Por, lo tanto, el objetivo a largo plazo
Más detallesPROCESOS 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 detallesAdministración del conocimiento y aprendizaje organizacional.
Capítulo 2 Administración del conocimiento y aprendizaje organizacional. 2.1 La Importancia Del Aprendizaje En Las Organizaciones El aprendizaje ha sido una de las grandes necesidades básicas del ser humano,
Más detallesGUÍA TÉCNICA PARA LA DEFINICIÓN DE COMPROMISOS DE CALIDAD Y SUS INDICADORES
GUÍA TÉCNICA PARA LA DEFINICIÓN DE COMPROMISOS DE CALIDAD Y SUS INDICADORES Tema: Cartas de Servicios Primera versión: 2008 Datos de contacto: Evaluación y Calidad. Gobierno de Navarra. evaluacionycalidad@navarra.es
Más detallesSistema para Gestión Hotelera Visión
Sistema para Gestión Hotelera Visión Tabla de Contenidos 1. Introducción 4 1.1 Propósito 4 1.2 Alcance 4 1.3 Definiciones, Acrónimos, y Abreviaciones 4 1.4 Referencias 4 2. Posicionamiento 4 2.1 Oportunidad
Más detallesPlantilla para Casos de Éxito
Plantilla para Casos de Éxito Nombre/Actividad de la EMPRESA objeto de estudio: INSIGNA Sector al que pertenece: Presidente o gerente de la empresa: Antonio Gil Moreno Localización: Valencia Facturación
Más detallesUnidad 1. Fundamentos en Gestión de Riesgos
1.1 Gestión de Proyectos Unidad 1. Fundamentos en Gestión de Riesgos La gestión de proyectos es una disciplina con la cual se integran los procesos propios de la gerencia o administración de proyectos.
Más detallesLa 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 detallesWorkflow, Gestión Documental y Tecnologías Web.
Workflow, Gestión Documental y Tecnologías Web. Nuevo prisma tecnológico en la Automatización de Expedientes 1 Introducción El objeto del presente planteamiento no es otro que abordar la siempre difícil
Más detallesIntroducción. Metadatos
Introducción La red crece por momentos las necesidades que parecían cubiertas hace relativamente poco tiempo empiezan a quedarse obsoletas. Deben buscarse nuevas soluciones que dinamicen los sistemas de
Más detallescomunidades de práctica
1. Introducción CoSpace es una plataforma web diseñada para proporcionar un espacio virtual de interacción y colaboración entre formadores en comunidades virtuales. Se originó como resultado de las necesidades
Más detallesCómo seleccionar el mejor ERP para su empresa Sumario ejecutivo
Índice completo de la Guía Índice completo de la Guía 1. Quién debe leer esta guía? 3 2. Qué es un ERP? 7 2.2. Qué es un ERP?... 9 2.3. Cuál es el origen del ERP?... 10 2.4. ERP a medida o paquetizado?...
Más detallesGestió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 detallesAnteproyecto Fin de Carrera
Universidad de Castilla-La Mancha Escuela Superior de Informática Anteproyecto Fin de Carrera DIMITRI (Desarrollo e Implantación de Metodologías y Tecnologías de Testing) Dirige: Macario Polo Usaola Presenta:
Más detallesEnginyeria del Software III
Enginyeria del Software III Sessió 3. L estàndard ISO/IEC 15504 Antònia Mas Pichaco 1 Introducción El proyecto SPICE representa el mayor marco de colaboración internacional establecido con la finalidad
Más detallesISO9001:2015. Todos los certificados emitidos en este periodo tienen una fecha de caducidad de 15 de septiembre de 2018.
ISO9001:2015 PLAN DE TRANSICIÓN Tras la publicación de la nueva versión de la norma ISO9001 el pasado mes de septiembre se inicia un periodo de convivencia entre las dos versiones de la norma. Este periodo
Más detallesEstándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008
Estándares para planes de calidad de software Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008 DIFERENCIA ENTRE PRODUCIR UNA FUNCION Y PRODUCIR UNA FUNCION
Más detallesUN ENTORNO A MEDIDA PARA EL DISEÑO Y LA SIMULACIÓN DE MAQUINARIA POR COMPUTADOR
UN ENTORNO A MEDIDA PARA EL DISEÑO Y LA SIMULACIÓN DE MAQUINARIA POR COMPUTADOR Manuel González y Javier Cuadrado Departamento de Ingeniería Industrial II, Campus de Esteiro, 15403 Ferrol Universidad de
Más detallesBPMN Business Process Modeling Notation
BPMN (BPMN) es una notación gráfica que describe la lógica de los pasos de un proceso de Negocio. Esta notación ha sido especialmente diseñada para coordinar la secuencia de los procesos y los mensajes
Más detallesANEXO : PERFILES. Guía de Comunicación Digital para la Administración General del Estado. ANEXO PERFILES
ANEXO : PERFILES Guía de Comunicación Digital para la Administración General del Estado. ANEXO PERFILES ANEXO: PERFILES. 3 1. REQUISITOS ANTES DE TENER EL SITIO WEB. 4 1.1 TOMA DE REQUISITOS. 4 1.2 ANÁLISIS
Más detallesFuncionalidades Software PROYECTOS GotelGest.Net Software para la gestión de Proyectos GotelGest.Net
2012 Funcionalidades Software PROYECTOS GotelGest.Net Software para la gestión de Proyectos GotelGest.Net Servinet Sistemas y Comunicación S.L. www.softwaregestionproyectos.com Última Revisión: Febrero
Más detallesK2BIM Plan de Investigación - Comparación de herramientas para la parametrización asistida de ERP Versión 1.2
K2BIM Plan de Investigación - Comparación de herramientas para la parametrización asistida de ERP Versión 1.2 Historia de revisiones Fecha VersiónDescripción Autor 08/10/2009 1.0 Creación del documento.
Más detalleshttp://www.informatizate.net
http://www.informatizate.net Metodologías De Desarrollo De Software María A. Mendoza Sanchez Ing. Informático - UNT Microsoft Certified Professional - MCP Analísta y Desarrolladora - TeamSoft Perú S.A.C.
Más detalles1 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 detallesFÁBRICA DE SOFTWARE. Presentado por: Ing. Juan José Montero Román Gerente de Fábrica de Software USMP jmonteror@usmp.pe
FÁBRICA DE SOFTWARE Presentado por: Ing. Juan José Montero Román Gerente de Fábrica de Software USMP jmonteror@usmp.pe FÁBRICA DE AUTOS Entrada Salida Autos FÁBRICA DE SOFTWARE Entrada Salida Información
Más detallesBase de datos en Excel
Base de datos en Excel Una base datos es un conjunto de información que ha sido organizado bajo un mismo contexto y se encuentra almacenada y lista para ser utilizada en cualquier momento. Las bases de
Más detallesHacer Realidad BPM en su Organización ADOPTAR BPM A PARTIR DE UN PROYECTO O NECESIDAD DE AUTOMATIZACIÓN
ADOPTAR BPM A PARTIR DE UN PROYECTO O NECESIDAD DE AUTOMATIZACIÓN OBJETIVOS GENERALES 1. Identificar, diseñar, automatizar y habilitar la mejora continua de los procesos relacionados a la necesidad o proyecto
Más detalles3.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 detallesAproximación práctica a ITIL. Proyecto VeredaCS. F07.02.01.00.30.r00
Aproximación práctica a ITIL. Proyecto VeredaCS Introducción En esta presentación pretendemos mostrar una aproximación práctica a la implantación de un modelo de prestación de servicios basado en ITIL
Más detallesUsos de los Mapas Conceptuales en Educación
Usos de los Mapas Conceptuales en Educación Carmen M. Collado & Alberto J. Cañas Introducción Los mapas conceptuales son una poderosa herramienta de enseñanza-aprendizaje. Su utilización en (y fuera de)
Más detallesLiLa Portal Guía para profesores
Library of Labs Lecturer s Guide LiLa Portal Guía para profesores Se espera que los profesores se encarguen de gestionar el aprendizaje de los alumnos, por lo que su objetivo es seleccionar de la lista
Más detallesPlan de Gestión de Configuración. Universidad Nacional de la Patagonia Austral
Plan de Gestión de Configuración Universidad Nacional de la Patagonia Austral Temario 1. Gestión de Configuración de Software 1.1 Definición 2. Plan de SCM 2.1 Estructura Organizacional 2.2 Actividades
Más detallesCOPPEL MANUAL TÉCNICO MCC DE SISTEMAS PROGRAMACIÓN DESCRIPCIÓN DEL PROCESO DE ARQUITECTURA DE SOFTWARE
COPPEL MANUAL TÉCNICO MCC DE SISTEMAS PROGRAMACIÓN DESCRIPCIÓN DEL PROCESO DE ARQUITECTURA DE SOFTWARE Creado en May/14 Objetivo: Contar con una guía de las actividades que se deben realizar en esta fase,
Más detallesExperiencias de la Televisión Digital Interactiva en Colombia - ARTICA
Experiencias de la Televisión Digital Interactiva en Colombia - ARTICA JUAN CARLOS MONTOYA Departamento de Ingeniería de Sistemas, Universidad EAFIT - Centro de Excelencia en ETI - ARTICA Medellín, Colombia
Más detallesPERFIL DEL PUESTO POR COMPETENCIAS Sepa cómo construirlo y evitar bajos desempeños posteriores
PERFIL DEL PUESTO POR COMPETENCIAS Sepa cómo construirlo y evitar bajos desempeños posteriores Martha Alicia Alles Es contadora pública nacional, doctora por la Universidad de Buenos Aires en la especialidad
Más detallesINSTRODUCCION. Toda organización puede mejorar su manera de trabajar, lo cual significa un
INSTRODUCCION Toda organización puede mejorar su manera de trabajar, lo cual significa un incremento de sus clientes y gestionar el riesgo de la mejor manera posible, reduciendo costes y mejorando la calidad
Más detallesObjetos educativos y estandarización en e-learning: Experiencias en el sistema <e-aula>
Objetos educativos y estandarización en e-learning: Experiencias en el sistema Fernández-Manjón, B.1, López Moratalla, J.2 Martínez Ortiz, I. 2, Moreno Ger, P. 2 Universidad Complutense de Madrid,
Más detallesSISTEMAS 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 detallesInstalación de Sistemas de Automatización y Datos
UNIVERSIDADE DE VIGO E. T. S. Ingenieros Industriales 5º Curso Orientación Instalaciones y Construcción Instalación de Sistemas de Automatización y Datos José Ignacio Armesto Quiroga http://www www.disa.uvigo.es/
Más detallesREDES DE ÁREA LOCAL. APLICACIONES Y SERVICIOS EN WINDOWS
REDES DE ÁREA LOCAL. APLICACIONES Y SERVICIOS EN WINDOWS Servicio DNS - 1 - Servicio DNS...- 3 - Definición... - 3 - Instalación... - 5 - Configuración del Servidor DNS...- 10 - - 2 - Servicio DNS Definición
Más detallesMANUAL DE USUARIO APLICACIÓN SYSACTIVOS
MANUAL DE USUARIO APLICACIÓN SYSACTIVOS Autor Edwar Orlando Amaya Diaz Analista de Desarrollo y Soporte Produce Sistemas y Soluciones Integradas S.A.S Versión 1.0 Fecha de Publicación 19 Diciembre 2014
Más detalles4.4.1 Servicio de Prevención Propio.
1 Si se trata de una empresa entre 250 y 500 trabajadores que desarrolla actividades incluidas en el Anexo I del Reglamento de los Servicios de Prevención, o de una empresa de más de 500 trabajadores con
Más detallesECONOMÍA SOCIAL SOLIDARIA
ECONOMÍA SOCIAL SOLIDARIA Módulo básico de capacitación para las organizaciones afiliadas a StreetNet Internacional Objetivos de este módulo de capacitación StreetNet Internacional fue fundada en el 2002
Más detallesActividades para mejoras. Actividades donde se evalúa constantemente todo el proceso del proyecto para evitar errores y eficientar los procesos.
Apéndice C. Glosario A Actividades de coordinación entre grupos. Son dinámicas y canales de comunicación cuyo objetivo es facilitar el trabajo entre los distintos equipos del proyecto. Actividades integradas
Más detallesMANUAL DE AYUDA TAREA PROGRAMADA COPIAS DE SEGURIDAD
MANUAL DE AYUDA TAREA PROGRAMADA COPIAS DE SEGURIDAD Fecha última revisión: Diciembre 2010 Tareas Programadas TAREAS PROGRAMADAS... 3 LAS TAREAS PROGRAMADAS EN GOTELGEST.NET... 4 A) DAR DE ALTA UN USUARIO...
Más detallesCurso: Arquitectura Empresarial basado en TOGAF
Metodología para desarrollo de Arquitecturas (ADM) El ADM TOGAF es el resultado de las contribuciones continuas de un gran número de practicantes de arquitectura. Este describe un método para el desarrollo
Más detallesIntroducción a la extensión de scripting en gvsig 2.0
Introducción a la extensión de scripting en gvsig 2.0 2012 gvsig Association Este documento se distribuye con la licencia Creative Commons 1 2 Índice de contenido 1 Introducción... 3 Instalación de la
Más detallesMetodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales
Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Modulo 03 UML: Vista de Casos de Uso Artefacto: Actores Catedrático MSC. Jose Juan Aviña Grimaldo e-mail josejuan_avina@gmail.com
Más detallesISO 9001:2000 DOCUMENTO INFORMATIVO DOCUMENTO ELABORADO POR CHRISTIAN NARBARTE PARA EL IVECE
ISO 9001:2000 DOCUMENTO INFORMATIVO DOCUMENTO ELABORADO POR CHRISTIAN NARBARTE PARA EL IVECE MARZO 2007 Este documento contesta las preguntas más frecuentes que se plantean las organizaciones que quieren
Más detallesBPM: 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 detallesCONCLUISIONES Y RECOMENDACIONES
CONCLUISIONES Y RECOMENDACIONES CONTENIDO 7.1 Verificación de Hipótesis 7.2 Conclusiones 7.3 Recomendaciones Mónica Cecilia Gallegos Varela - 145 - VERIFICACIÓN DE HIPÓTESIS La hipótesis planteada al inicio
Más detallesAdaptación al NPGC. Introducción. NPGC.doc. Qué cambios hay en el NPGC? Telf.: 93.410.92.92 Fax.: 93.419.86.49 e-mail:atcliente@websie.
Adaptación al NPGC Introducción Nexus 620, ya recoge el Nuevo Plan General Contable, que entrará en vigor el 1 de Enero de 2008. Este documento mostrará que debemos hacer a partir de esa fecha, según nuestra
Más detallesDía 5-6-2012 17:00h Lugar: Obra Social Ibercaja, Sala De actos, Rambla Ferran 38, 3º, Lleida
Resumen de la conferencia Día 5-6-2012 17:00h Lugar: Obra Social Ibercaja, Sala De actos, Rambla Ferran 38, 3º, Lleida Ponente: Luis Muñiz Socio Director de Sisconges & Estrategia y experto en Sistemas
Más detallesFigure 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 detallesEl diagnóstico basado en CobiT Noviembre 2013
El diagnóstico basado en CobiT Noviembre 2013 1. Desarrollo de la Auditoría de Sistemas en Repsol 2. Metodologías 3. Ley Sarbanes Oxley 4. Modelos de madurez y Mapas de riesgos 5. La función de Auditoría
Más detallesJAVATO: UN FRAMEWORK DE DESARROLLO JAVA LIBRE
JAVATO: UN FRAMEWORK DE DESARROLLO JAVA LIBRE Jefe de Servicio de Integración de Aplicaciones Corporativas Dirección General de Informática (Comunidad Autónoma Región de Murcia) Técnico Responsable Dirección
Más detallesTó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 detallesResumen del trabajo sobre DNSSEC
Resumen del trabajo sobre Contenido 1. -...2 1.1. - Definición...2 1.2. - Seguridad basada en cifrado...2 1.3. - Cadenas de confianza...3 1.4. - Confianzas...4 1.5. - Islas de confianza...4 2. - Conclusiones...5
Más detallesGestión de Permisos. Bizagi Suite. Copyright 2014 Bizagi
Gestión de Permisos Bizagi Suite Gestión de Permisos 1 Tabla de Contenido Gestión de Permisos... 3 Definiciones... 3 Rol... 3 Perfil... 3 Permiso... 3 Módulo... 3 Privilegio... 3 Elementos del Proceso...
Más detallesEclipse 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 detallesFigure 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 detallesMejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos
ANEXO VI. Mejores prácticas para el éxito de un sistema de información Uno de los problemas de información dentro de las empresas es contar con datos importantes del negocio y que éstos estén aislados
Más detallesGuía de uso del Cloud Datacenter de acens
guíasdeuso Guía de uso del Cloud Datacenter de Calle San Rafael, 14 28108 Alcobendas (Madrid) 902 90 10 20 www..com Introducción Un Data Center o centro de datos físico es un espacio utilizado para alojar
Más detallesNORMA ISO 31000 DE RIESGOS CORPORATIVOS
NORMA ISO 31000 DE RIESGOS CORPORATIVOS La norma ISO 31000 establece principios y guías para el diseño, implementación y mantenimiento de la gestión de riesgos en forma sistemática y transparente de toda
Más detallesUniversidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática
Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática Metodología Evolutiva Incremental Mediante Prototipo y Técnicas Orientada a Objeto (MEI/P-OO)
Más detallesCMMI (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 detallesGestión de la Configuración
Gestión de la ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ESTUDIO DE VIABILIDAD DEL SISTEMA... 2 ACTIVIDAD EVS-GC 1: DEFINICIÓN DE LOS REQUISITOS DE GESTIÓN DE CONFIGURACIÓN... 2 Tarea EVS-GC 1.1: Definición de
Más detallesPROCEDIMIENTO ESPECÍFICO. Código G114-01 Edición 0
Índice 1. TABLA RESUMEN... 2 2. OBJETO... 2 3. ALCANCE... 2 4. RESPONSABILIDADES... 3 5. ENTRADAS... 3 6. SALIDAS... 3 7. PROCESOS RELACIONADOS... 3 8. DIAGRAMA DE FLUJO... 4 9. DESARROLLO... 5 9.1. PROYECTO
Más detallesInternet aula abierta
MINISTERIO DE EDUCACIÓN Y CIENCIA SECRETARÍA GENERAL DE EDUCACIÓN Y FORMACIÓN PROFESIONAL DIRECCIÓN GENERAL DE EDUCACIÓN, FORMACIÓN PROFESIONAL E INNOVACIÓN EDUCATIVA CENTRO NACIONAL DE INFORMACIÓN Y COMUNICACIÓN
Más detallesGESTIÓN Y CONTROL DEL DESARROLLO E IMPLANTACIÓN DE APLICACIONES
Ciclo Formativo: Módulo: Desarrollo de Aplicaciones Informáticas Análisis y Diseño Detallado de Aplicaciones Informáticas de Gestión Unidad de Trabajo 10: GESTIÓN Y CONTROL DEL DESARROLLO E IMPLANTACIÓN
Más detallesCarlos Ais Conde. Director de la EPJ Pedro Ibarreche del Colegio de Abogados de Vizcaya.
CONVENIOS DE COLABORACION ENTRE ESCUELA DE PRACTICA JURIDICA Y LA UNIVERSIDAD. EXPERIENCIAS DE LA ESCUELA PEDRO IBARRECHE ANTERIORES A LA LEY DE ACCESO A LA PROFESION. Carlos Ais Conde. Director de la
Más detallesITBA - UPM MAGISTER EN INGENIERIA DEL SOFTWARE ANTEPROYECTO DE TESIS
ITBA - UPM MAGISTER EN INGENIERIA DEL SOFTWARE ANTEPROYECTO DE TESIS TÍTULO: TEMA: Sistema generador del mapa de actividades de un proyecto de desarrollo de software. Sistema basado en conocimientos para
Más detallesISO14001:2015. - disponer de un certificado bajo la versión de 2008 en vigor - superar una auditoria bajo los requisitos de la nueva versión
ISO14001:2015 PLAN DE TRANSICIÓN Tras la publicación de la nueva versión de la norma ISO14001 el pasado mes de septiembre se inicia un periodo de convivencia entre las dos versiones de la norma. Este periodo
Más detallesRedes de área local: Aplicaciones y servicios WINDOWS
Redes de área local: Aplicaciones y servicios WINDOWS 4. Servidor DNS 1 Índice Definición de Servidor DNS... 3 Instalación del Servidor DNS... 5 Configuración del Servidor DNS... 8 2 Definición de Servidor
Más detallesCONCLUSIONES. De la información total que acabamos de facilitar al lector podemos realizar el siguiente resumen:
CONCLUSIONES De la información total que acabamos de facilitar al lector podemos realizar el siguiente resumen: 1º. Ha habido un incremento en el número total de consultas y reclamaciones ante las asociaciones
Más detallesMetodología básica de gestión de proyectos. Octubre de 2003
Metodología básica de gestión de proyectos Octubre de 2003 Dentro de la metodología utilizada en la gestión de proyectos el desarrollo de éstos se estructura en tres fases diferenciadas: Fase de Éjecución
Más detallesIntroducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual
Introducción Algunas de las personas que trabajan con SGBD relacionales parecen preguntarse porqué deberían preocuparse del diseño de las bases de datos que utilizan. Después de todo, la mayoría de los
Más detallesDiseño de Actividades
INTRODUCCIÓN ÍNDICE DEL TUTORIAL Una de las primeras cuestiones que tenemos que abordar a la hora de comenzar con el desarrollo del material didáctico dentro de cualquier acción teleformativa, es la elaboración
Más detallesUna puerta abierta al futuro
Una puerta abierta al futuro SOA E ITIL EN LA LEY DE ACCESO ELECTRÓNICO DE LOS CIUDADANOS A LOS SERVICIOS PÚBLICOS (LAECSP) por francisco javier antón Vique La publicación de la Ley de Acceso electrónico
Más detallesCapí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 detallesPlataformas virtuales
Plataformas virtuales Índice Introducción 1 Qué es una plataforma virtual? 2 Para qué sirve una plataforma virtual? 3 Cómo se usa una plataforma virtual? 5 Tipos de plataformas virtuales 6 Conclusión
Más detallesSÍNTESIS Y PERSPECTIVAS
SÍNTESIS Y PERSPECTIVAS Los invitamos a observar, a identificar problemas, pero al mismo tiempo a buscar oportunidades de mejoras en sus empresas. REVISIÓN DE CONCEPTOS. Esta es la última clase del curso.
Más detallesPor qué es importante la planificación?
Por qué es importante la planificación? La planificación ayuda a los empresarios a mejorar las probabilidades de que la empresa logre sus objetivos. Así como también a identificar problemas claves, oportunidades
Más detalles1.1 EL ESTUDIO TÉCNICO
1.1 EL ESTUDIO TÉCNICO 1.1.1 Definición Un estudio técnico permite proponer y analizar las diferentes opciones tecnológicas para producir los bienes o servicios que se requieren, lo que además admite verificar
Más detallesMesa de Ayuda Interna
Mesa de Ayuda Interna Bizagi Suite Mesa de Ayuda Interna 1 Tabla de Contenido Mesa de Ayuda Interna... 3 Elementos del proceso... 5 Apertura del Caso... 5 Inicio... 5 Abrir Caso... 5 Habilitar Cierre del
Más detallesSistema informatizado de Trazabilidad alimentaria
Universdad de Oviedo Trazabilidad Alimentaria Según el reglamento europeo, todas las empresas del sector alimentario han de tener un control de la trazabilidad alimentaria. La forma más eficiente, segura,
Más detallesInstituto Tecnológico de Durango
Instituto Tecnológico de Durango Licenciatura en informática Negocios electrónicos Estrategias de mercadotecnia en la web Armstrong Aramburgo Cristabel Integrantes: Gutiérrez limas Christian Michelle:
Más detallesComisión Nacional de Bancos y Seguros
Comisión Nacional de Bancos y Seguros Manual de Usuario Capturador de Pólizas División de Servicios a Instituciones Financieras Mayo de 2011 2 Contenido 1. Presentación... 3 1.1 Objetivo... 3 2. Descarga
Más detallesPrácticas ITIL para un mejor flujo de trabajo en el helpdesk
Prácticas ITIL para un mejor flujo de trabajo en el helpdesk Se diferencia tres partes de gestión para mejorar la resolución de las incidencias de soporte técnico según el marco ITIL: 1. Gestión de Incidencias
Más detalles