Ingenier´ıa Dirigida por Modelos y Calidad de Software

Universidad de Cadiz

Escuela Superior de Ingenierıa

Modelado, simulacion y pruebas de procesos y

tratamiento de senales y de datos

TRABAJO DE INVESTIGACION

Ingenierıa Dirigida por Modelos y

Calidad de Software

AUTOR

Ivan Ruiz Rube

TUTOR

Dr. Juan Manuel Dodero Beardo

Cadiz, 2012

Agradecimientos

Quiero expresar mi agradecimiento al tutor del presente trabajo, Juan Ma-nuel Dodero, a la profesora de la Universidad de Sevilla, Marıa Jose Esca-lona y por supuesto a mi familia y a mi pareja.

Resumen

La gestion de la calidad del software tiene por objetivo planificar, asegurar,controlar y mejorar la calidad del software que se desarrolla o se mantiene.Sin embargo, suele ser habitual que no se le dediquen los esfuerzos y recur-sos necesarios para su puesta en marcha, aludiendo a que las actividadesde gestion de la calidad no conducen a producir software. Por este moti-vo, es importante investigar nuevas maneras de llevar a cabo actividades decalidad, con el menor esfuerzo posible.

En este trabajo, se examina el estado del arte de la investigacion cientıficaacerca del soporte que ofrece la ingenierıa dirigida por modelos (MDE) a lagestion de la calidad en el software. Debido a que la calidad del productosoftware depende en gran medida de la calidad de los procesos que se utilizan,se ha optado por dividir la investigacion en dos etapas:

Estudio de alcance sobre la utilizacion de MDE en actividades clasicasde la calidad (interna, externa y en uso) del producto software: me-dicion, revisiones tecnicas, mejora, pruebas, simulacion y calidad deservicio.

Revision exhaustiva de la literatura sobre el uso de MDE como basepara los procesos software, desde la perspectiva de la gestion de losprocesos de negocio y las fases que componen su ciclo vida: diseno,analisis, configuracion, ejecucion y evaluacion.

Los resultados de la investigacion han permitido comprobar que el desa-rrollo sistematico de modelos, permite agilizar practicas comunes en la ges-tion de la calidad en el producto, ası como contribuir en la definicion deprocesos organizacionales y dar soporte a la ejecucion y monitorizacion delos proyectos.

Palabras clave: Ingenierıa dirigida por Modelos, Gestion de la Calidad,Calidad del Producto Software, Ingenierıa de Procesos Software, Ingenierıade Metodos, Gestion de Procesos Software.

Abstract

Software quality management aims to plan, ensure, control and improvethe quality of software that is being developed or maintained. However, itis common that you do not realize of the necessary efforts and resourcesneeded for its implementation, referring to quality management activitiesdo not produce directly software. For this reason, it is important to researchnew ways of carrying out quality activities, with the minimum effort.

In this work, we review the state-of-the-art of scientific research on thesupport offered by the model-driven engineering (MDE) paradigm to soft-ware quality management. Due to the fact that software product qualitydepends largely on the process quality performed, we have decided to divideresearch into two phases.

Scoping study on the use of MDE on traditional activities of the softwa-re product quality (internal, external, in-use): measurement, technicalreviews, improvement, testing, simulation and quality of service.

Comprehensive review of the literature on the use of MDE as thebasis for software process, from the perspective of business processmanagement and its lifecycle’s phases: design, analysis, configuration,enactment and evaluation.

The research results have revealed that the systematic development ofmodels can expedite common practices in the management of product qua-lity. Also, MDE can contribute to define organization’s set of standard pro-cesses and support the enactment and monitoring of projects.

Keywords: Model-driven Engineering, Quality Management, Software Pro-duct Quality, Software Process Engineering, Method Engineering, BusinessProcess Management.

Contenido

I Prolegomeno 1

1. Introduccion 31.1. Metodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2. Contenido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Problema 62.1. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

II Antecedentes 8

3. Gestion de la Calidad 103.1. Calidad del Producto . . . . . . . . . . . . . . . . . . . . . . . 103.2. Calidad del Proceso . . . . . . . . . . . . . . . . . . . . . . . 11

4. Ingenierıa Dirigida por Modelos 144.1. Arquitectura de modelado . . . . . . . . . . . . . . . . . . . . 144.2. Niveles de abstraccion . . . . . . . . . . . . . . . . . . . . . . 154.3. Estandares OMG . . . . . . . . . . . . . . . . . . . . . . . . . 164.4. Tecnologıas relacionadas . . . . . . . . . . . . . . . . . . . . . 17

III Calidad en el Producto Software con MDE 19

5. Estudio de alcance 215.1. Calidad interna . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.1.1. Medicion . . . . . . . . . . . . . . . . . . . . . . . . . 215.1.2. Revisiones tecnicas . . . . . . . . . . . . . . . . . . . . 225.1.3. Mejora de la calidad . . . . . . . . . . . . . . . . . . . 22

5.2. Calidad externa . . . . . . . . . . . . . . . . . . . . . . . . . . 235.2.1. Pruebas de software . . . . . . . . . . . . . . . . . . . 235.2.2. Simulacion de software . . . . . . . . . . . . . . . . . . 23

5.3. Calidad en uso . . . . . . . . . . . . . . . . . . . . . . . . . . 24

iv

Contenido v

5.3.1. Calidad de servicio . . . . . . . . . . . . . . . . . . . . 24

IV Calidad en el Proceso Software con MDE 25

6. Modelado de Procesos Software 276.1. Lenguajes de modelado . . . . . . . . . . . . . . . . . . . . . 27

6.1.1. SPEM . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.1.2. SEMDM . . . . . . . . . . . . . . . . . . . . . . . . . . 296.1.3. MSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316.1.4. OPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.1.5. Otras propuestas . . . . . . . . . . . . . . . . . . . . . 33

6.2. Herramientas de soporte . . . . . . . . . . . . . . . . . . . . . 346.2.1. EPF Composer . . . . . . . . . . . . . . . . . . . . . . 346.2.2. Objecteering . . . . . . . . . . . . . . . . . . . . . . . 356.2.3. Enterprise Architect . . . . . . . . . . . . . . . . . . . 356.2.4. TopCased . . . . . . . . . . . . . . . . . . . . . . . . . 356.2.5. IRIS Software . . . . . . . . . . . . . . . . . . . . . . . 376.2.6. Visual Studio ALM . . . . . . . . . . . . . . . . . . . 386.2.7. Otras herramientas . . . . . . . . . . . . . . . . . . . . 40

7. Soporte al ciclo de vida 417.1. Diseno de procesos . . . . . . . . . . . . . . . . . . . . . . . . 41

7.1.1. Metodologıas agiles . . . . . . . . . . . . . . . . . . . . 417.1.2. Otras metodologıas . . . . . . . . . . . . . . . . . . . . 427.1.3. Enfoques para la mejora organizacional . . . . . . . . 427.1.4. Otros usos . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.2. Analisis de procesos . . . . . . . . . . . . . . . . . . . . . . . 437.2.1. Verificacion . . . . . . . . . . . . . . . . . . . . . . . . 437.2.2. Validacion . . . . . . . . . . . . . . . . . . . . . . . . . 447.2.3. Simulacion . . . . . . . . . . . . . . . . . . . . . . . . 447.2.4. Metricas . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.3. Configuracion de procesos . . . . . . . . . . . . . . . . . . . . 457.3.1. Implantacion . . . . . . . . . . . . . . . . . . . . . . . 457.3.2. Adaptacion . . . . . . . . . . . . . . . . . . . . . . . . 46

7.4. Ejecucion de procesos . . . . . . . . . . . . . . . . . . . . . . 467.4.1. Operacion . . . . . . . . . . . . . . . . . . . . . . . . . 467.4.2. Monitorizacion . . . . . . . . . . . . . . . . . . . . . . 48

7.5. Evaluacion de procesos . . . . . . . . . . . . . . . . . . . . . . 48

Contenido vi

V Epılogo 49

8. Analisis de los resultados 518.1. Producto software . . . . . . . . . . . . . . . . . . . . . . . . 51

8.1.1. Calidad interna . . . . . . . . . . . . . . . . . . . . . . 518.1.2. Calidad externa . . . . . . . . . . . . . . . . . . . . . . 518.1.3. Calidad en uso . . . . . . . . . . . . . . . . . . . . . . 52

8.2. Proceso software . . . . . . . . . . . . . . . . . . . . . . . . . 528.2.1. Diseno de procesos . . . . . . . . . . . . . . . . . . . . 528.2.2. Analisis de procesos . . . . . . . . . . . . . . . . . . . 548.2.3. Configuracion de procesos . . . . . . . . . . . . . . . . 548.2.4. Ejecucion de procesos . . . . . . . . . . . . . . . . . . 548.2.5. Evaluacion de procesos . . . . . . . . . . . . . . . . . . 55

9. Conclusiones 56

10.Lıneas de investigacion futuras 58

Referencias 60

Siglas 66

Indice de figuras

3.1. Modelo de calidad de ISO/IEC 25000 . . . . . . . . . . . . . 113.2. Ciclo de vida de un proceso de negocio . . . . . . . . . . . . . 12

4.1. Arquitectura de 4 niveles de la OMG . . . . . . . . . . . . . . 15

6.1. Paquetes del metamodelo de SPEM 2.0 . . . . . . . . . . . . 306.2. Elementos principales del metamodelo SPEM 2.0 . . . . . . . 316.3. Elementos principales del metamodelo SEMDM . . . . . . . . 326.4. Elementos principales del metamodelo MSF 4.0 . . . . . . . . 326.5. Elementos principales del metamodelo OPF . . . . . . . . . . 336.6. Entorno de modelado SPEM en EPF . . . . . . . . . . . . . . 346.7. HTML generado desde un modelo SPEM generado con EPF . 356.8. Entorno de modelado SPEM en Objecteering . . . . . . . . . 366.9. Entorno de modelado SPEM en Enterprise Architect . . . . . 366.10. Entorno de modelado SPEM en TopCased . . . . . . . . . . . 376.11. Entorno de modelado y validacion de procesos en IRIS . . . . 386.12. Entorno de trabajo de Visual Studio ALM . . . . . . . . . . . 396.13. Guia de proceso MSF para el desarrollo agil . . . . . . . . . . 39

8.1. Volumen de contribuciones segun la fase del ciclo de vida . . 538.2. Utilizacion de lenguajes de modelado de procesos software . . 53

vii

Parte I

Prolegomeno

1

2

En esta primera parte, se ofrece una introduccion al estudio realizado, asıcomo la descripcion del problema que motiva el desarrollo del presente tra-bajo.

Capıtulo 1

Introduccion

El objetivo del presente trabajo es poner en practica las competencias ad-quiridas durante el periodo formativo del Doctorado en Ingenierıa y Arqui-tectura, organizado por la Universidad de Cadiz1.

Ası mismo, con el desarrollo de este trabajo se pretende descubrir posi-bles lıneas de investigacion para una futura tesis doctoral, en el ambito dela mejora de los procesos software (Software Process Improvement (SPI)).

En este trabajo se pretende realizar una completa revision de la biblio-grafıa y desarrollar nuevos avances e innovaciones en la gestion de la calidaddel software, mediante la aplicacion de aspectos de la ingenierıa dirigida pormodelos (Model-Driven Engineering (MDE)).

El documento puede resultar de interes a todos aquellos interesados enla mejora del software, aprovechando la potencia inherente que ofrece eldesarrollo y la transformacion sistematica de modelos.

Dado que mis intereses personales de investigacion estan mas cercanos ala mejora del proceso software, este trabajo se focalizara especialmente enla utilizacion de MDE en este ambito.

Este trabajo podemos categorizarlo dentro del area de estudio ”Gestionde la Calidad”, siendo el mismo, de tipo descriptivo, presentando el estadodel arte en la aplicacion de modelos.

1.1. Metodo

En el desarrollo del presente trabajo, hemos seguido el metodo (con una levealteracion en el orden de las actividades) desarrollado por la Universidad deSkovde2, en Suecia y descrito en [9], con el fin de obtener un trabajo originalde investigacion, accesible y comprensible sobre el dominio del problema encuestion.

Las actividades que forman parte del proceso son:

1Universidad de Cadiz - http://www.ca.es2University of Skovde - http://www.his.se/english

3

Capıtulo 1. Introduccion 4

Desarrollo de la propuesta de proyecto: plasmada en el anteproyectoelaborado previamente y de mismo tıtulo.

Desarrollo de la descripcion del problema: comienzo de la memoria,identificacion de los objetivos y presentacion de los antecedentes.

