EVC001 - DSA - Diagnostico de La Situacion Actual-Public

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta
Diagnostico de la situacion actual
Esta obra est distribuida bajo la licencia Reconocimiento-Compartir bajo la misma licencia 3.0 Espaa de Creative Commons Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by-sa/3.0/deed.es
Fecha:13/07/2009

Diagnostico de la situacion
<Insertar logo>
NDICE
1 INTRODUCCIN................................................................................................................ 7 2 HARDWARE...................................................................................................................... 9 2.1 Compatible Linux.....................................................................................................9 2.2 Linux-tested........................................................................................................... 15 2.3 Comparativa........................................................................................................... 16 3 EMPRESA ....................................................................................................................... 17 3.1 ISO 9001:2000&2008............................................................................................. 18 3.1.1 Caracterizacin.............................................................................................. 18 3.1.2 Descripcin general........................................................................................ 18 3.1.3 Estructura del modelo....................................................................................19 3.1.4 Mtodo de evaluacin....................................................................................22 3.1.5 Certificacin................................................................................................... 23 3.1.6 Presencia en el mercado de las TICs............................................................... 23 3.2 EFQM...................................................................................................................... 25 3.2.1 Caracterizacin.............................................................................................. 25 3.2.2 Descripcin general........................................................................................ 25 3.2.3 Estructura del modelo....................................................................................26 3.2.4 Mtodo de evaluacin....................................................................................27 3.2.5 Certificacin................................................................................................... 29 3.2.6 Presencia en el mercado de las TICs............................................................... 30 3.3 IT-Mark................................................................................................................... 31 3.3.1 Caracterizacin.............................................................................................. 31 3.3.2 Descripcin general........................................................................................ 31 3.3.3 Estructura del modelo....................................................................................35 3.3.4 Mtodo de evaluacin....................................................................................36 3.3.5 Certificacin................................................................................................... 38 3.3.6 Presencia en el mercado de las TICs............................................................... 39 3.4 Comparativa........................................................................................................... 40 4 PROCESO....................................................................................................................... 41 4.1 CMMI...................................................................................................................... 42 4.1.1 Caracterizacin.............................................................................................. 42 4.1.2 Descripcin general........................................................................................ 42 4.1.3 Estructura del modelo....................................................................................48 4.1.4 Mtodo de evaluacin....................................................................................49
http://www.cenatic.es.
Pg. 2 de 119

4.1.5 Certificacin................................................................................................... 50 4.1.6 Presencia en el mercado de las TICs............................................................... 51 4.2 ISO/IEC 15504 (SPICE)............................................................................................53 4.2.1 Caracterizacin.............................................................................................. 53 4.2.2 Descripcin general........................................................................................ 54 4.2.3 Estructura del modelo....................................................................................57 4.2.4 Mtodo de evaluacin....................................................................................59 4.2.5 Certificacin................................................................................................... 60 4.2.6 Presencia en el mercado de las TICs............................................................... 60 4.3 ISO 20000/ITIL/CMMI-SVC.......................................................................................61 4.3.1 Caracterizacin.............................................................................................. 61 4.3.2 Descripcin general........................................................................................ 62 4.3.3 Estructura del modelo....................................................................................64 4.3.4 Mtodo de evaluacin....................................................................................67 4.3.5 Certificacin................................................................................................... 67 4.3.6 Presencia en el mercado de las TICs............................................................... 69 4.4 EN DESARROLLO.................................................................................................... 69 4.4.1 QualiPSo.........................................................................................................69 4.4.1.1 OMM. Caractersticas y plan de creacin................................................73 4.4.1.2 Elementos de fiabilidad y confianza (TWEs)............................................75 4.4.1.3 El modelo de evaluacin de madurez de procesos OMM.........................77 4.4.1.4 Conclusiones y perspectiva futura..........................................................79 4.5 Comparativa........................................................................................................... 79 5 SOFTWARE - PRODUCTO................................................................................................82 5.1 ISO 9126................................................................................................................ 82 5.1.1 Caracterizacin.............................................................................................. 82 5.1.2 Descripcin general........................................................................................ 82 5.1.3 Estructura del modelo....................................................................................84 5.1.4 Mtodo de evaluacin....................................................................................86 5.1.5 Certificacin................................................................................................... 88 5.2 McCall and Boehm.................................................................................................. 90 5.3 FURPS/FURPS+....................................................................................................... 90 5.4 NASA SATC............................................................................................................. 91 5.4.1 QSOS.............................................................................................................. 92 5.4.2 Open Source Maturity Model.......................................................................... 94 5.5 EN DESARROLLO.................................................................................................... 94 5.5.1 QualOSS......................................................................................................... 94 5.5.1.1 Modelo de calidad QUALOSS................................................................... 95 <Insertar logo>
Pg. 3 de 119

5.5.1.2 Metodologa............................................................................................ 96 5.5.1.3 Iniciar el proceso.................................................................................... 97 5.5.1.4 Planificacin del anlisis.........................................................................98 5.5.1.5 Recogiendo y analizando los datos.........................................................98 5.5.1.6 Interpretar resultados.............................................................................98 5.6 Comparativa......................................................................................................... 100 6 Certificacin de aptitudes y competencias personales (PERSONAS).............................101 6.1 IT Card................................................................................................................. 102 6.1.1 Caracterizacin............................................................................................ 102 6.1.2 Descripcin general...................................................................................... 102 6.1.3 Mtodo de evaluacin.................................................................................. 103 6.1.4 Certificacin................................................................................................. 103 6.1.5 Presencia en el mercado de las TICs.............................................................105 6.2 ITIL....................................................................................................................... 105 6.3 CompTIA Linux+................................................................................................... 106 6.4 LPI........................................................................................................................ 107 6.5 Novell Corporation: Linux Professional/Engineer.................................................. 107 6.6 Red Hat................................................................................................................ 108 6.7 Brainbench Certifications..................................................................................... 108 6.8 Mandriva Certification.......................................................................................... 109 6.9 SAIR Linux GNU Certification................................................................................ 109 6.10 MySQL Certification............................................................................................ 110 6.11 Solaris Certification............................................................................................ 111 6.12 Certificaciones Morfeo........................................................................................ 111 6.13 Pseudo-certificacin en competencias personales..............................................113 6.14 Comparativa....................................................................................................... 113 <Insertar logo>
ndice de imgenes
Imagen 1: Estructura de la norma ISO 9001:2008...................................22 Imagen 2: Informe ISO de certificados ISO 9001 en 2006........................26
http://www.cenatic.es. Pg. 4 de 119

Imagen 3: Mapa de criterios del modelo 1...............................................28 Diagnostico de la situacion Imagen 4: Esquema del mtodo de evaluacin de EFQM.........................30 Imagen 5: Relacin de niveles IT Mark y CMMI.........................................36 Imagen 6: Modelo de mejora de IT Mark..................................................37 Imagen 7: Requisitos a cumplir en los distintos niveles de IT Mark..........37 Imagen 8: Evaluacin basada en 10 SQUARED........................................39 Imagen 9: Evaluacin de procesos de seguridad de la informacin.........40 Imagen 10: Constelaciones CMMI.............................................................45 Imagen 11: Representacin escalonada...................................................48 Imagen 12: Ejemplo de perfil objetivo (representacin continua)............50 Imagen 13: Estructura CMMI....................................................................51 Imagen 14: Dimensin de procesos.........................................................58 Imagen 15: Esquema de niveles que desea mejorar la organizacin.......59 Imagen 16: Estructura del proceso SPICE.................................................60 Imagen 17: Mdulos de ITIL......................................................................66 Imagen 18: Requisitos de la norma ISO 20000 en los distintos procesos.67 Imagen 19: Esquema resumen del objetivo del proyecto QualiPSo..........72 Imagen 20: Ciclo de creacin del OMM....................................................76 Imagen 21: Niveles de madurez definidos en el modelo OMM.................78 Imagen 22: Proceso de establecimiento de correspondencias entre los elementos de confianza identificados para el OMM y los definidos en CMMI........................................................................................................79 Imagen 23: Esquema de cada una de las partes de la ISO 9126..............86 Imagen 24: Sub caractersticas en las que se divide cada una de las partes.......................................................................................................87 Imagen 25: Caractersticas que define el modelo de calidad...................87 Imagen 26: Relacin entre los estndares ISO 9126 e ISO 14598............88 Imagen 27: Marca IRAM certificacin producto software .........................90 Imagen 28: Esquema del modelo de calidad............................................98 Imagen 29: La metodologa de QualOSS se basa en cuatro tareas bsicas. .................................................................................................................99 Imagen 30: Ejemplo de Certificados IT Card...........................................108 Imagen 31: Mdulos de IT Card disponibles...........................................108
<Insertar logo>
ndice de tablas
Tabla 1: Comparativa de certificaciones hardware en software de fuente

abierta......................................................................................................18 Diagnostico de la situacion Tabla 2: Resumen de caractersticas de ISO 9001...................................20 Tabla 3: Resumen de caractersticas de EFQM.........................................27 Tabla 4: Resumen de caractersticas de IT-Mark......................................33 Tabla 5: Certificaciones IT Mark realizadas..............................................41 Tabla 6: Comparativa de certificaciones de empresa...............................42 Tabla 7: Resumen de caractersticas de CMMI.........................................44 Tabla 8: Niveles de CMMI.........................................................................49 Tabla 9: Certificaciones CMMI desde abril del 2002 a diciembre de 2008. .................................................................................................................55 Tabla 10: Resumen de caractersticas de ISO/IEC 15504.........................55 Tabla 11: Resumen de caractersticas de ISO 20000...............................64 Tabla 12: Resumen de caractersticas de ITIL..........................................64 Tabla 13: Comparativa de certificaciones de proceso..............................82 Tabla 14: Resumen de caractersticas de ISO 9001.................................83 Tabla 15: Comparativa de las certificaciones de Software.....................104 Tabla 16: Resumen de caractersticas de ITCard...................................106 Tabla 17: Presencia geogrfica de IT Card ............................................109 Tabla 18: Comparativa de certificaciones de habilidades personales en materia de software libre.......................................................................118
<Insertar logo>
Pg. 6 de 119
Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta 1 INTRODUCCIN
<Insertar logo>
El presente documento trata de mostrar los modelos de calidad y certificaciones asociadas ms relevantes respecto a las distintas perspectivas a abordar dentro del estudio de viabilidad tcnico financiera para la certificacin de software de fuente abierta. Se pretende explicar de manera clara y concisa la situacin actual respecto a las certificaciones en los mbitos de Hardware, Empresa, Software y Personas (HESP) relativos al software en general y al software de fuente abierta en particular. El objetivo es comprobar hasta qu punto las certificaciones existentes resuelven las problemticas relacionadas con el software de fuente abierta. En un principio se plante este anlisis comentando las perspectivas de Hardware, Empresa, Software y Personas. Se ha comprobado que esta denominacin puede llevar a error al no estar bien identificado los aspectos relacionados a procesos, de ah que se presenten de manera individual. De este modo se analizan:
Hardware:
Esta
perspectiva
trata
de
la
situacin
de
las
certificaciones en torno a la compatibilidad de los dispositivos frente a los sistemas operativos de fuente abierta de modo que puedan trabajar de manera conjunta.
Empresa: Esta perspectiva trata de la situacin de los modelos de calidad y certificaciones asociadas que buscan la calidad total en la empresa. En estos modelos se debe tener en cuenta que la directiva de la organizacin est incluida dentro del modelo de calidad. Dentro del mbito del software de fuente abierta se engloba en esta parte la organizacin de las comunidades de software de fuente abierta. Se busca la calidad total.
Procesos: Un proceso refleja una manera de trabajar, la manera en

Pg. 7 de 119

que la gente utiliza las herramientas e infraestructura para Diagnostico de la situacion producir bienes y conocimiento. Partiendo de esta definicin, esta perspectiva tiene en cuenta los procesos de desarrollo o lo que en software de fuente abierta se conoce como procesos de un proyecto.
<Insertar logo>
Software: perspectiva
esta de
perspectiva producto
tambin
se
identifica
como
la
englobando
aquellas
certificaciones
relacionadas con el producto software resultante. Se tiene en cuenta en esta seccin tanto las investigaciones que se han realizado sobre la certificacin de software de fuente abierta como de las certificaciones existentes que no distinguen si el software es de fuente abierta o no.
Personas: Esta perspectiva engloba las certificaciones existentes que acreditan la capacitacin de personas en temas relacionados con el software de fuente abierta.
Tras la presentacin del estado del arte de las distintas certificaciones se han realizado una serie de conclusiones y recomendaciones con el nimo de que sirvan de gua para determinar la viabilidad de modelos de certificacin de calidad. Dichos modelos debern garantizar a la industria en general el uso, aplicacin y/o integracin del software libre en condiciones de confianza plena mediante el impulso de polticas de normalizacin y control de calidad. Del diagnstico realizado se constata necesario el estudio de viabilidad en cada uno de las diferentes lneas en conjunto as como la combinacin entre ellas ya que no hay actualmente una certificacin que cubra de forma plena y satisfactoria todas las opciones.
Pg. 8 de 119
Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta 2 HARDWARE
<Insertar logo>
La certificacin de compatibilidad de dispositivos hardware, para su funcionamiento con sistemas operativos y programas software de fuentes abiertas, es uno de los apartados en los que menos se ha profundizado hasta el momento, no slo en nuestro pas sino en la UE y a nivel mundial. Tan slo encontramos dos iniciativas en este apartado: Compatible Linux y Linux-tested. Debido a la gran escasez de casos de estudio que sirvan para conocer detalles sobre iniciativas previas en este mbito, resulta especialmente valiosa la informacin que hemos podido recoger de lvaro del Castillo (actualmente miembro del equipo de CENATIC) y Santiago Dueas (actualmente miembro de GSyC/Libresoft), que estuvieron directamente implicados en el proyecto Compatible Linux dentro de la empresa Lambdaux. Esta iniciativa constituye el intento ms serio del que tenemos constancia hasta la fecha en el mbito de certificacin de compatibilidad de dispositivos hardware con software de fuentes abiertas (en este caso concreto, compatibilidad con sistemas operativos basados en GNU/Linux).
2.1
Compatible Linux.
Lambdaux1 fue una compaa inicialmente creada por Juan Antonio Esteban y Javier Pea, en febrero de 2003, con el objeto de desarrollar soluciones de software libre y presentar, adicionalmente, servicios de soporte y de mantenimiento de dicho software. La empresa estaba localizada dentro del Centro de Innovacin Tecnolgica de la URJC, puesto que dicha universidad pretenda contar con un programa integral de implantacin de software libre dentro de su plan estratgico de 1 http://www.terra.es/tecnologia/articulo/html/tec8870.htm

tecnologas de la informacin. Diagnostico de la situacion Una de las primeras iniciativas de la compaa fue la creacin y publicacin de una nueva distribucin del sistema operativo GNU/Linux llamada Lux (ux), que tena por objeto alcanzar una cuota de penetracin en el mercado de PCs locales de un 20% durante su primer ao de vida. Sin embargo, este proyecto no lleg a alcanzar las expectativas planteadas inicialmente, debido fundamentalmente a la existencia de muchas iniciativas similares en ese momento. Sin embargo, dentro de este proyecto comenz a detectarse la necesidad de trabajar conjuntamente con algunos fabricantes de hardware para intentar mejorar el nivel de compatibilidad de los equipos en los que se pretenda instalar esta distribucin. Este fue el germen de la iniciativa Compatible Linux. Tal y como nos cuenta lvaro del Castillo, la idea original fue la de generar un proceso de validacin de compatibilidad de hardware con distribuciones GNU/Linux. En un primer momento, se pens en testear la compatibilidad con la propia distribucin de la empresa (Lux), aunque ms adelante se incorporaron las distribuciones ms relevantes en ese momento (como Debian en su versin estable, RedHat o Mandrake). Poco a poco, fue hacindose ms evidente la necesidad de ajustar un proceso de certificacin global completo que pudiera responder a los retos planteados por esta iniciativa. Desde un punto de vista puramente tcnico, la coyuntura que en ese momento vivan muchas distribuciones GNU/Linux haca especialmente atractiva esta iniciativa. En efecto, tal y como comenta Santiago Dueas, en aquellas fechas muchas de las principales distribuciones se hallaban en pleno proceso de migracin a una nueva versin estable del Kernel de Linux (de la serie 2.4 a la serie 2.6). Esto generaba multitud de problemas de incompatibilidad y desajustes, provocados por la modificacin de drivers antiguos en el ncleo y la introduccin de otros nuevos. Este
<Insertar logo>
Pg. 10 de 119

proceso de adaptacin generaba muchos inconvenientes a la hora de Diagnostico de la situacion poder verificar la compatibilidad de un equipo hardware para funcionar con una determinada distribucin, puesto que en el plazo de unas pocas semanas los cambios experimentados en el ncleo Linux podan ser muy sustanciales. Por otra parte, la iniciativa supona tambin un reto importante en la adaptacin a los procesos de produccin de los principales fabricantes de hardware que quisieran implicarse en el proceso de certificacin. Segn lvaro del Castillo, no bastaba con describir dichos procesos de fabricacin, sino que el procedimiento de certificacin deba integrarse plenamente con dichos procesos de produccin. En este sentido, muchos fabricantes contaban ya con un plan de pruebas exhaustivas que, para otros sistemas operativos As, propietarios se el como Windows, intentaban de los garantizar su compatibilidad con todos los componentes hardware de un determinado configuracin equipo. realizaban buen revisiones completas de todos (verificando funcionamiento
<Insertar logo>
componentes, en especial los ms problemticos como tarjetas grficas, tarjetas de sonido, perifricos, etc.). De la misma forma, tambin se llevaban a cabo pruebas de carga (funcionamiento a pleno rendimiento del equipo durante 72 horas, de manera ininterrumpida) y pruebas de carga rpida del sistema operativo y la configuracin completa, a partir de una copia maestra que se descargaba a muy alta velocidad al disco duro del equipo (sistemas OEM). Por todo ello, se considero como una posible va de penetracin en este sector la definicin de una batera de pruebas semejantes para el caso de las distribuciones basadas en GNU/Linux. Tal y como nos detallan nuestros dos entrevistados, una de las principales ventajas con las que se cuenta en este apartado es el potente y amplio repertorio de herramientas que nos permiten descubrir, con todo lujo de detalles, el hardware que tenemos montado en una mquina con sistema operativo
Pg. 11 de 119

GNU/Linux. Por otro lado, determinadas la situacion Diagnostico de bases de datos disponibles en Internet (como PCI-IDS2 o USB-IDS3) adems de otras listas mantenidas en ese momento por los responsables de otras grandes distribuciones GNU/Linux (RedHat, Mandrake), ofrecan detallada informacin acerca de la compatibilidad de dispositivos hardware en cada una de las diferentes distribuciones, segn los drivers incluidos (o que podan instalarse). Por otra parte, existan algunos problemas particulares a los que hacer frente en el caso de sistemas operativos de fuentes abiertas. Por ejemplo, debido a la enorme cuota de mercado de Windows, la mayora de fabricantes de dispositivos hardware no se planteaban lanzar al mercado un producto sin proporcionar los drivers adecuados para que funcionase en este entorno. Sin embargo, el mismo principio no se poda aplicar a los sistemas operativos basados en GNU/Linux, donde en ocasiones existan solo drivers genricos, cuya compatibilidad haba que comprobar ex profeso. En ciertas ocasiones, la compatibilidad era solo parcial provocando, por ejemplo, la prdida de la capacidad de aceleracin en grficos 3D en algunas tarjetas de vdeo cuyo soporte todava no estaba cubierto por el driver correspondiente en GNU/Linux. Otro aspecto que dificultaba este proceso de validacin eran los pequeos cambios que se producan en la configuracin de los equipos sin previo aviso, cuando, por ejemplo, un fabricante de placas base decide repentinamente sustituir la controladora de red o alguno de los chipset por otra versin diferente, o por un producto de otro fabricante, lo que puede de nuevo convertirse en el origen de incompatibilidades. Una vez que el sistema de pruebas comenz a afinarse, comenz el envo de equipos por parte de algunos integradores de hardware, para poder certificar la compatibilidad de sus configuraciones con la principales distribuciones GNU/Linux. Este proceso permita generar una
<Insertar logo>
2 http://pciids.sourceforge.net/ 3 http://www.linux-usb.org/usb.ids

