· Instituto Nacional de Tecnologías de la Comunicación. Edición: Abril 2008 . La presente publicación pertenece a . Instituto Nacional de Tecnologías de la Comunicación (INTEC

Instituto Nacionalde Tecnologías de la Comunicación

Estudio sobre la certificación de la calidad del software en España Página 1 de 147

Estudio sobre la certificación de la calidad como medio para impulsar la industria de desarrollo del software en España

Observatorio de la Seguridad de la Información Laboratorio Nacional de Calidad del Software

OBSERVATORIO DE LA SEGURIDAD DE LA INFORMACIÓN LABORATORIO NACIONAL DE CALIDAD DEL SOFTWARE


Edición: Abril 2008

La presente publicación pertenece a Instituto Nacional de Tecnologías de la Comunicación (INTECO) y está bajo una licencia Reconocimiento-No comercial 2.5 España de Creative Commons, y por ello esta permitido copiar, distribuir y comunicar públicamente esta obra bajo las condiciones siguientes:

• Reconocimiento: El contenido de este informe se puede reproducir total o parcialmente por terceros, citando su procedencia y haciendo referencia expresa tanto a INTECO como a su sitio web: www.inteco.es. Dicho reconocimiento no podrá en ningún caso sugerir que INTECO presta apoyo a dicho tercero o apoya el uso que hace de su obra.

• Uso No Comercial: El material original y los trabajos derivados pueden ser distribuidos, copiados y exhibidos mientras su uso no tenga fines comerciales.

Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia de esta obra. Alguna de estas condiciones puede no aplicarse si se obtiene el permiso de INTECO como titular de los derechos de autor. Nada en esta licencia menoscaba o restringe los derechos morales de INTECO.

Texto completo de la licencia: http://creativecommons.org/licenses/by-nc/2.5/es/

Estudio sobre la certificación de la calidad del software en España Página 2 de 147 Observatorio de la Seguridad de la Información Laboratorio Nacional de Calidad del Software

http://creativecommons.org/licenses/by-nc/2.5/es/


INDICE DE CONTENIDO

INDICE DE CONTENIDO......................................................................................................3

PUNTOS CLAVE...................................................................................................................7

1.1 ................................................................................................7 Situación del sector

1.2 .........................................................................8 La visión de la empresa española

1.3 ...........................................................................9 Iniciativas orientadas a la PYME

1.4 ................................................11 El impulso del mercado mediante la certificación

2 ..........................................................................................................14 INTRODUCCIÓN

2.1 ........................................................................................................15 Presentación

2.1.1 ...............................15 El Instituto Nacional de Tecnologías de la Comunicación

2.1.2 ..........................................15 El Observatorio de la Seguridad de la Información

2.1.3 .............................................16 El Laboratorio Nacional de Calidad del Software

2.2 ........................................................................................18 Descripción del estudio

2.3 .........................................................................................................19 Metodología

2.3.1 .....................................................19 Fase de recopilación y estudio de informes

2.3.2 ...................................................................20 Fase de realización de entrevistas

3 ........................................................................................................................24

NORMAS, MODELOS Y CERTIFICACIONES ORIENTADAS A LA CALIDAD DEL SOFTWARE

3.1 .........................................................................................................24 Introducción

3.1.1 ................................................................26 Orientación a la mejora del proceso

3.1.2 ...............................................................27 Orientación a la mejora del producto

3.2 ..................................................................................28 Certificación y acreditación

3.3 ......30 Normas, modelos y certificaciones más importantes orientadas a procesos

3.3.1 ..........................................................................................................30 ISO 9000



3.3.2 ..................................................34 CMMI (Capability Maturity Model Integration)

3.3.3 ..............................................................................................................44

ISO/IEC 15504 (SPICE, Software Process Improvement and Capability dEtermination)

3.3.4 ..............................................................................................................47 ITMark

3.3.5 ............................................................................................................48 SwTQM

3.3.6 ...............................................................................................................54 TickIT

3.3.7 ..........................................................................55 ITIL (IT Infrastructure Library)

3.3.8 .................................................................57 PSP (Personal Software Proccess)

3.3.9 .................................................................................................59 ISO/IEC 20000

3.4 ..................................61 Normas, modelos y certificaciones orientadas al producto

3.4.1 .........................................................................................................61 TPI/TMAP

3.4.2 ..........................................................................64 ISO 9126 (Modelo de McCall)

3.5 ............................................................................66 Otros modelos y metodologías

3.5.1 .................................................................................66 Metodología MÉTRICA 3

3.5.2 .............................................................................................67 Metodología RUP

3.5.3 ...................................................................69 Metodología Six Sigma (6-Sigma)

3.5.4 .............................................................................................71 Metodología MSF

3.5.5 .................................................................................................72 Métodos ágiles

3.6 ........................................................................................74 Herramientas de apoyo

3.6.1 ...................................................................................75 IBM - Rational Software

3.6.2 ........................................................................77 Borland OPEN ALM - Gauntlet

3.6.3 .................................................78 Microsoft Visual Studio Team System - VSTS

3.6.4 ...............................................................................78 Herramientas de Telelogic

3.6.5 .....................................................................79 IrqA – Integral requisite analyzer



3.6.6 .......................................................................................................79 Subversion

4 ...............80 LA CERTIFICACIÓN DE LA CALIDAD EN LAS EMPRESAS ESPAÑOLAS

4.1 ...............................................................82 Características especiales de la PYME

4.2 ................................................................................84 La visión hacia el extranjero

4.3 .....................................85 La visión de las empresas hacia los modelos existentes

4.4 .......90 Situación de la PYME y la micropyme frente al mercado de la certificación

4.5 ...............................92 Aplicabilidad de los modelos a la PYME y la microempresa

4.5.1 ................................................................................94 Iniciativas en el extranjero

4.5.2 .....................................................................................101 Iniciativas en España

4.5.3 103

Resumen y comparación de las iniciativas para las PYME y microempresas

4.6 .......................................................105 Experiencias de implantación en las PYME

4.6.1 ..................................................................................108 El caso de PROCONSI

4.7 ..........................................................115 La experiencia de las grandes empresas

4.7.1 ...............................................................................116 El caso de ACCENTURE

4.7.2 .................................................................................117 El caso de SOLUZIONA

4.8 ............................................................................................117 La visión del cliente

4.9 .....................................................................................................................120

La necesidad real de las empresas españolas y el papel de los agentes intermedios

4.9.1 ..............................................................126 El caso de la Junta de Extremadura

5 ..............130 INICIATIVAS PARA EL IMPULSO DEL DESARROLLO DEL SOFTWARE

5.1 .................................132 Elección del modelo adecuado según el tipo de empresa

5.2 ..........136 Iniciativas en el extranjero sobre la calidad como impulso a la empresa

5.2.1 ..........................................................................................136 Comisión Europea

5.2.2 ..............................................................................................................138 BrasilEstudio sobre la certificación de la calidad del software en España Página 5 de 147 Observatorio de la Seguridad de la Información Laboratorio Nacional de Calidad del Software


5.2.3 ........................................................................................................140 Argentina

5.2.4 ............................................................................................................143 México

ÍNDICE DE TABLAS..........................................................................................................145

ÍNDICE DE GRÁFICOS.....................................................................................................146




PUNTOS CLAVE

En un mundo en que la informática y los sistemas de información se han convertido en una pieza fundamental en cualquier empresa, la adquisición de software paquetizado o hecho a medida es un mercado que crece año a año. La cantidad de empresas dedicadas al desarrollo de software, por lógica, sigue esta progresión basada en la demanda, y este crecimiento lleva implícito la búsqueda constante de métodos de diferenciación en el mercado. De esta forma, el sector del desarrollo de software español ha experimentado un alza del 8 por ciento en 2006 para situarse en unas cifras de facturación global de cerca de 1.600 millones de facturación. Este sector, con aproximadamente 80.000 empleados, se compone en un 99,8% de PYME, de las que más del 85% son microempresas de menos de 10 empleados.

1.1 Situación del sector

Como paso previo a la situación de la certificación de la calidad del software en España, se ha realizado un análisis de los modelos, metodologías e iniciativas existentes en la actualidad, así como las tendencias en lo referente a nuevos modelos.

En este sentido, y como resultado del análisis, se han detectado dos grandes grupos de modelos:

• Modelos que persiguen la mejora de los procesos de producción de software (modelos orientados a procesos). En este grupo se han detectado CMMI e ISO 15504 como los más importantes a nivel mundial, con una especial preponderancia del primero, así como modelos más generalistas con su versión para desarrollo de software como puede ser EFQM y su variación SwTQM.

• Modelos que persiguen la mejora del producto final (modelo orientados a producto), como puede ser TPI o la norma ISO 9126. Desde el año 2000, además, los modelos ágiles han aparecido para facilitar la consecución de ese producto final mediante metodologías ligeras que se enfocan en la participación del cliente y las pruebas continuas para completar proyectos de desarrollo relativamente cortos.

Estas diversas orientaciones ensanchan el abanico de posibilidades de manera que tanto la microempresa como la pequeña y mediana empresa, o incluso las grandes empresas, pueden encontrar un modelo que se adapta a sus posibilidades y necesidades. Así pues, como conclusión a lo expuesto en este estudio, se ha determinado que tanto CMMI, en sus distintas versiones, como ISO/IEC 15504, son modelos orientados a grandes y medianas empresas. En cambio, los modelos ITMark y SwTQM son certificables y podrían



ser implementados en cualquier PYME; aunque ITMark, en concreto, se adaptaría mejor a la microempresa, dado que SwTQM no deja de ser una personalización para software del modelo EFQM para la PYME en general.

En microempresas, con un número de empleados mínimo, a las que puede aplicarse ITMark, se ha observado también como buena opción el uso de modelos orientados a la mejora del producto, como TPI, que únicamente se enfoca sobre las pruebas del software. Además, el uso de métodos ágiles como XP (eXtreme Programming) en este tipo de empresas (orientados al producto y a la satisfacción y confianza del cliente frente a otros factores en proyectos cortos) se destacan pese a su poca implantación en España frente a otros modelos o metodologías de desarrollo.

El soporte a estos modelos, en forma de herramientas y aplicaciones software, ha creado un amplio mercado de posibilidades. IBM y su marca Rational Software se destacan en las grandes empresas, mientras que la pequeña y mediana empresa adopta otros desarrollos comerciales o de código abierto, como los productos de Borland, Telelogic, o Microsoft.

1.2 La visión de la empresa española

Ante la posibilidad de implantar un modelo de mejora de procesos y someterse a su certificación, tanto la PYME como las grandes empresas de desarrollo entrevistadas en el transcurso del proyecto ven en Europa un referente. A esto contribuye que las PYME españolas han estado realizando en los últimos años un esfuerzo comercial importante orientado hacia la exportación, sobre todo en el marco de la UE. El 50% de las ventas de la PYME son realizadas en el extranjero, lo cual pone de manifiesto que se está asumiendo el reto de la globalización y la PYME española se encuentra ya enraizada en el entramado internacional.

En este marco de actuación la competencia se ha intensificado, y los datos indican que el esfuerzo realizado está siendo enorme por cuanto, a pesar de esa creciente competencia, han conseguido aumentar el número de unidades vendidas. Este esfuerzo lleva consigo un aumento implícito de la calidad de los productos desarrollados, y debe ser incrementado aún más. El reto principal, pues, es adaptarse a este nuevo contexto, en el que los modelos de calidad son parte importante en este crecimiento. Es por ello que la situación sobre el estado de los modelos y certificaciones de calidad en Europa, y su adopción por empresas fuera de nuestras fronteras, es seguida con detalle desde España.

Tanto por esta necesidad de ampliar mercados como por la percepción de avance en el continente, la percepción de la empresa española sobre los modelos existentes en el mercado, analizados durante este estudio, es que CMMI es un referente absoluto, seguido por SPICE (adoptado por ISO como estándar ISO/IEC 15504) y, con mayor o menor



implantación, otros modelos como SwTQM, ITMark, o las iniciativas que a nivel local surgen en mercados como el latinoamericano.

Esta visión de la totalidad del sector hacia CMMI como modelo absoluto de referencia (en el que calidad de desarrollo se asocia unívocamente a CMMI) hace que la atención se pierda frente a otros modelos que se adaptan mejor que aquél, por múltiples razones, a muchas de las empresas españolas. Por ello, mientras las grandes empresas pueden adoptar CMMI (ó ISO/IEC 15504) sin demasiados problemas, las barreras que éste presenta para una PYME en el momento de evaluar su adopción hacen que la PYME detenga sus iniciativas de mejora.

En este punto, como principales aspectos en contra de la adopción por parte de la PYME se han identificado los siguientes:

• Los altos costes que conlleva la adopción de estos modelos referentes, con respecto a los costes de las auditorías y certificaciones, costes en recursos humanos y formación, y los costes de adquisición de herramientas que los soporten, entre otros.

• Escepticismo ante los beneficios que puede aportar una certificación. A este respecto, que el ROI (retorno de inversión) sea calculable únicamente a medio y largo plazo no ayuda a tomar la decisión por parte de la dirección de una PYME.

• El cambio de filosofía de trabajo que implican los modelos y las metodologías que subyacen.

• El cambio de organización, casi obligado, así como la creación de un departamento o área de calidad y nuevas contrataciones o especialización de personal cualificado.

Pese a que existe un esfuerzo evidente de asociaciones empresariales y la administración pública a la hora de facilitar ayudas para la adopción de estos modelos, se ha observado que casi todas las iniciativas tienen como punto de referencia CMMI y se centran, sobre todo, en superar la barrera económica. Es por ello que se hace necesario un cambio de mentalidad evidente de forma que se asuman, por parte de la PYME española y la microempresa en general, otros modelos o iniciativas encaminadas en exclusiva a este tipo de empresas.

1.3 Iniciativas orientadas a la PYME

Como se deduce en el estudio, no es posible implementar cualquier tipo de modelo en cualquier tipo de empresa, puesto que la complejidad de algunos de ellos es excesiva por multitud de factores. Ante la problemática de CMMI como punto de referencia básico y la



falta de apoyo a otros modelos, una de las soluciones propuestas es la creación y apoyo por parte de la administración de un modelo reducido orientado expresamente a la PYME y la microempresa. En este sentido, se han identificado varias iniciativas nacionales e internacionales con relativo éxito, como en el caso de México, Brasil o Colombia. Además, los comités ISO están trabajando en una versión de ISO 15504 para la microempresa, y el SEI (Software Engineering Institute) hace lo propio con CMMI mediante experiencias en pruebas piloto. En el caso de España se han detectado dos importantes niciativas:

• La AEC (Asociación Española para la Calidad) está desarrollando un modelo basado en CMMI para PYME, aún no terminado.

• ESI (European Software Institute), a nivel privado, y basándose también en CMMI, ha puesto en el mercado ITMark como modelo para PYME con un relativo éxito.

Las iniciativas llevadas a cabo en España se basan en la creación de un modelo orientado a PYME, pero también como un paso previo a los modelos CMMI e ISO/IEC 15504. Así mismo, se centran en la mejora de los procesos (tal y como defienden estos dos modelos) como método de alcanzar la calidad, por lo que apenas se tienen en cuenta modelos orientados a producto.

Por su parte, el Gobierno de Aragón, en colaboración con ESI (European Software Institute), ha puesto en marcha un proyecto de certificación para PYME denominado SoftAragon, que certifica mediante un sello de calidad propio a aquellas empresas que adoptan una versión reducida de CMMI. En todo caso, las conclusiones del proyecto han venido a reforzar la idea de que existe la necesidad de métodos de desarrollo disciplinados en la PYME, además de reforzar la idea de que CMMI en su formato actual no es viable para su adopción e implementación en PYME, y que es importante disponer de un agente o entidad que dé soporte a la difusión y adopción de los modelos de calidad.

No obstante, existen casos de empresas que han decidido implantar CMMI como modelo de mejora de procesos a pesar de los aparentes inconvenientes. El plan COMPETIC, encuadrado dentro del Plan Avanza, ha facilitado ayudas para ello, y las empresas del sector que han sido recientemente evaluadas están plenamente satisfechas con el resultado tanto a nivel interno como externo. Reconocen como beneficios conseguidos la mejora general de sus procesos, optimizando tiempo y recursos; el mejor control sobre los proyectos abordados, gracias en parte a las herramientas que la metodología arrastra; más facilidad para el desarrollo de software y consecución del producto final; y una mejor imagen de la empresa de cara al exterior. En el desarrollo de este estudio se incluyen casos detallados de implantación.



1.4 El impulso del mercado mediante la certificación

Los datos presentados muestran una cantidad de iniciativas y casos de éxito que presagian optimismo frente al futuro de la certificación y su contribución a la mejora de los procesos internos y los productos de las empresas españolas. Teniendo presente además la visión del cliente comprador de software, los motivos fundamentales por los que una empresa debiera certificarse o adoptar al menos un modelo de calidad son los siguientes:

• Para las microempresas el motivo fundamental es el cambio de inercia de cara a la reducción de costes a medio-largo plazo, adoptando buenas prácticas de gestión de proyectos y de ciclo de vida del software, así como la disminución de las tasas de error gracias a nuevas prácticas de testing para minimizar los trabajos extra de garantía y mantenimiento.

• Para la PYME, pueden estar más presentes los requerimientos externos o, como en el caso de las microempresas, implantar la mejora por futuros ahorros de costes.

• Para las grandes empresas, los motivos para la implantación de estos modelos son principalmente los requerimientos de sus clientes y la iniciativa propia para control interno de costes, así como el marketing y elemento diferenciador de cara al exterior.

La primera conclusión extraída al respecto de la necesidad real en España es que, a priori, no existe un motivo de peso que impulse a una microempresa o PYME hacia la implantación de un modelo de mejora; cosa que se hace más evidente cuantas más pequeña es la empresa. En este punto, se hace necesaria la figura de un agente intermedio que debiera servir como ente que publicite y dé valor a las certificaciones de calidad ante clientes y empresas, que realizase las oportunas campañas de información dirigidas tanto a las empresas como a sus clientes.

En este sentido, y en consonancia con las conclusiones de SoftAragon, se aprecia la necesidad de que este agente intermedio además aglutine las iniciativas en el ámbito de la calidad y sirva de puente entre la PYME y las entidades normalizadoras, además de los organismos que respaldan la creación de estándares, normas y modelos.

Como conclusión, este agente intermedio debería:

• Identificar los modelos existentes para los diversos tipos y tamaños de empresas, seleccionando aquellos que mejor se adapten a cada tipo independientemente de que se puedan tratar de modelos orientados a la mejora de procesos o a la mejora del producto.



• Fomentar la creación y desarrollo, en caso de que los modelos fuesen insuficientes para algún tipo o tamaño de empresa, de modelos adecuados a la idiosincrasia de cada uno de ellos.

• Promover y divulgar iniciativas que se deban llevar a cabo para difundir los modelos entre las empresas, como forma de dar a conocer las bondades y beneficios de cada uno de ellos para cada tipo de empresa identificada:

• Crear un directorio de contactos y un repositorio de información pública, al respecto de los agentes implicados en los esquemas de evaluación o certificación de cada modelo.

• Aglutinar y respaldar iniciativas de otras entidades, públicas o privadas, con el mismo fin.

• Gestionar, como punto único de información respaldado, reconocido y reconocible, la información referente a planes de futuro, subvenciones y/o créditos ofrecidos por entidades públicas o privadas para llevar acabo implantaciones de estos modelos.

• Servir como ente que publicite y dé valor a las certificaciones de calidad ante clientes y empresas.

• Realizar las oportunas campañas de información, por los métodos que se estimen necesarios, para hacer ver a los compradores de software en España de la necesidad de exigir productos con un sello de calidad.

• Realizar las oportunas campañas de información, por los métodos que se estimen necesarios, para hacer ver a las microempresas españolas de los beneficios reales de la implantación de modelos para la generación de productos bajo un sello de calidad.

La creación de un sello de calidad respaldado por este agente es una solución que garantizaría la respuesta ante las empresas y sus clientes, dotando al modelo o modelos elegidos de un mayor valor añadido, además de la propia mejora que para la empresa supone la implantación del modelo y por ende, la obtención del sello.

Los entrevistados en este estudio identifican a una entidad pública (como el INTECO) como el organismo que debería erigirse como agente impulsor de la certificación. En estos momentos, la administración ya es parte implicada en el proceso en varias vertientes:

• Convocatorias de subvenciones y otras ayudas (como las emprendidas a nivel nacional, dentro del Plan Avanza, iniciado por el Ministerio de Industria, Turismo y Comercio).



• Apoyo claro hacia modelos de mejora de procesos y productos, como modelos reducidos de CMMI o ISO/IEC 15504 (como el caso del gobierno de Aragón)

• Creación y respaldo de foros e iniciativas para difundir las bondades de las certificaciones hacia la empresa.

En menor medida, se otorga este papel a otras organizaciones intermedias como las asociaciones empresariales. Los datos aportados por los entrevistados sobre estas asociaciones hablan de ciertos factores como:

• Proximidad a la PYME, lo que las dota de una gran confianza desde el punto de vista de los asociados.

• Relación excelente con las administraciones públicas.

• Afán de mejora de sus asociados, punto expuesto tanto por los representantes de las asociaciones entrevistados como por las propias PYME.



2 INTRODUCCIÓN

La certificación de la calidad en el desarrollo de software ha adquirido una gran importancia en el mundo durante los últimos años. Continuamente surgen modelos e iniciativas que tratan de ofrecer a las organizaciones nuevas metodologías buscando la mejora en la calidad y la excelencia en sus productos. España no es ajena a esta tendencia que contribuirá a impulsar la industria de desarrollo del software en España.

El término “calidad”, tiene una definición ambigua al ser un concepto subjetivo que engloba multitud de factores y percepciones .No obstante, las normas y modelos internacionales ofrecen varias acepciones, basadas sobre todo en:

• Juran, 1970: La calidad es la “adaptabilidad de uso”, que implica dos parámetros: calidad de diseño y calidad de conformidad. En resumen, adaptable a las necesidades de los usuarios.

• Crosby, 1979: La calidad es la “conformidad con los requerimientos”.

Según el IEEE, la calidad del software debe ser mesurable y predecible, y debe incorporar varios factores básicos:

• Ausencia de defectos.

• Satisfacción del usuario.

• Conformidad con los requerimientos.

El factor inherente a la calidad es sin duda la ausencia de defectos. Usualmente se expresa de dos maneras:

• Tasa de defecto: mesurable según el número de defectos por cada 1000 líneas de código (KLOC), u otra unidad.

• Confiabilidad: mesurable según el número de fallos por “n” horas de operación o el tiempo medio entre fallos.

Según la norma “ISO 9126 Tecnologías de la Información – Calidad de los productos software”, las características de la calidad son portabilidad, eficiencia, confiabilidad, usabilidad, funcionalidad y mantenibilidad.

Otras empresas o entidades definen sus propios criterios de calidad, como el caso de IBM (funcionalidad, usabilidad, rendimiento, confiabilidad, instalación, mantenibilidad,


documentación/información, servicio y totalidad), o de Hewlett-Packard (funcionalidad, usabilidad, confiabilidad, rendimiento, servicio).

En el marco de estas definiciones, y teniendo estos parámetros como meta, muchos son los modelos que se han definido en el mercado de cara a la consecución de la calidad en sus múltiples acepciones. A lo largo de este capítulo se presentan los modelos, estándares y normas certificables más importantes en el mercado de la calidad, ofreciendo sus características más significativas como base para el análisis posterior.

2.1 Presentación

2.1.1 El Instituto Nacional de Tecnologías de la Comunicación

El Instituto Nacional de Tecnologías de la Comunicación (INTECO), sociedad estatal promovida por el Ministerio de Industria, Turismo y Comercio, es una plataforma para el desarrollo de la Sociedad del Conocimiento a través de proyectos del ámbito de la innovación y la tecnología.

Su objetivo es doble: por una parte, contribuir a la convergencia de España con Europa en la Sociedad de la Información y, de otra parte, promover el desarrollo regional, enraizando en León un proyecto con vocación global.

La misión de INTECO es impulsar y desarrollar proyectos de innovación relacionados con el sector de las Tecnologías de la Información y la Comunicación (TIC) y en general, en el ámbito de la Sociedad de la Información, que mejoren la posición de España y aporten competitividad, extendiendo sus capacidades tanto al entorno europeo como al latinoamericano. Así, el Instituto tiene la vocación de ser un centro de desarrollo de carácter innovador y de interés público a nivel nacional que constituirá una iniciativa enriquecedora y difusora de las nuevas tecnologías en España en clara sintonía con Europa.

El objeto social de INTECO es la gestión, asesoramiento, promoción y difusión de proyectos tecnológicos en el marco de la Sociedad de la Información. Para ello, INTECO desarrollará actuaciones, al menos, en líneas estratégicas de Seguridad Tecnológica, Accesibilidad, Innovación en soluciones TIC para la PYME, e-Salud, e-Democracia.

2.1.2 El Observatorio de la Seguridad de la Información

El Observatorio de la Seguridad de la Información se inserta dentro de la línea estratégica de actuación de INTECO en materia de Seguridad Tecnológica. El Observatorio nace con el objetivo de describir de manera detallada y sistemática el nivel de seguridad y confianza en la Sociedad de la Información y de generar conocimiento especializado en la materia.



De este modo, se encuentra al servicio de los ciudadanos, las empresas y las administraciones públicas españolas para describir, analizar, asesorar y difundir la cultura de la Seguridad de la Información y la e-Confianza.

El Observatorio ha diseñado un Plan de Actividades y Estudios con el objeto de generar conocimiento especializado y útil en materia de seguridad por parte de INTECO, así como de elaborar recomendaciones y propuestas que definan tendencias válidas para la toma de decisiones futuras por parte de los poderes públicos.

Dentro de este plan de acción se realizarán labores de investigación, análisis, estudio, asesoramiento y divulgación que atenderán, entre otras, a las siguientes estrategias:

• Elaboración de estudios e informes propios en materia de seguridad de las Tecnologías de la Información y la Comunicación, con especial énfasis en la Seguridad en Internet.

• Seguimiento de los principales indicadores y políticas públicas relacionadas con la seguridad de la información y la confianza en el ámbito nacional e internacional.

• Generación de una base de datos que permita el análisis y evaluación de la seguridad y la confianza con una perspectiva temporal.

• Impulso de proyectos de investigación en materia de seguridad TIC.

• Difusión de estudios e informes publicados por otras entidades y organismos nacionales e internacionales, así como de información sobre la actualidad nacional y europea en materia de la seguridad y confianza en la Sociedad de la Información.

• Asesoramiento a las Administraciones Públicas en materia de seguridad de la información y confianza, así como el apoyo a la elaboración, seguimiento y evaluación de políticas públicas en este ámbito.

2.1.3 El Laboratorio Nacional de Calidad del Software

INTECO a través de su Línea de Calidad del Software promueve estrategias en materia de calidad en la industria española del software así como el desarrollo y asentamiento de proyectos empresariales en España.

Las acciones relativas a la mejora de la calidad de software se apoyan en el Plan Avanza, aprobado por el Consejo de Ministros en noviembre de 2005, cuyo objetivo es conseguir que el volumen de la actividad económica relacionada con las tecnologías de la información se acerque al 7% del PIB en el año 2010. En la Sección relacionada con la medida “Mejora de la calidad del software” se establecen acciones complementarias que tendrán como objeto la promoción y difusión entre las empresas, en particular las PYME,



de modelos contrastados de calidad del software, en línea con el objetivo señalado en el Programa Nacional de Tecnologías Informáticas de conseguir una mejora significativa y mensurable de la calidad del software producido en España, innovando en los procesos de desarrollo de las empresas.

Por ello, INTECO tiene entre sus objetivos principales:

• El estudio y diagnóstico de la situación de partida, y el impacto que la calidad del software tiene en la competitividad del sector TIC.

• La puesta en marcha del Laboratorio Nacional de Calidad del Software.

• El impulso del proceso de creación de empresas TIC en regiones con escasa o nula tradición.

La misión del Laboratorio Nacional de Calidad del Software es la de promover estrategias de calidad en la industria española del Software y promover el desarrollo y asentamiento de proyectos empresariales en España. A tal fin se desarrollarán acciones encaminadas a:

• Promover la calidad de producto Software en los ámbitos de certificación a partir de acciones de apoyo y estructuración del mercado (consorcios y asociaciones empresariales e institucionales).

• Aportar un valor añadido a los procesos de certificación de calidad de producto introduciendo el consenso en el mercado TIC sobre la certificación de productos.

• Reforzar la visibilidad de la industria del Software en los mercados internacionales.

• Incrementar la capacitación de los desarrolladores del Software mediante cursos, herramientas y servicios de apoyo.

• Desarrollar servicios públicos destinados a PYMES y a usuarios finales de las TIC en materia de buenas prácticas de calidad.

• Establecer acciones permanentes de formación, sensibilización y prestación de servicios a empresas que faciliten el desarrollo de estrategias de calidad.

• Constituir un Centro Demostrador de Soluciones y Tecnologías al servicio de las empresas desarrolladoras, distribuidoras y consumidoras de software que prime la calidad coma elemento diferenciador del mercado español.



2.2 Descripción del estudio

De entre los nuevos retos a los que se enfrenta la Sociedad de la Información, cabe destacar el desarrollo de iniciativas para contribuir a un mayor crecimiento y facilidad de acceso a las nuevas tecnologías.

Ante esta situación y dentro de las funciones asignadas al Observatorio de la Seguridad de la Información de INTECO, ha puesto en marcha un “Estudio sobre Certificación de la calidad como medio para impulsar la industria de desarrollo de software en España”. En concreto, el proyecto consiste en la realización de un análisis sobre el estado de la calidad del software y las certificaciones existentes a nivel español para lograr un doble objetivo:

• Conocer la situación actual de la certificación de la calidad del software en España.

• Determinar la idoneidad de dicha certificación como medio para impulsar la industria de desarrollo de software a nivel nacional.

La ejecución del proyecto ha abordado diferentes fases de forma consecutiva, que se listan a continuación a modo de resumen:

• Recopilación y estudio de informes independientes relacionados con las tecnologías de la información, el desarrollo de software y con la certificación de la calidad en las empresas españolas.

• Realización de entrevistas a diferentes expertos relacionados con el mundo del desarrollo de software en España y, en concreto, con los modelos de mejora de procesos.

• Elaboración de un informe final con las conclusiones recabadas en las fases de recopilación de informes y realización de entrevistas que recoja la situación de la certificación de la calidad en las empresas españolas y las iniciativas para el impulso del desarrollo del software.

A partir de estas fases, que se describirán en el siguiente apartado, se pretende obtener conclusiones sobre cada uno de los aspectos relevantes para la consecución de las metas del Estudio:

• La situación actual en el mercado de la certificación, en el que se esbozan las líneas fundamentales del mercado actual de la certificación en España, así como el estado de la certificación de calidad en el resto del mundo.



• El estado de la certificación en España, en la que a nivel de empresa se aportan las experiencias de las empresas españolas en referencia a las prácticas de certificación.

• La certificación como impulso al desarrollo de software en España, en la que se presentan casos de éxito y se plantean iniciativas de futuro al respecto de la certificación de la calidad.

2.3 Metodología

En este apartado se analiza la metodología empleada de manera específica en cada una de las fases destinadas a la obtención de conclusiones para el Estudio.

2.3.1 Fase de recopilación y estudio de informes

Se han abordado el análisis de la situación actual de la empresa española en relación a la implantación de certificaciones sobre los procesos de desarrollo de software. Para ello, se han recopilado informes de organismos y asociaciones dedicadas al estudio de las tecnologías de la información y empresas dedicadas al desarrollo de software, a partir de los cuales se han extraído conclusiones que han conducido a conocer la situación actual del mercado global de la certificación, la situación de la empresa española, y las necesidades y carencias en la oferta de servicios. A partir de lo anterior, pueden deducirse las acciones a llevar a cabo para equiparar la pequeña y mediana empresa con las organizaciones de mayor tamaño en lo relativo al uso de certificaciones de calidad como elemento diferenciador.

Fuentes de información

Todos los informes referenciados en el presente estudio son propiedad de las siguientes entidades:

o Asociación Española para la Calidad

o Accenture

o AMR Research

o ATI (Asociación de Técnicos en Informática)

o Calidaddelsoftware.com

o Carleton University

o Deloitte

o ExpoQA

o Forrester

o IEEE

o INTECO

o ISACA (Information Systems Audit and Control Association)

o Red.es

o SEI (Software Engineering Institute)



o SQI – Australia o Universidad Europea de Madrid

2.3.2 Fase de realización de entrevistas

Las tareas englobadas en esta fase del proyecto tienen como objetivo realizar, documentar y analizar el resultado de las entrevistas a entidades y expertos relacionados con el mundo del desarrollo de software en España y, en concreto, con los modelos de mejora de procesos.

Destacando las siguientes actividades concretas:

• Elaboración de un guión para la realización de las entrevistas que permita obtener información sobre:

o La visión de las empresas hacia los modelos de certificación de la calidad existente.

o La situación de la PYME y la micropyme frente al mercado de la certificación en España.

o Las experiencias de implantación desde el punto de vista del mercado empresarial.

• Realización de las entrevistas propiamente dichas.

• Confección de un acta tras la finalización de cada entrevista, que resuma las ideas más significativas sobre los aspectos objeto del estudio.

• Obtención de conclusiones globales a partir de las entrevistas realizadas.

Participantes

En primer lugar se ha desarrollado una labor de identificación y contacto con numerosas empresas y expertos en relación con la gestión de la calidad del software. Así, se ha logrado entrevistar a diferentes empresas y asociaciones empresariales, organismos públicos, entidades certificadoras, entidades normalizadoras y acreditadoras, expertos de universidades españolas y expertos independientes, no vinculados a ninguna de estas categorías. El listado de empresas e instituciones expertas que han participado en las entrevistas es el siguiente:

• Empresas privadas:


o Accenture

o Altia

o Consoltic

o DxD. España

o DxD. India

o Grupo Mondragón

o Ibermatica

o IBM

o PROCONSI

o Software Ag

o SoftWCare

o Shylex

o TQS

• Asociaciones empresariales:

o ALETIC (Asociación Leonesa de Empresas de TIC).

o AGESTIC (Asociación Gallega de Empresas de Tecnología e Información).

o AETICAL (Federación Sectorial sin ánimo de lucro de empresas del sector de las Tecnologías de la Información, Comunicaciones y Electrónica de Castilla y León).

• Organismos públicos:

o Junta de Extremadura.

o ICM (Informática de la Comunidad de Madrid).

• Universidades:

o UPM (Universidad Politécnica de Madrid).

o Universidad del País Vasco – EHU.

• Entidades certificadoras:

o EQA (European Quality Assurance).

o SGS (Software Quality Systems).

o AENOR.

• Entidades acreditadoras y normalizadoras:

o ENAC (Entidad Nacional de Acreditación).

o Comité ISO sobre normalización de calidad y mejora de procesos en nuevas tecnologías.

• Expertos independientes y otros:

o Caelum1http://www.calidaddelsoftware.com/.

o Colegio Profesional de Ingenieros Informáticos de Cataluña.

1 Más información disponible en www.calidaddelsoftware.com.

http://www.calidaddelsoftware.com/

http://www.calidaddelsoftware.com/


o AEC (Asociación Española de la Calidad).

Contenido de las entrevistas

Las entrevistas se han realizado de manera personal a responsables de los procesos de calidad del software y/o personas con experiencia en este ámbito en base a un guión previamente establecido.

Las entrevistas han sido grabadas en audio y/o vídeo para lograr un mejor análisis de las mismas, explotando todos los detalles apuntados por los expertos.

Por último, en base al conjunto de actas de todas las entrevistas se han recabado las conclusiones y tendencias de opinión más generalizadas entre los expertos.




3 NORMAS, MODELOS Y CERTIFICACIONES ORIENTADAS A LA CALIDAD DEL SOFTWARE

3.1 Introducción

El software se ha convertido en un producto esencial para los usuarios domésticos2 y especialmente para las empresas, donde la dependencia de la informática se ha vuelto crucial3. Este hecho ha derivado en que en los últimos años se haya experimentado un auge notable en la cantidad de empresas dedicadas al desarrollo de software; tanto PYME, como microempresas o grandes empresas, tal y como se expondrá en el epígrafe siguiente.

Desde una perspectiva productiva, el desarrollo y mantenimiento del software es un trabajo altamente complejo y generalmente va a asociado a proyectos difíciles de gestionar, tal y como se pone de manifiesto en el informe del Standish Group de 2005 donde se indica que el 31,1% de los proyectos de desarrollo se cancelan antes de completarse y sólo el 16,2% de los proyectos se completan en tiempo, cumpliendo adecuadamente con todos los requerimientos (técnicos y económicos).

En este contexto, la implantación de modelos o estándares de calidad tiene como objetivo principal el desarrollo sistemático de productos, bienes y servicios de mejor calidad y el cumplimiento de las necesidades y expectativas de los clientes. Así las cosas, una certificación de calidad pretende:

• Unir la misión de la empresa y el esfuerzo de cada una de las áreas que la integran en una sinergia de resultados orientados a la competitividad y la calidad global.

• Tener procesos y procedimientos ágiles y comprensibles por todos los involucrados, de forma que se garantice el paso por los distintos hitos del desarrollo, prueba, producción y, finalmente, la satisfacción del cliente.

Los procesos software tienen una gran importancia en el campo de la Ingeniería del Software, siendo una pieza básica en su estructura. El Software Engineering Body of Knowledge (SWEBOK) es un material de buenas prácticas de referencia en el campo de la ingeniería del software, y suele ser de obligada referencia al implementar los modelos de mejora que se desarrollarán a lo largo de este informe.

2 Según la Encuesta sobre Equipamiento y Uso de Tecnologías de la Información y Comunicación en los hogares, del Instituto Nacional de Estadística (2007), 60,2% de los hogares españoles disponen de ordenador personal (portátil o sobremesa), siendo los usuarios más jóvenes (10 a 25 años) los usuarios de ordenadores en los últimos 3 meses (92,8%). 3 Estudio sobre incidencias y necesidades de seguridad en las pequeñas y medianas empresas españolas. INTECO. 2007


Las áreas clave que se especifican en estas buenas prácticas son:

• Requerimientos de software: describe los mejores métodos de gestión a la hora de abordar un desarrollo de software (cómo obtenerlos, cómo gestionarlos, cómo aplicarlos, cómo mantenerlos, etc.), además de ofrecer guías para validarlos y consideraciones prácticas.

• Diseño de software: describe los fundamentos y mejores prácticas indicando los aspectos clave del diseño, y ofreciendo recomendaciones para implementar una metodología de proyecto completa, aplicando calidad y las estrategias necesarias.

• Construcción del software: describe las mejores prácticas de gestión de la construcción, minimización de la complejidad, modelos de construcción, etc. Las consideraciones prácticas incluyen recomendaciones sobre lenguajes de codificación, codificación, testeo, etc.

• Testeo del software: prácticas sobre la verificación dinámica del software mediante un número finito de casos de prueba, niveles de testeo, aplicabilidad de los mismos, etc.

• Mantenimiento del software: describe prácticas sobre cómo afrontar anomalías no cubiertas, cambios en los sistemas operativos, etc. Incluye guías sobre los costes que supone realizar cambios en el software y las mejores prácticas para su gestión.

• Gestión de la configuración del software: describe las mejores prácticas para identificar a lo largo del tiempo la configuración, de forma que sea posible sistematizar los cambios efectuados para controlarlos de una manera automática manteniendo la integridad y la trazabilidad del código.

• Gestión de la ingeniería del software: describe los procesos básicos de planificación de proyectos, gestión de proveedores, control y medida de los indicadores que mejor se adaptan a cada proyecto iniciado, evaluación y cierre de los proyectos.

• Proceso de ingeniería del software: concierne a las mejores prácticas de la definición, implementación, verificación, medida, cambio y gestión del propio proceso de ingeniería a aplicar en cada proyecto.

• Métodos y herramientas de ingeniería del software: describe las mejores herramientas y métodos a utilizar en el proceso de ingeniería a lo largo de cada proyecto.

• Calidad del software: describe las mejores prácticas de calidad que trascienden el ciclo de vida del software. Indica los fundamentos de calidad como cultura y ética,




valor y coste de la calidad, modelos y características concretas, además de la gestión de todos estos parámetros.

Por último, es ampliamente conocido que la Ingeniería del Software abarca un amplio espectro de disciplinas, entre las cuales se encuentra el domino en la aplicación de modelos y estándares de calidad. Estos permiten que las empresas puedan implementar la calidad en una doble vertiente: a nivel proceso y a nivel producto.

Mientras que todos los modelos importantes orientados a la mejora de procesos toman en consideración todas estas áreas claves, otros métodos como los orientados a producto se centran únicamente en: Gestión de la Ingeniería, Proceso de Software, Métodos y Herramientas de la Ingeniería del Software (en parte), y Calidad de Software. Cada modelo o estándar puede tener una aplicación concreta o limitada orientada a lograr mejorar determinados objetivos. De esta forma, los modelos ligeros y de producto tratan el SWEBOK como una referencia en puntos clave como el diseño, construcción y testeo únicamente, abordando las demás de forma somera y, en la mayor parte de los casos, ignorándolas por no ser aplicables.

En este sentido, teniendo en cuenta la estrategia y los objetivos de la empresa, se puede pensar en poder aplicar y/o integrar modelos o estándares diferentes consiguiendo así objetivos mucho más globales (como puede ser el caso de adopciones de CMMI e ISO 9001:2000 al mismo tiempo).

3.1.1 Orientación a la mejora del proceso

El proceso software objeto de mejora según el Software Engineering Institute4 es el conjunto de actividades, métodos, prácticas y transformaciones que la gente usa para desarrollar y mantener software y los productos de trabajo asociados (planes de proyecto, diseño de documentos, código, pruebas y manuales de usuario). Ahora bien, según establece la norma ISO/IEC 15504, es el proceso o conjunto de procesos usados por una organización o proyecto, para planificar, gestionar, ejecutar, monitorizar, controlar y mejorar sus actividades software relacionadas.

El objetivo final del modelo de procesos es lograr una representación clara de los procesos reales de desarrollo, con la cual poder trabajar para planificar las mejoras a incluir en cada uno de esos procesos. Si la representación conceptual del proceso es buena, los análisis de estos procesos sobre el papel permitirán a la empresa la posibilidad de automatizarlos, controlar su eficiencia, comprobar las interacciones con otros procesos, y ofrecer a la Dirección una nueva fuente de información, como puede ser la información actual del

4 http://www.sei.cmu.edu/programs/acquisition-support/presentations/process-pro.pdf

http://www.sei.cmu.edu/programs/acquisition-support/presentations/process-pro.pdf


estado de cada proceso en cualquier momento, el significado que debe darse a cada uno de los puntos de decisión, etc.

La mejora del producto final pasa, según estos modelos, por la mejora de los procesos que llevan a su creación. La adopción del modelo o metodología adecuados podrá realizar esta mejora con una correcta implantación, dotando implícitamente al producto final de una calidad manifiesta. Entre los modelos o estándares a nivel de proceso se pueden mencionar ISO 9001:2000 (ISO 90003:2004), ISO/IEC 15504, CMMI, TickIT, ISO 20000, Bootstrap, SwTQM (basado en EFQM y CMMI), etc.

3.1.2 Orientación a la mejora del producto

Dentro del conjunto de modelos y metodologías de mejora de la calidad, existen un conjunto de modelos que sitúan el foco de la mejora no en el producto final obtenido, sino aplicando un modelo de pruebas en el ciclo de vida del software sobre los productos obtenidos.

La estrategia en este caso se basa en el establecimiento de varios puntos de testeo y verificación sobre todas las etapas del ciclo de vida (requisitos, análisis, diseño y construcción), además de la última etapa de pruebas finales. Las técnicas a emplear suelen ser las siguientes:

• Detección temprana de errores mediante la anticipación del testing.

• Utilización de técnicas especializadas, como los test estáticos, dinámicos, pruebas unitarias, pruebas de caja negra y caja blanca, etc.

• Incorporación a los equipos de trabajo de grupos especializados en testing.

Estas aproximaciones se engloban en modelos especializados, como puede ser el caso de Testing Proccess Improvement (TPI), desarrollado por Sogeti, y certificable bajo la evaluación TMAP, el cual se describirá más detalladamente en el presente informe.

No obstante, y a pesar de que los pilares básicos del desarrollo de software son comunes (costes, plazos y calidad), por regla general la aplicación de este tipo de aproximaciones a la calidad mediante los modelos orientados a producto dependen en gran medida de la organización. Debido a que la estructura de cada organización y proyecto suele ser distinta a las demás, las soluciones no son “fácilmente generalizables”.

Estos modelos comienzan a ser una pieza importante a tenor de los resultados obtenidos en encuestas nacionales e internacionales. En 2006 el Departamento de Sistemas Informáticos de la Escuela Superior Politécnica de la Universidad Europea de Madrid realizó un sondeo sobre la práctica profesional en el campo de las pruebas de software,




para lo cual fueron entrevistados 125 profesionales de distintos perfiles. Las conclusiones de este informe son las siguientes:

• La gran mayoría de las organizaciones y profesionales se concentra en los aspectos más evidentes y básicos de las pruebas, dejando al margen prácticas consideradas importantes y que pudieran garantizar la eficiencia de los recursos y el tiempo, así como un menor riesgo para la ejecución de los proyectos.

• Es habitual que exista entre los desarrolladores una actitud, identificada ya por Glenford J. Myers5, de falta de interés por las pruebas, considerándolas un mal necesario y una actividad destructiva y poco creativa. No existe una especial presión en los desarrolladores a aceptar con facilidad formación sobre pruebas.

• Se busca en muchas ocasiones una solución que resuelva automáticamente esta actividad, cuando las pruebas resultan mucho más sencillas y cómodas si la propia organización del desarrollo (y especialmente el esfuerzo de especificación de requisitos), se prepara de forma integral para el aseguramiento de la calidad del software.

• La formación de los actuales profesionales en universidades como en otros centros complementarios de formación se antoja escasa y no contribuye a mejorar los aspectos comentados.

Entre los modelos o estándares a nivel de producto se pueden mencionar TPI/TMAP, el Modelo de Boehm, el Modelo de Gilb, el Modelo de Dromey, la norma ISO 9126-1, el Modelo de McCall, WebQEM, ISO 25000, Portal Quality Model (PQM) y otros. Mientras que los modelos a nivel de proceso son independientes de la tecnología, los modelos y estándares a nivel de producto surgen o se actualizan de acuerdo a la evolución tecnológica.

3.2 Certificación y acreditación

El mundo de la certificación de la calidad del software, y por extensión el de cualquier tipo de certificación existente a la que puedan acogerse las empresas que lo soliciten, se basa en la confianza que el cliente (cualquier entidad solicitante) deposita en la empresa que lo certifica. Con este planteamiento, basta ser una entidad suficientemente reconocida en la práctica para poder emitir sellos de certificación basados en cualquier tipo de norma.

La Entidad Nacional de Acreditación (ENAC) es la entidad encargada en España de realizar el proceso de acreditación sobre aquellas empresas certificadoras que pretenden

5 Glenford J. Myers (1979): The art of software testing. John Wiley and Sons


lanzar al mercado sus productos. Esta entidad actúa como intermediadora al ofrecer confianza:

• A efectos de los clientes de las empresas certificadoras que operan en España respaldando la certificación que éstas otorgan.

• En el cliente de las empresas certificadas, de forma que éste sabe que contrata sus productos a una organización con un sello de calidad reconocido y respaldado.

Desde este punto de vista de respaldo sobre la certificación se entiende que las entidades certificadoras con suficiente peso en el mercado puedan lanzar sus propios productos sin necesidad de pasar el proceso de la acreditación.

Esta práctica es común en España, a tenor de la entrevista realizada a los responsables de nuevas tecnologías de ENAC, y parte del proceso de la acreditación. En el caso de que una empresa con suficiente arraigo y reconocimiento en el mercado decida incluir en su catálogo un producto nuevo de certificación basado en un esquema propio o ajeno, puede y debe hacerlo inicialmente sin necesidad de una acreditación previa. Será únicamente a medio-largo plazo cuando, si este producto tiene un éxito reconocido y medible, basado en una norma oficial reconocida (como ISO), y el mercado lo demanda, cuando ENAC proceda a estudiar los resultados y los factores de mercado para realizar la acreditación sobre esa certificación. Con ello, se podrá extender a otras empresas certificadoras menores que la soliciten a posteriori.

El mercado, dentro de esta línea, ofrece certificaciones de calidad sin acreditación de ENAC. El catálogo de productos de certificación de AENOR, por ejemplo, contiene una certificación de calidad de desarrollo de software basada en la norma ISO/IEC 15504 y son ya varias las empresas que han publicitado ya su certificación con AENOR bajo este esquema, como Stratesys Consulting, o Ibermática.

Cabe destacar en este punto que la base de datos de IQNet, acreditador europeo para respaldo de entidades certificadoras, contiene un total de 14.598 certificados ISO 9001:2000 emitidos por sus partners en España AENOR y DQS España bajo su acreditación.

Por último, y en referencia concreta a ISO/IEC 15504, ENAC está actualmente a la espera de recibir un esquema piloto de certificación para proceder a su revisión y prueba.

El mercado de la certificación de software es rico en cuanto a normas y modelos se refiere. La calidad a nivel de procesos puede ser evaluada de manera genérica o específica, según el modelo o estándar seleccionado. Todo modelo o estándar a nivel de proceso tiene que tener un ámbito de aplicación específico y tiene como finalidad la mejora continua.




En este marco, la orientación del trabajo de las empresas desarrolladoras hacia un establecimiento y control de los procesos software se está haciendo cada vez más importante. Muestra de ello es la aparición de gran cantidad de modelos encaminados a su mejora continua como vía para alcanzar la excelencia en los procesos (Tabla 1).

Tabla 1: Modelos y metodologías existentes en el mercado

Modelo Autor Información adicional BOOTSTRAP Kuvaja et al, 1994 http://www.bootstrap-institute.com

EIA 632 (más IEEE/EIA 12207) Sheard y Lake, 1998 http://www.eia.org

ISO/IEC 15504 ISO http://www.iso.org

ISO/IEC 9000 ISO http://www.iso.org

MIL STD-498 Departamento de Defensa (EE. UU.)

http://www2.umassd.edu/SWPI/DOD/MIL-STD-498/498_OVER.PDF

CMMI. Capability Maturity Model Integration

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

SCE. Software Capability Evaluation Byrnes y Philips, 1996 http://www.sei.cmu.edu

SEI PSP. Personal Software Process Humphrey, 1997 http://www.sei.cmu.edu/tsp/

SEI TSP. Team Software Process http://www.sei.cmu.edu/tsp/

ITMark ESI (European Software Institute) http://www.esi.es

TickIT TickIT Project Office, 1992 http://www.tickit.org

EFQM Fundación Europea de Gestión de Calidad http://www.efqm.org

ITIL OGC (Office of Government Comerce) http://www.itil.co.uk

TPI/TMAP Sogeti http://www.tmap.net

Fuente: INTECO

En los siguientes apartados se puede ver con más nivel de detalle la descripción de cada uno de estos modelos, así como el estado del arte de cada uno de ellos.

3.3 Normas, modelos y certificaciones más importantes orientadas a procesos

3.3.1 ISO 9000

La familia de normas ISO 9000 es un conjunto de normas de calidad establecidas por la Organización Internacional para la Estandarización (ISO), aplicables en cualquier tipo de organización. Fue publicada en 1987 con una norma estándar británica (BS) como base; ha sido revisada en 1994 y actualizada nuevamente en el año 2000, con un compromiso

http://www.bootstrap-institute.com/

http://www.eia.org/

http://www.iso.org/

http://www.iso.org/



http://www.sei.cmu.edu/

http://www.sei.cmu.edu/

http://www.sei.cmu.edu/tsp


http://www.esi.es/

http://www.tickit.org/

http://www.efqm.org/

http://www.itil.co.uk/

http://www.tmap.net/


de ser revisado cada 5 años. Aunque en 2005 ha sufrido modificaciones actualmente se certifica a las empresas solicitantes bajo la versión 2000. Entidades acreditadoras a nivel europeo como IQNet y la propia ENAC (Entidad Nacional de Acreditación), en España, aún no acreditan entidades certificadoras bajo la norma de 2005.

La versión de 1994 establecía un conjunto básico mínimo de requisitos para el establecimiento y mantenimiento de la gestión del Sistema de Gestión de la Calidad para la ingeniería del software. Identificaba 20 áreas principales (MTA’s) y 177 resultados de gestión. Se concibe como una metodología de procesos basada en una lista de comprobaciones o requisitos a cumplir, umbral de calidad, valorado apto o no apto. Esta simplicidad es la que la ha hecho mundialmente extendida. La revisión realizada en el año 2000 incorpora las siguientes mejoras que han contribuido aún más a hacerla muy difundida en el mercado:

• Aproximación de la gestión basada en el proceso.

• Compatibilidad con otros sistemas de gestión (p.ej. ISO 14000).

• Inclusión de requisitos para la mejora continúa del sistema de calidad.

• Coincidencia con las necesidades de los participantes externos (p.ej. clientes, proveedores, etc.).

• Facilidad de uso para el usuario y el cliente.

Además comprende las siguientes normas:

• ISO 9000:2000; “Definiciones y vocabulario”.

• ISO 9001:2000; “Requisitos del sistema de gestión de la calidad”.

• ISO 9004:2000; “Directrices para la mejora del desempeño”.

El estándar se basa en un conjunto de Principios de Gestión de la Calidad, que son:

• El enfoque permanente al cliente final.

• El liderazgo.

• La implicación de todo el personal.

• El enfoque a procesos.



• El enfoque del sistema hacia la gestión (mediante la implantación del Sistema de Gestión de la Calidad –en adelante SGC–).

• La mejora continua.

• El enfoque objetivo hacia la toma de decisiones.

• Las relaciones mutuamente beneficiosas con los proveedores.

La ISO 9001:2000 es la norma que contiene los requisitos básicos que debe cumplir una organización para la implementación de un SGC, y es la única certificable en la actualidad. Las organizaciones que desean ir más allá de los requisitos básicos exigidos en la norma ISO 9001:2000 deberían cumplir los requisitos adicionales que establece la norma ISO 9004:2000, complementaria a la anterior, y recomendada para las organizaciones que persiguen una mejora continua. No obstante, ISO 9004:2000 no es una norma certificable.

Estructura

La estructura de ISO 9001:2000 tiene muchas semejanzas al círculo de Deming, que define el extendido ciclo PDCA (Plan-Do-Check-Act). La norma se estructura en los siguientes capítulos:

• Capítulos 1 al 3: “Guías y descripciones generales”.

• Capítulo 4: “Sistema de Gestión”. Define los requisitos generales y los requisitos para la gestión de la documentación.

• Capítulo 5: “Responsabilidades de la Dirección”. Define los requisitos que debe cumplir la dirección de la organización, como son la definición de la política de calidad, asegurar que las responsabilidades y autoridades están definidas, etc.

• Capítulo 6: “Gestión de los Recursos”. Define los requisitos exigidos sobre los tres tipos de recursos en que se actúa: recursos humanos, infraestructura, y el ambiente de trabajo.

• Capítulo 7: “Realización del producto”. Define los requisitos productivos; atención al cliente, entrega del producto o el servicio, etc.

• Capítulo 8: “Medición, análisis y mejora”. Define los requisitos para los procesos que recopilan información, la analizan, y que actúan en consecuencia. El objetivo declarado en la norma es que la organización busque la satisfacción del cliente a través del cumplimiento de los requisitos.



A continuación, en el Gráfico 1 se muestra el esquema general de ISO 9001:2000 y las equivalencias previamente descritas.

Gráfico 1: Modelos existentes en el mercado encaminados a la mejora de procesos según especificaciones de la norma ISO 9001:2000

Fuente: INTECO

Esta norma es aplicable a la mejora de procesos en general por lo que el desarrollo de software tiene cabida en la misma. No obstante, la percepción del mercado sobre ella, en este sentido, es que se queda corta para los requerimientos que un desarrollo de software de calidad debería poseer. Según las entidades entrevistadas, ha perdido valor de mercado por la obvia razón de que en la práctica se trata más de un sello de certificación de obligado cumplimiento, un requisito inicialmente impulsado desde la Administración en España, que una certificación que otorgue algún tipo de excelencia sobre los procesos de una compañía. Por ello, ha dejado de ser un elemento diferenciador en las empresas españolas.

Si algo se achaca a la norma es su excesiva generalidad. La ISO 9001 fue publicada para ser utilizada por toda clase de industrias, y es difícil interpretarla cuando se quiere aplicar a determinadas industrias, campos específicos, sucursales o divisiones particulares por separado de una gran empresa, o incluso el desarrollo de software. Para tratar de paliar estas carencias, ISO ha publicado la norma ISO/IEC 9000-3, "Guía para la aplicación de ISO 9001 para el desarrollo, implementación y mantenimiento de software".



Si bien el objetivo de la ISO 9001 es construir un Sistema de Gestión de la Calidad que abarque la estructura de la organización, las responsabilidades, los procedimientos, los procesos y los recursos necesarios para implementar una dirección de calidad, el objetivo de la norma ISO 9000-3 es proveer las especificaciones de cómo aplicar la ISO 9001 al desarrollo del software, su implementación y su mantenimiento. Además, se incluyen algunos temas que no se encuentran en las normas ISO 9000 genéricas, tales como la Administración de la Configuración o la Planificación de Proyectos.

Por último, para ciertos productos o servicios, la especificación de requerimientos contenida en las normas genéricas ISO 9000 no es suficiente para asegurar la calidad, y por ello se justifica la necesidad de creación de otras normas o guías más específicas como la 9000-3.

3.3.2 CMMI (Capability Maturity Model Integration)

La norma Capability Maturity Model Integration –en adelante CMMI– es una de las normas mejor valoradas según las entrevistas realizadas en el transcurso del estudio, en las que queda de manifiesto el interés de las empresas españolas por el modelo.

CMMI es la evolución de CMM (Capability Maturity Model), que data de finales de los años ochenta. Como respuesta a un requerimiento del Gobierno Federal de los Estados Unidos, CMM fue desarrollado para establecer un modelo de madurez mesurable al que tuviesen que acogerse los procesos internos de las empresas concesionarias de servicios de la administración estadounidense, como un método de mejorar la calidad de sus productos a través de la mejora de sus procesos. La primera definición del modelo de madurez de procesos en el desarrollo de software se publicó en septiembre de 1987, y fue una variación que evolucionó al modelo CMM-SW (CMM for Software) con una última versión de 1993.

Durante los años 90, el Software Engineering Institute –en adelante SEI– desarrolló (además de CMM-SW) otra serie de modelos de madurez aplicables a otras áreas. Dado que las empresas solicitaban continuamente la evaluación de sus procesos para varias áreas, se creó CMMI como un modelo integrado que incluye, entre otros, el modelo CMM-SW y con un principio básico fundamental, la calidad de un producto o de un sistema es en su mayor parte consecuencia de la calidad de los procesos empleados en su desarrollo y mantenimiento. La primera versión de CMMI como tal data de enero 2002, y en la actualidad ha llegado a su versión 1.2.

Los documentos que actualmente forman el modelo CMMI son los siguientes:

• CMMI for Development, v.1.2.: es la continuación y mejora del modelo CMMI v1.1, y ha sido desarrollado gracias al concepto de “constelaciones CMMI”. Estas son un conjunto de componentes básicos que pueden ser aumentados por material



adicional para proveer modelos de aplicación específica con un alto contenido común. Con esta nueva descripción, CMMI-DEV no es más que el modelo CMMI para el área de desarrollo, que anteriormente se especificaba por completo en el modelo CMMI v.1.1.

• CMMI Acquisition Module v.1.1.: define una serie de prácticas (a añadir al modelo básico CMMI) con respecto a proyectos de adquisición. Estas “mejores prácticas” se enfocan en las actividades llevadas a cabo por profesionales de compras en el marco de la oficina de programas de adquisición.

En esta nueva representación en constelaciones, cada una es una colección de componentes CMMI que incluye un modelo, sus materiales de aprendizaje, y los documentos relativos a la evaluación para un área de interés determinada. SEI ha planteado la creación de tres constelaciones por el momento, incluidas en el marco de trabajo del modelo CMMI v.1.2:

• Desarrollo: elaborada como CMMI-DE y como evolución natural del anterior modelo CMMI v1.1.

• Servicios: elaborada como CMMI-SERV y que se encuentra aún en fase de pruebas.

• Adquisición: actualmente existe, aunque se encuentra en fase de desarrollo, como módulo independiente, denominado CMMI-AM en versión 1.1, complementario y anexionable al modelo definido CMMI.

Las referencias generales a CMMI en los textos que se incluyen en este informe abarcan tanto al modelo CMMI v.1.1 como a CMMI for Development (CMMI-DEV) v.1.2, debido a que CMMI-SE/SW ha evolucionado directamente a la constelación CMMI for Development.

Descripción del modelo CMMI (CMMI v1.1, CMMI for Development)

Una de las particularidades de este método de mejora es la agrupación de las áreas de proceso definidas en cinco niveles de madurez, de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez. Los niveles son los siguientes:

1. Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para el desarrollo y mantenimiento de software. Aunque se utilicen técnicas correctas de ingeniería, los esfuerzos se ven minados por la falta de planificación. El éxito de los proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos y sobrecostes, haciendo que el resultado de los proyectos sea impredecible.



2. Repetible/Gestionado. En este nivel las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos, existiendo unas métricas básicas y un razonable seguimiento de la calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente.

3. Definido. Además de una buena gestión de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinación entre grupos, formación del personal, técnicas de ingeniería más detalladas y un nivel más avanzado de métricas en los procesos. Implementándose bajo estas pautas técnicas de revisión por pares (peer reviews).

4. Gestionado cuantitativamente. Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El software resultante al utilizar estas medidas es de alta calidad.

5. Optimizado. La organización completa está volcada en la mejora continua de los procesos. Se hace un uso intensivo de las métricas y se gestiona el proceso de innovación.

El modelo CMMI, pues, establece una medida del progreso conforme avanza en niveles de madurez, poseyendo cada nivel a su vez un número de áreas de proceso que deben lograrse. El alcanzar estas áreas o estadios se detecta mediante la satisfacción o insatisfacción de varias metas claras y cuantificables.

Los datos del SEI al respecto de la madurez de los procesos de empresas en que se han realizado evaluaciones se pueden encontrar en el Gráfico 2, ordenados según el tamaño de la empresa. Puede verse fácilmente que los niveles más altos de madurez son alcanzados normalmente por empresas grandes, mientras que la PYME, por el contrario, suele establecerse en el nivel 2.




Gráfico 2: Nivel de madurez según CMMI, por tamaño de las organizaciones (muestra de 1680 empresas que han comunicado sus datos al SEI)

20,4

%

38,8

% 43,2

%

44,2

%

38,9

%

38,6

%

40,4

%

27,2

% 34,6

%

38,1

%

0%

10%

20%

30%

40%

50%

60%

70%

80%

25 o menos 25 a 50 51 a 75 76 a 100 101 a 200 201 a 300 301 a 500 501 a 1000 1001 a 2000 más de2000

No facilitados Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 5

Fuente: SEI6

La representación de los modelos integrantes de CMMI, en su presentación inicial como CMM (y su variante software, CMM-SW), variaba entre la denominada representación “continua” y la “escalonada”.

CMM-SW poseía representación “escalonada”, ya que según el modelo se centra en la madurez de la organización. El modelo “continuo”, en cambio, se centra en las actividades de mejora y evaluación de la capacidad de los distintos procesos.

A día de hoy, es posible elegir la representación que mejor se adapte a las características de la empresa y a sus prioridades de mejora, ya que ambas son equivalentes.

• El modelo escalonado (por etapas) tiene las siguientes características: Cinco niveles, numerados de 1 a 5, que indican “Madurez Organizacional”, definidos a su vez por un conjunto de áreas de proceso objeto de la mejora. Provee una única clasificación que facilita comparaciones entre organizaciones.

• El modelo continuo añade el nivel 0 (no implementado), por lo que consta de 6 niveles, numerados de 0 a 5, que indican “Capacidad” de un áreas de proceso, y

6 Software Engineering Institute (2007): CMMI® v1.1 SCAMPI SM v1.1 Class A Appraisal Results; 2006 end-year update.


están definidos por cada una de las áreas, sobre la que admite comparaciones como ente independiente, permitiendo además elegir el orden de las mejoras.

Variantes y añadidos al modelo CMMI

Como se ha descrito en la introducción, CMMI for Development (CMMI-DEV) es, como tal, la evolución natural de CMM v.1.1. En la versión 1.2, con la introducción del concepto de constelación, ha pasado además a ser una de las tres actualmente planificadas por el SEI (desarrollo, adquisición y servicios). Se describen a continuación las iniciativas y estado actual al respecto de las otras dos constelaciones.

• CMMI for Adquisition Module en versión 1.1: es un modulo añadido a CMMI for Developmenty funciona como una guía independiente que describe las mejores prácticas a emplear en la adquisición de productos, sistemas, y servicios de terceros. Su enfoque inicial es la efectividad de las actividades de adquisición y las prácticas a implementar por los proyectos de adquisición de primer nivel. Puede ser usado además para implementar actividades de mejora de procesos institucionales de compra dentro de una organización.

Además el modelo distingue dos clases de adquisiciones, dado que algunas de ellas están bajo control directo del proyecto de adquisición, y otras se dirigen mediante la monitorización de desarrollos de terceros.

Por último, las áreas de proceso involucradas en la adquisición de productos y su integración en el esquema del módulo CMMI se definen con detalle en el documento del SEI “CMMI Adquisition Module v1.1”.

• CMMI for Services: el propósito de esta constelación es extender el framework de CMMI para cubrir la provisión de servicios. En este sentido, el SEI define un servicio como un producto cuya principal característica es que es entregado a un cliente o usuario final de una forma intangible, no almacenable, y dependiente de la aplicación directa del trabajo. Otras características del modelo son:

o Los procesos, según la documentación previa del SEI, incluirían la gestión de los servicios y la entrega de los mismos. Los dominios de servicios desarrollados en el modelo incluirían un enfoque en los servicios de IT, operaciones y mantenimiento, y servicios profesionales fuera del dominio de los servicios.

o Debe complementar ITIL, debido a que sintetiza sus mejores prácticas en función de sus especificidades, mapeándolas a componentes del modelo CMMI de forma que se pueda consultar ITIL como referencia para la implementación.




o El nuevo modelo reutiliza alrededor de un 80% del modelo CMMI actual, permitiendo a los usuarios sacar provecho de su inversión previa en formación de procesos basados en desarrollo, las mejoras obtenidas, y la infraestructura de la oferta basada en servicios.

o Provee un modelo de madurez aceptado por la industria, ayudando a las organizaciones a planear y controlar su progreso incremental hacia una alta madurez.

o Usa el mismo método de evaluación que el modelo CMMI actual, permitiendo sacar partido del “expertise” de las evaluaciones, métodos de preparación, y artefactos seleccionados.

o El estado actual del modelo, según la planificación existente en el sitio web del SEI7 se indica que debería existir una versión inicial disponible en producción en julio de 2007.

Datos estadísticos sobre los beneficios del modelo

En la web de SEI (propietario del modelo y esquema de certificación) se pueden encontrar datos sobre los beneficios obtenidos por distintas empresas tras la implantación del modelo, en referencia a distintas categorías de mejora.

Tabla 2: Beneficios de la implantación de CMMI según encuestas del SEI

Categoría medida Media

Tamaño de la muestra en esta

categoría

Punto inferior de la muestra

Punto superior de la muestra

Coste 20% 21 3% 87%

Planificación de actividades 37% 19 2% 90%

Productividad 62% 17 9% 255%

Calidad final 50% 20 7% 132%

Satisfacción del cliente 14% 6 -4% 55%

Retorno de la inversión 4,7 : 1 16 2: 1 27,7 : 1

Fuente: SEI

Los datos de la Tabla 2 pertenecen a 25 empresas europeas que han implementado CMMI y han tenido un suficiente plazo de tiempo como para poder medir estos parámetros de

7 http://www.sei.cmu.edu/cmmi y a través del Basic Support for Cooperative Work (https://bscw.sei.cmu.edu/)

http://www.sei.cmu.edu/cmmi

https://bscw.sei.cmu.edu/


medio-largo plazo. Cabe destacar que el retorno de la inversión global se sitúa en una media de un 470%.

Como punto fuerte del modelo destaca la inclusión de las prácticas de institucionalización, que permiten asegurar que los procesos asociados con cada área de proceso serán efectivos, repetibles y duraderos. Así mismo, el modelo se establece como una guía paso a paso para la mejora, a través de niveles de madurez y capacidad (frente al modelo ISO). Ofrece, como último aspecto reseñable, la transición del ‘aprendizaje individual’ al ‘aprendizaje de la organización’ por mejora continua, lecciones aprendidas y uso de bibliotecas y bases de datos de proyectos mejorados.

Como puntos débiles destaca que CMMI puede llegar a ser excesivamente detallado para algunas organizaciones, aspecto esto de difícil comprensión, y además requiere una inversión elevada para ser completamente implementado. No existe una guía a medida de pequeñas organizaciones como las PYME, aunque la representación continua permite seleccionar sólo aquellas áreas de proceso de interés, punto que puede ser asumido por las pequeñas empresas. Este punto de partida ha sido asumido por ESI (European Software Institute) para crear su propio modelo adaptado a PYME, ITMark, que se describe posteriormente en el epígrafe 3.3.4.

Esquema de evaluación

Dado que CMMI no es una norma, por lo que no existe un proceso de certificación como tal, sólo se evalúa a través de profesionales reconocidos por el SEI, que éste denomina Lead Appraisers. Este proceso de evaluación determina la madurez de los procesos de la organización que la lleva a cabo, valorando formalmente el nivel adquirido. El método de evaluación instaurado de forma oficial por SEI es el SCAMPI (Standard CMMI Appraisal Method for Process Improvement), que proporciona un benchmarking relativo a la implantación de los modelos CMMI. Mediante la aplicación de este método, se identifican las fortalezas y debilidades de los procesos actualmente implementados en la organización, se descubren los riesgos asociados, y se pueden determinar los niveles de capacidad y madurez de los mismos.

Las evaluaciones bajo SCAMPI se basan en los principios de evaluación ARC, definidos por el SEI en el documento “Appraisal Requirements for CMMI (ARC), Version 1.2”. El método SCAMPI, a su vez, se define en “Standard CMMI Appraisal Method for Process Improvement (SCAMPISM), Version 1.2: Method Definition Document”.

Estos documentos definen tres tipos de revisiones bajo SCAMPI:

• Clase A: Método completo, utilizado en evaluaciones en profundidad, con el foco puesto en la institucionalización del modelo en la organización. Este método evalúa




realmente el nivel de madurez conforme a CMMI, y otorga puntuación sobre el mismo.

• Clase B: Evaluación útil previa a la implantación masiva de nuevos procesos, y que no proporciona puntuación sobre el nivel de madurez.

• Clase C: La evaluación más rápida, que evalúa áreas de riesgo con recolección básica de datos. No proporciona puntuación sobre el nivel de madurez, y puede ser realizada por la propia organización.

La evaluación clase A requiere que el proceso de evaluación sea llevado a cabo por Lead Appraisals, auditores acreditados por el SEI, de los que existe un amplio listado en su sitio web. Las demás evaluaciones (B y C) deben ser supervisadas por agentes autorizados del SEI para garantizar la interpretación correcta de los métodos.

En todas ellas se realiza una puntuación de la implementación de cada una de las prácticas indicadas en el modelo CMMI según los criterios indicados en la lista siguiente:

• Fully implemented (FI): Artefactos directos8 presentes y apropiados, apoyados por artefactos indirectos9 y/o afirmaciones10, no habiendo sido anotadas debilidades significativas.

• Largely implemented (LI): Artefactos directos presentes y apropiados, apoyados por artefactos indirectos y/o afirmaciones, con una o más debilidades significativas anotadas.

• Partially implemented (PI): Artefactos directos ausentes o juzgados inadecuados, o artefactos o afirmaciones que indican que algunos aspectos de la práctica están implementados. Existen una o más debilidades significativas anotadas.

• Not implemented (NI): Cualquier situación no contemplada previamente.

Si todas las prácticas asociadas están categorizadas como LI o FI, se considerará satisfecha la meta correspondiente. La agregación de debilidades no tiene un impacto significativo negativo en el logro de la meta. Para que una meta sea calificada como

8 En terminología CMMI, según el documento que define el modelo, un Artefacto Directo es un producto tangible resultado directo de la implementación de una práctica genérica o específica. Puede ser parte integral de la verificación de la implementación de una práctica, o puede estar explícitamente declarado o implícito en la declaración de la práctica o material asociado a la misma. 9 Son una consecuencia de ejecutar una práctica específica o genérica o de hacer tangible su implementación, pero no son el objetivo para el cual fueron realizados. 10 Declaraciones verbales (en entrevistas) o escritas, confirmando o apoyando la implementación de una práctica específica o genérica.


insatisfactoria, el equipo debe ser capaz de describir cómo las debilidades han llevado a esa calificación.

Implantación en el mercado

Los últimos resultados del informe emitido por el SEI, “CMMI® v1.1 SCAMPI SM v1.1 Class A Appraisal Results”, actualizado a final de año de 2006 y en que se muestran las evaluaciones SCAMPI realizadas hasta enero de 2007, aparecen en la Tabla 2. En esta tabla se puede comprobar la importancia que las empresas españolas otorgan a esta certificación, pues España se encuentra en el noveno lugar mundial con 31 evaluaciones realizadas, tras Estados Unidos, China, India, Corea, Japón, Reino Unido, Brasil y Francia. En Europa, España es el tercer país con más evaluaciones exitosas realizadas.

Tabla 3: Evaluaciones SCAMPI Clase A, a enero de 2007

Country Number of Appraisals

Maturity Level 1

Reported

Maturity Level 2

Reported

Maturity Level 3

Reported

Maturity Level 4

Reported

Maturity Level 5

Reported

Argentina 19 No Yes Yes Yes Yes

Australia 23 Yes Yes Yes Yes Yes

Austria 10 or fewer

Dahrain 10 or fewer

Belarus 10 or fewer

Belgium 10 or fewer

Brazil 48 No Yes Yes Yes Yes

Canadá 26 No Yes Yes Yes Yes

Chile 15 No Yes Yes No Yes

China 240 Yes Yes Yes Yes Yes

Colombia 10 or fewer

Czech Republic 10 or fewer

Denmark 10 or fewer

Dominican Republic 10 or fewer

Egypt 17 No Yes Yes Yes Yes

Finland 10 or fewer

France 75 Yes Yes Yes Yes Yes

Germany 35 Yes Yes Yes Yes Yes

Hong Kong 10

India 204 No Yes Yes Yes Yes

Indonesia 10 or fewer

Ireland 10 or fewer




Country Number of Appraisals

Maturity Level 1

Reported

Maturity Level 2

Reported

Maturity Level 3

Reported

Maturity Level 4

Reported

Maturity Level 5

Reported

Israel 10

Italy 10 or fewer

Japan 172 Yes Yes Yes Yes Yes

Korea, Republic Of 78 Yes Yes Yes Yes Yes

Latvia 10 or fewer

Malaysia 19 No Yes Yes No Yes

Mauritius 10 or fewer

Mexico 15 No Yes Yes Yes Yes

Morocco 10 or fewer

Netherlands 10 or fewer

New Zealand 10 or fewer

Pakistan 10 or fewer

Peru 10 or fewer

Philippines 16 No Yes Yes No Yes

Portugal 10 or fewer

Russia 10 or fewer

Singapore 10 or fewer

Slowakia 10 or fewer

South Africa 10 or fewer

Spain 31 No Yes Yes No Yes

Sweden 10 or fewer

Swtzerland 10 or fewer

Taiwan 46 No Yes Yes No Yes

Thailand 10 or fewer

Turkey 10 or fewer

United Kingdom 48 Yes Yes Yes Yes No

United States 718 Yes Yes Yes Yes Yes

Viet Nam 10 or fewer

Fuente: SEI11

Costes de implantación

Se incluyen a continuación, en la Tabla 3, los tiempos estimados de implantación/adaptación de cada nivel dentro del modelo CMMI según el SEI. 11 Op. cit. 6



Tabla 4: Tiempo de implantación de los niveles CMMI

Evolución al nivel superior Tiempo

Nivel 1 (por defecto) al nivel 2 23 meses

Nivel 2 al nivel 3 22 meses



Fuente: SEI12

3.3.3 ISO/IEC 15504 (SPICE, Software Process Improvement and Capability dEtermination)

ISO/IEC 15504 es un estándar dirigido, como CMMI, a la evaluación y determinación de la capacidad y mejora continua de procesos de ingeniería del software. Su filosofía es desarrollar un conjunto de medidas de capacidad estructuradas para todos los procesos del ciclo de vida y para todos los participantes.

ISO/IEC decidió afrontar en 1991 una investigación sobre necesidades y requisitos para un estándar de evaluación del proceso software. El proceso de desarrollo y validación empírica (proyecto SPICE) se alargó hasta 1998, en que fue publicada la primera versión del estándar como Informe Técnico, evolucionando posteriormente hasta Estándar Internacional. Su evolución consta de tres fases: la fase 1, de 1995, para validar la decisiones de diseño y usabilidad del borrador; la fase 2, de 1996 a 1998, para sumar a los objetivos anteriores una guía de aplicación y la revisión de la consistencia, validez, adecuación, usabilidad y portabilidad de SPICE; y la fase 3 (hasta marzo de 2003, en que se cierra el proyecto SPICE) para aportar entradas y publicar el estándar ISO.

12 Op. cit. 7


Gráfico 3: Estructura de procesos de ISO/IEC 15504 (SPICE), según indica la norma

Guía de uso para la mejora de procesos

Realización de una evaluación

Modelo de ref. para procesos y capacidad

Modelo de evaluación y guía de uso

Guía para determinar capacidad de proveedores

Guía de evaluación

Guía de calificación de proveedores

Conceptos y guía de introducción Vocabulario

P1 P9

P6P8P7

P3

P2

P4

P5

Fuente: Norma ISO

ISO/IEC 15504 se basa en el estado del arte actual con respecto a las certificaciones de calidad de desarrollo de software, incorporando así la escala de puntuación de capacidad de CMM, las actividades de proceso de ingeniería de ISO/IEC 12207, Trillium y CMM, la representación de capacidad basada en perfiles de atributos de BOOTSTRAP y la experiencia del sistema de gestión de la calidad general de ISO 9001.

Estructura del estándar

ISO/IEC desarrolla un modelo 2-D de evaluación de la capacidad del proceso. Se valora la organización de desarrollo software en la dimensión del proceso contra los atributos del proceso en la dimensión de capacidad:

• La primera, denominada dimensión del proceso, define un conjunto estándar de procesos para el ciclo de vida completo del software. Parte de tres clases básicas de procesos (primaria, soporte y organizativas), que a su vez se dividen en cinco categorías de proceso (cliente/suministrador, ingeniería, soporte, administración, organización), veinticuatro procesos de alto nivel y otros dieciséis componentes.

• La segunda, dimensión de la capacidad del proceso, se sustenta en un conjunto de atributos que determinan el nivel. Su objetivo es definir la escala de medida para la capacidad del proceso, y para ello se considera una escala de tipo ordinal basada en seis puntos de control:



o Incompleto: Hay un fallo generalizado al alcanzar los propósitos del proceso.

o Realizado: El propósito del proceso es generalmente alcanzado. Este éxito no tiene por qué haber sido rigurosamente planificado ni seguido.

o Gestionado: Se liberan productos de acuerdo a procedimientos específicos siendo el proceso planificado y seguido.

o Establecido: Se usan procesos definidos basados en principios de la ingeniería del software para alcanzar los objetivos.

o Predecible: El proceso definido es ejecutado en consistencia con controles de límites establecidos, para alcanzar los objetivos definidos. Las medidas detalladas del rendimiento son coleccionadas y analizadas.

o Optimizado: La realización de los procesos se encuentra optimizada de forma que coincidan con las necesidades actuales y futuras de negocio. Los resultados de los procesos son alcanzados de forma repetida de acuerdo con los objetivos definidos.

La primera versión estructuraba el modelo en treinta y cinco procesos agrupados en cinco categorías (Cliente-Proveedor, Ingeniería, Proyecto, Soporte y Organización). Sin embargo, la idea de expandir el ámbito de aplicación del estándar evitando restringirlo a un determinado ciclo de vida, la compatibilidad con ISO/IEC 12207 e ISO/IEC 15288 y con cualquier modelo posterior, permitió la evolución del estándar con el objetivo de aceptar Modelos de Referencia de Procesos (PRM’s) y eliminando la inicial dimensión de procesos al dividirla en cinco partes:

• Parte 1. Conceptos y Vocabulario.

• Parte 2. Realizando una Evaluación (requisitos, normativa).

• Parte 3. Guía para Realización de Evaluaciones.

• Parte 4. Guía para el Uso de Resultados de Evaluaciones.

• Parte 5. Un Modelo de Evaluación de Procesos Ejemplar.

Finalmente como puntos a favor, ISO 15504 es el primer modelo de procesos que incorpora las ya comentadas dimensiones independientes para los procesos y la capacidad. El resultado de la evaluación podría ser representado por un perfil en una gráfica de dos dimensiones. Así mismo, define un conjunto de criterios de conformidad para permitir la comparación de modelos externos de procesos y encontrar requisitos



comunes. Por el contrario, el dominio de procesos debería ser más amplio para abarcar todos los posibles ciclos de vida (algo no necesario por la adopción de modelos externos, los PRM) y es difícil que todos los atributos de proceso fueran universales, aplicables a todos los procesos y prácticas base. Además, la dimensión capacidad ha alcanzado un alto grado de dificultad y existen algunos solapamientos con la de procesos.

Además, cabe decir que la complejidad de las evaluaciones (y por consiguiente el costo) es significativamente más alta que en otros modelos.

3.3.4 ITMark

El modelo ITMark ha sido diseñado por ESI (European Software Institute), fundación privada sin ánimo de lucro creada en 1993 por la Comisión Europea en colaboración con el gobierno vasco, e integrada en la Corporación Tecnológica TECNALIA.

ITMark evalúa y acredita la calidad de la empresa en tres grandes áreas: una relacionada con la gestión general de la empresa (estratégica, comercial, financiera y de marketing), otra sobre la seguridad de la información y la tercera y más específica, vinculada a la madurez de sus procesos software. En los temas relativos a gestión se toma como referencia el modelo 10-Squared. Desde el punto de vista de la seguridad se emplea el estándar ISO 17799, en tanto que en el área específica de software se incorpora una versión simplificada de CMMI.

Este modelo se ha definido con la PYME y la microempresa como objetivo fundamental, preparando un esquema de certificación basado en CMMI que, según ESI, no se ha reducido para aplicarlo más fácilmente en PYME. Por el contrario, se aplica de forma concreta, pero estableciendo unos requisitos que se pueden interpretar únicamente desde las características especiales de las PYME. Las evaluaciones de cumplimiento del modelo ITMark, por ello, no son Clase A (ver el apartado sobre CMMI), sino evaluaciones simplificadas de Clases B y C.

Bajo ITMark se realizan evaluaciones a las empresas en tres niveles:

• ITMark, acredita, a una empresa, que es consciente de los problemas relacionados con la gestión técnica, de seguridad y del negocio, y que los mantiene habitualmente bajo control. Para ello se admite que algunas de las áreas de proceso puedan no estar suficientemente elaboradas, trabajándose en el caso particular de los Procesos Técnicos sobre CMMI Nivel 2 y por medio de evaluaciones rápidas orientadas fundamentalmente a la identificación de debilidades (de Clase C).

• ITMark Premium, acredita a una empresa que ha conseguido una buena madurez en sus procesos de trabajo técnico, seguridad y del negocio. En este caso los niveles necesarios son considerablemente superiores a los descritos anteriormente,



exigiéndose que todos los procesos evaluados desde los tres puntos de vista están razonablemente desarrollados. Por ejemplo, en el caso de CMMI se utiliza una evaluación bastante detallada de Clase B sobre CMMI Nivel 2, que una vez superada nos facilita una confianza grande de poder superar con un trabajo relativamente escaso la Evaluación Oficial CMMI de Clase A.

• ITMark Elite, acredita a una empresa que ha conseguido un nivel superior en la definición e institucionalización de sus procesos de trabajo técnico, de seguridad y de negocio, por lo que se confía en que la calidad de sus productos sea buena, debido a la madurez de sus procesos y a la mejora continua. En el caso de Elite, los niveles de exigencia son proporcionalmente superiores, y en caso de CMMI se trabaja sobre el Nivel 3.

Según el director de servicios de ESI, Iñigo Garro, con IT Mark se identifican las fortalezas, debilidades y oportunidades de mejora de los procesos fomentando la cultura de la mejora continua. Teniendo en cuenta la visión general de que CMMI es de aplicación únicamente en grandes empresas, ITMark se presenta como un modelo de ajuste de CMMI en cuanto a métodos de evaluación, más sencillos y flexibles, pensando ante todo en la PYME.

3.3.5 SwTQM

La iniciativa SwTQM parte del European Foundation for Quality Management (EFQM), fundación sin ánimo de lucro con sede en Bruselas que reúne a 700 organizaciones interesadas en la consecución de la excelencia a través de la calidad de sus procesos, y el ESI (European Software Institute), como modelo de excelencia para organizaciones que desarrollan software de forma intensiva (SIO). La base principal del modelo es CMMI v1.1, y se completa con el Modelo de Excelencia de EFQM.

El modelo se destina, según la información publicada en la web de ESI, a:

• Organizaciones cuyo negocio principal es el desarrollo de sistemas de información comerciales.

• Organizaciones cuyo departamento de IT desarrolla software como parte integrante de los productos finales de la organización.

• Organizaciones cuyo departamento de IT desarrolla sistemas de información para la mejora de sus procesos de negocio.

• Departamentos de IS (Sistemas de Información) de grandes organizaciones que trabajan como unidades de negocio independientes.

El beneficio real de SwTQM, como unión de un modelo SPI y uno TQM, sería:



• Extender los objetivos de negocio de las organizaciones hacia objetivos a tener en cuenta en la mejora de procesos software.

• Integrar el desarrollo de software y los procesos de producción en la gestión de negocio.

• Proveer a las SIOs de un modelo único y completo que satisfaga los requerimientos de negocio con respecto a TQM, facilitando la implicación de los departamentos de software en sus iniciativas.

El resultado de la mejora en negocio debería cubrir mejoras implícitas en los procesos de software, y asegurar que cualquier producida en los procesos de software contribuya al negocio.

Se presenta a continuación el modelo de excelencia EFQM, una de las dos bases sobre las que se sustenta SwTQM. CMMI v1.1, por su parte, ya ha sido descrito anteriormente.

El modelo de excelencia EFQM

El modelo establece la creación de un equipo de gestión que debe adoptar ciertos conceptos básicos listados a continuación:

• Orientación a resultados dirigidos a la complacencia de todos y cada uno de los implicados en la organización.

• La excelencia se puede lograr a través del mantenimiento de la satisfacción del cliente, lo que permite crear valor sostenible para el mismo.

• Liderazgo visionario e inspirado, unido a la constancia en los propósitos.

• Gestión de la organización mediante un conjunto de sistemas, procesos y hechos interdependientes y correlaccionados.

• Maximizar la contribución de los empleados de la organización a través de su desarrollo personal e implicación en los objetivos comunes.

• Utilización del aprendizaje continuo para innovar y desarrollar oportunidades de mejora.

• Desarrollo y mantenimiento de relaciones con partners que doten a la empresa de valor añadido.

• Exceder el marco regulatorio mínimo en el cual opera la organización, esforzándose por entender y responder a las expectativas de todos los implicados en la



organización ante la sociedad. Es lo que se conoce como Responsabilidad Social Corporativa (RSC) o Responsabilidad Social Empresarial (RSE).

El modelo fue introducido en 1992 como un marco de evaluación para organizaciones de cara al European Quality Award (premio europeo de calidad). Es ampliamente usado en Europa en organizaciones muy diversas, ya que puede ser aplicado a cualquier sector, estructura, madurez o tamaño de la empresa.

Está considerado como una herramienta práctica que puede ser usado por la empresa de varias formas:

• Como herramienta para la auto-evaluación.

• Como medio de realizar un benchmarking contra otras organizaciones.

• Como guía de identificación de áreas o procesos a mejorar.

• Como estructura para el sistema de gestión de la organización.

El uso principal del modelo es la autoevaluación, de la que se obtiene un conjunto de puntos fuertes y otro de áreas susceptibles de mejora. Sobre esta base, y una vez realizado un trabajo de priorización, puede construirse un plan de acción tendente a mantener aquéllos y realizar las mejoras correspondientes a éstas.

Estructura del modelo de excelencia EFQM

El modelo de excelencia EFQM es un framework que consta de 9 criterios básicos. Cinco de ellos son los denominados “Enablers” (agentes), que cubren qué hace la organización. Los otros cuatro, “Results” (resultados), cubren lo que la organización consigue. Los resultados son causados por los agentes, y permiten la mejora de éstos mediante el feedback que ofrecen. El Gráfico 4 muestra el diagrama de su estructura, con la premisa clara de que la innovación y el aprendizaje son la pieza básica para obtener la mejora en el sistema.




Gráfico 4: Estructura del modelo de excelencia de EFQM

Liderazgo

Personal

Política yEstrategia

Colaboradoresy recursos

Procesos

Resultadosen Personal

Resultadosen Sociedad

Resultadosen

ClientesRendimiento

AGENTES RESULTADOS

INNOVACIÓN Y APRENDIZAJE

Fuente: EFQM13

El modelo reconoce que hay varias aproximaciones para llegar al objetivo último de la excelencia en todos los aspectos del funcionamiento. Por ello, se establece únicamente como herramienta de mejora del sistema de gestión, y por tanto no es normativa ni prescriptiva: no dice cómo hay que hacer las cosas, respetando así las características de cada organización y la experiencia de sus miembros. En cualquier caso, el modelo establece indicadores sobre cómo evaluar los resultados obtenidos, así como claves finales que ofrecen la medida del rendimiento final.

El modelo establece la siguiente lógica (semejante al modelo PDCA) a la hora de implementar EFQM:

• Se planifican los resultados deseados.

• Se desarrollan enfoques adecuados para alcanzarlos.

• Se despliegan e implantan los enfoques.

• Se evalúan los resultados obtenidos, y se revisan los enfoques.

13 (http://www.efqm.org)

http://www.efqm.org/


Datos de implantación

Realizando una búsqueda en la base de datos de EFQM en agosto de 2007, aparecen 10 empresas TIC españolas incluidas en el sello “Club Excelencia en Gestión”, como se ve en la Tabla 4.

Tabla 5: Empresas con el sello de excelencia EFQM (Club Excelencia en Gestión)

Sello de calidad Entidades españolas Empresas TIC EFQM Commited to Excellence 163 5 EFQM Recognised to Excellence 52 4 EFQM European Quality Awards 10 1

Fuente: EFQM

La evolución a SwTQM

El modelo SwTQM se crea con la mentalidad de la mejora de procesos como eje del cambio en las organizaciones hacia sistemas de excelencia, y se piensa en las bondades de unir un modelo de excelencia en la gestión como EFQM, y un modelo SPI (Software Process Improvement, mejora de procesos de software) como CMMI v1.1, orientado además al desarrollo de software. Ambos modelos son distintos, en cuanto a los enfoques de partida, pero complementarios según los diseñadores de SwTQM.

De esta forma, EFQM:

• Se centra en TQM (Total Quality Management), gestión total de la calidad.

• Instituye un marco de trabajo con el objetivo puesto en la excelencia del negocio.

• Independiente de cualquier sector en que se aplique.

• Enfocado en el cliente.

• El papel principal lo juega la gerencia.

En cambio, CMMI:

• Se centra en SPI (Software Process Improvement), mejora de procesos de software).

• Es una guía de mejora de procesos de desarrollo en el marco de la seguridad de la información.

• Dirigido a unidades de IT/IS.



• Los gestores de proyectos juegan un papel fundamental.

Los dos puntos de vista sobre la mejora de la calidad se amoldan en un modelo común a partir de una situación inicial básica:

• La calidad del software se centra normalmente en modelos SPI.

• No hay muchas aplicaciones o adaptaciones de EFQM a empresas desarrolladoras de software.

• Es difícil para una SIO (organización intensiva en software) incluir los procesos relacionados con el desarrollo del software como procesos clave a la vista de los propietarios de los procesos de negocio.

• El desarrollo de software se ve a menudo desde la gerencia como una “caja negra”.

• Usualmente, los objetivos y estrategias de negocio no están suficientemente representadas en las iniciativas de mejora de procesos de software.

• Los procesos de desarrollo de software clave y sus resultados (el software en sí) no son monitorizados por la gerencia de negocio.

Por tanto, la aproximación a la calidad de los procesos de software se realiza mediante mejora de procesos (SPI), mientras que los propios departamentos de IS que implementan estos modelos no se ven realmente envueltos en las iniciativas de TQM.

El reflejo de estos puntos de vista sobre un modelo común se describe bajo la metodología RADAR (Results-Approach-Deployment-Assessment&Review), utilizada en EFQM. Las nuevas áreas y mejoras derivadas de la aplicación de un modelo SPI (CMMI v.1.1) sobre el anterior TQM (EFQM) se reflejan en un nuevo RADAR en la forma siguiente:

• Approach: Atributo que soporta política y estrategia (EFQM), y establece la política de planificación y realización del proceso (CMMI).

• Deployment: Implementación de la política diseñada en la fase Approach de forma estructurada y coherente (EFQM), y evalúa objetivamente la adherencia del proceso a su descripción, estándares, políticas, etc., delimitadas en la fase anterior según un control y métricas definidas de cara a su posible corrección (CMMI).

• Assessment&Review: Medición regular de la efectividad de las fases anteriores Approach y Deployment (EFQM), y medida de los resultados de la elaboración de productos mediante el control de los procesos (CMMI).



• Results: Control del buen rendimiento en negocio (EFQM), y del buen rendimiento en la implementación de mejoras según SPI (CMMI).

3.3.6 TickIT

En 1991, el Consejo Nacional de Acreditación de los Organismos de Certificación (National Accreditation Council of Certification Bodies, NACCB), introdujo en el Reino Unido el programa TickIT como respuesta a las quejas emitidas por las empresas dedicadas a la elaboración de software con respecto a la calidad y consistencia de las evaluaciones para la certificación ante la norma ISO 9001; el objetivo del programa TickIT era ayudar a las organizaciones de software a crear sistemas de calidad que agregaran valor a sus empresas y que cumplieran con la norma ISO 9001. Ha sido aprobada como norma por UKAS (United Kingdom Accreditation Service) y el SWEDAC (Swedish Board for Accreditation and Conformity Assessment).

Estructura del modelo

En términos generales al proceso de desarrollo de software se adoptan normalmente los siguientes elementos del modelo:

• Análisis y especificación de los requerimientos del sistema de información asegurando que sean revisados y acordados con el cliente.

• Planificación, control y supervisión del avance del desarrollo respecto al plan comunicando a las partes afectadas y que avise oportunamente de los problemas potenciales.

Específicamente en Calidad:

• Exige planificación de las actividades de calidad en los proyectos, especificando las inspecciones, revisiones y pruebas requeridas durante el desarrollo.

• Exige inspecciones de los productos usando como referente los estándares y requerimientos aplicables.

• Exige pruebas de los entregables del diseño para verificar que satisfagan la especificación.

• En integración se proponen pruebas e inspecciones del sistema, para demostrar que el sistema integrado funciona correctamente y satisface su especificación.

• Exige la identificación, segregación, investigación y corrección de productos no conformes, en la línea de ISO 9001.



El objetivo fundamental de TickIT es proveer a la industria del software de un esquema práctico completo para la gestión de la calidad en el desarrollo, mediante la publicación de material guía para asistir a las organizaciones que desarrollan software en la interpretación de la norma ISO 9001, la preparación de un cuerpo de auditores en TI, y la creación de reglas para la acreditación de entidades certificadoras. La última versión de este modelo se centra, pues, en permitir una adaptación de las empresas de desarrollo a la norma ISO 9001:2000. Por ello, el punto fundamental de la guía es la descripción de las Buenas Prácticas recomendadas proceso a proceso, tal y como se identifican éstos en la ISO/IEC 12207, de forma que la adopción del modelo lleve al cumplimiento inmediato de ISO 9001:2000.

En referencia a la mejora de procesos, TickIT no especifica ningún método para ser realizada, por lo que debe ser realizada según modelos externos. Las recomendaciones de la guía únicamente presentan casos prácticos de adopciones de EFQM, ISO/IEC 15504 y CMMI.

Los procedimientos de certificación en TickIT se relacionan con los de ISO 9001:2000. Los auditores que pretenden certificar en este modelo aplican los requerimientos de ISO 9001:2000 a empresas de desarrollo software, por lo que se les exige la asistencia a los cursos de IQA IRCA (International Register of Certificated Auditors).

3.3.7 ITIL (IT Infrastructure Library)

ITIL (IT Infrastructure Library) es un marco de trabajo para la administración de procesos de IT en una organización. Desarrollado en su primera versión a fines de la década de los 80 por la OGC (Office of Government Commerce), se ha convertido en un estándar de facto para servicios de IT.

La nueva edición de ITIL, versión 3, de junio de 2007 (que consta de cinco libros principales y diversos suplementos complementarios, cada uno de los cuales aportan guías para afrontar y resolver retos específicos) se centra en el ciclo de vida de los servicios, y gira alrededor de conceptos como estrategia, diseño, transición, operación y mejora continua del servicio. Siguiendo un esquema de círculos concéntricos, en el nivel exterior se ofrece información que ayuda a los departamentos de TI a adaptar el despliegue de los principios centrales de ITIL a las condiciones económicas y estrategias organizativas de cada empresa.

Los cambios fundamentales incluidos en ITIL 3.0 hacen referencia a la gestión del despliegue, añadiendo mejores prácticas relativas a la actualización y lanzamiento de nuevo software, así como a las instalaciones automatizadas. Otro cambio clave afecta a la visión estratégica de los servicios. Si, por ejemplo, en las versiones previas la gestión de los servicios aparecía como un área de interés exclusivo para los departamentos de TI, en la versión 3.0 cobra importancia, dirigiéndose también al personal ejecutivo, por cuanto




crea valor añadido y ayuda a comprender las ventajas de alinear la tecnología con el negocio.

Asimismo, la actualización de ITIL ayuda a alinear sus mejores prácticas con las recogidas en otros marcos de referencias, como COBIT (Control OBjectives for Information and related Technology).

ITIL define, en un framework de procesos de IT no propietario, cómo se aplica en una organización la Gestión del Servicio, mediante una terminología estándar basada en “Buenas Prácticas” independiente de tecnología y proveedores, e incluye interdependencias entre los procesos. Así mismo, define claramente “qué hacer” y “qué no hacer”. Cada libro describe un proceso crítico para la administración de servicios IT, y describe los procesos requeridos para el manejo eficiente y efectivo de la infraestructura, garantizando los niveles de servicio establecidos entre la organización y sus clientes.

Gráfico 5: Estructura del modelo ITIL

Clientes

Centro de Atención al Cliente

Equipo de Servicio

Entrega delServicio

Integracióndel Servicio

Equipo de Soporte

Desarrollo

Proveedores

Fuente: Desarrollo propio basado en el modelo ITIL14

El modelo se puede revisar gráficamente en la figura anterior (Gráfico 5). Los componentes que aparecen en el mismo son:

• Clientes: Exigen funcionalidades y resultados, sin conocimiento de la implantación de modelos internos.

• Service Desk: Punto de contacto con el cliente. 14 Information Technology Infrastructure Library, es un conjunto de conceptos y técnicas para la gestión de la tecnología de la información (IT) la infraestructura, el desarrollo y las operaciones.



• Equipo de Servicio: Soportan los distintos procesos internos.

• Equipo de Soporte: Estandarización y coordinación de actividades entre los Equipos de Servicio.

• Desarrollo: Creación de nuevos proyectos y servicios.

Costes de implantación

Se incluyen a continuación los tiempos estimados de implantación/adaptación de cada proceso perteneciente al estándar ITIL, diferenciando si se trata de una PYME o de una gran empresa.

Tabla 6: Tiempo de implantación de los procesos ITIL

Tiempo de implantación

Proceso ITIL PYME Gran empresa Administración de Incidentes y Service Desk 3-6 meses 6-24 meses Administración de Configuración 3-4 meses 4-12 meses Administración de Problemas 1-3 meses 3-4 meses Administración de Cambios 1-3 meses 3-5 meses Administración de Release 1 mes 1-2 meses Administración de Disponibilidad 3-6 meses 6-9 meses Administración de Capacidad 4-6 meses 6-12 meses Administración Continua de Servicios TI 3-6 meses 6-12 meses Administración Financiera 4-6 meses 6-9 meses Administración de Niveles de Servicios 2-4 meses 4-6 meses

Fuente:ITIL 15

3.3.8 PSP (Personal Software Proccess)

El Proceso Personal de Software (PSP)16 fue propuesto por Watts Humphrey (perteneciente al SEI) en 1995 y estaba dirigido a estudiantes. A partir de 1997, con el lanzamiento del libro "An introduction to the Personal Software Process", se dirige ahora a ingenieros principiantes.

PSP se concentra en las prácticas de trabajo de los ingenieros en una forma individual y su meta es la producción de software de calidad. PSP se diseñó para enseñar a profesionales a cómo planear y darle un seguimiento a su trabajo, a utilizar un proceso

15 http://www.itil.co.uk 16 http://www.sei.cmu.edu/tsp

http://www.itil.co.uk/



bien definido y medido, a establecer metas mesurables, y a la utilización del rastreo constante para alcanzar dichas metas.

PSP demuestra a los ingenieros cómo manejar la calidad desde el principio del trabajo, a cómo analizar los resultados de cada trabajo, y a cómo utilizar los resultados para mejorar el proceso del proyecto siguiente.

El diseño de PSP se basa en los siguientes principios de planificación y de calidad:

• Cada ingeniero es esencialmente diferente (para ser más precisos, los ingenieros deben planificar su trabajo y basar sus planes en sus propios datos personales).

• Para mejorar constantemente su funcionamiento, los ingenieros deben utilizar personalmente procesos bien definidos y medidos.

• Para desarrollar productos de calidad, los ingenieros deben sentirse personalmente comprometidos con la calidad de sus productos.

• Cuesta menos encontrar y arreglar errores en la etapa inicial del proyecto que encontrarlos en las etapas subsecuentes.

• Es más eficiente prevenir defectos que encontrarlos y arreglarlos.

La estrategia total de PSP es cerciorarse de que todos los componentes individuales se desarrollen con la más alta calidad. Y lo logra proporcionando un marco de proceso personal ya definido que el programador puede utilizar. Este marco es el siguiente:

• Desarrollar un plan para cada proyecto y/o componente.

• Registrar su tiempo de desarrollo.

• Registrar sus defectos.

• Conservar sus datos en informes del proyecto.

• Utilizar sus datos para planear los proyectos y/o los componentes futuros.

• Analizar sus datos para desarrollar sus procesos con más calidad para mejorar su funcionamiento.


Se definen en PSP una serie de KPA (Key Proccess Areas, Áreas Clave de Proceso) que deben ser cumplidas en su totalidad para poder progresar al siguiente nivel garantizando



una mejora en la calidad. Los siguientes son los niveles existentes y las KPAs que se manejan en cada uno:

• Nivel 2 - Inicial:

o Seguimiento y control de proyectos.

o Planificación de los proyectos.

• Nivel 3 - Repetible:

o Revisión entre compañeros.

o Ingeniería del producto de software.

o Manejo integrado del software.

o Definición del proceso de software.

o Foco del proceso de software.

• Nivel 4 - Definido:

o Control de calidad.

o Administración cuantitativa del proyecto.

• Nivel 5 - Controlado:

o Administración de los cambios del proceso.

o Administración del cambio tecnológico.

o Prevención de defectos.

3.3.9 ISO/IEC 20000

La serie ISO/IEC 20000 - Service Management, normalizada y publicada por las organizaciones ISO (International Organization for Standardization) e IEC (International Electrotechnical Commission) el 14 de Diciembre de 2005, es el estándar reconocido internacionalmente para la gestión de servicios de TI (Tecnologías de la Información). La serie 20000 proviene de la adopción de la serie BS 15000 desarrollada por la entidad de normalización y certificación británica BSI - British Standard Institute.


El estándar se organiza en dos partes:



• Parte 1: ISO/IEC 20000-1:2005 - Especificación (preparada por BSI como BS 15000-1).

• Parte 2: ISO/IEC 20000-2:2005 - Código de Prácticas (preparada por BSI como BS 15000-2).

La primera parte (Especificación) define los requerimientos (217) necesarios para realizar una entrega de servicios de TI alineados con las necesidades del negocio, con la calidad y el valor añadido para los clientes, asegurando una optimización de los costes y garantizando la seguridad de la entrega en todo momento. El cumplimiento de esta parte, garantiza además, que se está realizando un ciclo de mejora continua en la gestión de servicios de TI. La especificación supone un completo sistema de gestión (organizado según ISO 9001) basado en procesos de gestión de servicio, políticas, objetivos y controles. El marco de procesos diseñado se organiza en base a los siguientes bloques:

• Grupo de procesos de Provisión del Servicio.

• Grupo de procesos de Control.

• Grupo de procesos de Entrega.

• Grupo de procesos de Resolución.

• Grupo de procesos de Relaciones.

La segunda parte (Código de Prácticas) representa el conjunto de mejores prácticas adoptadas y aceptadas por la industria en materia de Gestión de Servicio de TI. Está basada en el estándar "de facto" ITIL (Biblioteca de Infraestructura de TI) y sirve como guía y soporte en el establecimiento de acciones de mejora en el servicio o preparación de auditorías contra el estándar ISO/IEC 20000-1:2005.

La aparición de la serie ISO/IEC 20000 ha supuesto el primer sistema de gestión en servicio de TI certificable bajo norma reconocida a nivel mundial. Hasta ahora, las organizaciones podían optar por aplicar el conjunto de mejoras prácticas dictadas por ITIL (completadas por otros estándares como CMMI o CoBIT) o certificar su gestión contra el estándar local británico BS 15000. La parte 1 de la serie, ISO/IEC 20000-1:20005 representa el estándar certificable. Desde principios de 2007, las entidades que desean certificarse contra la versión de la norma española pueden realizarlo en AENOR. Dicha




entidad recibió en 2006 por itSMF17 la versión traducida de la norma UNE correspondiente a la norma ISO/IEC 20000.

3.4 Normas, modelos y certificaciones orientadas al producto

3.4.1 TPI/TMAP

TPI (Test Process Improvement) está basado en las mejores prácticas de la industria relativas a la mejora del proceso de pruebas y orientado al producto final. El modelo incluye guías prácticas para evaluar el nivel de madurez del proceso de pruebas de una organización, así como los pasos para mejorar este proceso. Es certificable bajo la evaluación TMAP, y tanto este esquema de certificación como el modelo TPI son propietarios de Sogeti18.


El modelo se compone de 20 Áreas Claves, que constituyen la base para mejorar y estructurar el proceso de pruebas, tal y como se muestran en el Gráfico 6.

Gráfico 6: Estructura del modelo TPI

Estrategia de testUso ciclo de vidaMomento de participación

Estimación y planificaciónTécnicas de especificación de testTécnicas de test estáticasMétricas

Automatización de testing Entorno de test Entorno de oficina

Dedicación y motivaciónFunciones de test y formaciónCampo de aplicación de la metodologíaComunicaciónReportingGestión de defectosGestión de TestwareGestión del proceso de test

EvaluaciónWhite Box testing

Ciclo de Vida

Técnicas

Infraestructuras

Organización

General

Fuente: Elaboración propia basado en el modelo TPI

17 IT Service Management Forum (itSMF) es la única organización internacional independiente reconocida, dedicada a la gestión de servicios de TI. 18 http://www.es.sogeti.com


El enfoque sobre estas áreas, según TPI, contribuye a la mejora de los procesos de prueba en la forma siguiente:

• Estrategia de Pruebas: Enfocada a detectar los fallos más importantes de la forma más temprana y económica posible. Define qué pruebas cubren los requerimientos y cómo se mitigan los diferentes riesgos detectados.

• Uso de Ciclo de Vida: Define las fases del proyecto junto a las actividades y procedimientos para mejorar la predicción y control del proceso de pruebas.

• Momento de Participación: Una participación temprana es significativamente más beneficiosa.

• Estimación y Planificación: Indica qué actividades deben realizarse, cuándo y por quién.

• Técnicas de Especificación: Define la manera de obtener casuística de pruebas con la información disponible.

• Técnicas de Pruebas Estáticas: Inspección y/o evaluación sin la necesidad de ejecutar programas.

• Uso de Métricas: Son las observaciones cuantificadas acerca de un proceso o producto.

• Herramientas de Pruebas: Nivel de uso e implantación.

• Entornos de Pruebas: Mide la gestión, disponibilidad, disponibilidad, estabilidad, flexibilidad, veracidad, etc.

• Entorno de Oficina: Mide las facilidades de oficina y su organización.

• Compromiso y Motivación: Refleja los niveles en que se involucran los diferentes miembros del proyecto.

• Funciones de Test y Formación: Mide la organización interna del equipo de pruebas.

• Alcance de la Metodología: Mide la coherencia, homogeneidad y adaptabilidad.

• Comunicación: Refleja el buen uso de los diferentes canales de comunicación disponibles.

• Reporting: Mide la capacidad de informar de manera efectiva acerca del producto probado y del proceso de pruebas.



• Gestión de Defectos: Mide el buen uso del ciclo de vida y las cualidades que puedan obtenerse de cada defecto.

• Gestión del Testware: Refleja el nivel de reutilización de los diferentes productos de test generados.

• Gestión del Proceso de Pruebas: Tiene vital importancia de cara a la futura optimización de las pruebas.

• Evaluación: Considera el nivel de uso de evaluaciones internas a lo largo de los procesos de pruebas.

• White Box Test: Mide el nivel de conocimientos técnicos durante las pruebas de bajo nivel (unitarias).

Evaluación bajo TMAP

Para una evaluación de los procesos bajo TMAP, metodología oficial para la evaluación de TPI, propietaria de Sogeti, es imprescindible el compromiso de todos los implicados en el proceso de mejora. Por tanto, se deben considerar como factores de mejora el compromiso de la dirección, el sentido de urgencia, la visibilidad de las mejoras, la implicación de todos los agentes en el cambio y la consistencia (entre procesos, formación, recursos, etc.).

Como paso previo deben tenerse en cuenta los objetivos y el alcance de la mejora, como pueden ser la velocidad/coste del testing, los procesos de prueba susceptibles de mejora, el plazo para la realización del cambio, y el esfuerzo que se va a dedicar.

Para esta evaluación de la situación actual, el modelo TPI ofrece un marco de referencia objetivo para analizar los puntos fuertes y débiles del proceso de testing, mediante:

• Entrevistas con personal clave.

• Estudio de documentación.

• Puntuar los procesos contra el modelo TPI.

• Descripción de las características de la situación actual.

• Establecer el nivel de madurez deseado.

Con ello se definen las acciones de mejora, a partir de los objetivos de mejora establecidos, y de los resultados de la evaluación. Las acciones se determinan de tal manera que sea posible ir mejorando paso a paso. Las mejoras se identifican en base a la puntuación actual y el nivel deseado de cada una de las 20 áreas, y se debe realizar un Estudio sobre la certificación de la calidad del software en España Página 63 de 147 Observatorio de la Seguridad de la Información Laboratorio Nacional de Calidad del Software


proceso de inventariado de las dependencias entre las mejoras, su priorización, y definir los resultados de cada mejora de manera SMART (eSpecífico, Medible, Alcanzable, Realista, definido en el Tiempo).

Tras ello, TPI especifica la necesidad de definición de un plan detallado para la implantación de las acciones de mejora a corto, medio y largo plazo, la definición de responsabilidades, la implantación de las mejoras, la coordinación del proceso de cambio, la identificación de los puntos de medición, y un Plan de comunicación adecuado a los cambios efectuados en le organización. La evaluación final del resultado de las acciones de mejora, a través de la medición del nivel de éxito en relación con objetivos iniciales, debe determinar la necesidad de redefinir las mejoras a implantar o ajustar el plan de mejora.

Como resumen, la evaluación de TPI incluye la evaluación de la situación del proceso de pruebas contra una matriz de madurez, en que se refleja la puntuación de cada Área Clave para el conjunto de todas ellas en el modelo TPI, y ofrece como resultados tanto la matriz de madurez como las acciones de mejora de testing a corto plazo (proyecto piloto), a medio plazo (ampliación del alcance en la organización), a largo plazo (consolidación en la organización de la metodología), y un plan completo de implantación.

Con respecto a la PYME o a un proceso determinado dentro de una empresa, la evaluación puede realizarse mediante TPI Quickscan, que supone la evaluación rápida de la situación del proceso de pruebas mediante la identificación de aquellas zonas claves con mayor prioridad del modelo TPI. La duración se establece entre dos y tres semanas, y ofrece un plan de mejora a corto plazo mediante la identificación de QuickWins y un plan de implantación de un proyecto piloto de pruebas.

3.4.2 ISO 9126 (Modelo de McCall)

Las normas ISO/IEC 9126, ISO 14598 e IEC establecen un modelo para medir la calidad del producto y permiten identificar los requisitos de calidad de software. La ISO 9126 (basada en el modelo de McCall) plantea un modelo normalizado que permite evaluar y comparar productos sobre la misma base.

La calidad queda definida a un alto nivel de abstracción por seis características:

• Funcionalidad: Las funciones satisfacen necesidades declaradas o implícitas.

• Fiabilidad: Capacidad de un sistema para mantener su nivel de rendimiento.

• Usabilidad: Esfuerzo necesario para el uso y la valoración individual de tal uso, por parte de un conjunto de usuarios.



• Portabilidad: Es la capacidad de un sistema para ser transferido de un entorno a otro.

• Mantenibilidad: Es el esfuerzo necesario para realizar modificaciones específicas.

• Eficiencia: Es la relación entre el nivel de prestaciones de un sistema y el volumen de recursos utilizados en condiciones declaradas.

Una mejora al nivel de abstracción planteado por la norma ISO/IEC 9126 es el modelo QUINT2, que es un superconjunto del conjunto de características y subcaracterísticas de la ISO/IEC 9126 al proporcionar métricas para medir la calidad que se basa en la dicha norma.

Los modelos planteados (ISO/IEC 9126 y su mejora Quint 2) contemplan únicamente aproximaciones a la calidad externa e interna de un producto software, por lo que la norma se revisó y se incluyó un nuevo modelo de calidad que ampliaba (ISO 14598) las características de los mismos, incluyendo:

• Calidad Interna: Mide las propiedades estáticas del código.

• Calidad externa: Mide las propiedades dinámicas del código.

• Calidad en uso: Mide grado de satisfacción de funcionalidades.

Gráfico 7: Calidad en el ciclo de vida del software, según ISO 9126

Necesidades de calidad del usuario

Requerimientos de calidad externos

Requerimientos de calidad interna

Contribuye a especificar

Contribuye a especificar

Calidad de uso

Calidad externa

Calidad interna

Indica

Indica

Uso y retroalimentación

Validación

Verificación

Fuente: Norma ISO 9126



Adicionalmente, para realizar el análisis de los requisitos de calidad de uso se usan las 4 características principales definidas en la ISO/IEC 9126: Eficacia, Productividad, Seguridad y Satisfacción. Ahora bien, no hay que olvidar, que ISO 9126 es un modelo genérico y es necesario adaptarlo para:

• Determinar que subcaracterísticas son relevantes.

• Definir métricas específicas para los componentes software.

• Definir indicadores para las características de calidad.

3.5 Otros modelos y metodologías

Las metodologías presentadas en este apartado pueden ser aplicadas por sí mismas, como método para la mejora de los desarrollos de software, o en conjunción con un modelo de mejora de procesos como CMMI ó ISO/IEC 15504, ya que éstos exigen una metodología de trabajo aunque no impongan ninguna en sus especificaciones básicas.

3.5.1 Metodología MÉTRICA 3

METRICA es una metodología para el desarrollo de sistemas de información diseñada bajo los auspicios del Ministerio de Administraciones Públicas (MAP), dentro del Plan de Acción de la Subdirección General de Coordinación de Informática. La primera versión se remonta a 1989, “METRICA V.1: Guías metodológicas”, y la segunda de 1993, con la guía técnica, de referencia y de usuario. En 1995 se liberó la versión 2.1 y en julio de 2001 se liberó la versión 3, mejora resultante de la publicación del correspondiente borrador de enero de 2001 y la consideración de las aportaciones recopiladas hasta entonces. La metodología Métrica es utilizada habitualmente como referencia en licitaciones cuyo objeto es el desarrollo de programas para ordenador publicadas por organismos de carácter institucional españoles.

Para la elaboración de METRICA V.3 se han tenido en cuenta diversos métodos (MAGERIT, Eurométodo, SSADM V4, Information Engineering), normativas internacionales (ISO 12207, ISO/IEC TR 15504/SPICE, UNE-EN ISO 9001:2000, IEEE 610.12-1990) y se han tenido en cuenta diferentes tecnologías propias de la informática y las comunicaciones (cliente/servidor, orientado a objeto, reutilización y base de datos, entre otras).

Métrica propone una descomposición de los procesos en actividades, dividiendo a su vez éstas en tareas. Para cada tarea se definen sus entradas, productos resultantes, contenido, técnicas, prácticas y participantes definiendo de forma expresa cada uno de estos elementos.

Los procesos principales de METRICA V. 3 son:



• Planificación de sistemas de información (PSI).

• Desarrollo de sistemas de información:

o Estudio de Viabilidad del Sistema (EVS).

o Análisis del Sistema de Información (ASI).

o Diseño del Sistema de Información (DSI).

o Construcción del Sistema de Información (CSI).

o Implantación y Aceptación del Sistema (IAS).

• Mantenimiento de Sistemas de Información (MSI).

METRICA Versión 3 aporta un conjunto de procesos (definidos en la metodología como interfaces) orientados a la organización y como apoyo al propio proceso de desarrollo. Estas interfaces definen un conjunto de actividades que según la propia metodología, “en el caso de existir en la organización se deberán aplicar para enriquecer o influir en la ejecución de las actividades de los procesos principales de la metodología, y que si no existen habrá que realizar para complementar y garantizar el éxito del proyecto desarrollado con METRICA V. 3”.

Los interfaces que define METRICA V. 3 son los siguientes:

• Gestión de Proyectos (GP).

• Seguridad (SEG).

• Aseguramiento de la Calidad (CAL).

• Gestión de la Configuración (GC).

La metodología METRICA V. 3 también aporta técnicas con la intención de ayudar en la obtención de los productos resultantes de las tareas definidas. Igualmente propone herramientas que permiten automatizar el desarrollo y facilitar el trabajo de los profesionales.

3.5.2 Metodología RUP

El antecedente más importante de RUP data de 1967 con la Metodología Ericsson elaborada por Ivar Jacobson, una aproximación de desarrollo basada en componentes, que introdujo el concepto de caso de uso. Posteriormente, en 1995, Rational Software Corporation adquiere Objectory AB y entre 1995 y 1997 desarrolla Rational Objectory



Process (ROP) a partir de Objectory 3.8 y del Enfoque Rational (Rational Approach), adoptando UML como lenguaje de modelado.

En junio del 1998, finalmente, se lanza Rational Unified Process (RUP), el cual es un proceso de desarrollo de software, que, junto al Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. RUP es en realidad un refinamiento realizado por Rational Software del más genérico Proceso Unificado.

El proceso de software RUP tiene tres características esenciales:

• Dirigido por los casos de uso, que son como un fragmento de funcionalidad del sistema que proporciona al usuario un valor añadido y que representan los requisitos funcionales del sistema.

En RUP los Casos de Uso no son sólo una herramienta para especificar los requisitos del sistema. También guían su diseño, implementación y prueba, sirviendo como elemento integrador a través de las fases de Requisitos, Análisis y Diseño, Implementación y Pruebas.

• Centrado en la arquitectura del sistema, que es la organización de sus partes más relevantes, elementos de calidad del sistema, rendimiento, reutilización y capacidad de evolución por lo que debe ser flexible durante todo el proceso de desarrollo. Además con ella se puede tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo.

• Iterativo e incremental, en donde el trabajo se divide en partes más pequeñas o miniproyectos, permitiendo que el equilibrio entre Casos de Uso y arquitectura se logre durante cada uno de ellos a través del proceso de desarrollo. Cada miniproyecto se puede ver como una iteración (un recorrido más o menos completo a lo largo de todos los flujos de trabajo fundamentales), del cual se obtiene finalmente un incremento que produce un crecimiento en el producto.

Bajo la metodología RUP, cada proceso puede representarse en una gráfica de dos dimensiones. Mientras que en el eje de ordenadas (Y) se colocan las actividades (modelado de negocios, requisitos, análisis y diseño, modelado, despliegue, actividades de apoyo, etc.), el eje de abscisas (X) representa el tiempo dividido en cuatro fases:

• Inicio: las iteraciones ponen mayor énfasis en actividades de modelado y requisitos.



• Elaboración: las iteraciones se orientan al desarrollo de la arquitectura, y abarcan además los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), análisis y diseño.

