Experiencias en la Industria del Software:

Certificación del Producto con ISO/IEC 25000

Moisés Rodríguez1, Mario Piattini

2

1 Alarcos Quality Center, Universidad de Castilla-La Mancha, Ciudad Real, España.

moises.rodriguez@alarcosqualitycenter.com 2 Instituto de Tecnologías y Sistemas de la Información, Universidad de Castilla-La Mancha,

Ciudad Real, España.

mario.piattini@uclm.es

Abstract. La calidad del software está adquiriendo gran importancia durante los

últimos años, debido principalmente a que el software se encuentra presente en

todo lo que nos rodea: sanidad, banca, transporte, investigación, ocio, etc. Para

poder controlar la calidad del software es necesario llevar a cabo evaluaciones

del mismo, que inicialmente comenzaron realizándose sobre los procesos de de-

sarrollo y que ahora también se centran en las características del propio produc-

to software con normas como la familia ISO/IEC 25000. Sin embargo, este tipo

de evaluaciones se encuentra todavía en un estado incipiente y no se ha exten-

dido en el sector del software un certificado que asegure la calidad del produc-

to. En este artículo se presenta un conjunto de experiencias que se han llevado a

cabo en la industria del software, con casos reales de evaluación y certificación

de productos, así como el ecosistema de entidades que han participado en este

proceso.

Keywords: ISO/IEC 25000, calidad producto software, ecosistema de certifica-

ción, mantenibilidad, funcionalidad, laboratorio de evaluación.

1 Introducción

Durante los últimos años el software ha pasado a formar parte de prácticamente todos

los ámbitos de nuestra vida, dejando de estar presente solo en los ordenadores o sis-

temas de cómputo, para mejorar nuestros viajes, comunicación, sanidad, educación,

banca, seguros, ocio, etc. Este aumento en la demanda de productos software ha dado

lugar a un crecimiento del número de empresas y departamentos encargados de su

desarrollo, lo que se conocen como fábricas de software o “software factories” [1], así

como a un aumento en la necesidad de personas con los conocimientos necesarios

para el diseño, desarrollo, implantación y mantenimiento de dicho software. La falta

de personal especializado para ciertas tareas del desarrollo software, así como la

búsqueda constante de la reducción de costes por el actual ambiente económico inter-

nacional, han dado lugar a lo que se conoce como “outsourcing” del desarrollo soft-

ware, de manera que las empresas externalizan todo o parte de las actividades de de-

sarrollo software a otros departamentos o empresas.

Sin embargo, cuando se externaliza todo o parte del desarrollo de un producto,

también aumentan los riesgos y la falta de control sobre la calidad del software que la

empresa contratada entrega, surgiendo la necesidad de evaluar y asegurar la calidad

del software externalizado.

La evaluación de la calidad del software es un campo de gran actividad tanto inves-

tigadora como en el sector industrial desde hace varias décadas, habiéndose desarro-

llado gran cantidad de modelos y estándares de referencia, evaluación y mejora de

procesos de desarrollo software, entre los que se pueden citar: ISO 90003, ISO/IEC

12207, ISO/IEC 15504, CMM, CMMI, IDEAL, SCAMPI, etc. y en los que numero-

sas empresas de todo el mundo se han evaluado y/o certificado [2, 3]. Sin embargo,

hay poca evidencia de que cumplir un modelo de procesos asegure la calidad del pro-

ducto software resultante, y aunque la estandarización de los procesos garantiza la

uniformidad en la salida de los mismos, podría llegar a darse el caso de que institu-

cionalizara la creación de malos productos [4]. En este sentido, nosotros estamos de

acuerdo con que las evaluaciones deberían basarse en evidencias directas del propio

producto, y no solo en evidencias del proceso de desarrollo [5]. Por ello, es cada día

mayor el número de organizaciones y empresas que se interesan, no solo por la cali-

dad de los procesos que se siguen en el desarrollo de software, sino también por la

calidad de los productos que desarrollan y/o adquieren, ya que una vez que el produc-

to ha sido implantado en sus instalaciones se encuentran con graves problemas de

calidad y dificultades para corregirlo, adaptarlo o evolucionarlo.

En los últimos años se han elaborado también trabajos de investigación, normas y

estándares, con el objetivo de crear modelos, procesos y herramientas de evaluación

de la calidad del propio producto software, entre los que se pueden destacar los pre-

sentados en [6, 7, 8, 9]. Precisamente para dar respuesta a estas necesidades nace la

nueva familia de normas ISO/IEC 25000 conocida como SQuaRE (Software Product

Quality Requirements and Evaluation), que tiene por objetivo la creación de un marco

de trabajo común para evaluar la calidad del producto software, sustituyendo a las

anteriores ISO/IEC 9126 e ISO/IEC 14598 y convirtiéndose así en el referente para la