realimentacin muy til para los de la situacion podan conocer Diagnostico fabricantes, que detalladamente los problemas de compatibilidad que experimentaba cada configuracin. Fue entonces cuando comenz a surgir la idea de crear una base de datos que reuniese toda la informacin de compatibilidad que se iba recopilando. Sin embargo, antes de liberar dicha informacin se plante la necesidad de consolidar todo el proceso de certificacin, compatibilidad y homologacin. El ciclo completo del proceso de certificacin para un equipo comprenda las siguientes fases:
<Insertar logo>
Recepcin
del
equipo
en
el
laboratorio
de
certificacin.
Comprobacin de la configuracin.
Consulta de la informacin incluida en el ncleo Linux y en bases de datos externas, sobre el soporte de los diferentes componentes del equipo.
Comprobacin real del soporte de los diferentes componentes en cada distribucin, asignacin de un nivel de compatibilidad dependiendo de los resultados obtenidos.
Se podan distinguir cuatro niveles diferentes de compatibilidad:

Azul: Compatibilidad total con la distribucin Lux. Verde: Compatibilidad total con el ncleo Linux. Amarillo: Informaciones contradictorias sobre compatibilidad del componente hardware en diferentes distribuciones GNU/Linux.
Rojo: No existe informacin de compatibilidad sobre el componente hardware, o bien se ha constatado que el componente no es compatible (mediante pruebas en el laboratorio).
Una vez que el proceso de certificacin de equipo se defini de forma precisa, lleg el momento de dirigirse a una entidad de certificacin y estandarizacin oficial para afinar este diseo, preparndolo para su
Pg. 13 de 119

posible adopcin a gran escala a nivelde la situacion Diagnostico industrial, as como ofreciendo una ratificacin confiable y neutral por parte de un organismo autorizado. Para ello se establecieron contactos tanto con AENOR (de cara al diseo preciso de proceso de homologacin y certificacin de hardware) como con Red.es (para la posible adopcin del estndar de homologacin en pliegos de concursos pblicos que incluyesen la adquisicin de equipamiento destinado a funcionar con sistemas operativos GNU/Linux). El proceso conjunto de definicin de todo el estndar de homologacin dio como resultado la publicacin de la normativa de certificacin AENORCompatibilidad Linux, una normativa pblica que est disponible de forma completamente pblica a travs de la pgina web de AENOR en Internet4. Este reglamento de certificacin define los pasos necesarios para homologar equipos y dispositivos hardware contra la distribucin estable de Debian en el momento de su publicacin (Debian v3.0, conocida por su nombre de distribucin Sarge). A partir de entonces, la empresa decidi publicar una base de datos incluyendo toda la informacin recopilada de los diferentes repositorios consultados sobre soporte de dispositivos en GNU/Linux, as como las propias pruebas de laboratorio efectuadas en la compaa. De acuerdo con los datos reflejados en una presentacin de Santiago Dueas, esta base de datos lleg a albergar informacin de compatibilidad de ms de 19.800 dispositivos. Lamentablemente, el sitio web que albergaba dicha base de datos ya no est disponible pblicamente. La informacin estaba estructurada en 11 categoras diferentes (equipos y tipos de dispositivos) y 61 subcategoras, cada una de las cuales slo poda estar asociada a una categora de alto nivel. Cabe destacar que un total de 11.547 dispositivos hardware fueron capaces de obtener el nivel de compatibilidad verde, que garantizaba su perfecto funcionamiento con el 4 http://www.aenor.es/desarrollo/certificacion/productos/tipo.asp? tipop=11
<Insertar logo>

ncleo Linux. La base Diagnostico de con informacin de dispositivos de datos contaba la situacion procedentes de ms de 1.166 empresas diferentes que comercializan hardware. Finalmente, exploramos las razones que, en opinin de los entrevistados, pudieron llegar a provocar que el proyecto no siguiera adelante, con un plan de adopcin a mayor escala en el mercado. En primer lugar, una de las razones ms importantes que pudieron coartar su adopcin a gran escala fue el elevado coste que el proceso de certificacin supona para los fabricantes y empresas que comercializan hardware, dado el reducido tamao del mercado de usuarios finales que usan GNU/Linux en nuestro pas (en comparacin con el de otros sistemas operativos propietarios). Esto provocaba la aparicin de muchas reticencias para adoptar el modelo de certificacin por parte de asociaciones empresariales del sector, que evaluaban esta certificacin como una opcin que les reportaba escasos beneficios, puesto que no exista una clara demanda proveniente de un porcentaje significativo de usuarios en el mercado. Los fabricantes tienden a entender los sistemas de certificacin como una normativa impuesta, que se debe aadir e integrar en su proceso de fabricacin, y para la que tienen que existir razones de peso (en trmino de beneficios econmicos) que justifiquen su adopcin y puesta en marcha a gran escala. Otra posible razn que ralentiz el proceso de adopcin fue la ausencia de demanda en este sentido por parte de la Administracin pliegos de Central o de de Administraciones oferta pblica Autonmicas, de contratos que de incluyesen esta certificacin como un punto ms a cumplir dentro de los condiciones aprovisionamiento y servicios. As pues, como resumen encontramos un caso de estudio que demuestra que el diseo y puesta en marcha de un sistema de certificacin de hardware para GNU/Linux, no slo es perfectamente posible sino que adems ya se ha realizado anteriormente con xito, desde un punto de
<Insertar logo>
Pg. 15 de 119

vista estrictamente funcional. Por otra parte, hemos aprendido tambin Diagnostico de la situacion acerca de los posibles puntos que pueden ralentizar o dificultar la adopcin de este tipo de certificaciones a gran escala por parte de los principales actores dentro del mercado.
<Insertar logo>
2.2
Linux-tested.
El proyecto Linux-tested ha sido puesto en marcha por la empresa AppLabs ante la ausencia de estndares de certificacin de equipos y hardware para GNU/Linux en el mercado actual. Se trata de un programa de certificacin que ha sido definido internamente por la empresa, y del que conocemos pocos detalles en cuanto a su diseo y nivel de aceptacin para otros actores del mercado. No obstante, se pueden reconocer algunas similitudes con el caso anterior que hemos presentado. Por ejemplo, el sistema de certificacin insta a los fabricantes a enviar sus equipos y componentes a un laboratorio de la compaa, en donde se tiene la capacidad de verificar el correcto funcionamiento del hardware en al menos 12 de las distribuciones GNU/Linux ms importantes del panorama actual. La empresa ha publicado tambin el listado de tarifas de certificacin para cada uno de los dispositivos que se deseen testear5. Otra de las similitudes con la iniciativa anterior es que el valor aadido que aporta esta certificacin es que el dispositivo figure dentro de una base de datos pblica (disponible en la web de la compaa), indicando explcitamente fabricante segmento su nivel con de un No compatibilidad mecanismo obstante, con las de distribuciones ratificacin de equipos de y GNU/Linux que hayan sido probadas en el laboratorio. De esta forma, el cuenta del neutral el compatibilidad, que aporta un valor adicional a su producto de cara a ese mercado. nmero
5 http://www.linux-tested.com/procedures#fees

componentes que ya han sido incluidos dentro de esta base de datos es Diagnostico de la situacion todava muy reducido. No estn claras las causas por las que este nmero de equipos registrados es todava muy bajo (si se debe a la excesiva juventud del proceso de certificacin, o bien de nuevo a reticencias por parte de los fabricantes).
<Insertar logo>
2.3
Comparativa
Compatible Linux Linux-tested. AppLabs AppLabs 123 TurboLinux, SuSe, RedHat, Mandriva, Otras (12)
Organismo Certificador Propulsores Dispositivos aceptados Distribuciones Linux
AENOR Lambdaux 11.547 Debian
Tabla 1: Comparativa de certificaciones hardware en software de fuente abierta
Pg. 17 de 119
Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta 3 EMPRESA
<Insertar logo>
Se han seleccionado los modelos/estndares ms reconocidos y/o aplicados a nivel internacional y con una fuerte implantacin a nivel estatal:

ISO/IEC 9001:2008 EFQM
Para cada uno de los modelos o estndares recogidos en esta seccin, se cubren los siguientes aspectos, si aplican: Caracterizacin. En este apartado se resumen en una tabla
caractersticas relevantes a tener en cuenta en cada modelo. Descripcin general del modelo y estructura del proceso.
Proporciona una visin general del modelo y conceptos relevantes para entender el propsito del mismo. Mtodo de evaluacin. a las Describe el mtodo utilizado etc. segn para los
evaluar/certificar
organizaciones,
personas,
modelos/estndares. Es fundamental entender los mtodos de evaluacin de modelos como EFQM o SPICE antes de hablar de las distintas certificaciones que existen ligadas al modelo. Certificacin. Se identifican las certificaciones principales asociadas al modelo. Presencia en el mercado de las TICs. En este apartado se recogen datos relevantes para valorar la presencia del modelo en el mercado y el xito de las certificaciones asociadas.
Pg. 18 de 119

3.1 ISO 9001:2000&2008 la situacion Diagnostico de
<Insertar logo>
3.1.1
Caracterizacin
Enfoque Empresa Si PDCA Plan Do Check Act Definido a muy alto nivel Auditores acreditados Organismos acreditados ENAC ISO/IEC 9000-3 es una gua para la implantacin de la ISO 9001 en empresas de desarrollo de software/sistemas
Estndar internacional Modelo/Marco de mejora Ciclo de mejora asociado Tipos/Mtodos de evaluacin Certificaciones Organismo Certificador Otras particularidades
Tabla 2: Resumen de caractersticas de ISO 9001
La norma ISO 9001 es una norma genrica y aplicable a cualquier organizacin, independientemente del sector al que pertenece.
3.1.2
Descripcin general
La Norma ISO 9001 ha sido elaborada por el Comit Tcnico ISO/TC176 de ISO Organizacin Internacional para la Estandarizacin y especifica los requisitos para un sistema de gestin de la calidad que pueden utilizarse para su aplicacin interna por las organizaciones, para certificacin o con fines contractuales. La norma ISO 9001 tiene origen en la norma BS 5750, publicada en 1979 por la entidad de normalizacin britnica, la [British Standards Institution] (BSI). La versin actual de ISO 9001 (la cuarta) data de noviembre de 2008, y por ello se expresa como ISO 9001:2008.
Pg. 19 de 119

Las norma ISO 9001:
<Insertar logo>
Presenta directrices para la mejora de procesos Describe los procesos que debe considerar un Sistema de Gestin de Calidad
Ayuda a una organizacin a establecer y mejorar su Sistema de Gestin de Calidad
Est basado en 8 principios de gestin de la calidad para facilitar la consecucin de los objetivos de calidad. Estos son:

Organizacin enfocada al cliente Liderazgo Participacin del personal Enfoque a proceso Enfoque del sistema hacia la gestin Mejora continua Enfoque objetivo hacia la toma de decisiones Relacin mutuamente beneficiosa con el suministrador
3.1.3
La norma
Estructura del modelo

9001:2008 est estructurada en ocho captulos,
ISO
refirindose los cuatro primeros a declaraciones de principios, estructura y descripcin de la empresa, requisitos generales, etc., es decir, son de carcter introductorio. Los captulos cinco a ocho estn orientados a procesos y en ellos se agrupan los requisitos para la implantacin del sistema de calidad.
Pg. 20 de 119

<Insertar logo>
Imagen 1: Estructura de la norma ISO 9001:2008
Los ocho captulos de ISO 9001 son: 1. Guas y descripciones generales, no se enuncia ningn requisito. a) Generalidades . b) Reduccin en el alcance. 2. Normativas de referencia. 3. Trminos y definiciones. 4. Sistema de gestin: contiene los requisitos generales y los requisitos para gestionar la documentacin. a) Requisitos generales. b) Requisitos de documentacin. 5. Responsabilidades de la Direccin: contiene los requisitos que debe cumplir la direccin de la organizacin, tales como definir la poltica, asegurar que las responsabilidades y autoridades estn definidas, aprobar objetivos, el compromiso de la direccin con la calidad, etc. a) Requisitos generales.
Pg. 21 de 119

b) Requisitos del cliente. Diagnostico de la situacion c) Poltica de calidad. d) Planificacin e) Responsabilidad, autoridad y comunicacin. f) Revisin por parte de la gerencia. 6. Gestin de los recursos: la Norma distingue 3 tipos de recursos sobre los cuales se debe actuar: RRHH, infraestructura, y ambiente de trabajo. Aqu se contienen los requisitos exigidos en su gestin. a) Requisitos generales. b) Recursos humanos. c) Infraestructura. d) Ambiente de trabajo. 7. Realizacin del producto: aqu estn contenidos los requisitos puramente productivos, desde la atencin al cliente, hasta la entrega del producto o el servicio. a) Planificacin de la realizacin del producto y/o servicio. b) Procesos relacionados con el cliente. c) Diseo y desarrollo. d) Compras. e) Operaciones de produccin y servicio f) Control de dispositivos de medicin, inspeccin y monitoreo 8. Medicin, anlisis y mejora: aqu se sitan los requisitos para los procesos que recopilan informacin, la analizan, y que actan en consecuencia. El objetivo es mejorar continuamente la capacidad de la organizacin para suministrar productos que cumplan los requisitos.
<Insertar logo>
El
objetivo
declarado
Pg. 22 de 119
en
la
Norma,
es
que
la

organizacin busque sin descanso la satisfaccin del cliente a Diagnostico de la situacion travs del cumplimiento de los requisitos. a) Requisitos generales. b) Seguimiento y medicin. c) Control de producto no conforme. d) Anlisis de los datos para mejorar el desempeo. e) Mejora. Para implantar un sistema de gestin de calidad segn la norma ISO 9001, una organizacin debe seguir el ciclo de mejora PDCA Plan, Do, Check, Act -.
<Insertar logo>
3.1.4
Mtodo de evaluacin
Las principales actividades para realizar una auditoria ISO 9001 en una organizacin son: 1. Revisin documental y cuestionario preliminar 2. Fase I: Visita previa 3. Fase II: Auditora del sistema 4. Elaboracin de Informes 5. 1mes para realizar el plan de acciones correctivas 6. Auditora extraordinaria 7. Concesin del certificado 8. Auditora de seguimiento anual (fuera del proyecto) 9. Auditora de renovacin cada 3 aos (fuera del proyecto) Para auditar la organizacin segn la norma ISO 9001:2008, nicamente se exige que el auditor ISO 9001 sea acreditado y trabaje en una
Pg. 23 de 119

organizacin que acredite la ISO de la situacion Diagnostico 9001. Este requisito se aplica nicamente en auditoras externas. Para auditoras internas no es necesario que la empresa del auditor est acreditada.
<Insertar logo>
3.1.5
Certificacin
Certificaciones asociadas a la norma ISO 9001:

Organismos acreditados para certificar empresas ISO 9001 Auditores acreditados Instructores de auditores acreditados Certificacin que puede conseguir una empresa: Certificacin ISO 9001
Los organismos que impartan la formacin de auditores deben de satisfacer la norma ISO 17024. El organismo acreditador es ENAC.
3.1.6
Presencia en el mercado de las TICs
El grfico adjunto indica la tendencia en el nmero de empresas certificadas ISO 9001 en el mundo y ofrece datos de inters sobre el grado de implantacin de la norma en el mundo, algunos pases europeos y Espaa. En los datos aportados, no se distingue cuales de ellas son del sector TIC y cuales no.
Pg. 24 de 119

<Insertar logo>
Imagen 2: Informe ISO de certificados ISO 9001 en 2006 Se estima que hay unas 1000 empresas TIC certificadas ISO 9001 en Espaa. Grficas obtenidas de http://www.iso.org/iso/survey2006.pdf
Pg. 25 de 119

3.2 EFQM
<Insertar logo>
3.2.1
Caracterizacin
Enfoque Empresa No EFQM REDER Resultados, Enfoque, Despliegue, Evaluacin y Revisin Reglas de evaluacin basadas en REDER Evaluadores acreditados por EFQM Evaluadores locales y nacionales EFQM o sus representantes nacionales
Tabla 3: Resumen de caractersticas de EFQM
3.2.2
Descripcin general
Fue anunciado por la EFQM en 1991, bajo el patrocinio de la Comisin Europea . En octubre de 1992 se entregaron por primera vez los premios (entre ellos, uno concedido a una empresa espaola). En aos sucesivos, se incorporaron pequeos retoques y se anunciaron versiones especiales para organizaciones de servicios pblicos y para PYMEs. El 21 de abril de 1999 se anunci la versin que aqu presentamos. El Modelo EFQM de Excelencia tiene como objetivo ayudar a las organizaciones (empresariales o de otros tipos) a conocerse mejor a s mismas y, en consecuencia, a mejorar su funcionamiento. Se trata de un modelo no normativo, cuyo concepto fundamental es la autoevaluacin basada en un anlisis detallado del funcionamiento del sistema de gestin de la organizacin usando como gua los criterios del modelo.
Pg. 26 de 119

Esto no supone una Diagnostico de la situacion contraposicin a otros enfoques (aplicacin de determinadas tcnicas de gestin, normativa ISO, normas industriales especficas, etc.), sino ms bien la integracin de los mismos en un esquema ms amplio y completo de gestin. La utilizacin sistemtica y peridica del Modelo por parte del equipo directivo permite a ste el establecimiento de planes de mejora basados en hechos objetivos y la consecucin de una visin comn sobre las metas a alcanzar y las herramientas a utilizar. Es decir, su aplicacin se basa en:
<Insertar logo>
La comprensin profunda del modelo por parte de todos los niveles de direccin de la empresa.
La evaluacin de la situacin de la misma en cada una de las reas.
Pg. 27 de 119

3.2.3 Estructura del modelo situacion Diagnostico de la
<Insertar logo>
Imagen 3: Mapa de criterios del modelo 1 El Modelo Europeo de Excelencia Empresarial, patrocinado por la EFQM y la Comisin de la UE, base del Premio Europeo a la Calidad, consta de dos partes:
Un conjunto de criterios (ver mapa de criterios del modelo) de excelencia empresarial que abarcan todas las reas del funcionamiento de la organizacin.
Un conjunto de reglas para evaluar el comportamiento de la organizacin en cada criterio.
Hay dos grupos de criterios :
Los Resultados (Criterios 6 al 9) representan lo que la organizacin consigue para cada uno de sus actores (Clientes, Empleados, Sociedad e Inversores). Definen que se obtiene.
Los Agentes (Criterios 1 al 5) son aspectos del sistema de gestin de la organizacin. Son las causas de los resultados. Definen que se hace.
Para cada grupo de criterios hay un conjunto de reglas de evaluacin basadas en la llamada "lgica REDER" :
Los resultados han de mostrar tendencias positivas, compararse favorablemente con los objetivos propios y con los resultados de
Pg. 28 de 119

otras organizaciones, estar causados por los enfoques de los Diagnostico de la situacion agentes y abarcar todas las reas relevantes.
<Insertar logo>
Los agentes han de tener un enfoque bien fundamentado e integrado con otros aspectos del sistema de gestin, su efectividad ha de revisarse peridicamente con objeto de aprender y mejorar, y han de estar sistemticamente desplegados e implantados en las operaciones de la organizacin.
3.2.4
Mtodo de evaluacin
No existe un mtodo de evaluacin sino un conjunto de reglas para evaluar el comportamiento de la organizacin en cada criterio. Cada criterios consta de sub-criterios y la evaluacin se hace a nivel de subcriterios siguiendo la lgica REDER:
Imagen 4: Esquema del mtodo de evaluacin de EFQM Resultados Lo que la organizacin consigue. En una organizacin excelente, los resultados muestran tendencias positivas o un buen nivel sostenido, los objetivos son adecuados y se alcanzan, los resultados se comparan favorablemente con los de otros y estn causados por los enfoques.
Pg. 29 de 119

Adems el alcance de los resultados cubre todas la reas relevantes para Diagnostico de la situacion los actores. Enfoque Lo que la organizacin piensa hacer y las razones para ello. En una organizacin excelente, el enfoque ser sano (con fundamento claro, con procesos bien definidos y desarrollados, enfocado claramente a los actores) y estar integrado (apoyar la poltica y la estrategia y estar adecuadamente enlazado con otros enfoques). Despliegue Lo que realiza la organizacin para poner en prctica el enfoque. En una organizacin excelente, el enfoque estar implantado en la reas relevantes de una forma sistemtica. Evaluacin y Revisin Lo que hace la organizacin para evaluar y revisar el enfoque y su despliegue. En una organizacin excelente, el enfoque y su despliegue estarn sujetos con regularidad a mediciones, se emprendern actividades de aprendizaje y los resultados de ambas servirn para identificar, priorizar, planificar y poner en prctica mejoras . Como resultado de la evaluacin se asocia una puntuacin del 1 al 1000 a la organizacin. Las organizaciones con una puntuacin de ms de 400 son organizaciones con una Buena gestin empresarial mientras que las que tienen una puntuacin superior a 650 se consideran organizaciones excelentes.
<Insertar logo>
3.2.5
Certificacin
EFQM es una organizacin sin nimo de lucro cuya sede est en Bruselas. La organizacin consta de una red de centros asociados que se encargan de diseminar y dar apoyo a la implantacin del modelo. Cada pas tiene
Pg. 30 de 119

