Capítulo I

DE POR AUE LA NORMALIZACIÓN ES T]NAFT]ENTE PARA LA IN\¿ESTIGACIÓN EN

CALIDADDE SOFTWARE,LAORGANIIZACIÓN DEL DESARROIIO DENORNIAS Y SUS ACTORES PRINCIPALES

Peter HodgsonJuan Garbajosa

1.1 INTRODUCCIÓNRedactar el primer capítulo de un libro que recoge lo más avanzado de la

investigación en calidad del software es, sin duda, un honor para sus autores. Quedicho primer capítulo trate de normalización puede, para algunos, resultar

chocante. Así que dedicaremos algunos comentarios iniciales al porqué de lanormalización.

En muchos ámbitos de científicos, tecnológicos e industriales la norma-

lización es una base que permite el desarrollo y la inter-operatividad entre otras

muchas cosas. En dominio de los objetos materiales nadie cuestiona que un tubo

debe ajustarse a un diámetro normalizado y que un cable debe ser clasificado por

su revestimiento. En el dominio de lo intangible, las actuales redes globales de

comunicación serían inconcebibles sin la existencia de protocolos normalizados.

Pese a esta realidad, en el mundo del software y de la investigación a veces se

plantea que eso de normalizar es algo que se puede y se debe hacer después. ¡puessí!

Si las nuevas tecnologías resultantes de la investigación llegan a difundirseen la sociedad, sin dud_a gue habrá que normalizarlos-. Aunque sólo sea paraproteger la propia sociedad. Pero es igualmente cierto que la investigación tieneque partir de las normas' Aunque sólo sea con el sano propósito de criñcarlas. ¿porqué?

+6 CALIDAD DEL PRODUCTO Y PROCESO SOFTWARE ORA.MA

Al menos por los siguientes motivos:

Las normas proveen un vocabulario común. pocos dominios son tancapaces de generar neologismos como las tecnologías de la información yla ingeniería del software. Muchos de estos neologismos serán simplesardides de marketing, los que merezca' consideración acabaránr""ogido.en distintas nonnas. La precisión terminológica es una exigen"iu d.eualquier proceso de investigación que se precie.

Las normas recogen el consenso der conocimiento de un dominio. Lasnoñnas se redactan, revisan y aprueban por comités de expertos (o, almenos, interesados) en el dominio. Es más, la mayoriaio.-u, ,onaprobadas previa información pública. En consecuencia las noÍnas son unbuen punto de parlida pata empezar a conocer el estado de la técnica undominio determinado

Las normas implican habitualmente el conocimiento consolidado prove-niente de la experiencia industrial. sin embargo, a veces reflejandirectamente resultados de investigación. Esto rro

"r hubit ral en muchos

dominios pero sí se da en electrónica y, recientemente, en ingeniería deservicios e ingeniería web.

Las normas establecen categorías de objetos a evaluar. La calidad delsoftware nos acerca a la evaluación de algo que, en sí, es intangible. Losposibles acercamientos son múltiples, ,cubren aspectos de recursos,producto, proceso e incluso las propias herramierÍas producción. Lasnoñnas tipifican muchos de estos objetos facilitando, máÁ que un diálogointeligible, un marco estructurado de referencia donde encajar nuestroobjeto de estudio.

Las normas definen unidades de medida. Este motivo apenas requiereexplicación. objetos medidos con varas distintas ,ro ,on directamentecomparables. La cantidad de recursos desperdiciados en ingenieria para

ORA-MA CAPÍTULO 1.ISO.ESTÁNDARES 47

armonizar diversas unidades de medidas sólo es superada por la necesidad

de la Unión Europea de publicar todos sus actos en múltiples idiomas.

Las normas facilitan la trasferencia de tecnología. Los estándares son el

último eslabón en la cadena de desarrollo de conocimiento, antes de aplicarsistemáticamente una práctica. Desde ese punto de vista se pueden considerar una

forma de facilitarla transferencia de tecnología.

Visto que tanto la normativa como la investigación en calidad de software

pueden beneficiarse de su conocimiento mutuo. Este capítulo viene a exponer el

estado actual de la normalización desde un punto de vista genérico. Seguirán

capítulos redactados por miembros del WG6 del ISO-IEC JTC1 SC7 Ingeniería de

Software y Sistemas tratando aspectos específicos de la nueva serie de noñnas

SQuaRe que, como verán rápidamente, inciden directamente en la temática de este

libro.

§ota: En los párrafos anteriores sólo hemos mencionados algunos motivospor los que es impofiante la normativapara la investigación. Desde el punto de

vista de la creación o producción de software habría que añadir muchos aspectos

adicionales. Entre otros: evitar reinventar la rueda al especificar un producto ocrear bases comunes de entendimiento en el equipo de desanollo.]

1.2 ¿QUÉ SON LAS I\ORMAS Y QUIÉNES LASELABORAN? .i.

Conforme a la Real Academia Española una nonna es una "regla que se

debe seguir o a que se deben ajustar las conductas, tareas, actividades, etc." LJna

definición amplia a que se ajustan tantos las nornas y especificaciones

empresariales como los reglamentos de la administración pública. Las noÍnasindustriales que nos ocupan en esta sección se ajustan a la definición pero tienen

una serie de características adicionales que las distinguen y favorecen su difusión yuso.

La característica más evidente es que tienen apellido. Son normas {.INE,

DIN, IEEE, ISO,... Lo que viene a decir que son organizadas, elaboradas ymantenidas por entidades de reconocido prestigio. La entidad de normalizaciónespañola por excelencia es AENOR, corresponsal de la mayoría de laorganizaciones internacionales de normalización y fuente de las normas IINE. La

normalización europea corre de mano de CEN y CENELEC y la normalizaciÍninternacional tiende a mayor dispersión temática pero ISO, IEC, ETSI e ITU-T son

48 CAIIDAD DEL PRODUCTO Y PROCESO SOFTWARE ORA-MA

actores destacados. Por fortuna en el campo de las tecnologías de la información,desde 1987, ISO e IEC trabajan de forma conjunta a través del JTCI.

§ota: Aunque el nombre suene a película de de espías, JTC1 InformationTechnology significa simplemente, comité técnico conjunto número 1. Fue elprimero en crearse en 1987 y, de hecho, es el único comité conjunto de ISo e IEC.]

Estas normas con apellido se elaboran de forma colectiva por todas laspartes interesadas, se adoptan por consenso tras información pública y se aplicanpor la industria y los agentes económicos de forma voluntaria. Al igual que suaplicación, el esfuerzo de su elaboración también tiene carácter de esfuerzovoluntario. Los beneñcios que obtiene una organización o empresa de la existenciade una norna común deben exceder con creces el coste de las horas de dedicaciónde sus expertos a su redacción.

según el ámbito de normalización, el acceso a la participación es más omenos corñplejo. ISO por ejemplo está compuesto por entidades de normalizaciónnacionales. Para participar en un grupo de trabajo de ISO se necesita generalmentela acreditación por parte de una entidad nacional. Como los representantesnacionales no son diplomático sino técnicos expertos en el asunto objeto denonnalización; los grupos de trabajo intemacionales suelen llegar al consensosuficiente para su propósito. Lo que, algunas veces, da lugar a cierto grado deconflicto entre dichos representantes y sus organizaciones nacionales.

En cuanto al acceso a \a participación a nivel nacional, en el caso deAENOR, hipotéticamente, un grupo de trabajo podría rechazar la inclusión denuevos miembros. Que yo sepa, nunca se ha dado el caso, al menos en el ámbito dela ingeniería del software.

Hemos dicho que la adopción de la normas es voluntaria. No ha tenidolugar en el campo de la ingeniería del software pero, la administración frecuente-mente convierte las normas industriales en obligatorias por referencia en sureglamentación. Esto da lugar a una anomalía legislativa. Para conocer partes de lalegislación técnica (documento público), hay que comprar nornas, en el casoespañol, a AENOR (documento privado). La solución a este problema seríasencilla pero su discusión cae fuera de los objetivos de este capítulo.

§ota: Los párrafos anteriores describen el proceso de normalización conun criterio algo optimista. Si el lector prefiere una visión más crítica, lo remito alartículo "Cuatro mitos del proceso de normalización industrial".

O RA.MA CAPITULO 1. ISO, ESTANDARES 49

(http ://ictnet. es I 2007 I cuatro-mito s- del-proceso-de-normalizacion-indush'ial).1

1.3 NORM ALIZACTÓX EN CALIDAD DE SOFTWARELa calidad de software es de risa. Por supuesto no suscribimos esta

sentencia, pero también está claro que hay mucho camino que recorrer hasta lograrla satisfacción del cliente o el usuario final. La calidad, sea de software o decualquier otra cosa, requiere una visión integral. Algo bueno sólo en parte, no es

muy satisfactorio. La percepción de calidad en la experiencia de uso del softwareno depende sólo del producto. El entorno (sistema) en que se ejecuta es igual dedeterminante. A su vez,la calidad del producto software es función de los procesosque lo han generado y la calidad del sistema función de su buen gobierno.

En consecuencia, en los párrafos siguientes la expresión calidad desoftware, es genérica y pretende tocar el abanico de visiones del tema. Hablemosde normas y nornalización de ingeniería de software y la calidad.

Aunque muchas de las normas más relevantes parala calidad del softwarese pueden obtener en castellano, sin apenas excepciones, proceden todas de latraducción y adopción de normas ISO e ISO/IEC, redactados originalmente eninglés. Esto no significa que se hayan producido sin participación española, dehecho hay varios españoles activos como editores y líderes de grupos de trabajo anivel internacional. Más bien indica el carácter global de la industria del software.

'J

En los siguientes párrafos se resume la organización actual de lanormalización en el seno del SC7 del JTC1 de ISO/IEC. Como a través de los añosla organización se va adaptando a la demanda cambiante, puede ser convenienteconsultar la web de ISO (http://www.iso.ch) para verificar este contenido. EIsecretariado actual del SC7 mantiene una web (http://wwwjtcl-sc7.org/) quetambién es de interés.

El subcomité 7, Ingeniería de software y sistemas, del comité técnicoconjunto 1, Tecnologiadela información, de ISO e IEC; SC7 para abreviar, en laactualidad es presidido por Frangois Coallier. El secretariado recae en WitoldSuryn que, al igual que el presidente, es de la Escuela de Tecnología Superior de

Quebec. A1 margen de la actividad de la presidencia y el secretariado, el SC7 se

organiza en: grupos de trabajo, grupos de trabajo especiales, grupos consultivos,grupos de enlace y grupos de estudio. En líneas generales, los grupos de trabajo se

encargan de la redacción de las normas y su mantenimiento, los grupos de trabajoespeciales se encargan de la planificación y gestión de normas dentro del propioSC7, los grupos consultivos sirven de apoyo a la labor de la presidencia, los grupos

50 CALIDAD DEL PRODUCTO Y PROCESO SOFTWARE ORA-MA

de enlace se encargan de la comunicación con otras entidades y comités denormalizacióir y los grupos de estudio de la investigación de nuevas áreas detrabajo.

como el producto del sc7 son no[nas, nos interesa considerar en mayordetalle los grupos de trabajo del subcomité. según el último informe de lapresidencia del SC7, hay 16 grupos activos. (La web de ISo, en el momento deescribir, sólo describe 12.)La lista siguiente resume sus ámbitos.

Grupos de trabajo, JTC1 SC7:

o WG2, Documentación,

o WG4, Herramientas CASE,

o WG6, Evaluación de productos software y métricas

. WG7, Gestión del ciclo de vida,

. WGl0, Evaluación de procesos,

o WG19, Sistemas de proceso distribuido,

¡ WG20, Profesionalizaciíny corpus de conocimiento,

¡ WG21, Gestión de activos,

. WG22, Vocabulario,

¡ WG23, Gestión de la calidad,

o WG24,Ciclo de vidaparamicro PYME

o WG25, Gestión de servicios,

o WG26, Pruebas,

. WG42, Arquitectura,

. WGIA, Gobemanza de las TI

o JWG-ISO/TC159/SC4, Formatos comunes para Usabilidad.

ORA-MA CAPÍTULO 1. ISO, ESTÁNDARES 51

Sería lógico suponer que la mayor parte de la labor de normas relativas a lacalidad recae en el WG23. No obstante la suposición es errónea, el WG23 esresponsable de la UNE-ISO/IEC 90003, Guía de aplicación de la ISO 900i:2000 alsoftware, pero no de la mayoría de las nornas referidas a calidad, de software. Éstasson competencia, en general, del WG6.

Siendo así no ha de sorprender que los autores de los siguientes capítulospertenezcan al WG6.

1.4 ¿QUE NORMAS DEPENDEN DE WG6?Históricamente dependen del WG6 la serie de normas ISO/IEC 9126 de

Calidad de Producto (la primera parte, Modelo de Calidad, está publlcada comononna LINE), la serie de normas LINE-ISOIEC 14598 de Evaluación del productosoftware y una serie de normas sueltas. En el año 2005 se aprobó una noñna quepretendía crear un marco común para todas las normas producidas por este grupode trabajo, la norma ISO/IEC 25000, Software engineering - Software productQuality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE.

La norma 25000 además de establecer un vocabulario base ordena eldesarrollo de serie de normas conforme al siguiente gráfico que aparece en elprefacio de cualquier noÍna de la serie.

Qq§l&Rqguircr*em&

Ei\¡i§i#r

l§üütn

gssEe

§ir'¡**§an

I§{&l.x

üuaÉituhdslt*n*¡mamf Fl8tvieii¿:*r

¿t0$m

Figura 1.1. Organisation ofSquire Series ofstandars

52 CALIDAD DEL PRODUCTO Y PROCESO SOFTWARE ORA.MA

Hasta la fecha se han aprobado la siguiente serie noÍnas dentro de este

marco:

o ISO/IEC 25000:2005, Software product Quality Requirements andEvaluation (SQuaRE)

¡ ISO/IEC 25001,'2007 ... Planning and management

o ISOIIEC 25012:2008 ... Data quality model

r ISO/IEC 25A20:2007 ... Measurement reference model and guide

o ISO/IEC TR 25021:2007 ... Quality measure elements

¡ ISO/IEC 25030:20A7 ... Quality requirements

. t§OnBC 25051:2006,... Requirements for quality of Commercial Off-The-Shelf (COTS) software product and instructions for testing

o ISO/IEC 25062:2006... Common Industry Format (CIF) for usability testreports

Y están en desarrollo:

o ISOAEC 25010 ... Quality model

o ISO/IEC 25040 ... Evaluation reference model and guide

o ISOIIEC 25A45 ... Evaluation Module for Recoverability

r ISO/IEC 25060 ... Common Industry Format (CIF) for Usabil§ --General Framework for Usability-related Information

Si era la voluntad del WG6 tener un marco único de referencia para toda suactividad de normalización, en parte se habrá visto frustrada. El grupo de habajo se

ha hecho cargo además desde el 2008 de las noÍnas del disuelto grupo de trabajoWG12. Medida del tamaño firncional.

Conforme a lo que hemos antes, el trabajo del WG6 no agota todo elcampo de la calidad en referencia al software. Al margen del ya mencionado UNE--ISO/IEC 90003, quedan las normas que abordan aspectos de calidad de los ciclosde vida, de la evaluación de procesos (por ejemplo la serie conocida como SPICE,

ORA-MA CAPÍTULO l.ISO,ESTÁNDARES 53

responsabilidad de Viicl0), de los servicios y las normas referidas a pruebas que

saldrán del trabajo del WG26.

En los próximos capítulos se presentarán algunas de las norrnas del grupo

WG6 y su estado actual.