Perseguir los objetivos: realizacion de la revision de la literatura.

Presentar y analizar la informacion: elaboracion del cuerpo principalde la memoria.

Presentar conclusiones e identificar trabajo futuro: finalizacion de lamemoria.

Desarrollar la version final del informe: revision de la memoria con loscomentarios de los tutores.

Defender el trabajo de forma oral: exposicion publica ante el tribunal.

De cara a la realizacion de este trabajo, se ha realizado un analisis de dis-tintas publicaciones cientıficas localizadas a traves de las siguientes fuentesde informacion:

Buscadores bibliograficos:

Google Scholar - http://scholar.google.com

TDG Scholar - http://scholar.tdg-seville.info

Inspec - http://www.iee.org/Publish/INSPEC

Organizaciones de estandarizacion:

International Organization for Standardization (ISO) - http://www.iso.org

International Electrotechnical Commission (IEC) - http://www.iec.org

Object Management Group (OMG) - http://www.omg.org

Software Engineering Institute (SEI) - http://www.sei.cmu.edu

World Wide Web Consortium (W3C) - http://www.w3.org

Instituto Nacional de Tecnologıas de la Informacion (INTECO) - http://www.inteco.es

Capıtulo 1. Introduccion 5

Proyectos de investigacion:

ModelPlex - http://www.modelplex.org

Vulcano - http://www.ines.org.es/vulcano

MetaMethod - http://meta.dsic.upv.es

Ası mismo, para el desarrollo del presente trabajo de investigacion sehan empleado las siguientes herramientas:

Latex - http://www.latex-project.org

TexMaker - http://www.xm1math.net/texmaker

Mendeley - http://www.mendeley.com

1.2. Contenido

Este documento representa el resultado principal del trabajo de investiga-cion, el cual se estructura de la siguiente forma:

La primera parte (capıtulos 1-2) ofrece una introduccion al estudio rea-lizado, el problema y los objetivos establecidos para la investigacion.

En la segunda parte (capıtulos 3-4) se resumen los antecedentes necesa-rios para una correcta comprension del problema de investigacion: la gestionde la calidad en el software y la ingenierıa dirigida por modelos.

La tercera parte (capıtulo 5) presenta un estudio de alcance de las dis-tintas posibilidades que ofrece la ingenierıa dirigida por modelos a la gestionde la calidad en el producto software.

La cuarta parte (capıtulos 6-7) detalla una revision completa de la li-teratura referente a la utilizacion de MDE para los procesos software, des-cribiendo lenguajes y herramientas para el modelado y su utilizacion en elcontexto del ciclo de vida de los procesos de negocio.

El epılogo (capıtulos 8-10) recoge el analisis y evaluacion de los resultadosde la investigacion, las conclusiones y las lıneas de trabajo futuras.

Finalmente, se recogen las referencias utilizadas para el desarrollo deltrabajo y el conjunto ordenado de siglas que se han utilizado a lo largo delas paginas del presente trabajo.

Capıtulo 2

Problema

El papel de la calidad en la ingenierıa del software sigue siendo vital enel exito o el fracaso de los proyectos. La gestion de la calidad tiene porobjetivo planificar, asegurar, controlar y mejorar la calidad del software quese desarrolla o se mantiene.

Existen diferentes definiciones del concepto de calidad. Una de las massignificativas es la propuesta por la ISO [28]: ”La calidad es el grado enel que un conjunto de caracterısticas inherentes cumple con los requisitosestablecidos”.

A partir de la definicion de calidad, surgen dos preguntas importantes:(i) ¿Cuales son los requisitos? y (ii) ¿Quien define y valida los requisitos?Las respuestas a estas preguntas difieren dependiendo del ambito de calidadque estemos considerando:

A nivel de proceso, los requisitos son definidos por el estandar o modelode referencia que la organizacion adapte y suelen ser validados poralguna entidad externa autorizada. Por ejemplo, en el caso concretode Capability Maturity Model Integration (CMMI), la validacion serealiza mediante la aplicacion del Standard CMMI Appraisal Methodfor Process Improvement (SCAMPI).

A nivel de producto, los requisitos del software son determinados por losclientes con el fin de satisfacer sus necesidades concretas y por tanto,son ellos los que en ultima instancia, validan su correcta implementa-cion.

2.1. Motivacion

Es una premisa, que la calidad del software desarrollado (producto) vienedirectamente influenciada por la calidad en la ejecucion de las actividadesdefinidas en los procesos organizacionales [34]. Por este motivo, los esfuerzos

6

Capıtulo 2. Problema 7

relativos a la calidad deben focalizarse tanto a nivel de producto, como anivel de proceso.

Aunque la ejecucion de las actividades de gestion de la calidad sea fun-damental para la correcta consecucion de los objetivos planteados con eldesarrollo del software, es comun que no se le dediquen los esfuerzos y re-cursos necesarios. Esto se debe a que suelen considerarse las actividades decalidad como ”no productivas”, en el sentido que no conducen a generar nue-vo software. Por este motivo, es importante investigar nuevas maneras dellevar a cabo exhaustivas actividades de calidad, con la menor interaccionhumana posible y por tanto, con el menor coste asociado.

2.2. Objetivos

MDE es el paradigma que abarca el conjunto de metodos, tecnicas y tecnolo-gıas destinadas a construir software de forma mas rapida y sencilla, medianteel desarrollo y transformacion de modelos. El uso mas habitual de MDE esla generacion automatica de codigo fuente a partir de modelos definidos enUnified Modeling Language (UML), proporcionando fundamentalmente me-joras en la productividad: ahorro en tiempos de desarrollo y reduccion delnumero de errores.

Podemos plantearnos la siguiente pregunta: ¿Serıa posible utilizar el en-foque MDE para potenciar la calidad del software?. La hipotesis de investi-gacion de partida se basa en la idea de que sı es posible usar MDE comomecanismo de soporte a las actividades de gestion de la calidad.

En terminos generales, nuestra meta fundamental es conocer el estadodel arte actual en el uso del paradigma MDE como mecanismo de soportea la gestion de la calidad en el software. Ası pues, en el presente trabajo deinvestigacion se plantean satisfacer los siguientes objetivos:

1. Realizar un estudio de alcance sobre trabajos existentes relativos aMDE con respecto a la calidad del producto software, desde las pers-pectivas de la calidad interna, externa y en uso.

2. Recopilar, categorizar y analizar estudios relativos a MDE como so-porte a los procesos software, desde la optica de la gestion de procesosde negocio (Business Process Management (BPM)).

3. Realizar un analisis global de la utilizacion de MDE de cara a la gestionde la calidad e identificar posibles lıneas de trabajo futuras.

Parte II

Antecedentes

8

9

En los siguientes capıtulos se resumen la gestion de la calidad en el softwarey la ingenierıa dirigida por modelos, fundamentos necesarios para la correctacomprension del problema de investigacion.

Capıtulo 3

Gestion de la Calidad

Al inicio del capıtulo 2, se relataron los dos ambitos existentes a la hora deentender la calidad en el software: calidad a nivel de proceso y calidad a nivelde producto. En este capıtulo trataremos los conceptos basicos relativos aestos dos ambitos.

3.1. Calidad del Producto

El software como producto tiene caracterısticas diferenciadoras de cualquierotro tipo de producto: naturaleza inmaterial, frecuencia de cambios, depen-dencia del entorno donde se ejecuta, etc.

La calidad del producto software es un elemento de decision cada vezmayor a la hora de discernir entre productos similares o entre proveedoresde productos [27].

La gestion de la calidad del producto tiene un doble objetivo: por unlado, comprobar que el software cumple con los requisitos establecidos (ve-rificacion) y por otro, asegurar que el producto satisface el uso por el cualse ha motivado su desarrollo o mantenimiento (validacion).

Un error comun en muchos desarrollos de software, es dejar para el finaldel proyecto las actividades de calidad. Es importante que la gestion decalidad se lleve a cabo durante el transcurso del ciclo de vida del software.Por tanto, la calidad del producto no solo se refiere al software final, sinoque se hace efectiva a cualquier artefacto intermedio que se desarrolle y seanecesario para la construccion del software final.

El nuevo estandar ISO/IEC 25000 [29] define un conjunto de atributos ocaracterısticas con el cual “evaluar” la calidad del software como producto:funcionalidad, fiabilidad, usabilidad, eficiencia, portabilidad y mantenibili-dad. En la figura 3.1 podemos observar el detalle del modelo de calidad quepropone el estandar.

Ası mismo, el estandar define tres vistas diferenciadas en el estudio dela calidad de un producto:

10

Capıtulo 3. Gestion de la Calidad 11

Figura 3.1: Modelo de calidad de ISO/IEC 25000

Interno (caracterısticas intrınsecas, como el codigo fuente)

Externo (comportamiento del producto, como en una prueba)

En uso (durante la utilizacion efectiva por parte del usuario)

3.2. Calidad del Proceso

Dentro de la Ingenierıa del Software, existe una disciplina reciente, conoci-da como la Ingenierıa de Procesos Software (Software Process Engineering(SPE)). Esta disciplina tiene como motivacion, la creacion de un marco detrabajo tecnico y de gestion, que permita la produccion sistematica de soft-ware mediante procesos bien definidos.

Un proceso software es un conjunto coherente de polıticas, estructurasorganizacionales, tecnologıas, procedimientos y artefactos que son necesariospara concebir, desarrollar, instalar y mantener un producto software.

Disponer de un conjunto de procesos acordes a las estrategias y necesida-des de la organizacion (recursos humanos y tecnicos, tipologıa de proyectos,etc.) es fundamental para asegurar la correcta gestion de los proyectos, locual, redundara finalmente en la calidad de los productos desarrollados.

Las iniciativas mas importantes para la definicion, implantacion, evalua-cion y mejora de la calidad de los procesos software, son CMMI y el modeloISO/IEC 15504, tambien conocido como Software Process Improvement andCapability Determination (SPICE).

Hoy en dıa, existe gran interes por todas aquellas iniciativas referentesa la mejora de procesos software, siendo Espana, el paıs europeo con mayor


Figura 3.2: Ciclo de vida de un proceso de negocio

numero de organizaciones certificadas en CMMI [70].Por otra parte, la gestion de procesos de negocio (BPM), es un campo

que esta levantando gran interes en ambitos empresariales y tecnicos. Laidea subyacente es permitir a las organizaciones definir su actividad en ter-minos de sus procesos de negocio, ya sean de desarrollo o mantenimiento deproductos, o prestacion de servicios.

Weske [75] definio a los procesos de negocio como aquel conjunto de acti-vidades que se desarrollan en coordinacion y bajo un entorno organizacionaly tecnologico, que permiten alcanzar un determinado objetivo de negocio.Los procesos son llevados a cabo por una unica organizacion pero puedeninteractuar con otros interesados, como por ejemplo, el cliente que adquiereun determinado producto.

En este punto, podrıamos considerar entonces, que los procesos softwa-re son un tipo particular de procesos de negocio, ya que se basan en unacoleccion de actividades relacionadas entre sı, cuyo objetivo fundamental esdesarrollar y mantener un producto software de interes para el cliente. Asıpues, los procesos software siguen por tanto el ciclo de vida propuesto en[75] y que podemos observar en la figura 3.2.

Con respecto a la definicion de los procesos software, podemos encontrarlos siguientes supuestos:

Procesos no definidos explıcitamente: Debido a la ausencia de proce-dimientos formales, el desarrollo de los proyectos queda siempre some-


tido a la habilidad y el criterio de los participantes en el mismo. Portanto, esta situacion dificulta la medicion y el alcance de los objetivosde negocio.

Descripciones textuales: Los miembros de la organizacion disponen deuna serie de procedimientos que deberan seguir. Sin embargo, proce-sos con muchas actividades o interrelaciones pueden ser difıciles decomprender y en ocasiones dar lugar a interpretaciones diferentes.

Notaciones graficas: Utilizar diagramas de procesos acompanados de des-cripciones en formato textual favorecen la comprension de los proce-sos por parte de los interesados. Sin embargo, esto no asegura que losprocedimientos establecidos se sigan por parte de los miembros de laorganizacion.

Modelos de procesos: Definir los procesos software mediante modelos pro-cesables por el ordenador, permite beneficiarnos de las oportunidadesque ofrece la ingenierıa dirigida por modelos [63], con el fin de darsoporte a la ejecucion y evaluacion de los procesos implantados.

Capıtulo 4

Ingenierıa Dirigida por

Modelos