evaluación de la calidad del producto software [10]. La familia ISO/IEC 25000 se

encuentra compuesta de varias partes o divisiones, entre las que podemos destacar:

La norma ISO/IEC 25010:2011 [11] que define un modelo de calidad del producto

software con las características que se pueden evaluar (Fig. 1). En total son 8 las

características de calidad identificadas: funcionalidad, rendimiento, compatibili-

dad, usabilidad, fiabilidad, seguridad, mantenibilidad y portabilidad. Esta norma

define también un modelo para calidad en uso, pero queda fuera del alcance del

presente artículo cuyo objetivo son las evaluaciones del producto antes de que este

sea puesto en producción y sea utilizado por el usuario.

La norma ISO/IEC 25040:2011 [12] que define el proceso de evaluación de la

calidad del producto software, y está compuesta por cinco:

─ Establecer los requisitos: para determinar cuáles son los requisitos de calidad

que se deben considerar a la hora de evaluar el producto.

─ Especificar la evaluación: indicando las métricas, criterios de medición y de

evaluación a tener en cuenta.

─ Diseñar la evaluación: definiendo el plan de actividades que se realizarán.

─ Ejecutar la evaluación: realizando las actividades de medición y evaluación del

producto, considerando los criterios identificados en las fases previas.

─ Concluir la evaluación: elaborando el informe de evaluación y realizando la dis-

posición de resultados e ítems de trabajo.

La norma ISO/IEC DIS 25023 [13] que será la encargada de definir las métricas de

calidad del producto software y que todavía está siendo elaborada. Por ello, no

existe todavía un acuerdo respecto a los indicadores y umbrales que se deben utili-

zar para determinar la calidad de un producto software de manera estandarizada.

Fig. 1. Modelo de calidad del producto software ISO/IEC 25010:2011

Sin embargo, los modelos y normas anteriores relacionadas con la evaluación de la

calidad del producto software, no tratan el proceso posterior de la certificación, que

permita a las empresas superar una auditoría realizada por una entidad acreditada y

obtener un certificado que refleje la calidad del producto software. Por tanto, la certi-

ficación de la calidad del producto software sigue siendo a día de hoy un área novedo-

sa y de gran interés, en la que todavía no existe un consenso definitivo.

Por todo lo anterior, durante los últimos años hemos trabajado en la construcción

de un Ecosistema para la Evaluación y Certificación de la Calidad del Producto Soft-

ware (en adelante el ecosistema), siendo el objetivo principal del presente artículo

explicar las características del mismo y mostrar los resultados obtenidos tras la certi-

ficación de los primeros productos software. Para ello, el resto del artículo se estructu-

ra de la siguiente manera: en el apartado 2 se presentan los principales requisitos y

dificultades que se deben considerar a la hora de evaluar y certificar la calidad del

producto software. En el apartado 3 se describe el ecosistema, identificando las prin-

cipales entidades que lo integran, así como las relaciones que se establecen entre am-

bas y las necesidades de participación de cada una. En el apartado 4 se presenta cómo

se lleva a cabo el proceso de evaluación y certificación del producto y los resultados

que se han obtenido tras los primeros casos prácticos. Y finalmente, el apartado 5

presenta las conclusiones obtenidas con este trabajo y las líneas futuras de trabajo e

investigación.

2 Requisitos y dificultades para la evaluación y certificación del

producto software

Con el objetivo de conocer los trabajos existentes sobre certificación de la calidad del

producto software, durante nuestra investigación realizamos una revisión sistemática

detallada en [14] siguiendo la guía propuesta por Kitchenham en [15]. Como resulta-

do se obtuvo un conjunto de 10 estudios que cumplían con los requisitos de búsqueda:

[16, 17, 18, 19, 20, 21, 22, 23, 24, 25]. A partir de los análisis realizados sobre la

información extraída de los estudios, se obtuvieron las siguientes conclusiones:

La mayoría de los estudios destacan el trabajo que ya existe en la certificación de

procesos de desarrollo software y la necesidad de que esta certificación sea tam-

bién extendida a las características del producto, para poder asegurar que el resul-

tado final cumple con los requisitos establecidos.

La mayoría de los estudios se basan en certificar características de calidad extraí-

das de normas internacionales como la ISO/IEC 9126, utilizando métodos de eva-

luación también estándares como los de la ISO/IEC 14598. Sin embargo, ninguna

de las propuestas ha adoptado el nuevo modelo y proceso propuestos por la familia

ISO/IEC 25000, probablemente debido a la novedad de este.

Aunque ya existen varias propuestas para certificar el producto software, la mayor-

ía de ellas carece o tiene un número reducido de aplicaciones reales en la industria

del software, lo que se considera vital a la hora de poder extender su aceptación a

