Research article

Meta-Modelo de calidad para evaluar herramientas
de desarrollo de software con soporte a MDA

Resumen

Uno de los objetivos principales de la Ingeniería del Software, es construir productos software de Calidad, guiados a través de un proceso de desarrollo. Estos procesos de desarrollo de software deben ser soportados por herramientas de desarrollo que apoyen si no todo el proceso de desarrollo, una etapa o conjunto de etapas de tal manera de ir construyendo la aplicación software de una forma documentada y consistente con respecto a todas las fases que incluya el proceso de desarrollo seleccionado. Hoy en día existe la propuesta de un proceso de desarrollo dirigido por la transformación de modelos o Arquitectura Dirigida por Modelos (MDA), este proceso de desarrollo ha sido divulgado por la Object Management Group (OMG), y en virtud de esta nueva tendencia para desarrollar software, ya existen en el mercado Herramientas de Desarrollo de Software (HDS) que manifiestan ser herramientas MDA, es decir que soportan el enfoque MDA. Es por esta razón, que se origina este trabajo de investigación el cual tiene por objetivo Proponer un Meta-Modelo de Calidad para evaluar herramientas de desarrollo de software con soporte a MDA.

Quality Meta – Model to evaluate software development tools with an MDA support

Abstract

One of the main objectives of software engineering is to build quality software products guided through a development process. These software development processes must be supported by development tools that back up at least all the development process or if not a phase or a series of phases of it. So as to build the software application on a documented and consistent way in relation with all the phases that include the development process chosen. Nowadays, there’s the proposal of a development process guided by the transformation of models or Models Directed Architecture (MDA). This development process has been divulged by the Object Management Group (OMG) and on behalf of this new trend for software development there are Software Developmental Tools (SDT) already in the market that state being MDA tools, meaning this, that they support the MDA approach. This is the reason why this research work is originated, having as an objective the proposal of a Quality Goal – Model to evaluate software development tools with MDA support.

Marco introductorio

Las organizaciones que desarrollan Sistemas de Información (SI) deben tomar en cuenta la productividad y la calidad para decidir sobre cuál es el ambiente de desarrollo más apropiado. Una de las tecnologías que apoyan estos aspectos son las herramientas que soportan el desarrollo de los SI, o como se conoce en el área de sistemas, Computer Aided Software Engineering (CASE), con las cuales ya se han tenido experiencias, tanto en el exterior como en Venezuela, y puede decirse que han incrementado la productividad de los analistas de los SI. (Mendoza, 1999).

Entre los beneficios de las herramientas CASE se encuentra, un aumento de la productividad de los analistas, diseñadores y programadores de SI, y un sistema de mayor calidad, lo cual origina una reducción de costos de mantenimiento y un mejor desempeño del sistema para los usuarios. (Sommerville, 1998) También fomenta un ambiente controlado en vez de promover un ambiente “ad hoc” de desarrollo de SI, lo que permite que los desarrolladores puedan crear y mantener a la vez SI grandes y pequeños. (Topper et. al., 1994).  De igual forma mejora la comunicación analista-usuario e impulsa la integración de las actividades del ciclo de vida. (Kendall y Kendall, 2005).  En un estudio realizado por (Alfonso Rivas et al, 2011) donde compara un grupo de herramientas CASE y selecciona una para desarrollar el modelado de negocio como primera fase del desarrollo de un sistema de información concluyó que desde que se crearon las herramientas (1984) hasta la actualidad, las CASE cuentan con una credibilidad y exactitud que tienen un reconocimiento universal, siendo usadas por cualquier analista ingeniero y/o programador que busca un resultado óptimo y eficaz para cada uno de sus procesos.

Ahora bien, de acuerdo a los planteamientos anteriores, queda establecido que el uso de herramientas CASE es totalmente indispensable durante el desarrollo de un producto software, y esta importancia queda reforzada con la evolución que han sufrido las herramientas CASE luego se divulgarse a través de la OMG, una nueva forma de desarrollar software asistida por la transformación de los modelos.

La OMG en (OMG, 2003), establece que MDA proporciona una solución para los cambios de negocio y de tecnología, permitiendo construir aplicaciones independientes de la plataforma e implementarlas en plataformas como CORBA, J2EE o Servicios Web.  Según la OMG, MDA se trata de un framework de desarrollo de software que define una nueva forma de construir software en la que se usan modelos del sistema a distintos niveles de abstracción para guiar todo el proceso de desarrollo, desde el análisis y diseño hasta el mantenimiento del sistema y su integración con futuros sistemas.

De acuerdo con (Anacleto, 2006), la ventaja principal de MDA radica en una clara y estricta separación de responsabilidades. Por un lado, se modelaran los MIP (Modelo Independiente de la Plataforma), que representan los modelos de nuestro negocio, y por el otro, los MEP (Modelo Específico de la Plataforma) con las preocupaciones tecnológicas. Esto permitirá que ambos modelos evolucionen por separado. De esta manera, si se quisiera, por ejemplo, modificar un aspecto técnico, bastaría con modificar el MEP sin que éstos tuvieran impacto en la lógica de negocios. Esta idea parte de un concepto que, en ingeniería de software, se llama Guías de Diseño. Particularmente, una de esas guías dice que el modelado de la solución debe ser guiado por el negocio. Esta guía se basa en la afirmación de que un cambio en el negocio seguramente producirá uno en el código, pero que los cambios en el código no deberían impactar en el negocio. MDA también permite lidiar con la complejidad del negocio, modelando a éste por separado, y permitiendo su análisis y mejora; disminuir costos, si se cuenta con una herramienta MDA adecuada a nuestras necesidades; y mejorar la calidad de nuestros modelos y procesos, mediante su análisis y la separación de responsabilidades. De igual forma se plantea en (Chakir, Fredj y Nassar, 2012) donde definen MDA como un mecanismo para la creación de aplicaciones basado en la transformación de modelos.