• Construcción: se lleva a cabo la construcción del producto por medio de las iteraciones que sean necesarias.

• Transición: se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios o clientes finales.

RUP puede ser implementada como metodología de desarrollo bajo cualquier tipo de modelo de procesos como ISO/IEC 15504, CMMI, etc.

3.5.3 Metodología Six Sigma (6-Sigma)

Fue iniciado en Motorola el año 1982 por el ingeniero Bill Smith como una estrategia de negocios y mejora de la calidad, y posteriormente mejorado y popularizado por General Electric. Esta metodología parte de la apreciación externa y compartida de los propietarios de los procesos, con el fin de evaluar los diferentes problemas o disturbios que pueden llevar a un bajo rendimiento o baja calidad de los productos terminados, así como la ineficiencia o ineficacia de los procesos de una empresa.

Se centra en dos aspectos fundamentales:

• Evaluación de los procesos y métodos productivos, de forma que puedan optimizarse tanto la eficiencia como la eficacia de los mismos. Eficiencia descrita como el ahorro de tiempo y de los recursos en los procesos, y eficacia descrita como la búsqueda de la calidad del producto terminado y entregado a tiempo.

• Creación de una conciencia global en la organización sobre del modelo y sus beneficios desde la cúpula de la empresa, y no desde los niveles más bajos. El cambio cultural debe empezar desde la cima de la organización para que el modelo tenga éxito.