nivel internacional y poder contrastar los niveles obtenidos por diferentes produc-

tos software.

La mayoría de los estudios utiliza indistintamente los conceptos de evaluación y

certificación, lo que se considera un error. Es necesario diferenciar entre el proceso

de evaluación, realizado frente a un modelo de calidad. Y el posterior proceso de

certificación realizado por un organismo acreditado e independiente que asegure la

validez del certificado emitido. En este sentido se echa en falta que los estudios no

hagan referencia a que el proceso de certificación se haga siguiendo los requisitos

de un estándar internacional.

Un denominador común de los estudios que presentan casos de aplicación práctica

es la importancia que atribuyen a disponer de un entorno tecnológico que automa-

tice las actividades. La mayoría carecen de él y se plantean como trabajo futuro

abordar su construcción para que les permita medir, procesar los datos y analizar

los resultados de una manera más rápida y sencilla.

A partir de todo lo anterior, se pueden extraer los requisitos principales para poder

llevar a cabo la evaluación y certificación de la calidad del producto software, que

además de personal experimentado, se pueden concretar en los siguientes tres elemen-

tos: un modelo de calidad, un proceso de evaluación y un entorno tecnológico que de

soporte a los dos elementos anteriores.

2.1 Un modelo de calidad

El objetivo del modelo es definir las características del producto software que se pue-

den evaluar y que por tanto influyen en la calidad del mismo, es decir, el modelo deja

claro los puntos de vista desde los que se puede considerar la calidad de un producto

software. Es importante remarcar que el modelo define el qué evaluar (características

de calidad), pero no el cómo evaluarlas. Aspectos como la funcionalidad que tiene un

producto, la usabilidad, la seguridad o la mantenibilidad del producto software podr-

ían ser algunos de estos tipos de características.

Es importante que el modelo no solo defina las características de calidad, sino que

también desglose éstas en subcaracterísticas de más bajo nivel y a su vez estas en

indicadores y métricas que se puedan medir a partir de los elementos del producto

software. El modelo también debe identificar, si es que existen, las relaciones entre

las características de calidad del producto. De manera que podamos saber si mejorar

una característica supone mejorar a su vez otra, o si por el contrario una mejora en

una característica supone una pérdida en otra de dichas características.

Y probablemente la parte más complicada a la hora de definir el modelo de cali-

dad, es disponer de unos umbrales contrastados y validados que reflejen el valor de

calidad que se quiere alcanzar, es decir, por ejemplo cómo saber si cuando decimos

que un producto tiene un 4% de código duplicado, eso es bueno o malo y cómo de

bueno o malo es.

Como se ha comentado anteriormente, la nueva familia de normas ISO/IEC 25000

contempla un modelo para la calidad del producto software que define las caracterís-

ticas y subcaracterísticas de calidad que se pueden medir. La dificultad es que esta

familia de normas no determina un conjunto concreto de indicadores, métricas y um-

brales que puedan ser tomados por las organizaciones como referente a la hora de

evaluar y poder certificar la calidad de sus productos.

2.2 Un proceso de evaluación

El objetivo del proceso de evaluación es definir las actividades que se deben realizar

para poder llevar a cabo la evaluación de la calidad del producto software. Es impor-

tante remarcar que el proceso de evaluación define el cómo evaluar, pero no el qué

evaluar, que como veíamos antes estaba definido por el modelo.

El proceso de evaluación suele iniciarse por la selección de las partes del producto

software que se van a evaluar: el código fuente, los requisitos, los modelos, los casos

de pruebas, el producto en ejecución, etc. podrían ser algunos de los ejemplos de par-

tes del producto software que se pueden evaluar. Además, durante el proceso se debe

también identificar qué características se van a evaluar. Características de calidad que

se han definido previamente en un modelo de calidad como hemos visto en el aparta-

do anterior, de ahí la relación entre el proceso de evaluación y el modelo de calidad.

El proceso de evaluación debe definir el conjunto de pasos que el evaluador debe

seguir, identificar las herramientas que se utilizarán, así como identificar qué personas

participarán en la evaluación y cuáles serán las actividades en las que participarán.

El objetivo último del proceso de evaluación es generar un informe con los resulta-

dos obtenidos, asegurando que dicho informe sea completo, repetible y legible para el

público objetivo del mismo.

La ISO/IEC 25040:2011 también define un proceso de evaluación muy completo,

cuyas actividades se han enumerado en la introducción del presente artículo. Aquí la

dificultad es que este proceso no está preparado para la certificación del producto

software, sino solo para la parte de evaluación. Por tanto es necesario complementarlo

con otro conjunto de pasos.

2.3 Un entorno tecnológico de soporte a la evaluación

El objetivo del entorno tecnológico es precisamente el de asistir al proceso de evalua-