una organizacin representante de de la situacion Diagnostico EFQM a nivel nacional y varias representaciones regionales que normalmente dependen de la organizacin que representa a EFQM a nivel nacional. No existe una certificacin EFQM para las organizaciones sino premios de excelencia segn EFQM organizados por las organizaciones regionales, nacionales y el premio europeo de EFQM. Por ejemplo, las organizaciones regionales y nacionales tienen premios de calidad para las organizaciones que obtienen una puntuacin EFQM de 400 o ms puntos. Las mejores organizaciones se postulan posteriormente a nivel Europeo para el premio de excelencia europeo de EFQM. Para evaluar (puntuar) a las organizaciones, existen evaluadores
<Insertar logo>
acreditados. Los evaluadores y las condiciones para evaluar lo determina cada organizacin, siempre y cuando se cumplan unos requisitos mnimos fijados por EFQM. Existen pues evaluadores de EFQM y evaluadores, por ejemplo de
EUSKALIT, organizacin en el Pas Vasco de EFQM.
3.2.6
Del 2000 al 2008, EFQM ha nombrado finalistas y premiados a unas 140 organizaciones (evaluadas por evaluadores europeos acreditados por EFQM y que han obtenido una puntuacin superior a 650 puntos). Los pases con mayor nmero de organizaciones finalistas y premiadas son:

Espaa: con 27 organizaciones, 10 del Pas Vasco Alemania con 22 organizaciones Gran Bretaa con 24 organizaciones
Se desconoce cuantas de ellas son del sector TIC. En Espaa, una de las organizaciones ms activas es EUSKALIT, la organizacin que organiza los premios de excelencia en el Pas Vasco.

Esta organizacin ha premiado desde situacion al Diagnostico de la el 2000 2007 a 139 organizaciones:
<Insertar logo>
23 organizaciones obtuvieron la Q de Oro (puntuacin de 500 o superior)
116 organizaciones obtuvieron la Q de plata (puntuacin de 400 puntos o superior).
nicamente dos de las empresas premiadas son del sector Servicios.
3.3
IT-Mark
3.3.1
Caracterizacin
Tres enfoques distintos Empresa, Procesos Enfoque de Sw/Sistemas, Procesos de seguridad de la informacin No 10*square CMMI-DEV V1.2 ISO/IEC27001&27002 IDEAL &PDCA Plan Do Check Act Mtodo IT Mark (definido por ESI) Evaluadores autorizados Organizaciones acreditadas ESI Es una certificacin basada en modelos ampliamente reconocidos en el mercado;
Estndar internacional Modelo/Marco de mejora Ciclo de mejora asociado Tipos/Mtodos de evaluacin Certificaciones Organismo Certificador
Otras particularidades
Cada modelo tiene un enfoque distinto (empresa, procesos de sw/sistemas, procesos de seguridad )
Tabla 4: Resumen de caractersticas de IT-Mark
Pg. 32 de 119

3.3.2 Descripcin general la situacion Diagnostico de
<Insertar logo>
IT Mark ha sido concebido como mtodo para determinar y mejorar la competitividad de las PYMES del sector de las tecnologas de la informacin. El objetivo es centrar la mejora en los procesos crticos de la organizacin, al objeto de que sta desarrolle productos de calidad de manera consistente y predecible. IT Mark es un mtodo diseado especficamente para las pequeas y medianas empresas. Trabaja desde tres perspectivas de la empresa:
La Gestin General de la empresa, de acuerdo con el modelo 10-squared, que estudia diez categoras de procesos como son estrategia, comercial, financiera, definicin de productos y servicios, conocimiento del mercado, marketing, etc, hasta obtener una visin exhaustiva de la empresa. Cada una de estas categoras tiene en cuenta diez elementos, entre los cuales existen algunos elementos crticos, en funcin del estado de desarrollo de la empresa: Semilla, Start-up, Desarrollo o Expansin.
La Seguridad de la Informacin, basada en la norma ISO/IEC27001, 27.002:2005, en la que IT Mark define varios niveles:
Nivel
1:
Centrado
en
la
organizacin
de
la
seguridad,
responsabilidades, requisitos legales (Proteccin de Datos Personales, etc), y controles de seguridad
Nivel 2: Exige que la gestin de la seguridad se haya convertido en un proceso estandarizado en la organizacin
Nivel 3: Mejora Continua del Sistema de Gestin de la Seguridad de la Informacin
Los Procesos de desarrollo de Software y Sistemas y ncleo del modelo, basado en los procesos clave de CMMI-DEV V1.2.
Pg. 33 de 119

<Insertar logo>
Procesos
CMMI Nivel 2: de la situacion Diagnostico Planificacin del
proyecto
(PP);
Seguimiento y control del proyecto (PMC); Medicin y anlisis (MA); Aseguramiento de la calidad del proceso y producto (PPQA); Gestin de requisitos (REQM); Gestin de proveedores (SAM); Gestin de configuracin (CM).
Procesos de CMMI Nivel 3: Desarrollo de requisitos (RD); Solucin tcnica (TS); Integracin de producto (PI); Verificacin (VER); Validacin (VAL); Definicin de proceso organizacional (OPD); Formacin organizacional (OT); Gestin de proyecto integrado (IPPD); Enfoque proceso organizacional (OPF); Gestin de riesgos (RSKM); Anlisis de decisin y resolucin (DAR).
El esquema IT Mark distingue tres niveles posibles, y progresivamente ms exigentes, en funcin de la Madurez demostrada en los procesos de cada PYME. La madurez de un proceso software es el grado en el cual un proceso especfico es efectivo, definido, gestionado, medido y controlado. La madurez supone un potencial en crecimiento en cuanto a capacidad e indica la riqueza de los procesos de una organizacin y la consistencia con la cul stos son aplicados en los proyectos. As:
IT Mark acredita a una empresa que es consciente de los problemas relacionados con la gestin tcnica, de seguridad y del negocio, y que los mantiene habitualmente bajo control.
IT Mark Premium acredita a una empresa que ha conseguido una Buena Madurez en sus procesos de trabajo tcnico, seguridad y del negocio.
IT Mark Elite acredita a una empresa que ha conseguido un nivel Superior en la definicin e institucionalizacin de sus procesos de trabajo tcnico, de seguridad y de negocio, por lo que se confa en que la calidad de sus productos sea buena, debido a la madurez de
Pg. 34 de 119

sus procesos y a Diagnostico de la situacion la mejora continua.
<Insertar logo>
Imagen 5: Relacin de niveles IT Mark y CMMI La forma en que est organizado IT Mark en los tres niveles define la prioridad de las acciones para la mejora y para aumentar la madurez de los procesos software. La exigencia en los modelos de referencia utilizados y la profundidad de los diagnsticos sern mayores a medida que la organizacin avanza en los distintos niveles de madurez de la siguiente forma: La exigencia para alcanzar un IT Mark Premium es mayor que para alcanzar IT Mark.
Pg. 35 de 119

<Insertar logo>
Imagen 6: Modelo de mejora de IT Mark Los requisitos para los distintos niveles de IT Mark se detallan a continuacin:
Pg. 36 de 119

Diagnostico c de laa situacion l n a d c e i l o s u E v a l nu a d e i E v
E N iv e l v a l nu a d c e i l ol o s p r o c e s o s d de n e g o c i o i n o e n p r o c e s o s e s e g u r id a d C l a s e d e d e l a f o r mn a c ei v a l un a c i s l a
<Insertar logo>
p r o nc e y s do e d s e a rg r eo s l to i l s o f t w a r e H a l la z g o s n
d e
h a y a c a t e g o r N i v e l 3 r o j o y > 7 5 %
N i n n g r e a d e p r o c e s o e C l a s e B , N i v e l N r e a s d e p r o c e s o e n d e m a d u r e z 3
r o v e r d
jo e
& >
o e n
h a y a c a t e g o r N i v e l 2 r o j o y > 6 0 %
C l a s e B , NN i i v n ne g lr e a d e p r o c e s o e n r o jo & d e m a d u r Ne z r e 2 a s d e p r o c e s o e n v e r d e > = C la s e B s : d N A P n o p u e * , N iv e l C la s e C s : d N u r e z 2 m e n o s d e s e r n i P P , e o d e o 5 n 2 e 2 0
N o sm d e u n a c a t e a g e nr r o j No o > 5 0 %
i yv e
l 1
la s e C d e m a d
m A P e n r o j o . E s ta s n s e r n i P P , n i P M m A P a l c a n z a n d o % . E s t a s A P n o p u i P M C .
Imagen 7: Requisitos a cumplir en los distintos niveles de IT Mark
3.3.3
Los modelos de referencia de la certificacin IT Mark son tres:

10 SQUARED. Modelo para la mejora de los procesos de negocio. CMMI-DEV V1.2. Modelo para la mejora de los procesos de desarrollo software y de sistemas. Ver descripcin en este mismo documento.
ISO/IEC 27001 & 27002: La norma ISO 27001 es un instrumento base para la gestin en de un a la seguridad de de la informacin, y de promover, estructurndose recomendaciones conjunto los controles de
dirigido
responsables
implantar y mantener la seguridad en las entidades. Mediante ella las empresas pueden certificar sus Sistemas de gestin de Seguridad de la Informacin (SGSI). Un SGSI es un sistema de gestin que comprende la poltica, la estructura organizativa, los procedimientos, los procesos y los recursos necesarios para implantar la gestin de la seguridad de la informacin en funcin de los requisitos tcnicos, legales y organizativos identificados en la empresa.
Pg. 37 de 119

3.3.4 Mtodo de evaluacin situacion Diagnostico de la
<Insertar logo>
ESI ha definido un proceso de evaluacin detallado para las evaluaciones IT Mark. Ha desarrollado tambin una herramienta IT Mark asociada al proceso de evaluacin. Dicha herramienta consta de tres partes, cada cual a su vez sigue su propio mtodo de evaluacin:
Evaluacin del proceso de negocio basado en 10 SQUARED: se evalan 10 categoras de negocio y por cada categora se evalan 10 elementos. Cada elementos tiene una pregunta asociada. El cuestionario (ver figura abajo) lo rellena el gerente o director general de la organizacin con el apoyo de un consultor IT Mark.
Imagen 8: Evaluacin basada en 10 SQUARED
Evaluacin del proceso Sw/Sistemas. En el IT Mark bsico y Premium se evalan procesos CMMI Nivel de madurez 2 con el mtodo de evaluacin CMMI tipo C y B respectivamente. Para IT Mark lite se evalan procesos de Nivel de madurez 3 con una evaluacin de tipo B. El mtodo de evaluacin de tipo B es ms riguroso que el C.
Evaluacin de procesos de seguridad de la informacin: Se utiliza un cuestionario (ver figura de abajo) que lo rellena el responsable
Pg. 38 de 119

de Infraestructuras de la organizacin situacionde un consultor IT Diagnostico de la con apoyo Mark.
<Insertar logo>
Imagen 9: Evaluacin de procesos de seguridad de la informacin
3.3.5
Certificacin
Las organizaciones de TI pueden optar por tres certificaciones distintas:

IT Mark Bsico IT Mark Premium IT Mark Elite
Otras certificaciones asociadas a IT Mark son:

Certificacin de evaluadores IT Mark Certificacin de consultores IT Mark (los consultores dan apoyo a las organizaciones en la implantacin de IT Mark).
Organismos acreditados en IT Mark. Son los ESI@Centers(empresas participadas por el ESI que se encuentran en varios pases del mundo).
Pg. 39 de 119

3.3.6 Presencia en el mercado de las TICs Diagnostico de la situacion
<Insertar logo>
La siguiente tabla recoge las evaluaciones IT Mark realizadas en el mundo desde el lanzamiento de la certificacin (finales del 2005):
Pas Armenia Australia Bulgaria Colombia Francia Moldavia Per Repblica de Macedonia Espaa TOTAL N de evaluaciones 4 10 12 19 5 6 3 7 17 83
Tabla 5: Certificaciones IT Mark realizadas
Hay 20 evaluadores autorizados IT Mark. El ESI tiene experiencia en aplicar IT Mark en organizaciones de software de fuentes abiertas. En particular en micro-PYMES. En ellos, se ha demostrado de mucha utilidad, la parte de IT Mark relacionada con la evaluacin de aspectos de negocio, ya que esta es frecuentemente el aspecto ms dbil en muy pequeas organizaciones con personal con un perfil fuertemente tecnolgico y con considerables carencias a nivel de gestin de negocio.
Pg. 40 de 119

3.4 Comparativa Diagnostico de la situacion
ISO 9001:2000&2008 EFQM IT Mark Tres enfoques distintos EMPRESA, Procesos de Enfoque Empresa Empresa Sw/Sistemas, Procesos de seguridad de la informacin Estndar internacional Modelo/Marco de mejora Ciclo de mejora asociado Si No No 10*square L a propia norma EFQM REDER Resultados, Enfoque, Despliegue, Evaluacin y Revisin Reglas de evaluacin basadas en REDER Evaluadores acreditados por EFQM Evaluadores locales y nacionales EFQM o sus ENAC representantes nacionales Es una certificacin basada en modelos ISO/IEC 9003 es una Otras particularidad es gua para la implantacin de la ISO 9001 en empresas de desarrollo de software / sistemas ampliamente reconocidos en el mercado; Cada modelo tiene un enfoque distinto (empresa, procesos de sw/sistemas, procesos de seguridad ) ESI CMMI-DEV V1.2 ISO/IEC27001&27002 PDCA Plan Do Check Act IDEAL &PDCA Plan Do Check Act Mtodo IT Mark (definido por ESI) Evaluadores autorizados Organizaciones acreditadas <Insertar logo>
Tipos/Mtodos Definido a muy alto de evaluacin nivel Certificacione s Auditores acreditados Organismos acreditados
Organismo Certificador
Tabla 6: Comparativa de certificaciones de empresa
Pg. 41 de 119
Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta 4 PROCESO
<Insertar logo>
Se han seleccionado los modelos/estndares ms reconocidos y/o aplicados a nivel internacional:

CMMI, en particular CMMI-DEV SPICE, en particular el modelo de evaluacin de procesos de desarrollo software (ISO/IEC 15504-5).
ITIL/ISO
20000
CMMI-SVC
como
modelos/estndares
para
servicios de TI. Para cada uno de los modelos o estndares recogidos en esta seccin, se cubren los mismos apartados, si aplican, que en la seccin anterior: Caracterizacin, Descripcin general del modelo y estructura del proceso, Descripcin general del modelo y estructura del proceso, Mtodo de evaluacin, Certificacin, Presencia en el mercado de las TICs. Existe adems un apartado En desarrollo, en donde se explica la iniciativa QualiPSo en general y el modelo de procesos OMM Organizational Maturity Model en particular. Por tratarse de una iniciativa en curso y un modelo en fase de desarrollo, la descripcin del modelo no sigue los apartados de los modelos descrita previamente.
Pg. 42 de 119

4.1 CMMI
<Insertar logo>
4.1.1
Caracterizacin
Enfoque Procesos de desarrollo sw/sistemas No CMMI-DEV , CMMI-ACQ, CMMI-SVC IDEAL SCAMPI A, B y C Instructores autorizados para cada modelo Evaluadores autorizados Empresas que han alcanzado niveles de madurez 2, 3, 4 o 5 en CMMI Software Engineering Institute (SEI) Mtodo de evaluacin SCAMPI compatible con ISO/IEC 15504-2
Estndar internacional Modelo/Marco de mejora Ciclo de mejora asociado Tipos/Mtodos de evaluacin
Certificaciones
Organismo Certificador Otras particularidades
Tabla 7: Resumen de caractersticas de CMMI
Los aspectos relevantes de la caracterizacin del modelo se abordan en las secciones posteriores.
4.1.2
Descripcin general
El CMMI es un marco de mejora de procesos que consta de varias constelaciones.
Pg. 43 de 119

<Insertar logo>
Imagen 10: Constelaciones CMMI Cada una de las constelaciones representa un modelo de mejora de procesos distinto y cada modelo consta de un conjunto de procesos especficos y un conjunto de 16 reas de proceso comunes. Los modelos son: CMMI_DEV: Orientada a organizaciones que desarrollan productos intensivos en software. CMMI_ACQ: Orientada a organizaciones que subcontratan sus productos y servicios, proporciona al contratista buenas prcticas para gestionar sus procesos. CMMI_SVC: Orientada a organizaciones que ofrecen servicios de TI para clientes internos y externos. Cada uno de los modelos de la constelacin CMMI, tiene dos
representaciones posibles:
Representacin Continua
Pg. 44 de 119

<Insertar logo>
Representacin escalonada. Diagnostico de la situacion por
En esta seccin, se aborda nicamente el modelo de CMMI-DEV
entender que es el ms relevante para las comunidades y empresas que desarrollan software de fuentes abiertas, tanto software para dispositivos empotrados como aplicaciones de software. Sin embargo, en una seccin posterior se describir brevemente el modelo CMMI-SVC (seccin 4.1.3). El CMMI-DEV ha sido concebido como modelo para determinar y
mejorar la capacidad de los procesos de las organizaciones, al objeto de que stas desarrollen productos de calidad de manera consistente y predecible. La capacidad de un proceso es la facultad inherente de ste para generar resultados de forma predecible. Segn CMMI-DEV la calidad de un producto software est determinada por la calidad del proceso que se utiliza para desarrollarlo y mantenerlo. Un proceso efectivo agrupa a personas, herramientas y mtodos dentro de un contexto de actuacin integrado. La capacidad de un proceso software describe el rango de resultados esperados que se pueden obtener mediante la implementacin del proceso software. La capacidad de un proceso software en una organizacin proporciona un medio para predecir los resultados ms probables que se pueden esperar en proyectos que tengan similares caractersticas. La productividad de un proceso software representa los resultados reales obtenidos mediante la implementacin del proceso. Mientras que la capacidad de un proceso se centra en los resultados esperados, la productividad de un proceso software se centra en los resultados alcanzados. La madurez de un proceso software es el grado en el cual un proceso especfico es efectivo, definido, gestionado, medido y controlado. La madurez supone un potencial en crecimiento en cuanto a capacidad e
Pg. 45 de 119

indica la riqueza de los procesos de de la situacion y la consistencia Diagnostico una organizacin con la cul stos son aplicados en los proyectos. Por institucionalizacin se entiende construir una infraestructura y cultura dentro de la organizacin que d apoyo a los mtodos, prcticas y procedimientos, de forma que stos sean la base esencial en la forma de trabajo. Como resultado de la institucionalizacin se obtiene el despliegue de unos procesos software efectivos, utilizados y consistentemente aplicados en la organizacin. La mejora continua est basada en un conjunto de pasos progresivos, en contraposicin de una transformacin drstica. El CMMI proporciona un marco de referencia para organizar estos pasos gradualmente en cinco niveles de madurez. Los niveles aportan sucesivos estratos para un proceso de mejora continua. Estos cinco niveles de madurez definen un sistema escalonado que sirve para medir la madurez de los procesos software de una organizacin y para evaluar la capacidad de los mismos. El modelo tambin establece un contexto y determina las directrices para ayudar a una organizacin a priorizar los esfuerzos en un programa de mejora. Un nivel de madurez define un grado de evolucin bien definido a partir del cual se alcanza un proceso software maduro. Alcanzar un determinado nivel dentro del modelo de madurez resulta en un incremento de la capacidad de los procesos de la organizacin. Representacin escalonada La forma en que est organizado el modelo CMMI en los cinco niveles define la prioridad de las acciones para la mejora y para aumentar la madurez de los procesos software. Como se muestra en la imagen 11 las flechas indican el nivel de capacidad de proceso que est siendo institucionalizado por la organizacin en cada nivel del modelo de madurez. Salvo en los niveles 4 y 5 en los que se trata de mejorar el nivel
<Insertar logo>
Pg. 46 de 119

de capacidad nicamente de los procesos situacion Diagnostico de la considerados clave para la organizacin.
<Insertar logo>
Imagen 11: Representacin escalonada Estos cinco niveles son los que se describen a continuacin:
Pg. 47 de 119