La concepción de una nueva forma de construir software requiere de manera indispensable el uso de herramientas de transformación, que son las mismas herramientas CASE, pero soportando el enfoque MDA.  Si se toma en cuenta que la Ingeniería de software busca la construcción de productos de calidad, se debe garantizar que todo el proceso de desarrollo exhiba características de calidad, por lo que las herramientas CASE que soporten MDA también deben ser productos de calidad.  Entonces pareciera que las herramientas CASE - MDA como producto de software deben ser desarrolladas de una manera impecable, de tal forma que garanticen soportar el desarrollo de un SI, de todo esto surge una gran interrogante que es, ¿las herramientas CASE que soportan MDA son un producto de calidad?, ¿quién mide la calidad de una herramienta CASE - MDA?, ¿los compradores de herramientas CASE - MDA tienen al alcance algún mecanismo para comprobar la calidad de la herramienta CASE adquirida?

En función de poder adoptar productos de calidad Díaz A. en (Díaz, 2000) propone un Modelo de Calidad (MC-CASE) el cual tiene por objetivo evaluar y seleccionar Herramientas CASE.  Este modelo se divide en tres grandes Categorías que son: Internos, Usuario y Externos; luego cada una de estas categorías esta conformada por un grupo de Características, las características se desglosan en Subcaracterísticas y estás a su vez en Subcaracterísticas Atómica;  finalmente cada subcaracterística atómica posee un grupo de métricas las cuales servirán para medir un aspecto específico de la Herramienta CASE. 

Tomando como base que las herramientas CASE han evolucionado a herramientas de desarrollo de software (HDS) donde algunas soportan el enfoque MDA, el modelo de calidad que permite medir su calidad también debe evolucionar.  Esta es la razón por la cual surge este trabajo de investigación, con la intención de adaptar el MC-CASE a las herramientas de desarrollo de hoy en día.  Claro está el objetivo de este trabajo es más ambicioso, en vista de que se quiere proponer un Meta-Modelo de Calidad que incluya el Modelo del Producto, el Modelo del Proceso y el Modelo Humano.

Metodología aplicada

Los pasos que se seguirán para desarrollar este trabajo de investigación se describirán gráficamente a través de un diagrama de Actividad de UML, tal como lo muestra la figura Nº 1,  la cual permite mostrar de manera dinámica las actividades que deben ejecutarse para completar el objetivo central del trabajo de investigación.

Figura Nº 1. Aspectos metodológicos para desarrollar el Trabajo de Investigación Fuente: Elaboración propia

• Investigación Documental y Bibliográfica: a través de la revisión bibliográfica y electrónica sobre las herramientas CASE, la Arquitectura Dirigida por Modelos y el Modelo de Calidad para seleccionar herramientas CASE, se conformó el marco teórico referencial del presente Trabajo de Investigación.
• Caracterizar a MDA: tomando como base la información documental, se procede a buscar todas las formas que hasta ahora existen de caracterizar a una herramienta que soporte MDA entre las cuales están (Bollati, et al, 2008), (Cervantes y Riba, 2007), (García y Rodríguez, 2004) y (Herrera, Matteo y Díaz, 2007), con el objetivo de establecer un marco referencial para analizar el Modelo de Calidad para Evaluar Herramientas CASE MC-CASE.
• Análisis Semántico del MC-CASE: tomando como insumos primarios el Modelo de Calidad para Evaluar Herramientas CASE MC-CASE y la caracterización realizada, se procede a revisar semánticamente el significado de cada elemento presente en el MC-CASE con respecto a los aspectos que se deben considerar presentes en una Herramienta de Desarrollo de Software que soporte MDA, por lo cual aquí se establece el nivel de cobertura que tiene el MC-CASE para soportar la evaluación de una herramienta MDA. 
• Propuesta del Meta-Modelo: aquí se propone el Meta-Modelo de Calidad para Evaluar Herramientas CASE con soporte a MDA, esta propuesta incluye el Modelo del Producto, el cual a su vez esta compuesto por el Modelo Teórico que implica la definición de toda la Arquitectura que lo compone, tomando como base el MC-CASE y la definición técnica de cada una de las métricas que deban proponerse para conformar el modelo y el Modelo Matemático, el cual le da una base definida y objetiva para su aplicación.  El Modelo del Proceso, que describe los pasos que se deben seguir para la aplicación del Modelo del Producto y el Modelo Humano, que define a todas las personas con su respectivo perfil, que deben participar en el proceso de aplicación del Modelo del Producto.
• Conclusiones y Recomendaciones: en esta sección se redactaran las conclusiones, de tal manera que se facilite la toma de decisiones respecto al tema tratado.  Finalmente,  se harán algunas recomendaciones con respecto a futuras investigaciones relacionadas.

Meta-Modelo de calidad para evaluar herramientas de desarrollo de software con soporte a MDA

Esta sección centra su atención en plantear la propuesta de un Meta-Modelo de Calidad para Evaluar herramientas de desarrollo de software incluyendo el soporte al enfoque MDA.  Este Meta-Modelo esta compuesto a su vez por tres modelos, el Modelo del Producto, el Modelo del Proceso y el Modelo Humano.  El Modelo del Producto esta asociado con el producto real que se crea en esta propuesta, y que será instanciado en cada evaluación que se realice a una herramienta de desarrollo; el Modelo del Proceso contiene todos los pasos que se deben seguir para aplicar el producto y poder obtener unos resultados, y el Modelo Humano plantea como debe estar conformado el grupo de personas que deberán aplicar el proceso para generar unos resultados utilizando el producto.  La Figura Nº 2, ilustra el contenido del Meta-Modelo de Calidad para HDS, a través de un diagrama de clases.