ción y a la recolección de las métricas y umbrales definidos en el modelo de calidad.

Las herramientas que forman este tipo de entornos sirven para facilitar la obtención

de los datos, ya sea parseando automáticamente el producto software o permitiendo al

evaluador introducir los datos de una manera amigable. Estas herramientas deben

poder también automatizar los algoritmos de medición, de manera que a partir de las

métricas base que se hayan tomado, se puedan ir escalando dichos valores para obte-

ner los indicadores de calidad. Además, estas herramientas también deben permitir

presentar los resultados de una manera entendible dependiendo el público objetivo de

los mismos.

Dentro de este tipo de herramientas hay que diferenciar aquellas que realizan me-

dición de la calidad del producto software, obteniendo métricas de bajo nivel e indi-

cadores. De aquellas herramientas que evalúan la calidad del producto software, esca-

lando las métricas anteriores para dar una valoración de las subcaracterísticas y carac-

terísticas de calidad del modelo. De aquí la relación también entre el modelo y el

entorno tecnológico.

Aunque hoy en día existen ya en el mercado muchas herramientas de este tipo [26],

todavía no existe ninguna que esté alineada a un modelo de calidad que siga la familia

ISO/IEC 25000, de ahí la dificultad para poder elegir una que se adapte a las necesi-

dades de una organización que quiera certificar la calidad de sus productos.

Una vez detallados los requisitos necesarios para la evaluación y certificación del

producto y vistas las dificultades de las propuestas existentes, en el siguiente apartado

se presenta el ecosistema creado y las soluciones adoptadas.

3 Ecosistema para la evaluación y certificación del producto

La certificación, entendida como la evaluación por una entidad independiente y acre-

ditada para llevar a cabo auditorías de producto software, es un ámbito que hasta aho-

ra no está contemplado por la familia de normas ISO/IEC 25000 y que sin embargo,

es de gran interés para los desarrolladores y/o adquisidores de producto software, ya

que les permitiría identificar rápidamente la calidad de un producto software de una

manera estandarizada.

Por esta razón, AENOR (Asociación Española de Normalización y Certificación)1

y el laboratorio de evaluación de la calidad del producto software AQC Lab2, han

elaborado una certificación basada en la familia de normas ISO/IEC 25000. Dadas las

dificultades vistas en el apartado anterior para evaluar la calidad del producto en base

a la ISO/IEC 25000, junto con la novedad de esta nueva certificación y por tanto el

desconocimiento del sector sobre las necesidades para su implantación, se ha empe-

zado a construir lo que se ha denominado como Ecosistema para la Evaluación y Cer-

tificación de la Calidad del Producto Software, con el objetivo de resolver las dificul-

tades expuestas e identificar todas las entidades que deben participar en el proceso

que permita obtener un certificado para el producto software.

El ecosistema está formado inicialmente por las siguientes entidades (Fig. 2):

1. Organizaciones que quieren certificar la calidad del producto. Estas organiza-

ciones pueden ser tanto empresas desarrolladoras de software (de cualquier domi-

nio), como entidades que han externalizado sus desarrollos o directamente adquie-

ren un producto software, independientemente del propósito del mismo. Esta enti-

dad es el elemento central del ecosistema y su interés por la calidad del producto es

el que motiva precisamente la evaluación y certificación del mismo.

2. Organismo certificador acreditado. En este caso dicho organismo es AENOR,

quién tiene la experiencia de más de 20 años realizando auditorías de calidad de

productos en otros sectores y que desde 2006 viene desarrollando un modelo para

gobierno de las TIC basado en normas ISO [27], en el que recientemente ha inclui-

do la propia norma ISO/IEC 25000 para llevar a cabo este tipo de auditorías de ca-

lidad del producto software. Para ello, AENOR ha desarrollado un reglamento in-

terno de certificación del producto, de manera que a partir de un informe de eva-

luación emitido por un laboratorio acreditado y de una auditoría en las instalacio-

nes de la empresa desarrolladora del producto, está en disposición de emitir un cer-

tificado sobre el nivel de calidad del mismo. Gracias a esta entidad del ecosistema,

se complementa el proceso de evaluación, solucionando la dificultad que se identi-

ficaba anteriormente por la falta de un proceso de certificación.

3. Laboratorio acreditado para la evaluación de la calidad del producto. En este

caso dicha entidad del ecosistema es AQC Lab. Una de las necesidades que se

identificaron inicialmente para poder evaluar la calidad del producto software, fue

disponer de una entidad externa capaz de emitir una evaluación independiente so-

bre el producto software. Con esta idea, en 2009 comienza la construcción de AQC

Lab, un laboratorio que basado en la familia ISO/IEC 25000 permita, tanto a em-

presas desarrolladoras de software como a entidades que externalizan o adquieren

software, disponer de un informe independiente que refleje la calidad del producto