La implementación de la metodología se orienta a generar una cultura de mejora continua basada en la autorrevisión. Una empresa que funcione bien bajo este modelo debe encajar bien todas las partes de la estructura orgánica de la compañía, donde todos valoran lo que se hace en equipo y se aprecia la participación de cada uno de sus miembros.

La base de la metodología es la reducción de los “defectos” del sistema, entendiéndose como “defecto” cualquier instancia en que un producto o un servicio no logre cumplir los requerimientos del cliente. Los defectos pueden ser reunidos en siete grupos: sobreproducción, corrección, inventarios, procesamiento, movimiento, transporte y espera. Controlando cada uno de estos grupos de defectos se llegan a reducir de forma efectiva



desperdicios, excedentes, minimizar esfuerzos innecesarios o pérdidas de tiempo en las operaciones productivas.

En el proceso de control de defectos, también llamado proceso de las cinco eses (5S), se sigue el siguiente modelo:

• Sifting: Examinar todo el lugar de trabajo o donde se desarrolla el proceso, analizar todos los detalles del área y prescindir de todo aquello que sea innecesario para el desarrollo de las actividades involucradas.

• Sorting: El personal que participa en el proceso debe organizar y clasificar sus herramientas de trabajo y ubicarlas en los lugares donde tenga fácil su acceso.