La ingenierıa dirigida por modelos (MDE) es una disciplina dentro de la In-genierıa del Software que tiene por objetivo dar soporte a las actividades delciclo de vida del software, utilizando los modelos como principal artefacto.

El Desarrollo de Software Dirigido por Modelos (DSDM) o Model-DrivenDevelopment (MDD), tiene por objetivo la construccion de sistemas softwa-re, mediante el desarrollo y la transformacion sistematica de modelos, ele-vando ası el nivel de abstraccion requerido para el desarrollo de sistemas.Ası pues, podemos considerar a MDD como un subconjunto de MDD, en elsentido en que MDE va mas alla de las actividades de desarrollo e incluyetambien otros procesos adicionales de la ingenierıa del software.

Por otra parte, existe lo que se conoce como la arquitectura dirigida pormodelos (Model-Driven Architecture (MDA)) que es la propuesta de la OMGpara el desarrollo de modelos, basada en una arquitectura de modelado, unaserie de niveles de abstraccion y un conjunto de estandares y tecnologıas.

4.1. Arquitectura de modelado

La arquitectura de modelado propuesta por la OMG se presenta en la figura4.1. Los cuatro niveles propuestos en la arquitectura son:

Datos (Nivel 0): informacion que maneja el sistema. Los datos son con-formes a un determinado modelo.

Modelo (Nivel 1): descripcion o especificacion de un sistema realizadocon un lenguaje determinado. Representacion abstracta de un sistemao parte de el. Todo modelo es conforme a un metamodelo.

Metamodelo (Nivel 2): definicion de los constructores y reglas necesariaspara definir la semantica de los modelos. Contempla un lenguaje de

14

Capıtulo 4. Ingenierıa Dirigida por Modelos 15

Figura 4.1: Arquitectura de 4 niveles de la OMG

modelado general como UML o especıficos (Domain Specific Languages(DSL)). Todo metamodelo es conforme a un meta-metamodelo.

Meta-metamodelo (Nivel 3): definicion de un lenguaje de modelado pa-ra metamodelos.

4.2. Niveles de abstraccion

MDA promueve separar la especificacion de la funcionalidad de un siste-ma, de su implementacion en cualquier plataforma tecnologica concreta. LaOMG establece 4 puntos de vista, segun el nivel de abstraccion de los mo-delos con respecto al sistema o parte del sistema que representa:

Computation Independent Model (CIM): Es un modelo independien-te de la computacion, de tal modo que se centra en el entorno y losprocesos de negocio alrededor del sistema, sin contener informacionalguna respecto de la estructura del mismo.

Platform Independent Model (PIM): Es un modelo independiente dela plataforma que describe el sistema sin entrar en detalles tecnologi-cos.

Platform Specific Model (PSM): Es un modelo que incluye informa-cion relativa a como el sistema va a utilizar la tecnologıa o plataformanecesaria. Este modelo combina las especificaciones del PIM con res-pecto a un modelo particular de plataforma (Java1, Microsoft .NET2,

1Java Enterprise Edition (JEE) - http://www.oracle.com/technetwork/java/javaee2.NET Framework - http://www.microsoft.com/net


etc.).

Code: Es el codigo que da soporte a la ejecucion del software.

El proceso de desarrollo dirigido por modelos segun la OMG conlleva lassiguientes actividades (simplificado):

1. Construir modelos independientes de la plataforma (PIM) para repre-sentar la funcionalidad descrita en los procesos de negocio (modelosCIM).

2. Seleccionar el modelo de plataforma tecnologica.

3. Transformar los modelos PIM en modelos PSM para la tecnologıa se-leccionada

4. Transformar los modelos PSM en codigo ejecutable.

El elemento clave en este proceso es la transformacion de modelos, quepuede definirse como el proceso por el cual un modelo se convierte en otro delmismo sistema. Las transformaciones se realizan mediante la asociacion deconstructores del metamodelo origen con los constructores correspondientesdel metamodelo destino.

En sentido general, podemos entender dos tipos de transformaciones:Model-to-Model (M2M) y Model-to-Text (M2T), segun el metamodelo des-tino corresponda a otro modelo abstracto del sistema o a un modelo decodigo.

4.3. Estandares OMG

A continuacion, se describen someramente los principales estandares de laOMG relacionados con MDA.

MOF

Meta-Object Facility (MOF) es un estandar que provee de un marco de tra-bajo de gestion de metadatos y de un conjunto de servicios para permitir eldesarrollo de la interoperabilidad de sistemas dirigidos por modelos y meta-datos. En la arquitectura de modelado descrita en 4.1, MOF estarıa situadoen el nivel de meta-metamodelo (nivel 3). Con MOF es posible desarrollarnuevos lenguajes de modelado.


UML

UML es un lenguaje estandar para la visualizacion, especificacion, construc-cion y documentacion de sistemas software y no software. Esta situado enel nivel 2 de la arquitectura de modelado. Dispone de un mecanismo de ex-tension mediante perfiles, que permite crear lenguajes basados en el paramodelar dominios concretos.

OCL

Object Constraint Language (OCL) es un lenguaje formal usado para des-cribir restricciones sobre modelos UML y realizar consultas sobre los objetosdescritos en ellos.

QVT

Query, Views and Transformations (QVT) es un lenguaje que permite definirtransformaciones entre modelos (M2M) cuyos lenguajes han sido definidosempleando MOF.

MOFM2T

MOF Model to Text Transformation Language (MOFM2T) es una aproxi-macion basada en plantillas que permite definir transformaciones desde unmodelo a codigo ejecutable.

XMI

XML Metadata Interchange (XMI) es otro estandar OMG que permite elintercambio de modelos definidos mediante MOF, utilizando para ello unarepresentacion basada en eXtensible Markup Language (XML).

4.4. Tecnologıas relacionadas

Ademas de los estandares de la OMG, existen multitud de tecnologıas pro-venientes de la comunidad Eclipse3 que se han convertido en estandares defacto. A continuacion, se relatan algunos de estos estandares.

EMF

Eclipse Modeling Framework (EMF) se trata de un framework para el mo-delado y generacion de codigo orientado a la construccion de aplicaciones enJava, basadas en un modelo de datos estructurado.

3Eclipse Modeling Project - http://www.eclipse.org/modeling


GMF

Graphical Modeling Framework (GMF) proporciona los componentes nece-sarios para desarrollar editores graficos bajo el runtime de Eclipse, para losmodelos gestionados con EMF.

XText

XText es una herramienta que permite desarrollar DSLs textuales, ası comoeditores de texto integrados bajo el entorno de ejecucion de Eclipse.

ATL

Atlas Transformation Language (ATL) es un lenguaje y un entorno de traba-jo que permite desarrollar transformaciones (M2M) entre modelos definidos.

MOFScript

Este framework permite desarrollar transformaciones entre modelos y tex-tos (M2T), soportando la generacion de codigo ejecutable desde modelosgraficos.

Parte III

Calidad en el Producto

Software con MDE

19

20

En el siguiente capıtulo, se recogen los resultados del estudio de alcancerealizado, con el objetivo de proporcionar una vision general concerniente ala aplicacion de MDE para la gestion de la calidad del producto software.

Capıtulo 5

Estudio de alcance

En esta seccion se presenta un estudio de alcance sobre estudios relacionadoscon MDE y la gestion de la calidad en el producto software, desde las tresperspectivas descritas en el epıgrafe 3.1.

5.1. Calidad interna

La calidad interna hace referencia a las caracterısticas intrınsecas del pro-ducto software. A continuacion, se describen las actividades clasicas respectoa las actividades clasicas de gestion de la calidad interna del software.

5.1.1. Medicion

Con el objetivo de detectar posibles puntos de mejora en el producto soft-ware, las organizaciones suelen realizar actividades de medicion y analisis.Ejemplos: numero de defectos detectados tras la entrega, volumen de lıneasde codigo (Lines of Code (LoC)), etc.

Disponer de modelos efectivos para los artefactos del ciclo de vida, puedeayudar en la recogida y el calculo automatico de metricas.

Ası por ejemplo, en [10], se describe una propuesta academica para desa-rrollar modelos de medicion de calidad sobre artefactos tıpicos en cualquierproceso de desarrollo de ingenierıa web, mediante la utilizacion de un meta-modelo especıfico basado en una ontologıa para la medicion de software. Eltrabajo ademas, plantea un escenario de evaluacion.

En [50] se propone un marco teorico para el desarrollo de modelos deevaluacion de calidad. Las actividades del proceso se resumen en: (1) iden-tificacion de objetivos de calidad; (2) seleccion de elementos (objetos) sobrelos que impactan esos objetivos; (3) para cada uno de estos elementos, defi-nicion del conjunto de propiedades a estudiar y (4) establecer el metodo deevaluacion y las metricas a utilizar. El trabajo plantea tambien un escenariode evaluacion.

21

Capıtulo 5. Estudio de alcance 22

5.1.2. Revisiones tecnicas

Ya sean rigurosas o informales, las revisiones tecnicas tienen por objetivoasegurar que los artefactos desarrollados cumplan con los requisitos de ca-lidad especificados: directrices organizacionales, estandares, aspectos sobremantenibilidad y legibilidad, etc.

El proceso de revision de los artefactos puede ser en parte automatizado,siempre y cuando se generen los modelos adecuados para ellos.

En [36] se presenta un software que permite transformar modelos deprocesos de negocio, en modelos basados en Business Process ExecutionLanguage (BPEL). Ademas, se describe el uso de tecnicas relativas a pa-trones de modelado, reconocimiento de anti-patrones y chequeo de modelos.El software incluye una paleta grafica de componentes de transformacion demodelos, listos para utilizar.

En [19] se describe una herramienta que permite verificar la calidad de de-terminados modelos de ingenierıa con respecto a la metodologıa web NDT1,ası como asegurar el control de la trazabilidad entre los elementos de losmodelos. Estas comprobaciones se realizan chequeando la adherencia a losmetamodelos, y las relaciones entre los mismos. La aplicabilidad de herra-mienta se argumenta mediante un estudio de campo.

OCL es un lenguaje apropiado para definir reglas sobre modelos UML.En [20], los autores describen un caso de esudio uso de un demostradorsoftware (basado en OSLO2) en el contexto de un repositorio de modelos. Eneste trabajo, se presenta un prototipo capaz de ejecutar consultas OCL sobremodelos generados desde Matlab3, con el objetivo de verificar restriccionesen cuanto a estandares, apariencia, layout, convencion de nombres de losmodelos, etc.

5.1.3. Mejora de la calidad

Mejorar la calidad de los artefactos intermedios construidos durante el ciclode vida, redundara en la calidad del producto final. Por este motivo, sise pueden representar los artefactos del proceso software como modelos,podemos aprovechar los beneficios que ofrecen las tecnicas de mejora decalidad de modelos.

En [72] se presenta un prototipo acompanado de un caso de estudio,con el cual realizar de manera semi-automatica tareas habituales de refina-miento de calidad en los modelos de clases, entre ellas: la incorporacion derestricciones textuales y la aplicacion de patrones.

En [46] se describe la aplicacion de las tecnicas de refactoring de codigoa los modelos UML, con el objetivo de mejorar la calidad de los disenos,

1Navigational Development Techniques (NDT) - http://www.iwt2.org/ndt.php2Open Source Library for OCL - http://oslo-project.berlios.de3Matlab - http://www.mathworks.com


preservando la semantica de los modelos. Ası mismo, presentan un caso deestudio, utilizando la herramienta AndroMDA4.

5.2. Calidad externa

La calidad externa hace referencia al comportamiento observable del produc-to software. A continuacion, se describen las actividades clasicas respecto ala gestion de la calidad externa del software.

5.2.1. Pruebas de software

Las pruebas de software o testing son de las actividades mas conocidas enla Ingenierıa del Software. Existen diferentes niveles de prueba: unitarias,integracion, sistema, etc., ası como distintas estrategias: caja negra, cajablanca, etc.

Uno de los principales inconvenientes del testing, es el alto coste querequiere la definicion de casos de prueba. Por ello, MDE puede ayudar enla definicion de los mismos, mediante la transformacion desde modelos deingenierıa (por ejemplo, modelos de requisitos) a casos de prueba ejecutables.

En el trabajo descrito en [41], los autores un framework que permitedesarrollar casos de prueba para testear los procesos de transformacion en-tre modelos. El framework se integra en un motor de transformacion, elcual permite ejecutar los casos y presentar los resultados para su posteriorvalidacion.

