Especificación de procesos en la herramienta CAME MOSKitt4ME y construcción de un marco de evaluación para herramientas CAME y CASE

Proyecto Final de Carrera para obtener la titulación de: Ingeniero Superior en Informática Especificación de procesos en la herramienta CAME MOSKitt4ME y construcción de un marco de evaluación para herramientas CAME y CASE Autor: Alicia Jáen Bielsa 29 septiembre de 2011 Director: Victoria Torres Bosch Co-director: Manuela Albert Albiol índice 1. Introducción......................................................................................................................................1 2. Objetivos...........................................................................................................................................2 3. Introducción a la Ingeniería de Métodos..........................................................................................2 4. Aplicación de MOSKIT4ME para la construcción de soporte a procesos de gvMétrica.................3 4.1. Contexto....................................................................................................................................4 4.2. Metamodelos para la definición de procesos............................................................................4 4.2.1. SPEM 2.0..........................................................................................................................4 4.2.2. BPMN 2.0.........................................................................................................................7 4.3. Definición de Procedimientos con MOSKitt4ME....................................................................8 4.3.1. Características de los Procedimientos de la CITMA........................................................9 4.3.2. Definición de los procedimientos en EPF Composer.....................................................13 4.3.3. Generación de diagramas BPMN desde el EPFC..........................................................16 4.4. Construcción de herramientas CASE con MOSKitt4ME.......................................................20 5. Validación de herramientas CAME y CASE.................................................................................23 6. Conclusiones generales..................................................................................................................24 7.Agradecimientos..............................................................................................................................24 8.Trabajo futuros................................................................................................................................24 9. Anexos............................................................................................................................................25 9.1. ANEXO I - Introducción a la calidad del Software según el Modelo de calidad ISO/IEC 9126...............................................................................................................................................25 9.2ANEXO 2Cuestionario EPFC .............................................................................................29 9.3ANEXO 3Cuestionario Gestor Proyecto ............................................................................34 9.4ANEXO 4: Estructura creada en EPFC con SPEM...............................................................40 10. Referencias...................................................................................................................................49 11.Bibliografía....................................................................................................................................49 Proyecto Final de Carrera 1. Introducción Este documento presenta el Proyecto Final de Carrera (PFC) desarrollado en el periodo de prácticas de la autora en la Conselleria de Infraestructuras, Territorio y Medio Ambiente de Valencia (CITMA). Durante este periodo, la proyectanda ha participado en el Proyecto MOSKitt (Modeling Software Kitt) que se está desarrollando dentro de la CITMA para la construcción de la herramienta CASE MOSKitt. Esta herramienta, es una herramienta Open Source basada en Eclipse cuyo objetivo es proporcionar soporte a la metodología gvMétrica (metodología utilizada en la CITMA para el desarrollo de Software). MOSKitt constituye a su vez una Infraestructura para el Desarrollo de Herramientas de Soporte al Desarrollo de Software dirigido por Modelos (DSDM). En el contexto de MOSKitt, se ha desarrollado un prototipo de herramienta CAME (Computer Aided Method Engineering) para dar soporte a la construcción de métodos de producción de software (MPS). Esta herramienta es la denominada MOSKitt4ME. Este PFC se centra fundamentalmente en esta herramienta. MOSKIITT4ME permite especificar métodos de producción de Software y mediante transformaciones entre modelos, obtener reconfiguraciones de MOSKitt que den soporte software (en forma de herramientas CASE) al método especificado. Esta herramienta CAME utiliza para la definición de MPS el estándar de la OMG SPEM. Este lenguaje permite la definición completa de MPS cubriendo todos los aspectos necesarios para su especificación, permitiendo definir diferentes roles (responsabilidades), diferentes tipos de tareas (por ej. repetitivas o cíclicas), puntos de decisión y bifurcaciones. La definición de MPS realizada en SPEM está más orientada al proceso, donde las tareas se distribuyen entre los diferentes roles que participan en el método. A partir de la especificación SPEM de un MPS, MOSKitt4ME genera una reconfiguración de MOSKitt que da soporte a la ejecución de dicho MPS. Esto se consigue integrando un plugin adicional en la reconfiguración de MOSKitt. A este plugin que constituye la herramienta CASE de soporte al MPS, se le ha llamado Gestor de Proyectos. La herramienta MOSKitt4ME está en fase de desarrollo y es necesario llevar a cabo una validación de la herramienta que permita completar su desarrollo. El presente PFC se centrará en esta validación donde es necesario establecer inicialmente un marco de evaluación. Este marco de evaluación se ha definido utilizando como base un conjunto de estándares ISO. Este marco contempla las dos herramientas involucradas en este entorno: •La herramienta CAME que constituye propiamente MOSKitt4ME y •La herramienta CASE que genera la CAME. En base al marco de evaluación se definirán plantillas que van a servir para evaluar con usuarios reales de la CITMA ambas herramientas. 1 Alicia Jaén Bielsa 2. Objetivos Los objetivos del proyecto son los siguientes: •Especificar utilizando MOSKitt4ME un conjunto de procedimientos de gvMétrica utilizados en la CITMA. • Construir un Marco de Evaluación para la validación de MOSKitt4ME: ◦Construir cuestionarios para validar la herramienta CAME. ◦Validar las herramientas CASE que genera MOSKitt4ME, haciendo especial énfasis en el Gestor de Proyectos incluido en ésta: ▪Desarrollar una serie de proyectos SW utilizando el Gestor de Proyectos como soporte a uno de los procedimientos de la CITMA definidos en el objetivo anterior. ▪Construir cuestionarios para validar la herramienta CASE. 3. Introducción a la Ingeniería de Métodos A continuación se va a realizar una breve introducción a la Ingeniería de Métodos. Este punto va a ser tratado en base las definiciones que se encuentran en [1] . Los términos análisis de operaciones, simplificación del trabajo e ingeniería de métodos se utilizan con frecuencia como sinónimos. En la mayor parte de los casos se refieren a una técnica para aumentar la producción por unidad de tiempo y, en consecuencia, reducir el costo por unidad. En 1932, el termino "Ingeniería de Métodos" fue desarrollado y utilizado por H.B.Maynard y sus asociados, quedando definido como sigue: "Es la técnica que somete cada operación de una determinada parte del trabajo a un delicado análisis en orden a eliminar toda operación innecesaria y en orden a encontrar el método más rápido para realizar toda operación necesaria; abarca la normalización del equipo, métodos y condiciones de trabajo; entrena al usuario a seguir el método normalizado; realizado todo lo precedente (y no antes).” En ese momento, la Ingeniería de Métodos surgió como una forma prometedora de abordar la adaptación de los métodos de producción de software y las herramientas para especificar las necesidades del proyecto. Tal y como se explica en [1], los proyectos de desarrollo de software pueden estar enmarcados en numerosos contextos y utilizar una amplia variedad de elementos circunstanciales para poder ser llevados a cabo. Estos elementos, especialmente los que proporcionan las personas o los factores organizacionales, tienen un gran impacto en el desarrollo del proceso. Por lo tanto, con el fin de maximizar la productividad y mejorar la calidad del desarrollo de software, el proceso de desarrollo debe de estar gobernado por un método de producción de software que sea adaptable a estas necesidades circunstanciales de las que se habla. Con el fin de abarcar la necesidad de adaptación de los métodos, es necesario encontrar alternativas que no solo permitan la definición interna (y adaptación) de los métodos sinó también la 2 Proyecto Final de Carrera construcción de las correspondientes herramientas de soporte. Hasta ahora, la disciplina de la Ingenieria de Métodos Situacional parece ser la solución más prometedora para cubrir esta necesidad. Esta ingeniería estudia y propone técnicas y métodos para llevar a cabo la construcción de los métodos que están en sintonía con las situaciones específicas de los proyectos de desarrollo. Estas técnicas permiten la creación de métodos de desarrollo adecuado para cualquier situación de desarrollo. El desarrollo de cada sistema se inicia entonces, con una fase de definición del método, donde se construye el método de desarrollo en el lugar. La disciplina de Ingeniería de Métodos Situacional, abarca todos los aspectos en cuanto a la creación de métodos1 para situaciones específicas y constituye una sub-área de un amplio campo llamado Ingeniería de Métodos. La Ingeniería de Métodos se puede definir según [2] como: “La disciplina de la ingeniería que diseña, construye y adapta métodos, técnicas y herramientas para el desarrollo de Sistemas de Información”. Durante los últimos veinte años muchas propuestas teóricas han contribuido a establecer una base teórica amplia y sólida en este campo. Sin embargo, las herramientas existentes no están a la altura de las expectativas principalmente debido a la complejidad que conlleva poner esta base teórica en práctica. Con el fin de mejorar esta situación, en [1] se propone el uso del paradigma de Desarrollo de Software Dirigido por Modelos como solución que permite manejar esta complejidad de forma eficiente. De este modo se debe definir un marco metodológico que hace uso de técnicas de metamodelado y transformaciones de modelos para abordar el diseño e implantación de métodos de producción de software. Por lo tanto, con el fin de contribuir a la mejora de la situación,se están haciendo grandes esfuerzos de estandarización (Ej: las iniciativas de SPEM [3] y la ISO/IEC 24744 [4]). Estos estándares tienen el objetivo de proveer lenguajes dedicados a la especificación del método que no presenten las deficiencias encontradas en las teorías iniciales. 4. Aplicación de MOSKIT4ME para la construcción de soporte a procesos de gvMétrica En esta sección se describe cómo se han obtenido herramientas CASE de soporte a un conjunto de procedimientos utilizados en la CITMA utilizando MOSKitt4ME. El primer apartado introduce el contexto en el que se ha realizado el trabajo. El siguiente apartado describe como se han definido los procedimientos en MOSKitt4ME. En esta sección se introducen de forma general los lenguajes y las notaciones gráficas que incluye MOSKitt4ME (SPEM y BPMN) y que han sido utilizados para la especificación de los procedimientos de la CITMA. Por último se presenta cómo MOSKitt4ME obtiene las herramientas CASE a partir de la definición de los procedimientos. 1 En este documento, los términos “método” y “metodología” son usados como sinónimos de metodo de producción de software. 3 Alicia Jaén Bielsa 4.1. Contexto El presente PFC se ha realizado en el contexto de una beca realizada en la CITMA. La CITMA gestiona diversos proyectos, entre los que se encuentra MOSKitt. MOSKitt permite definir los procesos de desarrollo de software que se utilizan en la Conselleria. Estos procesos siguen una metodología definida también internamente como gvMétrica y es la encargada de realizar el seguimiento interno de los proyectos de desarrollo. El uso de esta metodología hace necesario la implantación de una herrramienta CASE que facilite su aplicación. En el proceso de adaptación de la metodología gvMétrica a la herramienta MOSKitt surgen problemas de usabilidad, integración y en la evolución de la metodología. Es posible abordar las limitaciones tecnológicas que se comentan en este mismo punto en cuanto a la adaptabilidad de la metodologia a la herramienta, de tal forma que MOSKitt sea más que una herramienta CASE de soporte a gvMétrica. Esto se realiza dando soporte desde MOSKitt a las fases de: •Desarrollo de MPS: incorporando soporte de herramienta para la especificación de MPS. •Ejecución de MPS: incorporando un entorno de ejecución de proyectos (basado en roles, productos, guías, etc...). MOSKitt4ME propone un marco metodológico para la construcción de MPSs que consta de las siguientes fases: 1. Construcción del modelo del MPS. En esta fase se especifica el método utilizando el lenguaje SPEM. Este modelo se puede construir desde cero o reutilizando fragmentos de otros métodos.El modelo no contiene detalles sobre tecnologías o notaciones. 2. Configuración del MPS. En esta fase se configura el modelo construido en la fase anterior incluyendo detalles sobre las notaciones o tecnologías que se utilizarán durante la ejecución del método. 3. Implementación del MPS En esta fase se obtiene una herramienta CASE que soporta el método modelado. La obtención de esta herramienta es semi-automática. La herramienta que se obtiene ofrece soporte a: 1. Proceso, proporcionando un entorno de guía para la ejecución de proyectos. 2. Producto, proporcionando las herramientas necesarias para la manipulación (creación, modificación, …) de los productos involucrados en el proyecto. 4.2. Metamodelos para la definición de procesos A continuación se describen los metamodelos de los que MOSKitt4ME hace uso para la especificación de procesos. En primer lugar se introduce SPEM y en segundo lugar BPMN. 4.2.1. SPEM 2.0 Como se ha comentado anteriormente, en MOSKitt4ME se utiliza (en el diseño del método), el estándar SPEM para la especificación del modelo del método, por ello a continuación se realiza una breve introducción al lenguaje. 4 Proyecto Final de Carrera SPEM (Software Process Engineering Metamodel) es un estándar de la OMG cuyo objetivo principal es proporcionar un marco formal para la definición de procesos de desarrollo de sistemas y de software así como para la definición y descripción de todos los elementos que los componen. SPEM ofrece un marco de trabajo para el modelado, documentación, presentación, gestión e intercambio de los procesos de desarrollo Software y sus componentes, dando una sintaxis y una estructura común para cada aspecto del proceso de desarrollo, incluyendo: roles, tareas, work products y guías. La idea central de SPEM para representar procesos está basada en tres elementos básicos: rol, producto de trabajo y tarea . Las tareas representan el esfuerzo a hacer, los roles representan quien lo hace y los productos de trabajo representan las entradas que se utilizan en las tareas y las salidas que se producen. La idea central subyacente es que un modelo de proceso consiste, básicamente, en decir quien (rol) realiza qué (tarea) para, a partir de unas entradas (productos de trabajo) obtener unas salidas (productos de trabajo). Figura 1: Idea básica de proceso en SPEM 2 Además de un metamodelo para ingeniería de procesos, SPEM también es un marco de trabajo conceptual que provee los conceptos necesarios para modelar, documentar, presentar, publicar, gestionar, intercambiar y realizar métodos y procesos software. Por ello, está destinado a ingenieros de procesos, jefes de proyectos, gestores de proyectos y programas; que son responsables de mantener e implementar procesos para sus organizaciones o para proyectos concretos. La siguiente figura muestra un resumen del marco de trabajo general de SPEM, es decir, de los escenarios más habituales de su uso. 5 Alicia Jaén Bielsa Figura 2: Marco de trabajo conceptual de SPEM 2.0 Tal como se deduce del marco de trabajo (ver Figura 2), en SPEM 2 se distinguen dos grupos de conceptos a la hora de implementar una metodología : 1. Primero, se puebla el Method Content (contenido del método) con Content Elements (elementos de contenido), es decir, los elementos primarios o constructores básicos. 2. Después, se combinan y reutilizan dichos elementos para obtener Processes (procesos). La siguiente imagen muestra esta estructura: Figura 3: Aspectos principales para modelar con SPEM 6 Proyecto Final de Carrera •En un lado se observa el paquete Method Content, donde se especifican los Métodos. El objetivo principal de este paquete es el de definir tareas (Task Definition), organizarlas en distintos pasos (Steps), definir cuáles son los productos de entrada-salida de cada una de ellas (Work Product Definition) y especificar quién ha sido el que ha realizado dicha tarea (Role Definition). •En la intersección de los métodos y los procesos se encuentran las guías (Guidance) son plantillas, ejemplos, roadmaps, etc, y dan soporte tanto a Métodos como a procesos. •En el otro lado se encuentran los Procesos. El elemento principal para representar los procesos en SPEM 2.0, es la Actividad, que está formada por un grupo de elementos (otras actividades, task uses, etc) que están definidos dentro de un espacio de nombres y para los que se han descrito una serie de relaciones específicas para un método o proyecto. 4.2.2. BPMN 2.0 En el presente proyecto, las descripciones de Proceso realizadas en SPEM, se utilizan para construir diagramas BPMN que muestran las tareas, dependencias entre estas, productos y fases de forma gráfica, por ello, vamos a hacer una pequeña introducción a esta notación. BPMN (Business Process Modelling Notation) es un estándar de la BPMI (Business Process Management Initiative), organismo que ha sido absorbido recientemente por la OMG2 cuyo principal objetivo es “proporcionar una notación fácilmente comprensible por todos los usuarios del negocio, desde los analistas, los desarrolladores técnicos hasta aquellos que monitorizarán y gestionarán los procesos“. Se trata de un estandar internacional de modelado de procesos aceptado por la comunidad. 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 que fluyen entre los participantes de las diferentes actividades. Es importante modelar con BPMN ya que cumple las siguientes características: •BPMN es un estándar internacional de modelado de procesos aceptado por la comunidad. •BPMN es independiente de cualquier metodología de modelado de procesos. •BPMN crea un puente estandarizado para disminuir la brecha entre los procesos de •negocio y la implementación de estos. •BPMN permite modelar los procesos de una manera unificada y estandarizada •permitiendo un entendimiento a todas las personas de una organización. La siguiente imagen muestra un ejemplo de un proceso modelado con BPMN: 2 Object Management Group, http://www.omg.org/ 7 Alicia Jaén Bielsa Cada uno de los paquetes de contenido tiene la siguiente estructura: Figura 12: Ejemplo de la estructura de los modelos en SPEM (FASE CASI) Es importante resaltar que el orden de edición en cada tarea ha sido el siguiente: 1. Crear los productos que se van a necesitar tanto si son de entrada o de salida. Esto se realiza en la carpeta Work Products del elemento el paquete. 2. Crear las guías que se van a necesitar para la tarea. Esto se realiza en la carpeta Guidance del elemento el paquete. 3. Crear la Tarea en la carpeta Tasks. Cabe comentar que en el ANEXO 4 existe una descripción más detallada del proceso que se ha seguido en la creación del contenido de cada uno de los paquetes creados. Una vez se han definido los elementos de contenido de método ( tal y como se explica en el ANEXO 4) éstos se pueden utilizar para crear procesos, en este caso los cuatro procesos de la CITMA escogidos. Cabe señalar que no es necesario haber creado elementos de contenido para utilizarlos en la creación de procesos, pues se pueden definir directamente en un proceso, pero esta opción dificulta mucho la reutilización y actualización posterior de dichos elementos y de sus procesos. Se han definido cuatro procesos, en base a los dos tipos de procedimientos que se debían definir como se muestra en la siguiente imagen: 14 Contiene las tareas de la Fase CASI Contiene las guías de ayuda de las tareas de la Fase CASI Contiene los productos creados en esta Fase CASI Proyecto Final de Carrera Figura 13: Contenido de la carpeta Processes Se va a tomar como ejemplo para mostrar el resultado de la definición de un proceso en SPEM, el procedimiento de Nuevas Aplicaciones general (NAPL_TIPO01GENERAL, Ver Figura 14). Los pasos que se han seguido en la creación de cada proceso ha sido: 1. Crear un elemento Activity por cada Fase (contiene subtareas). 2. Crear elementos Task Descriptor para cada tarea ejecutable (son subtareas que se ejecutan). 3. Crear dependencias (Columna Predecesors) entre las tareas de cada fase (deben ser tareas “hoja”). 4. Especificar las características ( si es necesario) en las tareas. En este paso, se seleccionan las casillas de las columnas que se refieran a repetibilidad de una tarea (Repeteable), Opcionalidad (Optional), etc...de forma que queden reflejados algunos requisitos en los procedimientos. 15 Alicia Jaén Bielsa Figura 14: Tareas en el procedimiento NAPL general A modo de ejemplo, la siguiente imagen muestra la estructura a nivel más interno de la Fase CASI: Figura 15: Estructura detallada de la fase CASI 4.3.3. Generación de diagramas BPMN desde el EPFC En este proyecto, los diagramas BPMN cumplen una labor primordial, ya que serán el resultado de la definición en base a los procedimientos definidos en SPEM con el EPF Composer. Es importante indicar que ha sido necesario la extensión en MOSKitt para poder generar diagramas BPMN's a partir de los modelos SPEM . 16 Proyecto Final de Carrera La forma de generar diagramas a partir de cada procedimiento es la siguiente: 1. Seleccionamos uno de los procedimientos definidos en SPEM. 2. Pulsamos sobre el elemento raíz (este elemento será el primero que se ejecute) 3. De este modo, comienza la generación de diagramas BPMN's en base a las fases, tareas, roles, recursos y dependencias definidas en los procedimientos. 4. Como resultado, se crea una carpeta nueva llamada Activiti que contiene todos los diagramas generados junto con las imagenes. En la siguiente imagen podemos ver una de las carpetas generadas en el directorio del procedimiento NAPL_TIPO01GENERAL: Figura 16: Carpeta activii creada para el proceso NAPL_TIPO01GENERAL Es importante señalar que la creación de esta carpeta es visible desde al vista Project Explorer de MOSKitt. A continuación se muestra cada uno de los procedimientos en SPEM y el BPMN generado a partir de el: 17 Alicia Jaén Bielsa •Procedimiento NAPL_TIPO01GENERAL en SPEM: •Procedimiento NAPL_TIPO01GENERAL en BPMN •Procedimiento NAPL_ProcedimientoTipo01GvHidra en SPEM 18 Proyecto Final de Carrera •Procedimiento NAPL_ProcedimientoTipo01GvHidra en BPMN •Procedimiento NAPL_ProcedimientoTipo01GvNix en SPEM •Procedimiento NAPL_ProcedimientoTipo01GvNix en BPMN 19 Alicia Jaén Bielsa •Procedimiento Mantenimiento en SPEM •Procedimiento Mantenimiento en BPMN 4.4. Construcción de herramientas CASE con MOSKitt4ME Una vez especificados los modelos de los procedimientos con el EPFC y el Activity Designer, se han generado automáticamente con MOSKitt4ME las herramientas CASE de soporte a estos procedimientos. Al entorno de la herramienta CASE generada con MOSKitt4ME para la ejecución de instancias de estos procedimientos se le denomina Gestor de Proyectos. En la figura 17 se muestra el resultado obtenido en la ejecución con el Gestor de Proyectos en la plataforma MOSKitt. Como podemos observar, el asistente de creación de un proyecto de tipo gvMétrica en MOSKitt, nos permite seleccionar la creación del Proyecto (Ver Figura 17) en base a la antigua metodología (Dashboard) o haciendo uso del Gestor de Proyectos incorporado (SPEM Process) para cada tipo de Proyecto. 20 Proyecto Final de Carrera Figura 17: Asistente en la creación de un Proyecto tipo gvMétrica en MOSKitt, en concreto NAPL-gvHidra. A modo de ejemplo, vamos a tomar como referencia para observar la ejecución del Gestor en MOSKitt, un proyecto de tipo NAPL-gvHidra. La siguiente imagen muestra el Gestor en la vista Method Execution de MOSKitt: 21 Alicia Jaén Bielsa Figura 18: Vistas presentes en el Gestor de Proyectos sobre MOSKitt Cada una de las vistas del Gestor se comentan a continuación: El Gestor de Proyectos dota a la herramienta CASE generada de una interfaz gráfica compuesta por una serie de vistas en Eclipse. Cada una de estas vistas proporcionan funcionalidad específica pero su objetivo principal es facilitar la participación del usuario en un proyecto específico. Los detalles de estas vistas son: •Product Explorer: Esta vista muestra el conjunto de productos que son usados (consumidos, finalizados y/o producidos) en el transcurso y en las tareas finalizadas del proceso. Esta vista puede ser filtara por roles para que los usuarios que sigan un rol específico tengan solo acceso a los productos que gestionan ellos. •Process: Esta vista muestra que tareas pueden ser ejecutadas dentro del estado actual del Proyecto. La ejecución de las tareas se puede levar a cabo de forma automática (lanzando la transformación asociada a la tarea) o manualmente por el ingeniero de Software ( por medio de una herramienta software asociada al producto de salida de la tarea). De forma similar a la vista Product Explorer, esta vista también puede ser filtrada por rol, viendo solo las tareas en las que el rol está involucrado. 22 Proyecto Final de Carrera •Guides: Esta vista muestra la lista de guías asociadas a la tarea seleccionada en la vista Process. El objetivo de estas guías es asistir al usuario durante la ejecución de dicha tarea, proporcionando algunos detalles sobre cómo deberían manipularse los productos que fueron asociados en la fase de configuración del método. 5. Validación de herramientas CAME y CASE Para completar el proceso de desarrollo de todo software es necesario llevar a cabo una etapa de validación que evalúe la calidad del software desarrollado. Una de las técnicas que se puede utilizar para esta validación consiste en definir cuestionarios que permitan capturar las bondades o defectos del software. Estos cuestionarios son completados por los usuarios finales de la herramienta. Para construir estos cuestionarios se ha definido un marco de evaluación atendiendo a los siguientes estándares: •ISO 9001: estándar que describe el sistema de calidad utilizado para mantener el desarrollo de un producto que implique diseño. •ISO 9000-3: documento específico que interpreta el ISO 9001 para el desarrollador de software. •ISO 9004-2: documento que proporciona las directrices para el servicio de facilidades del software como soporte de usuarios. •ISO/IEC 9126: documento desarrollado en un intento de identificar los atributos clave de calidad para el software. La norma ISO/IEC 9126 está enfocada a la calidad de Producto. El modelo estructura los atributos de calidad de software en seis características (funcionalidad, fiabilidad, utilidad, eficacia, capacidad de mantenimiento y portabilidad) que se subdividen en subcaracterísticas. Por el tipo de características que se desean evaluar en las herramientas CAME y CASE, se ha decidido adoptar el estándar ISO/IEC para la construcción del marco de evaluación de las herramientas CAME y CASE. Se han realizado dos cuestionarios con el fin de evaluar la herramienta CAME y CASE. Los cuestionarios se han realizado en base al estándar ISO/IEC 9126 [Ver ANEXO I] con el fin de obtener información sobre los aspectos más relevantes del modelado con SPEM usando el EPFC y del uso de los procedimientos modelados utilizando el Gestor de Proyectos integrado en MOSKitt. En los anexos 2 y 3 [VER ANEXO 2 y 3] se encuentran los cuestionarios creados. En dichos cuestionarios se añaden también las instrucciones para completarlos, de forma que facilite el trabajo. Inicialmente, el objetivo de la creación de los cuestionarios era la de evaluar la herramienta EPFC y obtener en base a los resultados obtenidos, una valoración de los principales funcionalidades, requisitos, carencias, debilidades y mejoras fundada en las respuestas de los cuestionados pero finalmente el experimento se realizará más adelante con usuarios tanto expertos como no en el 23 Alicia Jaén Bielsa 7-¿Había modelado con anterioridad usando SPEM? Responda al siguiente cuestionario teniendo especial atención al tipo de preguntas que se plantean (los tipos de preguntas se explican al comienzo de este documento) 1.FUNCIONALIDAD VALORACIÓN 1.1 Adecuación -¿Es posible aplicar el editor al ámbito de trabajo (académico) requerido? [ ] 1.2 Idoneidad -¿Ofrece una forma de trabajo apropiada? -¿Se ajusta a los requisitos necesarios para definir los procedimientos? -Puntúe según convenga: -¿Ofrece un entorno adecuado para definir el procedimiento? [ ] [ ] [ ] 1.3 Precisión -¿Permite definir todos los requisitos funcionales de los procedimientos? -¿Es posible definir la información necesaria para especificar el funcionamiento completo del procedimiento? -¿Se han encontrado limitaciones en la definición? -Describa las limitaciones encontradas brevemente: -¿Se han podido subsanar utilizando mecanismos derivados internos? -¿Qué número de requisitos se han visto mermados? (porcentaje % ): [ ] [ ] [ ] [ ] [ ] 30 Proyecto Final de Carrera 1.4 -Facilidades de uso: -¿Dispone de ayuda interactiva?: -¿La herramienta está en Castellano?: -¿Existe la posibilidad de deshacer el último cambio?: -¿Se trata de una herramienta monousuario? : -¿Se trata de una herramienta multiusuario? : -Si es así, indique el número máximo de usuarios: -¿Permite trabajo en grupo?: [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] 2 SEGURIDAD VALORACIÓN -¿Existen mecanismos que permitan guardan copias de seguridad?: -Si es así, ¿es posible acceder a las copias de seguridad con facilidad?: -¿Es posible deshacer cambios con facilidad?: [ ] [ ] [ ] 4 PERSONALIZACIÓN DE LA HERRAMIENTA VALORACIÓN -Elementos de la herramienta que se pueden configurar: -Metodología : -Documentación: -Impresos: -Pantallas: -Iconos: -Símbolos: -Menús : -Funciones: -Nomenclatura: [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] 4 USABILIDAD VAORACIÓN 4.1 Operatividad -¿La herramienta facilita la definición de procedimientos? -¿La herramienta permite definir fácilmente el siguiente tipo de información? -Tareas -Fases [ ] [ ] [ ] 31 Alicia Jaén Bielsa -Recursos -Roles -Dependencia [ ] [ ] [ ] 4.2 Atractivo -¿Presenta una estructura ordenada?: -¿Presenta una estructura intuitiva?: -¿Utiliza interfaces amigables?: [ ] [ ] [ ] 5 EFICIENCIA VALORACIÓN 5.1 Utilización de los recursos -Indique la rapidez de la herramienta según su experiencia: -¿La relación calidad/consumo de recursos es equilibrada?: [ ] [ ] 6EFECTIVIDAD -¿El editor es útil en el trabajo que necesita el usuario?: -Si es así, ¿lo realiza en el tiempo razonable?: [ ] [ ] 7 FIABILIDAD VALORACIÓN 7.1 Tolerancia de Fallos -¿Se ha producido pérdida de datos?: -¿Se han roto modelos por acciones permitidas?: [ ] [ ] 8 PRUEBAS VALORACIÓN -¿Dispone de Trazadores?: -¿Dispone de Simuladores?: [ ] [ ] 32 Proyecto Final de Carrera 8.1 Control de calidad VALORACIÓN -¿Dispone de comprobadores de requisitos? : -¿Dispone de generadores de prueba basados en las especificaciones del diseño? : -¿Dispone de trazadores de requisitos a probar? : [ ] [ ] [ ] 8 UTILIZACIÓN DE RECURSOS VALORACIÓǸ Indique la cantidad de memoria que requiere la herramienta en sus PC: -Lógica: -Sistemas operativos/Versión (especificar) : -Otros requisitos(especificar) : -Física: -Espacio requerido en disco: (MB) -¿Necesita pantalla gráfica?: -¿Necesita ratón? : [ ] [ ] [ ] 9 SATISFACCIÓN VALORACIÓN -Puntúe la herramienta en términos generales y en base a su criterio y experiencia al realizar las tareas para las que fueron planeadas: -¿Ha alcanzado sus expectativas iniciales? -¿Escogería de nuevo esta herramienta para realizar este tipo de tareas? [ ] [ ] [ ] Comentarios acerca de la herramienta: 33 Alicia Jaén Bielsa 9.3ANEXO 3Cuestionario Gestor Proyecto CUESTIONARIO Gestor de Proyectos El presente cuestionario se ha elaborado con el fin de evaluar la herramienta generada en base a procedimientos definidos en SPEM, l Gestor de Proyectos. El G.P se ha implantado en MOSKitt con el fin de dar una nueva opción en el proceso de desarrollo de aplicaciones con MOSKitt. El G.P dota a la herramienta CASE generada de una interfaz gráfica compuesta por una serie de vistas en Eclipse que no existían en la herramienta Dashboard. El cuestionario consta dos apartados: • Preguntas relacionadas con el perfil del usuario que va a realizar la prueba. • Preguntas relacionadas con el uso de la herramienta. En el cuestionario existen tres tipos de preguntas: •Tipo 1: Preguntas directas, en las que unicamente se indicará Si o No •Tipo 2: Preguntas en las que es necesario puntuar un aspecto de la herramienta en la cual se usarán los valores de 1 a 5, siendo 1 la nota más baja y 5 la más alta. •Tipo 3: Preguntas breves de desarrollo. Responda a las siguientes preguntas: Nº PERFIL DEL USUARIO RESPUESTA 1 -Especifique sus estudios : 2 -¿Hombre o mujer?: 3 -¿Conoce el Proyecto MOSKitt? 4-¿Es usuario habitual de MOSKitt? 5 -¿Ha utilizado alguna vez MOSKitt como herramienta de trabajo? 6 -¿Conoce el concepto MOSKitt4ME? 34 Proyecto Final de Carrera 7 -¿Ha usado alguna vez el Dashboard? 8 -Puntúe su valoración en cuanto al Dashboard como ayuda metodológica: 9-En su trabajo diario, ¿utiliza software que contenga funcionalidades de ayuda como guías o Gestores de Proyecto? Responda al siguiente cuestionario teniendo especial atención al tipo de preguntas que se plantean (los tipos de preguntas se explican al comienzo de este documento). NOTA: Si no ha utilizado MOSKitt el asistente Dashboard, omita las preguntas que hablan de el. 1.FUNCIONALIDAD VALORACIÓN 1.1 Idoneidad -¿El G.P ofrece una forma de trabajo apropiada?: -Puntúe según convenga: -¿Ofrece un entorno adecuado como guía durante el trabajo?: [ ] [ ] 1.3 Precisión -¿Permite visualizar la información relevante en todo momento? -¿Es necesario cambiar de vistas de forma rápida? -¿Se han encontrado limitaciones en el manejo? -Describa las limitaciones encontradas brevemente: [ ] [ ] [ ] 35 Alicia Jaén Bielsa -¿Se han podido subsanar utilizando mecanismos derivados internos? [ ] 1.4 -Facilidades de uso: -¿El G.P está en castellano?: -¿Se trata de una herramienta monousuario? : -¿Se trata de una herramienta multiusuario? : -Si es así, indique el número máximo de usuarios: -¿Permite trabajo en grupo?: [ ] [ ] [ ] [ ] [ ] [ ] 2 SEGURIDAD VALORACIÓN -¿Existen mecanismos que permitan guardan copias de seguridad durante el proceso?: -Si es así, ¿es posible acceder a las copias de seguridad con facilidad?: -¿Es posible deshacer cambios con facilidad?: [ ] [ ] [ ] 4 PERSONALIZACIÓN DE LA HERRAMIENTA VALORACIÓN -Elementos de la herramienta que se pueden configurar: -Metodología : -Documentación: -Impresos: -Pantallas: -Iconos: -Símbolos: -Menús : -Funciones: -Nomenclatura: [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] 4 USABILIDAD VAORACIÓN 4.1 Operatividad -¿La herramienta facilita el seguimiento del proceso de los proyectos? [ ] 36 Proyecto Final de Carrera -¿Permite abrir editores?: -¿Permite visualizar plantillas?: -¿Permite crear productos nuevos?: -¿Permite visualizar las guías de ayuda asociadas (Cheatsheets)?: -¿Permite ejecutar transformaciones?: -¿El G.P ha creado la estructura de plantillas correcta en base al tipo de proyecto seleccionado?: -Comente si ha tenido algún problema a la hora de ejecutar transformaciones desde el Gestor de Proyectos: -¿La herramienta permite diferenciar claramente los siguientes tipos de informacion ?: -Tareas: -Fases: -Recursos: -Roles: -Dependencias entre tareas: [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] 4.2 Atractivo -¿El G.P permite visualizar la información más relevante de cada proceso?: -¿El G.P permite visualizar la información más relevante de forma ordenada?: -¿Las distintas vistas del G.P son intuitivas? -¿El G.P utiliza interfaces amigables?: [ ] [ ] [ ] [ ] EFICIENCIA VALORACIÓN 37 Alicia Jaén Bielsa 5 5.1 Utilización de los recursos -Indique la rapidez de la herramienta según su experiencia: -¿La relación calidad/consumo de recursos es equilibrada?: [ ] [ ] 6EFECTIVIDAD -¿Ejecuta las tareas correctas en base a sus órdenes?: -Si es así, ¿lo realiza en el tiempo razonable?: -Indique el número de tareas que ha ejecutado de forma errónea: [ ] [ ] 7 FIABILIDAD VALORACIÓN 7.1 Tolerancia de Fallos -¿Se ha producido pérdida de datos?: -¿Se han roto modelos, plantillas o información por acciones permitidas?: [ ] [ ] 8 PRUEBAS VALORACIÓN 8.1 Control de calidad VALORACIÓN -¿Dispone de comprobadores de requisitos? : -¿Dispone de trazadores de requisitos a probar? : [ ] [ ] 9 SATISFACCIÓN VALORACIÓN -Puntúe la herramienta en términos generales y en base a su criterio y 38 Proyecto Final de Carrera experiencia al realizar las tareas para las que fueron planeadas: -¿Prefiere trabajar con el Gestor de Proyectos o con Dashboard?. Indique razones de la elección: -¿El G.P ha alcanzado sus expectativas iniciales?: -¿Escogería de nuevo la opción del G.P para realizar este tipo de tareas?: -¿Cree que el G.P aporta mejoras a MOSKitt?: -Indique qué mejoras aporta el G.P: -Indique qué carencias ha encontrado en el G.P : -Comentarios acerca de la herramienta en relación con el Dashboard (si no se dispone de criterios suficientes unicamente valore la herramienta según su experiencia): [ ] [ ] [ ] [ ] 39 Alicia Jaén Bielsa Figura 26: Pestañas de la tarea CASI-PDAT-ENTID_Análisis de Entidades Una vez se crea una tarea, es necesario especifiar información a cerca de quien la realiza (Pestaña Rol) qué productos tiene como entrada y/o salida (Pestaña Work Products) y qué guías tiene de ayuda (Pestaña Guidance). Por esta razón, es recomendable por comodidad crear primero los productos y guías y como último paso, crear las tareas y enlazar con la información pertinente. Por lo tanto, el ultimo paso es añadir en cada una de las pestañas la información necesaria, enlazando mediante el asistente la Descripción necesaria (Ver Figura 27), los Roles (Ver Figura 28), Productos (Ver Figura 29) y Guías (Ver Figura 30). 46 Proyecto Final de Carrera 10. Referencias [1] Cervera, M. Model Driven Method Enginneering. A Supporting Infraestructure. Tesina del Máster. Departamento de Sistemas Informáticos y Computación. Universidad Politécnica de Valencia. Diciembre 2010. [2] Brinkkemper, S.: Method engineering: engineering of information systems development methods and tools. Information and Software Technology, 38, 275-280, (1996). [3] Software & Systems Process Engineering Meta-model (SPEM) OMG Available Specification version 2.0. OMG Document Number: formal/2008-04-01. [4] ISO/IEC 24744: Software Engineering: Metamodel for Development Methodologies. International Standards Organization/ International Electrotechnical Commission, Geneva (2007). 11.Bibliografía •RUIZ, Francisco, VERDUGO, Javier. Guía de Uso de SPEM 2 con EPF Composer [en linea].Versión 3.0. Abril 2008. Disponible sur Internet: http://alarcos.infcr.uclm.es/doc/psgc/doc/lec/parte2b/guia-spem2&epf_v30.pdf. •ALBERT Manolil, TORRES Victoria. MOSKitt4ME: Ingeniería de Métodos al alcance de su organización. [Presentación gráfica]. Valencia, 24 diapositivas. Universidad Politécnica de Valencia. •BONET, Begoña. MOSKitt: Soporte a una Metodología de Desarrollo Dirigido por Modelos, Basada en Eclipse.[Presentación gráfica]. Valencia, 43 diapositivas. Conselleria de Infraestructuras, Territorio y Medio Ambiente. •NICKNAFS Ali, RAMSIN Raman. Computer-aided Method Engineering : An Analysis of existing enviroments. Departament of Computing Engineering, Sharif University of Technology, Tehran, Iran. •Object Management Group. Software Process Engineering Metamodel (SPEM) 2.0 (final adopted specification). http://www.omg.org/docs/ptc/07-03-03.pdf •Method Workbench User's Guide, http: //www.metacase.com/support/40/manuals/mwb40sr2a4.pdf •ALIAGA CAVERO, Felipe. Calidad de Software.[Presentación gráfica].2ª ed,Instituto Continental, [2010], 46 diapositivas. •Object Management Group. Meta Object Facility (MOF) Core Specification. Version 2.0. formal/06-01-01, http://www.omg.org/docs/formal/06-01-01.pdf, último acceso Septiembre 2011. 49