software. Con el objetivo de obtener un reconocimiento a la validez de las evalua-

ciones realizadas por AQC Lab, se decidió elaborar toda la infraestructura de ges-

tión necesaria para conseguir la acreditación, siguiendo además para ello prácticas

del desarrollo ágil como se expone en [28]. El resultado fue que en 2012 AQC Lab

conseguía la acreditación de ENAC (Entidad Nacional de Acreditación) en la nor-

1 www.aenor.es 2 www.alarcosqualitycenter.com/index.php/aqc-lab

ma ISO/IEC 17025 [29], como el primer laboratorio para la evaluación de la cali-

dad de aplicaciones software bajo la familia de normas ISO/IEC 25000. La acredi-

tación de acuerdo a la norma ISO/IEC 17025 confirma la competencia técnica del

laboratorio y garantiza la fiabilidad en los resultados de los ensayos realizados.

AQC Lab cuenta con los tres requisitos principales identificados anteriormente y

que se han detallado previamente en [30]:

─ Un Proceso de Evaluación, que adopta directamente la norma ISO/IEC

25040:2011, y la completa con los roles concretos del laboratorio y los procedi-

mientos de trabajo desarrollados.

─ Un Modelo de Calidad, que define las características, métricas y umbrales para

evaluar el producto software, complementando así la norma ISO/IEC 25010:2011.

─ Un Entorno tecnológico propio, formado por varios niveles de herramientas que

permiten automatizar en gran medida las tareas de medición y evaluación del pro-

ducto.

Gracias a esta entidad del ecosistema, se ha solucionado la dificultad de contar con

un modelo de calidad del producto detallado hasta las métricas y umbrales, así co-

mo de disponer de un laboratorio acreditado para la emisión de informes de eva-

luación sobre el producto software, que son la entrada al proceso de certificación.

4. Consultores expertos en calidad de software. Antes de que las empresas puedan

presentarse a una evaluación y certificación oficial, es necesario que cuenten con el

apoyo y soporte a la mejora de sus productos ofrecido por consultores (internos o

externos) que les permita controlar la calidad del producto a lo largo de todo el ci-

clo de vida y afrontar la certificación con garantías. Gracias a esta entidad del eco-

sistema, se soluciona la dificultad de contar con personal con experiencia para po-

der asegurar la calidad del producto software.

Fig. 2. Ecosistema para la Evaluación y Certificación de la Calidad del Producto Software

5. Empresas desarrolladoras de herramientas para la medición del producto

software. A su vez, tanto el laboratorio de evaluación como los consultores exper-

tos en calidad, necesitan de soporte al proceso mediante herramientas de medición.

Por ello, son necesarias empresas que desarrollen este tipo de herramientas y que

alineen las mismas a las mediciones y umbrales que después serán objeto de eva-

luación y certificación. Entre este tipo de herramientas se puede destacar Kiuwan3,

que ya ha comenzado a alinear sus mediciones al modelo de calidad del laboratorio

AQC Lab, u otras de software libre como SonarQube4. Gracias a este tipo de enti-

dades en el ecosistema, se solucionan las necesidades de contar con entornos tec-

nológicos que den soporte a la medición y la evaluación del producto.

De esta manera, por medio de estas herramientas, estos expertos en calidad software,

del laboratorio AQC Lab y de AENOR, las empresas pueden evaluar, mejorar y certi-

ficar la calidad de sus productos software aplicando la familia ISO/IEC 25000, con-

formándose así el primer ecosistema completo para llevar a cabo este proceso.

4 Proceso de evaluación y certificación del producto software

El proceso de evaluación y certificación del producto software consta de los seis

pasos que se pueden observar en la Fig. 3:

1. El proceso comienza cuando la organización interesada en la calidad del producto

software solicita una evaluación al laboratorio acreditado AQC Lab. Para ello debe

rellenar un formulario con las características del producto software que se quiere

evaluar, que es analizado por el laboratorio para emitir un contrato de evaluación

con las condiciones del servicio.

Fig. 3. Proceso de Evaluación y Certificación del Producto Software

3 www.kiuwan.com 4 http://www.sonarqube.org/

Aceptado este contrato, la organización hace entrega al laboratorio del producto

software a evaluar. A partir de aquí, AQC Lab haciendo uso del entorno basado en

ISO/IEC 25000 y acreditado por ENAC (modelo, proceso y herramientas) detalla-

do en [30], realiza la evaluación. Este proceso suele tener una duración estimada de

2-3 semanas, dependiendo de las características del producto bajo evaluación.

2. El resultado del paso anterior es un informe de evaluación con los resultados obte-

nidos, que es entregado a la organización solicitante. En este paso, puede ocurrir

que el nivel de calidad obtenido por el producto software no sea suficientemente

bueno, en cuyo caso la organización solicitante, apoyada por los consultores exper-

tos del ecosistema, deberán refactorizar el producto para mejorar el nivel de cali-

dad. En este caso, el tiempo que puede transcurrir dependerá el número de defectos

que se deben solucionar y de la cantidad de recursos que la organización pueda de-

dicar para tal fin. Una vez refactorizado el producto, la organización deberá repetir

el paso 1 del proceso para volver a obtener un informe de evaluación favorable.

3. Cuando el producto software ha obtenido en la evaluación un nivel de calidad fa-

vorable, la organización podrá contactar con AENOR solicitando la certificación

del producto e indicando la referencia previa de la evaluación que ha pasado reali-

zada por un laboratorio acreditado.

4. AENOR contactará con AQC Lab para solicitar los resultados de la evaluación con

la referencia indicada por la organización solicitante.

5. AQC Lab, como laboratorio colaborador, revisará sus registros de evaluación y fa-

cilitará dicha información a AENOR.

6. Finalmente AENOR, analizará el informe de evaluación facilitado por el laborato-

rio y realizará una visita a la organización solicitante para, siguiendo con su regla-

mento interno de auditoría definido para el producto software, revisar el producto y

las características del mismo. Como resultado de este proceso de auditoría de certi-

ficación, AENOR emitirá un informe y entregará a la organización un certificado

que acredite la calidad del producto software evaluado. Este informe identifica en-

tre otros a la organización solicitante, el producto certificado y su versión concreta,

las características de calidad del modelo evaluadas y el informe del laboratorio

acreditado que recoge los resultados de evaluación sobre los que se soporta el certi-

ficado emitido.

Gracias al ecosistema y a este proceso de evaluación y certificación, son varias las

empresas que han presentado sus productos a la evaluación, algunas de las cuales han

trabajado además en la refactorización de mejora y han conseguido posteriormente

una certificación de su producto. El listado actualizado de productos que han alcanza-

do la certificación se puede encontrar en la página web de iso250005. Tomando como

muestra las empresas que han realizado el ciclo completo hasta la certificación, po-

demos observar los resultados de la Tabla 1, donde por confidencialidad se ha identi-

ficado con “Px” a cada uno de los productos y con “Vx” a las versiones concretas de

dichos productos que se han presentado al proceso. Analizando estos datos se pueden

extraer las siguientes conclusiones:

5 www.iso25000.com/

Todos los productos tuvieron que pasar dos evaluaciones de AQC Lab. En la pri-

mera (V1) detectaron todas las deficiencias, después tuvieron que mejorar el pro-

ducto, y finalmente en la segunda evaluación (V2) obtuvieron un nivel favorable

que les permitió pasar al siguiente paso del proceso de la Fig. 3 (la certificación).

La versión V1 de todos los Px presentados al proceso se encuentra en un nivel 2 o

inferior (en una escala donde el 1 representa el nivel más bajo de calidad y el 5 el

nivel máximo). Esto indica que hasta ahora la mayoría de empresas no sigue un

proceso durante su desarrollo que permita asegurar la calidad del propio producto.

De ahí la necesidad de las entidades 4 y 5 del ecosistema, que permiten que el pro-

ducto se vaya desarrollando con calidad desde el inicio.

El nivel de calidad bajo obtenido inicialmente en las evaluaciones de los productos

ha sido la causa de que otras empresas no hayan seguido el proceso de certifica-

ción, por el coste que supone arreglar un producto software al final de su ciclo de

desarrollo.

Solo un producto ha conseguido el máximo nivel (5) para la característica de man-

tenibilidad, lo que supone tener todas las características con valores superiores al

95% de calidad. El resto de empresas buscan tener un nivel 4 o 3 que son los nece-

sarios para poder obtener el certificado de AENOR.

La subcaracterística que más cuesta mejorar es la de Analizabilidad, puesto que

según la Tabla 1, es en la que las empresas tienen un menor margen de mejora. Es-

to es debido a que es la característica que tiene más propiedades y reglas de codifi-

cación a cumplir por el producto software. Mientras que la subcaracterística que las

empresas corrigen con menor esfuerzo y por tanto mejoran más fácilmente es la

capacidad de ser modificado, ya que tras la mejora todos los productos superaron el

valor 92 (en una escala donde el 0 representa el valor más bajo de calidad y el 100

el valor máximo).

Tabla 1. Resultados de los primeros productos certificados

P1V1 P1V2 P2V1 P2V2 P3V1 P3V2 P4V1 P4V2

Mantenibilidad 2 5 2 4 2 4 2 3

Analizabilidad 41.67 98.44 18.75 80.36 37.5 85.71 41.67 68.75

Modularidad 43.75 100.0 37.5 81.25 43.75 85.42 68.75 68.75

Capacidad de

Ser Modificado 43.75 100.0 37.5 92.5 37.5 100.0 43.75 97.5

Capacidad de

Ser Reutilizado 46.88 100.0 37.5 82.5 16.67 97.5 46.88 62.5

Capacidad de

Ser Probado 43.75 100.0 20.0 82.14 37.5 85.71 43.75 68.75

Por otro lado, entre las empresas que han certificado hasta ahora alguno de sus

productos software se pueden destacar los siguientes beneficios obtenidos [31]:

Se ha conseguido reducir hasta un 75% las incidencias de mantenimiento correcti-

vo del producto software.

Se ha simplificado hasta en un 45% la complejidad del producto.

En algún caso se ha reducido hasta un 30% los tiempos de mantenimiento.

Varios productos han reducido las líneas de código hasta en un 40%.

Y además, varias empresas han conseguido establecer la trazabilidad entre la cali-

dad de sus procesos con normas como ISO/IEC 15504, con la calidad del producto

software con la familia de normas ISO/IEC 25000.

5 Conclusiones y trabajo futuro

La calidad del producto software es una de las principales preocupaciones tanto para

las empresas desarrolladoras, como para los organismos que los adquieren. Existen

varias propuestas para evaluar la calidad del producto software, algunas de ellas reco-

gidas en normas como la ISO/IEC 25000. Sin embargo dichas propuestas presentan

una serie de dificultades a la hora de aplicarlas en la práctica y de extenderlas a un

proceso que permita certificar la calidad del producto.

El presente artículo ha presentado una solución a estas dificultades, consistente en

un ecosistema completo para la evaluación y certificación de la calidad del producto,

que identifica todas las entidades participantes en el proceso y las tareas que realiza

cada una. Gracias a este ecosistema se han conseguido realizar los primeros proyectos

de evaluación y certificación de la calidad, inicialmente centrados en la característica

de la mantenibilidad del producto, que han permitido a las empresas detectar el nivel

de calidad de partida y realizar las mejoras necesarias.

Para ampliar este ecosistema, actualmente se sigue trabajando en varias líneas:

Ampliar la certificación a nuevas características, habiéndose realizado ya los pri-

meros proyectos piloto de evaluación, centrados en las características de usabilidad

y de adecuación funcional [32].

Ampliar la evaluación a más lenguajes de programación como Cobol, Ruby o

PL/SQL. Aunque las métricas son por norma general independientes del lenguaje,

las herramientas de medición sí suelen depender del mismo.

Extender el ecosistema para ampliar el número de entidades certificadoras, labora-

torios acreditados, consultores expertos y de herramientas de medición que lo co-

nozcan y se alineen a los requisitos de la certificación, permitiendo estandarizar y

homogeneizar este tipo de evaluaciones.

Agradecimientos. Esta investigación forma parte de los proyectos ECU: Evaluación