1. Inicial El proceso software est caracterizadosituacion y en ocasiones Diagnostico de la como ad hoc, puede ser incomprensible. Algunos procesos estn definidos y el xito depende de los esfuerzos a nivel de individuo. 2. Gestionado Los procesos de gestin de proyectos estn definidos de una manera bsica para realizar el seguimiento de los costes, fechas y funcionalidad. El rigor en la definicin de los procesos es el justo para poder repetir xitos previos en proyectos de similares caractersticas. 3. Definido El proceso software para las actividades de gestin e ingeniera est documentado, estandarizado e integrado en el proceso estndar dentro de la organizacin. Todos los proyectos utilizan una versin estndar del proceso software aprobado por la organizacin y adaptado a las necesidades del proyecto para desarrollo y mantenimiento de software. 4. Gestin Cuantitativ a 5. Optimizado Se recogen de forma detallada medidas de los procesos software y la calidad de los productos. Los procesos y productos software son entendidos cuantitativamente y controlados. La mejora continua de procesos se basa en los resultados cuantitativos de la aplicacin de innovaciones y tecnologas en los procesos ya establecidos. <Insertar logo>
Tabla 8: Niveles de CMMI
Estos cinco niveles reflejan el hecho de que el CMMI es un modelo para la mejora de la capacidad de las organizaciones de software. Las prioridades en el modelo no estn dirigidas hacia proyectos individuales sino a procesos que aporten valor a la organizacin en su conjunto. Representacin continua En la representacin continua es la propia organizacin la que decide QU procesos quiere abordar/evaluar y a QUE NIVEL DE CAPACIDAD quiere abordar/evaluar cada proceso. Es decir, la que determina el perfil objetivo. Por ejemplo, una organizacin puede estar interesada en mejorar sus procesos de ingeniera a un nivel de capacidad 3 y sus procesos de gestin a nivel 2 (ver imagen 5).
Pg. 48 de 119

<Insertar logo>
Imagen 12: Ejemplo de perfil objetivo (representacin continua) CMMI-DEV consta de 22 procesos que en el modelo escalonado se Sin embargo, segn la
agrupan segn se indica en la Imagen 11.
naturaleza de los procesos, stos se agrupan en varias categoras: Procesos de Gestin de Procesos, Procesos de Gestin de Proyectos, Procesos de Ingeniera y Procesos de Soporte. El modelo CMMI-DEV es un modelo de referencia para la mejora de procesos, que como tal tiene dos aplicaciones posibles en una organizacin que desarrolla software o sistemas embebidos: 1. Determinar el nivel de madurez de la organizacin y/o la capacidad de los procesos de desarrollo de software. Ello permite medir la capacidad de los procesos de una organizacin de manera objetiva. Este punto se desarrollar cuando hablemos del mtodo de certificacin. 2. Utilizar el modelo como referencia para la mejora de los procesos de la organizacin. Para esta segunda aplicacin, CMMI propone seguir el ciclo de mejora IDEAL:Initiating; Definining; Diagnosing; Actining; Learning.
4.1.3
Cada rea de proceso de CMMI tiene la siguiente estructura:
Pg. 49 de 119

Area de Proceso
<Insertar logo>
Objetivos Genrico
Objetivos especficos
Prcticas Genricas
Prcticas Especficas
Imagen 13: Estructura CMMI Las metas especficas y prcticas especficas son, como su nombre indica, especficas para cada rea de proceso de CMMI y describen buenas prcticas para el proceso en cuestin. Por ejemplo, si el proceso es de planificacin del proyecto, las prcticas especficas son del tipo, estimar el alcance del proyecto, definir el ciclo de vida, etc. Las metas y prcticas genricas describen buenas prcticas para la institucionalizacin del proceso y son comunes a todas las reas de proceso CMMI. Ejemplo de prcticas genricas son, planificar las actividades del proceso, proveer recursos adecuados, etc.
4.1.4
Mtodo de evaluacin
El Software Engineering Institute, propietario del CMMI, distingue tres tipos de evaluaciones segn su grado de rigurosidad. De menor a mayor: evaluaciones de tipo C, B y A. La evaluaciones de tipo A son las evaluaciones formales registradas por el SEI y sirven para hacer benchmarking sobre la madurez de las organizaciones. El mtodo que se utiliza para evaluar es el mtodo SCAMPI (Standard CMMI Appraisal Method for Process Improvement) propiedad del SEI.
Pg. 50 de 119

El SEI define adems una serie de requisitos, Appraisal Requirements for Diagnostico de la situacion CMMI (ARC), para evaluaciones de tipo B y C, siendo las distintas organizaciones acreditadas por el SEI las que desarrollan los mtodos de evaluacin adecuados que satisfacen dichos requisitos. Adems el mtodo SCAMPI del SEI es compatible con el estndar internacional ISO/IEC 15504-2 que veremos en una seccin posterior. Un mtodo de evaluacin o proceso de evaluacin consta de un conjunto de actividades bien definidas, herramientas de soporte y gente adecuadamente formada para ejecutar el proceso que permiten obtener un conjunto de resultados a partir de unos datos de entrada. El ESI as como otras organizaciones acreditadas por el SEI tiene su propio mtodo de evaluacin CMMI de tipo C y B que cumple con los requisitos ARC. El proceso de evaluacin es el que garantiza la consistencia y repetitividad de los resultados. Es decir, una misma compaa sometida a dos evaluaciones SCAMPI independientes ejecutados evaluaciones. por sendos evaluadores oficiales del SEI obtiene el mismo resultado en ambas
<Insertar logo>
4.1.5
Certificacin
El SEI, propietario del modelo CMMI, certifica:
Instructores para los cursos oficiales de CMMI. Hay instructores especficos para los distintos modelos CMMI (CMMI-DEV , CMMI-ACQ y CMMI-SVC).
Evaluadores CMMI (SCAMPIs)
Por otro lado, el SEI exige que tanto los instructores como los evaluadores formales trabajen en una organizacin acreditada por el SEI. Tanto para ser instructor como evaluador oficial del SEI es necesario