• Sleeping and Washing: Este paso corresponde a la limpieza y al despeje del área de trabajo. Esto no solo se refiere a la limpieza, sino también a la claridad, al orden, a que el ambiente de trabajo sea adecuado.

• Standardizing: En esta parte del método se entra a analizar los procesos operativos, buscando la minimización de sus defectos y su interacción con la cadena productiva de la empresa. Una vez hallado el método óptimo, se estandariza en la organización, creando un manual de procesos adecuado a las condiciones de la empresa, susceptible de mejora de acuerdo a los cambios y desarrollos futuros.

• Self-Discipline: La inercia que genera un proceso abierto al cambio debe generar una cultura de cambio y de mejora en los procesos productivos, involucrando para ello a toda la compañía para poder mantener su crecimiento y la continua mejora de los procesos.

El método de las 5S conduce a la excelencia en la organización (6S), y requiere de un cambio cultural, de un desarrollo sistemático y organizado para llegar a la misma.

Debido a la visión anterior, en la resolución de problemas operacionales se siguen métodos sistemáticos de análisis como es el MAMC (Medir – Analizar – Mejorar – Controlar), en la que la fase de "Medir" se enfoca en la globalidad del proyecto, siendo esta una etapa de observación y detalle para identificar los posibles problemas que se puedan presentar. En la etapa de "Analizar" se entra en los detalles del proceso y en la secuencia que se sigue para la identificación del origen del problema que presenta el proceso, descubriendo las posibles causas que plantean las hipótesis, para debatir posteriormente sobre la causa final y las partes que están involucradas en la misma.

En la fase de "Mejorar" se determinan las alternativas de posibles soluciones. De esta forma, sin perder de vista el objetivo del proyecto, se establece la mejor solución adecuada a las condiciones de desarrollo de procesos o del proyecto. Finalmente, la etapa



"Controlar" corresponde a la implementación de la solución, en que se usan los sistemas de control de calidad para institucionalizar el proceso evitando que el problema vuelva a ocurrir.

De la misma manera, se puede emplear el método NPR (Número de Probabilidad del Riesgo) como base para realizar un análisis de Pareto, con el fin de atacar las causas más frecuentes de los problemas más comunes de las compañías y sus procesos.

3.5.4 Metodología MSF

MSF es la metodología empleada por Microsoft para el desarrollo de software. Hasta su versión 3, de 2005, MSF se definía como un marco de desarrollo flexible para adaptarse a las necesidades de cada proyecto, en oposición a lo que sería una metodología prescriptiva, dado que parte de la premisa de que no hay una estructura de procesos óptima para las necesidades de todos los entornos de desarrollo posibles.

• Los principios fundamentales del marco MSF son los siguientes:

o Fomentar la comunicación abierta.

o Trabajar en torno a una visión compartida.

o Apoderar a los integrantes del equipo (“empowerment”).

o Establecer responsabilidades claras y compartidas.

o Centrar el objetivo en la entrega de valor para el negocio.

o Permanecer ágiles y esperar el cambio.

o Invertir en calidad.

o Aprender de la experiencia.

En 2005, el desarrollo del nuevo producto de Microsoft “Visual Studio 2005 Team System” ha causado una evolución de MSF hacia la nueva versión 4.0 con dos líneas paralelas:

• Microsoft Solutions Framework (MSF) for CMMI Process Improvement: Abarca los procesos de análisis de requerimientos, aprobaciones, revisiones formales, gestión de cambios, actividades de mejora de procesos, pruebas de contexto, desarrollo (dirigido por pruebas), pruebas funcionales, y planificación iterativa.

• Microsoft Solutions Framework (MSF) for Agile Software Development: Abarca únicamente los procesos orientados a desarrollo, pruebas (pruebas de contexto, desarrollo dirigido a las mismas y pruebas funcionales), y planificación iterativa.



3.5.5 Métodos ágiles

En marzo de 2001, un grupo liderado por Kent Beck (desarrollador de la metodología XP (eXtreme Programming) se reunió en Salt Lake City para discutir sobre los modelos de desarrollo de software existentes. De la reunión surgió el término “Métodos Ágiles” para definir a aquellos que estaban surgiendo como alternativa a las metodologías formales, (como CMM-SW, ó SPICE) a las que consideraban excesivamente rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas, previas al desarrollo.

Los integrantes de la reunión resumieron en cuatro postulados lo que ha quedado denominado como “Manifiesto Ágil”, que compendia el espíritu en el que se basan estos métodos. En la actualidad hay aproximaciones que combinan lo mejor de ambos enfoques (formal y ágil).

Como características principales comunes de estos métodos cabe destacar:

• Recogen técnicas contrastadas por profesionales reconocidos.

• Cada uno tiene sus características propias y cubre un rango de áreas de procesos más o menos amplias, con tendencia a combinarlas para dar mayor cobertura en el ciclo de vida del desarrollo del software.

• Han surgido de entornos reales de desarrollo de software, por lo que aparentemente responden mejor a la realidad del software y a las diferencias con producción industrial.

Se incluyen a continuación breves reseñas de los métodos más destacados y con más amplia difusión del grupo de modelos ágiles.

XP (eXtreme Programming)

Es el método que más popularidad ha alcanzado entre las metodologías ágiles, y posiblemente sea también el más trasgresor de la ortodoxia basada en procesos. Su creador, Kent Beck fue el alma mater del Manifiesto Ágil.

Extreme Programming (XP) se rige sobre la suposición de que es posible desarrollar software de gran calidad a pesar, o incluso como consecuencia, del cambio continuo. Su principal asunción es que con un poco de planificación, un poco de codificación y unas pocas pruebas se puede decidir si se está siguiendo un camino acertado o equivocado, evitando así tener que echar marcha atrás demasiado tarde.

Además XP pone en comunicación directa y continua a clientes y desarrolladores. El cliente se integra en el equipo para establecer prioridades y resolver dudas. De esta forma ve el avance día a día, y es posible ajustar la agenda y las funcionalidades de forma consecuente. La metodología se basa en el desarrollo incremental de pequeñas partes, Estudio sobre la certificación de la calidad del software en España Página 72 de 147 Observatorio de la Seguridad de la Información Laboratorio Nacional de Calidad del Software


con entregas y pruebas frecuentes y continuas, y proporciona un flujo de retro-información valioso para detectar los problemas o desviaciones.

• Los fallos se localizan muy pronto.

• La planificación no puede evitar algunos errores, que sólo se evidencian al desarrollar el sistema.

• La retro-información es la herramienta que permite reajustar la agenda y los planes.

XP no es un modelo de procesos ni un marco de trabajo, sino un conjunto de 12 prácticas que se complementan unas a otras y deben implementarse en un entorno de desarrollo cuya cultura se base en cuatro valores fundamentales: comunicación, feedback, coraje (toma de decisiones difíciles), y simplicidad. Las prácticas son las siguientes:

• Prácticas de codificación:

o Simplicidad de código y de diseño para producir software fácil de modificar.

o Reingeniería continua para lograr que el código tenga un diseño óptimo.

o Desarrollar estándares de codificación, para comunicar ideas con claridad a través del código.

o Desarrollar un vocabulario común, para comunicar las ideas sobre el código con claridad.

• Prácticas de desarrollo:

o Adoptar un método de desarrollo basado en las pruebas para asegurar que el código se comporta según lo esperado.

o Programación por parejas, para incrementar el conocimiento, la experiencia y las ideas.

o Asumir la propiedad colectiva del código, para que todo el equipo sea responsable de él.

o Integración continua, para reducir el impacto de la incorporación de nuevas funcionalidades.

• Prácticas de negocio:



o Integración de un representante del cliente en el equipo, para encauzar las cuestiones de negocio del sistema de forma directa, sin retrasos o pérdidas por intermediación.

o Adoptar el juego de la planificación para centrar en la agenda el trabajo más importante.

o Entregas regulares y frecuentes para satisfacer la inversión del cliente.

o Ritmo de trabajo sostenible, para terminar la jornada cansado pero no agotado.

Agile SPI

Desarrollado en el marco del proyecto SIMEP-SW, en Colombia, Agile SPI (Software Process Agile Improvement) parte de la premisa fundamental en este tipo de métodos de que los modelos utilizados sean ligeros, basados en estándares internacionales, y acordes a las características, idiosincrasia y circunstancias de la realidad socio-económica de la industria de software colombiana.

La arquitectura preliminar de Agile SPI consta de los siguientes componentes:

• Agile SPI Process: Implantación de un proceso ágil que guíe a un programa de mejora de procesos.

• Light SPI Evaluation Model: Un modelo ligero de evaluación del proceso productivo.

• Light SPI Metrics Quality Model: Un modelo ligero de métricas del proceso productivo.

• Framework PDS: Un marco conceptual y tecnológico para soportar los procesos.

• Light SPI Quality Model: Un modelo de calidad ligero.

3.6 Herramientas de apoyo

La implantación de cualquiera de los modelos anteriormente presentados requiere de la utilización de herramientas de apoyo para cada una de sus fases o áreas claves.

Se presentan a continuación algunas de las herramientas que el mercado ofrece para cada una de estas áreas, como muestra de lo que una empresa podría adquirir en el mercado español, según las necesidades que pueden surgir a la hora de la implantación de un modelo de mejora de procesos o de producto. Como se podrá ver en esta muestra, la mayoría de las compañías importantes ofrecen soluciones integradas para todas las fases del ciclo de vida del software (ELM ). No obstante, todas están diseñadas mediante



componentes que pueden ser adquiridos individualmente para dar solución a problemas en etapas determinadas del modelo elegido, o ser integrados con aplicaciones o herramientas ya existentes.

Dado que los métodos de licenciamiento de estas herramientas son muy variados, y en ocasiones dependen directamente del tamaño de la empresa, número de usuarios, o instalaciones en base de datos, no se pueden ofrecer costes asociados a su adquisición.

Se han obviado en la muestra los productos ofimáticos que únicamente permiten la realización de diagramas PERT o GANTT para los procesos de gestión de proyectos, ya que son de sobra conocidos.

3.6.1 IBM - Rational Software

Las herramientas de IBM, bajo el sello Rational Software, ofrecen un conjunto completo de aplicaciones dirigidas a cada uno de los agentes que deben poner en práctica los procesos implementados bajo un modelo como CMMI. Pueden ser adaptados para el trabajo con otro tipo de modelos semejantes a CMMI e, incluso, ser utilizadas como herramientas sin integración bajo modelos distintos a éste.

En su portafolio de productos, Rational Software posee las siguientes herramientas y soluciones ejecutadas sobre la plataforma Eclipse:

• Para uso del analista: Rational RequisitePro. Repositorio central de requisitos accesible a los grupos de ingeniería. Permite la identificación, documentación y aprobación de requisitos, así como su gestión histórica, trazabilidad de los mismos y el análisis de impacto de cada uno de ellos. Se ofrece como la base para la planificación del proyecto.

• Para uso del arquitecto de software y los desarrolladores: Rational Software Architect y Rational Data Architect. Herramientas ambas que permiten el diseño y construcción de aplicaciones en Java y C++. Permite sincronizar el modelado (mediante un módulo de modelado en lenguaje UML) con el código, así como la realización de pruebas unitarias sobre los elementos desarrollados (validación estática y pruebas de rendimiento).

• Para uso de los probadores del software: Rational Manual Tester, Rational Functional Tester, Rational Performance Tester: Estas tres tipos de herramientas. se integran en el ciclo de vida del software para permitir la realización de pruebas a los analistas (fase de planificación), a los arquitectos y desarrolladores (fase de diseño e implementación), y a los probadores (fases de ejecución y validación). Su uso conjunto con el Rational ClearQuest permite al project manager la generación



de informes sobre cada una de las etapas, e iniciar directamente peticiones de cambio sobre los inputs recibidos en cada una de las fases.

• A nivel directivo se ofrecen herramientas para el uso del equipo de gestión del proyecto, como es el caso de Rational MethodComposer, Rational ClearCase, Rational ClearQuest y Rational Project Console, o para el uso de la Dirección de IT, Rational Portfolio Manager.

o El Rational MethodComposer, es una herramienta dirigida como ayuda a la definición de procedimientos y documentación para el modelo CMMI y derivados. En cada fase de este modelo indica cuestiones sobre qué, cómo, cuándo y quién debe hacer cada una de las tareas asociadas. Es válida para cualquier tipo de desarrollo software, y se basa a su vez en una “instanciación” de la metodología RUP, anteriormente descrita, como soporte al modelo CMMI.

El uso de RUP define desde el Method Composer las mejores prácticas orientadas al equipo de desarrollo, guiando a éste en la toma de requisitos, análisis, modelado visual y desarrollo, pruebas automáticas, gestión del proyecto y la gestión de la configuración del software.

o Rational ClearCase, esta herramienta está destinada a la gestión de la configuración. Almacena de forma segura los artefactos de software producidos a lo largo de su ciclo de vida. Posee control del versionado de todos los artefactos (código, modelos, pruebas, etc.). Permite la gestión del trabajo en equipo y desarrollo en paralelo, así como la gestión de los espacios de trabajo de todos los grupos, y preparar compilaciones automáticas de código.

o Rational ClearQuest: Herramienta destinada a la gestión del cambio. Provee del sistema necesario para el trabajo en equipo, la gestión y monitorización de actividades, la gestión y control del proyecto, el diseño de métricas para el análisis del estado del proyecto, y el establecimiento de workflows para cada tipo de actividad.

o Rational Project Console: Herramienta que permite implementar métricas para la medida y análisis del progreso del proyecto. Recoge datos automáticamente, los filtra según los parámetros configurados, y relaciona las medidas obtenidas entre proyectos, productos y tiempo, ofreciendo además la posibilidad de presentar al usuario un estado objetivo del proyecto.



o Rational Portfolio Manager. Esta herramienta permite su utilización por gestores, jefes de proyectos y otros miembros del equipo, que lo pueden alimentar mediante la introducción directa de datos. El uso que los gestores pueden dar a la herramienta es para visualizar y gestionar portafolios de proyectos, de forma que se puedan tomar decisiones objetivamente, y transformar estas decisiones y otras propuestas en programas y proyectos.

Mientras que a los jefes de proyecto les permite poner rápidamente proyectos en marcha bajo la base de la experiencia y las mejores prácticas definidas en la metodología RUP. Permite, así mismo, la planificación de los recursos necesarios y el calendario para cada uno de los proyectos iniciados, además de ofrecer una completa gestión para los riesgos imprevistos.

3.6.2 Borland OPEN ALM - Gauntlet

La solución OPEN ALM (Application Lifecycle Management) de BORLAND se enfoca al modelo CMMI y sus derivados. Incluye el término “abierto” en su etiqueta comercial ya que es independiente de la metodología utilizada (METRICA3, RUP, TMAP, etc.), las herramientas utilizadas (ya sean comerciales u open source), la plataforma de desarrollo (Java, .net, C++, etc.), y las mediciones (herramientas de Borland u otro tipo).

La herramienta principal de su portafolio es Gauntlet, orientada a la realización de pruebas. Según BORLAND, esta herramienta aporta una mejora sustancial de la calidad mediante las pruebas continuas de forma consistente con la organización. Disminuye el tiempo de desarrollo ya que localiza fácilmente defectos (por lo que son corregibles rápidamente), automatiza tareas de calidad, y permite realizar una “release” del proyecto software en cualquier momento.

Así mismo, Gauntlet se orienta también al aumento de la visibilidad ante la dirección de proyecto. Permitiendo conocer la calidad y la corrección de los proyectos lo antes posible en el ciclo de vida, así como recoger y asociar datos con los sistemas de “business intelligence” disponibles en la empresa.

Existen plugins comerciales y no comerciales para la herramienta. En concreto, entre los primeros se pueden destacar Cenzic (para la detección de vulnerabilidades), Klocwork (para el análisis de defectos), Palamida (para el análisis de cumplimiento de licencias), y Fortify (para el análisis de la seguridad de la aplicación).

Gauntlet se asocia, pues, con la parte de pruebas de los modelos presentados anteriormente; ya sea como área clave en los modelos CMMI ó ISO 15504, o como



herramienta de apoyo a modelos orientados a producto, como TPI, e incluso métodos ágiles de desarrollo como XP.

3.6.3 Microsoft Visual Studio Team System - VSTS

La solución de ALM de Microsoft trata de incrementar la transparencia en proyectos, facilitar la colaboración del equipo y mejorar la calidad del software en un paquete basado en el ampliamente utilizado IDE de desarrollo Visual Studio.

VSTS está basado en el uso de MSF (Microsoft Solutions Framework), que es un conjunto integrado y configurable de procesos de desarrollo software, principios y mejores prácticas. VSTS 2005 proporciona por defecto dos plantillas de metodología MSF configurables: una de ellas basada en el modelo CMMI, y la otra en Agile Software Development. De esta forma, es la herramienta VSTS la que en realidad ejecuta los procesos indicados en las plantillas a modo de un workflow.

VSTS está diseñado para gestionar procesos del ciclo de vida del software con un alto nivel de flexibilidad, cuyos pasos están controlados, como se había comentado, por la herramienta.

3.6.4 Herramientas de Telelogic

La suite de herramientas diseñadas por Telelogic para ALM, MDD (Model Driven Architecture) y BPO (Bussiness Process Optimization) es extensa. Como muestra del portafolio de soluciones se presentan como más importantes las herramientas siguientes:

• Telelogic DOORS: Herramienta orientada a la gestión de requisitos, mediante el aseguramiento de la conformidad de los mismos con las regulaciones y estándares existentes.

• Telelogic Focal Point: Herramienta de soporte a la toma de decisiones mediante análisis, establecimiento de prioridades y visualización de los puntos más importantes parametrizados en el sistema.

• Telelogic System Architect: Herramienta destinada a la mejora del proceso de negocio (orientada a BPO), que permite la planificación, modelado y ejecución de los cambios organizativos asociados a los modelos que se pueden implantar en la empresa.

• Telelogic Tau: Herramienta destinada al diseño, desarrollo y pruebas de sistemas y software. Implementa y automatiza las mejores prácticas de ingeniería de sistemas basadas en estándares (UML, SDL, TTC), diseño y desarrollo de software, y las pruebas de todos los componentes desarrollados.




• Telelogic Synergy: Herramienta orientada a la gestión del cambio y la configuración del software.

• Telelogic Logiscope: Herramienta diseñada para el aseguramiento de la calidad del software, y que permite la detección de problemas en las primeras fases del ciclo de vida del software.

• Telelogic DocExpress: Herramienta destinada a la generación y mantenimiento de la documentación requerida por el modelo de mejora implantado en la empresa.

3.6.5 IrqA – Integral requisite analyzer

IrqA es una herramienta de gestión de requisitos diseñada por TCP (empresa radicada en Madrid), que se asocia normalmente al modelo CMMI en sus niveles 2 y 3. Soporta, además del análisis de requisitos en sí, los resultados pruebas de aceptación y validación de cara a llevar un histórico de todos aquellos requisitos modificados en el transcurso del ciclo de vida del software. Está orientada al trabajo colaborativo entre analistas, gestores del proyecto y responsables de pruebas.

Según la información obtenida de IrqA19, ofrece el soporte necesario para el ciclo de especificación, mediante modelos para la captura, análisis, construcción, validación, organización y clasificación de los requisitos, así como de la gestión de las pruebas de aceptación. Está enfocado en la explotación de la información, para lo cual se fundamenta en una base de datos RDBMS y provee un conjunto amplio de capacidades de modelado gracias al uso de XML como lenguaje de definición de datos e interfaces.

3.6.6 Subversion

Subversion es un repositorio de código fuente, destinado a servir como herramienta de gestión de la configuración. Es open source, por lo que contrariamente a las herramientas ya presentadas, no supone coste de licencia alguno.

De la misma forma que CVS, herramienta semejante de la que Subversion se erige como evolución natural, ésta es un repositorio de información instalado en un servidor dedicado que contiene todos los datos relacionados con los códigos fuente de un proyecto de software. Permite el control de versiones, modificaciones atómicas sobre los listados almacenados, y mantiene un histórico de todos los cambios efectuados de forma que es sencillo para los desarrolladores recuperar una versión anterior de sus desarrollos.

19 http://irqonline.com

http://irqonline.com/


4 LA CERTIFICACIÓN DE LA CALIDAD EN LAS EMPRESAS ESPAÑOLAS

Un rasgo claramente diferenciador del tejido empresarial español con respecto al resto de países vecinos es la fortaleza de la pequeña y mediana empresa, que atendiendo a su tamaño se define como ilustra la Tabla 7 y a su volumen de negocio como se indica en la Tabla 8.

Tabla 7: Definición de la PYME según la normativa de la Comunidad Europea (en vigor desde el 1 de enero de 2005)

Microempresa Empresa pequeña

Empresa mediana

Número de empleados Menos de 10 Menos de 50 Menos de 250 Facturación máxima (en millones de euros) 2 10 50

Valor máximo del Activo del Balance (en millones de euros) 2 10 43

Fuente: Recomendación C.E. (6 de mayo de 2003)

Tabla 8: Clasificación de las PYME por volumen de negocio

Recomendación 2003 Categoría de empresa Efectivos Volumen de negocio Balance general Mediana <250 <= 50 m € <= 43 m € Pequeña <50 <= 10 m € <= 10 m € Micro <10 <= 5 m € <= 2 m €

Fuente: Ministerio de Industria, Turismo y Comercio

Tal y como se puede comprobar en dichas tablas, se constata que las empresas españolas son en su mayoría organizaciones de menos de 10 empleados, también conocidas como microempresas. De hecho, según datos del Instituto Nacional de Estadística (DIRCE, Directorio Central de Empresas), de los más de tres millones de empresas existentes en España en el año 2006, cerca del 94% se trataba de organizaciones con menos de diez asalariados o con ningún trabajador en plantilla. Este hecho evidencia la influencia que la PYME tiene sobre la economía del país, así como sobre la sociedad en su conjunto.

El sector del software no es ajeno a esta situación y así, la estructura del sector se compone en un 99,8% de pymes, de las que más del 85% son microempresas de menos de 10 empleados. A pesar de esto, las PYME generan más del 60% del Valor Añadido en el Sector y el 70% de los puestos de trabajo.




En España existen en la actualidad 32.023 empresas dedicadas a actividades informáticas, como se ve en la Tabla 9. Un total de 31.905 (el 99,63% del total) son PYME, lo que supone que este tipo de empresas son el principal motor de la actividad informática en España.

Tabla 9: Empresas españolas dedicadas a actividades informáticas en 2006

Comunidad Autónoma Total <10 <50 <200 >200

Andalucía 3.157 3.004 116 34 3 Aragón 745 702 36 5 2 Asturias (Principado de) 436 416 18 1 1 Balears (Illes) 791 762 25 4 0 Canarias 1.135 1.101 31 3 0 Cantabria 268 257 8 2 1 Castilla y León 955 928 23 4 0 Castilla-La Mancha 584 566 18 0 0 Cataluña 7.513 7.100 337 57 19 Comunidad Valenciana 2.784 2.668 105 10 1 Extremadura 277 268 8 1 0 Galicia 1.206 1.155 45 5 1 Madrid (Comunidad de) 9.606 8.703 658 168 77 Murcia (Región de) 635 608 22 4 1 Navarra (Comunidad Foral de) 389 371 15 3 0 País Vasco 1.377 1.230 109 26 12 La Rioja 132 129 2 1 0 Ceuta y Melilla 33 33 0 0 0 Total empresas 32.023 30.001 1.576 328 118

Fuente: INE (2006)

Por otro lado y según se desprende del informe elaborado por la Asociación de Empresas de Electrónica, Tecnologías de la Información y Telecomunicaciones de España (AETIC)20, en colaboración con el Ministerio de Industria, Turismo y Comercio, el mercado interior neto (concepto que identifica el consumo de Tecnologías de la Información por parte de los usuarios finales) creció en 2006 un 8% y se situó en 11.544 millones de euros. La mayor tasa de crecimiento dentro del mercado interno se corresponde a los servicios informáticos que, con un crecimiento de 10,5%, se han situado en 4.975 millones de euros y a los servicios telemáticos e interactivos que registraron un crecimiento del 10,2% y una facturación de 849 millones de euros. El software, por su parte, experimentó un alza del 8% para situarse en 1.600 millones de euros.

20 Asociación de Empresas de Electrónica, Tecnologías de la Información y Telecomunicaciones de España (AETIC) (2006): Las Tecnologías de la Información en España


El software, por su parte, experimentó un alza del 8 por ciento para situarse en 1.600 millones. Los crecimientos más destacados se han dado en las áreas de sistemas operativos, con un 14,1 por ciento y el software para bases de datos, con un 11,6 por ciento. Por su peso en esta área, hay que destacar también el avance de las aplicaciones multimedia con un 10 por ciento de incremento.

Dentro de este importante entorno de crecimiento continuo, y a pesar de que las empresas de TI más conocidas son grandes multinacionales, el sector de T.I. se compone en un 99,8% de PYME, de las que más del 85% son microempresas de menos de 10 empleados. A pesar de esto, las PYME generan más del 60% del Valor Añadido en el Sector y el 70% de los puestos de trabajo.

Estos datos refuerzan la idea de que las PYME son uno de los grandes motores del sector de T.I., un sector en el que la gran competitividad existente hace que se busquen continuamente elementos diferenciadores ante el mercado español. El establecimiento de modelos para la mejora de los procesos internos o un sistema de pruebas del producto ofrece el punto de excelencia necesario dentro del mercado del desarrollo del software, dado que sus principales beneficios (como se podrá ver a lo largo de este informe) dotan a la empresa de calidad a la vez que un mayor control interno.

La competitividad intrínseca en este mercado, pues, ha adoptado los sellos de certificación de calidad como un paraguas bajo el que se aúnan los esfuerzos por la mejora interna, la consecución de la excelencia e, incluso, una dosis de marketing de cara al exterior que es realmente bien percibido por sus clientes.

4.1 Características especiales de la PYME

Las cifras presentadas en la introducción, en las que se indica un 99,63% de las empresas dedicadas a actividades informáticas en España son PYME, y de ellas un 93,68% son microPYME, con menos de 10 trabajadores, indican que este colectivo (especialmente las microempresas) tiene un peso específico muy importante en el desarrollo de software. Por ello, se debe incidir en ellas y presentar sus características esenciales antes de analizar los modelos de mejora presentados anteriormente.

Según las conclusiones obtenidas de las entrevistas realizadas a empresas y asociaciones empresariales, además de los autores mencionados en cada uno de los puntos abajo indicados, si realizamos un análisis muy escueto y exhaustivo de cuáles son las principales ventajas o puntos positivos que presenta una PYME, podemos observar que existen determinados aspectos que hacen que la misma presente ventajas diferenciales frente a las grandes empresas. A modo de ejemplo:

• Carácter emprendedor del gerente.




• Gran flexibilidad, en opinión de Barrutia, Churruca y Landeta21, lo que permite asimilar y hacer suya cualquier tecnología del mercado y adaptarse con rapidez al entorno.

• Proximidad y relación directa con el cliente.

• Ausencia de barreras jerárquicas.

• Mayor facilidad de planificación, en opinión de Sanchez22, debido a que:

o El número de datos a reunir es menor.

o El número de estratos que tiene que atravesar la información es menor.

o Las operaciones están menos dispersas.

Sin embargo, a pesar de presentar ventajas importantes, observamos que también existen desventajas o aspectos negativos que pueden plantear problemas a la hora de adaptarse a los cambios que se pueden producir con la implantación de un modelo evaluable:

• La resistencia al cambio, en opinión de Chen y Price23, debida entre otros motivos a:

o Muchas de las actividades las realiza una sola persona.

o El cambio es rápido y hace que los procedimientos queden anticuados en un breve periodo de tiempo.

o Limitada experiencia organizativa o carencia de toda experiencia.

o Amenaza del puesto de trabajo por miedo a dejar de ser indispensable, etc.

• La insuficiencia de medios financieros, medios humanos especializados e instalaciones para acceder y generar información suficiente o para llevar a cabo determinados proyectos y asignar recursos en función de determinadas prioridades.

21 Barrutia, J; Churruca, E; Landeta, J (1995): "Dirección estratégica de las pymes ante la globalización económica". Harvard Deusto Business Review nº 66. 22 Sanchez, G (1994): "Planificación en la pequeña empresa". Alta Dirección nº 177. 23 Chen, E; Price J (1994): "La gestión de la calidad en la pequeña empresa". Harvard Deusto Business Review nº 59.



• Déficit de información de todo tipo, según Guinjoan y Pellicer24, debido principalmente a una actitud poco receptiva a las múltiples señales que transmite el entorno.

• Además, en ocasiones se desperdician recursos de gran valor para la empresa, empleándose en actividades u operaciones poco relevantes o del día a día, no dedicando tiempo a lo que realmente es importante y necesita de una planificación a más largo plazo.

Según Judith Meles25, las particularidades de los desarrollos de software sin una metodología explícita acentúan estos aspectos negativos, pues a lo anterior se añaden los retrasos en las entregas, los costos excedidos, la falta de cumplimiento de los compromisos, requerimientos incompletos o no especificados en su totalidad, trabajo fuera de hora, etc.

Con todos estos datos, la implantación de modelos rígidos de control y mejora de procesos se hace una tarea compleja en este tipo de empresas, que se torna muy complicada por razones obvias si aplicamos estas conclusiones a las microempresas.

4.2 La visión hacia el extranjero

Según el informe26 del Observatorio de las Empresas Media Europeas “Desarrollo y capacidad competitiva de las empresas PYME en España”, las PYME españolas han venido realizando un esfuerzo comercial orientado hacia la exportación. Además el 50% de las ventas son realizadas en el extranjero, lo cual pone de manifiesto que se viene asumiendo el reto de la globalización y se encuentran enraizadas en el entramado internacional.

Las PYME españolas consideran que se deben buscar nuevos mercados a partir del propio esfuerzo individual y no creando nuevas filiales ni realizando joint ventures. Existe un rechazo a esta figura, aunque se puede considerar como un rasgo cultural del empresariado español, lo que constituye un hecho diferencial respecto a otros países europeos.

24 Guinjoan, M; Pellicer, P (1987): "Nuevas técnicas y sistemas organizativos para las pymes". Serie de estudios IMPI. 25 Judith Meles & Asociados (2006): “Calidad de software CMMI”. 26 Este estudio ha sido coordinado por la Universidad de Estrasburgo y realizado bajo el patrocinio del Programa ADAPT de la Unión Europea por la Universidad de Alcalá, con la colaboración de CEOE.



En segundo lugar, las empresas españolas consideran (un 48%) que la competencia se ha intensificado como consecuencia de la entrada de nuevos competidores y no por la incorporación de productos sustitutivos o por las exigencias de calidad. En este sentido el esfuerzo realizado por las PYME españolas es enorme por cuanto a pesar de la creciente competencia han conseguido aumentar el número de unidades vendidas. La situación en Europa es similar en relación al aumento de la competitividad. No obstante, hay diferencias en el análisis. En Europa el 53% de las empresas consideran que el incremento de la competitividad se debe a la influencia de los actuales competidores, mientras que en España el 33,8% de las empresas señalan que el incremento de la competitividad se debe a la aparición de productos sustitutivos y un 20% se debe a las nuevas exigencias de calidad.

Según este estudio, las PYME españolas han realizado un proceso de racionalización y optimización de los recursos, lo que les ha permitido incrementar la rentabilidad de ventas. El estudio afirma que las empresas ya han realizado un esfuerzo en la modernización de sus instalaciones y en los procesos de producción. Pero, una de las dificultades subrayadas por los empresarios es la dificultad para acceder a los mercados financieros, lo que obstaculiza dicho proceso de modernización.

Como se ha comentado, este esfuerzo lleva consigo un incremento implícito en la calidad de los productos desarrollados que debe ser abordado, por lo que las empresas españolas tratan de adaptarse a esta nueva situación. Por ello, la situación sobre el estado de los modelos y certificaciones de calidad en Europa y su adopción por empresas fuera de nuestras fronteras es seguida con detalle desde España.

4.3 La visión de las empresas hacia los modelos existentes

Ante la posibilidad de implantar un modelo de mejora de procesos y someterse a su certificación (o evaluación, según el modelo elegido), tanto las PYME como las grandes empresas de desarrollo (entrevistadas en el transcurso del proyecto) ven en Europa un referente. Tanto por la necesidad de ampliar mercados como por la percepción de avance en el continente, siempre según las entrevistas realizadas, la percepción de la empresa española es que los modelos más aplicables son CMMI, símbolo de la certificación de calidad aplicada al software por excelencia, y SPICE, adoptado por ISO como estándar ISO/IEC 1550427.

Se ha realizado un estudio para comprobar estas percepciones de los entrevistados al respecto del estado del arte con respecto a los modelos comentados. Para determinar los modelos más importantes aplicables a las empresas, además de las respuestas de los entrevistados, se ha contado con los resultados de la revisión sistemática de la

27 La descripción de estos modelos, como referencia, aparece en el apartado 3 del presente informe.



documentación recopilada y empleada en la elaboración de este estudio. En cualquiera de estos casos, la mejora de procesos internos en el desarrollo del software se asocia unívocamente a los modelos CMMI e ISO/IEC 15504 (SPICE), apareciendo como los más importantes en el 90% de los documentos encontrados y en el 100% de las entrevistas realizadas. De forma más general aparece ISO 9001, pero sin vinculación expresa al desarrollo de software.

Así mismo, una búsqueda rápida en los buscadores más conocidos de Internet (por http) ofrece resultados semejantes. La búsqueda “cmmi model” devuelve cerca de 2.000.000 de páginas; “iso 15504” unas 200.000, TickIT unas 70.000, y “TPI TMAP”, por ejemplo, unas 14.000. La búsqueda de “EFQM” ofrece más de un millón de páginas; pero de los modelos indicados, EFQM no se aplica generalmente al desarrollo de software.

Cabe destacar que el documento “Política industrial del sector TIC en España: Plan Avanza”28, presenta una serie de subvenciones a conceder a las empresas que se acojan a procesos de certificación de calidad del software bajo los modelos comentados, CMMI e ISO 15504, en sus niveles 2 a 5, con un presupuesto total de 1.500.000 euros en subvenciones y 5.000.000 euros en préstamos.

Los gráficos siguientes (Gráfico 8y Gráfico 9) muestran los resultados del estudio de AEC (Asociación Española para la Calidad) en su encuesta “Encuesta del Comité de Software sobre la Certificación de Sistemas de Calidad”, publicada a principios del año 2006, con respecto al conocimiento de las empresas con respecto a las certificaciones de calidad existentes. Los cuales ofrecen una idea general de la situación acerca del conocimiento de ambas normas.

Las empresas dedicadas a actividades informáticas consultadas coinciden a la hora de manifestar su conocimiento sobre ambas normas, así mientas un 37% de las empresas conocen CMM/CMMI frente a un 51% que lo hace de la ISO 15504.

Respecto a la utilización de dichas normas, CMM/CMMI es utilizada por un 38% de las empresas frente a un 8% que utiliza ISO 15504.

Por último, y a través de las respuestas efectuadas en la encuesta se puede comprobar cómo un 8% de las mismas desconoce CMM/CMMI y el mismo porcentaje (un 8%) la norma ISO 15504. Particularmente, en la muestra tomada como base para la realización de las entrevistas sólo una de las empresas desconocía los detalles de CMMI y SPICE, pese a que había oído hablar de estas normas y se había interesado por descubrir este mercado. Las entidades normalizadoras y certificadoras entrevistadas optan claramente 28 Publicado por el Ministerio de Industria, Turismo y Comercio a través de la Dirección General para el Desarrollo de la Sociedad de la Información el 4 de abril de 2005.


por ambos modelos, aunque es CMMI el estándar que aparece por delante en las preferencias.

Gráfico 8: Conocimiento sobre CMM/CMMI (empresas dedicadas a actividades informáticas)

0,0%

7,8%

69,2%

23,0%

0% 10% 20% 30% 40% 50% 60% 70% 80%

Otro

NS-NC

ISO 15504

CMMI

Fuente: AEC

Gráfico 9: Conocimiento sobre ISO 15504 (empresas dedicadas a actividades informáticas)

8,0%

51,0%

8,0%

33,0%

0% 10% 20% 30% 40% 50% 60%

NS-NC

Utiliza

Conoce

No conoce

Fuente: AEC

Por otro lado, los representantes de las grandes empresas entrevistadas aseguran por su experiencia internacional que en estos momentos en el extranjero se valora CMMI como Estudio sobre la certificación de la calidad del software en España Página 87 de 147 Observatorio de la Seguridad de la Información Laboratorio Nacional de Calidad del Software


primera opción, que ha pasado a ser el referente en los contactos con grandes empresas internacionales del sector, y que hace dos o tres años que ISO 15504 ha dejado de tener presencia en el mercado. Dada esta experiencia en relaciones y contactos internacionales, los responsables de las grandes empresas han comentado que, de facto, el modelo más sólido y útil en el entorno español es el de CMMI, Tal y como aparece reflejado en el Gráfico 10, donde un 69,2% de los entrevistados señalan CMMI como primera opción a la hora de elegir un modelo para su implantación frente a un 23% que muestran interés por la ISO 15504.

Gráfico 10: Interés/primera opción de los entrevistados sobre los modelos de mejora de la calidad a la hora de elegir un modelo para su implantación.

0,0%

7,8%

69,2%

23,0%

0% 10% 20% 30% 40% 50% 60% 70% 80%

Otro

NS-NC

ISO 15504

CMMI

Fuente: INTECO

Complementariamente al gráfico y por la entrevistas realizadas se pueden extraer las siguientes conclusiones generales:

• Para todos los agentes, el modelo CMMI es el referente en el ámbito de la certificación de calidad. No obstante, se percibe su complejidad de adopción por parte de empresas con un número de empleados reducido. La ventaja de CMMI sobre otros modelos es que ha sido diseñado para su uso en la industria del software, pero es esto lo que ha motivado que su uso en pequeñas organizaciones sea complicado debido a los requerimientos adicionales que este modelo presenta sobre, por ejemplo, la norma ISO 9001. Otros elementos que aparentemente pueden ser una complicación para empresas pequeñas es hacer frente al esfuerzo que se debe invertir en las numerosas revisiones e informes que están contenidos en el modelo.




• El modelo ISO 15504 es el segundo en importancia. Parece que la última revisión del estándar elimina parcialmente algunos de sus defectos y empieza a ser mejor considerado en el sector. No obstante, la distancia que le separa de CMMI a efectos de implantación práctica es muy significativa en la actualidad.

El problema fundamental de estos modelos a la hora de extrapolar estos datos al tejido empresarial español, con un 99,3% de PYME, es que están diseñados para grandes empresas (según Batista y Figueiredo29; Hareton y Terence30 y, Tuffley31). Incluso existen referencias, como Mekelburg32, que señalan que las organizaciones, incluso las grandes, tienden a agrupar sus procesos y relacionarlos como un conjunto, más que evaluar todos y cada uno de ellos de forma independiente como en el modelo CMMI.

La visión de la excelencia que aportan las certificaciones ante la competencia es uno de los factores que, como se ha comentado, ha creado en los últimos años una inquietud en España por la certificación. No obstante, los representantes de las entidades acreditadoras entrevistadas coinciden en señalar que el mercado de la certificación está apenas en sus comienzos, por lo que se han producido muy pocos pasos en este sentido.

La ENAC a través de su gerente de nuevas tecnologías manifiesta que esta institución, sólo otorga acreditación sobre una norma y empresa certificadora en el momento en que la norma está madura en el mercad. Es decir, habiendo sido implantada en un cierto número de empresas por parte de las empresas certificadoras, y habiendo además comprobado el funcionamiento del esquema. A día de hoy, esta acreditación nacional no se ha otorgado a ninguno de los modelos de calidad de software comentados, precisamente, por la falta de madurez del mercado. Pese a ello:

• Entidades certificadoras como AENOR ofrecen entre sus productos el sello de certificación en ISO15504 sin respaldo de la ENAC, aunque en el mercado español AENOR aparece como un referente y tercero confiable reconocido.

29 Batista, J., Dias de Figueiredo, A. (2000): “SPI in a Very Small Team: a Case with CMM”. Software Process: Improvement and Practice, vol. 5, nº 4, diciembre, pp. 243-250. 30 Hareton, L. y Terence, Y, (2001): “A process framework for small projects”. Software Process: Improvement and Practice. 6(2): p. 67-83. 31 Tuffley, A., Grove, B. y McNair, G. (2004): SPICE for small organisations. Software Process: Improvement and Practice 9(1): 23-31. 32 Mekelburg, D (2005): Sustaining Best Practices: How real-world software organizations improve quality processes.


• Otras entidades certificadoras, como EQA ó SGS, ofrecen también productos de certificación de calidad de software mediante acuerdos con entidades acreditadoras extranjeras.

• Entidades como la ESI (Engineering Software Institute), partners de certificadoras y acreditadoras extranjeras, han creado sus propias certificaciones de calidad de software basándose en modelos reconocidos. Es el caso de ITMark, basado en una adaptación más reducida del modelo CMMI.

En los resultados de las entrevistas no se contemplan otras opciones en el mercado español por diversos motivos:

• En las grandes empresas: piensan que CMMI, mayoritariamente, o ISO/IEC 15504, en menor medida, son los únicos modelos con futuro en las relaciones internacionales, por lo que su aporte es el máximo posible (respuesta de un 100% de los representantes entrevistados de las grandes empresas).

• En las PYME: las subvenciones de los organismos públicos se centran en la concesión de ayudas a los modelos más importantes, y en concreto CMMI y SPICE, por lo que se tratan de adaptar a ellas ante la ausencia de recursos para hacer frente a las implantaciones por ellas mismas (respuesta de un 45% de los representantes de las PYME entrevistados).

Además existe por un lado desconocimiento ante otros modelos (respuesta de un 30% de los representantes de las PYME entrevistados) y por otro, la idea clara de que estos modelos están probados y son un referente fuera de España (respuesta de un 100% de los representantes entrevistados).

Por otra parte, la ENAC, tal y como se ha comentado anteriormente, apenas trabaja en la actualidad en este sector en España. Los primeros pasos van encaminados hacia ISO/IEC 15504, ya que esta futura certificación estaría basada en una norma oficial (ISO), al contrario que CMMI, cuyo esquema es propiedad del SEI, quien se reserva la potestad de realizar las evaluaciones mediante sus Lead Appraisals.

4.4 Situación de la PYME y la micropyme frente al mercado de la certificación

Según los resultados generales de las entrevistas realizadas a PYME, representantes de asociaciones de empresas y organismos independientes, al respecto de su percepción sobre el conjunto de PYME y microempresas dedicadas al desarrollo de software en su entorno, existe un desconocimiento general en España acerca de qué puede aportar la certificación a una PYME a nivel interno. Las respuestas de los entrevistados son las siguientes:




• Desconocimiento de los propios modelos de mejora de procesos o producto existentes, por una obvia falta de información en la mayor parte de los casos, como indica que el 86% de los entrevistados, que ENAC no se haya pronunciado sobre ningún modelo o norma no hace sino ayudar a la desinformación.

Este desconocimiento sobre los estándares y los modelos de mejora se extiende desde los clientes hasta la propia administración. Mientras que sí existe conocimiento sobre la existencia de los estándares y su utilización fuera de nuestras fronteras, no existe detalle sobre su uso interno y todo aquello que implica su adopción, a no ser en foros especializados. Como ejemplo de esto último se pueden presentar convocatorias de subvenciones de varias comunidades autónomas, en las que según algunos entrevistados se han mezclado y malinterpretado conceptos básicos que deberían tener claros, como que SPICE y CMMI se evalúan, pero no se certifican realmente de forma oficial en España; que la adecuación a SPICE se mide en perfiles, no en niveles, al contrario que CMMI; etc.

• En caso de conocer los modelos, la sensación de “pionero” en este campo (sólo un 0,67% de las PYME españolas dedicadas al software están certificadas, según la Universidad de las Islas Baleares) termina por rechazar la posibilidad de certificación (respuesta de un 65% de entrevistados).

• Desconocimiento acerca de los beneficios económicos (respuesta de un 79%), debido a la dificultad de calcular el retorno de inversión (en adelante ROI) a corto plazo.

Ninguno de los agentes entrevistados duda en señalar que la implementación de una metodología y mejora de procesos evaluable o certificable es muy difícil en una PYME, y casi imposible en una microempresa; al menos, en los términos actuales en que existen como tales CMMI e ISO/IEC 15504. Estos estándares del SEI e ISO suponen una gran inversión en dinero, tiempo y recursos, y además las recomendaciones tras la evaluación son muy complejas de aplicar y el ROI se produce a largo plazo tal y como señalan Hareton K. N. Leung y Terence C. F. Yuen33, y Saiedian,y Urban34.

Las siguientes son las conclusiones sobre los principales aspectos esgrimidos por todos los entrevistados como barreras a salvar en este sentido:

33 Hareton K. N. Leung y Terence C. F. Yuen (2001): “A process framework for small projects”. Software Process: Improvement and Practice 6(2): 67-83. 34 Saiedian, H. y, Urban, J. (1997): “A case study to demonstrate the impact of quality design principles when restructuring existing software”. Software Quality Journal, 6(4):337-348.



• Los altos costes que conlleva la adopción del modelo, con respecto a:

o Costes de las auditorías y certificaciones.

o Costes en recursos humanos, tanto los dedicados al proceso de mejora durante la implantación, como las nuevas contrataciones de personal cualificado en calidad que requieren los modelos.

o Costes de adquisición de herramientas que soporten los modelos.

• El cambio de filosofía de trabajo que implican los modelos y las metodologías que subyacen en ellos.

• El cambio de organización casi obligado, así como la creación de un departamento de calidad y más que probablemente nuevas contrataciones de personal cualificado.

La cuantificación de los beneficios es además un aspecto recursivo en las entrevistas. Parece problemático realizar un cálculo sobre el beneficio que se puede obtener implantando una metodología y/o un modelo de calidad, por lo que muchas de las PYME no observan el ROI que suponen estas certificaciones de calidad. Este cálculo, además, no puede ser realizado a corto plazo. Las últimas iniciativas e implantaciones de modelos de mejora en PYME en España son suficientemente recientes como para no disponer de datos actualizados a ofrecer a las empresas interesadas. No así en grandes empresas, como se presenta más adelante.

Es por ello que la sensación de los entrevistados es que no se aprecia un beneficio claro en la implantación de un modelo; aunque, como se ha comentado anteriormente, sitúan el interés (en caso de que éste exista) por la competitividad del mercado y el afán de distinguirse mediante el valor añadido que otorga un sello de calidad para el marketing de la empresa, y los requerimientos de los grandes clientes.

Como conclusión, los entrevistados notan la carencia de un esfuerzo de publicitación de los modelos existentes (no sólo CMMI e ISO 15504), e información real sobre sus beneficios.

4.5 Aplicabilidad de los modelos a la PYME y la microempresa

Como se ha comentado, el problema fundamental de los modelos más conocidos y publicitados en el mercado, como muestra el interés de los entrevistados, antes comentado35, es que están pensados para grandes empresas.

35 Op. cit. 29


Los costes económicos a la implantación son, además, muy altos para lo que deben afrontar. En la Tabla 10 aparece un listado de costes aproximado, obtenido de los datos proporcionados por algunos de los entrevistados.

Tabla 10: Costes económicos asociados a las evaluaciones o certificaciones

Modelo Coste para PYME Coste gran empresa

CMMI (evaluación inicial) 10.000 a 20.000 € 40.000 € (4-5 semanas)

CMMI (acreditación) 13.000 a 30.000 € (*) Unos 450 € p/empleado (nivel 2), Unos 110 € p/empleado (nivel 3)

ISO/IEC 15504 Unos 5.000 € (5 días) (**) (*) Añadir los costes derivados del plan de acción inicial, como la adquisición de herramientas

(**) Sin datos al respecto

Fuente: INTECO

Estos costes económicos no son los únicos que debe abordar una organización. Según las certificadoras entrevistadas, el desglose total supone:

• Evaluación inicial de los procesos internos.

• Elaboración del plan de acción e implantación de las medidas correctoras, en una fase que suele durar entre 12 y 24 meses, según la organización y la certificación (como se podrá ver en las experiencias de implantación que se incluyen en este informe).

• Evaluación final, o acreditación de la implantación, o certificación del modelo, según cuál se haya elegido.

• Adquisición de herramientas para soportar el modelo y la metodología subyacente (gestión de proyectos, cuadro de mandos, gestor documental, repositorio de información y código fuente, etc.), con un coste global mínimo de unos 15.000 euros (según algunas fuentes entrevistadas).

• Cursos de formación del personal, tanto en línea (utilizando tecnologías de eLearning) como presenciales.

• Costes de reorganización interna y posibles nuevas incorporaciones especializadas en calidad a la plantilla.




Además de los costes mencionados, según Weitzenfeld y Alvarez36, estos modelos presentan, de cara a su implantación en empresas de menos de 20 trabajadores, ciertos problemas:

• Excesiva documentación del proceso de desarrollo de software, de la organización y de los aspectos relacionados.

• La planificación, organización y dirección de áreas clave de procesos orientadas a grandes organizaciones.

• Gran amplitud de las revisiones señaladas en las áreas de proceso.

• Los recursos limitados de las empresas que desarrollan software.

• Los altos costes de entrenamiento del personal, o la necesidad de contratación de personal con experiencia en calidad.

• Las prácticas sin relación al tipo de proyecto que apunta documentar CMM.

• La falta de guía de las necesidades del proyecto y equipo de desarrollo.

La conclusión de lo presentado hasta el momento es que para las PYME y las microempresas, los costes económicos asociados a estos modelos que ellas mismas ven como referentes en el mercado y sobre las que ponen su atención pueden suponer un serio inconveniente a la hora de su adopción.

Al respecto de este panorama, prácticamente todos los entrevistados coinciden en señalar como la solución más lógica en España, la creación de un modelo reducido orientado expresamente a este tipo de entidades.

4.5.1 Iniciativas en el extranjero

Se presentan a continuación las iniciativas más importantes lanzadas en el extranjero como respuesta a esta necesidad de adaptación de modelos a PYME y microempresas, resumidas para servir únicamente como referencia a partir de las fuentes originales y la documentación disponible en los sitios web correspondientes a cada iniciativa.

Iniciativas del SEI

A partir de su modelo CMMI, el SEI ha desarrollado varios estudios sobre la aplicación de este modelo a pequeñas y medianas compañías. Tal y como reflejan los informes del

36 Weitzenfeld y Álvarez (2003): Modelo para la reducción del ciclo de desarrollo de software basado en CMM. Universidad Autónoma de Aguascalientes, México.



SEI37, se están dando pasos a través de proyectos piloto encaminados a la creación de una guía de implantación de CMMI para PYME y microPYMEs. Uno de ellos ya está activo IPSS (Improving Processes in Small Settings)38.

La web de SEI, en la URL39, alberga un repositorio de documentos y herramientas denominado “CMMI in Small Settings Toolkit Repository from AMRDEC SED Pilot Sites”, como resultado final de las experiencias piloto de implantación de CMMI en pequeñas empresas. Como aparece indicado en el repositorio, hay tres formas de uso de este conjunto de herramientas:

• Como referencia para comprender y examinar a fondo las experiencias piloto.

• Como centro de consulta, dado que muchas de las partes de este conjunto de herramientas y repositorio pueden ser descargadas y usadas para ayudar a una pequeña organización a adoptar CMMI.

• Como una herramienta de aprendizaje, dado que partes de este conjunto de herramientas pueden ser descargadas y utilizadas para probar algunos aspectos de la adopción de CMMI.

La estructura del toolkit incluye:

• Casos prácticos de implantación de CMMI en empresas pequeñas, con datos sobre los problemas presentados y sus soluciones.

• Cómo abordar una implementación de CMMI a partir de una toma de contacto inicial.

• Herramientas sobre comprensión de CMMI, siempre a través de los casos prácticos, como un análisis GAP inicial para preparar el plan de mejora.

• Herramientas para experimentación en microempresas, a partir de la preparación que realizaron dos empresas piloto para pasar la evaluación de nivel 2 mediante SCAMPI Clase A.

37 SEI (2006): Thoughts on applying CMMI in small settings. y SEI (2006): Proceedings of the First International Research Workshop for Process Improvement in Small Settings, 2005. 38 http://www.sei.cmu.edu/iprc/ipss.html 39 http://www.sei.cmu.edu/cmmi/publications/toolkit/

http://www.sei.cmu.edu/iprc/ipss.html

http://www.sei.cmu.edu/cmmi/publications/toolkit/



Iniciativas de ISO

Al respecto de las actuaciones de ISO en este sentido, ISO ha creado el grupo de trabajo SC7-WG24 con el objetivo de buscar un marco sobre el que describir perfiles evaluables en pequeñas empresas y microempresas. Como resultado previo, pretenden elaborar un estándar y dos guías que ayuden a este tipo de empresas a mejorar sus procesos software como primer paso.

El trabajo concerniente a esta iniciativa está aún en curso. En la reunión del grupo celebrada en mayo de 2006, WG24 decidió por unanimidad tomar como base para su trabajo los modelos mexicanos MoProSoft y EvalProSoft, uno de los resultados del proyecto PROSOFT (a continuación), traducidos al inglés por requerimiento de ISO y con la ayuda de Microsoft.

Iniciativas encuadradas en el proyecto PROSOFT (México)

Encuadrados en el proyecto PROSOFT (Programa para el Desarrollo de la Industria del Software) de la Secretaría de Economía de México, con el objetivo de la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software adaptados a la industria software, mexicana se han diseñado dos modelos con un cierto éxito en Latinoamérica:

• MoProSoft: Modelo de Procesos para la Industria del Software, convertido en norma mexicana NMX-I-059-NYCE. Su creación se ha basado en la identificación de las mejores prácticas en la materia, recopilando casos de éxito de la industria de software a nivel mundial. Estas prácticas se han organizado por áreas de aplicación, y se han dado a conocer como áreas clave de procesos, en caso de CMM, o como procesos de software en ISO/IEC 15504.

Para la elaboración del modelo de procesos MoProSoft fueron aplicados los siguientes criterios, según Oktaba, H40:

o Generar una estructura de los procesos que esté acorde con la estructura de las organizaciones de la industria de software (Alta Dirección, Gestión y Operación).

o Destacar el papel de la Alta Dirección en la planificación estratégica, su revisión y mejora continua como el promotor del buen funcionamiento de la organización.

40 Oktaba, H (2005): Modelo de Procesos para la Industria de Software MoProSoft Por Niveles de Capacidad de Procesos. Versión 1.3,


o Considerar a la Gestión como proveedor de recursos, procesos y proyectos, así como responsable de vigilar el cumplimiento de los objetivos estratégicos de la organización.

o Considerar a la Operación como ejecutor de los proyectos de desarrollo y mantenimiento de software.

o Integrar de manera clara y consistente los elementos indispensables para la definición de procesos y relaciones entre ellos.

o Integrar los elementos para la administración de proyectos en un solo proceso.

o Integrar los elementos para la ingeniería de productos de software en un único marco que incluya los procesos de soporte (verificación, validación, documentación y control de configuración).

o Destacar la importancia de la gestión de recursos, en particular los que componen la base de conocimiento de la organización tales como: productos generados por proyectos, datos de los proyectos, incluyendo las mediciones, documentación de procesos y los datos recaudados a partir de su uso y lecciones aprendidas.

o Basar el modelo de procesos en ISO9000:2000 y nivel 2 y 3 de CMMI V.1.1. Usar como marco general ISO/IEC 15504 “Software Process Assesment” e incorporar las mejores prácticas de otros modelos de referencia tales como PMBOK, SWEBOK y otros más especializados.

• EvalProSoft: Método de Evaluación de Procesos para la Industria del Software. Mide el Nivel de madurez de capacidades de la organización definido como el máximo nivel de capacidades alcanzado por todos procesos. Cumple con los requisitos de ISO/IEC 15504, por lo que el resultado de las evaluaciones es significativo en el ámbito internacional.

EvalProSoft aplica a las organizaciones dedicadas al desarrollo y/o mantenimiento de software, y en particular, a las que han utilizado como modelo de procesos de referencia a MoProSoft para la implantación de sus procesos. Sus usos propuestos son:

o La evaluación del perfil de capacidades de procesos y de la madurez de capacidades de la organización.

o La autoevaluación.



o La evaluación por parte del comprador.

o Como efecto lateral, la evaluación de la industria.

Los requerimientos que se tomaron en cuenta para la elaboración del Método de Evaluación son los siguientes:

o El uso del Modelo de Procesos para la Industria de Software, MoProSoft V1.1, como modelo de procesos de referencia.

o El uso del Modelo de Capacidades de Proceso de la ISO/IEC 15504-2 Performing an assesment, y el cumplimiento de sus requisitos en el Método de Evaluación.

o El uso de ISO/IEC TR 15504-4 Guidance on performing an assesment como guía.

Iniciativa SIMEP-SW

SIMEP-SW es un proyecto financiado por Colciencias (entidad responsable de la investigación en ciencia y tecnología del país) y la Universidad del Cauca (Colombia). La finalidad del mismo es crear, aplicar y probar un sistema de mejora de procesos en base a otros modelos de calidad, mejora y evaluación internacionales, de forma que se logre una adaptación a las características de las empresas colombianas, así como la idiosincrasia y el contexto socio-económico del país. El resultado del proyecto ha sido la definición de un modelo de mejora denominado Agile SPI, basado en modelos ligeros adaptados de estándares internacionales para calidad y evaluación, y un método ágil para la mejora. Según los autores de la definición del modelo, no puede obviarse CMMI en el sector del desarrollo del software, pero estos modelos son descriptivos (dicen “qué” hay que hacer pero no el “cómo”), así que han diseñado una implementación del “cómo” hacerlo según el requerimiento del “qué” de CMMI.

COMPETISOFT Iberoamérica

COMPETISOFT trata de incrementar el nivel de competitividad de las PYME Iberoamericanas desarrolladoras de software, creando un marco metodológico común que se ajuste a las necesidades específicas de estas organizaciones. Este marco debería ser la base para establecer un mecanismo de evaluación y certificación de la industria del software en Iberoamérica. Los objetivos específicos de COMPETISOFT son:

• Desarrollo de un Modelo de Procesos, un Modelo de Capacidades y un Método de Evaluación, validado en empresas y organizaciones de diferentes países donde el proyecto CYTED es de aplicación.



• Difundir la cultura de la mejora de procesos en el sector del desarrollo de software mediante la formación de profesionales, investigadores y docentes universitarios.

• Ser reconocido en los diferentes organismos de normalización y certificación de los países iberoamericanos como base para establecer un mecanismo común y mutuamente reconocido de evaluación y certificación de la industria del software en Iberoamérica.

El modelo de COMPETISOFT está basado en el modelo de referencia de procesos MoProSoft y utiliza Agile SPI, antes descrito, como modelo de mejora de procesos. Aplica los métodos de mejora del programa SPI a través de pequeños proyectos, que atraviesan las fases del modelo Instalación, Diagnóstico, Formulación, Mejora y Revisión, en una base semejante al ciclo PDCA (Plan-Do-Check-Act).

El modelo de evaluación se basa en el método de evaluación EvalProSoft e ISO/IEC 15504-2. Define un conjunto de medidas de procesos, e implica la realización de herramientas para la recolección de información y para la evaluación de procesos software. Define además una guía para la ejecución de la actividad de evaluación. El proceso de evaluación guía las actividades de evaluación a lo largo de todo el proyecto de mejora, y permite abordar la evaluación de los procesos de una organización de dos formas:

• Evaluación rápida; valoración de procesos para un diagnóstico previo.

• Evaluación profunda; verificación de las mejoras implementadas antes de someterse a certificación.

ESSI (European Software and System Initiative)

ESSI es una iniciativa de la Unión Europea que ha impulsado proyectos para mejorar los procesos internos en las PYME. Como resultado de esta iniciativa, se han desarrollado entre otros los siguientes modelos:

• SPIRE (Software Process Improvement in Regions of Europe), aplicado a Austria, Irlanda, Italia y Suecia, y basado en SPICE (ISO/EC 15504).

• TOPS (Toward Organised Software Processes in SMEs), financiado por la Unión Europea a través del programa ESPRIT/ESSI en Italia.

• PROCESSUS (Slovenian software process improvement methodology), basado en ISO 9001:1994 y su guía ISO 9000-3:1994.




Iniciativas en Australia

RAPID (Rapid Assessments for Process Improvement for software Development) fue desarrollado por SQI (Software Quality Institute) bajo los auspicios del Software Engineering Australia, en el marco de un programa de investigación dirigido por Aileen Cater-Steel41, sobre la aplicación de nuevos métodos de evaluación a pequeñas y medianas empresas.

El método está basado en ISO/IEC 15504, y está diseñado para realizar la evaluación en un día con la base de la reducción de áreas y procesos a evaluar. De esta forma, de los 40 procesos definidos en ISO/IEC 15504 sólo se revisan 8, además de medir la capacidad de los procesos sólo en los niveles 1 a 3 del estándar en lugar de los 6 iniciales.

Uso de modelos ágiles

De la referencia incluida anteriormente sobre la iniciativa COMPETISOFT para las PYME, en la que se establecen como modelo de referencia MoProsoft y como modelo de mejora Agile SPI, y de los estudios realizados por la Universidad del Cauca (Colombia) y la Universidad de Chile sobre métodos ágiles y su comparación con CMMI42, se pueden extraer dos conclusiones fundamentales:

• Los métodos ágiles son un método muy adecuado para su aplicación en las PYME y la microempresa. El modelo Agile SPI, usado en el marco del proyecto para la mejora de procesos software, fue probado en un piloto del que formaron parte 4 empresas mexicanas de menos de 50 empleados durante 8 meses (según datos del informe final de COMPETISOFT elaborado por H. Oktaba). Un número determinado de procesos de cada una de ellas fue evaluado inicialmente según la escala CMMI, de 0 a 5, obteniendo una media global de 0,18. Los resultados finales tras 8 meses arrojaron una media global de 1,13, por lo que la mejora fue realmente alta. Alguna de estas empresas fue evaluada con el nivel 4 de CMMI al término del proyecto.

• Es posible combinar algunos de estos métodos ágiles (como XP) para lograr el equivalente a un nivel 2 de CMMI en un 72%, según los resultados del informe de las universidades antes mencionado. Como requerimientos, los autores exigían una definición clara de los procesos y la posibilidad de realizar una minievaluación inicial.

Con esto, los modelos ágiles se presentan como alternativas simples a CMMI y a sus modelos derivados para la PYME y la microempresa. 41 Aileen Cater-Steel: Software Process Evaluation: Experience Report. Department of Information Systems, Faculty of Business, University of Southern Queensland, Toowoomba, Australia. 42 Implementing CMMI using a Combination of Agile Methods.



En este sentido, XP se ha diseñado teniendo como meta final de la satisfacción del cliente y el cumplimiento de las fechas de entrega antes que ninguna otra circunstancia.

Otras iniciativas

• TSE (Towards Software Excellence): Iniciativa soportada por el UK Department of Trade and Industry (DTI), así como organizaciones del sector. Nace con el objetivo de permitir comparar las prácticas de la PYME del país dedicada al desarrollo del software con las Mejores Prácticas a nivel internacional.

• ParqueSoft: Organización sin ánimo de lucro establecida en 1999 en Colombia, con el propósito de crear y desarrollar bienes y servicios a las empresas de IT del país. Integra más de 120 microempresas (unos 1000 profesionales de la ingeniería del software), y sus esfuerzos en calidad del software se centran en ISO 9001 y CMMI. Los costes de formación de las empresas integradas se reducen mediante la compartición de recursos e información entre empresas.

4.5.2 Iniciativas en España

Se incluyen a continuación las iniciativas que se han lanzado en España al respecto de los modelos orientados a pequeñas empresas y microempresas, así como las adaptaciones que de modelos existentes y reconocidos (como CMMI e ISO/IEC 15504) se han desarrollado recientemente.

ITMark

El modelo ITMark ha sido diseñado por ESI (European Software Institute), fundación privada sin ánimo de lucro creada en 1993 por la Comisión Europea en colaboración con el gobierno vasco, e integrada en la Corporación Tecnológica TECNALIA.

ITMark43 evalúa y acredita la calidad de la empresa en tres grandes áreas: una relacionada con la gestión general de la empresa (estratégica, comercial, financiera y de marketing), otra sobre la seguridad de la información y la tercera y más específica, vinculada a la madurez de sus procesos software. En los temas relativos a gestión se toma como referencia el modelo 10-Squared. Desde el punto de vista de la seguridad se emplea el estándar ISO 17799, en tanto que en el área específica de software se incorpora una versión simplificada de CMMI.

Varias han sido las implantaciones de ITMark en Europa hasta julio de 2007. Según la web de ESI44, en España ha sido adoptado por las compañías Consultores Asociados, CTI

43 El modelo ITMark se describe con detalle en el epígrafe 3 de este informe. 44 http://www.esi.es/index.php?op=15.1.2

http://www.esi.es/index.php?op=15.1.2



Soft, ECNA Informática, Innobask y WideWorld, todas ellas PYME. No se ofrecen cifras sobre los resultados de estas implantaciones.

Iniciativas del gobierno de Aragón

El programa SoftAragón es una iniciativa del Departamento de Ciencia, Tecnología y Universidad del Gobierno de Aragón desarrollada por el ITA (Instituto Tecnológico de Aragón). Esta iniciativa pretende incrementar la competitividad de las empresas dedicadas al desarrollo de software de Aragón mediante la mejora de sus procesos internos.

De igual forma que en otro tipo de subvenciones (el proyecto incluye una fuerte subvención), las empresas participantes debían formar un grupo para realizar el objetivo de mejora en el mismo tiempo, a través de la sinergia generada mediante la asociación. SoftAragón cuenta con la colaboración de ESI, especialistas en CMMI, encargados de realizar las evaluaciones iniciales y la preparación de los planes de mejora para las empresas participantes.

El punto de partida del programa, según información proporcionada por el ITA, ha sido:

• Un modelo apropiado para cualquier tipo de PYME que partiese con niveles de madurez bajos en sus procesos.

• Específico para empresas dedicadas al desarrollo y mantenimiento de software.

• Definir un conjunto de procesos basados en prácticas reconocidas internacionalmente, como CMMI nivel 2.

Estos puntos han conformado la base de un modelo CMMI reducido, aplicado a PYME, que es un punto intermedio antes de conseguir el nivel 2 de CMMI (al que algunas de las empresas participantes optan actualmente). El modelo intermedio se acredita por parte del gobierno de Aragón con un sello específico (Básico, equivalente a una evaluación de CMMI Clase C; y Premium, equivalente a una evaluación clase B45).

Según el ITA, en datos presentados en la III Semana del CMMI celebrada en marzo de 2007 en Madrid, su experiencia tras tres años de programa ofrece las siguientes conclusiones:

• Existen fuertes evidencias de la necesidad de métodos de desarrollo disciplinados en la PYME.

45 Las evaluaciones CMMI se describen en el epígrafe 3 de este informe.


• El modelo CMMI en su formato actual no es viable para su adopción e implementación en PYME, por lo que:

o Se hace necesario desarrollar guías de adaptación.

o Sería interesante desarrollar un sistema de benchmarking para facilitar la comparación con otras PYME.

• Es importante disponer de un “agente del cambio” que dé soporte a la difusión y adopción en PYME.

Iniciativa de AEC (Asociación Española para la Calidad)

Dentro de las iniciativas del mercado para las PYME y microempresas, y dado que desde la AEC consideran que los modelos más exitosos como CMMI e ISO/IEC 15504 no son adecuados para ellas, el Comité de Software de la Asociación Española para la Calidad inició un grupo de trabajo con el objetivo de (según la presentación de esta iniciativa), “ayudar a las organizaciones/proyectos pequeños a implementar áreas claves de procesos proporcionándoles criterios para identificar el conjunto mínimo de buenas prácticas que le ayuden a cumplir sus objetivos”.

En este marco de actuación, el grupo de trabajo ha partido de una serie de líneas guía como son:

• No centrar su propuesta en un modelo ya existente, sino aprovechar lo mejor de cada uno.

• Identificar los procesos relevantes del desarrollo de software en exclusiva, y las prácticas específicas que se pueden hallar en proyectos pequeños.

• No incluir prácticas genéricas.

Según la AEC, la guía incluye, además de una introducción y un glosario de términos, siete apartados, uno por cada área de proceso; Gestión de requisitos, Planificación del proyecto, Seguimiento y control del proyecto, Gestión de acuerdos con proveedores, Medición y análisis, Aseguramiento de la calidad del proceso y del producto y Gestión de la configuración.

4.5.3 Resumen y comparación de las iniciativas para las PYME y microempresas

Las iniciativas antes presentadas tienen varios puntos en común:

• Todas se basan en los dos modelos con mayor renombre internacional, CMMI e ISO/IEC 15504.



• Todas surgen de un mismo punto de partida, que indica que estos modelos no son aplicables a PYME. Cada iniciativa llega a esta conclusión de forma independiente, justificada tras un estudio o encuesta previa.

• Todas tratan de crear un modelo puente, de manera que tras adoptar alguno de estos modelos, la empresa pudiese en un futuro optar a una evaluación clase A CMMI o a una certificación ISO/IEC 15504. Con ello se reconoce implícitamente la excelencia de estos dos modelos y los logros y beneficios que otorgan.

• Todas surgen de iniciativas que pretenden impulsar la mejora de la competitividad de la PYME.

Las iniciativas llevadas a cabo en España también aplican como punto de partida la creación de un modelo intermedio como paso previo a CMMI e ISO/IEC 15504. Se centran en la mejora de los procesos (tal y como defienden estos dos modelos) como método de alcanzar la calidad, y apenas tienen en cuenta los modelos orientados a producto.

Al respecto del estado de estas iniciativas, una conclusión que se ha extraído de las entrevistas realizadas es la descoordinación y la falta de información sobre las iniciativas a seguir en el campo de la aplicación de modelos aplicables a PYME y a microempresa. A este respecto, menos de un 15% de los entrevistados conocían la certificación ITMark, y ningún entrevistado conocía la iniciativa de la AEC.

Un ejemplo más claro de estas faltas es la participación española en los comités de normalización. En boca de uno de sus representantes, entrevistado durante este estudio, los demás comités internacionales participantes suelen achacar al español la poca relación que tienen con la empresa española. Esto se justifica por su parte por el poco interés de la empresa en participar en este tipo de grupos de trabajo, por lo que la labor de diseño de normas queda restringida a trabajos realizados en universidades o en empresas privadas como ESI. Debido a esto, la aportación a las normas en general es muy teórica en detrimento del punto de vista empresarial práctico.

Según el 86% de los entrevistados, existe la necesidad de un agente intermedio que aglutine las iniciativas, y sirva de puente entre la PYME y las entidades normalizadoras y demás organismos que respaldan la creación de estándares, normas y modelos. Este agente, según conclusiones de los entrevistados, debería jugar un papel consistente en:






o Utilizando un sitio web de Internet.

o Creando un foro de opinión.

o Promoviendo la creación de cursos, talleres y workshops sobre el tema.




Por los resultados obtenidos en cada iniciativa, revisando las conclusiones de cada una de ellas en los sitios web en que las han publicado, se observa que existe un éxito medible en la aplicación de los nuevos modelos intermedios. El agente aglutinador debería partir de esta información como una base sólida a la hora de llevar a cabo los proyectos antes indicados.

4.6 Experiencias de implantación en las PYME

Pese a estas dificultades, muchas son las razones que impulsan a una empresa a implementar un sistema de mejora continua de procesos. Se incluyen a continuación los resultados obtenidos por la AEC (Asociación Española para la Calidad) en su encuesta “Encuesta del Comité de Software sobre la Certificación de Sistemas de Calidad”, publicada a principios del año 2006.




Gráfico 11: Motivos que llevan a las empresas a implementar un modelo de mejora de procesos

73,0%

52,0%

49,0%

43,0%

19,0%

2,0%

0 10 20 30 40 50 60 70 8

Otros

Motivación del personal

Aumento de lacompetitividad

Requerimientoscomerciales o legales

Mejora de la satisfaccióndel cliente

Mejora de la gestióninterna

0

Fuente: AEC

El informe46 del Standish Group de 2005, indica que “el 31,1% de los proyectos se cancelan antes de completarse, y sólo el 16,2% de los proyectos se completan en tiempo, cumpliendo adecuadamente con todos los requerimientos, incluyendo financiación”. No es extraño, pues, que el primer motivo de las empresas a la hora de buscar una certificación de calidad sea la mejora de sus procesos internos.

Las empresas entrevistadas que han implementado CMMI en las últimas oleadas del Plan Avanza mediante el plan COMPETIC, como puede ser PROCONSI, están plenamente satisfechas con el resultado tanto a nivel interno como externo. Sin ningún género de dudas, reconocen como los beneficios a posteriori más importantes los siguientes puntos:

• Mejora general de sus procesos, optimizando tiempo y recursos.

• Mejor control sobre los proyectos abordados, gracias en parte a las herramientas que la metodología arrastra.

• Más facilidad para el desarrollo de software y consecución del producto final.

• Mejor imagen de la empresa de cara al exterior. 46 Disponible en www.scs.carleton.ca.

http://www.scs.carleton.ca/


Cuantitativamente no existen cifras de beneficios económicos para estas empresas, pues el plan de implantación acaba de terminar a principios de 2007, y por regla general estos beneficios se miden a medio-largo plazo. No obstante, según las respuestas de los entrevistados, su percepción cualitativa es la de una mejora sustancial.

La recepción del modelo por parte de los empleados de cualquier empresa varía en función de si es PYME o gran empresa. Mientras que la cultura interna de la gran empresa hace años que se orienta a modelos y metodologías de calidad, con grandes departamentos instalados en todas las áreas de la empresa destinados exclusivamente a su control y mejora (tal y como han referido en las entrevistas los representantes de Software Ag, Ibermática o Accenture), las PYME observan una reticencia inicial que finalmente desaparece conforme se implantan las mejoras que trae consigo el modelo (conclusión obtenida en el 100% de las entrevistas a representantes de empresas que ya han implementado algún modelo de mejora, como en el caso de la implantación de CMMI de nivel 2 de PROCONSI desarrollado en el siguiente aparatado).

Este punto de vista inicial se achaca a la forma en que la PYME afronta su trabajo diario. En empresas con menos de 20 trabajadores, sobre todo, las metas a muy corto plazo suelen eclipsar este tipo de iniciativas de mejora, que se observan como un impedimento más que como una ayuda. No es normal, a tenor de las conclusiones de las entrevistas, que en la vorágine de trabajo diario de la microempresa existan tiempo y recursos para cambiar un método de trabajo que aparentemente funciona y que tiene una importante inercia que es difícil modificar. La ausencia de medición sobre los beneficios de otras experiencias, además, no ayuda a cambiar estos métodos en empresas que ya llevan tiempo trabajando de esta forma.

La visión opuesta surge en casos muy puntuales, como el de la empresa CONSOLTIC, donde el éxito radica en que se construye a partir de profesionales con experiencia en el sector desde la base de la metodología y la calidad, inculcando a las futuras nuevas incorporaciones las ventajas de una manera de trabajo focalizada en estos conceptos. Este punto de vista es semejante al de las grandes empresas, que en sus cursos de formación tratan de ofrecer estos conceptos como un punto básico a sus nuevos empleados.

Según la encuesta de AEC “Encuesta del Comité de Software sobre la Certificación de Sistemas de Calidad”, las mejoras obtenidas tras la implantación de un modelo de mejora de procesos son las que se muestran en el Gráfico 12.



Gráfico 12: Mejoras obtenidas tras la implantación del modelo de calidad

7,0%

10,0%

12,0%

15,0%

38,0%

47,0%

48,0%

0% 10% 20% 30% 40% 50% 60%

Otros

Mejora de la calidad delproducto

Disminución de costes

Satisfacción del cliente

Mejora de la posicióncompetitiva

Aumento de ventas

Mejora de la calidad delservicio

Fuente: AEC

Según la misma encuesta, el 79% de las empresas que han implantado estos modelos están satisfechas con el resultado final y los beneficios obtenidos.

A tenor de los comentarios de expertos universitarios y empresas de desarrollo en general, la situación actual en la universidad española no ayuda, de forma indirecta, a la implantación de un modelo. La formación en calidad impartida en las universidades como asignatura, ya sean troncales, optativas o de libre elección, es prácticamente nula, aunque existen algunos casos de temarios de “Calidad del Software” como el de la Escuela Universitaria de Informática perteneciente a la Universidad de Valladolid.

Por este motivo, no existe una arraigada cultura de calidad en el desarrollo de software implícita en el personal recién licenciado. Esto supone, al entender de la gente entrevistada, una dificultad añadida en las empresas que quieren implantar una metodología y un sistema de calidad medible, evaluable o certificable. En aquellas que ya poseen certificaciones o evaluaciones, en cambio, y que contratan este tipo de personal sin experiencia no supone grandes problemas, puesto que como ya se ha comentado la formación inicial de las nuevas adquisiciones es un tema básico e implícito en su sistema de calidad.

4.6.1 El caso de PROCONSI

Como ejemplo ilustrativo del proceso de implantación de un modelo de mejora de procesos en una PYME española se presenta a continuación el caso de PROCONSI en el marco del proyecto COMPETIC.




El proyecto COMPETIC, liderado por la Confederación Española de Empresas de Tecnologías de la Información, Comunicaciones y Electrónica (CONETIC), y respaldado por el Ministerio de Industria, Turismo y Comercio a través del Plan AVANZA, tiene como objetivo fundamental la implantación del Nivel 2 del modelo CMMI entre las empresas del sector de desarrollo de software. La finalización del proyecto tendrá lugar de forma oficial en noviembre de 2007; pero en el desarrollo del mismo, las empresas ALGOR, WEBDUERO, PROCONSI, XERIDIA y ELVEX, asociadas a AETICAL (Asociación de Empresas de TI de Castilla y León) ya han conseguido pasar de forma exitosa la citada evaluación de CMMI.

PROCONSI es una de estas empresas leonesas, dedicada al desarrollo de software como punto fundamental de su negocio, está considerada en el mercado leonés como una de las punteras en la región. En el marco de este estudio fue concertada una entrevista con sus responsables para obtener datos acerca de sus experiencias en la implantación del modelo de mejora CMMI. La entrevista tuvo lugar en su sede social, estando presentes por su parte Marian Díaz, responsable de calidad, y Constantino Lázaro, jefe de proyectos.

Las conclusiones de la entrevista y las experiencias relatadas por los representantes de PROCONSI se muestran a continuación.

• Entorno y actividad de la empresa.

o PROCONSI pertenece a ALETIC, Asociación Leonesa de Empresas TIC. En el momento de la realización de la entrevista, ALETIC tenía 34 empresas asociadas dedicadas a las tecnologías de la información, de las que la mayoría son empresas de desarrollo de software. Gracias a la asociación, y con el apoyo de un proyecto de colaboración entre CONETIC, AETICAL47, GAIA48 y ALETIC, han podido involucrarse en el proyecto COMPETIC para implantar el modelo de mejora de procesos CMMI para pasar la evaluación de Nivel 2. GAIA fue la gran impulsora del proyecto, debido a su experiencia y a la relación con el ESI.

o Se plantearon abordar CMMI a partir de la iniciativa que les hizo llegar ALETIC, después de varias charlas y reuniones, dado que además eran conscientes de la necesidad de mejora por el crecimiento de la empresa.

o Han constatado un interés común entre las empresas de desarrollo en los diferentes cursillos a los que han acudido, todos sobre la mejora de calidad y rentabilidad. Se comenta el hecho de que existe un

47 AETICAL: Asociación de Empresas de TI de Castilla y León. 48 GAIA: Cluster de TIC del País Vasco.


“compañerismo de facto” a la hora de poder implantar un modelo como CMMI.

o La evaluación exitosa sobre la implantación realizada del modelo CMMI ha sido realizada apenas 6 meses después de comenzar el proceso, cuando se estima desde el SEI que se necesitan aproximadamente unos 18 meses de media. No obstante, ven que este plazo, marcado al inicio del proyecto por las exigencias del plan COMPETIC, ha sido excesivamente corto. Con más tiempo piensan que hubieran conseguido pasar la evaluación con una base más fuerte en su implantación. Consideran además que es algo que no debe ser logrado cuanto antes, dado que requiere su tiempo de madurez.

o El equipo encargado de la implantación fue de 4-5 personas a tiempo completo, con apoyo de otras personas en casos concretos. Existía, además, un respaldo firme de la dirección general.

o La evaluación se ha realizado sobre el departamento de desarrollo al completo, en el que trabajan actualmente (junio de 2007) unas 20 personas.

• Estado del arte en la calidad del software en general, y aplicado a la empresa y sus experiencias.

o Según sus comentarios, para lograr una implementación exitosa de CMMI nivel 2 han tenido que cambiar la cultura de la empresa, tanto de los programadores y analistas como de los gerentes y la cúpula directiva. Les ha requerido un gran esfuerzo y dedicación de todo el personal.

o El pensamiento inicial era que poseer la certificación ISO 9001:2000 (certificada por SGS, empresa acreditada por ENAC) supondría una ayuda a la hora de enfrentarse con la evaluación CMMI, en el sentido de que ya existían hábitos de supervisión continua y seguimiento de los requerimientos de una metodología. A la hora de enfrentarse de verdad con CMMI, la realidad ha demostrado que no tenía mucho que ver lo que hacían con lo que han tenido que conseguir.

o La principal mejora obtenida es la optimización del control de las diferentes acciones que llevan a cabo. Han podido estandarizar todos los rangos, ya que pese a que existía una manera de trabajar de facto, ésta no estaba documentada. Gracias a CMMI, ahora está estandarizado y totalmente documentado, lo que ha supuesto indirectamente el hecho positivo de perder dependencia de los procesos con el personal que



trabaja en la empresa. Las causas de la situación inicial son que la empresa ha tenido una gran expansión en muy poco tiempo, y lo que al principio y bajo la percepción de la gerencia parecía estar totalmente controlado, no lo estaba realmente.

o Otros beneficios logrados son los siguientes:

• Control total sobre lo que ocurre en el departamento. De los proyectos se puede conocer ahora, en cualquier momento, su estado, el trabajo realizado y el pendiente a realizar. Anteriormente a la implantación de la mejora, no se realizaban partes de tareas hechas por escrito.

• Han percibido que han mejorado los resultados de las pruebas realizadas al software desarrollado, por lo que consideran que el proceso está más optimizado porque el producto resultante presenta muchos menos fallos.

• El trabajo está más acotada a los recursos implicados, tiempo y seguimiento.

• Se estandariza el comportamiento de los diferentes jefes de proyecto. Cada uno tenía su propio estilo, y el cambio de uno a otro podía resultar más o menos duro para los desarrolladores.

• Las bajas en la compañía ya no suponen una pérdida de conocimiento ya que tanto procesos como información necesaria están documentados y almacenados en un repositorio documental.

• Es más fácil adecuarse a los servicios que el cliente solicita.

o En PROCONSI todavía no se sienten capaces de evaluar de una forma completa el impacto que ha tenido la certificación en CMMI, debido a que hacía escasamente tres semanas que habían sido evaluados por los Lead Appraisal del SEI. Se habla de un soporte de beneficios de 5 a 1 a largo plazo, pero lo comprobarán en su momento.

o Se han planteado abordar el nivel 3 de CMMI para finales de 2009. Esto les exige que para la siguiente revisión cumplan lo ya logrado mediante su perfecto mantenimiento y, si lo ven posible, alguna mejora a la implantación realizada. De hecho, se encuentran perfeccionando el sistema.



o Ha existido por su parte un gran esfuerzo en formación en el departamento de desarrollo y el equipo directivo de PROCONSI.

o Las herramientas son necesarias a la hora de la implantación, pero les ha sido necesario para ello tener antes una metodología bien asumida y muy bien concretada. Consideran que antes de plantear herramientas, el primer punto es concretar la metodología para las necesidades concretas de la empresa, para a partir de ahí comenzar la búsqueda de una herramienta adecuada.

o Han adquirido Polarium como herramienta de soporte. Antes poseían Subversion, el cual también puede ser (y de hecho ha sido) incorporado en Polarium. Consideran que necesitan tiempo para sacarle el mayor provecho. Incluye gestión de requisitos, gestión de cambio, asignación de tareas, planificación de proyectos, captura e informe de métricas. Han realizado, además, varias herramientas para complementar Polarium, ya que ésta no posee todas y cada una de las funcionalidades requeridas por CMMI.

o Han echado en falta herramientas más accesibles. La que ellos han adquirido ha tenido un coste de 15.000 euros por la forma de licenciar el producto, además del coste interno en recursos por la elaboración de desarrollos propios complementarios.

o Sus profesionales son, principalmente, ingenieros superiores informáticos, También han incorporado ingenieros técnicos informáticos y profesionales técnicos. En un principio, el personal fue reacio a los cambios realizados, aunque por otra parte, la plantilla ya había asimilado la necesidad de este cambio.

o Consideran que realizar nuevas incorporaciones es menos traumático para la empresa, gracias a la documentación de la que disponen ahora en los repositorios sobre los procesos, requerimientos al personal, métodos de programación, etc. Por otra parte, echan en falta conocimientos básicos (sobre todo de calidad) que debían ser impartidos en la formación universitaria o profesional. La formación requerida para el nuevo personal dependerá del rango al que se vaya incorporar, pero las exigencias mínimas están adaptadas al nuevo método, y suelen ser: para programadores, interpretación del lenguaje de descripción UML; para los analistas, conocimientos de modelado de UML y metodología RUP; y para los jefes de proyecto, conocimientos CMMI.



o El modelo CMMI requiere una metodología de desarrollo subyacente. Para ello se han basado en la metodología RUP, ya que han considerado que es la más utilizada en las empresas de desarrollo de software. Esta metodología se abstrae del nivel programación, permitiendo dar una gran libertad y mejora a los proyectos.

• Percepción, impresiones e interés sobre los modelos actuales.

o En PROCONSI piensan que los grandes clientes (incluyendo la administración) tienen un gran interés en que sus proveedores usen modelos como CMMI, que especialmente en proyectos que incluyen subcontratación de desarrollos resulta muy relevante.

o Clientes menores como puedan ser otras PYME no lo valoran tanto; entienden que es algo positivo, pero no le dan demasiada relevancia. A este tipo de clientes les interesa más que los productos sean más baratos y elaborados más rápidamente. En este punto, la aportación de CMMI sí es muy productiva al respecto.

o Creen que existe un movimiento de mercado causado por el reciente interés en la calidad de software. Estiman que es en este momento cuando va a tener auge la certificación de calidad en el desarrollo software, pero también piensan que irá decreciendo, como suele ocurrir con casi todo. Creen que además existe un gran interés por ver los resultados que han obtenido dentro de la empresa, y sobre todo de otras PYME que puedan tratar de adoptarlo también.

o Conocen ISO/IEC 15504, pero se interesaron más por CMMI que por SPICE debido a que: pensaban que CMMI era más conocida, habían escuchado rumores de la Administración adoptará ese estándar y es que es el modelo más utilizado por la gran empresa española.

o Se encuentran también interesados en los estándares EFQM e ITIL. Debido a que CMMI sólo se centra en los procesos de desarrollo, estiman importante cualquier otro tipo de estándares que ayuden a dirigir mejor a la empresa.

o Les interesan los modelos y variaciones de las diferentes certificaciones, normas o modelos con especial enfoque en la PYME. A la hora de englobar modelos, ven necesario que esto pueda permitir la certificación sobre aquello en lo que estén interesados.



o Piensan que en estos momentos, desde su experiencia de implantación, que las microempresas deben tener mucha precaución, dado que no les resultaría nada sencillo poder aplicar las prácticas que CMMI exige. Puede resultar duro la certificación para una PYME de unos 15 empleados, pero mientras existan subvenciones de apoyo se puede ir preparando el camino. Sobre grandes empresas, piensan que CMMI es la solución perfecta para sus procesos.

o En el caso de PYME y microempresa, el problema principal de la implantación de este modelo pueden ser los costes de la consultoría previa, de los recursos internos invertidos en el plan de acción, y la posterior evaluación. Creen que la gran diferencia de aplicar CMMI en grandes o pequeñas empresa es el nivel de recursos disponibles. Lo que más cuesta según su experiencia es la formación y la implantación del modelo en los proyectos en curso.

• Percepción sobre el futuro de la calidad del software en España a corto o medio plazo.

o El futuro próximo presentará a administraciones que exijan a las empresas cliente un certificado de calidad, ya que según su experiencia los modelos traen siempre implícitamente la calidad del producto final. Piensan que existirá una diferenciación entre la calidad que asegura la norma ISO 9001 y la que asegura CMMI, por lo que se centrarán en esta última.

o Creen que nos encontramos en la dinámica de conseguir CMMI como valor añadido, pero estiman también que caerá la demanda. Piensan que existe un interés especial por parte de los evaluadores CMMI del ESI en no desprestigiar el estándar, por lo que realizan unas evaluaciones muy exhaustivas.

o Así mismo, con el aumento de la demanda se espera que bajen los precios y que las evaluaciones se hagan más rápido. A medida que el mercado crezca, piensan que se definirá un nuevo modelo (o versión mejorada de alguno anterior) y que tendrán que certificarse de nuevo.

o Ven que la certificación puede ser un impulso comercial y una mejora en el procedimiento de trabajo.

o Así mismo, piensan que el modelo CMMI va a resultar muy importante dentro del Plan Avanza, debido a se rumorea que más que puntuable en



la administración, CMMI va a ser excluyente en muchos proyectos futuros.

o Por último, según la experiencia de implantación, creen que debe existir algún agente que mantenga contacto con las PYME del sector, mediante iniciativas como participación en foros, ferias sectoriales, etc., y ven a las asociaciones de empresas en este papel.

4.7 La experiencia de las grandes empresas

Las grandes empresas españolas que actúan como clientes suelen exigir a sus proveedores de software que se acojan a determinados estándares de calidad, como pueden ser las normas ISO 9000 y, últimamente, CMMI ó ISO 15504. Según las empresas desarrolladoras entrevistadas, éste suele ser un motivo fundamental para implantar los modelos solicitados.

Dado que un modelo de calidad basado en la familia de normas ISO 9000 es un requisito de facto en el mercado, para una gran empresa suele ser fácil la adopción de los modelos orientados a sus procesos de desarrollo de software. Software Ag e Ibermática, por ejemplo, cuentan sus casos frente a CMMI y SPICE, respectivamente, como implantaciones bastante sencillas dado que sus estructuras organizativas de calidad permitían la compatibilidad de las exigencias de los nuevos modelos. Consideran además que su personal apenas necesitaba ser formado, dado que la calidad en los procesos de desarrollo estaba muy implantada en la empresa.

Los beneficios adquiridos no son mesurables aún por lo reciente de las evaluaciones de los modelos que han implantado; no obstante y a priori, sin posibilidad de otras medidas, sitúan al marketing como uno de los principales beneficios que han adquirido.

Accenture es otra de las grandes empresas que ha implementado un modelo de mejora de procesos a gran escala. La elección ha sido CMMI, ya que el mercado europeo, según su percepción particular, ha abandonado definitivamente ISO 15504 (SPICE) en favor del primero. Al igual que las otras empresas comentadas, coinciden en señalar que la implantación en una gran empresa es más sencilla si ya se posee una certificación como ISO 9001, y ahonda en los beneficios que se obtienen.

Estos casos y experiencias no son extrapolables a empresas sin departamentos de calidad, ni a organizaciones sin metodologías de desarrollo y herramientas asociadas, como son gran parte de las PYME y prácticamente todas las microPYME. Además, los representantes de las grandes empresas coinciden al señalar (en un 100% de sus respuestas) que estos modelos son inalcanzables para las pequeñas y medianas empresas tanto por su enorme coste económico como por los recursos necesarios para implementarlos.



4.7.1 El caso de ACCENTURE

Ulises Arranz, socio de Accenture responsable de calidad, fue entrevistado en el transcurso de este estudio. Su empresa dispone de una software factory (fábrica de software) en Málaga, que en el año 2005 fue evaluada satisfactoriamente con nivel 5 de CMMI.

Los comentarios más relevantes al respecto de las experiencias en calidad de Accenture expuestas en la entrevista se muestran a continuación.

• Accenture presenta una apuesta continua sobre la calidad. No han sido los clientes, sino la propia empresa, quien ha iniciado los procesos para la mejora interna. De esta forma, en 1999 fueron certificados bajo la norma ISO 9001:1994; en 2002 comenzó la certificación de la fábrica de software con CMM-SW nivel 3; en 2003 con CMM-SW nivel 5; y finalmente, en 2005, con CMMI nivel 5.

• La evolución y la mejora continúan, pues es objetivo de la compañía la implantación de nivel 5 de CMMI en todos los centros y áreas geográficas en España, dentro de un proyecto global de certificación de la multinacional. Piensan que al menos seis de estas ubicaciones pasen la correspondiente evaluación durante 2007.

• El gasto interno en la implantación del modelo (que no ha sido detallado), sobre todo, se debe a la formación a los empleados. Esta formación especial producto de la implantación del modelo se extiende a gran parte de la empresa y a las nuevas incorporaciones dentro de una política de formación que lleva implícita la calidad en el desarrollo.

• Piensan que les ha resultado muy sencillo adoptar CMMI debido a la posesión de certificados de calidad en vigor como ISO 9001, y la cultura de calidad y mejora permanente que vive la empresa.

• Según sus métricas, implantadas en el marco de la última evaluación de nivel 5, el proceso de desarrollo de software en la fábrica de Málaga tiene una tasa de error inferior a 10 errores en cada 1.000 horas de trabajo.

• Piensan que los clientes en España dan muy poca importancia al nivel de CMMI, o a la certificación en general. En concreto, realizaron una prueba con un cliente en la que la tasa de errores fue deliberadamente multiplicada por 10. El cliente no sólo no se quejó en el transcurso del proyecto, sino que felicitó al equipo por su trabajo y haber entregado un producto con muy pocos errores.

• Accenture cuenta con un Lead Appraiser acreditado por el SEI. No obstante, han sido muy pocas las empresas que se han dirigido a ellos para realizar evaluaciones



SCAMPI desde que la acreditación fue concedida. Según el representante de Accenture, el mercado se mueve de forma muy lenta debido al poco interés en invertir recursos por parte de empresas medianas.

• Al respecto de la PYME, se piensa que CMMI no es un modelo hecho para ella, y que deben buscarse alternativas especializadas al mismo.

4.7.2 El caso de SOLUZIONA

En el marco de la VII Conferencia Anual de la Asociación Española de Métricas de Sistemas Informáticos (AEMES), SOLUZIONA, multinacional española, presentó públicamente sus experiencias en calidad del desarrollo de software.

En la presentación de sus datos, destaca lo siguiente:

• El modelo elegido en este caso ha sido también CMMI, con una metodología de desarrollo 6-Sigma subyacente. El área evaluada corresponde a su fábrica de software, al igual que en el caso de Accenture, aunque SOLUZIONA se encuentra en nivel 3, y esperan poder evaluar próximamente en nivel 4.

• SOLUZIONA sí ofrece cifras de la implantación. El coste por empleado derivado de la implementación de CMMI nivel 2 en su momento ha sido estimado en 449 euros, y el coste derivado de adoptar el modelo para pasar una evaluación nivel 3 a partir de los logros anteriores se reduce a 110 euros por persona.

• A la hora de enfrentarse con un modelo de mejora, el punto al que se quería llegar venía dado por la necesidad de conocer la calidad real de los productos software que desarrollan, conocer el coste del desarrollo, y disponer de procesos internos acordes a la operativa que realizan los ingenieros de software.

• El proyecto de evaluación está plenamente respaldado por la dirección de la organización, y disponen de un presupuesto específico para ello. Además, CMMI se sitúa como un objetivo estratégico en la organización, y no como un objetivo más de calidad.

4.8 La visión del cliente

Desde el punto de vista del cliente, el estudio de la AEC “Encuesta del Comité de Software sobre la Certificación de Sistemas de Calidad”, del año 2006, ofrece los resultados incluidos en el Gráfico 13.



Gráfico 13: Posición como cliente a la hora de contratar servicios de un proveedor

2,0%

12,0%

75,0%

11,0%

0% 10% 20% 30% 40% 50% 60% 70% 80%

NS-NC

Exigir que tenga unsistema de calidad

certificado

No es un factor diferencial

Valorar que tenga unsistema de calidad

Fuente: AEC

Como se puede apreciar, la mayor parte de las empresas que contratan servicios de un tercero valoran, pero no exigen, un sistema de calidad certificado. Según las entrevistas realizadas, que apoyan estos datos, la exigencia real de una certificación suele venir únicamente de los grandes clientes. En cambio, si son PYME las que actúan como cliente no se da esta clase de requerimiento.

El cliente de la PYME española suele ser, en la inmensa mayoría de los casos, otra PYME. Según algunos entrevistados, como SoftWCare, los clientes no entienden bien que el hecho de que su desarrolladora les entregue rápido el producto suele implicar normalmente la obtención de un producto inmaduro y de poca calidad. Es práctica habitual que esto suceda así en el mercado, y la solución no es obvia.

En otras ocasiones son los proveedores de software los que no quieren educar a sus clientes en este sentido, pues ven un gran negocio en ese mantenimiento. La realidad, según los entrevistados, es que luego se sufren las consecuencias de esta actitud. El denominado mantenimiento no es tal, sino una mera garantía que hay que cubrir sin coste; correcciones no previstas ni, por supuesto, abonadas, que son complicadas de corregir a posteriori al no haberlo hecho bien desde el principio.

Según las entrevistas realizadas y lo desarrollado anteriormente en el informe, los puntos importantes a tener en cuenta en este sentido al respecto de las PYME se resumen a continuación:



• El cliente de una PYME suele ser otra pequeñas y mediana empresa, y en la mayor parte de las ocasiones microempresas.

• El cliente de estas empresas no le da en general importancia a la posesión de certificados de calidad a su proveedor.

• El cliente requiere del software en plazo, y por los motivos antes comentados éste suele ser inmaduro.

• El mantenimiento del software generado se convierte en un constante goteo de modificaciones a posteriori debido a:

o Ausencia de documentos de inicio de proyecto y especificación de requerimientos.

o Ausencia de planificación (ausencia de modelos de gestión de proyectos).

o Ausencia de pruebas planificadas.

o Necesidad de entrega de un producto terminado en un plazo de tiempo mínimo.

El resultado final no hace sino reforzar el concepto de programar rápido, al día, con plazos enormemente cortos, sin que los clientes exijan la calidad que merecerían esos productos. La desarrolladora, en este escenario, carece de tiempo y recursos, como ya se ha comentado, para variar la inercia del proceso tratando de implantar un modelo como los comentados.

En el caso de las grandes empresas dedicadas al desarrollo de software en España, los resultados de las entrevistas ofrecen datos completamente distintos sobre sus clientes. Éstos suelen ser grandes empresas, con altos requerimientos de calidad a sus proveedores, por lo que en estos casos la certificación de calidad (o una evaluación positiva de una implantación de un modelo de mejora de procesos) en los trabajos destinados a ellos suele ser exigida constantemente. La certificación de calidad pasa de ser un elemento diferenciador a un requerimiento.

Si en el caso de las empresas entrevistadas la actitud frente a la implantación de modelos de mejora viene marcada en gran medida por sus clientes, las entidades de certificación y acreditación entrevistadas van más lejos, poniendo al cliente en la parte más importante de todo este proceso. Según éstas, como se ha puesto de manifiesto en las entrevistas realizadas a las mismas, el cliente es quien debería exigir la calidad en el desarrollo del software, por encima de otros requerimientos, y es además quien debería concienciarse



de que, como una de las piezas más importantes, el sello de la certificación de calidad debería aparecer siempre en los productos que adquiere.

En este sentido, las administraciones públicas entrevistadas que actúan como clientes de empresas desarrolladoras medianas o pequeñas reconocen que comienzan a dar pasos al respecto. Las valoraciones en los concursos públicos, según lo comentado en las entrevistas, comienzan a destacar los sellos de calidad como puntos importantes, y así lo hacen saber a sus proveedores de software, que encuentran en este sentido un acicate más para tratar de implantar un modelo de calidad de procesos.

4.9 La necesidad real de las empresas españolas y el papel de los agentes intermedios

A la vista de los datos presentados y la visión del cliente comprador de software, los motivos fundamentales por los que una empresa debe certificarse o adoptar al menos un modelo de calidad son los siguientes:

• Para las microempresas: Dado que los clientes no la requieren, el motivo fundamental es el cambio de inercia de cara a la reducción de costes a medio o largo plazo, adoptando buenas prácticas de gestión de proyectos y de ciclo de vida del software, y la disminución del número de errores por hora gracias a nuevas prácticas de testing para minimizar los trabajos extra de garantía y mantenimiento.

• Para la PYME: Según su tamaño y el tamaño de los clientes, puede darse el caso de necesidad por requerimientos externos o, como en el caso de las microempresas, implantar la mejora por futuros ahorros de costes.

• Para las grandes empresas: Según lo comentado por los representantes entrevistados, los motivos de que implanten estos modelos son por requerimientos de sus clientes, o iniciativa propia para control interno de costes y marketing de cara al exterior.

La primera conclusión extraída al respecto de la necesidad real en España es que no existe, a priori, un motivo de peso que impulse a una microempresa hacia la implantación de un modelo de mejora. El desconocimiento de información al respecto sobre los beneficios reales y la falta de publicidad sobre modelos a seguir son un lastre frente a los costes que supone la implantación, comentados y desarrollados hasta este punto.

Por ello, en este caso, la aparición del agente intermedio se hace más evidente en el caso de las microempresas o PYME de pocos trabajadores.

En este punto, y una vez examinados los requerimientos que los clientes tienen con respecto a estas empresas, a lo expuesto en el punto 3.5.3 al respecto de las funciones que ese agente intermedio debería realizar habría que añadir lo siguiente:




• Realizar las oportunas campañas de información, por los métodos que se estimen necesarios, para hacer ver a los compradores de software en España de la necesidad de exigir productos con un sello de calidad.

• Realizar las oportunas campañas de información, por los métodos que se estimen necesarios, para hacer ver a las microempresas españolas de los beneficios reales de la implantación de modelos para la generación de productos bajo un sello de calidad.

El efecto que el enfoque sobre el cliente daría a las posibles iniciativas con respecto a la introducción de los modelos de calidad es un punto esencial, y ha quedado de manifiesto en las entrevistas realizadas. En casos en que el cliente no requiere sellos de certificación, ni le da importancia a los mismos, no hay necesidad palpable de inversión en certificación. Los responsables de las grandes empresas opinan que éste ha sido un hecho esencial a la hora de implantar un modelo y así lo han observado también algunas PYME entrevistadas.

Las conclusiones preliminares apuntan al establecimiento de una entidad con las características que se han venido desarrollando hasta este punto. Preguntados al respecto los entrevistados, los resultados son los que ofrece el



Gráfico 14. Las respuestas mayoritarias (un 39,4%) identifican a la administración pública como entidad impulsora de la certificación, mientras que un 24,2% sitúan al cliente como impulsor, y un 21,2% a organizaciones intermedias como por ejemplo las asociaciones empresariales.




Gráfico 14: Cuál debe ser la entidad u organismo que impulse la adopción de modelos de calidad por parte del empresariado español

0,0%

21,2%

24,2%

39,4%

15,2%

0% 5% 10% 15% 20% 25% 30% 35% 40% 45%

Otros

La propia empresa

Entidades intermedias

El cliente

Administración pública

Fuente: INTECO

De esta forma, las administraciones públicas parecen tener un gran peso específico al respecto de la visión actual de las empresas. En estos momentos ya son parte implicada en el proceso en varias vertientes:

• Convocatorias de subvenciones y otras ayudas.

o A nivel nacional, dentro del Plan Avanza, iniciado por el Ministerio de Industria, Turismo y Comercio, se ofrecen subvenciones en convocatoria anual49. Para el caso de solicitar ayuda para implementar ISO 9001:2000 se pueden recibir 6.000 euros, mientras que para una certificación ISO/IEC 15504 ó evaluación CMMI, desde 20.000 euros en su nivel 2 hasta 35.000 euros en su nivel 5.

o Estas convocatorias estiman que la duración de un proyecto de mejora de procesos requiere un año para el nivel 2 y 18 meses para el 3, que a juicio de los entrevistados es un plazo de tiempo muy corto.

• Apoyo claro hacia modelos de mejora de procesos y productos.

49 Más información disponible en http://www.mityc.es/ProfitTIC/Contenido/Guia/TiposProyectos/

http://www.mityc.es/ProfitTIC/Contenido/Guia/TiposProyectos/


o Las últimas convocatorias de subvenciones analizadas (entre ellas las correspondientes al Plan Avanza, el Gobierno de Aragón, o la Xunta de Galicia) se enfocan exclusivamente, como modelos dedicados a la mejora de procesos en empresas desarrolladoras de software, hacia la implantación de CMMI y ISO/IEC 15504.

• Creación y respaldo de foros e iniciativas para difundir las bondades de las certificaciones hacia la empresa.

Debido a que además tienden a solicitar y valorar certificaciones o evaluaciones de las empresas de desarrollo que subcontratan, como se ha comentado, la opinión general de los entrevistados es que deberían tener un papel más que preponderante en el impulso de aquéllas, más allá de la mera concesión de subvenciones y ayudas.

Al respecto de estas ayudas, un inconveniente percibido por las entidades entrevistadas (en un 100% de los casos) es el corto plazo de tiempo para acometer la implantación del modelo cuando éste ha sido subvencionado. Normalmente, según los modelos presentados, los planes de acción y mejora resultantes de las auditorías previas suelen ser extensos en el tiempo, debido a que la PYME, principal receptora de estas ayudas, tiene poco o nada implantado al respecto, y se debe actuar sobre casi todos los procesos. Este aspecto conlleva cargas elevadas de un trabajo extra que les hacen plantearse la conveniencia o no de aceptar la subvención. Con ello, retrasan o ignoran la certificación de calidad hasta que algún factor externo (como la necesidad surgida en forma de requerimiento desde sus clientes) les hace replantearse la certificación.

Otro aspecto que han destacado algunos de los entrevistados al respecto de las subvenciones de la administración es la falta de información que existe en algunos de estos organismos:

• En los textos de convocatorias de muchas de ellas se perciben errores por desconocimiento de los detalles en los modelos propuestos.

• Se limitan a los dos o tres modelos certificables más famosos, no existiendo la posibilidad hasta el momento de realizar la implantación de algún otro modelo más orientado a características particulares.

No obstante, los entrevistados perciben un interés real en el desarrollo de las PYME y la mejora de la calidad de sus productos. Este interés se ve apoyado sobre todo en el Plan Avanza, y se piensa que estas ayudas podrán fortalecer la visión del mercado ante la certificación e implantación de modelos de mejora de procesos.

Es una opinión generalizada entre los encuestados que, aunque el peso de la administración debe ser elevado, un papel preponderante a la hora de impulsar la



certificación de calidad entre las PYME españolas se debe otorgar a los organismos intermedios como las asociaciones empresariales. Los datos aportados hablan de algunos factores como:

• Proximidad a la PYME, lo que las dota de una gran confianza desde el punto de vista de los asociados.

• Relación excelente con las administraciones públicas.

• Afán de mejora de sus asociados, punto expuesto tanto por los representantes de las asociaciones entrevistados como por las propias PYME.

Las asociaciones empresariales son de esta forma un punto de encuentro básico en el proceso en la actualidad. Los métodos que actualmente utilizan para hacer llegar información a sus asociados, y que pueden ser usados también para la difusión de información sobre las certificaciones de calidad, suelen ser:

• Internet en general, mediante el uso de correo electrónico y la web de cada una de las asociaciones empresariales.

• Revistas informativas, que se hacen llegar a todos los asociados puntualmente.

• Convocatorias de foros de discusión, en los que las PYME abordan temas que les preocupan, los ponen en común y adoptan decisiones conjuntas en forma de grupos de trabajo. Los foros han sido identificados en las entrevistas como uno de los mejores medios para la difusión de la información sobre calidad del software. Las PYME se muestran completamente de acuerdo en participar en ellos, ofreciendo además su experiencia en aquellos casos en que han obtenido ya alguna certificación sobre el tema o, simplemente, están en vías de hacerlo.

Así mismo, algunos de estos organismos intermedios como CONETIC (Confederación Española de Empresas de Tecnologías de la Información y Electrónica, unión de 14 Asociaciones Territoriales con el objetivo de aunar esfuerzos y representar los intereses de las pequeñas y medianas empresas ante organismos locales, Autonómicos, Centrales y Europeos), han servido de intermediarios ante el Ministerio de Industria, Turismo y Comercio para crear un plan de subvenciones enmarcado en el Plan Avanza. Este plan consistía en apoyar económicamente a empresas asociadas dedicadas al desarrollo de software para lograr una evaluación exitosa en nivel 2 de CMMI, mediante la agrupación de empresas ante los proveedores de servicios profesionales de consultoría para poder reducir los altos costes de implantación. En julio de 2007, habían conseguido el nivel 2 de CMMI un total de 20 empresas. Para el próximo año (2008) se va a convocar el segundo proyecto COMPETIC, en el que además de las comunidades autónomas que ya han participado en el primero (Castilla y León, País Vasco, Navarra y Asturias) se sumarán, Estudio sobre la certificación de la calidad del software en España Página 125 de 147 Observatorio de la Seguridad de la Información Laboratorio Nacional de Calidad del Software



previsiblemente, Cantabria, Andalucía y Galicia, siempre a través de las asociaciones de empresas que forman CONETIC50.

Tabla 11: Asociaciones de empresas por Comunidad Autónoma

Comunidad Asociación Asturias Cluster TIC

Cantabria ASCENTIC (Asociación Cántabra de Empresas de Nuevas Tecnologías de la Información y las Comunicaciones)

Galicia

AGESTIC (Asociación Gallega de Empresas de Tecnología e Información)

EGANET (Asociación de Empresas Gallegas dedicadas a Internet) INEO (Cluster INEO – Zona Franca; Vigo)

País Vasco GAIA (Asociación Cluster de Telecomunicaciones; Agrupación Vasca de las Tecnologías Electrónicas y de la Información)

La Rioja AERTIC (Asociación de Empresas Riojanas de Tecnologías de la Información y la Comunicación)

Castilla y León AETICAL (Asociación de Empresas de TIC de Castilla y León) Comunidad Foral de Navarra ATANA (Asociación de Empresas Navarras de TIC)

Aragón AEIA (Asociación de Empresas de Tecnologías de la Información y Comunicaciones de Aragón)

Comunitat Valenciana ESTIC (Asociación de Empresas del Sector TIC) AVINFO (Asociación de Informática de la Comunitat Valenciana)

Región de Murcia TIMUR (Asociación Murciana de Empresas de Tecnologías de la Información y de la Comunicación)

Andalucía ETICOM (Asociación de Empresarios de Tecnologías de la Información y Comunicaciones de Andalucía)

Cataluña ASEITEC (Asociación de Empresas de Informática y Telemática de Cataluña)

Castilla-La Mancha FEDETICAM (Federación de Empresas de Tecnologías de la Información de Castilla La Mancha)

Comunidad Balear GSBIT (Asociación Balear de Empresas de Software, Internet y Nuevas Tecnologías)

Fuente: INTECO

4.9.1 El caso de la Junta de Extremadura

Es un caso especial al ser pionera en el campo del uso de software libre en la administración, y haber creado indirectamente un mercado particular de desarrollo de software con ciertas exigencias de calidad.

50 Las asociaciones que integran CONETIC son parte de las mostradas en la Tabla 8; a saber: AEIA, AETICAL, ASCENTIC, ASEITEC, ATANA, AVINFO, EGANET, ETICOM, FEDETICAM, GAIA, GSBIT, INEO y TIMUR.


Se ha realizado una entrevista con Carmen González y Jesús Rubio, Jefe de Servicio de Promoción y Coordinación de la Dirección General para la Sociedad de la Información de la Junta de Extremadura, para obtener su percepción acerca del mercado de la calidad, y en especial aplicado al software libre. A continuación se presentan las conclusiones obtenidas.

• El centro de las iniciativas actuales es la distribución del sistema operativo LINUX gnuLinEx, desarrollada por la Junta de Extremadura, y adaptada según las necesidades que surgen. Es por ello que mantienen varias distribuciones del sistema operativo, diferenciadas por los componentes adicionales incluidos sobre el núcleo básico:

o Distribución estándar.

o Distribución para el ámbito sanitario, preparada para el soporte de control de hospitales, médicos, etc.

o Distribución para los colegios con una gran cantidad de programas educativos incluidos.

o Distribución para las PYME.

o Distribución para las entidades y/o administraciones locales, que se encuentra en modo piloto en la actualidad (julio de 2007).

• Para este sistema operativo desarrollan las aplicaciones necesarias en cada caso, bien por cuenta propia (servicios informáticos de la Junta de Extremadura), o bien mediante la subcontratación de las mismas por los métodos más adecuados en cada caso. La característica principal de estas aplicaciones es que deben ser desarrolladas en código abierto, por lo que los códigos fuente de las aplicaciones han de ser entregados a la Junta para su almacenamiento en un repositorio de información común de acceso libre. En la mayor parte de las ocasiones, estos desarrollos son realizados por las PYME de la región.

• No se exige ninguna certificación de calidad a las empresas que optan a contratas mediante la participación en los concursos públicos convocados por la Junta de Extremadura, si bien la existencia de alguna de ellas es valorada positivamente. El único requerimiento obligatorio es el uso de la metodología METRICA, además de una valoración extra en la documentación del desarrollo.

• En los proyectos que se desarrollan para la Junta de Extremadura es obligatorio el desarrollo de una memoria del aseguramiento de la calidad, independientemente de si se posee o no un sello de certificación.



• Consideran que el requerimiento principal de código abierto implica un aumento muy considerable de la calidad del código, disminución en el número de errores, y mejoría en la documentación.

o Como anécdota, cuentan el caso de una empresa que demoró seis meses la entrega del código de una aplicación. Este tiempo se debió al cambio y limpieza del código fuente para su puesta en el repositorio de libre acceso, pues en la propia empresa consideraban que el listado fuente no poseía calidad para ser puesta a disposición de otros programadores. La aplicación contenía menos errores y aparentemente su rendimiento había mejorado al término de este tiempo.

• La certificación en sí sólo causa una mejor impresión y valoración. No es en ningún caso un elemento excluyente.

• Piensan que sin un sello de certificación o una evaluación de sus procesos, las empresas que desarrollan código abierto, en su mayoría pequeñas y medianas empresas, actúan internamente como si hubiesen pasado con éxito la auditoría de una entidad certificadora. Si bien es cierto que en el último año han ofrecido subvenciones para la obtención de certificados, los representantes de la Junta de Extremadura consideran que con el requisito de entrega de código impulsan en gran medida la calidad como parte fundamental del proceso de desarrollo en las PYME de la región. Así mismo, piensan que para ello las desarrolladoras deben aplicar implícitamente unos criterios de calidad de desarrollo que indirectamente suponen el uso de metodologías, librerías y herramientas en la elaboración del código y la documentación semejantes a las requeridas por cualquier modelo de mejora de procesos.

• Están inmersos en un proyecto de creación de un modelo de certificación para el software libre, pues éste siempre ha sido creado y donado desde la buena voluntad y ven la necesidad de mejorar el sistema. Cuentan con la ayuda de CENATIC (Centro Nacional de referencia de Aplicación de las Tecnologías de Información y Comunicación) para sistematizar la certificación del código abierto desde una perspectiva imparcial e independiente. Por las encuestas que han realizado, piensan que esta certificación presenta un interés real desde las PYME. Así mismo, se encuentran investigando sobre estándares y formatos abiertos, como guía de referencia para su modelo certificable.

• Sobre las subvenciones y apoyos a la empresa al respecto de la certificación de calidad:



o Piensan que deberían de tratarse en forma de un incentivo. Proponen la idea de que sean un apoyo para lograr la certificación, pero manteniendo un compromiso claro por parte de la empresa para continuar su mantenimiento y pasar las posteriores evaluaciones y auditorías.

o El pasado año (2006) se ofrecieron ayudas a la PYME para la implantación de modelos de calidad certificables.



5 INICIATIVAS PARA EL IMPULSO DEL DESARROLLO DEL SOFTWARE

A la vista de la situación expuesta hasta el momento, tanto el mercado, como las apuestas de las administraciones en forma de ayudas, los planes de mejora propuestos a las empresas por éstas y los resultados mayoritarios de las entrevistas apuntan a CMMI como el mejor modelo posible a la hora de la mejora de procesos.

ISO/IEC 15504 es más reciente, y existe la percepción entre la mayoría de los entrevistados de que se ha quedado atrás en el mercado, además de la preferencia europea por CMMI en estos momentos. No obstante, su ventaja es que está respaldada por ISO y su implementación es más barata porque requiere menos esfuerzo estructural, pudiendo ser aplicada a procesos concretos en lugar de un todo. A medio plazo, a nivel español, dejará de ser una evaluación de procesos para pasar a ser una certificación ISO respaldada finalmente por la ENAC (Entidad Nacional de Acreditación), por lo que se estima que su valor como marca aumentará exponencialmente.

No obstante, el desconocimiento palpable sobre otros modelos y certificaciones, como las orientadas a producto en lugar de procesos, o el afán por conseguir un sello reconocible como método de aumento de competitividad, llevan a la errónea idea de que CMMI (o ISO/IEC 15504) deba de ser el modelo a implantar. Pero su prestigio a nivel internacional es tan grande como su complejidad a la hora de obtenerla, tanto por los costes humanos como por los monetarios, así como por los cambios organizativos y de mentalidad que implica su adopción.

Mientras que las grandes empresas pueden realizar implementaciones de estos modelos de forma exitosa, como se ha presentado en el informe, la realidad española, en la que el mayor porcentaje de empresas corresponde a las microempresas, hace que esta visión sobre los modelos existentes deba ser replanteada en la PYME:

• No es posible implementar cualquier tipo de modelo en cualquier tipo de empresa, puesto que la complejidad de algunos de ellos es excesiva por multitud de factores:

o El número de empleados es un elemento diferenciador básico.

o El tipo de cliente y sus requerimientos deben ser también considerados.

• Existen múltiples iniciativas que han desarrollado modelos adaptables directamente a PYME, y a microempresas en especial.



• Existen modelos orientados tanto a producto como a la mejora de procesos, igualmente válidos cuando se trata de la mejora de la calidad del software y los procesos internos de la organización no están consolidados.

En esta coyuntura, el impulso de la calidad de software debe pasar por un proceso de difusión de estándares y modelos de forma orientada, seleccionando los modelos más adecuados y teniendo en cuenta dos factores fundamentales:

• Empresa objetivo y sus necesidades.

• Respaldo de los modelos elegidos en forma de sello de acreditación.

En este sentido, cobraría más fuerza la necesidad de crear una entidad desde la administración, bien independiente o bien dependiente del INTECO, que asumiera las funciones presentadas a lo largo del informe, obtenidas tras el estudio de la situación actual.

Las funciones presentadas anteriormente, resumidas, serían las siguientes:




o Utilizando un sitio web de Internet.

o Creando un foro de opinión.

o Promoviendo la creación de cursos, talleres y workshops sobre el tema.







• Crear canales de contacto entre los diversos organismos y entidades involucrados (asociaciones de empresas, confederaciones, universidades, entidades normalizadoras, etc.).

Así mismo,


• Realizar las oportunas campañas de información, por los métodos que se estimen necesarios, para hacer ver a los clientes compradores de software en España de la necesidad de exigir productos con un sello de calidad.

• Realizar las oportunas campañas de difusión, por los métodos que se estimen necesarios, para hacer ver a las microempresas españolas de los beneficios reales de la implantación de modelos para la generación de productos bajo un sello de calidad reconocible.

5.1 Elección del modelo adecuado según el tipo de empresa

Uno de los objetivos de la entidad debe ser establecer claramente los modelos a difundir a cada tipo de empresa, así como la necesidad de desarrollar modelos nuevos si fuese necesario. Como se ha visto, los modelos presentados en los apartados anteriores resuelven de forma distinta la aproximación a la calidad del producto final. Algunos de ellos centran sus esfuerzos en la mejora de la capacidad de los procesos que conducen a ese producto, otros se centran en las pruebas a realizar durante el ciclo de vida, y otros realizan una mezcla de ambas aproximaciones con modelos más reducidos.

A continuación se incluye un pequeño resumen de apoyo51 sobre los modelos más importantes presentados anteriormente, descartando aquellos generalistas y no centrados exclusivamente en desarrolladoras de software, así como los modelos con poca implantación. La referencia sobre las características especiales de cada modelo se encuentra en el apartado 3 de este informe.

51 Para elaborar este resumen y las valoraciones en él incluidas, se han tenido en cuenta la información disponible sobre cada uno de los modelos (documentación oficial publicada, etc.); las opiniones e información obtenida a través de las entrevistas a los expertos y representantes de entidades certificadoras, normalizadoras y expertos independientes; la información obtenida a través de las experiencias de implantación comunicadas por los entrevistados; y el conocimiento y opinión de los expertos entrevistados.


• Modelos orientados a mejora de procesos:

o CMMI for Development, v1.2 es implementable en empresas con departamentos de desarrollo a partir de 15-20 personas, y una difícil implementación en empresas menores. Es difícil de entender y excesivamente detallado para algunas organizaciones. Requiere gran cantidad de herramientas, de las cuales muchas de ellas tienen un coste elevado. El retorno de inversión se obtiene a medio o largo plazo, tiempo elevado para las microPYMEs. Como tal, con su definición actual no es un modelo adecuado para microempresas. Existen varias iniciativas para la implantación de este modelo en PYME y microempresas, pero a día de hoy no existen desarrollos publicados. Referente internacional entre los modelos de mejora de procesos y muy bien valorado, es evaluado por SEI.

o ISO/IEC 15504:2003, es implementable en empresas con departamentos de desarrollo a partir de 10-15 personas. Tiene una difícil implementación en empresas menores. Al igual que CMMI, requiere gran cantidad de herramientas, de las cuales muchas de ellas tienen un coste elevado. El retorno de inversión se obtiene a medio plazo, tiempo elevado para las microPYMEs. Como tal, con su definición actual no es un modelo adecuado para microempresas; aunque ISO, mediante el grupo de trabajo WG24, está trabajando en una norma para la implantación de este modelo en PYME y microempresas, pero a día de hoy no existen desarrollos publicados. Conocido internacionalmente, respaldado por ISO, y a medio plazo es posible que sea respaldado por ENAC como entidad acreditadora en España.

o SwTQM, está basado en EFQM y CMMI, suavizando la complejidad de estos dos modelos y aprovechando sus puntos fuertes con respecto a los procesos de software. Es aplicable a la PYME y, con más dificultad, a la microempresa. No posee requerimientos tan fuertes como los anteriores modelos.

o ITMark, está desarrollado con el enfoque en las PYME y la microempresa, por lo que es muy adecuado para ellas. Está basado en CMMI y desarrollado por ESI, partner del SEI, por lo que es compatible con las premisas de CMMI y, por tanto, es posible la evolución a éste a partir de la base inicialmente certificada como ITMark.

o MoProsoft, parte de la base de ISO/IEC 15504:2003 para definir un modelo orientado a PYME, evaluable mediante EvalProSoft. Se ha



convertido en la norma mexicana de calidad de software, y es ampliamente implementado en Latinoamérica. El grupo WG24 de ISO lo toma como referencia para el desarrollo de su modelo orientado a microempresas.

• Modelos orientados a mejora del producto:

o TPI/TMAP, dado que proporciona una idea general de la madurez del proceso de testeo, estableciendo pasos de mejora graduales y controlados, es posible su implementación en cualquier tipo de empresa. Su coste es inferior al de modelos comentados. Se centra únicamente en el testeo, por lo que los objetivos de negocio y procesos asociados no se ven afectados. Es muy adecuado en empresas pequeñas con procesos poco maduros.

o ISO 9126, es un modelo genérico y es necesario adaptarlo, ya que deben ser elegidas que subcaracterísticas son relevantes, qué métricas específicas para los componentes software y definir indicadores para las características de calidad. Por ello, requiere un trabajo previo de consultoría, lo que la sitúa en desventaja frente a otros modelos.

De aquí se desprende que mientras CMMI e ISO/IEC 15504 son modelos para grandes y medianas empresas, los modelos ITMark y SwTQM son certificables y pueden ser implementados en cualquier PYME, aunque ITMark se adaptaría mejor a la microempresa debido a que SwTQM no deja de ser una personalización para software del modelo EFQM para PYME. En estas microempresas con muy pocos empleados, además, son una buena opción:

• El uso de modelos orientados a la mejora del producto como TPI, que únicamente se enfocan sobre las pruebas del software y son de rápida implementación (con respecto a los demás).

• El uso de métodos ágiles, como XP (eXtreme Programming), orientados al producto y a la satisfacción y confianza del cliente frente a otros factores. Toman al usuario final como parte del equipo y se utilizan ante todo en proyectos a corto plazo, lo que la hace muy aplicable en el caso de microempresas debido a la relación próxima con el cliente y el tipo de proyectos realizados. Así mismo, un factor positivo añadido es la posibilidad de rápida adaptación que estos métodos proveen.

Como se ha comentado anteriormente, debería existir un respaldo a estos modelos, o aquéllos que se considere establecer como objetivo de difusión. Para ello, tal y como



sucede en el Gobierno de Aragón (caso presentado en este informe), la creación de un sello de calidad respaldada por la entidad a crear (o el propio INTECO) es una solución que garantizaría la respuesta ante las empresas y sus clientes, dotando al modelo de un gran valor añadido (además de la propia mejora que para la empresa supone la implantación del modelo).

La adopción de un sello de calidad, independientemente de cuál fuera elegido por las empresas asesoradas por la nueva entidad, lleva consigo evaluaciones posteriores a la concesión de la certificación, puesto que ésta suele tener un periodo de validez determinada según el modelo. Esto implica, como se ha visto anteriormente en este informe, que el coste del sello para la empresa no termina con la concesión inicial y debe ser provista una partida anual para los costes de las evaluaciones anuales para su mantenimiento.

En este sentido, teniendo como foco el ahorro de costes para las pequeñas empresas y, en especial, las microempresas, debería ser tomado en consideración un esquema de evaluaciones anuales de la siguiente forma:

• Basado en la definición de una serie de criterios, normas y plantillas que permitan la autoevaluación formal en las empresas.

• Debería estar orientado a la entrega, por parte de la empresa certificada, de una serie de documentos claros, sencillos, basados en las plantillas comentadas en base a los criterios y normas anteriores, y en el marco de un calendario prefijado que facilite esta autoevaluación. Este calendario en ningún caso debería solaparse con requerimientos anuales de otras administraciones públicas como la presentación de impuestos, auditorías, etc.

• Las empresas que entregasen la documentación requerida en el plazo prefijado podrían ser renovadas automáticamente, quizá bajo el pago de una tasa de renovación mínima de acuerdo al tamaño de la empresa.

• Las empresas, en cualquier momento, podrían ser objeto de auditoría según una muestra seleccionada anualmente para verificar:

o Que la documentación aportada en el año en curso (o anteriores) refleja el estado de la implantación de su modelo.

o Que el modelo certificado cumple con lo estipulado mediante una evaluación completa.

En este marco de actuación, y a grandes rasgos, los costes de las evaluaciones anuales para la renovación de la certificación supondrían únicamente una tasa anual a pagar




según su tamaño o modelo. La entidad certificadora, por el contrario, debería ser quien realizase las auditorías según la muestra de empresas elegida

5.2 Iniciativas en el extranjero sobre la calidad como impulso a la empresa

Como referencia y soporte a las funciones de la entidad cuya creación se recomienda, se incluyen a continuación las iniciativas más importantes que, en el extranjero, se llevan a cabo en materia de mejora de la calidad e impulso a la empresa.

5.2.1 Comisión Europea

La Comisión Europea inició en el año 1997 un programa de actuación para promover mejoras en la industria de desarrollo de software, a través del establecimiento y/o desarrollo de modelos y metodologías adecuadas a cada uno de los tipos de empresa localizadas en el ámbito de los países de la Unión Europea. Esta iniciativa, denominada ESSI (European Systems and Software Initiative), pretende conseguir una mejora de eficiencia, mayor calidad, y mejora en general de la economía de estas empresas; la adopción de las Mejores Prácticas en el campo del software.

La meta de ESSI es asegurar que los desarrolladores de la Unión Europea posean un nivel de clase mundial (excelencia en el desarrollo), como mejora de la competencia ante países desarrolladores fuera de los límites de la UE. Para conseguir estos objetivos, las acciones a llevar a cabo son:

• Concienciar a las organizaciones destacando la importancia de los procesos de desarrollo de software para la competitividad de la industria europea.

• Demostrar qué puede ser hecho en el campo de la calidad para la mejora de las prácticas de desarrollo de software, a través de pruebas piloto.

• Crear comunidades de interés en Europa trabajando hacia una meta común de mejora de las prácticas de desarrollo.

• Elevar el nivel de los profesionales del software en Europa.

El alcance del programa abarca a cualquier organización de cualquier sector de la economía cuya base principal del negocio sea la generación de software. Dado que según la UE52 la mayor parte del software es desarrollado por organizaciones que no pertenecen al sector IT, además de PYME y microempresas, estos dos grupos serán sobre todo la base del programa.

52 http://cordis.europa.eu/esprit/src/essi.htm

http://cordis.europa.eu/esprit/src/essi.htm


Los tipos de proyecto a implementar dentro de ESSI, y en el marco del programa de trabajo de ESPRIT, son los siguientes:

• Process improvement experiments (PIE): la meta de estos proyectos es demostrar la mejora de los procesos mediantes pruebas piloto extrapolables más tarde a otras organizaciones del mismo tipo.

• ESSI PIE Nodes (ESPINODE): participación de organizaciones a nivel de nodos regionales en una red europea establecida por la Comisión para estimular, soportar y coordinar un conjunto de PIEs para explotar sinergias, compartir el conocimiento, etc.

• Pro-Active Software Best Practice Networks (ESBNETs): establecimiento de redes europeas de organizaciones que gestionan localmente conjuntos de Mejores Prácticas aplicadas al software, de forma que estén en disposición de ejecutar pruebas de aplicación en especial a microempresas, ser capaces de realizar evaluaciones, de ejecutar planes de mejora, y compartir su experiencia a otras redes de aplicación.

Tanto ESPINODEs como ESBNETs tienen como meta continuar los resultados de la iniciativa a nivel regional. Mientras que el objetivo de ESPINODE es proveer soporte a las PIE, ESBNET tiene como meta integrar las acciones realizadas a pequeña escala en una red cuyo énfasis se sitúe en la comunidad de empresas no acogidas a PIE.

Fruto de este proyecto se han creado varios modelos con implantación regional, a través de los programas piloto comentados, en países como Italia, Irlanda, Suiza y Austria. Sin embargo, los resultados no han sido extrapolados ni se ha ahondado en los modelos creados de cara a su difusión generalista.

Programa marco para la innovación y la competitividad (CIP) de 2007-2013

Con objeto de tener en cuenta la diversidad de sus objetivos y de garantizar su visibilidad, el CIP comprende tres subprogramas específicos. Los intereses de las pequeñas y medianas empresas (PYME) y la innovación ecológica constituyen prioridades transversales y se tienen en cuenta en todo el programa marco.

Uno de estos programas, el de iniciativa empresarial y la innovación, reúne acciones dirigidas a promover la iniciativa empresarial, la competitividad industrial y la innovación. El programa se dirige expresamente a las PYME, desde las empresas «gacela» (empresas de crecimiento rápido) de alta tecnología hasta las microempresas y empresas familiares, que son la gran mayoría de empresas europeas. Facilita el acceso de las PYME a la financiación y a las inversiones en su fase inicial y de crecimiento. Asimismo, hace posible que las empresas puedan acceder a información y asesoramiento sobre el funcionamiento




del mercado interior y sus posibilidades, así como sobre la legislación comunitaria que les es aplicable y sobre la legislación futura, para así poder prepararse y adaptarse de manera rentable. A tal fin, los servicios europeos de ayuda a las empresas desempeñan un papel importante. El programa prevé además el intercambio de mejores prácticas entre los Estados miembros a fin de mejorar el entorno normativo y administrativo para las empresas y la innovación. El Programa para la iniciativa empresarial y la innovación se basa en varios instrumentos financiados por el Programa plurianual en favor de la empresa y el espíritu empresarial, el Sexto programa marco para acciones de investigación, el programa LIFE y el Programa para la competitividad industrial, que ha finalizado el 31 de diciembre de 2006. Las iniciativas no detallan investigación en calidad del software, aunque sí incluyen proyectos de subvenciones englobados en la mejora general de la PYME. En este sentido, se pueden consultar las páginas web oficiales del ICT PSP53, y la web de SOST54.

5.2.2 Brasil

El Proyecto MPS.Br - mejora de proceso del software brasileño - es una iniciativa global promovida por la administración brasileña que involucra a universidades, grupos de investigación y empresas, bajo la coordinación de la Sociedad SOFTEX55 (Sociedad para Promoción de la Excelencia del Software Brasileño). El proyecto, en marcha desde el 2003, tiene como finalidad la definición y difusión de un Modelo de Referencia y un Modelo de Negocio para la mejora del proceso de software (MR.MPS y MN.MPS, respectivamente).

El proyecto promueve la calificación de un grupo amplio de empresas compatible con los estándares de calidad aceptados internacionalmente por la comunidad de software, a costos accesibles para la mayoría de las empresas brasileñas, siendo adecuado al perfil y la cultura de cada una de ellas.

La propuesta base es la elaboración de un Modelo de Referencia de Procesos, basado en los conceptos de madurez y capacidad de proceso, para evaluación y mejora de la calidad y productividad de productos y servicios de software para:

• Fomentar la calidad por parte de la industria nacional de software

• Dotar de una capacitación para la adecuación a los modelos internacionales para alineamiento con la realidad y decisiones de la política de software brasileña.

53 En http://ec.europa.eu/information_society/activities/ict_psp/index_en.htm 54 En http://www.sost.es/CIP.html 55 Más información disponible en http://www.softex.br

http://ec.europa.eu/information_society/activities/ict_psp/index_en.htm

http://www.sost.es/CIP.html

http://www.softex.br/


Las Instituciones brasileñas con competencias en la mejora de procesos de software en empresas que participan del MPS.BR desde diciembre de 2003 son:

• La Sociedad SOFTEX, coordinadora del proyecto.

• Instituciones de enseñanza, investigación y centros tecnológicos (Coppe/UFRJ, Cesar, CenPRA).

• La Compañía de Informática del Paraná (Celepar), donde está hospedado el Subcomité de Software de la Asociación Brasileña de Normas Técnicas (ABNT).

• Agentes locales SOFTEX: Minas Gerais (FUMSOFT), Rio de Janeiro (Riosoft) y en Campinas (SOFTEX Campinas).

• La Universidad Católica de Brasilia (UCB).

Los resultados esperados MPS.Br son:

• El Modelo de Mejora de Procesos de Software (considerando las prácticas de la comunidad de software, nacional e internacional, con interpretación y aplicaciones con foco en la estrategia competitiva de las empresas de software brasileñas)

• El Método de Evaluación de Procesos.

• Un conjunto de herramientas y guías con orientaciones para la utilización de esos resultados.

La coordinación del programa MPS.BR consta de dos estructuras de apoyo para el desarrollo de sus actividades:

• Fórum de Credenciamento e Controle (FCC), que tiene por objetivo asegurar que las Instituciones Implementadoras y las Instituciones Evaluadoras sean sometidas a un proceso adecuado de acreditación y que sus actuaciones se mantienen en dentro de los límites éticos y de calidad esperados, además de evaluar y controlar los resultados del programa MPS.BR.

• Equipe Tecnica do Modelo (ETM), es el encargado de actuar sobre los aspectos técnicos del modelo, tanto con el marco de referencia (MR-MPS) como el método de Evaluación (MA-MPS):

o Concepción y evolución de los modelos.

o Elaboración y actualización de guías.




o Preparación de material divulgativo y formativo.

5.2.3 Argentina

Uno de los casos que exponemos a continuación es el de la República Argentina, donde paralelamente han convergido tanto la iniciativa privada como la pública en la adopción de medidas concretas para el fomento de la calidad del software.

En este marco, se distinguen dos actores fundamentales en el desarrollo y la puesta en marcha de este tipo de iniciativas:

INTI

El Instituto Nacional de Tecnología Industrial56 (INTI) de la República Argentina es un organismo independiente, que actúa en la órbita de la Secretaría de Industria, Comercio y de la Pequeña y Mediana Empresa, del Ministerio de Economía y Producción.

El INTI es referente nacional en tecnología y líder en mediciones y ensayos de referencia con reconocimiento internacional, que contribuye a mejorar el bienestar y la calidad de vida de la población.

Actúa como:

• Referente técnico público, tanto para el Estado Argentino como para el ámbito privado, en:

o La aplicación de regulaciones de calidad e identidad de productos y la evaluación de conformidad,

o El cumplimiento de la Ley de Metrología,

o El apoyo general y técnico al Sistema Nacional de la Calidad,

o Las certificaciones de interés nacional que tengan carácter obligatorio y aquellas del campo voluntario que le sean requeridas por su idoneidad técnica.

• Responsable tecnológico de facilitar la integración de toda la comunidad al sistema productivo, promoviendo la asociación profesional, apuntalando el desarrollo local y fomentando la creación de nuevas empresas.

• Asistente público para la mejora de la competitividad industrial, contribuyendo al desarrollo y la transferencia de tecnología mediante la instrumentación de

56 Disponible en www.inti.gov.ar

http://www.inti.gov.ar/



soluciones innovadoras, desde el diseño hasta el producto final, para fortalecer así los eslabones nacionales de las cadenas de valor.

CESSI Argentina

La Cámara de Empresas de Software y Servicios informáticos57 (CESSI), es la entidad que agrupa y representa a las empresas dedicadas al desarrollo, producción, comercialización e implementación del software y todas las variantes de servicios en todo el ámbito de la república Argentina.

Con más de 300 empresas o entidades asociadas actualmente representa el 80% de los ingresos del sector y más del 85% de los empleos. Como tal, CESSI, hoy en día, es uno de los referentes centrales de la Industria de Tecnología Argentina entre los gobiernos nacional y extranjeros, el sector privado, la academia y los mercados Internacionales.

El programa del Software58

En el año 2002 se le encomendó al INTI el desarrollo de un proyecto que permitiera promover la comercialización de software argentino en el exterior trabajando conjuntamente con las empresas productoras para crear valores de exportación genuinos que, a su vez, generaran trabajo calificado. El objetivo propuesto es la generación de un modelo INTI de certificación progresiva de niveles de calidad acompañando a las empresas en el proceso con ventajas impositivas de distinto tipo.

A partir de la oportunidad abierta por la devaluación, las empresas productoras de software y servicios se lanzaron a mejorar sus procesos, promoviendo asociaciones regionales entre ellas y adoptando modelos de calidad reconocidos internacionalmente, como CMM/CMMI, ISO 9000.

Simultáneamente con este empuje del mercado, el Congreso de la Nación (de la República Argentina) analizaba una ley nacional de software59 para promocionar las actividades relacionadas con software y servicios informáticos y reconociendo a esta industria como estratégica.

Para mejorar su rendimiento en varias regiones del país las empresas argentinas de software, casi todas las PYME, comenzaron a relacionarse entre sí, con el fin de adoptar modelos comunes de desarrollo que les permitieran comercializar productos y servicios bajo exigencias de calidad internacionales. El Polo Tecnológico de Rosario y el Cluster

57 Más información en www.cessi.org.ar 58 Información obtenida directamente de la WEB del INTI: www.inti.gov.ar 59 Ley 25.922 de Promoción de la Industria del Software, publicada en el Boletín Oficial el 09/09/2004

http://www.cessi.org.ar/

http://www.inti.gov.ar/


Córdoba Technology fueron pioneros en la creación de procesos de asociación. Poco a poco y con la promulgación de la ley, que obliga a adoptar normas de calidad para acceder a los beneficios que otorga, se crean otras asociaciones en otras regiones del país.

Todo esto fue más allá de lo que la situación original definía como rol para el INTI conduciendo a la necesidad de establecer diferentes laboratorios regionales.

El objetivo del programa del software es evaluar y poner a disposición los medios para satisfacer las demandas de mejora de eficiencia y calidad de las empresas productoras de software y servicios informáticos.

Para ello, se establece como estrategia la puesta en marcha de una red de laboratorios regionales, para sensibilizar sobre los temas de calidad y procurar servicios a las empresas para alcanzar niveles de calidad acordes a las exigencias de la demanda nacional e internacional.

Las líneas de trabajo marcadas en el dicho programa son:

• Mejora de Calidad de Procesos de Desarrollo de Software.

• Evaluación de Calidad de Productos.

• Testing y Aseguramiento de la Calidad.

• Diseño y Productividad.

Las actividades desarrolladas en el marco de este programa son:

• Seminarios de divulgación y sensibilización.

• Cursos de Capacitación.

• Diagnósticos y Asistencia Técnica.

• Transferencias Tecnológicas.

Cada laboratorio se concibe como una asociación entre el polo tecnológico local, el INTI y universidades de la región. Esta unión permite desarrollar las líneas de trabajo enunciadas, a través de una puesta en marcha acorde con la especificidad y urgencia de cada región.

Los laboratorios creados en el marco del programa son los siguientes:




• Centro de Calidad en Tecnologías de la Información60: Ha sido el primero en ser inaugurado y el que se encuentra más desarrollado en la actualidad. Ubicado en el Rosario y destinado a la calidad referida a la fabricación y sus procesos. Ha sido inaugurado en 2005. Las actividades desarrolladas por el este laboratorio son:

o Promover el desarrollo tecnológico de las PYME fomentando la cultura de la calidad, esperándose los siguientes resultados:

o Generar una masa visible de productores comprometidos con el desarrollo de software de alta calidad.

o Generar productos y servicios exportables de alta calidad.

o Incrementar la sofisticación de la demanda local de modo de estimular los procesos de mejora continua.

o Visibilidad internacional de Rosario, como centro productor de software de alta calidad.

• Laboratorio de la calidad del software en Córdoba, destinado a la calidad en cuanto al buen funcionamiento y las técnicas de detección de errores en forma temprana (servicios de testeo). Puesto en marcha el en 2006.

• En Buenos Aires, junto con el Polo IT de buenos Aires, el laboratorio se está orientando a la calidad a partir de tener modelos que mejoren la productividad y el diseño.

• Laboratorio de la calidad del software de Mendoza está orientado a la calidad en el producto final, fundamentalmente validar que el software hace lo que promete hacer y evaluar si es apto para quien fue desarrollado.

5.2.4 México

El proyecto PROSOFT (Programa para el Desarrollo de la Industria del Software), lanzado en 2002, y promovido por la Secretaría de Economía de México, surge con el objetivo de la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software adaptados a la industria software mexicana. El PROSOFT61 engloba la política pública federal para desarrollar la industria de tecnologías de información (TI); por ello incluye actividades tales como desarrollo de software, servicios de TI, etc.

60 http://www.polotecnologico.net/CentroDeCalidad.asp 61 http://www.software.net.mx

http://www.polotecnologico.net/CentroDeCalidad.asp

http://www.software.net.mx/



Una de las iniciativas encuadradas en PROSOFT es la que concierne a la creación de un modelo de mejora, capacidad y evaluación de procesos de software. En ella participan universidades, empresas, la asociación AMCIS62 (Asociación Mexicana para la Calidad de Ingeniería del Software) y el CONACYT (Consejo Nacional de Ciencia y Tecnología). Esta iniciativa ha dado como resultado la creación de la norma nacional para el desarrollo del software NMX-I-059-NYCE, estandarización del modelo de mejora de procesos MoProSoft creado en el marco del plan PROSOFT.

A diferencia de iniciativas gubernamentales de otros países, en México no se ha creado ningún organismo encargado de la regulación y fomento de la calidad del software, ni otro tipo de laboratorio como en el caso argentino.

62 Más información disponible en http://www.amcis.org.mx

http://www.amcis.org.mx/


ÍNDICE DE TABLAS

Tabla 1: Modelos y metodologías existentes en el mercado...............................................30

Tabla 2: Beneficios de la implantación de CMMI según encuestas del SEI........................39

Tabla 3: Evaluaciones SCAMPI Clase A, a enero de 2007.................................................42

Tabla 4: Tiempo de implantación de los niveles CMMI .......................................................44

Tabla 5: Empresas con el sello de excelencia EFQM (Club Excelencia en Gestión)..........52

Tabla 6: Tiempo de implantación de los procesos ITIL .......................................................57

Tabla 7: Definición de la PYME según la normativa de la Comunidad Europea (en vigor desde el 1 de enero de 2005)..............................................................................................80

Tabla 8: Clasificación de las PYME por volumen de negocio .............................................80

Tabla 9: Empresas españolas dedicadas a actividades informáticas en 2006 ...................81

Tabla 10: Costes económicos asociados a las evaluaciones o certificaciones...................93

Tabla 11: Asociaciones de empresas por Comunidad Autónoma.....................................126



ÍNDICE DE GRÁFICOS

Gráfico 1: Modelos existentes en el mercado encaminados a la mejora de procesos según especificaciones de la norma ISO 9001:2000 .....................................................................33

Gráfico 2: Nivel de madurez según CMMI, por tamaño de las organizaciones (muestra de 1680 empresas que han comunicado sus datos al SEI) .....................................................37

Gráfico 3: Estructura de procesos de ISO/IEC 15504 (SPICE), según indica la norma......45

Gráfico 4: Estructura del modelo de excelencia de EFQM..................................................51

Gráfico 5: Estructura del modelo ITIL ..................................................................................56

Gráfico 6: Estructura del modelo TPI...................................................................................61

Gráfico 7: Calidad en el ciclo de vida del software, según ISO 9126 ..................................65

Gráfico 8: Conocimiento sobre CMM/CMMI (empresas dedicadas a actividades informáticas) ........................................................................................................................87

Gráfico 9: Conocimiento sobre ISO 15504 (empresas dedicadas a actividades informáticas) ........................................................................................................................87

Gráfico 10: Interés/primera opción de los entrevistados sobre los modelos de mejora de la calidad a la hora de elegir un modelo para su implantación................................................88

Gráfico 11: Motivos que llevan a las empresas a implementar un modelo de mejora de procesos ............................................................................................................................106

Gráfico 12: Mejoras obtenidas tras la implantación del modelo de calidad.......................108

Gráfico 13: Posición como cliente a la hora de contratar servicios de un proveedor ........118

Gráfico 14: Cuál debe ser la entidad u organismo que impulse la adopción de modelos de calidad por parte del empresariado español......................................................................123

http://www.inteco.es

http://observatorio.inteco.es Estudio sobre la certificación de la calidad del software en España Página 146 de 147 Observatorio de la Seguridad de la Información Laboratorio Nacional de Calidad del Software

http://www.inteco.es/

http://observatorio.inteco.es/


http://www.inteco.es/Calidad_del_Software/Laboratorio_Nacional


http://www.inteco.es/Calidad_del_Software/Laboratorio_Nacional

Documents

· Instituto Nacional de Tecnologías de la Comunicación. Edición: Abril 2008 . La presente publicación pertenece a . Instituto Nacional de Tecnologías de la Comunicación (INTEC