Figura Nº 2. Meta-Modelo de Calidad para HDS Fuente: Elaboración Propia.

A continuación se desarrollarán los Modelos del Producto, del Proceso y el Humano respectivamente.

Modelo del producto

El Modelo del Producto esta formado por dos grandes modelos, en primer lugar el Modelo Teórico, el cual describe toda la arquitectura del MC-HDS-MDA, mostrando todos sus niveles de abstracción, y en segundo lugar para darle mayor robustez al modelo teórico se propondrá un Modelo Matemático que valide las mediciones que se hagan a la hora de experimentar con el modelo teórico y ayude a agregarle objetividad a los resultados de la aplicación del Modelo de calidad para evaluar herramientas de desarrollo de software con soporte a MDA (MC-HDS-MDA).  A continuación se describirá el Modelo Teórico.

Modelo teórico MC-HDS-MDA

La propuesta del MC-HDS-MDA es una actualización del MC-CASE, la cual obedece al hecho comprobado de que no cubre los aspectos relativos a la evaluación de una herramienta CASE de hoy en día, tal como se evidenció en el Análisis Semántico realizado al  MC-CASE,  lógicamente si el objeto de evaluación evoluciona, el modelo de calidad usado para hacer la evaluación también debe evolucionar, y poder brindarle un apoyo más real y más actualizado al sector productivo encargado de desarrollar productos software.

De acuerdo a la estructura arquitectónica que se le dará al MC-HDS-MDA a continuación se presenta un resumen del modelo a nivel de procesos, tomando como base la cadena de valor, en tal sentido el modelo tiene dos procesos medulares que son Ciclo de Vida, que determina la razón de ser de la herramienta de desarrollo de software, y Cliente, quien establece las necesidades de uso que le dará a la herramienta de desarrollo.  Y posteriormente se encuentran los procesos de apoyo, como se puede observar en la Figura Nº 3, se tiene a Calidad, es decir que tan buena es la herramienta como producto de software, y a Comercialización, que relaciona los elementos asociados con el proveedor de la HDS.

Figura Nº 3. Cadena de Valor del MC-HDS-MDA Fuente: Elaboración Propia.

Arquitectura del modelo de calidad (MC-HDS-MDA)

El Modelo de Calidad para evaluar herramientas de desarrollo de software con soporte a MDA estará basado en el MC-CASE, debido a que éste a su vez estaba fundamentado en lo que plantea la ISO 14102 que es un estándar internacional propuesto por la ISO para evaluar herramientas CASE, entonces el MC-HDS-MDA quiere tomar las ventajas que posee el MC-CASE.  Otra particularidad importante del modelo propuesto es que se quiere que sea un modelo sistémico, es decir, perfectamente adaptable a las necesidades de la evaluación.

El MC-HDS-MDA esta compuesto por seis capas de abstracción, de arriba hacia abajo se tienen: capa 1 – categorías, capa 2 – característica, capa 3 – tipo de característica, capa 4 – subcaracterística, capa 5 – subcaracterística atómica y capa 6 – métricas.

Figura Nº 4. Arquitectura del MC-HDS-MDA Fuente: Elaboración Propia.

A continuación se describirán las capas ilustradas en la Figura Nº 4.

• Capa 1 – Categorías: Esta es la capa de mayor nivel de abstracción y se refiere al tipo de aspectos que se están evaluando, esta capa se divide en tres categorías: Internos, Usuario y Externos.  La categoría Internos se refiere a todos elementos involucrados en la evaluación que sean propios de la herramienta, en cuanto a su funcionalidad y a su calidad.  La categoría Usuario, hace referencia a todos los aspectos relacionados con la funcionalidad de la herramienta esperada por la persona o la organización para quien se hace la evaluación de la herramienta de desarrollo.  Y la categoría Externos esta relacionada con los elementos que no tienen que ver ni con la funcionalidad de la herramienta, ni con su calidad, ni con el cliente para el cual se hace la evaluación; esta categoría esta asociada directamente con información que depende de la calidad del desarrollador de la herramienta y del grado de aceptación que ha tenido la herramienta dentro del sector productivo de software.
• Capa 2 – Características: Esta capa hace una subclasificación más específica de cada una de las categorías descritas anteriormente.  En tal sentido se tiene a la categoría Internos, que se divide en primer lugar en la característica Ciclo de Vida, con todo lo relacionado al proceso de desarrollo de software, donde tradicionalmente se tienen a cada una de las grandes etapas del proceso de desarrollo separadas, esta característica relaciona todo lo que tiene que ver con la funcionalidad para la cual ha sido creada la herramienta CASE. Y en segundo lugar la característica Calidad, la cual tiene asociado todos los aspectos relacionados con la medición de la calidad de un producto software, y  está basada en el estándar internacional ISO 9126.  Luego se tiene a la categoría Usuario, ésta está subdivida en la característica Cliente, que reúne todos los elementos que están íntimamente involucrados con las necesidades que tiene  el cliente como usuario que desea adoptar la herramienta para soportar sus procesos de desarrollo. Y por último tiene la característica Comercialización, que depende directamente de la categoría Externos; esta característica engloba todos los aspectos asociados con el proceso de comercialización de la herramienta de desarrollo.
• Capa 3 – Tipo de Característica: Esta capa por ahora sólo la posee la característica Ciclo de Vida y se divide en dos, el tipo de característica Procesos Medulares y el Tipo de característica Procesos de Apoyo.  Esta capa se crea tomando como base la estructuración que tienen los procesos de desarrollo de hoy en día por ejemplo: RUP, Métrica, Watch, entre otros, que separan los procesos medulares de los procesos de apoyo, por lo tanto en este trabajo de investigación se quiere destacar la inclinación que tiene la herramienta de desarrollo de soportar procesos medulares o procesos de apoyo.
• Capa 4 – Subcaracterísticas: Esta es la cuarta capa del MC-HDS-MDA, y nace de una especificación más concreta de los aspectos que involucra la capa 3 como es el caso de la característica ciclo de vida; o de la capa 2 – características para los casos de Calidad, Cliente y Comercialización.  Por ejemplo, en el caso de la Característica de Calidad se hace una subclasificación de esta y nacen las subcaracterísticas: Funcionalidad, Fiabilidad, Portabilidad, Usabilidad, Mantenibilidad y Eficiencia.
• Capa 5 – Subcaracterísticas Atómicas: Es la quinta capa del modelo y corresponde a un nivel más bajo de abstracción en cuanto al manejo de las subcaracterísticas; centra la atención es aspectos muy particulares de cada subcaracterística, por ejemplo, en el caso de la Subcaracterística Indicadores de Soporte, señalada en el modelo arquitectónico como SOP, posee las siguientes subcaracterísticas atómicas: perfil del vendedor, perfil del producto y disponibilidad de entrenamiento.  Es importante recordar, que éste modelo esta basado en el estándar internacional para evaluar herramientas CASE 14102 y éstas subcaracterísticas son propuestas por este estándar.  El modelo MC-HDS-MDA propone un conjunto de subcaracterísticas atómicas provenientes de las subcaracterísticas NEG (Modelado de Negocio), REQ (Ingeniería de Requisitos), MDA (Arquitectura Dirigida por Modelos), ADQ (Proceso de Adquisición)  y VEN (Proceso de Venta).
• Capa 6 – Métricas: Es la sexta y última capa del MC-HDS-MDA, ésta capa hace referencia a un conjunto de métricas que se proponen por cada una de las subcaracterísticas atómicas del modelo.  Estas métricas son los aspectos más concretos del MC-HDS-MDA, y los verdaderamente medibles. Cada una de las métricas tiene unos valores de referencia por medio de los cuales el evaluador colocará una respuesta numérica como resultado de la medición de la métrica. La definición de este conjunto de métricas se puede encontrar en [Díaz, 2009]. 

En resumen el Modelo Teórico ha quedado conformado por 487 métricas que corresponden a la capa 6 de la arquitectura del MC-HDS-MDA, discriminadas de la siguiente manera: 

• característica: Ciclo de Vida – procesos medulares: 242 métricas.
• característica: Ciclo de Vida – procesos de apoyo: 89 métricas.
• característica: Calidad: 76 métricas.
• característica: Cliente: 53 métricas
• característica: Comercialización: 27 métricas

Por otro lado, es muy importante acotar que durante el desarrollo de este capítulo, se hizo un análisis semántico mucho más profundo al MC-CASE, lo que originó algunos cambios que se reflejaron en la propuesta de métricas descrita anteriormente.

Una vez construido el Modelo Teórico, se le debe dar el soporte numérico, para esto a continuación se describirá todos los elementos que permiten elaborar el Modelo Matemático.

Modelo matemático del MC-HDS-MDA

Este modelo tiene como objetivo principal establecer matemáticamente la forma de arrojar los resultados una vez que se aplique el modelo teórico a una o más herramientas de desarrollo de software.  Para ilustrar mejor su construcción, esta sección estará dividida en tres subsecciones que son: Consideraciones Generales, la cual pretende establecer algunas premisas que se utilizaron para conformar el modelo; luego estará Calculo de la Calidad de la HDS, donde se hace una abstracción de la arquitectura del MC-HDS-MDA para generar las relaciones que permiten ir calculando la Calidad de la Herramienta de Desarrollo de Software y por último se encuentra la Determinación del Índice de Confiabilidad del Evaluador, donde se califica de acuerdo a unas características a los evaluadores encargados de valorar  a las HDS.  A continuación se detallaran cada uno de estos aspectos.

Consideraciones generales

• El Modelo se instancia de arriba hacia abajo, y se ejecuta de abajo hacia arriba, es decir, los resultados deben ir organizándose de abajo hacia arriba.
• El Cliente es quien establece los requerimientos y las prioridades, es decir, lo que necesita, y lo que prefiere y lo que esta dispuesto a omitir, por ejemplo, el cliente pudiera establecer, que para él es necesario que se cumplan sus requisitos, pero en cuanto a calidad, debe ser la mejor, sin importar los aspectos relacionados con el proveedor, ni los aspectos relacionados con el ciclo de vida.
• Esta consideración conduce a que el modelo matemático tiene que permitir el establecimiento de prioridades, lo que a su vez caracteriza a este Meta-Modelo como un modelo de calidad dirigido al cliente.  Estas prioridades en el Modelo Matemático serán denominadas Pesos.
• El conjunto de prioridades se pueden establecer a partir de la capa 5, de abajo hacia arriba, es decir, la capa 6 no admite el establecimiento de prioridades.
• La escala de prioridades o pesos podrá ser 1, 2, 3, 4 o 5, por defecto el sistema asumirá el valor de 1, es decir, si el cliente no establece prioridades, el encargado de instanciar al modelo colocará el valor de 1 en los pesos.
• Si se quisiera omitir alguna Subcaracterística atómica, subcaracterística, característica tipo, característica o categoría, se le colocará el valor de 0 en el peso.
• Cada métrica tiene un valor mínimo y máximo que puede admitir.
• A la hora de realizar los cálculos de la Calidad, todos los valores de las métricas deben ser normalizados a la escala del 0 al 1.  Para las métricas Bolean y Tasa de Cobertura no hay problema porque su escala va del 0 al 1; pero en el caso de la métrica tipo Escala de Liker si hay que hacer una conversión, para esto se utilizará la siguiente relación:
• 0 equivale a 0
• 1 equivale a 0,25
• 2 equivale a 0,5
• 3 equivale a 0,75
• 4 equivale a 1

Calculo de la calidad de la HDS

Para ilustrar la abstracción que se hizo de la arquitectura del MC-HDS-MDA, y poder generar cuantitativamente la relación existente entre las diferentes métricas, subcaracterísticas atómicas, subcaracterísticas y características, con sus respectivos pesos a partir de las Subcaracterísticas atómicas hacia arriba, se muestra a continuación la Figura Nº 5.

Figura Nº  5.  Abstracción a través de matrices del MC-HDS-MDA Fuente: Elaboración Propia.

De acuerdo con la Figura Nº 5, el Modelo queda dividido en cuatro grandes características, representadas en este caso por C, que va desde 1 hasta k,  cada una de las características o de las Ck, posee un conjunto de Subcaracterísticas representadas por S, donde el numero de S por C, no necesariamente es igual, por lo que en la figura se muestra como l subcaracterísticas por cada C.   Dentro de cada S hay un conjunto j de Subcaracterísticas atómicas representadas por SA, y cada SAj, posee un número i de métricas, donde el i varía para cada una de las SA.  Ahora bien, como cada Subcaracterística atómica puede asumir un peso determinado entre (0 y 5) dependiendo de las prioridades del cliente, se tiene que: 

La calidad (representada por Q) de la J-ésima subcaracterística atómica, de la l-ésima subcaracterística, de la k-ésima característica, viene representada a través de la siguiente relación.

Donde P_jlk es el peso de cada j-ésima subcaracterística atómica.

Esta relación se determina por un promedio ponderado, en virtud de que cada subcaracterística atómica que conforma a la subcaracterística  tiene asociado un peso.

Ahora, subiendo al nivel de las características, la calidad de la k-ésima característica también se calcula a través de un promedio ponderado, dado que cada subcaracterística que la conforma tiene un peso asociado representada por la relación siguiente:

Para calcular la Calidad total de la HDS, se determina a través de un promedio ponderado de todas las características que conforman al MC-HDS-MDA.

Tomando en cuenta que el Meta-Modelo que se propone en esta investigación, lo constituyen el Modelo del Producto, el Modelo del Proceso y el Modelo Humano, y dentro del Modelo humano que será especificado en una sección más adelante, se encuentran los evaluadores, y son ellos quienes realizan la evaluación de la HDS; se hace necesario examinar las características que poseen los evaluadores, debido a que en toda evaluación humana, existe un grado de subjetividad incluido en las valoraciones que haga con respecto a algún rasgo de la HDS.

Determinación del índice de confiabilidad del evaluador

Para medir el Índice de Confiabilidad del evaluador (ICE), que será definido como el grado de confianza que se tendrá con respecto a sus evaluaciones, y que será determinado a través del uso de dos elementos: el primero, el tiempo de uso de la HDS, que será medido en meses; y el segundo, el número de proyectos realizados utilizando la HDS, en consecuencia se tiene lo siguiente:

En esta investigación se tomarán como elementos ideales a:

• Para el caso del tiempo de uso, 6 meses como mínimo.
• Para el caso de los proyectos realizados, se asumirá como ideal que el evaluador haya realizado 2 proyectos utilizando la HDS.

Por supuesto, lo ideal es tener evaluadores con estas características, pero se tiene que recordar que a la hora de experimentar y posteriormente cuando se ponga el MC-HDS-MDA en uso con el sector productivo, pudieran darse tres casos:

• Que se tengan uno o varios evaluadores con las condiciones ideales.
• Que se tengan uno o varios evaluadores con solo alguna de las condiciones cumplidas.
• Que se tengan uno o varios evaluadores en condiciones no ideales

Para dar respuesta a todas estas situaciones posibles, el Modelo Matemático propone calcular el Índice de Confiabilidad a cada uno de los evaluadores y de esta forma poder ofrecer al Experto en el Modelo una mejor fundamentación a la hora de tomar decisiones con respecto a una u otra HDS.

A continuación se mostrará la Figura Nº 6, donde se ha graficado las diferentes situaciones descritas anteriormente.

Figura Nº  6.  Ubicación de los evaluadores en un plano de dos dimensiones Fuente: Elaboración Propia.

Observe que el punto ideal sería cuando el evaluador tiene 2 proyectos realizados y 6 meses de uso con la HDS, en este caso el Índice de Confiabilidad para ese evaluador es 1, pero si tuviera más de 2 proyectos realizados y más de 6 meses de uso con la HDS, el punto en la gráfica estaría ubicado en el II cuadrante, y en este caso el Índice de Confiabilidad también sería 1.  Para los casos en que se tenga a x mayor a 2 o a y mayor a 6, el punto estaría en el primer y tercer cuadrante, donde se ha propuesto que el Índice de Confiabilidad sea de 0.8 en virtud de que, si el evaluador tiene más de dos proyectos en menos de 6 meses, quiere decir, que ha hecho mucho con la HDS en poco tiempo, y esta situación garantiza que hubo un trabajo intensivo con la herramienta en un corto tiempo.  Por otro lado, si el evaluador ha usado la herramienta por más de 6 meses pero tiene menos de dos proyectos concluidos, es posible que la razón sea por el tamaño de los proyectos, pero ha usado por un tiempo prolongado a la HDS y eso garantiza un conocimiento importante.

Para esta investigación, el problema realmente se presenta cuando se tiene a uno o más evaluadores con menos de 2 proyectos y menos de 6 meses de uso de la HDS.  Para estos casos se propone que el Índice de Confiabilidad sea calculado a través de la formula de la Distancia Euclideana, la cual establece el calculo de la distancia entre dos puntos en un plano de cualquier dimensión.

Para el caso de la distancia entre dos puntos, la fórmula quedaría de la siguiente manera:

En consecuencia  se tiene que:

• Para el caso de tener un evaluador con un Índice de Confiabilidad de 1, se confiará 100% en los resultados que arrojen sus evaluaciones.
• Si se tienen dos o tres evaluadores calificando a una misma HDS, la Q total será el promedio de las Q de cada evaluador, es decir:

Donde, E será el número de evaluadores; e=1,2,3,…,E.

• Si se tienen más de cuatro evaluadores calificando a una misma HDS, se eliminarán los extremos inferior y superior, y se determinará un  promedio con las  Q intermedias.  Esta estrategia se usa  para tratar de eliminarle en mayor grado el sesgo que pueda tener la media calculada entre las Q.
• En los casos de tener evaluadores ubicados en el I y III cuadrante, se confiará un  80% en los resultados de sus evaluaciones, e igual que en los casos anteriores si se tienen dos o tres evaluadores se obtendrá un promedio entre las Q, y se tienen de cuatro evaluadores en adelante, se eliminaran los extremos inferior y superior, y luego se obtiene el promedio con el resto de las Q.
• Si se tienen solo evaluadores ubicados en el IV cuadrante, se obtendrá el Índice de Confiabilidad de acuerdo con la fórmula de la Distancia Euclideana, de tal manera de escoger al evaluador que tenga la distancia menor con respecto al punto ideal (2 proyectos realizados y 6 meses de uso).  El índice arrojará un valor positivo y negativo, lo que significará que pudo haber sobreestimado o subestimado a la HDS en el porcentaje que arroje el cálculo de la Distancia Euclideana.

Una vez construido este modelo se ha conformado el Modelo del Producto, es decir, el Modelo Teórico y el Modelo Matemático, el próximo paso es proceder a su puesta a prueba que no es más que experimentar con dicho modelo, en otras palabras hacer evaluaciones de herramientas de desarrollo instanciando al MC-HDS-MDA; y para poder hacer esto se deben seguir unos pasos, los cuales se detallarán en la siguiente sección, estos pasos constituyen el Modelo del Proceso.

Modelo del proceso

El Modelo del Proceso lo constituyen una serie de pasos que se deben seguir para que las personas  que deben conformar el equipo de trabajo instancien el modelo del producto y así poder ofrecer una recomendación lo más objetiva posible al cliente.  A continuación se describen cada uno de los pasos que conforman el modelo.

En primer lugar el Cliente establece sus necesidades y prioridades, es decir, los requerimientos indispensables que desee que cubra la HDS y las prioridades con respecto a las preferencias y omisiones que puede aceptar de la herramienta de desarrollo de software.  El experto en el Modelo recibe estas necesidades y prioridades y procede a instanciar al Modelo Teórico, esta instanciación se hace de arriba hacia abajo o (Top-Down).

Este modelo plantea las siguientes sugerencias para realizar la instanciación del MC-HDS-MDA:

• Para el caso de la característica Cliente, se deben instanciar todos los aspectos relacionados con los requerimientos del cliente, en este caso puede ser necesario crear métricas nuevas, este modelo por ser Dinámico con respecto al cliente, ofrece esta bondad.
• Con respecto a la Característica Calidad, se deben instanciar como mínimo las Subcaracterísticas: Funcionalidad, Portabilidad y Usabilidad, y seleccionar por lo menos el 50% de sus Subcaracterísticas atómicas, y el 50% de las métricas que correspondan.
• Para la característica Comercialización, se debe mínimo instanciar las subcaracterísticas: Proceso de Venta, e Indicadores de Soporte, y seleccionar por lo menos el 50% de sus Subcaracterísticas atómicas, y el 50% de las métricas que correspondan.
• Con respecto a la Característica Ciclo de Vida, despenderá del tipo de HDS evaluada, por ejemplo si es una HDS MDA, se debe isntanciar la subcaracterística MDA y todas las de los procesos medulares, pero si fuera una herramienta solo de requisitos, se instanciaría la Subcaracterística Ingeniería de Requisitos.  Cualquier subcaracterística se debe instanciar con el 80% mínimo de subcaracterísticas atómicas el y 80% de sus métricas.

Una vez que el Experto en el Modelo ha realizado la instanciación, el próximo paso es determinar el Índice de Cumplimiento (IC) con respecto a las necesidades básicas del cliente, este valor lo calcula utilizando la instanciación del modelo más los pesos o prioridades suministradas por el cliente.  El Índice de Cumplimiento será definido como el valor máximo u óptimo que deben arrojar todas las métricas asociadas con las necesidades básicas del cliente, tomando en cuenta también los pesos que están representando la importancia de algún elemento con respecto a otro para ese cliente en especifico.