y Certificación del Producto Software (Consejería de Empleo y Economía y FEDER,

1313CALT0056), GEODAS-BC (Ministerio de Economía y Competitividad y

FEDER, TIN2012-37493-C03-01), SDGear (Ministerio de Industria, Energía y Tu-

rismo dentro del Plan Nacional de Investigación Científica, Desarrollo e Innovación

Tecnológica 2013-2016 y Fondo Europeo de Desarrollo Regional FEDER, TSI-

100104-2014-4) y GLOBALIA (Referencia: PEII11-0291-5274 Consejería de Educa-

ción, Ciencia y Cultura (JCCM) y Fondo Europeo de Desarrollo Regional FEDER.

Referencias

1. Piattini, M.G.,Garzás, J., Fábricas de software: experiencias, tecnologías y organización

(2ª edición actualizada). 2010, Paracuellos del Jarama (Madrid): RA-MA.

2. CMMI-Institute, Maturity Profile Report (January 2007 - March 2014). 2014, Carnegie

Mellon.

3. Garzás, J., Pino, F., Piattini, M., Fernández, C.M., A maturity model for the Spanish

software industry based on ISO standards. Computer Standards & Interfaces, 2012. 35(6):

p. 616–628.

4. Kitchenham, B.,Pfleeger, S.L., Software Quality: The Elusive Target. IEEE Software,

1996. 20(1): p. 12-21.

5. Maibaum, T.,Wassyng, A., A Product-Focused Approach to Software Certification.

Computer, 2008. 41(2): p. 91-93.

6. McCall, J.,Walters, G., Factors in Software Quality. 1977, Springfield, VA, USA: The

National Technical Information Service.

7. Boehm, B., Characteristics of Software Quality. 1978: North Holland Press.

8. ISO, ISO/IEC Standard 9126 Software Product Evaluation–Quality Characteristics and

Guidelines for their Use 2001, International Organization for Standardization.

9. ISO, ISO/IEC 14598-5:1998 - Information technology -- Software product evaluation --

Part 5: Process for evaluators. 1998, International Organization for Standardization:

Ginebra.

10. Piattini, M., García, F., García, N., Pino, F., Calidad de Sistemas de Información. 3 ed.

2015, Madrid: Ra-Ma.

11. ISO, ISO/IEC 25010, Systems and software engineering - Systems and software Quality

Requirements and Evaluation (SQuaRE) - System and software quality models. 2011:

Ginebra, Suiza.

12. ISO, ISO/IEC 25040 Systems and software engineering - Systems and software Quality

Requirements and Evaluation (SQuaRE) - Evaluation process. 2011: Ginebra, Suiza.

13. ISO, ISO/IEC DIS 25023. Systems and software engineering -- Systems and software

Quality Requirements and Evaluation (SQuaRE) -- Measurement of system and software

product quality. 2015.

14. Rodríguez, M.,Piattini, M., Systematic review of software product certification, in CISTI

2012: 7th Iberian Conference on Information Systems and Technologies. 2012: Madrid. p.

631-636.

15. Kitchenham, B., Guideline for performing Systematic Literature Reviews in Software

Engineering. Version 2.3. 2007, University of Keele (Software Engineering Group, School

of Computer Science and Mathematics) and Durham (Department of Computer Science).

16. Heck, P., Klabbers, M., van Eekelen, M., A software product certification model. Software

Quality Journal, 2009. 18(1): p. 37-55.

17. Carvalho, F., Meira, S.R.L., Freitas, B., Eulino, J., Embedded software component quality

and certification. Conference Proceedings of the EUROMICRO, 2009: p. 420-427.

18. Burger, E.,Reussner, R., Performance certification of software components. Electronic

Notes in Theoretical Computer Science, 2011. 279(2): p. 33-41.

19. Serebrenik, A., Mishra, A., Delissen, T., Klabbers, M., Requirements certification for

offshoring using LSPCM. Proceedings - 7th International Conference on the Quality of

Information and Communications Technology, QUATIC 2010, 2010: p. 177-182.

20. Yahaya, J.H., Deraman, A., Hamdan, A.R., SCfM_PROD: A software product certification

model. 2008 3rd International Conference on Information and Communication

Technologies: From Theory to Applications, ICTTA, 2008.

21. Yahaya, J., Deraman, A., Hamdan, A.R., Continuously ensuring quality through software

product certification: A case study. 2010 International Conference on Information Society,

i-Society 2010, 2010: p. 183-188.

22. Hatcliff, J., Heimdahl, M., Lawford, M., Maibaum, T., Wassyng, A., Wurden, F., A

Software Certification Consortium and its Top 9 Hurdles. Electronic Notes in Theoretical

Computer Science, 2009. 238(4): p. 11-17.

23. Morris, J., Lee, G., Parker, K., Bundell, G.A., Lam, C.P., Software component

certification. Computer, 2001. 34(9): p. 30-36.

24. Baggen, R., Correia, J.P., Schill, K., Visser, J., Standardized code quality benchmarking

for improving software maintainability. Software Quality Journal, 2012. 20(2): p. 287-307

25. Alvaro, A., De Almeida, E.S., Meira, S.L., Towards a software component certification

framework. Proceedings - International Conference on Quality Software, 2007: p. 298-303.

26. Tomas, P., Escalona, M.J., Mejias, M., Open source tools for measuring the Internal

Quality of Java software products. A survey. Computer Standards & Interfaces, 2013(36):

p. 244-255.

27. Fernández, C.M.,Piattini, M., Modelo para el Gobierno de las TIC basado en normas ISO.

2ª ed. 2015, Madrid: AENOR.

28. Verdugo, J., Rodríguez, M., Piattinni, M., Using Agile Methods to Implement a Laboratory

for Software Product Quality Evaluation, in 15th International Conference on Agile

Software Development (XP 2014). 2014: Roma (Italia).

29. ISO, ISO/IEC 17025:2005. General requirements for the competence of testing and

calibration laboratories. 2005, International Organization for Standardization.

30. Rodríguez, M.,Piattini, M., Entorno para la Evaluación y Certificación de la Calidad del

Producto Software, in XIX Jornadas de Ingeniería del Software y Bases de Datos

JISBD’2014. 2014: Cadiz. p. 163-176.

31. Rodríguez, M., Fernández, C.M., Piattini, M., ISO/IEC 25000 Calidad del Producto

Software. AENOR. Revista de la Normalización y la Certificación, 2013(288): p. 30-35.

32. Rodriguez, M., Oviedo, J.R., Piattini, M., Evaluation of Software Product Functional

Suitability: A Case Study, in Submitted to ICEIS 2015: 17th International Conference on

Enterprise Information Systems. 2015: Barcelona, Spain