En [62] se propone un metodo para la generacion automaticas de pruebasen lıneas de productos software (Software Product Lines (SPL)), medianteuna transformacion desde diagramas de secuencia UML, a modelos de prue-bas basadas en el perfil de testing en UML5.

5.2.2. Simulacion de software

La simulacion en la Ingenierıa del Software es una de las practicas que ma-yor interes academico ha levantado, aunque en la industria no ha llegado atener mucho exito. La simulacion puede ayudarnos en el analisis del com-portamiento futuro de los sistemas software, entre otras aplicaciones.

Uno de los principales problemas que tiene la simulacion recae en laelaboracion de los propios modelos de simulacion. De este modo, MDE puedeayudar a superar esta limitacion, mediante la transformacion automatica demodelos de ingenierıa en modelos de simulacion.

En el trabajo descrito en [51], se describe un caso de estudio de un expe-rimento relativo a MDA, con el objetivo de generar modelos de simulaciona partir de modelos de diseno (situaciones tacticas y trazas de simulacion).

4AndroMDA - http://www.andromda.org5UML Testing Profile - http://utp.omg.org


5.3. Calidad en uso

La calidad externa hace referencia al comportamiento observable del pro-ducto software, durante la utilizacion efectiva por parte del usuario en elentorno real de explotacion.

5.3.1. Calidad de servicio

Las actividades relacionadas con la calidad del servicio (Quality of Service(QoS)) tienen por objetivo asegurar el correcto funcionamiento y las presta-ciones de los sistemas software. Estos mecanismos, a diferencia del testing,realizan las pruebas directamente sobre entornos reales de produccion. Laautomatizacion de la puesta en marcha y la ejecucion de este tipo de meca-nismos de control, pueden ser agilizadas utilizando tecnicas MDE.

En [53] se describe un escenario de uso de un lenguaje especıfico de domi-nio. El lenguaje permite describir acuerdos de nivel de servicio a diferentesniveles de abstraccion (experto en el dominio y experto en la tecnologıa).Gracias a este DSL, se pueden especificar mediciones de QoS sobre serviciosweb, reglas de validacion y acciones a disparar en caso de incumplimiento.Finalmente, una posterior transformacion generara codigo ejecutable paraApache CXF6.

En [74], se presenta un proceso de desarrollo para aplicaciones distribui-das, en el cual, se modelan aspectos de QoS en los modelos PIM. Los autoresmuestran un caso de aplicacion de este enfoque, por el cual se mapean estosaspectos sobre una plataforma de middleware en .NET

6Apache CXF - http://cxf.apache.org

Parte IV

Calidad en el Proceso

Software con MDE

25

26

En este bloque, se describen los lenguajes y herramientas de soporte masdestacados para el modelado de procesos software y un compendio de estu-dios cientıficos relativos al uso de estos modelos, desde la vision de la gestionde procesos de negocio (BPM).

Capıtulo 6

Modelado de Procesos

Software

En anteriores capıtulos, se argumento la importancia de implantar iniciativaspara la definicion y mejora del proceso software y la necesidad de disponerun conjunto de activos de proceso reutilizables, en pro de la mejora continuade las organizaciones.

La definicion de las descripciones de procesos se enmarca dentro del areade proceso Organizational Process Definition (OPD) de CMMI [26] y deProcess Improvement Process Group (PIM) de ISO/IEC 12207 [31].

En este capıtulo, vamos a estudiar los lenguajes mas significativos para elmodelo de procesos software, ası como herramientas de apoyo al modelado.

6.1. Lenguajes de modelado

Los lenguajes de modelado (Process Modeling Language (PML)) permitenconstruir de forma homogenea descripciones de procesos, utilizando habi-tualmente una notacion grafica. Estos lenguajes ayudan a mejorar la correc-ta comprension de los procesos por parte de todos aquellos implicados en eltranscurso de los proyectos.

En [56] se recogen los lenguajes mas populares para representar procesos:

Diagramas de actividad de UML

Business Process Modeling Notation (BPMN)

XML Process Definition Language (XPDL)

JBPM Process Definition Language (JPDL)

Architecture of Integrated Information Systems (ARIS)

Integration DEFinition (IDEF)

27

Capıtulo 6. Modelado de Procesos Software 28

Ademas de los lenguajes anteriores, se han desarrollado lenguajes espe-cıficos para el modelado de procesos software, los cuales comparten ciertascaracterısticas comunes:

Actividades a llevar a cabo, como la definicion de requisitos.

Recursos, como la ayuda de una herramienta de gestion documental.

Productos de trabajo, como un catalogo de requisitos.

Actores responsables de las actividades, como un analista.

Reglas implıcitas al proceso, como que los requisitos deben estar acep-tados por el responsable del cliente antes de comenzar su desarrollo.

A continuacion, describimos los lenguajes mas significativos:

6.1.1. SPEM

La OMG lanzo hace unos anos el metamodelo para modelos de procesos deingenierıa del software y de ingenierıa de sistemas (Software and SystemsProcess Engineering Metamodel Specification (SPEM)), el cual se describe[54] mediante un metamodelo MOF y un perfil UML. Ası, a modo de ilus-tracion, podemos afirmar que SPEM es a los procesos software lo mismo queUML es a los sistemas software.

El metamodelo SPEM persigue los siguientes objetivos:

Proporcionar una representacion estandar para los procesos y conte-nidos de metodos.

Dar soporte al desarrollo sistematico y a la gestion de procesos dedesarrollo.

Permitir la adaptacion de los procesos a las necesidades especıficasde los proyectos (process tailoring), mediante extensiones, omisiones ypuntos de variabilidad.

Dar soporte a la ejecucion automatica de procesos (process enactment).

El metamodelo de la version 2 de SPEM esta compuesto por 7 paquetes,como podemos apreciar en la figura 6.1. Los describimos a continuacion:

Core: Se trata del paquete central del metamodelo, el cual contiene el con-junto de constructores y clases abstractas necesarias para el resto depaquetes.


Process Structure: Dispone de los constructores necesarios para definir laestructura de desglose de trabajo estatica a traves de la secuenciacionde actividades. En otras palabras, este paquete permite definir modelosde procesos.

Process Behavior: Permite extender los modelos de procesos con meca-nismos de comportamiento externos, como por ejemplo, los diagramasde actividad de UML.

Managed Content: Este paquete permite incorporar documentos y des-cripciones en lenguaje natural, en aquellas situaciones donde no esposible expresar ciertos conceptos mediante modelos estructurados.Las guıas pueden ser plantillas, listas de comprobacion, documentosde buenas practicas, etc.

Method Content: En este paquete se incluyen los constructores necesariospara dar contenido a las metodologıas. Estos elementos (indicados en-tre parentesis), permiten definir el siguiente concepto: algun miembrodel equipo de proyecto (Role Definition) hace algo (Task Definition),utilizando unas entradas (Work Product Definition) para obtener unassalidas (Work Product Definition).

Process with Methods: Los elementos de este paquete permiten integrarlos modelos de procesos (definidos a partir de Process Structure) conel contenido de metodos (definidos a partir de Method Content).

Method Plugin Gracias a este paquete, es posible gestionar repositoriosde contenidos de metodos y modelos de procesos, para dar soporte ala reutilizacion y adaptacion a diferentes entornos.

En la figura 6.2 se representan los elementos principales del metamodelo(con su icono representativo de la version perfil UML), agrupados seguncorrespondan a contenido de metodos (roles, tareas, productos de trabajo,etc.) o estructura de procesos (roles en uso, tareas en uso, actividades, etc).Las guıas (Guidance) aparecen en la interseccion de los conjuntos, debido aque sirven de apoyo a elementos especıficos de metodos dentro de procesosespecıficos.

6.1.2. SEMDM

En el estandar ISO/IEC 24744, se define una alternativa para el modeladode procesos de desarrollo software. Se trata de Software Engineering Meta-model for Development Methodologies (SEMDM), un metamodelo basadoen una arquitectura de 3 capas (Endeavour Domain, Methodology Domainy Metamodel Domain), en lugar de la conocida arquitectura de 4 capas de la


Figura 6.1: Paquetes del metamodelo de SPEM 2.0


Figura 6.2: Elementos principales del metamodelo SPEM 2.0

OMG. Este estandar internacional [30] hace uso de un nuevo enfoque paradefinir metodologıas, basandose en el concepto de powertypes y clabjects.

En la figura 6.3 se muestran las clases principales del metamodelo SEMDM.En este estandar se pueden contemplar tres tipos de clases principales:

Process Classes: Aquellos elementos que representan unidades de trabajo,tales como fases, procesos y tareas.

Producer Classes: Se corresponden con las personas (perfiles) que parti-cipan en el metodo y las responsabilidades que ellos poseen.

Product Classes: Aquellos elementos que se generan como resultado deltrabajo de un componente de proceso.

6.1.3. MSF

Microsoft Solution Framework (MSF) es el marco de trabajo que proponeMicrosoft1 para definir procesos software. El metamodelo de MSF se com-pone de una serie de principios fundamentales, un modelo de equipo, fasese iteraciones. De esta forma, MSF soporta multiples enfoques de procesos,los cuales pueden adaptarse a cualquier proyecto, con independencia de sucomplejidad o tamano.

En la figura 6.4, podemos observar una representacion abstracta del me-tamodelo MSF, extraıda desde [69].

1Microsoft - http://www.microsoft.com


Figura 6.3: Elementos principales del metamodelo SEMDM

Figura 6.4: Elementos principales del metamodelo MSF 4.0


Figura 6.5: Elementos principales del metamodelo OPF

6.1.4. OPF

Open Process Framework (OPF) es una propuesta libre (dominio publico)basada en la industria, para la produccion sistematica de metodologıas dedesarrollo [24].

OPF se compone de un metamodelo de procesos, un conjunto de me-todos reutilizables, y un conjunto de directrices para la creacion de nuevasmetodologıas compatibles con OPF y extender o adaptar metodologıas yaexistentes. En la figura 6.5, podemos comprobar las clases principales delmetamodelo de OPF.

6.1.5. Otras propuestas

Ademas de los lenguajes anteriores, en la literatura cientıfica se proponenotros lenguajes especıficos para la definicion de procesos software, habitual-mente en forma de extensiones o derivados de los metamodelos anteriores.

Ası, podemos citar un metamodelo de artefactos software (extension aUML y SPEM), descrito en [68], el cual permite recoger artefactos softwarea tres niveles: definicion, uso en los procesos y en datos reales.

Por otra parte, en [37] hay una interesante extension a SPEM, deno-minada MODAL, que permite separar la ”intencion” de la ”realizacion” delos procesos y el alineamiento de los productos de trabajo con los modelos,


Figura 6.6: Entorno de modelado SPEM en EPF

resaltando ası, la correlacion existente entre procesos, productos de trabajo,lenguajes y herramientas.

En el siguiente capıtulo iremos citando otras propuestas enmarcadas den-tro del ciclo de vida de los procesos software.

6.2. Herramientas de soporte

Para una correcta definicion de los modelos de procesos, es preciso disponerde herramientas de soporte a los lenguajes de modelado. Podemos destacarlas siguientes herramientas:

6.2.1. EPF Composer

Eclipse Process Framework (EPF) Composer es la herramienta de la co-munidad Eclipse2 para la creacion, edicion y mantenimiento de fragmentosde metodos, procesos o metodologıas de ingenierıa del software. La herra-mienta esta basada en el estandar SPEM 2, aunque en realidad, utiliza unaversion adaptada del metamodelo, denominada Unified Method Architectu-re (UMA). En la figura 6.6 podemos visualizar una captura de pantalla dela herramienta.

La herramienta permite transformar definiciones de procesos en una do-cumentacion en formato web navegable (ver figura 6.7), en un XML estandary en plantillas de Microsoft Project3.

2Eclipse Process Framework - http://www.eclipse.org/epf3Microsoft Project - http://www.microsoft.com/project


Figura 6.7: HTML generado desde un modelo SPEM generado con EPF

6.2.2. Objecteering

Objecteering es una herramienta de soporte a MDE de la compania Ob-jecteering Software4, que permite realizar modelos estandares como UML yBPMN, gestionar catalogos de requisitos, chequear la consistencia de mode-los y otras utilidades.

Este entorno dispone de una extension para modelar procesos softwa-re utilizando el estandar SPEM, permitiendo ademas publicar los procesosdisenados en documentos web, documentos Microsoft Word5 y Project. Lafigura 6.8 muestra una captura de pantalla de esta herramienta.

6.2.3. Enterprise Architect

Enterprise Architect, de Sparx Systems6 es una de las herramientas maspotentes para el analisis y diseno de modelos UML. La herramienta permitedefinir modelos SPEM, utilizando su perfil UML. La figura 6.9 muestra unejemplo de uso de este perfil.

Ademas, este software permite gestionar la trazabilidad desde los requi-sitos al despliegue de sistemas, facilita la ingenierıa directa e inversa sobreunos 10 lenguajes de programacion y ofrece multitud de funcionalidadesorientadas a la gestion de proyectos y de su documentacion asociada.

6.2.4. TopCased

Topcased7 es una herramienta destinada a disenar componentes softwarey hardware para sistemas incrustados crıticos. Este aplicacion promueve

4Objecteering - http://www.objecteering.com5Microsoft Word - http://office.microsoft.com/en-en/word6Sparx Systems - http://www.sparxsystems.com7TopCased Project - http://www.topcased.org


Figura 6.8: Entorno de modelado SPEM en Objecteering

Figura 6.9: Entorno de modelado SPEM en Enterprise Architect


Figura 6.10: Entorno de modelado SPEM en TopCased

el uso de la ingenierıa dirigida por modelos y de metodos formales comoherramientas principales para el diseno de sistemas. Dentro del subproyectoTopProcess, se incluye un editor para el lenguaje SPEM (ver figura 6.10).

6.2.5. IRIS Software

La compania Osellus8 dispone de dos herramientas comerciales destinadasa la gestion de procesos software:

IRIS Process Author

Herramienta para la autorıa de procesos software compatibles con SPEM. Laherramienta ofrece la posibilidad de utilizar tecnologıas wiki con el objetivode revisar y refinar los activos de procesos. Ası mismo, permite desplegar losmetodos en un repositorio central, en IRIS Process Live o en plataformas deejecucion Application Lifecycle Management (ALM). La figura 6.11 muestrael entorno de modelado de este software.

IRIS Process Live

IRIS Process Live es un sistema destinado a la ejecucion de proyectos, quepermite la colaboracion entre los miembros del equipo de desarrollo y contro-lar su seguimiento desde Visual Studio ALM (ver epıgrafe 6.2.6). El sistemapermite la creacion asistida de work ıtems de Visual Studio, la instancia-cion de procesos, la ejecucion de proyectos y la recoleccion automatica demetricas.

8Osellus - http://www.osellus.com


Figura 6.11: Entorno de modelado y validacion de procesos en IRIS

6.2.6. Visual Studio ALM

Visual Studio ALM es una solucion formada por varias herramientas desoporte al ciclo de vida del software, desarrollado por Microsoft. Entre estasherramientas, Team Foundation Server9 permite la gestion del codigo fuente,recopilar metricas, generar informes y monitorizar proyectos. En la figura6.12 mostramos el entorno de trabajo de la herramienta.

Este software se basa en un sistema de plantillas de procesos basadas en elmetamodelo MSF. Estas plantillas agrupan un conjunto de work ıtems, con-sultas predefinidas, plantillas de documentos, informes y guıas, entre otroselementos. Podemos visualizar un ejemplo de guıa MSF para desarrollosagiles, en la figura 6.13.

Por ultimo, es preciso comentar, que la herramienta esta orientada a laejecucion y seguimiento de los proyectos, pero no al diseno y conceptua-lizacion de los procesos software. Sin embargo, dentro del paquete VisualStudio Team System Power Tools10 existe un componente denominado Pro-cess Template Editor, el cual permite editar las plantillas de procesos MSF.

9TFS - http://www.microsoft.com/visualstudio/en-us/products/2010-editions/team-foundation-server

10TFS Power Tools - http://msdn.microsoft.com/es-es/vstudio/bb980963.aspx


Figura 6.12: Entorno de trabajo de Visual Studio ALM

Figura 6.13: Guia de proceso MSF para el desarrollo agil


6.2.7. Otras herramientas

Ademas de las anteriores herramientas, existen otras (habitualmente comoprototipos) que dan soporte a los PMLs descritos en la literatura.

Ası por ejemplo, podemos citar a DSL4SPM [35], una herramienta ba-sada en SPEM, caracterizada por permitir el modelado de procesos desdediferentes perspectivas: flujo de actividades, flujos de conocimiento, riesgos,etc. Estas vistas estan acordes a un formalismo ontologico que define lasrelaciones entre roles, actividades y artefactos.

En el siguiente capıtulo iremos comentando otras herramientas en rela-cion al ciclo de vida de los procesos software.

Capıtulo 7

Soporte al ciclo de vida

En este capıtulo se recogen diferentes aplicaciones de MDE para la gestiondel ciclo de vida de los procesos de negocio relativos al software (en adelante,proceso software). De esta forma, se recogen varias propuestas y solucionesreferentes al uso de modelos, como soporte al diseno, analisis, configuracion,ejecucion y evaluacion de procesos software.

7.1. Diseno de procesos

El ciclo de vida de los procesos software comienza con el diseno de los proce-sos, haciendolos explıcitos mediante la utilizacion de lenguajes destinados atal efecto (PMLs). A continuacion, se recogen estudios relativos al modela-do de metodologıas, frameworks de mejora de procesos y otros formalismos,utilizando estos lenguajes.

7.1.1. Metodologıas agiles

En la literatura existen referencias sobre aplicaciones de los PML para definirmetodologıas software agiles. Podemos citar las siguientes:

En [47] se describe una plantilla de procesos MSF orientada a desarrollosagiles, basadas en Scrum1 y XP2.

Por otra parte, existen implementaciones de OpenUp3, Scrum y XP desa-rrolladas con EPF, en [17].

En [45], se presenta PIT-P2M, un metamodelo basado en SPEM para laespecificacion, definicion y ejecucion de de procesos software, y se ejemplificamodelando un proceso XP.

Ası mismo, en [4] se desarrolla un modelo conceptual basado en SPEMpara especificar elementos de Agile SPI (un enfoque agil para la mejora de

1Scrum Alliance - http://www.scrumalliance.org2eXtreme Programming (XP) - http://www.extremeprogramming.org3OpenUP - http://epf.eclipse.org/wikis/openup

41

Capıtulo 7. Soporte al ciclo de vida 42

procesos software en la industria colombiana).

7.1.2. Otras metodologıas

Tambien existen evidencias de modelado de otro tipo de metodologıas, quecitamos a continuacion:

En [42], los autores definen una extension al metamodelo SPEM 2 con elfin de proporcionar un lenguaje especıfico que permita modelar metodologıasbasadas en el enfoque MDA.

En [64] se presenta una guıa de uso de EPF Composer, ası como aspectosrelativos al modelado de Metrica 3, metodologıa4 muy popular en Espana.

En [71] los autores describen un DSL para modelar estrategias de eje-cucion de procesos que permitan derivar planes de proyecto validos, en elcontexto de V-Modell5, la metodologıa de referencia en Alemania.

En [16] se detalla la utilizacion de OPF para describir metodologıas orien-tadas a agentes (Agent-oriented Methodology (AOM)). En [57], [60], [52] y[66] se describen escenarios de aplicacion de SPEM para modelar tambien es-te tipo de metodologıas, aunque en [66] se utilizan ademas unas extensionesdesarrolladas para cubrir ciertas carencias presentes en el metamodelo.

Por otra parte, en el contexto del proyecto MetaMethod, se ha disenadoun metamodelo [40] basado en el SEMDM (aunque sin utilizar los powerty-pes), con el objetivo de modelar metodologıas de desarrollo de software enel seno del proyecto.

7.1.3. Enfoques para la mejora organizacional

Existen varias evidencias del uso de PMLs para representar modelos demejora de procesos software.

En [38] se modela mediante SPEM el estandar de gestion de proyectosPMBOK 6.

En [22] se presenta un informe sintetizando los fragmentos de metodoextraıdos de los procesos ISO 12207, estableciendo la correspondencia entrelos elementos de estos procesos y SPEM 2.0.

Por otra parte, podemos encontrar varias referencias relativas al frame-work CMMI. En [25], se propone un perfil UML especıfico (Process ModelProfile (PMP)) para modelar procesos CMMI y sus relaciones, con la mo-tivacion de asegurar el cumplimiento de los objetivos establecidos por lasareas de proceso del framework.

En [67] se estudia como modelar los componentes de proceso de CMMIutilizando notaciones del metamodelo SPEM y en [33] se describe una exten-sion al metamodelo para definir procesos CMMI en el contexto de desarrollos

4Metrica 3 - http://www.csae.map.es/csi/metrica35V-Modell XT - http://v-modell.iabg.de6Project Management Body of Knowledge (PMBOK) - http://www.pmi.org


distribuidos en entornos geograficamente distantes. Ademas, existe en [48]una plantilla MSF para procesos de desarrollo de software que satisfagan losrequisitos de CMMI.

En [32] se describe un experimento de modelado SPEM de las areas deproceso de CMMI y las disciplinas de RUP7 para definir una base de pro-cesos organizacionales (Organization’s Set of Standard Processes (OSSP)),describiendo algunos problemas relativos a la organizacion de los componen-tes de proceso.

7.1.4. Otros usos

El estandar SPEM, junto con el estandar RAS8, puede dar soporte a lahora de automatizar tareas en los procesos [7], en el contexto de lıneas deproductos software (SPL).

En [11] se utiliza el metamodelo SEMDM para especificar los elementosbasicos de un metodo para la implantacion de sistemas de gestion de cadenasde suministros (Supply Chain Management (SCM)).

SPEM puede ser utilizado como formalismo para representar procesosde gestion de conocimiento [15], en el marco de organizaciones CMMI. En[6], se propone utilizar una solucion basada en patrones para mejorar laeficiencia en el uso de modelos basados en el conocimiento, para la mejorade los procesos software definidos con SPEM.

7.2. Analisis de procesos

Una vez disenados los procesos software mediante algun PML, es necesariollevar a cabo un proceso de analisis, con la finalidad de evaluar las bondadesy deficiencias que presenta el modelo. Existen distintas aproximaciones a lahora de analizar las descripciones de los procesos software, que presentamosen los siguientes subepıgrafes:

7.2.1. Verificacion

El proceso de verificacion de procesos software consiste en evaluar la correc-cion, completitud y consistencia de los modelos de procesos. Ası por ejemplo,es posible utilizar la potencia del lenguaje OCL con este fin. En [25] se ilustraeste tipo de analisis sobre modelos basados en CMMI.

En [8] se describe una extension a SPEM, denominada xSPEM, con elobjetivo de incorporar semantica operacional a los modelos de procesos soft-ware. El estudio detalla el proceso de transformacion entre las propiedadesde modelos xSPEM y propiedades LTL en Redes de Petri, con el fin de

7Rational Unified Process (RUP) - http://www-01.ibm.com/software/awdtools/rup8Reusable Asset Specification (RAS) - http://www.omg.org/spec/RAS


aprovechar, las tecnicas y herramientas formales existentes de analisis demodelos.

Existe otra alternativa para evaluar la correcta definicion de procesossoftware, utilizando la potencia del lenguaje OCL. En [25] se ilustra estetipo de analisis sobre modelos basados en CMMI.

7.2.2. Validacion

La validacion de los procesos software tiene por objetivo asegurar el cumpli-miento de los objetivos y requerimientos planteados en el diseno del proceso.

El objetivo del trabajo en desarrollo y presentado en [55] es contribuira la definicion de un metamodelo de procesos que permita determinar laadherencia de las practicas definidas a nivel organizacional con respecto amodelos de referencia como CMMI, utilizando la semantica SPEM y EPF.

En [43] se presentan los hallazgos relativos a factores que afectan a lausabilidad de descripciones de procesos software basadas en SPEM, UMA yOPF.

En [5] se propone validar modelos de procesos software, mediante la eva-luacion visual de los modelos de procesos, desde tres perspectivas diferentes:enfoque en roles, en tareas, o en productos de trabajo.

7.2.3. Simulacion

Las tecnicas de simulacion permiten a los usuarios comprobar paso a paso, elcomportamiento previsto del proceso software, y ası poder detectar posiblesaspectos deficientes en su desarrollo.

En [49], los autores proponen desarrollar modelos para la simulacionde procesos software (Software Process Simulation Model (SPSM)) desdemodelos SPEM. En el estudio, se describe la informacion cuantitativa quese necesita anadir al modelo SPEM, para su posterior transformacion enmodelos formales DEVS-Hybrid.

En [25] (ya citado previamente), se describe el proceso de transformacionentre modelos definidos segun el metamodelo desarrollado por los autores ymodelos ejecutables en el entorno de simulacion SimSE 9. De esta forma,los usuarios pueden interactuar con el entorno de simulacion educacional,con el proposito de comprobar las bondades y debilidades de los procesosdisenados.

7.2.4. Metricas

Con la intencion de comprobar el grado de calidad de un proceso software,se pueden realizar actividades de medicion sobre los modelos de procesos.

9SimSE - http://www.ics.uci.edu/ emilyo/SimSE


El analisis de estas mediciones permitira identificar acciones de mejora ocorrectivas.

En [12] y [23] se presenta FMESP, un marco conceptual y tecnologicopara la medicion de procesos software. El framework se basa en una serie deontologıas y metamodelos (de medicion y modelado de software), que juntocon unas herramientas de soporte, van a permitir realizar mediciones sobreaspectos de modelos SPEM.

7.3. Configuracion de procesos

Esta fase contempla la seleccion del sistema de gestion de procesos, la con-figuracion del mismo segun las caracterısticas de la organizacion y de losprocesos que se desplegaran en el, y por ultimo, las pruebas de integracion(a nivel de interfaz de usuario, de proceso y de datos) y rendimiento. Ade-mas, consideramos en esta fase la adaptacion o particularizacion (tailoring)de los procesos a las necesidades concretas de proyectos.

7.3.1. Implantacion

En la literatura podemos encontrar diversas propuestas de entornos de eje-cucion de procesos software.

En [42] se describe un entorno integrado para el modelado y ejecucionde procesos software MDA. La herramienta incluye una serie de editoresgraficos y editores de reglas de transformacion para el modelado de procesos,ası como un conjunto de formularios orientados al seguimiento del proyecto.

En [3] se presenta una plataforma software para la integracion de he-rramientas de soporte a MDE (herramientas de modelado, transformacion,verificacion y almacenamiento de modelos) a traves de un flujo orquestadode actividades Service-Oriented Architecture (SOA), mediante BPEL.

En [13] se detalla un marco conceptual y una infraestructura softwareen el contexto de Model Driven Method Engineering (MDME), con el ob-jetivo de construir automaticamente un entorno de soporte a los procesossoftware. Ası, los autores proponen tres fases: (i) Diseno de la metodologıautilizando fragmentos de metodos SPEM almacenados como activos RAS.(ii) Configuracion de la metodologıa, asociandole plugins de Eclipse desdeun repositorio de activos. (iii) Implementacion del metodo, mediante unatransformacion M2T, para obtener un fichero de configuracion de productoEclipse, que permita construir un unico entorno. Este entorno integra edi-tores para los productos de trabajo identificados y vistas de interes para lagestion del proceso.

En [14] se describe PRiME system, una herramienta experimental cons-truida con Eclipse y basada en el metamodelo SPEM, que soporta el disenoe implementacion de metodologıas, ası como la gestion cuantitativa de pro-yectos.


7.3.2. Adaptacion

Es difıcil encontrar organizaciones dedicadas a las tecnologıas de la informa-cion, que utilicen una misma metodologıa para dar soporte a la ejecucionde todos sus proyectos. Esto es debido a la naturaleza variable del procesosoftware ya que “no existen dos proyectos iguales”.

Ası, esta tomando gran importancia la idea de crear componentes o frag-mentos de metodo, en lugar de metodologıas completas, para luego adap-tarlas a las situaciones especıficas de los distintos proyectos, esta tomandogran valor. Esta enfoque es conocido como Situational Method Engineering(SME).

En [1] se describe una extension al metamodelo SEMDM, denomina-do ADOM-SME, para soportar la creacion de componentes de metodos yadaptarlos en metodologıas situacionales. Contempla productos, unidadesde trabajo, etapas, productores y unidades de modelo.

En [24] se describe el uso de OPF para crear y configurar procesos in-dividuales que satisfagan las caracterısticas y requerimientos de proyectosespecıficos.

Por otra parte, en [73], se propone una tecnica para desarrollar arquitec-turas de lıneas de procesos que incorporen aspectos sobre la variabilidad y locomun de ciertos dominios. La tecnica utiliza algunas extensiones a SPEMpara detallar estos aspectos en los flujos de procesos.

Tambien, en [44] se expone una extension a SPEM que permite soportarla variabilidad implıcita en las lıneas de procesos software, mediante puntosde variacion y variantes.

7.4. Ejecucion de procesos

Una vez finalizada la fase de configuracion, se deben instanciar los procesossoftware (process enactment) con el comienzo de cada nuevo proyecto. Asımismo, los procesos en ejecucion deben monitorizarse con el objetivo deproporcionar informacion sobre el progreso de los mismos y detectar posibleserrores o desviaciones en plazos o en calidad.

7.4.1. Operacion

Con independencia de las caracterısticas del modelo de proceso adoptado,es habitual la realizacion de un plan de proyecto, que refleje las diferentestareas a llevar a cabo por los miembros del equipo de proyecto. El alcance yla rigurosidad de las planificaciones dependeran por tanto, de la metodologıaempleada.

El uso de lenguajes y sistemas basados en workflows son los mecanismosmas habituales para la secuenciacion de tareas y la asignacion de responsa-bilidades a personas especıficas.


En [18] se presenta eSPEM, una extension de SPEM que permite mo-delar con gran detalle el comportamiento de los procesos, el ciclo de vidade los productos de trabajo y estrategias para la programacion de tareas,permitiendo la posterior instanciacion de procesos, pero sin proponer ninguntipo de transformacion desde el modelo eSPEM.

En el informe [38] se describe el procedimiento de transformacion demodelos SPEM en plantillas de MS Project.

En el trabajo descrito en [39] se presenta un asistente visual para EPF,que permite instanciar metodologıas para proyectos especıficos, publican-dose un portal web de referencia para los miembros del equipo. Para ello,utilizan una extension del metamodelo SPEM para permitir la asigancionde responsabilidades y herramientas de soporte.

En [58] han formalizado la transformacion de actividades SPEM en unavista de procesos BPMN. Para ello utilizan el lenguaje de especificacionformal RAISE10, con el cual especifican la vista de SPEM, de BPMN y lasrelaciones entre los conceptos de ambas vistas.

En [76] y [77] se sientan los principios para automatizar la gestion de losprocesos de desarrollo de software especificados con SPEM. En el primero, sepropone realizar una transformacion desde SPEM a XPDL y en el segundoa BPMN, ambos utilizando el lenguaje QVT Relations.

En [2] se describe dos alternativas para la ejecucion de procesos modela-dos con SPEM, realizando un mapeo entre conceptos de SPEM a conceptosen BPEL y a conceptos XPDL, respectivamente. Con este fin, los autoreshan generado una extension al metamodelo SPEM, para cubrir las carenciascon respecto a la instanciacion de procesos.

En [21] se describe el conjunto de reglas de mapeo necesarias para trans-formar modelos en SPEM a modelos en formato XPDL y el algoritmo detransformacion, para su posterior instanciacion sobre motores de workflowcomo Shark11.

La plataforma presentada en [3] utiliza modelos BPEL generados desdemodelos SPEM para la orquestacion de actividades. En [65] se plantea in-troducir un paso de transformacion intermedio entre SPEM y BPEL. Losautores proponen la generacion de un plan de proyecto desde el modeloSPEM, el cual posteriormente se enlaza con informacion de los recursos hu-manos asignados al proyecto, para finalmente generar un BPEL ejecutablesin intervencion humana.

Por ultimo, en el ya citado [8] proponen transformar procesos desa-rrollados con la extension XSPEM, en modelos basados en la propuestaBPEL4PEOPLE12, aunque requiera un refinamiento posterior del codigo

10Rigorous Approach to Industrial Software Engineering (RAISE) -http://www.iist.unu.edu/raise

11Enhydra Shark - http://shark.enhydra.org12WS-BPEL Extension for People - http://www.ibm.com/developerworks/webservices/

library/specification/ws-bpel4people


con vistas de ser ejecutado.

7.4.2. Monitorizacion

En [59] se aborda el modelado de restricciones sobre la definicion de activi-dades, roles, tareas y productos de trabajo en el metamodelo SPEM. Paraello, proponen realizar una transformacion entre modelos SPEM en onto-logıas OWL13, las cuales ofrecen soporte al razonamiento y a la inferencia.Las ontologıas resultantes pueden ser enriquecidas con reglas SWLR14 conel objetivo de detectar inconsistencias entre las definiciones de los procesosy los procesos ejecutados.

7.5. Evaluacion de procesos

La evaluacion de procesos tiene por objetivo comprobar la calidad de los pro-cesos desplegados y la adecuacion a su ambito de ejecucion, monitorizandola ejecucion de las diferentes actividades y utilizando tecnicas de minerıa dedatos.

En [61] se describe SPAGO4Q, un software que permite evaluar la correc-ta ejecucion de los proyectos, mediante la obtencion y analisis de metricasrecopiladas (utilizando tecnicas no intrusivas) de distintas fuentes de da-tos. La herramienta utiliza un metamodelo de procesos software (basado enSPEM), un metamodelo de medicion, un metamodelo de evaluacion y unmetamodelo de definicion de extractores de datos.

13Web Ontology Language (OWL) - http://www.w3.org/TR/owl-features14Semantic Web Rule Language (SWLR) - http://www.w3.org/Submission/SWRL

Parte V

Epılogo

49

50

En esta ultima parte, se presenta el analisis de los resultados del estudio,las conclusiones y posibles lıneas de trabajo futuras derivadas de la presenteinvestigacion.

Capıtulo 8

Analisis de los resultados

En este capıtulo, se presenta un analisis de las principales propuestas refe-rentes a la utilizacion de modelos para la gestion de la calidad en el software,desde las perspectivas de producto y proceso.

8.1. Producto software

El estudio de alcance realizado se ha limitado a un numero de estudiossuficiente que cubra al menos, todas las actividades clasicas de gestion de lacalidad del producto. De este modo, se analizo un total de 12 trabajos, delos que podemos extraer las siguientes conclusiones:

8.1.1. Calidad interna

MDE se presenta como una gran oportunidad para la mejora de la efecti-vidad y la ejecucion de las revisiones sobre los productos de trabajo. Lastecnicas de model checking y reconocimiento de patrones pueden ser de uti-lidad para la verificacion de modelos con respecto a los metamodelos. Adi-cionalmente, la incorporacion de reglas OCL, permiten verificar restriccionesmetodologicas o directrices organizacionales en nuestros disenos. Falta porevaluar la aplicabilidad de MDE para la medicion y analisis en entornos dedesarrollo reales.

8.1.2. Calidad externa

El testing es uno de los aspectos donde las tecnicas y tecnologıas MDEpueden proporcionar gran soporte, ya que estan surgiendo iniciativas parala generacion y ejecucion automatica de casos de prueba. La simulacion esotra de las actividades donde MDE puede proporcionar mucho valor, quepermita marcar un punto de inflexion hacia un uso mas generalizado de lasimulacion en la industria.

51

Capıtulo 8. Analisis de los resultados 52

8.1.3. Calidad en uso

Con respecto a la calidad en uso, destacar que la aplicacion de MDE para laconstruccion de mecanismos para el control de la calidad de servicio, quedasujeto al desarrollo de este tipo de tecnicas, que actualmente no estan muymaduras.

8.2. Proceso software

Con independencia de los frameworks o las iniciativas implantadas parala mejora de procesos software, una correcta gestion del ciclo de vida delos procesos organizacionales redundara en la mayor calidad del softwaredesarrollado.

Se han analizado los principales lenguajes de modelado existentes, descri-biendo sus caracterısticas principales, ası como las herramientas comercialesy no comerciales mas conocidas para el modelado de procesos software.

Todas estas herramientas utilizan el metamodelo SPEM, como formalis-mo para el diseno de los modelos, a excepcion de Visual Studio ALM queutiliza MSF. Ademas, tanto EPF como Objecteering permiten transformarlos modelos en plantillas MS Project.

Mencion especial requieren los entornos comerciales Visual Studio ALMe IRIS Process, los cuales ofrecen soporte para el diseno, configuracion, eje-cucion y monitorizacion de los procesos software.

Con respecto a la literatura cientıfica, se localizo un total de 64 publi-caciones posteriores a 2004, entre propuestas, metodologıas y experienciasrelativas a la utilizacion de modelos durante las actividades enmarcadasdentro del ciclo de vida de los procesos software. De entre todas estas publi-caciones, se descartaron 13, en la mayorıa de las ocasiones por no aportarmayor conocimiento.

En la figura 8.1 podemos comprobar el volumen de contribuciones cien-tıficas de interes, distribuidas segun la fase del ciclo de vida a la que dansoporte y el lenguaje de modelado utilizado. Tras el estudio de estos trabajos,podemos extraer las siguientes conclusiones:

8.2.1. Diseno de procesos

El lenguaje mas utilizado por los autores para el diseno de los modelos deproceso es SPEM, como podemos observar en la figura 8.2. Sin embargo, sehan planteado numerosas extensiones y lenguajes derivados del mismo, conel objetivo de cubrir carencias concretas que presenta el lenguaje, funda-mentalmente en lo referente a la ejecucion de los procesos (enactment). Pordiferentes motivos, el resto de lenguajes no esta teniendo tanto exito: OPF,SEMDM, y MSF.


Figura 8.1: Volumen de contribuciones segun la fase del ciclo de vida

Figura 8.2: Utilizacion de lenguajes de modelado de procesos software


Ası mismo, hemos observado distintas aplicaciones de los PMLs parael modelado de metodologıas (agiles, orientadas a agentes, etc.), marcos demejora de procesos (como CMMI) y otros enfoques.

8.2.2. Analisis de procesos

Al utilizar modelos como base para la definicion de procesos software, se per-mite la (re-)utilizacion de las tecnicas habituales para el analisis de modelos.En la investigacion, hemos encontrado estudios relativos a:

Verificacion: transformacion en Redes de Petri y definicion de reglas enOCL.

Validacion: usabilidad de modelos, analisis visual desde distintas perspec-tivas y la adecuacion con respecto a marcos de referencia.

Simulacion: transformacion de modelos conceptuales en modelos interpre-tables en entornos de simulacion.

Metricas: obtencion de medidas e indicadores de calidad desde modelos deproceso.

8.2.3. Configuracion de procesos

Considerar los procesos software como un tipo particular de proceso de ne-gocio, permite utilizar los beneficios que aportan los sistemas de gestion deprocesos existentes, habitualmente disenados segun una arquitectura basadaen servicios (SOA).

En el estudio realizado, hemos podido descubrir algunas propuestas aca-demicas destinadas a la creacion de un unico entorno software (basado enEclipse) que permita disenar procesos, desarrollar modelos y gestionar lasinstancias de los procesos, entre otras funcionalidades.

8.2.4. Ejecucion de procesos

En el contexto de la ejecucion de proyectos, hemos citado diferentes tra-bajos, entre los cuales destacan las transformaciones desde modelos SPEM(o de sus extensiones) a modelos de workflows como BPEL o XPDL. Estastransformaciones tienen por objetivo la orquestacion automatica de serviciosen plataformas de integracion de procesos.

Tambien se recogen trabajos relativos a transformaciones desde modelosde procesos a documentos web y plantillas MS Project.

Con respecto a la monitorizacion de procesos software, se ha estudiado lautilizacion de reglas definidas sobre ontologıas, las cuales permiten encontrarinconsistencias entre la definicion de los procesos y los procesos finalmenteejecutados.


8.2.5. Evaluacion de procesos

Para la evaluacion de los procesos de negocio, se utilizan herramientas parala monitorizacion en tiempo real y/o analisis post-mortem, las cuales suelenestar integradas en los sistemas BPM. Desde el punto de vista de los pro-cesos software, se describe un entorno que permite extraer y analizar datosprocedentes de diferentes herramientas de soporte al proceso.

Capıtulo 9

Conclusiones

La mejora de la calidad en el software es uno de los aspectos mas impor-tantes y demandados por los usuarios finales y en consecuencia por todoslos implicados en el exito de los proyectos de desarrollo o mantenimientosoftware.

El concepto de gestion de la calidad no solo significa mejora. La gestionde calidad tambien abarca otras tareas relativas a la planificacion de lasactividades, aseguramiento y control.

La calidad en el software puede contemplarse desde dos niveles diferen-tes, pero complementarios: calidad en el producto y calidad en el proceso.La calidad del producto depende en gran medida de la calidad de los proce-sos que se utilizan, por lo que para potenciar la calidad en el software, losesfuerzos deben concentrarse en ambos niveles.

Por otra parte, el uso del paradigma MDE promueve el desarrollo demodelos, como elemento fundamental en las distintas disciplinas de la Inge-nierıa del Software. Este paradigma abarca entre otros elementos: tecnicas ymetodos, lenguajes de modelado, lenguajes de transformacion entre modelos,herramientas de soporte, etc.

Al comienzo de esta investigacion, se definio la siguiente hipotesis deinvestigacion: Es posible usar MDE como mecanismo para dar soporte a lasactividades de gestion de la calidad.

El objetivo del presente trabajo de investigacion ha sido estudiar el so-porte que ofrece actualmente la ingenierıa dirigida por modelos a las activi-dades de gestion de calidad en el software, tanto a nivel de producto comode proceso.

En la investigacion relativa a la calidad del producto hemos encontradoevidencias del uso de MDE en propuestas relativas a la medicion, revisionestecnicas, mejora, pruebas, simulacion y calidad de servicio. Por ello, pode-mos afirmar que MDE es un enfoque valido y util para dar soporte a lasactividades clasicas de gestion de la calidad de los productos software.

Con respecto a la calidad desde el punto de vista de los procesos software,

56

Capıtulo 9. Conclusiones 57

en lugar de estudiar el soporte de MDE respecto de algun marco especıficopara la mejora de procesos (CMMI o SPICE), hemos optado por estudiar elsoporte desde la optica de la gestion de los procesos de negocio.

En la revision de la literatura, hemos descubierto un buen numero detrabajos que basandose en lenguajes de procesos software (PMLs), comoSPEM, modelan metodologıas o marcos de referencia para la mejora deprocesos.

Ademas, hemos descrito y clasificado distintas propuestas enfocadas a lavalidacion, configuracion, ejecucion y evaluacion de procesos software. Asıpues, podemos afirmar que MDE es un enfoque adecuado para dar soporte ala mejora de los procesos software, desde la perspectiva de la gestion de losprocesos de negocio.

Por tanto, en vista de las evidencias encontradas y la relevancia y apli-cacion de las propuestas citadas en este trabajo, podemos dar por satisfechanuestra hipotesis de trabajo y recalcar el papel cada vez mas significativoque tiene el desarrollo sistematico de modelos de cara a la gestion de la ca-lidad en el producto y el proceso software.

Capıtulo 10

Lıneas de investigacion

futuras

Una vez revisada la literatura y analizado el soporte actual que ofrece laingenierıa dirigida por modelos a la gestion de la calidad en el software, esimportante identificar posibles lıneas de actuacion con el objetivo de ampliarel conocimiento en el campo y aportar nuevas propuestas de mejora.

A continuacion, describimos posibles vıas de ampliacion de este trabajo:

Estudiar el soporte ofrecido por los modelos de proceso software a losobjetivos especıficos recogidos en las areas de proceso de CMMI, paracada uno de sus niveles de madurez.

Estudiar el soporte que los modelos de proceso software pueden ofreceral seguimiento del estandar SPICE para los procesos de ciclo de vida.

Estudiar el soporte potencial de los modelos de proceso sobre elemen-tos comunes de SPICE y CMMI, a partir de alguno de los trabajosexistentes en relacion a la armonizacion entre ambos modelos.

El empleo de un enfoque basado en la separacion de conceptos permi-tirıa modelar aspectos no funcionales del proceso software y que no estenestrechamente relacionados con la secuenciacion y ejecucion de las activida-des definidas para el proceso. Ası por ejemplo, serıa interesante el modelaraspectos de aprendizaje humano en los procesos software.

Con respecto al analisis de los procesos software, podemos contemplarlas siguientes oportunidades de investigacion:

Estudiar las posibilidades del enfoque Architecture-Driven Moderni-zation (ADM) de la OMG con respecto a los procesos software. Porejemplo, mediante la aplicacion del metamodelo SMM1 para la recopi-lacion de metricas sobre modelos SPEM.

1Software Metrics Metamodel (SMM) - http://www.omg.org/spec/SMM

58

Capıtulo 10. Lıneas de investigacion futuras 59

Exploracion de nuevos mecanismos para la simulacion de procesos des-de modelos de procesos definidos con SPEM.

De cara a la configuracion de los procesos, podemos tener en cuenta lassiguientes coyunturas:

Profundizacion en el modelado de lıneas de procesos software. Porejemplo, modelando aspectos como la novedad tecnologica del pro-yecto, criticidad del sistema a desarrollar, numero de participantes enel proyecto, etc. La valoracion de estos aspectos, permitirıan derivaruna metodologıa adaptada para los proyectos.

Aplicacion de tecnicas conocidas de testing de software sobre modelosde procesos software desplegados.

En el ambito de la ejecucion de procesos, serıa importante investigarsobre:

Mecanismos para la automatizacion de revisiones de calidad sobre pro-yectos en ejecucion, a partir del diseno explicito de modelos de pro-cesos. Por ejemplo, explotando el elemento Checklist del metamodeloSPEM.

Diferencias y particularidades entre el mantenimiento (correcto, evo-lutivo o perfectivo) de los sistemas de los informacion y de los procesossoftware desplegados.

Dado que la ejecucion de procesos software es todavıa un area inmadu-ra, se plantea la posibilidad de evaluar procesos que no esten definidos demanera formal. Por ello, se pretende analizar datos procedentes de reposito-rios publicos (forjas) de software libre para descubrir patrones de procesos yanalizar, por ejemplo, el impacto de ciertas mejoras tecnologicas y/o prac-ticas de ingenierıa, sobre la calidad del software y la monitorizacion de losproyectos.

En resumen, el diseno explıcito de modelos de procesos y su transforma-cion en otros tipos de modelos utiles para la gestion de los procesos software,es una lınea de investigacion todavıa por desarrollar.

Referencias

[1] Aharoni, A., Reinhartz-Berger, I.: A Domain Engineering Approach forSituational Method Engineering. Conceptual Modeling-ER 2008 pp.455–468 (2008)

[2] Aitor Bediaga, Jason Mansell, X.L.: Workpackage 2: Framework buil-ding Deliverables D2.6.a: Specifications of the SPEM 2.0 extensions forMODELPLEX (2007)

[3] Aldazabal, A., Baily, T., Nanclares, F., Sadovykh, A., Hein, C., Ritter,T.: Automated Model Driven Development Processes. In: Proceedingsof the ECMDA workshop on Model Driven Tool and Process Integra-tion. Fraunhofer IRB Verlag, Stuttgart (2008)

[4] Alegrıa, J., Bastarrica, M.: Implementing CMMI using a Combinationof Agile Methods. CLEI Electronic Journal 9(1), 1–15 (2006)

[5] Alegrıa, J., Lagos, A., Bergel, A., Bastarrica, M.: Software Process Mo-del Blueprints. New Modeling Concepts for Today’s Software Processespp. 273–284 (2010)

[6] Amescua, A., Garcıa, J., Medina-domınguez, F.: A Pattern-Based Solu-tion to Bridge the Gap Between Theory and Practice in Using ProcessModels. Language pp. 97 – 104 (2006)

[7] Avila-Garcıa, O., Garcıa, A., Rebull, E., Garcıa, J.: Combinando Mode-los de Procesos y Activos Reutilizables en una Transicion poco Invasivahacia las Lıneas de Producto de Software. sistedes.es (2007)

[8] Bendraou, R., Combemale, B., Cregut, X., Gervais, M.P.: Definitionof an Executable SPEM 2.0. 14th Asia-Pacific Software EngineeringConference (APSEC’07) pp. 390–397 (2007). DOI 10.1109/ASPEC.2007.60

[9] Berndtsson, M., Hansson, J., Olsson, B., Lundell, B.: Thesis projects:a guide for students in computer science and information systems.Springer-Verlag New York Inc (2008)

60

Referencias 61

[10] Cachero, C., Calero, C., Poels, G.: Metamodeling the quality of theweb development process’ intermediate artifacts. Web Engineering pp.74–89 (2007)

[11] Caldelas, A., Pastor, J., Mayol, E.: Formalizacion de Servicios de Im-plantacion de Sistemas SCM mediante el Estandar SEMDM. Actas delos Talleres de las Jornadas 3(3), 22–31 (2009)

[12] Canfora, G., Garcıa, F., Piattini, M., Ruiz, F., Visaggio, C.: Applying aframework for the improvement of software process maturity. Software:Practice and Experience 36(3), 283–304 (2006). DOI 10.1002/spe.697

[13] Cervera, M., Albert, M., Torres, V., Pelechano, V., Cano, J.: A Tech-nological Framework to support Model Driven Method Engineering 1.Taller DSDM de JISBD 2010 (2007)

[14] Choi, Y., Ha, S.j.: Eclipse-based management system for process in-novation & methodology enhancement. 2006 8th International Con-ference Advanced Communication Technology pp. 5 pp.–159 (2006).DOI 10.1109/ICACT.2006.205942

[15] Chongsringam, P., Prompoon, N.: Process Model Design for KnowledgeManagement in CMMI Organization. In: The 5th International Con-ference on Intellectual Capital: ICICKM 2008, vol. 1, p. 97. AcademicConferences Limited (2008)

[16] Debenham, J., Henderson-Sellers, B.: Full lifecycle methodologies foragent-oriented systems–the extended OPEN process framework. Agent-Oriented Information Systems pp. 1–15 (2002)

[17] Eclipse Foundation: Eclipse Process Framework. URLhttp://www.eclipse.org/epf/

[18] Ellner, R., Al-Hilank, S., Drexler, J., Jung, M., Kips, D., Philippsen,M.: eSPEM–a SPEM Extension for Enactable Behavior Modeling. Mo-delling Foundations and Applications pp. 116–131 (2010)

[19] Escalona, M., Gutierrez, J., Perez-Perez, M., Molina, A., Martınez-Force, E., Domınguez-Mayo, F.: Measuring the quality of Model-Drivenprojects with NDT-Quality. In: Advances in Engineering Software.Springer Verlag (2010)

[20] Farkas, T.: Quality Improvement in Automotive Software Engineeringusing a Model-Based Approach. Model-Driven Software Development:Integrating Quality Assurance (2008)

[21] Feng, Y., Mingshu, L., Zhigang, W.: SPEM2XPDL: Towards SPEMModel Enactment. In: Proceedings of the International Conference on

http://www.eclipse.org/epf/

Referencias 62

Software Engineering Research and Practice & Conference on Program-ming Languages and Compilers (SERP’06), Las Vegas, USA, pp. 240–245. Citeseer (2006)

[22] Garbajosa, J., Espinoza, A.: Entregable DX.Y2. Repositorio de frag-mentos de metodo y herramientas de explotacion basicas. Informe sobrefragmentos de metodo definidos en la fuente ISO 12207 (2007)

[23] Garcia, F., Ruiz, F., Visaggio, C.: A Proposal and Empirical Valida-tion of Metrics to Evaluate the Maintainability of Software ProcessModels. In: Instrumentation and Measurement Technology Conferen-ce, 2006. IMTC 2006. Proceedings of the IEEE, April, pp. 1093–1097.IEEE (2007). DOI 10.1109/IMTC.2006.328377

[24] Henderson-sellers, B.: Process Metamodelling and Process Construc-tion: Examples Using the OPEN Process Framework (OPF). Annals ofSoftware Engineering pp. 341–362 (2007)

[25] Hsueh, N., Shen, W., Yang, Z., Yang, D.: Applying UML and softwa-re simulation for process definition, verification, and validation. In-formation and Software Technology 50(9-10), 897–911 (2008). DOI10.1016/j.infsof.2007.10.015

[26] Institute, S.E.: CMMI R© for Development, Version 1.2 (2006)

[27] Instituto Nacional de Tecnologıas de la Comunicacion: Guıa de mejorespracticas de calidad de producto. Laboratorio Nacional De Calidad DelSoftware (2008)

[28] International Organization for Standardization: Quality ManagementSystems: Fundamentals and Vocabulary (2000)

[29] International Organization For Standarization: Software and systemengineering–Software product Quality Requirements and Evaluation(SQuaRE)–Guide to SQuaRE (2005)

[30] International Organization For Standarization: Software Engineering —Metamodel for Development Methodologies (2007)

[31] International Organization For Standarization: Systems and softwareengineering – Software life cycle processes (2008)

[32] Jarvi, A., Makila, T.: Observations on Modeling Software Processeswith SPEM Process Components. In: Proc. of 9th Symposium on Pro-gramming Languages and Software Tools, Estonia (2005)

[33] Juan Li, M., Wu, Z., Wang, Q.: A Metamodel for the CMM SoftwareProcess. In: Parallel and distributed processing and applications: second

Referencias 63

international symposium, ISPA 2004, Hong Kong, China, December13-15, 2004; proceedings, vol. 1, p. 446. Springer-Verlag New York Inc(2004)

[34] Juran, J.: Quality in Software Development. McGraw-Hill Professional(1998)

[35] Kerzazi, N., Robillard, P.n.: Multi-Perspective Software Process Mode-ling. IEEE (2010). DOI 10.1109/SERA.2010.52

[36] Koehler, J., Gschwind, T., Kuster, J., Pautasso, C., Ryndina, K., Van-hatalo, J., Volzer, H.: Combining quality assurance and model transfor-mations in business-driven development. Applications of Graph Trans-formations with Industrial Relevance pp. 1–16 (2008)

[37] Koudri, A., Champeau, J.: MODAL: A SPEM Extension to ImproveCo-design Process Models. New Modeling Concepts for Today’s Soft-ware Processes pp. 248–259 (2010)

[38] Ko lcz, K.: Using SPEM/UML profile to specification of IS developmentprocesses. Ph.D. thesis, School of Engineering. Blekinge Institute ofTechnology (2006)

[39] Larrucea, X., Alonso, J.: Vulcano: Entregable D2.1. Especificacion delmetamodelo a utilizar (2007)

[40] Larrucea, X., Bediaga, A., Gortazar, A.: Metamodelo para Metodolo-gıas de Desarrollo. MetaMethod pp. 1–7 (2010)

[41] Lin, Y., Zhang, J., Gray, J.: A testing framework for model transfor-mations. Model-driven Software Development pp. 219–236 (2005)

[42] Maciel, R.S.P., Silva, B.C.D., Magalhaes, A.P.F., Rosa, N.S.: An Inte-grated Approach for Model Driven Process Modeling and Enactment.2009 XXIII Brazilian Symposium on Software Engineering pp. 104–114(2009). DOI 10.1109/SBES.2009.18

[43] Mahrin, M., Carrington, D., Strooper, P.: Investigating factors affec-ting the usability of software process descriptions. In: Proceedings ofthe Software process, 2008 international conference on Making globallydistributed software development a success story, pp. 222–233. Springer-Verlag (2008)

[44] Martınez-Ruiz, T., Garcıa, F., Piattini, M.: Towards a SPEM v2. 0Extension to Define Process Lines Variability Mechanisms. Softwa-re Engineering Research, Management and Applications pp. 115–130(2008)

Referencias 64

[45] Martins, P.V.: PIT-P2M : ProjectIT Process and Project Metamodel.Management (2005)

[46] Mens, T., Taentzer, G., Muller, D.: Model-driven software refactoring.Refactoring Tools (WRT’07) p. 25 (2008)

[47] Microsoft: MSF for Agile Software Development v5.0. URLhttp://msdn.microsoft.com/library/dd380647.aspx

[48] Microsoft: MSF for CMMI Process Improvement v5.0. URLhttp://msdn.microsoft.com/library/dd997574.aspx

[49] Modelling, P.: Developing a software process simulation model usingSPEM and analytical models Seunghun Park*, Hyeonjeong Kim, Dong-won Kang and Doo-Hwan Bae. Simulation 4 (2008)

[50] Mohagheghi, P., Dehlen, V.: Developing a quality framework for model-driven engineering. Models in Software Engineering pp. 275–286 (2008)

[51] Monperrus, M., Jaozafy, F., Marchalot, G., Champeau, J., Hoeltzener,B., Jezequel, J.: Model-driven simulation of a maritime surveillancesystem. In: Model Driven Architecture–Foundations and Applications,pp. 361–368. Springer (2010)

[52] Nardini, E., Molesini, A., Omicini, A., E: SPEM on test: the SODAcase study. Proceedings of the 2008 pp. 700–706 (2008)

[53] Oberortner, E., Zdun, U., Dustdar, S.: Tailoring a model-drivenQuality-of-Service DSL for various stakeholders. In: Proceedings of the2009 ICSE Workshop on Modeling in Software Engineering, pp. 20–25.IEEE Computer Society (2009)

[54] Object Management Group: Software & Systems Process EngineeringMeta-Model Specification (2008)

[55] Pablo Szyrko, D.R.: Definicion de un metamodelo para la validacion deprocesos de software organizacionales basados en modelos estandares.Actas del XII Workshop de Investigadores en Ciencias de la Compu-tacion (2010)

[56] Perez, J.: Notaciones y lenguajes de procesos. Una vision global. (2007)

[57] Puviani, M., Serugendo, G., Frei, R., G: Methodologies for self-organising systems: a SPEM approach. Proceedings of the 2009 pp.66–69 (2009). DOI 10.1109/WI-IAT.2009.128

[58] Riesco, D., Montejano, G., Debnath, N., Cota, M.P.: Formalizing theManagement Automation with Workflow of Software Development Pro-cess Based on the SPEM Activities View. IEEE (2009). DOI10.1109/ITNG.2009.158

http://msdn.microsoft.com/library/dd380647.aspx

http://msdn.microsoft.com/library/dd997574.aspx

Referencias 65

[59] Rodrıguez, D., Sicilia, M.: Defining spem 2 process constraints withsemantic rules using swrl. Proceedings of ONTOSE (2009)

[60] Rougemaille, S., Migeon, F., Millan, T., MP: Methodology FragmentsDefinition in SPEM for Designing Adaptive Methodology: A First Step.Agent-Oriented Software pp. 74–85 (2009)

[61] Ruffatti, G., Oltolina, S., Tura, D., Damiani, E., Bellettini, C., Colom-bo, A., Frati, F.: New Trends Towards Process Modelling: Spago4Q.Trust in Open-Source Software (TOSS), Limerick (2007)

[62] Rui-zhi, D.: Model-Driven Testing of Software Product Line. Journalof Changshu Institute of Technology (2009)

[63] Ruiz, F.: Software Process Engineering: De una gestion de procesosContemplativa a una Productiva. Grupo Alarcos. UCLM (2007)

[64] Ruiz, F., Verdugo, J.: Guıa de Uso de SPEM 2 con EPF Composer.Grupo Alarcos. UCLM (2008)

[65] Sadovykh, A., Abherve, A.: MDE Project Execution Support via SPEMProcess Enactment. Model Driven Tool and Process Integration p. 53(2009)

[66] Seidita, V., Cossentino, M., Gaglio, S.: aa. Agent-Oriented Softwarepp. 1–12 (2009)

[67] Silva, J.: Modelagem das areas de processo do CMMI usando BusinessProcess Management e Software Process Engineering Metamodel Spe-cification. wiki.dcc.ufba.br pp. 1–7 (2005)

[68] Silva, M., Oliveira, T., Bastos, R.: Software Artifact Metamodel. 2009XXIII Brazilian Symposium on Software Engineering pp. 176–186(2009). DOI 10.1109/SBES.2009.28

[69] Stott, W., Newkirk, J.: Visual studio team system: better software de-velopment for agile teams. Addison-Wesley Professional (2007)

[70] Team, C.P.: Process Madurity Profile. CMMI R© For DevelopmentSCAMPI Class A Appraisal Results March 2010. Software Enginee-ring Institute, Carnegie Mellon University (2010)

[71] Wachtel, E., Kuhrmann, M., Kalus, G.: A Domain Specific Languagefor Project Execution Models. Design (2009)

[72] Wahler, M.: A Pattern Approach to Increasing the Maturity Level ofClass Models. Model-Driven Software Development: Integrating Qua-lity Assurance (2008)

Referencias 66

[73] Washizaki, H.: Building Software Process Line Architectures from Bot-tom Up. Computer pp. 415–421 (2006)

[74] Weis, T., Ulbrich, A., Geihs, K., Becker, C.: Quality of service in midd-leware and applications: a model-driven approach. In: Proceedings.Eighth IEEE International Enterprise Distributed Object ComputingConference, 2004. EDOC 2004., Edoc, pp. 160–171. Ieee (2005). DOI10.1109/EDOC.2004.1342513

[75] Weske, M.: Business Process Management: Concepts, Languages, Ar-chitectures. Springer-Verlag New York Inc (2007)

[76] Zorzan, F., Riesco, D.: Transformacion de Transiciones de Procesos deDesarrollo de Software Basados en SPEM a Transiciones de un Work-flow. Citeseer (2006)

[77] Zorzan, F., Riesco, D.: Automatizacion de procesos de desarrollo desoftware definidos con SPEM. Citeseer (2007)

Ingenier´ıa Dirigida por Modelos y Calidad de Software

Documents

Transcript of Ingenier´ıa Dirigida por Modelos y Calidad de Software