satisfacer un conjunto Diagnostico en cuanto a formacin acadmica, de requisitos de la situacion experiencia profesional y competencias, adems de haber asistido a determinados cursos oficiales sobre el modelo. Por ejemplo, para ser instructor del curso de introduccin al CMMI-DEV V1.2, el candidato debe tener un certificado oficial de los cursos de introduccin y curso intermedio de CMMI, asistir a un curso especfico para formar instructores impartido por el SEI y ser observado y evaluado mientras imparte un curso de formacin. Slo si satisface todos los requisitos y supera todas las pruebas obtendr la certificacin de instructor oficial del SEI. El SEI controla todos los certificados oficiales que se emiten cuando se obtiene un determinado nivel de madurez de CMMI o se asiste a un curso oficial de CMMI impartido por instructores oficiales. El procedimiento consiste en enviar informes de cada empresa que obtiene la certificacin, con detalles que el SEI utiliza para obtener informes peridicos. Adems, lleva tambin el control de los instructores oficiales, scampis, etc. Sin embargo, los datos de las empresas no son pblicos, salvo que stas as lo soliciten. Por otro lado, para mantener los ttulos del SEI, los instructores y evaluadores deben satisfacer una serie de requisitos tales como, realizar al menos una evaluacin SCAMPI cada dos aos, haber presentado un artculo sobre CMMI en algn evento internacional, etc.
<Insertar logo>
4.1.6
El SEI publica semestralmente un informe sobre el nivel de madurez en las organizaciones, accesible desde su pgina web (http://www.sei.cmu.edu/appraisal-program/profile/profile.html). En este apartado resumimos algunos datos relevantes sobre la presencia de CMMI en el mercado, extrado del ltimo informe de Marzo del 2009. El

informe recoge datos sobre evaluacionesla situacion tipo A ejecutadas Diagnostico de formales de en el perodo desde Abril del 2002 a Diciembre del 2008.
<Insertar logo>
4.134 evaluaciones realizadas 564 organizaciones re-evaluadas 3.446 Organizaciones implicadas 2.544 Compaas involucradas 21.141 proyectos evaluados 71,4% de evaluaciones en organizaciones fuera de USA De las 1.500 evaluaciones ms recientes:
6,6% no obtuvieron certificacin (normalmente solo se enva el informe de resultados al SEI cuando la organizacin ha conseguido la certificacin)
28,5% obtuvieron el nivel de madurez 2 58,3% obtuvieron nivel 3 6,6% obtuvieron niveles 4 o 5.
Ms de la mitad de las evaluaciones (53,6%) se realizaron en organizaciones con menos de 100 empleados:

14,1% en organizaciones de 25 o menos empleados 18,3% en organizaciones de 26 a 50 empleados 13% en organizaciones de 51 a 75 empleados 8,2% en organizaciones de 76 a 100 empleados.
De las evaluaciones realizadas en organizaciones de 25 o menos empleados: 59,5% obtuvieron CMMI Nivel 2 y 28,8% CMMI Nivel 3.
De las 4.134 evaluaciones del informe: 1.901 se hicieron en
Pg. 53 de 119

Asia, 1.328 en Norte Amrica, 536 en Europa, 289 en Sudfrica, Diagnostico de la situacion 47 en frica y 33 en Oceana.
<Insertar logo>
El numero de evaluaciones va creciendo de manera lineal ao tras ao: desde 52 ejecutadas en el 2002 a 988 en el 2008.
Datos sobre Espaa y algunos pases con un nmero alto de evaluaciones ejecutadas:
Pas Espaa Francia Aleman ia UK China India
N Evaluaciones 102 133 54 79 726 395
Nivel 1 1 4 9 3 1
Nivel 2 60 81 32 42 117 14
Nivel 3 35 45 11 30 540 191
Nivel 4 2 1 1 1 27 24
Nivel 5 4 2 1 3 41 166
Tabla 9: Certificaciones CMMI desde abril del 2002 a diciembre de 2008.
Pg. 54 de 119

4.2 ISO/IEC 15504 (SPICE) la situacion Diagnostico de
<Insertar logo>
4.2.1
Enfoque
Caracterizacin
Proceso de desarrollo sw/sistemas Si ISO/IEC 15504-5 (SPICE for Sw development) ISO/IEC 15504-6 (SPICE for System Engineering) Gua para un proceso de mejora en ISO/IEC 15504-4 A, B, C y D (provisional) Mtodos/proceso de evaluacin debe satisfacer la norma ISO/IEC 15504-2 Instructores autorizados. Evaluadores provisionales y competentes por organismos acreedores. ENAC Los esquemas de certificacin de instructores y evaluadores deben satisfacer las competencias identificadas en ISO/IEC 15504-3 y tienen que estar acreditadas segn la ISO/IEC 17024
Estndar internacional Modelo/Marco de mejora Ciclo de mejora asociado Tipos/Mtodos de evaluacin Certificaciones Organismo Certificador
Otras particularidades
Tabla 10: Resumen de caractersticas de ISO/IEC 15504
Los aspectos relevantes de la caracterizacin del modelo se abordan en las secciones posteriores.
4.2.2
Descripcin general
ISO/IEC 15504 o SPICE es el estndar internacional que sirve como marco para la evaluacin de procesos. Consta de las siguientes componentes: 1. ISO/IEC 15504-1: Conceptos y vocabulario Parte 1 (informativa). Describe las distintas partes del modelo y proporciona la terminologa y definiciones bsicas relacionadas con la norma. 2. ISO/IEC 15504-2 Ejecutando una evaluacin - Parte 2 (normativa). Define los requisitos que debe satisfacer un proceso de evaluacin as
Pg. 55 de 119

como cualquier modelo de evaluacin que utilicemos como referencia. Diagnostico de la situacion A veces, los modelos de evaluacin toman como punto de partida uno o ms estndares a los que llama modelos de referencia. En la parte 2 de la norma, se describen adems los requisitos que deben de satisfacer los modelos de referencia. 3. ISO/IEC 15504-3: Gua para ejecutar una evaluacin Parte 3 (informativa). Es una gua explicativa de la parte 2 de la norma. Contiene adems los requisitos requeridos para ser un asesor competente (competent assessor). 4. ISO/IEC 15504-4: Parte 4 de la norma (Informativa).Gua para usar los modelos de evaluacin como referencia para la mejora de procesos o para determinar el nivel de capacidad de los procesos en una organizacin. 5. ISO/IEC 15504-5: Es un ejemplo de modelo de evaluacin para los procesos de desarrollo software Parte 5 (informativa). Esta parte es el modelo de mejora de procesos para los desarrollos software. Es la parte de la norma comparable al modelo de mejora de procesos CMMIDEV V1.2. Sin embargo, mientras CMMI-DEV V1.2 agrupa en un nico modelo los procesos de software e ingeniera de sistemas, SPICE consta de dos modelos de mejora de procesos independientes (dos componentes distintas de la norma) para la mejora de los procesos de desarrollo software (ISO/IEC 1554-5) y los procesos de ingeniera de sistemas (ISO/IEC 15504-6). 6. ISO/IEC 15504-6: Es un ejemplo de modelo de evaluacin para los procesos de Ingeniera de Sistemas. Esta parte 6 de la norma, an no se ha publicado como estndar (sino como informe tcnico) y es informativa. 7. ISO/IEC 15504-7: Evaluando la madurez organizacional Parte 7. No se ha publicado an como norma (sino como informe tcnico) por
<Insertar logo>
Pg. 56 de 119

tanto sus requisitos no son de de la situacion Diagnostico obligado cumplimiento y podran cambiar sensiblemente en la versin pblica de la norma. Actualmente la parte 7 contiene los requisitos para definir un modelo de madurez organizacional y cmo evaluar segn dicho modelo de madurez. Un modelo de madurez organizacional est definido sobre un modelo de evaluacin como la ISO/IEC 15504-5 y define entre otros, la prioridad con la que abordar la implementacin de los procesos del modelo de mejora (SPICE for Sw development; SPICE for System Engineering,...). ISO/IEC 15504 o SPICE proporciona un marco para la mejora de proceso. Son varios los modelos de evaluacin que forman parte del estndar o han sido derivados tomando como punto de partida el estndar (ej. ISO/IEC 15504-5, ISO/IEC 15504-6, Automotive SPICE, SPICE for SPACE). A partir de aqu, nos referiremos nicamente al modelo de evaluacin para la mejora de los procesos software ISO/IEC 15504-5, por ser el ms relevante para las empresas o comunidades que desarrollan software de fuentes abiertas. Adems la informacin proporcionada en esta seccin y las siguientes de SPICE, a partir de esta introduccin inicial, es comparable con la descripcin realizada sobre CMMI-DEV en la seccin anterior. El modelo ISO/IEC 15504-5, en adelante SPICE, tiene dos dimensiones: Dimensin de procesos: consta de un conjunto de 48 procesos agrupados segn la naturaleza de los procesos en distintos grupos. Los grupos a su vez se agrupan en ciclos de vida (ver imagen 14). Dimensin de capacidad: hay 6 niveles de capacidad del 0 al 6: 0 Incompleto; 1 Ejecutado; 2 Gestionado; 3 Establecido; 4 Predecible; 5 Optimizando. El concepto de nivel de capacidad de un proceso es idntico al concepto de capacidad de CMMI descrito arriba.
<Insertar logo>
Pg. 57 de 119

P
A
A A A A A
<Insertar logo>
R
c q u
C C C C C Q A Q S Q C Q S Q C
I M L A i fC e y Y P l re o R c
i P ir t oi o c Gne rs o s ( uA p C s
c. u. o . u. u . 1q 2p 3n 4p 5s u pi s r i et i po an r a t i o n sp el i e e r c t i o n l at r g a r c e t e m e n t m l io e n r i t o r i n g p t ao cm c e e r p t a n c e
c e s s e s O
Q ) M
M M M M M M A A A A A A
R C
G A N I Z L y P l re o c e c
a a m m k a P Q a s n n i az la i g t i no m n i m a a t ni o a n g z a r o ja e g c e t m n a u n a a l g t ye m i n a g e m e u r e m e n ae l a el e e n t
iA f e T I O s s e s
N
t
a n a g Pe rm o ec Gne rts o s ( uM p A
O N O N N N R N M N .r 1g .r 2g . 3 . 4 i. sm 5 .e 6 n t m e n n t n t t
S
S S S
u p P p r l o c G e rs o s ( uS p P y
P P P
L ) P G
E E E E E E
S . u 1 p tp e l in e d r e r i n g L P . r 2 o dr e u l ce t a s e L P . r 3 o da uc c te p s t ua pn pc o r t L e
r o c I em s p s r o v P e rm o e G n rst o s ( uP p I M c e
P P P I M P . r1 o I M P . r2 o I M P . r3 o c e e s s t as b l i s h m e n t c a e s ss s e s s m e n t c i me s p s r o v e m e n t
E
E E E E E E
n g i n
N N N N N N G R G S G S G G G e . y. y. . . .
eP e r ro i c G eg rs o s ( uE p N n
1 q u i r ee 2 s r t ee qm u 3 s at e r qm u 4 S e oq f r 5 S eo sf d 6 S oo n f c l mi c e t an tt is o n i i r e a mn a e l ny ts s i s i t de ec st u i g r e n ut w i r aea rmn e a e l ny ts s i s t i wg na r e t s w t r a u r ce t i o n
)
N N N N N N G G G S GS G G . . y. . . . 7 8 9s y1 1 1 S n ot e f t g w r a tr i S e o s f t t i wn ga r t i t n e t me g r a t i s 0 t t ee s m t i n g 1 i nS s o t fa t lw l a a 2 a S n s o d y f ts w m e a t ie o n e o n t ri oe n a r ei n t e m n a
R G
R n c eR R R
e s o a u n r I cn e f r a e s t Pr u r oc c u e r s e s d t r o ( uR p I N )
I I I I N N NK NI . . . n. 1 rH e us m mu a r anc o 2 T r a i n i n n3 o w m l e a d n g a e 4f r a e s t r u c ne a g e m e n g g e m e n t t u r e t
O
O O
p
P P
e r aP t r i oo cn G e rs o s ( uO p P
O E C E . p 1 e r a u t si o e n a l .u 2 s t so um p e p r o r t
e u P s r e o c G e rs o s ( uR p E
R R R E E E U A U R U D
)
e n t
S
S
S S S S S U U U U U P . V e P . V a P . JP o . A u P .
O L Ri fC e T y I PN l reG o c
P )
S S S S S U U U U U P D P C P P PC c e
c e
s s e
s. 1 sm e a t n a g e m e n t .e 2 up s r oe g m r a a m n a g e m .o 3 m e an i g n i n e e r i n g
u p p or or t c G e rs o s ( uS p U P
1 a Q s su ua rl ia t yn 2r i f i c a t i o n 3l i d a t i o n 4ri ne t v i e w 5d i t
r. 6o de uv ca t l u a t i o n .o 7 c u m e n t a t i o n .o 8 n f i g mu r a a n t i a o g n e m e n t r. 9o b r e e s m o l mu t a i o n n a g e m l e n t . 1 0 r n e g q e u m e a s nt a g e m h a e n t
Imagen 14: Dimensin de procesos La representacin continua y escalonada son conceptos y terminologa CMMI. Utilizando terminologa CMMI, SPICE solo tiene representacin continua. Al modelo SPICE se le pueden asociar distintos modelos de madurez, similares a la representacin escalonada de CMMI. Los requisitos para poder definir un modelo de madurez SPICE ad-hoc estn descritos en la componente 7 de la norma. SPICE tiene dos aplicaciones posibles: 1. Determinar el nivel de capacidad de los procesos en una organizacin. 2. Utilizar el modelo de evaluacin como referencia para la mejora de los procesos de la organizacin. Para esta aplicacin, la parte 4 de la norma es una gua que contiene un proceso de mejora.
Pg. 58 de 119

Una organizacin que Diagnostico de la situacion desea utilizar SPICE como modelo de referencia, debe seleccionar primeramente que procesos quiere abordar y con qu nivel de capacidad. Por ejemplo, una organizacin puede estar interesada en mejorar sus procesos de ingeniera a un nivel de capacidad 3 y el de gestin de proyecto a nivel 2.
<Insertar logo>
5,2 5,1 4,2 4,1 3,2 L 3,1 L 2,2 2,1 1,1
L L f f f f f f
ENG.2
L L f f f
ENG.3
L L f f f
ENG.4
L L f f f
ENG.5
L L f f f
ENG.6
L L f f f
ENG.7
L L f f f
ENG.8
L L f f f
ENG.9
L L f f f
ENG.10
L L F
MAN.3
ENG.1
F Fully Implemented
L Largely Iplemented
P Partially Implemented
N Not Implemented
Not Assessed
Imagen 15: Esquema de niveles que desea mejorar la organizacin
4.2.3
El modelo de evaluacin SPICE, provee un conjunto de indicadores para evaluar la capacidad de los procesos. La estructura de un proceso SPICE se recoge en la siguiente figura:
Pg. 59 de 119

<Insertar logo>
Imagen 16: Estructura del proceso SPICE Cada nivel de capacidad consta de 1 o 2 atributos: el nivel de capacidad 1 de un nico atributo de proceso y los niveles del 2 al 5 de 2 atributos. El nivel 0 consta de 0 atributos de proceso. Cada atributo de proceso consta de un conjunto de buenas prcticas (prcticas genricas). El nivel 1 consta de una nica prctica genrica. Dicha prctica consiste bsicamente en ejecutar todas las prcticas de base asociadas a un proceso y obtener los productos de trabajo (work products) relevantes del proceso. Los indicadores principales asociados a un proceso SPICE son: en la dimensin de procesos, las prcticas de base (Base Practices) y en la de capacidad las prcticas genricas que se agrupan en atributos de procesos. Las prcticas de base estn ligadas a la naturaleza del proceso y describen buenas prcticas para el proceso en cuestin. Ejemplos de prcticas de base para el proceso de gestin de proyectos son definir el alcance del proyecto, definir el ciclo de vida, etc. Las prcticas genricas tienen que ver con la institucionalizacin del proceso y son comunes a todos los procesos de SPICE. Un ejemplo de

prctica genrica es planificar las actividades del proceso. Diagnostico de la situacion
<Insertar logo>
4.2.4
Mtodo de evaluacin
En SPICE, no existe un mtodo de evaluacin propietario como el SCAMPI del SEI, sino una norma, la ISO/IEC 15504-2 que describe los requisitos que debe cumplir un proceso de evaluacin, requisitos sobre la informacin de entrada mnima al proceso y los resultados esperados. En SPICE, las organizaciones proveedoras del servicio de
evaluacin SPICE deben de tener su propio mtodo de evaluacin y dicho mtodo debe satisfacer los requisitos de la norma ISO/IEC 15504-2. El ESI por ejemplo, ha desarrollado su propio mtodo de evaluacin SPICE compatible con la norma, al igual que otros proveedores de este servicio. Tipos de evaluacin SPICE. ISO/IEC 15504-7 describe distintos tipos de evaluacin SPICE segn el tamao del equipo evaluador y el grado de independencia del evaluador con la organizacin evaluada. Sin embargo, la parte 7 de la norma todava no ha sido publicada (se ha publicado como informe tcnico), por lo que sus requisitos no son an de obligado cumplimiento y podran variar sensiblemente cuando se publique como estndar. Se resume a continuacin, los distintos tipos de evaluacin segn el informe de la parte 7 de SPICE an no aprobado: Segn el equipo evaluador, las evaluaciones se clasifican en:
Clase 1: equipo evaluador formado por dos o ms miembros, uno de ellos evaluador competente. El evaluador competente debe ser independiente de la organizacin evaluada.
Clase 2: equipo evaluador formado por dos o ms miembros, uno de ellos evaluador competente.
Clase 3: equipo evaluador formado por al menos un miembro que
Pg. 61 de 119

debe ser evaluador competente. Diagnostico de la situacion Segn el grado de independencia entre el personal evaluador y la organizacin evaluada, hay 4 tipos de evaluaciones: Tipo A, B, C y D. Por ejemplo, en las de tipo A y B, el organismo evaluador es independiente de la organizacin evaluada, el evaluador competente tambin, y el resto de los miembros del equipo puede ser o no ser independientes, segn la evaluacin sea de clase A o B. Las evaluaciones formales son de clase 1 y A. Todo tipo de evaluaciones SPICE deber satisfacer los requisitos de la norma ISO/IEC 15504-2.
<Insertar logo>
4.2.5
Certificacin
La ISO/IEC 15504-3 y 7 describen los requisitos para certificar:

Evaluadores SPICE: provisional y competente Instructores SPICE Organismos acreditados para impartir formacin oficial SPICE
Los organismos que certifican a evaluadores e instructores deben de tener definida un esquema de competencias que satisface los requisitos de la ISO/IEC 15504-3 y el organismo acreditado debe satisfacer la norma ISO/IEC 17024.
4.2.6
Un grupo de trabajo de la ISO se ha encargado del desarrollo del modelo. En el trabajo realizado, se distinguen principalmente dos versiones de SPICE:
La versin de SPICE publicada en 1999
Pg. 62 de 119

<Insertar logo>
La versin SPICE Diagnostico de la situaciondel 1-5 estaban actual, cuyas componentes disponibles desde el 2006.
ESI ha participado en el desarrollo del estndar desde sus comienzos, aunque ms activamente en la versin de 1999 donde tuvimos el rol de coordinadores internacionales de las evaluaciones SPICE a nivel mundial. En ese perodo, el ESI form en SPICE a ms de 400 profesionales de TI y coordin y/o particip en ms de 50 evaluaciones SPICE. Respecto a la nueva versin de SPICE, no existe ningn organismo propietario ni tampoco se conocen datos oficiales sobre su implantacin a travs de informes como publica el SEI, aunque s hay iniciativas incipientes para poder disponer de esta informacin en un futuro. A nivel estatal, hay unas 20 organizaciones certificadas SPICE en el marco del Programa Avanza. El ESI ha evaluado con el nuevo modelo SPICE y su mtodo de evaluacin compatible con la ISO/IEC 15504-2 a unas 10 organizaciones, dos de ellas grandes organizaciones y el resto PYMEs.
4.3
ISO 20000/ITIL/CMMI-SVC
Se engloban dentro de un mismo apartado estos tres modelos, ya que todos ellos tratan de las prcticas que sirven para mejorar los servicios que se prestan en el mbito de tecnologas de la informacin. Se considera que existen diferencias con los procesos de desarrollo para los que se ja incluido informacin en los apartados anteriores, pero merece la pena incluir informacin acreca de ellos, considerando la ejecucin de un servicio tambin como un proceso. Se analizan lostres modelos y/o estndares a la vez, tratando de definir los aspectos comunes a los tres as como las principales diferencias. Los tres modelos/estndares tienen como objetivo mejorar los servicios de
Pg. 63 de 119

tecnologas de la informacin. Diagnostico de la situacion
<Insertar logo>
4.3.1
Caracterizacin
Norma ISO 20000:

Enfoque Estndar internacional Modelo/Marco de mejora Ciclo de mejora asociado Tipos/Mtodos de evaluacin Certificacin de servicios TI en las empresas Certificaciones Certificados personales: Consultor certificado ISO 20000 Tutor certificado ISO 20000 Auditor certificado ISO 20000 Organismo Certificador Otras particularidades IAF (Foro de acreditacin internacional) Procesos de gestin de servicios TI Si ITIL, COBIT PDCA
ITIL:
Enfoque Estndar internacional Modelo/Marco de mejora Ciclo de mejora asociado Tipos/Mtodos de evaluacin Certificaciones Organismo Certificador Otras particularidades Procesos de gestin de servicios TI No ITIL PDCA No es aplicable Diplomado en ITIL Experto en Gestin de Servicios IT Mster en Gestin de Servicios IT EXIN e ISEB (solo se certifican personas)
Tabla 12: Resumen de caractersticas de ITIL
CMMI-SVC (la caracterizacin est proporcionada conjuntamente con CMMI-DEV ).
Pg. 64 de 119

4.3.2 Descripcin general la situacion Diagnostico de
<Insertar logo>
Qu es un servicio TI? Un servicio es un conjunto de actividades que buscan responder a las necesidades de un cliente, satisfaciendo sus expectativas en el resultado de stas. La prestacin de un servicio no resulta en posesin, en eso se diferencia de proveer un bien fsico. Un servicio de TI (Tecnologa de la Informacin) define un marco donde se desarrollan (servicios actividades prestados por para una un cliente con tipo el soporte de la o infraestructura tecnolgica necesaria. Engloba tanto servicios tcnicos mquina, correo electrnico almacenamiento) o servicios profesionales (servicios prestados por personas, tipo soporte o mantenimiento de sistemas). La tendencia de Gestin de Servicio TI se basa en la promocin y soporte de aplicacin de las mejores prcticas, marcos referenciales y estndares de aceptacin internacional, tales como ITIL, ISO/IEC 20000, CMMISVC y otras. ITIL (Information Technology Infrastructure Library): ITIL describe los procesos que se necesitan para gestionar la
Infraestructura de TI eficientemente y eficazmente, con objeto de garantizar los niveles de servicio acordados por la organizacin TI y sus clientes. Se debe entender como Infraestructura de TI al conjunto de elementos TI de una organizacin relativos al hardware, software, recursos de telecomunicacin (redes, comunicacin, etc.), procedimientos y resto de documentacin relacionada. ISO/IEC 20000: Basada en la norma BS 15000, establece una serie de requisitos mnimos que una organizacin debe cumplir para lograr unos procesos de gestin de servicios de TI eficaces.
Pg. 65 de 119

Estrechamente ligada al ITIL, la ISO 20000 situacion una declaracin Diagnostico de la proporciona de la conformidad para Gestin de los Servicios TI mientras que ITIL trata sobre la eficiencia y eficacia de la gestin aunque no en su conformidad. CMMI-SVC (CMMI for Services): Es una constelacin del modelo CMMI al igual que CMMI-DEV (CMMI for Development) y CMMI-ACQ (CMMI for Acquisitions). Se conforma de componentes comunes a las dems constelaciones y aade objetivos y practicas enfocadas a servicios, cubriendo las actividades requeridas para gestionar, establecer y entregar servicios. CMMI-SVC podra adaptarse rpidamente en la inversin de los actuales usuarios de CMMI para llevar los procesos maduros a sus servicios adems de proveer un lenguaje familiar entre las distintas reas y organizaciones involucradas. CMMI-SVC podra resumir principios esenciales de modelos de servicios TI actuales, como por ejemplo ITIL, del cual asocia sus mejores prcticas a componentes CMMI, de forma que los usuarios pueden consultar ITIL como informacin adicional para su implementacin.
<Insertar logo>
4.3.3
Mdulos de ITIL
Pg. 66 de 119

<Insertar logo>
Imagen 17: Mdulos de ITIL Estrategia del Servicio. Cmo disear, desarrollar e implantar la gestin de servicios como un activo estratgico. Diseo del Servicio. Guas para disear y desarrollar los servicios y la gestin del servicio. Establece principios y mtodos para convertir la estrategia en servicios y activos. Transicin del servicio. Desarrollo y mejora de las capacidades para llevar a produccin servicios nuevos y mejorados. Operacin del servicio. Gua para obtener eficiencia y efectividad en la estrategia y el soporte del servicio. Convierte la estrategia en una capacidad. Mejora continua. Mejorar el diseo, la transicin y la operacin del servicio dando valor al cliente. La organizacin se enfoca en la calidad y la continuidad del servicio. Norma ISO 20000 Proporciona un conjunto de requisitos agrupados en los procesos que se indican en el siguiente grfico:
Pg. 67 de 119

<Insertar logo>
Imagen 18: Requisitos de la norma ISO 20000 en los distintos procesos En empresas que desarrollan software, los procesos que abarca la ISO20000 estn especialmente orientados a actividades relacionadas con la provisin del servicio una vez que el producto se ofrece en el mercado y posteriormente se implanta y se provee de soporte y mantenimiento al cliente. En la Imagen 18 se resumen los principales procesos que una organizacin que desarrolla software debe implantar para proveer servicios de calidad segn la ISO 20000 as como la relacin entre
Pg. 68 de 119

servicios TI y los procesos de desarrollosla situacion sistemas, estos Diagnostico de software o de ltimos fuera del alcance de la ISO 20000. La estructura del modelo CMMI-SVC incorpora nuevas reas de procesos especificas para la gestin de los servicios TI, reutiliza algunas de las reas de proceso relacionadas con las categoras de gestin de los proyectos y soporte y deja sin ninguna modificacin el resto de las reas de proceso de CMMI-DEV . Esto minimiza el impacto en la implantacin, formacin y evaluacin de aquellas empresas que estn planeando implementar CMMI-DEV y CMMI-SVC. El modelo CMMI-SVC consta de 21 ampliaciones en 7 reas de Proceso de CMMI-DEV , 1 rea de proceso modificada y 8 reas de proceso nuevas y especficas de CMMI-SVC tales como Gestin de incidencias y peticiones (IRM), Gestin de capacidad y disponibilidad (CAM), Continuidad del servicio (SCON) y otros. El ciclo de mejora para implantar ITIL y/o ISO 20000 en una organizacin es el PDCA. Para el CMMI-SVC es IDEAL.
<Insertar logo>
4.3.4
Mtodo de evaluacin
Para auditar una organizacin segn la ISO 20000 se siguen los mismos pasos que para auditar la norma ISO 9001 (descritos arriba).
4.3.5
Certificacin
Qu cobertura tiene la ISO20000? La ISO20000 certifica los servicios gestionados por una empresa. El alcance puede incluir un servicio, un grupo de servicios, una seccin del catlogo de servicios o todos los servicios prestados. Puede abarcar toda una organizacin o parte de ella, varias sedes separadas geogrficamente, uno o varios departamentos, etc. Incluso

puede depender de las evidencias dede situacion Diagnostico o la las contribuciones de otras organizaciones de proveedores. El alcance de cada auditora se define claramente antes de la realizacin de la misma e ir asociado a la certificacin. Las certificaciones personales asociadas a ISO 20000 son:
<Insertar logo>
Consultor certificado ISO 20000 Tutor certificado ISO 20000 Auditor certificado ISO 20000
El organismo acreditador es la IAF (Foro de acreditacin internacional) Existe tambin el Foro de acreditacin europeo (EA). A nivel estatal, hay varios organismos de acreditacin: ENAC Entidad de acreditacin en Espaa; UKAS Entidad de acreditacin inglesa,.. Bajo el paraguas de las entidades acreditadoras estn las entidades certificadoras como BSI (acreditada por UKAS), AENOR (acreditada por ENCA), etc. Puedo una organizacin certificarse en ITIL? ITIL no tiene certificacin para empresas o servicios, nicamente es un compendio de buenas prcticas aplicable a la gestin del servicio. Sin embargo se puede obtener acreditacin por parte de las personas. En ITIL V2:

ITIL Foundations: certificacin en fundamentos bsicos de ITIL Practitioners: certificacin en las distintas disciplinas o mdulos de ITIL
Service
Manager:
certificacin
para
expertos
en
Service
Delivery y Service Support La versin 3 sigue un sistema de crditos para la obtencin de las distintas acreditaciones: Diplomado en ITIL, Experto en Gestin de
Pg. 70 de 119

Servicios IT y Mster en Gestin de Servicios situacion Diagnostico de la IT. Certificaciones asociadas a CMM-SVC. Hay definido un modelo escalonado con una filosofa igual a la de CMMI-DEV . De manera que una organizacin puede obtener del nivel 2 al 5 de CMMI-SVC. Las evaluaciones formales de CMMI-SVC las realizan evaluadores acreditados por el SEI. De la misma manera hay instructores de CMMI-SVC acreditados por el SEI.
<Insertar logo>
4.3.6
Tanto ISO

como ITIL y CMMI-SVC se aplican nica y
20000
exclusivamente al sector de las TICs. De acuerdo a los datos de los que dispone el ESI sobre el grado de implantacin de ISO 20000 en las TIC espaolas, del 2006 al 2009 se han certificado servicios en 13 empresas. El alcance de la certificacin en ellas vara desde un servicio (por ejemplo, correo electrnico corporativo en una Caja de Ahorros espaola) hasta todos los servicios (por ejemplo en Honosa). De ITIL, al no tener una certificacin asociada, no disponemos datos sobre en cuntas empresas lo tienen implantado. Respecto a CMMI-SVC no existen datos ya que el modelo se ha publicado este mismo ao (en el 2009). El ESI est liderando un proyecto asociativo en el marco del programa AVANZA cuyo objetivo es fomentar y facilitar la mejora de la competitividad de las PYME del sector TIC, en especial las empresas del sector de Software Libre, a travs de la adopcin de metodologas avanzadas de servicio TIC (Modelo ISO 20000 e ITIL). Mejorar la calidad de los servicios ofrecidos por las empresas de desarrollo de software libre y por tanto de su rentabilidad, capacidad y
Pg. 71 de 119

reconocimiento a travs de la certificacinla situacion20000-1. Diagnostico de UNE-ISO/IEC
<Insertar logo>
4.4
EN DESARROLLO
4.4.1
QualiPSo.
El proyecto QualiPSo es un proyecto de investigacin financiado dentro del 6 programa marco de financiacin de proyectos de investigacin de la UE (FP6-IST-034763). El proyecto nace como una gran alianza entre numerosos socios industriales (grandes corporaciones y pequeas y medianas empresas), acadmicos y representantes de entidades relacionadas con las administraciones pblicas, con el objeto de mejorar la forma en la que el software de fuentes abiertas es incorporado en proyectos de innovacin de sistemas de informacin. Algunos socios provienen de pases fuera de la UE, como Brasil o China, en un intento de globalizar el alcance de esta ambiciosa iniciativa. As pues, dos propsitos fundamentales dentro del proyecto son:
Mejorar el soporte tcnico, procedimental y legal para la adopcin de software de fuentes abiertas en proyectos de innovacin tecnolgica.
Ofrecer un marco de evaluacin del nivel de fiabilidad que ofrece el software de fuentes abiertas que se pretende integrar, de manera que se pueda asegurar que dichos componentes cumplen los requerimientos de calidad de los sistemas en los que van a ser incluidos.
Uno de los pilares bsicos para articular este proyecto, es la creacin de una red mundial de centros de competencia que, actuando como entidades neutrales desde el punto de vista de intereses en el mercado, permitan ofrecer diferentes servicios (certificacin de software, consultora y asesoramiento de empresas, formacin, etc.) que catalicen

de manera efectiva los Diagnostico de la cabo en el seno del proyecto. esfuerzos llevados a situacion Adems, estos centros, constituidos como entidades con autonoma propia, continuarn su labor una vez finalizado el proyecto, proporcionando de esta forma un soporte permanente para seguir llevando a cabo este importante papel dentro del mercado de innovacin en sistemas de informacin.
<Insertar logo>
Imagen 19: Esquema resumen del objetivo del proyecto QualiPSo Por otra parte, como ya hemos dicho otro de los propsitos principales del proyecto es el de proporcionar un soporte tcnico y procedimental para poder evaluar y certificar la calidad y fiabilidad del software de fuentes abiertas que se evala para incluirse dentro de proyectos de innovacin tecnolgica. Para ello, QualiPSo se encuentra en estos momentos creando una plataforma de desarrollo de proyectos de nueva generacin, siguiendo el clsico esquema de funcionamiento de las forjas de desarrollo de proyectos de software de fuentes abiertas. No obstante, esta nueva plataforma de nueva generacin (llamada por el momento
Pg. 73 de 119

QualiPSo Factory), incluye algunos aspectos muy novedosos: Diagnostico de la situacion
<Insertar logo>
Integracin de herramientas de desarrollo y control del proyecto de nueva generacin (sistemas de VoIP y videoconferencia) as como soluciones que faciliten la administracin de la plataforma y de las diferentes herramientas integradas en la misma.
Integracin de una serie de herramientas que permitan, siguiendo una metodologa de evaluacin y certificacin concreta, asesorar sobre el nivel de calidad y fiabilidad del software desarrollado o integrado dentro de un proyecto que se lleve a cabo en la Factora.
As pues, una de las tareas especficas que se estn llevando a cabo dentro de QualiPSo es la definicin de un completo programa de evaluacin y certificacin de software de fuentes abiertas. Para ello, se han distinguido dos dimensiones de trabajo, que avanzan en paralelo a pesar de estar muy ntimamente relacionadas:
Evaluacin de la calidad de productos de software de fuentes abiertas a partir del anlisis de diferentes parmetros descriptivos. Se incluye la creacin e integracin dentro de la Factora de todas aquellas herramientas que sean precisas para llevar a cabo esta tarea.
Evaluacin de calidad de procesos de desarrollo de software de fuentes abiertas, con el fin de conocer el grado de confianza que nos puede ofrecer una determinada empresa o comunidad de desarrollo de software en funcin de los procesos que siguen. De nuevo, esto incluye la creacin e integracin dentro de la Factora de todas aquellas herramientas que sean precisas para llevar a cabo esta tarea.
Los distintos socios que colaboran en cada una de estas actividades estn a cargo del desarrollo o integracin de nuevas soluciones, u otras ya existentes, que permitan asesorar sobre la calidad de un producto o
Pg. 74 de 119

proceso de desarrollo Diagnostico de la situacion No obstante, en de software de fuentes abiertas. ltima instancia la informacin sobre el producto y el proceso debe integrarse para ofrecer una visin global de una solucin que pretendemos incluir dentro de un proyecto de innovacin tecnolgica. Con este fin, la empresa italiana Engineering ha creado una nueva versin (publicada bajo una licencia abierta) de su entorno de asesoramiento de calidad para proyectos software Spago4Q. Este framework ofrece un entorno realmente completo que integra desde la parte de adquisicin de datos y creacin de mtricas y resultados, a la lgica de inteligencia de negocio para interpretar dichos resultados y ofrecer informes de asesoramiento sobre la calidad del proyecto analizado. Este framework estar tambin integrado dentro de la versin final de la Factora que estar disponible al concluir el proyecto. Nos centraremos aqu en el sistema de evaluacin de procesos, llevado a cabo dentro de la Actividad 6 de QualiPSo, por ser el ms interesante para el propsito del presente documento. En esta actividad, se est definiendo un completo marco de certificacin de procesos de desarrollo de software de fuentes abiertas, tomando como modelo el sistema de certificacin de madurez de procesos CMMI (que ya hemos presentado en un epgrafe anterior de este estudio). El nuevo modelo de certificacin de momento recibe el nombre de Open Maturity Model (OMM), aunque este nombre puede estar sujeto a modificaciones en los prximos meses. En las prximas secciones presentaremos brevemente cul es el plan de ejecucin para la creacin y definicin de este nuevo modelo de certificacin, as como un repaso de sus principales caractersticas (al menos, de aquellas que ya han sido consolidadas dentro del proyecto) y de los retos que todava plantea para el periodo de trabajo restante de QualiPSo.
<Insertar logo>
Pg. 75 de 119

4.4.1.1 OMM. Caractersticas la plan de creacin. Diagnostico de y situacion El modelo de madurez y certificacin de calidad de procesos de desarrollo de software libre de QualiPSo (OMM), pretende ser especificado sobre la amplia base de aceptacin del modelo CMMI, uno de los ms importantes y ampliamente extendidos del mercado actual para este propsito. Por otra parte, desde el momento del diseo inicial del nuevo sistema de certificacin se pretendan evitar determinados inconvenientes que a veces se achacan a CMMI como su excesiva complejidad al llegar a ciertos niveles dentro de la pirmide de evolucin y mejora. Por otra parte, CMMI no fue desarrollado originalmente teniendo en mente a los procesos de desarrollo de software de fuentes abiertas, los cuales presentan numerosas peculiaridades que dificultan su evaluacin utilizando este modelo (ms acentuadas, si cabe, en el caso de que se trate de procesos llevado a cabo en el seno de una comunidad de desarrollo de software libre, por tanto fuera de un entorno industrial ms controlado). Por todo ello, y para asegurar que el nuevo modelo de evaluacin propuesto respondiese a las necesidades del mercado objetivo al que se dirige (fundamentalmente, integradores de software que participen en proyectos de innovacin en los que se pretende hacer uso de software de fuentes abiertas), se estableci un plan de creacin en 5 fases, comenzando un un periodo de recopilacin de informacin sobre el estado del arte en este mbito. Este estudio fue finalmente complementado por una serie de entrevistas personales, junto con un cuestionario pblico, que se hizo llegar a responsables de proyecto, desarrolladores y en general, actores implicados en este sector para que pudieran ofrecer su opinin sobre aquellos aspectos que se consideraban capitales a la hora de evaluar el grado de confianza y madurez que ofrece un proyecto de desarrollo de software de fuentes abiertas. Concluido este proceso previo, se pas a la fase de anlisis de resultados
<Insertar logo>
Pg. 76 de 119

de la participacin de actores para extraer un listado de los 12 elementos Diagnostico de la situacion de confianza mejor valorados por los participantes para evaluar la madurez de un proceso de desarrollo de software de fuentes abiertas. Siguiendo una metodologa Goal-Question-Metric, este listado de elementos de confianza generaran una serie de objetivos a cumplir dentro del proceso de desarrollo a evaluar, que seran el punto de partida para la definicin del modelo de madurez, siguiendo el ejemplo CMMI. El modelo en s, una vez definidos los objetivos a cumplir, establece como veremos una serie de niveles de madurez a los que podemos ir accediendo conforme se cumplan los requisitos obligatorios para llegar a dicho nivel. Estos requisitos obligatorios estn, adems, acompaados por una serie de requisitos complementarios u opcionales que pueden refrendar an ms si cabe la obtencin de dicho nivel de madurez. Finalmente, una vez definido el modelo de evaluacin, se procede a estudiar las herramientas actualmente disponibles para la obtencin de las mtricas que ofrecen respuestas a las preguntas formuladas en el modelo, cada una de las cuales conectadas con uno o varios de los objetivos especificados. En caso de no existir ya una herramienta que ofrezca dichas mtricas, los socios evalan cules son las ms relevantes de cara a su posterior aplicacin, y se desarrollan nuevas herramientas desde cero para mejorar el soporte al proceso de evaluacin. Finalmente, el proyecto definir una serie de pruebas experimentales vara evaluar la utilidad y adaptacin a los requerimientos especificados del modelo y el sistema de evaluacin que lo soporta, ayudando a detectar posibles desviaciones para poder as refinar la definicin del modelo de evaluacin, antes de dar por finalizado el proceso de creacin.
<Insertar logo>
Pg. 77 de 119

<Insertar logo>
Imagen 20: Ciclo de creacin del OMM El proceso completo se resume en la Figura 2. En este momento, las dos primeras tareas se han finalizado por completo, y la primera versin del modelo de evaluacin de madurez de procesos ha sido propuesta. En el presente ao, se pretende ofrecer una segunda versin de dicho modelo, as como una primera y segunda versin del entorno de soporte para implementacin del sistema de evaluacin, y una primera ronda de experimentos para testear la validez del modelo propuesto. 4.4.1.2 Elementos de fiabilidad y confianza (TWEs).
Como resultado del proceso de evaluacin de las entrevistas y cuestionarios realizados en la etapa inicial de la actividad, se obtuvo un listado de 12 elementos crticos que deban ser evaluados para obtener una visin completa del nivel de madurez y confianza que ofrece un proceso de desarrollo de software de fuentes abiertas. El listado es el que ofrecemos a continuacin:

Calidad de la documentacin: completa y fcil de entender (PDOC). Popularidad del producto FLOSS (REP). Uso de estndares consolidados, bien conocidos y ampliamente
Pg. 78 de 119

extendidos (STD). Diagnostico de la situacion
<Insertar logo>
Disponibilidad y utilizacin de una hoja de ruta (roadmap) (RDMP). Calidad del plan de pruebas (QTP). Relaciones entre los diferentes actores implicados en el proceso de desarrollo (STK).
Existencia de un proceso de toma de decisiones para la seleccin de licencia/inclusin de mensajes de advertencia e informativos sobre la licencia del cdigo y la documentacin (LCS).
Vitalidad del proceso de desarrollo y adecuacin del proceso de subsanacin de errores (DFCT).
Requerir la mantenibilidad y estabilidad del producto/proceso (MST).
Disponibilidad de resultados de asesoramiento relevantes sobre el proceso de desarrollo (RASM).
Contribuciones al producto de fuentes abiertas por compaas de desarrollo de software (CONT).
Existencia de mtodos que fuercen el seguimiento de normas sobre calidad y correccin del cdigo de las soluciones desarrolladas (ENV).
Estos 12 elementos conforman la base sobre la que se definirn los Objetivos (Goals) marcados para alcanzar cada nivel de madurez en el proceso de desarrollo, as como las Preguntas (Questions) para evaluar dichos objetivos y las Mtricas (Metrics) para responder a dichas preguntas. El desarrollo de esta estrategia GQM permitir la definicin y mejora del modelo de evaluacin de madurez OMM.
Pg. 79 de 119

4.4.1.3 OMM. Anteriormente hemos presentado el modelo de evaluacin OMM como un sistema basado en la certificacin CMMI. En efecto, en la Figura 3 podemos ver cmo el modelo OMM define tambin una serie de niveles de madurez que puede llegar a alcanzar el proceso de desarrollo de software de fuentes abiertas, en el caso de que vaya cumpliendo los diferentes requisitos asociacin a cada nivel. Estos requisitos estn fundamentados en los diferentes elementos de confianza que hemos presentado en el apartado anterior, y que junto al sistema de niveles, conforman un proceso de evaluacin y asesoramiento que permite ir mejorando paulatinamente la fiabilidad y madurez del proceso de desarrollo analizado. El modelo de evaluacinsituacion Diagnostico de la de madurez de procesos
<Insertar logo>
Imagen 21: Niveles de madurez definidos en el modelo OMM Adicionalmente, se inici un proceso de comparacin e identificacin de concordancias entre los elementos de confianza definidos a travs de los estudios previos para el OMM, y los elementos de confianza definidos dentro del modelo CMMI. A continuacin, se identificaron aquellos

elementos de confianza dentro de CMMI que podan ayudar a completar Diagnostico de la situacion el esquema de evaluacin del OMM. La Figura 4 ilustra el proceso que se ha seguido en este apartado, y que de momento contina, a la espera de efectuar los primeros resultados de evaluacin del modelo OMM.
<Insertar logo>
Imagen 22: Proceso de establecimiento de correspondencias entre los elementos de confianza identificados para el OMM y los definidos en CMMI. A la hora de definir el proceso de correspondencias, se decidi limitar el mbito de inspeccin a los niveles 2 y 3 de CMMI, puesto que se consider que los niveles 4 y 5 son, en muchos de los casos, innecesariamente complejos como para aportar una mejora significativa del proceso de desarrollo, y por otra parte, porque sera demasiado difcil intentar adaptar su evaluacin en procesos de desarrollo de software de fuentes abiertas, especialmente en el caso de comunidades de desarrollo formadas en su mayor parte por voluntarios, que desempean su labor de forma distribuida y deslocalizada, fuera del control de un mbito empresarial tradicional.
Pg. 81 de 119

4.4.1.4 Conclusiones y perspectiva futura. Diagnostico de la situacion Actualmente, el modelo de evaluacin de madurez de procesos de desarrollo de software libre, OMM, contina en su fase de definicin y evaluacin interna, a la espera de contar con los primeros resultados experimentales que puedan arrojar alguna luz acerca de su utilidad y adecuacin para el mercado objetivo para el que ha sido concebido. Dentro del ao y medio de evolucin que todava resta en QualiPSo, el modelo deber recibir el soporte de herramientas que permitan obtener las mtricas que se definan para evaluar cada uno de los elementos de confianza identificados dentro del proceso de diseo. Adems, el modelo de evaluacin deber integrarse con el modelo de evaluacin de calidad de productos de software libre definido dentro de la Actividad 5 de QualiPSo. A su vez, el marco global de evaluacin de proyectos (proceso ms producto) ser integrado dentro de la Factora QualiPSo con el objetivo de proporcionar una plataforma de desarrollo de nueva generacin que ofrezca, adems, informacin de asesoramiento sobre el nivel de calidad de los proyectos de software de fuentes abiertas alojados en la misma.
<Insertar logo>
4.5
Comparativa
Pg. 82 de 119

CMMI Procesos de Enfoque Estndar internacional desarrollo sw/sistemas No ISO/IEC(SPICE) Proceso de desarrollo sw/sistemas Si ISO/IEC 15504-5 (SPICE Modelo/Marco CMMI-DEV , CMMIde mejora Ciclo de mejora asociado Tipos/Mtodo s de evaluacin Certificacione Instructores s autorizados para cada modelo Evaluadores A(SCAMPI), B y C IDEAL ACQ, CMMI-SVC for Sw development) ISO/IEC 15504-6 (SPICE for System Engineering) Gua para un proceso de mejora en ISO/IEC 155044 A, B, C y D (provisional) Mtodos/proceso de evaluacin debe satisfacer la norma ISO/IEC 15504-2 Instructores autorizados. Evaluadores provisionales y competentes por Certificacin de servicios TI en las empresas Certificados personales: Consultor certificado ISO Diplomado en ITIL Experto en Gestin de Servicios IT Mster en Gestin de Definido a muy alto nivel No es aplicable PDCA PDCA ITIL, COBIT ITIL Open Maturity Model (OMM) ISO 20000 Procesos de gestin de servicios TI Si ITIL Procesos de gestin de servicios TI No QualiPSo Procesos de desarrollo de software y productos software No
Pg. 83 de 119

20000 autorizados organismos acreedores. Tutor certificado ISO 20000 Auditor certificado ISO 20000 Organismo Certificador Software Engineering Institute (SEI) ENAC Los esquemas de certificacin de instructores y Otras es Mtodo de evaluacin con ISO/IEC 15504-2 evaluadores deben satisfacer las competencias identificadas en ISO/IEC 15504-3 y tienen que estar acreditadas segn la ISO/IEC 17024 Actualmente en estado de definicin IAF Servicios IT
particularidad SCAMPI compatible
Tabla 13: Comparativa de certificaciones de proceso
Pg. 84 de 119
Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta 5 SOFTWARE - PRODUCTO
<Insertar logo>
5.1
ISO 9126
5.1.1
Caracterizacin
Enfoque Calidad de Producto Software Si ISO/IEC 9126 (Software product quality) ISO/IEC 14598 (Software product evaluation)
ISO 25000:2005 SquaRE es una combinacin de ISO 9126 y ISO 14598
5.1.2
Descripcin general
ISO/IEC 9126 (1991) es un estndar internacional para la evaluacin del producto software, que define unas caractersticas de calidad y unas guas para su uso. En concreto se definen seis caractersticas de calidad y un modelo de proceso de evaluacin del producto software. Este modelo fue desarrollado a principio de los noventa como una manera de englobar los modelos existentes (ej: Boehm, McCall o FURPS entre otros) y cuyo objetivo principal es el de servir de estndar a nivel mundial. La mayor diferencia con sus antecesores es que se hace una clara distincin entre el significado de calidad externa y calidad interna. En el
Pg. 85 de 119

primer caso, la calidadDiagnosticocuando situacion es ejecutado, lo se refiere a de la el producto cual es tpicamente medido y evaluado en procesos de testeo y en entornos simulados. El segundo caso se refiere a todo lo que pueda ser medido de forma interna, como es el caso de complejidad del cdigo, facilidad de comprensin, etc. Este estndar est dividido en cuatro partes, bajo el ttulo general de Software engineering Product quality ,de la siguiente forma: Parte 1: Modelo de calidad, donde se describe un modelo de dos partes:
<Insertar logo>
calidad interna y calidad externa calidad en uso
Parte 2: Mtricas externas, donde se definen mtricas de calidad externas para su uso en el modelo definido en la parte 1. Parte 3: Mtricas internas, donde se definen mtricas de calidad internas para su uso en el modelo definido en la parte 1. Parte 4: Calidad en las mtricas de uso, donde se definen mtricas de calidad en uso para su uso en el modelo definido en la parte 1. Los indicadores de calidad as como las mtricas asociadas pueden ser tiles no slo para evaluar un producto software, sino tambin para definir requerimientos de calidad y otros usos. El estndar ISO/IEC 9126 (1991) ha sido reemplazado por ISO/IEC 9126 (Software product quality) y ISO/IEC 14598 (Software product evaluation). Adems, actualmente, el Comit Tcnico Conjunto ISO/IEC JTC1 Information Technology / CS7 Software and systems engineering est revisando ambas series de normas, y est elaborando una nueva serie, la ISO/IEC 25000, bajo el ttulo general de Software Quality Requirements and Evaluation conocido como SQuaRE, que abarcar a las series ISO/IEC 14598 e ISO/IEC 9126. Los indicadores de calidad existentes en el modelo pueden ser usados
Pg. 86 de 119

para especificar los requerimientos tanto funcionales como no funcionales Diagnostico de la situacion de los clientes y usuarios. Informacin ms detallada sobre este estndar puede encontrarse en http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_tc_browse.ht m?commid=45086 donde se puede descargar las caractersticas de cada una de las partes del estndar, previo pago.
<Insertar logo>
5.1.3
La primera parte de este estndar (Information Technology - Software product quality - Part 1: Quality model) hace referencia al modelo de calidad, un modelo de dos partes: a) Calidad interna y calidad externa: En esta parte el modelo especifica seis caractersticas para la calidad externa e interna, que sern ms adelante subdivididas en sub-caractersticas. Estas sub-caractersticas se manifiestan externamente cuando el producto software es usado como parte de un sistema, y son resultado de atributos internos del software. El modelo no est definido para niveles por debajo de estas subcaractersticas. b) Calidad en uso. Esta segunda parte del modelo especifica cuatro caractersticas de calidad en uso, sin bajar a niveles ms profundos. La calidad en uso se considera como el efecto que para el usuario tienen las 6 caractersticas de la calidad de producto combinadas.
Un esquema sencillo de estas partes se puede ver en la siguiente figura:
Pg. 87 de 119

<Insertar logo>
Imagen 23: Esquema de cada una de las partes de la ISO 9126
Se considera calidad interna como los aspectos de calidad medibles a partir de las caractersticas intrnsecas, como el cdigo fuente. La calidad externa se puede medir por el comportamiento del producto, como en una prueba, y la calidad en uso, se mide durante la utilizacin efectiva por parte del usuario. Las seis caractersticas que identifica el modelo para la calidad externa e interna, as como las subcaractersticas en las que se divide cada una de ellas, se aprecian claramente en la siguiente figura:
Pg. 88 de 119

<Insertar logo>
c a l i d e i n
a d e x t e r n t e r n a
f u
c i o
af i l a i d b a i l d i d u a s d a
i l i d e af i d c i e n m c i a a n
t e n
pi b o i rl i t d a a b d i l i d
a d e c u a e x a c t i t i n t e r o p e s e g u r i d a c c e s o c u l a
c a p a c i d a d p a r a s e r e n t e n d i d o n a d u r e z c a p a c i d a c d o mp a p r o a r l e r a n c i a a s e r a p r e n dt e i md o p o a i l l i l do a s d c a p a c i d a u d t i p l ia z r a a c dp ea c i d a d d e s e r o p e r a rd e o c u r s c u p e r a c i n c a p a c i d a d d e a t r a c c i c un m p l i m m p l i m c i ue nm t op l di m e i e n t o d e l a e f i c i f u n c i o nl a a l f i i d a ab d i l i d a d c u m p l i m i e n t o d l au s a b i l i d a d c u r a i m td o a bf cd a r e
c a p a c i d a d p a r a s e r a n a l i az d a ad p o t a b i l i d a d t a m i e n t o c a p a c i d a i d n s p t aa r l a b i l i d a d r a l s e r c a m b c i oa de x o i s t e n c i a i n d e e s t a b i l i d c aa dp a c i d a d p a r a o s c a p a c i d a s de r p r a e r e a m p l a z a d o s e r p r o b a d o i e n t o d e c u m p l i m i e n t o d e e n c i a c u m p l i m l i a e n p t o o r td a e b i l i d a d e l am a n t e n i b i l i d a d
Imagen 24: Sub caractersticas en las que se divide cada una de las partes De la misma forma, el modelo de calidad para calidad en uso define cuatro caractersticas, que se muestran en la figura siguiente:
Imagen 25: Caractersticas que define el modelo de calidad
5.1.4
Mtodo de evaluacin
Asociado al estndar para la calidad del producto existe el estndar para
Pg. 89 de 119

la evaluacin del producto software ISO 14598 Diagnostico de la situacion La relacin entre los dos estndares se puede apreciar mediante el siguiente esquema:
<Insertar logo>
e c u r s o s e n t o r n o
yP r o c e s o d e P r o d u c t o e v a l u a c i n s o f t w a r e
E f e c t o d e l p r o d u c t o s o f t w a r e
A p o y o a P l r a o c e s o Md e t r i c a s M t r i c a Ms t r i c a s d e e v a l u a c i e v n a l u a c i I n n t e r n a s e x t e r n a sc a l i d a d e n u s o
1 4 5 -19 8 1 4 5-29 8 1 4 5-39 8 1 4 5-49 8 1 4 5-69 8 1 4 5-59 8 9 1 -23 6 9 1 -22 6 9 1 -24 6 9 1 -21 6
Imagen 26: Relacin entre los estndares ISO 9126 e ISO 14598 Existe adems la serie de normas UNE 71048 que proporcionan mtodos para la medicin, valoracin y evaluacin de la calidad del producto software, basndose en el estndar internacional ISO 14598. Esta norma, al igual que el estndar en el que se basa, consta de 6 partes:
Parte 1: Visin general Parte 2: Planificacin y gestin Parte 3: El proceso para desarrolladores Parte 4: El proceso para adquisidores Parte 5: El proceso para evaluadores
Pg. 90 de 119

<Insertar logo>
Parte 6: Documentacin de los mdulos de evaluacin Diagnostico de la situacion
En concreto, las partes 3, 4 y 5, proporcionan los requisitos y una gua para el proceso de evaluacin en tres situaciones distintas:
La norma UNE 71048-3 debe usarse por organizaciones que
proyectan el desarrollo de un nuevo producto o la mejora de un producto existente y pretenden realizar la evaluacin del producto utilizando los miembros de su propia plantilla de tcnicos. Se centra en el uso de aquellos indicadores que pueden predecir la calidad del producto final mediante la medicin de productos intermedios creados durante el ciclo de vida.
La norma UNE 71048-4 debe usarse por las organizaciones que
proyectan adquirir o reutilizar un producto software existente o predesarrollado. Puede aplicarse para decidir sobre la aceptacin del producto o para la seleccin de un producto de entre varios alternativos. (Un producto puede ser auto-contenido, ser una parte de un sistema, o puede ser parte de un producto mayor).
La norma UNE 71048-5 debe usarse por los evaluadores que lleven
a cabo una valoracin independiente de un producto software. Esta evaluacin podra realizarse bajo peticin de un desarrollador, adquisidor u otros. Esta parte est destinada a aquellos que realizan evaluaciones independientes. Con frecuencia trabajan para terceros.
5.1.5
Certificacin
El IRAM, Instituto Argentino de Normalizacin y Certificacin, ha logrado formalizar el proceso de certificacin de productos de software a travs del modelo propuesto por la norma IRAM-ISO/IEC 14598 con su gua ISO/IEC 9126, y complementando su estructura con tres laboratorios evaluados segn los procedimientos internos, priorizando la competencia tcnica de los mismos.
Pg. 91 de 119

El modelo para la certificacin adoptado por IRAM siguiendo los Diagnostico de la situacion lineamientos de la norma IRAM-ISO/IEC 14598, se desarrolla en cuatro etapas. La primera consiste en el "Establecimiento de los requisitos de evaluacin" a travs de la determinacin de las caractersticas y atributos de calidad planteados en la norma ISO/IEC 9126. Esto dependen del tipo de producto software y el uso que se tenga destinado del mismo. Con las caractersticas y los requisitos de evaluacin definidos, se procede a la segunda etapa donde se realiza la "Especificacin de la evaluacin" Dependiendo del tipo de producto software que se trate y el alcance o la aplicacin definidos por el cliente, el modelo plantea analizar al producto software en tres dimensiones: Calidad Interna; Calidad Externa y Calidad en Uso. Considerando estas dimensiones, se evalan las ms adecuadas acorde con la definicin antes mencionada La tercera etapa consiste en "Disear la evaluacin", momento en el cual se realiza el plan de evaluacin cuantitativa, se establecen los mtodos de ensayo y se fijan los criterios de aceptacin. La ltima etapa es la "Realizacin de la evaluacin", donde se ejecutan los ensayos de testing, se registran los resultados de las mtricas evaluadas y en funcin de los mismos, se emite el dictamen al Comit General de Certificacin de IRAM, que lo analiza y realiza el otorgamiento de la certificacin de calidad de Producto Software para el nivel de evaluacin acordado IRAM ha desarrollado una marca asociada a la certificacin de los productos a fin de identificar tambin el alcance de la evaluacin del producto realizada.
<Insertar logo>
Pg. 92 de 119

<Insertar logo>
Imagen 27: Marca IRAM certificacin producto software
5.2
McCall and Boehm
Se trata de dos modelos presentados en 1973 por Boehm y 1977 por McCall. Ambos identifican caractersticas bsicas de lo que significa calidad desde el punto de vista de un usuario. Estas caractersticas, denominadas como factores, son los atributos de calidad ms externos los cuales son subdivididos a su vez en nuevos factores de calidad. Entre los factores ms relevantes analizados en el modelo de McCall encontramos: confiabilidad, eficiencia, integridad, ergonoma, mantenibilidad, pruebas de testeo, flexibilidad, portabilidad, reusabilidad e interoperabilidad. Por otro lado, en el modelo de calidad de Boehm tenemos: portabilidad, confiabilidad, eficiencia, pruebas de testeo, comprensin y modificabilidad.Deutsche Gesellschaft fr Qualitt A principios de los ochenta, la asociacin alemana para la calidad (Deutsche Gesellschaft fr Qualitt) conform un grupo de trabajo que ofreciera recomendaciones de como lograr calidad en software. Este grupo estaba compuesto por diferentes empleados de Nixdorf Computer, IBM de Alemania, Siemens AG y el instituto Fraunhofer.
Pg. 93 de 119

5.3 FURPS/FURPS+ Diagnostico de la situacion
<Insertar logo>
Este modelo de calidad fue desarrollado por HP para mejorar la calidad de sus productos. Bsicamente se definen cinco caractersticas de calidad las cuales a su vez se subdividen en otras 27. Por otra parte se definen una serie de mtricas las cuales son enganchadas con cada atributo de calidad. Usar este modelo de calidad significa llevar a cabo dos pasos bsicos, por un lado establecer prioridades y por otro lado establecer objetivos concretos para ser medidos a continuacin. Estas mtricas son especficas y dependen de la fase de la vida del producto en la que nos encontremos.
5.4
NASA SATC
El centro de software de la NASA (Software Assurance Technology Center SATC) desarroll un modelo de calidad con el propsito de ayudar a los gestores de proyectos. Inicialmente basaron sus investigaciones en los modelos de McCall, Boehm i el ISO 9126/1993, aunque se percataron de que no eran adecuados a los requisitos que tenan.OpenBRR OpenBRR es una metodologa general de evaluacin para software de fuentes abiertas. Su objetivo es definir una metodologa y un proceso de evaluacin completamente abiertos para clasificar, teniendo en cuenta parmetros del modelo de negocio de la empresa, las distintas posibles soluciones de software de fuentes abiertas que se podran adoptar para una situacin concreta. Est fundamentalmente orientado a la reduccin del Coste Total de Propiedad del software, y lo podran aplicar tanto empresas como desarrolladores para evaluar este tipo de productos. Se trata de una iniciativa que surgi de una comunidad que mostraba inquietudes en estos aspectos, siendo impulsado principalmente por el
Pg. 94 de 119

Carnegie Mellon WestDiagnostico de la situacion Center for Open Source Investigation, O'Reilly CodeZoo, Spike Source e Intel. Todas estas empresas e instituciones detectaron claramente la necesidad de que existiese un modelo de evaluacin abierto y homogneo para clasificar el software de fuentes abiertas en funcin de su calidad, dada la ingente cantidad de propuestas que se pueden encontrar en las diferentes forjas y repositorios. OpenBRR proporciona una serie de atributos de calidad los cuales directamente son obtenidos a travs de mtricas definidas. Es un modelo de calidad abierto, con lo que acepta modificaciones y es totalmente flexible en ese sentido, puesto que es muy fcil aadir nuevas mtricas o incluso atributos de calidad. Otro de los motivos para dotar a OpenBRR de un elevado grado de flexibilidad es que, en muchas ocasiones, es difcil poder captar todos los detalles del modelo de negocio de una empresa o un departamento dentro de ella, de forma que se pueda evaluar las opciones disponibles para ese caso en concreto. De entre los modelos existentes en el mbito de evaluacin de productos de software libre, es probablemente el ms extendido y el ms conocido de todos ellos. Muchos atributos de calidad que define han sido considerados tambin en otros proyectos como QualOSS, por ejemplo: calidad, seguridad, escalabilidad, arquitectura, soporte, documentacin, adopcin, comunidad y profesionalidad. Entre las criticas ms extendidas sobre el modelo de evaluacin de OpenBRR, la principal es el excesivo grado de complejidad con el que nos encontramos cuando queremos implementar una evaluacin. A pesar de los formularios permiten obtener un ratio resumen de toda la evaluacin en un solo nmero (facilitando de esta forma la comparacin entre diferentes productos evaluados), en la prctica cada uno de los formularios y tablas individuales usan muchas veces escalas de clasificacin no uniformes, cualitativas en muchos casos, y que tienden a aadir una fuerte componente subjetiva de la opinin de la persona que
<Insertar logo>
Pg. 95 de 119

realiza la evaluacin, en lugar de ofrecerla situacion Diagnostico de mtodos objetivos basados en mtricas obtenidas del producto para obtener una evaluacin menos sesgada.
<Insertar logo>
5.4.1
QSOS
Este modelo, desarrollado por la empresa ATOS Origin, proporciona dos tipos de secciones, una genrica y una particular para diferentes tipos de productos, como bases de datos, sistemas de gestin de contenidos, etc. Estas secciones estn de nuevo enfocadas a evaluar el nivel de adaptacin de un determinado paquete de software libre a los requerimientos tcnicos y funcionales que se requieren en un entorno empresarial. La seccin ms especfica est enfocada al apartado de funcionalidad. Todo la documentacin que contiene las especificaciones de la metodologa de evaluacin est publicada bajo la GNU FDL. Entre los aspectos ms positivos de la propuesta, cabe destacar un exhaustivo anlisis de las diferentes opciones de licencias de software libre existentes en el mercado, desde 3 puntos de vista posibles:
Propiedad: Analiza si los componentes de software derivados debern permanecer licenciados como software libre, o podrn crearse versiones bajo licencia propietaria.
Componente vrica: Estudia si otros componentes o libreras enlazados al software evaluado se ven inevitablemente afectados por su licencia.
Herencia: Evala si el cdigo derivado del software evaluado est obligatoriamente sujeto a las mismas condiciones, o se pueden imponer condiciones adicionales.
No obstante, como podemos ver la terminologa empleada puede resultar algo confusa, puesto que tradicionalmente se reconocen como licencias vricas a aquellas que de alguna forma fuerzan a que el cdigo derivado

se licencie bajo las mismas condiciones del software original. De la misma Diagnostico de la situacion forma, se han detectado diversas incongruencias entre el informe genrico y la versin web del mismo. Por ejemplo el atributo de calidad Exploitability aparece como un atributo de calidad de alto nivel, cuando por el contrario aparece como subatributo de calidad en la categora de Industrialized Solution. Adems se han detectado algunas deficiencias en la terminologa y definiciones usadas por QSOS como es el caso de Intrinsic Durability, cuyo significado no queda del todo claro. Estas lagunas merman considerablemente la aplicabilidad de este modelo, al menos hasta que sufra un importante proceso de revisin para ajustar las definiciones y conceptos recogidos en el mismo a los conceptos y trminos comnmente aceptados dentro del rea del software libre.
<Insertar logo>
5.4.2
Open Source Maturity Model
El modelo ofrecido por la empresa Navica (Cap Gemini) se basa en los atributos principales de producto, integracin, uso y aceptacin por parte de la comunidad. Comparte con los anteriores el hecho de que es un modelo de evaluacin completamente abierto, que cualquier empresa puede por tanto utilizar y adaptar sin coste alguno, y que est orientado a la evaluacin del nivel de adecuacin de una solucin de software libre para las necesidades especficas de la empresa. Las reas concretas que se evalan dentro de este modelo son: cdigo, soporte, documentacin, formacin ofrecida, integracin del producto y servicios profesionales. Sin embargo, de nuevo, las definiciones son algo imprecisas como es el caso de Integration Standards donde no se indica qu caractersticas relacionadas con los estndares hay que tener en cuenta. De hecho, el nivel de adopcin de este estndar es muy bajo, ya que es uno de los menos conocidos en el mbito del software libre.
Pg. 97 de 119

5.5 EN DESARROLLO Diagnostico de la situacion
<Insertar logo>
5.5.1
QualOSS
QualOSS es un proyecto de investigacin financiado dentro del programa EU FP6, cuyo objetivo principal es el de automatizar casi por completo la obtencin de mtricas de calidad para software de fuentes abiertas. Pretende definir una plataforma de evaluacin en la que se analizan dos tipos de datos: cdigo fuente e informacin sobre los repositorios de mantenimiento de cdigo fuente, que aportan informacin sobre parmetros del proceso de desarrollo que influyen en la calidad del producto final. Gracias a esta metodologa, se pretende que el modelo sea capaz de evaluar la calidad de proyectos de software de fuentes abiertas de manera cuantitativa, objetiva y eficiente. El objetivo estratgico de QualOSS (Quality of Open Source Software) consiste en mejorar la competitividad de la industria de software europea a travs de la creacin o mejora de metodologas y herramientas que permitan incrementar su productividad y la calidad de sus productos. Para lograr este objetivo, QualOSS ha identificado que diversas
organizaciones integran de una manera u otra software libre en sus sistemas. Sin embargo la seleccin final del producto a integrar se realiza de un modo ad-hoc sin seguir un proceso riguroso de seleccin. En el mundo de software propietario, el personal encargado de la seleccin de software est preocupada por el producto en s, pero tambin por la compaa que se encuentra detrs, particularmente interesan cuestiones como la reputacin de dicha compaa. Este factor tambin est presente en el mundo de software libre y es por ello que QualOSS se preocupa tambin de este punto. Existen algunas metodologas ya en el mercado para medir calidad en
Pg. 98 de 119

software libre, como es el caso de OpenBRR (Open Business Readiness Diagnostico de la situacion Rating) y QSOS (Qualification and Selection of Open Source) que han aparecido en los ltimos aos. Sin embargo son modelos que no se han extendido lo suficiente y no son considerados lo suficientemente rigurosos. 5.5.1.1 Modelo de calidad QUALOSS
<Insertar logo>
Teniendo en cuenta los modelos de calidad, se procedi a realizar una serie de entrevistas a empresas y organismos gubernamentales con el propsito de detectar cules son los atributos de calidad interesantes. Entre ellos se encuentran: funcionalidad, robustez, soporte y evolucin. A su vez estos cuatro estn subdivididos en otros tantos, que son:
Funcionalidad:
Rendimiento,
adecuacin
los
requisitos,
estabilidad y seguridad.

Robustez: Estabilidad, seguridad y madurez Soporte: Calidad de la comunidad y madurez del proyecto Evolucin: Madurez del proyecto, comprensin del cdigo fuente, uso de estndares, capacidad de testeo y mantenibilidad.
Pg. 99 de 119

<Insertar logo>
Imagen 28: Esquema del modelo de calidad A partir de aqu se realiz un modelo de calidad que result en lo siguiente:Se puede observar que los atributos de calidad bsicos son robustez y evolucin, los cuales se subdividen en producto, comunidad, proceso y herramientas y dependencias. 5.5.1.2 Metodologa
La imagen siguiente muestra la metodologa seguida dentro de QualOSS para el proceso de evaluacin. En esencia, se trata de un proceso iterativo (no cclico), en el que se identifican, dentro del conjunto de parmetros observables, aquellos que se consideran de especial relevancia para el caso de aplicacin. Se procede entonces a recoger (de la manera ms automatizada posible) todos aquellos datos y mtricas del productos que puedan aportar informacin en los aspectos anteriormente identificados. Finalmente, hay un apartado final de interpretacin de los
Pg. 100 de 119

resultados obtenidos en base a una seriesituacion Diagnostico de la de criterios que permitan establecer el resultado del proceso de evaluacin de la forma ms objetiva posible.
<Insertar logo>
Imagen 29: La metodologa de QualOSS se basa en cuatro tareas bsicas. 5.5.1.3 Iniciar el proceso
Se busca conseguir los siguientes objetivos:
Describir el contexto y la motivacin de la realizacin del estudio de calidad de un producto y su comunidad.
Explicar como va a ser usado el resultado del anlisis dentro de un contexto mayor (por ejemplo, se realiza un anlisis de un proyecto para integrarlo con otro o para compararlo con otros proyectos similares).
Enumerar requisitos que hayan de cumplirse, como es el caso de lmites de coste, tiempo o esfuerzo.
Pg. 101 de 119

5.5.1.4 Planificacin del anlisis Diagnostico de la situacion Los objetivos a alcanzar son los siguientes:
<Insertar logo>
Identificar adecuadamente los proyectos a ser analizados, por tanto debe estar claramente especificado.
Seleccionar al personal que realizar los anlisis e identificar a la comunidad de personas (por ejemplo desarrolladores de un proyecto) sobre los que pueda tener algn tipo de impacto este anlisis.
Planificar el trabajo de cada persona dentro de cada anlisis para compartir adecuadamente la carga de trabajo (por ejemplo mediante un flujo de trabajo).
Identificar herramientas que vayan a ser usadas y como han de ser configuradas para un anlisis de un proyecto en particular (diversos proyectos que puedan ser comparados pueden usar, por ejemplo, diversos sistemas de control de versiones). 5.5.1.5 Recogiendo y analizando los datos
Se persiguen los siguientes objetivos:
Recoger los datos cuyas fuentes de datos fueron identificadas en el punto anterior.
Analizar los datos usando los mtodos seleccionados en anteriores puntos.
Mantener la relacin con los datos en bruto, los mtodos y las herramientas usadas.
Validar los resultados obtenidos y el proceso de su obtencin. 5.5.1.6 Interpretar resultados
Se persiguen los siguientes objetivos:


<Insertar logo>
Interpretar y analizar los datos resultantes del anterior punto. Diagnostico de la situacion Mantener la relacin entre los datos analizados y esos resultados interpretados.
El modelo de calidad de QualOSS ha sido ya definitivamente establecido, y el proyecto se encuentra ahora en fase de implementacin de los procedimientos automatizados ms convenientes para obtener las mtricas necesarias para el proceso de evaluacin. La fecha de finalizacin del proyecto ser noviembre de 2009, por lo que para entonces todos los detalles de metodologa e implementacin del proceso de evaluacin se espera que ya sean definitivos y estn listos para su introduccin en el mercado.
Pg. 103 de 119

5.6 Comparativa Diagnostico de la situacion
ISO 9126 Calidad de Producto Enfoque Software OpenBRR QSOS OSMM QualOSS Calidad de Producto FLOSS y proceso de desarrollo Estndar internacio nal Modelo/M arco de mejora ISO/IEC 9126 (Software product quality) ISO/IEC Tipos/Mt odos de evaluaci n Certificaci ones Organism o Certificad or ISO 25000:2005 Otras particular idades SquaRE es una combinacin de ISO 9126 y ISO 14598 Excesivament e complejo y sujeto a posibles criterios demasiado subjetivos Indefinicin o confusin en algunos aspectos descriptivos de la metodologa Confusin en algunos apartados de la descripcin de su metodologa En estado de desarrollo, final previsto para noviembre de 2009. ----------14598 (Software product evaluation) --Basada en criterios adaptables que proporcionan un ratio final ----Basada en atributos y mtricas del producto Basada en atributos y mtricas del producto y proceso de desarrollo --Basada en atributos y mtricas del producto y proceso de desarrollo --Propio (abierto) Propio (abierto) Propio (abierto) QualOSS (abierto) Si No No No No <Insertar logo>
Tabla 15: Comparativa de las certificaciones de Softwares?
Pg. 104 de 119
Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta 6 Certificacin de aptitudes y competencias
<Insertar logo>
personales (PERSONAS)
En los ltimos aos ha aumentado la demanda de profesionales familiarizados con las tecnologas de software libre. Los programas de certificacin de las competencias personales proporcionan una manera tangible de demostrar de forma objetiva conocimiento y destreza para el desarrollo de software y el despliegue de sistemas de informacin basados en software libre. Dicha certificacin es especialmente relevante en este mbito, dado que la formacin en materia de software libre ha sido tradicionalmente en muchos casos de carcter autodidacta e informal. Por este motivo muchos puestos de trabajo ya favorecen a aquellos candidatos que cuentan con un certificado de Linux en su curriculum vitae. El objetivo de este captulo es analizar el estado del arte en materia de certificaciones personales de software libre en el mercado actual y evaluar las posibilidades de mejora en funcin de dicha demanda de mercado. A continuacin presentamos un breve repaso de los principales programas de certificacin de personas que se han encontrado a travs de una bsqueda exhaustiva en Internet.
Pg. 105 de 119

6.1 IT Card Diagnostico de la situacion
<Insertar logo>
6.1.1
Caracterizacin
Enfoque Personas
Estndar internacional Modelo/Marco de mejora Ciclo de mejora asociado Tipos/Mtodos de evaluacin Certificaciones Organismo Certificador Otras particularidades Examen personal Catlogo variado de mdulos de examen con diferentes niveles. ESI Entidad independiente & Ente promotor Posibilidad de compartir marca con el promotor del servicio de certificacin
Tabla 16: Resumen de caractersticas de ITCard
6.1.2
Descripcin general
Es un Servicio de Certificacin que acredita las competencias y conocimientos que un usuario tiene en las Tecnologas de la Informacin. Se trata de un servicio de Certificaciones (GUC-Good User Certificate) creado por la fundacin European Software Institute (ESI) pensando en dos tipos de pblico. Est dirigido a :
Organizaciones Ciudadanos.
involucradas
en
el
despliegue
de
iniciativas
orientadas al desarrollo de la Sociedad de la Informacin en los
Instituciones y Empresas interesadas en evaluar de forma objetiva e independiente los conocimientos que tanto sus empleados en plantilla como las futuras incorporaciones poseen en nuevas tecnologas.
Pg. 106 de 119

ESI, como entidad independiente, acredita los conocimientos en TIC de Diagnostico de la situacion las personas de manera que, independientemente de la forma en la que haya adquirido sus conocimientos, obtenga el reconocimiento que acredite un nivel determinado de conocimiento.
<Insertar logo>
6.1.3
Mtodo de evaluacin
Los usuarios se inscriben en el mdulo elegido (ms de 60, que comprenden Ofimtica, Internet, Sistemas Operativos Windows y Linux y OpenOffice) a travs de Internet. En el momento en que se inscriben, se genera un nombre de usuario y clave con los cuales acceden a la aplicacin de prueba. Las pruebas dirigidas a la ciudadana son realizadas en centros y entidades de formacin. ESI enva un listado de usuarios convocados a una prueba para que en el momento de realizar la misma, se compruebe su identidad. Las preguntas que el usuario debe responder en cada mdulo se generan aleatoriamente de una batera de preguntas. El nmero de cuestiones que el usuario tiene que responder es de 70, existiendo preguntas de tipo test (con respuesta simple o mltiple), de tipo imagen (el usuario ve una situacin y debe responder qu est viendo) de simulacin (se le presenta una situacin real en un programa), de relacin de conceptos y de ordenacin de conceptos. Cuando el usuario supera una prueba, se emite un certificado por parte de ESI, que luego generar la ITCard.
6.1.4
Certificacin
Pg. 107 de 119

<Insertar logo>
Imagen 30: Ejemplo de Certificados IT Card
Amplio catlogo de exmenes: ms de 60 mdulos de examen que cubren tanto herramientas comerciales como de software libre que cubren diferentes niveles de exigencia: del bsico al avanzado con actualizaciones continuas.
Imagen 31: Mdulos de IT Card disponibles
Pg. 108 de 119

6.1.5 Presencia en el mercado de las TICs Diagnostico de la situacion
<Insertar logo>
ESI ha firmado un convenio con el Gobierno Vasco, concretamente con SPRI, S.A., por el cual dentro del programa ITTxartela perteneciente al Plan Euskadi en la Sociedad de la Informacin, ESI es la entidad certificadora dentro del Programa. Once mil personas han accedido al Programa en dos aos, contabilizando la ciudadana y el personal del Gobierno Vasco que tambin se certifica a travs de ITTxartela. El mismo sistema de certificacin es utilizado en el Principado de Asturias, a travs de la Fundacin CTIC y su red de telecentros. Se han desarrollado proyectos en empresas privadas, concretamente del sector financiero, como Kutxa (Guipzcoa) y Caixanova (Vigo-Pontevedra). Este sistema de certificacin est en fase de implantacin en Bulgaria, a travs del ESI Center de Sofa, en colaboracin con el Gobierno Blgaro y en Panam por medio de ESI Center Cono Sur en colaboracin con COSPAE.
MBITO NACIONAL Comunidad Pas Vasco Asturias Castilla La Mancha Extremadura Pas Bulgaria Panam Ente promotor SPRI (Sociedad para la reconversin industrial) CTIC (Centro tecnolgico Asturias) Junta de Castilla La Mancha Junta Extremadura MBITO INTERNACIONAL Ente Promotor Ministerio de Administraciones Pblicas COSPAE
Tabla 17: Presencia geogrfica de IT Card
6.2
ITIL
ITIL, que ya se ha explicado en un captulo anterior, no tiene certificacin
Pg. 109 de 119

para empresas o servicios, nicamente la situacion Diagnostico de es un compendio de buenas prcticas aplicable a la gestin del servicio. Sin embargo se puede obtener acreditacin por parte de las personas. En ITIL V2 se pueden conseguir als siguientes certificaciones:
<Insertar logo>
ITIL Foundations: certificacin en fundamentos bsicos de ITIL Practitioners: certificacin en las distintas disciplinas o mdulos de ITIL
Service
Manager:
certificacin
para
expertos
en
Service
Delivery y Service Support La versin 3 sigue un sistema de crditos para la obtencin de las distintas acreditaciones: Diplomado en ITIL, Experto en Gestin de Servicios IT y Mster en Gestin de Servicios IT.
6.3
CompTIA Linux+
Es una certificacin independiente y genrica a travs de distribuciones, que valida el conocimiento de individuos con un mnimo de seis a doce meses de experiencia prctica en software libre. Acredita la gestin bsica de los sistemas Linux desde la lnea de comandos, la administracin de usuario, los permisos de archivos, configuraciones de los programas, y la gestin de clientes, de los sistemas del servidor y de la seguridad basada en Linux. Ha sido impulsado por diversas organizaciones como SuSE y Linuxcare y se trata de una de las certificaciones con mayor reconocimiento en el mbito de la industria.
El proceso consiste en la realizacin de un test, sin requisitos previos, y disponible en ingls y japons. En cada programa de certificacin ofrecen adems el material necesario para su preparacin y formacin especfica para el examen. Los exmenes se pueden realizar en los centros

existentes a nivel mundial de Prometric y Pearson VUE. Diagnostico de la situacion
<Insertar logo>
6.4
LPI
Es un programa reconocido internacionalmente, impulsado por una organizacin sin nimo de lucro, sistema. Consiste en la realizacin de diferentes tests para establecer un nivel de certificacin basado en el puesto de trabajo a desempear, para lo cual se usan procesos de psicometra que garantizan la relevancia y calidad de la certificacin. Los exmenes estn basados en un informe que llev a cabo en 1999 el LPI (Linux Professional Institute) a travs de una encuesta realizada entre profesionales de Linux a nivel internacional. El estudio se hizo con el objetivo especfico de ayudar a disear el contenido ms adecuado de los exmenes de certificacin LPI, proporcionando mucha informacin de la comunidad de Linux en general. El programa est diseado en diferentes niveles, existiendo tres niveles de certificacin y una especializacin. Los exmenes se pueden realizar en los centros existentes a nivel mundial de Prometric y Pearson VUE. que certifica la capacitacin de los profesionales de las TIC usando Linux y herramientas asociadas a este
6.5
Novell Corporation: Linux
Professional/Engineer
La empresa Novell ofrece desde el 2008 un programa de certificacin centrado en la distribucin de SUSE de Linux y orientado El fundamentalmente a administradores. Consiste en la realizacin de
exmenes para diferentes tipos de certificaciones profesionales.
primer nivel de certificacin es el Certifies Linux Administrator (CLA) que
Pg. 111 de 119

mide el conocimientoDiagnostico de lapero no necesariamente las acerca de Linux, situacion habilidades. El resto de las certificaciones son ms tiles en el entorno profesional, desde el Novell Certified Linux Desktop Administrator (CLDA), orientado a la administracin de escritorios, hasta el Novell Certified Administrator (NCA) para administracin de redes, servidores y servicios. Existen otros programas como el Certified Linux Professional (CLP), diseado para administradores bsicos, que ofrece un nivel bsico de certificacin e introductorio para aquello que aspiren a obtener el Certified Linux Engineer (CLE), que refleja habilidades administrativas ms avanzadas. Los exmenes se pueden realizar en los centros existentes a nivel mundial de Prometric. Sin embargo, estas certificaciones son independientes y no es un requisito de ninguno haber obtenido previamente alguno de los anteriores. Ofrece tambin servicios de formacin y preparacin para cada una de las certificaciones.
<Insertar logo>
6.6
Red Hat
Es una certificacin centrada en la distribucin de Red Hat que ha sido catalogada como una de las certificaciones actuales ms importantes. Un estudio reciente lo proclamaba como el programa de formacin y certificacin de mayor calidad en el mbito de las tecnologas de la informacin. Consiste en la realizacin de tests para medir diferentes niveles de competencia tcnica. Ofrece certificaciones tanto para alumnos sin experiencia que quieran desarrollar sus habilidades para el uso de Linux por lnea de comandos como para aquellos que quieran ejercitarse como administradores de sistemas Red Hat Enterprise Linux a distintos niveles. Tanto los cursos de formacin como los mtodos de evaluacin estn muy centrados en desarrollar habilidades prcticas. Su pgina web
Pg. 112 de 119

incluye cuestionarios Diagnostico de la situacion de evaluacin previa gratuitos para usuarios registrados para orientar sobre los cursos ms adecuados a cada cliente.
<Insertar logo>
6.7
Brainbench Certifications
Ofrece cuatro certificaciones diferentes de Linux para administradores y programadores. Dos de las certificaciones son de carcter neutral: genrico y 'Linux Administration' y 'Linux Programming' y otras dos son de materiales de referencia. Para obtener esta
especficas para SuSE y Red Hat. Los exmenes se realizan online y se permite el uso certificaciones es preciso realizar un curso de cuatro o cinco das de duracin, dependiendo de la certificacin, y aprobar un examen al final del mismo. Cubre el conocimiento de los conceptos bsicos a la hora de administrar un sistema Linux. El examen incluye los siguientes temas: Configuracin Windows. Esta certificacin est impulsada por Hands On Technology Transfer, Inc. (HOTT), una empresa proveedora de formacin en TIC que opera en Norte Amrica y Reino Unido. y administracin, Cuestiones generales, instalacin, 'networking', administracin de sistemas y seguridad y migracin desde
6.8
Mandriva Certification
El proyecto Mandriva ofrece formacin y certificacin tanto para usuarios como para administradores de su distribucin. Consta de un programa para principiantes (Mandriva Certification for enlightened Beginners-MCB) centrado en el uso bsico y la instalacin de Mandriva, y otro para usuarios avanzados (Mandriva Certification for Advanced Users-MCU), con vistas a formar especialistas en Linux/Mandriva en lo que respecta a su instalacin, configuracin y desarrollo. Por ltimo ofrece un programa orientado a administradores de sistemas basados en Linux/Mandriva

(Mandriva Certification For Networking situacion Diagnostico de la Administrator-MCA), sobre cuestiones de configuracin, seguridad y optimizacin de un servidor. Los programas incluyen acceso a los cursos y el material preparatorio para el examen, as como a foros especficos con tutores de apoyo disponibles.
<Insertar logo>
6.9
SAIR Linux GNU Certification
Sair Linux es una empresa privada, creada por Tobin Maginnis en 1999, proveedora de certificaciones de carcter neutral en Linux y GNU alrededor de todo el mundo. Funciona a tres niveles de certificacin, cada uno se construye en base al anterior. Las tres posibles cualificaciones son la de administrador (Linux Certified Administrator), ingeniero (Linux Certified Engineer) e ingeniero 'master' (Linux Certified Master Engineer). Cada uno de los programas contempla cuatro reas: instalacin de Linux, administracin de sistemas, conectividad de red, seguridad, y tica y privacidad. Los exmenes se pueden realizar en los centros existentes a nivel mundial de Prometric.
6.10
Las
MySQL Certification
personales de MySQL estn dirigidas
certificaciones
fundamentalmente directores, gerentes, desarrolladores y DBAs. Otorga al cliente:

Habilidades y conocimiento comprobables Disminucin de riesgos Grados de disponibilidad ms altos Mayor satisfaccin del cliente Una mejor productividad
Pg. 114 de 119

<Insertar logo>
Eliminacin de costosos errores de la situacion Diagnostico Reduccin de gastos de explotacin Mayores ingresos
Los consultores, desarrolladores y DBAs utilizan la certificacin de MySQL para demostrar a futuros directores y clientes que son conocedores de las ltimas herramientas y funcionalidades de MySQL. Es expedida por la fundacin y los exmenes son administrados a travs de los centros de exmenes Pearson VUE que se encuentran repartidos por todo el mundo. Est disponible el Associate Certification (CMA) para un nivel bsico que se obtiene pasando un solo examen, el Developer (CMDEV) and DBA (CMDBA) Certification, disponibles slo para MySQL 5.0, que consta de dos exmenes y el MySQL Cluster certification para la versin 5.1 de MySQL que requiere haber obtenido antes el CMDBA.
6.11
Solaris Certification
La empresa SUN ofrece programas de certificaciones, como parte del proceso de aprendizaje para validar los conocimientos y las habilidades de cara al mbito profesional. Contempla, por un lado, el manejo de los comandos principales de UNIX y tareas bsicas del sistema Solaris OS (Sun Certified Solaris Associate), por otro, el desarrollo de los procesos esenciales de la administracin de sistemas Solaris OS (Sun Certified System Administrator) y, por ltimo, capacidades ms avanzadas de administracin de redes y seguridad. El objetivo de la certificacin de Sun es evaluar para funciones profesionales especficas, por lo que la la formacin y preparacin previa al examen es un componente importante en el proceso de certificacin.
Pg. 115 de 119

6.12 Certificaciones Morfeo situacion Diagnostico de la
<Insertar logo>
La comunidad Morfeo puso en marcha a finales de 2008 el proyecto Morfeo Formacin y Certificacin en Tecnologas Libres donde inclua la iniciativa de certificacin Morfeo. Esta certificacin se propone como referencia para la certificacin de personas en tecnologas libres en general y en tecnologas desarrolladas dentro de la comunidad Morfeo en particular. En Morfeo Formacin y Certificacin se han diseado certificaciones en tres niveles. Esto significa que cada certificacin tiene entre uno y tres de los siguientes niveles:
Morfeo Professor: Esta certificacin debern obtenerla todas aquellas personas que deseen formar a la nueva generacin de profesionales en tecnologas desarrolladas dentro de la comunidad Morfeo. Se evaluarn tanto los conocimientos de la tecnologa especfica como sus capacidades de formacin. Debern conocer tanto las tecnologas Morfeo como la plataforma de formacin y la metodologa propuesta por el proyecto como la adecuada para la capacitacin de estas tecnologas.
Morfeo Developer: Esta certificacin est diseada para aquellos profesionales que desean atestiguar sus conocimientos en cada una de las tecnologas. Son gente capaz de utilizar las tecnologas y ayudarse en ellas para la ejecucin de sus desarrollos. Esta certificacin puede ser de gran utilidad para las empresas
Morfeo Contributor: Esta certificacin est diseada para aquellos profesionales que aseguran a la comunidad su profundo conocimiento de cada una de las tecnologas y su trabajo puede ser integrado dentro de la comunidad. Conoce el funcionamiento de la comunidad Morfeo y puede colaborar en el desarrollo de la tecnologa en la que se certifica.
Pg. 116 de 119

El objetivo del proyecto es crear de la plataforma de formacin y Diagnostico una situacion certificacin dinmica donde los mismos alumnos propongan nuevos cursos en funcin de sus necesidades de capacitacin. De manera anloga se crearn las certificaciones. No obstante durante el transcurso del proyecto de Morfeo Formacin & Certificacin estarn disponibles las siguientes certificaciones
Materia Tecnologas Libres EzWeb MyMobileWeb Niveles de Certificacin disponibles Morfeo Professor Morfeo Professor Morfeo Professor Morfeo Developer Morfeo Developer Morfeo Developer Morfeo Contributor Morfeo Contributor <Insertar logo>
No obstante estas materias podrn aumentar con nuevas tecnologas obtenidas de la forja Morfeo y a peticin de los alumnos y/o la comunidad. Las nuevas certificaciones podrn tener alguno o todos los niveles de certificacin.
6.13
Pseudo-certificacin en competencias
personales
Para cerrar este apartado, cabe destacar tambin algunos mtodos no regulados pero ampliamente aceptados por una parte significativa del mercado para establecer el nivel de competencias personales adquirido por un profesional. As, por ejemplo, el hecho de que alguien se haya convertido en desarrollador o mantenedor de un paquete de software para el proyecto Debian, o que haya obtenido privilegios de contribucin a un proyecto como FreeBSD, llevan implcitos la adquisicin de una serie de conocimientos y habilidades tcnicas muy valoradas en ciertos mbitos profesionales. La consideracin de estas menciones proviene del hecho de que, para poder obtenerlas, esa persona necesita haber demostrado su grado de competencia a otros miembros de estas comunidades durante un periodo de tiempo razonablemente amplio, de
Pg. 117 de 119

modo que pueda ser finalmente aceptado como un miembro activo ms Diagnostico de la situacion de la comunidad de desarrollo. Su valor radica, por tanto, en la ratificacin por parte de otros expertos neutrales, pertenecientes a la comunidad en cuestin, de las habilidades tcnicas del nuevo candidato. Por supuesto, se trata de algn modo de un mecanismo informal de validacin de conocimientos personales (aunque como hemos mencionado, tremendamente til en muchas ocasiones). Sin embargo, hasta la fecha no tenemos constancia alguna de que exista ningn tipo de iniciativa que pretenda formalizar la adquisicin de este tipo de menciones tcnicas dentro de un proceso de certificacin de competencias ya existente. Este podra ser, por tanto, un posible camino para complementar las iniciativas ya existentes con otro tipo de informacin complementaria, y valiosa, que ayudase a crear un perfil ms preciso de grado de formacin de un candidato.
<Insertar logo>
6.14
Comparativa
Casos de certificaciones de habilidades personales en materia de software libre
Pg. 118 de 119

Nombre Tipo PblicoImpulsores Reconocimien Diagnostico de la situacion objetivo principales to
Panam (COSPAE), Bulgaria (ITCARD) y en ITCard Neutral Ciudadana en general ESI y Gobierno vasco Espaa: Pas Vasco (KZGune), Castilla La Mancha (IT CARD) y Asturias (IT CARD) CompTIA Linux+ LPI Novell Certification Red Hat Certification Brainbench Certifications Mandriva Certification SAIR Linux GNU Certification MySQL Certification Solaris Certification Certificaciones Morfeo Neutral Neutral SuSE Red Hat Neutral, SuSE y Red Hat Mandriva Neutral MySQL Solaris Neutral Administradores Administradores Administradores Usuarios y administradores LPI, SuSE, Linuxcare LPI Novell Red Hat Internacional Internacional Internacional Internacional <Insertar logo>
Administradores Hands On Technology y Transfer, Inc. programadores (HOTT) Usuarios y administradores Administradores e ingenieros Profesionales Profesionales Usuarios y desarrolladores Mandriva Sair Linux MySQL Solaris Comunidad Morfeo
Norte Amrica y Reino Unido
Internacional Internacional Internacional Internacional Iniciando su despliegue.
Tabla 18: Comparativa de certificaciones de habilidades personales en materia de software libre
Pg. 119 de 119

EVC001 - DSA - Diagnostico de La Situacion Actual-Public

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

EVC001 - DSA - Diagnostico de La Situacion Actual-Public

Încărcat de

Drepturi de autor:

Formate disponibile

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Diagnostico de la situacion actual

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Procesos: Un proceso refleja una manera de trabajar, la manera en

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Se podan distinguir cuatro niveles diferentes de compatibilidad:

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Organismo Certificador Propulsores Dispositivos aceptados Distribuciones Linux

AENOR Lambdaux 11.547 Debian

Tabla 1: Comparativa de certificaciones hardware en software de fuente abierta

ISO/IEC 9001:2008 EFQM

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Tabla 2: Resumen de caractersticas de ISO 9001

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Ayuda a una organizacin a establecer y mejorar su Sistema de Gestin de Calidad

Estructura del modelo

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Imagen 1: Estructura de la norma ISO 9001:2008

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Certificaciones asociadas a la norma ISO 9001:

Presencia en el mercado de las TICs

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Tabla 3: Resumen de caractersticas de EFQM

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

La evaluacin de la situacin de la misma en cada una de las reas.

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Un conjunto de reglas para evaluar el comportamiento de la organizacin en cada criterio.

Hay dos grupos de criterios :

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

EUSKALIT, organizacin en el Pas Vasco de EFQM.

Presencia en el mercado de las TICs

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

23 organizaciones obtuvieron la Q de Oro (puntuacin de 500 o superior)

116 organizaciones obtuvieron la Q de plata (puntuacin de 400 puntos o superior).

nicamente dos de las empresas premiadas son del sector Servicios.

Tabla 4: Resumen de caractersticas de IT-Mark

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

responsabilidades, requisitos legales (Proteccin de Datos Personales, etc), y controles de seguridad

Nivel 3: Mejora Continua del Sistema de Gestin de la Seguridad de la Informacin

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

CMMI Nivel 2: de la situacion Diagnostico Planificacin del

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Estudio de viabilidad tcnico financiera para certificacin de software de fuente abierta

Imagen 7: Requisitos a cumplir en los distintos niveles de IT Mark

Estructura del modelo

Los modelos de referencia de la certificacin IT Mark son tres: