La competitividad en el mercado de la industria del software exige a las empresas elaborar productos que satisfagan las necesidades de las partes interesadas, en menos tiempo de desarrollo, con bajos costos y elevados estándares de calidad [1-3]. Para alcanzar estos propósitos se adoptan modelos y normas internacionales, los cuales ofrecen una estrategia de trabajo progresiva que contribuye, a largo plazo, a mejorar los indicadores de rendimiento de los procesos de desarrollo de software [4-11]. Cuba cuenta con un Modelo de la Calidad para el Desarrollo de Aplicaciones Informáticas (MCDAI) el cual tiene como propósito que sea fácil de entender y aplicar, y que sirva de base para alcanzar evaluaciones futuras en otros modelos de referencia internacional [12]. El proceso de diseño del producto juega un papel fundamental en la calidad final del mismo. Esta afirmación la corrobora Pressman al expresar: “Tanto la calidad como la facilidad de recibir mantenimiento son resultado de un buen diseño” [13].
Los modelos y normas internacionales proponen un conjunto de buenas prácticas para el diseño del software entre la que se encuentra la reutilización de activos principales de software [4].
Los autores de la presente investigación concuerdan con [14-16] al afirmar que incorporar buenas prácticas para la reutilización de software en el proceso de diseño es una posible solución para dar respuesta a un mercado que exige productos cada vez más fiables, baratos y entregados a tiempo.
La reutilización de software es el proceso de crear sistemas de software a partir de un software existente. El enfoque de la reutilización ha variado desde una perspectiva individual (donde se reutiliza código fuente cuando es necesario), hacia una oportunista donde se cuenta con un repositorio de componentes que son reutilizados una vez surja una necesidad, hasta una reutilización gestionada donde el proceso de creación de componentes reutilizables se realiza de manera institucionaliza, sistematiza, planifica y mejora [15, 17].
Este enfoque es el utilizado por las líneas de productos de software, la cual se define como un grupo de sistemas de software que comparten un conjunto común y gestionado de características para satisfacer las necesidades específicas de un segmento de mercado o misión particular y se desarrollan a partir de un conjunto común de activos principales de forma prescrita [18].
Organizaciones reconocidas como: Hewlett-Packard, Cummins, Inc., General Motors, CelsiusTech, Rockwell- Collins, Motorola, Philips, Nokia, Boeing, Raytheon y Salion, Inc., han adoptado el enfoque de líneas de productos y refieren obtener mejoras competitivas en atributos de la calidad (modificabilidad, testabilidad, usabilidad y adaptabilidad de los productos y servicios que brindan), reducción de tiempo de desarrollo, que permitió la disminución de los gastos y el aumento del índice de satisfacción de los clientes, entre otras [4, 19]. El enfoque de reutilización en Cuba por lo general no está dirigido al desarrollo de líneas de producto de software. En un diagnóstico realizado en el 2014 a una muestra de catorce (14) organizaciones desarrolladoras de software, se identificó que el 66,98% de las mismas dirigen su producción a un segmento de mercado, sin embargo, las buenas prácticas de gestión de la reutilización, identificadas en [7, 18, 20, 21], no se implementan en el 49% y se implementan parcialmente en el 33%. Los resultados del diagnóstico también permitieron identificar que el 52,24% de los proyectos se entregaron fuera de tiempo, el 16,42% no cumplieron la totalidad de los requisitos pactados con el cliente, el 50% no analizan alternativas de solución a partir de componentes reutilizables y el 65% no registra las principales decisiones arquitectónicas [22].
Las empresas que conforman la naciente Industria de Servicios y Aplicaciones Informáticas en Cuba, están clasificadas mayoritariamente por pequeñas y medianas empresas de software (PYME) en un 57%, el 22% se consideran grandes empresas y el 21% micro empresas, de acuerdo con el criterio que plantean varios autores donde las empresas según la cantidad de empleados se clasifican en: micro empresas de 1 a 9 trabajadores, pequeñas empresas de 10 a 49 trabajadores, medianas empresas de 50 a 199 trabajadores y gran empresa, superior a 200 trabajadores [23, 24].
En noviembre de 2017 se aplicó otro estudio a una muestra en ocho organizaciones desarrolladoras de software en Cuba, con la finalidad de profundizar en el comportamiento del proceso de diseño del software y las actividades de gestión de reutilización que incorporan, aplicando las técnicas entrevista, observación y encuesta. Los resultados permitieron identificar que: el 92% no define una arquitectura de dominio que tenga en cuenta los elementos comunes y variantes para la familia de aplicaciones, el 97% no evalúa la arquitectura, el 69% no aplica un programa que gestione el desarrollo de activos reutilizables, el 65% no evalúa las oportunidades de reutilización a partir de activos de dominio desarrollados, ni identifican los esfuerzos de adaptación, creación o adquisición de nuevos activos y el 90% no cuenta con un repositorio de activos reutilizables.
A partir de las dificultades antes expuestas se plantea la necesidad de elaborar un proceso de Diseño del Producto de Software para el MCDAI, que incorpore buenas prácticas de la gestión de reutilización para ayudar a mejorar los indicadores de rendimiento del proceso de la Industria de Aplicaciones y Servicios Informáticos en Cuba.
Los autores de la presente investigación realizaron una revisión bibliográfica con el propósito de identificar las buenas prácticas a tener en cuenta en el diseño del software y la reutilización en los siguientes modelos y normas [9], [10], [7], [11], [6] y [20] y en los artículos [13-16, 19]. En la tabla 1 se muestra un resumen de las buenas prácticas identificadas, constituyendo la base para la propuesta de la presente investigación.
En el caso de los modelos CMMI-DEV, MoProSoft y COMPETISOFT presentan las bases para desarrollar con reutilización (definición y descripción de interfaces, análisis de alternativas de solución, análisis de si hacer/reutilizar/adquirir), pero no tienen el enfoque gestionado de la reutilización.
Tabla 1. Buenas prácticas del diseño del software (fuente: elaboración propia)
|
Buenas prácticas |
CMMI-DEV |
MPS.Br |
MoProSoft |
COMPETISOFT |
ISO/IEC /IEEE |
|
|
12207 |
15288 |
|||||
|
Diseñar y documentar el producto o componente de producto |
x |
x |
x |
x |
x |
x |
|
Diseñar interfaces internas y externas |
x |
x |
x |
x |
x |
x |
|
Seleccionar soluciones alternativas |
x |
x |
x |
x |
x |
|
|
Realizar análisis sobre si hacer-reutilizar o comprar |
x |
x |
x |
x |
x |
|
|
Definir la arquitectura de dominio teniendo en cuenta los elementos comunes y variantes |
x |
x |
x |
|||
|
Gestionar un programa de gestión de reutilización |
x |
x |
x |
|||
|
Gestionar la biblioteca de activos reutilizable |
x |
x |
x |
|||
Las normas ISO/IEC/IEEE 12207 y 15288, proponen un proceso de gestión del conocimiento que impulsa la gestión de reutilización de activos de software. El MPS.Br propone un área de gestión de reutilización y una de desarrollo para la reutilización donde se separan las actividades de gestión, infraestructura y alineación estratégica con los objetivos de negocio, con las actividades ingenieriles necesarias para el desarrollo de activos reutilizables. Teniendo en cuenta lo antes descrito se decidió realizar una propuesta propia que indique “qué” hacer para diseñar el producto incorporando paulatinamente prácticas para la gestión de la reutilización y ejemplificando “cómo” ponerla en práctica mediante un proceso que contiene actividades y roles asociados, así como un conjunto de indicadores que ayuden a medir y mejorar el proceso propuesto.
Para la elaboración de la propuesta se convocaron 12 especialistas de más de ocho años de experiencia en los roles de jefe de proyecto, arquitecto y desarrollador. posteriormente se realizó un análisis, basado en el método grupo focal, con el propósito de definir los requisitos que serían incluidos en la propuesta como parte del modelo MCDAI, teniendo en cuenta las buenas prácticas identificadas (ver tabla 1) y las incidencias de estas sobre los problemas detectados. Los requisitos identificados fueron agrupados por los niveles de madurez que plantea el MCDAI: Básico, Intermedio y Avanzado [12], lo cual permite que la propuesta pueda ser adoptada de forma escalonada, incorporando pequeñas mejoras en las organizaciones.
3. Resultados
Como resultado de la investigación se decidió incorporar buenas prácticas del diseño del software y de gestión de reutilización al Proceso Base Desarrollo de la Solución (DS) del MCDAI, ya que el mismo tiene como propósito: seleccionar y evaluar soluciones a partir de alternativas existentes. Diseñar, implementar y ensamblar los componentes que forman parte de la solución para dar cumplimiento a los requisitos. Identificar oportunidades de reutilización sistemática de activos de software y desarrollar activos a partir de ingeniería de dominios.
Para cumplir con este propósito se definieron los siguientes requisitos separados por niveles de madurez.
Requisitos para el nivel básico
D 1 Identificar soluciones (Identifica y registra las decisiones arquitectónicas, las cuales comprenden: soluciones tecnológicas, patrones y estilos arquitectónicos, entre otras necesarias para realizar el producto).
D 2 Diseñar el producto o el componente de producto. (Realiza el diseño estructural de acuerdo a las decisiones tomadas para satisfacer los requisitos de las partes interesadas pertinentes).
Requisitos para el nivel intermedio
D 1.1 Evaluar las posibles soluciones aplicables. (Realiza el análisis de alternativas de solución y registra los criterios y la decisión tomada, analiza además si es mejor desarrollar un componente de producto, reutilizar o adquirirlo en el mercado).
D 2.1 Definir y describir interfaces. (Identifica y registra las interfaces entre los componentes del sistema y los externos al mismo).
Requisitos para el nivel avanzado
D 1.2 Evaluar las posibles soluciones aplicables a partir de activos reutilizables. (Encargado de analizar el esfuerzo de adopción, modificación o creación de activos de dominio a partir de la biblioteca de activos reutilizables).
D 8 Desarrollar en función de la reutilización de activos de software. (Encargado de definir una arquitectura de dominio que a partir del modelo de variabilidad escogido que indique los elementos comunes y variantes para la familia de aplicaciones).
Como parte de la solución, se propone los procesos (Diseño del producto e identificación de soluciones aplicables) que facilita a las entidades la implementación de los requisitos; no es de obligatorio cumplimiento sino una guía que se puede adecuar a las condiciones de cada entidad. Debido a la amplitud de la solución propuesta, se muestra a continuación una breve descripción de los procesos.
Las actividades de reutilización se van incorporando paulatinamente en el proceso, en el nivel básico, se fomenta el registro de las tecnologías y la identificación de componentes que se pueden reutilizar en futuros desarrollos (para que de manera individual los desarrolladores puedan reutilizar los elementos de la arquitectura que consideren necesario), en el nivel intermedio se incorpora la identificación y descripción de las interfaces, fomentando un principio básico del desarrollo basado en componentes como son la modularización, abstracción y ocultación de información, que además constituye la base para la gestión de reutilización, en el nivel avanzado se propone que se aplique ingeniería de dominio e ingeniería de aplicaciones para el desarrollo de los componentes del producto, donde en un flujo de actividades, se definen los elementos comunes y variantes para la familia de aplicaciones en la arquitectura de dominio, así como la estructura de datos e interfaces estándares, en el otro flujo se realiza ingeniería de aplicaciones donde se contextualiza la arquitectura de dominio para un cliente específico, teniendo en cuenta las variabilidades exigidas como parte de sus requisitos.
3.1 Proceso de Diseño del Producto
A continuación, se presenta la descripción gráfica y textual del Proceso Diseño del Producto ver figura 1:
Actividad 1: Obtener la estructura de los elementos del sistema.
El Comité técnico / Arquitecto teniendo en cuenta las necesidades, el alcance y los objetivos del proyecto definidos en la “Oferta” y/o “Proyecto técnico”:
Identifica los principales componentes del producto y realiza su representación estructural a un alto nivel de abstracción, determinando las relaciones existentes entre los elementos que lo componen.
Se obtiene como resultado de la ejecución de esta actividad la “Oferta” y/o “Proyecto técnico” / Propuesta técnica inicial (actualizada).
Actividad 2: Identificar la arquitectura base.
El arquitecto teniendo en cuenta la propuesta técnica inicial definida en la “Oferta” y/o “Proyecto técnico” y la “Especificación de requisitos”:
Define los atributos de la calidad y requisitos funcionales que impactan en la arquitectura.
Realiza la priorización de las unidades funcionales.
Determinan los componentes que funcionan como plataforma del sistema que será desarrollado y que sirve como base para futuras implementaciones.
Se obtiene como resultado de la ejecución de esta actividad la “Arquitectura del sistema”.
Actividad 3: Refinar la estructura de los elementos del sistema.
El arquitecto teniendo en cuenta la propuesta técnica inicial definida en la “Oferta” y/o “Proyecto técnico”, la “Especificación de requisitos”, el “Modelo conceptual” y las partes interesadas definidas en el “Plan de desarrollo”:
Refina la descomposición del sistema en módulos o componentes, en dependencia del tamaño y complejidad del mismo y teniendo en cuenta las soluciones aplicables como son las tecnologías, estilos arquitectónicos, patrones entre otros.
Determina los datos persistentes que se necesitan manejar en el sistema e identifica el modelo de datos.
Define la estructura de los nodos físicos como apoyo al despliegue del sistema.
Figura 1. Descripción gráfica del proceso diseño del producto. Fuente: elaboración propia.
Se obtiene como resultado de la ejecución de esta actividad la “Arquitectura del sistema” / Estructura de los elementos del sistema.
Actividad 4: Identificar y describir las interfaces.
A partir de la “Especificación de requisitos” y la “Arquitectura del sistema”:
El arquitecto define y describe las interfaces entre los componentes del sistema (internas), y las interfaces con componentes externos al mismo para controlar los elementos de entrada/ salida y garantizar la integración con elementos externos y con el resto de los componentes del sistema.
El Diseñador identifica y describe las interfaces con los usuarios del sistema de manera tal que se cumplan los requisitos de usabilidad aplicables.
Se obtiene como resultado de la ejecución de esta actividad la “Arquitectura del sistema” / Descripción de interfaces (actualizada).
Actividad 5: Definir/Refinar la arquitectura de dominio.
En el nivel avanzado, el Comité técnico / Arquitecto teniendo en cuenta la propuesta técnica inicial definida en la “Oferta” y/o “Proyecto técnico”, la “Especificación de requisitos”, las partes interesadas definidas en el “Plan de desarrollo” y el estilo arquitectónico estándar y la plataforma tecnológica definidas en la “Arquitectura de dominio”:
Determina las vistas arquitectónicas que se van a desarrollar, de acuerdo a los puntos de vista necesarios para satisfacer a las partes interesadas en posibles entornos específicos. Ejemplos: vista lógica, vista de datos, vista de infraestructura, vista de procesos, entre otras.
Define/Refina la estructura estándar del sistema e identifica los componentes que van a ser comunes y variantes, opcionales u obligatorios para toda la familia de aplicaciones. Ejemplo de vista a utilizar: vista de lógica (la misma puede incluir el diagrama de paquetes con la descomposición del sistema, la descripción de cada elemento y sus relaciones, entre otros elementos).
Determina los datos persistentes que se necesitan manejar en el sistema y se apoya en el “Modelo conceptual”, para definir el modelo de datos estándar. Ejemplo de vista a utilizar: vista de datos (la misma puede incluir el diagrama entidad-relación y el modelo de datos).
Se obtiene como resultado de la ejecución de esta actividad la “Arquitectura del dominio” / Vista arquitectónicas (creadas).
Actividad 6: Identificar y describir las interfaces estándares.
A partir de la “Especificación de requisitos” y la “Arquitectura del dominio”:
El arquitecto define y describe las interfaces estándares entre los componentes de la familia de aplicaciones (internas), y las interfaces con componentes externos, para controlar los elementos de entrada-salida y garantizar la integración con el resto de los componentes, donde se especifica los elementos comunes y variantes, opcionales u obligatorios.
El Diseñador identifica y describe las interfaces para posibles usuarios de la familia de aplicaciones como un marco de trabajo común, de manera que se cumplan los requisitos de usabilidad aplicables.
Se obtiene como resultado de la ejecución de esta actividad la “Arquitectura de dominio” / Vista de integración (creada) / Vista de Presentación (creada).
Actividad 7: Contextualizar la arquitectura de dominio al cliente específico.
El arquitecto teniendo en cuenta la propuesta técnica inicial definida en la “Oferta” y/o “Proyecto técnico”, la “Especificación de requisitos”, el “Modelo de dominio”, el “Modelo conceptual” y las partes interesadas definidas en el “Plan de desarrollo”:
En función de las vistas arquitectónicas definidas en la “Arquitectura de dominio”, determina las vistas que se van a modificar o desarrollar, de acuerdo a los puntos de vista necesarios para satisfacer a las partes interesadas en un entorno específico.
En función de los elementos variantes identificados en el “Análisis de los componentes de la solución que se van a hacer/reutilizar/adquirir” del “Documento de toma de decisiones”, y siguiendo el estilo arquitectónico estándar; se modifican los elementos necesarios en los componentes variantes y/o se incorporan nuevos competentes, para satisfacer las necesidades del cliente específico.
Identifica nuevos datos persistentes en relación al “Modelo de datos” identificados en la “Arquitectura de dominio”.
Define la estructura de los nodos físicos como apoyo al despliegue del sistema.
Se obtiene como resultado de la ejecución de esta actividad la “Arquitectura del sistema” / Vistas arquitectónicas.
Actividad 8: Ajustar las interfaces a las necesidades del cliente específico.
A partir de la “Especificación de requisitos”, “Arquitectura del dominio” y la “Arquitectura del sistema”:
El arquitecto identifica y describe las interfaces internas y externas que se modificarán o agregarán, para controlar los elementos de entrada-salida y garantizar la integración con el resto de los componentes.
El diseñador identifica y describe las modificaciones a las interfaces para los usuarios del sistema, de manera que se cumplan los requisitos de usabilidad aplicables.
Se obtiene como resultado de la ejecución de esta actividad la “Arquitectura de dominio” / Vista de integración (creada) / Vista de Presentación (creada).
Actividad 9: AC-Ejecutar evaluación.
El equipo de evaluación, teniendo en cuenta los atributos de la calidad aplicables y los requisitos arquitectónicamente significativos, verifica que el diseño se encuentre técnicamente correcto guiado por el subproceso AC-Ejecutar Evaluación.
Actividad 10: DS_Identificación de Soluciones Aplicables.
El Comité técnico / Arquitecto identifica las soluciones aplicables al producto como lo plantea el sub-proceso DS-Identificación de Soluciones Aplicables.
Figura 2. Descripción gráfica del subproceso DS_Identificación de Soluciones Aplicables.
3.2 Subproceso identificación de soluciones aplicables
A continuación, se presenta la descripción gráfica y textual del subproceso DS_Identificación de Soluciones Aplicables ver figura 2.
Actividad 1: Identificar / refinar las soluciones aplicables al producto.
El Comité técnico / Arquitecto teniendo en cuenta las necesidades, el alcance y los objetivos del proyecto identificados, así como, estudios de mercado realizados y el “Estándar de solución técnica”:
Identifica las soluciones aplicables de la propuesta técnica inicial a un alto nivel de abstracción. Entre las soluciones aplicables se encuentran: Gestor de bases de datos, COTS, lenguaje de programación, Marco de trabajo para el desarrollo, entre otros.
Identifica y refina la propuesta de soluciones aplicables al producto como parte de la arquitectura del software/sistema (Gestor de bases de datos, COTS, lenguaje de programación, Marco de trabajo para el desarrollo y la interfaz de usuario, patrones, estilos, escenarios, algoritmos, entre otros).
Se obtiene como resultado de la ejecución de esta actividad la “Oferta” y/o “Proyecto técnico” / Propuesta técnica inicial, la “Arquitectura del sistema” / Soluciones aplicables (actualizada).
Actividad 2: Identificar las posibles soluciones aplicables al producto.
A partir del nivel Intermedio el Comité técnico / Arquitecto teniendo en cuenta las necesidades, el alcance y los objetivos del proyecto así como, estudios de mercado realizados, y el “Estándar de solución técnica”:
Realiza un estudio sobre productos similares y tendencias tecnológicas para identificar alternativas de solución aplicables. Ejemplos: alternativas por tipos de tecnologías de desarrollo (Gestor de bases de datos, COTS, lenguaje de programación, Marco de trabajo para el desarrollo y la interfaz de usuario, API, entre otros), alternativas estructurales, entre otros.
Para la concepción inicial del proyecto, se identifican alternativas de soluciones aplicables de la propuesta técnica inicial a un alto nivel de abstracción.
Como parte de la elaboración y refinamiento de la arquitectura, se identifican nuevas alternativas de soluciones que refinan la arquitectura.
Se obtiene como resultado de la ejecución de esta actividad el “Documento de toma de decisiones” / Alternativas aplicables.
Actividad 3: Seleccionar soluciones aplicables.
El Comité técnico / Arquitecto teniendo en cuenta el “Documento de toma de decisiones” / Alternativas aplicables: Realiza el análisis si hacer, reutilizar o adquirir los componentes de la solución identificados, teniendo en cuenta los criterios de factibilidad definidos, aplicando técnicas para la toma de decisiones.
En el nivel Avanzado, cuando se aplica ingeniería de aplicaciones, para realizar el análisis también se tiene en cuenta el “Modelo de dominio” almacenado en la “Biblioteca de activos reutilizables”.
Identifica criterios para la selección de la solución aplicable al producto. Algunos ejemplos de criterios pueden ser: cumplimiento requisitos arquitectónicamente significativos de los atributos de la calidad, cobertura de patrones por parte de los lenguajes y tecnologías identificados, costos de desarrollo, aprovisionamiento y mantenimiento, limitaciones tecnológicas, riesgos, capacidades de los usuarios finales, entre otros.
Evalúa las alternativas de solución teniendo en cuenta los criterios seleccionados y métodos para la toma de decisiones (Ejemplos: Tormenta de ideas, espina de pescado, diagrama de campo de fuerza, entre otros) con el objetivo de seleccionar las soluciones aplicables al producto.
Para la concepción inicial del proyecto, se evalúan alternativas de soluciones aplicables para seleccionar la propuesta técnica inicial a un alto nivel de abstracción.
Como parte de la elaboración y refinamiento de la arquitectura, se identifican nuevas alternativas de soluciones a partir de la evaluación de las nuevas propuestas de solución aplicables con el objetivo de refinar la arquitectura.
A partir del nivel Avanzado se define el estilo arquitectónico estándar y la plataforma tecnológica a utilizar para desarrollar los activos de dominios para la familia.
Se obtiene como resultado de la ejecución de esta actividad el “Documento de toma de decisiones” / Evaluación (actualizado) y la “Arquitectura del sistema” (actualizado) o “Estudio de factibilidad” (actualizado).
Actividad 4: Hacer análisis hacer /reutilizar/adquirir.
El Comité técnico / Arquitecto teniendo en cuenta los componentes del producto identificados en la “Oferta” / “Proyecto técnico” o el documento de “Arquitectura del sistema”:
Determina los criterios de factibilidad para realizar el análisis de si hacer, reutilizar o adquirir los componentes del producto identificados (Ejemplos de criterios: tiempo, recursos, esfuerzo, costos, entre otros).
A partir del análisis realizado, identifica los componentes que serán desarrollados.
Se obtiene como resultado de la ejecución de esta actividad el “Documento de toma de decisiones” / Análisis de los componentes de la solución que se van a hacer/reutilizar/adquirir (actualizado) y la “Arquitectura del sistema” (actualizado) o “Oferta” / “Proyecto técnico” (actualizado).
Actividad 5: Evaluar propuesta de reutilización.
En el nivel Avanzado el Comité técnico / Arquitecto a partir de los activos de dominio existentes en la “Biblioteca de activos reutilizables” (Modelo de dominio o Arquitectura de dominio), el “Documento de toma de decisiones” / análisis hacer/reutilizar/adquirir (actualizado) y el dominio de aplicación al que estará dirigido el desarrollo del nuevo producto:
Evalúan los activos reutilizables que formarán parte del proyecto, para determinar el esfuerzo de adopción, modificación de los activos de dominios existentes o la necesidad de crear un nuevo activo de dominio.
Determina los activos de dominios que se adoptarán como parte de la solución, los que serán modificados y si es necesario, los que serán desarrollado como nuevos activos de dominio.
En el caso de los componentes que requieren modificación, se identifican los elementos a variar a partir de la Arquitectura de dominio y las peculiaridades del proyecto específico.
Se obtiene como resultado de la ejecución de esta actividad el “Documento de toma de decisiones” (actualizado), la “Arquitectura del sistema” (actualizado) y la “Arquitectura de dominio” (actualizado).
3.3 Sistema de indicadores
Para poder brindar al personal de un proyecto y a la dirección de una organización una visión objetiva del proceso de Diseño del producto, se hace necesario contar con un sistema de indicadores de procesos para que a partir del análisis de resultados históricos permita conocer el avance alcanzado, así como identificar las dificultades que surjan para la mejora del proceso desarrollado. A continuación se muestra un sistema de indicadores que tributan al rendimiento de los procesos.
Indicador 1: Eficacia del proceso
El objetivo del indicador es analizar la eficacia del proceso Diseño del producto donde las medidas base son las siguientes:
AE: Cantidad de actividades del proceso ejecutadas. AP: Cantidad de actividades del proceso planificadas.
CAP: Cantidad de artefactos del procesos planificados.
ARE: Cantidad de artefactos del proceso realizados.
CIE: Cantidad de inconsistencias encontradas con el diseño.
CIC: Cantidad de inconsistencias corregidas con el diseño.
CRP: Cantidad de requisitos arquitectónicamente significativos planificados.
CRD: Cantidad de requisitos arquitectónicamente significativos cubiertos en el diseño.
Medidas Derivadas:
ICA: Índice del cumplimiento de las actividades del proceso.
IRA: Índice de la realización de artefactos. IDR: Índice en el desarrollo de los requisitos. ICR: Índice de cumplimiento de requisitos. EP: Eficacia del proceso.
IDR: Índice en el desarrollo de los requisitos.
ICR: Índice de cumplimiento de requisitos.
EP: Eficacia del proceso.
Cada medida derivada anteriormente descrita puede tomarse como un indicador por separado y ser analizada una vez sea aplicada la propuesta para comprobar la mejoría que el proceso permitió introducir.
Indicador 2: Tiempo dedicado al diseño del producto
El objetivo del indicador es compara el tiempo dedicado a la actividad de diseño para comprobar su disminución mediante la aplicación los procesos definidos.
X = T
Donde T es el tiempo dedicado a la actividad de diseño.
Se realiza un análisis entre proyectos que han aplicado el proceso definido para comprobar la mejoría basada en datos históricos.
Indicador 3: Tasa de defectos.
El objetivo del indicador es comprobar la disminución de la tasa de defectos asociados a los requisitos arquitectónicamente significativos teniendo en cuenta datos históricos.
Donde:
ND: Cantidad de defectos encontrados.
LC: Líneas de código.
Se realiza un análisis teniendo en cuenta la reducción de los defectos una vez aplicada la propuesta. De acuerdo con la norma ISO/IEC 25023:2017 [25] que propone medidas para la calidad del producto, se identificaron algunas medidas en las que la propuesta puede influir directamente y que se pueden tomar como referencia para mejorar el producto y, por consiguiente, el proceso de diseño del mismo.
Vale resaltar que la correcta ejecución del proceso de diseño va a implicar que todos los productos que se generen a partir de esta arquitectura de dominio cumplan con los atributos de la calidad definidos.
Indicador 4: Indicadores del producto. Acoplamiento de componentes.
El objetivo del indicador analizar la fortaleza que poseen los componentes independientes y cuántos componentes son libres de los impactos de cambios a otros componentes en un sistema o programa de computadora.
Donde:
A = Número de componentes que se implementan sin impacto en otros.
B = Número de componentes especificados que deben ser independientes.
Indicador 5: Indicadores del producto. Reutilización de activos.
El objetivo del indicador es determinar cuántos activos de un sistema se pueden reutilizar (los activos podrían ser productos de trabajo tales como documentos de requisitos, módulos de código fuente, módulos de prueba y hardware específico, etc.).
Donde:
A = Número de activos diseñados e implementados para ser reutilizables.
B = Número de activos en un sistema.
Indicador 6: Indicadores del producto. Eficiencia de la modificación.
El objetivo del indicador es determinar qué tan eficientes son las modificaciones hechas en comparación con el tiempo esperado
Ai= Tiempo de trabajo total dedicado a realizar un tipo específico de modificación i.
Bi = Tiempo esperado para realizar el tipo específico de modificación i (puede basarse en datos históricos o en tiempo medio de la industria).
n = Número de modificaciones medidas.