Luego debe seleccionar a los evaluadores, para esto tomará en cuenta el Índice de Confiabilidad del Evaluador y paralelamente podrá generar los cuestionarios de acuerdo a la  instanciación realizada.  El experto debe enviar el cuestionario dirigido al proveedor de la HDS, lo más pronto posible, ya que éste tendrá mínimo 10 días hábiles para responderlo.  Una vez recibido este cuestionario y tener seleccionados a los evaluadores, se le entrega a los evaluadores el cuestionario respondido por el proveedor y el cuestionario relacionado con la Característica Cliente.  El evaluador lo recibe y procede a llenarlo, para esta actividad y tomando en cuenta lo delicado de las respuestas o valoraciones a las métricas que debe hacer el evaluador se sugiere, dar valores a no más de 20 métricas al día, de tal manera de garantizar la máxima objetividad de los resultados que de acuerdo a su percepción tenga de la HDS.  Estos valores deben ser revisados por el evaluador y corregir detalles de ser necesario, posteriormente le debe suministrar esta tabulación de métricas al experto. 

Para el modelo del proceso estamos llamando Q1 a la calidad relacionada con el ciclo de vida,  Q2 a la calidad asociada con característica Calidad, Q3 a la calidad asociada con el cliente y a Q4 a la calidad referida a la comercialización. 

Posteriormente el experto con esta información y haciendo uso del modelo matemático calcula la Q3, si esta Q3 es mayor o igual al Índice de Cumplimiento (IC) de los requisitos del cliente, el experto envía los cuestionarios de Ciclo de Vida, Calidad y Comercialización, de acuerdo con la instanciacion realizada, el evaluador los llena y los revisa, para luego pasarlos al experto nuevamente, que es quien calcula la calidad (Q) de la HDS con respecto a ese evaluador, de tener más de 1 evaluador determina el promedio y luego genera un informe de resultados y recomendaciones, si tiene un solo evaluador, igualmente genera el informe.  Finalmente debe entregar el informe al Cliente y realizar las sugerencias respectivas.

Para los casos de que Q3 sea inferior al IC, el experto genera un informe y lo somete a consideración con el cliente.

Para ilustrar estos pasos, observe la Figura Nº 7, donde a través de un Diagrama de Actividades de UML, se muestra la dinámica que posee el Modelo del Proceso del  MC-HDS-MDA.  Se selecciona este Diagrama por ser altamente dinámico y ajustarse perfectamente a los requerimientos del modelo.

Figura Nº  7.  Diagrama de Actividad del Modelo del Proceso del MC-HDS-MDA Fuente: Elaboración Propia

Modelo humano

El Modelo Humano hace referencia al conjunto de personas que deben conformar el equipo de trabajo para someter a evaluación a una herramienta de desarrollo de software. Este equipo de personas ejecutará el modelo del proceso para lograr una correcta aplicación del MC-HDS-MDA y poder obtener los resultados que conducirán a indicarle a un cliente si le conviene o no adoptar una herramienta de desarrollo de software.

De acuerdo con la Figura Nº 8, entre las personas que se encuentran dentro del equipo están:

Figura Nº  8.  Modelo Humano del Meta-Modelo de Calidad para HDS Fuente: Elaboración Propia.

• Experto en el Modelo: Es la persona o personas con el suficiente conocimiento acerca del modelo, su arquitectura, el modelo matemático y su aplicación, que permita hacer la instanciación del modelo de acuerdo a las necesidades planteadas por el cliente.
• Evaluador: Puede ser una o varias personas con experiencia en cuanto a desarrollo de aplicaciones de software y en cuanto al uso de la herramienta que será objeto de la evaluación.  Se recomienda que sea más de una persona que ejecute la evaluación de las herramientas.
• Cliente: Es la persona u organización que desea adoptar una herramienta de desarrollo de software.  Este cliente debe plantear sus necesidades y prioridades, es decir, cual será el uso que le pretende dar a la herramienta de desarrollo.
• Proveedor: Es la persona u organización que pone a disposición una o unas herramientas de desarrollo de software para que sean sometidas a evaluación.

A continuación se muestran las personas que conforman el Modelo Humano, a través de un Diagrama de Clases, el cual permite observar de una manera más clara la cantidad mínima y máxima de cada una de las personas y las relaciones que se establecen entre ellos.

Figura Nº 9.  Modelo Humano del Meta-Modelo de Calidad para HDS a través de un Diagrama de Clases Fuente: Elaboración Propia.

Conclusiones

Con respecto al Modelo Teórico

• El MC-HDS-MDA permite ser más concreto que el MC-CASE en cuanto al tipo de herramienta que se esta evaluando, y ésto se logra a través de la división entre los procesos medulares y los procesos de apoyo de la característica Ciclo de Vida.
• El Modelo Teórico perteneciente al Modelo del Producto, le agrega a los procesos medulares tres subcaracterísticas atómicas muy importantes dentro del mundo de los procesos de desarrollo como son: las subcaracterísticas; Modelado del Negocio, Ingeniería de Requisitos y MDA. Y para cada una de estas subcaracterísticas se proponen las subcaracterísticas atómicas y las métricas correspondientes.
• Las métricas consideradas dentro del grupo de métricas críticas es decir, las que están asociadas íntimamente con las necesidades del usuario, pueden aumentar, dado que de acuerdo a los requerimientos del cliente se pueden adicionar nuevas métricas, por lo que la categoría usuario se considera altamente dinámica, lo que conduce a caracterizar el Modelo Teórico como un Modelo Dinámico.
• Se decide separar MDA como una subcaracterística aparte en función de que si la herramienta no fuera MDA, penalizaría considerablemente la puntuación si la herramienta fuera solo de diseño o solo de programación.  Entonces para no desfavorecer a este tipo de herramientas de desarrollo de software, se crea una nueva Subcaracterística para evaluar todos los aspectos que implique que la herramienta soporte el enfoque MDA.
• Todas las métricas tipo tasa de cobertura que en el MC-CASE estaban distribuidas por todo el modelo, en el MC-HDS-MDA estarán concentradas en la categoría Usuario.
• Todas las métricas del Usuario deben instanciarse al momento de ejecutar una evaluación.
• Durante la construcción del Modelo Teórico debido al nivel de detalle necesitado para lograr su conformación, se hizo necesario hacer nuevamente un Análisis Semántico del MC-CASE, con respecto a las elementos que se mantendrían para el MC-HDS-MDA.
• Con respecto al Modelo Matemático
• El Modelo del Producto propone un Modelo Matemático que soporta al modelo teórico dándole objetividad a los resultados del MC-HDS-MDA.
• El Modelo Matemático toma en cuenta las prioridades establecidas por el cliente.
• El Modelo Matemático considera las características del evaluador y permite determinar el Índice de Confiabilidad del Evaluador.

Con respecto al Modelo del Proceso y al Modelo Humano

• La instanciación del MC-HDS-MDA que se realiza durante el Modelo del Proceso es Top-Down.
• El Meta-Modelo propone un Modelo de Proceso, el cual permite de una forma sistemática aplicar el MC-HDS-MDA a una  o un conjunto de herramientas de desarrollo de software.
• El Meta-Modelo es un modelo de Calidad dirigido al cliente, en virtud de que el cliente no solo establece sus necesidades para adquirir una HDS sino también que establece las prioridades que considera relevantes para sus intereses organizacionales.
• El Meta-Modelo propone un Modelo Humano, donde establece cuales son las personas que deben conformar el equipo que aplicará el MC-HDS-MDA.

Recomendaciones

Dentro de las recomendaciones que se sugieren para futuras investigaciones están:

• Experimentar con el MC-HDS-MDA, de tal manera de ponerlo a prueba para lograr el refinamiento necesario y obtener la versión final del Meta-Modelo.
• Divulgar todas las investigaciones que en materia de Calidad de herramientas de desarrollo de software  se concreten para lograr uno de los objetivos fundamentales de la academia: servir de apoyo a los sectores productivos involucrados en la adopción de nuevas tecnologías, particularmente las HDS.
• Crear un pool de herramientas de desarrollo de software tanto libres como propietarias y así contar con el elemento principal para realizar las evaluaciones con el MC-HDS-MDA.
• Generar una base de datos con la información resultante de las evaluaciones hechas a las herramientas CASE con las que cuenta el Decanato de Ciencias y Tecnología.
• Generar proyectos de investigación-extensión en el Decanato de Ciencias y Tecnología que permitan asesorar al sector productivo de la región, en la evaluación de HDS.

Referencias

Alfonso Rivas E., Marcano C., Yegres K. y Gascón Y., Uso de herramientas CASE para el modelado de negocios.  Ninth LACCEI Latin American and Caribbean Conference (LACCEI’2011), Engineering for a Smart Planet, Innovation, Information Technology and Computational Tools for Sustainable Development, August 3-5, 2011, Medellín, Colombia.

Anacleto Valerio Adrian.  Ventajas de MDA: Arquitectura dirigida por Modelos. 18-10-2006.

Bollati, Vara, Vela y Marcos.  “Una revisión de herramientas MDA”.  2008

Cervantes Maceda Humberto y Riba Zarate Nestor.  Un Enfoque MDA para el desarrollo de aplicaciones basadas en un modelo de componentes orientados a servicios.  Universidad Autónoma Metropolitana.  Unidad Iztapalapa.  2007.

Chakir Boutaina, Fredj Mounia y Nassar Mahmoud.    A model driven method for promoting reuse in SOA-solutions by managing variability.  International Journal of Computer Science Issues.  Vol. 9, Issue 3, No 3, Mayo 2012.

Díaz Ana M.  Adaptación de los indicadores tecnológicos a la ISO 14102 para evaluar calidad de herramientas CASE.  Tesis de Maestría.  USB. 2000.

Díaz Ana M. Propuesta de un Meta-Modelo de Calidad para Evaluar Herramientas de Desarrollo de Software con Soporte a MDA.  Trabajo de Ascenso.  UCLA. Barquisimeto – Venezuela.  2009.

Garcia Molina Jesús y Rodríguez Vicente Jesús.  Ingeniería de Modelos con MDA.  Estudio Comparativo de OptimalJ y ArcStyler.  Facultad de Informática de la Universidad de Murcia.  Junio 2004.

Herrera Juan Carlos, Matteo Alfredo e Isabel Díaz.  Una Caracterización de Herramientas MDA de Código Abierto.  UCV.  2007.

Kendall, Keneth. y Kendall, Julie. Análisis y Diseño de Sistemas. Sexta Edición. Pearson Prentice Hall. 2005.

Mendoza Luis Eduardo.  Indicadores organizaciones para evaluar herramientas CASE en organizaciones venezolanas.  Tesis de maestría.  USB.  1999.

Object Managment Group, “MDA Guide Version 1.0.1”, editado por la OMG, E.U., 2003.

Sommerville, I. Software engineering. Fifth edition, Addison-Wesley Publishing Company. 1998.

Topper, A., Oullette, D. y Jorgensen, P.  Structured methods: models, techniques, and CASE. McGraw-Hill, Inc. 1994.

Técnica Administrativa
ISSN 1666-1680

http://www.cyta.com.ar -

Vol.:12
Nro.:01
Buenos Aires, 15-01-2013

URL http://www.cyta.com.ar/ta1201/v12n1a3.htm